Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
That explicit ID sounds pretty much like a issuer+serialno or one of the
other X.509 methods to identify a key. It is not a fingerprint as we know it
and it can't be used as a secure identification of the key.
It works quite well as a unique identifier for a key. The problem here is
that PGP makes the same mistake that's made in things like credit cards and
SSNs, where you've got a magic value that's supposed to be both a unique
identifier (public) and an authentication/authorisation value (private).
X.509 handles this by having two distinct things, a unique identifier
(subjectKeyIdentifier) to identify a key, and a fingerprint (hash of the cert)
to verify its integrity or whatever it is you want to do with it.
PGP in contrast confuses the two, so you have a supposedly unique identifier
that hashes in a mutable value (the time) but then doesn't hash in other
important information like the user ID associated with the key. So it doesn't
work very well either as an identifier or as an integrity-check value.
The fix would be to have two distinct values, a unique identifier (64 or 128
bits of whatever) to uniquely identify a key, and then a fingerprint that
covers the key, subkey(s), user ID(s), attributes, and whatnot, to check that
you've got what you were expecting to get.
Lost key?
The key is present somewhere on the keyring but the date has changed, so you
can't locate it by key ID any more because the date hashed into the other bits
and pieces changes the key ID.
Peter.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp