Certificats ML-DSA et PKI post-quantique : construire une autorité de certification résistante au quantique (guide 2026)

Les certificats ML-DSA sont des certificats X.509 dont la clé publique et la signature utilisent ML-DSA (Module-Lattice-Based Digital Signature Algorithm), l'algorithme de signature numérique fondé sur les réseaux euclidiens modulaires que le NIST a normalisé dans FIPS 204 en août 2024. Ils remplacent les signatures RSA et ECDSA, qu'un ordinateur quantique suffisamment puissant pourrait falsifier, par un schéma de signature conçu pour résister aux attaques quantiques. L'IETF a défini l'encodage de ML-DSA dans les certificats X.509 dans la RFC 9881 (octobre 2025).

Pour une équipe de sécurité, la question n'est plus de savoir s'il faut passer une PKI aux signatures post-quantiques, mais par où commencer et dans quel ordre. Le TLS public n'est pas prêt : en octobre 2026, le CA/Browser Forum n'a adopté aucun ballot autorisant ML-DSA dans les certificats TLS de confiance publique. La PKI privée, c'est une autre histoire. Lorsque vous exploitez l'AC et maîtrisez à la fois l'émetteur et les parties utilisatrices (relying parties), vous pouvez commencer dès maintenant à construire et à tester une autorité de certification post-quantique.

Ce guide présente ML-DSA et SLH-DSA, l'impact réel sur la taille des chaînes de certificats, l'état des normes de l'IETF, les cas où choisir des certificats hybrides (composites) plutôt que purement post-quantiques, ainsi qu'un plan de migration pas à pas pour une hiérarchie d'AC privée.

---

Table des matières

1. Pourquoi la PKI post-quantique compte dès maintenant
2. ML-DSA et SLH-DSA : les deux normes de signature du NIST
3. Ce qui change dans les certificats et les chaînes
4. État des normes : IETF LAMPS et CA/Browser Forum
5. Pourquoi commencer par la PKI privée
6. Certificats hybrides ou PQC pure : tableau de décision
7. Plan de migration pour une hiérarchie d'AC privée
8. Exploiter une autorité de certification post-quantique avec DuoKey
9. FAQ

---

Pourquoi la PKI post-quantique compte dès maintenant

Le chiffrement et les signatures ne sont pas exposés au même risque quantique. Un trafic chiffré peut être enregistré aujourd'hui et déchiffré plus tard (store now, decrypt later), c'est pourquoi l'échange de clés a migré en premier. Une signature est vérifiée au moment de son utilisation : une signature falsifiée ne pose problème qu'à partir du moment où quelqu'un est réellement capable d'en falsifier une. Cela semble laisser plus de temps, mais la PKI a les délais de mise en œuvre les plus longs de toute la cryptographie :

• Les AC racines vivent des années. Une racine créée aujourd'hui est souvent encore de confiance dix ans plus tard. Une racine que vous créez maintenant avec RSA ou ECDSA devra être remplacée avant que la falsification quantique ne devienne praticable.
• Les magasins de confiance évoluent lentement. Faire entrer une nouvelle racine dans chaque serveur, poste de travail, image de conteneur, appliance et appareil embarqué prend plus de temps que de l'émettre.
• Certaines signatures ont une longue durée de vie. Le firmware, la signature de code et les documents signés peuvent devoir rester vérifiables pendant de nombreuses années.

Une migration de PKI commence donc par le sommet de la hiérarchie et par la distribution de la confiance, bien avant que le dernier certificat feuille ne change. Les régulateurs attendent un plan ; pour les banques suisses, voir la migration post-quantique selon la circulaire FINMA 05/2026.

---

ML-DSA et SLH-DSA : les deux normes de signature du NIST

Le NIST a publié les deux normes le 13 août 2024 :

• FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Standard), dérivée de CRYSTALS-Dilithium.
• FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Standard), dérivée de SPHINCS+.

Jeux de paramètres ML-DSA (FIPS 204)

FIPS 204 définit trois jeux de paramètres. Les tailles sont en octets et proviennent du tableau 2 de FIPS 204 ; les catégories de sécurité, de la section 4.

FIPS 204 n'exprime pas la robustesse en « 128 bits de sécurité ». Chaque catégorie signifie que casser le jeu de paramètres exige au moins les ressources nécessaires pour casser un chiffrement par bloc ou une fonction de hachage de référence. En pratique, ML-DSA-65 est un choix par défaut courant pour les certificats d'AC et de serveur, ML-DSA-87 pour les racines et les usages à haut niveau d'assurance, et ML-DSA-44 lorsque la taille est la contrainte principale.

