@blamejs/pki 0.7.4 → 0.7.6

package/CHANGELOG.md

@@ -4,6 +4,28 @@ 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.6 — 2026-09-10
+
+A Sigstore bundle is held to the shape its specification states, in signature count and in entry count.
+
+### Changed
+
+- A bundle offering more than 32 transparency-log entries is refused with sigstore/bad-bundle, naming the count it offered. Each entry a bundle offers can cost a certification-path validation, since an entry is tried until one passes every check that depends on which entry it is, and the validation instant comes from the entry itself unless the caller pins opts.time. Nothing bounded the count: the 1 MiB bundle budget leaves room for roughly 155 entries, and every bundle in the Sigstore conformance suite carries exactly one. The ceiling is a local resource bound rather than a rule the specification states, and it is checked before any entry is read. It is available as pki.C.LIMITS.TLOG_MAX_COUNT.
+
+### Fixed
+
+- A DSSE envelope carrying more than one signature is refused with sigstore/bad-dsse, naming the count it carried. The Sigstore bundle specification states the rule on the producer, that an envelope in a bundle has exactly one signature, and again on the verifier, that a client rejects an envelope whose signature count is not one. Only the first signature was ever read, so an envelope with a second was accepted and returned a verdict that said nothing about it. An envelope with exactly one is unaffected, and an empty signature list keeps the refusal it already had.
+
+## v0.7.5 — 2026-09-10
+
+Certificate linting now covers the ML-DSA and SLH-DSA certificate profiles.
+
+### Added
+
+- pki.lint checks an ML-DSA certificate's key usage against RFC 9881 section 5, as the finding id lint/rfc9881/mldsa-key-usage under the new profile name rfc9881. Where the keyUsage extension is present, at least one of digitalSignature, nonRepudiation, keyCertSign or cRLSign must be set and none of keyEncipherment, dataEncipherment, keyAgreement, encipherOnly or decipherOnly may be. The finding carries which key-establishment bits were set and whether a signing bit was present. A certificate carrying no keyUsage extension is unconstrained. All three parameter sets are covered.
+- pki.lint checks an SLH-DSA certificate's key usage against RFC 9909 section 6, as the finding id lint/rfc9909/slhdsa-key-usage under the new profile name rfc9909. The requirement is the same pair. RFC 9909 section 5 admits both the pure id-slh-dsa-* and the prehash id-hash-slh-dsa-*-with-* identifiers as a subject public key algorithm, and the rule reaches both, across all twelve parameter sets of each.
+- pki.lint.profiles() returns rfc5280, rfc9881, rfc9909, rfc9935 and cabf-tls. Passing rfc9881 or rfc9909 as opts.profile runs that profile on its own, and pki.lint.rules(name) enumerates its rows.
+
 ## v0.7.4 — 2026-09-10
 
 Two authoring inputs that were accepted quietly are now refused by name.

package/README.md

