Résumé

  • La révision 03 classe chaque référence typée en quatre résultats distincts : Malformed, Unresolved, Failed ou Verified. Une structure valide et couverte par une signature n’est pas encore une preuve de liaison avec le contenu cité.
  • Le résultat Verified exige un seul contexte de condensat autorisé, l’obtention de l’artefact, l’exécution de la construction déclarée et une égalité dans la représentation prévue.
  • La validité de la signature, l’autorité de l’émetteur, la vérification du reçu SCITT, l’évaluation de l’artefact et l’autorisation d’agir conservent chacune leur propre preuve.

Une révision de projet, pas un fait de déploiement

Le 5 septembre 2026, Steven Mih et Anton Sokolov ont déposé la révision 03 de Canonical Payload Binding: A Signed Statement Construction Profile. Le Datatracker la décrit comme un Internet-Draft individuel actif. Les auteurs visent le groupe de travail SCITT, mais le texte n’a ni flux IETF, ni responsable AD, ni téléconférence de décision, ni statut de consensus. Il peut être modifié, remplacé ou expirer.

Cette prudence n’enlève rien à l’intérêt opérationnel de la révision. Elle empêche simplement de transformer une proposition précise en norme acquise. La section consacrée aux changements depuis -02 sépare les mécanismes neutres de CPB des formats de charge utile. La référence typée devient un modèle d’information à quatre membres. Un profil de charge peut définir son propre encodage ; CPB propose aussi cpb-refs, un transport optionnel dans l’en-tête COSE protégé.

La révision retire surtout l’idée d’un registre universel de types d’artefacts au sein de CPB. C’est au profil consommateur d’indiquer, par une référence normative stable, les types et les contextes de condensat qu’il accepte. Elle sépare le mode à contenu complet de RFC 9943 du mode Hash Envelope de RFC 9995, interdit l’emploi simultané de deux transports de références et donne enfin un vocabulaire distinct aux résultats de traitement.

Quatre issues au lieu d’un voyant vert

Malformed désigne une faute d’admission. Il manque un membre obligatoire, le type CBOR est mauvais, une taille ou le nombre d’entrées dépasse la borne, une clé est dupliquée, le même quadruplet revient, ou une clé inconnue apparaît dans la carte interne fermée. Dans cpb-refs, les clés autres que 1 à 4 ne sont pas des extensions que l’on pourrait ignorer. Si une entrée est mal formée, le vérificateur ne peut pas sauver une autre entrée du même en-tête en la déclarant Verified. Le résultat de signature reste toutefois rapportable séparément.

Unresolved commence là où la syntaxe peut être irréprochable. Le vérificateur ne parvient pas à sélectionner exactement un contexte autorisé par le profil consommateur. Ou bien le contexte est clair mais l’artefact reste introuvable. Ou encore le contexte et l’artefact existent, mais l’implémentation ne sait pas exécuter la construction. Rien ne démontre alors une différence de condensat ; rien ne permet non plus d’affirmer une liaison.

Failed correspond à un constat plus avancé. Un contexte unique a été choisi, mais l’algorithme ou la représentation portés par la référence sont incompatibles avec lui, le jeton est définitivement indéfini ou interdit, ou le calcul effectué sur l’artefact obtenu ne donne pas la valeur annoncée. Confondre Failed avec Unresolved efface la différence entre une panne de conservation, un manque de capacité, une politique ambiguë et une divergence matérielle.

Verified exige la fermeture de toute la chaîne : un contexte autorisé, un artefact obtenu, la sélection et l’exclusion de champs prescrites, la canonicalisation, la séparation de domaine, l’encodage du préimage, le hachage et la représentation de sortie, puis une comparaison égale. La conclusion reste étroite : cet artefact est lié à cette référence dans ce contexte.

Le nom d’un algorithme ne sélectionne pas le contexte

Un digest context ne se résume pas à « SHA-256 ». Il comprend l’ensemble des paramètres qui déterminent la valeur : champs retenus, champs exclus, algorithme de canonicalisation, éventuelle séparation de domaine, encodage du préimage et représentation du résultat. Deux chaînes hexadécimales identiques ne forment un raccord probant que si leurs contextes complets sont compatibles.

La sélection part de type et, le cas échéant, de purpose. Si le profil n’autorise qu’un contexte pour un type, purpose peut manquer ; s’il est présent, il doit correspondre. Si plusieurs contextes sont permis, chacun porte un purpose distinct et non vide, et la référence doit choisir. Une absence de correspondance ou une ambiguïté laissée par plusieurs déclarations normatives mène à Unresolved.

Le vérificateur ne peut pas trancher selon l’ordre d’une liste, la longueur du condensat, l’allure de la charge, une habitude d’implémentation ou un instantané de registre non spécifié. Cette règle protège l’autorité du profil consommateur. Une bibliothèque générale sait peut-être exécuter JCS selon RFC 8785 ; elle ne sait pas pour autant quels champs l’organisation a accepté d’inclure ni quelle version du profil fait foi.

La même discipline vaut pour un identifiant dérivé transporté dans la charge. Le projet le qualifie d’indicatif. Le vérificateur doit le recalculer après avoir appliqué l’ensemble d’exclusion normatif et toute transformation explicitement ordonnée. Recopier la valeur du producteur dans un champ local appelé « vérifié » ne crée aucune preuve nouvelle.

Un seul transport, aucune fusion opportuniste

Un profil choisit pour chaque Signed Statement soit cpb-refs dans l’enveloppe protégée, soit son propre transport dans la charge utile. Les deux ne peuvent pas coexister, même s’ils citent des artefacts différents. Si un vérificateur conscient du profil trouve les deux, il déclare l’ensemble non conforme ; il n’en fait pas l’union et ne privilégie pas le premier qu’analyse son code.

