On Sat, 11 Sep 1999, Jon Callas wrote:
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
instead.
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
it.
Someone else suggested that the problem of computing a key pair that has a
particular key ID is computationally infeasible. I can't really speak to
this either way but it seems to me like 1: the probability of people
independentally randomly generating the same key pair (or keypairs with
identical fingerprints/keyIDs) is quite small and that 2: it would be
completely impractical for almost anyone (three-letter agencies excluded)
to try to exploit a system by systematically causing keyID collisions.
As far as my particular system goes, it seems like I have two options:
1. Don't worry about key ID collisions. Under most circumstances, I
think that this would probably be ok.
2. Use a "signer's key fingerprint" signature subpacket and leave the
keyID packet there and ignore it. Has the working group considered an
extension to OpenPGP to standardize such a thing (i.e. keyID Must
Implement, fingerprint Should implement)? It seems like this would be
preferable to me defining my own subpacket type for my specific system...
later
john
(ps I'm not on the OpenPGP WG mailing list so please cc replies to me)
-------------------------------------------
John Bucy
"My mind is going....I can feeeeeeel it..."
bucy(_at_)gloop(_dot_)org
-------------------------------------------