@blamejs/pki 0.5.23 → 0.5.25

package/lib/cmp-build.js

@@ -34,6 +34,11 @@ var asn1 = require("./asn1-der");
 var oid = require("./oid");
 var cmp = require("./schema-cmp");
 var crmf = require("./crmf-sign");
+var schemaCrmf = require("./schema-crmf");
+var intrinsic = require("./guard-intrinsic");
+// Own-key membership through an operation taken at load: it decides which proof-of-possession
+// methods couple the message to a protocol version, and an inherited name is one no RFC defined.
+var _hasOwn = intrinsic.hasOwn;
 var csr = require("./schema-csr");
 var crl = require("./schema-crl");
 var x509 = require("./schema-x509");
@@ -422,6 +427,29 @@ function _encodeKeyRecRepContent(spec, state) {
   return b.sequence(children);
 }
 
+// Does a built CertReqMessages carry a proof of possession that RFC 9810 sec. 5.2.8.3 couples to
+// cmp2021(3)? Stated over the RFC's pair rather than over the arms this toolkit happens to emit, so
+// the coupling still holds if agreeMAC is built later.
+var CMP2021_POP_METHODS = { agreeMAC: 1, encryptedKey: 1 };
+function _popNeedsCmp2021(crmfDer) {
+  var messages;
+  // Re-reading a CertReqMessages this process just produced. A fault here is an internal
+  // inconsistency, not a caller error, so it is named in this module's namespace: a crmf/* parse code
+  // surfacing from cmp.build would send the operator looking at a request they wrote correctly. A
+  // CRMF fault raised while BUILDING that body still passes through untranslated, where it does name
+  // the caller's own input.
+  try { messages = schemaCrmf.parse(crmfDer).messages; }
+  catch (e) {
+    throw _err("cmp/bad-body", "the certificate request body this message just built did not parse back: " +
+      ((e && e.message) || e), e);
+  }
+  for (var i = 0; i < messages.length; i++) {
+    var popo = messages[i].popo;
+    if (popo && popo.method && _hasOwn(CMP2021_POP_METHODS, popo.method)) return true;
+  }
+  return false;
+}
+
 // Dispatch the single-key body object to its EXPLICIT-tagged arm. Returns { bodyTLV, usesCmp2021 }.
 function _encodeBody(bodySpec, key, opts) {
   if (!bodySpec || typeof bodySpec !== "object" || Buffer.isBuffer(bodySpec)) throw _err("cmp/bad-input", "message.body must be a single-key object");
@@ -442,7 +470,13 @@ function _encodeBody(bodySpec, key, opts) {
       delete reqSpec.key;
     }
     return crmf.build(reqSpec, popKey, {}).then(function (crmfDer) {
-      return { bodyTLV: b.explicit(tag, b.raw(crmfDer)), usesCmp2021: false };
+      // RFC 9810 sec. 5.2.8.3: "When using agreeMAC or encryptedKey choices, the pvno cmp2021(3)
+      // MUST be used." Read off the message that was actually emitted rather than off the spec that
+      // asked for it, so the announced version answers for the bytes on the wire. The parser
+      // enforces the same rule on the way in, and before this the two disagreed: a request carrying
+      // an encryptedKey proof went out announcing cmp2000(2), and this toolkit's own reader refused
+      // the message this toolkit had just built.
+      return { bodyTLV: b.explicit(tag, b.raw(crmfDer)), usesCmp2021: _popNeedsCmp2021(crmfDer) };
     });
   }
   var inner;

package/lib/cmp-verify.js

