@blamejs/pki 0.4.14 → 0.5.0

package/lib/oid.js

@@ -132,7 +132,65 @@ var FAMILIES = {
   // 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-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,
+    "id-cmc-recipientNonce": 7, "id-cmc-addExtensions": 8, "id-cmc-encryptedPOP": 9,
+    "id-cmc-decryptedPOP": 10, "id-cmc-lraPOPWitness": 11,
+    "id-cmc-getCert": 15, "id-cmc-getCRL": 16, "id-cmc-revokeRequest": 17,
+    "id-cmc-regInfo": 18, "id-cmc-responseInfo": 19,
+    "id-cmc-queryPending": 21, "id-cmc-popLinkRandom": 22, "id-cmc-popLinkWitness": 23,
+    "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) ONLY
+    //
+    // 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),
@@ -312,6 +370,11 @@ var FAMILIES = {
   // 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, rather than meeting an unknown OID.
+    "id-alg-noSignature": 2,
     "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
@@ -348,6 +411,11 @@ var FAMILIES = {
     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 -- unsigned by design, so a consumer must treat its contents as
+    // untrusted data rather than as part of the authenticated message.
+    cmcUnsignedData: 34,
     asymmDecryptKeyID: 54, certificationRequestInfoTemplate: 61, extensionReqTemplate: 62 } },
 
   // ANSI X9.62 EC public key, named curve, and ECDSA signatures.