Signatures post-quantiques et certificats TLS publics : des vérifications de maturité distinctes

Ce que c'est

État au 25 octobre 2026. Le NIST a publié FIPS 204, qui spécifie ML-DSA, et FIPS 205, qui spécifie SLH-DSA, le 13 août 2024. Ce sont des normes de signature numérique. Vérifier de nouveau les errata du NIST, le statut de publication de l'IETF et les exigences applicables du CA/Browser Forum avant de planifier des changements de certificats. La page de présentation de FIPS 204 comporte une note de planification du 31 juillet 2026 sur des problèmes mineurs destinés à être corrigés ultérieurement.

La normalisation de l'algorithme, l'encodage des certificats, l'authentification TLS et l'acceptation dans les systèmes de confiance publics sont des étapes distinctes. Un échange de clés post-quantique ne transforme ni la clé publique d'un certificat existant ni la signature de son émetteur en signature post-quantique.

Pourquoi c'est important

Une norme d'intégration à X.509 existe déjà : la RFC 9881, publiée en octobre 2025, définit les conventions ML-DSA pour les certificats et les listes de révocation de certificats. Elle couvre la variante pure de ML-DSA et exclut HashML-DSA de ce profil. Il serait donc incorrect d'affirmer que tous les travaux sur les certificats ML-DSA en sont encore au stade de propositions non publiées.

L'intégration à TLS a son propre état d'avancement. Le suivi de l'IETF classe draft-ietf-tls-mldsa-06, daté du 11 septembre 2026, comme un travail en cours dans la file d'attente du RFC Editor ; ce suivi a été mis à jour pour la dernière fois le 12 octobre 2026. Cela ne signifie pas qu'une RFC TLS est déjà publiée.

Pour les certificats TLS conventionnels reconnus par les systèmes de confiance publics, les Baseline Requirements du CA/Browser Forum, version 2.3.1 du 4 octobre 2026, limitent encore les encodages concernés aux algorithmes classiques. La section 7.1.3.1 autorise les clés publiques de sujet RSA et ECDSA, et la section 7.1.3.2 spécifie des encodages de signature classiques. Aucune de ces sections ne fournit de profil d'émission ML-DSA ou SLH-DSA. Cela explique pourquoi les certificats classiques restent requis dans ce cadre ; il ne s'agit pas d'un état des lieux de toutes les autorités de certification, de tous les systèmes de confiance expérimentaux ou de toutes les PKI privées.

Comment l'appliquer

• Suivre séparément l'établissement de clé, la clé publique du sujet du certificat, la signature de l'émetteur et l'authentification lors de la négociation. Exiger des preuves pour chaque affirmation au lieu d'accepter une étiquette post-quantique unique pour toute la connexion.
• Pour une expérimentation avec un certificat ML-DSA, identifier la variante exacte de l'algorithme et le profil du certificat. La RFC 9881 fournit la base d'encodage ; elle n'établit pas à elle seule l'acceptation par un programme public de certificats racines ou par tous les clients.
• Avant un déploiement public, vérifier les TLS Baseline Requirements en vigueur, la politique de l'autorité de certification concernée et les politiques de confiance des clients visés. Suivre les changements d'algorithmes approuvés et leurs dates d'entrée en vigueur. Un projet de norme ou un identifiant d'algorithme attribué ne suffit pas à établir que le déploiement est prêt.
• Distinguer les essais en PKI privée des hypothèses sur l'émission publique. Consigner les résultats de validation de chaîne, d'authentification, de renouvellement, de révocation et d'interopérabilité pour les logiciels réellement utilisés. Les TLS Baseline Requirements applicables aux certificats publics excluent explicitement de leur périmètre les PKI d'entreprise à usage exclusivement interne.
• Suivre les corrections de FIPS 204, la page de publication de FIPS 205, les errata des RFC et le statut des documents du groupe de travail TLS. Mettre à jour l'inventaire lorsque le comportement déployé change, et pas simplement à l'annonce d'une spécification.

Pièges

Ne pas déduire la prise en charge des signatures de celle de l'échange de clés, ni considérer la liste d'algorithmes d'une bibliothèque comme une preuve de confiance des navigateurs. De même, la normalisation de SLH-DSA par le NIST n'établit pas un profil de certificat TLS public. Aucune date universelle de déploiement dans les navigateurs, aucune échéance de migration des autorités de certification ni aucune étendue de déploiement expérimental n'est affirmée ici. Ces points nécessitent des éléments probants distincts et à jour issus de sources primaires.