Zusammenfassung

  • Revision 13 lässt einen Verifier nach Start, Update, Steuerungs-Failover oder Hardwarewechsel neue Evidence empfangen, statt auf die nächste Abfrage zu warten.
  • Replay, Nonce, Epoch, signierte TPM-Uhr und Heartbeat verbessern Kontinuität und Frische, beweisen allein aber keine lückenlose Geschichte.
  • Erzeugung, Transport, Sequenz/Replay, Frische, Bewertung, Autorisierung des Relying Party und Ergebnis benötigen je einen eigenen Nachweis.

Ein Gerät, das beim Start bestand, kann Stunden später ein anderes System sein. Es bootet neu, installiert Software, wechselt die Steuereinheit oder erhält ein Forwarding-Modul. Polling sieht das erst bei der nächsten Frage. draft-ietf-rats-network-device-subscription-13 schlägt deshalb ein Abonnement des YANG Event Stream <attestation> nach RFC 8639 vor.

Die Anfrage enthält Nonce, ausgewählte PCRs und optional einen Filter. Das Gerät kann PCR-Extend-Ereignisse seit dem Boot wiedergeben, den Replay-Abschluss markieren und anschließend ein an die Nonce gebundenes TPM Quote liefern. Spätere Extend-Benachrichtigungen gehen dem jeweiligen Quote voraus; es soll innerhalb weniger, spätestens zehn Sekunden entstehen. Ein Heartbeat macht auch eine Zeit ohne Quote beobachtbar.

Das ist mehr als Push statt Pull. Es schafft eine praktikable Belegspur. Gerade deren gleichmäßiger Takt kann jedoch sieben Fragen überdecken.

Erstens: Wurde das relevante Ereignis überhaupt gemessen? Ein Quote bindet ausgewählte PCRs, beweist aber nicht, dass außerhalb dieses Umfangs nichts Messwürdiges geschah. Filter verkleinern den Strom absichtlich. Eine Signatur schützt den Umfang, erklärt ihn nicht für vollständig.

Zweitens: Kam die Nachricht über das erwartete Abonnement beim richtigen Gerät und in der richtigen Sitzung an? Kanalschutz belegt Empfang, nicht das, was nie in den Kanal gelangte.

Drittens: Sind Sequenz und Replay erklärbar? Der Entwurf enthält echte Kontrollen: bootbegrenzte Rekonstruktion, replay-completed, Reihenfolge von Extend und Quote, Reset/Restart-Behandlung und Heartbeat. Der Betrieb muss Abonnement-ID, Filter, Reihenfolge, Wiederverbindungen und jede Lücke prüfen. Gültige Belege vor und nach einer Lücke füllen sie nicht.

Viertens: Ist die Evidence frisch genug? Eine Nonce erzeugt eine grobe Challenge-Epoche; zentrale Epoch-IDs oder ein separates RFC-9684-Quote können sie erneuern. Signierte TPM-2.0-Werte für clock, reset und restart unterstützen Drift- und Lebenszyklusprüfungen. RFC 9334 lässt dennoch ein Rennen bestehen: Frische engt den Entstehungszeitpunkt ein, sie macht eine frühere Messung nicht dauerhaft aktuell. Wichtige Regeln, etwa zur Nonce-Wiederverwendung, bleiben außerhalb des Protokolls.

Fünftens: Besteht die Evidence die richtige Bewertung? Der Verifier braucht Reference Values, Endorsements und Bewertungsregeln. RFC 9683 nennt Konflikte, Lücken und Mehrdeutigkeit in Referenzwerten. Eine gültige Signatur sagt, wer Claims geschützt hat; sie bestätigt nicht die Eignung der Baseline.

Sechstens: Wer darf entscheiden? Im RATS-Modell erzeugt der Verifier ein Attestation Result; der Relying Party wendet darauf seine eigene Regel für eine konkrete Transaktion an. Ein Inventar kann denselben Befund akzeptieren, den ein Netzzugang ablehnt. Kryptografie überträgt keine Geschäftsautorität.

Siebtens: Trat die Wirkung ein? Eine korrekte Ablehnung beweist nicht, dass der Enforcement Point handelte, Verkehr verschoben wurde oder das Risiko verschwand. Der handelnde Betrieb muss den letzten Beleg liefern.

Am 9. September 2026 war Revision 13 ein aktiver Internet-Draft. Der Datatracker zeigte AD Followup nach Einreichung an die IESG und Proposed Standard als Ziel. Das ist weder RFC-Freigabe noch Einsatznachweis. Seine Stärke liegt darin, Fakten schneller zu bewegen, nicht Sehen, Bewerten und Handeln zu verschmelzen.

Quellen