Re: Key wrap/unwrap/import/export open issue

On 07/08/2013 08:18 PM, Ryan Sleevi wrote:
> 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.
Will the browser vendors, in their initial implementation, store 
non-extractable keys in LocalStorage or IndexedDB?

Do they plan to offer some better "security boundary" around 
extractability?

I am assuming a "trust the JS" approach, but I'd like to clarify what 
non-extractable means in terms of current browser storage. I.e. 
obviously it means we shouldn't let exportKey() work, but also I imagine 
that it's intuitive that a developer would expect there should be no 
other way via localStorage/IndexedDB to get at the underlying key material.

Otherwise, we need to clarify that setting extractable=false may have 
not offer what we appear it to be offered in this note.

*Implementation Note:* When performing the structured clone algorithm 
for a |Key| object, it is important that the underlying cryptographic 
key material not be exposed to a JavaScript implementation. Such a 
situation may arise if an implementation fails to implement the 
structured clone algorithm correctly, such as by allowing a |Key| object 
to be serialized as part of a structured clone implementation, but then 
deserializing it as a |DOMString|, rather than as a |Key| object.


If developers can't tell what "extractable" means, then we should warn 
them :)

    cheers,
    harry