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

The answer to this has *always* been "yes"

This is entirely orthogonal to any other question. You stick a Key
into IDB. You can only get a Key out. The browser implementation, by
definition of Structured Clone, will *never* expose the raw key bytes.

Does that address the crux of yoru concern?

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

That's already true, by definition.

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

That's entirely unnecessary.

It's like adding an implementation note "An implementation that fails
to properly implement the extractable attribute will allow keys to be
extractable". It's a tautology. Of course anything that fails to
incorporate any part of the spec - or its normative references - will
have bugs. But that's not a spec issue.

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

Received on Monday, 8 July 2013 18:52:11 UTC