Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,590 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go
Área
security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Go
Estrellas
29
Forks
24
Merge medio
2 d 18 h
PR fusionados (30 d)
45

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nuts-foundation/nuts-node

Todos los issues de nuts-foundation/nuts-node

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.