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

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.

Received on Monday, 8 July 2013 19:22:15 UTC