Résumé

  • suit-report-reason-invoke-pending indique que l’invocation va être tentée, sans affirmer son résultat ; ce n’est ni un succès anticipé ni une preuve d’échec.
  • Les SUIT_Record sont des repères compressés : sans le manifeste exact validé par son empreinte, leur chemin d’exécution ne doit pas être reconstruit.
  • Une décision sérieuse relie signature, fraîcheur, manifeste, mesures de l’environnement, passage de contrôle et observation du service au lieu de faire porter tout le verdict au rapport.

Signer avant de perdre la main

Dans une chaîne de démarrage, le dernier geste du processeur de manifeste peut être le plus difficile à documenter. Il a validé des conditions, parcouru des séquences et prépare l’invocation. La commande suivante transfère le contrôle à un programme qui, par conception, peut ne jamais revenir.

Pour une attestation distante, attendre le retour n’est donc pas toujours possible. Signer le rapport avant l’invocation devient nécessaire. Mais inscrire « succès » à ce moment reviendrait à certifier le futur.

Le projet draft-ietf-suit-report-22 refuse cette facilité. La raison suit-report-reason-invoke-pending dit seulement que l’invocation est imminente et que son résultat final demeure inconnu. Le texte précise qu’un succès inconditionnel serait trompeur si le code appelé échouait ensuite.

Cette nuance protège la valeur du rapport. Une signature valide garantit l’origine et l’intégrité des octets protégés. Elle ne garantit pas qu’une instruction future sera exécutée. L’horodatage logique du propos compte autant que sa protection cryptographique.

Un journal qui ne se lit pas seul

Le format économise les octets en utilisant le manifeste comme dictionnaire. Un SUIT_Record conserve un chemin dans l’arbre de dépendances, une séquence de commandes, un décalage, un index de composant et certaines propriétés mesurées. Il ne recopie pas tout ce que la commande signifiait.

La conséquence est normative : les enregistrements n’ont de sens pour la reconstruction que si le destinataire obtient le manifeste correspondant et le valide avec suit-report-manifest-digest. Si le manifeste contient une URI de référence, le rapport doit reprendre exactement cette URI. Sans le manifeste correspondant, la reconstruction à partir des SUIT_Record est interdite.

Pourquoi l’empreinte plutôt qu’un numéro de séquence ? Parce que plusieurs signataires autorisés peuvent produire des numéros identiques. Une séquence indique un ordre local ; elle n’identifie pas nécessairement un objet unique. L’empreinte caractéristique désigne les octets du manifeste qui donnent leur sens aux repères.

Les system-property-claims constituent une exception limitée : ils portent directement un identifiant de composant et peuvent être traités sans charger d’abord le manifeste. Leur autonomie souligne précisément ce qui manque aux simples offsets.

Archiver seulement le rapport revient donc à conserver une carte sans légende. La carte reste authentique. Elle cesse d’être une preuve exploitable dès que son manifeste exact disparaît.

Fraîcheur, authenticité et autorité

Un nonce peut protéger contre la répétition. Il peut aussi être omis quand le conteneur d’authentification offre déjà la fraîcheur, par exemple grâce à un défi d’attestation. Cette souplesse ne mélange pas les questions.

L’authenticité demande qui a produit le rapport et si son contenu a changé. La fraîcheur demande s’il appartient à l’échange présent. L’empreinte du manifeste demande quelle instruction permet de lire les repères. L’autorité demande si ce signataire et cette politique sont recevables pour ce parc. Le résultat indique enfin ce que le processeur savait lors de la signature.

Un rapport invoke-pending frais reste un rapport en attente. Un ancien succès peut être parfaitement signé et ne rien dire du redémarrage courant. Une correspondance d’empreinte peut être exacte alors que l’environnement de mesure est compromis.

La machine qui produit la preuve fait partie de la preuve

Pour servir d’Attestation Evidence, le rapport ne suffit pas à lui-même. La révision 22 exige que l’environnement qui l’a généré soit mesuré : le Manifest Processor, le Report Generator, ainsi que les chargeurs de démarrage et systèmes d’exploitation pertinents.

Cette exigence évite une erreur classique : valider le conteneur sans évaluer l’instrument qui a choisi les affirmations. Un générateur altéré peut signer une histoire cohérente. Un processeur modifié peut produire un rapport exact sur les décisions du mauvais logiciel.

L’architecture RATS de la RFC 9334 distribue les responsabilités. L’Attester fournit des Evidence. Le Verifier les évalue selon une politique et produit des Attestation Results. La Relying Party prend ensuite sa décision. La confiance est cette décision ; la fiabilité est une qualité de la cible. Aucun rôle ne doit emprunter le mandat de l’autre.

Le vérificateur doit également convertir le journal SUIT. Avec le manifeste correspondant, il reconstruit les étapes puis formule des affirmations compréhensibles pour la partie qui s’y fie. Sans dictionnaire exact ou sans mesure de l’environnement, la conclusion peut être élégante et incomplète.

La confidentialité ne transforme pas « bientôt » en « fait »

Les rapports distants doivent emprunter un canal authentifié et confidentiel ou une protection équivalente. Un conteneur COSE, une affirmation protégée dans un EAT ou un transport sécurisé peuvent remplir ce rôle. Si la politique exige l’authentification, l’appareil ne doit pas envoyer une version non authentifiée ; un rapport partiel reste soumis à la même intégrité.

Ces règles ferment des attaques de falsification et d’exposition. Elles ne changent pas le verbe du résultat. Chiffré, signé et frais, invoke-pending signifie toujours « l’essai va commencer ».

Après ce message, il faut un témoin nouveau : mesure de démarrage, heartbeat, état d’application ou sonde extérieure. Il doit indiquer ce qu’il observe et depuis quel point.

Un dossier de preuves après le point de bascule

Le dossier minimal conserve les octets du rapport, la méthode d’authentification, l’identité du signataire et le mécanisme de fraîcheur. Il fixe l’empreinte du manifeste racine, récupère les octets correspondants et reconstruit seulement alors le chemin, la séquence, l’offset et le composant.

Il ajoute l’évaluation des mesures du processeur, du générateur, du bootloader et de l’OS. Puis il enregistre sans réécriture le résultat : succès, échec, passage implicite de contrôle ou invoke-pending.

La suite appartient au monde exécuté : preuve que le point d’entrée a été atteint, preuve de durée de vie, observation du service. L’ordre est volontaire :

rapport protégé → fraîcheur → manifeste exact → reconstruction → environnement mesuré → passage de contrôle → exécution → service

Au moment de la recherche, la révision 22 restait un Internet-Draft visant Proposed Standard. Le Datatracker la plaçait dans la file du RFC Editor, bloquée par une référence de seconde génération. Ce n’était pas un RFC, et ce statut ne prouve ni mise en œuvre ni interopérabilité.

Sources