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

Returning to the subject of the original post, and to start off the
discussion.

Ryan has mentioned two other possibilities for solving this problem, so I'd
like to take a moment to describe my understanding of those.

(1) Implicit unwrap semantics in pre-provisioned keys

A pre-provisioned key with usage unwrap could be imbued with behaviors that
dictate the extractable and usage attributes of keys that it unwraps or
even that imbue the unwrapped keys with other such properties. The former
would be sufficient for "single step" key wrapping, where the final key to
be used for encryption, decryption, signature or signature verification is
wrapped directly with the pre-provisioned key. The special property of the
pre-provisioned key ensures that the final key has extractable = false.

If you want to have two steps, for example the key you are transferring is
encrypted using a temporary Content Encryption Key (as in JWE) and then
this CEK is wrapped using the pre-provisioned key, then you not only need
the pre-provisioned key to force extractable = false and usage = unwrap on
the CEK, but it must also transfer a special property to the CEK, so that
when this in turn is used for unwrapping the resultant key always has
extractable = false.

(2) Explicit attributes on wrapping keys

A key with usage "unwrap" also has properties which dictate the attributes
of keys that it unwraps. Let's call these properties "unwrap-extractable"
and "unwrap-usages". Whenever a key, W, is used to perform an unwrap
operation, the unwrapped key, K, gets it's attributes set as follows:

K.extractable = W.unwrap-extractable
K.usages = W.unwrap-usages

Again, this is sufficient for single-step unwrapping. When the wrapping key
W is generated, the unwrap-extractable and unwrap-usages properties are set
to 'false' and the intended usages of the expected wrapped key,
respectively, When it comes to unwrapping the unwrapped key, K, gets the
appropriate properties.

However, if the intended usage of the key K is also for unwrapping (as in
the two-step key wrapping described above), we need a way to set
K.unwrap-extractable and K.unwrap-usages.

Theoretically, we could go down the path of having unwrap-extractable and
unwrap-usages each be an array, popping the first value on each unwrap
operation, i.e.

K.extractable = W.unwrap-extractable[ 0 ]
K.usages = W.unwrap-usages[ 0 ]
K.unwrap-extractable = W.unwrap-extractable[ 1 : ]
K.unwrap-usages = W.unwrap-usages[ 1 : ]

(using python-like slice notation)

It may not be necessary to explicitly expose these attributes on the Key
object: it may be sufficient to have them settable at key creation time.

The other option is to have the extractable and usage attributes carried
securely with the wrapped key, as I have proposed.

Other options ?

...Mark

On Mon, Jul 8, 2013 at 12:44 PM, Mark Watson <watsonm@netflix.com> wrote:

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