- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 8 Jul 2013 11:18:26 -0700
- To: Harry Halpin <hhalpin@w3.org>
- Cc: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Jul 8, 2013 at 11:16 AM, Harry Halpin <hhalpin@w3.org> wrote: > On 07/08/2013 06:31 PM, GALINDO Virginie wrote: > > Thanks Mark for this proposal, which makes your request crystal clear. > > We will allocate some time during the next call in 2 weeks, to collect > feedbacks from editors and have your proposal integrated in the next public > working draft, as it was supposed to. > > > I missed the last call and it appears there were lots of discussion over the > security boundary actually being offered by > > I can imagine a case where no real security boundary that JS code makes > sense (i.e. private key material stored in say, localStorage, and can be > easily exported in some fashion), but if a real security boundary is offered > to non-extractable keys, then it seems doing wrap/unwrap in JS doesn't seem > to make sense. > > This seems like, as many people will try to store private key material as > non-extractable, something we should clarify with an informative note > somewhere in the spec. > > Are the various browser vendors planning on doing anything around security > boundary for keys of structured clone (while maintaining > persistence/lifespan/etc.) at all to enforce non-extractable properties for > keys? I'm sorry Harry, I do not understand your question.
Received on Monday, 8 July 2013 18:18:53 UTC