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

On Mon, Jul 8, 2013 at 11:40 AM, Harry Halpin <hhalpin@w3.org> wrote:

>  On 07/08/2013 08:18 PM, Ryan Sleevi wrote:
>
> On Mon, Jul 8, 2013 at 11:16 AM, Harry Halpin <hhalpin@w3.org> <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.
>

It's obvious, but it should also be specified. Whether and what storage
mechanisms a browser supports should be irrelevant. The spec says that the
extractable attribute determines "Whether or not the raw keying material
may be exported by the application.", and it's obvious here that "exported"
means any means for the application to obtain the raw keying material (if
it just meant whether the exportKey operation could be used, then the whole
attribute would be pointless). I think we have all understood it that way
from the outset and this is supported by the note below and many other
discussions.

...Mark


> 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
>
>