Re: Comments on wrap/unwrap

Sent from my iPhone

On Jun 17, 2013, at 5:35 PM, Hutchinson Michael <
Michael.Hutchinson@gemalto.com> wrote:

Is there not a third option?



Specify the problem away?



Any attempt to create/return a key with KeyUsage of “unwrap” and with
extractable set to true returns an error

Any attempt to create/return a key with KeyUsage of “unwrap” and “decrypt”
returns an error


The problem is that the Key object for the CEK could be returned with just
usage 'decrypt'. There is no way for the WebCrypto implementation to know
whether the thing being unwrapped is a CEK or a payload that is ok to have
usage 'decrypt'.

And then there is the more straightforward problem of the case where you
just wrap a key by encrypting its JWK (no JWE wrapper around that). How do
you ensure the non-extractability of the wrapped key is maintained if there
is no extractable attribute in the JWK ?

We could address the latter by having unwrapped keys have the same
extractability as the key used to unwrap them, but this is a bit arbitrary.
And that would not solve the JWE problem.

...Mark



>Michael

 T

*From:* Mark Watson [mailto:watsonm@netflix.com <watsonm@netflix.com>]
*Sent:* Monday, June 17, 2013 6:24 PM
*To:* Ryan Sleevi
*Cc:* public-webcrypto@w3.org; Vijay Bharadwaj
*Subject:* Re: Comments on wrap/unwrap





On Mon, Jun 17, 2013 at 3:34 PM, Ryan Sleevi <sleevi@google.com> wrote:

On Mon, Jun 17, 2013 at 2:34 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Mon, Jun 17, 2013 at 10:55 AM, Ryan Sleevi <sleevi@google.com> wrote:
>>

<snip>

>>
>> Mark,
>>
>> I fail to see how you reach the conclusion of an attribute-carrying
>> temporary key being necessary, especially given the following examples
>> of other APIs.
>
>
> Ok, I'll state it again. Suppose you have a JWE-wrapped JWK and the
payload
> key is supposed to be non-extractable.
>
> My first step to unwrap the CEK, resulting in a Key object K[CEK]. Then I
> can unwrap the payload using K[CEK]. To maintain the non-extractability of
> the payload key, I need the following to be true:
> (1) K[CEK] does not have usage "decrypt"
> (2) K[CEK] is non-extractable
>
> The reasons for these requirements are, (1) if K[CEK] has usage "decrypt"
I
> can use it to decrypt the payload JWK, exposing the key material to JS and
> (2) if K[CEK] is extractable, I can just export it and re-import it with
> usage "decrypt".
>
> So, how do we ensure (1) and (2). There are only two options:
> (a) something in the CEK format causes the attributes to be set this way.
> For example the CEK actually carries attributes and these are respected
> during the upwrap into K[CEK]
> (b) some special properties of the unwrapping key used to unwrap the CEK
> cause K[CEK] to obey (1) and (2)
>
> You've argued (b) could apply for named keys, but I don't see how (b)
could
> work for ordinary WebCrypto keys without extension to the Key API.
>
> For (a), one could imagine simply assuming (1) and (2) always for all
> formats, or for all formats that don't explicitly carry attributes, but I
> don't feel this is especially elegant. Hence the conclusion that
attributes
> must be supported.
>
> Note that I am not saying that *only* formats with attributes must be
> supported, just that we need to specify this case.

I pointed you to examples of other APIs that either intentionally
*refuse* to deal with the problem (eg: CryptoAPI/CNG) or which provide
for a means of specifying the attributes for all keys unwrapped (what
you term as (b)), such as the example of PKCS#11. This is *a* possible
long-term solution - but again, you're asking for an API that serious
cryptographers and applications have not needed, so I don't think it's
entirely consistent to argue that useful applications or use cases
can't be met without it.

I strongly believe (a) is a mistake on multiple levels.


>> I think it's fundamentally a mistake to attempt to solve this problem
>> generically at this time, which is part of why I've highlighted from
>> the beginning the issues with wrapping and unwrapping.
>
>
> Can you explain why you think this ?

Because you get into the same mess that we saw with key querying, in
which you attempt to define a language and syntax for attributes that
can be represented in some normal form, whether it be for purposes of
querying for keys matching the attributes or for restricting the set
of attributes.



