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.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff