Thanks for your reply Neil! I think there's a hidden assumption which is not defined anywhere. According to section 7.1 of JWA: > This specification establishes the IANA "JSON Web Signature and Encryption > Algorithms" registry for values of the JWS and JWE "alg" (algorithm) and > "enc" (encryption algorithm) *Header Parameters*. Later in the registration template in section 7.1.1, the "Algorithm Usage Location(s) column is defined like this: > [...] This must be one or more of the values "alg" or "enc" if the algorithm > is to be used with JWS or JWE. The value "JWK" is used if the algorithm > identifier will be used as a JWK "alg" member value, but will not be used > with JWS or JWE [...]
According to the JWE RFC, the "alg" Header Parameter has the same meaning as in JWS. However, JWS does not define what the "Usage Location(s)" should be for "alg" and neither does JWE. So, in a JWE, you could use an algorithm whose usage location is "enc". This does not make sense. You don't use a CEK algorithm to encode the actual CEK. The problem lies in the registration template I think. If the "Algorithm Usage Location(s)" column was defined as the Header Parameter name that should be used with the entry, everything would be fine. So the hidden implication is that the "Algorithm Usage Location(s)" corresponds to the Header Parameter Name but that just isn't written anywhere, is it? Then in JWK, I think there is the same hidden assumption that the "Algorithm Usage Location(s)" corresponds to Parameter name which would exclude any CEK algorithms since they all have "enc" as their usage location. And, I also think that a JWK is not intended to represent a CEK since they are tied to a single JWE. > It makes sense when alg=dir is used, as the enc is then the real algorithm to > be used with the key. Yes and in the registry, the usage location is "alg" as also described in RFC 7518 section 4.5. > (And I notice our code that enforces this does exactly this check only when > alg=dir). Which check exactly? Has your implementation support for JWK and if so, does it successfully parse the key from RFC 7520 section 3.6? Btw, is your implementation public? I'd like to play around with it to look for interoperability issues. -- Erik Tesar <[email protected]> https://erik-tesar.com ------- Original Message ------- On Wednesday, July 20th, 2022 at 5:04 PM, Neil Madden <[email protected]> wrote: > This is an interesting question. The definition of the “alg” field in RFC > 7517 (JWK - as distinct from the “alg” header in JWE/JWS), just says that the > value must come from the IANA JSON Web Signature and Encryption Algorithms > registry or a collision-resistant name. That registry contains both “alg” and > “enc” values, so I guess technically this is fine. > > It makes sense when alg=dir is used, as the enc is then the real algorithm to > be used with the key. (And I notice our code that enforces this does exactly > this check only when alg=dir). > > — Neil > > > On 17 Jul 2022, at 16:13, Erik Tesar [email protected] > > wrote: > > > > Hi there, > > it seems like the example symmetric key in section 3.6 uses `A256GCM`, > > which is a content encryption algorithm (used in the `enc` header), in the > > `alg` header parameter. According to the `Algorithm Usage Location(s)` > > column in the `IANA JSON Web Signature and Encryption Algorithms` > > registry1, `A256GCM` should be used in the `enc` header not the `alg` > > header. Therefore, I wonder if this is intentional or an error (I believe > > the latter). If it is an error, the key is malformed and I think an errata > > should be issued. > > > > Sincerely, > > > > -- > > Erik Tesar [email protected] > > https://erik-tesar.com > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