@@ -252,7 +252,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 plus 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, 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`, `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, 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`, `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>` |

package/lib/constants.js

@@ -128,6 +128,7 @@ var LIMITS = Object.assign(Object.create(null), {
   CBOR_MAX_ITEMS: 1000000,
   SCT_MAX_BYTES: BYTES.kib(64) + 1,
   SCT_MAX_COUNT: 256,
+  TLOG_MAX_COUNT: 32,
   CMS_MAX_KARI_ENCRYPTED_KEYS: 64,
   CMP_KEM_MAX_KEY_BYTES: 1024,
   CMP_KEM_MIN_KEY_BYTES: 20,

package/lib/lint.js

@@ -10,8 +10,9 @@
  *   ALREADY-PARSED certificate (from `pki.schema.x509.parse`, whose extension values it
  *   decodes with the shared RFC 5280 decoders) and emits graded, advisory FINDINGS: each
  *   with a stable id, a severity (`fatal` > `error` > `warn` > `notice` > `pass`), a source,
- *   a spec-clause citation, and a human message. It ships the RFC 5280 certificate profile
- *   plus a representative CA/Browser Forum TLS Baseline Requirements subset.
+ *   a spec-clause citation, and a human message. It ships the RFC 5280 certificate profile,
+ *   the post-quantum certificate profiles for ML-KEM, ML-DSA and SLH-DSA, and a
+ *   representative CA/Browser Forum TLS Baseline Requirements subset.
  *
  *   Unlike every other toolkit entry, the lint data path never throws. A linter surveys a
  *   corpus that includes malformed members, so `pki.lint.certificate(hostileBytes)` returns
@@ -20,7 +21,7 @@
  *   unknown profile, an out-of-range severity threshold, or a wrong-type input), which
  *   raises a typed `LintError`. This deliberate inversion of the toolkit's fail-closed-throw
  *   posture is what lets an operator lint a whole directory without a try/catch per file.
- * @spec RFC 5280, CA/Browser Forum TLS Baseline Requirements
+ * @spec RFC 5280, RFC 9881, RFC 9909, RFC 9935, CA/Browser Forum TLS Baseline Requirements
  * @card Lint a certificate against RFC 5280 + CABF TLS BR, in pure JS.
  */
 
@@ -511,12 +512,61 @@ var RFC9935_RULES = [
   },
 ];
 
+/** @internal RFC 9881 sec. 5 and RFC 9909 sec. 6 state one pair of requirements for a post-quantum
+ * signature key, both conditioned on keyUsage being present: at least one of digitalSignature,
+ * nonRepudiation, keyCertSign or cRLSign is set, and none of keyEncipherment, dataEncipherment,
+ * keyAgreement, encipherOnly or decipherOnly is. The nine RFC 5280 bits are exhausted by those two
+ * lists, so the only input that fails the signing-bit requirement without also setting a
+ * key-establishment bit is one whose sole bit is reserved. A keyUsage with no bits set never
+ * reaches either rule: the extension decoder refuses it first. */
+function _spkiAlgName(cert) {
+  var spki = cert.subjectPublicKeyInfo;
+  var n = spki && spki.algorithm && spki.algorithm.name;
+  return typeof n === "string" ? n : "";
+}
+function _isMlDsa(cert) { return _spkiAlgName(cert).indexOf("id-ml-dsa-") === 0; }
+/** @internal RFC 9909 sec. 5 admits both the pure and the prehash identifier as a subject public
+ * key algorithm, and sec. 6 binds the key usage of both. */
+function _isSlhDsa(cert) {
+  var n = _spkiAlgName(cert);
+  return n.indexOf("id-slh-dsa-") === 0 || n.indexOf("id-hash-slh-dsa-") === 0;
+}
+var PQC_SIG_ESTABLISHMENT_BITS = ["keyEncipherment", "dataEncipherment", "keyAgreement", "encipherOnly", "decipherOnly"];
+var PQC_SIG_SIGNING_BITS = ["digitalSignature", "nonRepudiation", "keyCertSign", "cRLSign"];
+function _pqcSigKeyUsage(cert, ctx) {
+  var ku = ctx.decode("keyUsage");
+  if (!ku || !ku.value) return null;
+  var v = ku.value;
+  var establishment = PQC_SIG_ESTABLISHMENT_BITS.filter(function (bit) { return v[bit] === true; });
+  var signing = PQC_SIG_SIGNING_BITS.some(function (bit) { return v[bit] === true; });
+  if (establishment.length === 0 && signing) return null;
+  return { context: { keyEstablishmentBitsSet: establishment, signingBitSet: signing } };
+}
+function _pqcSigKeyUsageRule(id, source, citation, family, appliesTo) {
+  return {
+    id: id, severity: "error", source: source, citation: citation,
+    message: "an " + family + " certificate's keyUsage, if present, must set at least one signing bit "
+      + "(digitalSignature, nonRepudiation, keyCertSign, cRLSign) and no key-establishment bit "
+      + "(keyEncipherment, dataEncipherment, keyAgreement, encipherOnly, decipherOnly)",
+    appliesTo: appliesTo,
+    check: _pqcSigKeyUsage,
+  };
+}
+var RFC9881_RULES = [
+  _pqcSigKeyUsageRule("lint/rfc9881/mldsa-key-usage", "rfc9881", "RFC 9881 5", "ML-DSA", _isMlDsa),
+];
+var RFC9909_RULES = [
+  _pqcSigKeyUsageRule("lint/rfc9909/slhdsa-key-usage", "rfc9909", "RFC 9909 6", "SLH-DSA", _isSlhDsa),
+];
+
 var PROFILES = Object.assign(Object.create(null), {
   "rfc5280": RFC5280_RULES,
+  "rfc9881": RFC9881_RULES,
+  "rfc9909": RFC9909_RULES,
   "rfc9935": RFC9935_RULES,
   "cabf-tls": CABF_TLS_RULES,
 });
-var ALL_RULES = RFC5280_RULES.concat(RFC9935_RULES).concat(CABF_TLS_RULES);
+var ALL_RULES = RFC5280_RULES.concat(RFC9881_RULES).concat(RFC9909_RULES).concat(RFC9935_RULES).concat(CABF_TLS_RULES);
 
 function _selectRules(profile) {
   if (profile == null || profile === "all" || profile === "default") return ALL_RULES;
@@ -535,11 +585,12 @@ function _applyThreshold(report, severity) {
  * @signature  pki.lint.certificate(input, opts?) -> LintReport
  * @since      0.2.10
  * @status     stable
- * @spec       RFC 5280, CA/Browser Forum TLS BR
+ * @spec       RFC 5280, RFC 9881, RFC 9909, RFC 9935, CA/Browser Forum TLS BR
  * @related    pki.schema.x509.parse, pki.inspect.certificate, pki.path.validate
  *
- * Lint a certificate against the RFC 5280 profile plus a representative CABF TLS BR
- * subset. `input` is a PEM string, a DER `Buffer`, or an already-parsed
+ * Lint a certificate against the RFC 5280 profile, the post-quantum certificate profiles,
+ * and a representative CABF TLS BR subset. `input` is a PEM string, a DER `Buffer`, or an
+ * already-parsed
  * `pki.schema.x509` object. Returns a `LintReport`
  * `{ findings: [{id, severity, source, citation, message, context?}], counts, worst, ran }`.
  *
@@ -608,11 +659,11 @@ function rules(profile) {
  * @signature  pki.lint.profiles() -> [string]
  * @since      0.2.10
  * @status     stable
- * @spec       RFC 5280, CA/Browser Forum TLS BR
+ * @spec       RFC 5280, RFC 9881, RFC 9909, RFC 9935, CA/Browser Forum TLS BR
  *
  * List the known lint-profile names.
  * @example
- *   pki.lint.profiles();   // -> ["rfc5280", "rfc9935", "cabf-tls"]
+ *   pki.lint.profiles();   // -> ["rfc5280", "rfc9881", "rfc9909", "rfc9935", "cabf-tls"]
  */
 function profiles() { return Object.keys(PROFILES); }
 

package/lib/sigstore.js

@@ -290,6 +290,13 @@ function parseBundle(input) {
       !d.signatures[0] || typeof d.signatures[0] !== "object" || typeof d.signatures[0].sig !== "string") {
     throw _err("sigstore/bad-dsse", "the DSSE envelope is missing a required field (payload / payloadType / signatures[].sig)");
   }
+  /** @internal The bundle specification states this on the producer and again on the verifier: an
+   * envelope in a bundle carries exactly one signature, and a verifier rejects one whose count is
+   * not one. Only `signatures[0]` is ever read, so admitting a second would return a verdict that
+   * says nothing about content the envelope carries. */
+  if (d.signatures.length !== 1) {
+    throw _err("sigstore/bad-dsse", "a bundle's DSSE envelope carries exactly one signature; this one carries " + d.signatures.length);
+  }
   return obj;
 }
 
@@ -1263,6 +1270,15 @@ async function verifyBundle(bundle, opts) {
 
   var tlogs = _isArray(vm.tlogEntries) ? vm.tlogEntries : [];
   if (!tlogs.length) throw _err("sigstore/bad-bundle", "a keyless bundle requires at least one transparency-log entry");
+  /** @internal An entry is tried until one passes every check that depends on which entry it is,
+   * and those checks include a certification-path validation whose instant comes from the entry
+   * itself unless the caller pins one. The count is therefore a work multiplier, and the byte
+   * budget alone leaves room for far more entries than any real bundle carries. This is a local
+   * resource bound rather than a rule the bundle specification states. */
+  if (tlogs.length > C.LIMITS.TLOG_MAX_COUNT) {
+    throw _err("sigstore/bad-bundle", "a bundle offers at most " + C.LIMITS.TLOG_MAX_COUNT
+      + " transparency-log entries; this one offers " + tlogs.length);
+  }
   /** @internal Selecting an entry means finding one that passes EVERY check deciding WHICH entry it
    * is: that it binds to this signature and certificate, that it records this artifact, and that the
    * certificate chain and the embedded timestamps hold at the instant it attests. Any of those

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/pki",
-  "version": "0.7.4",
+  "version": "0.7.6",
   "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:f78d7d30-68ed-48a9-905f-3e46577f4005",
+  "serialNumber": "urn:uuid:8551b89b-6716-4eab-914a-0a3d1aafe57d",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-09-10T10:14:34.771Z",
+    "timestamp": "2026-09-10T12:38:33.413Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/pki@0.7.4",
+      "bom-ref": "@blamejs/pki@0.7.6",
       "type": "application",
       "name": "pki",
-      "version": "0.7.4",
+      "version": "0.7.6",
       "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.4",
+      "purl": "pkg:npm/%40blamejs/pki@0.7.6",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/pki@0.7.4",
+      "ref": "@blamejs/pki@0.7.6",
       "dependsOn": []
     }
   ]