On Tue, Sep 20, 2005 at 09:10:53PM -0400, David Shaw wrote:
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.
Oh, there seems to be a misunderstanding between us, for which I should
probably apologize. I never for a moment suggested that SKS's bad behavior
was the result of the wording in RFC2440, though reading back, it might have
indeed come across like I did.
I simply listed interoperability problems that I have encountered that in my
opinion resulted from not anticipating less obvious, yet perfectly
RFC-compliant behavior. In this particular case, I have noted a minor
possible ambiguity in the standard text, which, I repeat, should be obvious
for anyone giving it a little thought. As an implementer myself, I have
resorted to the same workarounds: canonizing public key packets before
uploading to keyserver and using short key IDs.
Also, I totally agree with you that clarification in the standard is not the
way to fix this problem, but listing it as a known interoperability issue in
the mailing list archive or even on some webpage dedicated to
interoperability between OpenPGP applications (is that what Jon aims to do?)
might help in two ways: culprits may eventually fix their bugs, and
meanwhile others might avoid running into them.
For example, if such a list existed when I coded the relevant parts of
ePointPGP, it would have saved me a lot of time. I think, Jon's idea of an
interop grill-off is an excellent opportunity for assembling such a list of
known interoperability issues, before venturing into testing unknown,
suspected ones.
That said, SKS is by far the most standards-compliant HKP-compatible
keyserver that I have seen. Others do horrible things to keys and search
results. Since keyservers are (correctly) considered outside of security
perimeters and should be treated as untrustworthy in any case, they tend to
be the least carefully written and maintained applications in the OpenPGP
world. That's just a fact of life, I guess, that we need to cope with.
And again, apologies in case I have unintentionally offended someone.
--
Daniel