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

On 08/06/2012 06:46 AM, Web Cryptography Working Group Issue Tracker wrote:
> crypto-ISSUE-16: Definition for Key Expiration [Web Cryptography API]
>
> http://www.w3.org/2012/webcrypto/track/issues/16
>
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
>
> During the July Face-to-Face, the topic of Key Expiration was raised. However, a solid definition is lacking for what the semantics should be.
>
> Argument for Implementation Semantics:
> - Expiration could serve as a quota-management technique. Keys may represent expensive resources, particularly in constrained environments. Therefore, an understanding of how long a key is supposed to live may allow a user agent to remove 'expired' keys over time.

My initial preference is to have implementation semantics, as while 
application semantics are in general preferable, I do think that in this 
particular case the chances of abuse are severe and I'm not convinced a 
wide variety of application environments (including OSes) will 
adequately interop enough on this subject. However, keys that don't 
specify expiration could default to application semantics. Any other 
opinions?

>
> Argument for Application Semantics:
> - Expiration should have no specific meaning to the implementation; it is simply provided to the application in an advisory capability to inform the application how a key can/should be used. This is particularly important for implementations that use pre-existing cryptographic APIs, such as OS APIs, as the underlying API may enforce these semantics. An example was given for a keypair where the private key may no longer be able to sign messages after a particular date, but the associated public key may be used to verify existing messages.
>
> Should expiration be handled on a per-application basis in the custom attributes, or is it a global attribute on all Key types that should be managed by the User Agent?
>
>
>

Received on Wednesday, 8 August 2012 03:46:38 UTC