Skip to content

CURATION.md

Latest commit

 

History

History
107 lines (82 loc) · 5.44 KB

CURATION.md

File metadata and controls

107 lines (82 loc) · 5.44 KB
Raw

Curation rules

This document defines which CA root certificates cacrt accepts and why. The rules are enforced in code (build_support/curation.rs, exercised by build.rs and the cacrt-tool verify command) and are intended to track current CA/Browser Forum and root-program best practice.

The source of truth for the trusted set is the collection of per-root PEM files in roots/. Those files are seeded from Mozilla NSS and then maintained by hand; this document explains the policy applied when deciding what belongs there.

Source

  • Roots are seeded from Mozilla's NSS certdata.txt root store — the de-facto trust store used by ca-certificates, curl, and most of the open Linux ecosystem.
  • certdata.txt is distributed by Mozilla under the Mozilla Public License 2.0. The certificates themselves are public data.

Acceptance rules

A certificate is included only if it passes all of the following. Rules 1, 3, 4 are machine-checkable and re-verified on every build / in CI.

  1. TLS server-auth trust anchor. The certificate must have an NSS trust record with CKA_TRUST_SERVER_AUTH = CKT_NSS_TRUSTED_DELEGATOR. Roots marked CKT_NSS_MUST_VERIFY_TRUST (e.g. e-mail/SMIME- or code-signing-only roots) are excluded — they are not trust anchors for TLS.

    Rationale: CA/Browser Forum Baseline Requirements and the browser root programs scope trust by purpose; a root trusted only for S/MIME must not be a TLS anchor.

  2. No active phase-out. Certificates carrying NSS CKA_NSS_SERVER_DISTRUST_AFTER (a graceful server-auth distrust date) are excluded.

    Rationale: a distrust-after date is the root programs signalling that the CA is being wound down for TLS. A curated, forward-looking store should not ship anchors already on the way out. See CHANGELOG-roots.md for the specific roots this removes.

  3. Not expired. Certificates whose notAfter is in the past at build / verification time are excluded.

    Rationale: an expired root is dead weight and can mask configuration errors.

  4. Adequate key strength. RSA keys must be ≥ 2048 bits; ECC keys must be on P-256, P-384, or P-521. DSA and unrecognized key algorithms are excluded.

    Rationale: CA/Browser Forum BR §6.1.5 minimum key sizes; DSA is obsolete for the Web PKI.

  5. Self-signature algorithm is recorded but NOT used to exclude. A root's own self-signature may use SHA-1 and the root is still eligible.

    Rationale: a root's self-signature is not validated by relying parties — trust comes from the root being in the store, not from its signature. The SHA-1 prohibition in the BRs and root-program policies applies to subscriber and intermediate certificates, not to root self-signatures. Excluding SHA-1 self-signed roots would wrongly drop many still-trusted, widely-deployed roots.

  6. Explicit deny list. Specific CAs may be excluded beyond the above via a documented deny list (DENY_LABEL_SUBSTRINGS in build_support/curation.rs). Mozilla already removes fully-distrusted CAs from certdata.txt, so this list is for deliberate, additional removals. Every entry must have a matching note in CHANGELOG-roots.md. The list is currently empty.

  7. Dedicated-TLS preference (guidance, not auto-enforced). Modern root programs (notably the Chrome Root Program) favor hierarchies dedicated to TLS server authentication. This cannot be fully derived from certdata.txt, so it is applied as reviewer guidance when adding roots rather than a hard automated gate.

Disabling a root

To retire a root we have already shipped, rename its .pem file to .disabled (e.g. Buypass_Class_3_Root_CA.pem → Buypass_Class_3_Root_CA.disabled). The build only compiles *.pem, so a .disabled file is excluded from the generated store — but it stays in the repository, preserving the certificate itself, its company README.md, and the recorded rationale. This keeps the audit trail intact (we can always see what was once trusted and why it was dropped) without deleting history. Record every such change in CHANGELOG-roots.md, and add a status banner to the company's README.md.

Typical reasons to disable rather than keep a root: the CA has stopped issuing TLS certificates and all of its end-entity certificates have since expired (so the anchor can no longer serve any live chain), or a root program has distrusted it.

Auditability

Every addition or removal of a root is recorded in CHANGELOG-roots.md with a date and a reason, so the provenance of the trusted set is reviewable over time.

References