Re: Importing self-identifying JWKs

On Fri, Feb 21, 2014 at 9:48 AM, Mark Watson <watsonm@netflix.com> wrote:

> 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
>
>
This is exactly what I meant by something we can address later, but I'm
opposed to including now.

There are still many edge cases - including the SPKI and PKCS#8 cases - and
I would much rather have a uniform consistency for all import operations,
and for all formats, and THEN worry about optimizations.


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