RE: I want to have unsafe key exchange.

Given the web assumption of an untrustworthy execution environment, "make the key secure" isn't possible. Any flag that says "make the key secure" is implicitly adding "... if you can and deign to".

Why not go the other direction - say that key storage is up to the environment/browser, unless the app says specifically that it wants an exportable key, in which case the browser must either generate an exportable key or fail. That would also allow for browsers to implement the maximum security possible under the app's constraints.

(I thought I saw someone else also express this same idea recently, but I can't find the email right now.)

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, July 16, 2012 12:39 PM
To: Mark Watson
Cc: GALINDO Virginie; Ryan Sleevi; Vijay Bharadwaj; Wan-Teh Chang; David Dahl; Zooko Wilcox-OHearn; public-webcrypto@w3.org
Subject: Re: I want to have unsafe key exchange.

On Mon, Jul 16, 2012 at 11:37 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Jul 14, 2012, at 7:13 AM, Eric Rescorla wrote:
>
>> On Sat, Jul 14, 2012 at 6:50 AM, GALINDO Virginie 
>> <Virginie.GALINDO@gemalto.com> wrote:
>>> Vijay, Ryan, and all,
>>>
>>>
>>>
>>> Just to make sure we are on line on this topic :
>>>
>>> About a key to be extractable, Ryan wrote" it is up to the 
>>> implementation and how it handles key", my understanding of our 
>>> conversations was that this 'extractable capability' should be 
>>> defined at key creation. If it is really up to the implementation 
>>> and will vary from one browser to another, then I think we do not 
>>> help the developer to build consistent security : he will not be able to choose if the key could or not be viewed by the JS.
>>>
>>> Did I miss something ?
>>
>> It's important to remember that WebCrypto is likely to be initially 
>> deployed via a polyfill. I.e., there will be pure JS implementations 
>> which sites import to allow operation with browsers which don't 
>> currently support WebCrypto. Under those circumstances, it is 
>> obviously not possible to build an implementation which secures the key from the JS.
>>
>> Such an implementation has two choices:
>>
>> 1. Refuse to make keys which are tagged as protected.
>> 2. Make keys which are tagged as protected but actually aren't 
>> protected.
>
> Surely a site which needed 'protected' keys for some function would not use this "import a JS implementation of WebCrypto" approach and would instead tell the user that their browser didn't support the capabilities needed for that site function ?

You're assuming that they aren't just pulling in a library which wraps the crypto functions as jQuery/underscore, etc. do for so many other pieces of web functionality.

-Ekr

Received on Monday, 16 July 2012 23:44:53 UTC