Résumé

  • RFC 9999 fournit une enveloppe commune et auto-descriptive aux Evidence, Endorsements, Reference Values, Attestation Results et Appraisal Policies de RATS.
  • Les formes Record, Tag et Collection indiquent une structure et un type ; elles n’apportent seules ni authenticité, ni intégrité, ni confidentialité, ni décision d’accès.
  • Lorsqu’une Collection représente un équipement composite, ses éléments de preuve doivent être liés cryptographiquement avant que le Verifier ne les apprécie et que la Relying Party ne décide de l’action permise.

Prenons un serveur destiné à une zone de calcul confidentiel. Son processeur principal décrit sa chaîne de démarrage. La SmartNIC atteste son micrologiciel. Le GPU produit un troisième objet depuis son propre environnement d’attestation. Un service assemble les trois objets dans une Collection CMW et l’envoie au vérificateur.

Un attaquant remplace alors uniquement l’élément de la SmartNIC par une preuve authentique provenant d’une machine saine. Les trois signatures individuelles peuvent rester valides. Les types de média sont connus. La collection est syntaxiquement impeccable. Elle raconte néanmoins une machine qui n’existe pas. Sans une liaison couvrant l’appareil, la session et la composition, plusieurs vérités locales peuvent fabriquer une conclusion globale fausse.

C’est la frontière essentielle du RFC 9999, publié en juillet 2026 sur le Standards Track de l’IETF. Le RATS Conceptual Message Wrapper rend les messages conceptuels de l’architecture RATS transportables dans des protocoles et sérialisations différents. Il standardise l’enveloppe, pas la véracité de ce qu’elle contient.

Reconnaître le message n’est pas l’apprécier

Dans le RFC 9334, l’Attester produit l’Evidence. Le Verifier combine cette Evidence avec des Endorsements, des Reference Values et une Appraisal Policy for Evidence pour produire un Attestation Result. La Relying Party applique ensuite sa propre Appraisal Policy for Attestation Results avant de déclencher une action propre à l’application.

RFC 9999 conserve ces fonctions dans un registre d’indicateurs. Les positions 0 à 4 représentent les Reference Values, Endorsements, Evidence, Attestation Results et Appraisal Policy. Un Record CMW contient un type de média ou un CoAP Content-Format, la valeur sérialisée et, lorsqu’une ambiguïté existe, un bitmap ind.

Ce bitmap permet de sélectionner le bon gestionnaire. Il ne garantit pas que l’objet est recevable. Une valeur de référence peut être périmée ; un endorsement peut être signé par une clé fabricant non approuvée ; une Evidence authentique peut être trop ancienne ; un résultat peut provenir d’une autre politique ; la politique elle-même peut avoir été altérée.

Le cœur d’un processeur CMW peut ainsi rester agnostique et passer le contenu opaque à un module spécialisé. Cette qualité d’architecture crée aussi une limite de pouvoir. Le composant qui choisit le décodeur exerce une fonction d’aiguillage. Il n’acquiert pas le droit de déclarer la plateforme digne de confiance.

Une Collection est un arbre, pas un certificat d’unité

Record et Tag forment les feuilles de l’arbre CMW. Record nomme directement la sérialisation ; Tag utilise un numéro CBOR dérivé d’un CoAP Content-Format. Collection rassemble plusieurs CMW sous des libellés uniques et peut elle-même contenir d’autres collections.

Cette construction répond à la réalité d’une machine hétérogène. Un CPU, une SmartNIC et un GPU peuvent s’appuyer sur des formats de preuve différents. L’enveloppe commune évite de refaire le protocole externe à chaque évolution matérielle.

Mais la grammaire autorise aussi une Collection à mélanger plusieurs types de messages ou des objets concernant plusieurs appareils. Sa simple existence ne signifie donc pas « une machine complète ». Le champ facultatif __cmwc_t, sous forme d’URI ou d’OID, donne un type global et un espace de noms aux libellés. Il peut décrire un assemblage attendu. Non protégé, il reste une assertion sur la forme, pas une preuve de la forme.

La récursion introduit une autre décision locale : la profondeur maximale. Une passerelle qui n’inspecte qu’un niveau et un Verifier qui en accepte quatre peuvent attribuer des sens différents au même objet. Les limites de profondeur, de taille, de nombre d’éléments et le traitement des types inconnus doivent être alignés à l’échelle du protocole hôte.

Trois signatures ont encore besoin d’un lien

