Summary

  • On 18 September, the IESG approved draft-ietf-lamps-cms-composite-kem-03 as a Proposed Standard in a Protocol Action. It has not yet been published as an RFC. The live Datatracker state is RFC Ed Queue, the RFC Editor status is blocked: Reference Not Received, and IANA processing remains In Progress with IANA OK - Actions Needed.

  • The blocking relationship is substantive, not administrative trivia. The CMS document normatively cites draft-ietf-lamps-pq-composite-kem-21, which defines the Composite ML-KEM algorithms, their KeyGen, Encaps and Decaps behavior, their X.509 carriage and their algorithm identifiers. That dependency remains at IESG Evaluation::Revised I-D Needed, with two outstanding DISCUSS positions and IANA actions still needed.

  • The practical control problem is state synchronization. IESG approval, RFC publication, IANA registration, library support, certificate issuance, CMS processing support, interoperability testing and production policy are distinct states. Collapsing them into a single “supported” flag creates avoidable deployment and rollback risk.

What changed on 18 September

The IESG announcement records approval of Composite ML-KEM for use in Cryptographic Message Syntax (CMS), revision -03, as a Proposed Standard. The announcement describes it explicitly as a companion to draft-ietf-lamps-pq-composite-kem-21. It also records working-group consensus and says that substantial implementation work and IETF Hackathon effort had been used to test interoperability.

The subsequent state transitions are equally important. On the same date, the Datatracker history records the IESG approval, the move into RFC Ed Queue, the start of IANA action and the RFC Editor block Reference Not Received. The live document page continues to identify -03 as an active Internet-Draft rather than a published RFC.

That distinction matters commercially. Approval can trigger product-roadmap commitments, customer announcements, certificate-profile work and procurement planning before the RFC production chain has converged. An organization that treats “IESG approved” as equivalent to “stable production contract” can make implementation commitments against identifiers, module references or normative text that are not yet in their final published state.

The dependency is part of the product

The CMS draft does not independently specify the entire cryptographic object it uses. It places Composite ML-KEM into CMS using the KEMRecipientInfo framework standardized by RFC 9629, but delegates the underlying Composite ML-KEM operations to the separate LAMPS dependency. The CMS text points to that document for KeyGen, Encaps and Decaps; it also states that conventions for carrying Composite ML-KEM public keys in recipient certificates come from that dependency.

RFC 9629 supplies the generic CMS machinery: KEMRecipientInfo identifies the recipient, KEM algorithm, KEM ciphertext, key-derivation function, wrapping algorithm and encrypted content key. The Composite ML-KEM CMS draft specializes that mechanism by requiring a Composite ML-KEM identifier in the kem field and defining the associated processing conventions.

The dependency, however, owns the algorithm-level contract. Its current -21 text defines the composite encapsulation and decapsulation procedures and the X.509/PKIX handling of Composite ML-KEM public keys. It also supplies the Composite ML-KEM algorithm identifiers imported by the CMS ASN.1 module.

That makes the two documents one operational dependency chain even though they are separate standards-track artifacts.

The unresolved state is visible in the standards machinery

The CMS draft’s normative-reference section binds directly to draft-ietf-lamps-pq-composite-kem-21, dated 1 September 2026. This is not a vague reference to a future concept: revision -21 is the concrete work-in-progress dependency named in the approved CMS text.

Yet the dependency has not cleared the same gate. Its Datatracker state remains IESG Evaluation::Revised I-D Needed; the page reports two DISCUSS positions and says it has enough positions to pass once those DISCUSS positions are resolved. Its IANA review remains IANA OK - Actions Needed. The ballot identifies the two DISCUSS holders as Éric Vyncke and Roman Danyliw.

This does not mean the dependency will fail. It means closure has not yet occurred. For production governance, unresolved and resolved are different states regardless of how tractable individual review comments may appear.

The RFC production dependency is also encoded directly in the CMS text. Its IANA section still contains a module-number placeholder, and its ASN.1 imports use TBDCompositeMOD for the module belonging to id-mod-composite-mlkem-2025 in the dependency. The RFC Editor is instructed to replace that placeholder with the module number assigned through the other document.

