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

On 08/08/2012 05:46 PM, David Dahl wrote:
> ----- 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.

Precisely, I think having a non-app dependent mechanism in this regard 
would be a big +1 for reliability for many users/developers.
>
> 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 18:28:52 UTC