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

On Mon, Jul 8, 2013 at 12:03 PM, Ryan Sleevi <sleevi@google.com> wrote:

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

In that case, shouldn't the definition say "extractable: Whether or not the
raw keying material may be *extracted* by the application."

No, the API doesn't offer the ability to extract other than using
exportKey, but this should be a blanket requirement on the UA, not just on
the WebCrypto API. That is, if a browser also supported a non-standard
custom method x-exportNonExtractableKey( ... ) or x-setExtractableTrue( Key
key ) then that browser would be non-compliant to the WebCrypto API
requirement.

...Mark


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