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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users