ISSUE-9 [was Re: ISSUE-30: Key import/export?]

On 02/25/2013 09:52 PM, Ryan Sleevi wrote:
> On Mon, Feb 25, 2013 at 12:44 PM, Harry Halpin <> 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.

Perhaps then let's point those "empty" parts of the spec at right IDL or 
remove them.

I thought we agreed on ASN.1 and JOSE (assuming things went well with 
JOSE WG). Is this still a problem?

I think the "algorithm naming" issue is orthogonal here.

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

I think that's ISSUE-9. How does the normative text or proposed text 
deal with same-origin as well?
>> 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.

I think this goes back to ISSUE-9.

If the Web Crypto library defines a way to import/export keys to 
locations outside the brower without any user-interaction, that will 
likely have problematic privacy concerns. For example, what would stop a 
user-agent from placing a key somewhere as a unique

Unlike localStorage, the user can't delete those easily from the 
browser, like they can remove their cookies. Thus, we run the risk of 
creating "superkeys" that work like "supercookies".

I'm OK with that as long as the user has some "interaction" ala File API 
in selecting a key for import or having to confirm they are exporting a 
key to some off browser location. Otherwise, the browser could silently 
place keys on user machine and import them at a later date. If 
same-origin isn't specified, they could even do so across multiple origins.

Thus, let's not close ISSUE-9 till we have discussed this and had a 
Privacy Interest Group review. Note this is core to primary features, 
ala "key storage and control beyond the lifetime of a single session. In 
addition, the API should be asynchronous and must prevent or control 
access to secret key material and other sensitive cryptographic values 
and settings."

Leaning on how File API solved this could help.


>> 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
> It's been written since the FPWD - see
>>     cheers,
>>     harry
>> [1]
>> [2]

Received on Monday, 4 March 2013 13:49:52 UTC