Double check the spec that MAC is not prohibited
awoie opened this issue · comments
The specification currently uses terms like public key validation and potentially other things when it comes to the verification of the KB-JWT. We should make sure there is no language that would prohibit the use of MAC authentication for KB-JWT and Issuer-signed JWT.
Currently blocked by SD-JWT:
@paulbastian A few options we discussed on the editor's call today (cc @danielfett @bc-pi ):
- not do anything in SD-JWT to enable this since SD-JWT just prohibits "symmetric algorithms". We could wait for an JOSE
algvalue specification to appear and to be registered in the IANA registry which states that the algorithm is not symmetric. One downside of this approach is that standard JOSE libs won't work today since thealgvalue is not supported. Note that technically one could implement this using standardHS256if the key was agreed/derived using an ECDH/ConcatKDF schema. - remove the normative statement completely from SD-JWT that prohibits "symmetric algorithms".
- change the normative statement to a SHOULD NOT use "symmetric algorithms" and explain in the SD-JWT security - considerations section where symmetric
algvalues are acceptable and when not. - keep the MUST NOT statement in SD-JWT but add an "... unless" clause that explains where this could be useful, e.g., for hybrid schemes but this needs to be confirmed if this process is indeed hybrid and therefore the use case is covered.
I think I still lean towards preferring something like # 2 - just remove the explicit prohibition of symmetric algorithms from SD-JWT and not say much, if anything else about it in that spec. Let the layer above SD-JWT/JOSE (probably the presentation protocol) define how an HMAC key is agreed upon and use existing JWS HMAC algs and implementations. I.e., the verifier sends a public key in it's presentation request, which the generator uses in a key agreement with their private key to get a key that is then KDFd to produce an appropriate key for existing/established JWS HS256[384|512] algs. That layer is going to have to define much of that anyway so there's not much gain from pushing an ECDH-based MAC alg into JOSE/JWS (also note that defining and registering a new JOSE alg is far from a trivial exercise). And the prohibition of symmetric algorithms in SD-JWT makes sense from a particular perspective but is arguably just unnecessarily restrictive at the building block layer.
I would agree that removing the restriction is okay, as SD-JWT is an improvement of JWT and JWTs don't have this restriction.
Do you think that ECDH-ES is an anti-pattern? It has been in JWA from the beginning and you could have the same arguments there?
Do you think that ECDH-ES is an anti-pattern? It has been in JWA from the beginning and you could have the same arguments there?
I wouldn't take it that far. My comments/arguments here are really just in the context of the current state of JWS specs and existing library support.
@bc-pi @paulbastian if option 2 is our favorite options. Should the SD-JWT VC spec then say something about that? IMO, it would be good to say something in the security considerations at least.
I agree in general that since SD-JWT is a building block, being too restrictive there regarding symmetric algorithms is probably not necessary.
I don't object removing the restriction, I checked RFC7519 and there is no similar statement.
[...] if option 2 is our favorite options. Should the SD-JWT VC spec then say something about that? IMO, it would be good to say something in the security considerations at least.
Definitely not opposed to saying something. But it might be challenging to say something that's actually meaningful/helpful.
oauth-wg/oauth-selective-disclosure-jwt#400 removes the explicit prohibition on MAC from SD-JWT (which will be in the -08 draft-ietf-oauth-selective-disclosure-jwt)
Then, we need a PR that cleans up the language in this specification, so MAC is not going to be prohibited.