Merkle Tree-certificaten: WebPKI opnieuw bekeken voor het post-kwantumtijdperk

Kort antwoord: Een Merkle Tree Certificate (MTC) is een experimenteel voorstel van de IETF voor een compacter TLS-certificaat. Hierbij bundelt een certificeringsinstantie meerdere certificaten in één Merkle-boom en ondertekent alleen de root van de boom, in plaats van elk certificaat afzonderlijk te ondertekenen. Browsers bewijzen de aanwezigheid van het certificaat met een kort cryptografisch bewijs. Dit is belangrijk omdat de post-kwantum handtekeningalgoritmen van NIST, zoals ML-DSA, tot veertig keer groter zijn dan de huidige ECDSA-handtekeningen. Het toevoegen ervan aan elke TLS-handshake zou vijftien tot dertig kilobyte aan overhead kunnen toevoegen, genoeg om de implementatie van kwantumveilige authenticatie te vertragen. Het is niet aan te raden om de conceptspecificatie zelf te volgen, aangezien deze nog in ontwikkeling is binnen de IETF. In plaats daarvan moet u zich richten op het ontwikkelen van certificaatdetectie, cryptografische flexibiliteit en automatisering, zodat uw organisatie MTC's (of welk formaat er ook na komt) kan implementeren als een configuratiewijziging in plaats van een geforceerde implementatie.

Key Takeaways

• MTC's zijn een voorstel van de IETF PLANTS-werkgroep, geen publicatie van NIST; ze gebruiken standaard NIST-algoritmen zoals ML-DSA, maar veranderen de manier waarop handtekeningen worden gebundeld en verzonden, niet de onderliggende cryptografie zelf.
• ML-DSA-44-handtekeningen zijn ongeveer 2,420 bytes groot, vergeleken met circa 64 bytes voor ECDSA P-256, en een volledige kwantumveilige handshake zou vijftien tot dertig kilobytes kunnen beslaan zonder een structurele oplossing zoals MTC's.
• MTC's integreren certificaattransparantie direct in de uitgifte en bieden een optionele "ondertekeningsloze" modus waarbij moderne klanten alleen een publieke sleutel en een Merkle-inclusiebewijs nodig hebben, zonder enige vorm van ondertekening tijdens de overdracht.
• Let's Encrypt, dat meer dan 500 miljoen websites beveiligt, heeft MTC op 3 juni 2026 aangewezen als de gekozen route na de kwantumcrisis, met als doel een testomgeving eind 2026 en productiegereedheid in 2027.
• Google bouwt een aparte, kwantumresistente rootstore voor MTC's in Chrome, met een framework voor het onboarden van certificeringsinstanties dat naar verwachting rond het derde kwartaal van 2027 beschikbaar zal zijn, in plaats van post-kwantumhandtekeningen achteraf in traditionele X.509-certificaten in te bouwen.

Het probleem van de omvang van certificaten na de kwantumfase

Een Merkle Tree Certificate (MTC) is een nieuw, compacter type TLS- certificaat, momenteel een experimenteel voorstel van de IETF, waarbij een certificeringsinstantie veel certificaten bundelt in één Merkle-boom en alleen de wortel van de boom ondertekent, in plaats van elk certificaat afzonderlijk te ondertekenen. Een browser bewijst vervolgens dat zijn certificaat bij die ondertekende boom hoort met behulp van een kort bewijs van inclusie in plaats van een volledige keten van handtekeningen mee te dragen. Het doel is om post-kwantum, kwantumveilige authenticatie te bieden zonder de overdreven grote handtekeningen die de PQC-algoritmen van NIST anders aan elke TLS-handshake zouden toevoegen.

Als je je beroepsmatig bezighoudt met digitale certificaten, is de term 'post-kwantumtransitie' waarschijnlijk niet langer een abstractie op de lange termijn, maar een concrete stap op je planning. NIST heeft de eerste standaarden voor post-kwantumcryptografie ( PQC ) afgerond, browsers bieden al kwantumveilige sleuteluitwisseling aan en de vraag is niet langer óf WebPKI zal veranderen, maar hoe ingrijpend die verandering zal zijn. Het eerlijke antwoord is dat de cryptografie het makkelijke deel is. Het lastige is om het te integreren in een dertig jaar oud certificaatsysteem zonder de prestaties te verstoren waar iedereen stilletjes op vertrouwt.

