Résumé

  • Annoncé le 5 septembre 2026, draft-sato-soos-pt-03 est un Internet-Draft individuel actif, sans approbation ni statut formel de l’IETF, sans flux RFC, Area Director responsable ou téléconférence inscrite.
  • La révision 02 plaçait ProgressiveTrustSummary dans un contexte HEM sans préciser sa composition cryptographique. La révision 03 impose d’en faire un champ de chaque requête d’escalade HEM avant la signature du GEC.
  • Le nouveau texte interdit à l’interface du principal humain de traiter comme faisant foi un bilan livré en dehors de l’enveloppe signée de la requête.
  • pt_summary_hash reste une empreinte SHA-256 du JSON canonique, utile pour contrôler un bilan après extraction. Pour le destinataire, l’authenticité vient de kernel_signature, la signature de la requête qui l’englobe.
  • Un reçu commun devrait conserver l’identifiant de requête, la préimage signée, le signataire et sa clé, le verdict de vérification, le chemin du bilan, son empreinte extraite et l’historique des relais. C’est une recommandation de Daniel Kade, pas une règle de l’IETF.

Un bilan exact peut accompagner la mauvaise escalade

L’annonce du 5 septembre présente Progressive Trust comme une mémoire comportementale : les actions d’un agent au fil des sessions alimentent des recommandations sur l’évolution de son autorité. La fiche Datatracker classe la révision 03 de Tom Sato parmi les Internet-Drafts individuels actifs. Elle précise que le texte n’est pas approuvé par l’IETF et n’y possède aucun statut formel. Aucun flux RFC, aucun Area Director responsable et aucune date de téléconférence ne lui sont attribués. La mention « Standards Track » exprime un objectif de l’auteur.

PT suit cinq dimensions : qualité de l’autoévaluation, discernement dans le recours à l’humain, efficacité, précision et adaptation après un refus. Le ProgressiveTrustSummary rassemble ces dimensions, une vue composite, des tendances, des volumes de sessions, des recommandations en cours et une empreinte pt_summary_hash.

Ce paquet devient sensible lorsqu’il arrive à l’écran de décision. Une note de 0,88 n’a pas de contexte naturel. Elle doit appartenir au bon agent, être calculée au bon instant et rester liée au bon hem_id, au bon motif d’escalade et aux bonnes options. Un cache ou un relais peut conserver un bilan parfaitement cohérent tout en l’accolant à une autre demande. L’intégrité interne survit ; la relation gouvernante disparaît.

PT-03 traite précisément ce risque de mauvais assemblage. La nouveauté importante n’est pas une sixième dimension ni un seuil supplémentaire. C’est la définition de l’objet qui doit porter l’authentification.

La révision 02 nommait un contexte, pas la préimage

La révision 02 figée demandait au GEC d’inclure un bilan dans chaque HEMContext remis lors d’une escalade. Elle fixait aussi le moment de calcul et conservait l’empreinte. Mais « présent dans le contexte » pouvait encore signifier une récupération parallèle après la signature de la requête principale.

La comparaison officielle montre la réparation. PT-03 fait du bilan un champ à l’intérieur de chaque requête d’escalade HEM. Le GEC doit composer cette requête complète avant de la signer selon la section 18.8 de HEM. Un bilan transmis hors de l’enveloppe signée ne doit pas être considéré comme faisant foi par l’interface du destinataire.

Le texte attribue cette correction au constat principal d’une revue de sécurité WIMSE. La recherche publique ordinaire n’a pas permis de retrouver un artefact distinct de cette revue. Il faut donc s’en tenir à l’attribution écrite par le projet lui-même. Le changement entre 02 et 03, lui, est directement observable.

Cette précision sépare deux architectures qui peuvent avoir le même aspect. Dans la première, l’application signe une requête et charge ensuite une carte de confiance depuis un service analytique. Dans la seconde, la carte est déjà dans la préimage. Seule la seconde permet au vérificateur de dire que le signataire s’est engagé sur ce bilan pour cette demande.

L’empreinte confirme une égalité, pas un mandat

Le champ pt_summary_hash est décrit comme le SHA-256 d’un JSON canonique. PT-03 lui assigne désormais une fonction limitée et utile : après extraction du bilan, un auditeur peut recalculer l’empreinte et vérifier qu’il examine la même représentation. Le champ n’est pas la source d’authenticité qui accompagne la décision humaine.

Le RFC 8785 expose le problème général : pour hacher ou signer du JSON de manière répétable, les participants doivent produire une représentation canonique déterministe. Une empreinte isolée permet alors de comparer. Elle ne nomme toutefois ni l’auteur de l’objet, ni l’escalade à laquelle il appartient, ni le destinataire qui l’a vu. Celui qui remplace un objet non authentifié peut aussi calculer l’empreinte du remplaçant.

