Re: Importing self-identifying JWKs

One follow-up on this.

I believe we are in agreement that the caller of importKey() must specify
the algorithm. The algorithm parameter of importKey and the
unwrappedKeyAlgorithm parameter of unwrapKey should therefore not be
nullable. The "alg" member of the JWK, if present, must be checked for
consistency and it will be an error if it is inconsistent.

Similarly, if algorithm parameters (say, key length or choice of hash
algorithm) are specified in the importKey() call, then these must be
checked against anything specified in the imported key and again it should
be an error if they are inconsistent.

However, if algorithm parameters are not specified in the importKey() call,
and they can be derived from the imported key data, I believe we should do
that.

For example, the following should be allowed:

jwk = toUTF8( JSON.stringify( { kty: "oct", alg: "HS256", k:
"6gf8ewpf8g2478fypqf==" } ) )

p = importKey( "jwk", jwk, { name: "HMAC" }, true, [ "sign", "verify" ] )

However, the following, with the same value of jwk, would be an error:

p = importKey( "jwk", jwk, { name: "HMAC", hash: { name: "SHA-1" } }, true,
[ "sign", "verify" ] )

And the following would also be an error:

jwk = toUTF8( JSON.stringify( { kty: "oct", k: "6gf8ewpf8g2478fypqf==" } )
)

p = importKey( "jwk", jwk, { name: "HMAC" }, true, [ "sign", "verify" ] )

Comments ?

...Mark



On Thu, Feb 20, 2014 at 8:15 PM, Mark Watson <watsonm@netflix.com> wrote:

> Fine by me too - just wanted to provoke a discussion + decision.
>
> ...Mark
>
> Sent from my iPhone
>
> On Feb 20, 2014, at 8:03 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>
> Given that we don't support doing defaulting on things like extractability
> and key_ops - I think this should be punted until a need is demonstrated as
> well.
>
>
>
> Jim
>
>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com <sleevi@google.com>]
> *Sent:* Thursday, February 20, 2014 6:17 PM
> *To:* Richard Barnes
> *Cc:* Mark Watson; public-webcrypto@w3.org
> *Subject:* Re: Importing self-identifying JWKs
>
>
>
> I closed this as WontFix before I saw this, so we can re-open if someone
> can demonstrate a compelling counter-argument.
>
>
>
> No. I strongly oppose this. "alg" is optional in JWK, it is not
> self-defining. pkcs8 and spki also have OPTIONAL (PSS, OAEP) params that do
> not guarantee a key is fully self-describing.
>
>
>
> We already have to specify all of those mappings anyways - it's necessary
> to ensure a key is internally consistent with the import case that the
> requesting party chose. That is, you already have to decide if importing an
> SPKI that is RSA-PSS, whether or not it's valid for the specific hash/mgf
> that has been chosen (eg: when PSS params are not supplied AND when they
> are)
>
>
>
> Even if we were to support it, I do not support adding it to "v1" - we
> can/should punt this down the road, as it's always possible to re-visit
> this as an optimization, but impossible to re-visit if we shove it in now.
>
>
>
> On Thu, Feb 20, 2014 at 5:53 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
> Note that the "pkcs8" and "spki" key types also have algorithm
> identifiers.  So if we do this for JWK, we might as well do it for those
> key types as well.  Only "raw" is, well, raw.
>
>
>
> The only nuance I see here would be in mapping the respective algorithm
> identifiers to WebCrypto algorithm identifiers.  It would be unpleasant to
> have to specify all these mappings, which it seems like we would have to do
> unless we all agree that the mappings are obvious.  I do think that it is
> the case (that the mappings are obvious), but not having thought much about
> it, I'm concerned that there's some subtlety lurking.
>
>
>
> So while I generally agree that the API should do the right thing when it
> has the information it needs (sensible defaults!), we should have some
> discussion of the mapping issue to make sure we're OK.
>
>
>
> --Richard
>
>
>
> On Thu, Feb 20, 2014 at 8:09 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> I filed this:
>
>
>
> Presently, the algorithm whose import key operation is executed when
> importKey is called is determined entirely by the "algorithm" parameter to
> that method.
>
>
>
> For JWK, it would in theory be possible to support:
>
>
>
> P = crypto.subtle.importKey( "jwk", jwk, null, true, [ <usages> ] )
>
>
>
> and have the correct algorithm determined by the "alg" member of the JWK.
>
>
>
> Do we want to support this ?
>
>
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24759
>
>
>
> ...Mark
>
>
>
>
>
>