Post-Quantum Ready PKIaaS: Checklist voor kopersevaluatie

Elke PKIaaS-aanbieder heeft zijn marketing bijgewerkt met termen als 'post-quantum ready' en 'crypto-agile'. Deze termen beschrijven belangrijke mogelijkheden, maar ze vertellen je niet of de aanbieder daadwerkelijk vandaag de dag ML-DSA-certificaten kan uitgeven, of hun ACME-endpoint de grotere certificaatformaten aankan die post-quantum-algoritmen produceren, of hun HSM's zijn gevalideerd voor ML-DSA-sleutelbewerkingen, of dat hun CA-sleutelmigratieservice een formele PQC-root-CA-sleutelceremonie omvat. Marketingtaal en daadwerkelijke productiemogelijkheden zijn niet hetzelfde.

Deze checklist biedt beveiligingsarchitecten, PKI-programma-eigenaren en inkoopteams de specifieke vragen die ze moeten stellen bij het evalueren van een PKIaaS-provider op gereedheid voor de post-quantum-revolutie. De checklist is onderverdeeld in acht evaluatiecategorieën. Voor elke categorie identificeren de vragen het verschil tussen een provider die daadwerkelijk voorbereid is op PQC-migratie en een provider die een roadmap beschrijft alsof het een huidige functionaliteit betreft. De afschaffing van RSA en ECC voor nieuwe toepassingen volgens NIST IR 8547 wordt rond 2030 verwacht. PKI-migraties binnen een organisatie duren 24 tot 48 maanden. De evaluatie die u nu uitvoert, bepaalt of uw organisatie de PQC-migratie ruim vóór die deadline kan voltooien of juist onder druk erna.

Kort antwoord: Wat maakt een PKIaaS-aanbieder klaar voor het post-kwantumtijdperk?

Een post-quantum-ready PKIaaS-provider kan vandaag de dag acht dingen in een productieomgeving doen: ontdekken welke algoritmen momenteel in gebruik zijn binnen uw certificaatportfolio; abonneecertificaten uitgeven die zijn ondertekend met ML-DSA (FIPS 204); hybride/samengestelde certificaten uitgeven die ECDSA en ML-DSA combineren in één X.509-certificaat; ML-DSA CA-ondertekeningssleutels genereren en een nieuwe PQC CA-hiërarchie inrichten; certificaatprofielen bijwerken om het ondertekeningsalgoritme te wijzigen zonder de CA-infrastructuur te vervangen; PQC-certificaatinschrijving ondersteunen via ACME-, EST- en CMP-eindpunten; een distributiestrategie voor de PQC-root CA-vertrouwensarchief aanbieden voor de overgangsperiode naar twee algoritmen; en richtlijnen voor compatibiliteit met relying parties bieden voor systemen die moeten worden bijgewerkt om ML-DSA-certificaten te verifiëren. Als een provider minder dan acht van deze mogelijkheden biedt, vormen de ontbrekende functionaliteiten een migratierisico dat uw organisatie zal moeten dragen.

Key Takeaways

• NIST heeft in augustus 2024 drie post-kwantumcryptografiestandaarden afgerond: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA). Voor het ondertekenen van PKI-certificaten is ML-DSA (FIPS 204) de belangrijkste migratiedoelstelling. Een PKIaaS-aanbieder die de uitgifte van ML-DSA-certificaten in een productieomgeving niet ondersteunt, is niet klaar voor het post-kwantumtijdperk, ongeacht wat hun marketingmateriaal beweert.
• Cryptografische schuld is het verschil tussen de algoritmen die u gebruikt en de algoritmen die u kunt verantwoorden. Voordat een PKI-migratie kan worden gepland, moet de organisatie weten welke certificaten welke algoritmen gebruiken, welke CA's welke algoritmetypen uitgeven en welke vertrouwende partijen ML-DSA-certificaten kunnen verifiëren. Vraag elke PKIaaS-aanbieder hoe hun platform cryptografische inventarisatie en CBOM-generatie ondersteunt.
• De afschaffing van RSA en ECC voor nieuwe toepassingen volgens NIST IR 8547 wordt rond 2030 verwacht; de definitieve uitsluiting vindt rond 2035 plaats. PKI-migraties binnen bedrijven duren 24 tot 48 maanden. Organisaties die nu met de evaluatie beginnen, bevinden zich op het juiste moment in het tijdschema voor een methodische migratie; organisaties die de migratie uitstellen, verkorten hun migratieperiode en belanden in een noodsituatie.
• Hybride/samengestelde certificaten vormen de praktische overbrugging voor de overgangsperiode. Ze stellen de organisatie in staat om PQC-certificaten te implementeren voordat alle vertrouwende partijen ML-DSA-verificatie ondersteunen. Vraag specifiek of de provider samengestelde certificaten ondersteunt die voldoen aan de conceptspecificaties van de IETF LAMPS-werkgroep, en of ondersteuning voor samengestelde certificaten beschikbaar is voor CA-certificaten en abonneecertificaten.
• Productiegereedheid is belangrijker dan beloftes in de roadmap. Vraag of de uitgifte van ML-DSA-certificaten onder de productie-SLA van de provider valt, of de HSM's die de ML-DSA CA-ondertekeningssleutels bevatten, gevalideerd zijn voor ML-DSA-bewerkingen en of de intrekking van ML-DSA-certificaten en OCSP door de productie-infrastructuur worden afgehandeld. Een label als "beta" of "preview" betekent dat de functionaliteit nog niet in productie is.

