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