W3C home > Mailing lists > Public > public-webcrypto@w3.org > February 2013

Re: ISSUE-30: Key import/export?

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 25 Feb 2013 12:52:08 -0800
Message-ID: <CACvaWvZX4U8Z9ejes9pT7B0E6siCsKELqBtFO3Rbsxc4MkDAmA@mail.gmail.com>
To: Harry Halpin <hhalpin@w3.org>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Feb 25, 2013 at 12:44 PM, Harry Halpin <hhalpin@w3.org> wrote:
> Now, if we don't have key import/export, it seems to me it seems we're
> limiting ourselves to ephemeral keys generated in the JS by the same origin.
> Since we have no multi-origin policies and same-origin is the de-facto way
> to do this, I'm happy with that.
>
>  In the spec now, there is just a place-holder:
>
> "
> 15.2.8. The importKey method
>
> 15.2.9. The exportKey method"
>
>  Nonetheless, I think a key import/export function might be useful.
> High-level libraries like Keyczar do key import/export, see their Encrypter
> method [1]. Could we do something similar and just lean on the File API to
> do the reading of keys [2], with a check to make sure the file is a valid
> bytestream or serialized JOSE key. That would also cause a dependency on the
> File API. Arun, when is the File API supposed to go to Rec?

I do not think it at all necessary to depend on the File API.

The issue with Import/Export, as raised on previous calls, was the
interaction between the key formats (ASN.1, JOSE, etc) and
supplementary parameters. In an earlier proposal, Netflix raised a use
case where they wanted wrapped keys which could then provide arbitrary
parameters, with a proposal of extending the JWK format to provide
associative name/value pairs. This has been retracted in the Named
Keys proposal, and support for arbitrary key parameters is no longer a
primary issue with format.

I don't know of anyone who has proposed removing import/export
support. There is simply the question about the exact semantics and
formats.

Requiring a JWK format is useful for some cases, but EXTREMELY
developer hostile for others. Likewise, requiring ASN.1 is useful for
some cases, but EXTREMELY developer hostile for others.

If your concern is the lack of normative text, that's because the
normative text was not written while we still worked out the issues in
the IDL:

  KeyOperation importKey(KeyFormat format,
                         ArrayBufferView keyData,
                         AlgorithmIdentifier? algorithm,
                         bool extractable = false,
                         KeyUsage[] keyUsages = []);
  KeyOperation exportKey(KeyFormat format, Key key);

>
> The hard issue is how this interfaces with same-origin and privacy. Two
> thoughts:

I don't know why you say that. These are not issues that have been
raised in any discussion of import or export. Perhaps you
misunderstand?

>
> Re privacy, I think we should say that if the key-material is a private key,
> moving it into structured clone localStorage/indexedDB should require a user
> prompt, and leave it to the implementer to define the security/privacy
> message to be stated.

I disagree. There should be no need for any prompt.

>
> Re same-origin, we could state that if the key is imported by explicit user
> selection (i.e. see privacy), then the key is treated as if it were
> generated by same-origin of the JS that called the File API to import the
> key. In export, we don't worry about it. Thus we don't have to deal with
> same origins. Thus we can still close ISSUE-19/ISSUE-26.

I don't know why you see there being any requirement for user
selection. These are key bytes being imported. There is no magical UI
involved.

>
> Before writing a WebIDL, I wanted a sanity-check on the thinking.

The Web IDL is already written. See
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#subtlecrypto-interface

It's been written since the FPWD - see
http://www.w3.org/TR/WebCryptoAPI/#crypto-interface

>
>    cheers,
>    harry
>
> [1]http://www.keyczar.org/javadocs/index.html?org/keyczar/Encrypter.html
> [2]http://www.w3.org/TR/FileAPI/
>
>
>
>
>
>
>
Received on Monday, 25 February 2013 20:52:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 25 February 2013 20:52:37 GMT