Summary

  • Ein individueller Internet-Draft beschreibt einen RATS-fähigen Identity Document Service, der aus einem akzeptierten Attestation Result einen vertrauten Schlüssel, Token oder Berechtigungsnachweis für RATS-unkundige Dienste macht.
  • Nach der Ausstellung entsteht eine Lebenszykluslücke: Der Nachweis kann nach seinen eigenen Regeln weiterhin gültig sein, obwohl Evidence, Bewertungsrichtlinie, Standort oder eine tragende Aussage nicht mehr aktuell sind.
  • Daniel Kade schlägt einen Attestierungs-Nachweis-Lease vor, der Laufzeit und nativen Widerruf an Evidence-Epochen, Richtlinienversionen, Aussageklassen, Workload-Schlüssel und Änderungsereignisse bindet. Das ist ein redaktioneller Governance-Vorschlag, kein IETF-Konsens.

Ein Ortswechsel ohne Sicherheitsvorfall

Die Schwachstelle benötigt weder Angreifer noch Schlüsseldiebstahl. Ein Workload liefert Evidence, ein Verifier bewertet sie und ein Identity Document Service (IDS) akzeptiert das Ergebnis. Die Verbindung kann geschützt, der private Schlüssel im Workload und jede Signatur korrekt sein. Danach verschiebt ein Orchestrator den Workload im normalen Betrieb.

draft-bdnr-rats-trustworthy-credentials-02 benennt die Konsequenz ungewöhnlich konkret. Bei einer Live-Migration von Deutschland nach Frankreich kann Country=Germany falsch werden, während Region=Europe weiterhin stimmt. Für eine europaweit gültige Fähigkeit muss sich daraus nichts ergeben. Für eine Berechtigung, die Verarbeitung in Deutschland voraussetzt, ist dieselbe Migration wesentlich.

Der Altdienst sieht diese Aufteilung nicht. Er prüft lediglich das ihm bekannte Zertifikat oder Token. Gerade dies war das Integrationsziel. Governance beginnt daher nicht mit dem Vorwurf, der Dienst hätte RATS verstehen müssen, sondern mit der Zuständigkeit des Vermittlers: Wer die ursprüngliche Entscheidung in ein gewöhnliches Objekt übersetzt, muss auch spätere Änderungen in dessen Lebenszyklus übersetzen.

Ein kleiner Änderungsradius ist vernünftig

Viele bestehende Gegenstellen lassen sich nicht ohne Weiteres für Evidence, Attestation Results und Bewertungsrichtlinien umbauen. Drittanbieter-Binärdateien, ungeeignete Sprachen, regulatorische Prüfungen oder getrennte organisatorische Verantwortung können eine Änderung teuer oder unmöglich machen. Müsste jede Anwendung zuerst RATS-fähig werden, würde die unflexibelste Komponente die Einführung bestimmen.

Der Draft setzt deshalb einen Credential Broker, Key Broker oder eine Credential Authority dazwischen. Diese Instanz ist zugleich RATS Relying Party und IDS. Der Workload weist seinen Zustand ihr gegenüber nach; bei einem akzeptablen Ergebnis erhält er ein Identity Document, das bestehende Partner bereits verarbeiten. Gemeint sind Schlüssel, Tokens oder kurz- wie langlebige Berechtigungsnachweise. Genannt werden Schlüsselvermittlung, vorab bereitgestellte Proof-of-Possession-Nachweise sowie neu ausgestellte PoP-Nachweise oder kurzlebige Bearer Tokens.

Der geringe „blast radius“ ist ein echter Vorteil. Vorhandene TLS-, Zertifikats- und Tokenpfade bleiben nutzbar. Private Schlüssel können beim Workload bleiben. Sensible Evidence muss nicht an jede Anwendung verteilt werden.

