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

----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "Harry Halpin" <hhalpin@w3.org>
> Cc: "David Dahl" <ddahl@mozilla.com>, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>, "Web Cryptography Working
> Group" <public-webcrypto@w3.org>
> Sent: Thursday, August 9, 2012 4:32:30 PM
> Subject: Re: crypto-ISSUE-16: Definition for Key Expiration [Web Cryptography API]

> 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.

Ok, that makes sense, thanks for the clarification.

> 
> 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.
> 

I never intended to have the browser delete the key past it's expiration time. I intended to follow the lead of a server SSL cert, where a warning is issued (or a user is prevented from loading resources) when connecting to the site via https if the cert has expired.

Perhaps we can suggest implementations at least throw an error into the JS console when using an expired key, but still allow usage?

Regards,

David

Received on Thursday, 9 August 2012 21:48:28 UTC