Post-Quanten-Signaturen und öffentliche TLS-Zertifikate: Einsatzreife getrennt prüfen

Worum es geht

Stand: 25. Oktober 2026. NIST veröffentlichte am 13. August 2024 FIPS 204 zur Spezifikation von ML-DSA und FIPS 205 zur Spezifikation von SLH-DSA. Es handelt sich um Standards für digitale Signaturen. Vor der Planung von Zertifikatsänderungen die Errata von NIST, den IETF-Veröffentlichungsstatus und die geltenden Anforderungen des CA/Browser Forum erneut prüfen. Die Einstiegsseite zu FIPS 204 enthält einen Planungshinweis vom 31. Juli 2026 zu kleineren Problemen, deren Korrektur für die Zukunft vorgesehen ist.

Die Standardisierung des Algorithmus, die Zertifikatskodierung, die TLS-Authentifizierung und die Anerkennung im öffentlichen Vertrauenssystem sind separate Meilensteine. Ein Post-Quanten-Schlüsselaustausch macht weder den öffentlichen Schlüssel eines bestehenden Zertifikats noch dessen Ausstellersignatur zu einer Post-Quanten-Signatur.

Warum es wichtig ist

Es gibt bereits einen Standard für die X.509-Integration: RFC 9881, veröffentlicht im Oktober 2025, definiert ML-DSA-Konventionen für Zertifikate und Zertifikatssperrlisten. Er umfasst die reine ML-DSA-Variante und schliesst HashML-DSA in diesem Profil aus. Die Behauptung, sämtliche Arbeiten an ML-DSA-Zertifikaten seien weiterhin unveröffentlichte Vorschläge, wäre daher falsch.

Die TLS-Integration hat einen eigenen Status. Der IETF-Tracker führt draft-ietf-tls-mldsa-06 vom 11. September 2026 als laufende Arbeit in der Warteschlange des RFC Editor; der Tracker wurde zuletzt am 12. Oktober 2026 aktualisiert. Das entspricht keinem bereits veröffentlichten TLS-RFC.

Für herkömmliche, öffentlich vertrauenswürdige TLS-Zertifikate beschränken die Baseline Requirements des CA/Browser Forum in Version 2.3.1 vom 4. Oktober 2026 die relevanten Kodierungen weiterhin auf klassische Algorithmen. Abschnitt 7.1.3.1 erlaubt öffentliche Schlüssel des Zertifikatsinhabers auf Basis von RSA und ECDSA, und Abschnitt 7.1.3.2 legt klassische Signaturkodierungen fest. Keiner der beiden Abschnitte enthält ein Ausstellungsprofil für ML-DSA oder SLH-DSA. Dies erklärt, weshalb innerhalb dieses Regelwerks weiterhin klassische Zertifikate erforderlich sind; es ist keine Bestandsaufnahme sämtlicher Zertifizierungsstellen, experimenteller Vertrauenssysteme oder privater PKI.

So wird es angewendet

• Schlüsselvereinbarung, den öffentlichen Schlüssel des Zertifikatsinhabers, die Signatur des Ausstellers und die Handshake-Authentifizierung getrennt erfassen. Für jede Aussage Nachweise verlangen, statt eine einzige Post-Quanten-Kennzeichnung für die gesamte Verbindung zu akzeptieren.
• Für ein Experiment mit ML-DSA-Zertifikaten die genaue Algorithmusvariante und das Zertifikatsprofil bestimmen. RFC 9881 liefert die Grundlage für die Kodierung; er belegt für sich genommen keine Anerkennung durch ein öffentliches Root-Programm oder jeden Client.
• Vor einem öffentlichen Deployment die aktuellen TLS Baseline Requirements, die relevante Richtlinie der Zertifizierungsstelle und die Vertrauensrichtlinien der vorgesehenen Clients prüfen. Genehmigte Algorithmusänderungen und ihre Wirksamkeitsdaten verfolgen. Ein Entwurf oder eine zugewiesene Algorithmuskennung allein belegt keine Einsatzreife.
• Versuche mit privater PKI von Annahmen zur öffentlichen Ausstellung trennen. Ergebnisse zu Kettenvalidierung, Authentifizierung, Erneuerung, Sperrung und Interoperabilität für die tatsächlich beteiligte Software festhalten. Die öffentlichen TLS Baseline Requirements schliessen rein interne Unternehmens-PKI ausdrücklich aus ihrem Geltungsbereich aus.
• Korrekturen zu FIPS 204, die Veröffentlichungsseite von FIPS 205, RFC-Errata und den Dokumentstatus der TLS-Arbeitsgruppe verfolgen. Das Inventar aktualisieren, wenn sich das Verhalten der eingesetzten Systeme ändert, nicht schon bei der Ankündigung einer Spezifikation.

Stolpersteine

Aus der Unterstützung eines Schlüsselaustauschverfahrens nicht auf Signaturunterstützung schliessen und die Algorithmenliste einer Bibliothek nicht als Nachweis für Browservertrauen behandeln. Ebenso begründet die NIST-Standardisierung von SLH-DSA kein Profil für öffentliche TLS-Zertifikate. Hier werden weder ein allgemeiner Einführungstermin für Browser noch eine Migrationsfrist für Zertifizierungsstellen oder der Umfang experimenteller Deployments behauptet. Dafür sind separate, aktuelle Primärnachweise erforderlich.