On Tue 2018-01-16 01:02:11 +0000, listo factor via Gnupg-users wrote: > Burning it down is not what I was advocating. I am advocating orderly > evacuation and replacement of a system that has clearly outlived its > usefulnesses. If it is not replaced in time, it will, at some point, > burn ignited by forces we have no control over. ~Then~ it will have > to be abandoned in rather more painful manner - just as you are > alluding to.
While i think we disagree on "has outlived its usefulnesses", i would agree that planning and preparing for catastrophic keyserver network failure is a good idea. What i haven't seen in this thread is a list of the variety of proposals for OpenPGP key distribution that do *not* require the global append-only keyserver network. So in the hopes of making this a productive discussion, i'll list a few. Already briefly mentioned are: * Web Key Directory (WKD) Mail provider publishes public keys of users via https to a well-known location. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-05 * Keybase social media and other avenues for key publication, identification, and corroboration. https://keybase.io A few other approaches are: * DNS OPENPGPKEY records DNS lookups of public keys (or hashes of public keys for confirmation) https://tools.ietf.org/html/rfc7929 * Autocrypt In-band key exchange (in every e-mail message) removes the need for external distribution mechanisms for all messages but the first. https://autocrypt.org/ * VVV DNS (SRV) discovery of HKP service operated by the mail provider. https://keys4all.de/media/beschreibung-vvv-loesung.pdf I'm sure i've missed some other distribution/verification/update mechanism, and would be happy to see constructive pointers. Of the above, i'm most leaning toward Autocrypt today, because it does not require involvement of any third party -- as long as both sides of the e-mail use an autocrypt-capable client, there is no additional information leakage. Note that the different schemes have different properties in terms of: * information leakage * cryptographic verification * third-party control * censorship * ... The keyserver network (or some future variant of it) can of course play a role in parallel to any or all of these. for example, keyservers are particularly well-situated to offer key revocation, updates to expiry, and subkey rotation, none of which would necessarily involve names or e-mail addresses. It would be interesting to see a network of keyserver operators that: (a) did cryptographic verification, and rejected packets that could not be verified (also: required cryptographic verifications of cross-signatures for signing-capable subkeys) (b) rejected all User IDs and User Attributes and certifications over those components (c) rejected all third-party certifications -- so data attached to a given primary key is only accepted when certified by that primary key. This would basically be a network that facilitates update/revocation/key-rotation, without exposing any names or e-mail addresses to the public by default; it could be run in parallel with the existing keyserver network. i don't know how well we could bridge the two networks, though and it'd be a shame to have to upload updated keys to both networks manually. :/ anyway, hopefully this gives some concrete, positive next steps that folks who want the keyserver network to go away can take, rather than trying to burn it all down :) --dkg
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users