- From: Eric Rescorla <ekr@rtfm.com>
- Date: Sat, 14 Jul 2012 07:13:16 -0700
- To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Cc: 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 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. Note that we might also have an API which said something like "make the key secure if you can"... -Ekr
Received on Saturday, 14 July 2012 14:14:19 UTC