2026-08-18 · RESEARCH · Het Offensive Technology team

Certificate transparency post-quantum: 43% van de static-CT logs ondertekent al met ML-DSA-44

Certificate transparency is stilletjes begonnen aan zijn post-quantum migratie, en zit op de log-ondertekeningslaag al 43% van de weg. We haalden het publieke checkpoint-bestand op van elk van de 70 static-CT logs in de publieke logslijst, en 30 daarvan (42,9%) voegen een post-quantum ML-DSA-44 handtekening toe aan elk checkpoint, direct naast hun klassieke ECDSA handtekening. Dat is opmerkelijk, want geen vergelijkbaar oppervlak heeft die stap gezet: DNSSEC is 0% post-quantum en de TLS-handshake staat nog aan het begin. De wending zit in de andere helft van het ontwerp. De witness-laag, het mechanisme dat een log moet betrappen op liegen over zijn eigen geschiedenis, is nauwelijks uitgerold: slechts 11 van de 70 logs dragen ook maar een witness-cosignature, we zagen in het hele ecosysteem maar 6 verschillende witnesses, en 0 daarvan zijn post-quantum. Het ondertekenen loopt ver voor op het toezicht.

Wat we gemeten hebben, en waarom een checkpoint leesbaar is

Certificate transparency stapt over van het oude RFC 6962 request-response protocol naar het static-ct-api formaat, waarbij een log gewoon een set statische bestanden op een CDN is. Let's Encrypt sloot zijn klassieke logs op 28 februari 2026 (hun end-of-life plan heeft de tijdlijn), en het tiled model is nu de mainstream. Het ene kleine bestand dat de huidige staat van een static log samenvat is zijn checkpoint: de naam van de log, zijn tree size, zijn Merkle root hash, en dan een blok handtekeningen. Het is bewust openbaar, omdat monitors wereldwijd het constant ophalen om de log eerlijk te houden. Het lezen ervan raakt niets privés en onderzoekt geen host; het is dezelfde GET die een monitor uitvoert, en het is het CT-equivalent van het lezen van een openbaar DNS-record.

We namen de gepubliceerde CT logslijst, haalden er elke tiled log uit, en haalden ieders checkpoint precies één keer op. Alle 70 antwoordden. Daarna parsten we het handtekeningblok. In het signed-note formaat dat een checkpoint gebruikt, staat elke handtekening op zijn eigen regel: een streepjesmarkering, dan de naam van de ondertekenaar, dan een base64-waarde die bestaat uit een vier-byte key hint gevolgd door de handtekening zelf. Dat laatste detail is de hele methode: de bytelengte van de handtekening verraadt het algoritme. Een Ed25519 handtekening is 64 bytes. De legacy RFC 6962 tree-head handtekening is een timestamp plus een korte ECDSA blob. En een ML-DSA-44 handtekening is 2.420 bytes, de vaste grootte gedefinieerd door NIST FIPS 204. We hoefden dus geen label te vertrouwen; we telden bytes.

Post-quantum staat al op 43% van de static-CT logs

Hier is de hele populatie, geclassificeerd naar wat daadwerkelijk in elk checkpoint voorkomt. Eén checkpoint draagt doorgaans meer dan één handtekeningregel, dus dit zijn tellingen van logs, niet van handtekeningen.

De tweede rij is het hoofdnieuws. Dertig logs ondertekenen hun checkpoint niet alleen met een klassieke sleutel; ze voegen daar bovenop een volledige 2.420-byte ML-DSA-44 handtekening aan toe, zodat elk checkpoint op beide manieren ondertekend is. Dit is precies wat de checkpoint-spec vraagt. In eigen woorden zouden logs ML-DSA-44 cosignatures moeten gebruiken om het checkpoint te ondertekenen, en het cosignature-formaat definieert een specifiek post-quantum type, omschreven als veilig tegen quantumcomputers, direct naast het klassieke type. Een adoptiegraad van 43% voor een zou moeten die de meeste operators konden negeren, is snelle beweging. En het is geconcentreerd: de post-quantum handtekeningen clusteren bij een minderheid van operators die grote families van temporal-shard logs draaien, dus een beslissing van een paar teams dekt al bijna de helft van de populatie. We rapporteren het geaggregeerde beeld in plaats van een naam-en-schaam lijst, want meer ondertekenen met crypto is iets goeds, geen bevinding tegen iemand.

De reden dat deze laag kan bewegen terwijl andere dat niet kunnen, is omvang. Een ML-DSA-44 handtekening is ruwweg 38 keer zo groot als een ECDSA-handtekening, wat verklaart waarom het niet in een DNS-pakket past en waarom de TLS-handshake er terughoudend mee is. Maar een checkpoint is een klein bestand dat door een paar duizend monitors wordt opgehaald, geen veld dat op miljarden handshakes wordt verstuurd. De transparency-laag heeft het bytebudget om als eerste post-quantum te gaan, en het geeft dat budget ook uit.

