Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
Thus we already "salt" the fingerprints with version numbers and a timestamp
and get different fingerprints for these 3 protocols and most likely for all
protocols even for the same key material. For a v5 key the fingerprint will
also be different due to a.3b).
... which is a major pain because the value used to ID the key changes with
any tiny change in the metadata surrounding it, so you can no longer identify
the key that was used to sign something. The timestamp is the real killer,
since non-PGP key formats don't record this and there's no explicit storage of
the keyID (it's implicitly calculated from data that isn't available in non-
PGP storage), you can no longer track down which key did what. I've got
around it by always recording a creation time of zero for keys (so you just
hash four bytes of zeroes), but this only works for keys created in my code
that knows about this convention.
The whole PGP key format as it currently stands is rather a mess. There's no
single entry for a key but a connected series of packets of arbitrary number
where you have to perform arbitrary amounts of lookahead to see where they
end, then a second pass to parse the packets, and then more iterative passes
to resolve all the bits and pieces in the packets. Since the keyID is
generated implicitly from the packets, you have to do this each time you
search a keyring. There are all sorts of attributes, often only vaguely
defined, that can be attached at any point where a signature can be found. The
descriptions contain gems like:
This is a flag in a User ID's self-signature that states whether this User
ID is the main User ID for this key [...] If more than one User ID in a key
is marked as primary, the implementation may resolve the ambiguity in any
way it sees fit, [...]
I have no idea what would happen if you created entries like ones with
multiple subkeys or conflicting attributes in different locations, but I'd
imagine the behaviour of implementations would be pretty much a coin-toss, and
the spec doesn't help. I've got around this in my code by assuming a
canonical "one main key, one subkey, some userIDs", with anything outside this
ignored. This leads to predictable, deterministic behaviour and (hopefully) a
lack of surprises, like the one I'm currently dealing with where a particular
implementation wants to see a certain arrangement of packets and attributes
and I'm still not sure what they are.
If the keyring format is redefined for the PGPng, I'd really like to see the
format be made more usable, something like (for each entry):
header (type + length )
{
ID information (explicitly stored, not implicitly generated);
primary key;
[ optional subkey ];
user IDs;
certifications (signatures);
}
To find a key:
foreach entry
{
read length;
check IDs for a match;
if( match )
break;
skip length bytes;
}
With the IDs explicitly stored, you no longer need some complex hash-based
value to identify the key, you can use any probabilistically-unique value.
Peter.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp