W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

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

From: Harry Halpin <hhalpin@w3.org>
Date: Wed, 08 Aug 2012 05:46:31 +0200
Message-ID: <5021E117.5070602@w3.org>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
CC: Web Cryptography Working Group Issue Tracker <sysbot+tracker@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC