RE: Importing self-identifying JWKs

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