did:x509: decide whether X509Credential CRL check should honour pki.softfail

[reinkrul]

Context

Follow-up to #3530, which introduced pki.Validator.CheckCRLStrict so that did:x509 chains could be checked with a hard-fail strategy regardless of pki.softfail. Noticed while reviewing where the node checks revocation of did:x509 credentials.

Problem

The code and the documentation disagree, and the strict variant is dead code.

• The only did:x509 CRL check, in x509CredentialValidator.Validate (vcr/credential/validator.go:321), calls CheckCRL, which follows pki.softfail (pki/validator.go:146-148).
• CheckCRLStrict (pki/validator.go:150) is referenced only from pki/interface.go:77 and the generated mock.
• docs/pages/deployment/certificates.rst:28-29 states: "For certificate chains used in did:x509 the Nuts-node always uses a hard-fail strategy, i.e., the pki.softfail config value is ignored during certificate validation for did:x509."

Actual behaviour with the default pki.softfail=true (pki/config.go:29):

Situation	Documented	Actual
Certificate in chain is revoked	Reject	Reject
CRL cannot be downloaded (ErrCRLMissing)	Reject	Accept, error log "Certificate CRL check softfail bypass"
Cached CRL older than pki.maxupdatefailhours (ErrCRLExpired)	Reject	Accept, error log
Denylist unavailable (ErrDenylistMissing)	Reject	Accept, error log

Either the code or the docs must change. Which one is a policy decision.

Proposal to discuss

Option A: hard-fail, as documented and as decided in #3530.
Change vcr/credential/validator.go:321 to CheckCRLStrict(chain). A did:x509 credential is rejected whenever a CRL in its chain is missing or stale, regardless of pki.softfail. Argument: for did:x509 the certificate chain is the root of trust of the credential, unlike a TLS connection where the CRL is one of several measures.

Option B: honour pki.softfail, as implemented.
Keep CheckCRL, remove CheckCRLStrict from pki.Validator, and rewrite the docs paragraph to say did:x509 follows pki.softfail with an error log on bypass. Argument: an unreachable CRL endpoint would otherwise take down every use case that relies on did:x509 credentials, and operators who want hard-fail can set pki.softfail=false. Downside: that flag also affects TLS validation, so there is no way to get hard-fail for did:x509 only.

Option C: separate knob.
Add a did:x509-specific setting, for example pki.didx509.softfail defaulting to false, and route it to checkCRL. Most flexible, one more config key.

Position: not taken here. The decision should be recorded in the issue before any PR is made.

Scope (either way)

• vcr/credential/validator.go and vcr/credential/validator_test.go, or pki/interface.go plus mock regeneration for option B
• docs/pages/deployment/certificates.rst:28-29
• Release notes, since option A changes behaviour for operators on the default pki.softfail=true

Considerations

• did:x509 resolver: CRL check and set expires/revoked on keys #4083 plans to move the CRL check from the validator into the did:x509 resolver and specifies CheckCRL(chain). The outcome of this decision applies to that location too.
• checkCRL never softfails on ErrUnknownIssuer, so unknown-issuer handling is unaffected by any option.

Related

• PKI: add method to perform strict validation for did:x509 regardless of configured softfail value #3530: introduced CheckCRLStrict for did:x509
• X509Credential validation #3599: X509Credential validation
• did:x509 resolver: CRL check and set expires/revoked on keys #4083: did:x509 resolver CRL check