SLH-DSA : petites signatures ou signature rapide

SLH-DSA repose uniquement sur la sécurité des fonctions de hachage, une hypothèse prudente et indépendante des mathématiques des réseaux euclidiens sur lesquelles repose ML-DSA. FIPS 205 approuve 12 jeux de paramètres, chacun instancié avec SHA-2 ou SHAKE. Le suffixe indique le compromis : les jeux « s » visent des signatures relativement petites, les jeux « f » une génération de signature relativement rapide.

Les clés publiques sont minuscules, les signatures volumineuses, et la signature est lente comparée à ML-DSA. SLH-DSA convient donc aux racines et aux autres clés qui signent rarement et doivent durer longtemps, et se prête mal aux certificats feuilles TLS qui signent à chaque poignée de main.

ML-DSA et SLH-DSA en un coup d'œil

---

Ce qui change dans les certificats et les chaînes

Un certificat X.509 contient la clé publique du sujet et la signature de l'émetteur. Avec ECDSA P-256, les deux se mesurent en dizaines d'octets. Avec ML-DSA, elles se mesurent en kilo-octets.

D'après les tailles de FIPS 204, un certificat ML-DSA-65 signé par un émetteur ML-DSA-65 transporte 1 952 + 3 309 = 5 261 octets de clé et de signature, avant tout nom ou toute extension. Dans une poignée de main TLS 1.3, le serveur envoie généralement son certificat feuille et son certificat intermédiaire, plus une signature CertificateVerify ; une chaîne entièrement en ML-DSA-65 ajoute donc environ :

Concrètement :

• Taille de la poignée de main. Une chaîne de plus de 13 Ko ne tient plus dans quelques paquets. Attendez-vous à des allers-retours supplémentaires sur les réseaux avec pertes et vérifiez les équipements intermédiaires (middleboxes), répartiteurs de charge et proxys dont les tampons ont une taille fixe.
• Appareils contraints. Les appareils IoT et OT dotés de peu de mémoire, de liaisons lentes ou d'emplacements de stockage de certificats de taille fixe peuvent ne pas être en mesure de stocker ou d'analyser des chaînes ML-DSA. Inventoriez-les tôt.
• Stockage et journalisation. Les bases de données de certificats, les CRL signées avec ML-DSA, les réponses OCSP et les journaux Certificate Transparency grossissent tous. La capacité des journaux CT fait partie des préoccupations soulevées dans les discussions du CA/Browser Forum.
• Les chaînes courtes aident. Chaque intermédiaire supprimé économise environ 5 Ko avec ML-DSA-65. Le passage au post-quantique est une bonne occasion d'aplatir des hiérarchies qui se sont étoffées pour des raisons historiques.

Utilisez le guide d'automatisation ACME pour les AC privées et le calendrier de la durée de vie des certificats TLS à 47 jours pour planifier le volet renouvellement : des durées de vie plus courtes et des certificats plus volumineux poussent tous deux vers une émission entièrement automatisée.

---

État des normes : IETF LAMPS et CA/Browser Forum

Le draft composite définit 18 combinaisons de ML-DSA avec un algorithme traditionnel, par exemple id-MLDSA65-ECDSA-P256-SHA512 et id-MLDSA87-ECDSA-P384-SHA512. Une signature composite n'est valide que si chacune des signatures qui la composent est vérifiée : un attaquant devrait donc casser les deux algorithmes. Tant que la RFC n'est pas publiée, les OID et les encodages peuvent encore changer ; réservez les certificats composites aux tests ou à un usage privé et suivez la RFC finale.

TLS public. Le Server Certificate Working Group du CA/Browser Forum travaille sur un ballot « Allow ML-DSA » depuis au moins le printemps 2026. Le procès-verbal de mai 2026 fait état de questions ouvertes sur la capacité des journaux Certificate Transparency et sur la question de savoir si les certificats X.509 traditionnels feront même partie de la transition post-quantique ; les Merkle Tree Certificates ont également été évoqués. Le procès-verbal d'août 2026 indique que le travail se poursuit en vue d'un ballot combiné. Aucun ballot ML-DSA ne figure dans la liste des ballots du Forum. Le même procès-verbal de mai indique que la prise en charge des ancres de confiance ML-DSA pour la PKI privée dans TLS 1.3 sera livrée avec Chrome 150.

