At 4:12 PM -0400 8/30/99, John S. Bucy wrote:
It would make my code substantially simpler if I could have a "signer's
key fingerprint" instead. And as the spec stands, I have to define my own
subpacket type for it. Since the ID can be directly derived from the
fingerprint and they both have distinct, fixed lengths, it seems to me
like you could unambiguously use either one or the other in the same
subpacket without any other indication of which it was; if the length is 8
bytes, its the ID, if its 20 bytes, its the fingerprint. Any thoughts?
You're perceptive, and in my opinion right. I agree with you 100%.
However, the reason the key ID is used is to be compatible with previous
implementations. PGP 2 used eight-byte key ids as a handle to look up the
proper key not only for signatures, but for encrypted data.
When we started OpenPGP, a number of us, myself included, wanted to take
the opportunity to clean up a number of things, like existence of key IDs.
I think that every place a key id is used, it should be a fingerprint
But. We have to be compatible with existing versions of PGP out there. So
we use key IDs, even though they have all the flaws you mentioned. That's
the only reason: we do it that way because that's the way we've always done