Que sont les certificats Merkle Tree (MTC) ?
23 juillet 2026
Les certificats Merkle Tree pourraient transformer les opérations de gestion des certificats à mesure que la durée de vie des certificats diminue et que les signatures post-quantiques se généralisent. Découvrez pourquoi l’automatisation, la visibilité et la flexibilité cryptographique prennent de plus en plus d’importance.
Le secteur des infrastructures à clé publique (PKI) sur le Web public évalue actuellement un nouveau modèle de certificat appelé « certificats à arbre de Merkle » (MTC). Bien que la norme soit encore en cours d’élaboration au sein du groupe de travail PLANTS de l’IETF, cette proposition suscite un vif intérêt car elle vise à relever un défi auquel le secteur est confronté à mesure que la cryptographie post-quantique (PQC) devient une réalité : comment maintenir des opérations de gestion des certificats efficaces et évolutives lorsque la taille des signatures cryptographiques augmente considérablement.
Pour la plupart des organisations, l’essentiel n’est pas de savoir si les MTC deviendront finalement le modèle dominant, mais plutôt que les tendances opérationnelles qui sous-tendent leur développement se dessinent déjà clairement.
Les MTC constituent une forme proposée de certificat X.509 qui intègre l'enregistrement public directement dans le modèle de certificat. Au lieu de s'appuyer uniquement sur les signatures de certificats traditionnelles, les certificats peuvent être validés grâce à des preuves de leur présence au sein d'une structure d'arbre de Merkle enregistrée publiquement. Cette approche vise à réduire la charge liée à des durées de vie des certificats plus courtes et à des signatures post-quantiques plus volumineuses, tout en préservant la sécurité et la transparence.
Il est important de noter que les MTC ne remplacent pas la norme X.509. La proposition actuelle les décrit comme une nouvelle forme de certificat X.509 plutôt que comme un système d’infrastructure à clé publique (PKI) entièrement distinct.
L’un des messages les plus forts qui ressort des discussions sur les MTC est l’attente croissante d’une réduction continue de la durée de vie des certificats. Les certificats TLS doivent être raccourcis selon une approche progressive, ce qui aboutira à une durée de vie de 47 jours d’ici 2029. En ce qui concerne les MTC, les discussions ont porté sur des périodes de validité de sept jours, mais cette durée n’est pas encore une exigence définitive dans la norme actuelle. L’orientation opérationnelle est néanmoins claire : le remplacement plus fréquent des certificats renforce l’importance de processus fiables et reproductibles.
Pour les équipes chargées des certificats, les MTC relèvent autant de l’exploitation que de la cryptographie. Les renouvellements fréquents ne peuvent pas reposer sur des feuilles de calcul, des scripts ou des outils fragmentés, ni sur des installations manuelles ponctuelles. Les organisations ont besoin d’une automatisation couvrant l’ensemble du cycle de vie des certificats, notamment :
La gestion automatisée du cycle de vie des certificats (CLM) peut aider les organisations à réduire les risques opérationnels tout en se préparant aux changements de formats de certificats, de durées de validité et de normes cryptographiques. Les organisations qui ont déjà mis en place une solution CLM seront nettement mieux placées pour s’adapter aux futurs modèles de certificats.
Les MTC pourraient rendre l’automatisation encore plus importante, car les opérations liées aux certificats pourraient impliquer la récupération, le déploiement, la surveillance et la mise à disposition de plusieurs types de certificats devenant disponibles à des moments différents.
À mesure que la durée de vie des certificats ne cesse de diminuer, les protocoles d’inscription et de renouvellement automatisés prennent de plus en plus d’importance.
La proposition actuelle relative aux MTC décrit des certificats autonomes et des certificats liés à des repères, qui deviennent disponibles à des moments différents et peuvent devoir être fournis en fonction de ce que la partie qui s'y fie prend en charge. Gérer ce processus manuellement serait difficile à grande échelle. Que les organisations utilisent finalement ACME ou d’autres technologies d’automatisation, le principe sous-jacent est clair : les MTC pourraient rendre la gestion manuelle des certificats de plus en plus impraticable.
Même lorsque les MTC seront largement adoptés, les entreprises ne doivent pas s’attendre à une transition immédiate.
Les applications, appareils, infrastructures et systèmes embarqués existants évolueront probablement à des rythmes différents. Par conséquent, les organisations pourraient devoir gérer des certificats signés directement parallèlement aux nouvelles formes de certificats MTC, à mesure que la prise en charge évolue.
En effet, la proposition actuelle relative aux MTC décrit deux formats de certificat pour une même entrée de journal sous-jacente : un certificat initial autonome et un certificat plus petit, lié à un repère, qui devient disponible après l’attribution du repère concerné. Comme le format lié au repère ne fonctionne qu’avec des parties de confiance suffisamment à jour, les serveurs devront peut-être conserver les deux formats et sélectionner celui qui convient pour chaque connexion. Cela ajoute une complexité opérationnelle qui sera difficile à gérer sans automatisation.
La leçon la plus importante à tirer du débat sur les MTC n’a peut-être rien à voir avec les MTC eux-mêmes.
Que le secteur adopte finalement les MTC, un autre format de certificat post-quantique ou une combinaison de plusieurs approches, les organisations doivent être capables de s’adapter rapidement à l’évolution des normes. La feuille de route post-quantique de Google met explicitement l’accent sur l’agilité cryptographique en tant que capacité fondamentale pour l’avenir.
Les organisations devraient se concentrer sur :
L’avenir de la gestion des certificats pourrait passer par les MTC, mais les organisations les mieux préparées à cet avenir seront celles qui investissent dès aujourd’hui dans l’automatisation, la visibilité et l’agilité cryptographique.
23 juillet 2026