De witness-laag is het omgekeerde verhaal

Een checkpoint ondertekenen bewijst dat de log een verklaring heeft afgelegd. Het bewijst niet dat de log dezelfde verklaring aan iedereen aflegde. Een gecompromitteerde log kan een split-view aanval uitvoeren: slachtoffers een tree tonen die een frauduleus certificaat bevat, en monitors een schone tree tonen die dat niet doet, zodat de fraude nergens landt waar iemand audit. De oplossing is witnessing. Een witness is een onafhankelijke dienst die het laatste checkpoint onthoudt dat hij van een log zag, verifieert dat elk nieuw checkpoint een consistente, append-only uitbreiding is, en pas dan een cosignature teruggeeft. Vereis genoeg onafhankelijke witnesses op een checkpoint en een log kan niet langer twee geschiedenissen bijhouden, omdat geen eerlijke witness beide zal cosigneren.

Dat is het mechanisme dat een log verandert van vertrouw-me naar kan-niet-liegen. In het levende ecosysteem is het dun:

• Slechts 11 van de 70 logs (16%) dragen ook maar een witness-cosignature, en elk van die logs hoort bij de logfamilie van één enkele operator. Alle checkpoints van elke andere operator zijn alleen door de log zelf ondertekend, zonder onafhankelijke partij die de consistentie attesteert.
• Slechts 6 verschillende witnesses komen voor in het hele ecosysteem, en maar 2 daarvan lijken op productiediensten. De andere vier identificeren zichzelf als staging-, dev- of proof-of-concept witnesses.
• Elke witness-cosignature zonder uitzondering is klassiek Ed25519. Niet één witness gebruikt het post-quantum ML-DSA-44 cosignature-type dat dezelfde spec definieert. De anti-equivocation laag is 0% post-quantum.

Waar witnessing wel draait, draait het goed: de cosignatures die we zagen droegen timestamps met een mediaan van ongeveer 5 seconden achter op ons ophaalmoment, dus witnesses cosigneren vrijwel in real time. Het probleem is niet latency, het is dekking. Een split-view verdediging die één operator dekt en twee productiedeelnemers heeft, is een veelbelovende pilot, nog geen ecosysteemgarantie.

Twee verschillende weddenschappen op de toekomst van transparency

Zet de twee lagen naast elkaar en er komt een patroon naar boven dat interessanter is dan elk cijfer apart. De logs die post-quantum zijn gegaan en de logs die witness-cosignatures dragen zijn disjuncte verzamelingen, gerund door verschillende operators. Het ene kamp steekt zijn moeite in post-quantum logsignaturen en levert geen witnessing. Het andere kamp steekt zijn moeite in het witness-netwerk en levert geen post-quantum handtekening. Niemand in deze telling doet beide.

Die splitsing is het benoemen waard omdat de twee investeringen tegen verschillende dreigingen beschermen, en de zwaardere dreiging is degene die je verliest. Post-quantum ondertekenen beschermt tegen het verre-toekomstscenario waarin een quantumcomputer de handtekening van een log vervalst. Witnessing beschermt tegen het scenario van vandaag waarin een log nu equivoceert. Het ecosysteem heeft collectief de speculatieve dreiging naar voren gehaald en de concrete dreiging ondergeïnvesteerd. Post-quantum is de zichtbare, aantoonbare upgrade; witnessing vereist dat andere partijen infrastructuur draaien en dat clients een quorum eisen, wat organisatorisch lastiger is. Dus is de makkelijke helft als eerste geleverd.

De lokhandtekeningen, en waarom ze een goed teken zijn

Eén bijkomstige bevinding zegt iets gezonds over het ecosysteem. Op 46 van de 70 logs (66%) draagt het checkpoint een handtekeningregel onder de naam grease.invalid, waarvan de bytes willekeurig zijn en tegen niets verifiëren. Dit staat niet in de specificatie, dus we melden het als observatie, niet als regel. Maar het sluit precies aan bij de gedocumenteerde eis dat een verifiërende partij handtekeningen van sleutels die hij niet herkent moet negeren. Die regel is wat het veilig maakt voor een log om witness-cosignatures of een nieuwe post-quantum sleutel toe te voegen zonder oude clients te breken. Het uitzenden van een opzettelijk ongeldige handtekening, in de stijl van de GREASE-techniek uit TLS, dwingt elke parser om die must-ignore regel daadwerkelijk na te leven in plaats van te stikken in de eerste onbekende regel. Twee derde van de logs die hun eigen consumenten stress-testen is een teken van een ecosysteem dat verwacht dat het handtekeningblok blijft groeien, precies wat een post-quantum overgang nodig heeft.

