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

I see. So these same use cases are achievable with key attributes and finalization is just a different API construct for achieving the same goal. That seems reasonable.

One thing we might want to think about - what should happen if a user who has thus finalized his RSA encryption key wants to get a new certificate with the same key? Do we believe that this should fail (with the rationale that if a user wanted to do that then they shouldn't have finalized the key)?

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Tuesday, September 4, 2012 3:37 PM
To: Vijay Bharadwaj
Cc: Web Cryptography Working Group
Subject: 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 Friday, 7 September 2012 05:55:56 UTC