Diese Vereinfachung ist jedoch eine Verlagerung. Der IDS nimmt den Altdiensten die Attestierung ab. Damit übernimmt er die Gegenpflicht, eine spätere Vertrauensänderung in Ablauf, Status, Einschränkung oder Widerruf zu überführen, die diese Dienste tatsächlich durchsetzen können.

Drei Uhren laufen nebeneinander

RFC 9334 trennt die Appraisal Policy for Evidence des Verifiers von der Appraisal Policy for Attestation Results der Relying Party. Die erste Richtlinie deutet Evidence und erzeugt ein Ergebnis. Die zweite entscheidet, ob dieses Ergebnis für einen konkreten Zweck genügt. Ein authentisches Attestation Result ist noch keine Autorisierung.

Evidence benötigt eine angemessene Frische, und das Resultat besitzt einen Gültigkeitsrahmen. Der RFC weist zugleich auf ein unvermeidbares Rennen hin: Zustand oder Richtlinie können sich unmittelbar nach der Ergebnisbildung ändern. Ergebnisse dürfen nicht über ihre Gültigkeit hinaus verwendet werden; innerhalb des Fensters steht die Umgebung dennoch nicht still.

Mit dem ausgestellten Berechtigungsnachweis kommt eine dritte Uhr hinzu. Ein Zertifikat hat notBefore und notAfter, ein Token eine Ablaufzeit, ein Statusdienst einen Aktualisierungstakt. Nur diese Uhr kennt der RATS-unkundige Dienst. Gilt der Nachweis acht Stunden, obwohl eine wesentliche Aussage nur fünf Minuten frisch ist, macht die Umwandlung aus fünf Minuten keine acht Stunden. Sie verbirgt lediglich die Differenz.

Kurze Laufzeiten verkleinern, aber definieren die Lücke nicht. Auch ein Zehn-Minuten-Token kann eine Fünf-Minuten-Aussage überleben. Kontinuierliche Attestierung erkennt Änderungen schneller, benötigt aber weiterhin eine Regel für bereits umlaufende Nachweise. Widerruf wirkt nur, wenn Abhängigkeiten auffindbar sind und alle Gegenstellen den Statuskanal tatsächlich verwenden.

Eine korrekte Signatur bewahrt mitunter alte Bedeutung

JWS nach RFC 7515 schützt Integrität und weist eine Signatur einem Schlüssel zu. Zertifikatspfadprüfung nach RFC 5280 behandelt Aussteller, Namen, Einschränkungen, Zeit und konfigurierte Widerrufsinformationen. Proof of Possession zeigt die Kontrolle über einen privaten Schlüssel. Keine dieser Prüfungen wiederholt die Evidence-Bewertung, auf der die Ausstellung beruhte.

Der Altdienst kann deshalb technisch vollkommen richtig entscheiden und dennoch überholte Autorität fortführen. Ein nicht abgelaufener, nicht widerrufener Nachweis soll aus seiner Sicht akzeptiert werden. Es wäre widersprüchlich, ihn absichtlich von RATS freizuhalten und ihm anschließend die fehlende Beobachtung einer Migration anzulasten.

Der IDS bleibt nach der Ausstellung Teil der Vertrauenskette. Er verbindet eine dynamische Seite aus Evidence, Reference Values, Endorsements, Verifiern und Richtlinien mit einer Seite aus Gültigkeit, Schlüsselwechsel, Introspection und Widerruf. Die Verbindung muss als handlungsfähiger Betriebszustand fortbestehen. Ein Archivvermerk, der erst nach einem Vorfall gelesen wird, beendet keine Berechtigung.

Aussagen altern nicht gemeinsam

Land und Region zeigen, warum ein Attestation Result kein unteilbares grünes Licht sein darf. Der Betreiber kann wechseln, während die gemessene Software gleich bleibt. Eine Konfiguration kann abweichen, während Secure Boot weiter gilt. Eine neue Richtlinie kann einen Algorithmus ausschließen, ohne jede Identitätseigenschaft des Workloads zu verwerfen.