Hoe we het gemeten hebben, zodat een scepticus de cijfers kan vertrouwen

De dataset is van onszelf, opgebouwd uit uitsluitend publieke bestanden, en gerapporteerd als aggregaat. We hebben geen enkele log gescand, geprobed, iets ingediend bij, of verbinding mee gemaakt, buiten het ophalen van het ene publieke checkpoint-bestand dat elke log precies voor dit doel publiceert. Er zit geen privédata in een checkpoint; het is een tree size, een hash, en handtekeningen. We noemen geen enkele operator gebrekkig, want dat is er geen: dit is een momentopname van een ecosysteem midden in een upgrade.

• De populatie. Elke tiled log in de publieke CT logslijst, 70 in totaal. Alle 70 gaven op de meetdatum een leesbaar checkpoint terug. Veel zijn temporal shards, dus het aantal logs is hoger dan het aantal operators.
• De classificatie. Voor elke handtekeningregel decodeerden we de base64, lieten de vier-byte key hint vallen, en lazen de resterende lengte. 2.420 bytes (in een timestamped envelope) is een ML-DSA-44 handtekening volgens FIPS 204; 64 is Ed25519; de korte timestamped blob is de RFC 6962 tree-head handtekening. Algoritme door constructie, niet door label.
• Log versus witness. Een handtekening waarvan de naam overeenkomt met de eigen origin van de log, is de log die zichzelf ondertekent. Een cosignature onder een aparte witness-identiteit is een onafhankelijke attestatie. We telden ze apart, wat verklaart waarom het post-quantum-aantal en het witness-aantal verschillende lagen beschrijven.
• Post-quantum op basis van omvang. De 30 post-quantum logs dragen elk een handtekening van precies de ML-DSA-44 lengte, in de cosignature-envelope die de spec ervoor definieert. Een klassiek schema kan niet per ongeluk een handtekening van 2.420 bytes produceren, dus het aantal is geen schatting.

Waarom dit ertoe doet, en de eerlijke beperkingen

Certificate transparency is een fundament waar andere verdedigingen op steunen. Het is hoe de wereld een verkeerd uitgegeven certificaat voor een bank of een mailprovider opmerkt, en het ondersteunt controles zoals de garanties die je van een certificaat kunt aflezen en uitgiftebeperkingen zoals CAA. Net als DNSSEC ondertekent CT in plaats van te versleutelen, dus het quantumrisico is toekomstige vervalsing, niet harvest-now-decrypt-later. Dat betekent dat het 43% post-quantum resultaat oprecht voorloopt op de dreiging, wat goed nieuws en zeldzaam is. Maar de keerzijde is het onderdeel dat meer aandacht zou moeten krijgen: het mechanisme dat een log betrouwbaar maakt tegen een hedendaagse, niet-quantum aanvaller, onafhankelijk witnessing, is precies degene die dun en klassiek is. Als je erop gokt dat transparency de volgende verkeerde uitgifte opvangt, is het witness-netwerk het cijfer om in de gaten te houden, niet het handtekeningalgoritme.

Een resultaat zonder zijn beperkingen is marketing, dus hier zijn de grenzen.

• Eén lijst, één dag. Dit is de publieke logslijst op één specifieke datum. Shards worden toegevoegd en geroteerd, en witnessing wordt actief uitgerold, dus de exacte aantallen zullen verschuiven. De structurele bevinding, dat ondertekenen witnessing heeft ingehaald, is het duurzame deel.
• Alleen geserveerde checkpoints. We lazen wat elke log op zijn eigen checkpoint-endpoint serveert. Een witness die een log cosigneert maar zijn cosignatures elders distribueert, zou hier niet verschijnen, dus de werkelijke omvang van witnessing-activiteit is een ondergrens, geen bovengrens. Het punt blijft staan dat de checkpoints die clients daadwerkelijk ophalen grotendeels ongewitnessed zijn.
• Aanwezigheid, geen verificatie. We classificeerden handtekeningen op algoritme en identiteit, niet door elk cryptografisch te verifiëren tegen zijn sleutel. Een aanwezige ML-DSA-44 handtekening van de juiste omvang is sterk bewijs van post-quantum ondertekenen; bevestigen dat elke handtekening geldig is, is een aparte oefening.
• De GREASE-regel is afgeleid. De grease.invalid lokhandtekening is onze interpretatie van een ongedocumenteerd maar consistent gedrag, geen door de spec verplicht kenmerk.

Veelgestelde vragen

Wat is een static CT log?

