Bâtir une autorité de certification post-quantique avec les certificats MTC (Merkle Tree Certificate)

Lorsque vous saisissez une adresse dans un navigateur, comment savez-vous que vous vous connectez au bon site web ? L’infrastructure à clés publique du web (Web Public Key Infrastructure, Web PKI) est un écosystème complexe et distribué de politiques, de protocoles et d’opérateurs d’infrastructure qui vous permet d’avoir la certitude de ne pas être redirigé vers un site incorrect ou malveillant. Au cours des dernières décennies, cet écosystème a connu des changements considérables. L’un d’eux réside dans l’apport de la transparence : l’obligation désormais incontournable d’enregistrer tous les certificats dans des registres publics de transparence des certificats (CT, Certificate Transparency). Cet écosystème fait désormais face à un autre défi : l’arrivée imminente de l’ordinateur quantique, qui nous contraint à migrer vers la cryptographie post-quantique (PQ) d’ici 2029.

Cette transition n’a rien de simple : la simple substitution de la cryptographie post-quantique aux algorithmes actuels des certificats à l’échelle d’Internet entraînerait une dégradation inacceptable des performances. Cette situation exige une nouvelle approche de l’infrastructure Web PKI, permettant de traiter la transparence comme une propriété native, et non pas comme un module complémentaire, et de concevoir un nouveau système capable d’adapter efficacement l’ampleur du déploiement des signatures post-quantiques.

Après avoir remporté un large soutien dans l’industrie, les certificats MTC (Merkle Tree Certificate) se sont imposés comme la voie à suivre. Cette année, au terme d’un déploiement expérimental réussi avec Chrome, Cloudflare avance à pleine vitesse sur les certificats MTC.

Suite à l’annonce d’aujourd’hui, dans laquelle Cloudflare déclare son intention de devenir une autorité de certification (Certification Authority, CA), nous sommes ravis d’annoncer que cette autorité de certification prendra en charge l’émission de certificats MTC, avec l’objectif d’une inclusion début 2027 au sein du nouveau programme de clés racine à l’épreuve de l’informatique quantique (Quantum-Resistant Root Store) lancé par Chrome. Fidèles à notre mission de contribuer à bâtir un Internet meilleur, et dans le respect de la tradition de Cloudflare consistant à offrir gratuitement la cryptographie la plus robuste qui soit, nous proposerons l’émission standard de certificats MTC sans frais. Disposer d’une autorité de certification capable d’émettre à la fois des certificats classiques et des certificats MTC nous permet d’adopter par défaut la méthode d’authentification la plus sécurisée disponible, et ainsi, de proposer à une grande partie d’Internet une approche simple et performante de l’évolution vers la cryptographie post-quantique.

L’écosystème de confiance actuel

Pour comprendre en quoi les certificats MTC changent la donne, commençons par expliquer quelques notions sur l’établissement de la confiance sur le web aujourd’hui.

Côté client, les navigateurs (dans ce contexte, les « clients TLS ») gèrent des programmes racine qui définissent un ensemble de politiques que les autorités de certification doivent respecter pour être reconnues de confiance. Côté serveur, les autorités de certification se comportent comme les garants de la confiance : elles exploitent une infrastructure d’émission de certificats au sein de laquelle elles valident la propriété des domaines et confirment le lien existant entre un nom de domaine et une clé publique qui démontre la propriété de ce domaine.

Mais comment vérifier que les autorités de certification respectent ces règles ? C’est là qu’intervient la transparence des certificats (Certificate Transparency, CT), qui rend l’émission de certificats publiquement vérifiable. Lorsqu’une autorité de certification émet un certificat, elle doit également le soumettre à au moins deux registres publics. Cloudflare exploite la famille de registres CT Nimbus depuis 2016 et lance aujourd’hui Raio, une nouvelle famille de registres CT statiques.

