On Wed, Sep 21, 2005 at 09:56:38PM +0200, Daniel A. Nagy wrote:
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:
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
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
There have been a number of mentions of the key-with-subpackets idea
recently, so I'll repost the mail where I first proposed the idea. It
has many more details than I mentioned in this thread.
In short though, the subpackets are hashed into the fingerprint and
any certification signatures (including self signatures). In my
proposal there are no unhashed subpackets. In the case of expiration,
we would have two different ways to specify expiration. The
expiration time hashed into the key is a hard expiration time that
cannot be extended. The expiration time in the self-signature is a
soft expiration time that can be extended or changed whenever desired
- but only up to the hard limit given in the key itself.