Summary

  • RFC 9936 puts ML-KEM into CMS through KEMRecipientInfo: rid identifies a recipient certificate or public key, kem names the ML-KEM algorithm and kemct carries ciphertext made for that recipient.
  • Those fields make a narrow protocol claim inspectable. They do not show who controlled the private decapsulation key, whether decapsulation occurred, whether the content passed local checks, or whether anyone was authorized to act on it.

The message archive supplied a comforting answer: the recipient was present. A certificate identifier appeared in the CMS record; an ML-KEM algorithm identifier was explicit; a ciphertext was attached to that recipient. In a hurried review, that can become “the intended party received and handled the message.”

That conclusion does not follow from the record.

RFC 9936 supplies conventions for using ML-KEM-512, ML-KEM-768 and ML-KEM-1024 in the Cryptographic Message Syntax. Its task is specific. An ML-KEM originator uses the recipient public encapsulation key (ek) to produce ciphertext (c) and a shared secret (ss). A recipient uses its private decapsulation key (dk) and that ciphertext to produce its corresponding shared secret. CMS uses the resulting construction to transfer a content-encryption key.

The record is therefore useful. It can show that a CMS object was prepared with a particular KEM recipient path. But it has an owner and a scope. It is evidence about encoded cryptographic material, not a universal receipt.

A recipient identifier is a key-distribution fact

For an ML-KEM recipient, RFC 9936 requires the CMS RecipientInfo alternative to be OtherRecipientInfo using KEMRecipientInfo. Its fields state different bounded facts. rid identifies a recipient certificate or public key. kem identifies the algorithm, and must name one of the specified ML-KEM identifiers. kemct is ciphertext produced for that recipient. The structure also has the KDF and key-wrap material needed for the prescribed key-transfer path.

RFC 9936 says the originator obtains a recipient static public key from the recipient certificate, using conventions in RFC 9935. That explains how public key material enters the message. It does not convert the certificate into a contemporaneous attestation about possession of its private counterpart. A certificate can be an indispensable component of a protocol exchange while leaving custody, activation, revocation handling, local access control and audit evidence to other systems.

The same restraint applies to an S/MIME capability announcement. RFC 9936 allows an implementation to announce a partial list of supported algorithms through SMIMECapabilities. “Can support” is not “used for this message”; “used in the encoding” is not “decapsulated”; and “decapsulated” is not “read, approved or executed.” Each arrow introduces a new local event.

The decisive operation is not inside the public label

The protocol makes the seam visible. Encapsulation takes the public key and yields ciphertext plus an originator secret. Decapsulation takes the private key and ciphertext to yield the recipient secret. The originator must implement the former and a CMS recipient must implement the latter. Neither requirement provides an external observer with a record of who operated the recipient environment at a particular time or what application consumed the derived key.

Nor does an authenticated CMS container settle the later question. Enveloped-data, authenticated-data and authenticated-enveloped-data name protected content constructions. Their use may support bounded confidentiality or integrity assertions when their own conditions hold. They do not specify an organizational inbox, a human review, a transaction system's acceptance rule or a delegated authority matrix.

RFC 9936's security considerations reinforce the separation rather than eliminating it. Implementations must protect the ML-KEM private key and relevant encryption/authentication keys; ephemeral keys must be wiped after use. Weak randomness can severely erode security, and intermediate values must not be used directly. These are implementation obligations. A CMS artifact cannot demonstrate, merely by existing, that an implementation met them.

Heng Lu's useful discipline is to keep the common fact narrow enough to be locally checked. A shared artifact can be parsed and its fields compared against a specification. Publication of an identifier is not proof of a wider operational reality. In this setting, that means retaining the recipient record without allowing it to impersonate custody, execution or authority.

Build an evidence chain with named seams

For a high-consequence workflow, preserve the CMS object and record its rid, KEM algorithm, ciphertext, KDF/key-wrap choice, timestamps and certificate-validation result. Treat this as the message-format layer. Preserve key-custody evidence separately: which protected system held the decapsulation material, which access policy was active, and what recovery or revocation state applied.

Then record the local processing result separately. That record may need a decapsulation audit, content-authentication outcome, application acceptance outcome and a transaction-specific receipt. Finally, if the workflow depends on a decision, retain the authority and approval evidence that identifies the decision maker, rule and effective time. One record should answer one question cleanly.

Sources