Certificats post-quantiques hybrides : pourquoi votre première migration PQC n'est pas vraiment post-quantique

Les standards NIST 2024 dans la réalité de production 2026

Le 13 août 2024, le NIST a publié trois Federal Information Processing Standards qui ont condensé une décennie de compétition en une stack cryptographique déployable : FIPS 203 (ML-KEM) pour l'encapsulation de clé, dérivé de CRYSTALS-Kyber ; FIPS 204 (ML-DSA) pour les signatures numériques, dérivé de CRYSTALS-Dilithium ; et FIPS 205 (SLH-DSA), le schéma de signature basé sur le hash sans état anciennement connu sous le nom de SPHINCS+. Un quatrième standard, FIPS 206 (FN-DSA, ex-Falcon), est encore en draft au T2 2026.

L'affirmation marketing entendue à chaque briefing fournisseur depuis est que la transition post-quantique a commencé. La réalité technique est plus étroite et plus intéressante : ce qui est déployé en production en 2026 est une histoire de certificat post-quantique hybride et d'échange de clé hybride, pas une histoire PQC pure, et les deux ne devraient pas être confondus.

Le déploiement PQC le plus mesurable aujourd'hui vit dans l'échange de clé TLS 1.3. Chrome a activé X25519MLKEM768 (codepoint 0x11EC, défini dans draft-kwiatkowski-tls-ecdhe-mlkem) par défaut pour les clients desktop à partir de la version 124 en avril 2024 et atteint maintenant plus de 30 % des handshakes TLS 1.3 globalement selon la télémétrie Radar de Cloudflare début 2026. Firefox a livré le même groupe en version 132. La périphérie de Cloudflare supporte les KEM hybrides depuis 2022, d'abord avec X25519Kyber768Draft00, puis migré vers le X25519MLKEM768 standardisé lorsqu'AWS-LC et BoringSSL ont basculé au deuxième semestre 2024.

AWS-LC 1.30 livre ML-KEM derrière la frontière du module FIPS ; BoringSSL l'expose dans le cadre de la liste de groupes par défaut. OpenSSL 3.5, sorti en avril 2025, a ajouté le support natif ML-KEM et ML-DSA sans plug-ins de provider ; avant 3.5, les équipes de production s'appuyaient sur l'oqs-provider du projet Open Quantum Safe, qui convient pour l'expérimentation et est non sûr pour les workloads liés FIPS.

Ce qui n'est pas déployé est tout aussi important. Les signatures PQC à l'intérieur des handshakes TLS restent rares. Le draft IETF draft-ietf-tls-mldsa est encore en working group last call en mai 2026, et aucun navigateur majeur ne négocie ML-DSA pour le certificat serveur par défaut. Les CA racine publiques ont émis exactement zéro racine ML-DSA qui chaîne dans les trust stores Mozilla, Apple, Microsoft ou Chrome. Le Server Certificate Working Group du CA/Browser Forum a un tracker de ballot PQC mais aucune baseline requirement fusionnée permettant ML-DSA dans les certificats publics.

Concrètement : lorsqu'un utilisateur Chrome charge un site web via X25519MLKEM768, la clé de session symétrique est post-quantique-sûre, mais le certificat serveur qui a authentifié le handshake est encore signé avec ECDSA P-256 ou RSA-2048. Cette asymétrie est la caractéristique définissante du déploiement PQC en 2026 et le sujet entier de cet article. Pour le contexte plus large, voyez notre guide pratique de la cryptographie post-quantique.

Ce que « hybride » signifie réellement

Le mot hybride est utilisé de manière vague dans les decks fournisseurs et précisément dans trois documents IETF. La distinction compte parce que les trois variantes ont des formats wire différents, des modes de défaillance différents et des voies différentes vers la standardisation.

La première variante est le KEM hybride concaténé défini pour TLS 1.3 dans la RFC 9794 (publiée en décembre 2024) et instancié comme X25519MLKEM768. Le secret partagé est la concaténation de la sortie ECDH classique et du secret dérivé du ciphertext ML-KEM, passé à travers HKDF-Extract. Si l'un des deux composants est cassé — cassure quantique de X25519 ou cassure cryptanalytique classique de ML-KEM — le secret combiné reste sécurisé sous l'indifférentiabilité du KDF.

