Allow HMAC-based Issuer-signed JWTs and KB-JWTs to support different aspects of repudiation

[awoie]

Currently the spec says:

It MUST NOT use none or an identifier for a symmetric algorithm (MAC).

To support KB-JWTs using HS256, for example after using DH key agreement, we should allow symmetric algorithms.

[tlodderstedt]

I support this issue. There are scenarios where sd-jwts may be protected with symmetric crypto. I'm wondering why symmetric algorithm (MAC) are ruled out so far.

[awoie]

The section I quoted applies to Issuer-signed JWTs, closing this issue.

[awoie]

After some internal discussion, I guess it is worthwhile to confirm with the authors that HMAC for KB-JWT is supported @bc-pi @danielfett ?

[awoie]

I quoted the wrong section above. However, in the KB-JWT section there is a similar requirement on alg of the KB-JWT:

alg: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. MUST NOT be none or an identifier for a symmetric algorithm (MAC).

By having this requirement it means the SD-JWT spec does not allow HS256 and therefore does not allow approaches where a HS256 is agreed via DH. Note, the asymmetric DH key could still be endorsed by the cnf claim

[tlodderstedt]

I think it should be allowed for both, kb jwt and sd jwt. Or let me put it the other way around. Why is it prohibited now?

[paulbastian]

The text is only about SD-JWT right now. I actually want HMAC for SD-JWT

[awoie]

The text is only about SD-JWT right now. I actually want HMAC for SD-JWT

Currently, the spec does not allow HMAC for Issuer-signed JWT and it does not allow HMAC for KB-JWTs. To support repudiation KB-JWTs should allow alg values involving symmetric keys such as HS256 (see my comment above).

[Sakurann]

I don't support adding an option to HMAC KB JWT. Issuer signs over the key used to HMAC KB JWT. Anyone who knows the nonce of the transaction can generate that HMAC KB JWT. It does not proof anything. It only makes sense if it is issuance during presentation where wallet is asking issuer to issue over wallet's key that wallet generated for that verifier.

[awoie]

I don't support adding an option to HMAC KB JWT. Issuer signs over the key used to HMAC KB JWT. Anyone who knows the nonce of the transaction can generate that HMAC KB JWT. It does not proof anything. It only makes sense if it is issuance during presentation where wallet is asking issuer to issue over wallet's key that wallet generated for that verifier.

This is how it works:

• The issuer signs the public key of the holder and puts it into the cnf claim.
• Verifier provides their public key (potentially ephemeral) to the holder.
• Holder performs DH to compute a shared secret and then derives a symmetric key, for example using concatKDF
• Holder computes the HMAC and encodes it as a KB-JWT
• Holder provides KB-JWT to the verifier
• Verifier verifies KB-JWT and knows that holder signed it but verifier cannot prove to anybody else that holder signed it because the verifier could have also computed it -> repudiation.

[awoie]

I don't support adding an option to HMAC KB JWT. Issuer signs over the key used to HMAC KB JWT. Anyone who knows the nonce of the transaction can generate that HMAC KB JWT. It does not proof anything. It only makes sense if it is issuance during presentation where wallet is asking issuer to issue over wallet's key that wallet generated for that verifier.

This is how it works:

• The issuer signs the public key of the holder and puts it into the cnf claim.
• Verifier provides their public key (potentially ephemeral) to the holder.
• Holder performs DH to compute a shared secret and then derives a symmetric key, for example using concatKDF
• Holder computes the HMAC and encodes it as a KB-JWT
• Holder provides KB-JWT to the verifier
• Verifier verifies KB-JWT and knows that holder signed it but verifier cannot prove to anybody else that holder signed it because the verifier could have also computed it -> repudiation.

DH is computed using the public key of the verifier and the private key of the holder, so the HMAC proves KB of the private key of the holder.

[awoie]

Essentially, there are two things where repudation could be applied:

• KB-JWTs (especially if sd_hash is used)
• Issuer-signed JWTs

Both can use an approach using DH with a private holder key and a public verifier key to derive a symmetric key to either issue an SD-JWT or prove KB of the cnf claim.

