Using the "clean" function (and the "PGP Global Directory")

[David Shaw]

On Jun 22, 2010, at 11:02 PM, Dan Mahoney, System Admin wrote:

> It seems there's two interesting problems which inter-relate.
> 
> The first is PGP corporation's "global directory", which seems to operate orthogonally from every other keyserver I've seen.  It's HTTP-only, not queryable by any of the open-source clients (in fact, it doesn't support wildcard searches at all, and returns a captcha before delivering results), and not SUBMITTABLE to from any of the open source clients.

Not exactly.  The GD speaks LDAP, so you can set your keyserver to ldap://keyserver.pgp.com and you can query and submit, etc.

> It's also the ONLY keyserver I've seen that supports photo IDs, and actually uses the web interface to show you the person.

The SKS servers (i.e. pretty much everything that isn't the GD) do support photo IDs, but they do not use the web interface to show you the photo.

> Finally, it will sign your non-photo-uids.  With a very short signature time, and pollute them so they look like this:
> 
> uid                  Dan Mahoney <dmahoney at isc.org>
> sig 3        E919EC51 2008-11-22  Dan Mahoney <dmahoney@>
> sig 3        E8048D08 2009-10-15  Peter Losher <Peter_Losher@>
> sig          68D482E2 2009-08-31  Guy Sisalli <gsisalli@>
> sig          CF9890F8 2009-07-01  Mark Andrews <marka@>
> sig          08F13AD2 2009-10-14  Evan Hunt <each@>
> sig 3        294EC062 2009-06-30  Paul Vlaar <vlaar@>
> sig          2DC6FF82 2009-10-14  Rob Austein <sra@>
> sig          8FA50232 2010-06-13  Emma Smith <esmith@>
> sig       X  CA57AD7C 2009-12-16  PGP Global Directory Verification Key
> sig       X  CA57AD7C 2009-12-29  PGP Global Directory Verification Key
> sig       X  CA57AD7C 2010-01-12  PGP Global Directory Verification Key
> sig       X  CA57AD7C 2010-01-25  PGP Global Directory Verification Key
> sig       X  CA57AD7C 2010-02-07  PGP Global Directory Verification Key
> sig       X  CA57AD7C 2010-02-20  PGP Global Directory Verification Key
> sig          B38DB1BE 2010-06-13  Francisco Obispo (ISC) <fobispo@>
> uid                  Dan Mahoney <dan_mahoney at isc.org>
> 
> Yes, I'm sure I need a signature added to my key EVERY TWO WEEKS.  From the same ENTITY.
> 
> So, to correct this, gpg has the "clean" function, except that it seems to be broken.  I can then re-upload my key.
> 
> "clean" kills off any local signature and uid that is expired, but it also removes keys I have no trust value for.   This might make sense on someone ELSE'S key in my homedir.  But I want EVERY nonexpired signature to stay on my public key, even if I don't have an explicit trust value for the person.

Are you sure about that?  "clean" strips off useless signatures (useless being defined as an invalid signature, a superseded signature, a revoked signature, and a signature from a key that isn't present on the keyring).  Signatures from keys that are present, but have no trust value are not stripped off.

> A workaround is to assign some trust value to every other person who's signed my key, then run --clean, but this seems broken.
> 
> So, all that said, two questions.
> 
> 1) Is there some option I'm missing that will just remove expired signatures, and not other things?  Assume I'm still interested in the social networking aspect of who-knows-who and who-trusts-who, but not interested in this automated "I figured out a web url three years ago" noise.

Hard to answer since you seem to be reporting behavior (signatures from keys that have no trust value being stripped off) that is not in accordance with what I'm seeing.  What version of GPG are you seeing it on?  Can you demonstrate the problem?

> 2) If I find the magic way to do #1, and upload it to a keyserver, will they accept it, or will they just re-merge the expired sigs in?  (For most common keyservers).

SKS servers will re-merge.  The GD won't re-merge, but will take the new key whole.

David