Re: crypto-ISSUE-16: Definition for Key Expiration [Web Cryptography API]

On Wed, Aug 8, 2012 at 11:28 AM, Harry Halpin <hhalpin@w3.org> wrote:
> On 08/08/2012 05:46 PM, David Dahl wrote:
>>
>> ----- Original Message -----
>>>
>>> From: "Ryan Sleevi" <sleevi@google.com>
>>> To: "Web Cryptography Working Group" <public-webcrypto@w3.org>
>>> Cc: "David Dahl" <ddahl@mozilla.com>, "Vijay Bharadwaj"
>>> <Vijay.Bharadwaj@microsoft.com>
>>> Sent: Sunday, August 5, 2012 11:53:23 PM
>>> Subject: Re: crypto-ISSUE-16: Definition for Key Expiration [Web
>>> Cryptography API]
>>>
>>> David, you initially scoped key expiration, so I was hoping you could
>>> explain a bit more of the use case and how you see it working.
>>>
>> (I missed this email as it was filed in a rarely-looked-at email folder of
>> mine for some reason...)
>>
>> I assume it is (of course optionally) good practice to set a time limit on
>> a public key in the same way many users set a time limit on a PGP keypair. I
>> may be wrong about this being a good practice. It seems like an optional
>> restriction some app developers might have. The only use case I have is
>> making keys inoperable after some time period might be a safety mechanism
>> whereby an attacker who has snatched the key material cannot use it.
>
>
> Precisely, I think having a non-app dependent mechanism in this regard would
> be a big +1 for reliability for many users/developers.

I'm not sure I understand.

Key expiration in other systems, including for PGP, is not about
making the key disappear after time X, but about an indication to
relying parties (eg: those relying on signatures/messages using said
key) that the assertions made in the certificate are no longer
guaranteed.

For example, a certificate issued by a CA expires, in part, because
the claims made in the certificate regarding ownership/operation of a
domain name, company, etc cannot be guaranteed as always true. Setting
an expiration forces the customer to have their claims re-verified by
the CA.

Expiration also factors in for general key management, but again,
doesn't mean "This message must self-destruct". NIST key lifetime
recommendations are about how long a key can be assumed to be
un-cracked, given current/expected computation models and power. That
is, how long it would take to factor the key.

It has little-to-nothing to do about whether or not the user is likely
to lose the key within X years. Those issues are addressed by
revocation, not expiration.

The utility for expiration seems to be a way for applications to hint
to an implementation when the key can truly be destroyed/garbage
collected, and is merely a hint, if that. Thus, it seems to make more
sense to have a cookie-like maxAge mechanism, where the key's
expiration can be continually refreshed as it's used.

Even with those semantics, I'm still very concerned applications will
get it wrong and thus be unpleasantly surprised when keys just
'disappear'. A key being deleted by an implementation is,
fundamentally, indistinguishable from an attacker who does not have
access to the key. If an application just assumes that "the key must
have expired," it seems very likely to undermine security, whereas if
an application assumes "this must be an attacker," the user experience
is actively harmed.

Received on Thursday, 9 August 2012 21:32:57 UTC