Zusammenfassung

  • Revision 03 band den Nachfolger an den Hash eines vorab erzeugbaren Kontexts; ein Orchestrator konnte die Unterschriften rückwärts einsammeln.
  • Revision 04 hasht den vollständigen Vorgänger-Signoff einschließlich tatsächlicher Signatur und weist alte, gemischte oder ungepinnte starke Ketten zurück.
  • Der neue Link belegt eine Abhängigkeit fertiger Beweisobjekte. Er belegt weder vertrauenswürdige Zeit noch Lesen, Verstehen, endgültige Autorisierung, Ausführung oder Wirkung.

Eine Reihe gültiger Signaturen kann eine falsche Reihenfolge erzählen. Genau diesen Fehler benennt draft-schrock-ep-quorum-04, am 6. September als individueller Informational-Entwurf eingereicht.

In Revision 03 unterschrieb jeder spätere Genehmiger einen Kontext mit prev_context_hash, dem Hash des vorangegangenen Kontexts. Daraus leitete der Text ab, die Signaturen selbst bewiesen das Nacheinander der Freigaben.

Doch ein Kontext ist noch kein Signaturnachweis. Der Orchestrator konnte alle Kontexte vorab bilden, zuerst die letzte Person unterschreiben lassen, rückwärts fortfahren und das Ergebnis anschließend in Listenreihenfolge zeigen. Jede Prüfung konnte grün sein. Dass der Vorgänger bereits unterschrieben hatte, folgte daraus nicht.

Der fertige Vorgängernachweis wird zur Eingabe

EP-QUORUM-SIGNOFF-CHAIN-v1 hasht jetzt das vollständige JSON-Objekt des Vorgänger-Signoffs samt tatsächlicher Signatur. Vor SHA-256 stehen eine Domänentrennung, ein Null-Oktett und die UTF-8-JCS-Darstellung. Der Nachfolger nimmt den Wert als prev_signoff_hash in seinen eigenen signierten Kontext auf.

Beim ersten Mitglied muss das Feld fehlen. Null als erster Link, unbekanntes oder fehlendes Profil, das alte prev_context_hash, gemischte Linkarten, ein falscher Hash oder eine ausgetauschte Vorgängersignatur lassen die starke Kette scheitern. Selbst eine andere gültige Signatur über denselben Kontext ändert den Link und verlangt eine neue Nachfolgersignatur.

Unter den genannten Annahmen über Signaturen und Hashfunktionen hängt der spätere Beweis damit kausal von einem bereits fertigen früheren Beweis ab. Eine vertrauenswürdige Uhr entsteht nicht. issued_at bleibt behauptete Metadaten. Ebenso wenig belegt der Link, dass der Mensch die vorherige Entscheidung oder dieselbe Darstellung sah, den Vorgang verstand oder ohne Zwang und Routineklick handelte.

Das Beweispaket darf seine Verfassung nicht selbst liefern

Das Gate prüft Policy-Form, Signaturen, exakte Aktion, zugelassene Rollen, verschiedene Personenkennungen, verschiedene Schlüssel, Schwelle, Reihenfolge, starke Kette und Zeitfenster. Eine echte Signatur einer registrierten, aber rollenfremden Person zählt nicht. Ein Schlüssel unter zwei Namen ergibt keine zwei Genehmiger. Ein unvollständiger Trail verleiht keine Teilbefugnis.

Die erwartete Policy und das Approver Directory müssen jedoch aus authentisierten Quellen außerhalb des Quorums kommen. Sonst bringt das Artefakt seinen eigenen Maßstab mit. Auch der Basisentwurf grenzt Identität ein: Kryptografie belegt die Unterschrift des registrierten Schlüssels; die Zuordnung zu einer natürlichen Person gehört zur Registrierung und Identitätsprüfung.

Inkrementelle Aufnahme hilft beim frühen Zurückweisen, ersetzt aber nicht das Gesamturteil. Der Executor rechnet das komplette Gate nach, weil er dem Orchestrator nicht vertraut. Ein erfülltes Quorum bleibt Freigabeevidenz. Danach folgen lokale Autorisierungsentscheidung, Ausführung, beobachtete Wirkung und atomare Einmalverwendung als getrennte Nachweise.

Gemeinsame Tests sind keine unabhängige Bestätigung

JavaScript-, Python- und Go-Verifizierer verwenden ein gemeinsames Repository und Testkorpus. Übereinstimmung bei rückwärts signierten Altketten und ersetzten Vorgängersignaturen ist nützliche Konsistenzevidenz desselben Teams. Sie ist keine unabhängige Implementierung, kein formaler Beweis, kein Interoperabilitätstest und kein Produktivbetrieb.

Der Entwurf verlangt keine IANA-Aktion. Seine Aufnahme in den Datatracker ist kein IETF-Konsens. Sein Verdienst ist enger: Er zieht eine gemeinsame Invariante dort, wo Bytes sie tragen können, ohne menschliches Verfahren und betriebliche Realität in den Hash hineinzuerfinden.

Quellen

  1. IETF-Datatracker-Eintrag
  2. EP-QUORUM, Revision 04
  3. EP-QUORUM, Revision 03
  4. EP Authorization Receipts, Revision 12
  5. RFC 8785: JSON Canonicalization Scheme
  6. Web Authentication, Level 2
  7. RFC 2119: normative Schlüsselwörter
  8. RFC 8174: Groß- und Kleinschreibung normativer Wörter
  9. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  11. Running-Code Primacy