@blamejs/pki 0.5.24 → 0.5.26

package/lib/crmf-sign.js

@@ -33,6 +33,14 @@ var pkix = require("./schema-pkix");
 var pkiBuild = require("./pki-build");
 var frameworkError = require("./framework-error");
 var guard = require("./guard-all");
+var intrinsic = require("./guard-intrinsic");
+// Own-key membership through an operation taken at load: it decides which proof-of-possession
+// alternative a request carries, and a name reached from the prototype is one the RFC never defined.
+var _hasOwn = intrinsic.hasOwn;
+var _stringify = intrinsic.stringify;
+var cms = require("./schema-cms");
+var cmsEncrypt = require("./cms-encrypt");
+var key = require("./key");
 require("./path-validate");   // side-effect: path-validate injects its signature engine into crmf-verify at load
 var crmfVerify = require("./crmf-verify");
 
@@ -50,6 +58,28 @@ var _b = pkiBuild.makeBuilder({
 });
 
 var KNOWN_SPEC_KEYS = { certReqId: 1, certTemplate: 1, controls: 1, regInfo: 1, pop: 1 };
+// spec.pop across all four ProofOfPossession arms: `type` picks the arm; `raVerified` and `sender`
+// belong to the raVerified / signature arms; the rest to POPOPrivKey (RFC 4211 sec. 4.2, 4.3).
+// spec.pop is a CHOICE, so the accepted key set is per ARM rather than a union of all of them. A
+// single flat list would accept `{ type: 'keyEncipherment', method: 'subsequentMessage', privateKey,
+// recipients, archive: true }`: a caller who believed they were sending the key that way gets a
+// message that declares a later exchange instead, with the three fields they supplied read by
+// nothing. `type` and `method` are what pick the arm, so they are read first and the rest is checked
+// against the arm the caller chose.
+var POP_KEYS_BY_ARM = {
+  raVerified: { type: 1, raVerified: 1 },
+  signature: { type: 1, sender: 1 },
+  subsequentMessage: { type: 1, method: 1, subsequentMessage: 1 },
+  encryptedKey: {
+    type: 1, method: 1, privateKey: 1, identifier: 1, recipients: 1, archive: 1,
+    contentEncryptionAlgorithm: 1,
+  },
+  // The arms that refuse before they read anything else still need a set, so the refusal a caller
+  // sees names the method rather than an unknown field alongside it.
+  agreeMAC: { type: 1, method: 1 },
+  thisMessage: { type: 1, method: 1 },
+  dhMAC: { type: 1, method: 1 },
+};
 var KNOWN_BATCH_KEYS = { messages: 1 };
 var KNOWN_TEMPLATE_KEYS = { version: 1, subject: 1, publicKey: 1, validity: 1, extensions: 1, issuer: 1 };
 var REVOCATION_TEMPLATE_KEYS = { version: 1, subject: 1, publicKey: 1, validity: 1, extensions: 1, issuer: 1, serialNumber: 1 };
@@ -161,19 +191,271 @@ function _encodeCertId(id) {
   return b.sequence([_b.encodeGeneralName(id.issuer), _b.serialInteger(id.serialNumber)]);
 }
 
