Résumé

  • Les responsables de SCITT demandent si le projet individuel sur les reçus COSE pour Merkle Mountain Ranges doit devenir une base de travail du groupe; les réponses sont attendues avant le 9 octobre.
  • Le sondage de juillet mesurait la disponibilité de participants pour relire le texte, pas un consensus d'adoption.
  • La norme RFC 9942 unifie l'enveloppe des reçus, mais avertit que les structures de données vérifiables différentes ne sont pas automatiquement interopérables.

Une enveloppe reconnaissable n'est pas une preuve intelligible. Le problème apparaît lorsqu'un service annonce qu'il accepte les « reçus COSE » sans préciser l'algorithme d'arbre ni le type de preuve qu'il sait contrôler. C'est sur ce terrain que prend sens l'appel lancé par les responsables de SCITT le 25 septembre: faut-il faire du projet draft-bryce-cose-receipts-mmr-profile-03 un document du groupe pour poursuivre les travaux?

Le message demande explicitement des positions motivées, favorables ou défavorables, et des engagements éventuels à relire, contribuer ou implémenter. Il fixe le 9 octobre comme échéance de réponse. Il précise aussi qu'une adoption ne déclarerait pas le texte achevé ou prêt à paraître. Le Datatracker le classe encore parmi les Internet-Drafts individuels actifs, sans aval formel de l'IETF. Il serait donc prématuré de parler de standard SCITT approuvé.

La réunion IETF 126 aide à éviter une autre confusion. En juillet, quatre personnes ont répondu qu'elles accepteraient de relire le profil, aucune n'a répondu non et trois n'ont pas exprimé d'avis, sur 34 présents. La question posée n'était pas un vote de normalisation. Le procès-verbal annonçait une suite sur la liste de diffusion; l'appel de septembre est précisément cette étape publique supplémentaire.

Le projet décrit un type déterminé de registre: des arbres binaires construits en ordre postfixe, dont les sommets composent un accumulateur. Une preuve d'inclusion rattache un élément à un état signé; une preuve de cohérence relie un état ancien à un état plus récent. Dans le reçu proposé, l'identifiant de structure figure dans un en-tête COSE protégé, tandis que les données de preuve suivent leur propre encodage. La charge utile détachée impose au vérificateur de recalculer la racine avant de valider la signature. Il ne suffit donc pas de décoder l'enveloppe.

La RFC 9942 expose elle-même la limite d'interopérabilité: des structures de données vérifiables distinctes peuvent exiger des représentations et des analyses de sécurité distinctes. SCITT travaille déjà sur un profil CCF; celui des MMR répond à un autre agencement d'arbre. Même si les deux s'inscrivent dans le cadre COSE, savoir traiter l'un ne démontre pas la prise en charge de l'autre. Le projet MMR rappelle aussi qu'une preuve d'inclusion ne décide pas si l'inscription était légitime et qu'une omission antérieure échappe à son périmètre.

Ces réserves n'effacent pas l'enjeu propre de cette consultation: définir qui fera évoluer un format spécialisé et comment constater sa compatibilité réelle.

Pour un acheteur ou un auditeur, la bonne question n'est donc pas « acceptez-vous les reçus? » mais « quels identifiants de structure, quelles preuves et quelles versions votre vérificateur exerce-t-il sur des cas contrôlables? ». C'est un test éditorial de diligence, non une exigence décidée par SCITT. L'adoption éventuelle ouvrirait un travail collectif; elle ne remplacerait ni l'examen technique ni la vérification locale.

Sources