@@ -339,14 +339,9 @@ function _rfc822Equal(a, b) {
 // SIGN lowercases to "k", so a host carrying it would compare EQUAL to the ASCII spelling
 // and two distinct domains would read as one identity. Fold only A-Z and leave every other
 // octet alone, so a non-ASCII host can differ from an ASCII one but never collide with it.
-function _lowerAsciiDomain(h) {
-  var out = "";
-  for (var i = 0; i < h.length; i++) {
-    var c = _charCodeAt(h, i);
-    out += (c >= 0x41 && c <= 0x5a) ? _fromCharCode(c + 32) : _charAt(h, i);
-  }
-  return out;
-}
+// Through the toolkit's one definition of that fold, so no two name comparisons can disagree
+// about which characters case-fold.
+var _lowerAsciiDomain = guard.name.lowerAscii;
 
 // RFC 5280 sec. 4.2.1.6 / RFC 3986 sec. 6.2.2.1 URI comparison: the scheme and the authority host are
 // case-insensitive; every other component (userinfo, port, path, query, fragment) is byte-exact. Return

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-all.js

@@ -51,6 +51,7 @@
 // its guard module, so a new boundary cannot re-inline the shape and forget the
 // defense.
 
+var _freeze = require("./guard-intrinsic").freeze;
 var bytes  = require("./guard-bytes");
 var text   = require("./guard-text");
 var limits = require("./guard-limits");
@@ -74,7 +75,11 @@ var async_ = require("./guard-async");
 // live reads were never named. With one spelling, a module's own require IS the fact, and the check
 // reads it off the loaded module graph rather than guessing at the text.
 
-module.exports = {
+// Frozen, like every module it gathers. A boundary reaches its guard as `guard.<family>.<fn>(...)`
+// at the call, and the registry hands every module this same object, so one property assignment
+// would replace a fail-closed check everywhere at once -- which is the substitution the family
+// exists to refuse. Nothing writes to it after load.
+module.exports = _freeze({
   bytes:  bytes,
   text:   text,
   limits: limits,
@@ -92,4 +97,4 @@ module.exports = {
   secret: secret,
   parsed: parsed,
   async:  async_,
-};
+});

package/lib/guard-async.js

@@ -46,4 +46,6 @@ function deferred(body) {
   catch (e) { return _reject(_Promise, e); }
 }
 
-module.exports = { deferred: deferred };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _intrinsic.freeze({ deferred: deferred });

package/lib/guard-bytes.js

@@ -1032,8 +1032,10 @@ function fixedCall(ErrorClass, code, args, body) {
   }), function () { if (handle) handle.release(); });
 }
 
-module.exports = {
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = intrinsic.freeze({
   view: view, source: source, snapshot: snapshot, snapshotSource: snapshotSource,
   isByteSource: isByteSource, lengthOf: lengthOf, outputView: outputView,
   snapshotDeep: snapshotDeep, fixArguments: fixArguments, fixedCall: fixedCall,
-};
+});

package/lib/guard-compress.js

