prohibit self-signed certificates for x509_hash

[awoie]

• prohibit self-signed certificates for x509_hash
• additionally, we somehow lost the preventing the trust anchor language from prevent trust anchor certs to be included in x5c header #238 for x509_hash; also the doc history, this PR fixes it.

Fixes #236

[jogu]

There are another 2 places that we mention x5c and don't mention "The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the signed request" - should we just fix them all?

[tlodderstedt]

I don't understand why we want to prohibit self signed certifcates. Issue #236 also does not explain the rationale. So I suggest to remove the second sentence.

[jogu]

Discussed on this morning's WG call: Torsten is going to add a comment to the issue as he's not sure why we're preventing self-signed certs.

[tlodderstedt]

I don't understand why we want to prohibit self signed certifcates. Issue #236 also does not explain the rationale. So I suggest to remove the second sentence.

[awoie]

I don't understand why we want to prohibit self signed certifcates. Issue #236 also does not explain the rationale. So I suggest to remove the second sentence.

@tlodderstedt Here are some of the reasons and does this make sense?

• No revocation path
  If a Verifier's key is compromised, a CA-issued certificate can be revoked via OCSP/CRL. A self-signed certificate has no revocation path. The only option is out-of-band redistribution, which is impractical and still imposes some of the risks below.

• Spoofing and downgrade attacks
  Self-signed certificates let a malicious Verifier present a signed request without a trust anchor enforcing constraints. A naive Wallet might even import the self-signed certificate from the request directly into its trust store. Certificate pinning could mitigate this, but at the cost of scalability and manageability.

• Scalability
  Without a CA, each Wallet must pin or fetch Verifier certificates out of band, effectively managing potentially thousands of certs. A registry of self-signed certs only shifts the problem and re-creates a pseudo-CA, but without PKI's policy and cryptographic assurances. Using a CA is the simpler approach.

• Lack of accountability
  CAs provide audits, issuance policies, and accountability. Self-signed certs remove this layer, leaving Verifiers to assert their own trustworthiness which is problematic in regulated or cross-border contexts.

• Risk of misuse
  Without CA-enforced policies, Verifiers may reuse keys across services, omit or misconfigure extensions, or set excessive lifetimes. CA policies enforce modern crypto, short validity, and appropriate key usage, reducing exposure.

• Operational security
  Self-issued certs may use weak algorithms, inappropriate key usage, or uncontrolled renewal practices. Even with defined crypto requirements (consider adding MTI crypto suites  #112), lifecycle and governance gaps remain.

[Sakurann]

to clarify, The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the signed request. has already been in the spec before but got lost

[tlodderstedt]

thanks @awoie these are good reasons to prohibit self signed certs in the HAIP.

[tlodderstedt]

I support the change given the fix @jogu asked for is applied.

[paulbastian]

Looks good to me, but agree that we should apply this to all occurrences of x5c

[charsleysa]

• No revocation path
  If a Verifier's key is compromised, a CA-issued certificate can be revoked via OCSP/CRL. A self-signed certificate has no revocation path. The only option is out-of-band redistribution, which is impractical and still imposes some of the risks below.
• Spoofing and downgrade attacks
  Self-signed certificates let a malicious Verifier present a signed request without a trust anchor enforcing constraints. A naive Wallet might even import the self-signed certificate from the request directly into its trust store. Certificate pinning could mitigate this, but at the cost of scalability and manageability.
• Scalability
  Without a CA, each Wallet must pin or fetch Verifier certificates out of band, effectively managing potentially thousands of certs. A registry of self-signed certs only shifts the problem and re-creates a pseudo-CA, but without PKI's policy and cryptographic assurances. Using a CA is the simpler approach.
• Lack of accountability
  CAs provide audits, issuance policies, and accountability. Self-signed certs remove this layer, leaving Verifiers to assert their own trustworthiness which is problematic in regulated or cross-border contexts.
• Risk of misuse
  Without CA-enforced policies, Verifiers may reuse keys across services, omit or misconfigure extensions, or set excessive lifetimes. CA policies enforce modern crypto, short validity, and appropriate key usage, reducing exposure.
• Operational security
  Self-issued certs may use weak algorithms, inappropriate key usage, or uncontrolled renewal practices. Even with defined crypto requirements (consider adding MTI crypto suites  #112), lifecycle and governance gaps remain.

Aren't these all effectively ecosystem policies? In many other parts of HAIP, ecosystems are left with responsiblity to supply policy which HAIP defers to. I don't see any of the above points being any different.

Unless there are specific interoperability concerns that are being addressed, I think it should be a recommendation with the ecosystem ultimately deciding if they want to allow self-signed certificates. Trust management is explicitly out of scope for HAIP.

There also seems to be the assumption that there are central CAs that will be responsible for oversight, however it is completely valid for each verifier to have their own CA. This comes down to ecosystem policy.

While I am not dead set against forbidding self-signed certificates, I do want to make sure it's not stepping into trust management territory without there being valid interopability concerns that are getting addressed.

[Sakurann]

@awoie please add this text to all occurrences of x5c in the specification

[c2bo]

Approved given the changes Joseph suggested (making sure this applies to all places that use x5c)

[charsleysa]

After WG discussion, there are better ways to solve concerns which rely on self-signed certificates. Prohibiting self-signed certificates doesn't impact trust management enough to be a meaningful reason to be against these changes. Happy with changes.

[jogu]

Consensus on WG call to merge this once the conflicts are resolved.