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

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

From: Ryan Sleevi <sleevi@google.com>
Date: Sun, 5 Aug 2012 21:53:23 -0700
Message-ID: <CACvaWvaWbrTCPBr+zgvJtL6GkOzBn43OE=+JW3_bnL3xkWNKWw@mail.gmail.com>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
Cc: David Dahl <ddahl@mozilla.com>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
On Sun, Aug 5, 2012 at 9:46 PM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org> 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.
>
> 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?
>
>
>

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.

Vijay, you provided the example of a key that can no longer be used
for signing, so I was hoping you could explain a bit more.


While it is "easy" to say that expiration info reflects whatever is in
the associated certificate, it's not a guarantee that there will even
BE an associated certificate (eg: crypto-ISSUE-15, symmetric keys,
ephemeral key pairs). It's also not clear what the validity period
would be if the user has two certificates with either overlapping
times (is it the union of the two validity periods?) or
non-overlapping times (is it the min max? Whichever period is current
for Now? Something else?)

I will note that PKCS#11 (Linux/Mozilla) exposes this information via
CKA_START_DATE and CKA_END_DATE on Key objects, as optional,
non-normative parameters. Similarly, CSSM_KEYHEADER (OS X) defines
startDate and endDate as the effective dates of the keys. I didn't see
anything equivalent in CryptoAPI or CNG (under Key Storage Property
Identifiers), however, so I'm not sure how universal this concept is.
Received on Monday, 6 August 2012 04:53:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 August 2012 04:53:51 GMT