Launching a new keyserver on keys.openpgp.org!
dirk.gottschalk1980 at googlemail.com
Tue Jul 9 14:31:58 CEST 2019
Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter:
> Dear Hagrid Team,
> Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> > the Hagrid team is pleased to announce the launch of our new
> > keyserver,
> > running at keys.openpgp.org!
> > https://keys.openpgp.org/about/news#2019-06-12-launch
> > Some of the things we do are a bit experimental. For some things we
> > found
> > that there is no good mechanism at this point, so we decided to
> > drop them
> > for now.
> it is good to see more code around OpenPGP.
> Maybe hagrid can be useful to improve the common infrastructure to
> distribute public keys in the future.
> From my point of view the service announcement and its description
> is a bit problematic, though:
I fully agree with Bernhard. And I, for myself, think that strißßing
off third party signatures is a bad idea as well. It should be possible
to implement some kind of validation for them. Another way could be to
make only signatures from keys which are already on the server
available. Something like "import-clean" does on import. This would
avoid flooded keys. It could also be possible to filter out double
signatures which are made unintented. So it happened to me with key of
Werner a while ago. Sorry for this, Werner, something went wrong.
The other pint is, the hkp protocol should be expanded to some kind of
authentication, so only the owner can upload and update a key. The
hagrid approach, which forces people to upload the keys via web, as far
as I could look into it, is a bad solution for automatic systems. Yes,
I know, they offer some kind of Api for this, but it doesn't work just
utilizing gpg itself, as far as I can tell at this moment.
I tested the new server and it works. It's not a bad solution, but I am
missing some functions.
I think we should not only touch the server side. We should improve
both sides, or in other words the underlying protocol.
I know, all People involved in GnuPG have enough work to do. I am
willing to help where I can.
GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the Gnupg-devel