@blamejs/pki 0.6.14 → 0.6.16

package/lib/oid.js

@@ -40,110 +40,58 @@ var guard = require("./guard-all");
 
 var OidError = frameworkError.OidError;
 
-// (code, message) -> OidError, the factory shape the composed guards throw
-// through so a malformed identifier keeps the oid/* typed verdict.
 function _oidError(c, m) { return new OidError(c, m); }
 
-// FAMILIES -- OIDs grouped by their shared base arc (the "similar starting
-// variable" that defines a class). A member is `name: leaf`, where leaf is a
-// trailing arc (number) or a short arc array for a multi-level leaf; the full
-// arc is derived at load via base.concat(leaf). Declaring by family means no
-// dotted-decimal OID literal appears in this source at all, and adding a
-// member is one `name: leaf` line under its class, with no base to re-type.
 var FAMILIES = {
-  // RFC 5280 attribute types.
   attributeType: { base: [2, 5, 4], of: {
     commonName: 3, surname: 4, serialNumber: 5, countryName: 6,
     localityName: 7, stateOrProvinceName: 8, streetAddress: 9,
     organizationName: 10, organizationalUnitName: 11, title: 12, givenName: 42,
-    // RFC 5755 sec. 4.4 attribute-certificate attribute types.
     clearance: 55, role: 72 } },
 
-  // RFC 5280 certificate extensions.
   certExtension: { base: [2, 5, 29], of: {
-    subjectDirectoryAttributes: 9,   // id-ce 9 (RFC 5280 sec. 4.2.1.8) -> 2.5.29.9
+    subjectDirectoryAttributes: 9,
     subjectKeyIdentifier: 14, keyUsage: 15, subjectAltName: 17, issuerAltName: 18,
     basicConstraints: 19,
-    // CRL + CRL-entry extensions (RFC 5280 sec. 5.2, sec. 5.3)
     cRLNumber: 20, reasonCode: 21, invalidityDate: 24, deltaCRLIndicator: 27,
     issuingDistributionPoint: 28, certificateIssuer: 29,
     nameConstraints: 30, cRLDistributionPoints: 31,
     certificatePolicies: 32, policyMappings: 33, authorityKeyIdentifier: 35,
     policyConstraints: 36, extKeyUsage: 37, freshestCRL: 46,
     inhibitAnyPolicy: 54,
-    // The two special-OID leaves under extension arcs (RFC 5280 sec. 4.2.1.4 /
-    // sec. 4.2.1.12): the certificate-policies wildcard and the EKU wildcard.
     anyPolicy: [32, 0], anyExtendedKeyUsage: [37, 0],
-    // RFC 5755 attribute-certificate extensions (sec. 4.3.2, sec. 4.3.6).
     targetInformation: 55, noRevAvail: 56 } },
 
-  // PKIX private extensions on the id-pe arc (authorityInfoAccess et al, plus the
-  // RFC 5755 attribute-certificate id-pe extensions: ac-auditIdentity sec. 4.3.1,
-  // aaControls sec. 7.4, ac-proxying sec. 7.2).
   pkixAccess: { base: [1, 3, 6, 1, 5, 5, 7, 1], of: {
     authorityInfoAccess: 1, acAuditIdentity: 4, aaControls: 6, acProxying: 10,
     acmeIdentifier: 31,
-    // id-pe-subjectInfoAccess (RFC 5280 sec. 4.2.2.2) -- the SIA extension companion to the AIA.
     subjectInfoAccess: 11,
-    // id-pe-tlsfeature (RFC 7633) -- the TLS Feature (formerly "must-staple") extension.
     tlsFeature: 24,
-    // id-pe-qcStatements (RFC 3739 sec. 3.2.6) -- the qualified-certificate-statements extension.
     qcStatements: 3,
-    // RFC 3779 -- the IP-address and AS-number delegation extensions that carry a resource
-    // certificate's authority (RPKI). Each has an RFC 8360 "v2" twin with identical syntax and
-    // stricter path-validation semantics, so both are registered here.
     ipAddrBlocks: 7, autonomousSysIds: 8, ipAddrBlocksV2: 28, autonomousSysIdsV2: 29 } },
 
-  // RFC 3739 sec. 3.2.6.1 id-qcs -- the PKIX QCStatement statementIds carrying SemanticsInformation.
   pkixQcSyntax: { base: [1, 3, 6, 1, 5, 5, 7, 11], of: { qcsPkixQCSyntaxV1: 1, qcsPkixQCSyntaxV2: 2 } },
 
-  // ETSI EN 319 412-5 qualified-certificate statements (esi4-qcStatement-N) on the id-etsi-qcs arc.
   etsiQcs: { base: [0, 4, 0, 1862, 1], of: {
     qcCompliance: 1, qcLimitValue: 2, qcRetentionPeriod: 3, qcSSCD: 4, qcPDS: 5,
     qcType: 6, qcCClegislation: 7, qcIdentMethod: 8, qcQSCDlegislation: 9 } },
 
-  // ETSI EN 319 412-5 QcType member OIDs (the certificate-purpose types) on the id-etsi-qct arc.
   etsiQcType: { base: [0, 4, 0, 1862, 1, 6], of: { qctEsign: 1, qctEseal: 2, qctWeb: 3 } },
 
-  // [MS-WCCE] AD CS enrollment extensions on the id-microsoft-21 arc (szOID-CERTSRV / szOID-CERTIFICATE_TEMPLATE / szOID-APPLICATION_CERT_POLICIES).
   msEnrollment: { base: [1, 3, 6, 1, 4, 1, 311, 21], of: {
     msCaVersion: 1, msPreviousCertHash: 2, msCertificateTemplate: 7, msApplicationPolicies: 10 } },
 
-  // [MS-CRTD] legacy v1 enroll cert-type name on the id-microsoft-20 arc (szOID-ENROLL_CERTTYPE_EXTENSION).
   msEnrollmentLegacy: { base: [1, 3, 6, 1, 4, 1, 311, 20], of: { msEnrollCertType: 2 } },
 
-  // id-aca -- RFC 5755 attribute-certificate attribute types on the id-pkix 10 arc:
-  // authenticationInfo sec. 4.4.1 .. group sec. 4.4.4, plus encAttrs sec. 7.1 (the encrypted-
-  // attribute wrapper, syntax ContentInfo). { id-aca 5 } is reserved.
   idAca: { base: [1, 3, 6, 1, 5, 5, 7, 10], of: {
     authenticationInfo: 1, accessIdentity: 2, chargingIdentity: 3, group: 4, encAttrs: 6 } },
 
-  // The legacy RFC 3281 id-at-clearance on the X.501 selected-attribute-types arc.
-  // RFC 5755 sec. 4.4.6 says implementations MUST NOT OUTPUT this form but SHOULD ACCEPT
-  // it for decoding, so it is registered as an alias of "clearance". The canonical
-  // name -> OID reverse stays the RFC 5755 attributeType-arc 2.5.4.55 (registered
-  // first under attributeType, so it wins the reverse mapping).
   selectedAttrType: { base: [2, 5, 1, 5], of: { clearance: 55 } },
 
-  // PKIX Access Descriptor methods (id-ad, RFC 5280 sec. 4.2.2.1/sec. 4.2.2.2). id-ad-ocsp
-  // is the arc the OCSP responder OIDs hang under; id-ad-caIssuers names the AIA
-  // CA-issuers access method. The remaining id-ad methods (timeStamping RFC 3161, caRepository
-  // + rpkiManifest/signedObject/rpkiNotify RFC 6487/8182) complete the C509 Information Access
-  // registry (draft-ietf-cose-cbor-encoded-cert sec. 8.11); they carry the id-ad- prefix so the
-  // name->OID reverse stays unambiguous next to the id-kp "timeStamping" purpose (a distinct arc).
   adAccess: { base: [1, 3, 6, 1, 5, 5, 7, 48], of: { ocsp: 1, caIssuers: 2,
     "id-ad-timeStamping": 3, "id-ad-caRepository": 5, "id-ad-rpkiManifest": 10,
     "id-ad-signedObject": 11, "id-ad-rpkiNotify": 13, "id-ad-cmc": 12 } },
 
-  // CMC control attributes -- id-cmc ::= {id-pkix 7} (RFC 5272 sec. 6, extended by RFC 6402
-  // sec. 2.2/2.8). The whole registry is declared, not just the controls used today: a control
-  // this side does not act on must still be RECOGNIZED to be reported by name, and a decoder that
-  // meets an unknown OID cannot tell "control this build ignores" from "attacker-supplied filler".
-  //
-  // The gaps are the specification's own: 12/13/14 (identityProof/popLinkRandom/popLinkWitness's
-  // superseded siblings are retained below where RFC 6402 kept them) and 20 are unassigned in
-  // RFC 5272 Appendix A. V2 forms exist because RFC 6402 replaced the originals to fix a hash
-  // agility gap. Both are registered, since a v1 message is still legal to receive.
   idCmc: { base: [1, 3, 6, 1, 5, 5, 7, 7], of: {
     "id-cmc-statusInfo": 1, "id-cmc-identification": 2, "id-cmc-identityProof": 3,
     "id-cmc-dataReturn": 4, "id-cmc-transactionId": 5, "id-cmc-senderNonce": 6,
@@ -155,60 +103,21 @@ var FAMILIES = {
     "id-cmc-confirmCertAcceptance": 24, "id-cmc-statusInfoV2": 25, "id-cmc-trustedAnchors": 26,
     "id-cmc-authData": 27, "id-cmc-batchRequests": 28, "id-cmc-batchResponses": 29,
     "id-cmc-publishCert": 30, "id-cmc-modCertTemplate": 31, "id-cmc-controlProcessed": 32,
-    // ---------------------------------------------------------------------
-    // 33 / 34: the specification assigns these two OIDs both ways, and no
-    // erratum resolves it. Counted across every place either document states an
-    // assignment, it is not an even split:
-    //
-    //   identityProofV2 = 34, popLinkWitnessV2 = 33
-    //     rfc5272.txt:1494 / :1504   the sec. 6 control summary table
-    //     rfc5272.txt:1846           sec. 6.2.1 body
-    //     rfc5272.txt:2037           sec. 6.3.1.1 body
-    //     rfc5272.txt:4041 / :4049   RFC 5272's own ASN.1 module
-    //     rfc6402.txt:1228 / :1245   RFC 6402 Appendix A.1 (1988 module)
-    //
-    //   identityProofV2 = 33, popLinkWitnessV2 = 34
-    //     rfc6402.txt:1938 / :1949   RFC 6402 Appendix A.2 (2008 module) alone
-    //
-    // The rows below therefore follow the base specification's normative body
-    // text and its module, which RFC 6402's own 1988 module agrees with. The
-    // 2008 module is the lone outlier and is treated as its typo.
-    //
-    // This binds what the toolkit EMITS, and it is load-bearing because the two
-    // controls cannot be told apart by SHAPE: both are SEQUENCE {
-    // AlgorithmIdentifier, AlgorithmIdentifier, OCTET STRING } (rfc6402.txt:1238,
-    // :1246), so the OID is the only discriminator. Emitting the A.2 reading
-    // would hand a peer built on RFC 5272 an Identity Proof it reads as a POP
-    // Link Witness. A CONSUMER must still not infer meaning from these names
-    // alone -- a peer built against A.2 means the other one, and nothing on the
-    // wire says which module it read.
     "id-cmc-identityProofV2": 34, "id-cmc-popLinkWitnessV2": 33,
     "id-cmc-raIdentityWitness": 35, "id-cmc-changeSubjectName": 36, "id-cmc-responseBody": 37,
   } },
 
-  // CMC content types -- id-cct ::= {id-pkix 12} (RFC 5272 Appendix A). The eContentType a CMC
-  // message rides under inside its CMS SignedData wrapper. RFC 5272 Appendix B repeatedly writes
-  // "id-ct-PKIData"; that is erratum 4775 (Verified) and the correct prefix is id-cct-.
   idCct: { base: [1, 3, 6, 1, 5, 5, 7, 12], of: {
     "id-cct-PKIData": 2, "id-cct-PKIResponse": 3,
   } },
 
-  // id-on -- RFC 5280 sec. 4.2.1.6 otherName type-ids the C509 sec. 8.13 registry gives their own
-  // negative ints: id-on-hardwareModuleName (RFC 4108), id-on-SmtpUTF8Mailbox (RFC 9598),
-  // id-on-MACAddress (I-D.ietf-lamps-macaddress-on) on the id-pkix 8 arc.
   pkixOn: { base: [1, 3, 6, 1, 5, 5, 7, 8], of: { hardwareModuleName: 4, smtpUtf8Mailbox: 9, macAddress: 12 } },
 
-  // CA/Browser Forum certificate policies (draft-ietf-cose-cbor-encoded-cert sec. 8.9 ints 1-4) on the
-  // 2.23.140.1 arc: the id-cabf validation levels under .2, ev-guidelines under .1.
   cabfPolicy: { base: [2, 23, 140, 1], of: {
     "ev-guidelines": 1, "domain-validated": [2, 1], "organization-validated": [2, 2], "individual-validated": [2, 3] } },
 
-  // id-cp-ipAddr-asNumber (RFC 3779 / RFC 8360) on the id-pkix 14 arc: the RPKI resource-certificate
-  // policy OIDs (sec. 8.9 ints 7-8).
   idCp: { base: [1, 3, 6, 1, 5, 5, 7, 14], of: { "id-cp-ipAddr-asNumber": 2, "id-cp-ipAddr-asNumber-v2": 3 } },
 
-  // GSMA SGP.22 Remote SIM Provisioning roles (sec. 8.9 ints 24-38) on the 2.23.146.1.2.1 id-rspRole arc.
-  // The -v2 roles are shallow leaves .{1..7}; the non-v2 roles descend into deeper sub-arcs (draft-20).
   gsmaRspRole: { base: [2, 23, 146, 1, 2, 1], of: {
     "id-rspRole-ci": 0, "id-rspRole-euicc-v2": 1, "id-rspRole-euicc": [0, 0, 0, 0, 0],
     "id-rspRole-eum-v2": 2, "id-rspRole-eum": [0, 0, 0],
@@ -218,57 +127,29 @@ var FAMILIES = {
     "id-rspRole-ds-tls-v2": 6, "id-rspRole-ds-tls": [0, 0, 2, 0],
     "id-rspRole-ds-auth-v2": 7, "id-rspRole-ds-auth": [0, 0, 2, 1] } },
 
-  // id-qt policy qualifiers (RFC 5280 sec. 4.2.1.4) on the id-pkix 2 arc, which is the C509 sec. 8.10 registry.
   pkixQt: { base: [1, 3, 6, 1, 5, 5, 7, 2], of: { cps: 1, unotice: 2 } },
 
-  // OCSP (RFC 6960) on the id-pkix-ocsp arc (= id-ad-ocsp). id-pkix-ocsp-basic is
-  // the ResponseBytes.responseType this build decodes; id-pkix-ocsp-nonce (sec. 4.4.1)
-  // names the nonce extension; the remaining members name the other OCSP extensions
-  // of RFC 6960 sec. 4.4 and RFC 9654 (CRL references, acceptable-response-types,
-  // archive-cutoff, service-locator, preferred-signature-algorithms, extended-revoke).
   ocsp: { base: [1, 3, 6, 1, 5, 5, 7, 48, 1], of: {
     ocspBasic: 1, ocspNonce: 2, ocspCrl: 3, ocspResponse: 4, ocspNoCheck: 5,
     ocspArchiveCutoff: 6, ocspServiceLocator: 7, ocspPrefSigAlgs: 8, ocspExtendedRevoke: 9 } },
 
-  // CRMF (RFC 4211) registration controls (sec. 6) and registration info (sec. 7) on the
-  // id-pkip arc (id-pkix 5). id-regCtrl (id-pkip 1) names the control types a
-  // CertRequest carries; id-regInfo (id-pkip 2) names the registration-info types.
-  // The parser surfaces each control/info value raw, keyed by these names.
-  // altCertTemplate (7) and the two keySpec controls algId (11) / rsaKeyLen (12) are the RFC 9480
-  // sec. 2.16 additions; a CertReqTemplate response states its key requirements with the latter two.
   regCtrl: { base: [1, 3, 6, 1, 5, 5, 7, 5, 1], of: {
     regToken: 1, authenticator: 2, pkiPublicationInfo: 3, pkiArchiveOptions: 4, oldCertID: 5, protocolEncrKey: 6,
     altCertTemplate: 7, algId: 11, rsaKeyLen: 12 } },
   regInfo: { base: [1, 3, 6, 1, 5, 5, 7, 5, 2], of: { utf8Pairs: 1, certReq: 2 } },
 
-  // PKIX extended key purposes (id-kp, RFC 5280 sec. 4.2.1.12). timeStamping is required,
-  // critical, and sole on an RFC 3161 TSA signing certificate (sec. 2.3). The SSH
-  // (RFC 6187), CMC (RFC 6402), and Bundle Security (RFC 9174) purposes complete the C509
-  // Extended Key Usages registry (draft-ietf-cose-cbor-encoded-cert sec. 8.12).
   pkixKp: { base: [1, 3, 6, 1, 5, 5, 7, 3], of: {
     serverAuth: 1, clientAuth: 2, codeSigning: 3, emailProtection: 4, timeStamping: 8, ocspSigning: 9,
     secureShellClient: 21, secureShellServer: 22, cmcCA: 27, cmcRA: 28, cmcArchive: 29, cmKGA: 32, bundleSecurity: 35 } },
 
-  // Kerberos PKINIT extended key purposes (id-pkinit, RFC 4556 sec. 3.2.3 / 3.2.4): the client
-  // and KDC authentication EKUs (C509 Extended Key Usages registry integers 10 / 11).
   pkinitKp: { base: [1, 3, 6, 1, 5, 2, 3], of: { pkinitClientAuth: 4, pkinitKdc: 5 } },
 
-  // Wi-SUN FAN device extended key purpose (C509 Extended Key Usages registry integer 20).
   wisun: { base: [1, 3, 6, 1, 4, 1, 45605], of: { fanDevice: 1 } },
 
-  // Google Certificate Transparency (RFC 6962) on the 1.3.6.1.4.1.11129.2.4 arc:
-  // the SCT-list X.509 extension (sec. 3.3), the precertificate poison (sec. 3.1), the
-  // precert-signing EKU (sec. 3.1, naming only), and the OCSP-delivered SCT list
-  // (sec. 3.3). The SCT payload itself is TLS presentation language, so it is parsed
-  // by lib/ct.js (pki.ct) and never routed through the DER schema engine.
   ct: { base: [1, 3, 6, 1, 4, 1, 11129, 2, 4], of: {
     signedCertificateTimestampList: 2, precertificatePoison: 3,
     precertificateSigningCert: 4, ocspSignedCertificateTimestampList: 5 } },
 
-  // Fulcio (Sigstore) X.509 certificate-extension arc. `.1.1`-`.1.6` are the
-  // DEPRECATED members whose values are raw UTF-8 strings (no DER wrapping);
-  // `.1.7` is the OtherName SAN type; `.1.8` onward are DER-encoded ASN.1
-  // UTF8String -- the decode MUST honor the raw-vs-DER split by member.
   fulcio: { base: [1, 3, 6, 1, 4, 1, 57264, 1], of: {
     issuerLegacy: 1, githubWorkflowTrigger: 2, githubWorkflowSha: 3,
     githubWorkflowName: 4, githubWorkflowRepository: 5, githubWorkflowRef: 6,
@@ -279,34 +160,25 @@ var FAMILIES = {
     buildConfigURI: 18, buildConfigDigest: 19, buildTrigger: 20,
     runInvocationURI: 21, sourceRepositoryVisibilityAtSigning: 22 } },
 
-  // PKCS#1 RSA public-key + RSASSA signature algorithms.
   rsa: { base: [1, 2, 840, 113549, 1, 1], of: {
     rsaEncryption: 1, rsaesOaep: 7, mgf1: 8, pSpecified: 9, rsassaPss: 10,
     sha256WithRSAEncryption: 11,
     sha384WithRSAEncryption: 12, sha512WithRSAEncryption: 13 } },
 
-  // PKCS#7 / CMS content types (RFC 5652 sec. 4, RFC 2315). id-signedData is the one
-  // this toolkit structurally decodes; the rest are recognized-and-deferred.
   pkcs7: { base: [1, 2, 840, 113549, 1, 7], of: {
     data: 1, signedData: 2, envelopedData: 3, signedAndEnvelopedData: 4,
     digestedData: 5, encryptedData: 6 } },
 
-  // PKCS#9 attribute types, including the CMS signed-attribute OIDs (RFC 5652 sec. 11)
-  // and the PKCS#12 bag attributes friendlyName / localKeyId (RFC 7292 sec. 4.2).
   pkcs9: { base: [1, 2, 840, 113549, 1, 9], of: {
     emailAddress: 1, contentType: 3, messageDigest: 4, signingTime: 5,
     countersignature: 6, challengePassword: 7, extensionRequest: 14,
     smimeCapabilities: 15, friendlyName: 20, localKeyId: 21 } },
 
-  // PKCS#9 CertBag / CRLBag value discriminators (RFC 7292 sec. 4.2.3-sec. 4.2.4).
   pkcs9CertTypes: { base: [1, 2, 840, 113549, 1, 9, 22], of: { x509Certificate: 1, sdsiCertificate: 2 } },
   pkcs9CrlTypes:  { base: [1, 2, 840, 113549, 1, 9, 23], of: { x509CRL: 1 } },
 
-  // PKCS#5 password-based schemes (RFC 8018) + the PBMAC1 MacData arm (RFC 9579).
   pkcs5: { base: [1, 2, 840, 113549, 1, 5], of: { pbkdf2: 12, pbes2: 13, pbmac1: 14 } },
 
-  // CMP InfoTypeAndValue types -- id-it under id-pkix (RFC 9810 sec. 5.3.19; the
-  // PKIXCMP-2023 module assigns these leaves, 8/9 unassigned).
   idIt: { base: [1, 3, 6, 1, 5, 5, 7, 4], of: {
     caProtEncCert: 1, signKeyPairTypes: 2, encKeyPairTypes: 3, preferredSymmAlg: 4,
     caKeyUpdateInfo: 5, currentCRL: 6, unsupportedOIDs: 7, keyPairParamReq: 10,
@@ -315,52 +187,32 @@ var FAMILIES = {
     certReqTemplate: 19, rootCaCert: 20, certProfile: 21, crlStatusList: 22,
     crls: 23, kemCiphertextInfo: 24 } },
 
-  // CMP message-protection MAC algorithms on the Entrust arc (RFC 9810
-  // sec. 5.1.3.1/.2/.4; RFC 9481 sec. 6.1.1).
   entrustAlg: { base: [1, 2, 840, 113533, 7, 66], of: {
     passwordBasedMac: 13, kemBasedMac: 16, dhBasedMac: 30 } },
 
-  // PKCS#12 bag types (RFC 7292 sec. 4.2, Appendix D).
   pkcs12BagTypes: { base: [1, 2, 840, 113549, 1, 12, 10, 1], of: {
     keyBag: 1, pkcs8ShroudedKeyBag: 2, certBag: 3, crlBag: 4, secretBag: 5, safeContentsBag: 6 } },
 
-  // PKCS#12 password-based encryption schemes (RFC 7292 Appendix C). These legacy
-  // PBE identifiers are still emitted by deployed exporters; they are recognized so
-  // a shrouded bag's algorithm resolves to a name, never decrypted here.
   pkcs12Pbe: { base: [1, 2, 840, 113549, 1, 12, 1], of: {
     pbeWithSHAAnd128BitRC4: 1, pbeWithSHAAnd40BitRC4: 2,
     "pbeWithSHAAnd3-KeyTripleDES-CBC": 3, "pbeWithSHAAnd2-KeyTripleDES-CBC": 4,
     "pbeWithSHAAnd128BitRC2-CBC": 5, "pbeWithSHAAnd40BitRC2-CBC": 6 } },
 
-  // RSADSI digest / HMAC algorithms (RFC 8018 sec. B.1) -- the PBKDF2 / PBMAC1 PRFs.
   rsadsiDigest: { base: [1, 2, 840, 113549, 2], of: {
     hmacWithSHA1: 7, hmacWithSHA224: 8, hmacWithSHA256: 9,
     hmacWithSHA384: 10, hmacWithSHA512: 11 } },
 
-  // S/MIME content types on the PKCS#9 smime arc (RFC 5652, RFC 3161): id-ct.
-  // authData is RFC 5652 sec. 9 AuthenticatedData; authEnvelopedData is RFC 5083;
-  // compressedData is RFC 3274 CompressedData.
   smimeCt: { base: [1, 2, 840, 113549, 1, 9, 16, 1], of: { authData: 2, tSTInfo: 4, compressedData: 9, encKeyWithID: 21, authEnvelopedData: 23 } },
 
-  // S/MIME other-recipient-info types (id-ori, RFC 5652 sec. 6.2.5). id-ori-kem
-  // carries a KEMRecipientInfo (RFC 9629) inside the ori [4] RecipientInfo arm.
   smimeOri: { base: [1, 2, 840, 113549, 1, 9, 16, 13], of: { kem: 3 } },
 
-  // S/MIME algorithm identifiers (id-alg). The HKDF KDFs (RFC 8619) and the
-  // CEK-HKDF content-encryption wrapper (RFC 9709) a KEMRecipientInfo names, plus
-  // the RSA-KEM SPKI algorithm (RFC 9690). Parameters are absent for the HKDFs.
   smimeAlg: { base: [1, 2, 840, 113549, 1, 9, 16, 3], of: {
     "id-alg-zlibCompress": 8, "id-alg-PWRI-KEK": 9,
     "id-rsa-kem": 14, "id-alg-hss-lms-hashsig": 17,
-    // RFC 8418 X25519/X448 key-agreement schemes (HKDF-based).
     "dhSinglePass-stdDH-hkdf-sha256-scheme": 19, "dhSinglePass-stdDH-hkdf-sha384-scheme": 20,
     "dhSinglePass-stdDH-hkdf-sha512-scheme": 21,
     hkdfWithSha256: 28, hkdfWithSha384: 29, hkdfWithSha512: 30, cekHkdfSha256: 31 } },
 
-  // RFC 5753 ephemeral-static ECDH key-agreement schemes -- the keyEncryptionAlgorithm OID of a
-  // kari, whose PARAMETER is the KeyWrapAlgorithm (so these are not params-absent). The X9.63 KDF
-  // variants: stdDH (SECG arc 1.3.132.1.11) + cofactorDH (1.3.132.1.14) for SHA-224/256/384/512,
-  // and the SHA-1 KDF pair on the ANSI-X9.63 arc (the OpenSSL default).
   secgStdDH: { base: [1, 3, 132, 1, 11], of: {
     "dhSinglePass-stdDH-sha224kdf-scheme": 0, "dhSinglePass-stdDH-sha256kdf-scheme": 1,
     "dhSinglePass-stdDH-sha384kdf-scheme": 2, "dhSinglePass-stdDH-sha512kdf-scheme": 3 } },
@@ -370,22 +222,10 @@ var FAMILIES = {
   x963Schemes: { base: [1, 3, 133, 16, 840, 63, 0], of: {
     "dhSinglePass-stdDH-sha1kdf-scheme": 2, "dhSinglePass-cofactorDH-sha1kdf-scheme": 3 } },
 
-  // PKIX algorithms arc -- the stateful hash-based signature algorithm
-  // identifiers (RFC 9802 sec. 4). HSS/LMS additionally has the SMIME
-  // id-alg-hss-lms-hashsig OID above (RFC 9708 / RFC 9802 share it).
   pkixAlg: { base: [1, 3, 6, 1, 5, 5, 7, 6], of: {
-    // id-alg-noSignature (RFC 6402 sec. 2.4, {id-pkix id-alg(6) 2}): the CMC
-    // "signature" algorithm for a request whose signer has no key yet; the
-    // SignerInfo carries a MAC-based proof instead. Registered so a decoder can
-    // name it and refuse it deliberately.
     "id-alg-noSignature": 2,
-    // RSASSA-PSS with SHAKE (RFC 8692): RSA signature algorithms on the PKIX arc.
-    // Registered so a consumer can name them -- e.g. the CMP keySpec RSA exclusion.
     "id-RSASSA-PSS-SHAKE128": 30, "id-RSASSA-PSS-SHAKE256": 31,
     "id-alg-xmss-hashsig": 34, "id-alg-xmssmt-hashsig": 35,
-    // Composite ML-DSA signature algorithms (draft-ietf-lamps-pq-composite-sigs
-    // sec. 6): a PQ ML-DSA paired with a traditional RSA / ECDSA / EdDSA so the
-    // certificate stays trustworthy if EITHER primitive is later broken.
     "id-MLDSA44-RSA2048-PSS-SHA256": 37, "id-MLDSA44-RSA2048-PKCS15-SHA256": 38,
     "id-MLDSA44-Ed25519-SHA512": 39, "id-MLDSA44-ECDSA-P256-SHA256": 40,
     "id-MLDSA65-RSA3072-PSS-SHA512": 41, "id-MLDSA65-RSA3072-PKCS15-SHA512": 42,
@@ -395,9 +235,6 @@ var FAMILIES = {
     "id-MLDSA87-ECDSA-P384-SHA512": 49, "id-MLDSA87-ECDSA-brainpoolP384r1-SHA512": 50,
     "id-MLDSA87-Ed448-SHAKE256": 51, "id-MLDSA87-RSA3072-PSS-SHA512": 52,
     "id-MLDSA87-RSA4096-PSS-SHA512": 53, "id-MLDSA87-ECDSA-P521-SHA512": 54,
-    // Composite ML-KEM key-establishment algorithms (draft-ietf-lamps-pq-composite-kem
-    // sec. 6): a PQ ML-KEM paired with a traditional RSA-OAEP / ECDH / X25519 / X448 so the
-    // established secret stays safe if EITHER primitive is later broken.
     "id-MLKEM768-RSA2048-SHA3-256": 55, "id-MLKEM768-RSA3072-SHA3-256": 56,
     "id-MLKEM768-RSA4096-SHA3-256": 57, "id-MLKEM768-X25519-SHA3-256": 58,
     "id-MLKEM768-ECDH-P256-SHA3-256": 59, "id-MLKEM768-ECDH-P384-SHA3-256": 60,
@@ -405,82 +242,35 @@ var FAMILIES = {
     "id-MLKEM1024-ECDH-P384-SHA3-256": 63, "id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256": 64,
     "id-MLKEM1024-X448-SHA3-256": 65, "id-MLKEM1024-ECDH-P521-SHA3-256": 66 } },
 
-  // RSA-KEM key-transport algorithm (RFC 9690, obsoletes RFC 5990) on the ISO
-  // 18033-2 arc -- the kem OID an RSA KEMRecipientInfo carries (distinct from the
-  // id-rsa-kem SPKI algorithm above).
   iso18033: { base: [1, 0, 18033, 2, 2], of: { "id-kem-rsa": 4 } },
 
-  // RFC 3370 HMAC-SHA-1 MAC algorithm (the AuthenticatedData macAlgorithm on the
-  // PKIX arc, distinct from the RSADSI hmacWithSHA1).
   pkixHmac: { base: [1, 3, 6, 1, 5, 5, 8, 1], of: { "hmac-SHA1": 2 } },
 
-  // S/MIME authenticated attributes (id-aa, RFC 2634 / RFC 5035 / RFC 5816). The ESS
-  // signing-certificate attributes bind a CMS / TSP SignerInfo to its signing cert;
-  // signingCertificateV2 (ESSCertIDv2) carries a non-SHA-1 cert hash (RFC 5816 sec. 2.2.1).
-  // The RFC 2634 originals (receiptRequest .. contentReference) are name-only: they
-  // resolve to a name so an unsupported-attribute diagnostic is legible, not decoded.
-  // decryptKeyID / asymmDecryptKeyID name the out-of-band key-encryption key a
-  // /serverkeygen client references (RFC 4108 sec. 2.2.5 / RFC 7030 sec. 4.4.1);
-  // certificationRequestInfoTemplate / extensionReqTemplate are the RFC 9908
-  // CSR-attributes template carriers.
   smimeAa: { base: [1, 2, 840, 113549, 1, 9, 16, 2], of: {
     receiptRequest: 1, eSSSecurityLabel: 2, mlExpansionHistory: 3, contentHints: 4,
     msgSigDigest: 5, contentIdentifier: 7, equivalentLabels: 9, contentReference: 10,
     signingCertificate: 12, timeStampToken: 14, decryptKeyID: 37, signingCertificateV2: 47,
-    // id-aa-cmc-unsignedData (RFC 6402 sec. 2.7, {id-aa 34}): the CMC unsigned
-    // attribute that carries body parts too large to sit inside the signed
-    // PKIData. It is unsigned by design, so a consumer must treat its contents
-    // as untrusted data.
     cmcUnsignedData: 34,
     asymmDecryptKeyID: 54, certificationRequestInfoTemplate: 61, extensionReqTemplate: 62 } },
 
-  // ANSI X9.62 EC public key, named curve, and ECDSA signatures.
   ansiX962: { base: [1, 2, 840, 10045], of: {
     ecPublicKey: [2, 1], prime256v1: [3, 1, 7],
     ecdsaWithSHA256: [4, 3, 2], ecdsaWithSHA384: [4, 3, 3], ecdsaWithSHA512: [4, 3, 4] } },
 
-  // SECG named curves.
   secg: { base: [1, 3, 132, 0], of: { secp384r1: 34, secp521r1: 35 } },
 
-  // Brainpool named curves (RFC 5639).
   brainpool: { base: [1, 3, 36, 3, 3, 2, 8, 1, 1], of: { brainpoolP256r1: 7, brainpoolP384r1: 11 } },
 
-  // Edwards / Montgomery curves (RFC 8410).
   edwards: { base: [1, 3, 101], of: { X25519: 110, X448: 111, Ed25519: 112, Ed448: 113 } },
 
-  // OIW Secsig SHA-1 (1.3.14.3.2.26) -- the most common OCSP CertID hashAlgorithm;
-  // nistHash covers only SHA-256 and above.
-  // OIW Secsig arc (1.3.14.3.2). id-SHA1 (.26) plus every RSA identifier the OIW SIG assigned under the
-  // arc: md4WithRSA (.2), md5WithRSA (.3), md4WithRSAEncryption (.4), rsaSignature (.11, the ISO 9796 RSA
-  // scheme), mdc2WithRSASignature (.14), shaWithRSAEncryption (.15), rsaKeyTransport (.22), and the
-  // md2/md5/sha1-WithRSASignature set (.24/.25/.29) -- pre-PKCS#1 RSA algorithms still seen in old certs.
-  // This is the arc's complete RSA membership per the OIW SIG assignments. Registered so a consumer can
-  // name them -- e.g. the CMP keySpec RSA exclusion, which recognizes RSA wherever it is standardized.
-  // The arc is shared with DES, DSA, DH, and the hashes, so no prefix isolates RSA; each is named.
   oiwSecsig: { base: [1, 3, 14, 3, 2], of: {
     sha1: 26,
     "md4WithRSA": 2, "md5WithRSA": 3, "md4WithRSAEncryption": 4, "rsaSignature": 11,
     "mdc2WithRSASignature": 14, "shaWithRSAEncryption": 15, "rsaKeyTransport": 22,
     "md2WithRSASignature": 24, "md5WithRSASignature": 25, "sha1WithRSASignature": 29 } },
 
-  // TeleTrusT (BSI) RSA signature arc (1.3.36.3.3.1) -- RSA signatures with SHA-1 and the RIPEMD family.
-  // The arc is RSA-dedicated, so a consumer can classify the whole family by its prefix; one member is
-  // registered here so that prefix can be derived from the registry rather than a dotted-decimal literal.
   teletrustRsaSig: { base: [1, 3, 36, 3, 3, 1], of: { "rsaSignatureWithripemd160": 2 } },
 
-  // TeleTrusT (BSI) signatureScheme arc (1.3.36.3.4) -- the ISO/IEC 9796-2 RSA signatures giving message
-  // recovery (schemes 1/2/3: two deterministic, one randomized). ISO/IEC 9796-2 is titled "integer
-  // factorization based mechanisms", so EVERY scheme it defines is RSA and the standard has no non-RSA
-  // member; each node is registered so a consumer can name it -- e.g. the CMP keySpec RSA exclusion, which
-  // must recognize RSA wherever it is standardized. ISO/IEC 9796-2 assigns no algorithm OIDs of its own;
-  // this registrant tree is the de-facto registry. The .2 (deterministic) and .3 (randomized) sub-arcs are
-  // RSA-dedicated in full -- every descendant is RSA -- so a consumer prefix-matches each to catch a hash
-  // variant added later; the per-hash leaves are registered for readability. The `...Withrsa-even-exp`
-  // nodes (.2.1 / .3.1) are the even-public-exponent RSA variants the registrant marks "not used"; they are
-  // RSA (the registrant names them `sigS_ISO9796-2Withrsa_even-exp`), so the sub-arc prefix classifies them
-  // correctly, not wrongly. .1 is ISO/IEC 9796-1, also RSA, on the same arc. The PARENT node (.4) is generic
-  // "signatureScheme" and the sibling authentication arc (.5) is mixed (its .5.3 children are ECC), so
-  // neither is RSA-dedicated -- a consumer must not prefix-match the parent or .5.
   teletrustSigScheme: { base: [1, 3, 36, 3, 4], of: {
     "sigS-ISO9796-1": 1, "sigS-ISO9796-1-DFUE": [1, 1],
     "sigS-ISO9796-2": 2, "sigS-ISO9796-2Withrsa-even-exp": [2, 1], "sigS-ISO9796-2Withrsa": [2, 2],
@@ -492,52 +282,25 @@ var FAMILIES = {
     "sigS-ISO9796-2rndWithrsa-sha224": [3, 2, 3], "sigS-ISO9796-2rndWithrsa-sha256": [3, 2, 4],
     "sigS-ISO9796-2rndWithrsa-sha384": [3, 2, 5], "sigS-ISO9796-2rndWithrsa-sha512": [3, 2, 6] } },
 
-  // X.509 directory encryptionAlgorithm arc (2.5.8.1). id-ea-rsa (.1) is the X.509 `rsa` public-key
-  // identifier, distinct from PKCS#1 rsaEncryption. Registered so a consumer can name it -- e.g. the
-  // CMP keySpec RSA exclusion, which must recognize RSA wherever it is standardized.
   x509EncAlg: { base: [2, 5, 8, 1], of: { "rsa": 1 } },
 
-  // X.500 directory signatureAlgorithm arc (2.5.8.3). Its RSA members are sqMod-nWithRSA (.1, the
-  // ITU-T X.509 / ISO 9594-8 square-mod-n-with-RSA signature) and mdc2WithRSA (.100, MDC-2-with-RSA).
-  // Registered so the CMP keySpec RSA exclusion can name them; the arc is not RSA-dedicated, so each
-  // member is named individually rather than prefix-matched.
   x509SigAlg: { base: [2, 5, 8, 3], of: { "sqMod-nWithRSA": 1, "mdc2WithRSA": 100 } },
 
-  // Chinese GM/T (SCA) SM algorithm arc (1.2.156.10197.1). Its one RSA member is sm3WithRSAEncryption
-  // (.504, a PKCS#1 v1.5 RSA signature over an SM3 digest); sm2 (.301), sm3 (.401), and SM2-with-SM3
-  // (.501) on the arc are not RSA. Registered so the CMP keySpec RSA exclusion can name it -- the arc is
-  // mixed, so the RSA member is named individually rather than prefix-matched.
   smAlg: { base: [1, 2, 156, 10197, 1], of: { "sm3WithRSAEncryption": 504 } },
 
-  // BSI TR-03110 EAC Terminal Authentication RSA arc (0.4.0.127.0.7.2.2.2.1, id-TA-RSA). Every child is an
-  // RSA signature scheme -- PKCS#1 v1.5 or PSS over SHA-1/256/512 -- and the sibling id-TA-ECDSA arc
-  // (0.4.0.127.0.7.2.2.2.2) is EC, so this arc is RSA-dedicated. The members are registered so a consumer
-  // can derive the arc prefix from the registry rather than a dotted-decimal literal and classify the
-  // whole family, including a variant BSI adds later, by that prefix.
   bsiTaRsa: { base: [0, 4, 0, 127, 0, 7, 2, 2, 2, 1], of: {
     "id-TA-RSA-v1-5-SHA-1": 1, "id-TA-RSA-v1-5-SHA-256": 2, "id-TA-RSA-PSS-SHA-1": 3,
     "id-TA-RSA-PSS-SHA-256": 4, "id-TA-RSA-v1-5-SHA-512": 5, "id-TA-RSA-PSS-SHA-512": 6 } },
 
-  // NIST AES content-encryption algorithms (arc 2.16.840.1.101.3.4.1) -- the
-  // modern PBES2 / CMS content ciphers a PKCS#12 or EnvelopedData names.
   nistAes: { base: [2, 16, 840, 1, 101, 3, 4, 1], of: {
     "aes128-CBC": 2, "aes128-wrap": 5, "aes128-GCM": 6, "aes128-CCM": 7,
     "aes192-CBC": 22, "aes192-wrap": 25, "aes192-GCM": 26, "aes192-CCM": 27,
     "aes256-CBC": 42, "aes256-wrap": 45, "aes256-GCM": 46, "aes256-CCM": 47 } },
 
-  // NIST hash functions (SHA-2, SHA-3, SHAKE).
   nistHash: { base: [2, 16, 840, 1, 101, 3, 4, 2], of: {
     sha256: 1, sha384: 2, sha512: 3, "sha3-256": 8, "sha3-512": 10, shake128: 11, shake256: 12 } },
 
-  // NIST signature algorithms -- FIPS 204 ML-DSA + FIPS 205 SLH-DSA share the
-  // signature arc 2.16.840.1.101.3.4.3. RFC 9909 sec. 3 assigns the 12 Pure SLH-DSA
-  // sets .20-.31 (SHA-2 .20-.25, SHAKE .26-.31) and the 12 pre-hash HashSLH-DSA
-  // sets .35-.46, each pairing a parameter set with its message-digest hash. The
-  // parameters MUST be absent for every one of them (enforced via paramsMustBeAbsent).
   nistSig: { base: [2, 16, 840, 1, 101, 3, 4, 3], of: {
-    // RSASSA-PKCS1-v1_5 with SHA-3 (NIST CSOR): RSA signature algorithms on the NIST
-    // signature arc, alongside the ML-DSA / SLH-DSA sets. Registered so a consumer can
-    // name them -- e.g. the CMP keySpec check that must recognize RSA to exclude it.
     "id-rsassa-pkcs1-v1_5-with-sha3-224": 13, "id-rsassa-pkcs1-v1_5-with-sha3-256": 14,
     "id-rsassa-pkcs1-v1_5-with-sha3-384": 15, "id-rsassa-pkcs1-v1_5-with-sha3-512": 16,
     "id-ml-dsa-44": 17, "id-ml-dsa-65": 18, "id-ml-dsa-87": 19,
@@ -554,45 +317,23 @@ var FAMILIES = {
     "id-hash-slh-dsa-shake-192s-with-shake256": 43, "id-hash-slh-dsa-shake-192f-with-shake256": 44,
     "id-hash-slh-dsa-shake-256s-with-shake256": 45, "id-hash-slh-dsa-shake-256f-with-shake256": 46 } },
 
-  // NIST KEM -- FIPS 203 ML-KEM (arc 2.16.840.1.101.3.4.4).
   nistKem: { base: [2, 16, 840, 1, 101, 3, 4, 4], of: {
     "id-ml-kem-512": 1, "id-ml-kem-768": 2, "id-ml-kem-1024": 3 } },
 
-  // Misc datatypes (RFC 4519 domainComponent).
   datatype: { base: [0, 9, 2342, 19200300, 100, 1], of: { domainComponent: 25 } },
 
-  // FIDO Alliance generated-credential certificate extensions (arc
-  // 1.3.6.1.4.1.45724.1.1). id-fido-gen-ce-aaguid carries the authenticator's
-  // AAGUID -- a WebAuthn packed-attestation leaf-cert extension (WebAuthn L3 8.2.1)
-  // whose OCTET STRING value MUST equal the attestedCredentialData aaguid.
   fidoGenCe: { base: [1, 3, 6, 1, 4, 1, 45724, 1, 1], of: { idFidoGenCeAaguid: 4 } },
 
-  // Android Keystore key-attestation extension (arc 1.3.6.1.4.1.11129.2.1). The
-  // keyDescription extension carries the hardware-backed KeyDescription SEQUENCE a
-  // WebAuthn android-key attestation leaf cert asserts (WebAuthn L3 8.4.1).
   androidKeystore: { base: [1, 3, 6, 1, 4, 1, 11129, 2, 1], of: { keyDescription: 17 } },
 
-  // Apple anonymous-attestation extension (arc 1.2.840.113635.100.8). The value in
-  // a WebAuthn apple attestation leaf cert embeds the SHA-256 nonce over
-  // authenticatorData || clientDataHash (WebAuthn L3 8.8).
   appleAttest: { base: [1, 2, 840, 113635, 100, 8], of: { appleAnonymousAttestation: 2 } },
 
-  // TCG (Trusted Computing Group) TPM identifiers on the 2.23.133 arc. tcgKp
-  // (id-tcg-kp) names the AIK-certificate extended key purpose a WebAuthn tpm
-  // attestation leaf cert MUST carry; tcgAt (id-tcg-at) names the tpmManufacturer /
-  // tpmModel / tpmVersion directory attributes its subjectAltName MUST carry
-  // (WebAuthn L3 8.3.1).
   tcgKp: { base: [2, 23, 133, 8], of: { tcgKpAikCertificate: 3 } },
   tcgAt: { base: [2, 23, 133, 2], of: { tpmManufacturer: 1, tpmModel: 2, tpmVersion: 3 } },
 
-  // SCEP (RFC 8894) transaction attributes on the VeriSign arc 2.16.840.1.113733.1.9
-  // (id-attributes). scep-prefixed because the CMC arc already registers senderNonce /
-  // transactionId under different OIDs (RFC 8894 sec. 3.2.1, Tables 1-2).
   scepAttribute: { base: [2, 16, 840, 1, 113733, 1, 9], of: {
     scepMessageType: 2, scepPkiStatus: 3, scepFailInfo: 4,
     scepSenderNonce: 5, scepRecipientNonce: 6, scepTransactionId: 7 } },
-  // id-scep on the PKIX arc 1.3.6.1.5.5.7.24; failInfoText is the only leaf SCEP uses
-  // (RFC 8894 sec. 3.2.1.4).
   scep: { base: [1, 3, 6, 1, 5, 5, 7, 24], of: { scepFailInfoText: 1 } },
 };
 
@@ -601,44 +342,26 @@ var _byName = new Map();
 
 function _index(dotted, name) {
   _byOid.set(dotted, name);
-  // First registration of a name wins as the canonical reverse entry.
   if (!_byName.has(name)) _byName.set(name, dotted);
 }
 
-// An arc is a non-negative integer. Large arcs (a 128-bit UUID-based arc
-// exceeds 2^53) must be BigInt to survive without precision loss, so both
-// a non-negative safe-integer Number and a non-negative BigInt are valid.
 function _isArc(a) {
   if (typeof a === "bigint") return a >= 0n;
   return typeof a === "number" && Number.isSafeInteger(a) && a >= 0;
 }
 
-// Seed the registry family by family -- the built-in set is registered through
-// the exact same primitive an operator uses (registerFamily), so there is one
-// path from a declared family to indexed OIDs and no dotted literals anywhere.
 Object.keys(FAMILIES).forEach(function (fam) {
   registerFamily(FAMILIES[fam].base, FAMILIES[fam].of);
 });
 
 function _assertDotted(dotted, who) {
-  // SYNTAX only (canonical dotted form, no leading-zero arc that would round-trip
-  // to a DIFFERENT OID). For the LOOKUP entry points (name / has): a well-formed
-  // but non-encodable OID is simply not registered (a miss), not an error, so the
-  // X.660 arc bounds are waived (boundsCode null).
   guard.identifier.assertCanonicalOid(dotted, _oidError, "oid/bad-input", who, null);
 }
 
 function _assertEncodable(dotted, who) {
-  // SYNTAX and the X.660 arc bounds -- for the paths that assert / convert a real
-  // encodable OID (toArcs / toDER / register), where an out-of-bounds arc is a
-  // hard reject (oid/bad-arc), so the string form agrees with the DER form.
   guard.identifier.assertCanonicalOid(dotted, _oidError, "oid/bad-input", who, "oid/bad-arc");
 }
 
-// X.660 encodability: the root arc is 0..2 and, under roots 0 and 1, the
-// second arc is 0..39 (the first two arcs pack into a single octet as
-// 40*X+Y). An OID outside these bounds can never be DER-encoded, so a
-// registration carrying one fails at config time, before anything tries to use it.
 function _assertEncodableArcs(arcs, who) {
   if (arcs.length < 2) {
     throw new OidError("oid/bad-input", who + ": an OID must have at least 2 arcs");
@@ -674,16 +397,13 @@ function byName(n) {
   return _byName.get(n);
 }
 
-// Does `s` look like a dotted-decimal OID -- one or more digit groups joined by single dots (at least two
-// groups, no leading/trailing/doubled dot)? Distinguishes a numeric OID from a symbolic name so a caller may
-// pass either. Decided by character scan (no regex); the arc-value bounds are the encoder's authority.
 function isDottedDecimal(s) {
   if (typeof s !== "string" || s.length === 0) return false;
   var i, c, sawDot = false, atomEmpty = true;
   for (i = 0; i < s.length; i += 1) {
     c = s.charCodeAt(i);
-    if (c === 46) { if (atomEmpty) return false; sawDot = true; atomEmpty = true; }   // "."
-    else if (c >= 48 && c <= 57) { atomEmpty = false; }                               // 0-9
+    if (c === 46) { if (atomEmpty) return false; sawDot = true; atomEmpty = true; }
+    else if (c >= 48 && c <= 57) { atomEmpty = false; }
     else return false;
   }
   return sawDot && !atomEmpty;
@@ -711,9 +431,6 @@ function has(dotted) {
  *   pki.oid.register("1.3.6.1.4.1.99999.1", "acmeWidgetPolicy");
  */
 function register(dotted, n) {
-  // _assertDotted now enforces the X.660 arc bounds on the string form too, so
-  // the separate arc-based check register used to run is redundant here (it is
-  // kept for registerFamily, which validates arcs it assembles, not a string).
   _assertEncodable(dotted, "register");
   if (typeof n !== "string" || n.length === 0) throw new OidError("oid/bad-input", "register: name must be a non-empty string");
   _index(dotted, n);
@@ -771,9 +488,6 @@ function all() {
   return out;
 }
 
-// toArcs / fromArcs -- dotted <-> numeric arc array. Arcs come back as
-// Number where safe and BigInt where an arc exceeds 2^53 (rare, but a
-// UUID-based OID arc can), so the round-trip never loses precision.
 function toArcs(dotted) {
   _assertEncodable(dotted, "toArcs");
   return dotted.split(".").map(function (p) {
@@ -794,8 +508,6 @@ function fromArcs(arcs) {
   }).join(".");
 }
 
-// DER convenience -- thin pass-throughs to the codec so callers reach for
-// one namespace when they have a dotted string in hand.
 function toDER(dotted) { _assertEncodable(dotted, "toDER"); return asn1.build.oid(dotted); }
 function fromDER(input) {
   var buf = guard.bytes.view(input, OidError, "oid/bad-input", "fromDER");
@@ -803,14 +515,6 @@ function fromDER(input) {
   return asn1.read.oid(node);
 }
 
-// Algorithm identifiers whose `parameters` field MUST be absent -- no explicit
-// NULL, no bytes. The FIPS 204 ML-DSA and FIPS 205 SLH-DSA signature families
-// and the RFC 8410 Edwards / Montgomery curves each carry this MUST: RFC 9909 sec. 3
-// (SLH-DSA in X.509), RFC 9814 sec. 4 (SLH-DSA in CMS), RFC 9881 sec. 2 (ML-DSA in X.509),
-// RFC 8410 sec. 3 (Ed25519 / Ed448 / X25519 / X448). Built by NAME through the same
-// registry every caller uses, so a typo fails closed at load rather than silently
-// dropping a member. One set drives the single shared AlgorithmIdentifier reject
-// (schema-pkix), so every format consumer inherits the rule with no per-format code.
 var _PARAMS_ABSENT = new Set();
 [
   "id-ml-dsa-44", "id-ml-dsa-65", "id-ml-dsa-87",
@@ -818,7 +522,6 @@ var _PARAMS_ABSENT = new Set();
   "id-slh-dsa-sha2-192f", "id-slh-dsa-sha2-256s", "id-slh-dsa-sha2-256f",
   "id-slh-dsa-shake-128s", "id-slh-dsa-shake-128f", "id-slh-dsa-shake-192s",
   "id-slh-dsa-shake-192f", "id-slh-dsa-shake-256s", "id-slh-dsa-shake-256f",
-  // Pre-hash HashSLH-DSA sets (RFC 9909 sec. 3) -- parameters MUST be absent too.
   "id-hash-slh-dsa-sha2-128s-with-sha256", "id-hash-slh-dsa-sha2-128f-with-sha256",
   "id-hash-slh-dsa-sha2-192s-with-sha512", "id-hash-slh-dsa-sha2-192f-with-sha512",
   "id-hash-slh-dsa-sha2-256s-with-sha512", "id-hash-slh-dsa-sha2-256f-with-sha512",
@@ -826,16 +529,9 @@ var _PARAMS_ABSENT = new Set();
   "id-hash-slh-dsa-shake-192s-with-shake256", "id-hash-slh-dsa-shake-192f-with-shake256",
   "id-hash-slh-dsa-shake-256s-with-shake256", "id-hash-slh-dsa-shake-256f-with-shake256",
   "Ed25519", "Ed448", "X25519", "X448",
-  // FIPS 203 ML-KEM (RFC 9935 sec. 3 certificates + RFC 9936 sec. 3 CMS: PARAMS ARE absent).
   "id-ml-kem-512", "id-ml-kem-768", "id-ml-kem-1024",
-  // HKDF key-derivation identifiers (RFC 8619 sec. 2: when any of these appear
-  // within AlgorithmIdentifier, the parameters component SHALL be absent).
   "hkdfWithSha256", "hkdfWithSha384", "hkdfWithSha512",
-  // Stateful hash-based signatures (RFC 9802 sec. 4 / RFC 9708): the parameters
-  // field MUST be absent for HSS/LMS, XMSS, and XMSS^MT public keys and signatures.
   "id-alg-hss-lms-hashsig", "id-alg-xmss-hashsig", "id-alg-xmssmt-hashsig",
-  // Composite ML-DSA (draft-ietf-lamps-pq-composite-sigs sec. 5.3 + Figure 1:
-  // the parameters field MUST be absent for every composite AlgorithmIdentifier).
   "id-MLDSA44-RSA2048-PSS-SHA256", "id-MLDSA44-RSA2048-PKCS15-SHA256",
   "id-MLDSA44-Ed25519-SHA512", "id-MLDSA44-ECDSA-P256-SHA256",
   "id-MLDSA65-RSA3072-PSS-SHA512", "id-MLDSA65-RSA3072-PKCS15-SHA512",
@@ -845,8 +541,6 @@ var _PARAMS_ABSENT = new Set();
   "id-MLDSA87-ECDSA-P384-SHA512", "id-MLDSA87-ECDSA-brainpoolP384r1-SHA512",
   "id-MLDSA87-Ed448-SHAKE256", "id-MLDSA87-RSA3072-PSS-SHA512",
   "id-MLDSA87-RSA4096-PSS-SHA512", "id-MLDSA87-ECDSA-P521-SHA512",
-  // Composite ML-KEM (draft-ietf-lamps-pq-composite-kem sec. 5.3: the parameters
-  // field MUST be absent for every composite KEM AlgorithmIdentifier).
   "id-MLKEM768-RSA2048-SHA3-256", "id-MLKEM768-RSA3072-SHA3-256",
   "id-MLKEM768-RSA4096-SHA3-256", "id-MLKEM768-X25519-SHA3-256",
   "id-MLKEM768-ECDH-P256-SHA3-256", "id-MLKEM768-ECDH-P384-SHA3-256",
@@ -855,9 +549,6 @@ var _PARAMS_ABSENT = new Set();
   "id-MLKEM1024-X448-SHA3-256", "id-MLKEM1024-ECDH-P521-SHA3-256",
 ].forEach(function (nm) {
   var d = byName(nm);
-  // A seed-list typo must fail at module load -- admitting undefined would
-  // make paramsMustBeAbsent(byName(sameTypo)) return TRUE for every other
-  // unregistered name (Set.has(undefined)), a fail-open guard.
   if (typeof d !== "string") throw new OidError("oid/unknown-name", "paramsMustBeAbsent seed: " + JSON.stringify(nm) + " is not a registered name");
   _PARAMS_ABSENT.add(d);
 });
@@ -886,38 +577,15 @@ function paramsMustBeAbsent(dotted) {
   return _PARAMS_ABSENT.has(dotted);
 }
 
-// ---- ML-KEM parameter sets (FIPS 203 Table 3) --------------------------------
-//
-// ONE row per parameter set, resolvable by dotted OID or by registered name, because the
-// consumers hold different currencies: the CMS codec and the decrypt path key by OID, the
-// linter keys by the SPKI algorithm's name. Before this table the same FIPS 203 constants
-// lived in three modules -- schema-cms's ciphertext lengths, webcrypto's {ek, dk}, and
-// lint's encapsulation-key lengths -- so a fourth consumer (a composite KEM, an HPKE row,
-// HQC by analogy) meant a fourth copy, and the ek values were already duplicated verbatim
-// in two of them. A parameter set is a property OF the algorithm identifier, so it lives
-// beside the registry that resolves one rather than in whichever module needed it first.
-//
-//   ek : encapsulation-key octets      dk : decapsulation-key octets
-//   ct : ciphertext octets             ss : shared-secret octets
-// A null-prototype table: a plain object would answer kemParams("toString") with a function
-// inherited from Object.prototype, so the documented fail-closed contract would hold for every
-// input EXCEPT the handful every object already carries -- exactly the ones an untrusted
-// identifier might be.
 var KEM_PARAMS = Object.create(null);
 [["id-ml-kem-512", 800, 1632, 768, 32],
   ["id-ml-kem-768", 1184, 2400, 1088, 32],
   ["id-ml-kem-1024", 1568, 3168, 1568, 32]].forEach(function (r) {
-  // FROZEN, because these rows are reachable from the public surface AND one of them now governs a
-  // security check: the engine reads .ct to enforce the FIPS 203 sec. 7.3 ciphertext length. A shared
-  // mutable row would let any code in the process rewrite that bound once, for every later call --
-  // a parameter set is a fact about the algorithm, not a setting an application may retune.
   var row = Object.freeze({ ek: r[1], dk: r[2], ct: r[3], ss: r[4] });
-  KEM_PARAMS[byName(r[0])] = row;   // by dotted OID
-  KEM_PARAMS[r[0]] = row;           // and by registered name -- the same frozen row
+  KEM_PARAMS[byName(r[0])] = row;
+  KEM_PARAMS[r[0]] = row;
 });
 Object.freeze(KEM_PARAMS);
-// kemParams(oidOrName) -> the row, or undefined for anything that is not an ML-KEM
-// parameter set. Undefined is the caller's signal to fail closed; it never guesses a size.
 function kemParams(oidOrName) { return KEM_PARAMS[oidOrName]; }
 
 module.exports = {