- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 16 Jul 2012 18:37:06 +0000
- To: Eric Rescorla <ekr@rtfm.com>
- CC: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, Ryan Sleevi <sleevi@google.com>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, "Wan-Teh Chang" <wtc@google.com>, David Dahl <ddahl@mozilla.com>, Zooko Wilcox-OHearn <zooko@leastauthority.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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 ? …Mark > > Note that we might also have an API which said something like "make the > key secure if you can"... > > -Ekr > >
Received on Monday, 16 July 2012 18:37:35 UTC