Google hat der Zertifikatsbranche gerade mitgeteilt, dass sein Plan für Post-Quanten-HTTPS nicht dem entspricht, was irgendjemand erwartet hat.
Am 27. Februar verkündete Chromes Secure Web and Networking Team, dass Chrome keinen unmittelbaren Plan hat, traditionelle X.509-Zertifikate mit Post-Quanten-Kryptographie in den Chrome Root Store aufzunehmen. Stattdessen baut Chrome eine parallele Vertrauensinfrastruktur auf, die auf Merkle Tree Certificates (MTCs) basiert — einer grundlegend anderen Zertifikatsarchitektur, die durch die neue PLANTS-Arbeitsgruppe der IETF entwickelt wird. Cloudflare führt bereits experimentelle MTC-Deployments in Zusammenarbeit mit Chrome durch.
Das geht weit über Browser-Engineering hinaus. Wenn Sie als Organisation Ihre PQC-Migration planen, hat sich das Ziel gerade verschoben.
Die Annahme, die gerade zerbrochen ist
Die Arbeitsannahme in weiten Teilen der Branche war geradlinig: PQC-Zertifikatsmigration bedeutet, klassische Signaturen (ECDSA, RSA) durch Post-Quanten-Signaturen (ML-DSA) innerhalb des bestehenden X.509-Zertifikatsformats zu ersetzen. Größere Schlüssel, größere Signaturen, gleiche Architektur. Die Migration wäre schmerzhaft — ML-DSA-Signaturen und öffentliche Schlüssel sind um Größenordnungen größer als ihre klassischen Äquivalente — aber konzeptionell einfach.
Google hat diesen Weg für das öffentliche Web gerade abgelehnt.
Der Grund ist Performance. Die heutige X.509-Zertifikatskette trägt etwa 64 Bytes an Signaturmaterial. Ein Post-Quanten-Äquivalent mit ML-DSA bläht sich auf mehrere Kilobytes auf. Jeder TLS-Handshake — jeder Seitenladevorgang, jeder API-Aufruf, jeder Ressourcenabruf — würde diesen Overhead tragen. Wie Cloudflares Bas Westerbaan es ausdrückte: Je größer man das Zertifikat macht, desto langsamer wird der Handshake und desto mehr Menschen bleiben zurück.
MTCs lösen dies, indem sie die Funktionsweise des Zertifikatsvertrauens umstrukturieren. Anstatt dass jedes Zertifikat seine eigene Signaturkette trägt, signiert eine Zertifizierungsstelle einen einzelnen Tree Head, der potenziell Millionen von Zertifikaten repräsentiert. Der Browser erhält einen kompakten Beweis, dass ein bestimmtes Zertifikat in diesem Baum enthalten ist. Die Post-Quanten-Kryptographie existiert weiterhin — sie schützt den Tree Head und die Transparenzinfrastruktur — aber sie ist von den Daten entkoppelt, die Benutzer bei jedem Handshake tatsächlich erleben.
Was Kim Nguyen richtig erkennt
Kim Nguyen, SVP Innovations bei Bundesdruckerei, wies innerhalb von Stunden auf LinkedIn darauf hin, und seine Einordnung ist präzise: PQC-Migration in der Web-PKI ist keine Algorithmusfrage mehr. Es ist eine Architekturfrage.
Nguyen leitet die Innovationsabteilung der Bundesdruckerei, der Muttergesellschaft von Deutschlands primärem qualifizierten Vertrauensdiensteanbieter D-Trust. Seine Organisation stellt die Zertifikate aus, betreibt die Infrastruktur und implementiert die eIDAS-konformen Vertrauensdienste, von denen die europäische digitale Identität abhängt. Wenn er sagt, dass dies die operative Rolle von Vertrauensdiensteanbietern verändert, beschreibt er Veränderungen an seinem eigenen Geschäft.
Seine zentrale Beobachtung — dass sich die Diskussion von „wie ersetzen wir Algorithmen“ zu „wie gestalten wir Vertrauensinfrastruktur so um, dass Post-Quanten-Sicherheit im globalen Maßstab tragfähig ist“ verschoben hat — ist korrekt und hat Konsequenzen, die weit über die TSP-Gemeinschaft hinausgehen.
Das Migrationsumfang-Problem
Hier ist, was das für Organisationen außerhalb des Browser- und CA-Ökosystems bedeutet.
Die meisten PQC-Migrations-Roadmaps — sofern sie überhaupt existieren — gehen von einem relativ begrenzten Umfang aus: kryptographische Abhängigkeiten inventarisieren, quantenverwundbare Algorithmen identifizieren, durch NIST-standardisierte Post-Quanten-Äquivalente ersetzen, Interoperabilität validieren, deployen. Das ist nach vernünftigen Schätzungen bereits ein 12-Jahres-Vorhaben, und die meisten Organisationen haben noch nicht begonnen.
Die Chrome-MTC-Ankündigung ändert nichts an der Algorithmus-Migrationsarbeit. Sie brauchen weiterhin ML-KEM für den Schlüsselaustausch. Sie brauchen weiterhin ML-DSA für Signaturen. Sie müssen weiterhin jede Stelle finden, an der Ihre Systeme klassische Kryptographie aushandeln, und den Übergang planen.
Was sich ändert, ist die Infrastruktur, in die sich diese Algorithmen einfügen. Wenn Ihre Organisation Webdienste betreibt, TLS-Zertifikate ausstellt oder nutzt, oder auf zertifikatsbasierte Authentifizierung angewiesen ist, hat Ihr Migrationsplan jetzt eine zusätzliche Variable: Das Zertifikatsformat und das Vertrauensmodell selbst könnten sich unter Ihnen verändern. Nicht irgendwann. Chrome peilt Phase 2 an — CT-Log-Betreiber zum Bootstrapping öffentlicher MTCs einzuladen — für Q1 2027. Phase 3, die Aufnahme weiterer CAs in einen neuen Chrome Quantum-resistant Root Store, zielt auf Q3 2027.
Das sind 18 Monate ab jetzt.
Was das für die Migrationsverfolgung bedeutet
Wir argumentieren seit dem Start von pqprobe, dass PQC-Migration eine Trajektorienverfolgung über die Zeit erfordert, keine Momentaufnahme-Bewertung. Die entscheidende Frage ist nicht „sind Sie heute quantensicher“ — niemand ist es. Die Frage ist: Werden Sie besser oder schlechter?
Die MTC-Entwicklung schärft dieses Argument. Wenn sich das Migrationsziel selbst weiterentwickelt — wenn das, was „PQC-ready“ für Ihre Zertifikatsinfrastruktur bedeutet, aktiv von dem Browser neu definiert wird, der zwei Drittel des weltweiten Webverkehrs abwickelt — ist eine statische Bewertung noch weniger nützlich. Sie müssen Ihre Position gegen einen sich bewegenden Referenzpunkt verfolgen.
Überlegen Sie, wie das PQC-Migrations-Dashboard einer Organisation jetzt aussehen sollte. Schlüsselaustausch-Bereitschaft: messbar, relativ stabiles Ziel (ML-KEM, klar definiert durch NIST). Signaturalgorithmus-Bereitschaft: messbar, stabiles Ziel (ML-DSA). Zertifikatsinfrastruktur-Bereitschaft: Ziel verschiebt sich aktiv. Die ersten beiden kann man scannen und den Fortschritt verfolgen. Das dritte erfordert, nicht nur die eigenen Systeme zu beobachten, sondern auch die Ökosystem-Entscheidungen von Google, Cloudflare und der IETF-PLANTS-Arbeitsgruppe — und zu verstehen, wie diese Entscheidungen Ihren Zeitplan beeinflussen.
Die weitergehende Architekturfrage
Chromes MTC-Plan hat auch Auswirkungen über Web-Zertifikate hinaus.
Wir schrieben letzten Monat darüber, wie Deutschlands Bundesdruckerei die Chip-Ebene für Identitätsdokumente PQC-härtet, während die darüberliegende Middleware- und Verifikationsinfrastruktur quantenverwundbar bleibt. Die EUDI-Wallet wird Ende 2026 mit der Kryptographie ausgeliefert, die jetzt eingebaut ist. Das Identitäts-Ökosystem — Credential-Signierung, Schlüsselvereinbarung, DID-Auflösung, Vertrauensregister — sitzt auf klassischer Kryptographie, die laut BSI-Präsident Plattner bis 2030 brechbar sein wird.
Wenn die Web-PKI von X.509 zu Merkle Tree Certificates wechselt, wird die Frage für jedes andere PKI-abhängige System: Braucht Ihre Vertrauensarchitektur das gleiche Umdenken? Enterprise-PKI, Code-Signierung, E-Mail-Zertifikate, IoT-Geräteidentität — all diese nutzen heute X.509. Chromes Antwort auf das PQ-Zertifikatsgrößen-Problem ist architektonische Innovation. Andere Ökosysteme werden vor dem gleichen Größenproblem stehen und möglicherweise nicht über die gleichen Engineering-Ressourcen verfügen, um es zu lösen.
Was als Nächstes kommt
Googles phasenweiser Rollout — Machbarkeitsstudie jetzt, CT-Log-Betreiber-Bootstrapping in Q1 2027, neuer Root Store in Q3 2027 — ist aggressiv nach Standards-Gremien-Zeitplänen und konservativ nach Bedrohungszeitplänen. Die IETF-PLANTS-Arbeitsgruppe entwickelt die MTC-Spezifikation aktiv weiter. Cloudflare registriert etwa 1.000 TLS-Zertifikate im experimentellen Deployment. Chrome hat bereits vorläufige MTC-Unterstützung integriert.
Das ist nicht mehr theoretisch. Die Frage für CISOs und Infrastrukturteams ist, ob ihre Migrationspläne das berücksichtigen.
Lassen Sie uns klarstellen, was hier passiert ist. Google hat Tausende von Ingenieuren und ein werbebasiertes Geschäftsmodell, das Projekte finanziert, die die meisten Organisationen nie rechtfertigen könnten. Sie haben keine tiefe technische Erkenntnis gewonnen, die der Rest der Branche übersehen hat. Sie hatten den Luxus zu entscheiden, dass der bestehende Weg zu langsam ist, und die Ressourcen, einen anderen zu bauen. Das ist kein Geniestreich. Das ist Personalstärke.
Aber das Ergebnis ist dasselbe, ob man es bewundert oder ärgert: Das Migrationsziel hat sich verschoben, und es hat niemanden um Erlaubnis gefragt. Wenn Ihre PQC-Roadmap davon ausging, dass Sie ML-DSA in X.509 eintauschen und fertig sind, hat diese Roadmap jetzt eine Lücke. Nicht weil Sie bei der Kryptographie falsch lagen, sondern weil jemand mit mehr Ressourcen die Infrastruktur darunter verändert hat.
Deshalb zählt Agilität mehr als Architektur. Kim Nguyen hat Recht, dass sich die Diskussion von Algorithmen zu Architektur verschoben hat. Aber für jeden, der reale Dienste mit realen Kunden betreibt, lautet die Lektion nicht „gestalten Sie Ihre Vertrauensinfrastruktur um.“ Das können Sie nicht. Sie haben keinen Browser mit zwei Dritteln Marktanteil. Die Lektion ist: Bauen Sie Migrationspläne, die es überleben, wenn sich das Ziel verschiebt. Denn genau das ist passiert, und es wird wieder passieren.
Die Organisationen, die PQC-Migration als einmaliges Projekt mit festem Ziel behandeln, sind diejenigen, die es treffen wird. Diejenigen, die die Fähigkeit aufbauen, Veränderungen zu erkennen, neu zu bewerten und umzuschwenken — die werden noch stehen, wenn sich der Staub gelegt hat. Die Bedrohung sind nicht Quantencomputer. Die Bedrohung ist kryptographischer Konservatismus und Starrheit.