From: wcs@anchor.ho.att.com
Date: Mon, 13 Feb 95 19:42:42 PST
To: cypherpunks@toad.com
Subject: Distributed Key Service for PGP (was: why pgp sucks)
Message-ID: <9502140340.AA28899@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


Matt Blaze writes:
> >Doesn't having some kind of central record of keys go against
> >the principle of PGP?  
> 
> The only "principle" of which I'm aware (and particularly interested
> in supporting) is that of having widely fielded, useful and strong
> privacy and authentication tools that work properly and transparently.
> That means, among a great many other things, flexible protocols
> and tools that support remote key distribution services.

Another main principle of PGP is that it _has_ to be able to work
in a decentralized fashion, so it's usable by
> the civilizing forces of Anarchy (PGP?)
even if the most common uses are in the centralized wired real-world.

Perry and other write:
[ lots of things about the need for distributed scalable key servers ]
[ particularly the numeric-only IDs. ]
There are two main times you need to get PGP keys -
encrypting a message to someone, and validating a signature from someone.

The former can be distributed easily enough - use something DNS-like
to serve keys for joe_user@foo.bar.com, and add them to your local
keyring if they're not there (possibly with temporary keyrings,
if that's easy enough on PGP version N.) 
Fetching keys needs to be a separate tool from PGP anyway,
since PGP should be general enough to work on wired and unwired systems,
with different protocols and APIs for using the available networks.
(And of course, the fetched keys need to be validated using web_of_trust
or whatever, adding yet another step.)  Sounds like a job for a shell...

The latter problem is more difficult - partly PGP's fault, but partly 
because the underlying problem is harder.  Signed documents _may_
arrive from keyids not on the keyservers, whether they're from
non-wired users, users who wish to remain pseudonymous,
one-or-two-use keys, etc....  What PGP can be blamed for, which will
hopefully be addressed in version 3.x, is that it's possible to have
collisions in the abbreviated key_ids, especially for the optional
short key_ids that have been requested as an added feature for people
who _very strongly_ want to remain anonymous.
(There have already been collisions in the 24-bit key_ids,
and it's been shown that it's possible to generate arbitrary key_ids
if you _want_ to cause a collision, as well as birthday-problem 
probabilities of random collisions.)

One way to address it is to make it easy to loop through a bunch
of keys with the same key_id, which is a bit tough given PGP's current
MS-DOS-like interface.  Another way is out-of-band attachment of the
user_id with the message, followed by DNS-like lookup, or attachment of
the signature key with the message, accompanied by a lookup to validate it.

As Matt said, there's a lot of policy-vs-mechanism issues here;
PGP version 3.0 will have some library support that makes it
easier to build some of these things.

		Bill