Global Directory signatures

[David Shaw]

On Fri, Dec 31, 2004 at 07:18:53AM -0000, Greg Sabino Mullane wrote:

> I've been working on this problem for a while, and finally had a
> chance during this past break to hash out some final issues. I'm
> going to be expanding biglumber soon into a "real" keyserver.
> However, it's going to be a little different from other keyservers.
> The main difference is that the owner of a key will have complete
> control of their public key. This means that (for example)
> --recv-key will work, but --send-keys may* not. If you want to make
> a change to your public key, you must authenticate (currently via
> web/email, but either alone someday). In addition, the keyserver
> will only have entries from people who are either in the strong set
> or who have added their key to biglumber directly. I consider the
> fact that anyone can upload another person's changed public key to a
> keyserver a potential Denial of Service, and thus will not allow it.

Very neat!

I'm curious about the details.  What keyserver protocol are you
planning to use to communicate with the outside world?  (http like the
current biglumber? hkp? ldap?)

You may well have addressed this already, but there are a couple of
hidden gotchas in a design that only allows the key owner to prevent
third-party updates.  Consider the case where Alice signs Baker's key,
and Baker stores this signed key in biglumber.  If Alice then revokes
that signature, Baker may well choose to keep the signature but
discard the revocation.  This makes a false link, and is an attack
against Alice and anyone who trusts Alice's signatures.

There are similar problems with designated revocations.  Baker has his
key stored in biglumber but it is compromised.  Alice is Baker's
designated revoker, and generates a revocation certificate for Baker
but cannot upload it because the false "Baker" won't allow her to.

A simple solution to all of this is to allow some modifications to
take place on keys without key owner approval: signature revocations
(only if the original signature exists on the key), key revocations
(anytime), and designated revocations (only from a designated
revoker).  Note that 'sensitive' designated revocations come with
their own designated revoker status.

Incidentally, I believe the GD handles these issues correctly, though
I'm not sure about designated revocations.  I know I discussed them
with the PGP folks when they were designing the GD.

David