Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#4,590 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
go
Ambito
security

Direzione di ricerca

First review the behavior and policy alternatives in vcr/credential/validator.go, pki/validator.go, and docs/pages/deployment/certificates.rst, then record the chosen policy in this issue. Update the relevant validator, tests in vcr/credential/validator_test.go, documentation, and release notes so they agree; option B also involves pki/interface.go and mock regeneration.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

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

  • #3530: introduced CheckCRLStrict for did:x509
  • #3599: X509Credential validation
  • #4083: did:x509 resolver CRL check
Lingua principale
Go
Stelle
29
Fork
24
Merge medio
2g 18h
PR unite (30g)
45

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nuts-foundation/nuts-node

Tutte le issue di nuts-foundation/nuts-node

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.