Bien que l’écosystème CT rende les certificats consultables par tous, cela ne garantit pas pour autant qu’ils ont été correctement émis ou qu’ils sont sûrs d’utilisation. La surveillance pèse ici dans la balance, en comparant les entrées de ces enregistrements avec les informations qu’attendaient les propriétaires de domaines et en signalant toute activité suspecte. Cloudflare a lancé le programme Certificate Transparency Monitoring en 2019 et l’a récemment proposé en disponibilité générale. Nous publions également des mesures à grande échelle sur les certificats sur la page Certificate Transparency dans Radar (anciennement appelée Merkle Town).

À mesure que les entreprises commenceront à mettre à niveau leurs serveurs pour adopter l’authentification post-quantique, la surveillance de la transparence des certificats jouera un rôle encore plus important dans la détection d’éventuelles attaques par rétrogradation post-quantique. Les propriétaires de domaines ayant accompli la migration vers l’authentification post-quantique devront surveiller les registres de transparence des certificats pour détecter l’émission inattendue de certificats hérités, afin d’éviter que les clients ne basculent vers un schéma de rétrogradation malveillant.

Un des problèmes affectant le système actuel réside dans l’ajout a posteriori de la transparence, qui entraîne des problèmes de déploiement de grande ampleur. Les certificats sont fréquemment enregistrés plusieurs fois, sous différentes formes, dans plusieurs registres distincts, contraignant les outils de surveillance à télécharger et à traiter chaque registre afin de ne manquer aucune émission. Cette démarche peut être coûteuse, freinant l’émergence d’un ensemble diversifié d’opérateurs de registres à l’échelle d’Internet. Selon nos estimations, les signatures post-quantiques multiplieront par 40 le volume de données que devront stocker les journaux de transparence des certificats. Ce défi d’évolutivité et le défaut d’alignement des incitations qui en découle sont au cœur de la problématique du déploiement à grande échelle de la cryptographie post-quantique.

La problématique du déploiement à grande échelle de la cryptographie post-quantique

Nous avons écrit un nombre considérable d’articles sur les difficultés que comporte le déploiement à grande échelle de la cryptographie post-quantique, mais pour résumer nos réflexions : pour prendre en charge l’authentification des serveurs à l’échelle d’Internet, l’infrastructure Web PKI doit authentifier environ un milliard de serveurs TLS sans précharger la clé publique de chaque serveur sur chaque client. Historiquement, les autorités de certification ont résolu ce problème en utilisant des chaînes de certification comme un mécanisme de distribution de la confiance. Au fil du temps, toutefois, des ajouts tels que les vérifications de révocation de clés et la transparence des certificats ont entraîné l’accumulation des clés publiques et de signatures – cinq signatures et deux clés lors d’une négociation TLS typique. Les signatures post-quantiques sont environ 40 fois plus volumineuses que les signatures classiques, entraînant d’importantes surcharges de données, dont la gestion à grande échelle s’avérerait coûteuse pour les clients, les autorités de certification, les registres et les outils de surveillance.

C’est là qu’interviennent les certificats Merkle Tree Certificates (MTC), une spécification en cours d’élaboration par le groupe de travail PLANTS de l’IETF, qui décrit une architecture permettant d’obtenir des certificats post-quantiques compacts et efficients. Les certificats MTC regroupent les certificats dans un arbre de Merkle à ajout exclusif (« append only »), permettant à une autorité de certification de signer la racine de cet arbre plutôt qu’une multitude de certificats individuels. Les navigateurs ou autres clients peuvent ainsi vérifier un certificat au moyen d’une preuve d’inclusion compacte (c’est-à-dire une séquence de hachages cryptographiques) adossée à une tête d’arbre signée, au lieu de devoir valider chaque certificat individuellement. Une idée fondamentale des certificats MTC réside dans le postulat « n’enregistrez pas ce que vous émettez, émettez en enregistrant ». En couplant l’émission et l’enregistrement, la transparence devient une condition intrinsèque de fonctionnement, et non un simple module complémentaire.

Le rôle d’une autorité de certification dans une PKI repensée

Nous développons notre capacité à émettre des certificats MTC comme une facette indissociable de la création de l’autorité de certification Cloudflare. Cela exige d’assurer le suivi des nouvelles exigences des programmes de clé racine post-quantique et de concevoir une pile logicielle d’émission et de réplication (« mirroring »), tout en développant les infrastructures, les opérations et les fonctions de conformité de l’autorité de certification traditionnelle. C’est un défi de taille !

