Résumé

  • RFC 9999 définit un emballage autodécrit pour transporter les preuves, résultats d’attestation, recommandations, valeurs de référence et politiques d’évaluation RATS dans plusieurs encodages et protocoles.
  • Les formes Record, Tag et Collection indiquent comment reconnaître et aiguiller un contenu ; elles n’apportent seules ni authenticité, ni intégrité, ni confidentialité, ni fraîcheur.
  • Pour représenter un équipement composite ou en couches, les éléments doivent être liés cryptographiquement entre eux ; plusieurs preuves individuellement valides ne prouvent pas spontanément une seule machine.

Le scénario commence par un remplacement banal. Une carte d’un routeur de production tombe en panne. Le stock contient une carte saine du même modèle. Quelques heures plus tard, l’outil d’admission reçoit une collection d’attestations : le châssis, la carte principale et les cartes de ligne ont chacune un élément, un type reconnu et une signature valide.

Mais la preuve de la carte saine pourrait provenir du stock, non du logement qui vient d’être remis en service. Les signatures diraient toujours vrai sur leurs objets respectifs. La collection mentirait par assemblage.

C’est la limite que permet de voir RFC 9999, publié en juillet 2026 sur la voie Standards Track de l’IETF. Le Conceptual Message Wrapper de RATS, ou CMW, résout un problème d’interopérabilité : faire circuler des messages d’attestation hétérogènes sans obliger chaque protocole d’accueil à connaître d’avance tous les formats. Il ne transforme pas la proximité syntaxique en unité matérielle.

Un vocabulaire commun pour des objets qui restent différents

RFC 9334 sépare les rôles avant de parler de format. L’Attester produit des Evidence. Le Verifier les confronte aux Endorsements, aux Reference Values et à une Appraisal Policy, puis émet des Attestation Results. Le Relying Party applique ensuite sa propre politique pour décider d’un accès, d’une remise de clé ou d’une commande.

CMW conserve cette répartition. Un Record contient un type, une valeur opaque et éventuellement un indicateur. Cet indicateur peut signaler cinq natures de message : Reference Values, Endorsements, Evidence, Attestation Results ou Appraisal Policy. Un Tag utilise un identifiant CBOR dérivé d’un CoAP Content-Format selon RFC 9277. Une Collection réunit des CMW étiquetés et peut contenir d’autres collections.

Le registre public IANA RATS Parameters coordonne les indicateurs. RFC 9711 définit l’Entity Attestation Token et RFC 9782 ses types de média. L’ensemble permet à un cœur logiciel de choisir un gestionnaire sans deviner le format.

Choisir n’est pas croire. Le champ type désigne une grammaire ; il ne certifie ni la véracité des claims, ni la qualité de l’émetteur. L’indicateur « Evidence » décrit une fonction dans le flux RATS ; il n’atteste pas que la preuve appartient au demandeur. Une inscription IANA empêche les collisions d’identifiants ; elle n’impose ni prise en charge, ni politique, ni confiance.

L’emballage ne signe rien par sa seule présence

RFC 9999 qualifie le CMW d’encapsulation, non de format de sécurité. Un Record, un Tag ou une Collection sans mécanisme supplémentaire n’offre aucune authenticité, intégrité ou confidentialité.

La protection peut se trouver à l’intérieur du message conceptuel. Elle peut entourer un CMW CBOR avec COSE, défini par RFC 9052, ou un CMW JSON avec JWS, défini par RFC 7515. Un canal sécurisé peut protéger le transport. Un protocole défi-réponse peut apporter une défense contre le rejeu.

Ces mécanismes ne couvrent pas le même périmètre. TLS protège une session, pas nécessairement l’objet après son stockage. Une signature sur chaque élément authentifie plusieurs objets, mais ne prouve pas qu’ils appartiennent au même équipement. Une signature sur la collection protège l’assemblage, à condition que la clé soit autorisée à affirmer cette composition et que le profil signé en donne le sens.

RFC 9781 fournit un rappel particulièrement net. Un UCCS est un ensemble de claims CWT non protégé. Le placer dans un CMW facilite son transport ; aucune propriété cryptographique n’apparaît. RFC 9999 montre comment signer l’emballage lorsque cette protection est nécessaire. La sécurité vient d’un acte supplémentaire, observable et vérifiable.

La substitution exploite les frontières entre composants

Les équipements réels ne sont pas monolithiques. Un serveur peut disposer d’environnements d’attestation séparés pour son processeur, sa SmartNIC et son GPU. Un routeur peut comprendre un châssis et plusieurs cartes. Une chaîne de démarrage peut produire des preuves à plusieurs couches.

Une Collection CMW autorise ces formats différents à cohabiter. Pour l’attestation d’un seul équipement composite ou en couches, RFC 9999 exige toutefois une liaison cryptographique de tous les messages Evidence. Sans protection de l’objet complet ou liaison interne entre éléments, un attaquant peut remplacer la preuve d’un composant compromis par celle d’un composant sain.

