Résumé

  • Le RFC 9802 normalise les identifiants et les encodages de HSS, XMSS et XMSSMT dans les certificats et CRL X.509 ; le certificat ne contient pas l’historique des clés à usage unique déjà consommées.
  • Une signature peut être mathématiquement valide alors que l’état privé a été restauré trop loin en arrière ou s’est divisé entre deux appareils. La continuité de cet état exige donc un registre monotone et vérifiable séparé.

Le scénario que la chaîne de certificats ne voit pas

Une autorité de certification sauvegarde lundi son équipement de secours. L’image contient la clé et indique que le prochain indice disponible est 41 200. Le signataire principal émet ensuite des certificats et des listes de révocation jusqu’à 41 259. Vendredi, une panne pousse l’équipe à restaurer l’image de lundi. L’équipement signe un autre objet avec l’indice 41 200.

Chaque objet peut passer une vérification isolée. La clé publique correspond, l’identifiant d’algorithme est exact et l’encodage est conforme. Le fait destructeur n’est pas dans un seul fichier : il réside dans la relation entre deux messages différents signés avec la même clé OTS.

Le RFC 9802, publié sur la voie normative de l’IETF en juin 2025, explique qu’une telle réutilisation rend la fabrication de faux calculatoirement réalisable. Il définit les OID, les structures ASN.1, les clés publiques, les signatures et les usages de clé permettant à HSS, XMSS et XMSSMT d’entrer dans l’infrastructure X.509 pour les certificats et les CRL. La fiche officielle et l’historique IETF confirment ce périmètre.

Ce périmètre est essentiel mais limité. L’OID indique au vérificateur quel algorithme interprète les octets. Il ne lui indique pas combien d’états du signataire ont existé, ni si une ancienne copie a redémarré.

La clé privée comprend une chronologie

Avec une signature sans état, la sauvegarde est souvent pensée comme la conservation d’un secret. Pour une signature fondée sur un hachage avec état, l’actif à protéger comprend aussi la chronologie irréversible des éléments à usage unique.

Le RFC 8554 impose qu’une clé privée LM-OTS signe au plus un message. HSS organise un grand nombre de ces clés dans une hiérarchie. Le RFC 8391 définit XMSS et XMSSMT autour de WOTS+, d’arbres de Merkle et d’adresses qui séparent les composants. Le budget peut être immense ; il demeure fini, et l’unicité de la consommation reste une condition de sécurité.

Une représentation opérationnelle correcte ressemble donc moins à « clé privée » qu’à « clé + prochain indice validé + réservations + signatures libérées + états abandonnés + époque de reprise ». Perdre le secret interdit de signer. Perdre la chronologie peut permettre de signer avec succès de manière dangereuse.

La recommandation NIST SP 800-208 encadre LMS/HSS et XMSS/XMSSMT et limite génération et signature à des modules cryptographiques matériels. Le RFC 9802 demande de prendre ces exigences en compte. Il recommande aussi d’enregistrer les signatures ou indices utilisés, de vérifier ce registre avant toute nouvelle libération, de réserver des états futurs et de garder un volume auditable. Une réutilisation détectée doit geler la signature, déclencher un réexamen et peut conduire à la révocation.

Le certificat n’accomplit aucune de ces actions. Il ne fait ni réservation, ni verrouillage, ni rapprochement, ni arbitrage de restauration.

La redondance change de sens

Copier une clé sans état sur deux équipements contrôlés peut améliorer la disponibilité. Appliquer mécaniquement cette recette à HSS ou XMSS crée un risque de double consommation. Le RFC 9802 avertit que la duplication ou la restauration ordinaires produiront très probablement une réutilisation OTS si la cohérence de l’état n’est pas garantie.

Le retour arrière rouvre des indices consommés après la sauvegarde. Le fonctionnement parallèle donne à deux appareils la même suite disponible. L’ambiguïté d’acquittement ajoute un troisième cas : un signataire persiste son nouvel état et calcule une signature, mais l’orchestrateur perd la réponse et recommence ailleurs. L’absence de preuve de livraison ne rend pas l’indice neuf.

La haute disponibilité doit donc reposer sur une autorité d’état unique, des plages irrévocablement séparées, des baux clôturés, un compteur monotone matériel ou une cérémonie de reprise établissant que le premier indice restauré dépasse toute réservation antérieure. Chaque architecture a un coût. L’invariant commun est qu’aucun chemin ne doit pouvoir revenir dans le passé.

Les limites de la validation

Le RFC 5280 définit les chemins de certification, les contraintes, les usages et les CRL. Le RFC 9802 rend les nouveaux algorithmes interprétables dans ce cadre. Une validation réussie prouve que la signature présentée correspond à la clé et à l’algorithme déclarés ; avec une chaîne et des informations de révocation adéquates, elle soutient aussi une décision locale de confiance.

Elle ne révèle pas les signatures jamais publiées, les réservations concurrentes, les clichés de disque, les appareils de secours ou les restaurations. Elle ne prouve pas que le budget suffira pendant toute la validité du certificat. Elle ne distingue pas un historique intact d’une bifurcation dont le second objet n’est pas encore parvenu au vérificateur.

Il faut séparer les reçus : octets analysables, signature valide, chemin accepté, indice réservé une seule fois, état persisté, absence de plage concurrente, inventaire des objets libérés, puis résultat de l’application. Les trois premiers sont visibles au vérificateur X.509. Les suivants appartiennent à l’opérateur du signataire.

La primauté du code en fonctionnement de Lu Heng fournit ici une discipline : le document coordonne l’interopérabilité, alors que l’unicité réellement consommée doit survivre dans les systèmes. Le principe de spécification initiale minimale et de décision locale attribue correctement les rôles : encodage commun au standard, continuité et reprise à l’opérateur. L’argument de la couche de réalité empêche enfin de confondre l’apparence rassurante d’un certificat avec la machine qui l’a produit.

Sources