Merkle-Baum-Zertifikate: WebPKI für das Post-Quantenzeitalter neu denken

Ein Merkle Tree Certificate (MTC) ist eine neue, kompaktere Art von Zertifikat. TLS Zertifikat, derzeit ein experimenteller IETF-Vorschlag, in dem ein Zertifizierungsstelle Es bündelt viele Zertifikate in einem einzigen Merkle-Baum und signiert nur dessen Wurzel, anstatt jedes Zertifikat einzeln zu signieren. Ein Browser beweist dann mithilfe eines kurzen Inklusionsbeweises, dass sein Zertifikat zu diesem signierten Baum gehört, anstatt die vollständige Signaturkette mitzuführen. Ziel ist es, eine quantensichere Authentifizierung nach der Quantenbeschränkung zu ermöglichen, ohne die überdimensionierten Signaturen, die die PQC-Algorithmen des NIST sonst jedem TLS-Handshake hinzufügen würden.

Wenn Sie beruflich mit der Verwaltung digitaler Zertifikate zu tun haben, ist der Begriff „Post-Quanten-Übergang“ wahrscheinlich von einer fernen Abstraktion zu etwas geworden, das auf Ihrer Roadmap steht. NIST hat seine erste Post-Quanten-Kryptographie abgeschlossen (PQCDa Browser bereits quantensicheren Schlüsselaustausch gemäß den WebPKI-Standards anbieten, stellt sich nicht mehr die Frage, ob sich die WebPKI ändern wird, sondern wie tiefgreifend diese Änderung sein wird. Ehrlich gesagt ist die Kryptografie der einfache Teil. Die Schwierigkeit besteht darin, sie in ein dreißig Jahre altes Zertifikatssystem zu integrieren, ohne die gewohnte Performance zu beeinträchtigen.

Genau diese Lücke sollen Merkle-Tree-Zertifikate schließen. Vorab eine wichtige Klarstellung, da der Name oft zu Verwirrung führt: Merkle-Tree-Zertifikate (MTCs) sind keine NIST-Veröffentlichung. Sie sind ein experimenteller Vorschlag der IETF, der aktuell in der PLANTS-Arbeitsgruppe entwickelt und von Ingenieuren von Google, Cloudflare und Geomys verfasst wird. Die Verbindung zum NIST liegt in dem Problem, das sie lösen. Die NIST-standardisierten PQC-Signaturalgorithmen, wie beispielsweise … ML-DSASie sind deutlich größer als die heute verwendeten elliptischen Kurvensignaturen, und MTCs stellen eine strukturelle Lösung für dieses Größenproblem dar. Das Verständnis von MTCs bedeutet daher, zu verstehen, warum die quantensicheren Algorithmen des NIST das Web überhaupt erst in eine schwierige Lage gebracht haben.

Warum Post-Quanten-Zertifikate das Leistungsbudget des Webs belasten

Der Grund, warum die Branche überhaupt auf PQC umsteigt, ist die Bedrohung durch das Prinzip „jetzt abfangen, später entschlüsseln“. Ein Angreifer kann heute verschlüsselten Datenverkehr abfangen und speichern und darauf spekulieren, dass ein zukünftiger Quantencomputer, der Shors Algorithmus ausführt, diesen schließlich entschlüsseln wird. RSA und elliptische Kurvenkryptographie, die sie schützte. Gartner prognostizierte, dass herkömmliche asymmetrische Kryptographie wie RSA und ECC Die Sicherheit sensibler Daten könnte bereits lange vor einem vollständigen Quantendurchbruch gefährdet sein. Um dem vorzubeugen, haben Chrome und andere gängige Browser bereits einen hybriden Post-Quantum-Schlüsselaustausch (X25519MLKEM768) eingeführt, um die Vertraulichkeit des TLS-Handshakes zu gewährleisten.

Die Authentifizierung ist eine andere Geschichte. Die Signaturen, die die Echtheit eines Zertifikats beweisen, sind erst dann angreifbar, wenn ein kryptografisch relevanter Quantencomputer existiert. Daher besteht noch etwas Spielraum. Doch wenn es soweit ist, werden die Datenmengen erschreckend sein. Eine ECDSA-P-256-Signatur umfasst etwa 64 Byte. ML-DSA-44, eines der kompakteren NIST PQC-Signaturverfahren, erzeugt Signaturen von etwa 2,420 Bytes.Das ist fast vierzigmal größer. Bei ML-DSA-65 sind die Signaturen etwa 3,309 Byte groß, die öffentlichen Schlüssel etwa 1,952 Byte.

Diese Zahlen sind wichtig, da Zertifikate während des TLS-Handshakes ausgetauscht werden – dem latenzkritischen Moment, bevor auch nur ein einziges Byte einer Webseite geladen wird. Eine typische Zertifikatskette umfasst heutzutage etwa vier Kilobyte. Berücksichtigt man die Post-Quanten-Signaturen entlang der Kette sowie die von Certificate Transparency geforderten Zeitstempel der signierten Zertifikate, kann der Signaturaufwand pro Handshake von einigen Hundert Byte auf weit über dreizehntausend ansteigen.

Manche Schätzungen gehen von einem Umfang vollständiger quantensicherer Handshakes von 15 bis 30 Kilobyte aus. In mobilen oder ressourcenbeschränkten Netzwerken führt diese Datenmenge direkt zu langsameren Seitenladezeiten. Wenn quantensichere Sicherheit als langsam empfunden wird, stagniert die Akzeptanz, und der versprochene Schutz erreicht die Nutzer nicht. MTCs (Mobile Transfer Certificates) existieren, um diesen Zielkonflikt aufzulösen.

Was Merkle Tree-Zertifikate tatsächlich sind

Ein Merkle-Baum ist jedem vertraut, der bereits mit Transparenzprotokollen oder Blockchains gearbeitet hat: Daten werden in Blätter gehasht, Hash-Paare werden kombiniert und erneut gehasht, und dieser Prozess wiederholt sich, bis ein einzelner Hash, die Wurzel, den gesamten Datensatz repräsentiert. Jeder kann mit einem kurzen „Inklusionsbeweis“ (einigen wenigen verwandten Hashes) anstelle des gesamten Datensatzes beweisen, dass ein bestimmtes Blatt zum Baum gehört.

MTCs wenden dieses Prinzip auf die Zertifikatsausstellung an. Anstatt dass eine Zertifizierungsstelle jedes einzelne Zertifikat signiert, fasst sie viele Zertifikate in einem großen Merkle-Baum zusammen und signiert nur die Wurzel, den sogenannten Baumkopf, einmalig. Ein vertrauender Teilnehmer, wie beispielsweise ein Browser, erhält dann einen kompakten Nachweis, dass sein Zertifikat unter dieser signierten Wurzel enthalten ist. Dabei wird leicht übersehen, dass MTCs keine neue Kryptografie erfinden oder die NIST-Standards umgehen. ML-DSA führt weiterhin die Signierung durch; es signiert lediglich einen einzigen zusammengefassten Baumkopf anstelle von Tausenden einzelner Zertifikate. Die grundlegenden Funktionen sind standardisiert; was sich ändert, ist die Architektur, die sie bereitstellt.

So funktionieren Merkle Tree-Zertifikate

Die Idee ist im Prinzip einfach, aber eine Reihe von Faktoren müssen zusammenwirken, damit sie in der Praxis funktioniert – von der Ausstellung eines Zertifikats bis hin zur Frage, wie ein Browser diesem letztendlich vertraut.

Von Einzelzertifikatsignaturen zu einem einzigen signierten Baumkopf

In der klassischen PKI wird jedes Glied einer X.509-Kette einzeln signiert und bei jedem Handshake vollständig übertragen. Bei MTCs führt die Zertifizierungsstelle (CA) ein fortlaufendes Protokoll aller von ihr ausgestellten Zertifikate und signiert regelmäßig einen Teil dieses Protokolls, den sogenannten Tree Head, um zu bestätigen, dass die aufgeführten Zertifikate tatsächlich von ihr stammen. Da eine Signatur nun einen ganzen Stapel von Zertifikaten abdeckt, verteilen sich die hohen Kosten der Post-Quantum-Signatur auf alle Zertifikate, anstatt pro Zertifikat und Verbindung anfallen zu müssen. Die Signatur der CA kann zudem mit Gegensignaturen unabhängiger Parteien kombiniert werden, die die korrekte Funktionsweise der CA überprüfen und das Protokoll spiegeln können.

Verknüpfung von Zertifikatstransparenz und -ausstellung

Das Design verändert auch die Funktionsweise von Certificate Transparency (CT), und dies ist ein Aspekt, der besondere Beachtung verdient. Aktuell fungiert CT als separate Ebene, die über der Zertifikatsausstellung liegt: Zertifizierungsstellen (CAs) übermitteln Zertifikate an unabhängige Protokolle, die signierte Zertifikatszeitstempel (SCTs) zurückgeben. Browser überprüfen diese Zeitstempel später, wodurch dem Handshake weitere Signaturen hinzugefügt werden. MTCs integrieren die Protokollierung direkt in die Zertifikatsausstellung, sodass die Ausstellung und die Protokollierung eines Zertifikats untrennbar miteinander verbunden sind. Dies gewährleistet vergleichbare Transparenz und Nachvollziehbarkeit und eliminiert gleichzeitig die separaten SCT-Signaturen, die den Post-Quantum-Handshake unnötig aufblähen.

Die signaturlose (Landmark-)Optimierung

Der Entwurf, der die größte Aufmerksamkeit erregt, beschreibt eine optionale Optimierung für sogenannte Landmark-Zertifikate. Ein herkömmliches X.509-Zertifikat enthält einen öffentlichen Schlüssel, eine CA-Signatur und zwei CT-Signaturen. Im signaturlosen Modus von MTC bleibt der öffentliche Schlüssel erhalten, die Signaturen werden jedoch effektiv an anderer Stelle gespeichert. Dadurch benötigt eine aktuelle vertrauende Partei für den Handshake lediglich einen öffentlichen Schlüssel und einen Merkle-Inklusionsnachweis – eine Signatur während der Übertragung ist nicht mehr erforderlich.

Forschung zur Anwendung von MTCs auf private Infrastruktur Ein bahnbrechender Beweis konnte in der Größenordnung von 736 Bytes gefunden werden, wobei das Validierungsmaterial außerhalb des regulären Kommunikationsablaufs verteilt und nicht in jeden Handshake integriert wird. Der Haken dabei – und das ist ein wichtiger Punkt – ist, dass dies nur für ausreichend aktuelle vertrauende Parteien funktioniert; ältere Clients greifen auf einen traditionelleren, signaturbasierten Weg zurück. Um dieses Zeitfenster für den Rückgriff klein zu halten, verwenden MTCs kurzlebige Zertifikate und definierte Gültigkeitsdauern, was bedeutet, dass Zertifikate häufiger erneuert werden, als viele Teams es gewohnt sind.

Was dies für die WebPKI und das Zertifikatsmanagement bedeutet

Der Wandel reicht weit über die Kryptographie hinaus und verändert die Art und Weise, wie Vertrauen verteilt wird, wie Zertifikate verwaltet werden und wie die Teams, die sie verwalten, tagtäglich arbeiten müssen. 

Ein neues Vertrauensmodell und die Chrome-Roadmap

Google hat klargestellt, dass es nicht einfach Post-Quantum-Signaturen in herkömmliche X.509-Zertifikate für Chrome integrieren will. Stattdessen verfolgt das Unternehmen MTCs als zukunftsweisenden Ansatz und testet diese bereits mit Cloudflare. Der Plan sieht einen separaten, quantenresistenten Root-Speicher für Chrome mit eigenem Root-Programm vor, der schrittweise eingeführt wird. Die Integration weiterer Zertifizierungsstellen (CAs) ist für das dritte Quartal 2027 geplant. Für das CA-Ökosystem signalisiert diese Kombination aus aktiven Tests und konkreten Zeitplänen, dass das Konzept längst nicht mehr nur ein Gedankenexperiment ist.

Dieses Signal verstärkte sich im Juni 2026. Am 3. Juni 2026 gab Let's Encrypt, die gemeinnützige Zertifizierungsstelle, die mehr als 500 Millionen Websites sichert, bekannt, dass... veröffentlichte seinen Fahrplan für die Zeit nach der Quantenphysik und hat Merkle-Tree-Zertifikate als ihren bevorzugten Weg benannt. Sie plant eine Testumgebung, die Ende 2026 Merkle-Tree-Zertifikate ausgibt, und eine produktionsreife Umgebung im Jahr 2027.

Let's Encrypt betreibt seit 2019 Certificate Transparency Logs (CTLs) auf Basis von Merkle-Bäumen und verfügt daher bereits über praktische Erfahrung mit der Datenstruktur, auf der MTCs beruhen. Die Organisation betonte, dass sich für bestehende Abonnenten nichts ändert: Zertifikate werden weiterhin wie bisher über ACME ausgestellt. Die eigentliche Arbeit konzentriert sich auf die Ausstellungsinfrastruktur, das ACME-Protokoll sowie die Werkzeuge für Widerruf und Transparenz. Wenn sich eine Zertifizierungsstelle, die einen so großen Anteil der Webzertifikate ausstellt, für einen bestimmten Post-Quantum-Pfad entscheidet, muss das gesamte Ökosystem aufmerksam bleiben.

Jenseits des Browsers: Private PKI

Obwohl MTCs für die öffentliche WebPKI konzipiert wurden, bestehen dieselben Anforderungen auch in Unternehmen. Umgebungen wie Kubernetes-Steuerungsebenen und Cloud-native 5G-Kerne authentifizieren Tausende von Verbindungen pro Sekunde gegenseitig, und der Aufwand für die Post-Quanten-Signatur summiert sich in diesen Umgebungen rasant. Erste Forschungsarbeiten haben begonnen, MTC-Architekturen an private Netzwerke anzupassen. PKIDabei wird die interne Zertifizierungsstelle eines Clusters durch eine MTC-ähnliche Autorität ersetzt, inklusive Mitunterzeichnern und Landmark-Distributoren. Sollte diese Entwicklung weiterentwickelt werden, könnten die Ideen hinter MTCs weit über öffentliche TLS-Systeme hinaus Verbreitung finden und die Maschinenidentitäten prägen, auf denen moderne Infrastrukturen basieren.

Die Abwägungen und offenen Fragen

Nichts davon ist umsonst. MTCs bringen erhebliche Komplexität in ein Ökosystem, das jahrzehntelang das X.509-Modell optimiert hat, und der Vorteil der signaturlosen Zertifikatsverwaltung gilt nur für Clients, die auf dem neuesten Stand bleiben. Die separate Verteilung von Validierungsmaterial, die kürzeren Zertifikatslebensdauern, der Bedarf an Mitunterzeichnern und Monitoren sowie ein paralleler quantenresistenter Root-Speicher bringen zusätzliche Komplexität mit sich. Der Vorschlag ist noch experimentell und wird innerhalb der IETF weiterentwickelt, daher werden sich die Details noch ändern. Es geht nicht darum, sich auf einen Entwurf festzulegen, der sich noch ändern kann. Es geht darum, die Richtung der Entwicklung zu erkennen. Vertrauen wird neu gestaltet, und Zertifikate werden immer kürzer und immer zahlreicher.

Warum Automatisierung nicht länger optional ist

Diese Entwicklung hat eine unausweichliche Konsequenz für die Teams, die die Zertifikatsverwaltung durchführen. In einer Welt mit kürzeren Gültigkeitsdauern, gebündelter Ausstellung, integrierter Transparenz und möglicherweise zwei parallel existierenden Vertrauensmodellen (klassisches X.509 und MTC) wird die manuelle Zertifikatsverwaltung stillschweigend unmöglich. Es ist nicht möglich, Zertifikate, die alle paar Tage zwischen einem quantenresistenten Stammzertifikatspeicher und einem herkömmlichen Speicher rotieren, gleichzeitig manuell zu verfolgen. Organisationen, die diesen Übergang reibungslos meistern, sind diejenigen, die bereits umfassende Transparenz über jedes ihrer Zertifikate besitzen, die nötige Krypto-Agilität haben, um Algorithmen und Formate ohne Architekturumstrukturierung zu wechseln, und die eine automatisierte Erkennung, Registrierung und Verlängerung gewährleisten, unabhängig davon, ob die zugrunde liegende Signatur … ECDSA oder ML-DSA. Die Vorbereitung auf MTCs sieht in der Praxis sehr ähnlich aus wie die Optimierung Ihres Zertifikatslebenszyklusmanagements.

Wie kann Verschlüsselungsberatung helfen?

Merkle-Tree-Zertifikate befinden sich noch im experimentellen Stadium, und der Entwurf wird sich bis zur Markteinführung weiter verändern. Daher ist es jetzt ratsam, nicht den Spezifikationen hinterherzujagen, sondern Ihre Zertifikatslandschaft so zu gestalten, dass eine solche Umstellung lediglich eine Konfigurationsänderung und keine Notfallmaßnahme darstellt. Die Grundlagenarbeit, die sich mit der Einführung von Merkle-Tree-Zertifikaten (oder deren zukünftiger Architektur) auszahlt, ist dieselbe, die sich auch heute schon bewährt: die Kenntnis jedes einzelnen Zertifikats, die Möglichkeit, die Kryptografie ohne Architekturänderung anzupassen, und die Automatisierung des Lebenszyklus, um Fehler zu vermeiden.

Der CertSecure Manager von Encryption Consulting ist eine herstellerneutrale Lösung für das Zertifikatslebenszyklusmanagement, die Erkennung, Automatisierung, Registrierung, Richtliniendurchsetzung und Integrationen zentralisiert. Sie verhindert Ausfälle durch automatisierte Verlängerungen, verbessert die Compliance, optimiert den IT-Betrieb und vereinheitlicht die Verwaltung öffentlicher und privater Zertifizierungsstellen über eine einzige, automatisierte und skalierbare Plattform.

Genau diese Funktionen bereiten Sie auf das MTC-Zeitalter vor. Die vollständige Erfassung liefert Ihnen den kompletten Überblick, den Sie benötigen, wenn sich die Vertrauensmodelle ändern. So wissen Sie immer genau, welche Systeme wo laufen. Die automatisierte Registrierung und Verlängerung kümmert sich um die kurzlebigen Zertifikate und die schnellere Rotation, auf die MTCs angewiesen sind und die manuell schnell unüberschaubar werden.

Die Krypto-Agilität der Plattform ermöglicht den Wechsel zwischen Algorithmen – von den heutigen ECDSA- und RSA-Verfahren hin zu Post-Quanten-Optionen wie ML-DSA – ohne dass Sie Ihre Arbeitsabläufe neu aufbauen müssen. Und weil CertSecure Manager Die Lösung verwaltet bereits öffentliche und private Zertifizierungsstellen parallel und ist für eine Übergangsphase konzipiert, in der klassisches X.509 und neue Zertifikatsformate nebeneinander existieren müssen. In Kombination mit einer robusten rollenbasierten Zugriffskontrolle und transparenter Darstellung Ihrer Zertifikatsvorgänge ermöglicht sie Ihnen, die nächsten Schritte in Ihrem eigenen Tempo zu implementieren, anstatt hektisch reagieren zu müssen.

Fazit

Merkle-Baum-Zertifikate (MTCs) sind kein wirklicher Ersatz für die Post-Quanten-Algorithmen des NIST. Sie bilden vielmehr die Grundlage, die diese Algorithmen im offenen Web praktikabel macht. Das NIST lieferte quantensichere Signaturen, deren Größe jedoch den TLS-Handshake zu überlasten drohte. MTCs stellen die strukturelle Lösung der IETF dar: Sie ersetzen die Signaturen pro Zertifikat durch einen einzigen signierten Baumkopf, fügen kompakte Inklusionsnachweise hinzu und integrieren die Zertifikatstransparenz direkt in den Ausstellungsprozess. Das Ergebnis ist ein glaubwürdiger Weg zu quantenresistenter Authentifizierung ohne die Leistungseinbußen, die die Akzeptanz sonst behindern würden. 

Der Vorschlag befindet sich noch im experimentellen Stadium, die Zeitpläne sind noch im Fluss und die Kompromisse werden innerhalb der IETF noch ausgehandelt. Doch die großen Browser, Zertifizierungsstellen und CLM-Anbieter werten ihn allesamt als wichtiges Signal für die zukünftige Entwicklung der WebPKI: hin zu mehr Vertrauensankern, kurzlebigeren Zertifikaten, integrierter Transparenz und einer Phase, in der klassische und Post-Quanten-Modelle parallel existieren. Unabhängig davon, ob MTCs in ihrer jetzigen Form umgesetzt werden, bleibt die praktische Lehre dieselbe. Die Teams, die dies erfolgreich umsetzen, sind diejenigen, die bereits wissen, welche Zertifikate sie besitzen, die Kryptografie bei Bedarf austauschen können und den gesamten Lebenszyklus automatisiert haben. Wenn diese Grundlagen stimmen, lässt sich selbst eine Neugestaltung des Vertrauenskonzepts gelassen bewältigen, anstatt in Panik zu geraten.