@blamejs/pki 0.8.21 → 0.8.23

package/CHANGELOG.md

@@ -4,6 +4,42 @@ All notable changes to `@blamejs/pki` are documented here. The format
 follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this
 project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## v0.8.23 — 2026-09-24
+
+A root program's requirement is graded by the clause that states it, so the same key purpose is a warning in one place and an error in another.
+
+### Added
+
+- `pki.lint.certificate(der, { profile: "chrome-root" })` runs the Chrome Root Program Policy v1.8 profile. Naming it is the only way to reach these rows, and passing no profile leaves every one of them inert.
+- The section 1.3.2 rules for a subordinate CA certificate, which the policy states as two admitted forms, `id-kp-serverAuth` alone or `id-kp-serverAuth` with `id-kp-clientAuth`. Both forms require the extKeyUsage extension and require `id-kp-serverAuth` in it, and neither admits any other purpose, so those three are errors and `anyExtendedKeyUsage` is reported among the others. Each offending purpose draws its own finding naming that purpose. The second form is open only where the certificate was disclosed to the CCADB before 15 June 2026, which a certificate does not carry, so `id-kp-clientAuth` is reported as a warning whose message names the date that settles it.
+- Those four rows reach the unexpired subordinate CA certificates the clause names, so a certificate whose notAfter precedes 15 June 2026 is passed over: the phase-out begins that day and the certificate was not among the unexpired ones then. They do reach a branch serving another purpose, which is the point of the section rather than an overreach, since it governs every subordinate CA certificate beneath a root in the store and exists to phase out the multi-purpose hierarchies. Whether a certificate is revoked is not in the bytes and stays outside the reading.
+- The same section's rule for a subscriber certificate, which admits `id-kp-serverAuth` alone and is gated on issuance rather than disclosure. The three rows are silent on a certificate whose notBefore precedes 15 March 2027 and report on the same bytes after it, and `id-kp-clientAuth` is an error there rather than the warning it draws on a subordinate CA. A subscriber certificate is not every end entity: a delegated OCSP responder has its own profile in the Baseline Requirements that section 1.1.1 binds, asking for `id-kp-OCSPSigning` and no other purpose, so a certificate whose extKeyUsage names that purpose and nothing else is passed over. One naming it beside others is not a responder under that profile and is read here as the subscriber certificate it is.
+- The section 1.3.1.3 ceiling of three years on a subordinate CA certificate's validity period, reported as a warning at the strength the clause states it. A ceiling given in years is measured in months, so a 29 February notBefore clamps to 28 February rather than moving into March.
+- The section 1.3.1.2 root CA term limit. The clause determines the age of key material from the earliest certificate that carries the key, and a self-signed root's own notBefore is at or after that date. The schedule is monotone, so the removal date computed from notBefore is the latest one the schedule can give, and a notAfter past it runs beyond the term whatever earlier certificate exists. The finding names a self-signed CA certificate rather than a root, which is as far as the bytes reach: a CA outside any store issues itself one of these during its own key rollover and it matches a root in every field. What the finding says is that if this certificate is a root in the store the caller named, its term ends before its validity does, and the notice grade is that conditional. It carries the removal date.
+- Matching issuer and subject names make a certificate self-issued, which is not the same as self-signed: a CA reissued in its own name under a new key carries the same two names and was signed by its predecessor. The term limit governs a root, so it reads the key identifiers as well, and passes over a certificate whose authorityKeyIdentifier names a key other than its own subjectKeyIdentifier. A certificate that omits the extension, or names its own key in it, is held to the clause. A keyIdentifier with no readable subjectKeyIdentifier beside it settles nothing, and the row rests on settling it, so that reads as not a root too. What remains outside that reading is a reissued CA carrying no authorityKeyIdentifier keyIdentifier at all, which RFC 5280 section 4.2.1.1 permits only in a self-signed certificate and which the `rfc5280` profile reports on its own row.
+- A subordinate CA is a role in a hierarchy rather than something a certificate states, so the rows that govern one read the certificate's own issuer and subject names and pass over a certificate issued in its own name. Section 1.3.1.1 requires a cross-certificate from a root to its replacement, which carries one name in both fields, so those rows under-report rather than reporting a succession certificate for the extended key usage a root does not need.
+
+### Changed
+
+- `pki.lint.rules()` enumerates the new rows, which stay inert under the default rule set because each one asks whether the caller named the profile.
+
+## v0.8.22 — 2026-09-24
+
+An algorithm identifier is compared as the bytes a root program fixed, not as the algorithm it names.
+
+### Added
+
+- `pki.lint.certificate(der, { profile: "mozilla-root" })` runs the Mozilla Root Store Policy v3.1 profile. Naming it is the only way to reach these rows, and passing no profile leaves every one of them inert.
+- The section 5.1 algorithm encodings, compared as DER: a subjectPublicKeyInfo AlgorithmIdentifier must be one of the four the policy writes out, for RSA and for NIST P-256, P-384 and P-521, and a signature AlgorithmIdentifier one of the ten, covering RSASSA-PKCS1-v1_5, RSASSA-PSS at its matching mask and salt lengths, and ECDSA. Only one of a certificate's two algorithm fields is read, because the parser already refuses a certificate whose outer `signatureAlgorithm` differs from `tbsCertificate.signature`.
+- An RSA modulus must be at least 2048 bits and a whole number of octets, and a public exponent of 1 is reported as the unusable key the policy names. An EdDSA key is admitted only in a certificate carrying `id-kp-emailProtection`, and is exempt from the encoding rows, since the policy gives no EdDSA encoding to hold it to. An EdDSA signature is exempt for the same reason and on the issuer's behalf: a permitted EdDSA intermediate signs with that key, and reporting the certificates it signs would fail them for a key they do not carry.
+- The section 5.1.3 SHA-1 prohibitions, each gated to the date it carries: from 1 July 2022 over an end entity certificate carrying `id-kp-emailProtection`, and from 1 July 2023 over a certificate carrying `id-kp-OCSPSigning` or over an intermediate certificate. That clause names intermediates rather than certificate authorities, so a root's own self-signature is not one of the four things it lists. The clause also allows SHA-1 over an end entity only where a list of conditions all hold, so a certificate carrying no extKeyUsage, or one naming `id-kp-serverAuth` or `anyExtendedKeyUsage`, is reported as outside that allowance. Its remaining conditions name the issuing certificate and the Baseline Requirements scope, which are not in these bytes.
+- The section 5.2 practices a certificate's own bytes answer for: an extKeyUsage extension on every end entity certificate with no `anyExtendedKeyUsage` in it, and a serial number greater than zero. The rest of that sentence asks for at least 64 bits of CSPRNG output, which constrains the draw rather than the integer, and a DER INTEGER drops the leading zero octets a draw produces: eight random octets beginning with zero encode to seven of magnitude, which a conforming certificate does about once in 256. So a short magnitude is reported as a warning and the positive-serial half as an error, each at the strength its own clause supports.
+- The section 5.3 rules for intermediate certificates created after 1 January 2019, gated to that date: an extKeyUsage extension is required, `anyExtendedKeyUsage` is not permitted, and `id-kp-serverAuth` and `id-kp-emailProtection` may not appear together. Being an intermediate is a role in a hierarchy that a certificate does not state, so these three read the one thing the bytes give and pass over a certificate issued in its own name. That is every root, which the clause does not govern, and it is also a rollover intermediate reissued in its own name, which the clause does govern, so the three under-report rather than reporting a root for carrying no extended key usage.
+
+### Changed
+
+- `pki.lint.rules()` enumerates the new rows, which stay inert under the default rule set because each one asks whether the caller named the profile.
+
 ## v0.8.21 — 2026-09-24
 
 A qualified certificate is linted against the statements it carries, not just their syntax.

package/README.md

