Must trust roots use the same algorithms as leaf certificates

[charsleysa]

Currently the text is unclear whether trust roots must use the same algorithms as the leaf certificates.

For example:

• Root (ES384)
• Leaf (ES256) with ES384 signature from Root
• Key Attestation with ES256 signature from Leaf
• Issuer proof alg set to ["ES256"]

Would this be valid or invalid? The issuer has specified they support ES256 for the key attestation, but the trust root is ES384.

If this is invalid, that would effectively require any component that wishes to support multiple algorithms, be it for Credential, Wallet Attestation, Key Attestation, Verifier, to have a trust root per algorithm.

[jogu]

My reading of the spec is that this is valid; I don't think there's any intent that the requirements on signed JWTs extend into x509 certificates in the certificate chain.

[TimoGlastra]

My reading of the spec is that this is valid

@jogu that does have a lot of impact on the interoperability. When the first version of the playground from one of the EU LSPs came out, it used a certificate signed with P521 and it caused quite some interop issues.

Requiring P256 everywhere but leaving it undefined for root/intermediate certificates, may have similar effects as it did in the LSP.

Is this something an ecosystem should define further?

[c2bo]

We are already stating that certificate profiles are out of scope for HAIP and should be defined by ecosystems. Profiles usually also define mandatory to implement algorithms (at least in my understanding of profiles).

that The X.509 certificate profiles to be used are out of scope of this specification.

Which X.509 certificate profile to use (see Section 5, Section 4.4.1 and Section 4.5.1)

Maybe we should a bit of text that a profile definition should include mandatory to implement signature schemes for X.509 certificates?