Zusammenfassung

  • Die IESG-Genehmigung von draft-ietf-lamps-cms-composite-kem-03 am 18. September 2026 reduziert die Standardisierungsunsicherheit für die CMS-spezifische Einbettung von Composite ML-KEM. Sie macht den Entwurf jedoch nicht zu einem RFC. Der Datatracker zeigt RFC Ed Queue, der RFC Editor blocked: Reference Not Received, IANA steht auf In Progress beziehungsweise IANA OK - Actions Needed.
  • Das CMS-Dokument ist ausdrücklich ein Begleitdokument zu draft-ietf-lamps-pq-composite-kem-21. Es übernimmt von dieser normativen Abhängigkeit unter anderem die eigentlichen Composite-KEM-Verfahren, die Aufnahme der öffentlichen Schlüssel in X.509-Zertifikate und die Composite-ML-KEM-Kennungen. Die Abhängigkeit befindet sich weiterhin im Zustand IESG Evaluation::Revised I-D Needed, mit zwei DISCUSS-Positionen und noch erforderlichen IANA-Maßnahmen.
  • Standardisierungsstatus, RFC-Publikation, IANA-Zuweisung, Algorithmusdefinition, Implementierungsunterstützung, Interoperabilität zweier konkreter Endpunkte und Produktionsaktivierung sind verschiedene Zustände. Sie sollten weder technisch noch in Beschaffung, Risiko-Reporting oder Produktkommunikation zu einem einzigen Label wie „unterstützt“ zusammengezogen werden.
  • Ein belastbares Freigabemodell braucht deshalb einen überprüfbaren Companion-Dependency Receipt: einen Belegsatz, der exakte Dokumentversionen und Hashes, zeitgestempelte Prozesszustände, endgültige Kennungen, Implementierungsversionen, getestete Kombinationen, konkrete Interoperabilität und operative Fallback-, Rollback- und Ausstiegskriterien miteinander verbindet.

Was am 18. September tatsächlich passiert ist

Die IESG-Mitteilung ist eindeutig: draft-ietf-lamps-cms-composite-kem-03, Composite ML-KEM for use in Cryptographic Message Syntax (CMS), wurde als Proposed Standard genehmigt. Die Mitteilung beschreibt den Entwurf zugleich als Begleitdokument zu draft-ietf-lamps-pq-composite-kem-21.

Damit ist eine wichtige Governance-Hürde genommen. Der CMS-spezifische Teil hat die IESG-Genehmigung erreicht. Für Organisationen, die ihre Post-Quanten-Migration planen, ist das relevant, weil die Konventionen für die Nutzung von Composite ML-KEM innerhalb von CMS nicht mehr lediglich auf Working-Group-Ebene stehen.

Aber die nächste Aussage darf nicht lauten: „Composite ML-KEM für CMS ist jetzt als RFC veröffentlicht.“ Der aktuelle Zustand spricht dagegen. Der Datatracker führt den Entwurf als aktiven Internet-Draft und zeigt für die IESG-Seite RFC Ed Queue. Beim RFC Editor steht er auf blocked: Reference Not Received. Für IANA lautet der Aktionsstatus In Progress, während die Review-Anzeige IANA OK - Actions Needed meldet.

Diese Unterschiede sind mehr als Prozesssemantik. Sie markieren unterschiedliche Kontrollpunkte. Eine IESG-Genehmigung beantwortet eine andere Frage als die RFC-Veröffentlichung; eine IANA-Registrierung eine andere als ein bestandener Interoperabilitätstest; und selbst ein erfolgreicher Test entscheidet nicht, ob ein Betreiber eine Funktion in der Produktion aktivieren sollte.

Eine brauchbare Statusdarstellung sieht daher nicht wie ein einzelnes Ampelfeld aus:

Zustand Aktueller Befund Was daraus nicht folgt
IESG-Genehmigung des CMS-Entwurfs erfolgt am 18. September 2026 keine RFC-Veröffentlichung
RFC-Editor-Prozess RFC Ed Queue, blockiert wegen fehlender Referenz keine endgültige RFC-Nummer
IANA für CMS In Progress, IANA OK - Actions Needed keine vollständig abgeschlossene Registrierungsarbeit
Normative Companion-Abhängigkeit IESG Evaluation::Revised I-D Needed keine Genehmigung der Abhängigkeit
DISCUSS der Abhängigkeit zwei Positionen im Datatracker keine belegte Auflösung
Algorithmus/OID-Arbeit Definitionen vorhanden; Registereinträge existieren keine universelle Implementierungsunterstützung
Implementierung Code und Hackathon-Arbeit dokumentiert keine Abdeckung aller Produkte und Kombinationen
Interoperabilität begrenzte Implementierungserfahrung vorhanden kein Nachweis für beliebige Endpunktpaare
Produktionsaktivierung Entscheidung jedes Betreibers beziehungsweise Produkts folgt aus keinem der obigen Zustände automatisch

Gerade für Beschaffung und Risikomanagement ist diese Trennung wirtschaftlich relevant. Wer „standardisiert“, „implementiert“, „interoperabel“ und „produktionsfähig“ als Synonyme behandelt, kann Abhängigkeiten zu früh in Verträge, Zertifikatsprofile oder Produkt-Roadmaps einbauen. Die späteren Kosten entstehen dann nicht primär durch Kryptografie, sondern durch Koordination und Rückbau.

Die eigentliche Einheit ist ein Dokumentpaar

Der CMS-Entwurf definiert nicht das gesamte Composite-ML-KEM-System neu. Er baut auf draft-ietf-lamps-pq-composite-kem-21 auf.

Das Basismodell ist klar getrennt. Der Companion-Entwurf definiert die Composite-KEM-Verfahren selbst. Der CMS-Entwurf übernimmt diese Verfahren und beschreibt, wie sie in die bereits durch RFC 9629 definierte KEMRecipientInfo-Struktur eingebettet werden.

Die Trennung reicht bis zu den Kernoperationen. Für Composite ML-KEM verweist das CMS-Dokument auf die andere Spezifikation für KeyGen(), Encaps() und Decaps(). Im CMS-Kontext verwendet es die RFC-9629-Terminologie Encapsulate() und Decapsulate(), macht aber ausdrücklich die Zuordnung zu Encaps() und Decaps() der Companion-Spezifikation.

Auch die X.509-Seite verbleibt außerhalb des CMS-Dokuments. Ein Empfänger benötigt einen statischen öffentlichen Schlüssel; dieser wird aus seinem Zertifikat gewonnen. Die Konventionen dafür, wie Composite-ML-KEM-Schlüssel in Zertifikaten transportiert werden, werden an draft-ietf-lamps-pq-composite-kem delegiert.

Dasselbe gilt für die wesentlichen Composite-ML-KEM-Kennungen. Der CMS-Entwurf reproduziert OIDs für die Nutzung innerhalb von CMS, erklärt aber ausdrücklich, dass die Composite-ML-KEM-Identifikatoren in der Companion-Spezifikation definiert sind.

Das bedeutet operativ: Die Genehmigung des CMS-Bindings kann nicht unabhängig von der Stabilität des Algorithmus- und X.509-Dokuments bewertet werden.

Die normative Abhängigkeit ist noch nicht geschlossen

Der CMS-Entwurf verweist in seiner normativen Referenz ausdrücklich auf draft-ietf-lamps-pq-composite-kem-21 vom 1. September 2026. Die Versionsbindung ist damit konkret und nachprüfbar.

Der aktuelle Datatracker-Zustand dieses Companion-Dokuments lautet jedoch IESG Evaluation::Revised I-D Needed. Zusätzlich zeigt der Ballot zwei DISCUSS-Positionen und hält fest, dass genügend Positionen zum Bestehen vorhanden wären, sobald die DISCUSS-Punkte gelöst sind.

Das ist gerade keine Genehmigung. Es bedeutet auch nicht, dass eine Lösung bereits feststeht oder dass die noch erforderliche Revision ausschließlich redaktionell sein wird. Ein Teil der offenen Diskussion betrifft normative beziehungsweise formale Spezifikationsfragen, darunter Anforderungen rund um das ASN.1-Modul. IANA führt für den Entwurf ebenfalls IANA OK - Actions Needed.

Der sichtbare Block beim RFC Editor für das CMS-Dokument — Reference Not Received — passt deshalb zur strukturellen Abhängigkeit: Ein bereits genehmigtes Dokument kann in der Publikationspipeline auf sein normativ referenziertes Companion-Dokument warten.

Aus wirtschaftlicher Sicht ist genau hier die zentrale Verzögerungslogik zu sehen. Die Genehmigung eines Teilstücks reduziert das Risiko, dass der CMS-Ansatz grundsätzlich verworfen wird. Sie beseitigt aber nicht das Koordinationsrisiko des Gesamtpakets.

OIDs können sichtbar sein, bevor die Publikationskette geschlossen ist

Besonders leicht entsteht ein falscher Reifeeindruck durch registrierte Objektkennungen.

Das IANA-SMI-Register enthält bereits Composite-ML-KEM-Einträge. Die Kennungen 55 bis 65 sind dort sichtbar und verweisen derzeit noch auf eine ältere Fassung, draft-ietf-lamps-pq-composite-kem-10. Auch die aktuelle Companion-Spezifikation verwendet diese OID-Familie für ihre Composite-KEM-Kombinationen.

Das ist reale Infrastruktur: Eine OID-Zuweisung ist kein bloßer Textvorschlag. Trotzdem ist sie kein Ersatz für den Abschluss der Spezifikations- und Publikationskette.

Insbesondere enthält der CMS-Entwurf selbst noch einen RFC-Editor-Platzhalter. TBDCompositeMOD soll durch die Modulnummer ersetzt werden, die für id-mod-composite-mlkem-2025 aus der Companion-Spezifikation vergeben wird. Damit ist die Kopplung nicht nur konzeptionell oder durch eine Literaturangabe sichtbar, sondern im ASN.1-Publikationsmaterial selbst.

Für Governance-Systeme folgt daraus eine wichtige Regel: „OID vorhanden“ ist ein eigener Status. Er darf weder als „RFC fertig“ noch als „Produktion unterstützt“ modelliert werden.

Register können zeitlich vor anderen Teilen der Standardisierungskette liegen. Ebenso können ihre Referenzen auf ältere Draft-Versionen zeigen. Wer nur das Vorhandensein einer Nummer prüft, verpasst deshalb die Provenienzfrage: Von welcher Spezifikationsversion stammt die Semantik, und ist diese Semantik identisch mit dem später veröffentlichten Text?

CMS erweitert die Nutzungsschicht, nicht den Algorithmuskern

Die Rolle des CMS-Dokuments wird klarer, wenn man seine Kontrollfläche präzise eingrenzt.

RFC 9629 definiert KEMRecipientInfo für den Einsatz von KEM-Algorithmen in CMS. Der Composite-ML-KEM-Entwurf für CMS legt darauf aufbauend fest, wie Composite ML-KEM mit dieser Struktur verwendet wird. Ein CMS-Ursprungspunkt muss für diesen Fall die Encapsulation-Funktion implementieren, der Empfänger die Decapsulation-Funktion.

Für einen Empfänger wird OtherRecipientInfo mit der KEMRecipientInfo-Struktur verwendet. Darüber hinaus definiert der Entwurf Regeln für die Zertifikatsnutzung und für SMIMECapabilities.

Bei Letzteren kann eine Implementierung Unterstützung für einen oder mehrere Composite-ML-KEM-Algorithmusidentifikatoren ankündigen. Die entsprechende SMIMECapability enthält die Composite-ML-KEM-OID im capabilityID-Feld; Parameter sind bei diesen OIDs nicht vorgesehen.