[bc-pi]

328 is related and has some prior discussion

[bc-pi]

The thinking behind the Issuer-signed JWT being only asymmetric was basically that this model implies/assumes that an Issuer issues a token/credential to the holder with no idea of where the holder will use it. Having a shared symmetric key seemed really weird in that situation. Also hard/awkward to explain why or how a shared symmetric key would work in that kind of situation (like ECDH happening through the holder to establish an symmetric key between verifier and issuer is a pretty different model with less obvious need for SD). But with that said, there’s been some reoccurring talk about loosening the restriction to not prohibit an HMAC on the Issuer-signed JWT. And thinking (mostly from @danielfett) that that change could be made without delving into the how or why details. Personally, I'd be okay with allowing it but do not think the draft should get into describing how it might work.

[bc-pi]

With respect to HMAC for key binding - the current draft does allow for Key Binding to be "provided by means not defined in this specification" like here and here and maybe other places. Is that sufficient to allow for these cases that need repudation of the presentation?

[bc-pi]

Allowing for HMAC'd KB-JWT doesn't seem unreasonable but I don't think defining the whole DH & KDF dance is appropriate at the level of this draft. So appropriate scoping and detail might be tricky. But I think it'd have to be similar to the treatment of nonce and aud in the KB-JWT now (which say "How this value is obtained is up to the protocol used and out of scope of this specification" and "How the value is represented is up to the protocol used and out of scope of this specification" respectively).

[danielfett]

Regarding the question whether we want to allow HMACs for the Issuer-signed part of the KB-JWT: For our use case, only the HMAC for the Issuer-signed part is critical. The KB-JWT can remain as-is with an asymmetric key, as a throwaway asymmetric key can be used for it.

(There may be other use cases though.)

[paulbastian]

Related: https://paulbastian.github.io/jose-ecdh-mac-algorithms/draft-bastian-jose-alg-ecdh-mac.html This mechanism may work for both SD-JWT and KB-JWT

[awoie]

SD-JWT currently says:

It MUST NOT use none or an identifier for a symmetric algorithm (MAC)

@paulbastian Does this mean your new ecdh algorithm is now allowed by SD-JWT?

[paulbastian]

Actually, now that you say it, a spec change may not be needed as the draft defines a new alg

[bc-pi]

https://paulbastian.github.io/jose-ecdh-mac-algorithms/draft-bastian-jose-alg-ecdh-mac.html

interesting work @paulbastian! I might humbly suggest that you revisit how the header parameters are used to better align with how they are already defined in JWS. Specifically, I think the standard JWS headers https://www.rfc-editor.org/rfc/rfc7515#section-4.1 like kid/jwk/x5c/x5t/etc should be for indicating the key of the Generating Party, which is really like the signer in this case. And a new header be defined to convey the Verifying Party's key. What's in draft-bastian-jose-alg-ecdh-mac-01 currently feels kinda backwards from what JWS has. And the Generating Party's key is probably not going to be ephemeral in most cases so epk doesn't seem quite right.

[paulbastian]

https://paulbastian.github.io/jose-ecdh-mac-algorithms/draft-bastian-jose-alg-ecdh-mac.html

interesting work @paulbastian! I might humbly suggest that you revisit how the header parameters are used to better align with how they are already defined in JWS. Specifically, I think the standard JWS headers https://www.rfc-editor.org/rfc/rfc7515#section-4.1 like kid/jwk/x5c/x5t/etc should be for indicating the key of the Generating Party, which is really like the signer in this case. And a new header be defined to convey the Verifying Party's key. What's in draft-bastian-jose-alg-ecdh-mac-01 currently feels kinda backwards from what JWS has. And the Generating Party's key is probably not going to be ephemeral in most cases so epk doesn't seem quite right.

Thanks for the feedback @bc-pi The header names were the part that I was least sure about, I oriented on the ECDH-ES part of JWA. But I don't mind changing them, feel free to open an issue on the repo!

[danielfett]

With the PR, MACs are now no longer prohibited, but we agreed to not touch the other language in the spec (around signatures/signing/private/public keys etc.) as that would needlessly complicate the spec.