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

(Ryan is correct that neither CryptoAPI nor CNG supports expiration as a native property of keys. To the extent that it is supported in the Windows crypto stack, it is supported as a certificate property and its usage is determined by the type of key.)

There are multiple problems IMO with applying implementation semantics to keys. Firstly, as pointed out, a key may have different validity periods for different purposes. For instance, I may have two certificates for the same key - one granted by issuer1 for purpose1 and having expiration1, and the other granted by issuer2 for purpose2 having expiration2. So the validity of the key depends on the context in which I am performing the operation.

The bigger problem is that "key expiration" is not a single concept, but a set of behaviors that are linked to application semantics. Those semantics are in turn determined by the desired security goals.

In PKI, the central concern is linking of public keys to principals, so key expiration is always the concern of the party using the public key. So for signature keys, expiration is a relying-party problem. In other words, a signer who possesses a private key may technically sign with it at any time, it's just that a relying party won't accept the signature after a certain time. In fact, in the absence of timestamps, the relying party may not accept a signature after the expiration time even if the signature itself was performed within the validity period. And of course the public key would need to be usable for verification even after the key expires. Similarly, for encryption keys, it is the encryptor (a.k.a. sender) who cares about expiration. The receiver generally does not care, and in fact expects to be able to use the private key at any time to decrypt received messages.

On the other hand, many systems use expiration as a method of reducing key exposure. So in various financial applications, you may have limits such as only allowing a key to generate a certain number of signatures, or only allowing a key to authorize a certain total dollar amount of transactions. So in these cases, it would be the signer who cares about enforcing expiration, and the verifier may not care at all. 

Given how closely linked expiration is to application semantics, I fear that building any implementation semantics into such a low-level API will only serve to limit the API's applicability. Instead I believe we should leave it up to the application.

-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org] 
Sent: Wednesday, August 8, 2012 11:29 AM
To: David Dahl
Cc: Ryan Sleevi; Vijay Bharadwaj; Web Cryptography Working Group
Subject: 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 Tuesday, 14 August 2012 16:32:40 UTC