Keyservers mangle with subkey binding sigs

[Simon Josefsson]

"Vlad \"SATtva\" Miller" <sattva at pgpru.com> writes:

> While I understand that this place isn't the best for PKS bug reports,
> I'm still not sure of what's happening (except it's quite weird). My key
> 0x8443620A consists of a main certification key and two subkeys: one for
> encryption and one for signing.
>
> Both subkeys have expired in the end of the last year, but I've chosen
> not to generate new and to simply extend life of existing subkeys for
> another few years, so I've re-signed them with extended expiration date
> and updated to keyservers. A few days later one of my correspondents
> contacted me saying that my key is expired and unusable. I've looked at
> keyservers, and was very surprised that they're not reflecting the
> changes made!
>
> Here for example (in the bottom) you may see two subkeys with binding
> signatures expired at 2007-12-31:
> http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex
>
> But if you look at the original copy you'll see that all regenerated
> sigs are in place:
> http://www.vladmiller.info/contacts/openpgp.txt
>
> sattva at localhost ~ $ cat openpgp.txt | gpg --list-packets
> [snip]
> :signature packet: algo 1, keyid FAEB26F78443620A
>         version 4, created 1199529401, md5len 0, sigclass 0x18
>         digest algo 2, begin of digest 1f 06
>         hashed subpkt 26 len 45 (policy:
>         http://www.vladmiller.info/services/cert.html)
>         hashed subpkt 27 len 1 (key flags: 0C)
>   >>>>  hashed subpkt 2 len 4 (sig created 2008-01-05)       <<<<
>   >>>>  hashed subpkt 9 len 4 (key expires after 3y11d13h6m) <<<<
>         subpkt 16 len 8 (issuer key ID FAEB26F78443620A)
>         data: [4095 bits]
>
> If I understand this correctly and not missing something terribly here,
> keyservers just looked at newly uploaded key, thought "huh? I already
> have that subkey in place, and this 0x18 sig too!", and discarded it
> without going into much trouble of analyzing any binding sigs'
> timestamps (maybe marking them as duplicates).
>
> Could anyone confirm this behavior?

I had similar problems with many key servers, until I switched to
subkeys.pgp.net which is (if I understand correctly) documented to only
point to key servers with full subkey support.

/Simon