@@ -181,4 +181,6 @@ function bounded(algorithm, stream, cap, E, codes, label) {
 // and a consumer offering an algorithm this list omits fails closed at `bounded`.
 function algorithms() { return _objectKeys(SAFE); }
 
-module.exports = { bounded: bounded, algorithms: algorithms };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _intrinsic.freeze({ bounded: bounded, algorithms: algorithms });

package/lib/guard-crypto.js

@@ -28,6 +28,7 @@
 // with unusedBits !== 0 fails closed before its bytes reach a verifier.
 
 var nodeCrypto = require("node:crypto");
+var _freeze = require("./guard-intrinsic").freeze;
 
 // constantTimeEqual(a, b) -> boolean. Length-checked, then constant-time over
 // equal lengths. a and b are Buffers.
@@ -61,4 +62,6 @@ function assertOctetAligned(bitString, E, code, label) {
   return bitString;
 }
 
-module.exports = { constantTimeEqual: constantTimeEqual, isOctetAligned: isOctetAligned, assertOctetAligned: assertOctetAligned };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _freeze({ constantTimeEqual: constantTimeEqual, isOctetAligned: isOctetAligned, assertOctetAligned: assertOctetAligned });

package/lib/guard-der.js

@@ -33,6 +33,7 @@
 // The byte comparison SET-OF ordering is decided by, taken at load. A replacement chooses which
 // encodings this guard calls correctly ordered. See guard-intrinsic for the whole captured set.
 var _compare = require("./guard-intrinsic").compare;
+var _freeze = require("./guard-intrinsic").freeze;
 var _forEach = require("./guard-intrinsic").forEach;
 // The emptiness gate below decides whether bytes reach the decoder at all, and on a byte view
 // `length` is a replaceable accessor: one answering non-zero for an empty buffer sends nothing to
@@ -172,4 +173,6 @@ function tlv(content, E, code, label) {
   return content;
 }
 
-module.exports = { element: element, tlv: tlv };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _freeze({ element: element, tlv: tlv });

package/lib/guard-encoding.js

@@ -132,4 +132,6 @@ function hex(text, maxBytes, E, code, label) {
   return buf;
 }
 
-module.exports = { base64url: base64url, base64: base64, hex: hex };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _intrinsic.freeze({ base64url: base64url, base64: base64, hex: hex });

package/lib/guard-header.js

@@ -21,6 +21,7 @@ var C = require("./constants");
 // Taken at load. `byteLength` is what the RFC 5322 line limit is measured with, so a replacement
 // decides whether an over-long header line is refused. See guard-intrinsic for the whole set.
 var _byteLength = require("./guard-intrinsic").byteLength;
+var _freeze = require("./guard-intrinsic").freeze;
 // The character-code read the RFC 5322 ftext and CR/LF/NUL checks are built on. One that never
 // reports a control byte is a header-injection defense that inspects nothing.
 var _charCodeAt = require("./guard-intrinsic").uncurry(String.prototype.charCodeAt);
@@ -60,4 +61,6 @@ function assertField(name, value, E, code) {
   return v;
 }
 
-module.exports = { assertField: assertField };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _freeze({ assertField: assertField });

package/lib/guard-identifier.js

@@ -851,7 +851,9 @@ function _settle(opts, E, code, label) {
   return opts;
 }
 
-module.exports = {
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = intrinsic.freeze({
   assertCanonicalOid: assertCanonicalOid,
   assertKnownKeys: assertKnownKeys,
   optionsObject: optionsObject,
@@ -864,4 +866,4 @@ module.exports = {
   // Exported for the same reason as its sibling: a caller copying an array has to reach the
   // elements a read reaches, and the own keys are not that set.
   readableIndices: readableIndices
-};
+});

package/lib/guard-intrinsic.js

@@ -260,7 +260,12 @@ function sizeOf(value) {
     (value === null ? "null" : typeof value));
 }
 
-module.exports = {
+// Frozen, and that is what makes the capture worth taking. A consumer binds these at load, but it
+// also reads several of them as `intrinsic.<name>(...)` at the call itself, and the module registry
+// hands every caller this same object: assigning one property would redirect that call in every
+// module at once, which is the substitution the captures exist to refuse. Freezing costs nothing
+// here because nothing writes to it after load.
+module.exports = Object.freeze({
   uncurry: uncurry,
   getter: getter,
   sizeOf: sizeOf,
@@ -347,4 +352,4 @@ module.exports = {
   Set: _Set,
   Map: _Map,
   WeakMap: _WeakMap,
-};
+});

package/lib/guard-json.js

@@ -27,6 +27,7 @@ var text = require("./guard-text");
 // setter, and `fromCharCode` is how an escape becomes the character it names; a replacement for
 // either decides what this parser produces. See guard-intrinsic for the whole captured set.
 var _defineProperty = require("./guard-intrinsic").defineProperty;
+var _freeze = require("./guard-intrinsic").freeze;
 var _fromCharCode = require("./guard-intrinsic").fromCharCode;
 // The character-code read the whole scanner is built on: whitespace, escapes and the control-byte
 // reject all consult it, so one that lies decides what this parser sees in the input.
@@ -209,4 +210,6 @@ function parse(input, ErrorClass, spec) {
   return result;
 }
 
-module.exports = { parse: parse };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _freeze({ parse: parse });

package/lib/guard-limits.js

@@ -27,6 +27,7 @@ var constants = require("./constants");
 // one returning true admits a NaN or fractional cap, which makes the comparison it guards always
 // false. See guard-intrinsic for the whole captured set.
 var _isInteger = require("./guard-intrinsic").isInteger;
+var _freeze = require("./guard-intrinsic").freeze;
 // And the size measurement, for the same reason one step further in: a cap compares against a
 // length, and on a byte view `length` is a replaceable accessor. One reporting a small number for a
 // large buffer leaves every byteCap below always-false, which is the size defense silently dead.
@@ -137,4 +138,6 @@ function byteCap(buf, max, E, code, label) {
   return buf;
 }
 
-module.exports = { cap: cap, depthCap: depthCap, counter: counter, byteCap: byteCap };
+// Frozen for the reason the family header gives: a boundary reads its guard off this object at the
+// call, so a writable export would let a caller replace the check rather than pass it.
+module.exports = _freeze({ cap: cap, depthCap: depthCap, counter: counter, byteCap: byteCap });