Zusammenfassung

  • RFC 9999 gibt RATS Evidence, Attestation Results, Endorsements, Reference Values und Appraisal Policies eine selbstbeschreibende Hülle für CBOR, JSON, JWT, CWT, X.509, HTTP, MIME und CoAP.
  • Record, Tag und Collection CMW ermöglichen Erkennung, Weiterleitung und Zusammensetzung, liefern allein aber weder Authentizität noch Integrität, Vertraulichkeit, Frische, Bewertung oder Berechtigung.
  • Soll eine Collection ein zusammengesetztes oder geschichtetes Gerät belegen, müssen ihre Evidence-Elemente kryptografisch miteinander verbunden sein; einzelne gültige Signaturen beweisen keine gemeinsame Maschine und keinen gemeinsamen Zeitpunkt.

Nach einem Kartentausch meldet sich ein Router wieder im Produktionsnetz. Seine Attestierung enthält einen Eintrag für das Chassis, einen für die Steuerkarte und mehrere für Linecards. Jeder Typ ist bekannt. Jede innere Signatur ist gültig. Der automatische Prüflauf zeigt keine rote Zeile.

Eine der Linecard-Aussagen könnte dennoch von einer gesunden Ersatzkarte stammen, die nie im Router steckte. Alle Signaturen wären echt. Nur die behauptete Zusammensetzung wäre falsch.

Genau hier liegt die operative Bedeutung von RFC 9999. Der IETF-Standard vom Juli 2026 definiert den Remote ATtestation procedureS Conceptual Message Wrapper (CMW). RATS kennt mehrere konzeptionelle Nachrichten, Claims-Formate, Serialisierungen und Transportwege. Eine gemeinsame, explizit typisierte Hülle verhindert, dass jedes Aufnahmeprotokoll bei einer neuen Attestierungstechnik neu gebaut werden muss.

CMW standardisiert die Übergabe. Es standardisiert nicht das Vertrauen.

Die Architektur trennt Aussage, Bewertung und Handlung

RFC 9334 weist die Aufgaben verschiedenen Rollen zu. Der Attester erzeugt Evidence. Der Verifier bewertet sie mit Endorsements, Reference Values und einer Appraisal Policy und erstellt Attestation Results. Erst die Relying Party wendet ihre eigene Richtlinie an und entscheidet über Netzzugang, Schlüsselherausgabe oder einen anderen fachlichen Effekt.

CMW lässt diese Trennung bestehen. Ein Record enthält type, einen undurchsichtigen value und bei Bedarf ind. Der Indikator kann Reference Values, Endorsements, Evidence, Attestation Results oder Appraisal Policy markieren. Ein Tag CMW leitet einen CBOR-Tag nach RFC 9277 aus einem CoAP Content-Format ab. Eine Collection gruppiert beschriftete CMW-Elemente und kann weitere Collections enthalten.

Die IANA RATS Parameters koordinieren die Indikatorwerte. RFC 9711 definiert das Entity Attestation Token, RFC 9782 die EAT-Medientypen. Ein Kernsystem kann dadurch den passenden Handler wählen, ohne den Inhalt zu erraten.

Die Wahl eines Handlers ist noch keine Glaubwürdigkeitsentscheidung. Ein Medientyp beschreibt die Grammatik. Das Bit „Evidence“ beschreibt die beabsichtigte Funktion. Eine IANA-Zuweisung verhindert Namenskollisionen. Keiner dieser Schritte beweist, dass der Absender zuständig, der Claim wahr, das Profil unterstützt oder die Richtlinie aktuell ist.

Sicherheit braucht einen benannten Geltungsbereich

RFC 9999 bezeichnet CMW als Kapselung und ausdrücklich nicht als Sicherheitsformat. Record, Tag und Collection bieten für sich keine Authentizität, Integrität oder Vertraulichkeit.

Schutz kann bereits im inneren Objekt liegen. Ein CBOR-CMW lässt sich mit COSE nach RFC 9052 schützen, ein JSON-CMW mit JWS nach RFC 7515. Ein sicherer Kanal schützt die Übertragung. Ein Challenge-Response-Ablauf kann Wiederholung begrenzen.

