Résumé
- Publié le 5 septembre 2026, un Internet-Draft individuel applique six libertés binaires d’encodage CBOR à un même objet COSE_Sign1 de 165 octets.
- Les 64 combinaisons donnent 64 suites d’octets et 64 valeurs de
data-hash, sans collision, mais une seuleSig_structurede 109 octets : la signature reste valide dans tous les cas. - Le décodeur de référence n’en rejette aucune. Pour 31 variantes, lire puis réencoder suffit à produire silencieusement les octets de départ.
- Une exécution indépendante du script publié a reproduit les 64 hachages, les zéro rejets et les 31 normalisations avec des copies dont les empreintes concordent.
- L’expérience ne révèle ni attaque cryptographique ni incident en production. Elle impose une question de gouvernance : quels octets l’identifiant désigne-t-il, et qui doit pouvoir les restituer ?
Deux promesses superposées dans le même message
La signature d’un COSE_Sign1 et le hachage de son encodage complet ne portent pas sur la même matière. Suivant RFC 9052, la vérification utilise une Sig_structure construite notamment avec l’en-tête protégé et la charge utile. Les détails de présentation du conteneur CBOR extérieur n’y entrent pas tous.
Le data-hash étudié dans le nouveau projet est au contraire calculé sur la suite d’octets transmise. Il peut servir d’adresse, de clé de recherche ou de point d’ancrage pour une autre attestation. Dès lors, deux parties peuvent reconnaître le même contenu signé et obtenir des identifiants différents, simplement parce qu’elles n’ont pas conservé la même représentation.
Ce n’est pas une contradiction. La signature garantit ce que son domaine couvre. Le hachage distingue exactement les octets qu’on lui fournit. La faute de gouvernance serait de laisser croire que la réussite de la première opération prouve la reproductibilité de la seconde.
Six choix binaires dessinent un espace plus grand qu’une liste d’exceptions
L’objet initial A occupe 165 octets. L’auteur le décode une fois, puis réémet les mêmes valeurs selon six axes : présence ou absence du tag CBOR 18 ; longueur déterminée ou indéterminée du tableau extérieur ; même alternative pour la carte des en-têtes non protégés ; enfin émission en un seul bloc ou par fragments des chaînes d’octets de l’en-tête protégé, de la charge utile et de la signature.
Les six interrupteurs produisent 64 cas. Le fichier de mesure recense autant de suites d’octets et autant de hachages SHA-256 distincts, sans collision. Les tailles vont de 164 à 170 octets. Pourtant, les 64 messages conduisent à une seule Sig_structure, de 109 octets, et donc à la même vérification de signature.
Le chiffre de 64 ne clôt pas l’univers des représentations. L’expérience ne modifie ni la largeur d’encodage des entiers ni l’ordre des clés de carte. RFC 8949 fournit le contexte de ces libertés. Interdire quelques formes connues revient donc à traiter les exemples, pas à définir la frontière.
La perte peut avoir la forme d’une réussite
Aucun des 64 messages n’a déclenché d’erreur dans le décodeur utilisé. Le résultat le plus opérationnel vient des 31 variantes transformées en A après un simple aller-retour décodage–encodage. Le logiciel n’annonce pas qu’il vient d’abandonner la représentation reçue ; il rend un objet parfaitement lisible dans sa forme préférée.
Imaginons alors un service qui calcule H(B) dès la réception, décode B et ne stocke que sa réémission A. Il détient toujours un objet dont la signature est vérifiable. En revanche, il ne possède plus les octets nécessaires pour recalculer H(B). Si ce hachage devient l’index public de l’enregistrement, la preuve de présence et le contenu conservé se séparent sans alarme.
Le mot « silencieux » ne prête aucune intention au parseur. La mesure n’a examiné aucun service déployé et n’établit pas la fréquence de cette chaîne de traitement. Elle démontre seulement que l’absence d’erreur syntaxique ne vaut pas reçu de conservation.
Une réplication qui confirme le compte, pas davantage
Les entrées, le tableau des 64 résultats et le script sont publics. Après l’échec d’accès au point de téléchargement brut, j’ai récupéré le même script par l’API Contents de GitHub, puis l’ai exécuté dans un répertoire et un environnement Python temporaires. Les deux fichiers JSON locaux avaient les mêmes empreintes que les artefacts publiés.
Le script a reconstruit A octet pour octet avec l’empreinte 8595e4a4c8b93e7b1b7b798dc302a2b7d2890021f7eff372d79b32f78867e4ac. Il a retrouvé 64 data-hash distincts, aucun rejet et 31 normalisations. Cette exécution utilisait cbor2 5.7.1 ; le document indique 6.1.3, CPython 3.13 et macOS arm64. La concordance est utile, mais elle ne constitue ni une campagne d’interopérabilité ni une preuve d’exhaustivité.
Elle ne modifie pas non plus le statut du texte. Le Datatracker le présente comme une soumission individuelle sans approbation de l’IETF ni place formelle dans le processus. Le projet ne prescrit rien. Aucune signature n’a été forgée, aucun hachage n’est entré en collision et aucun incident réel n’est revendiqué.
« Tel qu’enregistré » reste une proposition de discussion
La mesure a alimenté l’examen du profil CCF pour les reçus COSE, alors en Last Call de l’IETF. Dans un message du 5 septembre, Nicholas Templeman soutient l’avancement du texte tout en suggérant de lier data-hash aux octets tels qu’ils ont été enregistrés, jamais à une ré-sérialisation. Il précise que son observation n’est pas bloquante.
Ce message est une contribution individuelle. Il ne constitue pas un accord de l’IETF et la formulation n’est pas, à la date de l’enquête, une règle adoptée. Le projet SCRAPI et le profil CCF restent eux aussi des documents de travail. RFC 9943 définit l’architecture SCITT publiée, mais ne préjuge pas de ce choix ultérieur.
Un autre projet individuel, Canonical Payload Binding, avait déjà décrit un algorithme as-transmitted : aucune canonicalisation, la suite exacte d’octets formant la préimage. Ses variantes jcs-n et cde-n sont marquées Withdrawn. Cette antériorité empêche d’attribuer la solution à la nouvelle expérience ; elle ne transforme pas davantage le projet antérieur en norme.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