+// The two ProofOfPossession arms a key that cannot sign has to use: keyEncipherment [2] and
+// keyAgreement [3], each carrying a POPOPrivKey. Both field tags are EXPLICIT, because POPOPrivKey is
+// itself a CHOICE and X.680 sec. 31.2.7 forbids implicit tagging of one. The parser states and
+// enforces the same rule (schema-crmf.js), so an implicit emission here would disagree with the
+// module's own reader.
+var POPO_PRIVKEY_TAGS = { keyEncipherment: 2, keyAgreement: 3 };
+// SubsequentMessage ::= INTEGER { encrCert (0), challengeResp (1) } (RFC 4211 sec. 4.2).
+var SUBSEQUENT_MESSAGE = { encrCert: 0n, challengeResp: 1n };
+// The specification deprecates two of the five alternatives in the same breath as defining them:
+// thisMessage "has been deprecated in favor of encryptedKey", dhMAC "is deprecated in favor of the
+// agreeMAC field" (sec. 4.2), and RFC 9810 sec. 5.2.8.3 restates both as `-- deprecated`. A reader
+// still has to accept them, since a peer may send one; a producer choosing to emit one today is
+// choosing the superseded encoding, so the builder names the successor instead of emitting it.
+var DEPRECATED_POPO_METHOD = { thisMessage: "encryptedKey", dhMAC: "agreeMAC" };
+
+// EncKeyWithID ::= SEQUENCE { privateKey PrivateKeyInfo,
+//                             identifier CHOICE { string UTF8String, generalName GeneralName } OPTIONAL }
+// (RFC 4211 sec. 4.2.1). `identifier` is marked OPTIONAL in the module and then made mandatory by the
+// prose for this use: "This field MUST be present if the purpose is to prove possession of the private
+// key." The reason is stated there too. Without it an escrow agent decrypts a key without knowing
+// whose it is, so an attacker can wrap someone else's intercepted key in a request of their own and
+// then ask for it back. Building a POP is that first purpose, so the caller supplies one.
+function _encKeyWithID(privateKeyDer, identifier) {
+  var idNode;
+  if (typeof identifier === "string") idNode = b.utf8(identifier);
+  else idNode = _b.encodeGeneralName(identifier);   // the GeneralName alternative of the CHOICE
+  return b.sequence([b.raw(privateKeyDer), idNode]);
+}
+
+// POPOPrivKey, the proof an encryption or key-agreement key gives instead of a signature (RFC 4211
+// sec. 4.2 / 4.3). A key that cannot sign has no POPOSigningKey available, so without these arms the
+// only reachable alternative is raVerified, an RA's assertion and not a proof at all. For a toolkit
+// whose signature story is PQC-first that gap lands exactly on ML-KEM enrollment.
+//
+// `subsequentMessage` carries no cryptography: it declares which follow-up exchange will complete the
+// proof, and the completion happens in the enrolling protocol (RFC 9810 sec. 5.2.8.3.2 / .3), not here.
+// `encryptedKey` carries the private key itself to the CA, which is why it is gated twice below.
+function _buildPopoPrivKey(pop, mode, template) {
+  var outerTag = POPO_PRIVKEY_TAGS[mode];
+  var method = pop && pop.method;
+  if (typeof method !== "string") {
+    throw _err("crmf/bad-popo", "a " + mode + " proof of possession requires pop.method ('subsequentMessage' or 'encryptedKey')");
+  }
+  if (_hasOwn(DEPRECATED_POPO_METHOD, method)) {
+    throw _err("crmf/bad-popo", "the " + method + " proof of possession is deprecated by RFC 4211 sec. 4.2 in favor of " +
+      DEPRECATED_POPO_METHOD[method] + "; a reader still accepts it, a new message should not carry it");
+  }
+  // sec. 4.2 lists exactly three methods for an encipherment key (the private key provided, a
+  // decrypted challenge, an encrypted certificate) and introduces the MAC alternatives only in
+  // sec. 4.3, "for keyAgreement (only)". The parser refuses a MAC arm under keyEncipherment; the
+  // builder refuses to produce one, so the two directions agree about the same message.
+  if (method === "agreeMAC" && mode === "keyEncipherment") {
+    throw _err("crmf/bad-popo", "keyEncipherment proof of possession cannot use the agreeMAC alternative -- " +
+      "it is defined for keyAgreement only (RFC 4211 sec. 4.2, sec. 4.3)");
+  }
+  if (method === "agreeMAC") {
+    // Conforming, and not built here. It needs the static Diffie-Hellman shared secret of RFC 2875
+    // sec. 3, derived between the requester's private key and a CA certificate the requester already
+    // holds, a classical key-agreement primitive this toolkit does not otherwise carry. It is
+    // reported, not approximated: verifyPop already names an inbound agreeMAC as unverified, and an
+    // emitted one nothing here can check would be worse than none.
+    throw _err("crmf/unsupported-popo", "the agreeMAC proof of possession is not built by this toolkit: it requires " +
+      "the RFC 2875 static Diffie-Hellman shared secret between the requester's key and a CA certificate it " +
+      "already holds. Use 'subsequentMessage' (encrCert or challengeResp), which every key type can produce");
+  }
+  if (method === "subsequentMessage") {
+    var which = pop.subsequentMessage;
+    if (typeof which !== "string" || !_hasOwn(SUBSEQUENT_MESSAGE, which)) {
+      throw _err("crmf/bad-popo", "pop.subsequentMessage must be 'encrCert' or 'challengeResp' -- " +
+        "SubsequentMessage ::= INTEGER { encrCert (0), challengeResp (1) } has no other value (RFC 4211 sec. 4.2)");
+    }
+    // subsequentMessage [1] IMPLICIT SubsequentMessage, inside the EXPLICIT [2]/[3] wrapper.
+    return b.explicit(outerTag, b.implicit(1, b.integer(SUBSEQUENT_MESSAGE[which])));
+  }
+  if (method !== "encryptedKey") {
+    throw _err("crmf/bad-popo", "unsupported POPOPrivKey method " + JSON.stringify(method) +
+      " (supported: 'subsequentMessage', 'encryptedKey')");
+  }
+  // encryptedKey is legal under BOTH outer arms, and the asymmetry with agreeMAC above is the
+  // specification's own. RFC 4211 sec. 4.3: key-agreement POP "is accomplished by one of four
+  // different methods. The first three are identical to those presented above for key encryption
+  // keys" -- and the first of sec. 4.2's three is "The private key can be provided to the CA/RA",
+  // which is this alternative. Only the fourth, the MAC, is agreement-only. The parser reads
+  // encryptedKey under both arms for the same reason, so gating it to keyEncipherment here would put
+  // the producer and the reader back into disagreement about one message.
+  return _buildEncryptedKeyPop(pop, outerTag, template);
+}
+
+// encryptedKey [4] EnvelopedData. RFC 9810 sec. 5.2.8.3.1: "This method SHALL only be used if archival
+// of the private key is desired." Nothing in a builder can confirm that intent, so it is an explicit
+// opt-in on the raVerified precedent: handing your private key to the CA should take a sentence that
+// says so, not a mistyped method name.
+function _buildEncryptedKeyPop(pop, outerTag, template) {
+  if (pop.archive !== true) {
+    throw _err("crmf/bad-popo", "an encryptedKey proof of possession sends the requester's private key to the CA, " +
+      "and RFC 9810 sec. 5.2.8.3.1 permits it only where archival is intended -- opt in with pop.archive: true");
+  }
+  if (pop.identifier == null) {
+    throw _err("crmf/bad-popo", "an encryptedKey proof of possession requires pop.identifier (a string or a GeneralName): " +
+      "RFC 4211 sec. 4.2.1 makes EncKeyWithID.identifier mandatory when the purpose is proving possession, so a " +
+      "decrypting agent knows whose key it holds");
+  }
+  // From here the function owns a plaintext copy of the caller's private key, so every exit clears it.
+  // The checks below reject a malformed PKCS#8, an empty recipient list, an AEAD algorithm and a
+  // template with no key, and each of those throws synchronously: cleanup attached only to the
+  // promise would run on none of them, leaving the copy readable exactly on the paths a caller hits
+  // by getting the call wrong. `wipe` tolerates the second buffer not existing yet.
+  var privateKeyDer = guard.bytes.snapshot(pop.privateKey, CrmfError, "crmf/bad-input", "pop.privateKey");
+  var encKeyWithIdDer = null;
+  function wipe() { guard.secret.zeroizeAll([privateKeyDer, encKeyWithIdDer], CrmfError, "crmf/bad-input", "the enclosed private key"); }
+  try {
+    return _encryptedKeyPopBody();
+  } catch (e) { wipe(); throw e; }
+
+  function _encryptedKeyPopBody() {
+  if (!privateKeyDer.length) throw _err("crmf/bad-input", "pop.privateKey must be the requester's PrivateKeyInfo (PKCS#8) DER");
+  // PrivateKeyInfo.version MUST be 0 (sec. 4.2.1). These are caller bytes, so the value is read rather
+  // than assumed; a v1 OneAsymmetricKey carries a public key the CA did not ask to be told.
+  var pkiKids, pkiVersion;
+  try { pkiKids = pkix.rootSequenceChildren(asn1.decode(privateKeyDer), 3); }
+  catch (e) { throw _err("crmf/bad-input", "pop.privateKey must be a PrivateKeyInfo (PKCS#8) SEQUENCE", e); }
+  if (!pkiKids) throw _err("crmf/bad-input", "pop.privateKey must be a PrivateKeyInfo (PKCS#8) SEQUENCE of at least three fields");
+  try { pkiVersion = asn1.read.integer(pkiKids[0]); }
+  catch (e) { throw _err("crmf/bad-input", "PrivateKeyInfo.version must be an INTEGER (RFC 4211 sec. 4.2.1)", e); }
+  if (pkiVersion !== 0n) {
+    throw _err("crmf/bad-input", "EncKeyWithID.privateKey must be a PrivateKeyInfo with version 0, got " + pkiVersion + " (RFC 4211 sec. 4.2.1)");
+  }
+  var recipients = pop.recipients;
+  if (!intrinsic.isArray(recipients) || recipients.length === 0) {
+    throw _err("crmf/bad-input", "an encryptedKey proof of possession requires pop.recipients (the CA or archive agents to envelope the key to)");
+  }
+  // The field is typed EnvelopedData, so the content-encryption algorithm has to be one that produces
+  // one. An AEAD algorithm yields an AuthEnvelopedData (RFC 5083), a different structure this field
+  // cannot carry and the parser will not read. It is refused by name, not emitted for a peer to
+  // reject. CBC is the default here for that reason, not as a preference between the two.
+  var cea = pop.contentEncryptionAlgorithm || "aes-256-cbc";
+  if (typeof cea !== "string") throw _err("crmf/bad-input", "pop.contentEncryptionAlgorithm must be an algorithm name");
+  if (/gcm|ccm|chacha/i.test(cea)) {
+    throw _err("crmf/bad-popo", "encryptedKey is typed EnvelopedData, and the AEAD algorithm " + cea +
+      " produces an AuthEnvelopedData instead (RFC 5083) -- choose a CBC content-encryption algorithm");
+  }
+  // RFC 4211 sec. 4.2: encryptedKey "contains the encrypted private key MATCHING THE PUBLIC KEY for
+  // which the certificate is to be issued". Without this the arm proves nothing it claims to: a
+  // requester could ask for a certificate over one key while enclosing an unrelated private key, and
+  // the CA would issue on a proof of possession of something it never certified. The signature arm
+  // self-verifies before returning for the same reason; this is that check for this arm.
+  if (template.spki == null) {
+    throw _err("crmf/bad-input", "an encryptedKey proof of possession requires certTemplate.publicKey -- " +
+      "the proof is that the enclosed private key is the one being certified (RFC 4211 sec. 4.2)");
+  }
+  // The second plaintext copy: the EncKeyWithID that carries the key into the message. This arm is
+  // the one place in the toolkit that deliberately holds a caller's private key in the clear, so both
+  // copies are cleared on every exit. The caller's own buffer stays intact, since it was copied.
+  encKeyWithIdDer = _encKeyWithID(privateKeyDer, pop.identifier);
+  // Composed, never hand-rolled: the one CMS producer emits the RecipientInfos, and the content type is
+  // the id-ct-encKeyWithID sec. 4.2 requires -- the same OID the parser independently checks for.
+  return _assertEnclosedKeyMatches(privateKeyDer, template.spki).then(function () {
+    // The CMS producer raises its own cms/* faults for a malformed recipient or an algorithm it does
+    // not carry. Those are this module's inputs, reached through a composition the caller cannot see,
+    // so they are re-raised in this module's namespace with the original kept as the cause -- the
+    // same translation the CRMF parser performs where it composes the CMS reader.
+    return cmsEncrypt.encrypt(encKeyWithIdDer, recipients, { contentType: "encKeyWithID", contentEncryptionAlgorithm: cea })
+      .then(null, function (e) {
+        if (e instanceof CrmfError) throw e;
+        throw _err("crmf/bad-input", "the encryptedKey proof of possession could not envelope the private key to " +
+          "pop.recipients: " + ((e && e.message) || e), e);
+      });
+  })
+    .then(function (contentInfo) {
+      // cms.encrypt returns a ContentInfo wrapping the EnvelopedData; the field carries the bare
+      // structure. Read back through the shipped walker rather than indexing into our own output, so a
+      // change in what encrypt emits is a typed error here and not a malformed message on the wire.
+      var inner = _bareEnvelopedData(contentInfo);
+      return b.explicit(outerTag, b.implicit(4, inner));
+    })
+    .then(function (out) { wipe(); return out; }, function (e) { wipe(); throw e; });
+  }
+}
+
+// Is the private key about to be enclosed the one the template asks to have certified? Derived through
+// the toolkit's own key engine, not a second re-implementation, so every algorithm it drives (RSA, EC,
+// the Edwards curves, ML-KEM, ML-DSA) answers the same way. Both values are public, so this is an
+// ordinary comparison and not a secret one.
+// nosemgrep: pki-non-constant-time-secret-compare
+function _assertEnclosedKeyMatches(privateKeyDer, templateSpki) {
+  return Promise.resolve()
+    .then(function () { return key.publicFromPrivate(privateKeyDer); })
+    .then(function (derivedSpki) {
+      var derived = guard.bytes.view(derivedSpki, CrmfError, "crmf/bad-input", "the derived public key");
+      var wanted = guard.bytes.view(templateSpki, CrmfError, "crmf/bad-input", "certTemplate.publicKey");
+      if (!_b.samePublicKey(derived, wanted)) {
+        throw _err("crmf/bad-popo", "the private key enclosed in the encryptedKey proof of possession is not the " +
+          "private half of certTemplate.publicKey, so it proves possession of a key this request does not ask to " +
+          "have certified (RFC 4211 sec. 4.2)");
+      }
+    }, function (e) {
+      if (e instanceof CrmfError) throw e;
+      throw _err("crmf/bad-input", "pop.privateKey could not be read as a private key to check against " +
+        "certTemplate.publicKey: " + ((e && e.message) || e), e);
+    });
+}
+
+// The EnvelopedData SEQUENCE inside the ContentInfo cms.encrypt returns, validated on the way out.
+// Every fault here comes from re-reading a composition the caller never sees. The codec's decode and
+// the CMS walker each raise in their own namespace, so the whole body is translated, not the one call
+// that happens to be likeliest. `pki.crmf.build` promises a typed CrmfError, and a promise with an
+// exception for the paths nobody expected to take is the shape that makes it untrue exactly once.
+function _bareEnvelopedData(contentInfoDer) {
+  try {
+    var kids = pkix.rootSequenceChildren(asn1.decode(contentInfoDer), 2, 2);
+    var wrapper = kids && kids[1];
+    if (!wrapper || wrapper.tagClass !== "context" || wrapper.tagNumber !== 0 || !wrapper.children || wrapper.children.length !== 1) {
+      throw _err("crmf/bad-popo", "the enveloped private key is not a ContentInfo carrying one [0] EXPLICIT content");
+    }
+    var env = wrapper.children[0];
+    cms.walkEnvelopedData(env);   // typed cms/* on anything that is not a well-formed EnvelopedData
+    return b.raw(env.bytes);
+  } catch (e) {
+    if (e instanceof CrmfError) throw e;
+    throw _err("crmf/bad-popo", "the enveloped private key could not be read back as an EnvelopedData: " +
+      ((e && e.message) || e), e);
+  }
+}
+
+// Check spec.pop against the arm the caller selected, never against every arm's fields at once. Every
+// opt-in below is a refusal a caller turns off by naming it, so a field that belongs to a different
+// arm must not read as one this arm accepted and ignored: the caller believes they asked for
+// something the message does not say. An unrecognized arm falls through with only the selector
+// fields allowed, so the error names the arm rather than a field beside it.
+function _assertPopArmKeys(pop, mode) {
+  var arm = _hasOwn(POPO_PRIVKEY_TAGS, mode) ? pop.method : mode;
+  var allowed = (typeof arm === "string" && _hasOwn(POP_KEYS_BY_ARM, arm))
+    ? POP_KEYS_BY_ARM[arm]
+    : { type: 1, method: 1 };
+  guard.identifier.assertKnownKeys(pop, allowed, _err, "crmf/bad-input", function (k) {
+    return "spec.pop field " + _stringify(k) + " is not read by a " +
+      (typeof arm === "string" ? arm : "proof") + " proof of possession";
+  });
+}
+
 // ProofOfPossession. The signature arm (the default when a key is given): when the template carries both
 // subject and publicKey (complete), sign the CertRequest DER and omit poposkInput; otherwise build a
 // POPOSigningKeyInput (authInfo sender [0] GeneralName + the requested publicKey), sign its SEQUENCE, and
 // carry it as poposkInput [0] (RFC 4211 sec. 4.1). raVerified is emitted only on an explicit opt-in.
 function _buildProofOfPossession(pop, certReqDer, template, signingKey, opts) {
   if (pop != null && (typeof pop !== "object" || Buffer.isBuffer(pop))) throw _err("crmf/bad-input", "spec.pop must be an object (e.g. { type: 'signature' } or { type: 'raVerified', raVerified: true })");
+  // Every opt-in below is a refusal a caller turns off by naming it, so a misspelled key must not
+  // read as an omitted one: `archve: true` silently withholding the archival consent, or `identifer`
+  // silently omitting the field RFC 4211 sec. 4.2.1 makes mandatory, would each be a message built
+  // on the opposite of what the caller asked for.
+  // The arm is resolved BEFORE its fields are checked, because `type` is not the only thing that
+  // picks one: a spec that supplies a key and omits `type` selects the signature arm, and checking
+  // against an unresolved arm would refuse the `pop.sender` that arm reads.
   var mode = (pop && pop.type) || (signingKey != null ? "signature" : null);
+  if (pop != null) _assertPopArmKeys(pop, mode);
   if (mode == null) return null;   // no POP requested and no key -> omit popo (an RA supplies it out of band)
   if (mode === "raVerified") {
     if (!(pop && pop.raVerified === true)) throw _err("crmf/bad-popo", "raVerified must be explicitly opted into (pop: { type: 'raVerified', raVerified: true }) -- a requester does not normally assert it (RFC 4211 sec. 4)");
     return b.implicit(0, b.nullValue());   // raVerified [0] IMPLICIT NULL
   }
-  if (mode !== "signature") throw _err("crmf/bad-popo", "unsupported proof-of-possession type " + JSON.stringify(mode) + " (supported: 'signature', 'raVerified')");
+  if (_hasOwn(POPO_PRIVKEY_TAGS, mode)) return _buildPopoPrivKey(pop, mode, template);
+  if (mode !== "signature") {
+    throw _err("crmf/bad-popo", "unsupported proof-of-possession type " + JSON.stringify(mode) +
+      " (supported: 'signature', 'raVerified', 'keyEncipherment', 'keyAgreement')");
+  }
   if (signingKey == null) throw _err("crmf/bad-input", "a signature proof of possession requires the requester's private key");
   if (template.spki == null) throw _err("crmf/bad-input", "a signature proof of possession requires certTemplate.publicKey");
   var scheme = signScheme.resolveSignScheme(_b.certLikeFromSpki(template.spki), { combinedRsaSig: true, pss: opts.pss, digestAlgorithm: opts.digestAlgorithm }, true, _signE);
@@ -227,6 +509,27 @@ function _buildProofOfPossession(pop, certReqDer, template, signingKey, opts) {
  * PEM block with `opts.pem` (the label is required). Malformed input throws a typed `CrmfError`.
  * Certificate-request-message parsing is `pki.schema.crmf.parse`.
  *
+ * A key that cannot sign proves possession another way (RFC 4211 sec. 4.2, 4.3), which is the case an
+ * ML-KEM enrollment is in. Set `pop.type` to `keyEncipherment` or `keyAgreement` and pick a `pop.method`:
+ *
+ * - `subsequentMessage` with `pop.subsequentMessage` of `encrCert` or `challengeResp`. The proof completes
+ *   over the enrolling protocol's next exchange (RFC 9810 sec. 5.2.8.3.2 / .3), so this message only
+ *   declares which one. No key material leaves the requester, and every key type can produce it.
+ * - `encryptedKey`, which sends the requester's private key to the CA inside a CMS `EnvelopedData` whose
+ *   content type is `id-ct-encKeyWithID`. RFC 9810 sec. 5.2.8.3.1 permits it only where archival is
+ *   intended, so it takes `pop.archive: true`; `pop.privateKey` is the PKCS#8 DER, `pop.recipients` the CMS
+ *   recipients to envelope it to, and `pop.identifier` (a string or GeneralName) is required, because
+ *   sec. 4.2.1 makes it mandatory whenever the purpose is proving possession -- without it a decrypting
+ *   agent cannot tell whose key it holds. `pop.contentEncryptionAlgorithm` defaults to `aes-256-cbc`; an
+ *   AEAD algorithm is refused, since it would produce an `AuthEnvelopedData` this field cannot carry.
+ *
+ * The two alternatives the specification deprecates in the same breath as defining them, `thisMessage` and
+ * `dhMAC`, are refused with their successors named; `pki.schema.crmf.parse` still reads both, since a peer
+ * may send one. `agreeMAC` is not built: it needs the RFC 2875 static Diffie-Hellman shared secret between
+ * the requester's key and a CA certificate it already holds. Building an `encryptedKey` or `agreeMAC` proof
+ * inside `pki.cmp.build` raises the announced protocol version to cmp2021(3), which RFC 9810 sec. 5.2.8.3
+ * requires.
+ *
  * @opts
  *   - `pem` (string) -- return a PEM block with this label instead of DER (e.g. "CERTIFICATE REQUEST MESSAGE").
  *   - `pss` (boolean) -- sign an RSA key with RSASSA-PSS instead of PKCS#1 v1.5.

package/lib/guard-identifier.js

@@ -738,6 +738,41 @@ function _notAnOptionsBag(v) {
 // error and says so. A Buffer is excluded because it is an object and is never an options bag --
 // passing one is an argument-order mistake, which is worth naming rather than treating as empty.
 //
+// A built-in exotic whose data lives in internal slots rather than own enumerable keys, recognized by
+// identity so a cross-realm instance is caught too. `util.types` covers each such kind; an array is not
+// among them and is checked separately by the caller.
+function _isBuiltinExotic(v) {
+  var t = util.types;
+  return t.isDate(v) || t.isMap(v) || t.isSet(v) || t.isWeakMap(v) || t.isWeakSet(v) || t.isRegExp(v) ||
+    t.isPromise(v) || t.isArrayBuffer(v) || t.isSharedArrayBuffer(v) || t.isArrayBufferView(v) ||
+    t.isBoxedPrimitive(v) || t.isNativeError(v) || t.isArgumentsObject(v) || t.isGeneratorObject(v);
+}
+
+// assertPlainRecord(v, E, code, label): v MUST be a plain data record -- a non-null object that is not an
+// array, a Buffer, a Proxy, or a built-in exotic (a Date, Map, Set, boxed primitive, ...). A caller's
+// `typeof v === "object"` gate admits an array or a Date, which then passes assertKnownKeys with no own
+// key to reject and reads as a keyless record -- every field `undefined` and silently defaulted. This
+// door refuses that shape, so a malformed container is a refusal rather than a request assembled from
+// defaults. Composes BEFORE assertKnownKeys, which only
+// judges the keys that are present, not whether the value is a record at all.
+//
+// The prototype is NOT consulted, so a record built by a caller's own class, or one from another realm
+// (a vm context, a worker) whose prototype is a different Object.prototype, is accepted -- it holds its
+// fields as own enumerable properties like any record. Only a built-in exotic that keeps its data in
+// internal slots (a Date, Map, Set, boxed primitive, ...), an array (index-keyed), a Buffer, or a Proxy
+// is refused, each recognized by identity through `util.types` / `Array.isArray` so a cross-realm
+// instance is caught where an `instanceof` or a prototype check would miss it.
+//
+// @enforced-by behavioral -- a plain-record refusal has no single rename-proof code shape worth a
+// tree-wide detector; the RED vectors (an array, a Date, and a Proxy at each routed entry point, and a
+// cross-realm/subclass record that must still be ACCEPTED) are the guard.
+function assertPlainRecord(v, E, code, label) {
+  _requireFactory(E);
+  if (v === null || typeof v !== "object" || _isNodeBuffer(v) || _isArray(v)) throw E(code, label + " must be a plain object");
+  _refuseUnenumerable(v, E, code, label);   // a Proxy's reported keys need not match what it answers
+  if (_isBuiltinExotic(v)) throw E(code, label + " must be a plain object (a built-in exotic such as a Date or Map is refused)");
+}
+
 // @enforced-by behavioral -- the defect is an ordering, which has no rename-proof code shape; the
 // RED vector (a verb handed `false` accepting it as `{}`) is the guard.
 function optionsObject(opts, E, code, label) {
@@ -856,6 +891,7 @@ function _settle(opts, E, code, label) {
 module.exports = intrinsic.freeze({
   assertCanonicalOid: assertCanonicalOid,
   assertKnownKeys: assertKnownKeys,
+  assertPlainRecord: assertPlainRecord,
   optionsObject: optionsObject,
   refuseAccessorFields: refuseAccessorFields,
   // Exported so a caller that forwards an options bag copies the same surface this module

package/lib/guard-name.js

@@ -53,6 +53,12 @@ var _String = String;
 // matches, and it is captured for the same reason as the rest: what a guard does is settled before
 // a caller runs, or it is settled by the caller.
 var _isArray = Array.isArray;
+// Byte identity and the shape test that gates it, both captured for the reason above: a
+// distribution-point comparison asks whether two encodings are the same bytes, and an object
+// supplying its own `equals` would be answering that question about itself.
+var _isBuffer = intrinsic.isBuffer;
+var _bufferEquals = intrinsic.bufferEquals;
+var _getOwnPropertyDescriptor = intrinsic.getOwnPropertyDescriptor;
 
 // assertNoControlBytes(str, E, code, label) -> str | throws E(code, ...)
 // DirectoryString policy (a DN attribute value): reject NUL and C0 control bytes
@@ -185,6 +191,89 @@ function dnEqual(rdnsA, rdnsB, E, code, label) {
   return true;
 }
 
+// dpnCorresponds(a, b, E, code, label) -> boolean. Do two DistributionPointNames name the
+// same CRL distribution point? RFC 5280 sec. 6.3.3(b)(2)(i) asks it of a certificate's
+// DistributionPoint against a shard CRL's issuingDistributionPoint, and RFC 9483 sec. 4.3.4
+// asks it of the dpn a CMP crlUpdate requested against the IDP of the CRL that came back.
+// The answer is "at least one name in common", compared by BYTE-IDENTICAL DER.
+//
+// The comparison key is pinned by sec. 5.2.5: "The identical encoding MUST be used in the
+// distributionPoint fields of the certificate and the CRL". This is therefore the one name
+// comparison in the toolkit that must NOT canonicalize. dnEqual's sec. 7.1 rule applied here
+// would equate two encodings the spec keeps distinct, and a CRL would be accepted as covering
+// a point it was never published for. Whole-set equality is the opposite error: a point
+// published under several names (a URI beside a directoryName) shares one of them with a
+// reference that lists only that one, and demanding all would reject its own CRL.
+//
+// Mixed forms never correspond, with fullName on one side and nameRelativeToCRLIssuer on the
+// other. Deciding that would mean resolving an RDN fragment against a CRL issuer DN this
+// comparison is not given, so the answer is no.
+//
+// @enforced-by behavioral -- the rule's identity is carried by the kind strings, which the
+// pattern walk strips before matching, so it has no rename-proof code shape. The RED vectors
+// in guard-name.test.js and the crlUpdate vectors in cmp-session.test.js are the guard.
+function dpnCorresponds(a, b, E, code, label) {
+  var x = _reduceDpn(a, E, code, label), y = _reduceDpn(b, E, code, label);
+  if (x.kind !== y.kind) return false;
+  if (x.kind === "rdn") return _bufferEquals(x.bytes, y.bytes);
+  for (var i = 0; i < x.names.length; i++) {
+    for (var j = 0; j < y.names.length; j++) {
+      if (_bufferEquals(x.names[i], y.names[j])) return true;
+    }
+  }
+  return false;
+}
+
+// The comparand, checked and REDUCED to the values that were checked. The reason _assertSequence
+// gives applies here in full: a comparison handed the wrong shape must refuse at the call site
+// instead of answering. Reading `names` off a value that has none would run a loop over
+// `i < undefined` zero times and report "no correspondence", which reads as a clean refusal of a
+// CRL and hides that nothing was compared; reading it off a sparse array would walk to
+// Array.prototype for the missing index and compare a name the reference never carried.
+//
+// Every field must be the comparand's OWN DATA property, and its value is taken FROM the property
+// descriptor. That is one reflective read per field, so the value the shape check validated is the
+// value the comparison is answered from: no second read is left for an accessor, or a Proxy trap,
+// to answer differently, and a field the decoder never produces (inherited, or reached through a
+// getter) is refused. Buffers, not caller byte-likes, for the same reason: the comparison is byte
+// identity, and an object answering `equals` or `length` for itself would be deciding the question
+// asked of it.
+function _reduceDpn(d, E, code, label) {
+  function refuse(why) { return E(code, "cannot compare " + label + ": " + why); }
+  function ownValue(o, k) {
+    // FromPropertyDescriptor hands back a fresh ordinary object, so `value` here is the value the
+    // object itself reported for that key, including through a Proxy's own-descriptor trap.
+    var desc = _getOwnPropertyDescriptor(o, k);
+    if (!desc || !_hasOwn(desc, "value")) throw refuse("a distribution-point comparison requires " + k + " to be the comparand's own value (RFC 5280 sec. 6.3.3 compares decoded names)");
+    return desc.value;
+  }
+  if (!d || typeof d !== "object") {
+    throw refuse("a distribution-point comparison requires the decoded DistributionPointName on both sides (kind fullName or rdn)");
+  }
+  var kind = ownValue(d, "kind");
+  if (kind !== "fullName" && kind !== "rdn") throw refuse("a DistributionPointName is fullName or nameRelativeToCRLIssuer, and this is neither");
+  if (kind === "rdn") {
+    var bytes = ownValue(d, "bytes");
+    if (!_isBuffer(bytes)) throw refuse("a nameRelativeToCRLIssuer distribution point must carry its encoded bytes");
+    return { kind: kind, bytes: bytes };
+  }
+  var names = ownValue(d, "names");
+  if (!_isArray(names)) throw refuse("a fullName distribution point must carry a sequence of encoded GeneralNames");
+  // The length is read once, into the bound the copy runs to. A hole and an inherited element are
+  // the same refusal as any other missing own value: indexing past a hole walks to Array.prototype,
+  // where a planted numeric property supplies a name the reference never carried.
+  var len = names.length;
+  // Indexed assignment, never a push: the accumulator must not be built by a method a caller can
+  // replace, since what it collects is what the comparison is answered from.
+  var taken = [];
+  for (var i = 0; i < len; i++) {
+    var n = ownValue(names, i);
+    if (!_isBuffer(n)) throw refuse("every fullName GeneralName must be its encoded bytes");
+    taken[i] = n;
+  }
+  return { kind: kind, names: taken };
+}
+
 // escapeControlBytes(str) -> str. The render-side sibling of assertNoControlBytes:
 // where a name string must still be DISPLAYED best-effort (a human-readable report,
 // a log line) instead of rejected, neutralize every C0 control byte and DEL by
@@ -316,7 +405,7 @@ function lowerAscii(s) {
 // call, so a writable export would let a caller replace the check rather than pass it.
 module.exports = intrinsic.freeze({
   assertNoControlBytes: assertNoControlBytes, assertPrintableIa5: assertPrintableIa5,
-  dnEqual: dnEqual, rdnEqual: rdnEqual, emailEqual: emailEqual,
+  dnEqual: dnEqual, rdnEqual: rdnEqual, emailEqual: emailEqual, dpnCorresponds: dpnCorresponds,
   escapeControlBytes: escapeControlBytes, escapeDnValue: escapeDnValue,
   lowerAscii: lowerAscii,
 });

package/lib/oid.js

@@ -234,8 +234,11 @@ var FAMILIES = {
   // 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 } },
+    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,
@@ -376,6 +379,9 @@ var FAMILIES = {
     // 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
@@ -432,7 +438,49 @@ var FAMILIES = {
 
   // OIW Secsig SHA-1 (1.3.14.3.2.26) -- the most common OCSP CertID hashAlgorithm;
   // nistHash covers only SHA-256 and above.
-  oiwSecsig: { base: [1, 3, 14, 3, 2], of: { sha1: 26 } },
+  // 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 } },
+
+  // 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.
@@ -451,6 +499,11 @@ var FAMILIES = {
   // 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,
     "id-slh-dsa-sha2-128s": 20, "id-slh-dsa-sha2-128f": 21,
     "id-slh-dsa-sha2-192s": 22, "id-slh-dsa-sha2-192f": 23,