Re: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis

On Fri, 2015-04-24 at 13:02 -0700, Jon Callas wrote: 
> I read your explanation. I understand it. I just disagree.
> I think that hard-expiration is not only a bad idea, but unenforceable.
Then please elaborate why, cause I gave some clear usage scenarios where
hard expiration times would be beneficial, and your points below don't
really seem to be good against.


> It's a *good* thing for Alice to be able to update the expiration time
> on her key. It encourages putting a limit on (as opposed to no limit)
> if it can be changed later. It also allows advanced systems to be able
> to do some really cool things with short lived keys.
But for all that I don't think we'd need to have a mutable expiration
time.
Just make they non-expiring at first, and release a revocation
certificate once the point has been reached, when it should really be
stopped from using.
Theoretically one could even make the revocation signatures themselves
expiring again, so that the revocation would only last for so and so
long (which is however really just hypothetically, and nothing that
should ever be done ;) ).


Further, my proposal of allowing for an immutable expiration time
doesn't mean that we have to drop the mutable on.
Just define it like this:
- if the expiration time in the key block itself is set to non-zero,
than this time is the expiation time and any other key expirations on
self signature MUST be ignored
- if the expiration time in the key block itself is set to zero, then
the key doesn't expire, but selfsigs may.

So you still could revoke single selfsigs and you could also resign your
key with new selfsigs, thereby getting the same behaviour as of now - a
mutable "key expiration time".


But the key expiration time signature subpacket should really go away,
it doesn't do what it's name promises, and it's effect could/should
rather be done with the expiration time of the selfsigs.


> And you probably can't prevent it anyway. X.509 syntax people have
> kittens if you reuse a key in certs. And yet a major feature of many
> PKI systems is to "reissue" a cert with a new expiration time, because
> it makes operations much easier for everyone.
I don't see why it shouldn't be possible.
Just put it back into the key block, then the FP will include it and the
cert sigs from other users as well.
Of course you can still use the raw key material and create a new key
with another expiration time and the same UIDs of it,... but that will
be a new and totally different key.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

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