Diese Maßnahmen haben verschiedene Reichweiten. Eine authentisierte Verbindung sagt wenig über ein später gespeichertes und weitergereichtes Objekt. Drei Einzelsignaturen schützen drei Bytefolgen, nicht deren Zusammengehörigkeit. Eine Signatur über die gesamte Collection fixiert die Zusammenstellung – aber nur, wenn der Schlüssel diese Zusammensetzung behaupten darf und das signierte Profil ihre Bedeutung festlegt.

RFC 9781 liefert den schärfsten Test. Ein UCCS ist ein ungeschützter CWT Claims Set. CMW kann ihn erkennbar und transportierbar machen; geschützt wird er dadurch nicht. RFC 9999 zeigt, wie außen eine Signatur ergänzt werden kann. Die Sicherheitswirkung entsteht aus diesem zusätzlichen, überprüfbaren Schritt.

Eine belastbare Aufzeichnung nennt daher die geschützten Bytes, die Ebene, den Schlüssel und seinen Zweck, den Vertrauenspfad sowie die Wirkung von Extraktion, Speicherung und Weiterleitung. „Signiert“ ist ohne diese Angaben zu ungenau.

Eine gesunde Komponente kann die kompromittierte ersetzen

Reale Systeme sind zusammengesetzt. CPU, SmartNIC und GPU eines Servers können getrennte Attesting Environments haben. Ein Router besteht aus Chassis und Karten. In einer geschichteten Bootkette misst eine Stufe die nächste.

Collection CMW kann die heterogenen Evidence-Formate tragen. Wenn die Collection jedoch ein einzelnes zusammengesetztes oder geschichtetes Gerät darstellen soll, verlangt RFC 9999 eine kryptografische Bindung aller Evidence-Nachrichten. Ohne Schutz der ganzen Collection oder belastbare Beziehungen zwischen Mitgliedern kann ein Angreifer den Beleg einer kompromittierten Komponente durch den einer gesunden Komponente ersetzen.

Die Spezifikation lässt mehrere Bindungsarten zu: Signatur über die Collection, gemeinsame Identifikatoren oder Nonces, gegenseitige Signaturen oder Hashes sowie eine Konstruktion des Hostprotokolls. Maßgeblich ist nicht der Name des Verfahrens, sondern ob der geprüfte Bereich jedes Mitglied mit dem behaupteten Subjekt, der Topologie-Epoche und der Transaktion verbindet.

Nicht jede Collection behauptet ein Gerät. Sie kann Endorsements, Reference Values, Ergebnisse oder Nachrichten mehrerer Geräte bündeln. Die Reihenfolge ihrer Einträge ist bedeutungslos; Bezeichnungen sind nur innerhalb der Collection eindeutig. gpu oder slot-3 wird erst durch Collection Type beziehungsweise Assembly Profile, Anlageninventar, Gerätekennung und Topologiegeneration präzise.

Die Hülle sagt, wo etwas liegt. Das Profil sagt, was diese Position bedeutet. Das laufende Inventar sagt, welche physische Komponente sie jetzt ausfüllt.

Rekursion ist auch ein Ressourcenvertrag

Collections dürfen weitere Collections enthalten. Das bildet Schichten gut ab, vergrößert aber Parse-Tiefe, Elementzahl, Datenmenge, Base64-Arbeit, Signaturprüfungen und externe Abfragen.

RFC 9999 erlaubt Tiefenbegrenzungen und lässt ihre genaue Aushandlung außerhalb des Standards. Betreiber müssen Gesamtgröße, Mitgliederzahl, Tiefe, Handler-Zeit, kryptografische Operationen und externe Fan-outs festlegen. Ein erfolgreich ausgewählter Decoder erhält dadurch kein unbegrenztes Budget.