---

Pourquoi commencer par la PKI privée

Une AC privée (interne) est l'endroit où les certificats post-quantiques sont utilisables dès aujourd'hui, pour trois raisons :

1. Vous maîtrisez les deux extrémités. Vous décidez quelles ancres de confiance vos clients installent et quelles bibliothèques vos serveurs exécutent. Aucun programme de racines (root program) n'a à approuver votre racine.
2. Le rayon d'impact est limité. Vous pouvez piloter ML-DSA sur un service mesh, un VPN ou une flotte d'appareils, et revenir en arrière sans affecter vos clients.
3. Elle produit les preuves dont vous avez besoin. Des mesures réelles de la taille des poignées de main, de la latence et de la compatibilité des appareils dans votre environnement sont ce qui transforme une feuille de route en projet financé.

Premiers candidats typiques : le mTLS de service à service dans Kubernetes, les API internes, le VPN et l'identité des appareils lorsque vous fournissez le client, ainsi que la signature de code ou de firmware avec votre propre vérificateur. Conservez des certificats classiques émis par des AC publiques pour les sites web exposés au public tant que les règles de la WebPKI n'ont pas changé. Si votre PKI interne repose sur Active Directory Certificate Services, examinez ses limites connues (voir les ressources associées) avant d'y planifier une hiérarchie PQC.

---

Certificats hybrides ou PQC pure : tableau de décision

Les certificats hybrides combinent un algorithme post-quantique et un algorithme classique, de sorte que le résultat reste sûr tant que l'un des deux tient. L'approche normalisée à l'IETF LAMPS est le certificat composite : un seul certificat avec une clé publique composite et une signature composite (par exemple ML-DSA-65 + ECDSA P-256). L'alternative est celle des chaînes parallèles : une chaîne classique et une chaîne PQC pure côte à côte, chaque client utilisant celle qu'il comprend.

Deux points souvent négligés. Un certificat composite n'est pas lisible par un client uniquement classique : il utilise un nouvel identifiant d'algorithme, si bien qu'un ancien vérificateur échoue quand même. Et les certificats composites sont légèrement plus volumineux que les certificats ML-DSA purs, puisqu'ils transportent aussi la clé et la signature classiques.

---

Plan de migration pour une hiérarchie d'AC privée

Une séquence pratique pour faire passer une PKI interne aux signatures post-quantiques :

Étape 1 : inventorier l'existant

Recensez chaque AC, son algorithme, sa taille de clé, sa validité et l'emplacement de sa clé, ainsi que chaque consommateur de certificats qui aura besoin d'une nouvelle ancre de confiance. Une nomenclature cryptographique (CBOM) et un scan de découverte vous donnent le point de départ ; la gestion de la posture cryptographique le maintient à jour.

Étape 2 : choisir les algorithmes par niveau

L'algorithme de l'AC émettrice doit être un algorithme que son parent peut signer et que les vérificateurs de ses enfants comprennent. Ne placez pas une AC intermédiaire PQC sous une racine classique en qualifiant la chaîne de résistante au quantique : un attaquant capable de falsifier la signature de la racine peut falsifier toute la chaîne.

Étape 3 : créer une nouvelle racine PQC en parallèle

Générez la clé de la nouvelle racine dans un HSM ou un coffre (vault), jamais sur un poste de travail. Laissez la racine classique existante en service. Les deux hiérarchies fonctionnent côte à côte pendant la transition.

Étape 4 : distribuer tôt la nouvelle ancre de confiance

C'est l'étape la plus longue. Poussez la racine PQC dans les magasins de confiance des systèmes d'exploitation, les images de base des conteneurs, les truststores Java, les profils de gestion des appareils mobiles (MDM) et le firmware des appareils. Distribuer l'ancre ne coûte rien à l'exécution tant qu'elle n'est pas utilisée : commencez maintenant, même si l'émission vient plus tard.

Étape 5 : émettre les intermédiaires PQC, puis les feuilles

Créez des intermédiaires ML-DSA sous la nouvelle racine. Faites passer un groupe de services à la fois à des feuilles issues de la chaîne PQC, en utilisant l'enrôlement automatisé (ACME, EST, SCEP ou CMP) afin que le renouvellement ne dépende pas d'interventions humaines.

Étape 6 : exploiter des chaînes parallèles, mesurer, puis basculer

