Re: Preserving WebCrypto Key usages in JWK

On Thu, Nov 14, 2013 at 10:53 AM, Alexey Proskuryakov <ap@webkit.org> wrote:

> (combining responses, as they are very similar)
>
> 14 нояб. 2013 г., в 10:27, Graham Steel <graham@cryptosense.com>
> написал(а):
>
> > Relying on the fact that decrypt and unwrap use different algorithms
> > to keep the operations separated is a bad idea. Even if algorithms are
> > not identical, they can be similar enough to cause serious problems
> > (e.g. if they are variants of a counter mode and allow the same
> > keystream to be produced).
>
> Algorithms that are not identical will cause the operation to fail - the
> JWK key already contains an algorithm identifier that needs to be checked.
>
> I agree that relying on contents of cyphertext being incompatible with
> other algorithms would have been crazy.
>
>
> 14 нояб. 2013 г., в 0:58, Mark Watson <watsonm@netflix.com> написал(а):
>
> > ​My assumption has been that, in the absence of any text to the
> contrary, all algorithms that support decrypt also support unwrap, because
> we have defined unwrap == ( decrypt + import ) ​.​
>
> Not sure if this should be the case - e.g. supporting regular
> encrypt/decrypt with AES-KW seems unnecessary, and maybe the opposite
> (supporting key wrapping with other AES variations) is unnecessary too?
>

​We agreed last week to add wrap and unwrap usages to the algorithms that
support encrypt/decrypt, but not the opposite (i.e. we don't have
encrypt/decrypt with AES-KW).​


>
> >> I'm asking because if the sets of algorithms that support decryption
> and ones that support unwrapping don't intersect, then there is no problem.
> >>
> > Well, you're right that the problem illustrated in my example wouldn't
> be a problem. But it could also be a problem that a key intended to be used
> for "decrypt" got given the usage "encrypt" etc.
>
> I think that this kind of problem is not necessarily something to solve at
> key format level. As mentioned in the bug, there are lots of possible
> meaningful restrictions (like, "only allowed to be used during business
> hours"), and hopefully we are not adding them all into key serialization.
>
> I can't stress it strongly enough that having a key format with separate
> "use" and "uses" keys that have similar yet subtly different syntax and
> semantics is not a solution, it only perpetuates the problem by making it
> impenetrably confusing. I don't have a different solution to propose, but
> I'm still hopeful that there is no problem, or that it can be worked around
> in a less confusing manner.
>

​I have no objection at all to using the existing "use" attribute - if
there is a proposal that works. I share your concern, but I don't have a
working proposal either.

We could define new "use" values, like "enconly", "deconly", "sigonly",
"vfyonly", "wraponly", "unwraponly" etc. With just these, we would be able
to represent the usages that we are interested in for our use-case. But we
would not be able to represent all values of the WebCrypto usages
attribute, because that is an array that can represent multiple uses.

Together with the above, we could:
(a) extend the "use" format to allow multiple uses to be specified - either
as, say, a comma-separated list or just say that "use" can be an array, OR
(b) just say that combinations of usages other than the standard JWA ones
(enc = { encode, decode, wrap, unwrap } and sig = { sign, verify }) can't
be represented in JWK, OR
(c) disallow such combined usages in WebCrypto altogether

Odd combined usages (e.g. { encode, sign }) are probably a bad idea anyway,
so I have no problem if they are not supported, but if they are supported
in WebCrypto and not JWK then that just feels a little ugly.

Let me know you preference, or if you have any other ideas.

...Mark
​



>
> - WBR, Alexey Proskuryakov
>
>