Re: Preserving WebCrypto Key usages in JWK

On Tue, Dec 10, 2013 at 12:51 PM, Ryan Sleevi <sleevi@google.com> wrote:

> This seems like it would break backwards compatibility with a lot of JWK
> applications.
>

​No, a string containing a single usage would still be valid. We'd be
adding the possibility to specify an array of values. We can require that
the array format is used only when there is more than one value. Since any
existing JWK applications use only a single value there'd be no change for
them.​




>
> That said, it seems that if JWK is meant to be a JSON-friendly key format,
> the notion of a collection of usages is reasonable. It seems that the
> current "use" specification in JWK (being either sign = sign/verify and
> encrypt = encrypt/decrypt) is alternatively expressed as use = "jwe" (for
> encrypt/decrypt) or use = "jws" (for sign/verify), at least conceptually.
>

​Indeed.​


>
> I'm fine with approaching JOSE again to discuss this in the context of JWK
> as a key representation form. If you do post, can you include the link to
> the discussion (rather than cross-posting on the two lists) so we can
> follow-up in JOSE?
>

​Sure.

...Mark​



>
>
> On Tue, Dec 10, 2013 at 12:46 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> All,
>>
>> I've got some implementation feedback that it would be better to specify
>> multiple uses in JWK as a JSON array instead of comma-separated string.
>>
>> We could ask JOSE to tweak the JWK specification to allow registration of
>> non-string values for the use attribute. I would hope this would be
>> straightforward.
>>
>> Comments ?
>>
>> ...Mark
>>
>>
>>
>> On Thu, Nov 21, 2013 at 8:51 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>> All,
>>>
>>> I made a revision to the proposal based in (a) in the bug:
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23796
>>>
>>> JWK defines "use" to be a string, so I think it would be problematic to
>>> define it to be an Array without getting the JWK specification to change.
>>>
>>> Some combined usages (for example WebCrypto encrypt + decrypt) could be
>>> useful, but cannot be represented with options (b) and (c).
>>>
>>> ...Mark
>>>
>>>
>>> On Mon, Nov 18, 2013 at 10:52 AM, Alexey Proskuryakov <ap@webkit.org>wrote:
>>>
>>>>
>>>> 18 нояб. 2013 г., в 9:57, Mark Watson <watsonm@netflix.com> написал(а):
>>>>
>>>> > ​My assumption has been that, in the absence of any text to the
>>>>> contrary, all algorithms that support decrypt also support unwrap, because
>>>>> we have defined unwrap == ( decrypt + import ) ​.​
>>>>>
>>>>> Not sure if this should be the case - e.g. supporting regular
>>>>> encrypt/decrypt with AES-KW seems unnecessary, and maybe the opposite
>>>>> (supporting key wrapping with other AES variations) is unnecessary too?
>>>>>
>>>>
>>>> ​We agreed last week to add wrap and unwrap usages to the algorithms
>>>> that support encrypt/decrypt, but not the opposite (i.e. we don't have
>>>> encrypt/decrypt with AES-KW).​
>>>>
>>>>
>>>> Makes sense to me!
>>>>
>>>> We could define new "use" values, like "enconly", "deconly", "sigonly",
>>>> "vfyonly", "wraponly", "unwraponly" etc. With just these, we would be able
>>>> to represent the usages that we are interested in for our use-case. But we
>>>> would not be able to represent all values of the WebCrypto usages
>>>> attribute, because that is an array that can represent multiple uses.
>>>>
>>>> Together with the above, we could:
>>>> (a) extend the "use" format to allow multiple uses to be specified -
>>>> either as, say, a comma-separated list or just say that "use" can be an
>>>> array, OR
>>>>
>>>>
>>>> An array seems like the cleaner option of the two, but it also has
>>>> higher potential of breaking tools designed to work with JWK, as it's a
>>>> different code path than string comparison. We'd need JWK changed to allow
>>>> arrays, and even then, tools authors don't all read standards, many just
>>>> look at a single example and work from that.
>>>>
>>>> (b) just say that combinations of usages other than the standard JWA
>>>> ones (enc = { encode, decode, wrap, unwrap } and sig = { sign, verify })
>>>> can't be represented in JWK, OR
>>>> (c) disallow such combined usages in WebCrypto altogether
>>>>
>>>> Odd combined usages (e.g. { encode, sign }) are probably a bad idea
>>>> anyway, so I have no problem if they are not supported, but if they are
>>>> supported in WebCrypto and not JWK then that just feels a little ugly.
>>>>
>>>> Let me know you preference, or if you have any other ideas.
>>>>
>>>>
>>>> I'm fine with any of these as an implementor, these are all very good
>>>> ideas.
>>>>
>>>> Thank you!
>>>>
>>>>  - WBR, Alexey Proskuryakov
>>>>
>>>>
>>>
>>
>