PQC TLS certificaatmigratie is het proces waarbij organisaties hun op klassieke wiskunde gebaseerde TLS-certificaten vervangen door of aanvullen met certificaten die bestand zijn tegen aanvallen door kwantumcomputers. Voor compliance officers en IT-beslissers in gereguleerde sectoren is dit geen toekomstige zorg, maar een lopende operationele verplichting: de cryptografische infrastructuur die nu TLS-verbindingen beveiligt, wordt kwetsbaar zodra voldoende krachtige kwantumcomputers beschikbaar komen.
Drie modellen voor PQC-authenticatie in TLS 1.3
De keuze voor een migratiemodel bepaalt zowel de interoperabiliteit als de beheerlast voor de komende jaren. Er zijn drie hoofdmodellen, elk met eigen afwegingen voor organisaties in overheid, juridische dienstverlening en andere gereguleerde sectoren.
Composiet certificaten
Bij composiet certificaten worden een klassiek algoritme (zoals ECDSA of RSA) en een PQC-algoritme (zoals ML-DSA, gedefinieerd in NIST FIPS 204) gecombineerd in één enkel X.509-certificaat. De LAMPS-werkgroep van de IETF ontwikkelt de bijbehorende X.509 PQC-certificaatprofielen. De gecombineerde handtekening is alleen geldig als beide componenten kloppen, wat “and-logica” oplevert: het certificaat is zo sterk als het sterkste algoritme in de ogen van een kwantumcapabele aanvaller, maar vereist dat de ontvangende partij beide algoritmen begrijpt.
Het voordeel is gecentraliseerd beheer: één certificaat per entiteit, één vernieuwingscyclus, één PKI-pad. Het nadeel is dat niet alle bestaande TLS-clients composiete OID’s herkennen. Oudere middleware en browserversies kunnen handshakes weigeren of de extra component negeren, wat het risico op stille degradatie vergroot.
Dubbele certificaten
Het model van dubbele certificaten, beschreven in het IETF-draft draft-yusef-tls-pqt-dual-certs, geeft een server twee afzonderlijke certificaten: één klassiek (ECDSA of RSA) en één PQC-certificaat op basis van ML-DSA of een vergelijkbaar algoritme. De client selecteert op basis van zijn mogelijkheden welk certificaat hij accepteert tijdens de TLS-handshake.
Dit model biedt maximale achterwaartse compatibiliteit: legacy-clients blijven het klassieke certificaat gebruiken, terwijl PQC-capabele clients automatisch het kwantumveilige pad kiezen. De operationele keerzijde is dat elke server twee certificaatketens moet onderhouden, met de bijbehorende verdubbeling van vernieuwingstaken, monitoringconfiguraties en CA-aanvragen.
PQC-only certificaten
Het derde model verwijdert klassieke algoritmen volledig en werkt uitsluitend met ML-DSA of SLH-DSA (FIPS 205) certificaten. Dit is het eindpunt van elke migratie en levert de schoonste architectuur op, maar is voorlopig uitsluitend geschikt voor gesloten omgevingen waar alle clients en servers al PQC-capabel zijn. Voor organisaties met externe partners, publieke API’s of brede clientpopulaties is een PQC-only benadering vandaag niet haalbaar zonder substantieel interoperabiliteitsverlies.
| Model | Interoperabiliteit | Beheerlast | Kwantumveiligheid | Geschikt voor |
|---|---|---|---|---|
| Composiet certificaat | Matig (vereist composiet-ondersteuning) | Laag (één certificaat) | Hoog (als beide componenten worden gevalideerd) | Interne PKI, gecontroleerde ecosystemen |
| Dubbele certificaten | Hoog (legacy-clients blijven werken) | Hoog (twee certificaatketens) | Hoog voor PQC-clients, klassiek voor legacy | Publieke diensten, gemengde clientpopulaties |
| PQC-only | Laag (vereist volledige PQC-clientondersteuning) | Laag (één certificaat) | Maximaal | Gesloten interne systemen, lange termijn eindtoestand |
Downgrade- en rollback-aanvallen tijdens de transitieperiode
De transitiefase, waarbij klassieke en kwantumveilige mechanismen naast elkaar bestaan, introduceert een specifiek aanvalsoppervlak: een actieve aanvaller kan de PQC-component uit een composiet certificaat of de TLS-extensie die PQC-ondersteuning signaleert, wegstoken of onderdrukken, waarna de verbinding terugvalt op klassieke cryptografie.
Het IETF-draft draft-sheffer-tls-pqc-continuity-02 beschrijft een mechanisme waarbij servers via een TLS-extensie kenbaar maken dat zij PQC ondersteunen en waarbij clients die eerder een PQC-verbinding hebben gehad, een niet-PQC-handshake kunnen weigeren of markeren. Dit concept lijkt op HTTP Strict Transport Security (HSTS), maar dan voor het kwantumveiligheidslaagje. Concreet betekent dit dat IT-beheerders bij de implementatie van composiet of dubbele certificaten ook de bijbehorende TLS-extensieconfiguratie moeten inrichten en dat TLS-monitors moeten controleren of de verwachte PQC-signatuurcomponent aanwezig is in elke verbinding met kritieke systemen.
‘Harvest now, decrypt later’ en het tijdpad van migratie
NIST schat dat kwantumcomputers klassieke publieke-sleutelcryptografie binnen tien tot vijftien jaar kunnen breken (NIST, 2024). De Amerikaanse NSA vereist via CNSA 2.0 dat nationale veiligheidssystemen uiterlijk in 2030 kwantumbestendige algoritmen gebruiken (NSA, 2022). NIST publiceerde in augustus 2024 drie definitieve PQC-standaarden: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA).
Zoals ENISA in haar Post-Quantum Cryptography rapport stelt: “The threat of ‘harvest now, decrypt later’ attacks means that any data encrypted today with classical algorithms can be stored and decrypted once a sufficiently powerful quantum computer becomes available.” Dit betekent dat TLS-sessiedata die vandaag wordt onderschept, al kwetsbaar is als de geheimhoudingstermijn van die data langer is dan de verwachte tijd tot een relevante kwantumcomputer. Voor advocatenkantoren, overheidsdiensten en financiële instellingen die gevoelige informatie uitwisselen met langjarige vertrouwelijkheidsverplichting, is de urgentie dus groter dan de tien-jaar-horizon suggereert.
PKI-infrastructuurwijzigingen voor kwantumveilige certificaten
De overgang naar PQC-certificaten raakt de volledige PKI-keten: root CA’s, intermediate CA’s, end-entity certificaten, OCSP-responders en certificaatbeheersystemen moeten allemaal worden bijgewerkt.
Root CA en intermediate CA
Bestaande root CA’s zijn gebouwd op RSA of ECDSA en ondertekenen geen ML-DSA-gebaseerde end-entity certificaten zonder aanpassing. Organisaties met een private PKI moeten nieuwe PQC-root CA’s genereren, bij voorkeur als composiet (klassiek plus ML-DSA) of als afzonderlijke PQC-root naast de bestaande klassieke root. Deze nieuwe roots moeten worden verspreid naar alle vertrouwensstores: besturingssystemen, browsers, Java-truststores en applicatiespecifieke configuraties.
Certificaatbeheer en automatisering
PQC-certificaten hebben grotere sleutelgroottes en handtekeningen dan hun klassieke tegenhangers. ML-DSA handtekeningen zijn aanzienlijk groter dan ECDSA-handtekeningen, wat gevolgen heeft voor TLS-handshakelatentie en MTU-grenzen. Certificaatbeheersystemen (zoals ACME-gebaseerde automatisering) moeten worden gecontroleerd op ondersteuning voor de nieuwe OID’s die de LAMPS-werkgroep van de IETF definieert in de X.509 PQC-certificaatprofielen.
Interoperabiliteit met IETF-werkgroepen
De IETF PQUIP-werkgroep coördineert de bredere integratie van PQC-algoritmen in internetprotocollen. Het draft draft-ietf-uta-pqc-app geeft applicatieontwikkelaars en TLS-implementatoren richtlijnen voor het gebruik van PQC in de context van gebruikersgerichte applicaties. Organisaties die hun TLS-stacks bijwerken, doen er verstandig aan deze drafts te volgen, omdat implementaties die afwijken van de uiteindelijke IETF-standaarden later opnieuw moeten worden aangepast.
Concrete stappen voor gereguleerde organisaties
Dustin Moody, wiskundige en leider van het NIST PQC-standaardisatieproject, stelt: “Organisations that have not started their cryptographic inventory and agility programme by 2025 will struggle to meet mandatory PQC timelines set by regulators and standards bodies.” Voor IT-teams in overheid, juridische dienstverlening en andere NIS-2- of GDPR-plichtige sectoren vertaalt dit zich in een gestructureerde aanpak.
Stap 1: Cryptografische inventarisatie. Breng alle certificaten, CA’s, TLS-eindpunten en cryptografische bibliotheken in kaart. Identificeer welke systemen RSA of ECDSA gebruiken en wat hun vernieuwingsdatum is.
Stap 2: Cryptografische behendigheid (crypto agility). Zorg dat applicaties en middleware de cryptografische algoritmen via configuratie kunnen wisselen, zonder hercompilatie. Dit is de voorwaarde voor een gecontroleerde migratie.
Stap 3: Pilotdeployment met composiet of dubbele certificaten. Start met een interne omgeving of een niet-kritiek extern systeem. Gebruik ML-DSA (FIPS 204) als PQC-component en meet de impact op handshakelatentie en applicatiefunctionaliteit.
Stap 4: PKI-uitrol en vertrouwensankerpropagatie. Genereer nieuwe PQC-intermediates ondertekend door een composiet root, verspreid de nieuwe trustankerpunten naar alle relevante systemen en zorg dat OCSP-responders en CRL-distributie ook het nieuwe profiel ondersteunen.
Stap 5: Downgrade-protectie activeren. Implementeer de mechanismen uit draft-sheffer-tls-pqc-continuity-02 of vergelijkbare TLS-extensies op kritieke endpoints, en voeg PQC-aanwezigheidscontroles toe aan uw TLS-monitoringinfrastructuur.
Stap 6: Fasering naar PQC-only. Zodra alle clients in een gegeven segment PQC-capabel zijn, verwijder de klassieke component en ga over op PQC-only certificaten conform de uiteindelijke LAMPS-profielen.
Interoperabiliteit en de rol van IETF-drafts
De IETF-drafts die momenteel in omloop zijn, zijn geen definitieve standaarden. Draft-sheffer-tls-pqc-continuity-02 en draft-yusef-tls-pqt-dual-certs beschrijven mechanismen die nog kunnen wijzigen voor de definitieve RFC-publicatie. Organisaties die deze drafts nu al implementeren, lopen het risico op herbouwwerk wanneer de uiteindelijke standaard afwijkt. De IETF PQUIP-werkgroep en de LAMPS-werkgroep publiceren regelmatig updates; het abonneren op de bijbehorende mailinglijsten is voor PKI-verantwoordelijken geen overbodige luxe.
De huidige drafts bieden wel al voldoende basis voor pilotimplementaties, mits de organisatie bereid is de configuratie aan te passen bij RFC-publicatie. Verkopers als Mozilla, Google en Apple volgen de IETF-standaardisatie actief en bouwen PQC-ondersteuning in hun TLS-stacks in. De interoperabiliteit neemt daarmee toe naarmate meer clients en servers FIPS 204-conforme handtekeningen ondersteunen, maar in 2025 is volledige ecosysteemondersteuning nog niet bereikt.
FAQ
Wat is het verschil tussen composiet certificaten en dubbele certificaten bij PQC TLS-migratie?
Bij composiet certificaten worden een klassiek algoritme en een PQC-algoritme gecombineerd in één X.509-certificaat. Bij dubbele certificaten heeft een server twee afzonderlijke certificaten: één klassiek en één PQC. Composiet is eenvoudiger te beheren, dubbele certificaten bieden meer achterwaartse compatibiliteit maar verdubbelen de beheerlast.
Wat is ‘harvest now, decrypt later’ en waarom is het relevant voor TLS-certificaatmigratie?
Aanvallers kunnen versleuteld TLS-verkeer nu onderscheppen en opslaan, om het later te ontsleutelen zodra een kwantumcomputer beschikbaar is. Dit maakt migratie urgent voor data met een langjarige vertrouwelijkheidsverplichting, zoals juridische dossiers of overheidscommunicatie, zelfs als kwantumcomputers pas over tien jaar inzetbaar zijn.
Hoe bescherm ik TLS-verbindingen tegen downgrade-aanvallen tijdens de PQC-transitie?
Via mechanismen beschreven in draft-sheffer-tls-pqc-continuity-02 kunnen clients worden geconfigureerd om verbindingen te weigeren of te markeren wanneer de verwachte PQC-component ontbreekt. Combineer dit met strikt cipher-suite-beleid en TLS-monitoring die controleert op de aanwezigheid van PQC-handtekeningen.
Welke FIPS-standaarden zijn relevant voor PQC-authenticatie in TLS-certificaten?
NIST FIPS 204 (ML-DSA) is de primaire standaard voor digitale handtekeningen en certificaatauthenticatie. FIPS 203 (ML-KEM) is relevant voor sleuteluitwisseling in TLS-handshakes. FIPS 205 (SLH-DSA) biedt een alternatief op basis van hash-functies. Voor de meeste TLS-certificaatmigraties in gereguleerde omgevingen is ML-DSA het meest toepasbaar.
Wanneer moeten organisaties beginnen met PQC certificaatmigratie?
Gezien de NSA CNSA 2.0-deadline van 2030 en de dreiging van ‘harvest now, decrypt later’-aanvallen is de aanbeveling om nu te starten met cryptografische inventarisatie en agility-planning. PKI-migraties in complexe organisaties kosten meerdere jaren, en starten in 2025 is voor de meeste gereguleerde organisaties het verantwoorde minimum.
