Currently in V4 keys, the keyid is defined to be the rightmost 64 bits
of the fingerprint. Phil Zimmermann has often complained about this
and expressed the opinion that this was a blunder, and that we should
have chosen the leftmost bits rather than the rightmost bits.
He says that this would facilitate a generalization of the keyid to be
the leftmost N bits of the fingerprint. N could be as long as the entire
fingerprint, to have an essentially unambiguous pointer to a given key.
Or N could be short, just a few bits, to have a nearly-"anonymous"
key, where the set of possible keys was understood by all parties to be
very small.
He also suggests that this would facilitate going to a key server storage
model where a length-N keyid was the index. N could be shorter or longer,
and by using left substrings rather than right, he says that the server
would have an easier time adapting to the variable length indexes.
PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for
the first time. These will use the hash method to derive the fingerprint
and keyid, as with other V4 keys.
Phil proposed to me that we change the keyid calculation for these keys to
use a left substring of the fingerprint rather than the right substring.
More generally, all new key types would use left substrings.
The only keys that used right substrings would be "legacy" DSA and ElGamal
keys (assuming that no one else has implemented RSA V4 keys, which I am
not sure about). We might do some kind of upgrade to DSA keys when the
new larger hash is announced later this year, and they could switch at
that time. Maybe some arbitrary change could be made to ElGamal as well.
I will refrain from giving my own opinion about this idea, its
justification, its timing, and its impact. Input from others is welcome.
Hal