Dat is de kloof die Merkle Tree Certificates moesten dichten. Laten we eerst iets verduidelijken, want de naam zorgt voor verwarring: Merkle Tree Certificates (MTC's) zijn geen publicatie van NIST. Het is een experimenteel voorstel van de IETF, dat momenteel wordt ontwikkeld in de PLANTS-werkgroep en is opgesteld door ingenieurs van Google, Cloudflare en Geomys. Wat ze verbindt met NIST is het probleem dat ze oplossen. De door NIST gestandaardiseerde PQC-signatuuralgoritmen, zoals ML-DSA , zijn aanzienlijk groter dan de elliptische-curve-signaturen die we tegenwoordig gebruiken, en MTC's bieden een structurele oplossing voor dat omvangsprobleem. Het begrijpen van MTC's betekent dus ook begrijpen waarom de kwantumveilige algoritmen van NIST het web in de eerste plaats in een lastig parket hebben gebracht.

Waarom post-kwantumcertificaten het prestatiebudget van het web onder druk zetten

De reden dat de industrie überhaupt overstapt op PQC is de dreiging van "nu gegevens verzamelen, later decoderen". Een tegenstander kan vandaag de dag versleuteld verkeer onderscheppen en opslaan, in de hoop dat een toekomstige kwantumcomputer die het algoritme van Shor gebruikt, uiteindelijk de RSA- en elliptische-curve-cryptografie die het beschermde, zal ontrafelen. Gartner heeft voorspeld dat conventionele asymmetrische cryptografie zoals RSA en ECC onveilig zou kunnen zijn voor de bescherming van gevoelige gegevens, ruim voordat een volledige kwantumdoorbraak zich daadwerkelijk voordoet. Om hierop voorbereid te zijn, hebben Chrome en andere belangrijke browsers al een hybride post-kwantum sleuteluitwisseling (X25519MLKEM768) geïntroduceerd om de vertrouwelijkheid van de TLS-handshake te waarborgen.

Authenticatie is een ander verhaal. De handtekeningen die de legitimiteit van een certificaat bewijzen, zijn pas kwetsbaar als er daadwerkelijk een cryptografisch relevante kwantumcomputer bestaat, dus er is nog wat speelruimte. Maar wanneer die dag aanbreekt, zijn de cijfers ontmoedigend. Een ECDSA P-256-handtekening is ongeveer 64 bytes groot. ML-DSA-44, een van de compactere NIST PQC-handtekeningschema's, produceert handtekeningen van ongeveer 2,420 bytes , bijna veertig keer zo groot. Bij ML-DSA-65 krijg je handtekeningen van ongeveer 3,309 bytes, naast publieke sleutels van ongeveer 1,952 bytes.

Die cijfers zijn belangrijk omdat certificaten worden uitgewisseld tijdens de TLS-handshake, het latencygevoelige moment voordat er ook maar één byte van een webpagina wordt geladen. Een typische certificaatketen is tegenwoordig ongeveer vier kilobyte groot. Voeg daar post-quantum handtekeningen aan toe, plus de Signed Certificate Timestamps die Certificate Transparency vereist, en de overhead per handtekening kan oplopen van een paar honderd bytes tot ruim dertienduizend.

Sommige schattingen geven aan dat volledige kwantumveilige handshakes vijftien tot dertig kilobytes groot zijn. Op mobiele of beperkte netwerken vertaalt die omvang zich direct in tragere laadtijden van webpagina's, en als kwantumveilige beveiliging traag aanvoelt, stagneert de acceptatie en bereikt de beloofde bescherming de gebruikers nooit. MTC's bestaan ​​om die afweging te doorbreken.

Wat Merkle Tree-certificaten nu eigenlijk inhouden

Een Merkle-boom is een bekende structuur voor iedereen die met transparantielogboeken of blockchains heeft gewerkt: data wordt gehasht naar bladeren, paren van hashes worden gecombineerd en opnieuw gehasht, en dit proces herhaalt zich totdat één enkele hash, de wortel, de volledige dataset vertegenwoordigt. Iedereen kan bewijzen dat een specifiek blad tot de boom behoort met behulp van een kort "inclusiebewijs" (een handvol hashes van verwante bladeren) in plaats van de volledige dataset.

MTC's passen dat idee toe op de uitgifte van certificaten. In plaats van dat een certificeringsinstantie (CA) elk individueel certificaat ondertekent, verzamelt de CA veel certificaten in een grote Merkle-boom en ondertekent slechts de root, de zogenaamde Tree Head, eenmaal. Een vertrouwende partij, zoals een browser, ontvangt vervolgens een compact bewijs dat zijn certificaat is opgenomen in die ondertekende root. Wat hier gemakkelijk over het hoofd wordt gezien, is dat MTC's geen nieuwe cryptografie uitvinden of de NIST-standaarden omzeilen. ML-DSA voert nog steeds de ondertekening uit; het ondertekent alleen één gebundelde Tree Head in plaats van duizenden individuele certificaten. De primitieven zijn standaard; wat verandert, is de architectuur die ze levert.

Hoe werken Merkle Tree-certificaten?

Het idee is in grote lijnen eenvoudig, maar een aantal onderdelen moeten goed samenwerken om het in de praktijk te laten werken, van de manier waarop een certificaat wordt uitgegeven tot de manier waarop een browser het uiteindelijk vertrouwt.

Van handtekeningen per certificaat naar één ondertekende stamboom.

Bij klassieke PKI wordt elke schakel in een X.509-keten individueel ondertekend en volledig verzonden bij elke handshake. Met MTC's houdt de CA een doorlopend logboek bij van alles wat het uitgeeft en ondertekent periodiek een weergave van dat logboek, de Tree Head, om te bevestigen dat de vermelde certificaten daadwerkelijk van de CA zelf zijn. Omdat één handtekening nu een hele reeks certificaten dekt, worden de dure kosten van de post-quantum handtekening over alle certificaten verdeeld in plaats van per certificaat, per verbinding te worden betaald. De handtekening van de CA kan ook worden gecombineerd met medeondertekeningen van onafhankelijke partijen die verifiëren dat de CA correct functioneert en die het logboek kunnen spiegelen.

Het samenvoegen van certificaattransparantie met uitgifte

Het ontwerp verandert ook de werking van Certificate Transparency (CT), en dit is een van de aspecten die de aandacht verdienen. Momenteel werkt CT als een aparte laag bovenop de uitgifte: certificeringsinstanties (CA's) dienen certificaten in bij onafhankelijke logs, die Signed Certificate Timestamps (SCT) retourneren die browsers later verifiëren, waardoor er nog meer handtekeningen aan de handshake worden toegevoegd. MTC's integreren de logging direct in de uitgifte, waardoor het uitgeven van een certificaat en het vastleggen ervan onlosmakelijk met elkaar verbonden raken. Dit biedt vergelijkbare transparantie- en verantwoordingsgaranties, terwijl de afzonderlijke SCT-handtekeningen die de post-quantum handshake onnodig complex maken, worden verwijderd.

De handtekeningloze (landmark) optimalisatie

Het onderdeel dat de meeste aandacht krijgt, is een optionele optimalisatie die in het conceptdocument wordt beschreven voor wat het 'landmark certificates' noemt. Een traditioneel X.509-certificaat bevat een publieke sleutel, één CA-handtekening en twee CT-handtekeningen. In de signatureless-modus van MTC blijft de publieke sleutel behouden, maar de handtekeningen worden in feite elders opgeslagen, zodat voor een actuele relying party de handshake alleen nog een publieke sleutel en een Merkle inclusion proof nodig heeft, zonder dat er een handtekening op het netwerk hoeft te worden gezet.

Onderzoek naar de toepassing van MTC's op private infrastructuur heeft aangetoond dat een belangrijk bewijs ongeveer 736 bytes groot kan zijn, waarbij het validatiemateriaal buiten de band wordt verspreid in plaats van in elke handshake te worden opgenomen. De crux, en dat is een belangrijke, is dat dit alleen werkt voor vertrouwende partijen die voldoende recente certificaten hebben; oudere clients vallen terug op een meer traditionele methode met een digitale handtekening. Om die terugvalperiode kort te houden, maken MTC's gebruik van certificaten met een kortere geldigheidsduur en gedefinieerde geldigheidsperioden, wat betekent dat certificaten vaker worden vervangen dan veel teams gewend zijn.

Wat dit betekent voor WebPKI en certificaatbeheer

De verschuiving reikt veel verder dan cryptografie en verandert de manier waarop vertrouwen wordt verdeeld, hoe certificaten worden beheerd en hoe de teams die ze beheren dagelijks moeten werken. 

Een nieuw vertrouwensmodel en de Chrome-routekaart

Google heeft duidelijk gemaakt dat het niet van plan is om post-quantum handtekeningen simpelweg in traditionele X.509-certificaten voor Chrome te stoppen. In plaats daarvan kiest het voor MTC's (Multi-Table Certificates) en test het deze al live met Cloudflare. Het plan omvat een aparte, quantumbestendige root store voor Chrome met een eigen rootprogramma, die gefaseerd wordt uitgerold. Het raamwerk voor het toevoegen van extra certificeringsinstanties (CA's) zal naar verwachting rond het derde kwartaal van 2027 gereed zijn. Voor het CA-ecosysteem geeft deze combinatie van actieve tests en concrete tijdlijnen aan dat dit de fase van een theoretisch experiment allang voorbij is.

Dat signaal werd sterker in juni 2026. Op 3 juni 2026 publiceerde Let's Encrypt, de non-profit certificeringsinstantie die meer dan 500 miljoen websites beveiligt, haar routekaart voor na de kwantumcrisis en noemde Merkle Tree Certificates als de gekozen aanpak. Het bedrijf streeft naar een testomgeving voor het uitgeven van MTC's eind 2026 en een productieklare omgeving in 2027.

Let's Encrypt beheert al sinds 2019 Certificate Transparency-logs die gebaseerd zijn op Merkle-bomen, en heeft dus al praktische ervaring met de datastructuur waarop MTC's gebaseerd zijn. De organisatie benadrukte dat er voor bestaande abonnees vandaag niets verandert; certificaten worden nog steeds via ACME uitgegeven, precies zoals voorheen. De diepere ontwikkelingen vinden plaats in de uitgifte-infrastructuur, het ACME-protocol en de tools voor intrekking en transparantie. Wanneer een certificeringsinstantie die zo'n groot deel van de webcertificaten uitgeeft zich vastlegt op een specifiek pad na de kwantumfase, moet de rest van het ecosysteem daar aandacht aan besteden.

Voorbij de browser: privé-PKI

Hoewel MTC's zijn bedacht voor de openbare WebPKI, bestaan ​​dezelfde uitdagingen ook binnen bedrijven. Omgevingen zoals Kubernetes-controlplanes en cloud-native 5G-cores authenticeren duizenden verbindingen per seconde, en de overhead van post-quantum signatures neemt in die omgevingen snel toe. Er is al vroeg onderzoek gedaan naar de aanpassing van MTC-architecturen aan private PKI , waarbij de interne CA van een cluster wordt vervangen door een MTC-achtige autoriteit, compleet met cosigners en landmark-distributeurs. Als dat onderzoek zich verder ontwikkelt, zouden de ideeën achter MTC's zich ver buiten de openbare TLS kunnen verspreiden en ook van toepassing kunnen zijn op de machine-identiteiten waar moderne infrastructuren van afhankelijk zijn.

De afwegingen en open vragen

Dit alles komt niet zonder kosten. MTC's introduceren aanzienlijke complexiteit in een ecosysteem dat decennialang het X.509-model heeft versterkt, en het voordeel van het ontbreken van een handtekening geldt alleen voor clients die up-to-date blijven. De out-of-band distributie van validatiemateriaal, de overstap naar kortere certificaatlevensduren, de noodzaak van medeondertekenaars en monitors, en een parallelle, kwantumresistente root-opslag voegen allemaal nieuwe factoren toe. Het voorstel is nog experimenteel en wordt binnen de IETF verder ontwikkeld, dus de details zullen blijven veranderen. Het gaat er niet om uw plannen te baseren op een concept dat nog kan worden gewijzigd. Het gaat erom de richting te volgen. Vertrouwen wordt opnieuw vormgegeven en certificaten worden korter en talrijker.

Waarom automatisering geen optie meer is

Die ontwikkeling heeft één onvermijdelijke consequentie voor de teams die daadwerkelijk certificaatbeheer uitvoeren. Een wereld met kortere geldigheidsperioden, batchgewijze uitgifte, geïntegreerde transparantie en mogelijk twee naast elkaar bestaande vertrouwensmodellen (klassiek X.509 en MTC) is een wereld waarin handmatig certificaatbeheer stilletjes onmogelijk wordt. Je kunt niet tegelijkertijd handmatig certificaten bijhouden die om de paar dagen rouleren in een kwantumresistente rootstore en een legacy-store. De organisaties die deze overgang soepel doorstaan, zijn de organisaties die al diepgaand inzicht hebben in elk certificaat dat ze beheren, de cryptografische flexibiliteit om algoritmen en formaten te wisselen zonder de architectuur te hoeven aanpassen, en geautomatiseerde detectie, registratie en verlenging die er niet toe doet of de onderliggende handtekening ECDSA of ML-DSA is. Voorbereiding op MTC's komt er in de praktijk op neer dat je nu al je certificaatlevenscyclusbeheer op orde brengt.

Hoe kan Encryption Consulting u helpen?

Merkle Tree Certificates zijn nog experimenteel en het concept zal blijven veranderen voordat er iets in productie gaat. Juist daarom is het nu verstandig om niet de specificatie na te jagen, maar om uw certificaatportfolio zo in te richten dat een dergelijke verandering een configuratiewijziging is in plaats van een noodsituatie. De basis die zijn vruchten afwerpt wanneer MTC's (of hoe ze ook zullen worden) er komen, is dezelfde basis die vandaag de dag al vruchten afwerpt: elk certificaat dat u bezit kennen, de cryptografie kunnen wijzigen zonder de architectuur opnieuw te hoeven ontwerpen en de levenscyclus automatiseren zodat er niets over het hoofd wordt gezien.

CertSecure Manager van Encryption Consulting is een leveranciersneutrale oplossing voor certificaatlevenscyclusbeheer die de ontdekking, automatisering, inschrijving, beleidshandhaving en integraties centraliseert. Het voorkomt storingen door geautomatiseerde verlengingen, verbetert de naleving van regelgeving, stroomlijnt IT-activiteiten en verenigt het beheer van openbare en private certificeringsinstanties via één geautomatiseerd en schaalbaar platform.

Diezelfde mogelijkheden bereiden u voor op het MTC-tijdperk. Dankzij complete inventarisatie beschikt u over het volledige overzicht dat u nodig hebt wanneer vertrouwensmodellen veranderen, zodat u nooit hoeft te gissen wat waar draait. Geautomatiseerde inschrijving en verlenging zorgen voor een soepele afhandeling van de kortere looptijden van certificaten en de snellere rotatie waarop MTC's vertrouwen, wat handmatig al snel onbeheerbaar wordt.

De cryptografische flexibiliteit van het platform stelt u in staat om te schakelen tussen algoritmen, van de huidige ECDSA en RSA naar post-quantum opties zoals ML-DSA, zonder uw workflows opnieuw te hoeven opbouwen. En omdat CertSecure Manager al publieke en private CA's naast elkaar beheert, is het platform ontworpen voor een overgangsperiode waarin klassieke X.509 en nieuwe certificaatformaten naast elkaar moeten bestaan. In combinatie met robuuste, op rollen gebaseerde toegangscontrole en helder inzicht in uw certificaatactiviteiten, kunt u zich in uw eigen tempo aanpassen aan de nieuwste ontwikkelingen, in plaats van halsoverkop te moeten reageren.

Conclusie

Merkle Tree Certificates (MTC's) zijn niet echt een vervanging voor de post-kwantumalgoritmen van NIST. Ze vormen de infrastructuur die deze algoritmen praktisch toepasbaar maakt op het open web. NIST leverde kwantumveilige handtekeningen, maar hun omvang dreigde de TLS-handshake te verstikken. MTC's zijn de structurele oplossing van de IETF: ze vervangen handtekeningen per certificaat door één ondertekende Tree Head, voegen compacte bewijzen van inclusie toe en integreren certificaattransparantie direct in de uitgifte. Het resultaat is een geloofwaardige weg naar kwantumresistente authenticatie zonder de prestatievermindering die anders de acceptatie zou belemmeren. 

Het voorstel is nog experimenteel, de tijdlijnen verschuiven nog en de afwegingen worden nog steeds binnen de IETF besproken. Maar de grote browsers, certificeringsinstanties en CLM-leveranciers beschouwen het allemaal als een serieus signaal over de richting die WebPKI opgaat: naar meer vertrouwensankers, certificaten met een kortere geldigheidsduur, geïntegreerde transparantie en een periode waarin klassieke en post-kwantummodellen naast elkaar bestaan. Of MTC's nu precies in hun huidige vorm worden geïmplementeerd of niet, de operationele les blijft hetzelfde. De teams die dit goed aanpakken, zijn de teams die al weten welke certificaten ze bezitten, cryptografie kunnen wisselen wanneer dat nodig is en de volledige levenscyclus hebben geautomatiseerd. Zorg dat deze basisprincipes kloppen, en zelfs een herontwerp van het vertrouwen zelf wordt iets wat je rustig kunt beheren in plaats van ertegen te moeten vechten.

Veelgestelde Vragen / FAQ

Zijn Merkle Tree-certificaten een NIST-standaard?

Nee. MTC's zijn een experimenteel voorstel dat is ontwikkeld binnen de PLANTS-werkgroep van de IETF, door ingenieurs van Google, Cloudflare en Geomys. Ze gebruiken door NIST gestandaardiseerde algoritmen zoals ML-DSA voor ondertekening, maar de batchverwerkingsarchitectuur zelf is geen NIST-publicatie.

Waarom vormen post-kwantumhandtekeningen een probleem voor TLS-handshakes?

Een ECDSA P-256-handtekening is ongeveer 64 bytes groot, terwijl ML-DSA-44 handtekeningen produceert van circa 2,420 bytes, bijna veertig keer zo groot. Wanneer deze handtekeningen worden toegevoegd aan een certificaatketen plus Certificate Transparency-tijdstempels, kan een volledige kwantumveilige handshake vijftien tot dertig kilobytes groot zijn. Dit vertraagt ​​het laden van pagina's op mobiele apparaten of netwerken met beperkte bandbreedte, waardoor de acceptatie ervan wordt belemmerd.

Wat is de "signatureless" of landmark-modus in MTC's?

Het is een optionele optimalisatie waarbij een actuele vertrouwende partij alleen een publieke sleutel en een Merkle-inclusiebewijs nodig heeft om een ​​certificaat te valideren, zonder dat er een handtekening op het netwerk nodig is. Onderzoek naar de toepassing hiervan op private infrastructuur toonde aan dat dergelijke bewijzen ongeveer 736 bytes groot kunnen zijn. Oudere clients die niet voldoende actueel zijn, vallen terug op de traditionele methode met een handtekening.

Welke organisaties hebben zich gecommitteerd aan Merkle Tree-certificaten?

Let's Encrypt, dat meer dan 500 miljoen websites beveiligt, heeft MTC's op 3 juni 2026 aangewezen als de gekozen strategie na de kwantumcrash. Het bedrijf streeft naar een testomgeving eind 2026 en productiegereedheid in 2027. Google test MTC's ook live met Cloudflare en bouwt een aparte, kwantumresistente root store voor Chrome, met een framework voor het onboarden van certificeringsinstanties dat naar verwachting rond het derde kwartaal van 2027 beschikbaar zal zijn.

Zijn MTC's van invloed op certificaten die vandaag worden uitgegeven?

Nee. Let's Encrypt heeft aangegeven dat er vandaag niets verandert voor bestaande abonnees; certificaten worden nog steeds via ACME uitgegeven, precies zoals voorheen, terwijl het diepere werk achter de schermen plaatsvindt in de uitgifte-infrastructuur, het ACME-protocol en de tools voor intrekking en transparantie.

Hoe moeten organisaties zich voorbereiden op MTC's als de specificatie nog experimenteel is?

In plaats van de steeds veranderende conceptversie nauwlettend te volgen, kunt u zich beter richten op de fundamentele aspecten die zich ongeacht de uiteindelijke specificatie uitbetalen: volledig inzicht in elk certificaat dat u bezit, cryptografische flexibiliteit om algoritmes te wisselen zonder de architectuur opnieuw te hoeven ontwerpen, en geautomatiseerde detectie, registratie en verlenging, aangezien een wereld van certificaten met een kortere levensduur en een groter aantal certificaten handmatig certificaatbeheer onmogelijk maakt.