L’avantage est que nous pouvons hiérarchiser, dès le premier jour, les exigences et l’architecture de cette nouvelle infrastructure PKI post-quantique, en structurant notre environnement d’une manière fidèle aux valeurs et au réseau mondial de Cloudflare, avec l’ambition de rester aussi transparents que possible pendant cette nouvelle aventure.

Examinons l’architecture mise à jour pour les certificats MTC :

Si vous la comparez à l’écosystème d’une autorité de certification traditionnelle, vous remarquerez que les responsabilités d’une autorité de certification restent sensiblement les mêmes : valider le contrôle d’un domaine, lier ce domaine à une clé publique, puis émettre des certificats. La principale différence réside dans le fait que, dans l’écosystème MTC, au lieu de signer directement les certificats, puis de les enregistrer, l’autorité de certification gère désormais un registre de transparence adossé à un arbre de Merkle, où une preuve d’inclusion du certificat dans l’arbre sert d’ancre de confiance. Les autorités de certification exploiteront également des cosignataires de réplication (« mirroring cosigners ») qui conservent une copie des registres d’émission, en vérifient la cohérence en ajout exclusif et garantissent la transparence et la disponibilité de ces registres pour l’ensemble de l’écosystème.

Émettre des certificats MTC

Les certificats MTC se présentent sous deux formes, pouvant toutes deux être encodées dans le format de certificat X.509 que les logiciels clients reconnaissent aujourd’hui, avec simplement un algorithme de signature « inhabituel ». Sous sa forme autonome (« standalone »), la valeur de signature du certificat contient une tête d’arbre cosignée d’un registre d’émission et une preuve d’inclusion (c’est-à-dire une suite de hachages) démontrant que le certificat est bien contenu dans ce registre. Si les clients peuvent obtenir les têtes d’arbre cosignées hors bande (par exemple, via un mécanisme de mise à jour du navigateur), le certificat peut alors être servi sous une forme relative à un point de repère (« landmark-relative »). Dans ce cas, la valeur de signature consiste en la preuve d’inclusion légère, sans aucune signature post-quantique volumineuse.

Pour simplifier, prenons l’exemple de l’émission d’un certificat autonome. Lorsqu’un site web requiert un certificat pour son domaine, il peut le demander auprès d’une autorité de certification via le protocole ACME (Automatic Certificate Management Environment), qui gère les demandes de certificats, la validation du contrôle de domaine et les flux d’émission. L’infrastructure ACME de Cloudflare sera un fork de Boulder, le logiciel ACME largement déployé et éprouvé sur lequel repose Let’s Encrypt. Let’s Encrypt développe activement la prise en charge des certificats MTC dans Boulder, et nous avons l’intention de gérer notre propre fork qui intègre ces modifications en amont ainsi que des modifications spécifiques à Cloudflare, tout en contribuant, autant que possible, à l’initiative en amont.

Lorsque l’autorité de certification MTC reçoit une demande d’émission de certificat, le serveur ACME de l’autorité de certification vérifie que le serveur demandeur contrôle effectivement le domaine. Si ces vérifications réussissent, l’autorité de certification sérialise ces données et les ajoute à un registre à ajout exclusif.

Après avoir ajouté l’entrée MTC à son registre d’émission, l’autorité de certification calcule l’état mis à jour du registre, puis signe un point de contrôle (« checkpoint ») correspondant à cet état. Ce point de contrôle atteste que l’autorité de certification a émis chaque entrée incluse dans l’arbre de Merkle du registre jusqu’à ce moment précis.

L’autorité de certification envoie ensuite son état de registre mis à jour et son nouveau point de contrôle à un cosignataire de confiance, qui conserve durablement une copie du registre d’émission de l’autorité de certification et vérifie que chaque nouvel état est conforme au principe d’ajout exclusif, reste cohérent avec l’arbre précédent et est correctement formé. Cette cosignature supplémentaire garantit aux clients et aux outils de surveillance qu’un tiers de confiance a observé le même état du registre et a vérifié que l’autorité de certification ne présente pas des visions divergentes de l’émission aux différentes parties de l’écosystème. Elle garantit également que les certificats émis restent disponibles aux fins de la surveillance, même si le registre d’émission de l’autorité de certification devient indisponible.

