consider adding MTI crypto suites

[Sakurann]

There has been feedback from EUDIW that having a small list of MTI (mandatory to implement) crypto suites for multiple things would greatly help for interoperability. Below is probably a least controversial list..?

Issuer Signatures:

• ECDSA using secp256r1 and SHA-256

Key binding/presentation and Verifier Signatures:

• ECDSA using secp256r1 and SHA-256

Encryption (if needed):

• AES-256-GCM

Hashing:

• SHA-256

[andprian]

This list looks reasonable.

[c2bo]

For encryption, it might make sense to mandate support for AES-128-GCM as well. Same Security Strength as ECDSA + P256 and most references I've seen in the past mandate support for AES-128-GCM and recommend AES-256-GCM (e.g., TLS 1.3 https://www.rfc-editor.org/rfc/rfc8446.html#section-9.1).

[Sakurann]

WG discussion:

• what if the implementation can only issue using algorithms not in the list here? is that still compliant to haip or are those implementers expected to write their own profiles.
  • current assumption is probably that not implementing MTI algs at all is not HAIP-compliant
  • some regulatory bodies are starting discouraging P256, are we better off mandating P384 instead of P256? does it make lives of implementators harder? alternative view on the call was that after P256, there's post quantum, so P256 is good enough.
• this sentence was intended to apply to mdocs too: "Issuers, Holders, and Verifiers MUST support P-256 (secp256r1) as a key type with the ES256 JWT algorithm [RFC7518] for the creation and the verification of the above signatures" so need to clarify this sentence

[jogu]

ISO WG noted that if we mandate P-256 for issuing mdls then that would mean that some 18013-5 compliant mdls would not be compliant with HAIP and requested that we are clear with them if that is the case or not.

[awoie]

IMO, the following can be done:

• issuer must use one of the following curves: p-256, p-384, ...
• wallet must support all curves
• verifier must support all curves

[Sakurann]

comment from @martijnharing in https://github.com/openid/OpenID4VC-HAIP/pull/228/files#r2287494885

Related to https://github.com/openid/OpenID4VC-HAIP/issues/193 ,this section is not explicitly referenced in the different sections and the question is whether it's applicable to all the different flows (issuance / presentment of sd-jwt, mdocs etc) It's important because it's currently not clear whether it's possible to present / issue any mdoc that's compliant with ISO/IEC 18013-5. For example, are the following flows compliant to HAIP:

Issuing an mdoc or sd-jwt to a wallet that only supports P-384 key Issuing an mdoc or sd-jwt a wallet that only supports brainpool-256 keys Issuing an mdoc or sd-jwt by an issuer that only wants to issue brainpool curves Having an RP certificate with a P-384 key Having a root RP certificate with a P-521 key I'm not necessarily saying that all of these should be HAIP compliant, but it should be clear whether they are or not.

[Sakurann]

wg discussion:

summary

• rough direction seems to be mandate 1 or more curves in HAIP for issuers/wallets/verifiers, but leave an option for the ecosystems to define things on top.
• next step is to decide the curves.

discussion

options for who supports what option 1: mandate the set in HAIP

1. to sign the credential signing, issuer can choose between and the verifier and the wallet must be able to understand both for validating.
2. to sign the cryptographic key binding, wallet can choose between and the verifier and the wallet must be able to understand both for validating.
3. to sign the openid4vp request, verifier can choose between and the wallet must be able to understand both for validating.

option 2: entirely leave it for verifier to find out for 1. and 2., alternative is to say that it is verifier's responsibility to know what issuer/wallet supports for signing and support it.

option 3: combination of option 1 and 2

• x number of mandatory curves, but ecosystem can add additional things on top (not instead of)

option 4: make it entirely an ecosystem choice

• verifier needs to figure out what issuer/wallet supports.

(current) options for the curves to be supported:

• P-256
• P-384
• P-512
• Ed25519 (no wide cloud HSM support)

considerations: - preventing dual issuance of the same credential signed with different curves - for the curves, need be careful of what is supported by the device local HW and cloud HSMs. also be mindful of what ISO supports, from the perspective of 18103-7 annex D, 23220-3 and 23220-4. - de facto this means no MAC-ing for both mdoc and sd-jwt (based on the curves algs)

[Sakurann]

need to talk about status list signing algs too

[awoie]

need to talk about status list signing algs too

