@blamejs/pki 0.7.26 → 0.7.27

package/CHANGELOG.md

@@ -4,6 +4,20 @@ 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.7.27 — 2026-09-12
+
+pki lint detects a certificate, a CRL or an OCSP response and runs the matching profile.
+
+### Added
+
+- pki lint <file> detects whether the file holds a certificate, a CRL or an OCSP response, as DER or PEM, and lints it with pki.lint.certificate, pki.lint.crl or pki.lint.ocsp. --profile, --severity and --json apply to whichever verb runs, and a profile that belongs to another structure is refused with the message naming the verb that takes it. For a file holding a structure no profile covers (a certificate request, a CMS message, a key), the command reports the name the detector gives it and exits instead of linting it as a certificate.
+- lint/rfc5280/extension-criticality (error) reports a certificate extension marked critical that RFC 5280 requires a conforming CA to mark non-critical: authorityKeyIdentifier (section 4.2.1.1), subjectKeyIdentifier (4.2.1.2), subjectDirectoryAttributes (4.2.1.8), freshestCRL (4.2.1.15), authorityInfoAccess (4.2.2.1) and subjectInfoAccess (4.2.2.2). Each finding names the extension and its clause.
+
+### Changed
+
+- A certificate marking one of those six extensions critical was reported as lint/rfc5280/unknown-critical-extension, which told an operator the extension was not recognized when the defect was its criticality. The profile recognizes them, so that finding no longer fires for them; the new row does, at the same severity, so a report filtered at error is unchanged in its verdict and changed in its name.
+- The table of extensions whose criticality RFC 5280 and RFC 6962 fix now lives once, in the shared PKIX schema module, and both pki.x509.sign (which refuses to write against it) and pki.lint.certificate (which reports against it) read it from there.
+
 ## v0.7.26 — 2026-09-12
 
 An OCSP response can be linted against RFC 6960, and against the RFC 5019 lightweight profile on request.

package/README.md

