Résumé

  • Le 25 septembre, l’IESG a lancé une dernière consultation sur la version 17 de SATP Core, envisagée comme Proposed Standard. Les observations sont attendues au plus tard le 9 octobre ; aucun RFC n’est encore approuvé.
  • Selon le projet, l’effet d’un message d’abandon varie avec l’étape atteinte. Après l’envoi de commit-final, il ne permet plus d’annuler l’engagement ; un abandon peut aussi ne jamais parvenir au pair si une passerelle tombe en panne.
  • Le texte indique expressément que la récupération et la reprise d’une session ne sont pas prises en charge par le protocole actuel. Cette limite ne tranche pas la question d’éventuelles procédures extérieures.

Une passerelle peut recevoir un ordre d’arrêt trop tard. C’est la distinction qui mérite d’être lue dans SATP Core au moment où l’Internet Engineering Steering Group demande des commentaires sur ce texte. La consultation ouverte le 25 septembre porte sur le cœur technique d’un transfert entre réseaux d’actifs numériques, avec une perspective de Proposed Standard. Elle ne doit pas être confondue avec les consultations précédentes sur l’architecture et les cas d’usage, destinés à des RFC informatifs et déjà traités sous l’angle de la responsabilité des passerelles.

Le modèle proposé emploie deux passerelles qui parlent chacune pour leur réseau. Le protocole cherche à coordonner la validité d’un actif de part et d’autre, au moyen d’un canal sécurisé et d’un engagement en deux phases. Après l’initialisation, la passerelle d’origine verrouille l’actif et signe une déclaration. La préparation de l’engagement amène la destination à créer un actif sous son contrôle et à se dire prête ; viennent ensuite l’extinction de l’actif d’origine, l’assertion finale, l’attribution au bénéficiaire et l’accusé de réception.

Réduire cette suite à un simple « transfert réussi ou échoué » efface les états intermédiaires dont dépend une décision de reprise.

La section 11.5 ne présente pas l’abandon comme un retour en arrière universel. Avant que la destination ne confirme qu’elle est prête, le texte décrit des moyens de déverrouiller l’origine ou de renverser les changements locaux à destination. Mais il avertit qu’un message d’abandon peut être perdu, notamment si une passerelle s’interrompt avant de le recevoir. Après l’envoi de commit-final par l’origine, l’abandon n’est plus efficace selon le projet. Le point utile n’est donc pas la seule présence d’une commande d’abandon, mais l’état effectivement atteint et connu des deux côtés.

Une autre phrase du projet mérite autant d’attention que le diagramme de messages. La section 10.8 précise que la récupération et la reprise de session ne sont pas prévues dans la version actuelle ; elles pourraient faire l’objet d’une version ultérieure ou d’un autre document. Le protocole ne fournit donc pas à lui seul un chemin prescrit pour reprendre une conversation interrompue. Cela ne prouve ni qu’une opération donnée serait irrécupérable, ni qu’un opérateur disposerait automatiquement d’un mécanisme extérieur fiable. Il faut distinguer les deux questions.

Les auteurs évoquent aussi les coûts de perturbations, de messages retardés ou abandonnés intentionnellement et de clés compromises. Il s’agit de risques analysés, non d’un incident observé. La charte du groupe de travail prévoit par ailleurs que des accords juridiques ou autres seront vraisemblablement nécessaires entre réseaux et les situe hors du champ de SATP. Une signature atteste l’origine et l’intégrité d’un message ; elle n’attribue pas d’elle-même les pertes d’une transaction interrompue.

La date du 9 octobre est une échéance pour les commentaires, pas une date de mise en service. Le test de gouvernance de cette consultation est simple à formuler et difficile à éluder : qui constate le dernier état partagé, qui décide de franchir la phase irréversible et quelle preuve subsiste si le pair ne répond plus ? Poser ces questions au projet de norme est plus utile que d’inférer la sécurité d’une exploitation réelle de la seule promesse d’atomicité.

Sources