Een static CT log is een certificate transparency log die als statische bestanden, tiles genoemd, wordt geserveerd vanuit object storage of een CDN, volgens de C2SP static-ct-api specificatie. In plaats van de RFC 6962 request-response API publiceert het append-only tiles van 256 entries plus een klein signed checkpoint dat de huidige tree size en root hash aangeeft. Monitors lezen de bestanden rechtstreeks, wat logs goedkoop maakt om te draaien en te spiegelen. Dit ontwerp, aanvankelijk de Sunlight API genoemd, werd in 2025 en 2026 mainstream bij CT-operators.

Zijn certificate transparency logs al post-quantum?

Gedeeltelijk, en eerder dan de meesten aannemen. In onze telling van alle 70 static-CT logs voegen 30 daarvan (43%) al een ML-DSA-44 handtekening toe aan elk checkpoint, naast hun klassieke handtekening. ML-DSA-44 is het FIPS 204 lattice-schema dat bestand is tegen quantumaanvallen, en het is precies wat de checkpoint-spec aanbeveelt. De log-ondertekeningslaag zit dus al goed in zijn post-quantum migratie. De witness-laag die deze checkpoints cosigneert is nog steeds 0% post-quantum; elke witness-cosignature die we zagen was klassiek Ed25519.

Wat is ML-DSA-44 en waarom wordt het hier gebruikt?

ML-DSA-44 is de kleinste parameterset van ML-DSA, de module-lattice handtekeningstandaard in NIST FIPS 204, afgeleid van CRYSTALS-Dilithium. Zijn handtekeningen zijn 2.420 bytes en zijn sleutels 1.312 bytes, veel groter dan een 64-byte Ed25519 handtekening, maar het wordt niet gebroken door het algoritme van Shor. Certificate transparency kan de omvang absorberen omdat een checkpoint slechts af en toe door monitors wordt opgehaald, niet bij elke handshake wordt verzonden, wat verklaart waarom CT post-quantum handtekeningen jaren voor DNSSEC of de TLS-handshake kan adopteren.

Wat is een CT witness en een witness-cosignature?

Een witness is een onafhankelijke dienst, geïdentificeerd door een naam en een publieke sleutel, die de checkpoints van een log in de gaten houdt. Voordat hij een nieuw checkpoint cosigneert, verifieert hij dat de nieuwe tree consistent is met de laatste die hij zag, wat betekent dat de log alleen heeft toegevoegd en nooit geschiedenis heeft herschreven, en geeft dan een timestamped cosignature terug, gedefinieerd door de C2SP tlog-witness en tlog-cosignature specificaties. Een checkpoint met cosignatures van meerdere onafhankelijke witnesses is voor een gecompromitteerde log veel moeilijker om over te liegen.

Hoe voorkomt een witness-cosignature een split view?

Een split-view aanval is een log die één tree aan slachtoffers toont en een andere, eerlijke tree aan monitors, zodat frauduleuze certificaten nergens verschijnen waar iemand audit. Omdat een witness pas cosigneert na het controleren van consistentie met de geschiedenis die hij al bezit, kan een log geen twee tegenstrijdige checkpoints door dezelfde eerlijke witness laten cosigneren. Als clients cosignatures van een quorum onafhankelijke witnesses eisen, moet de log iedereen dezelfde append-only tree tonen, wat het gat dicht dat kaal loggen openlaat.

Wanneer zijn RFC 6962 certificate transparency logs gestopt?

De migratie liep door 2025 en 2026. Let's Encrypt kondigde in augustus 2025 het einde van de levensduur van zijn RFC 6962 logs aan, zette ze op 30 november 2025 op read-only, en sloot ze op 28 februari 2026 volledig af, ten gunste van zijn static Sycamore- en Willow-logs. Chrome voegde begin 2025 ondersteuning voor static-ct-api toe en faseert de eis uit dat minstens één SCT van een oude RFC 6962 log moet komen.

Hoeveel certificate transparency logs zijn er in 2026?

De publieke CT logslijst die we gebruikten bevat 70 static, tiled logs verspreid over een handvol operators, plus de resterende klassieke logs. Veel van de 70 zijn temporal shards, elk met een bereik aan certificaatvervaldatums, dus één operator draait er meerdere tegelijk. Alle 70 static logs gaven een leesbaar checkpoint terug toen we ze maten.

Gerelateerde artikelen

• DNSSEC post-quantum gereedheid: 0% van de top 30.000 domeinen. Dezelfde post-quantum vraag op een oppervlak dat nog niet kan bewegen, omdat de handtekeningen niet in een DNS-pakket passen.
• Schakelt FIPS post-quantum TLS uit? De post-quantum overgang gemeten op de TLS-handshake in plaats van de transparency-laag.
• Wat de certs bewijzen. Cryptografische garanties aflezen van publieke records in plaats van het label te vertrouwen, dezelfde methode toegepast op certificaten zelf.
• Hoeveel topdomeinen beperken certificaatuitgifte? Het certificaatecosysteem passief gemeten vanuit publieke data.