La politique provisoire du programme de clés racine à l’épreuve de l’informatique quantique (Quantum-Resistant Root Program) de Chrome exige au moins deux cosignatures : l’une provenant d’un cosignataire de réplication (« Mirroring Cosigner ») reconnu par Chrome et exploité par une organisation distincte, et l’autre provenant de l’autorité de certification MTC émettrice elle-même. Nous gérerons donc des systèmes de réplication pour d’autres autorités de certification pilote et exigerons au moins une cosignature indépendante sur nos propres certificats émis.

Cloudflare intégrera son cosignataire de réplication à Azul, notre registre de transparence open source écrit en Rust et, pour une interopérabilité maximale, implémentera le protocole tlog mirror de c2sp.

Enfin, après avoir reçu avec succès la cosignature d’un cosignataire de réplication, l’autorité de certification assemble un certificat MTC avec les cosignatures, la clé publique du serveur et une preuve d’inclusion. Elle transmet ensuite ce certificat MTC au serveur, qui peut alors l’utiliser pour l’établissement de connexions TLS.

Distribuer efficacement les signatures post-quantiques : l’optimisation par points de repère (« landmarks »)

Bien que les certificats autonomes soient pleinement fonctionnels, ils transmettent encore des signatures post-quantiques volumineuses lors de la négociation TLS, ce qui limite leur efficacité. Les véritables gains de performance qu’offre l’architecture des certificats MTC proviennent des certificats relatifs à un point de repère (« landmark-relative »).

Au lieu de transmettre des cosignatures incluses dans chaque certificat, les autorités de certification peuvent désigner comme point de repère (« landmark ») une séquence de sous-arbres englobant l’ensemble des certificats actifs dans le registre, puis diffuser ces sous-arbres (ainsi que les données permettant de les authentifier) auprès des clients via un service de mise à jour hors bande. Lors d’une négociation TLS, l’authentification effective auprès du serveur se déroule lorsque le navigateur vérifie que les données de certificat du serveur (notamment son nom de domaine et sa clé publique) figurent bien dans un sous-arbre de confiance du registre de l’autorité de certification. Si la preuve d’inclusion relie ce certificat à un point de repère (« landmark ») cosigné, et si la clé publique prouve ensuite la propriété lors de la négociation TLS, le client sait qu’il communique avec le bon serveur.

En transmettant périodiquement ces signatures et ces métadonnées d’arbre aux clients TLS hors bande, un nombre restreint de signatures par lots MTC peut permettre de couvrir efficacement des milliards de certificats émis par une autorité de certification donnée. Bien que les repères se montrent plus efficaces à grande échelle, ils n’éliminent pas pour autant le besoin de certificats MTC autonomes : des clients peuvent avoir été récemment installés, être hors ligne ou ne pas disposer de la mise à jour du point de repère (« landmark ») concerné. C’est pourquoi il est important que les serveurs conservent une solution de secours, sous la forme d’un certificat autonome.

Les certificats MTC dans la réalité : résultats de notre expérience avec Chrome

Cette année, nous avons réalisé une expérience avec Chrome afin de tester la faisabilité des certificats MTC entre un client et un serveur. Nous avons exploité une « autorité de certification d’amorçage » (concrètement, une fausse autorité de certification simulant le pipeline d’émission) qui émettait des certificats MTC adossés à une chaîne de certification traditionnelle pour une sélection de domaines Cloudflare hébergés sur l’offre « gratuite » de Cloudflare, et nous avons délivré ces certificats à 50 % des utilisateurs de Chrome Beta 146. Pendant cette expérience, nous avons délivré avec succès des milliards de certificats MTC.