@@ -252,10 +252,10 @@ 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, SAN required and CN-in-SAN, dNSName syntax, serverAuth EKU, weak keys, 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), `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), SAN required and CN-in-SAN, dNSName syntax, serverAuth EKU, weak keys, 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), `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>`, `pki convert <file> --to der\|pem`, `pki verify <cert>... --anchor <cert>`, `pki sign <file> --cert <c> --key <k>` |
+| `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>` |
 
 ### CLI
 
@@ -267,6 +267,8 @@ pki parse cert.pem                       # structured JSON summary of a certific
 pki inspect cert.pem                     # openssl x509 -text style report (pki.inspect)
 pki lint cert.pem                        # graded conformance findings; exit 1 on an error
 pki lint cert.pem --json --profile cabf-tls
+pki lint list.crl                        # detects a CRL or an OCSP response and runs its profile
+pki lint status.ors --profile rfc5019    # the RFC 5019 lightweight rows for an OCSP response
 pki convert cert.pem --to der > cert.der # transcode between PEM and DER (round-trips)
 pki verify leaf.pem --anchor root.pem --time 2026-01-01T00:00:00Z   # RFC 5280 path validation
 pki sign msg.txt --cert signer.pem --key signer-key.pem --out msg.p7s   # CMS SignedData (pki.cms.sign)

package/bin/pki.js

@@ -9,7 +9,7 @@
  *   pki oid <dotted|name>                resolve an OID <-> name
  *   pki parse <cert>                      parse an X.509 certificate to JSON
  *   pki inspect <cert>                    render a certificate as text (openssl x509 -text style)
- *   pki lint <cert> [--profile P]         lint a certificate; exit non-zero on an error finding
+ *   pki lint <file> [--profile P]         lint a certificate, CRL or OCSP response; exit non-zero on an error finding
  *              [--severity S] [--json]
  *   pki convert <file> --to der|pem       transcode a DER/PEM file between the two encodings
  *              [--label LABEL]
@@ -135,15 +135,31 @@ function cmdInspect(file) {
 
 function pad(s, n) { while (s.length < n) s += " "; return s; }
 
-// pki lint <cert> -- lint against pki.lint's profiles. Prints one line per finding and
-// exits non-zero when any error/fatal finding is present (0 when the worst is advisory).
+// The lint verb for each structure `pki lint` detects. A file holding anything else (a request, a
+// CMS message, a key) has no lint profile and is refused by the name the detector gives it.
+var LINT_VERB_FOR = { "x509": "certificate", "crl": "crl", "ocsp-response": "ocsp" };
+
+// pki lint <file> -- detect whether the file holds a certificate, a CRL or an OCSP response and
+// lint it against that structure's profiles. Prints one line per finding and exits non-zero
+// when any error/fatal finding is present (0 when the worst is advisory).
 function cmdLint(args) {
   var file = args._[0];
-  if (!file) fail("usage: pki lint <cert> [--profile <name>] [--severity <floor>] [--json]");
+  if (!file) fail("usage: pki lint <cert|crl|ocsp-response> [--profile <name>] [--severity <floor>] [--json]");
+  var input = readForLib(file);
+  // Bytes no detector recognizes (garbage, or a structure outside the detector's set) fall
+  // through to the certificate verb, whose never-throw data path reports them as a fatal
+  // lint/unparseable finding; a structure the detector DOES name but no profile covers is a
+  // config-time refusal naming it, so a request is not silently linted as a certificate.
+  var verb = "certificate", format;
+  try { format = pki.schema.detectFormat(input); } catch (_e) { format = null; }
+  if (format !== null) {
+    verb = LINT_VERB_FOR[format];
+    if (verb === undefined) return fail(file + ": holds a " + format + " structure, and pki lint covers a certificate, CRL, or OCSP response");
+  }
   var report;
   // Config-time misuse (unknown profile / bad severity) throws a typed LintError; the data
   // path never throws (malformed bytes become a fatal lint/unparseable finding).
-  try { report = pki.lint.certificate(readForLib(file), { profile: args.profile, severity: args.severity }); }
+  try { report = pki.lint[verb](input, { profile: args.profile, severity: args.severity }); }
   catch (e) { return fail(e.code + ": " + e.message); }
   if (args.json) {
     process.stdout.write(JSON.stringify(report, null, 2) + "\n");

package/lib/lint.js

@@ -195,9 +195,18 @@ function _subjectCNs(cert) {
   return out;
 }
 
+/** @internal The criticality RFC 5280 fixes for a certificate extension, read from the shared table
+ * the certificate signer refuses to write against. The profile has its own row for each extension
+ * the table holds CRITICAL (basicConstraints, nameConstraints, policyConstraints, inhibitAnyPolicy),
+ * so only the NON-critical direction is graded through this table, under one id, the way the CRL
+ * profile grades its criticality rows. */
+var CERT_FIXED_CRITICALITY = pkix.certFixedCriticality(oid);
 var _CRITICAL_LEGIT = Object.create(null);
 _CRITICAL_LEGIT[oid.byName("precertificatePoison")] = true;
+/** @internal An extension whose criticality the profile fixes is one it recognizes: marked against
+ * the table it is a criticality fault with its own row, never an unrecognized extension. */
 function _isUnknownExtension(extOid) {
+  if (CERT_FIXED_CRITICALITY[extOid] !== undefined) return false;
   if (path.PROCESSED_EXTENSIONS[extOid] !== true) return _CRITICAL_LEGIT[extOid] !== true;
   return path.TARGET_UNPROCESSED_IF_CRITICAL[extOid] === true;
 }
@@ -270,6 +279,22 @@ var RFC5280_RULES = [
     message: "the signatureValue contains no signature",
     check: function (cert) { return cert.signatureValue.bytes.length === 0 ? true : null; },
   },
+  {
+    id: "lint/rfc5280/extension-criticality", severity: "error", source: "rfc5280", citation: "RFC 5280 4.2.1.1 / 4.2.1.2 / 4.2.1.8 / 4.2.1.15 / 4.2.2.1 / 4.2.2.2",
+    message: "an extension a conforming CA must mark non-critical is marked critical",
+    /** @internal Keyed by the extension's OID throughout. The display name the parser attaches can
+     * be re-pointed through the registry, so a lookup by name would answer for a different
+     * extension, or for none. */
+    check: function (cert) {
+      var rows = [];
+      (cert.extensions || []).forEach(function (e) {
+        var fixed = CERT_FIXED_CRITICALITY[e.oid];
+        if (fixed === undefined || fixed.critical !== false || e.critical !== true) return;
+        rows.push({ context: { extension: e.name || e.oid, oid: e.oid, required: "non-critical", was: "critical", scope: "extensions", citation: fixed.citation } });
+      });
+      return rows.length ? rows : null;
+    },
+  },
   {
     id: "lint/rfc5280/serial-not-positive", severity: "error", source: "rfc5280", citation: "RFC 5280 4.1.2.2",
     message: "the certificate serialNumber must be a positive integer",

package/lib/pki-build.js

@@ -317,17 +317,9 @@ function reqDenseArrayImpl(list, what, E, code) {
   return out;
 }
 
-/** @internal RFC 5280 sec. 4.2 fixes the criticality of these certificate extensions. Each entry maps
- *  the extension OID to the flag the RFC requires and the clause that sets it. */
-var CERT_FIXED_CRITICALITY = intrinsic.create(null);
-[["authorityKeyIdentifier", false, "RFC 5280 sec. 4.2.1.1"], ["subjectKeyIdentifier", false, "RFC 5280 sec. 4.2.1.2"],
-  ["subjectDirectoryAttributes", false, "RFC 5280 sec. 4.2.1.8"], ["nameConstraints", true, "RFC 5280 sec. 4.2.1.10"],
-  ["policyConstraints", true, "RFC 5280 sec. 4.2.1.11"], ["inhibitAnyPolicy", true, "RFC 5280 sec. 4.2.1.14"],
-  ["freshestCRL", false, "RFC 5280 sec. 4.2.1.15"], ["authorityInfoAccess", false, "RFC 5280 sec. 4.2.2.1"],
-  ["subjectInfoAccess", false, "RFC 5280 sec. 4.2.2.2"],
-  ["precertificatePoison", true, "RFC 6962 sec. 3.1"]].forEach(function (r) {
-  CERT_FIXED_CRITICALITY[oid.byName(r[0])] = { critical: r[1], citation: r[2] };
-});
+/** @internal The criticality RFC 5280 sec. 4.2 fixes for a certificate extension, by OID, read from
+ *  the shared table the certificate lint profile reports from, so the two cannot disagree. */
+var CERT_FIXED_CRITICALITY = pkix.certFixedCriticality(oid);
 
 var NC_KEYS = intrinsic.assign(intrinsic.create(null), { permitted: 1, excluded: 1 });
 var NC_FORM_TAG = intrinsic.assign(intrinsic.create(null), {

package/lib/schema-pkix.js

@@ -458,6 +458,29 @@ function rawNonEmptySequence(ns, opts) {
 
 var CRL_REASON_NAMES = constants.NAMES.CRL_REASON;
 
+/** @internal The criticality RFC 5280 (and RFC 6962 for the poison) fixes for a certificate
+ *  extension, by extension name, each with its clause. One table for the two consumers that state
+ *  the rule: the certificate signer refuses to write an extension against it, and the certificate
+ *  lint profile reports one that arrived against it. Extensions whose criticality the CA chooses
+ *  (basicConstraints, keyUsage, the alternative names) are absent. */
+var CERT_FIXED_CRITICALITY_ROWS = [
+  ["authorityKeyIdentifier", false, "RFC 5280 sec. 4.2.1.1"], ["subjectKeyIdentifier", false, "RFC 5280 sec. 4.2.1.2"],
+  ["subjectDirectoryAttributes", false, "RFC 5280 sec. 4.2.1.8"], ["nameConstraints", true, "RFC 5280 sec. 4.2.1.10"],
+  ["policyConstraints", true, "RFC 5280 sec. 4.2.1.11"], ["inhibitAnyPolicy", true, "RFC 5280 sec. 4.2.1.14"],
+  ["freshestCRL", false, "RFC 5280 sec. 4.2.1.15"], ["authorityInfoAccess", false, "RFC 5280 sec. 4.2.2.1"],
+  ["subjectInfoAccess", false, "RFC 5280 sec. 4.2.2.2"],
+  ["precertificatePoison", true, "RFC 6962 sec. 3.1"],
+];
+/** @internal The table keyed by dotted OID through the registry the caller passes, since this
+ *  module takes its registry as a parameter rather than requiring it. */
+function certFixedCriticality(oidRegistry) {
+  var table = _create(null);
+  _forEach(CERT_FIXED_CRITICALITY_ROWS, function (r) {
+    table[oidRegistry.byName(r[0])] = { critical: r[1], citation: r[2] };
+  });
+  return table;
+}
+
 var GN_CONSTRUCTED = _assign(_create(null), { 0: 1, 3: 1, 4: 1, 5: 1 });
 var GN_IA5 = _assign(_create(null), { 1: 1, 2: 1, 6: 1 });
 /** @internal DirectoryString ::= CHOICE { teletexString, printableString, universalString,
@@ -1439,6 +1462,7 @@ module.exports = {
   utf8Text: utf8Text,
   rawNonEmptySequence: rawNonEmptySequence,
   CRL_REASON_NAMES: CRL_REASON_NAMES,
+  certFixedCriticality: certFixedCriticality,
   certExtensionDecoders: certExtensionDecoders,
   _decodeHelpers: _decodeHelpers,
   attribute: attribute,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/pki",
-  "version": "0.7.26",
+  "version": "0.7.27",
   "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:4d386905-4bf6-44a7-b504-c8e9fe74646d",
+  "serialNumber": "urn:uuid:c684e528-5bc7-435f-8e5c-076712d49f7f",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-09-12T03:45:28.477Z",
+    "timestamp": "2026-09-12T04:29:07.726Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/pki@0.7.26",
+      "bom-ref": "@blamejs/pki@0.7.27",
       "type": "application",
       "name": "pki",
-      "version": "0.7.26",
+      "version": "0.7.27",
       "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.7.26",
+      "purl": "pkg:npm/%40blamejs/pki@0.7.27",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/pki@0.7.26",
+      "ref": "@blamejs/pki@0.7.27",
       "dependsOn": []
     }
   ]