key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
andrewg at andrewg.com
Mon Jul 16 12:57:37 CEST 2018
On 13/06/18 14:43, Daniel Kahn Gillmor wrote:
> the proposed revocation distribution network wouldn't allow any user IDs
> or third-party certifications, so most of the "trollwot" would not be
As I see it, the keyservers perform two related but distinct functions -
finding unknown keys by UID, and finding updates to known keys by
All the current issues are related to the first function, but the first
function has several alternative solutions available (DNS, WKD, Keybase,
attaching pubkeys to every email...). If this first function were to
fail overnight, it would be an inconvenience but not a disaster.
But there is no known alternative to the second function, which is the
distribution of key updates, including revocations. Therefore I believe
the immediate priority should be to protect update distribution.
How to prevent abuse of a distributed, unauthenticated store of
arbitrary data remains an unsolved problem (see: usenet). If the
keyservers are to remain unauthenticated and distributed, then the only
option is to prohibit arbitrary data. That means no arbitrary data
fields (i.e. no UIDs) and no arbitrary data in structured data fields
(i.e. validity checks on self-sigs). This will shrink the size of the
database significantly, but impose some processing cost.
There are two ways forward: a new network of key-material-only servers,
or restricting the existing network to key material only. In the first
case, we would still need a means to propagate keys between the old and
new networks during the transition. And in the second case, we would
need to handle an intermediate state where only some servers have been
upgraded to the new version.
So no matter what we do, we will still need to have some method of doing
fake recon with legacy sks instances. The question is how to arrive at
this state most efficiently. I would suggest that since recon is at the
root of the problems, we should concentrate on the recon process itself.
If uploading a bad key takes down one server then fine, we can lose one
server. But the badness must not infect other servers automatically.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 862 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users