Zusammenfassung

  • Der individuelle Entwurf draft-schrock-ep-authorization-evidence-chain-07 vom 28. September teilt das frühere VERIFIED in native Prüfung VERIFIED und lokale Annahme ACCEPTED. Er ist kein verabschiedeter IETF-Standard.
  • Ein nicht auflösbarer Schlüsselverweis führt zu NOT_EVALUATED, nicht zu einem nachgewiesenen Signaturfehler; ein aufgelöster Schlüssel ist für die verlangte Rolle noch nicht vertrauenswürdig.
  • Auch nach Annahme folgen Aktionsabgleich und Nachweisanforderung. SATISFIED ersetzt weder die eigene Entscheidung AUTHORIZED des Ausführenden noch einen Ergebnisbeleg.

Ein Agent legt vor einer folgenreichen Änderung ein signiertes Beweisstück vor. Zwei Betreiber prüfen genau dieselben Daten und können beide die Signatur kryptografisch nachvollziehen. Der erste hat den Aussteller und dessen Schlüsselklasse für diese Genehmigungsrolle in seiner Vertrauenskonfiguration zugelassen. Der zweite nicht. Wenn beide Protokolle nur „Signatur gültig“ melden, ist der entscheidende Unterschied unsichtbar. Wenn eine Vermittlungsstelle daraus gar „freigegeben“ macht, gibt sie eine Entscheidung aus, die weder die Signatur noch die Vermittlungsstelle für den geschützten Betreiber treffen darf.

Ian Schrocks Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence macht diese Unterscheidung in der Fassung -07 ausdrücklich. Das offizielle Archiv datiert sie auf den 28. September 2026. Es handelt sich um einen individuell eingereichten Internet-Draft mit vom Autor angegebenem Informationszweck, nicht um einen RFC, einen von einer Arbeitsgruppe angenommenen Text oder einen Bericht über eingesetzte Technik. Die vorherige Fassung -06 behandelte bereits die Zusammenstellung verschiedenartiger Identitäts-, Delegations- und Genehmigungsartefakte. Das konkrete Änderungsereignis liegt enger: Laut Änderungsliste steckte im alten Ergebnis VERIFIED sowohl die native Prüfung als auch die Vertrauensannahme der Gegenstelle. Jetzt werden VERIFIED und ACCEPTED separat ermittelt.

Für VERIFIED muss der zuständige native Prüfer die kryptografischen und strukturellen Bedingungen des jeweiligen Artefakts erfüllen. Für ACCEPTED muss dieses Resultat bereits vorliegen; danach gelten die vom Empfänger festgelegten Vertrauensdaten. Dazu gehören das Material zur Schlüsselauflösung, Einträge und Status im Schlüsselverzeichnis, zugelassene Aussteller, Schlüsselklassen, Rolle oder Adressat sowie native Richtlinie und Formatversion. Diese Eingaben kommen nicht aus einer selbstbeglaubigenden Behauptung des Agenten. Wenn ein Format seinen Prüfschlüssel nur als Referenz nennt, muss der Empfänger ihn zunächst auflösen. Gelingt das nicht, ist die Prüfung nicht bewertet (NOT_EVALUATED) und nicht etwa als fehlgeschlagen bewiesen (FAILED). Gelingt es, lassen sich die Bytes prüfen; ob dieser Schlüssel die behauptete Rolle zu diesem Zeitpunkt tragen darf, ist damit noch nicht entschieden.

Selbst das erste Urteil kann zwischen Gegenstellen auseinanderfallen, wenn ihre Materialien denselben Verweis auf verschiedene Schlüssel abbilden. Ein Prüfvermerk ohne Schlüssel- und Profilkontext ist deshalb kein ortsunabhängiger Zustand des Dokuments. Der Entwurf untersagt, einen vom Präsentierenden mitgelieferten Wahrheitswert, einen Vertrauensanker oder eine vermeintlich schon normalisierte Tatsache als Ersatz für die native Prüfung und eigene Annahme zu verwenden.

Vorherige Ergebnisse dürfen innerhalb derselben geschützten Vertrauensgrenze übernommen werden, wenn sie unveränderbar an den genauen Nachweis-Digest, das Prüferprofil, den Vertrauens-Snapshot und den Prüfzeitpunkt gebunden sind. Eine von außen serialisiert gelieferte „Prüfung“ ist dagegen selbst ein zu prüfendes Artefakt.

Danach verläuft eine andere Grenze. Nur zugleich geprüfte und akzeptierte Komponenten dürfen mit der vom Ausführenden festgelegten Handlung verglichen werden. Ein echter Nachweis eines akzeptierten Ausstellers für eine andere Handlung scheitert an MATCH, nicht an der Signatur oder der Vertrauensregel. Aktualität, authentifizierter Status, Rollenbedingungen und belegte Verknüpfungen zwischen Komponenten entscheiden anschließend, ob die vom Empfänger benannte Nachweisanforderung SATISFIED ist. Das belegt ausschließlich die Eignung der vorgelegten Evidenz zur Prüfzeit. Die geschützte Anwendung muss AUTHORIZED eigenständig entscheiden und Ausführung sowie Wirkung gesondert festhalten.

Revision -07 sieht einen wiederholbaren Auswertungsdatensatz vor: Fassung des Algorithmus, Digests von Kette, erwarteter Aktion und Anforderung, Zeitpunkt, Digest des Vertrauens-Snapshots sowie für jede Komponente native_verification und acceptance als eigene Felder. Begründungen sollen einen kryptografischen Fehler, eine nicht mögliche Prüfung, eine abgelehnte Vertrauensstellung und einen falschen Aktionsbezug unterscheiden. So kann eine spätere Untersuchung herausfinden, ob sich Beweisbytes, Schlüsselauflösung, lokale Politik oder die verlangte Handlung geändert haben. Der Datensatz ist jedoch weder ein vom Agenten vorgelegter Freifahrtschein noch eine weltweite Vertrauensliste. Der Entwurf fordert keine IANA-Aktion.

Quellen