Een PKI-migratiemodel voor post-quantum cryptografie beschrijft de gestructureerde overgang van een publieke sleutelinfrastructuur die steunt op klassieke algoritmen zoals RSA en ECDSA, naar een infrastructuur die bestand is tegen aanvallen door cryptografisch relevante kwantumcomputers. Voor Europese organisaties in de overheids-, juridische en gereguleerde sectoren is die overgang geen theoretische oefening meer: NIST heeft in 2024 de eerste post-quantum standaarden gepubliceerd, de NIS-2-richtlijn vereist aantoonbaar cryptografisch risicobeheer, en het “harvest now, decrypt later”-dreigingsmodel maakt uitstel direct riskant.
Drie modellen: composiet, dubbel en PQC-only
De keuze van het certificaatmodel bepaalt de architectuur van de volledige migratie. Er zijn drie fundamenteel verschillende benaderingen, elk met eigen toepassingsgebied.
Composiet-certificaten combineren een klassieke publieke sleutel (bijvoorbeeld P-256) en een PQC-sleutel (bijvoorbeeld ML-DSA op basis van FIPS 204) in één enkel X.509-certificaat. De handtekening is eveneens samengesteld: beide algoritmen ondertekenen het certificaat, en een verifiërende partij moet beide handtekeningen kunnen valideren. Het IETF-werkdocument draft-ietf-lamps-dilithium-certificates legt de X.509 PQC-certificaatprofielen vast die nodig zijn voor interoperabele composiet-certificaten met ML-DSA. Dit model vereist dat CA-software wordt uitgebreid en dat clients actief beide algoritmen begrijpen.
Dubbele certificaten (dual certificates), zoals beschreven in IETF draft-yusef-tls-pqt-dual-certs, volgen een andere aanpak: de server houdt twee afzonderlijke certificaten in omloop, een klassiek en een PQC-certificaat, en biedt tijdens de TLS 1.3-handshake het meest geschikte aan op basis van de geadverteerde mogelijkheden van de client. De bestaande CA-infrastructuur blijft grotendeels intact; de complexiteit verschuift naar de TLS-serverconfiguratie.
PQC-only certificaten bevatten uitsluitend een post-quantum algoritme en veronderstellen dat alle communicerende partijen PQC-compatibel zijn. Dit model is het eindpunt van de migratie, niet een tussenstation.
| Kenmerk | Composiet-certificaat | Dubbel certificaat | PQC-only |
|---|---|---|---|
| CA-aanpassing vereist | Ja, uitgebreide X.509-profielen | Minimaal | Ja, volledig nieuw algoritme |
| Serverbeheer-complexiteit | Laag (één certificaat) | Hoog (twee certificaten beheren) | Laag |
| Legacy-client ondersteuning | Beperkt (client moet composiet begrijpen) | Goed (klassiek certificaat als fallback) | Geen |
| Geschikt voor IoT/embedded | Beperkt | Ja, via fallback | Alleen bij volledig gecontroleerde omgeving |
| Eindbestemming van migratie | Nee | Nee | Ja |
Operationele voor- en nadelen voor CA-operators en TLS-serverbeheerders
Dubbele certificaten bieden CA-operators een belangrijk voordeel: bestaande uitgifte-processen, revocatieinfrastructuur (OCSP, CRL) en HSM-configuraties hoeven niet direct te worden aangepast. Elke certificaatstroom, klassiek en PQC, verloopt via bekende procedures. Het nadeel is dat serverbeheerders twee certificaatketens moeten onderhouden, twee verloopcycli bewaken en twee ACME-of beheerprocessen inrichten. Bij grote deployments verdubbelt dit de operationele last aanzienlijk.
Composiet-certificaten vragen meer van de CA: de uitgifte-software moet de composiet-structuur begrijpen, de trust store moet de gecombineerde handtekening kunnen valideren, en de certificaatprofielen moeten conform de ETSI CYBER Quantum-Safe Cryptography (QSC)-specificaties en de X.509 PQC-certificaatprofielen zijn vastgelegd. Daar staat tegenover dat de serverbeheerder slechts één certificaat beheert. Voor grote CA-operators met honderden uitgevers (sub-CA’s) is de eenmalige investering in CA-aanpassing te rechtvaardigen door de lagere doorlopende servercomplexiteit.
Migratiekosten en de dubbele transitiekost
Een hybride transitiemodel brengt inherent dubbele kosten met zich mee: organisaties investeren eerst in de hybride infrastructuur (dubbele certificaten of composiet), en vervolgens opnieuw in de definitieve PQC-only overgang. Dit “dubbele transitiekost”-effect is een reëel financieel argument dat compliance officers en IT-budgethouders moeten meenemen in hun businesscase.
Toch zijn de alternatieven duurder. Wie wacht op een volledig volwassen PQC-ecosysteem, loopt het risico dat klassieke encryptie eerder wordt gecompromitteerd dan verwacht. NIST IR 8547 beveelt organisaties expliciet aan om nu te beginnen met cryptografische inventarisatie en hybride migratie, ook al is het eindpunt nog niet bereikt. De kosten van een gedwongen spoedmigratie na een kwantumincident overtreffen ruimschoots de planmatige transitiekosten.
Praktisch gezien kunnen organisaties de dubbele kosten beperken door hybride certificaten te introduceren op het moment dat systemen toch worden vernieuwd, en door CA-contracten te sluiten die PQC-uitgifte al inbegrepen hebben, zodat er geen extra uitgifte-kosten komen bij de definitieve overstap.
“The migration to post-quantum cryptography will be one of the most complex and far-reaching cryptographic transitions ever undertaken. Early planning and crypto-agility are essential.” — Dustin Moody, projectleider Post-Quantum Cryptography, NIST
Aanbevelingen voor beperkt updatebare systemen
IoT-apparaten, industriële besturingssystemen (OT/ICS) en smartcards vormen de hardste uitdaging bij PKI-migratie. Deze systemen hebben doorgaans vaste firmware, beperkt geheugen en lange levenscycli van tien tot twintig jaar. ML-DSA vereist aanzienlijk meer rekenkracht en geheugen dan RSA of ECDSA, wat implementatie op resource-beperkte hardware bemoeilijkt.
De aanbevelingen voor dit segment zijn concreet:
- Voer een inventarisatie uit van alle systemen met ingebedde certificaten, inclusief de algoritmeconfiguratie en de vervaldatum van de huidige certificaten.
- Raadpleeg fabrikanten over de beschikbaarheid van firmware-updates met PQC-ondersteuning. Voor smartcards geldt dat hardware-revisies doorgaans de enige weg zijn.
- Gebruik het dubbele-certificaat-model aan de serverzijde zodat de server moderne clients PQC kan aanbieden zonder de klassieke authenticatie van legacy-apparaten te breken.
- Plan vervanging van niet-updatebare apparaten in lijn met de reguliere vervangingscycli, maar versneld als het kwantumrisico-tijdlijn dat vereist volgens NIST IR 8547.
- Overweeg voor gesloten OT-netwerken een netwerksegmentatie-aanpak waarbij klassieke interne communicatie wordt geïsoleerd van externe PQC-verbindingen.
IETF-specificaties en FIPS-conformiteit voor overheden
De IETF-conceptspecificatie draft-yusef-tls-pqt-dual-certs beschrijft hoe een TLS 1.3-server twee certificaten aanbiedt via een uitbreiding op het CertificateRequest– en Certificate-mechanisme. De client selecteert het certificaat op basis van de algoritmen die het ondersteunt. Dit is een pragmatische oplossing die geen wijzigingen vereist in de kern van TLS 1.3, maar wel implementatie-specifieke serverlogica.
Voor overheidsorganisaties die FIPS-conform moeten zijn, geldt een extra laag complexiteit. FIPS 204 (ML-DSA) is door NIST vastgesteld als standaard, maar de FIPS 140-3 validatie van cryptografische modules die ML-DSA implementeren, loopt nog voor de meeste leveranciers. Dit betekent dat overheidsorganisaties in een tijdelijk spanningsveld zitten: NIST beveelt de overgang aan, maar de gevalideerde modules zijn nog niet breed beschikbaar. ETSI CYBER QSC geeft aanvullende richtlijnen voor Europese overheidsomgevingen die zowel FIPS als Europese normen moeten combineren.
“Organisations should not wait for a perfect post-quantum solution before acting. A hybrid approach using both classical and post-quantum algorithms provides a pragmatic path that maintains backwards compatibility while building quantum resilience.” — ETSI CYBER QSC Working Group
De praktische aanbeveling voor FIPS-plichtige organisaties is: implementeer hybride sleuteluitwisseling (zoals X25519 gecombineerd met ML-KEM) op transportlaagniveau nu al, en wacht met de volledige vervanging van authenticatiecertificaten tot FIPS 140-3 gevalideerde ML-DSA-modules beschikbaar zijn van uw leverancier.
Vertrouwensankers vernieuwen: tijdlijn en stappen
Het vernieuwen van root CA’s is het meest ingrijpende onderdeel van de PQC-migratie. Vertrouwensankers hebben looptijden van tien tot twintig jaar en moeten in alle relevante trust stores worden opgenomen: besturingssystemen, browsers, Java-runtimes, embedded systemen en organisatie-interne PKI-clients.
Een realistisch stappenplan ziet er als volgt uit:
- Jaar 1: Genereer een nieuwe PQC root CA (ML-DSA conform FIPS 204 en de X.509 PQC-certificaatprofielen van draft-ietf-lamps-dilithium-certificates). Begin de indiening bij grote trust store-programma’s (Mozilla, Microsoft, Apple, Google).
- Jaar 1-3: Propageer de nieuwe root naar interne systemen via Group Policy, MDM of configuratiebeheer. Geef tussentijdse sub-CA’s en eindentiteitscertificaten uit onder zowel de klassieke als de nieuwe PQC root.
- Jaar 2-4: Wacht op opname in externe trust stores. Dit proces duurt gemiddeld twee tot vier jaar na indiening en is afhankelijk van het auditproces van de trust store-beheerder.
- Jaar 4-6: Faseer de klassieke root gefaseerd uit zodra alle kritieke clientsystemen de PQC root vertrouwen. Intrek niet eerder dan nadat u heeft geverifieerd dat er geen productiesystemen meer afhankelijk zijn van de klassieke keten.
Volgens ENISA heeft meer dan 40 procent van de kritieke infrastructuurorganisaties in de EU in 2023 nog geen formele inventarisatie gemaakt van hun cryptografische afhankelijkheden (ENISA Threat Landscape 2023). Zonder die inventarisatie is stap 1 niet uitvoerbaar: u kunt geen nieuwe root vertrouwen propageren als u niet weet welke systemen de huidige root gebruiken.
NIST IR 8547 schat dat cryptografisch relevante kwantumcomputers binnen tien tot vijftien jaar operationeel kunnen zijn. Dat klinkt ruim, maar gezien de gemiddelde doorlooptijd van vijf tot zes jaar voor een volledige root CA-vervanging is er feitelijk nauwelijks marge voor verdere vertraging.
FAQ
Kan een organisatie direct overstappen naar PQC-only certificaten zonder een hybride tussenstap?
Dat is technisch mogelijk maar in de praktijk weinig verstandig. PQC-only certificaten zijn niet interoperabel met TLS-clients en systemen die nog geen PQC ondersteunen. Voor omgevingen waar alle eindpunten volledig beheerbaar zijn, kan een directe overgang worden overwogen. In gemengde omgevingen met legacy-clients, IoT-apparaten of externe partijen is een hybride model via dubbele of composiet-certificaten de enige werkbare route.
Wat is het grootste verschil tussen een composiet-certificaat en een dubbel-certificaat bij TLS 1.3?
Een composiet-certificaat bevat één gecombineerde publieke sleutel in één X.509-structuur. Een dubbel-certificaat houdt twee afzonderlijke certificaten in omloop. De TLS 1.3-server biedt afhankelijk van de clientcapaciteit het juiste certificaat aan. Composiet-certificaten vereisen aanpassing van de CA-software; dubbele certificaten plaatsen de complexiteit bij de serverbeheerder.
Vallen post-quantum hybride certificaten al onder FIPS 140-3 validatie?
FIPS 204 (ML-DSA) is vastgesteld door NIST, maar de FIPS 140-3 validatie van modules die ML-DSA implementeren, loopt nog voor de meeste leveranciers. Overheidsorganisaties dienen de CMVP-database van NIST te raadplegen voor de actuele validatiestatus van specifieke bibliotheken en hardware security modules.
Hoe lang duurt het realistisch om een root CA te vervangen door een PQC-veilige variant?
Het opnemen van een nieuwe PQC root CA in externe trust stores duurt gemiddeld twee tot vier jaar na indiening. Samen met de voorbereiding en de uitfasering van de klassieke root loopt de totale doorlooptijd op tot vijf à zes jaar. Voor interne PKI-infrastructuren is dat sneller, maar ook daar moet de nieuwe root volledig zijn gepropageerd voordat de klassieke root kan worden ingetrokken.
Welke aanbeveling geldt voor smartcards en hardware security tokens bij de PQC-migratie?
Controleer bij de fabrikant of firmware-updates met PQC-ondersteuning beschikbaar zijn. Als dat niet het geval is, plan dan een vervangingscyclus in die samenvalt met de reguliere levensduurplanning. Gebruik in de tussentijd het dubbele-certificaat-model zodat de server PQC kan aanbieden aan moderne clients zonder de smartcard-authenticatie te breken voor gebruikers met legacy-hardware.
