Let me give my responses to Daniel's points about V4 key packets.
First I want to mention that Ian seemed to take a much larger view and
wanted to redesign the whole of the OpenPGP format. V4 to V5 key packets
is only one small part of the spec. No one is proposing to redo OpenPGP
from scratch here.
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.
This is a very good point, and it is a little different from the previous
attacks. If we had thought of it, we would have tried to fix it when
we added the checksum over the private key material.
The previous attack involved modifying some private key material and
causing the signature algorithm to fail. In RSA keys, if you hack
just one of p or q and get it to do the signature using the Chinese
Remainder Theorem (CRT), the resulting value can leak the other of p or
q and therefore leak your private key. To defend against this we added
a SHA-1 hash over the private material as a checksum.
Daniel proposes an extension to the attack where the private key
material is left alone and the public material (in the private key
packet) is modified. I don't think this would do anything on RSA
keys, as the CRT based signature algorithm does not use the public
modulus or exponent. However it would be effective against DSA keys.
The attacker could change p and q to be much smaller values, such that
discrete logs were feasible, then request a DSA signature using these
values, solve the discrete log and reveal x (the private value) mod q.
Do this a few times with different q's would reveal x.
Had we thought about this, we could easily have had the SHA-1 hash
cover the public as well as the private key material, but we didn't,
unfortunately. Putting some size-based sanity checks in the DSA signature
code might be a good idea though.
I don't know if there are other variations on the attack that could also
be addressed for now with sanity checks.
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.
I am inclined to agree with David that there is not much point to being
able to parse a packet's details when we can't do anything useful with it.
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.
Yes, this has hurt our PGP implementation when dealing with foreign keys
such as X.509 certificates. If we want to import a raw modulus+exponent
pair as a PGP key, and we want to know if we already have one on the
keyring, we can't easily compute a fingerprint and look for a match,
because creation date affects fingerprints. I agree that fingerprints
should just be over the formatted key material.
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.
I like David's idea better to have some sub-packets in the V5 key.
I would like to see immutable material put there. One thing that bothers
me in the current V4 is that the key's expiration date can be changed by
updating the self-signature. Suppose your key has expired and you don't
use it any more. As a result perhaps you don't protect it that well.
If someone gets hold of the private part, they can issue a new self-sig
with a new expiration date and bring this dead key back to life. It would
be better if a dead key would stay dead. Expiration date and creation
date would be better placed in the key packet, IMO (as they were with
V3 keys).
Hal Finney