Waarom de timing van deze evaluatie belangrijk is

De HNDL-aanvalsstrategie (Harvest Now, Decrypt Later), waarbij tegenstanders vandaag versleuteld verkeer verzamelen om het in de toekomst door een kwantumcomputer te laten decoderen, betekent dat de PQC-migratie niet alleen draait om de voorbereiding op een toekomstige compliance-deadline. Het gaat erom het risico op retrospectieve decodering van gegevens die nu worden verzonden te verminderen. Organisaties die gegevens verwerken met lange geheimhoudingsverplichtingen (records die tientallen jaren worden bewaard, geclassificeerde overheidsinformatie, financiële gegevens met een lange termijn) zouden de PQC-migratie moeten beschouwen als een actief risicomanagementprogramma in plaats van een toekomstig complianceproject.

De NIST IR 8547-tijdlijn (RSA en ECC worden rond 2030 afgekeurd voor nieuw gebruik en rond 2035 niet meer toegestaan) stelt de deadline voor naleving vast. De tijdlijn voor de programma-uitvoering (24 tot 48 maanden voor PKI-migratie op bedrijfsniveau voor alle certificaattypen en vertrouwende partijen) bepaalt de startdatum. Voor de meeste organisaties was 2026 of 2027 een comfortabele startdatum. De evaluatie van de PKIaaS-provider is de cruciale eerste stap: als de geselecteerde provider niet daadwerkelijk PQC-certificaten kan uitgeven of CA-sleutels kan migreren wanneer dat nodig is, is de migratietijdlijn van de organisatie afhankelijk van de roadmap van de provider.

Categorie 1: Cryptografische inventarisatie en ontdekking

Een PQC-migratie die begint zonder cryptografische inventarisatie leidt tot het missen van certificaten, verrassingen voor vertrouwende partijen en het niet halen van de uitfaseringsdeadline van 2030 voor sommige certificaatcategorieën. De cryptografische inventarisatie laat de organisatie zien waarvan ze migreert.

