- From: <bugzilla@jessica.w3.org>
- Date: Mon, 12 Jan 2015 22:44:57 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27814 --- Comment #5 from Ryan Sleevi <sleevi@google.com> --- (In reply to jimsch from comment #4) > It is also an "alg" parameter for some JWK - which says that the JWK is to > be used only for JWE operations which have the same "alg" value. That is it > can be used to restrict the set of algorithms the key can be used with. <snip> > And, from a JOSE perspective, this results in an encryption operation even > though there are some operations performed which are not encryption in the > middle. Only the composite algorithm is to be considered. I'm still a little confused here about how it's relevant to WebCrypto, in as much we don't support the composite algorithms. <snip> > > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#ecdh- > > description > > > > In particular, importKey dictates that if "use" is present in a JWK, then > > throw a DataError. > > And was I ever surprised when the import operation did not work because of > this. This was completely unexpected behavior Not to sound dismissive, but there's been plenty of "unexpected" behaviour that comes when people have approach with different mindsets. e.g. I see that Anders recently raised again that it was "unexpected" behaviour that JOSE and Web Crypto algorithms don't match - which is unexpected if you think the two are meant to solve the same use cases and problems, or completely expected if you think they aren't (which they aren't, as was pointed out on the JOSE list). In order to better understand this impedence, could you provide a scenario where things would break under the current behaviour? And what I mean by that is not so much a contrived case (we can easily see that "use" on a JWK would be rejected, as per the spec), but a use case where it would cause issue? I think that may help make it clearer the issue at hand. Also, to make sure I'm understanding your argument well enough to repeat it: - In JOSE, an EC public key with an "alg" of "enc" is used for a combined ECDH-ES or ECDH-ES+A*KW algorithm, which grants the EC public key the deriveKey capability, which is then fed into Concat to either derive a Wrap/Unwrap AES-KW key (ECDH-ES+A*KW) or a Encrypt/Decrypt [any alg here] CMK key (ECDH-ES) - Thus, when used with JOSE, in all cases, a JWK EC key with "enc" implies deriveKey/deriveBits Now, you've filed this bug against Appendix A.2, but it sounds like the *real* issue is with ECDH + JWK import. That is, one would not necessarily have the deriveKey/deriveBits usages on an RSA key, and for a JWK secret key, it would be an algorithm-by-algorithm basis (e.g. an AES key would not have the deriveKey/deriveBits, but if we allowed an HKDF key to be imported as JWK, then a 'use' field would be presumably valid) Have I properly restated the issue as you see it? -- You are receiving this mail because: You are on the CC list for the bug.
Received on Monday, 12 January 2015 22:44:58 UTC