Unbekannte Typen brauchen ebenfalls eine eindeutige Behandlung. Ein Archiv kann ein undurchsichtiges Objekt bewahren. Ein Autorisierungsdienst darf ein unbekanntes Pflichtmitglied nicht überspringen und anschließend behaupten, das Gerät vollständig bewertet zu haben. Ungültig, nicht unterstützt, fehlend und laut Profil optional sind verschiedene Zustände.

Zu jedem akzeptierten Typ gehören Handler-Version, erlaubte Profile, Algorithmuspolitik, Ressourcenlimits und Fehlersemantik. Nur so bleibt Erweiterbarkeit kontrollierte Kompatibilität.

Frische steht nicht auf der Verpackung

Nach Firmware-Update, Kartenwechsel oder Änderung der Referenzwerte kann eine alte Evidence weiterhin eine gültige Signatur tragen und den heutigen Zustand verfehlen. RFC 9334 behandelt Frische getrennt über synchronisierte Zeit, Nonces oder Epoch IDs.

CMW kann die beteiligten Nachrichten transportieren, beweist jedoch nicht, dass alle Mitglieder dieselbe Challenge beantworten. CPU mit Nonce A, SmartNIC mit Nonce B und GPU nur mit Zeitstempel bilden nicht automatisch eine kohärente Transaktion. Das entscheiden Assembly Profile und Verifier-Richtlinie.

Für eine spätere Reproduktion müssen Challenge, Aussteller, Zeitfenster, Uhrannahmen, Epoche und Mitgliedsabdeckung erhalten bleiben. Eine gültige Signatur ist kein Frischeurteil.

Danach bleibt die Relying Party zuständig. Ein unter einer Firmware-Richtlinie vertrauenswürdiges Gerät ist nicht automatisch berechtigt, Kundendaten zu lesen oder Releases zu signieren. Ein portables Attestation Result darf nicht ohne seinen Verifier, seine Policy-Version, seinen Adressaten und seine Gültigkeit weitergereicht werden.

Ein vollständiger Abschluss weist erwartete Mitglieder, Parsing, Schutz, Bindung, Frische, Bewertung, Ergebnisübergabe, fachliche Entscheidung und beobachtete Wirkung nach.

X.509 kann aus privater Evidence ein dauerhaftes Publikumsgut machen

RFC 9999 erlaubt CMW in X.509-Zertifikaten, CSRs und CRLs. Der bestehende PKIX-Verteilweg ist praktisch – und kann vertrauliche Hardwaredaten weit streuen.

Ein Antragsteller mag einer Certification Authority HSM-Modell und Patchstand offenlegen, um ein Codesignaturzertifikat zu erhalten, ohne diese Details allen Zertifikatsempfängern zeigen zu wollen. RFC 5280 regelt Zertifikate und Erweiterungen allgemein, schafft aber keine Offenlegungserlaubnis. RFC 3647 liefert den Rahmen für Certificate Policy und Certification Practice Statement. RFC 9999 empfiehlt, dort die Bedingungen für die Aufnahme fremder Evidence festzuhalten.

Claim-Minimierung, Zielgruppe, Aufbewahrung, Profil und Publikationsrecht müssen vor Ausstellung geklärt sein. Ein Widerruf holt verbreitete Informationen nicht zurück.

Der ausgeführte Pfad entscheidet

Heng Lus Prinzip der Running-Code-Priorität richtet den Blick auf Parser, Handler, exakte Bytes, Schlüssel, Bindung, Frische, Richtlinienversion, Entscheidung und Wirkung. Ein formal gültiges CMW ist eine Station dieses Pfades.

Sein Ansatz einer minimalen Anfangsspezifikation mit lokalisierten Folgeentscheidungen begrenzt gemeinsame Macht sinnvoll: Hülle und Register sichern Interoperabilität; Gesundheitskriterien, Berechtigungen und Haftung bleiben bei benannten Betreibern.

Die Trennung der Realitätsebenen hält Syntax, Kryptografie, semantische Bewertung und reale Wirkung auseinander. Gute Automatisierung macht diese vier Urteile sichtbar, statt sie in einem grünen Status zu vermischen.