On Fri, 2015-04-24 at 13:11 -0400, Derek Atkins wrote: > >> I.e., IMNSHO I feel you should expire your key by expiring your > >> self-signature on the key. If you want to extend your key then you > >> re-sign it with a new self-signature. > > Well but than it's useless to make the key as a whole expirable. > No, it's not useless. If the expiration time is *not* hard-coded into the FP and other signatures... what does it give you that can't be done with revocation signatures? > If you know that when you generate the key you > absolutely never want it to be usable past a certain date, then you put > the expiry into the Public Key packet. Once that date passes, the key > has expired. The date should be immutable. Maybe I'm wrong, but I don't think there is a field for that. Section 5.5.2 lists only the creation time as part of the public key packet for v4 keys. So to my understanding, with v4 keys (and IIRC v3 is deprecated?) any expiration times are always stored in the signature subpackets. But since these are not part over which the FP or other user's sigs are calculated, they forgeries I've mentioned earlier are possible. > However if you're not sure As I've mentioned before, I don't think we should made an expiration time mandatory - it should be hardcoded, but users should still be able to set it to infinity or 1000 years if they want. > , or you want to prove user liveness on the > key Proving "user liveness" is a) anyway questionable (if the user is dead, who guarantees that noone else has his private key?) and b) much better done by simply resigning the key+UID with a selfsig - but that doesn't mean one cannot hardcode the expiration time. > It doesn't destroy the use case; you can still use the Key Expiry. It's > just an IMMUTABLE setting. Well than please explain this more detailed. AFAIU, when you now change the expiration time on a v4 key+UID, it neither invalidates 3rd user sigs, nor it changes the FP. Have a look at 5.2.4, where it's described how cert sigs are made and AFAIU, these are only done over the UID+key, but not the selfsigs and thus not the key expiration times. > > If that's only in the selfsig *without* invalidating the other > > signatures, then an attacker could try a downgrade attack and e.g. forge > > the selfsig with weaker algos... or more likely... simply create a new > > selfsig when the key was compromised. > > Yes, this is a risk of not using the expiry field in the key packet. I guess you mixed up v3 with v4 keys, the former were still secure with respect to meta attacks on the expiration time. > > If the fingerprint and other users' signatures wouldn't invalidate them, > > all the attacker needs to do is block the revocation (if any). > > I'm not sure I understand this statement. Well I referred to the basic attack vector in this scenario: - If I could create a key/UID with immutable expiration times, then I could e.g. say, all my high security keys are only valid for one year. If the key is compromised after that time, then an attacker could no longer "re-sign" they key with a new expiration time (thereby tricking my peers into trusting it), because it would change the FP and invalidate their sigs. - Right now (with v4 keys) they expiration is to my understanding only set in the self-sigs and changing it doesn't invalidate other user's signatures nor result in another FP. So if my key is compromised now, than even if I set the expiration to one month, the attacker could simply make another selfsig. Further, he could probably block any revocation signatures from the keyservers... and even any "older" self-sigs that contain the expiration (which may otherwise look suspicious to the careful lookin user) > Yes, that's why the key expiry should be immutable. Changing it would > invalidate all signatures on the key, as well as changing the key > fingerprint. I.e., it's a "different key". Well that's what I always say, isn't it? It's just not doable with current key versions. > However the key expiry should not be mandatory (i.e. it can be 0, > meaning "never expired"). Sure, but I never said that we should force the user to actually set a time. Cheers, Chris.
Description: S/MIME cryptographic signature
_______________________________________________ openpgp mailing list openpgp@xxxxxxxx https://www.ietf.org/mailman/listinfo/openpgp