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

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

From: David Dahl <ddahl@mozilla.com>
Date: Wed, 8 Aug 2012 08:46:05 -0700 (PDT)
To: Ryan Sleevi <sleevi@google.com>
Cc: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
Message-ID: <588203585.2875498.1344440765478.JavaMail.root@mozilla.com>
----- 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.

cheers,

David  

> 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 Wednesday, 8 August 2012 15:46:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 August 2012 15:46:37 GMT