Post-Quantum Security ist kein Zukunftsthema — RFC 9964, ML-DSA und was wir heute bereits produktiv einsetzen

TL;DR — die 90-Sekunden-Zusammenfassung

Post-Quantum-Kryptografie landet in den meisten Unternehmen noch in der Schublade „interessant, aber nicht jetzt“. Verständlich — die Bedrohung durch Quantencomputer klingt nach Science-Fiction. Das Problem ist: Die Standards, Bibliotheken und Plattformen entstehen bereits jetzt.

RFC 9964 standardisiert ML-DSA für JOSE- und COSE-Systeme. Das bedeutet: JWTs, OAuth-Tokens und OpenID-Connect-Flows können ab sofort auf einem standardisierten Weg auf Post-Quantum-Signaturen umgestellt werden. Keycloak — die meistgenutzte Open-Source-IAM-Plattform — beobachtet diese Entwicklung aktiv.

Caddy, den wir bei Moselwal als Reverse Proxy und TLS-Terminator einsetzen, unterstützt Post-Quantum-Hybridverfahren im TLS-Stack bereits produktiv. Kompatible Clients profitieren beim Verbindungsaufbau heute schon von hybriden Schlüsseläaustauschverfahren auf PQ-Basis.

Die eigentliche Frage ist nicht ob, sondern wann und wie schnell. Wer heute Plattformen für die nächsten fünf bis zehn Jahre baut, muss Crypto Agility als Architekturprinzip verankern — die Fähigkeit, kryptografische Verfahren kontrolliert auszutauschen, bevor es ein Incident erfordert.

Das Thema ist nicht Zukunft — die Standards entstehen jetzt

Spricht man über Post-Quantum-Kryptografie, bekommt man häufig dieselbe Reaktion: „Ja, das wird mal wichtig. Aber Quantencomputer brechen heute noch keine Verschlüsselung.“ Das stimmt. Und es greift trotzdem zu kurz.

Die Frage ist nicht, ob es morgen einen Quantencomputer gibt, der RSA in Echtzeit bricht. Die Frage ist, ab wann die Verfahren, auf denen Ihre Plattform läuft, als unzureichend gelten — und wie viel Vorlauf Sie dann haben.

Was in den letzten Jahren passiert ist, war kein akademisches Schauspiel:

• Das NIST hat ML-DSA (FIPS 204) und ML-KEM (FIPS 203) als Post-Quantum-Standards veröffentlicht.
• Die IETF hat mit RFC 9964 einen standardisierten Integrationsweg für ML-DSA in JOSE und COSE definiert.
• Projekte wie Keycloak beginnen, sich mit PQ-Signaturunterstützung für OAuth und OpenID Connect auseinanderzusetzen.
• Produktive Infrastrukturkomponenten wie Caddy unterstützen PQ-Hybridverfahren im TLS-Handshake bereits heute.

Das ist keine Forschungsagenda. Das ist die Produktions-Roadmap der nächsten fünf Jahre.

RFC 9964 — was das für digitale Identitäten konkret bedeutet

RFC 9964 klingt zunächst wie eine weitere IETF-Spezifikation in einer langen Reihe. Aber was sie adressiert, ist für moderne Plattformarchitekturen direkt relevant.

Praktisch jede API-Landschaft, jedes Identity-System und jede Service-to-Service-Kommunikation baut heute auf JOSE-basierte Verfahren auf:

• JSON Web Tokens (JWTs)
• OAuth 2.0 Access Tokens
• OpenID Connect ID-Tokens
• Maschinenidentitäten und API-Keys mit Signatur-Validierung

Diese Verfahren nutzen kryptografische Signaturen — bisher auf Basis von RSA oder ECDSA. RFC 9964 definiert, wie ML-DSA als Post-Quantum-Signaturalgorithmus in diese Welt integriert wird: mit standardisierten Algorithmusbezeichnern, Schlüsselrepräsentationen und Signaturformaten für JWS und JWK.

Was das bedeutet: Identity Provider, API-Gateways und jede Plattform, die heute JOSE-basierte Tokens ausstellt oder validiert, bekommt damit einen standardisierten Migrationsweg — ohne proprietäre Sonderlösungen.

Das ist der Moment, in dem Post-Quantum-Kryptografie aufhört, Theorie zu sein.

Caddy — Post-Quantum-TLS läuft bei uns bereits produktiv

Konkreter als RFC 9964 ist, was wir bei Moselwal bereits im produktiven Einsatz haben.

Wir setzen Caddy als Reverse Proxy und TLS-Terminator ein. Caddy unterstützt Post-Quantum-Hybridverfahren im TLS-Handshake — konkret hybride Schlüsseläaustauschverfahren, die klassische Elliptic-Curve-Diffie-Hellman-Verfahren mit ML-KEM kombinieren.

Was das in der Praxis bedeutet:

• Klassische Clients verbinden sich wie gewohnt — keine Unterbrechung, keine Kompatibilitätsprobleme.
• Kompatible Clients — aktuelle Chrome- und Firefox-Versionen, Cloudflare-Endpoints — profitieren beim Verbindungsaufbau bereits von hybridem Post-Quantum-Schlüsselaustausch.
• Für Verbindungen, die über PQ-Hybrid laufen, gilt Forward Secrecy auch gegen zukünftige Quantenangriffe.

Das ist kein Laborexperiment und kein Pilot. Das ist unser produktiver Default-Stack.

