On Tue, Apr 28, 2015 at 3:01 PM, Derek Atkins <derek(_at_)ihtfp(_dot_)com>
wrote:
Hi,
Nicholas Cole <nicholas(_dot_)cole(_at_)gmail(_dot_)com> writes:
On Mon, Apr 27, 2015 at 4:29 PM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
FWIW: I have no real preference pro or contra a hard expiration time.
I have not seen anyone in favour of a hard expiration time explain
what it is designed to prevent / enable. I think the new standard
should have a real prejudice in favour of excluding anything unless
there is a clear justification. It could be that I've just missed
something, but I don't think that standard has been reached here yet.
You have seen them. You've just ignored them.
It prevents someone who gains access to your private key the ability to
keep your public key going past your pre-selected expiration time.
Using soft expiration doesn't help in this case because the attacker has
access to your private key and could, as a result, issue additional
self-sigs with extended expirations.
No. I haven't ignored them. What you cut out of my email was the
point I made that assuming an attacker is in a position to forge or
coerce an extension of the key expiration time but would not be in a
position to forge or coerce a new key is a very niche model of an
attacker. That was the point I made. Unless you think that scenario
is likely, I am against adding complexity to the new standard, even if
it is small complexity.
Please don't tell me I ignored something I didn't. I completely
understand the *technical* point being made. What I do not understand
is whether the use-case is realistic.
Has there *ever* been a confirmed attack that this feature would have prevented?
N.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp