Launching a new keyserver on keys.openpgp.org!

[Dirk Gottschalk]

Am Dienstag, den 09.07.2019, 14:40 +0200 schrieb Michał Górny:
> On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel
> wrote:
> > Hi.
> > 
> > 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:
> > 
> > [snip]
> > 
> > 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.

It could be done by cleaning the keys after recieving. At first there
surely will only a few signatures be shown, but with a growing
database, it would be a good idea. It would be possible to preseed the
database with the strong set, or with other well known clean keys.

> > 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 from it.

That could be one was. On the other hand, there is no need für the sync
to also use HKP. There are other options to sync the database. And I
prefer the decentralized approach, so decentralized servers are
mandatory. 

Permission? I think you are talking about the permission to distribute
the UID. That doesn't need to be stored in the key and it should not
be. Assuming the recipient knows who he is talking to and has recieved
the complete key directly from the sender, is there any nead for the
recipient to know that the sender doesn't want his UID to be leaked on
the servers? This could lead to wrong assumptions on the recipients
side.

Regards,#
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190709/1aac43cc/attachment.sig>