Launching a new keyserver on keys.openpgp.org!

[Michał Górny]

On Tue, 2019-07-09 at 14:54 +0200, Dirk Gottschalk wrote:
> 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.

I don't think you understood my point.  There is no reason why
the attacker wouldn't be able to upload all the garbage keys used to
create garbage signatures.

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

No, I'm talking about permission to distribute signature, i.e. the proof
that the key owner has accepted it.  Otherwise, GnuPG is still
vulnerable to being hit by a single malicious keyserver in the pool.


-- 
Best regards,
Michał Górny

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