RE: crypto-ISSUE-38: Key initialization and "finalization" [Web Cryptography API]

CNG uses a finalization construct (NCryptFinalizeKey), but not for these reasons. In that API, prior to finalization, the key is in a "pre-created" state, and cannot be used for any operations. The idea is that you create an empty key object with NCryptCreatePersistedKey, then either set parameters for key generation or key import, then finalize the object to make the key available. Those key states are not present in this API.

I'd be interested to know why use cases like the ones below can't be accomplished without a finalize construct - for example by manipulating key attributes only.

-----Original Message-----
From: Web Cryptography Working Group Issue Tracker [mailto:sysbot+tracker@w3.org] 
Sent: Thursday, August 30, 2012 4:50 PM
To: public-webcrypto@w3.org
Subject: crypto-ISSUE-38: Key initialization and "finalization" [Web Cryptography API]

crypto-ISSUE-38: Key initialization and "finalization" [Web Cryptography API]

http://www.w3.org/2012/webcrypto/track/issues/38


Raised by: Ryan Sleevi
On product: Web Cryptography API

It is common in cryptographic APIs that there is a distinct state of Keys that are first being created, to allow them to have attributes mutated or to allow keying material to be exported or escrowed, up until some point where the key is "finalized", and no further changes are supported.

An example use case for such feature would be:
- Generating a new keypair, escrowing the private key using a key escrow pprovider, then marking the generated key as non-exportable. Future attempts to export the key will fail once it has been "finalized".
- Creating a key, then defining one or more attributes after creation (perhaps after first registering the key with an authority), but then "finalizing" the key such that the attributes become read-only.

While I realize that this use case hasn't been brought up yet, the prevalence of such APIs seems that they may affect how key generation/derivation behaves, and thus we should consider whether such use cases should be prohibited - implicitly by choice of API, or explicitly by text.

Received on Tuesday, 4 September 2012 09:06:08 UTC