La révision 07 de HEM fournit l’autre moitié de la relation proposée. Le GEC doit signer la requête d’escalade entière avec Ed25519 ; kernel_signature couvre la sérialisation canonique de tous les autres champs. HEM-07 décrit en outre progressive_trust_summary comme un champ obligatoire de la requête. La vérification porte donc sur une proposition jointe : ce GEC a associé ce bilan à cette escalade.

La signature ne garantit pas la justesse du score. Des événements peuvent manquer, le calcul peut être défectueux, la clé compromise ou le jugement humain contestable. Elle fournit provenance et intégrité selon les hypothèses du projet. C’est moins spectaculaire qu’une certification de vérité, mais exactement ce qu’une frontière cryptographique peut honnêtement promettre.

Vérifier avant d’afficher

L’ordre de traitement doit être visible dans l’interface. D’abord, vérifier la requête qui englobe hem_id, le déclencheur, les options, le bilan et la clé pertinente. Ensuite seulement, extraire et afficher notes, tendances et explications. Extraire le bilan, valider uniquement son empreinte puis le rattacher à une requête inverse cette logique.

Les intermédiaires ont la même obligation structurelle. HEM-07 indique qu’un intermédiaire capable de vérifier la signature du noyau ne doit pas transmettre une requête invalide. Un relais peut transporter ou présenter l’information ; il ne devient pas une source d’autorité en recomposant des fragments convaincants. S’il modifie la sérialisation, il doit conserver la préimage signée ou un reçu permettant de rejouer la vérification.

Le bilan demeure informatif. Le principal humain peut approuver malgré une note basse ou mettre fin à l’action malgré une note élevée. La métrique n’a pas de voix propre. L’inscrire dans la requête signée ne transfère pas le pouvoir au calcul ; cela rend attribuable l’information qui a entouré l’exercice du pouvoir humain.

Conserver le lien, pas seulement les deux pièces

Un reçu de vérification commun serait la plus petite mémoire opératoire utile. Il devrait retenir hem_id, la version de la requête, les octets signés ou la préimage canonique, kernel_signature, l’identité du signataire et de sa clé, ainsi que l’heure et le résultat du contrôle. Il devrait aussi indiquer le chemin exact du bilan, son instant de calcul, l’empreinte recalculée après extraction et toute transformation effectuée par un relais. Cette proposition est la mienne ; les projets ne l’imposent pas sous cette forme.

Les cas négatifs doivent dominer les essais. Un bilan valide associé au mauvais hem_id doit échouer. Une note modifiée avec l’ancienne empreinte doit échouer. Un bilan remplacé, muni d’une nouvelle empreinte correcte mais sans signature externe valable, doit encore échouer. Une requête bien signée dont l’interface substitue ensuite l’explication en langue naturelle doit échouer au contrôle d’équivalence de présentation. Une clé inconnue doit produire un état non résolu, jamais une carte verte par défaut.

La primauté du code en fonctionnement de Heng Lu fournit ici une méthode : un document publié n’est pas une réalité d’exploitation ; il faut une règle testable localement. Sa spécification initiale minimale pousse vers une couche commune mince. Une requête, une signature externe et un reçu reproductible suffisent à exprimer cette frontière. Ces notes éclairent l’analyse ; elles ne prouvent aucune adoption de PT.

Une correction documentaire, pas encore un résultat de terrain

Les fiches Datatracker de PT et de HEM ne fournissent aucune preuve d’implémentation indépendante, d’interopérabilité, de production, d’exploitation d’une faille ou d’incident réparé. Les deux documents restent individuels et peuvent être modifiés, expirer ou ne jamais intégrer un flux RFC.

La nouvelle vérifiable est donc étroite : PT-03 identifie désormais l’objet signé qui transporte le bilan présenté à l’humain et remet l’empreinte dans son rôle d’audit. La prochaine preuve importante ne sera pas une formule supplémentaire sur la confiance, mais deux implémentations capables de refuser les mêmes mauvais assemblages et de conserver le même lien vérifiable.

Sources

  1. Annonce IETF de draft-sato-soos-pt-03
  2. Datatracker — Progressive Trust
  3. Archive IETF — PT-03
  4. Archive IETF — PT-02
  5. Comparaison officielle PT-02/PT-03
  6. Archive IETF — HEM-07
  7. Datatracker — Human Escalation Mechanism
  8. RFC 8785 — JSON Canonicalization Scheme
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — spécification initiale minimale
  11. Heng Lu — la réalité plutôt que le plaidoyer