key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Jan 16 19:40:36 CET 2018
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>
More information about the Gnupg-users
mailing list