Zusammenfassung

  • Der RATS Call for Adoption für draft-poirier-rats-eat-da-10 endet am 11. September 2026. Er fragt, ob die Gruppe einen individuellen Entwurf übernehmen soll; er ist weder ein abgeschlossenes Adoptionsergebnis noch ein RFC oder eine Betriebsanweisung.
  • Ein Device Assignment Token kann Gerätnachweise transportieren. Es wählt keine zusätzlichen Sicherheitsanforderungen, bewertet keinen Nachweis, setzt keine Politik der vertrauenden Partei und autorisiert keine Gerätenutzung.

Der Aufruf betrifft ein Arbeitspapier, kein zugelassenes Gerät

Das öffentliche Objekt ist genau benannt: An EAT Profile for Trustworthy Device Assignment, Revision 10. Der Datatracker führt es weiterhin als aktiven Internet-Draft und RATS-Kandidaten, nicht als IETF-gebilligte Norm mit formellem Status. Bis zum 11. September lautet die konkrete Frage, ob die Gruppe am Text arbeiten soll. Eine spätere Disposition kann den Zustand eines Arbeitspunkts ändern; sie zertifiziert keinen Adapter, keine GPU und keine virtuelle Funktion für eine bestimmte Last.

Der Kontext ist gleichwohl folgenreich. Die Gerätezuweisung kann einer vertrauten VM die Kontrolle über einen Netzwerkadapter, eine GPU oder eine PCIe-Funktion geben, obwohl Hypervisor oder andere VMs außerhalb ihrer Vertrauensgrenze liegen. Der Entwurf verlangt Nachweise zu Identität, Firmware und Konfiguration und definiert dafür das DAT als EAT-Profil.

Eine gemeinsame Darstellung ist nützlich. Sie macht Claims, Submodule, Signaturen und Umschläge zwischen Implementierungen verständlicher. Doch sie macht eine Beobachtung nicht automatisch vollständig, frisch oder für eine bestimmte Arbeitslast ausreichend. Ein gemeinsames Format verringert Mehrdeutigkeit im Nachweis; es ersetzt nicht das Urteil nach dem Nachweis.

Die Zusatzanforderungen stecken nicht im Token

Der Entwurf sagt ausdrücklich, dass er auf den durch SPDM gelieferten Informationen beruht und keine zusätzlichen Sicherheitsanforderungen auferlegt. Andere Stellen müssen diese Anforderungen nach ihren betrieblichen Bedürfnissen beschreiben, auswählen und durchsetzen. Das ist keine Lücke, die durch die Annahme „das Format hat Sicherheit gelöst“ geschlossen werden darf. Dort bleibt die lokale Kontrolle.

Der Eigentümer muss weiterhin Vertrauensanker, zulässige Firmware- und Konfigurationszustände, die maximale Nachweisalterung, Widerrufsinformationen, den Prüfer, Weiterleitungsregeln und Rückfallbedingungen wählen. Ein Cloud-Mieter, ein Betreiber geteilter GPUs und eine Organisation mit einem sensiblen Schlüssel können dieselbe Syntax nutzen und dennoch zu vernünftigerweise unterschiedlichen Ergebnissen kommen. Ihre Verluste und Pflichten sind nicht austauschbar.

Auch der heutige Umfang verlangt Zurückhaltung: im Mittelpunkt stehen SPDM-konforme PCIe-Geräte; On-Chip-SPDM-Geräte bleiben einer späteren Betrachtung vorbehalten, und die Live-Migration einer vertrauten VM wird nicht erfasst. Ein Format mit diesen eigenen Grenzen ist kein allgemeines Sicherheitsurteil über jede Gerätezuweisung.

Ein Prüferergebnis ist keine Autorisierung

RFC 9334 trennt die Nachweisbewertung durch einen Verifier, der Referenzwerte, Endorsements und eine eigene Bewertungspolitik nutzt, von der Bewertung der Attestation Results durch die Relying Party. Diese wendet ihre eigene Politik für eine anwendungsspezifische Entscheidung einschließlich Autorisierung an. Die beiden Politiken können verschiedenen verantwortlichen Eigentümern zugeordnet sein.

RFC 9711 setzt dieselbe Grenze. Ein EAT kann eine Entität für eine Vertrauensentscheidung beschreiben, legt aber keine normativen Verarbeitungsregeln für Verifier fest. Ein Verifier kann Claims nach seiner Politik weitergeben, verändern oder ergänzen; die vertrauende Partei muss diese Verarbeitung verstehen, bevor sie das Ergebnis auslegt. Eine gültige Signatur und ein wohlgeformtes Profil beschreiben ein Artefakt, nicht den transportablen Befehl, ein Gerät zuzulassen.

Die RATS-Charta behandelt Formate und Verfahren für Nachweise und Ergebnisse als Arbeitsbereich, nicht aber Formate und Protokolle für Bewertungspolitiken. Diese Trennung ermöglicht Interoperabilität, ohne vorzutäuschen, dass eine Arbeitsgruppe den Risikoappetit jeder Organisation bestimmt.

Zwei Belege für zwei Verantwortlichkeiten

Der öffentliche Beleg sollte Aufruf, Datum, genaue Revision, Profilumfang, die Grenze zu Zusatzanforderungen, Kommentare und spätere Disposition enthalten. Er darf nicht zu „RATS hat dieses Gerät genehmigt“ werden. Daneben braucht es einen lokalen Entscheidungsbeleg: Gerät und Zuweisungskontext, Nachweisquelle, akzeptierter Anker, Prüfer und Verarbeitungsregeln, Referenzwerte, Frische, Politikversion, Autorisierungsumfang, Verantwortlicher, Monitoring und Rollback.

Zu beobachten sind die dokumentierte Disposition des Aufrufs, eine erste Arbeitsgruppenversion und ausdrückliche Umfangsänderungen. Eine Aussage über Einsatz verlangt andere Unterlagen: Politik der vertrauenden Partei, Bewertungsgrundlage des Prüfers, Autorisierung und beobachtetes Betriebsergebnis. Ihre Trennung schützt das Format vor einer Autorität, die es nicht besitzt.

Quellen

  1. RATS Call for Adoption
  2. Datatracker-Eintrag
  3. draft-poirier-rats-eat-da-10
  4. RATS-Charta
  5. RFC 9334
  6. RFC 9711