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 #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)