No, because we need to address this only for the WebCrypto attributes that
are fully defined in our specification: extractable and usages. In both
cases there are a small and well-defined set of values that need to be
mapped. I'm not talking about arbitrary attributes.




This is true whether you're talking about mapping tables of JWK or
programatic APIs.

Fundamentally, your constraint of "I must not trust the executing
JavaScript" forces a very strict requirement on implementations,
whereas I'm trying to argue that we can ship a useful API that is
hinged on "I trust JavaScript", and then iterate further on the "I do
not trust JavaScript" case.



In which case we should remove the extractable attribute.



Adopting the "Trust JS" case does not
preclude the "Don't trust JS" case, but adopting the "Don't trust JS"
case greatly restricts and impairs the ability to make any progress
whatsoever.



I don't see why, except that it seems to make all our proposals at least
unpopular with the Editor ;-)



...Mark




>
>>
>>
>> I don't think it necessarily requires a new UnwrappingKey subclass,
>> nor of the mapping to JWK. I suspect there's probably some interim
>> steps in how you see this process working that I'm missing, because it
>> does not seem self-evident.
>
>
> I hope the above clarifies.
>
>>
>>
>> I do not see requiring the format to support attributes on the CEK
>> being acceptable for the API
>
>
> I mean that the specification should include a format with attributes and
a
> requirement that attributes when specified must be respected.
>
> Of course, if you want to use CEK formats without attributes this should
> also work, but you won't be able to maintain non-extractability.

You should be clear that "you won't be able to maintain
non-extractability" is only true if we go with the solution you termed
as (a) [or your original proposal], which I think highlights why both
(a) and your original proposal are of limited value outside of the
Netflix-specific use case.


>
>>
>> , even if it will meet Netflix's specific
>> use case. We should specifically be avoiding both coupling the API to
>> any particular format
>
>
> With respect to key wrapping formats, agreed. JWK is on of the key export
> formats we've already decided to support.
>
>>
>> AND inventing our own formats, which such a
>> solution requires.
>
>
> Except that we need to define mapping from WebCrypto Key attributes
to/from
> JWK.

I think we will continue to disagree as to what "support JWK" means,
but I do not see it self-evident that we need to define a mapping of
all attributes to "support JWK".

<snip>

>>
>> Again, I'm proposing a solution that attempts to solve a middle-ground
>> in the quest for a generic long-term solution.
>>
>>
>> It allows for unextractable to be set for keys generated through the
>> API, and permits implementations using the key discovery API (which
>> is, inherently, as "implementation specific" as APIs such as EME) to
>> provide a different set of guarantees.
>
>
> Yep, but this doesn't address the base specification case, without named
> keys, as discussed on the call.

Agreed. And I see that as a feature.


>
>>
>>
>> I think we need to be extremely careful about trying to shove too much
>> into V1, and I also think we must remain very aware of the fact that
>> this particular feature you're requesting is one that is not at all
>> common in the crypto libraries existing user agents are using - which
>> was part of the whole motivation from this groups formation.
>
>
> I think we *are* being extremely careful. We've been working on
wrap/unwrap
> for many months. The group agreed after long discussion to put the
proposal
> into the specification, but it has only be partially implemented. There
are
> multiple independent implementations of our original proposal and so it's
> probably far better vetted than some other aspects of the specification.
>
> ...Mark

While I appreciate your proposal as a way of clearly specifying your
use cases, I do not see that the WG agreeing to treat "wrap and
unwrap" as in spec (and at risk) as an inherent agreement of either
all of the properties of your wrap/unwrap proposal or of the proposal
itself.

Quite simply, your proposal was deficient in a number of areas for any
non-Netflix use case, which you can see the modified proposal attempts
to rectify in a way that is both consistent with the underlying
cryptographic platforms that will be used to implement this API and
with what has been sufficient for a variety of industry uses. Further,
while it's absolutely correct that it does not (yet) attempt to solve
the 'unextractable' problem for non-wrapped keys, I would argue that
it's far better to leave it underspecified than to attempt to shoehorn
it in through things such as CEK attributes or through JOSE-only
functionality.