Sans cette frontière, une référence de charge pourrait sembler corriger une référence protégée, les doublons pourraient devenir des votes et deux piles logicielles pourraient calculer des graphes différents. Le transport unique produit une surface d’entrée unique et un reçu d’admission intelligible.

Dans la forme d’enveloppe, cpb-refs apparaît uniquement dans l’en-tête protégé. Le tableau contient de une à 64 références. Chaque carte fermée associe des clés entières à type, purpose optionnel, digest_alg et digest, avec des limites de taille. Les doublons doivent être détectés avant une conversion de modèle qui risquerait de les effacer. Les stratégies first-wins, last-wins, succès partiel et pondération par répétition sont exclues.

Le CDDL limite le modèle de données, pas une seule sérialisation CBOR. Un vecteur de test peut figer des octets pour être reproductible ; un vérificateur conforme ne rejette pas un autre encodage valide uniquement parce qu’il diffère du fixture. Cette question complète, sans la répéter, l’étude antérieure des multiples cadrages CBOR : ici, l’enjeu est le passage d’une référence admise à une liaison externe prouvée.

La représentation et l’obtention sont deux contrôles

Les 32 octets bruts d’un condensat, leur texte hexadécimal minuscule de 64 caractères et une forme préfixée sont trois représentations distinctes. Une conversion silencieuse n’est pas un service de compatibilité : c’est une opération de protocole non déclarée. Elle n’est permise que si la spécification ou le profil définit à la fois la conversion et la représentation dans laquelle comparer.

L’obtention de l’artefact a sa propre temporalité. Un contexte unique accompagné d’un objet inaccessible produit Unresolved. Une panne réseau, un refus d’accès, une lacune de rétention ou un schéma de récupération non pris en charge ne démontrent pas que le digest est faux. Une nouvelle tentative peut réussir plus tard sans modifier le statement initial ; les deux observations doivent rester visibles.

Il en va de même lorsqu’une implémentation reconnaît le contexte mais ne sait pas l’exécuter. Le système peut transférer le travail vers un vérificateur capable, différer la décision, installer une capacité approuvée ou refuser selon sa politique. Il ne peut pas emprunter un ancien voyant vert à un autre composant.

Signature, émetteur, référence et reçu répondent à des questions différentes

Parce que cpb-refs se trouve dans l’en-tête protégé, son intégrité est couverte par une signature COSE valide. Cette couverture ne prouve pas que la clé était autorisée à parler au nom de l’émetteur. La révision distingue donc Signature-Valid d’Issuer-Authenticated, ce dernier dépendant de la politique locale sur la clé.

Un statement Signature-Valid peut contenir une référence Unresolved ou Failed. À l’inverse, l’égalité d’un digest ne répare pas une signature invalide et n’authentifie pas son auteur. L’API et l’interface devraient restituer le résultat de signature et le résultat de chaque référence, non une couleur commune.

Le reçu SCITT constitue encore une autre preuve. RFC 9943 permet à un Transparency Service d’enregistrer un statement et d’émettre un reçu gouverné par une structure de données vérifiable. Un statut fondé sur ce reçu exige la vérification sous une clé de service de confiance et la lecture du VDS dans l’en-tête protégé du reçu. L’inscription n’obtient pas l’artefact cité et ne transforme pas Unresolved en Verified.

Enfin, la vérification CPB ne démontre ni autorité de l’émetteur, ni validité, portée, fraîcheur ou état de révocation de l’artefact, ni conformité de politique, acceptation sémantique ou autorisation d’application. Le profil de l’artefact et l’organisation qui supporte les conséquences conservent ces décisions.

Protégé ne veut pas dire confidentiel

Un en-tête COSE protégé est intègre après validation de la signature ; il n’est pas chiffré. cpb-refs révèle le type, le purpose, l’algorithme, la valeur du digest et la structure du graphe de citations. Des valeurs stables permettent la corrélation entre statements. Un artefact à faible entropie peut aussi faire l’objet d’une recherche par dictionnaire.

Lorsque cette visibilité est inacceptable, le projet recommande d’omettre cpb-refs ou d’employer un transport confidentiel défini par le profil dans la charge. La décision doit précéder la diffusion. Un contrôle d’accès installé plus tard sur une application ne rappelle pas un graphe déjà distribué.

Une demande IANA n’est pas encore une allocation

La révision 03 demande la création d’un Canonicalization Algorithm Registry et l’enregistrement du paramètre COSE cpb-refs. Ce sont des propositions du projet, non la preuve que l’IANA a créé les coordonnées. Une expérimentation doit retenir la révision, les valeurs provisoires et la stratégie de migration.

Le principe de spécification initiale minimale de Heng Lu offre ici un garde-fou. Le socle partagé n’a besoin de transporter qu’un fait reproductible : un contexte déclaré a été appliqué à un artefact obtenu et a produit un résultat de comparaison. Les profils futurs restent libres d’attribuer du sens, d’évaluer la fraîcheur et de décider l’usage. Le running code compte s’il conserve les octets, les choix et les reçus qui rendent son résultat vérifiable.

Limites et incertitude

Cette analyse n’affirme ni adoption IETF, ni consensus du groupe, ni action IANA, ni support produit ou déploiement. Elle ne transforme pas les exemples d’instances de l’annexe en preuve d’interopérabilité générale. Aucun service, logiciel, registre, incident, benchmark, exploit ou taux de prévalence n’a été testé.

La canonicalisation ne rend pas davantage une charge vraie ou sûre. Le résultat des quatre états est une preuve bornée. Signature, identité de l’émetteur, reçu, liaison de référence, évaluation de l’objet, décision locale et effet observé restent séparés parce qu’ils ont des propriétaires et des conséquences différents.

Sources