En ce qui concerne TLS, nous avons constaté que le cas d’usage est assez efficace : avec un certificat relatif à un point de repère (« landmark-relative »), la négociation n’a besoin de transmettre qu’une clé publique, une signature et une preuve d’inclusion de moins de 1 ko. Pendant l’expérience, nous avons basculé vers la chaîne de certification traditionnelle, plutôt que vers un certificat autonome dans les cas où nous ne pouvions pas négocier un certificat relatif à un point de repère avec le client. Au regard de la transparence des certificats (Certificate Transparency, CT), les certificats MTC modifient également les propriétés d’évolutivité de la transparence : le registre n’a besoin de conserver que des hachages des clés publiques ; il n’y a pas de signature par entrée, et la signature sur la tête d’arbre couvre l’ensemble du registre. Ceci évite la prolifération massive des certificats, car le registre d’émission de l’autorité de certification devient la source unique de vérité pour tous les certificats émis, et les consommateurs de registres n’ont besoin de récupérer qu’une seule copie de chaque certificat.

En conclusion, les certificats MTC fonctionnent vraiment ! En médiane, l’utilisation d’un certificat MTC avec point de repère MTC est 9 % plus rapide qu’une chaîne de signatures classique (il est vrai que la majeure partie de ce gain de performance est liée à l’élimination des certificats intermédiaires). Et parce que nous avons testé les certificats MTC avec des signatures classiques, nous anticipons une amélioration encore plus grande avec les signatures post-quantiques. Forts de ces résultats satisfaisants et du niveau de collaboration intersectorielle autour des certificats MTC au sein du groupe de travail PLANTS de l’IETF, nous avons commencé à mettre fin à cette expérience le mois dernier (août 2026).

L’avenir des certificats MTC

Nous sommes ravis que notre expérience avec Chrome ait permis de démontrer le fonctionnement des certificats MTC dans la pratique, et nous sommes particulièrement enthousiastes à la perspective d’émettre des certificats en tant qu’autorité de certification à part entière.

Il reste cependant des questions plus vastes auxquelles nous ne pourrons répondre qu’en réalisant cette grande expérience à l’échelle de l’écosystème PKI dans son ensemble. Les outils de surveillance indépendants seront-ils capables de consommer et de vérifier les registres d’émission de certificats MTC au volume de la production ? Une multitude d’autorités de certification et de cosignataires émergera-t-elle pour assurer la diversité indispensable à la résilience du système ? Comment les navigateurs doivent-ils équilibrer les gains de performance des certificats MTC légers basés sur les points de repère (« landmarks ») et les chemins de secours indispensables pour les clients sans points de repère récents ? Les certificats MTC s’imposent comme l’architecture de référence pour l’authentification post-quantique, mais prouver leur efficacité à l’échelle d’Internet et au volume de la production exigera l’implication d’un ensemble diversifié de programmes de clés racine, d’éditeurs de navigateurs, d’autorités de certification, de cosignataires de réplication, d’outils de surveillance et de la communauté dans son ensemble.

C’est un honneur pour nous de participer à cette prochaine phase de l’écosystème Web PKI, et nous prenons très au sérieux la responsabilité d’exploiter une infrastructure d’autorité de certification. Les autorités de certification occupent une position privilégiée au sein de l’écosystème de confiance : navigateurs, propriétaires de domaines et utilisateurs du quotidien comptent sur elles pour assurer correctement la validation des identités, protéger les clés de signature, respecter les politiques et fonctionner de manière fiable. Avant que l’autorité de certification de Cloudflare puisse obtenir la confiance des navigateurs pour l’émission de certificats MTC, nous devrons déposer notre candidature au programme de programme de clés racine à l’épreuve de l’informatique quantique (Quantum Resistant Root Store) de Chrome et nous soumettre à un processus d’évaluation rigoureux. Nous accueillons cet examen avec plaisir et nous entendons nous montrer à la hauteur de toutes les autres autorités de certification qui assument la responsabilité de contribuer à la sécurité d’Internet. Nous espérons que d’autres autorités de certification émergeront pour soutenir l’adoption des certificats MTC, et nous sommes impatients de collaborer avec tout navigateur souhaitant déployer ces certificats.