Re: Importing self-identifying JWKs

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