Launching a new keyserver on keys.openpgp.org!
mgorny at gentoo.org
Tue Jul 9 14:40:18 CEST 2019
On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel
> 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 be trivially worked around via uploading the flooding keys to
the server. After all, it accepts *all* keys, only UIDs it restricts.
> 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.
This presumes you can trust the server, and therefore solves only half
of the problem. If the server eventually becomes distributed, you would
also need to authorize cross-server exchanges. This still could be done
via hacking on HKP but in the end I think it's preferable to store
the permission on the key somewhere, so that end users can also benefit
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: This is a digitally signed message part
More information about the Gnupg-devel