On Wed, 7 Oct 2015 16:02, pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
said:
X.509 handles this by having two distinct things, a unique identifier
(subjectKeyIdentifier) to identify a key, and a fingerprint (hash of the cert)
Which is not defined by any standard.
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
As you surely know PGP can't add the user ID because the user id is
attached to the key so that you can add or remove user ids.
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.
It will only take a few days until the first wags create multiple
different keys with the same identifier to confuse software. Think of
the collisions in 64 bit key ids which will sooner or later lead to
problems in current OpenPGP.
Let's call your proposed system UnDER.509.
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.
I call this corrupt data. The self-signature would not verify and thus
the key is unusable. Time to remember where you stored the backup.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp