Zusammenfassung

  • Am 10. September 2026 wies die IESG einen Einspruch zurück, löste die Veröffentlichungssperre und verschickte die Billigung für draft-ietf-tls-mldsa-05. Das Dokument beschreibt FIPS-204-ML-DSA-Signaturen zur Authentisierung in TLS 1.3. Vorgesehen ist ein Informational RFC; zum Prüfzeitpunkt war es weiterhin ein Internet-Draft ohne RFC-Nummer.
  • Im IANA-Register TLS SignatureScheme stehen mldsa44, mldsa65 und mldsa87 unter 0x0904, 0x0905 und 0x0906. Alle drei sind mit N markiert. Nach RFC 9847 bedeutet N, dass die IETF keine Eignungsaussage trifft oder kein Konsens besteht; es ist nicht das Abraten kennzeichnende D.
  • Veröffentlichung, interoperable Zuteilung und Einsatzempfehlung sind eigenständige Handlungen. Die Einspruchsentscheidung beendet den vor der IESG anhängigen Verfahrensstreit, wählt aber nicht für jeden Betreiber zwischen reinem und zusammengesetztem ML-DSA.
  • Wer das Verfahren aktiviert, sollte einen lokalen Entscheidungsbeleg führen: TLS-Fläche, Profil und Parametersatz, Gegenstellen und Zertifikate, datierte Nachweise, Fehlerschwellen, Rücknahmebefugnis und nächste Prüfung.

Gebilligt wurde das Vorankommen des Dokuments

Die Datatracker-Chronik zeigt zwei getrennte Vorgänge. Am 8. Juli billigte die IESG das Dokument, hielt es aber am selben Tag wegen eines Einspruchs zurück. Am 10. September wies sie den Einspruch ab, löste die Sperre und setzte das Dokument wieder auf „Approved-announcement sent“. Die Bekanntmachung bezeichnet es als Ergebnis der TLS-Arbeitsgruppe mit dem vorgesehenen Status Informational.

Der Streit bleibt im Vorgang sichtbar. Die Zusammenfassung des Document Shepherd nennt rund 275 Nachrichten und beschreibt das Verhältnis für ein Vorankommen mit ungefähr vier zu eins. Sie nennt auch abweichende Positionen: reines ML-DSA nicht veröffentlichen, zusammengesetzte Verfahren empfehlen oder beide Wege gleichzeitig herausgeben. Die Antwort der IESG erklärt, sie habe die Rückmeldungen aus dem Working Group Last Call geprüft, breite Unterstützung gefunden und festgestellt, dass Einwände berücksichtigt und erörtert wurden. Deb Cooley nahm als Security Area Director an dieser Entscheidung nicht teil.

Damit ist geklärt, dass rough consensus für die Veröffentlichung bestand. Nicht geklärt ist, ob jedes technische Bedenken erledigt oder welches Profil für eine bestimmte Infrastruktur richtig ist. Ein Einspruchsbescheid ist eine Kontrolle der vorgelegten Verfahrensentscheidung. Er übernimmt weder die Haftung für Zertifikatsketten noch die Verfügbarkeit einer gemischten Client-Flotte.

Auch sprachlich ist die Produktionsstufe zu erhalten. Die aktuelle Datatracker-Seite nennt den Zustand Approved-announcement sent, führt Version 05 aber weiter als aktiven Internet-Draft. Die IANA-Prüfung lautet Version Changed - Review Needed, die Aktion In Progress. Eine RFC-Nummer gibt es noch nicht. Richtig ist daher „zur Veröffentlichung gebilligt“, nicht „bereits als nummerierter RFC erschienen“.

Drei Zuteilungen schaffen Eindeutigkeit

FIPS 204 standardisiert ML-DSA als Post-Quanten-Signaturverfahren. Das IETF-Dokument löst einen engeren Punkt: Es verbindet drei Parametersätze mit der Signaturalgorithmus-Aushandlung von TLS 1.3. ML-DSA-44 erhält mldsa44/0x0904, ML-DSA-65 mldsa65/0x0905 und ML-DSA-87 mldsa87/0x0906.

RFC 9881 definiert die zugehörigen AlgorithmIdentifiers in X.509. Der TLS-Entwurf macht daraus aushandelbare SignatureSchemes. Wird einer der Werte in CertificateVerify eingesetzt, erfolgen Signieren und Prüfen nach FIPS 204 mit leerem ctx; das End-Entity-Zertifikat muss den passenden AlgorithmIdentifier verwenden. Die vorgehashten HashML-DSA-Varianten sind nicht gemeint.

Diese Festlegungen verhindern, dass getrennte Implementierungen dieselbe Technik verschieden benennen oder codieren. Sie beweisen nicht, dass eine Zertifizierungsstelle die erforderliche Kette ausstellt, Clients sie annehmen, das gewählte Hardwaremodul Schlüssel sicher verarbeitet oder ein gemischter Bestand eine Teilaktivierung zurücknehmen kann. Eindeutigkeit auf dem Draht ist Voraussetzung, nicht Einsatzfreigabe.

Im Live-Register der IANA sind die drei Werte mit N sichtbar. Die Referenz zeigt noch auf eine frühere Entwurfsfassung, während Datatracker die IANA-Arbeit als laufend meldet. Beides ist gleichzeitig wahr: Die Werte sind zugeteilt und öffentlich; Referenzpflege und abschließende Publikation sind noch nicht vollständig erledigt.

N ist weder Ablehnung noch Freigabe

RFC 9847 gibt der Spalte drei Zustände. Y bedeutet IETF-Konsens, dass ein Eintrag für seinen definierten Zweck empfohlen und geeignet ist, wobei Anwendungsgrenzen weiter gelten. D kennzeichnet ein abgeratenes Verfahren und verlangt eine Begründung. N sagt, dass die IETF keine Eignungsaussage getroffen hat, kein Konsens besteht oder der Einsatz eingeschränkt sein kann.

Der RFC stellt ausdrücklich klar, dass N nicht zwingend einen Mangel bedeutet. Ein Codepoint ist folglich kein grünes Licht, N aber auch kein rotes. Der Eintrag lässt Implementierungen dasselbe Objekt testen, ohne aus der Zuteilung einen nicht vorhandenen allgemeinen Eignungskonsens zu machen.

Würde jede Zuteilung als Empfehlung gelesen, bekäme Registerpflege unbeabsichtigt die Wirkung einer Sicherheitszulassung. Würde N als Verbot gelesen, verschwände der Unterschied zwischen „nicht bewertet“ und „abgeraten“. Beide Verkürzungen geben der gemeinsamen Schicht mehr Entscheidungsmacht, als sie beansprucht.

Reines und zusammengesetztes ML-DSA haben nicht denselben Status

Das gebilligte Dokument beschreibt reines ML-DSA. Ein gesonderter aktiver individueller Internet-Draft kombiniert ML-DSA mit einem klassischen Signaturverfahren in TLS 1.3. Datatracker weist darauf hin, dass dieser individuelle Entwurf keine Unterstützung durch einen IETF-Stream besitzt. Er belegt eine ausgearbeitete Alternative, keine gleichrangige institutionelle Entscheidung.

Welcher Ansatz tragfähig ist, hängt vom Bedrohungsmodell ab. Das reine Profil erspart die erfolgreiche Prüfung einer zweiten Signatur, bündelt die Sicherheit aber in ML-DSA und dessen Implementierung. Ein zusammengesetztes Profil kann bei einem Bruch des neuen Verfahrens oder seiner Software eine klassische Komponente bewahren; zugleich wachsen Zertifikate, Nachrichten, Rechenaufwand und Kompatibilitätsrisiken. Ein Informational-Status verrechnet diese Größen nicht für jedes System.

Auch die Implementierungsliste der Bekanntmachung ist kein Flottennachweis. Code in OpenSSL, BoringSSL, rustls-post-quantum, s2n-tls, wolfSSL, Bouncy Castle oder GnuTLS belegt konkrete Entwicklungsarbeit. Er belegt weder standardmäßige Aktivierung noch Produktivverkehr, gemeinsame Zertifikatsketten, akzeptable Latenz oder eine erprobte Rücknahme.

Der fehlende Beleg entsteht beim Betreiber

Zuerst braucht die Entscheidung einen genauen Gegenstand. „Post-Quanten-fähig“ ist zu breit. Server- oder Client-Authentisierung, ein abgegrenzter privater Dienst oder ein öffentliches Experiment sind verschiedene Flächen. Parametersatz sowie reine oder zusammengesetzte Ausprägung gehören ausdrücklich in den Beleg.

Danach wird die Population festgelegt: Aussteller, Zertifikatsprofile, Endpunkte, Clients, Bibliotheken und Hardwaregrenzen. Für die Aushandlung muss feststehen, was geschieht, wenn die Gegenstelle den neuen Wert nicht anbietet. Wird abgebrochen, eine andere Kette präsentiert, umgeleitet oder auf ein zugelassenes Verfahren zurückgefallen? Ein unsichtbarer Fallback kann Verfügbarkeit retten und die beabsichtigte Sicherheit zugleich aufheben.

Nachweise brauchen Datum und Vielfalt. Interoperabilitätstests sollten unterschiedliche Implementierungsfamilien verbinden. Handshake-Größe, CPU und Latenz sind unter realistischer Parallelität zu messen. Schlüsselerzeugung, Signieren, Prüfen, Zufalls- oder deterministischer Modus und Seitenkanäle müssen in der tatsächlichen Betriebsgrenze untersucht werden. Ausstellung und vollständige Kettenprüfung dürfen nicht durch einen isolierten Signaturtest ersetzt werden.

Schließlich benennt der Beleg, wer ausweiten und wer abschalten darf, welche Telemetrie den Rückbau auslöst, wie verteilte Schlüssel und Zertifikate ausscheiden, wann die Evidenz verfällt und wann neu entschieden wird. Er ändert den IANA-Eintrag nicht. Er macht die von der IETF bewusst offengelassene Betreiberentscheidung zurechenbar.

Evidenzgrenzen

Keine Quelle belegt eine Standardaktivierung oder allgemeine Produktivnutzung. Die Quellen entscheiden nicht universell zwischen rein und zusammengesetzt. Die Einspruchsantwort ist eine Verfahrensbewertung, kein kryptografischer Beweis. Die NIST-Standardisierung ist keine TLS-Einsatzprüfung. Sichtbare Registerzeilen beweisen nicht den Abschluss sämtlicher IANA- und RFC-Editor-Arbeiten.

Der belastbare Befund ist kleiner: Die IETF hat die Veröffentlichung einer interoperablen Beschreibung für drei ML-DSA-Parametersätze in TLS 1.3 gebilligt, während das Register den Empfehlungszustand N bewahrt. Der nächste Nachweis gehört jedem einzelnen Anwender.

Quellen

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Billigungsmitteilung zu Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — Dokumenthistorie
  7. IESG — Antwort auf den Einspruch, Artefakt 320
  8. IANA — Transport Layer Security Parameters
  9. RFC 9847 — IANA Registry Updates for TLS and DTLS
  10. NIST — FIPS 204, ML-DSA-Standard
  11. RFC 9881 — Algorithmuskennungen für ML-DSA
  12. RFC 9846 — Das Protokoll TLS 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3