New keyserver at keys.openpgp.org - what's your take?

[Michał Górny]

On Tue, 2019-06-25 at 16:30 +0200, Vincent Breitmoser via Gnupg-users
wrote:
> > Hi @ll.
> 
> Hi Dirk,
> 
> thanks for your thoughts!
> 
> > I don't think it's such a good idea to drop Signatures on keys.
> 
> As mentioned in our FAQ, the reason we don't support those is that with the SKS
> model, anyone can attach arbitrary data to others' keys.  It's hard to overstate
> how problematic that is. I can just add a megabyte or fifty of data to your key.
> 
> There are solutions that still allow for some of the TPS-based use cases, but
> until there is at least some agreement on how to proceed, we decided against
> supporting them.
> 
> Free distribution of arbitrary TPSes is quite simply not a viable model for any
> keyserver. The discussion shouldn't be about liking or disliking them, it should
> be about what alternatives could be.
> 
> I see from your signing policy that you do a caff-style workflow. Have you
> considered the option to have keys cross-sign third party signatures for
> publication? It's a very slight switch in tooling if we assume a caff workflow,
> but that way each key remains in control of the public version of itself.
> 

I honestly neither like the idea of requiring the 'first party' to
explicitly confirm all signatures, nor losing compatibility with
existing software in order to implement that.  The latter should be
quite obvious so I'll focus on the former.

In Gentoo we're using a CA-like model with a central service signing
UIDs of all developers.  It is *convenient* for it to be able to inject
those signatures into keys of the developers, and distribute them along
with them.  If we required developers to explicitly import
the signature, certify it and upload the key I'm pretty sure our
coverage would go down because people simply won't care.  The problem is
that this bites not developers who don't care much but users who lose
the ability to verify the key easily.

As an alternative: since keys.openpgp.org makes keys without verified e-
mail addresses practically useless, why not permit only those signatures
that were made using a key that's on keys.o.o and has at least single
verified e-mail address?  If you combine that with accepting only one
signature per certifying key (i.e. pruning old signatures), it should be
'good enough'.  That is, as long as attackers won't decide to create
and verify humongous number of e-mail addresses.

This could work fine alongside 'first-party attested blah blah' model,
or at least work as an interim solution until the latter is widely
deployed.

-- 
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-users/attachments/20190702/d7d2f9ef/attachment.sig>