On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote:
3. Key fingerprint depends on data unrelated to the actual key (namely:
creation date).
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.
Me too.
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).
Careful! If this information is not part of the fingerprint/keyID it can
still be changed by updating the self-signature, no matter whether it's in
thte signature packet or in the key packet.
David's idea with sub-packets should be implemented in such a way that
hashed sub-packets are part of the fingerprint. Maybe, we don't even need
unhashed sub-packets.
If you're importing a foreign key or generating one on the fly, you don't
put subpackets into the key that cannot be determined next time you use the
same source to get the key. A flag in a subpacket indicating where the key
comes from might be useful, though.
--
Daniel