Yep, for this, please also update Section 7 Crypto Suites.

[awoie]

IMO, Section 8 Hashing also should be updated, since the hash algorithms used in signature suites are already defined by the suite itself (e.g., ES256 = ECDSA with P-256 and SHA-256). Defining the hash algorithm for the SD digests in SD-JWT VC would make sense but this belongs to the Credential Format Profile for SD-JWT VC.

[jogu]

I think we probably need a carve out around in particular mdl for at least the credential signing - as many mdl ecosystems are already live with choices that aren't currently allowed in HAIP, we should have some way for those ecosystems to use HAIP without having to redo their issuers etc. i.e. other crypto curves and MAC.

[Sakurann]

wg discussion:

• in cases where there are existing requirements on crypto suites (like ISO 18013-5) mandating specific set of signing curves, probably worth adding a sentence that allows/encourages compliance with those on top of what HAIP requires.
• also. in cases where there are existing requirements on MACing the credential on top of digital signatures (like ISO 18013-5), probably worth adding a sentence that allows/encourages compliance with those on top of what HAIP requires.
• on top of a general statement on the ecosystems defining their crypto requirements, have an annex or something that gives specific examples like 18013-5. new issue will be opened on this

[jogu]

Further WG discussion today:

• We shouldn't do anything specific to mdl, because we'd then need to define for other mdoc formats (vehicle registration, vaccination certs, etc etc), and we don't want to get into defining per-credential-use-case things

• We shouldn't do anything generally for mdoc, it would be bad to reference the 18013-5 table for mdoc in general.

@awoie to think further & check what ISO 23220 says

[Sakurann]

We shouldn't do anything generally for mdoc, it would be bad to reference the 18013-5 table for mdoc in general.

why?

[jogu]

Discussing on today's EU call:

Probably we can't limit the algorithms that are used for mdoc (e.g. various jurisdictions already have live deployments and we don't want them to have to change their crypto to be able to adopt HAIP - but unfortunately we have very little information on what choices people have made in their existing / in progress mdl/mdoc deployments).

We can recommend algorithms perhaps (e.g. NIST have approved algorithms for the TSA Real ID waiver program.) but this doesn't really solve the interoperability issue.

People then raised the point that it's odd restricting SD-JWT but not mdoc, as that would mean ecosystems using both potentially would have an existing choice for mdoc and would be forced into using a different one for SD-JWT.

Christian suggested should be some MTI algorithms for Wallets as that's the most important points, as verifiers generally know what credential they have requested and what signature the issuers they accept would use. ISO has MTI algorithms for verifiers though.

[Sakurann]

clarification:

• clarification: for HAIP, it is more important to have MTI algs for the wallet as opposed to the RP/issuer (unlike 18013-5 which is offline use-case). mainly for credential signing.

[Sakurann]

option 1: editors/chairs suggestion (perspective of wallet):

• leave it open what issuers supports
• leave it open what verifiers support
  • assumption is that verifiers can in advance determine cryptosuites supported by the ecosystem (ie such as mDL issuers/verifiers implementing 18013 series)
• for interoperability, wallets MUST support at least P-256
  • for signing KB-JWT/deviceSigned during presentation
  • to validate presentation request, when it is signed
  • to sign wallet attestation (incl. PoP), when VCI Annex E is used
  • to sign key attestation, when VCI Annex D is used
• ecosystems can mandate other curves for wallet too

Option 2: suggestion that came up during the WG discussion (from the verification perspective):

• lssuers MUST at least support P-256
  • to validate wallet attestation (incl. PoP), when VCI Annex E is used
  • to validate key attestation, when VCI Annex D is used
• RPs MUST at least support P-256
  • to validate KB-JWT/deviceSigned
  • assumption is that verifiers can in advance determine cryptosuites supported by the ecosystem (ie such as mDL issuers/verifiers implementing 18013 series)
• wallets MUST at least support P-256
  • to validate presentation request, when it is signed
• ecosystems can mandate other curves for wallet too

other comments

• Peter: what matters are curves that would required HW, those are harder to implement. curves in SW are easier to implement.
• Martijn: add in the implementation considerations something like "in real life, the actual issuer/RP/wallet may not accept a specific artifact if there are legitimate concerns (security/privacy/etc)"?
• WG discussion: will proceed with PR with the Option 2.