Re: Algorithm aliasing and JWK algorithm names

On Fri, Jan 31, 2014 at 10:03 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> I am not sure if the following is possible or even desirable.
>
>
>
> Is there some sense in which the JWK algorithm names defined in 11.5.2.1
> can be treated as alias names for the WebCrypto algorithms in the algorithm
> normalization process?
>
>
>
> One of the issues that I am seeing is that there is, in some sense,
> information that is lost or not provided for some of the dictionary entries
> on the JWK side but that are not on WebCrypto side.
>

>

Just to close the loop on this - this is being resolved. Mark has some
currently committed text on how to map it, but it in fact leaves it
somewhat ambiguous. The general issue here is that we need to more formally
specify how the key tainting works, and make it a formal property rather
than implied.

What I mean by that is in the case of PSS or OAEP, for example, yes, the
hash algorithm needs to move into the generation parameters. This also
mirrors how Import/Export would work, since Importing an SPKI for PSS/OAEP
will necessarily bind to a hash, the same as it would for a JWK.

This may also solve (some of) the angst re: generation vs operation
parameters.


> For example, if I import a JWK key that has {“alg”:”RS256”,…} in it, this
> means that the hash algorithm is, in theory, a fixed value.  However this
> is not information that is currently defined for the RSA key generation
> dictionary.  As such the value would not be visible as part of the
> Key.algorithm since this is defined to return only the generation
> dictionary elements.
>

Just to clarify - it is *not* defined to return only the generation
dictionary elements. It's actually undefined. This is an issue I'm
correcting.


>
>
> I am also not sure how an export call is supposed to make the decision
> between A128GCM and A128GCMKW (unless possibly there is some alias
> indicator or we drop a hint of using keyusage as a distinguisher) when
> doing an export using the jwk format.
>
>
>
> Jim
>
>
>

I don't have a compelling solution for this. Someone who feels particularly
motivated to support this use case needs to provide a proposal. There's
nothing prohibiting a (WebCrypto) key from supporting an (encrypt, decrypt,
wrap, unwrap).

There's a similar fidelity question regarding how "key_ops" and "use" - you
might Import a JWK with a "use" of "enc" - which corresponds to an
"encrypt" and "decrypt" usage - but for which export instead uses the
"key_ops" field.

Note that this is *only* an issue for wrapped keys - an application that
cares deeply about this case can *always* make it conform to the *JOSE*
requirements by using JSON.parse and JSON.stringify . Considering that
WebCrypto is not meant to be a JOSE implementation, and instead is solely
using JWK (eg: without considerations to requirements of JWE like RSA keys
being >= 2048 bits) I'm happy living with that solution.