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

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

> On Mon, Jul 8, 2013 at 12:18 PM, Mark Watson <watsonm@netflix.com> wrote:
> >
> >
> > 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.
> >
>
> While I understand where you're coming from, I don't think I could
> agree to such text.
>
> I agree, we should specify the language to be clear about what the
> requirements are for a UA. But that absolutely does not and cannot
> affect future specs or implementation work from updating or adjusting
> that.
>
> That's not to say it might be ill-advised to do so, but any spec that
> says "Thou shalt never do X" is simply broken. A good spec doesn't say
> what you can't do - it simply provides the necessary and complete
> definition of what you should do. And as specs change, are enhanced,
> or are extended, that definition may change.
>
> I agree it'd be an issue of 'backwards compatibility' to change the
> definition of extractable, but that doesn't mean it can't or shouldn't
> be done.
>
> So no, I cannot support adding a statement like you suggest. But I
> agree we should make it clear what the guarantees are, so any changes
> to that are properly evaluated as to whether or not they're backwards
> compatible.
>

My suggestion was just s/exportable/extractable/ in the definition of the
extractable attribute. The rest of my last response was my interpretation
of what that would mean.

Of course, nothing in any specification constrains future specifications.
It can always be decided to introduce non-backwards-compatible changes in
future.

Can you agree with the one-word change ? If not, what is your
interpretation of what using the work "extractable" here would mean
compared to using the word "exportable" ?

...Mark