Résumé

  • L'IESG a lancé le 24 août un dernier appel sur draft-ietf-rats-endorsements-09, en vue d'une publication comme RFC Informational. Les commentaires sont attendus jusqu'au 7 septembre et aucune décision finale n'est acquise.
  • Dans une contribution publique qui doit lui être attribuée, Anton Sokolov a séparé l'invariance d'une affirmation de la qualité persistante de l'Endorser, puis demandé si cette qualité se vérifie au moment de l'Evidence ou au moment de l'évaluation.
  • Les auteurs ont répondu que CoRIM possédait déjà deux fenêtres, l'une pour le contenu, l'autre pour la signature. Le contributeur a considéré la question résolue, tandis que les éditeurs ont choisi d'en conserver la trace dans le projet.
  • La pull request 76 a été fusionnée le 28 août. La copie latest explique désormais rim-validity, signature-validity, révocation et trust anchor, mais la version numérotée 09 ne contient pas ces paragraphes.
  • Un reçu de traitement devrait relier contribution, réponse, différence relue, fusion, prochaine version numérotée, choix de politique, résultat d'évaluation et décision de l'IESG. Il documenterait le progrès sans faire passer une fusion éditoriale pour une approbation de l'IETF.

Une consultation ouverte sur un texte encore daté

Le message de l'IESG du 24 août ne proclame aucune nouvelle règle. Il invite la communauté à examiner la version 09 de RATS Endorsements, que le groupe Remote ATtestation ProcedureS souhaite publier comme RFC de statut Informational. La date limite est le 7 septembre.

Au moment de cette enquête, la fiche Datatracker affichait toujours « In Last Call », revision 09, sans date de telechat ni action finale. Cette photographie officielle ne disparaît pas parce que le dépôt de travail a évolué. Le texte soumis, la source éditoriale courante et la décision de publication sont trois états distincts.

L'architecture RATS distribue elle aussi les rôles. Un Attester émet de l'Evidence sur l'état d'un système. Un Verifier l'évalue, généralement à l'aide de Reference Values, d'Endorsements et d'une Appraisal Policy for Evidence. Le Verifier Owner fait autorité pour cette politique ; le Relying Party Owner décide de la politique appliquée aux Attestation Results. Un Endorser apporte des assertions supplémentaires. Sa signature ne le transforme pas en autorité finale sur la confiance.

La section 5 de la version 09 confie aux spécifications de protocole le soin d'assurer la temporalité de l'Endorsement lui-même, par exemple au moyen de la durée d'un certificat. Elle ajoute qu'une affirmation « static », décrivant une propriété invariante de l'Environment, ne demande pas de mécanisme temporel supplémentaire pour son contenu.

Ces deux propositions sont compatibles. Leur enchaînement pouvait néanmoins laisser croire que le caractère statique du contenu réglait aussi le sort temporel de celui qui l'avait signé.

Une propriété immobile, trois états susceptibles de bouger

Anton Sokolov a formulé la distinction dans un commentaire public de dernier appel. Une caractéristique matérielle peut rester identique tandis que le certificat du fabricant expire, que sa clé est révoquée ou que le Verifier retire le trust anchor correspondant. La stabilité de l'énoncé et la qualité actuelle de l'Endorser ne sont pas la même propriété.

Il a ensuite posé une question de référence temporelle. Si l'Evidence décrit l'Attester à T1 et que l'évaluation a lieu à T2, doit-on apprécier la qualité de l'Endorser à T1 ou à T2 ? La contribution soutenait la publication et ne signalait ni attaque, ni appareil compromis, ni mise en œuvre fautive. Elle demandait de nommer le choix.

Ce raisonnement appartient au contributeur qui l'a publié. Le travail éditorial de Daniel Kade ne consiste pas à s'en attribuer l'origine, mais à examiner comment une institution démontre le parcours qui mène de cette contribution à une modification, puis éventuellement à un texte approuvé.

Thomas Fossati, coauteur du document, a d'abord reformulé le correctif : les contrôles portant sur la qualité de l'Endorser sont logiquement indépendants de la temporalité du contenu ; le choix T1 ou T2 revient au protocole ou à la politique d'évaluation. Sokolov a approuvé et proposé, à titre complémentaire, que le résultat permette de savoir quel repère a été appliqué.

La discussion a alors retrouvé le mécanisme dans des travaux existants. Fossati a expliqué que le processeur CoRIM conserve deux fenêtres séparées : l'une pour le contenu, l'autre pour la signature. Dans cet exemple, la validité de la signature, la révocation et l'état du trust anchor sont examinés au moment de l'évaluation. L'identité du Verifier dans l'Attestation Result peut rendre ce choix interprétable. Sokolov a ensuite clos sa réserve, satisfait qu'un dispositif existant fournisse la réponse.