• Beschikt het PKIaaS-platform over een ingebouwde cryptografische ontdekkingsfunctie, of integreert het met een externe CBOM-tool? Kan het platform concreet een inventaris genereren van alle actieve certificaten, inclusief het ondertekeningsalgoritme, de sleutelgrootte, de uitgevende certificeringsinstantie (CA) en het certificaattype voor elk certificaat in de betreffende omgeving? Zonder deze gegevens is het bepalen van de migratieprioriteit giswerk;
• Kan het platform certificaten identificeren die zijn uitgegeven door certificeringsinstanties buiten de PKIaaS-hiërarchie (zelfondertekende certificeringsinstanties, traditionele on-premises certificeringsinstanties, certificeringsinstanties van cloudproviders)? Een volledige cryptografische inventaris omvat alle certificaten in de omgeving, niet alleen de certificaten die door het PKIaaS-platform zijn uitgegeven. Certificaten van niet-beheerde certificeringsinstanties (CA's) vormen de items met het hoogste risico in de inventaris, omdat ze geen automatische verlenging of governance kennen.
• Houdt het platform het algoritmegebruik in de loop van de tijd bij, zodat de voortgang van de migratie kan worden gemeten? De migratievoortgangsstatistieken die in de NIST-richtlijnen worden beschreven (percentage actieve certificaten die gebruikmaken van klassieke versus PQC-algoritmen, percentage certificaattypen met ML-DSA-compatibele profielen) vereisen longitudinale gegevens, niet slechts een momentopname;
• Kan de cryptografische inventaris worden geëxporteerd in CycloneDX CBOM-formaat? CycloneDX is de opkomende standaard voor cryptografische stuklijsten (Bills of Materials). Exporteren in dit formaat maakt het mogelijk dat de CBOM door downstream-tools (SIEM, kwetsbaarheidsbeheer, risicokwantificatie) kan worden gebruikt zonder formaatconversie.

Categorie 2: Ondersteuning bij de uitgifte van ML-DSA-certificaten

ML-DSA (FIPS 204) is het belangrijkste digitale handtekeningalgoritme van na het kwantumtijdperk voor het ondertekenen van PKI-certificaten. Een provider die beweert PQC-gereed te zijn, moet de uitgifte van ML-DSA-certificaten in een productieomgeving ondersteunen.

• Ondersteunt het platform het uitgeven van abonnementscertificaten die zijn ondertekend met ML-DSA CA-sleutels? Dit is de basisfunctionaliteit. Zonder deze functionaliteit kan het platform geen post-quantumcertificaten uitgeven, ongeacht andere functies.
• Welke ML-DSA-parameterreeksen worden ondersteund? De drie parameterreeksen zijn ML-DSA-44 (beveiligingscategorie 2), ML-DSA-65 (categorie 3, ongeveer gelijk aan AES-192-beveiliging) en ML-DSA-87 (categorie 5, vereist voor TOP SECRET-systemen onder CNSA 2.0). Organisaties die onder CNSA 2.0 vallen, hebben ML-DSA-87 nodig; voor de meeste bedrijfsomgevingen volstaat ML-DSA-65.
• Valt de uitgifte van ML-DSA-certificaten onder de productie-SLA van de provider, of is het een preview- of bètaversie? 'Preview' of 'beta' betekent dat de functionaliteit niet onderworpen is aan dezelfde beschikbaarheid, sleutelbeveiliging en auditregistratie als de klassieke algoritmefunctionaliteiten van de provider. Baseer uw migratieplan niet op previewfunctionaliteit;
• Worden ML-DSA-certificaten ondersteund voor alle certificaattypen die het platform uitgeeft, of alleen voor TLS-abonneecertificaten? De migratie moet uiteindelijk gebruikersauthenticatiecertificaten, S/MIME-certificaten, codeondertekeningscertificaten en apparaatidentiteitscertificaten omvatten, en niet alleen TLS-servercertificaten. Vraag de leverancier naar de productieondersteuningsmatrix voor alle certificaattypen;
• Ondertekent de certificeringsinstantie van de provider zelf met ML-DSA-sleutels, of ondertekent deze ML-DSA-abonneecertificaten met een klassieke CA-ondertekeningssleutel? Een ML-DSA-abonneecertificaat, ondertekend met een klassieke (RSA of ECDSA) CA-sleutel, produceert een hybride keten die niet volledig post-quantum is. Volledige PQC-migratie vereist ML-DSA CA-ondertekeningssleutels op elk niveau van de hiërarchie.

Categorie 3: Ondersteuning voor hybride en samengestelde certificaten

Hybride en samengestelde certificaten vormen de praktische oplossing voor organisaties die niet gelijktijdig alle vertrouwende partijen kunnen bijwerken om ML-DSA-verificatie te ondersteunen. Stel de volgende vragen om de mogelijkheden van de aanbieder met betrekking tot samengestelde certificaten te beoordelen.

• Ondersteunt het platform het uitgeven van samengestelde certificaten die ECDSA en ML-DSA combineren in één X.509-certificaat? Ondersteuning voor samengestelde certificaten vereist dat de CA-software en HSM-firmware beide algoritmesleutels genereren en opslaan en beide handtekeningen produceren in één enkele ondertekeningsbewerking. Niet alle platforms die beweren samengestelde certificaten te ondersteunen, hebben dit op CA-sleutelniveau geïmplementeerd;
• Welke ontwerpspecificaties van de IETF LAMPS-werkgroep volgt de samengestelde implementatie? De IETF LAMPS-werkgroep is de standaardisatie-instantie die specificaties ontwikkelt voor samengestelde publieke sleutel- en handtekeningalgoritmen. Implementaties die de conceptspecificaties volgen, zullen interoperabel zijn met andere implementaties die dezelfde specificaties volgen; propriëtaire samengestelde implementaties zijn dat mogelijk niet.
• Is ondersteuning voor samengestelde certificaten beschikbaar voor CA-certificaten en uitgevende CA-certificaten, of alleen voor abonneecertificaten? Een samengesteld abonnementscertificaat onder een CA die alleen klassieke certificaten gebruikt, heeft nog steeds een gedeeltelijk klassieke vertrouwensketen. Volledige migratie naar een samengesteld certificaat vereist ook samengestelde CA-certificaten op het niveau van de intermediaire CA en de uitgevende CA.
• Wat zijn de richtlijnen van de aanbieder met betrekking tot de geldigheidsperioden van samengestelde certificaten en de criteria voor de overgang van samengestelde naar pure ML-DSA-profielen? Samengestelde certificaten zijn een overgangsmechanisme. De aanbieder moet een duidelijke aanbeveling hebben voor wanneer samengestelde certificaten geschikt zijn en wanneer de overstap naar pure ML-DSA gerechtvaardigd is, gebaseerd op een compatibiliteitsbeoordeling van de vertrouwende partij.

Categorie 4: CA-sleutelmigratie en root-CA-strategie

Migreren naar een post-quantum CA-hiërarchie vereist het genereren van nieuwe ML-DSA CA-ondertekeningssleutels, het uitvoeren van een nieuwe root CA-sleutelceremonie, het inrichten van ML-DSA intermediaire en uitgevende CA's, en het beheren van de periode met dubbele vertrouwensopslag waarin zowel de klassieke als de PQC CA-hiërarchieën actief zijn. Dit is complexer dan het wijzigen van een certificaatprofiel.

• Biedt de aanbieder een begeleide ML-DSA CA-sleutelmigratieservice aan, inclusief een formele PQC-root-CA-sleutelceremonie? De sleutelceremonie van de root-CA is een beveiligingskritische gebeurtenis die met de juiste controles moet worden uitgevoerd (door HSM ondersteunde sleutelgeneratie, M-van-N-sleutelbeheer, auditgetuigen). Vraag of de migratieservice van de provider de planning, uitvoering en documentatie van de ceremonie omvat;
• Hoe gaat de aanbieder om met de overgangsperiode naar een dubbele hiërarchie, waarin zowel de klassieke als de ML-DSA CA-hiërarchieën actief zijn? Tijdens de overgang moet de organisatie klassieke certificaten uit de klassieke CA-hiërarchie uitgeven voor vertrouwende partijen die nog geen ML-DSA ondersteunen, en ML-DSA- of samengestelde certificaten uit de nieuwe PQC-hiërarchie voor vertrouwende partijen die dat wel doen. Vraag hoe het beheerplatform van de provider deze parallelle bewerking afhandelt;
• Biedt de provider een PQC-root-CA aan waar de organisatie zich aan kan koppelen, of moet de organisatie zelf een PQC-root-CA genereren en beheren? Organisaties die niet over de operationele capaciteit beschikken om een ​​root CA-sleutelceremonie uit te voeren, geven er wellicht de voorkeur aan om tijdens de overgangsperiode gebruik te maken van de PQC-root CA van de provider. Informeer of dit mogelijk is en onder welk vertrouwensmodel;
• Hoe ondersteunt de provider de distributie van het nieuwe ML-DSA root CA-certificaat naar vertrouwensarchieven van de relying parties? Het ML-DSA-rootcertificaat moet worden opgenomen in de vertrouwensarchief van het besturingssysteem, de browser en de applicatie, voordat ML-DSA-certificaatketens kunnen worden geverifieerd. Vraag de leverancier of er een gedocumenteerd plan en tools beschikbaar zijn voor de distributie van het vertrouwensarchief naar de vertrouwende systemen in uw omgeving.

Categorie 5: Profielupdates en algoritme-flexibiliteit

De kerntest voor een crypto-flexibel PKIaaS-platform is of de migratie van een klassiek algoritme naar ML-DSA een wijziging in de profielconfiguratie is of een infrastructuurproject. Stel jezelf de volgende vragen om onderscheid te maken tussen beide.

• Vereist het wijzigen van het handtekeningalgoritme voor een certificaattype alleen een aanpassing van de certificaatprofielconfiguratie, of zijn er ook CA-software-updates, HSM-firmware-upgrades of een herimplementatie van het platform nodig? Een echt crypto-agile platform wijzigt de algoritmekeuze via profielconfiguratie. Een platform dat infrastructuurwijzigingen vereist om elk nieuw algoritme te ondersteunen, is niet crypto-agile; het is handmatig uitbreidbaar, wat een ander en trager proces is.
• Kunnen ML-DSA-certificaatprofielen worden aangemaakt en gewijzigd via de standaard beheerinterface (console en REST API) door de CA-beheerder van de klant, of moet het ondersteuningsteam van de provider dit doen? Het aanmaken van profielen door de klant is het juiste model. Profielen die door de provider worden aangemaakt, introduceren een wachtrij voor ondersteuning in het migratieproces.
• Ondersteunt de provider de implementatie van beleids-als-code-implementatie van profielwijzigingen via de PKIaaS REST API? Organisaties die PKIaaS-configuratie als code beheren (profieldefinities in versiebeheerde repositories, geïmplementeerd via een CI/CD-pipeline) hebben een REST API nodig die alle profielbewerkingen ondersteunt. Vraag of ML-DSA-profielparameters via dezelfde REST API beschikbaar worden gesteld als klassieke algoritmeprofielen;
• Hoe pakt de aanbieder de overgang van samengestelde profielen naar pure ML-DSA-profielen aan? De migratie van een samengesteld profiel (ECDSA + ML-DSA) naar een puur ML-DSA-profiel is een tweede profielupdate die plaatsvindt na de eerste (klassiek naar samengesteld). Vraag of beide overgangen beheerd kunnen worden als profielconfiguratiewijzigingen via de standaard beheerinterface.

Categorie 6: Geautomatiseerde PQC-inschrijving

PQC-certificaten zijn groter dan klassieke certificaten. ML-DSA-65 genereert een publieke sleutel van 1,952 bytes en een handtekening van 3,309 bytes, vergeleken met een ECDSA P-256 publieke sleutel van 65 bytes en een handtekening van 72 bytes. Dit verschil in grootte heeft gevolgen voor registratieprotocollen en automatiseringsclients die mogelijk buffergroottes of time-outconfiguraties hebben die zijn afgestemd op klassieke certificaten.

• Ondersteunen de ACME-, EST-, CMP- en SCEP-eindpunten van de provider het registreren en verlengen van PQC-certificaten zonder dat er protocolconfiguratiewijzigingen aan de clientzijde nodig zijn? Vraag specifiek of het ACME-eindpunt CSR's verwerkt die ML-DSA-publieke sleutels bevatten (die groter zijn dan klassieke publieke sleutels) en of het ML-DSA-ondertekende certificaten retourneert zonder de standaard ACME-clientconfiguratie aan te passen;
• Heeft de aanbieder zijn inschrijvings-endpoints getest met gangbare ACME-clients (cert-manager, certbot, acme.sh) voor ML-DSA- en samengestelde certificaatinschrijving? Vraag om testresultaten of klantreferenties voor elk inschrijvingsprotocol dat de aanbieder claimt ter ondersteuning van PQC-certificaten;
• Ondersteunt de cert-manager ClusterIssuer- of CA Gateway-integratie van de provider het aanvragen van ML-DSA- of samengestelde certificaten vanuit Kubernetes-native automatisering? Kubernetes is voor de meeste cloud-native organisaties de omgeving met het grootste volume aan machinecertificaten. Als de cert-manager-integratie geen ondersteuning biedt voor PQC-certificaatinschrijving, kan de migratie van de Kubernetes-machine-identiteit niet via de standaard platformautomatisering verlopen.
• Houdt de CLM-laag van de provider de verlenging van PQC-certificaten apart bij van de verlenging van klassieke certificaten, en kan deze statistieken genereren over de voortgang van de migratie (percentage actieve certificaten dat ML-DSA of samengesteld is versus alleen klassieke certificaten)? Voor het meten van de voortgang van de migratie moet het CLM-systeem niet alleen de vervaldatum van het certificaat, maar ook het type algoritme begrijpen en rapporteren.

Categorie 7: Compatibiliteit van de applicatie en de vertrouwende partij

Het uitgeven van ML-DSA-certificaten door een PKIaaS-platform dat geschikt is voor post-quantum computing is slechts de helft van de migratie. De andere helft bestaat uit het ervoor zorgen dat de systemen die deze certificaten verifiëren (RADIUS-servers, VPN-gateways, TLS-stacks voor browsers, e-mailclients, smartcardmiddleware, MDM-platforms, loadbalancers en applicatieframeworks) in staat zijn om ML-DSA-handtekeningen te verifiëren. Dit valt buiten de directe controle van de PKIaaS-provider, maar het is wel binnen hun expertisegebied om hierover advies te geven.

• Houdt de aanbieder een gepubliceerde compatibiliteitsmatrix bij voor ML-DSA en samengestelde certificaatverificatie voor veelgebruikte vertrouwende partijsystemen? De matrix moet minimaal de volgende onderdelen omvatten: de belangrijkste TLS-stacks van besturingssystemen (OpenSSL, BoringSSL, SChannel, Secure Transport), TLS in browsers (naarmate browsers worden bijgewerkt), VPN-gatewayproducten, RADIUS-serverproducten, smartcardmiddleware en e-mailclients (Outlook, Apple Mail). Vraag naar de meest recente versie van deze matrix en hoe vaak deze wordt bijgewerkt.
• Biedt de aanbieder diensten of tools voor compatibiliteitstesten voorafgaand aan de migratie, waarmee de organisatie de ML-DSA-certificaatverificatie in haar specifieke omgeving kan testen? Algemene compatibiliteitsmatrixgegevens zijn nuttig voor een eerste beoordeling; omgevingsspecifieke compatibiliteitstests zijn vereist voordat productiecertificaattypen worden gemigreerd;
• Wat is het advies van de provider voor het omgaan met vertrouwende partijsystemen die geen ML-DSA-verificatie ondersteunen binnen de migratietijdlijn van de organisatie? Sommige verouderde systemen zullen mogelijk nooit worden bijgewerkt om ML-DSA te ondersteunen. De provider moet een gedocumenteerde aanpak hebben voor deze systemen (voortzetting van de klassieke certificaatuitgifte vanuit de klassieke CA-hiërarchie, samengestelde certificaten voor gedeeltelijke compatibiliteit of geplande systeemvervanging);
• Ondersteunt de HSM van de provider ML-DSA-sleutelbewerkingen, en wat is het specifieke HSM-model en de firmwareversie? Deze vraag is van toepassing op zowel de HSM's die de provider gebruikt voor CA-ondertekeningssleutels als op klantgerichte HSM's die de privésleutels van abonnees opslaan voor certificaattypen met hoge betrouwbaarheid (aanmelden met smartcard, codeondertekening). Een HSM die niet is bijgewerkt om ML-DSA te ondersteunen, kan niet worden gebruikt om ML-DSA-privésleutels te genereren of op te slaan.

Categorie 8: Migratieplanning en adviesondersteuning

PQC-migratie is een meerjarig programma. Stel de volgende vragen om te beoordelen of de leverancier de advies- en planningsondersteuning biedt die een bedrijfsbrede migratie vereist, of dat ze alleen het technische platform leveren en de migratieplanning aan de klant overlaten.

• Biedt de aanbieder een gestructureerde PQC-migratiebeoordelingsservice aan die het huidige certificatenportfolio van de klant evalueert en een migratieprioriteit en -routekaart opstelt? Bij de beoordeling moet gebruik worden gemaakt van de cryptografische inventarisgegevens om prioriteit te geven aan certificaattypen voor migratie op basis van de gereedheid van de vertrouwende partij voor updates, de geldigheidsperiode van het certificaat en de gevoeligheid van de gegevens;
• Heeft de aanbieder gedocumenteerde richtlijnen voor de volgorde van de migratiestappen van de CA-sleutel (van root naar intermediate naar issuing CA) en de overgangsperiode naar een dubbele hiërarchie? Klanten die een CA-hiërarchie met meerdere niveaus migreren, hebben behoefte aan begeleiding bij de juiste migratievolgorde. Het migreren van de uitgevende CA-sleutels vóór de root-CA-sleutels leidt tot een inconsistente hiërarchie die niet correct kan worden geverifieerd;
• Biedt de aanbieder ondersteuning bij de migratieplanning naar CNSA 2.0 voor organisaties die nationale veiligheidssystemen beheren of onder de richtlijnen van de NSA vallen? CNSA 2.0 specificeert ML-DSA-87 en ML-KEM-1024 en hanteert ambitieuzere tijdlijnen dan de algemene NIST IR 8547-richtlijnen. Defensieaannemers en -instanties die met geclassificeerde systemen werken, hebben een leverancier nodig die de CNSA 2.0-vereisten begrijpt en kan ondersteunen.
• Wat is de toezegging van de aanbieder met betrekking tot algoritmevaluta? Wanneer NIST updates publiceert voor PQC-standaarden, wanneer de FIPS 204- of 205-richtlijnen voor parameterinstellingen worden bijgewerkt, of wanneer nieuwe post-kwantumalgoritmen worden gestandaardiseerd, hoe snel zal de aanbieder zijn platform bijwerken om de wijzigingen te ondersteunen? Vraag naar de staat van dienst van de aanbieder met betrekking tot het toevoegen van algoritmeondersteuning en of ze een gepubliceerde roadmap voor algoritmen hebben.

Deze checklist gebruiken om de antwoorden van de zorgverleners te beoordelen.

Bij het beoordelen van de antwoorden van zorgverleners aan de hand van deze checklist, dient onderscheid te worden gemaakt tussen drie soorten antwoorden:

• Over het algemeen beschikbaar in productie: De functionaliteit valt onder de productie-SLA van de provider, is beschikbaar voor alle klanten via de standaard beheerinterface en wordt ondersteund door dezelfde infrastructuur voor sleutelbescherming, auditregistratie en intrekking als klassieke algoritmefunctionaliteiten. Dit is het enige responstype dat het opstellen van een migratieplan voor deze functionaliteit ondersteunt;
• Voorvertoning, bèta of beperkte beschikbaarheid: De functionaliteit bestaat wel, maar wordt niet in productie gebruikt. Het opstellen van een migratieplan op basis van previewfunctionaliteit betekent dat het plan afhankelijk is van de leverancier die zijn eigen roadmap volgens schema voltooit, wat een afhankelijkheid creëert waar de klant geen controle over heeft.
• Op de routekaart: De functionaliteit bestaat momenteel niet. De leverancier is van plan deze te ontwikkelen. Een toezegging in de roadmap is geen garantie voor een productieklare functionaliteit. Organisaties met een migratiedeadline in 2028 of 2029 kunnen het zich niet veroorloven om een ​​leverancier te kiezen die de benodigde functionaliteiten pas in 2027 belooft.

Voor elk van de acht evaluatiecategorieën moet de organisatie antwoorden krijgen met "algemeen beschikbaar in productie" voordat een leverancier wordt geselecteerd voor een PQC-migratieprogramma. Categorieën waarbij de leverancier antwoordt met "preview" of "op de roadmap" duiden op lacunes die de organisatie moet accepteren (met een gedocumenteerde risicobeslissing) of moet aanpakken door een leverancier te selecteren die momenteel over de benodigde productiecapaciteit beschikt.

Hoe encryptieconsultancy kan helpen

• PQC-adviesdiensten: Encryptie Consulting's PQC Adviesdiensten Inclusief PKIaaS-providerevaluatie op PQC-gereedheid: gestructureerde beoordeling van de reacties van de provider aan de hand van de bovenstaande checklistcategorieën, gap-analyse om vast te stellen welke mogelijkheden ontbreken of in ontwikkeling zijn, en risicokwantificatie voor het doorgaan met een provider wiens PQC-ondersteuning tekortkomingen vertoont. Neem contact met ons op via Encryptie Consulting een gestructureerde PKIaaS PQC-gereedheidsevaluatie uitvoeren.
• CBOM Secure: Encryptie Consulting's CBOM Secure Dit sluit direct aan op Categorie 1 (Cryptografische inventarisatie en ontdekking): geautomatiseerde cryptografische ontdekking in het netwerk en de infrastructuur van de organisatie, algoritmeclassificatie voor elk certificaat (RSA, ECDSA, algoritmefamilie, sleutelgrootte), CBOM-generatie in CycloneDX-formaat en continue updates van de inventaris. De CBOM-output dient als input voor het PKIaaS PQC-migratieplanningsproces en levert de migratieprioriteitsgegevens die providers nodig hebben om een ​​zinvolle routekaart op te stellen.
• PKI als een service: Encryptie Consulting's PKIaaS-aanbod Het behandelt de vereisten voor productiegereedheid van de evaluatiechecklist: ondersteuning voor ML-DSA (FIPS 204) certificaatprofielen, uitgifte van samengestelde/hybride certificaten voor de overgangsperiode, CA-sleutelmigratieservices inclusief planning van de ML-DSA root CA-sleutelceremonie, ACME- en EST-eindpunten die geschikt zijn voor PQC-certificaatregistratie en algoritmebeheer op profielniveau zonder vervanging van de infrastructuur. Encryption Consulting kan tijdens een gestructureerde evaluatiesessie ook elk van de acht checklistcategorieën voor ons eigen platform met u doornemen.
• PKI-diensten (migratieplanning): Encryptie Consulting's PKI-diensten Dit omvat de planning voor de sleutelmigratie van PQC CA's: het ontwerpen van de migratievolgorde (van root naar intermediair naar uitgevende CA), het beheer van de overgangsperiode met dubbele hiërarchie, de planning van de distributie van vertrouwensarchieven voor ML-DSA root CA-certificaten, de afstemming op CNSA 2.0 voor organisaties met verplichtingen op het gebied van nationale veiligheidssystemen en het ontwerpen van een samengesteld certificaatprofiel voor de overgangsperiode.
• PQC-expertisecentrum: Organisaties die behoefte hebben aan op onderzoek gebaseerd advies over IETF LAMPS-specificaties voor samengestelde certificaten, de interpretatie van de NIST IR 8547-conformiteit, de CNSA 2.0-vereisten of de compatibiliteitsstatus van ML-DSA-vertrouwenspartijen voor specifieke systemen, kunnen terecht bij Encryption Consulting. PQC Centrum van Uitmuntendheid Biedt directe toegang tot deskundige specialisten op het gebied van post-kwantumcryptografie die deze standaarden als primaire bronnen volgen.

Conclusie

Het verschil tussen een PKIaaS-provider die klaar is voor de post-quantum-revolutie en een provider met een post-quantum-roadmap is het verschil tussen een migratieplan dat uitvoerbaar is en een plan dat dat niet is. De bovenstaande checklist maakt dat verschil zichtbaar tijdens het evaluatieproces, in plaats van nadat een contract is getekend.

De acht evaluatiecategorieën behandelen elk onderdeel van een functionele PQC PKI-migratie: weten waar u vandaan migreert (Categorie 1), in staat zijn om de certificaten van het doelalgoritme in productie uit te geven (Categorie 2), de overgang van de relying party overbruggen met samengestelde certificaten (Categorie 3), de CA-hiërarchie zelf migreren (Categorie 4), certificaatbeleid bijwerken als configuratie in plaats van infrastructuur (Categorie 5), PQC-certificaten registreren via standaardautomatisering (Categorie 6), PQC-certificaten verifiëren in de relying party-systemen die relevant zijn voor uw omgeving (Categorie 7), en deskundige begeleiding hebben gedurende de 24 tot 48 maanden van programma-uitvoering die volgen op de selectie van de provider (Categorie 8).

Een leverancier die in alle acht categorieën kan antwoorden met "algemeen beschikbaar in productie", is een leverancier wiens platform uw PQC-migratie kan ondersteunen. Gebruik deze checklist in uw RFP, uw proof-of-concept-evaluatie en uw jaarlijkse PKI-programma-evaluatie om te bevestigen dat de gereedheid voor productie na de initiële implementatie niet is teruggevallen naar de beloftes in de roadmap.

Als uw organisatie een PKIaaS-provider evalueert op PQC-gereedheid en een gestructureerde beoordeling aan de hand van deze checklist wenst, neem dan contact op met Encryption Consulting.

Deze checklist wordt elke zes maanden herzien en wanneer NIST, NSA, IETF LAMPS of belangrijke leveranciers van besturingssystemen en browsers updates publiceren met betrekking tot de ondersteuning van PQC-algoritmen, specificaties voor samengestelde certificaten of richtlijnen voor de integratie van vertrouwensarchieven die van invloed zijn op de evaluatiecriteria.

Veelgestelde Vragen / FAQ

Welke NIST-algoritmen voor post-kwantumtoepassingen moet een PKIaaS-aanbieder ondersteunen voor het ondertekenen van certificaten?

Voor het ondertekenen van PKI-certificaten is het primaire algoritme ML-DSA (FIPS 204, gebaseerd op CRYSTALS-Dilithium), dat in augustus 2024 is afgerond. De drie parameterreeksen zijn ML-DSA-44 (categorie 2), ML-DSA-65 (categorie 3, aanbevolen voor de meeste bedrijfsapplicaties) en ML-DSA-87 (categorie 5, vereist voor TOP SECRET-systemen onder CNSA 2.0). SLH-DSA (FIPS 205) is een alternatief post-quantum-ondertekeningsalgoritme met hash-gebaseerde beveiligingsveronderstellingen; het is het back-upalgoritme en niet het primaire migratiedoel. Een post-quantum-compatibele provider moet minimaal ML-DSA-65 in productie ondersteunen voor abonneecertificaten.

Waarom is de 'oogst nu, decodeer later'-aanval relevant voor PKI-certificaten?

HNDL (harvest now, decrypt later) is een dreigingsstrategie waarbij tegenstanders nu versleuteld verkeer verzamelen en opslaan, met de bedoeling dit te decoderen zodra een kwantumcomputer beschikbaar is. De dreiging is vooral van toepassing op TLS-sessies: als de TLS-sleuteluitwisseling gebruikmaakt van RSA of ECDH (in plaats van ML-KEM, FIPS 203), kan een toekomstige kwantumtegenstander de sessie decoderen. PKI-certificaten zelf worden niet direct door HNDL verzameld, maar ze authenticeren wel de sessies die dat wel worden. Organisaties met lange termijnvereisten voor gegevensvertrouwelijkheid moeten dit beschouwen als een actief risico, niet als een toekomstig risico.

Wat is een hybride of samengesteld PQC-certificaat en wanneer is het nodig?

Een hybride of samengesteld PQC-certificaat bevat zowel een klassieke ECDSA-handtekening als een ML-DSA-handtekening in één X.509-certificaat. Vertrouwende partijen die alleen klassieke verificatie ondersteunen, verifiëren met behulp van de ECDSA-component; bijgewerkte vertrouwende partijen verifiëren met behulp van ML-DSA. Hybride certificaten zijn nodig tijdens de overgangsperiode wanneer niet alle vertrouwende partijen ML-DSA-verificatie ondersteunen. Ze maken het mogelijk om met de PQC-implementatie te beginnen voordat elk systeem is bijgewerkt, maar fungeren als een overgangsmechanisme: het eindpunt gebruikt uitsluitend ML-DSA-certificaten zodra alle vertrouwende partijen deze ondersteunen.

Wat is NIST IR 8547 en waarom stelt het de deadline voor PKIaaS PQC-gereedheid?

NIST IR 8547 (“Overgang naar post-kwantumcryptografiestandaarden”) stelt dat RSA en ECC rond 2030 niet meer zullen worden ondersteund voor nieuwe toepassingen en rond 2035 niet meer toegestaan ​​zullen zijn. Voor PKIaaS betekent dit dat nieuwe CA-implementaties na 2030 gebruik moeten maken van ML-DSA-ondertekeningssleutels en dat alle bestaande RSA/ECC CA-hiërarchieën vóór 2035 moeten zijn gemigreerd. Aangezien PKI-migraties binnen bedrijven 24 tot 48 maanden duren, lopen organisaties die nog niet zijn begonnen met inventarisatie en planning al achter op schema voor een vlotte migratie vóór de uitfasering in 2030.

Hoe weet ik of de PQC-ondersteuning van mijn PKIaaS-provider klaar is voor productiegebruik of zich nog in de previewfase bevindt?

Stel vier specifieke vragen: Valt de uitgifte van ML-DSA onder de productie-SLA van de provider? Zijn de HSM's die ML-DSA CA-ondertekeningssleutels bevatten gevalideerd voor ML-DSA-sleutelbewerkingen (vraag naar het specifieke HSM-model en de firmwareversie)? Kunnen ML-DSA-certificaatprofielen worden aangemaakt door de CA-beheerder van de klant via de standaard beheerinterface, of moet het supportteam van de provider dit inschakelen? Worden de intrekking van ML-DSA-certificaten en OCSP-reacties afgehandeld door de productie-OCSP-infrastructuur? Als het antwoord op een van deze vragen nee is, is de PQC-ondersteuning niet volledig productiegericht.