Résumé

  • Le projet individuel draft-templeman-scitt-framing-space-00, annoncé le 5 septembre 2026, rapporte une mesure informative. Il ne constitue ni RFC, ni consensus de l’IETF, ni proposition de texte normatif.
  • Six libertés binaires de cadrage CBOR ont produit 64 suites d’octets acceptées et 64 data-hash distincts. Elles ont toutes reconstruit le même Sig_structure et validé la même signature.
  • Trente et une entrées ont été réémises silencieusement sous une seule forme canonique après lecture. Sans conservation préalable des octets reçus, le service peut perdre la matière nécessaire pour reproduire l’identifiant qu’il a publié.

Le cas le plus trompeur ne déclenche aucune erreur. Le décodeur accepte le message. La signature est correcte. L’enregistrement réussit. Pourtant, lorsque le service relit son stockage, les octets ne sont plus ceux auxquels l’identifiant public avait été attaché.

Le nouveau projet de Nicholas Templeman mesure cette divergence sans la dramatiser. Son annonce du 5 septembre le présente comme un Internet-Draft informatif de huit pages. Le texte précise qu’il ne spécifie rien et ne propose aucune formulation. Il apporte un résultat reproductible à des travaux SCITT en cours.

La preuve cryptographique ne couvre pas toute la représentation

Dans RFC 9052, la signature COSE porte sur un Sig_structure construit à partir du contexte, des attributs protégés, des données externes authentifiées et de la charge utile. Les choix de représentation de l’enveloppe CBOR ne sont pas tous inclus dans ce calcul.

Or RFC 8949 permet plusieurs sérialisations d’une même valeur de modèle de données. Une longueur peut être définie ou indéfinie. Une chaîne d’octets peut être entière ou fragmentée. Un tag peut être présent ou absent selon le profil. Un lecteur peut donc retrouver la même valeur tandis que l’observateur du réseau reçoit d’autres octets.

L’expérience part d’un COSE_Sign1 A de 165 octets. Elle varie la présence du tag 18, la forme de longueur du tableau extérieur et de la map d’en-tête non protégée, puis le caractère entier ou fragmenté de trois chaînes : en-tête protégé, payload et signature. Aucun élément ne change de valeur.

Les six choix à deux états donnent 64 combinaisons, longues de 164 à 170 octets. Le décodeur cbor2 6.1.3 les accepte toutes. Elles reconstruisent toutes un seul Sig_structure de 109 octets. La même signature est donc valable dans les 64 cas.

Le condensat des octets transmis raconte une autre histoire : 64 entrées, 64 résultats SHA-256, aucune collision. Il ne s’agit pas d’un échec de SHA-256. Les préimages sont différentes. Il ne s’agit pas non plus d’une falsification de signature. Les données signées sont identiques.

Une liste d’interdictions ne ferme pas un espace combinatoire

La mesure n’épuise pas le sujet. Elle ne varie ni la largeur d’encodage des entiers ni l’ordre des clés de map. Le nombre 64 est donc une borne inférieure pour l’objet étudié, pas un inventaire universel.

Cette réserve change la réponse opérationnelle. Interdire un tableau extérieur indéfini ne supprime pas les combinaisons formées par les cinq autres axes. Corriger chaque exemple découvert revient à poursuivre une classe dont la taille augmente à chaque nouvelle liberté indépendante.

Le fichier de reproduction publie les variantes, les résultats et le script de génération. Le vecteur de départ fournit les octets de A. L’auteur indique l’environnement de mesure et cite une recomputation indépendante d’un axe avec un autre lecteur, sans bibliothèque COSE.

Ce dossier permet de tester le mécanisme dans plusieurs piles. Il ne mesure pas le nombre de services touchés et n’identifie aucun incident réel. Transformer cette preuve de possibilité en statistique de déploiement serait précisément abandonner la réalité pour le récit.

Le nettoyage automatique peut effacer la provenance

Parmi les 64 entrées, 31 reviennent aux octets canoniques de A lors d’un cycle décodage-réencodage. Le mot important est « silencieusement ». Une chaîne d’ingestion peut considérer cette normalisation comme une simple hygiène de données et jeter le corps brut de la requête.

Si le data-hash est calculé avant cette étape, puis si seul l’objet réémis est conservé, le service a créé une dette de preuve. Il sait quel identifiant il a retourné, mais ne possède plus nécessairement sa préimage. Un contrôle effectué plus tard calcule le hash de la version normalisée et conclut à tort que l’enregistrement manque ou a changé.

L’effet se propage lorsque le data-hash sert de clé d’index, de clé de déduplication, de coordonnée de receipt ou de sujet d’une attestation ultérieure. Une modification du cadrage peut alors créer une deuxième identité pratique sans toucher à la signature. Deux vérificateurs peuvent être honnêtes, valider la même preuve et ne pas chercher au même endroit.

La première décision doit donc précéder le parseur. Le point d’entrée conserve les octets reçus dans un stockage immuable, calcule l’identifiant sur cette copie et nomme précisément la frontière couverte. La valeur décodée et toute réémission deviennent des dérivés reliés à l’original, jamais ses remplaçants.

Une représentation déterministe imposée par un protocole constitue une autre solution possible. La section 4.2 de RFC 8949 donne une base pour la définir. Mais une bibliothèque qui préfère une forme n’a pas, à elle seule, imposé cette forme à tous les émetteurs ni vérifié que l’entrée la respecte.

Le projet de profil as-transmitted choisit l’octet exact : aucune canonicalisation et un sélecteur qui cite une production nommée du format. Il précède la nouvelle mesure et demeure lui aussi un projet individuel. La mesure explique la nécessité d’une frontière ; elle ne transforme pas cette proposition en norme.

Quatre reçus, quatre autorités

L’architecture SCITT de RFC 9943 distingue déclaration signée, service de transparence, receipt et appréciation. Les travaux actuels sur les API SCITT et le profil CCF emploient des identifiants de type data-hash, ce qui rend la fidélité des octets observable dans la chaîne réelle.

Mais les conclusions ne se transmettent pas automatiquement. Les octets bruts établissent ce qu’un composant a reçu. Une signature valide établit l’intégrité du Sig_structure sous une clé ; l’application doit encore relier cette clé à une identité autorisée. Un receipt établit une inscription selon les règles d’un service. Aucun de ces éléments ne garantit la vérité, l’actualité ou l’usage légitime du contenu.

La règle de réalité avant plaidoyer de Heng Lu empêche d’inventer un adversaire : le décodeur tolérant et l’encodeur canonique peuvent fonctionner correctement. L’erreur de système consiste à leur faire parler au nom de la même preuve.

La primauté du code en exploitation déplace ensuite l’audit vers le trajet concret : corps HTTP, passerelle, bus, base, API de lecture et vérificateur. Enfin, la séparation entre capacité technique et autorité rappelle qu’une bibliothèque capable de normaliser n’est pas autorisée à redéfinir l’identité déjà donnée au client.

Le problème n’oppose donc pas wire hash et canonicalisation comme deux doctrines. Il demande une décision explicite : quelle réalité l’identifiant désigne-t-il, et l’organisation conserve-t-elle encore la preuve permettant de le recalculer ?

Sources