La conversation aurait pu rester une explication dans les archives. Les éditeurs ont décidé d'en faire aussi une modification du texte.

La pull request corrige plus qu'une ambiguïté de certificat

La pull request 76, ouverte le 25 août, a reçu plusieurs retouches, puis l'approbation de Dave Thaler et de Henk Birkholz. Elle a été fusionnée le 28 août avec le commit bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624.

Dans la copie actuelle des éditeurs, un même relevé de micrologiciel peut recevoir deux appréciations à des dates différentes. Avant la découverte d'une vulnérabilité, un Endorser le qualifie de fiable ; après, il peut le qualifier de non fiable. Les deux messages peuvent être signés par un Endorser dont la qualité n'a jamais cessé. rim-validity sert alors à borner le contenu et à déterminer quel Endorsement s'applique.

Une autre fenêtre porte sur l'Endorser. Sa clé, son certificat ou son trust anchor peuvent changer d'état. Le texte cite signature-validity et indique que le processeur CoRIM vérifie cette fenêtre, la révocation et le trust anchor au moment de l'évaluation. Un autre protocole peut retenir un autre repère ; sa spécification ou sa politique doit alors l'indiquer.

La formule « deux horloges » simplifie donc une réalité à trois mouvements : la valeur décrivant l'Environment, le jugement de l'Endorser sur cette valeur et la qualité de l'Endorser lui-même. Réduire les trois à un badge « valide » détruit le motif de la décision, même si chaque contrôle local a été exécuté correctement.

Le dépôt donne une preuve de fusion, pas une délégation de l'IESG

Les lignes ajoutées, les relecteurs et le commit de fusion sont publics. Pourtant, le rendu porte le nom draft-ietf-rats-endorsements-latest. Il ne s'agit ni d'une version 10 publiée sur Datatracker, ni d'un RFC. La version 09 en dernier appel ne comporte toujours pas les nouveaux paragraphes.

Cette différence est normale dans un travail éditorial. Les Internet-Drafts sont des documents de travail et une source courante doit pouvoir recevoir des corrections avant le dépôt d'une nouvelle révision. L'erreur serait d'effacer les étiquettes d'état. « Les éditeurs ont fusionné le texte », « le groupe a soumis la version 09 » et « l'IESG a approuvé la publication » relèvent de pouvoirs différents. Seules les deux premières phrases sont étayées ici, et elles ne décrivent pas le même ensemble d'octets.

Le critère de blanchiment de mandat proposé par Heng Lu s'applique directement. GitHub peut prouver ce que les éditeurs ont accepté ; il ne peut fabriquer la décision de l'IESG. Réciproquement, la position officielle de la version 09 ne rend pas invisible une amélioration déjà intégrée à la source. Il faut relier les couches sans les confondre.

Un reçu public de la contribution jusqu'au texte

Les éléments nécessaires existent déjà dans Mail Archive, GitHub, la copie des éditeurs et Datatracker. Un reçu concis pourrait les réunir sans créer de nouveau droit d'approbation.

Il commencerait par l'URL stable de la contribution, sa date, son auteur, la révision et la section visées, puis une disposition explicite : acceptée, partiellement acceptée, résolue par un mécanisme existant, reportée ou rejetée. Il lierait la réponse responsable, l'issue ou la pull request, les commits de tête et de fusion, les relecteurs, l'heure de fusion et un résumé borné de ce qui a changé.

Il poursuivrait avec la première version numérotée contenant la modification, l'état ultérieur de l'IESG et le numéro de RFC s'il existe. Dans le cas présent, il conserverait aussi la fenêtre du contenu, celle de la qualité de l'Endorser, T1, T2, l'acteur qui choisit le repère et l'identité du Verifier ou de la politique nécessaire pour lire le résultat.

Enfin, le reçu énoncerait ce qu'il ne conclut pas. Une contribution utile ne constitue pas le consensus de l'IETF. Une fusion ne vaut pas autorisation de publier. Une signature correcte établit une provenance sous un chemin de confiance donné ; elle ne prouve seule ni la vérité de l'assertion, ni la compétence institutionnelle de son auteur, ni la fiabilité de l'appareil.

Aucune délibération privée n'est requise. Des liens, empreintes, rôles, dates et états publics suffisent. Le reçu ne remplace ni la liste, ni les éditeurs, ni le groupe, ni l'IESG ; il empêche chaque couche de revêtir l'autorité de la suivante.

Sources