@blamejs/pki 0.6.14 → 0.6.16

package/lib/constants.js

@@ -32,8 +32,6 @@ var frameworkError = require("./framework-error");
 
 var ConstantsError = frameworkError.ConstantsError;
 
-// _positive(n, who) is the shared guard every scale helper runs. Config-
-// time tier: a bad scale argument is an authoring bug, so it throws.
 function _positive(n, who) {
   if (typeof n !== "number" || !isFinite(n) || n < 0) {
     throw new ConstantsError(
@@ -44,11 +42,6 @@ function _positive(n, who) {
   return n;
 }
 
-// _scale(n, who, factor) validates the argument and the product. A finite
-// operand can still overflow the multiplication (days(1e304) -> Infinity),
-// and an Infinity handed onward silently disables any bound compared
-// against it (`len > Infinity` is always false), so a product outside the
-// safe-integer range throws instead of returning.
 function _scale(n, who, factor) {
   var out = Math.round(_positive(n, who) * factor);
   if (!Number.isSafeInteger(out)) {
@@ -115,265 +108,61 @@ var BYTES = {
   gib: function (n) { return _scale(n, "C.BYTES.gib", BYTES_PER_KIB * BYTES_PER_KIB * BYTES_PER_KIB); },
 };
 
-// LIMITS -- shared codec ceilings. A DER document larger than this, or
-// nested deeper than this, is refused before the parser walks it: an
-// unbounded length prefix or a pathologically-nested SEQUENCE is a
-// classic decoder-DoS, so the bound is a fail-closed default rather
-// than a tunable an operator must remember to set.
-//
-// DER_MAX_INTEGER_BYTES and OID_MAX_SUBIDENTIFIER_BYTES are per-value
-// ceilings the whole-document cap can't provide: a single INTEGER or OID
-// sub-identifier under the 16 MiB limit can still carry hundreds of KiB,
-// so a value reader that scales super-linearly in its content length is a
-// decoder-DoS the document cap does not stop. 16 KiB covers any real key
-// material (an RSA-131072 modulus), and 32 bytes covers any real OID arc:
-// the largest standard sub-identifier is a 128-bit UUID-based arc (X.667,
-// e.g. 2.25.<uuid>), which is 19 base-128 bytes -- so the cap must exceed
-// that, not sit at 16. Anything larger than 32 bytes is refused as hostile.
 var LIMITS = {
   DER_MAX_BYTES: BYTES.mib(16),
   DER_MAX_DEPTH: 64,
-  // Total decoded-node ceiling: the DER decoder builds an eager node tree, so a
-  // dense run of tiny TLVs (a 2-byte NULL is a node) fans a small input into a
-  // huge tree -- ~350 B/node, so a 16 MiB input of NULLs is ~8M nodes ~= 2.8 GiB.
-  // 4M sits well above the largest realistic structure (a full 16 MiB CRL carries
-  // ~500k revoked entries ~= 2.5M nodes) and below the dense-bomb count; the
-  // operator may override via opts.maxItems. (The CBOR sibling caps at 1M, too
-  // low for DER's legitimate large CRLs.)
   DER_MAX_ITEMS: 4000000,
-  // Hard stack-safe ceiling on the recursion depth of the DER / CBOR
-  // decoders, independent of the (operator-tunable) maxDepth. Both decoders
-  // are recursive descent; a maxDepth raised above the engine's native call-
-  // stack limit would let deeply nested input overflow the C stack with a raw
-  // RangeError instead of the typed too-deep verdict, defeating the fail-closed
-  // contract. A maxDepth above this ceiling is refused at config time. 256 is
-  // four times the default cap and far deeper than any real PKI / CBOR nesting
-  // (a certificate is ~6 levels; the deepest bounded re-decode is 16), while
-  // staying well below the overflow threshold on any supported platform.
   MAX_DECODE_DEPTH_CEILING: 256,
   PEM_MAX_BYTES: BYTES.mib(16),
   DER_MAX_INTEGER_BYTES: BYTES.kib(16),
   OID_MAX_SUBIDENTIFIER_BYTES: 32,
-  // Network transport response ceiling (pki.transport / the EST client). A remote
-  // server's HTTP response body is bounded WHILE it streams -- the accumulator
-  // aborts the socket the instant the running total crosses this cap, before the
-  // body reaches a decoder, so a malicious length field cannot drive unbounded
-  // allocation (RFC 7030 sec. 6). Sized above a base64-inflated DER_MAX_BYTES
-  // document plus multipart/header overhead (16 MiB * 4/3 ~= 21.3 MiB); 24 MiB
-  // clears it. An operator may only tighten it DOWNWARD via opts.maxResponseBytes.
   HTTP_MAX_RESPONSE_BYTES: BYTES.mib(24),
-  // A single untrusted WWW-Authenticate challenge header, bounded BEFORE the string
-  // is copied/tokenized so a hostile server cannot drive unbounded work parsing it
-  // (CWE-770). 8 KiB clears any realistic multi-scheme Digest challenge.
   HTTP_AUTH_HEADER_MAX_BYTES: BYTES.kib(8),
-  // Deterministic-CBOR codec ceilings (RFC 8949), the DER neighbors' siblings:
-  // a whole-document cap refused before the walk, a nesting cap, and a per-value
-  // bignum ceiling the document cap can't provide. Unlike DER_MAX_INTEGER_BYTES,
-  // the bignum cap carries NO +1 sign octet -- a CBOR tag-2/3 bignum body is pure
-  // unsigned big-endian magnitude (RFC 8949 sec. 3.4.3), so 16 KiB is the exact
-  // byte ceiling (covers an RSA-131072 modulus).
   CBOR_MAX_BYTES: BYTES.mib(16),
   CBOR_MAX_DEPTH: 64,
   CBOR_MAX_BIGUINT_BYTES: BYTES.kib(16),
-  // Total decoded-item ceiling. A definite-length array or map can declare a
-  // huge element count that stays under the byte cap yet allocates one node per
-  // element -- e.g. a 16 MiB input of `9a00fffffb` followed by ~16 million
-  // one-byte items would build ~16 million nodes and exhaust memory before a
-  // typed verdict. The decoder counts every item it builds and refuses past this
-  // cap, so a high-fanout bomb fails closed with cbor/too-many-items instead of
-  // OOM-ing. 1,000,000 is far above any real CBOR-encoded PKI structure (a C509
-  // certificate or COSE message is hundreds of items) while bounding the tree.
   CBOR_MAX_ITEMS: 1000000,
-  // Certificate Transparency SCT-list bounds (RFC 6962 sec. 3.3). The outer sct_list
-  // vector carries a 2-byte length prefix, so a well-formed list body is at most
-  // 2^16-1 = 65535 bytes and the full TLS blob (prefix + body) is at most 65537.
-  // The byte cap sits at that structural maximum, so the largest conforming list
-  // is accepted while an oversized inner OCTET STRING (up to the DER document cap)
-  // is refused BEFORE the list is walked. The per-list count cap is asserted per
-  // element DURING the walk (an element count is unknowable before walking
-  // variable-length elements), bounding total work at SCT_MAX_COUNT+1 elements
-  // regardless of a hostile length prefix (the CVE-2022-0778 class: crafted bytes
-  // inside a certificate extension pinning a validator). A real chain carries
-  // 2-5 SCTs; 256 is far above policy.
   SCT_MAX_BYTES: BYTES.kib(64) + 1,
   SCT_MAX_COUNT: 256,
-  // Merkle-proof node-count ceiling (RFC 6962 / RFC 9162). A DoS backstop that
-  // rejects a pathologically long proof array BEFORE the O(log n) fold does any
-  // digest work. 65 is the exact structural maximum: a tree size is a uint64, so
-  // an audit (inclusion) path is at most ceil(log2(2^64)) = 64 nodes, but a
-  // consistency proof is at most ceil(log2(newSize)) + 1 = 65 nodes (the extra
-  // node is the SUBPROOF terminal for a non-power-of-two old size near 2^64). Real
-  // CT logs are 2^30-2^40 (30-40-node proofs), so 65 is generous headroom while
-  // still bounding hostile work. The PRECISE per-proof guard is the geometry
-  // check in each verify (the node count must equal what the coordinates require);
-  // this is the coarse cap. A node count, not a byte size.
   MERKLE_MAX_PROOF_NODES: 65,
-  // Certification-path length ceiling: bounds the per-cert asymmetric verify
-  // work on an untrusted certificate bundle (a real chain is well under this;
-  // the operator may override via opts.maxPathCerts).
   PATH_MAX_CERTS: 100,
-  // Valid-policy-tree node ceiling: bounds the RFC 5280 6.1.3(d) tree a
-  // policy-rich hostile chain can grow (the CVE-2023-0464 class). A real
-  // chain's tree holds a handful of nodes; the operator may override via
-  // opts.maxPolicyNodes.
   PATH_MAX_POLICY_NODES: 4096,
-  // Certification-path BUILDING bounds (pki.path.build). The pool of candidate
-  // issuers is untrusted, so a cross-certificate cycle or Bridge-CA fan-out can
-  // grow the number and length of candidate paths without bound (RFC 4158 sec.
-  // 8.1). PATH_BUILD_MAX_DEPTH caps the chain length explored from the leaf --
-  // well under PATH_MAX_CERTS so a built path clears the validator's own bound
-  // on hand-off; a real hierarchy is a handful of hops. PATH_BUILD_MAX_CANDIDATES
-  // is the total-work ceiling: the builder ticks it once per candidate-issuer
-  // expansion, so a hostile mesh terminates deterministically. Both are operator
-  // overridable (opts.maxDepth / opts.maxCandidatesConsidered).
   PATH_BUILD_MAX_DEPTH: 20,
   PATH_BUILD_MAX_CANDIDATES: 1000,
-  // AIA caIssuers network-fetch bounds (pki.path.build with opts.fetchAia). Fetching an issuer over the
-  // network from an untrusted certificate's authorityInfoAccess opens an SSRF / amplification surface (a
-  // hostile mesh where each fetched cert advertises a fresh caIssuers URL). PATH_AIA_MAX_FETCHES is the
-  // TOTAL network GET budget across a whole build() call (a breach throws path/aia-fetch-limit);
-  // PATH_AIA_MAX_PER_CERT caps how many caIssuers URIs are tried for a single certificate (an AIA MAY carry
-  // many). Both are small by default and operator-overridable (opts.maxAiaFetches / opts.maxAiaPerCert).
   PATH_AIA_MAX_FETCHES: 10,
   PATH_AIA_MAX_PER_CERT: 3,
-  // A caIssuers response is one certificate or a short chain -- never a 24 MiB bundle. Bounding the AIA
-  // fetch below the general HTTP ceiling (and capping the certificate COUNT a single response contributes)
-  // stops a hostile-but-TLS-trusted AIA endpoint from forcing tens of thousands of certificate parses per
-  // fetch (parse work bounded by COUNT, not only by bytes). Both operator-overridable (opts.maxResponseBytes
-  // tightens downward only; the count cap is a fixed defense).
   PATH_AIA_MAX_RESPONSE_BYTES: BYTES.mib(1),
   PATH_AIA_MAX_CERTS_PER_RESPONSE: 16,
-  // PKCS#12 container ceilings. A PFX carries lists at three altitudes
-  // (ContentInfos per AuthenticatedSafe, SafeBags per SafeContents,
-  // attributes per bag) and can chain fresh DER blobs inside OCTET STRINGs,
-  // where every re-decode would otherwise restart the depth cap from zero.
-  // A real keystore holds a handful of keys and certificates; thousands of
-  // elements or dozens of chained re-decodes is hostile input, not a store.
   PKCS12_MAX_ELEMENTS: 1024,
   PKCS12_MAX_REDECODES: 64,
   PKCS12_MAX_BAG_DEPTH: 16,
-  // BER constructed-string reassembly copies each nesting level's payload, so
-  // nesting multiplies transient memory. Real producers segment one level
-  // deep; nesting past this cap is amplification, not a store.
   BER_MAX_STRING_NESTING: 8,
-  // A single attribute's value SET -- no deployed attribute carries more than
-  // a handful of values; a list at this scale is amplification.
   ATTRIBUTE_MAX_VALUES: 256,
-  // JSON message bounds for the JOSE / ACME layer (RFC 8555). Directories and
-  // resource objects are small (certificates travel as PEM, not JSON); 1 MiB is
-  // generous headroom. Depth 32 clears the deepest real nesting (a problem
-  // document's subproblems nest one level) with margin below any stack risk;
-  // enforced BEFORE parsing so a hostile document is refused up front.
   JSON_MAX_BYTES: BYTES.mib(1),
   JSON_MAX_DEPTH: 32,
-  // The CT log-list JSON ceiling -- the full "all logs" variant (with historical logs) exceeds the
-  // 1 MiB JSON_MAX_BYTES used for small ACME resource objects; 4 MiB gives headroom while staying bounded.
   CT_LOG_LIST_MAX_BYTES: BYTES.mib(4),
-  // PBKDF2 iteration ceiling on the DECRYPT side (RFC 8018 pwri / PBES2). An attacker-supplied
-  // iterationCount is attacker-controlled work; a message above this is refused before any
-  // derivation (typed cms/iteration-limit), and a caller may cap it lower via opts.maxIterations.
-  // 10M clears the authoring default (600k) with generous headroom for high-security policies.
   PBKDF2_MAX_ITERATIONS: 10000000,
   PBKDF2_MAX_SALT: 1024,
-  // A MIME entity / S/MIME message size ceiling -- bounds the header + body decode before a copy.
   MIME_MAX_BYTES: BYTES.mib(16),
-  // RFC 5322 sec. 2.1.1: a header line MUST be <= 998 octets excluding the CRLF. A composer that emits a
-  // longer unfolded field line risks a relay re-folding or rejecting the message -- for multipart/signed
-  // that re-fold changes the signed bytes and breaks verification -- so an emitted field line is capped here.
   HEADER_LINE_MAX_OCTETS: 998,
-  // The decompressed-output ceiling for CMS CompressedData (RFC 3274) -- bounds the inflate BEFORE the
-  // output is materialized (a decompression-bomb / resource-exhaustion defense, CWE-409); a caller may
-  // tighten it DOWNWARD via opts.maxOutputBytes, never loosen it.
   COMPRESS_MAX_BYTES: BYTES.mib(16),
-  // The largest TLS handshake message body. RFC 8446 sec. 4 frames every Handshake with a uint24
-  // length, so a Certificate message cannot exceed 2^24-1 bytes -- the ceiling RFC 8879 sec. 5
-  // requires a CompressedCertificate to respect ("they MUST apply the same limit as if no
-  // compression were used"). That section spells the number 16777216, which is one MORE than any
-  // uint24 can express; the field width governs, so this is deliberately not mib(16).
   TLS_CERT_MSG_MAX_BYTES: BYTES.mib(16) - 1,
-  // The most CertificateEntry elements a TLS Certificate message may carry. The byte ceiling
-  // alone does not bound this: the smallest legal entry is 6 bytes (a uint24 length, one payload
-  // octet, an empty uint16 extensions vector), so a message inside the framing limit can declare
-  // millions of them and each costs far more heap than wire -- an allocation DoS (CWE-770) that
-  // terminates but exhausts memory. This matches PATH_MAX_CERTS: a chain longer than the path
-  // validator will ever accept has nothing to offer, so refusing it at the decoder is free.
   TLS_CERT_MAX_ENTRIES: 100,
-  // A FIDO Metadata Service BLOB is a JWS whose payload carries every registered authenticator's
-  // metadata; the live one runs about 10 MB across ~500 entries. The byte cap bounds the decode
-  // before the payload is materialized, and the entry and anchor caps bound the per-entry work
-  // (each anchor is a DER certificate parse), since a byte ceiling alone does not bound how many
-  // items are declared inside it (CWE-770).
   MDS_BLOB_MAX_BYTES: BYTES.mib(32),
-  // The BLOB's JWS protected header is read BEFORE the signature is checked, so it carries its own,
-  // far smaller ceiling: a header is a few hundred bytes plus the x5c chain, and the envelope cap
-  // would otherwise let unauthenticated input buy heap ahead of every authentication step.
   MDS_BLOB_HEADER_MAX_BYTES: BYTES.kib(256),
-  // The JWS signature, likewise read before anything is authenticated. Every algorithm this reader
-  // supports has a tightly bounded signature: 64/96/132 bytes for ECDSA P-256/384/521, 64 and 114
-  // for Ed25519 and Ed448, the modulus size for RSA, and 2420 / 3309 / 4627 for ML-DSA-44/65/87
-  // (FIPS 204). The bound has to clear the LARGEST of those -- an accepted algorithm whose ordinary
-  // signature the ceiling refuses is a row that can never verify -- so 8 KiB, which covers ML-DSA-87
-  // and an RSA-16384 key with room to spare while still refusing a segment whose only purpose is to
-  // make the verifier allocate.
   MDS_BLOB_SIG_MAX_BYTES: BYTES.kib(8),
   MDS_MAX_ENTRIES: 4096,
-  // A model's certification history: bounded like the other repeated per-entry structures, because
-  // the status gate walks the whole array on every verification.
   MDS_MAX_STATUS_REPORTS_PER_ENTRY: 256,
   MDS_MAX_ANCHORS_PER_ENTRY: 16,
-  // A U2F authenticator carries no AAGUID, so its entry is keyed by the key identifiers of its
-  // attestation certificates instead -- a batch-attested product line legitimately registers dozens.
   MDS_MAX_KEY_IDS_PER_ENTRY: 64,
-  // The most nested statements a WebAuthn compound attestation (sec. 8.9) may carry. The syntax
-  // says "2*" -- unbounded -- so this is a resource bound this toolkit chooses, NOT a spec MUST.
-  // The CBOR parse caps bound the decode; they do not bound the crypto, and each element costs a
-  // signature verification plus, for some formats, a full certificate-path validation. Seven
-  // non-compound formats are registered, so a conforming statement carrying one of each is 7.
   WEBAUTHN_COMPOUND_MAX_STATEMENTS: 16,
-  // The most certificates a WebAuthn attestation chain may carry, in an attStmt x5c array or a JWS
-  // x5c header. A real attestation chain is one to four; the byte ceiling on a single entry does
-  // not bound the COUNT, so an array of thousands of small certificates is an unbounded parse and
-  // signature-check fanout (CWE-770) that terminates but costs far more CPU than wire. This is a
-  // resource bound this toolkit chooses -- no specification states it -- and it is far tighter than
-  // PATH_MAX_CERTS because an attestation chain is not a general PKI path.
   WEBAUTHN_X5C_MAX_CERTS: 10,
-  // A WebAuthn android-safetynet attestation statement carries the SafetyNet response as a JWS
-  // compact serialization: two small JSON objects plus a signature, with the certificate chain
-  // inline in the header. Real ones run a few kilobytes. The cap bounds the text decode before the
-  // string is materialized, so an oversized statement is refused rather than allocated (CWE-770).
   SAFETYNET_JWS_MAX_BYTES: BYTES.kib(64),
-  // One x5c entry is a single DER certificate; PATH_MAX_CERT_BYTES is the ceiling the path
-  // validator already applies to any certificate it will accept, and an entry above it could not
-  // chain even if it decoded.
   SAFETYNET_CERT_MAX_BYTES: BYTES.kib(64),
-  // ACME challenge token entropy floor (RFC 8555 sec. 8, errata 6950): >= 128
-  // bits of base64url is >= 22 characters. A shorter token is refused before use.
   ACME_TOKEN_MIN_CHARS: 22,
-  // SCEP transactionID length ceiling (RFC 8894 sec. 3.2.1.1). The RFC sets no
-  // length; a real transaction id is a short hash or key fingerprint, so the
-  // builder caps the caller-supplied PrintableString here rather than emitting
-  // an unbounded attribute.
   SCEP_TRANSACTION_ID_MAX: 255,
-  // OCSP embedded-certificate ceiling. A BasicOCSPResponse (or an OCSP request
-  // Signature) carries the responder / requestor certificate plus at most a short
-  // chain; the delegated-responder authorization loop verifies each candidate
-  // BEFORE the response signature is checked, so an attacker-crafted stapled /
-  // relayed response with a huge certs list would drive unbounded pre-auth
-  // signature verifies. 32 is generous headroom over a real chain.
   OCSP_MAX_CERTS: 32,
-  // HSS hierarchy depth (RFC 8554 sec. 6.1: L is 1..8). The HSS verifier caps
-  // its per-level parse loop at this from the registry, never at the blob's own
-  // Nspk, so a hostile signature cannot drive an unbounded level walk.
   HSS_MAX_LEVELS: 8,
-  // Trust-store ingestion ceilings (Mozilla/NSS certdata.txt + CCADB CSV).
-  // Every cap is refused BEFORE the offending allocation with a typed trust/*
-  // error -- never a silent truncate. A live certdata.txt is a few MiB and a
-  // CCADB all-records export a few MiB more, so 16 MiB whole-input headroom
-  // matches the codec siblings. A root certificate (or a CCADB PEM cell) is a
-  // few KiB; a MULTILINE_OCTAL blob or CSV field past 64 KiB is amplification,
-  // not a root. The real store is ~150 roots x 2 object blocks (and one CCADB
-  // row per root), so 10000 objects / rows is generous headroom while bounding
-  // a block/row bomb.
   TRUST_MAX_BYTES: BYTES.mib(16),
   TRUST_MAX_OCTAL_BYTES: BYTES.kib(64),
   TRUST_MAX_OBJECTS: 10000,
@@ -381,19 +170,7 @@ var LIMITS = {
   TRUST_MAX_CSV_FIELD_BYTES: BYTES.kib(64),
 };
 
-// NAMES -- display-naming conventions shared by the human-readable renderers
-// (pki.inspect today; a future lint / CLI report tomorrow). Centralized so every
-// consumer speaks ONE convention -- the OpenSSL-familiar labels an operator expects
-// -- rather than each renderer copying a table that silently drifts. These are
-// DISPLAY strings, not wire identifiers (those resolve through pki.oid): a value here
-// never affects parse or verify, only how a decoded field is titled in a report.
 var NAMES = {
-  // ==== Distinguished-name attribute short names (RFC 4514 sec. 3 + RFC 4519 / CABF) ==
-  // The single source of truth: this table was previously copied in both
-  // lib/inspect.js and lib/schema-pkix.js and had already drifted (STREET vs street,
-  // SERIALNUMBER vs serialNumber). An entry whose type the OID registry does not yet
-  // resolve is simply never hit -- forward entries (jurisdiction*, organizationIdentifier)
-  // are harmless until their arc is registered.
   DN_SHORT: {
     commonName: "CN", surname: "SN", serialNumber: "SERIALNUMBER", countryName: "C",
     localityName: "L", stateOrProvinceName: "ST", streetAddress: "STREET",
@@ -404,8 +181,6 @@ var NAMES = {
     jurisdictionCountryName: "jurisdictionC", jurisdictionStateOrProvinceName: "jurisdictionST",
     jurisdictionLocalityName: "jurisdictionL", organizationIdentifier: "organizationIdentifier",
   },
-  // ==== X.509v3 extension section titles (OpenSSL-familiar); an extension absent
-  // here is titled from the OID registry name / dotted OID ====
   EXTENSION: {
     basicConstraints: "X509v3 Basic Constraints", keyUsage: "X509v3 Key Usage",
     extKeyUsage: "X509v3 Extended Key Usage", subjectAltName: "X509v3 Subject Alternative Name",
@@ -420,43 +195,29 @@ var NAMES = {
     invalidityDate: "Invalidity Date", certificateIssuer: "X509v3 Certificate Issuer",
     signedCertificateTimestampList: "CT Precertificate SCTs", precertificatePoison: "CT Precertificate Poison",
   },
-  // ==== KeyUsage bits (RFC 5280 sec. 4.2.1.3, bit order) ====
   KEY_USAGE: {
     digitalSignature: "Digital Signature", nonRepudiation: "Non Repudiation", keyEncipherment: "Key Encipherment",
     dataEncipherment: "Data Encipherment", keyAgreement: "Key Agreement", keyCertSign: "Certificate Sign",
     cRLSign: "CRL Sign", encipherOnly: "Encipher Only", decipherOnly: "Decipher Only",
   },
-  // ==== ExtendedKeyUsage purposes (RFC 5280 sec. 4.2.1.12 + common); an unlisted
-  // purpose shows its registry name / OID ====
   EXT_KEY_USAGE: {
     anyExtendedKeyUsage: "Any Extended Key Usage", serverAuth: "TLS Web Server Authentication",
     clientAuth: "TLS Web Client Authentication", codeSigning: "Code Signing",
     emailProtection: "E-mail Protection", timeStamping: "Time Stamping", ocspSigning: "OCSP Signing",
   },
-  // ==== GeneralName CHOICE labels, by context tag number (RFC 5280 sec. 4.2.1.6) ====
   GENERAL_NAME: { 0: "othername", 1: "email", 2: "DNS", 3: "X400Name", 4: "DirName", 5: "EdiPartyName", 6: "URI", 7: "IP Address", 8: "Registered ID" },
-  // ==== Named-curve -> NIST alias, for the EC key line ====
   NIST_CURVE: { prime256v1: "P-256", secp384r1: "P-384", secp521r1: "P-521" },
-  // ==== ReasonFlags BIT STRING bit -> name (RFC 5280 sec. 4.2.1.13, a CRL
-  // distribution point's revocation scope; bit 0 is "unused"). Distinct from the
-  // CRLReason ENUMERATED below -- a BIT STRING of scopes, not a single code. ====
   REASON_FLAGS: {
     1: "Key Compromise", 2: "CA Compromise", 3: "Affiliation Changed", 4: "Superseded",
     5: "Cessation Of Operation", 6: "Certificate Hold", 7: "Privilege Withdrawn", 8: "AA Compromise",
   },
-  // ==== CRLReason ENUMERATED value names (RFC 5280 sec. 5.3.1; value 7 is unused) ====
   CRL_REASON: {
     "0": "unspecified", "1": "keyCompromise", "2": "cACompromise", "3": "affiliationChanged",
     "4": "superseded", "5": "cessationOfOperation", "6": "certificateHold",
     "8": "removeFromCRL", "9": "privilegeWithdrawn", "10": "aACompromise",
   },
-  // ==== OCSPResponseStatus value names (RFC 6960 sec. 4.2.1; value 4 is unassigned) ====
   OCSP_STATUS: { "0": "successful", "1": "malformedRequest", "2": "internalError", "3": "tryLater", "5": "sigRequired", "6": "unauthorized" },
-  // ==== Attribute-cert objectDigestInfo digested-object types (RFC 5755 sec. 4.4.2) ====
   OBJECT_DIGEST_TYPE: { "0": "publicKey", "1": "publicKeyCert", "2": "otherObjectTypes" },
-  // ==== Public-key / signature algorithm display names, classical + PQC. Forward-
-  // looking: the toolkit is PQC-first, so the FIPS 203/204/205 names render as-is;
-  // a consumer that finds no entry shows the OID registry name / dotted OID ====
   ALGORITHM: {
     rsaEncryption: "rsaEncryption", rsassaPss: "rsassaPss", rsaesOaep: "rsaesOaep", ecPublicKey: "id-ecPublicKey",
     ed25519: "ED25519", ed448: "ED448", x25519: "X25519", x448: "X448",
@@ -467,19 +228,9 @@ var NAMES = {
   },
 };
 
-// NAMES is BOTH a display table (pki.inspect) and the strict parsers' legal-value
-// allow-list: the CRL reasonCode, OCSP response-status, and attribute-cert object-
-// digest decoders check membership against CRL_REASON / OCSP_STATUS / OBJECT_DIGEST_TYPE
-// to fail closed on an RFC-reserved / undefined value. Deep-freeze it so a caller can
-// NEVER widen what those decoders accept by mutating the "display-only" table (e.g.
-// adding CRLReason 7, RFC-reserved, which would otherwise make the decoders fail open).
 Object.keys(NAMES).forEach(function (k) { Object.freeze(NAMES[k]); });
 Object.freeze(NAMES);
 
-// Single-sourced from the package manifest so the reported version can
-// never drift from the published package (package.json is always present
-// in the installed tarball). A hand-maintained literal here silently
-// shipped 0.1.0 on a 0.1.1 release.
 var VERSION = require("../package.json").version;
 
 module.exports = {