Jeder Berechtigungsumfang sollte mit der kleinsten tragenden Aussage verknüpft sein. Eine europäische Fähigkeit benötigt möglicherweise kein unverändertes Land; eine deutsche Datenverarbeitungsberechtigung schon. Stecken beide in einem groben Nachweis, wird jede Korrektur unverhältnismäßig: Fortführung lässt zu viel Macht bestehen, vollständiger Widerruf unterbricht auch weiterhin begründete Rechte.

Eine Abhängigkeitskarte hält zwei Fehlanreize auseinander. Wenn jede Änderung einen Totalausfall erzeugt, lernen Teams, Attestierungssignale zu unterdrücken. Wenn bis zum Ablauf nie reagiert wird, konserviert die Signatur überholte Voraussetzungen. Prüffähig sein muss, welche Aussage welche Fähigkeit trug und warum ein Ereignis zu Ersatz, Einschränkung, Sperre oder begründetem Nichtstun führte.

Der technische Antragsteller ist nicht der attestierte Workload

Der Draft berücksichtigt einen EST-Client, der im Hypervisor oder Orchestrator außerhalb der Trusted Computing Base des Workloads läuft. Dieser Client darf sich für den Kanal authentisieren. Seine optionale Identität darf aber nicht festlegen, für welchen Workload ein Nachweis zurückgegeben wird. Evidence und Attestierung stellen die Bindung her; der private Schlüssel sollte beim Workload verbleiben.

Diese Trennung gilt auch nach der Ausstellung. Ein Migrations- oder Neubewertungsereignis muss über die attestierte Identität und den Workload-Schlüssel zum richtigen Nachweis führen, nicht bloß über die damalige Orchestrator-Sitzung. Andernfalls können sämtliche Transportverbindungen authentisch sein, während das falsche Objekt erneuert oder widerrufen wird.

Der LAMPS-Draft zur CSR-Attestierung macht eine verwandte Pflicht sichtbar. Nutzt eine CA oder RA Attestierung, ist sie für die Bindung mehrerer Aussagen untereinander und an den öffentlichen Schlüssel im Antrag verantwortlich. Anforderungen sollen in der Certification Practice Statement stehen. Das stützt die Notwendigkeit klarer Bindungsverantwortung, beweist aber keinen fertigen Nachausstellungsmechanismus im Trustworthy-Credentials-Draft.

Auch WIMSE trennt den Workload-Berechtigungsnachweis als Identitätsdarstellung vom Proof of Possession. Schlüsselkontrolle beantwortet, wer präsentiert. Sie sagt nicht, ob Standort, Messwert oder Richtlinie aus dem Ausstellungszeitpunkt noch gelten.

Der Attestierungs-Nachweis-Lease

Daniel Kade schlägt einen vom IDS geführten Lease zwischen Attestierung und Nachweis vor. Er ist kein neues öffentliches Format und verlangt vom Altdienst keine RATS-Implementierung. Er hält mit minimalem Zustand zwei Gültigkeitsregime verbunden.

Zuerst erfasst er Kennung und Typ des Nachweises, Workload-Identität, den vom Workload gehaltenen öffentlichen Schlüssel und die PoP-Bindung. Hinzu kommen Evidence-Epoche und Frischegrenze, Verifier und Version seiner Appraisal Policy for Evidence sowie die IDS-Richtlinienversion, die das Attestation Result akzeptiert hat. Ändert sich Verifier oder Richtlinie, lassen sich betroffene Nachweise gezielt finden.

Danach verbindet eine Karte Berechtigungen mit Aussageklassen: Land, Region, gemessene Software, Schlüsselschutz oder Betriebsumgebung. Die Abhängigkeit kann zwingend, informativ oder nur laufzeitverkürzend sein. Rohe Evidence muss nicht vollständig kopiert werden; eine geschützte Referenz, Epoche und ein Ergebnisdigest können die Verbindung unter Datenschutz- und Aufbewahrungsgrenzen bewahren.