Damit entsteht eine mehrschichtige Kompatibilitätsfrage. Zwei Systeme können dieselbe Bibliothek besitzen und trotzdem nicht dasselbe operative Profil unterstützen. Relevant sind mindestens:

  • die konkrete Composite-ML-KEM-Kombination,
  • die Zertifikatsdarstellung des öffentlichen Schlüssels,
  • die verwendete KEMRecipientInfo-Verarbeitung,
  • die interpretierte OID,
  • die Fähigkeit zur korrekten Encapsulation beziehungsweise Decapsulation,
  • gegebenenfalls die angekündigten SMIMECapabilities,
  • sowie die tatsächlichen Produkt- und Bibliotheksversionen auf beiden Seiten.

„Unterstützt Composite ML-KEM“ ist daher für eine Produktionsentscheidung zu grob.

Implementierung und Hackathon sind Evidenz — aber begrenzte Evidenz

Die IESG-Mitteilung beschreibt umfangreiche Code-Arbeit und Interoperabilitätstests beim Hackathon. Das ist wertvoll. Spezifikationen, die tatsächlich implementiert und zwischen unabhängigen Teilnehmern ausprobiert werden, liefern stärkere technische Evidenz als ein ausschließlich auf Papier geprüfter Mechanismus.

Aber daraus darf keine Universalbehauptung entstehen.

Hackathon-Interoperabilität zeigt nicht automatisch, dass alle verfügbaren Implementierungen, sämtliche Composite-Kombinationen, alle X.509-Zertifikatspfade und jede CMS-Verarbeitungsvariante interoperabel sind. Sie beweist ebenfalls nicht, dass ein konkretes kommerzielles Produkt die Funktion in einer freigegebenen Produktionsversion anbietet.

Dass in der Working Group Konsens bestand und Teilnehmer die spezifizierten Kombinationen wollten, ist ebenso kein Nachweis für universelle Marktnachfrage. WG-Konsens beantwortet eine Standardisierungsfrage. Nachfrage, Beschaffungsvolumen und Aktivierungsbereitschaft sind andere Größen.

Für Betreiber ist der Unterschied wesentlich: Die Kosten einer Migration hängen nicht davon ab, ob irgendwo interoperabler Code existiert, sondern davon, ob ihre beiden Endpunkte, Zertifikatsketten und Betriebsprozesse dasselbe Profil zuverlässig abbilden.

Der Wirkungsmechanismus ist Koordination

Der technische Mechanismus endet bei Schlüsselerzeugung und Kapselung. Der wirtschaftliche Mechanismus reicht weiter.

Composite-Verfahren koppeln neue und traditionelle kryptografische Komponenten. In einem realen CMS- oder S/MIME-Umfeld müssen diese Entscheidungen durch Zertifikate, Kennungen, Bibliotheken, Sender, Empfänger und häufig mehrere organisatorische Zuständigkeiten hindurch konsistent bleiben.

Dadurch entsteht ein Koordinationsproblem mit mehreren Kostenstellen.

Eine PKI kann ein neues Zertifikatsprofil unterstützen, während der Empfänger-Stack es noch nicht akzeptiert. Eine Kryptobibliothek kann die Algorithmen implementieren, während die Anwendung KEMRecipientInfo nicht vollständig integriert hat. Ein Produkt kann mehrere Composite-Kombinationen kompilieren, aber nur einen Teil davon für den Support freigeben. Zwei Produkte können jeweils „Unterstützung“ melden und dennoch unterschiedliche Kombinationen oder Capability-Signale erwarten.

Die teuerste Fehlentscheidung ist deshalb häufig nicht ein fehlgeschlagener Labortest, sondern eine zu früh verbreitete Abhängigkeit: ausgestellte Zertifikate, gespeicherte CMS-Objekte, externe Partnervereinbarungen oder automatisierte Policies, die eine bestimmte Semantik bereits voraussetzen.

Das spricht nicht gegen frühe Implementierung. Es spricht für eine präzise Trennung von Erprobung und Aktivierung.

Ein prüfbarer Companion-Dependency Receipt

