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

On Mon, Jul 8, 2013 at 11:55 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Mon, Jul 8, 2013 at 11:51 AM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>> 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.
>
>
> Ryan - I think there's a minor issue with the definition of extractable, in
> that it says the attribute determines whether the key is "exportable". I
> believe the reason we gave called the attribute "extractable" and not
> "exportable" was to avoid the mis-interpretation that it applied only to the
> export operation. As you say, what we mean is that it cannot be extracted
> (normal english meaning) by the application by any means.

Not really. It just matched the PKCS#11 definition, rather than the
CNG definition, in part because the CNG definition is tied to CNG
structures, whereas PKCS#11 is both industry standard and describes
particular formats.

We've used the terms interchangably throughout the discussions, but
'extractability' is very much a common term of art in this space.

Can you explain why you feel the definition is unclear? Do you feel
that the API offers the ability to extract the key without exporting
it?

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

Received on Monday, 8 July 2013 19:03:41 UTC