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