W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

Re: ACTION-22: Key export

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Mon, 13 Aug 2012 17:52:02 -0700
Message-ID: <5029A132.7070007@netflix.com>
To: <public-webcrypto@w3.org>
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 

> 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.
Received on Tuesday, 14 August 2012 00:52:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC