[sinkog]

Refs #164

What

checkRevocation accepted any CRL whose issuer name matched: nothing verified the signature or NextUpdate, an unparsable CRL was only logged, and in prod no CRL was ever loaded (bootstrapPKI read CIC_PLATFORM_CA_BUNDLE for certificates only), so revocation was inert in both modes.

• cabinet.VerifyCRLSignature: a CRL must verify against a CA certificate of the trust store. One that does not is never used, in any mode.
• cabinet.CRLFreshness / VerifyOptions.CRLFreshness / CheckCRLFresh: a CRL past NextUpdate (or without one) is rejected at verification time when the rule is set, so a CRL that goes stale while the relay runs stops being trusted. A nil rule keeps the old behaviour (dev).
• prod: CRLs travel as X509 CRL blocks in CIC_PLATFORM_CA_BUNDLE; an unparsable, unauthenticated or stale CRL is a start-up error. CIC_CRL_MAX_STALENESS sets an explicit grace (default none; an invalid value is a start-up error).
• dev stays lenient: a bad signature drops the CRL with a warning; an unparsable or stale CRL is logged.
• prod states what is off: "no CRL in the bundle" and "SPKI pin set is empty" are logged as warnings.
• context/SYMBOLS.md and MANIFEST.sha256 regenerated (3 new exported symbols); the CI manifest diff is empty locally.

Claim check against the issue

Confirmed: no signature or freshness check, unparsable CRL only warned, empty CRL set and empty pin set both pass. Additions the issue did not state: prod never loaded a CRL at all, and PinnedSPKIs is never populated in production code (pinning has no configuration source, not just an empty default).

Not done

"A missing CRL for a configured issuer is an error" needs a way to say which issuers require a CRL; none exists, and a root CA without a CRL is legitimate. Either a separate setting or "every CA in a prod bundle needs a CRL" would do it; that is a decision for the owner. Until then the absence is a visible warning, not an error. No SPKI pin source was added.

Tests

With the old behaviour emulated under the new API (signature and freshness checks off, prod not loading CRLs), these fail: TestBootstrapPKI_Prod_CRL_ForeignKeySignature_Error, TestLoadPKIAssets_Dev_CRL_ForeignKeySignature_NotUsed, ..._UnknownIssuer_Error, ..._Stale_Error, ..._InvalidTolerance_Error, ..._CRL_Unparsable_Error, ..._RevokedLeafStaysRejectedAfterRestart, ..._NoCRL_NoPins_AreVisible, TestVerifyCRLSignature, TestCheckCRLFresh, TestVerifyCertificateChain_StaleCRL. TestCrlToleranceFromEnv is characterization only (new function).

"Restart" in the revoked-leaf test means loading the same bundle twice, not a process restart.

Local gates (Docker golang:1.26.11): gofmt -s -l empty, go vet ./... clean, staticcheck (cabinet, cmd/relay) clean, go test -count=1 ./... all ok, no new entry in deadcode ./..., scripts/gen_manifest.sh diff empty.

Reachability

cmd/relay/main.go:694 bootstrapPKI -> prod branch -> parseBundleCRLs / acceptCRLs (cmd/relay/pki_crl.go) -> cabinet.VerifyCRLSignature / CheckCRLFresh. Verification: cmd/relay/bootstrap.go:78, :554, cmd/relay/pki_companion.go:78 pass CRLFreshness into cabinet.VerifyCertificateChain -> checkRevocation.

Notes

• Existing prod bundles without CRL blocks keep starting (warning only).
• feat(cabinet): report whether the ProofTrace was persisted, and allow requiring it #177 and this PR both change context/SYMBOLS.md and the SYMBOLS.md line of MANIFEST.sha256; after the second merge both need regenerating (symbolsgen, scripts/gen_manifest.sh), not a manual merge.
• Docs for CIC_CRL_MAX_STALENESS are not added to the env tables: fix(relay): require an explicit CIC_TRUST_MODE and guard prod against an unloaded trust store #176 and feat(cabinet): report whether the ProofTrace was persisted, and allow requiring it #177 edit the adjacent rows. Follow-up after those merge.
• main() was not run; the prod branch is covered by bootstrapPKI tests.
• The commit carries the developer's Vault signing metadata, added by a global commit hook. No workflow or CI files are touched.

🤖 Generated with Claude Code