RFC 9999 précise que CMW n’est pas un format de sécurité. Un objet CBOR peut être signé avec COSE_Sign1 ; une forme JSON avec JWS ; une enveloppe peut aussi figurer dans un claim cmw d’un CWT ou d’un JWT. Ces mécanismes existent, mais aucun n’est implicite.

Lorsque la Collection porte l’Evidence d’un seul appareil composite ou en couches, tous les éléments doivent être liés cryptographiquement. La protection peut couvrir la collection entière. Elle peut aussi reposer sur des identifiants communs, des nonces corrélés, des signatures ou des hachages entre éléments. L’Attester qui construit la Collection porte la responsabilité de son intégrité.

La portée de la liaison détermine ce que l’on sait. Une signature du collecteur prouve que ce service a signé des octets ; elle ne prouve pas nécessairement que sa clé appartient à la racine d’attestation de l’appareil. Un même numéro de série répété partout n’est utile que si les composants ne peuvent pas l’inventer. Un nonce commun lie une session seulement s’il est arrivé par un chemin authentifié dans chaque environnement et si chaque réponse l’a effectivement couvert.

Le dossier d’audit doit donc dépasser signature_valid=true. Il lui faut le hachage brut de la Collection, sa forme, son type, les libellés, les types internes, les indicateurs, les identités de clé, les éléments de fraîcheur, la méthode de liaison, la profondeur et la transcription de validation. Sinon, impossible de savoir après coup si la cryptographie couvrait les feuilles, l’assemblage ou uniquement le jeton externe.

Le transport déplace aussi la frontière de confiance

RFC 9999 enregistre application/cmw+cbor, application/cmw+json, application/cmw+cose et application/cmw+jws, ainsi que les claims JWT/CWT et une extension X.509. Le même vocabulaire peut donc passer par une API web, un protocole contraint, un certificat ou un fichier.

Chaque support protège une surface différente. Un JWS peut signer la Collection sans protéger l’Evidence extraite ensuite. Un JWT peut authentifier son émetteur sans établir l’origine de tous les objets internes. TLS protège un canal, pas l’auteur initial d’un objet transféré. Une conversion CBOR vers JSON peut conserver le sens tout en détruisant la signature sur les octets et la matière nécessaire à une relecture forensique.

Le protocole hôte doit donc spécifier les types et combinaisons admis, les protections requises, l’interface avec CMW et l’effet de leur interaction sur la sécurité. Écrire seulement « payload CMW » choisit une syntaxe sans définir un modèle de confiance.

L’extension X.509 illustre le choix. Elle ne devrait normalement pas être marquée critique. Elle peut l’être lorsque le message enveloppé conditionne l’accès à une ressource et qu’une ancienne Relying Party risquerait de l’ignorer. La criticité décide alors si un client non averti s’arrête ou contourne silencieusement l’exigence d’attestation.

La publication dans un certificat modifie aussi le cercle de divulgation. Une Evidence peut contenir des données personnelles, le modèle d’un HSM ou son niveau de correctif. Les communiquer à une autorité de certification ne vaut pas consentement à les publier durablement. Le RFC demande une politique de certification explicite lorsque ces informations doivent être diffusées dans un certificat public.

Le résultat n’est toujours pas l’autorisation

Le dernier raccourci consiste à transformer un Attestation Result positif en ordre d’accès. L’architecture RATS l’interdit conceptuellement en séparant le Verifier Owner, qui définit l’appréciation de l’Evidence, du Relying Party Owner, qui décide comment le résultat agit sur l’application.

Un même résultat valide peut autoriser la télémétrie, imposer une quarantaine pour le plan de contrôle et rester insuffisant pour une opération de signature. Le service demandé, la zone réseau, la durée de validité et l’exception métier appartiennent au contexte de la Relying Party.

Un enregistrement rejouable relie sans fusionner : Evidence et liaison ; versions des endorsements et reference values ; politique du Verifier et résultat ; politique de la Relying Party et action demandée ; décision finale. Réduire le tout à un booléen supprime la causalité. Garder seulement le jeton supprime l’autorité qui l’a appliqué.

La primauté du code exécuté défendue par Lu Heng prend ici une forme concrète : la conformité de l’enveloppe est une provenance, mais elle ne peut pas contredire ce que les gestionnaires, le Verifier et le contrôle d’accès ont réellement fait. La Minimum Initial Specification justifie une grammaire commune mince. Les choix de liaison, de combinaison et de conséquence restent locaux. Les Reality Layers empêchent de confondre un type, une signature, une appréciation et une action de production.