That is a concrete reason the companion cannot be treated as an isolated publication unit.

Registry presence is not chain completion

The IANA SMI registry already contains Composite ML-KEM algorithm rows including identifiers 55 through 65, and those entries currently reference the substantially earlier draft-ietf-lamps-pq-composite-kem-10. The current dependency text, meanwhile, describes the algorithm identifiers as registered while its own module registration still contains a replacement placeholder.

This is exactly the kind of state divergence that infrastructure teams need to preserve rather than flatten. An OID existing in a registry establishes identifier provenance. It does not establish that the current normative draft has finished IESG review, that all dependent ASN.1 module assignments have been finalized, that a particular software release implements the final semantics, or that two production endpoints have compatible certificate and CMS behavior.

Similarly, IANA’s 2026 draft-status report shows the CMS document’s action as In Progress. Registration machinery is moving, but “moving” is not “complete.”

The operational control surface is wider than the standard

For an enterprise or service provider, the deployable object is not draft-ietf-lamps-cms-composite-kem-03 by itself. It is a chain that runs from normative specifications through identifiers, certificate issuance, cryptographic libraries, CMS implementations, endpoint configuration and policy.

The CMS document illustrates why. It requires the originator to perform encapsulation and the recipient to perform decapsulation; it defines how Composite ML-KEM is carried through KEMRecipientInfo; it specifies certificate use; and it allows S/MIME implementations to advertise Composite ML-KEM identifiers through SMIMECapabilities.

A production transaction can therefore fail even when every component is individually standards-aware. One side may possess the algorithm OID but not the same composite combination. A certificate may carry the expected public key while the receiving CMS implementation lacks the corresponding KEMRecipientInfo behavior. An S/MIME capability declaration may advertise an identifier that the peer’s installed crypto provider cannot actually execute. A library may implement an earlier draft revision whose serialization or error-handling behavior no longer matches the other side.

The impact mechanism is coordination failure: standards state, software state, certificate state and policy state diverge.

Economically, the cost appears as integration work, certificate reissuance, vendor coordination, failed exchanges, delayed migrations and potentially stranded configuration. Those costs arise before any cryptographic weakness is required.

The receipt operators should require

A defensible enablement decision therefore needs a companion-dependency receipt, not a screenshot saying “Approved.” That receipt should bind the exact draft revisions and cryptographic hashes of both documents; timestamp the IESG, RFC Editor and IANA states independently; record the exact normative-reference version and all module or placeholder dependencies; and preserve the provenance of every algorithm identifier and OID.

It should then show closure: evidence that DISCUSS positions and required revisions are resolved, final RFC numbers and IANA assignments when publication occurs, and the exact algorithm combinations the implementation supports.

The implementation half of the receipt is just as important. It should identify the software versions at both endpoints, document their KEMRecipientInfo behavior, certificate conventions and SMIMECapabilities declarations, bind testing to named test vectors, and state the scope of bilateral interoperability actually demonstrated.

Finally, the receipt needs the production decision itself: which combinations are enabled, whether fallback is permitted, what conditions trigger rollback, and what technical or commercial events require exit from the deployed configuration.

Without those joins, “support” is an aggregation of unrelated claims rather than an operational fact.

Evidence boundary and uncertainty

The IETF announcement provides meaningful evidence of maturity: it reports substantial code and significant Hackathon work aimed at interoperability. It also records working-group consensus after debate over how many combinations should be included.

Neither point should be stretched further than the evidence allows. Working-group consensus is evidence of standards-process agreement, not universal customer demand. Hackathon interoperability demonstrates that identified implementations could interoperate in tested circumstances; it does not establish compatibility across every implementation, every Composite ML-KEM combination, every certificate profile or every production environment.

The same boundary applies to lower-level artifacts. A registry entry proves that an identifier has been registered. A test vector can prove conformance to the vector under the tested implementation. A laboratory exchange can prove that two tested endpoints exchanged data successfully under defined conditions.

None of those, alone, proves bilateral production readiness.

The strongest current fact is therefore a split state: the CMS companion has cleared IESG approval, while RFC publication, its normative dependency and associated IANA/module processing have not all converged.

Sources