On Wed, Sep 21, 2005 at 01:53:39AM +0200, Daniel A. Nagy wrote:
Doing otherwise would be an absurd thing to do - the signing
equivalent of putting the main key ID into a PKESK packet when
encrypting to a subkey. If you can point to a single implementation
that does this wrong, I'll immediately concede the point.
Of course, I can't. This is why I am saying that SKS has an important
interoperability problem. It EXPECTS the wrong behavior, while nobody
actually does it.
While it is true that SKS doesn't do long keyid searches for subkeys,
and I agree this is suboptimal behavior, understand that this is not
connected to what clients put in the issuer key ID subpacket. There
has never been a client that put anything other than the signing key
ID in the subpacket, and the SKS behavior is not based on some
misreading of that point in the draft.
Even if SKS started supporting long subkey ID searches tomorrow, it
would not resolve this problem, as GnuPG doesn't provide long key IDs
when speaking to any HKP-ish keyserver because there are still old PKS
servers out that that just won't die. I believe PGP does the same
thing. If you want long key ID searches, you need to use LDAP.
Note that even those PKS servers that don't blow up completely on long
key ID searches don't really do them either: they just pretend to, and
ignore the upper 32 bits - try searching for 0x99242560 and
0x1111111199242560. PKS doesn't do subkey searches at all.
I'm all for getting these problems fixed, but we stand a better chance
of doing by working the actual problem. By all means, add some
clarifying text to the text for the issuer key ID subpacket, but
understand that won't change the keyserver situation. It's just two
different problems.
David