On 2019/06/30 18:06, Daniel Kahn Gillmor wrote: > On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote: >> Indeed, c) was exactly the killer use case I had in mind. > > so, how do we get there?
We start from hagrid or something like it, and carefully add the ability to sync only the absolute minimum of data required to allow revocations to propagate. This probably means primary keys, their self-sigs and revocation sigs. (*Maybe* subkeys also, but it's probably unnecessary since distributing new key material is less urgent than revoking existing material.) We could repurpose the existing SKS recon protocol, but introduce breaking changes: a) the protocol is versioned so that implementations can gracefully degrade, and b) only whitelisted packet types are synced. >> On the other hand, b) is also quite useful in the short to medium >> term, until all mail providers decide to support WKD etc. > > WKD is mighty nice, but it is not necessary. For example, if you don't > care about first-contact, Autocrypt is a totally reasonable key > discovery mechanism. Sure, but WKD and Autocrypt still don't collectively cover all the edge cases, so some residual need for a keyserver-like system remains. >> And considering that some companies still don’t fully support PGP/MIME >> after nearly twenty years of being the preferred standard (I’m looking >> at you, Apple), “short to medium” effectively means “indefinitely”. > > If you know something specific about Apple failing PGP/MIME in some > capacity i hope you'll be more explicit about it, because i don't know > what you're talking about. iOS's native Mail app cannot be replaced, and all third-party mail apps must use its API which is less than fully-featured. Constructing a PGP/MIME message requires access to the MIME headers that the Mail app does not expose. All PGP apps under iOS must either cut and paste inline PGP or encapsulate messages as attachments that Mail treats as black boxes. PGP on iOS is therefore klunky as hell, and it's not going to improve unless Apple makes a conscious decision to support it. > Anyone who claimed > keyservers were authoritative in the past was either confused or > misleading you. I am under no illusion that the keyservers are authoritative, don't worry. A comparison with DNS may be useful. DNS is a distributed cached database, but there is a distinction between primary, secondary, recursive etc. Recursive resolvers make the system resilient, but the primary is consulted regularly and the cache constantly invalidated. (In DNS of course, the master is also considered authoritative, but this does not automatically follow in a cryptographically validating system) The keyservers make no distinction between primary and secondary - all keyservers are equal, the provenance of data is thrown away, and the cache can therefore never be invalidated. But provenance matters, and if synchronising keyservers can't be primaries, something else should be. That can be WKD, DANE, or just a plain URL on a server that I control. Keyservers would then be mainly limited to caching information that was obtained from some master keystore (with the exception of material strictly required for revocations). OpenPGP already has the "keyserver" field which is rarely used. It is supposedly a hint to clients to tell them to prefer a particular keyserver, but it could also be used as a hint to the keyservers themselves, to tell them where the master copy of any public key can be sourced. > If you want to propose changes to > https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore > i'd be happy to incorporate them too. I'd suggest adding a "caching keystore", either after or as a subsection of "updates-only keystore", with the following properties: ``` A caching keystore extends the concept of an updates-only keystore, by supplying user IDs and third-party certifications on the condition that they were recently available at an original location specified by the key's owner. This mitigates key-flooding attacks by preventing arbitrary submissions, and allows for the coordinated deletion of old or problematic material by removing it from the original location. * A caching keystore MUST accept submissions of primary keys as well as cryptographically-valid self-certification and revocation sigs (including third-party revocations) over those primary keys. * It MAY synchronise the above key packets from other keystores. It MUST NOT synchronise, or accept external submission of, any other packets. * It SHOULD attempt to fetch and temporarily cache user IDs and incoming third-party certifications over each primary key from the URL contained in that primary key's "keyserver" field, if defined. * If more than one "keyserver" definition is found for a given primary key, then the most recent cryptographically-valid packet MUST take precedence. * It MUST cryptographically verify all fetched material. * It MUST discard any unexpected fetched packets, even if they are cryptographically valid. In particular, it must discard any outgoing third-party certifications *from* the fetched key, in case they flood some other key. * It MAY impose further restrictions on cached packets (e.g. it may choose not to cache image IDs). * It SHOULD delete cached packets after a reasonable period of time once they can no longer be retrieved from the "keyserver" URL. ``` -- Andrew Gallagher
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
