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

On Tue, Sep 4, 2012 at 2:05 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> 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.

Tainting + Escrow/POP do not play together nicely, as you pointed out,
when dealing with encryption keys (as opposed to signature keys). To
prove possession, one must compute a signature (generally), which then
prevents it from being usable for encryption (or otherwise restricting
usages/algorithms)

With regards to attributes, an implementation "may" wish to mark an
attribute as read-only, but can only do so after getting some
acknowledgement from the server. Example would be to generate a key,
generate a POP, send it to the server, server replies with some
"server-supplied" key ID, then the attribute is added as a read-only
attribute for the key.

An alternative API to the latter case would be to 'seal' attributes
and mark them read-only, but finalization seemed a viable alternative.

>
> -----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 22:37:50 UTC