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.
>