In order to design a successor to v4 key packet format, it is important to
first identify its shortcomings. Here's a list of my problems with it:
1. No cryptographic binding between the encrypted private key material and
the public key material.
This results in a serious security issue, by allowing an attacker to replace
the public material thus compromising the private material with the first
use in the signature. There are various stop-gap measures to deal with this
attack, but the only sure protetction would be some MDC binding together the
private and the public key material.
2. No explicit count of MPIs constituting the key material (both public and
private).
This information can only be inferred from the algorithm specifier, meaning
that any implementation that wants to perform key management must have some
rudimentary knowledge about all public key algorithms. This, in turn,
hampers forward-compatibility.
3. Key fingerprint depends on data unrelated to the actual key (namely:
creation date).
This prevents solutions when signature keys are generated on the fly (e.g.
directly from a passphrase), as the key creation (or, in this case, key
registration) date is not available at the time of signing, thus making it
impossible to put am unambiguous reference to the public key into the
signature.
4. More generally, creation time does not belong to the key packet.
Because it is just an attribute of the key as any other, thus belonging to
certificatiton signature sub-packets, rather than the key packet.
--
Daniel