Résumé

  • L’appel à l’adoption RATS pour draft-poirier-rats-eat-da-10 se termine le 11 septembre 2026. Il sollicite une décision sur la prise en charge d’un projet individuel; il n’est ni une adoption achevée, ni un RFC, ni une consigne de déploiement.
  • Un Device Assignment Token peut transporter une preuve de périphérique. Il ne choisit pas les contraintes supplémentaires, n’évalue pas cette preuve, ne fixe pas la politique de la partie utilisatrice et n’autorise pas l’usage du périphérique.

Un appel porte sur un texte, pas sur un périphérique admis

L’objet public est exactement nommé: An EAT Profile for Trustworthy Device Assignment, révision 10. Le Datatracker le présente encore comme un Internet-Draft actif, candidat au travail de RATS, sans approbation IETF ni statut normatif formel. La date de clôture du 11 septembre circonscrit donc la question présente: le groupe doit-il travailler sur ce texte? Une réponse ultérieure peut modifier l’état d’un élément de travail. Elle ne certifie pas une carte réseau, un accélérateur ou une fonction virtuelle pour un environnement déterminé.

Le contexte est néanmoins sensible. L’attribution de périphérique permet à une machine virtuelle de confiance de contrôler un adaptateur, un GPU ou une fonction PCIe, alors que l’hyperviseur ou d’autres machines peuvent être hors de son périmètre de confiance. Le projet demande une preuve sur l’identité, le micrologiciel et la configuration de l’appareil, puis définit le DAT comme profil EAT destiné à représenter cette preuve.

Cette représentation a une valeur pratique. Elle peut rendre compatibles des revendications, des sous-modules, des signatures et des enveloppes qui ne l’étaient pas. Mais elle ne rend pas une observation complète, récente ou acceptable pour une charge donnée. Un format commun réduit l’ambiguïté du dossier; il ne supprime pas le jugement qui suit le dossier.

Les contraintes restent hors du format

Le texte le dit sans détour: il s’appuie sur les informations SPDM et n’impose pas de contraintes de sécurité supplémentaires. Il appartient à d’autres entités de les décrire, de les sélectionner et de les appliquer selon leurs exigences opérationnelles. Ce n’est pas un blanc à combler par extrapolation; c’est le lieu où demeure le contrôle.

Le propriétaire d’une charge doit encore retenir des ancres de confiance, des états de micrologiciel admis, une durée de fraîcheur, des informations de révocation, un vérificateur, des règles de transmission et une possibilité de retour en arrière. Un locataire de cloud, un opérateur de plateforme et une organisation qui manipule une clé sensible peuvent employer le même encodage tout en refusant raisonnablement les mêmes risques. Leurs obligations et leurs pertes ne sont pas interchangeables.

Le périmètre actuel confirme cette réserve: priorité aux périphériques PCIe compatibles SPDM, pas de prise en charge des périphériques SPDM sur puce, et pas de migration à chaud d’une machine virtuelle de confiance. Un document qui délimite lui-même ces cas ne doit pas être présenté comme une conclusion universelle de sécurité.

Le résultat du vérificateur n’est pas l’autorisation

RFC 9334 distingue l’évaluation de la preuve, menée par le Vérificateur avec des valeurs de référence, des endossements et sa propre politique, de l’évaluation du résultat par la Partie utilisatrice. Cette dernière applique sa propre politique pour prendre une décision propre à l’application, notamment une autorisation. Les deux politiques peuvent appartenir à des responsables différents.

RFC 9711 impose une prudence analogue. Un EAT peut décrire une entité afin d’éclairer une décision de confiance, mais il ne fixe pas de règles normatives de traitement pour les vérificateurs. Ceux-ci peuvent transmettre, modifier ou enrichir des revendications conformément à leur politique; la partie utilisatrice doit comprendre ce traitement avant d’interpréter le résultat. Une signature valide et un profil bien formé décrivent un artefact, non un ordre portable d’autoriser un périphérique.

La charte RATS suit cette séparation: formats et procédures de transport sont dans son champ, tandis que les formats et protocoles de politique d’évaluation n’y sont pas. Une norme de format peut donc circuler sans usurper l’appétit de risque de chaque organisation.

Deux reçus, deux responsabilités

Le reçu public doit conserver l’appel, sa date, la révision exacte, la portée du profil, la limite explicite sur les contraintes et toute disposition ultérieure. Il ne doit jamais devenir «RATS a approuvé cet appareil». À côté, un reçu local doit identifier l’appareil, la source de preuve, l’ancre acceptée, le vérificateur et ses règles, les valeurs de référence, la fraîcheur, la version de politique, le périmètre d’autorisation, le responsable et le retour en arrière.

Les éléments à surveiller sont une disposition enregistrée de l’appel, une première version de groupe et toute modification de périmètre. Pour un déploiement, les preuves décisives restent la politique de la partie utilisatrice, la base d’évaluation du vérificateur, la décision d’autorisation et l’observation opérationnelle. Les séparer protège le format au lieu de lui attribuer une autorité qu’il n’a pas.

Sources

  1. Appel RATS à l’adoption de draft-poirier-rats-eat-da-10
  2. Fiche Datatracker du projet
  3. draft-poirier-rats-eat-da-10
  4. Charte du groupe RATS
  5. RFC 9334
  6. RFC 9711