RE: ACTION-22: Key export

Mitch> As described during our f2f: we would like to use a KDF on a Diffie-Hellman negotiated shared secret to create a session key (or session keys) where the raw session key is never allowed to be accessed by the webapp.

I agree with the aim, but as discussed earlier I don't know of a way to make this work in general. In general, the output of a KDF is "just bytes" as far as the algorithm is concerned, so it's hard to see a way to pick some bytes from that output and designate them as "special" (i.e. key material). I suppose this case could be made to work if we applied additional restrictions, but that may require a different API that takes in key or secret handles rather than an ArrayBuffer.

Mitch> In terms of expected user interaction in a browser, is there some idea of a key store password, where the user has to enter the password to explicitly export a wrapped key? Or is this a click-through dialog box where the user simply clicks "Ok" and the webapp gains access to the raw key?

I was imagining a situation where this is determined by the key itself. Most exportable keys would be exported with no user interaction at all, and non-exportable keys would just fail. Keys stored on smart cards for example may require UI but that is imposed by the card not the UA.

From: Mitch Zollinger [mailto:mzollinger@netflix.com]<mailto:[mailto:mzollinger@netflix.com]>
Sent: Monday, August 13, 2012 5:52 PM
To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: ACTION-22: Key export

On 8/13/2012 7:54 AM, Vijay Bharadwaj wrote:

We've gone around on this a few times, including at the f2f, so here is a concrete proposal. I'm trying to find a balance between extensibility and not loading up the API with a bunch of stuff, so feedback is welcome.

I see the following use cases for key import/export:

-          Create session key object from derived key bytes (using either KDF or secret agreement): this would require raw key import

I would add:
 - Create session key object from derived key bytes, using KDF of underlying keying material, which does not allow raw key import / export.

As described during our f2f: we would like to use a KDF on a Diffie-Hellman negotiated shared secret to create a session key (or session keys) where the raw session key is never allowed to be accessed by the webapp.



-          Create key object from public key received from peer (for asymmetric encryption or signature verification): this would require public key import, where the public key is likely ASN.1 encoded in many apps

-          Export/import (wrapped) content encryption key for data encryption: this could be just the wrapped key or something like a PKCS#7 RecipientInfo (which is ASN.1 encoded). Import/export requires a handle to the wrapping key.

-          Export/import of private keys for distribution, with formats like PKCS#8.

>From an API perspective, supporting export seems to be straightforward. The Key object needs an export (or wrap) method, which takes a target format and potentially a wrapping key as parameters.

In terms of expected user interaction in a browser, is there some idea of a key store password, where the user has to enter the password to explicitly export a wrapped key? Or is this a click-through dialog box where the user simply clicks "Ok" and the webapp gains access to the raw key?



It seems to me there are two API models to support import. Either have an ability to create an empty Key object, then invoke an import method on that object, or make it part of the construction of the Key object. I propose the latter, so that we don't complicate the state model of the Key object.

So in WebIDL,

interface Crypto {

... other stuff ...

KeyGenerator importKey(DOMString format, ArrayBuffer keyBlob, optional Key wrappingKey=null);
}

interface Key {

... other stuff ...

KeyExporter exportKey(DOMString format, optional Key wrappingKey=null);
}

Where KeyExporter is exactly like KeyGenerator but returns a value instead of a Key object.

One big issue is what key formats should be supported. For symmetric keys it makes sense to support a raw format, but for asymmetric keys things are more complex. As has been brought up on other threads, many commonly-used formats are ASN.1 based and so it seems like supporting that would really help interoperability. However, I'd like to avoid a repeat of the mandatory algorithms discussion. Any ideas here are welcome.