On Fri, Sep 23, 2005 at 11:35:42AM +0100, Ben Laurie wrote:
David Shaw wrote:
On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote:
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.
This is a good point, I'll have to think about it. I'm still not
sure that covering this material with key fingerprints and keyids is
the right thing to do. What would the security threats be from being
able to bring a key back to life with the same fingerprint and keyid,
but without any signatures on it being valid?
My original idea with subpackets was that they would be part of the
fingerprint, and changing a subpacket was akin to making a whole new
key as the fingerprint and key ID (though not the key material) would
change. I see some advantages of what you are discussing. It would
(somewhat) allow someone to violate a hard expiration date on their
key: make the key, get signatures, and then when the key expires, just
remake the key. Essentially you can buy an extension on your "hard"
expiration time at the cost of losing all of your signatures.
The thing is, I can't really decide if that is a threat or a
feature...
You can already do this by signing the new version of the key with the
old version of the key - same keypair, so messages to either will work,
and signatures made by either key will still check - but different IDs
and signatures on the keys.
Absolutely, but from the trust perspective (at least using the web of
trust), this second key is one further "hop" away from the one that
was signed. It becomes the same situation as if someone generated a
brand new key without doing any trickery by keeping the same key
material and just signed it with the old one; the fact that the key
material is the same is interesting, but not really useful in practice
since the (changed) key ID is used to locate it in a keyring when
verifying a signature or handling a PKESK.
David