RE: ACTION-22: Key export

1) What do you imagine the "Format" to contain? Something like "ASN.1" vs "JOSE"? Some registered mime type? Something else entirely?

I intended something that specifically identifies the data type and not just its encoding. The easiest thing would be to reuse identifiers of existing ASN.1 types. For instance "pkcs-8.PrivateKeyInfo". For symmetric keys it would be useful to have a null format which contains the clear key bytes.

2) With key wrapping, you're only taking a key - so what algorithm is being used for key wrap? It would seem that for key wrap/unwrap, a full AlgorithmIdentifier specification would be needed here.

I was imagining that being specified by the format, as above.

3) The asymmetry of the API seems rather unfortunate (crypto.importKey, key.exportKey). I'm wondering whether it makes more sense to have them both on the crypto interface. This would mean key.exportKey takes a key as an input parameter, but has the advantage of symmetry with the other 'primitive' operations (en/decrypt, sign/verify). What are your thoughts on this?

You mean crypto.exportKey takes a key as an input parameter?

I'm not opposed to this either. I did wonder about the asymmetry myself. I knew I didn't want to do key.importKey because I didn't want to create yet another key state, but the only reason to reject crypto.exportKey was the clunkiness of an extra argument. In some cases, your version may actually be better (e.g. if you're exporting an AES key you don't need to expand it so creating a key object for it may be overkill).

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, August 13, 2012 3:11 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: Re: ACTION-22: Key export

On Mon, Aug 13, 2012 at 7:54 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> 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
>
> -          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.
>
>
>
> 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.

Hi Vijay,

Thanks for writing this up. A few questions:

1) What do you imagine the "Format" to contain? Something like "ASN.1"
vs "JOSE"? Some registered mime type? Something else entirely?

2) With key wrapping, you're only taking a key - so what algorithm is being used for key wrap? It would seem that for key wrap/unwrap, a full AlgorithmIdentifier specification would be needed here.

3) The asymmetry of the API seems rather unfortunate (crypto.importKey, key.exportKey). I'm wondering whether it makes more sense to have them both on the crypto interface. This would mean key.exportKey takes a key as an input parameter, but has the advantage of symmetry with the other 'primitive' operations (en/decrypt, sign/verify). What are your thoughts on this?

Received on Tuesday, 14 August 2012 16:39:27 UTC