Der Lease setzt außerdem einen Horizont. Ohne gleichwertige kontinuierliche Beobachtung und verlässlichen Statuspfad soll der Nachweis die kürzeste wesentliche Vertrauensabhängigkeit nicht unerklärt überdauern. Das ist keine pauschale Forderung nach Minimaldauer. Eine längere Dauer braucht lediglich einen nachprüfbaren Mechanismus, der den Abstand schließt.

Schließlich ordnet der Lease Ereignissen Aktionen zu. Migration, Schlüsselwechsel, neue Richtlinie, Rücknahme eines Referenzwerts, Softwareänderung, fehlgeschlagene Remediation oder ein geändertes Endorsement können eine neue Attestierung auslösen. Darauf folgen Ersatz, Umfangsreduktion, Sperre, Widerruf oder eine begründete Nichtaktion, wenn die Änderung unerheblich ist. Der IDS muss nicht nur die Entscheidung, sondern auch die Übermittlung des nativen Signals nachweisen.

Widerruf endet nicht am Datenbankeintrag

Ein Feld mit dem Wert „revoked“ beweist noch keine beendete Nutzung. Manche Dienste cachen Status, andere prüfen nur beim Verbindungsaufbau, wieder andere verlassen sich auf das natürliche Ende kurzer Tokens. Bereits bestehende Sitzungen können weiterlaufen. Der Lease muss den wirklichen Durchsetzungspfad und dessen maximale Verzögerung benennen.

Eine Prüfung verfolgt daher den ganzen Ablauf: Quelle des Migrationsereignisses, Zeit bis zur Neubewertung, verwendeter Zertifikats- oder Tokenstatus, Behandlung bestehender Sitzungen und nicht erreichbarer Dienste sowie Reihenfolge von Ersatz und Ungültigkeit. Der erfolgreiche Widerrufsaufruf ist der Anfang des Vorgangs, nicht sein Abschluss.

Auch Ausnahmen sind zeitliche Zustände. Bei Ausfall des Verifiers können dreißig Minuten eingeschränkter Weiterbetrieb vertretbar sein. Genehmiger, Umfang, Ablauf, kompensierende Beobachtung und Endentscheidung müssen feststehen. Wiederholte Ausnahmeverlängerung darf nicht zur dauerhaften zweiten Vertrauenskette werden.

Was die Dokumente offenlassen

Der Trustworthy-Credentials-Draft kennzeichnet unerledigte Arbeit. Für den Bearer-Token-Pfad wird ein weiteres Protokoll oder eine Erweiterung benötigt; /serverkeygen braucht nähere Ausarbeitung. Geschützte Kanäle und sichere Schlüsselhaltung werden verlangt, aber ein vollständiges Governance-Modell nach der Ausstellung wird nicht festgelegt.

Zum Stichtag ist das Dokument ein individueller Internet-Draft ohne formalen IETF-Status. Auch die LAMPS- und WIMSE-Texte sind in Arbeit. Die Quellen belegen keine konkrete Einführung, übliche Laufzeit, Migrationstörung, Rechtsverletzung, Leistungszahl oder Verbreitung. Das Eingangsszenario prüft einen vom Draft selbst genannten Zustandswechsel und wirft keinem Anbieter Fehlverhalten vor. Der Lease ist redaktionelle Orientierung.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
  5. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
  6. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
  7. https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
  8. https://www.rfc-editor.org/rfc/rfc9334.html
  9. https://www.rfc-editor.org/rfc/rfc9711.html
  10. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
  11. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
  12. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
  13. https://www.rfc-editor.org/rfc/rfc7030.html
  14. https://www.rfc-editor.org/rfc/rfc5280.html
  15. https://www.rfc-editor.org/rfc/rfc7515.html