Le ClientHello porte une seule entrée key_share de 1216 octets (32 octets X25519 + 1184 octets de clé publique ML-KEM-768) ; le ServerHello renvoie 1120 octets (32 + 1088). C'est le hybride le moins cher et le plus opérationnellement mature : seule la stack TLS a besoin de le connaître, et les chaînes de certificats sont intactes.

La deuxième variante est la signature composite, spécifiée dans draft-ietf-lamps-pq-composite-sigs et draft-ietf-lamps-pq-composite-kem. Un certificat composite porte une seule clé publique subject dont l'AlgorithmIdentifier est un nouvel OID (par exemple id-MLDSA65-ECDSA-P256-SHA512) et dont la valeur de clé est la concaténation d'une clé publique ML-DSA-65 et d'une clé publique ECDSA P-256. La signature est aussi une concaténation : la partie vérificatrice doit vérifier les deux composants, et l'échec de l'un avorte la vérification.

Cela préserve la structure X.509 existante décrite dans notre explication du standard X.509, mais cela double la taille de signature (une signature ML-DSA-65 fait 3309 octets ; une signature ECDSA P-256 fait 64-72 octets ; le composite est d'environ 3380 octets). LAMPS a atteint le working group last call sur les signatures composites en mars 2026 avec une RFC cible au T4 2026.

La troisième variante est le certificat chaîné ou approche de chaîne parallèle, illustrée par les expériences Merkle-Tree-Ladder de Cloudflare et par l'ancien draft-truskovsky-lamps-pq-hybrid-x509 de 2018. Ici la partie utilisatrice traite deux chaînes complètes de certificats en parallèle — une classique, une PQC — soit livrées comme extensions X.509 non-critiques à l'intérieur d'un seul certificat soit comme deux chaînes distinctes négociées dans le handshake TLS.

C'est le moins intrusif pour les racines mais le plus lourd sur le fil, et il a la pire histoire pour les vérificateurs hérités qui analysent strictement les extensions critiques inconnues selon la RFC 5280 section 4.2. Comprendre pourquoi une partie utilisatrice rejetterait l'un et accepterait l'autre nécessite de comprendre comment les chaînes de certificats et la confiance sont construites et vérifiées.

• KEM concaténé (RFC 9794) : TLS uniquement, double la taille key_share, ne nécessite aucun changement PKI. Déjà en production chez Cloudflare, Google, Amazon, Apple iCloud Private Relay. Mode de défaillance : mismatch de stack TLS causant un repli sur la courbe classique.
• Signatures composites (draft-ietf-lamps-pq-composite) : nouveaux OID dans le certificat lui-même, dual-verify obligatoire. Sémantique la plus propre pour le PQC lié au certificat. Mode de défaillance : toute partie utilisatrice qui ne connaît pas l'OID composite rejette la chaîne purement et simplement.
• Certificats chaînés / parallèles : deux chaînes complètes livrées ensemble. Plus rétrocompatible si les extensions sont marquées non-critiques, mais plus grande empreinte wire et sémantique de confiance ambiguë. Utilisé dans les PKI privées et déploiements expérimentaux.

Les trois endroits où les certs hybrides cassent

Les déploiements hybrides échouent en production pour des raisons ennuyeuses. Trois classes de défaillances dominent le journal d'incidents de chaque pilote PQC, et aucune ne concerne la cryptographie lattice elle-même.

La première est le décalage de version de bibliothèque. Jusqu'à OpenSSL 3.5, ML-KEM et ML-DSA vivaient dans le module oqs-provider de liboqs 0.10+, qui à son tour dépendait du fork OQS d'OpenSSL. BoringSSL implémente ML-KEM dans son cœur mais expose une surface d'API différente, et son parser de certificat rejette les OID de signature inconnus que des versions plus anciennes d'OpenSSL acceptent silencieusement. AWS-LC, dérivé de BoringSSL, livre ML-KEM comme primitif FIPS-validé dans le module AWS-LC FIPS 2024 mais le désactive hors de la frontière FIPS sauf si explicitement activé au moment du build. BouncyCastle Java a ajouté ML-KEM en 1.78 et ML-DSA en 1.79, mais les OID de signature composite nécessitent 1.80 et un JcaCompositeSignerInfoGeneratorBuilder non par défaut.

Un pilote qui compile bien sur l'ordinateur portable du développeur avec OpenSSL 3.5 va silencieusement rétrograder dans un conteneur tournant sur une image de base Ubuntu 22.04 avec OpenSSL 3.0.2 et aucun provider configuré.

Il n'y a pas d'erreur au niveau du protocole : le client propose le groupe hybride, le serveur ne le comprend pas, et TLS négocie un groupe classique comme si rien ne s'était passé. La détection nécessite soit un client appliquant, soit une surveillance active de la suite de chiffrement négociée par endpoint.

La deuxième est le décalage des modules HSM et FIPS 140-3. Les algorithmes FIPS 203, 204 et 205 ne peuvent pas être revendiqués dans un module FIPS-validé sauf si ce module a été revalidé par un laboratoire Cryptographic and Security Testing (CST) accrédité et est entré dans la file CMVP du NIST. En mai 2026, la file CMVP contient plus de 200 soumissions de modules ML-KEM/ML-DSA avec un backlog documenté de 14 à 22 mois.

Quelques fournisseurs détiennent des certificats module-in-process ; seuls une poignée (Utimaco SecurityServer Se Gen2 firmware 5.5, Thales Luna 7 firmware 7.8.0, Entrust nShield 13.6, HSM interne AWS KMS) ont un module entièrement validé couvrant au moins ML-DSA-65. Pour les organisations opérant sous CNSA 2.0, PCI DSS 4.0, eIDAS QSCD ou toute enveloppe FedRAMP High, une implémentation PQC non-FIPS n'est pas déployable.

L'implication est que les CA racine et de politique dans un module matériel de sécurité à haute assurance ne peuvent pas passer à ML-DSA jusqu'à ce que le firmware HSM soit sur la liste validée CMVP, et cette contrainte pousse typiquement la migration de la CA racine en 2027 ou 2028 indépendamment du reste de la stack.

La troisième est les limites de taille des logs Certificate Transparency. La RFC 6962-bis et la RFC 9162 n'imposent pas de plafond dur de taille sur les certificats journalisés, mais les logs opérationnels le font : les shards Argon et Xenon de Google rejettent les pre-certificates au-delà de 16 Ko ; Nimbus de Cloudflare rejette au-delà de 8 Ko ; le log Sabre plafonne à 8 Ko ; le log Wyvern accepte jusqu'à 32 Ko mais avec une pénalité de limite de débit documentée.

Un certificat ML-DSA-87 avec deux SAN, un point de distribution CRL et une extension SCT pèse environ 5,5 Ko ; un certificat composite ML-DSA-65 + ECDSA P-256 avec les mêmes métadonnées est d'environ 4,2 Ko ; un certificat SLH-DSA-SHA2-128s est d'environ 8,8 Ko.

Les chaînes composites où chaque intermédiaire porte une signature ML-DSA peuvent pousser la feuille porteuse de SCT plus la chaîne au-delà des seuils d'inclusion pratiques de la plupart des logs. L'écosystème Certificate Transparency a été conçu pour des artefacts de taille ECDSA, et ses hypothèses de taille font surface comme des échecs d'inclusion silencieux plutôt que des erreurs vérificateur, ce qui est le pire mode de défaillance possible pour une couche de transparency.

Une réponse opérationnelle défendable à ces trois classes de défaillances a cinq composants, exécutés en parallèle plutôt qu'en séquence.

• Épinglez les versions de bibliothèque à travers la stack. Traitez la bibliothèque cryptographique comme un composant contrôlé. Enregistrez les versions exactes d'OpenSSL, BoringSSL, AWS-LC, BouncyCastle, mbedTLS et tout module provider dans votre CBOM. Bloquez les builds qui ne correspondent pas au manifeste de version approuvé.
• Stagez les mises à jour de firmware HSM en parallèle. Planifiez les mises à jour de firmware HSM sur la voie d'un build ML-DSA validé CMVP au moins six mois avant qu'une CA de politique ne soit attendue pour signer ML-DSA. Coordonnez avec le statut module-in-process du fournisseur, pas avec les revendications marketing.
• Pré-vol de l'inclusion log CT. Soumettez des pre-certificates ML-DSA et composites synthétiques à chaque log sur lequel vous comptez avant la première émission réelle. Mesurez le succès d'inclusion par log et par algorithme de signature, pas seulement le compte SCT.
• Instrumentez la négociation TLS sur chaque endpoint. Exportez le named_group négocié et signature_scheme comme métrique Prometheus par session TLS. Sans cette télémétrie, le repli silencieux sur des groupes classiques passera inaperçu pendant des trimestres.
• Inventoriez les vérificateurs conscients des composites. Cataloguez chaque partie utilisatrice qui analyse vos certificats : agents SIEM, forwarders de logs, SDK mobiles, clients embarqués. Tout vérificateur qui ne reconnaît pas les OID composites devient un risque de déni de service au moment où le composite quitte le laboratoire.

Ordre de migration en monde réel

Un plan de migration PQC qui fonctionne est séquencé. Terminaison TLS hybride d'abord, CA internes ensuite, code signing troisième, S/MIME quatrième, racines publiques en dernier. La séquence n'est pas arbitraire ; elle suit là où le risque cryptographique est le plus élevé, là où le changement opérationnel est le moins cher et là où la population de parties utilisatrices est la plus contrôlée.

La terminaison TLS bouge en premier parce que les parties utilisatrices sont des navigateurs et des clients HTTP modernes avec des cadences de release mensuelles, l'échange de clé est renégocié à chaque session, et le format wire hybride est déjà standardisé dans la RFC 9794.

Une organisation peut déployer X25519MLKEM768 derrière un seul changement de configuration de load balancer et faire un rollback sans réémettre aucun certificat. Les déploiements 2025 chez Cloudflare, Google Frontend et Apple iCloud Private Relay démontrent que même à l'échelle internet le surcoût de handshake supplémentaire est de l'ordre de 1,5 ms médian et 7 ms en queue, sans changement mesurable du taux de succès de connexion.

Les CA internes bougent en deuxième parce que la population de parties utilisatrices est finie, identifiable et sous le même contrôle opérationnel que la CA émettrice. Les services internes qui consomment des primitifs cryptographiques via un ensemble connu de bibliothèques peuvent être inventoriés, mis à jour et testés.

L'émission composite ML-DSA-65 + ECDSA P-256 depuis des CA de politique internes est la voie la plus propre pour introduire des signatures PQC en production sans casser les microservices plus anciens, à condition que le workload utilise des bibliothèques qui reconnaissent les OID composites. C'est là que la plupart des organisations enregistreront leur première victoire PQC quantifiable en 2026 et 2027.

Le code signing vient troisième parce que les vérificateurs (Windows Authenticode, macOS Gatekeeper, gestionnaires de paquets Linux, attestations de registry de conteneurs) sont lents à bouger, mais l'horizon de menace est long : un binaire signé distribué en 2026 peut s'exécuter pendant 15 ans. CNSA 2.0 impose ML-DSA pour la signature de logiciel et firmware d'ici 2025, avec application complète d'ici 2030.

Microsoft Authenticode a ajouté le support ML-DSA dans Windows 11 24H2 via la release SignTool 10.0.26100 ; les CA de code signing correspondantes dans le Microsoft Trusted Root Program accepteront les OID ML-DSA à partir du ballot SC-77 du CA/Browser Forum Code Signing WG.

Le compromis pertinent est la taille de signature à l'échelle — un catalogue de drivers Windows typique avec 50 000 entrées portant chacune une signature ML-DSA-65 grossit d'environ 160 Mo par rapport à ECDSA. Le contexte plus profond vit dans notre référence sur la gestion des clés publiques et privées.

S/MIME bouge en quatrième parce que la population de parties utilisatrices est la plus fragmentée et la plus lente à mettre à jour : Outlook desktop, Outlook Mobile, Apple Mail, Thunderbird, applis mail mobiles intégrées dans des conteneurs MDM, et passerelles mail d'entreprise vieilles de 20 ans qui retirent les OID inconnus. Les S/MIME Baseline Requirements 1.0.4 du CA/Browser Forum ne permettent pas encore ML-DSA. Tant qu'elles ne le font pas, S/MIME exécutera des chaînes doubles dans les quelques organisations qui pilotent, et la plupart attendront la révision BR 2027.

Les CA racine publiques bougent en dernier, et elles le devraient. La rotation d'une racine publiquement approuvée est un exercice pluriannuel contraint par l'équipement le plus lent dans la population de parties utilisatrices — systèmes embarqués avec trust stores codés en dur de 2018, terminaux de point de vente, set-top boxes, contrôleurs industriels.

Remplacer l'algorithme de signature sur une racine avant que la flotte de trust stores ne puisse la vérifier est un exercice de pannes auto-infligées.

La posture correcte est la conception de racine crypto-agile : maintenez les racines classiques RSA-4096 et ECDSA P-384 jusqu'à ce que la flotte de parties utilisatrices supporte la vérification ML-DSA, et montez des racines ML-DSA parallèles dans une configuration cross-signée pour amorcer le trust store de prochaine génération, plutôt que de faire tourner l'existante. L'argument complet pour cette approche vit dans notre référence sur la crypto-agilité et la transition post-quantique.

Mesure : comment suivre le vrai progrès PQC

L'expression PQC-ready n'a pas de sens sans métriques attachées. Un programme PQC défendable rapporte quatre nombres, rafraîchis mensuellement, avec les pipelines de données qui les produisent sous le même change-control que la stack cryptographique de production.

Le premier est le pourcentage de sessions TLS négociées avec un KEM PQC. Ceci est mesuré par endpoint et par population de parties utilisatrices. La périphérie de Cloudflare le rapporte nativement ; pour les load balancers auto-exploités cela nécessite d'analyser le named_group négocié depuis les logs d'accès TLS ou depuis des sondes eBPF sur le chemin kernel TLS.

Une cible 2026 réaliste pour un service face publique est 25-40 % de couverture KEM PQC, pilotée par la part client Chrome et Firefox. En dessous de 10 % indique un problème au niveau de la stack, généralement décalage de version OpenSSL ou BoringSSL. Au-dessus de 50 % n'est actuellement vu que sur des services qui priorisent activement les groupes hybrides dans leur ordre de préférence serveur.

Le deuxième est le pourcentage de certificats émis dont l'algorithme de signature est ML-DSA ou un composite qui inclut ML-DSA. Ceci est mesuré depuis la base de la CA émettrice, segmenté par modèle de certificat, unité business et durée de vie. Un pilote qui émet 5 000 certificats composites contre une baseline de 2 millions de certificats classiques est à 0,25 %, pas à PQC-ready. Des cibles internes utiles suivent la séquence de migration ci-dessus : mTLS interne à 50 % composite d'ici fin 2026, code-signing à 100 % composite d'ici mi-2027, feuille TLS publique à 0 % jusqu'à ce que la baseline du CA/Browser Forum le permette.

Le troisième est le résultat de l'audit de bibliothèque : le nombre de versions distinctes de bibliothèque cryptographique en production, le pourcentage qui supporte ML-KEM, le pourcentage qui supporte ML-DSA, et le pourcentage couvert par la validation FIPS 140-3 lorsque c'est une exigence réglementaire. C'est la métrique qui se rattache directement au cryptographic bill of materials. Une organisation qui ne peut pas répondre à quel build d'OpenSSL tourne sur chacun de nos 12 000 hôtes n'est pas en position de revendiquer un progrès PQC quel que soit le nombre de certificats pilotes qu'elle a émis.

Le quatrième est l'inventaire de support PQC HSM et KMS : modèle, version firmware, statut de validation CMVP, ensembles de paramètres ML-DSA supportés, ensembles de paramètres ML-KEM supportés, chemin de mise à jour planifié et date de fin de support attendue.

La question décisive à laquelle cette métrique répond est de savoir si les clés à plus haute assurance dans l'organisation — clés CA racine, clés CA de politique, clés de code signing — peuvent être émises comme ML-DSA dans la frontière du module FIPS ou si le module doit être remplacé d'abord. Presque chaque grande entreprise trouvera au moins un modèle d'HSM sur cette liste qui nécessite un remplacement matériel, et le délai sur le remplacement matériel est la contrainte limitante sur le calendrier PQC pour cette organisation.

Cinq mythes courants

Cinq affirmations reviennent dans les briefings fournisseurs, les conférences et les revues d'architecture internes. Chacune contient un noyau de vérité et chacune est dangereuse à répéter sans qualification.

• « Les certs PQC sont 10x plus gros. » Partiellement vrai. Une signature ML-DSA-87 fait 4627 octets contre 64-72 octets pour ECDSA P-256, un ratio 60-70x. Mais la taille du certificat dépend de la signature et de la clé publique ensemble, et la plupart des métadonnées sont partagées. Une feuille ML-DSA-65 pure est d'environ 5,5 Ko contre 1,4 Ko en classique, plus proche de 4x. Les signatures SLH-DSA vont de 7856 octets (128s) à 49856 octets (256f) et peuvent atteindre 10x dans le pire cas.
• « On a fini parce qu'on utilise X25519MLKEM768. » Faux. Le KEM est post-quantique-sûr ; le certificat serveur est encore signé avec ECDSA ou RSA, tous deux vulnérables à Shor. Un adversaire harvest-now-decrypt-later ne peut pas déchiffrer le trafic de session symétrique, mais les clés de signature long terme restent une cible. L'authentification PQC est une migration séparée et plus dure.
• « L'hybride convient pour toujours. » Faux. L'hybride est une construction transitoire qui achète la rétrocompatibilité et la défense en profondeur pendant une phase où ML-KEM et ML-DSA ont moins d'une décennie de cryptanalyse publique. À mesure que la confiance dans les constructions lattice s'accumule et que les populations de parties utilisatrices migrent, l'hybride impose une pénalité permanente de taille et de performance que l'industrie ne portera pas indéfiniment. Attendez-vous à une voie RFC PQC pure pour TLS d'ici 2030.
• « Les racines ont besoin de rotation maintenant. » Faux, et dangereux. Faire tourner une CA racine avant que la flotte de parties utilisatrices ne puisse vérifier le nouvel algorithme de signature produit des pannes, pas de la sécurité. Ce dont les racines ont besoin est une conception crypto-agile : plans de succession définis, racines ML-DSA parallèles cross-signées pour l'amorçage de trust store, et répétition opérationnelle de la rotation. Le contrôle décisif sur la migration racine est la distribution du trust store, pas la génération de clé.
• « Migration PQC = mise à jour de bibliothèque. » Faux. La mise à jour de bibliothèque est les 5 % les plus faciles du travail. Les 95 % durs sont l'inventaire (CBOM), la matrice de compatibilité côté vérificateur, la roadmap HSM et KMS, la reconfiguration de CA de politique, la refonte de modèle de certificat, le pipeline de surveillance, la communication aux parties utilisatrices et le plan de rollback pour chaque étape.

Où s'inscrit Evertrust

Le cadrage honnête du déploiement PQC 2026 est que les certificats hybrides et l'échange de clé hybride sont la bonne réponse pour les trois à cinq prochaines années, et ils ne sont pas la même chose que post-quantique. Les traiter comme s'ils l'étaient produit deux modes de défaillance à parts égales : la complaisance, lorsque les équipes déclarent victoire après avoir déployé X25519MLKEM768 sur un seul load balancer ; et la paralysie, lorsque les équipes refusent de bouger sur l'hybride parce que ce n'est pas du PQC pur.

La posture correcte est opérationnelle : instrumentez la négociation, séquencez la migration, surveillez l'inventaire et concevez les racines pour l'agilité, pas pour la rotation.

Cette posture nécessite une plateforme de gestion de certificats qui émet des feuilles composites ML-DSA + ECDSA aux côtés de feuilles classiques depuis la même CA de politique, exporte des enregistrements CycloneDX 1.6 d'actifs cryptographiques pour chaque certificat et chaque clé, s'intègre avec des HSM à travers les états de validation CMVP, et fait apparaître le groupe TLS négocié et l'algorithme de signature comme télémétrie de première classe.

Evertrust est construit pour exactement cette transition : émission hybride depuis des CA de politique qui comprennent déjà les OID composites, découverte automatisée de certificats classiques éligibles à la réémission hybride, intégrations HSM à travers la file CMVP actuelle, et reporting continu qui mappe aux quatre métriques PQC décrites ci-dessus.

La roadmap PQC n'est pas une fonctionnalité produit future ; c'est un programme opérationnel actuel. Pour voir comment cela se branche, explorez Evertrust PKI et la gestion de certificats.