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