Résumé

  • Daté du 28 septembre, draft-reddy-wimse-aggregate-signatures-01 reste un Internet-Draft individuel, sans statut de RFC ni adoption attestée par le groupe WIMSE.
  • Les empreintes conservées à chaque étape révèlent la disparition d’un relais qui a modifié le message, mais pas nécessairement celle d’un relais qui l’a transmis intact.
  • L’agrégation des signatures vise à rendre vérifiable la participation de ce dernier. Elle ne statue ni sur sa permission d’agir ni sur le résultat de l’application.

Dans une chaîne de trois services, celui du milieu peut recevoir une requête, la signer puis la transmettre à l’identique. Si l’on retire ensuite sa signature individuelle, la sortie du premier et l’entrée du dernier présentent toujours la même empreinte. La continuité mathématique du contenu survit à l’effacement d’un participant. Ce cas, détaillé dans l’annexe A du projet, explique pourquoi une liste de modifications n’est pas à elle seule un registre fiable des passages.

Le document révisé s’intitule Authenticated Provenance for WIMSE Delegation Chains. Le suivi de l’IETF le classe parmi les projets individuels actifs et précise qu’un tel dépôt n’est pas approuvé par l’IETF. Il n’a pas de flux RFC; son état IESG est simplement I-D Exists. L’idée de réunir les signatures figurait déjà dans la version -00 du 8 septembre. La nouveauté rédactionnelle de -01 est d’exposer plus nettement ce que prouvent deux mécanismes complémentaires, avec un traitement plus explicite du chemin, de la requête et de la réponse.

Le projet WIMSE de base consacré aux signatures HTTP authentifie le message d’une charge de travail auprès de son destinataire immédiat. Il ne prétend pas conserver, pour le destinataire final, tous les maillons d’une délégation. Le projet individuel ajoute des empreintes de ce que chaque maillon reçoit et expédie. Lorsque l’un d’eux transforme le corps du message, supprimer son entrée rompt la correspondance avec les voisins. Les valeurs portant sur le chemin et la requête aident également à attribuer une transformation au maillon signataire; elles ne disent rien de la justesse du contenu.

Pour le relais qui ne transforme rien, le texte propose une signature agrégée. Chaque participant contribue à une valeur collective, sans que sa signature isolée soit transportée. Le vérificateur contrôle cette valeur par rapport à l’ensemble des signataires déclarés. Dans le modèle et sous les hypothèses cryptographiques du projet, omettre un signataire qui n’a changé aucun octet ferait échouer la vérification. Il s’agit d’une propriété revendiquée pour une proposition, non d’un résultat observé sur un réseau exploité.

La contrepartie mérite d’être lue avant d’en faire une promesse de sécurité. La valeur de signature reste proche de la taille d’une seule signature, mais les identités, entrées de signature et empreintes s’accumulent. Tous les maillons doivent partager une famille d’algorithmes compatible avec l’agrégation. Selon le texte, ML-DSA ne permet pas cette agrégation et le repli sur des signatures individuelles perd la protection du relais inchangé. Une seule contribution défectueuse invalide l’ensemble sans désigner immédiatement son auteur.

La lignée authentifie l’ordre des maillons qui modifient le message, pas, à elle seule, celui de relais consécutifs qui le transmettent intact. Les champs proposés ne sont encore que des demandes d’enregistrement auprès de l’IANA.

Enfin, le projet écarte explicitement l’autorisation de son périmètre. Prouver qu’une charge de travail a signé ne démontre pas qu’elle avait le droit de voir cette tâche ou de l’exécuter. Il faut garder la décision de politique et le résultat du destinataire à part de la preuve de passage.

Sources