Résumé

  • draft-reddy-wimse-aggregate-signatures-01 associe une continuité d’empreintes par saut à une signature agrégée : la première localise les transformations, la seconde empêche d’effacer un signataire qui n’a rien modifié.
  • Seule la valeur de signature reste proche d’une signature unique. Les WIT, entrées Signature-Input, chemins, requêtes et empreintes augmentent avec le nombre de participants.
  • Une agrégation valide établit la participation présentée et l’attribution des changements ; elle ne décide ni de leur autorisation, ni de l’exhaustivité du parcours, ni de l’exécution finale.

Ce que l’agrégation ne compacte pas

Dans une chaîne d’agents, le destinataire ne reçoit pas nécessairement la représentation créée au départ. Un agent formule une intention, un orchestrateur la transforme, un service intermédiaire ajuste le chemin, puis une passerelle transmet le corps sans y toucher. La dernière requête ne raconte pas ce parcours.

La révision 01 propose une provenance authentifiée. Chaque charge signe la représentation qu’elle transmet. Elle inscrit l’empreinte du corps reçu dans wimse-req-digest et celle du corps envoyé dans Content-Digest. Son WIT fournit son identité et sa clé publique. Son entrée Signature-Input conserve les paramètres indispensables à la reconstruction. Les signatures individuelles sont enfin combinées dans Signature-Aggregate.

Cette dernière valeur reste presque constante lorsque la chaîne s’allonge. Mais le vérificateur ne la confronte pas au seul message final. Il la vérifie sur la liste complète des couples clé publique–message signé. Il lui faut donc autant de clés et de représentations qu’il y a de sauts.

La section 10 ne laisse guère de place au malentendu : Signature-Input, Workload-Identity-Tokens et les empreintes continuent de croître avec la chaîne. L’économie porte sur les octets des signatures, pas sur le nombre de faits à conserver.

Le relais transparent révèle l’utilité précise de l’agrégat

Prenons trois charges. H1 envoie un corps dont l’empreinte est A. H2 reçoit A et renvoie A sans modification. H3 reçoit A, le transforme et produit B.

Avec des signatures individuelles et une simple continuité d’empreintes, H2 peut être retiré du récit. Après son effacement, la sortie A de H1 correspond toujours à l’entrée A de H3. Les signatures de H1 et H3 restent vérifiables. Le relais disparaît parce qu’il n’a laissé aucune différence de contenu.

Dans le mode agrégé, la contribution de H2 est incorporée à la valeur courante et sa signature individuelle n’est jamais transmise séparément. Un adversaire qui présente seulement H1 et H3 doit fabriquer l’agrégat correspondant à ces deux participants. Il ne dispose pas de la contribution isolée de H2 pour la retrancher. L’ensemble annoncé ne vérifie plus.

L’agrégat ajoute donc une propriété bien circonscrite : la non-suppression d’un signataire intérieur, y compris quand il a relayé le corps à l’identique. Les empreintes détectent la disparition d’un transformateur ; l’agrégat détecte aussi celle d’un relais signataire.

En revanche, un intermédiaire qui transmet sans signer ne laisse pas de contribution. Et si un service obligatoire est contourné avant d’entrer dans la chaîne, la cryptographie ne sait pas qu’il était attendu. Une règle extérieure doit préciser qu’un contrôleur, un filtre ou une juridiction doit apparaître, puis comparer cette obligation à l’ensemble effectivement prouvé.

La vérification dépend d’une reconstruction relationnelle

Le chemin et la requête URI d’un ancien saut peuvent être écrasés par les suivants. La révision 01 ajoute donc wimse-req-path et wimse-req-query aux paramètres signés de chaque charge. Le destinataire reconstruit la base de signature de H1 avec les valeurs de H1, non avec l’URI finale.

Le corps suit une logique voisine. Pour savoir ce que H1 a envoyé, le vérificateur lit l’empreinte d’entrée signée par H2. Le dernier saut n’ayant pas de successeur, sa sortie est le Content-Digest final. Chaque déclaration de sortie dépend ainsi de l’accusé de réception signé par le voisin suivant.

Les WIT sont transportés dans un dictionnaire Workload-Identity-Tokens, sous des étiquettes uniques reliées aux entrées Signature-Input. Chaque nouveau saut conserve les membres existants et ajoute le sien. Remplacer un jeton antérieur modifie une valeur couverte et fait échouer la vérification. Mais la seule présence d’un WIT ne suffit pas : sa validité, son domaine de confiance, sa clé et son algorithme doivent être évalués.

