Re: Preserving WebCrypto Key usages in JWK

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

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.

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?


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