Global Directory signatures (was Re: GPG wants to check trustdb every day)

[David Shaw]

On Sun, Jan 02, 2005 at 03:54:19PM -0500, Jason Harris wrote:
> On Thu, Dec 30, 2004 at 09:48:22PM -0500, David Shaw wrote:
> 
> > Which shows that people aren't actively bridging keys, or you'd have
> > vastly more than 120 signatures issused by the GD key on the keyserver
> 
> Regardless of your particular semantics of "actively bridging keys,"
> signatures from 0xCA57AD7C are showing up on the regular keyservers.

I'm fairly sure you understand the difference between "active" and
"passive", and if not, it should be quite clear from the context.  I'm
not going to explain it again.

I'm happy to continue having this discussion, but if you would rather
play "neener neener neener" games, I'd just as soon pass.  I'd rather
do something productive.

> Having read the FAQ for GD, I believe pgp.com sees the 14 day
> expirations as a real feature and won't be changing that value
> anytime soon.  If so, it may be reasonable for regular keyservers to
> remove all signatures by the GD key that have expired, or perhaps
> not to store any at all.  Clearly, such expired signatures only
> serve to bloat keys on users' keyrings and regular keyservers.
> 
> A much better design would be to issue yearly signatures and revoke
> them when a key is removed from the GD.  This way, multiple GD
> signatures are caused (mostly) by the users' actions and/or
> inactions.

I'm not as sure as you that the 14 day expiration is intended to be
permanent.  It may be, as it does very well serve to cap the time
after a key has been retrieved from the server but before the client
must go back for a refresh.  The GD works on 6 month increments, so a
6 month signature would seem to be the obvious duration to use, but
that of course does not handle as well the case where the key is
removed from the GD (or replaced within the GD) before 6 months is up.

> Also, the GD should store expired and revoked keys.  Users who rely
> solely on the GD keyserver now must search for each key by email
> address before encrypting to it or trusting a signature from it.  If
> a key is expired by a signature not yet downloaded from GD, but the
> key is already gone from the GD, how else is a user to know the key
> has expired?

The user would be forced back to the GD for a new 14-day signature at
which point they would discover that the key is missing so no new
signature would be available.  This makes the key invalid in their
trust calculations.

> Worse, if a key has been compromised, how is the keyholder supposed
> to record that fact with the GD?

I don't think that is the intent of the GD.  Rather, the idea is that
if you find a key on the GD, it is a usable key.  Period.  If a key
isn't usable (revoked, expired, etc), it should not be on the GD at
all.  A compromised key would presumably be removed from the GD by the
owner so it could not be served at all.

> Refreshing one's keyring only from the GD only using keyids cannot
> reveal unusable keys.

As before, if the key itself no longer exists on the GD, you will not
get another 14-day signature, and the key will become invalid to you.
Sure, you could dream up a scenario where a key was revoked and then
removed from the GD so the actual revocation was only posted to the
keyserver net, but note that the GD did the right thing for its design
here - it stopped serving the revoked key.  It is not responsible for
serving the revocation, since it only serves keys that are usable.
Shortly after all this happens, the 14-day signature expires and the
GD is completely uninvolved.

Remember that the GD is intended to be the "keyserver of last resort"
for new users.  If it isn't on the GD (or the 3-4 places PGP looks
before it falls over to the GD), the key doesn't exist.

David