Zusammenfassung

  • Bei Anwendung, Betriebssystem, Firmware und Hardware aus verschiedenen Häusern reicht eine gemeinsame Liste vertrauenswürdiger Endorser nicht aus.
  • Eine gültige Signatur des OS-Anbieters kann echt und dennoch unzuständig sein, wenn sie Aussagen über die Hardware trägt.
  • Revision 11 lässt die Zuordnung in Appraisal Policy, Evidence oder beiden Quellen zu; ein prüfbares Ergebnis muss die tatsächlich verwendete Zuordnung bewahren.

Vier Hersteller können an einem Gerät beteiligt sein und alle vier können korrekt signieren. Das ist noch keine Antwort auf die Frage, wer welche Komponente beschreiben darf. Wird aus „vertrauenswürdiger Unterzeichner“ ein geräteweites Recht, funktioniert die Kryptografie und die Zuständigkeitsordnung versagt.

RATS Endorsements 11 modelliert Anwendung, OS, Firmware und Hardware als getrennte Target Environments. Lieferanten können zusätzliche Claims zu ihrer jeweiligen Ebene beisteuern. Der Verifier braucht aber mehr als eine Menge vertrauenswürdiger Endorser: Er muss erkennen, welcher Endorser über welches Target Environment aussagen darf.

Das Beispiel des Entwurfs ist eindeutig. Ein OS Endorser kann für das Betriebssystem zugelassen sein, nicht aber für die Hardware. Weder böse Absicht noch ein kompromittierter Schlüssel sind erforderlich. Eine zu weit gefasste Policy genügt, um authentische Herkunft mit sachlicher Zuständigkeit zu verwechseln.

Die Bindung hat keinen vorgeschriebenen Einzelspeicherort. Sie kann in der Appraisal Policy for Evidence stehen. Evidence kann einen zulässigen Endorser für eine Ebene benennen. Beides kann kombiniert werden. Deshalb enthält die signierte Endorsement allein noch nicht die vollständige Begründung ihrer Zulassung.

Zwei Verifier können identische Bytes empfangen und unterschiedlich entscheiden, weil Ebenenmodell, Policy-Version oder Delegation in der Evidence abweichen. Ohne die wirksame Bindung kennt eine spätere Prüfung den Absender, nicht aber dessen damaliges Mandat.

RFC 9334 hält die Rollen auseinander: Der Endorser liefert Claims, der Verifier Owner kontrolliert die Bewertung von Evidence, der Relying Party Owner entscheidet über die Nutzung des Attestation Result. Herkunft, Urteil und Wirkung sind getrennte Kontrollflächen.

Auch eine bedingte Endorsement ersetzt die Zuständigkeit nicht. Ihre Matching-Regel kann entscheiden, ob ein Claim anwendbar ist. Sie entscheidet nicht allein über Vertrauenswürdigkeit und ermächtigt den Endorser nicht für andere Ebenen. Ein perfekter Match kann daher einen Claim aus der falschen Autoritätsdomäne aufnehmen.

Die richtige Schlüsselzuordnung ist ebenfalls kein Gesamtmandat. Ein UEID nach RFC 9711 kann helfen, Verifikationsmaterial zu finden. Revision 11 überlässt die Granularität – Instanz, Klasse oder andere Claims – dem jeweiligen Protokoll. Ein gefundener Schlüssel beantwortet die Ebenenfrage nicht.

Ein belastbarer Nachweis verbindet frische Evidence; Identität, Vertrauenskette und Status des Endorsers; Kennung und Ebenenkarte des Target Environment; die Regel für Endorser, Ebene und Claim-Klasse; die ausgewählte Endorsement-Version; Verifier- und Policy-Identität; sowie Entscheidung und beobachtete Wirkung der Relying Party.

Die Datatracker-Historie führt Revision 11 in der IESG Evaluation und auf der Agenda für den 8. Oktober 2026. Der Vergleich 09–11 ist prüfbar. Der Text der Revision 11 bleibt dennoch ein Internet-Draft, kein RFC.

CoRIM 11 bietet ein konkretes Datenmodell. Seine Verwendung belegt nicht automatisch, dass eine Implementierung die Endorser-Reichweite korrekt speichert und durchsetzt.

Quellen