Re: Preserving WebCrypto Key usages in JWK

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