Perdre une ancienne requête URI, réutiliser une étiquette, supprimer un jeton, casser l’ordre ou conserver une sérialisation différente suffit à rendre l’agrégat inexploitable. La valeur cryptographique peut être intacte alors que son contexte de vérification ne l’est plus.

Le reçu opérationnel minimal proposé par Daniel Kade contient donc l’ordre des participants, l’agrégat exact, les WIT validés, les entrées de signature, les empreintes d’entrée et de sortie, les valeurs de chemin et de requête, l’algorithme, la politique appliquée et le résultat. Il s’agit d’une projection d’exploitation, non de colonnes imposées par le projet.

Attribuer un changement n’est pas l’approuver

Le texte indique expressément que les empreintes donnent une attribution, non une garantie de correction. Une charge malveillante ou défaillante peut modifier le contenu et signer fidèlement l’avant et l’après. L’auditeur apprend qui a opéré la transformation ; il ne sait pas encore si ce rôle y était autorisé.

La même séparation vaut pour l’initiateur. Un intermédiaire peut abandonner l’ancien agrégat et commencer une nouvelle chaîne sous sa propre identité. La signature identifie ce nouvel initiateur. Seule une politique décide s’il a le droit d’émettre cette action.

Il faut donc conserver cinq décisions distinctes : identité et validité des participants ; représentations reçues et envoyées ; validité de l’agrégat ; autorisation des rôles et transformations ; engagement applicatif et résultat observé. Le troisième voyant vert ne remplace pas les deux derniers.

Cette discipline vaut aussi pour la réponse. La protection ne couvre le retour que s’il est signé sur la chaîne inverse. Une réponse non signée peut être altérée ou supprimée sans détection par ce mécanisme. Une réponse signée prouve sa filiation, pas la vérité du résultat métier annoncé.

Une preuve collective produit une panne collective

La vérification agrégée est globale : une seule mauvaise contribution fait échouer l’ensemble. L’agrégat n’indique pas quel saut est fautif. Un jeton expiré, une divergence de reconstruction, un algorithme refusé ou un participant hostile peut provoquer un déni de service de toute la chaîne.

L’admission peut légitimement rester binaire. Le diagnostic ne le peut pas. Il faut prévoir des reçus de validation par préfixe, des journaux locaux protégés ou une relecture contrôlée. Sans cela, la chaîne résiste à la suppression mais l’équipe ne sait pas localiser la rupture.

L’agilité algorithmique ne signifie pas que tout algorithme déclaré devient acceptable. Chaque WIT dit ce qui a été utilisé ; la politique locale dit ce qui peut l’être. La révision 01 cite le schéma BLS avec augmentation de message comme instanciation possible, tout en laissant son identifiant WIT à une autre spécification et en rappelant que BLS n’est pas post-quantique.

Une agrégation exige en outre le même schéma sur tous les sauts. En l’absence d’un algorithme agrégeable, les signatures individuelles restent possibles. Les empreintes repèrent encore la suppression d’un transformateur, mais pas celle d’un signataire transparent avec la même propriété.

La provenance dévoile aussi l’architecture

Chaque WIT révèle une charge. Chaque audience peut révéler le prochain destinataire. La succession des empreintes montre où le contenu a changé. Le dossier de vérification peut donc exposer une topologie et une histoire de traitement sensibles.

La doctrine des couches de réalité de Heng Lu aide à ne pas confondre les objets : identité de charge, clé, représentation HTTP signée, filiation des transformations, validation agrégée, autorisation, engagement applicatif et effet externe sont huit dossiers liés, non une même réalité.

La primauté du code en fonctionnement désigne le véritable contrôle : le parseur qui préserve les champs structurés, le validateur qui reconstruit chaque base, la vérification de chaque WIT et la jointure entre empreintes voisines. Une figure élégante ne répare pas un système qui n’archive que le dernier en-tête.

Une spécification initiale minimale n’exige pas tous les journaux internes. Elle exige l’ensemble minimal mais complet permettant à un vérificateur autorisé de reproduire la preuve. Cet ensemble grandit parce que le nombre de faits grandit. La signature peut être compacte ; la réalité ne l’est pas.

Sources et limites

Les sources ont été figées le 30 septembre 2026, fuseau Asia/Shanghai. La révision 01 est un Internet-Draft individuel actif, non un RFC, un consensus de l’IETF, une preuve d’adoption ou une norme déployée. Elle peut changer, être remplacée ou expirer. Les sources ne fournissent ni mesure de surcharge, ni interopérabilité démontrée, ni attaque réelle, ni économie en production, ni verdict de conformité, ni perte observée. Le modèle de taille du dossier factuel est une explication de Daniel Kade, non un banc d’essai.