PGP Global Directory

David Shaw dshaw at jabberwocky.com
Sun Dec 12 16:41:36 CET 2004


On Sun, Dec 12, 2004 at 12:14:39PM +0000, Neil Williams wrote:
> On Thursday 09 December 2004 1:28 pm, David Shaw wrote:
> > Hi Folks,
> >
> > I figured I'd forestall the obvious question about the new keyserver
> > that the PGP company announced this morning:
> 
> Where can I find out some facts about this signing keyserver
> protocol? I've heard some rumours of what it's doing to 'verify' the
> uploaded key but what's the truth?
> 
> Rumour: Keys uploaded to the new keyserver result in an email to the
> main email address of the key to see if the email address in the key
> actually exists and is functional and, if so, the key is signed by
> PGP's Global Directory Verification Key.

Close.  It results in an email to every email address on the key, but
the rest is basically correct.

> Problem:
> If that is truly all that happens, it's all but useless. All it's doing is 
> sifting out dead keys - it is migrating all the keys on current pgp 
> keyservers. 

Weeding out dead keys is really, really useful.  I often have to guess
from 2-3 keys on the keyservers which is the right one to send to for
a given email address (I usually just pick the most recent, but there
is no guarantee that is right).  With the GD, you know the key is the
right one (for some reasonable value of "know").  It isn't perfect,
but it's better than the current system.

> From the FAQ: Every six months, everyone with an active key is now
> going to receive an email from PGP. Great, thanks. If you don't
> reply, your key will be deleted from the Global Directory.
> 
> Somehow, I see a lot of active keys being wrongly marked as dead
> simply because of the email process.

Could be.  You have 2 weeks to answer the mail probe.  If you don't,
your key is purged.  Big deal - just send it in again.  Submitting a
key fresh, and reconfirming a key really amount to the same thing.

The GD is supposed to be a list of active keys.  If a key ages off,
well, it wasn't really that active ;)

> Does it deal with subkeys?

Yes, as many as you like.

> Does it deal with photos?

Yes.  I haven't tried it with multiple photos, but I expect it works.
It certainly works with single photos.

> It would take a lot more before I'd trust any signatures made by the
> PGP keyserver key.
> 
> There are some of these automated signing keys around already and I
> never trust them. Without verification of the physical person behind
> the key, what is the point?

[..]

> I've got no problem with the removal of dead keys from keyservers,
> but what bothers me is WHY they choose to sign the key rather than
> simply delete ones that can't be verified. When the signature is
> untrustworthy, why sign at all?

This is a very good point, and I don't think the PGP folks have made
this nearly clear enough in their documentation.

The fact is, the GD is serving two functions: one, a keyserver that
weeds out bad email addresses, and two, a (weak) CA, based on the same
idea.  These two functions are related, but not identical.

If you want to use it purely as a keyserver, you can do that - just
treat it like any other keyserver.  You will continue to use the web
of trust to validate keys, and nothing has really changed for you
except that it's a little easier to get keys.

If you want to go further, you can get and locally sign the GD key and
give it as much trust as you care to.  This lets you automatically
trust any key that comes from the GD.  For some people, the GD
mailback verification is sufficient (set trust to "full").  For some
people it is a hint, but not complete (set trust to "moderate").  For
some people it is completely useless (don't set any trust at all).
It's important to note that this part of the system is strictly
opt-in.  If you do nothing, nothing happens.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 251 bytes
Desc: not available
Url : /pipermail/attachments/20041212/dbae9293/attachment-0001.bin


More information about the Gnupg-users mailing list