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

Een Merkle Tree Certificate (MTC) is een nieuw, compacter type certificaat. TLS certificaat, momenteel een experimenteel IETF-voorstel, waarin een Certificate Authority Het bundelt veel certificaten in één Merkle-boom en ondertekent alleen de wortel van de boom, 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 leveren zonder de overdreven grote handtekeningen die de PQC-algoritmen van NIST anders aan elke TLS-handshake zouden toevoegen.

Als je beroepsmatig met digitale certificaten werkt, is de term 'post-kwantumtransitie' waarschijnlijk niet langer een abstractie op afstand, maar iets wat je nu op je planning hebt staan. NIST heeft zijn eerste post-kwantumcryptografie voltooid (PQC(De laatste zin is een veelvoorkomend probleem) dat browsers al kwantumveilige sleuteluitwisseling aanbieden, 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 in te passen 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. Om misverstanden over de naam te voorkomen, eerst even iets duidelijk maken: Merkle Tree Certificates (MTC's) zijn geen publicatie van NIST. Het is een experimenteel voorstel van de IETF, momenteel ontwikkeld in de PLANTS-werkgroep door ingenieurs van Google, Cloudflare en Geomys. Wat ze wel met NIST verbindt, is het probleem dat ze oplossen. De door NIST gestandaardiseerde PQC-handtekeningalgoritmen, zoals ML-DSADe afmetingen van MTC's 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 lastige positie 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 versleuteld verkeer onderscheppen en opslaan, in de hoop dat een toekomstige kwantumcomputer die het algoritme van Shor gebruikt, het uiteindelijk zal ontcijferen. RSA en elliptische-curve-cryptografie die het beschermde. Gartner heeft voorspeld dat conventionele asymmetrische cryptografie zoals RSA en ECC Het beschermen van gevoelige gegevens kan onveilig zijn, 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-ondertekeningsschema's, produceert handtekeningen van ongeveer 2,420 bytes.Bijna veertig keer groter. 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 particuliere infrastructuur Een baanbrekend bewijs kan ongeveer 736 bytes groot 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 actuele 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 vernieuwd 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 lanceerde Let's Encrypt, de non-profit certificeringsinstantie die meer dan 500 miljoen websites beveiligt, heeft zijn post-kwantumroutekaart gepubliceerd en heeft Merkle Tree Certificates aangewezen als de gekozen aanpak. Het bedrijf streeft naar een testomgeving voor de uitgifte 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 ontworpen voor de openbare WebPKI, gelden 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 voor private omgevingen. PKIwaarbij de interne CA van een cluster wordt vervangen door een MTC-achtige autoriteit, compleet met medeondertekenaars en landmark-distributeurs. Als dat werk zich verder ontwikkelt, zouden de ideeën achter MTC's zich ver buiten het publieke TLS kunnen verspreiden en zelfs doordringen in de machine-identiteiten waar moderne infrastructuren van afhankelijk zijn.

De afwegingen en open vragen

Niets hiervan is gratis. 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 store 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 veranderen. Het gaat erom de richting te volgen. Vertrouwen wordt opnieuw vormgegeven, en certificaten Ze worden steeds korter van levensduur en steeds 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 herzien, en geautomatiseerde detectie, registratie en verlenging die er niet toe doet of de onderliggende handtekening wel of niet geldig is. ECDSA of ML-DSA. De voorbereiding op MTC's komt er in de praktijk op neer dat je nu 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-kwantumopties zoals ML-DSA, zonder uw workflows opnieuw te hoeven opbouwen. En omdat CertSecure Manager Het systeem beheert al openbare en particuliere CA's naast elkaar en is 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 de volgende ontwikkelingen in uw eigen tempo implementeren 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.