Der Vorteil für uns: Wir sammeln Betriebserfahrung mit PQ-Hybridverfahren, bevor jemand uns dazu zwingt. Wenn in drei Jahren ein Identity Provider PQ-Signaturen voraussetzt oder ein Audit PQ-Readiness abfragt, haben wir eine Antwort, die auf produktiven Betriebsdaten beruht — nicht auf einem PowerPoint.

Warum Keycloak diese Entwicklung interessant macht

Caddy löst TLS. RFC 9964 löst den Signaturstandard für JOSE. Die nächste Eskalationsstufe kommt, wenn Identity Provider die PQ-Signaturen tatsächlich ausstellen.

Keycloak ist bei vielen Mittelstand-Stacks die zentrale IAM-Plattform: Single Sign-On, OAuth 2.0, OpenID Connect, LDAP-Integration. Wenn Keycloak anfängt, ML-DSA-Signaturen in JWTs zu unterstützen, verändert sich der Trust-Graph über alle nachgelagerten Services.

Wir beobachten die laufenden Arbeiten zur Keycloak-Unterstützung von Post-Quantum-Signaturen deshalb aktiv — nicht weil wir kurzfristig eine Migration planen. Sondern weil der Moment, in dem der Identity Provider beginnt, PQ-Tokens auszustellen, der Moment ist, ab dem alle nachgelagerten Systeme PQ-Validierung können müssen.

Wer das dann das erste Mal hört, hat keine Zeit mehr für eine ruhige Architekturentscheidung. Wer es heute schon kennt, hat einen strukturellen Vorteil.

Crypto Agility — die eigentliche Architekturaufgabe

Die Frage, ob Sie bereits ML-DSA oder ML-KEM einsetzen, ist die falsche Frage. Die richtige Frage ist: Wie schnell könnten Sie es, wenn Sie es müssten?

Das ist Crypto Agility — die Fähigkeit, kryptografische Verfahren kontrolliert auszutauschen, ohne operative Unterbrechung und ohne Architektur-Notoperation.

Was Crypto Agility voraussetzt:

• Transparenz über eingesetzte Kryptografie: Welche Algorithmen laufen wo? TLS-Versionen, Zertifikatstypen, Signaturalgorithmen in Token-Validierungen, Verschlüsselung in Storage.
• Zentrale Verwaltung von Identitäten: Ein Identity Provider, der Algorithmuswechsel zentral ausrollt — nicht zwanzig verteilte Stellen mit eigenem Zertifikatsmanagement.
• Automatisiertes Zertifikatsmanagement: ACME, automatische Renewal, kein manueller Zertifikats-Lifecycle.
• Infrastructure as Code: Kryptografische Konfiguration ist Code, kein Adminhandbuch.
• DevSecOps-Prozesse: Algorithmuswechsel gehen durch dieselbe Review- und Deployment-Pipeline wie Code-Änderungen.

Organisationen, die das bereits haben, werden PQ-Migrationen wie einen geplanten Upgrade ausrollen. Alle anderen werden sie als Notoperation erleben.

Was das für Ihre Plattform konkret bedeutet

Wir raten heute nicht zu überstürzten Migrationen. Wer jetzt hektisch einen PQ-Algorithmus in seine Plattform integriert, ohne die Grundlagen zu haben, schafft mehr Angrifffläche als er beseitigt.

Was sinnvoll ist — und zwar heute:

Kryptografischen Bestand verstehen. Wo laufen Zertifikate? Welche Systeme stellen Tokens aus oder validieren sie? Welche Algorithmen nutzen Ihre TLS-Verbindungen, Ihre Identity Provider, Ihre API-Gateways? Wer das nicht beantworten kann, hat keine Grundlage für eine Migration — unabhängig vom verwendeten Verfahren.

Moderne Plattformkomponenten bevorzugen. Caddy statt älterer Reverse Proxies. Keycloak statt proprietärer Legacy-IAM-Systeme. Automatisiertes Zertifikatsmanagement statt manueller Renewal. Diese Entscheidungen sind ohnehin sinnvoll — sie schaffen aber als Nebeneffekt eine Basis für PQ-Migration, wenn sie fällig wird.

Crypto Agility als Architekturprinzip verankern. Kryptografische Konfiguration in Code, zentrale Schlüssel- und Zertifikatsverwaltung, Prozesse für den kontrollierten Algorithmuswechsel. Nicht weil Quantencomputer morgen anklopfen — sondern weil Algorithmuswechsel grundsätzlich Teil des Plattformbetriebs sind und in einer funktionierenden DevSecOps-Struktur keine Notoperation sein sollten.

Fazit

Post-Quantum Security ist kein Zukunftsthema, das man auf „irgendwann“ vertagen kann. Die Standards sind gesetzt. Die ersten Plattformkomponenten implementieren sie. Die Identitätssysteme werden folgen.

Was wir bei Moselwal daraus machen: Wo Technologien produktionsreif sind, nutzen wir sie. Caddy läuft bei uns mit Post-Quantum-Hybridverfahren. RFC 9964 und die Keycloak-Entwicklungen beobachten wir aktiv. Und die Architekturgrundsätze — Crypto Agility, zentrales Identitätsmanagement, automatisiertes Zertifikatsmanagement — sind keine Post-Quantum-Maßnahmen. Sie sind gute Plattformarchitektur, die PQ-Readiness als Nebeneffekt mitliefert.

Gute Sicherheitsarchitekturen entstehen nicht dann, wenn eine Migration zwingend erforderlich wird. Sie entstehen, indem man technologische Entwicklungen frühzeitig versteht, bewertet — und sinnvoll in moderne Plattformen integriert.