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

On Mar 4, 2013, at 9:40 AM, Harry Halpin wrote:

> On 03/04/2013 06:32 PM, Mark Watson wrote:
>> On Mar 4, 2013, at 5:49 AM, Harry Halpin wrote:
>> 
>>> On 02/25/2013 09:52 PM, Ryan Sleevi wrote:
>>>> 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.
>>> 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.
>>> Agreed.
>>> 
>>>> 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."
>> I'm not sure I understand the problem here. Import/export deal with moving keys between the JS application and Key objects. Key objects are ephemeral, in the sense that they no longer exist when the browser is closed. They're available only to the script which created them (and other scripts it can pass JS objects to). They can't in themselves be used for tracking unless they are stored somewhere more permanent and the only places they can be so stored are existing web storage mechanisms - with all the existing same-origin and user control protections.
>> 
>> Likewise, if a script exports a Key, it just means the script now has access to the actual keying material in some form. Again, the script can only communicate and store this in the same way it can any other kind of information.
>> 
>> Furthermore, if there is a privacy issue associated with communicating an exported key somewhere then there is also a privacy issue with simply using that key: one could simply encrypt a string of zero bytes with this key and use the result for tracking. In that case it's not export that needs user authorization but access to the key at all (as may be the case for pre-provisioned keys, for example).
> 
> Again, to clarify - what I mean is key importing/exporting is the import and export of a Key Object outside of the browser and thus beyond the lifetime of a single session and without the obvious same-origin/user control protection.

The export operation only moves the key data from the UA to the script, nowhere else. After that, isn't it covered by the usual restrictions on script communication ? Why is the result of an export any different from the result of performing an encrypt operation on a string of zero bytes ? Or for that matter, any different from generating a random number ?

> 
> That is why I brought up File API, and it seems this is relevant to ISSUE-9 and the scope of the API in general.
>> 
>> …Mark
>> 
>> 
>>> Leaning on how File API solved this could help.
>>> 
>>>   cheers,
>>>    harry
>>> 
>>>>> 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, 4 March 2013 17:55:00 UTC