key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180116/900d99c1/attachment.sig>