La norme n’impose pas une seule technique. Une signature peut couvrir la collection entière. Des identifiants et des nonces peuvent relier les membres. Les éléments peuvent se signer ou se hacher mutuellement. Le protocole d’accueil peut définir une autre construction. La question de contrôle est donc précise : quel champ validé rattache chaque membre au sujet, à la topologie et à la transaction revendiqués ?

Il serait tout aussi faux de supposer que toute collection représente une seule machine. RFC 9999 permet de regrouper des Endorsements, des Reference Values ou des résultats concernant plusieurs équipements. La Collection donne une structure ; son profil facultatif doit définir ce que signifie la composition.

Les étiquettes ne sont uniques qu’à l’intérieur de la collection et leur ordre n’est pas significatif. slot-3 ou gpu n’acquiert pas une identité universelle. Il faut encore une correspondance avec l’inventaire installé, une génération de topologie, un profil d’assemblage et une responsabilité de mise à jour.

La récursivité crée un budget, pas seulement une élégance

Une Collection peut en contenir une autre. Cette récursivité suit bien un matériel en couches, mais elle déplace aussi du risque vers le parseur : profondeur, nombre d’éléments, volume total, décodage Base64, vérifications cryptographiques et consultations externes peuvent croître ensemble.

RFC 9999 permet aux implémentations de limiter la profondeur ; il laisse hors périmètre le détail de la découverte et de la négociation de cette limite. L’exploitant doit donc fixer ses propres plafonds : octets, membres, profondeur, coût cryptographique, temps par gestionnaire et nombre d’appels vers les sources de référence.

Le comportement face à l’inconnu doit également être écrit. Un service d’archivage peut conserver un objet opaque. Une porte d’autorisation ne peut pas ignorer un élément non pris en charge et annoncer ensuite que l’équipement composite est conforme. « Invalide », « non pris en charge », « absent » et « non requis par ce profil » sont quatre états distincts.

La promesse d’extensibilité du CMW est alors tenue sans devenir une prime à l’ignorance : chaque type accepté doit avoir un gestionnaire versionné, un profil, une politique d’algorithmes, un budget et un mode d’échec.

La fraîcheur et l’évaluation vivent ailleurs

Une preuve parfaitement signée peut décrire l’état d’hier. Après une mise à jour de microcode, un échange de carte ou une modification des valeurs de référence, sa validité cryptographique ne suffit plus.

RFC 9334 traite la fraîcheur au moyen du temps synchronisé, de nonces ou d’identifiants d’époque. CMW peut transporter les objets concernés, mais ne démontre pas que tous les membres couvrent le même défi. Si le processeur répond au nonce A, la carte réseau au nonce B et le GPU à un horodatage, le profil d’assemblage et la politique du Verifier doivent décider si l’ensemble décrit une transaction cohérente.

Ensuite vient l’évaluation. Le Verifier peut conclure que l’équipement correspond à une politique de référence. Le Relying Party conserve le droit de refuser une action particulière. Un serveur suffisamment sain pour le réseau de maintenance ne devient pas, par cette seule conclusion, autorisé à lire les données d’un client ou à signer une version logicielle.

La piste de preuve complète retient donc le défi, l’époque, les membres couverts, les clés, les Endorsements, les Reference Values, la version de la politique du Verifier, le résultat, la politique du Relying Party et l’effet observé. « Décodage réussi » et « signature valide » sont des étapes, non une clôture.

Le certificat peut rendre publique une confidence

RFC 9999 autorise aussi le CMW dans les certificats X.509, les demandes de certificat et les listes de révocation. Ce canal est pratique et durable. C’est précisément ce qui peut le rendre dangereux.

Une personne ou une entreprise peut accepter de révéler à une autorité de certification le modèle d’un HSM ou son niveau de correctif pour obtenir un certificat de signature de code. Elle n’a pas nécessairement consenti à publier ces détails auprès de tous les destinataires du certificat. RFC 5280 définit le cadre PKIX général ; il ne crée pas ce consentement. RFC 3647 donne le cadre des politiques et pratiques de certification. RFC 9999 demande qu’une pratique explique dans quelles circonstances une CA peut inclure des Evidence reçues d’un tiers.

Le contrôle de confidentialité doit précéder l’émission : minimisation des claims, audience, durée de conservation, profil de certificat et autorité de publication. Après diffusion mondiale, la révocation ne rappelle pas les informations déjà copiées.

La réalité opérationnelle doit refermer la chaîne

Le principe du running code de Heng Lu oblige à regarder le chemin exécuté : quel parseur a choisi quel gestionnaire, quels octets ont été protégés, quelle clé a été admise, comment la liaison et la fraîcheur ont été prouvées, quelle politique a produit quelle décision et quel effet a réellement suivi.

Son texte sur la spécification initiale minimale et la décision future localisée éclaire aussi l’équilibre. L’enveloppe et les registres communs réduisent les coûts de compatibilité. Les seuils de santé, l’autorisation et la responsabilité peuvent rester locaux, à condition d’avoir un propriétaire identifiable.

Enfin, la distinction entre couches de réalité empêche quatre constats de se remplacer : conformité syntaxique, protection cryptographique, évaluation sémantique et effet opérationnel. La clarté consiste à conserver les quatre verdicts.