Résumé

  • La révision 04 du profil SCITT pour les reçus CCF contient la feuille et une suite de hachages frères orientés à gauche ou à droite, mais ni l’indice explicite de la feuille ni la taille de l’arbre.
  • La vérification d’inclusion reste possible : le vérificateur recalcule la racine et contrôle sa signature. L’ambiguïté ne commence que lorsqu’on transforme ce résultat en preuve d’ordre ou de position.

Le cas révélateur tient dans un chemin à un élément, 1. Dans un arbre à deux feuilles, il correspond à l’indice 1. Dans des arbres à trois, cinq et neuf feuilles, le même chemin correspond respectivement aux indices 2, 4 et 8. Le bit est identique ; c’est la géométrie absente qui change son sens.

Cette observation est apparue pendant la Last Call de l’IETF consacrée à la révision 04 de CCF Profile for COSE Receipts. Selon le Datatracker, il s’agit d’un Internet-Draft du flux IETF, destiné au statut Proposed Standard, transmis à l’IESG et toujours « In Last Call ». La consultation ouverte le 24 août s’achève le 7 septembre 2026. Il ne s’agit donc ni d’un RFC ni d’une décision de rejet.

Une racine juste ne fournit pas des coordonnées

Le profil reprend une construction d’arbre proche de Certificate Transparency. Au-delà d’une feuille, l’arbre est coupé à la plus grande puissance de deux inférieure à sa taille. Les tailles qui sont elles-mêmes des puissances de deux produisent des arbres équilibrés ; les autres laissent une branche droite plus petite.

La preuve d’inclusion décrite à la section 3 fournit une feuille et une liste de hachages frères, accompagnés chacun d’un booléen gauche/droite. Le texte indique que ces directions peuvent être lues comme la décomposition binaire de l’indice, de la feuille vers la racine. Cette lecture fonctionne dans les arbres équilibrés. Elle ne fonctionne pas pour toutes les formes que la règle autorise.

Le 6 septembre, Henri Sirkkavaara a corrigé sa propre relecture après avoir testé les tailles 2 à 11. Chacune des tailles qui n’était pas une puissance de deux comportait au moins une feuille dont le chemin se décodait en un mauvais indice. Les tailles 2, 4 et 8, elles, étaient exactes.

Emek Can Dogru a reproduit séparément le phénomène et publié un programme de onze lignes. Entre 2 et 1 024 feuilles, seules les dix puissances de deux étaient exactes pour toutes les feuilles. Dans les 1 013 autres tailles, au moins un indice était mal reconstruit. Le code de reproduction figé rend le constat aisément vérifiable.

Pourtant, l’algorithme de la section 3.2 n’a pas besoin de retrouver ce numéro. Il part du hachage de la feuille candidate, combine les frères selon leurs côtés, puis obtient une racine. Si cette racine est couverte par la signature COSE, l’inclusion de la candidate est confirmée. La preuve répond correctement à une question plus étroite que celle qu’on pourrait lui prêter.

La séparation est nette : « cette feuille est-elle sous cette racine signée ? » n’est pas « quel rang occupait-elle ? ». Le problème naît après le calcul, quand une application, un auditeur ou une politique présente la première réponse comme si elle contenait la seconde.

Les profils voisins lient le repère

RFC 9162, qui normalise Certificate Transparency version 2, prend explicitement la taille de l’arbre et l’indice de la feuille pour vérifier une preuve d’inclusion. RFC 9942, profil COSE fondé sur cet arbre, encode lui aussi les deux valeurs et précise que l’indice est relatif à une taille donnée.

Ce ne sont pas de simples facilités d’implémentation. Elles définissent le système de coordonnées. Sans taille, le numéro de feuille est incomplet ; sans taille ni indice, un vecteur de directions peut décrire plusieurs positions ordinales.

Une installation CCF peut disposer d’un contexte extérieur. La documentation CCF sur les reçus part d’un identifiant de transaction, et certaines données d’engagement exposent un TxID complet. Le profil SCITT possède aussi une chaîne internal-evidence, mais autorise le vérificateur à l’ignorer et ne la définit pas comme grammaire interopérable de position. Un contexte local peut résoudre une recherche locale ; il ne rend pas la preuve auto-descriptive.

Les auteurs des remarques ne parlent ni d’attaque ni de cryptographie cassée. Tous deux considèrent le point comme non bloquant et soutiennent la publication. Dans son message consacré au remède, Sirkkavaara constate que la longueur du chemin exige encore de connaître la taille et préfère un indice explicite. C’est une correction de sémantique de schéma, pas un rapport d’incident.

Ne pas laisser l’interface élargir la preuve

Les reçus alimentent des politiques de publication logicielle, des journaux d’audit ou des automatismes de conformité. Beaucoup n’ont besoin que de l’inclusion. Dans ce cas, le profil actuel peut suffire. En revanche, une décision fondée sur « cinquième entrée », « antérieure à » ou « numéro de séquence » exige de conserver les valeurs qui rendent cette position démontrable.

La spécification initiale minimale de Heng Lu invite à formuler un invariant commun étroit, puis à laisser les systèmes locaux adopter des garanties supplémentaires. Les couches de réalité empêchent une relation mathématique vérifiée de devenir, sans transition explicite, un récit institutionnel sur l’ordre. La primauté du code en fonctionnement demande enfin de garder les entrées réellement utilisées par le vérificateur.

Le profil peut demeurer utile en nommant modestement son résultat. Si seule l’inclusion est signée, appelons-le reçu d’inclusion. Si la position fait partie de la décision, il faut lier la taille de l’arbre ou un indice explicite.

Sources

  1. Dossier du document dans l’IETF Datatracker
  2. Historique des événements IETF
  3. CCF Profile for COSE Receipts, révision 04
  4. Annonce de Last Call
  5. Correction de Henri Sirkkavaara
  6. Reproduction indépendante d’Emek Can Dogru
  7. Conclusion sur le remède
  8. Source du programme de reproduction
  9. RFC 9162
  10. RFC 9942
  11. RFC 9943
  12. Vérification des reçus CCF
  13. Heng Lu : spécification initiale minimale
  14. Heng Lu : couches de réalité
  15. Heng Lu : primauté du code en fonctionnement