@@ -290,7 +290,7 @@ comment blocks, is at [pkijs.com](https://pkijs.com).
 | `pki.sigstore` | Offline verifier for a Sigstore bundle, the artifact `npm publish --provenance` produces and the registry serves. `verifyBundle` composes five fail-closed legs against caller-pinned trust (Fulcio CA roots and Rekor log keys, never trusted from the bundle): the DSSE signature over its PAE preimage under the Fulcio leaf key, the ephemeral Fulcio certificate chain validated as of the Rekor log time, the RFC 9162 inclusion proof folded to a Rekor-signed tree root, the log entry bound to this exact signature, and the in-toto SLSA subject digest the caller confirms against the published artifact. It reuses the X.509 parser, the RFC 5280 path validator, and the Merkle verifier; the net-new codecs are the DSSE PAE byte-builder and a fail-closed JSON reader. `verified: true` says the artifact was signed and logged, not that a party you trust signed it — Fulcio issues to anyone who completes an OIDC flow, so who signed is decided only by `opts.identity`, and `identityChecked` reports which of its fields were compared. An identity policy naming no field, or a field name that is not one of the three, is refused rather than satisfied — either would accept every signer while reading as a policy in force. A sixth leg is opt-in: pinning the certificate-transparency logs in `opts.ctLogs` checks the receipt Fulcio embeds in the certificate it issues (RFC 6962 §3.2), verified over the certificate as it stood before the receipt was added and under the key of the log that issued it, so the verdict says the signing certificate was public when it was issued rather than handed out quietly. At least one receipt must verify against a pinned log, the verdict reports `sctChecked` and `validScts`, and an empty log set is refused rather than read as a policy that checks nothing. Both content arms are read: a DSSE-wrapped in-toto attestation, and a message signature over an artifact's own bytes, which `cosign sign-blob` produces. For that arm `opts.artifact` supplies the bytes, and they are held to the hash the Rekor `hashedrekord` entry records before the signature is checked over them; the `messageDigest` the bundle carries is covered by no signature, so it is compared against the computed digest and never used in its place. `contentType` names the arm and the verdict has one shape for both — `pae`, `parseBundle`, `verifyBundle` |
 | `pki.inspect` | Human-readable inspection, the pure-JS equivalent of `openssl x509/crl/req/cms -text`. `certificate(pem \| der \| parsed)` renders an OpenSSL-style report: version, serial, signature algorithm, issuer and subject distinguished names, validity, public-key details (curve or modulus size plus the raw point or modulus), every decoded extension with its critical flag, and the signature. `crl`, `csr`, and `cms` render the other formats the same way — a CRL like `openssl crl -text`, a CSR like `openssl req -text`, and a CMS message like `openssl cms -cmsout -print`, with a stable summary for a non-SignedData ContentInfo — and `any(input)` detects the format and routes to the right report. Built over the strict parsers and the two-way OID registry with one set of field renderers, it names extension and algorithm OIDs an OpenSSL build shows only as raw bytes. No OpenSSL dependency, and the format is stable and OpenSSL-familiar rather than pinned to one OpenSSL version. A certificate policy's user notice renders as text, both its explicit text and a notice reference with the notice numbers that identify it, rather than hex, and a malformed part falls back to a hex dump rather than throwing — `certificate`, `crl`, `csr`, `cms`, `any` |
 | `pki.webauthn` | WebAuthn and passkey verification, both halves: offline trust evaluation of a W3C WebAuthn (Level 3) registration, and signature verification of the assertion every login returns. `parseAttestationObject(bytes)` decodes the CBOR attestation object, authenticatorData, and COSE credential key over the strict `pki.cbor` codec; `parseAuthenticatorData(bytes)` reads the bare form an assertion carries through the same parser; `parseClientData(bytes, opts)` decodes the `clientDataJSON` no signature check looks inside, through the shared JSON guard since these are attacker-chosen bytes, returning the challenge decoded so a caller compares bytes rather than spellings, and checking the ceremony type, challenge, and origin when the relying party supplies what it issued. `verifyAssertion(input)` verifies an assertion signature over `authenticatorData \|\| SHA-256(clientDataJSON)` — raw bytes, no COSE_Sign1, an ES256 signature in ASN.1 DER — and applies the §7.2 step 21 counter rule when a stored `previousSignCount` is given, so a counter that fails to advance is refused as a cloned authenticator. `verify(attestationObject, clientDataHash, opts)` checks the attestation-statement signature and each format's structural bindings for packed, tpm, android-key, apple, fido-u2f, and none: the x5c leaf key, the apple nonce, the tpm `certInfo` Name and `extraData` over the `pubArea`, the android `KeyDescription`, and the fido-u2f `verificationData`. It binds the credential public key to each attestation, through the signed authenticatorData for packed and fido-u2f or a cert or `pubArea`-key equality check for android-key, apple, and tpm, and enforces each leaf's certificate requirements. The credential-key check covers the full WebAuthn COSE algorithm set — ES256/384/512, RS256/384/512, PS256/384/512, EdDSA (Ed25519), and the RFC 9864 fully-specified identifiers ESP256/384/512, Ed25519, and Ed448 — validating the public-key point on its curve, rejecting the compressed EC point form, and enforcing a minimally encoded DER ECDSA signature. The verdict field is `attestationVerified`, and `signatureVerified` for an assertion, rather than a bare `verified`, because a sound statement is a different claim from an acceptable ceremony: an attestation naming another origin's RP ID with user presence clear is perfectly sound and must not be registered. Pass `expectedRpId`, `requireUserPresence`, `requireUserVerification`, or `allowedAlgorithms` and those are checked, with `bindingChecked` reporting which ran, so a check that passed can be told from one that never happened. Pass `opts.clientDataJSON` instead of the digest and the client data is read here too: the ceremony type is checked unconditionally, since a login response replayed into a registration is what that rule stops, and the challenge, origin, and top-level origin are checked against what the relying party issued, with `clientData.checked` reporting which comparisons ran. A registration verdict also carries the `credentialId`, `credentialPublicKey`, and initial `signCount` a later login needs. A credential key declaring COSE algorithm `-65535` (RSASSA-PKCS1-v1_5 with SHA-1) is refused unless `allowedAlgorithms` names it, since every signature that credential ever makes would use SHA-1. Anchoring the trust path has two routes: `opts.metadata` resolves the roots the authenticator's own model registered, and `opts.rootCertificates` pins roots directly, which is what anchors the formats FIDO MDS does not cover, Apple's authenticators and the Google hardware-attestation roots among them. `metadata` governs when both are given, and `anchoredTo` names every route that anchored the path, joined with `+` when more than one did: `"metadata"`, `"rootCertificates"`, and `"safetyNetRoots"` for the android-safetynet chain, which anchors through the roots that format requires whether or not either other route was asked for. It is `null` only when nothing anchored the path. `verifyMetadataBlob(blob, opts)` reads a FIDO Metadata Service (MDS v3) BLOB, the signed catalogue of registered authenticator models, verifying its JWS and chaining its signer to an operator-supplied FIDO root before the payload is parsed, with sequence-number rollback and `nextUpdate` freshness checks. Passing the result as `opts.metadata` to `verify` resolves the authenticator's registered attestation roots from its identifier and requires the trust path to fully validate to one of them, refusing an unlisted or revoked model. `metadataAnchors(entry, opts)` applies the same status gate for a caller anchoring the path themselves: a model the catalogue has disqualified registers no anchors. Both of the catalogue's key spaces are covered: an aaguid, and the attestation-certificate key identifiers a U2F authenticator is listed under instead. No FIDO root is bundled, there is no trust-on-first-use, and retrieving the BLOB is out of scope. Fail-closed with typed `webauthn/*` errors — `parseAttestationObject`, `verify`, `verifyMetadataBlob`, `metadataFor`, `metadataAnchors` |
-| `pki.lint` | Certificate linting, the zlint or pkilint of JavaScript. `certificate(pem \| der \| parsed, opts)` walks a parsed certificate and emits graded advisory findings, each with a stable id, a severity (`fatal`, `error`, `warn`, `notice`), a source, a spec-clause citation, and a message, against the RFC 5280 profile, the post-quantum certificate profiles, and a representative CA/Browser Forum TLS BR subset: serial sign and size, validity ordering and the SC081v3 reducing validity schedule, keyCertSign coherence, extension criticality (basicConstraints, nameConstraints, policyConstraints and inhibitAnyPolicy must be critical, and keyUsage should be), nameConstraints CA-scope, unknown critical extensions, empty-subject SAN, SKI and AKI presence including the end-entity subjectKeyIdentifier, the six extensions a conforming CA must mark non-critical (reported by clause rather than as unrecognized) and the two it should (issuerAltName, cRLDistributionPoints), a policy mapping to or from anyPolicy, a unique identifier a conforming CA must not generate, a critical subjectAltName beside a non-empty subject, a critical extKeyUsage naming anyExtendedKeyUsage, a userNotice noticeRef, SAN required and CN-in-SAN, dNSName syntax, serverAuth EKU, weak keys, the CA/Browser Forum subscriber certificate profile of §7.1.2.7 (the extension presence and criticality table, the authorityInformationAccess accessMethod and accessLocation tables, basicConstraints cA and pathLenConstraint, certificatePolicies against anyPolicy and the exactly-one reserved identifier rule and the permitted-qualifier table, the forbidden extended key purposes, the two Key Usage tables that differ by key type, and the subjectAltName GeneralName table with its criticality rule in both directions), the CA/Browser Forum S/MIME BR subscriber profile of §7.1.2.3 (a) through (n) as `cabf-smime`, whose requirements follow the generation a certificate declares through its reserved policy identifier (the distribution-point and accessMethod URI scheme rules, the policy qualifier rules for an id-qt-cps URL and an id-qt-unotice explicitText and noticeRef, the key-usage table for the certificate's own key algorithm including a bit set past the nine named positions, the extended key purposes forbidden at every generation and the ones Strict alone forbids, the authorityKeyIdentifier field rules, a required mailbox in the subjectAltName as an rfc822Name or an id-on-SmtpUTF8Mailbox otherName, the criticality each extension must carry, the subjectDirectoryAttributes and Adobe extensions the Strict generation prohibits, the Legal Entity Identifier extensions keyed on the certificate type rather than the generation, and the Legacy generation retired on 15 July 2025), the CA/Browser Forum Code Signing BR subscriber profile of §7.1.2.3 as `cabf-cs`, whose rows follow the kind a certificate declares through one of the three reserved identifiers of §7.1.6.1 (the extension presence and criticality rules at the strengths this document states them, a HTTP URL required in the distribution points and in each accessMethod location, a critical keyUsage asserting digitalSignature with `keyCertSign` and `cRLSign` forbidden and every other bit discouraged, the extended key purpose each kind must carry with the critical extKeyUsage a timestamp certificate needs, the §7.1.6.4 exactly-one-identifier rule gated to 15 September 2026, the §6.3.2 ceilings of 39 months, 460 days and 135 months, and the §6.1.5.2 floors of a 3072-bit RSA modulus, NIST P-256, P-384 or P-521, or DSA parameters of 2048 bits with a 224- or 256-bit modulus length, and the §7.1.4.2 subject distinguished name rows: a required commonName, a prohibited domainComponent, a subject attribute made only of the metadata characters the clause names, a required organizationName and two-letter countryName, one of localityName and stateOrProvinceName, and on an EV certificate a businessCategory from the four strings the clause names, a jurisdictionCountryName and a serialNumber), the ETSI qualified-certificate profile of EN 319 412-5 as `etsi-qc` (a non-critical qcStatements extension, a QcType naming one and only one of the three purposes the clause defines, a QcPDS providing an https URL and, on an EU qualified certificate, a document in English and no more than one per language, plus the EN 319 412-1 semantics identifiers holding a subject serialNumber or organizationIdentifier to a three-character identity type reference, a two-character country code, a hyphen-minus and an identifier, with XG required of an LEI value and a name registration authority URI required of a locally defined reference), the post-quantum key-usage rules binding a certificate's keyUsage bits to its subject key type (ML-KEM under RFC 9935 §5, ML-DSA under RFC 9881 §5, and SLH-DSA under RFC 9909 §6 across both its pure and prehash identifiers) together with the ML-KEM encapsulation-key encoding and size, and the §4.2.1.4 certificate-policy user-notice rules (a VisibleString or BMPString explicitText, a notice past 200 characters, an empty notice, control characters, and a non-NFC UTF8String notice, each at the strength the clause states). Alone among these entries the data path never throws: hostile bytes return a `fatal` `lint/unparseable` finding carrying the strict parser's code, so a whole directory lints without a try/catch, and only config-time misuse throws a typed `LintError` — `certificate`, `crl` (the RFC 5280 §5 revocation-list profile: nextUpdate presence, update ordering, cRLNumber presence and its 20-octet ceiling, authorityKeyIdentifier presence, the criticality each profiled CRL and entry extension must carry, freshestCRL in a delta CRL, and unrecognized critical extensions), `ocsp` (the RFC 6960 response profile: an empty signature, each SingleResponse's update ordering and its relation to producedAt, an empty `certs` field, the extended revoked definition and the fixed shape of a revoked answer for a non-issued certificate, the list each extension belongs in, the criticality and value syntax of the CRL entry extensions a SingleResponse may carry, unrecognized critical extensions, the reasons unspecified and removeFromCRL, and two answers for one CertID; the RFC 5019 lightweight rows run on request), `csr` (the artifact a CA reads before it issues: an empty subject naming no identity, an empty subject whose subjectAltName is not critical, a request for an extension the issuer determines, a request asking for a CA certificate, a broken signing digest, and a challengePassword traveling with the request; `opts.profile: "cabf-tls"` adds the certificate profile's own commonName-in-SAN, dNSName syntax, SAN-required and key-strength rows, applied to what the request asks for, and they run only when named because a request carries no extKeyUsage. It does not check the request's signature, which is a cryptographic operation `pki.csr.verify` owns), `rules`, `profiles` |
+| `pki.lint` | Certificate linting, the zlint or pkilint of JavaScript. `certificate(pem \| der \| parsed, opts)` walks a parsed certificate and emits graded advisory findings, each with a stable id, a severity (`fatal`, `error`, `warn`, `notice`), a source, a spec-clause citation, and a message, against the RFC 5280 profile, the post-quantum certificate profiles, and a representative CA/Browser Forum TLS BR subset: serial sign and size, validity ordering and the SC081v3 reducing validity schedule, keyCertSign coherence, extension criticality (basicConstraints, nameConstraints, policyConstraints and inhibitAnyPolicy must be critical, and keyUsage should be), nameConstraints CA-scope, unknown critical extensions, empty-subject SAN, SKI and AKI presence including the end-entity subjectKeyIdentifier, the six extensions a conforming CA must mark non-critical (reported by clause rather than as unrecognized) and the two it should (issuerAltName, cRLDistributionPoints), a policy mapping to or from anyPolicy, a unique identifier a conforming CA must not generate, a critical subjectAltName beside a non-empty subject, a critical extKeyUsage naming anyExtendedKeyUsage, a userNotice noticeRef, SAN required and CN-in-SAN, dNSName syntax, serverAuth EKU, weak keys, the CA/Browser Forum subscriber certificate profile of §7.1.2.7 (the extension presence and criticality table, the authorityInformationAccess accessMethod and accessLocation tables, basicConstraints cA and pathLenConstraint, certificatePolicies against anyPolicy and the exactly-one reserved identifier rule and the permitted-qualifier table, the forbidden extended key purposes, the two Key Usage tables that differ by key type, and the subjectAltName GeneralName table with its criticality rule in both directions), the CA/Browser Forum S/MIME BR subscriber profile of §7.1.2.3 (a) through (n) as `cabf-smime`, whose requirements follow the generation a certificate declares through its reserved policy identifier (the distribution-point and accessMethod URI scheme rules, the policy qualifier rules for an id-qt-cps URL and an id-qt-unotice explicitText and noticeRef, the key-usage table for the certificate's own key algorithm including a bit set past the nine named positions, the extended key purposes forbidden at every generation and the ones Strict alone forbids, the authorityKeyIdentifier field rules, a required mailbox in the subjectAltName as an rfc822Name or an id-on-SmtpUTF8Mailbox otherName, the criticality each extension must carry, the subjectDirectoryAttributes and Adobe extensions the Strict generation prohibits, the Legal Entity Identifier extensions keyed on the certificate type rather than the generation, and the Legacy generation retired on 15 July 2025), the CA/Browser Forum Code Signing BR subscriber profile of §7.1.2.3 as `cabf-cs`, whose rows follow the kind a certificate declares through one of the three reserved identifiers of §7.1.6.1 (the extension presence and criticality rules at the strengths this document states them, a HTTP URL required in the distribution points and in each accessMethod location, a critical keyUsage asserting digitalSignature with `keyCertSign` and `cRLSign` forbidden and every other bit discouraged, the extended key purpose each kind must carry with the critical extKeyUsage a timestamp certificate needs, the §7.1.6.4 exactly-one-identifier rule gated to 15 September 2026, the §6.3.2 ceilings of 39 months, 460 days and 135 months, and the §6.1.5.2 floors of a 3072-bit RSA modulus, NIST P-256, P-384 or P-521, or DSA parameters of 2048 bits with a 224- or 256-bit modulus length, and the §7.1.4.2 subject distinguished name rows: a required commonName, a prohibited domainComponent, a subject attribute made only of the metadata characters the clause names, a required organizationName and two-letter countryName, one of localityName and stateOrProvinceName, and on an EV certificate a businessCategory from the four strings the clause names, a jurisdictionCountryName and a serialNumber), the ETSI qualified-certificate profile of EN 319 412-5 as `etsi-qc` (a non-critical qcStatements extension, a QcType naming one and only one of the three purposes the clause defines, a QcPDS providing an https URL and, on an EU qualified certificate, a document in English and no more than one per language, plus the EN 319 412-1 semantics identifiers holding a subject serialNumber or organizationIdentifier to a three-character identity type reference, a two-character country code, a hyphen-minus and an identifier, with XG required of an LEI value and a name registration authority URI required of a locally defined reference), the Mozilla Root Store Policy as `mozilla-root`, which is named rather than detected because a root program's requirements apply by virtue of the store a certificate chains to (the §5.1 AlgorithmIdentifier encodings compared as DER, an RSA modulus of at least 2048 bits and a whole number of octets, a public exponent above 1, an EdDSA key only beside id-kp-emailProtection, the §5.1.3 SHA-1 prohibitions on their own dates, a serial greater than zero with a short magnitude reported as a warning, an extKeyUsage on every end entity without anyExtendedKeyUsage, and the §5.3 intermediate rules from 2019, which pass over a certificate issued in its own name), the Chrome Root Program Policy v1.8 as `chrome-root`, named on the same grounds (the §1.3.2 dedicated-hierarchy rules holding a subordinate CA certificate's extKeyUsage to id-kp-serverAuth with id-kp-clientAuth reported as a warning, scoped to the unexpired certificates the clause names by passing over a notAfter before 15 June 2026, the same rules over a subscriber certificate issued on or after 15 March 2027 where id-kp-serverAuth stands alone and an extKeyUsage naming id-kp-OCSPSigning and nothing else is a delegated OCSP responder rather than a subscriber, the §1.3.1.3 three-year subordinate CA validity ceiling, and the §1.3.1.2 root term limit, which reports a self-signed CA certificate whose validity runs past the removal date its own notBefore fixes and passes over a CA reissued in its own name whose authorityKeyIdentifier names a key other than its own subjectKeyIdentifier), the post-quantum key-usage rules binding a certificate's keyUsage bits to its subject key type (ML-KEM under RFC 9935 §5, ML-DSA under RFC 9881 §5, and SLH-DSA under RFC 9909 §6 across both its pure and prehash identifiers) together with the ML-KEM encapsulation-key encoding and size, and the §4.2.1.4 certificate-policy user-notice rules (a VisibleString or BMPString explicitText, a notice past 200 characters, an empty notice, control characters, and a non-NFC UTF8String notice, each at the strength the clause states). Alone among these entries the data path never throws: hostile bytes return a `fatal` `lint/unparseable` finding carrying the strict parser's code, so a whole directory lints without a try/catch, and only config-time misuse throws a typed `LintError` — `certificate`, `crl` (the RFC 5280 §5 revocation-list profile: nextUpdate presence, update ordering, cRLNumber presence and its 20-octet ceiling, authorityKeyIdentifier presence, the criticality each profiled CRL and entry extension must carry, freshestCRL in a delta CRL, and unrecognized critical extensions), `ocsp` (the RFC 6960 response profile: an empty signature, each SingleResponse's update ordering and its relation to producedAt, an empty `certs` field, the extended revoked definition and the fixed shape of a revoked answer for a non-issued certificate, the list each extension belongs in, the criticality and value syntax of the CRL entry extensions a SingleResponse may carry, unrecognized critical extensions, the reasons unspecified and removeFromCRL, and two answers for one CertID; the RFC 5019 lightweight rows run on request), `csr` (the artifact a CA reads before it issues: an empty subject naming no identity, an empty subject whose subjectAltName is not critical, a request for an extension the issuer determines, a request asking for a CA certificate, a broken signing digest, and a challengePassword traveling with the request; `opts.profile: "cabf-tls"` adds the certificate profile's own commonName-in-SAN, dNSName syntax, SAN-required and key-strength rows, applied to what the request asks for, and they run only when named because a request carries no extKeyUsage. It does not check the request's signature, which is a cryptographic operation `pki.csr.verify` owns), `rules`, `profiles` |
 | `pki.C` / `pki.constants` | Version-stable constants: the functional scale helpers `C.TIME.*` and `C.BYTES.*`, the codec `LIMITS`, and `version` |
 | `pki.errors` | The `PkiError` taxonomy — `defineClass` plus `ConstantsError`, `Asn1Error`, `OidError`, `PemError`, `CertificateError`, `CrlError`, `CsrError`, `Pkcs8Error`, `CmsError`, `OcspError`, `TspError`, `AttrCertError`, `CrmfError`, `Pkcs12Error`, `CmpError`, `PathError`, `CtError`, `JoseError`, `AcmeError`, `WebauthnError`, and `LintError`, each carrying a stable `code` in `domain/reason` form |
 | `pki` CLI | `pki version`, `pki oid <dotted\|name>`, `pki parse <cert>`, `pki inspect <cert>`, `pki lint <cert\|crl\|ocsp-response>`, `pki convert <file> --to der\|pem`, `pki verify <cert>... --anchor <cert>`, `pki sign <file> --cert <c> --key <k>` |

package/lib/lint.js

@@ -272,6 +272,17 @@ function _rsaModulusBits(spki) {
     return mod.toString(2).length;
   } catch (_e) { return null; }
 }
+/** @internal The RSA public exponent, read from the same RSAPublicKey the modulus comes from, or
+ *  null where the key does not decode as one. */
+function _rsaExponent(spki) {
+  try {
+    var pk = spki.publicKey && (spki.publicKey.bytes || spki.publicKey);
+    if (!Buffer.isBuffer(pk)) return null;
+    var seq = asn1.decode(pk);
+    if (!seq.children || seq.children.length !== 2) return null;
+    return asn1.read.integer(seq.children[1]);
+  } catch (_e) { return null; }
+}
 var RSA_KEY_ALGS = Object.assign(Object.create(null), { rsaEncryption: 1, rsassaPss: 1, rsaesOaep: 1 });
 var APPROVED_EC_CURVES = ["prime256v1", "secp384r1", "secp521r1"];
 function _ecCurveName(spki) {
@@ -1602,6 +1613,550 @@ var CABF_SMIME_RULES = [
   },
 ];
 
+/** @internal Mozilla Root Store Policy v3.1 sec. 5.1.1 and 5.1.2 give the permitted
+ *  AlgorithmIdentifier encodings as hex-encoded BYTES, so these are compared as DER rather than as
+ *  a decoded triple: the point of the clause is the encoding, and two AlgorithmIdentifiers naming
+ *  the same algorithm can differ in whether the parameters are an explicit NULL or absent. */
+var MOZILLA_SPKI_ALGORITHMS = [
+  "300d06092a864886f70d0101010500",
+  "301306072a8648ce3d020106082a8648ce3d030107",
+  "301006072a8648ce3d020106052b81040022",
+  "301006072a8648ce3d020106052b81040023",
+];
+var MOZILLA_SIGNATURE_ALGORITHMS = [
+  "300d06092a864886f70d0101050500",
+  "300d06092a864886f70d01010b0500",
+  "300d06092a864886f70d01010c0500",
+  "300d06092a864886f70d01010d0500",
+  "304106092a864886f70d01010a3034a00f300d060960864801650304020105" +
+    "00a11c301a06092a864886f70d010108300d06096086480165030402010500a203020120",
+  "304106092a864886f70d01010a3034a00f300d060960864801650304020205" +
+    "00a11c301a06092a864886f70d010108300d06096086480165030402020500a203020130",
+  "304106092a864886f70d01010a3034a00f300d060960864801650304020305" +
+    "00a11c301a06092a864886f70d010108300d06096086480165030402030500a203020140",
+  "300a06082a8648ce3d040302",
+  "300a06082a8648ce3d040303",
+  "300a06082a8648ce3d040304",
+];
+/** @internal The RSASSA-PKCS1-v1_5 with SHA-1 encoding, which sec. 5.1.1 admits and sec. 5.1.3
+ *  then restricts by date and by key purpose. */
+var MOZILLA_SHA1_RSA = "300d06092a864886f70d0101050500";
+var MOZILLA_SHA1_ECDSA = "300906072a8648ce3d0401";
+var MOZILLA_SHA1_EMAIL_FROM = new Date("2022-07-01T00:00:00Z");
+var MOZILLA_SHA1_OCSP_CA_FROM = new Date("2023-07-01T00:00:00Z");
+/** @internal "Intermediate certificates created after January 1, 2019" (sec. 5.3). */
+var MOZILLA_INTERMEDIATE_EKU_FROM = new Date("2019-01-01T00:00:00Z");
+/** @internal "at least 64 bits of output from a CSPRNG" in the serial (sec. 5.2), of which the
+ *  eight octets are what a certificate's bytes can answer for. */
+var MOZILLA_SERIAL_MIN_OCTETS = 8;
+var MOZILLA_RSA_MIN_BITS = 2048;
+
+/** @internal The SubjectPublicKeyInfo's AlgorithmIdentifier as DER hex. The parsed record carries
+ *  the decoded triple, and this clause is about the encoding, so the bytes are read back out. */
+function _mozillaSpkiAlgorithmHex(cert) {
+  try {
+    var spki = cert.subjectPublicKeyInfo;
+    if (!spki || !Buffer.isBuffer(spki.bytes)) return null;
+    var node = asn1.decode(spki.bytes);
+    if (!node.children || !node.children.length) return null;
+    return node.children[0].bytes.toString("hex");
+  } catch (_e) { return null; }
+}
+/** @internal The signature AlgorithmIdentifier as DER hex, read from the TBSCertificate. Only one
+ *  of the two algorithm fields needs reading: schema-x509 refuses a certificate whose outer
+ *  signatureAlgorithm differs byte-for-byte from tbsCertificate.signature, so by the time a rule
+ *  sees one they cannot disagree. */
+function _mozillaSignatureAlgorithmHex(cert) {
+  // allow:swallow-unverified the ingest door has already produced a parsed certificate, so this reads bytes the parser accepted and a fault answers null
+  try {
+    var kids = asn1.decode(cert.tbsBytes).children;
+    if (!kids || kids.length < 2) return null;
+    var idx = (kids[0].tagClass === "context" && kids[0].tagNumber === 0) ? 2 : 1;
+    return kids[idx] ? kids[idx].bytes.toString("hex") : null;
+  } catch (_e) { return null; }
+}
+function _mozillaIsEdDsa(cert) {
+  var spki = cert.subjectPublicKeyInfo;
+  var name = spki && spki.algorithm && spki.algorithm.name;
+  return name === "Ed25519" || name === "Ed448";
+}
+function _mozillaIsSha1Signature(cert) {
+  var hex = _mozillaSignatureAlgorithmHex(cert);
+  return hex === MOZILLA_SHA1_RSA || hex === MOZILLA_SHA1_ECDSA;
+}
+/** @internal The profile is NAMED, never detected. Every other profile here is selected by
+ *  something the certificate declares; a root program's policy applies because the certificate
+ *  chains to a root in that store, which the certificate does not state and a single-certificate
+ *  lint cannot know. */
+function _isMozilla(cert, ctx) { return ctx.profile === "mozilla-root"; }
+/** @internal An INTERMEDIATE, which is what sec. 5.3 governs. Being an intermediate is a role in a
+ *  hierarchy and a certificate does not state it, so this reads the one thing the bytes give: a
+ *  certificate issued in its own name is passed over. That is every root, which the clause does not
+ *  govern, and it is also a self-issued rollover intermediate, which the clause DOES govern, so the
+ *  rows under-report rather than reporting a root for carrying no extended key usage. The
+ *  cross-certificate the clause exempts need not carry matching names, which is why each message
+ *  names that exemption for the operator to apply. */
+function _isMozillaIntermediate(cert, ctx) {
+  return _isMozilla(cert, ctx) && ctx.isCaCert && !_sameName(cert.issuer, cert.subject);
+}
+function _isMozillaEndEntity(cert, ctx) { return _isMozilla(cert, ctx) && !ctx.isCaCert; }
+
+/** @internal The Mozilla Root Store Policy v3.1 profile. */
+var MOZILLA_RULES = [
+  {
+    id: "lint/mozilla-root/spki-algorithm-encoding", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1.1 and 5.1.2",
+    /** @internal An EdDSA key is exempt here and answered by its own row: sec. 5.1 admits one in a
+     * certificate carrying id-kp-emailProtection and gives no EdDSA encoding, so holding it to
+     * this list would report every conforming certificate of that kind. */
+    message: "the subjectPublicKeyInfo AlgorithmIdentifier is not one of the encodings this policy names",
+    appliesTo: function (cert, ctx) { return _isMozilla(cert, ctx) && !_mozillaIsEdDsa(cert); },
+    check: function (cert) {
+      var hex = _mozillaSpkiAlgorithmHex(cert);
+      return MOZILLA_SPKI_ALGORITHMS.indexOf(hex) === -1 ? { context: { algorithmIdentifier: hex } } : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/eddsa-without-email-protection", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1",
+    /** @internal "EdDSA keys MAY be included in certificates that chain to a root certificate in
+     * our root store if the certificate contains id-kp-emailProtection in the EKU extension.
+     * Otherwise, EdDSA keys MUST NOT be included." */
+    message: "an EdDSA key needs id-kp-emailProtection in the extKeyUsage extension",
+    appliesTo: function (cert, ctx) { return _isMozilla(cert, ctx) && _mozillaIsEdDsa(cert); },
+    check: function (cert, ctx) {
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return true;
+      return d.value.indexOf(oid.byName("emailProtection")) === -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/signature-algorithm-encoding", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1.1 and 5.1.2",
+    /** @internal Membership of the ten, and nothing more: sec. 5.1.2 binds a curve to a digest for
+     * the SIGNING key, which is the issuer's and is not in this certificate. Matching
+     * distinguished names would not prove the subject key made the signature, which is the
+     * cross-certificate shape sec. 5.2 calls out.
+     * An EdDSA signature is outside these clauses rather than in breach of them: sec. 5.1.1 and
+     * sec. 5.1.2 fix the encodings for a signing RSA key and a signing ECDSA key, and sec. 5.1
+     * admits an EdDSA key in a certificate carrying id-kp-emailProtection, which can be an
+     * intermediate and sign with it. Reporting the certificates it signs would fail them for the
+     * issuer's key. */
+    message: "the signature AlgorithmIdentifier is not one of the encodings this policy names",
+    appliesTo: function (cert, ctx) {
+      var name = cert.signatureAlgorithm && cert.signatureAlgorithm.name;
+      return _isMozilla(cert, ctx) && name !== "Ed25519" && name !== "Ed448";
+    },
+    check: function (cert) {
+      var hex = _mozillaSignatureAlgorithmHex(cert);
+      return MOZILLA_SIGNATURE_ALGORITHMS.indexOf(hex) === -1 ? { context: { algorithmIdentifier: hex } } : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/rsa-modulus-invalid", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1",
+    /** @internal "RSA keys whose modulus size in bits is divisible by 8, and is at least 2048
+     * bits". The AlgorithmIdentifier row above cannot answer for this, since the modulus lives in
+     * the subjectPublicKey rather than in the algorithm field. */
+    message: "an RSA modulus must be at least 2048 bits and a whole number of octets",
+    appliesTo: function (cert, ctx) {
+      var spki = cert.subjectPublicKeyInfo;
+      return _isMozilla(cert, ctx) && !!(spki && spki.algorithm && RSA_KEY_ALGS[spki.algorithm.name]);
+    },
+    check: function (cert) {
+      var bits = _rsaModulusBits(cert.subjectPublicKeyInfo);
+      if (bits === null) return { context: { rsaBits: null } };
+      return (bits < MOZILLA_RSA_MIN_BITS || bits % 8 !== 0) ? { context: { rsaBits: bits } } : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/rsa-exponent-one", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.2",
+    /** @internal "invalid public keys (e.g., RSA certificates with public exponent equal to 1)",
+     * the one example the clause gives and the one a certificate's bytes settle. */
+    message: "an RSA public exponent of 1 is not a usable key",
+    appliesTo: function (cert, ctx) {
+      var spki = cert.subjectPublicKeyInfo;
+      return _isMozilla(cert, ctx) && !!(spki && spki.algorithm && RSA_KEY_ALGS[spki.algorithm.name]);
+    },
+    check: function (cert) {
+      var e = _rsaExponent(cert.subjectPublicKeyInfo);
+      return e !== null && e <= 1n ? { context: { exponent: e.toString() } } : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/serial-number-not-positive", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.2",
+    /** @internal "all new certificates MUST have a serial number greater than zero", the half of
+     * the sentence a certificate's bytes settle outright. */
+    message: "a serial number must be greater than zero",
+    appliesTo: _isMozilla,
+    check: function (cert) {
+      if (typeof cert.serialNumber !== "bigint") return null;
+      return cert.serialNumber > 0n ? null : { context: { serialNumber: cert.serialNumber.toString() } };
+    },
+  },
+  {
+    id: "lint/mozilla-root/serial-number-short", severity: "warn", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.2",
+    /** @internal "containing at least 64 bits of output from a CSPRNG" constrains the DRAW, and a
+     * DER INTEGER does not carry the leading zero octets a draw can produce: eight random octets
+     * whose first is zero encode to seven of magnitude, which happens to a conforming certificate
+     * about once in 256. So the magnitude is evidence rather than a verdict and the row is graded
+     * below the sentence's other half, which is its own row above. */
+    message: "a serial number carries fewer than eight octets of magnitude, which 64 bits of CSPRNG output rarely produces",
+    appliesTo: _isMozilla,
+    check: function (cert) {
+      var octets = _serialOctets(cert);
+      return octets < MOZILLA_SERIAL_MIN_OCTETS ? { context: { octets: octets } } : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/end-entity-eku-missing", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.2",
+    message: "an end entity certificate must carry an extKeyUsage extension",
+    appliesTo: _isMozillaEndEntity,
+    check: function (cert, ctx) { return ctx.raw("extKeyUsage") ? null : true; },
+  },
+  {
+    id: "lint/mozilla-root/end-entity-eku-any", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.2",
+    message: "an end entity certificate's extKeyUsage must not name anyExtendedKeyUsage",
+    appliesTo: _isMozillaEndEntity,
+    check: function (cert, ctx) {
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return null;
+      return d.value.indexOf(oid.byName("anyExtendedKeyUsage")) !== -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/sha1-email-protection", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1.3",
+    /** @internal "Effective July 1, 2022, CAs SHALL NOT sign SHA-1 hashes over end entity
+     * certificates with an EKU extension containing the id-kp-emailProtection key purpose." */
+    message: "a SHA-1 signature over an end entity certificate carrying id-kp-emailProtection",
+    appliesTo: _isMozillaEndEntity,
+    effectiveDate: MOZILLA_SHA1_EMAIL_FROM,
+    check: function (cert, ctx) {
+      if (!_mozillaIsSha1Signature(cert)) return null;
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return null;
+      return d.value.indexOf(oid.byName("emailProtection")) !== -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/sha1-end-entity-outside-allowance", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1.3",
+    /** @internal SHA-1 over an end entity is permitted "only if all the following are true", and
+     * the conditions this certificate answers for are that it "contains an EKU extension that does
+     * not contain the id-kp-serverAuth, id-kp-emailProtection, or anyExtendedKeyUsage key
+     * purposes". The remaining conditions name the issuing certificate and the BR scope, which are
+     * not in these bytes. The id-kp-emailProtection arm has its own dated row, so this one passes
+     * over it and a certificate draws one finding rather than two. */
+    message: "a SHA-1 signature over an end entity certificate outside the allowance this clause gives",
+    appliesTo: _isMozillaEndEntity,
+    check: function (cert, ctx) {
+      if (!_mozillaIsSha1Signature(cert)) return null;
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return { context: { reason: "no extKeyUsage extension" } };
+      var out = [];
+      ["serverAuth", "anyExtendedKeyUsage"].forEach(function (name) {
+        if (d.value.indexOf(oid.byName(name)) !== -1) out.push({ context: { purpose: name } });
+      });
+      return out.length ? out : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/sha1-ocsp-or-ca", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.1.3",
+    /** @internal "Effective July 1, 2023, CAs SHALL NOT sign SHA-1 hashes over: certificates with
+     * an EKU extension containing the id-kp-ocspSigning key purpose; intermediate certificates
+     * that chain up to roots in Mozilla's program; OCSP responses; or CRLs." The two the
+     * certificate answers for are the key purpose and being an INTERMEDIATE. The clause names
+     * intermediate certificates rather than CA certificates, so a root's own self-signature is not
+     * one of the four things it lists, and the intermediate reading is the one the sec. 5.3 rows
+     * use with the limit it carries. */
+    message: "a SHA-1 signature over an OCSP signing certificate or an intermediate certificate",
+    appliesTo: _isMozilla,
+    effectiveDate: MOZILLA_SHA1_OCSP_CA_FROM,
+    check: function (cert, ctx) {
+      if (!_mozillaIsSha1Signature(cert)) return null;
+      if (_isMozillaIntermediate(cert, ctx)) return { context: { reason: "intermediate certificate" } };
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return null;
+      return d.value.indexOf(oid.byName("ocspSigning")) !== -1
+        ? { context: { reason: "id-kp-OCSPSigning" } } : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/intermediate-eku-missing", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.3",
+    /** @internal The clause exempts "cross-certificates that share a private key with a
+     * corresponding root certificate", which names a role in a hierarchy that a certificate does
+     * not state, so the message carries the exemption for the operator to apply. */
+    message: "an intermediate certificate must carry an extKeyUsage extension, unless it is a cross-certificate sharing a private key with a root",
+    appliesTo: _isMozillaIntermediate,
+    effectiveDate: MOZILLA_INTERMEDIATE_EKU_FROM,
+    check: function (cert, ctx) { return ctx.raw("extKeyUsage") ? null : true; },
+  },
+  {
+    id: "lint/mozilla-root/intermediate-eku-any", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.3",
+    message: "an intermediate certificate's extKeyUsage must not name anyExtendedKeyUsage, unless it is a cross-certificate sharing a private key with a root",
+    appliesTo: _isMozillaIntermediate,
+    effectiveDate: MOZILLA_INTERMEDIATE_EKU_FROM,
+    check: function (cert, ctx) {
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return null;
+      return d.value.indexOf(oid.byName("anyExtendedKeyUsage")) !== -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/mozilla-root/intermediate-eku-server-and-email", severity: "error", source: "mozilla-root", citation: "Mozilla Root Store Policy 5.3",
+    message: "an intermediate certificate must not name both id-kp-serverAuth and id-kp-emailProtection, unless it is a cross-certificate sharing a private key with a root",
+    appliesTo: _isMozillaIntermediate,
+    effectiveDate: MOZILLA_INTERMEDIATE_EKU_FROM,
+    check: function (cert, ctx) {
+      var d = ctx.decode("extKeyUsage");
+      if (!d || !Array.isArray(d.value)) return null;
+      var server = d.value.indexOf(oid.byName("serverAuth")) !== -1;
+      var email = d.value.indexOf(oid.byName("emailProtection")) !== -1;
+      return (server && email) ? true : null;
+    },
+  },
+];
+
+/** @internal The two purposes sec. 1.3.2 admits in a subordinate CA certificate, as (a)
+ *  id-kp-serverAuth alone or (b) id-kp-serverAuth with id-kp-clientAuth. */
+var CHROME_TLS_PURPOSES = ["serverAuth", "clientAuth"].map(function (n) { return oid.byName(n); });
+/** @internal "All corresponding subscriber certificates issued on or after March 15, 2027"
+ *  (sec. 1.3.2). Issuance is a date the certificate carries, unlike the CCADB disclosure date the
+ *  subordinate CA half of the same clause turns on. */
+var CHROME_SUBSCRIBER_EKU_FROM = new Date("2027-03-15T00:00:00Z");
+/** @internal "Beginning June 15, 2026, the Chrome Root Program will phase-out PKI hierarchies found
+ *  in violation of the below requirements" (sec. 1.3.2). */
+var CHROME_DEDICATED_FROM = new Date("2026-06-15T00:00:00Z");
+var CHROME_SUBORDINATE_MAX_MONTHS = 36;
+/** @internal The sec. 1.3.1.2 removal schedule, keyed on the date the key material was generated.
+ *  Each row holds the exclusive upper bound of its bracket; a date at or after the last bound takes
+ *  the clause's tail, fifteen years from generation. */
+var CHROME_TERM_SCHEDULE = [
+  { until: new Date("2008-01-01T00:00:00Z"), removal: new Date("2026-04-15T00:00:00Z") },
+  { until: new Date("2010-01-01T00:00:00Z"), removal: new Date("2027-04-15T00:00:00Z") },
+  { until: new Date("2012-01-01T00:00:00Z"), removal: new Date("2028-04-15T00:00:00Z") },
+  { until: new Date("2014-04-15T00:00:00Z"), removal: new Date("2029-04-15T00:00:00Z") },
+];
+var CHROME_TERM_MONTHS = 180;
+
+function _chromeRemoval(notBefore) {
+  var at = guard.time.instantOf(notBefore);
+  for (var i = 0; i < CHROME_TERM_SCHEDULE.length; i++) {
+    if (at < guard.time.instantOf(CHROME_TERM_SCHEDULE[i].until)) return CHROME_TERM_SCHEDULE[i].removal;
+  }
+  return guard.time.addMonths(notBefore, CHROME_TERM_MONTHS, _cfg, "lint/bad-input", "notBefore");
+}
+/** @internal The profile is NAMED, never detected, for the reason mozilla-root is. */
+function _isChrome(cert, ctx) { return ctx.profile === "chrome-root"; }
+/** @internal A SUBORDINATE CA, which is what sec. 1.3.2 and sec. 1.3.1.3 govern. Being one is a
+ *  role in a hierarchy that a certificate does not state, so this reads the one thing the bytes
+ *  give and passes over a certificate issued in its own name. That is every root, which those
+ *  clauses do not govern, and it is also a rollover CA reissued in its own name, which they do, so
+ *  the rows under-report rather than reporting a root for carrying no extended key usage. */
+function _isChromeSubordinate(cert, ctx) {
+  return _isChrome(cert, ctx) && ctx.isCaCert && !_sameName(cert.issuer, cert.subject);
+}
+/** @internal Sec. 1.3.2 reaches "all corresponding UNEXPIRED and unrevoked subordinate CA
+ *  certificates", and its phase-out begins on 15 June 2026. A certificate whose notAfter precedes
+ *  that day was not among the unexpired ones the clause names when it began to bite, so the four
+ *  extended key usage rows pass over it. Whether a certificate is revoked is not in these bytes and
+ *  stays outside the reading. Sec. 2.3 states the same requirement for an Applicant hierarchy with
+ *  no date on it, and a certificate does not say whether its hierarchy is an Applicant's, so the
+ *  date sec. 1.3.2 carries is the one used.
+ *  Expiry is an EXEMPTION from a clause the names have already brought the certificate under, so a
+ *  notAfter that cannot be read leaves the rows applying: an exemption nothing establishes is not
+ *  granted. That is the opposite default from `_selfSignedIdentifiers`, where the unreadable field
+ *  is what the row's own premise rests on. */
+function _isChromeTlsSubordinate(cert, ctx) {
+  if (!_isChromeSubordinate(cert, ctx)) return false;
+  var notAfter = cert.validity && cert.validity.notAfter;
+  if (!guard.time.isDate(notAfter)) return true;
+  return guard.time.instantOf(notAfter) >= guard.time.instantOf(CHROME_DEDICATED_FROM);
+}
+/** @internal A SUBSCRIBER certificate, which is not every end entity beneath a root. A delegated
+ *  OCSP responder has its own profile in the Baseline Requirements that sec. 1.1.1 binds, and that
+ *  profile asks for id-kp-OCSPSigning and NO other purpose, so reading one as a subscriber would
+ *  report a conforming responder for the id-kp-serverAuth it must not carry. The exemption is the
+ *  purpose standing ALONE rather than merely present: a certificate naming it beside others is not
+ *  a responder under that profile, and exempting on presence would let any certificate leave every
+ *  row here by adding the purpose. Naming this profile does not run the cabf-tls set, so no other
+ *  row would catch it. */
+function _isChromeSubscriber(cert, ctx) {
+  if (!_isChrome(cert, ctx) || ctx.isCaCert) return false;
+  var purposes = _chromePurposes(ctx);
+  if (!purposes || purposes.length !== 1) return true;
+  return purposes[0] !== oid.byName("ocspSigning");
+}
+/** @internal Matching issuer and subject names make a certificate self-ISSUED, which is not the
+ *  same as self-signed: a CA reissued in its own name under a new key carries the same two names
+ *  and was signed by its predecessor. The key identifiers separate the two without a signature
+ *  check, which this synchronous surface cannot make. A certificate whose authorityKeyIdentifier
+ *  names a key other than its own subjectKeyIdentifier was signed by a different key and is not a
+ *  root; one that omits the extension, or names its own, is consistent with a self-signature. A
+ *  keyIdentifier present with no readable subjectKeyIdentifier beside it settles nothing, and the
+ *  row rests on settling it, so that reads as not a root too. The residual is a rollover CA that
+ *  carries no authorityKeyIdentifier keyIdentifier at all, which RFC 5280 sec. 4.2.1.1 permits
+ *  only in a self-signed certificate and which the rfc5280 profile reports on its own row. */
+function _selfSignedIdentifiers(cert, ctx) {
+  var aki = ctx.decode("authorityKeyIdentifier");
+  var kid = aki && aki.value ? aki.value.keyIdentifier : null;
+  if (!Buffer.isBuffer(kid)) return true;
+  var ski = ctx.decode("subjectKeyIdentifier");
+  return Buffer.isBuffer(ski && ski.value) && kid.equals(ski.value);
+}
+function _isChromeRoot(cert, ctx) {
+  return _isChrome(cert, ctx) && ctx.isCaCert && _sameName(cert.issuer, cert.subject) &&
+    _selfSignedIdentifiers(cert, ctx);
+}
+function _chromePurposes(ctx) {
+  var d = ctx.decode("extKeyUsage");
+  return (d && Array.isArray(d.value)) ? d.value : null;
+}
+function _chromePurposeLabel(dotted) { return oid.name(dotted) || dotted; }
+
+/** @internal The Chrome Root Program Policy v1.8 profile. */
+var CHROME_RULES = [
+  {
+    id: "lint/chrome-root/subordinate-ca-eku-missing", severity: "error", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    /** @internal Both admitted forms include the extension, so its absence breaks the clause on
+     * either side of the CCADB disclosure date that decides between them. */
+    message: "a subordinate CA certificate must carry an extKeyUsage extension",
+    appliesTo: _isChromeTlsSubordinate,
+    check: function (cert, ctx) { return ctx.raw("extKeyUsage") ? null : true; },
+  },
+  {
+    id: "lint/chrome-root/subordinate-ca-eku-server-auth-missing", severity: "error", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    /** @internal Both forms require the purpose, so its absence needs no date either. A missing
+     * extension is the row above, which is why this one reads a present extension only. */
+    message: "a subordinate CA certificate's extKeyUsage must name id-kp-serverAuth",
+    appliesTo: _isChromeTlsSubordinate,
+    check: function (cert, ctx) {
+      var purposes = _chromePurposes(ctx);
+      if (purposes === null) return null;
+      return purposes.indexOf(oid.byName("serverAuth")) === -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/chrome-root/subordinate-ca-eku-not-tls", severity: "error", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    /** @internal Neither form admits a purpose outside the two, and anyExtendedKeyUsage is such a
+     * purpose. Each offending purpose draws its own finding, since a certificate naming two is
+     * two breaches and an operator fixes them one at a time.
+     * A non-TLS branch is inside this row rather than outside it. The clause governs "all
+     * corresponding unexpired and unrevoked subordinate CA certificates operated beneath an
+     * existing root included in the Chrome Root Store", and it exists "to align all PKI
+     * hierarchies included in the Chrome Root Store on the principle of serving only TLS server
+     * authentication use cases", so a code signing intermediate beneath such a root is the
+     * multi-purpose hierarchy the section phases out. */
+    message: "a subordinate CA certificate's extKeyUsage must name no purpose other than id-kp-serverAuth and id-kp-clientAuth",
+    appliesTo: _isChromeTlsSubordinate,
+    check: function (cert, ctx) {
+      var purposes = _chromePurposes(ctx);
+      if (purposes === null) return null;
+      var out = [];
+      purposes.forEach(function (dotted) {
+        if (CHROME_TLS_PURPOSES.indexOf(dotted) === -1) {
+          out.push({ context: { purpose: _chromePurposeLabel(dotted) } });
+        }
+      });
+      return out.length ? out : null;
+    },
+  },
+  {
+    id: "lint/chrome-root/subordinate-ca-eku-client-auth", severity: "warn", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    /** @internal Form (b) is open only to a subordinate CA disclosed to the CCADB before 15 June
+     * 2026, and sec. 2.3 gives an Applicant hierarchy the same form with 15 June 2025. Neither
+     * date is in these bytes, so the row reports below error and its message names what decides
+     * it. */
+    message: "a subordinate CA certificate naming id-kp-clientAuth is admitted only where it was disclosed to the CCADB before 15 June 2026, which a certificate does not carry",
+    appliesTo: _isChromeTlsSubordinate,
+    check: function (cert, ctx) {
+      var purposes = _chromePurposes(ctx);
+      if (purposes === null) return null;
+      return purposes.indexOf(oid.byName("clientAuth")) !== -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/chrome-root/subscriber-eku-missing", severity: "error", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    message: "a subscriber certificate must carry an extKeyUsage extension",
+    appliesTo: _isChromeSubscriber,
+    effectiveDate: CHROME_SUBSCRIBER_EKU_FROM,
+    check: function (cert, ctx) { return ctx.raw("extKeyUsage") ? null : true; },
+  },
+  {
+    id: "lint/chrome-root/subscriber-eku-server-auth-missing", severity: "error", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    message: "a subscriber certificate's extKeyUsage must name id-kp-serverAuth",
+    appliesTo: _isChromeSubscriber,
+    effectiveDate: CHROME_SUBSCRIBER_EKU_FROM,
+    check: function (cert, ctx) {
+      var purposes = _chromePurposes(ctx);
+      if (purposes === null) return null;
+      return purposes.indexOf(oid.byName("serverAuth")) === -1 ? true : null;
+    },
+  },
+  {
+    id: "lint/chrome-root/subscriber-eku-not-server-auth", severity: "error", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.2",
+    /** @internal The subscriber half admits id-kp-serverAuth alone, so id-kp-clientAuth is
+     * reported here rather than warned as it is on a subordinate CA: the same purpose, graded by
+     * which sentence of the clause reads it. */
+    message: "a subscriber certificate's extKeyUsage must name no purpose other than id-kp-serverAuth",
+    appliesTo: _isChromeSubscriber,
+    effectiveDate: CHROME_SUBSCRIBER_EKU_FROM,
+    check: function (cert, ctx) {
+      var purposes = _chromePurposes(ctx);
+      if (purposes === null) return null;
+      var out = [];
+      purposes.forEach(function (dotted) {
+        if (dotted !== oid.byName("serverAuth")) {
+          out.push({ context: { purpose: _chromePurposeLabel(dotted) } });
+        }
+      });
+      return out.length ? out : null;
+    },
+  },
+  {
+    id: "lint/chrome-root/subordinate-ca-validity-over-three-years", severity: "warn", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.1.3",
+    /** @internal "Subordinate CA certificates SHOULD have a maximum validity period of three (3)
+     * years." A ceiling stated in years is measured in months, through guard.time.addMonths, since
+     * how many days three years hold depends on which three. The clause's other sentence asks that
+     * CA owners deploy a new subordinate CA each year, which is a schedule rather than anything
+     * one certificate answers for. */
+    message: "a subordinate CA certificate's validity period should not exceed three years",
+    appliesTo: _isChromeSubordinate,
+    check: function (cert) {
+      var v = cert.validity;
+      if (!guard.time.isDate(v.notBefore) || !guard.time.isDate(v.notAfter)) return null;
+      var ceiling = guard.time.addMonths(v.notBefore, CHROME_SUBORDINATE_MAX_MONTHS, _cfg,
+        "lint/bad-input", "notBefore");
+      return guard.time.instantOf(v.notAfter) > guard.time.instantOf(ceiling)
+        ? { context: { maxMonths: CHROME_SUBORDINATE_MAX_MONTHS } } : null;
+    },
+  },
+  {
+    id: "lint/chrome-root/self-signed-ca-term-limit-outlived", severity: "notice", source: "chrome-root", citation: "Chrome Root Program Policy 1.3.1.2",
+    /** @internal The clause determines the age of key material by the earlier of a key generation
+     * report, which is not in these bytes, or "the validity date of the earliest appearing
+     * certificate that contains the corresponding public key". A self-signed root's own notBefore
+     * is the validity date of one such certificate, so the determined date is at or before it. The
+     * schedule is monotone, so the removal date computed from notBefore is the LATEST the removal
+     * can fall, and reporting only a notAfter past that date holds whatever earlier certificate
+     * carries the key.
+     * The table opens on 1 January 2006 and gives no row for an older key; an older key is removed
+     * no later than a 2006 one, so the first bracket takes it. Its fourth bracket ends on 14 April
+     * 2014 and its tail begins after 15 April 2014, and the two agree on the day between them,
+     * since 15 April 2014 plus fifteen years is 15 April 2029.
+     * The row names a SELF-SIGNED CA certificate rather than a root, which is as far as the bytes
+     * reach. A CA outside the store issues itself one of these during its own key rollover, and it
+     * is identical in every field to a root's. What the finding says is that IF this certificate
+     * is a root in the store the caller named, its term ends before its validity does, and the
+     * notice grade is that conditional. The CA's other certificate, the one its parent issued,
+     * carries different names and is read by the sec. 1.3.2 rows. */
+    message: "a self-signed CA certificate whose validity runs past the removal date this clause fixes for key material of its age",
+    appliesTo: _isChromeRoot,
+    check: function (cert) {
+      var v = cert.validity;
+      if (!guard.time.isDate(v.notBefore) || !guard.time.isDate(v.notAfter)) return null;
+      var removal = _chromeRemoval(v.notBefore);
+      return guard.time.instantOf(v.notAfter) > guard.time.instantOf(removal)
+        ? { context: { removal: removal.toISOString().slice(0, 10) } } : null;
+    },
+  },
+];
+
 /** @internal The three purposes ETSI EN 319 412-5 clause 4.2.3 names, of which a QcType declares
  *  "one and only one". The ASN.1 carries an extension marker, so an identifier outside the three
  *  is admitted and is not one of the purposes being counted. */
@@ -4042,9 +4597,14 @@ var PROFILES = Object.assign(Object.create(null), {
   "cabf-smime": CABF_SMIME_RULES.concat(RFC5280_EXTENSION_SYNTAX_RULES),
   "cabf-cs": CABF_CS_RULES.concat(RFC5280_EXTENSION_SYNTAX_RULES),
   "etsi-qc": ETSI_QC_RULES.concat(RFC5280_EXTENSION_SYNTAX_RULES),
+  "mozilla-root": MOZILLA_RULES.concat(RFC5280_EXTENSION_SYNTAX_RULES),
+  "chrome-root": CHROME_RULES.concat(RFC5280_EXTENSION_SYNTAX_RULES),
 });
 var ALL_RULES = RFC5280_RULES.concat(RFC9881_RULES).concat(RFC9909_RULES).concat(RFC9935_RULES)
-  .concat(CABF_TLS_RULES).concat(CABF_SMIME_RULES).concat(CABF_CS_RULES).concat(ETSI_QC_RULES);
+  .concat(CABF_TLS_RULES).concat(CABF_SMIME_RULES).concat(CABF_CS_RULES).concat(ETSI_QC_RULES)
+  /** @internal The root-program rows are in the registry so `rules()` enumerates them, and stay
+   * inert under the default set because each one asks whether the caller named the profile. */
+  .concat(MOZILLA_RULES).concat(CHROME_RULES);
 
 var CABF_TLS_CSR_RULES = CABF_TLS_RULES.filter(function (r) {
   return CABF_TLS_CSR_RULE_IDS.indexOf(r.id) !== -1;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/pki",
-  "version": "0.8.21",
+  "version": "0.8.23",
   "description": "Pure-JavaScript PKI toolkit that owns its stack — X.509, ASN.1/DER, CMS, PQC-first.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:0f0cede4-1bf3-480e-818c-d982a201c398",
+  "serialNumber": "urn:uuid:3b5edc83-2243-4232-883c-f9c904da9bbb",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-09-24T12:14:29.178Z",
+    "timestamp": "2026-09-24T15:20:10.358Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/pki@0.8.21",
+      "bom-ref": "@blamejs/pki@0.8.23",
       "type": "application",
       "name": "pki",
-      "version": "0.8.21",
+      "version": "0.8.23",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "Pure-JavaScript PKI toolkit that owns its stack — X.509, ASN.1/DER, CMS, PQC-first.",
-      "purl": "pkg:npm/%40blamejs/pki@0.8.21",
+      "purl": "pkg:npm/%40blamejs/pki@0.8.23",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/pki@0.8.21",
+      "ref": "@blamejs/pki@0.8.23",
       "dependsOn": []
     }
   ]