Organisationen, die den Übergang belastbar steuern wollen, können die Freigabe an einen gemeinsamen Nachweis für beide Dokumente binden. Ein solcher Companion-Dependency Receipt sollte kein Marketing-Siegel sein, sondern ein reproduzierbarer Datensatz.

Er sollte zunächst die Artefakte selbst fixieren: exakter Name und Versionsnummer beider Internet-Drafts sowie ein kryptografischer Hash der tatsächlich geprüften Dateien. Für den aktuellen CMS-Stand wären damit beispielsweise draft-ietf-lamps-cms-composite-kem-03 und die konkret normative Companion-Version draft-ietf-lamps-pq-composite-kem-21 eindeutig gebunden.

Hinzu kommen zeitgestempelte Zustände aus Datatracker, RFC-Editor- und IANA-Systemen. Ein Receipt sollte also nicht nur „approved“ speichern, sondern separat festhalten, ob ein Dokument genehmigt, in der RFC-Editor-Warteschlange, blockiert, bei IANA in Bearbeitung oder endgültig publiziert ist.

Für die Abhängigkeit müssen mindestens dokumentiert werden:

  1. die normative Referenz vom CMS-Dokument auf die konkrete Companion-Version;
  2. noch vorhandene RFC-Editor-Platzhalter und ihre Herkunft;
  3. die Provenienz aller verwendeten Algorithmus- und OID-Zuweisungen;
  4. der Abschluss aller DISCUSS-Positionen und erforderlichen Revisionen;
  5. die endgültigen RFC-Nummern und finalen IANA-Zuweisungen;
  6. ein Vergleich, ob sich relevante Semantik gegenüber den getesteten Draft-Versionen verändert hat.

Erst danach beginnt der produktspezifische Teil. Dort sollte der Receipt die tatsächlich unterstützten Composite-Kombinationen auf beiden Endpunkten nennen, statt lediglich ein boolesches Feld „Composite ML-KEM = ja“ zu verwenden.

Ebenso gehören hinein: die konkrete KEMRecipientInfo-Unterstützung, Zertifikatsprofil und Schlüsselaufnahme, Verarbeitung beziehungsweise Erzeugung von SMIMECapabilities, Software- und Bibliotheksversionen beider Endpunkte sowie die verwendeten Testvektoren.

Ein Interoperabilitätsnachweis sollte zudem seinen Umfang nennen: Welche Kombination wurde mit welchem Zertifikat zwischen welchen Versionen in welcher Richtung getestet? Wurde nur Entschlüsselung geprüft oder auch Erzeugung, Capability-Aushandlung, Fehlerbehandlung und gemischter Betrieb?

Schließlich braucht der Receipt eine betriebliche Ebene: Aktivierungsregel, Fallback-Verhalten, Rollback-Pfad und Ausstiegskriterien. Damit wird er zu einem Instrument für Change Management und nicht nur zu einer Dokumentensammlung.

Evidenzgrenzen und verbleibende Unsicherheit

Der aktuelle Befund erlaubt mehrere positive Aussagen: Der CMS-Entwurf hat die IESG-Genehmigung erreicht. Seine CMS-Konventionen sind konkret. Die Companion-Abhängigkeit ist explizit. Implementierungserfahrung existiert. OIDs sind im IANA-Register sichtbar.

Nicht belegt sind dagegen die Genehmigung der Companion-Spezifikation, die Auflösung ihrer beiden DISCUSS-Positionen, der Abschluss sämtlicher IANA-Arbeit oder die Veröffentlichung des CMS-Dokuments als RFC.

Ebenso wenig lässt sich aus den vorliegenden öffentlichen Informationen eine vollständige Einführung aller definierten Composite-Kombinationen in Produkten oder Produktionsnetzen ableiten.

Diese Grenzen sind kein Detail. Sie definieren, welche Entscheidungen heute bereits vertretbar dokumentiert werden können. Labore, Implementierer und Produktteams können mit den konkreten Drafts arbeiten. Für Produktionsfreigaben sollte der Nachweis dagegen enger an konkrete Versionen und konkrete Endpunkte gebunden sein.

Quellen