Servez les chaînes classique et PQC aux clients qui prennent en charge chacune d'elles. Mesurez la taille des poignées de main, la latence et les échecs. Lorsqu'un groupe de parties utilisatrices est entièrement compatible PQC, cessez de lui émettre des certificats classiques.

Étape 7 : retirer la hiérarchie classique

Laissez expirer les feuilles classiques, révoquez celles qui restent, publiez les dernières CRL, puis retirez la racine classique des magasins de confiance.

---

Exploiter une autorité de certification post-quantique avec DuoKey

La gestion des certificats de DuoKey dans DuoKey Cockpit est conçue pour le plan de migration ci-dessus. Selon la documentation PKI de DuoKey :

• Algorithmes. RSA-2048/4096, EC-P256/P384, ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) et un composite hybride ML-DSA-65 + ECDSA-P256, une combinaison qui figure aussi dans la liste du draft composite de l'IETF.
• Hiérarchie d'AC. AC racines, intermédiaires/émettrices et externes (importées). Cockpit impose la compatibilité avec l'algorithme du parent, de sorte que les chaînes PQC et hybrides se vérifient de bout en bout. Le cycle de vie des AC couvre la suspension et la réactivation, la révocation simple et en cascade, ainsi que l'archivage.
• AC PQC signées par le coffre. Les clés de signature des AC PQC et hybrides résident dans le coffre ou le HSM et ne sont pas générées localement ; pour les certificats PQC émis, la clé de la feuille réside elle aussi dans le coffre. Les AC adossées à un coffre peuvent utiliser des coffres externes reposant sur un HSM, par exemple Securosys (HSM FIPS 140-2 niveau 3).
• Cycle de vie. Workflow d'approbation des CSR (demande, approbation ou rejet, émission), renouvellement, révocation avec les motifs de la RFC 5280, ainsi qu'une CRL et un répondeur OCSP par AC.
• Enrôlement. ACME (RFC 8555) avec les défis http-01 et dns-01, EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), Kubernetes cert-manager via ACME et un point de terminaison serveur KMIP 2.1, ainsi que des connecteurs de déploiement avec validation et retour arrière par tâche.

Pour faire pointer Kubernetes cert-manager vers une AC DuoKey via ACME, on utilise l'URL de répertoire de l'AC :

# ClusterIssuer pointing cert-manager at a DuoKey CA over ACME
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory

La documentation de DuoKey formule la même recommandation que ce guide : utiliser la PQC là où vous maîtrisez les deux extrémités, et le composite hybride là où vous devez interopérer avec des parties utilisatrices classiques, car « not every browser, server or device understands ML-DSA / SLH-DSA yet » (tous les navigateurs, serveurs ou appareils ne comprennent pas encore ML-DSA / SLH-DSA).

Pour identifier les certificats et les clés à migrer en priorité, commencez par le Quantum Readiness Score gratuit.

---

FAQ

Q: Qu'est-ce qu'un certificat ML-DSA ?

Un certificat ML-DSA est un certificat X.509 qui utilise ML-DSA (FIPS 204) pour sa clé publique et sa signature au lieu de RSA ou d'ECDSA. L'encodage est défini dans la RFC 9881. Il est conçu pour rester sûr face aux attaques menées par des ordinateurs quantiques.

Q: Les navigateurs prennent-ils en charge les certificats ML-DSA ?

Pas encore pour le web public. Le CA/Browser Forum n'a adopté aucun ballot autorisant ML-DSA dans les certificats TLS de confiance publique ; les AC publiques ne peuvent donc pas en émettre pour des sites web. Pour la PKI privée, le procès-verbal du CA/B Forum de mai 2026 indique que la prise en charge des ancres de confiance ML-DSA pour la PKI privée dans TLS 1.3 sera livrée avec Chrome 150.

Q: Quelle est la différence entre ML-DSA et SLH-DSA ?

ML-DSA (FIPS 204) repose sur les réseaux euclidiens, avec des clés et des signatures de quelques kilo-octets et une signature rapide. SLH-DSA (FIPS 205) repose uniquement sur des fonctions de hachage, avec des clés publiques de 32 à 64 octets mais des signatures d'environ 7,9 Ko à 49,9 Ko et une signature plus lente. ML-DSA convient à la plupart des certificats ; SLH-DSA convient aux racines à longue durée de vie et à la signature de firmware.

Q: Qu'est-ce qu'un certificat composite (hybride) ?

