Re: [openpgp] rfc3880bis - hard expiration time

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp