RE: Comments on wrap/unwrap

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

>Michael

From: Mark Watson [mailto: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<mailto:sleevi@google.com>> wrote:
On Mon, Jun 17, 2013 at 2:34 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
>
>
> On Mon, Jun 17, 2013 at 10:55 AM, Ryan Sleevi <sleevi@google.com<mailto: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.