Un certificat composite contient une clé publique combinée, par exemple ML-DSA-65 + ECDSA P-256, et une signature combinée qui n'est valide que si les deux signatures qui la composent sont vérifiées. Il est défini dans le draft draft-ietf-lamps-pq-composite-sigs de l'IETF LAMPS, qui se trouve dans la file d'attente du RFC Editor mais n'est pas encore publié en tant que RFC.

Q: Quel jeu de paramètres ML-DSA dois-je utiliser ?

ML-DSA-65 (catégorie 3) est un choix par défaut raisonnable pour les intermédiaires et les serveurs. Utilisez ML-DSA-87 (catégorie 5) pour les racines ou les exigences de haut niveau d'assurance, et ML-DSA-44 (catégorie 2) lorsque la taille des certificats est la contrainte principale.

Q: De combien les certificats ML-DSA sont-ils plus volumineux ?

Un certificat ML-DSA-65 signé par une AC ML-DSA-65 transporte 5 261 octets de clé publique et de signature, contre quelques dizaines d'octets pour ECDSA P-256. Une chaîne de deux certificats plus la signature de la poignée de main ajoute environ 13,8 Ko à une poignée de main TLS 1.3.

Q: ML-DSA est-il normalisé pour X.509 ?

Oui. La RFC 9881 (octobre 2025) définit les identifiants d'algorithme ML-DSA pour X.509, et la RFC 9909 (décembre 2025) fait de même pour SLH-DSA. Toutes deux sont des Proposed Standards de l'IETF.

Q: Faut-il utiliser des certificats hybrides ou purement post-quantiques ?

Utilisez ML-DSA pur là où vous maîtrisez l'émetteur et toutes les parties utilisatrices. Utilisez des certificats composites lorsque la politique exige une composante classique ou que vous souhaitez vous prémunir contre des bogues d'implémentation PQC, et des chaînes classique et PQC parallèles lorsque certains clients restent uniquement classiques.

Q: Peut-on construire une autorité de certification post-quantique dès aujourd'hui ?

Oui, pour la PKI privée. Créez une racine PQC dans un HSM ou un coffre, distribuez-la dans vos magasins de confiance, puis émettez des intermédiaires et des feuilles ML-DSA via l'enrôlement automatisé, en exploitant des chaînes parallèles jusqu'à ce que vos clients soient prêts.

---

Conclusion : checklist de la PKI post-quantique

La PKI post-quantique commence au sommet de la hiérarchie et par la distribution de la confiance, pas par le dernier certificat feuille. La PKI privée est l'endroit où vous pouvez la construire et la mesurer dès aujourd'hui, pendant que les règles de la WebPKI publique sont encore en cours de rédaction.

• Inventorier chaque AC, son algorithme, sa validité et l'emplacement de sa clé
• Recenser les parties utilisatrices qui auront besoin d'une nouvelle ancre de confiance, y compris les appareils contraints
• Choisir les algorithmes par niveau (par exemple racine ML-DSA-87 ou SLH-DSA, intermédiaires ML-DSA-65)
• Générer la racine PQC dans un HSM ou un coffre, en parallèle de la racine classique
• Commencer dès maintenant à distribuer l'ancre de confiance PQC
• Automatiser l'enrôlement (ACME, EST, SCEP ou CMP) avant d'émettre des feuilles PQC
• Piloter sur un groupe de services internes et mesurer la taille des poignées de main et les échecs
• Choisir PQC pure, composite ou chaînes parallèles pour chaque groupe de parties utilisatrices
• Suivre la RFC composite et le ballot ML-DSA du CA/B Forum

---

Références

• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 204 (PDF), Tables 1 and 2
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST FIPS 205 (PDF), Table 2
• RFC 9881: Internet X.509 PKI: Algorithm Identifiers for ML-DSA
• RFC 9909: Internet X.509 PKI: Algorithm Identifiers for SLH-DSA
• IETF draft-ietf-lamps-pq-composite-sigs: Composite ML-DSA for X.509
• CA/Browser Forum Ballot SMC013: Enable PQC Algorithms for S/MIME
• CA/Browser Forum: Server Certificate WG minutes, 21 May 2026
• CA/Browser Forum: Server Certificate WG minutes, 13 August 2026
• CA/Browser Forum: All ballots
• DuoKey Docs: PKI and SSL overview
• DuoKey Docs: Post-quantum certificates
• DuoKey Docs: Enrollment protocols