Zusammenfassung

  • draft-dogru-cedulon-decision-profile-02 vom 5. September 2026 ist ein aktiver individueller Internet-Draft ohne Billigung oder formellen Status der IETF, ohne RFC-Stream und ohne zuständigen Area Director.
  • Das Profil gleicht signierte Decision Records mit authentisierten Zeilen eines Effect Extract ab. Ein Allow erwartet eine Wirkung; Deny oder Defer erwarten keine.
  • Revision 02 sagt ausdrücklich, dass die Bindung die beiden Uhren nicht ordnet. Der Zeitstempel einer Zeile wird gegen das Extract-Fenster geprüft, nicht gegen den Zeitstempel des zugehörigen Decision Record.
  • effect-against-refusal belegt deshalb das gemeinsame Auftreten einer Ablehnung und einer Wirkung unter derselben Referenz. Es belegt weder die zeitliche Nachfolge noch den Ort eines Kontrollversagens.
  • Ein eigener Sequenzbeleg sollte Uhrenhoheit, Toleranz und Zusatzbelege nennen und zwischen davor, danach, innerhalb der Abweichung und unbestimmt unterscheiden.

Ein Abgleich ist noch kein Ablauf

Der Datatracker-Eintrag beschreibt Revision 02 eines individuellen Entwurfs von Emek Can Doğru, aktualisiert am 5. September. Er grenzt seinen institutionellen Rang klar ab: Jeder kann einen I-D einreichen; dieser Text ist nicht von der IETF gebilligt und hat keinen formellen Status im Standardisierungsprozess. RFC-Stream, Responsible AD und Telechat-Datum fehlen, der IESG-Zustand lautet nur „I-D Exists“.

Das technische Modell vergleicht zwei Populationen. Der Decider signiert einen Datensatz darüber, ob ein Agent handeln darf. Der Kanal oder sein Erfassungsprozess authentisiert die tatsächlich beobachteten Wirkungen in einem Zeitfenster. Der Verifier prüft genau einen Decider, einen Kanal und ein deklariertes Fenster.

Ein Allow soll genau eine Zeile mit derselben Referenz, demselben Content-Hash und derselben Wirkungsklasse finden. Fehlt sie, entsteht decision-without-effect. Eine Zeile ohne Decision Record wird effect-without-decision. Eine Ablehnung — Deny oder Defer — erwartet keine Zeile; taucht eine unter ihrer Referenz auf, lautet der Befund effect-against-refusal.

Diese Unterscheidung ist substanziell. Sie zeigt, dass die Entscheidungspopulation und die Wirkungspopulation nicht zusammenpassen. Die archivierte Revision 02 verhindert jedoch, dass daraus automatisch eine zeitliche Erzählung wird.

Eine frühere Zeile bindet ebenfalls

Beide Seiten tragen timestampMs. Trotzdem führt das aktuelle Verfahren keinen paarweisen Zeitvergleich aus. Die Zeile muss innerhalb von [windowStartMs, windowEndMs) liegen. Ihr Wert wird nicht mit der Zeit des Decision Record verglichen. Eine Zeile mit einem Datum vor dem Record bindet so, als wäre sie danach entstanden. Gemessen werden Referenz, Inhalt und Klasse, nicht die Reihenfolge.

Liegt eine Wirkung um 10:00 Uhr und eine Ablehnung um 10:01 Uhr vor, kann der Verifier denselben Befund ausgeben wie bei der umgekehrten Folge. Die Wirkung kann tatsächlich früher gewesen sein; eine Uhr kann vorgehen; die Entscheidung kann früher gefallen, aber später signiert worden sein; oder der Erfassungsprozess kann Zeiten nachgetragen haben. Der Populationsfehler bleibt möglich, während die Historie offenbleibt.

Das Fenster erfüllt eine andere Funktion. Eine Zeile außerhalb des Bereichs macht das gesamte Extract fehlerhaft. Ungepaarte Einträge nahe einer Fenstergrenze können nach der geerbten Regel zurückgestellt oder in das nächste Extract getragen werden; der Companion verwendet dafür standardmäßig fünf Minuten. Damit wird der Prüfungsumfang gesichert. Es wird nicht bewiesen, dass Decider- und Kanal-Uhr dieselbe Quelle oder Synchronisation hatten.

Auch Signaturen schließen diese Lücke nicht. Sie belegen den signierten Zahlenwert unter einem Schlüssel, nicht dessen Entstehungszeit oder Uhrengenauigkeit. Das Profil selbst macht seine Garantie von der Unabhängigkeit der beiden Trust Roots abhängig. Wenn ein Deployment beide Seiten nachträglich erfasst, kann kryptografische Konsistenz bestehen, ohne dass eine unabhängige Chronologie vorliegt.

Den Befund nicht zur Schuldbehauptung aufblasen

effect-against-refusal sollte als Erhaltungsbefund bestehen bleiben. Unter einer Referenz, die als Ablehnung geführt wird, ist eine Wirkung vorhanden. Das unterscheidet den Fall von einer Wirkung ohne jede Entscheidung und schafft eine bessere Ermittlungsgrundlage.

Der Draft sagt zugleich, dass der Befund den Fehler nicht lokalisiert. Kontrollübertragung, Enforcement, Nebenpfad oder Erfassung können betroffen sein. Ebenso streng sollte die Zeitsprache sein. „Wirkung unter einer abgelehnten Referenz“ ist gedeckt. „Der Agent handelte nach der Ablehnung“ fügt Reihenfolge, Zustellung und Durchsetzbarkeit hinzu.

Diese Zusätze können Incident-Eskalation, Vertragsansprüche oder personelle Maßnahmen auslösen. Der Grundsatz genauer Aufzeichnungen von Heng Lu liefert eine passende redaktionelle Grenze: Ein Register beschreibt Wirklichkeit, es erzeugt sie nicht. Hier darf der Abgleich nur die vorhandenen Daten und ausgeführten Vergleiche beschreiben. Das ist Daniel Kades analytische Anwendung, keine Cedulon- oder IETF-Vorgabe.

Vier Zustände statt einer erzwungenen Antwort

Eine Sequenzprüfung kann den vorhandenen Befund ergänzen. effect-against-refusal und sequence-indeterminate dürfen gleichzeitig gelten. Das eine betrifft den Populationsabgleich, das andere die Beweiskraft der Zeiten.

Ein Zeitbeleg sollte beide signierten Datensätze per Hash identifizieren. Für jede Uhr gehören Quelle, Betreiber, Erfassungsweg, Synchronisation und ein möglicher Vorabnachweis in den Beleg. Ebenso muss die Toleranz mit ihrer betrieblichen Begründung sichtbar sein.

Dann reichen vier Ergebnisse: before, wenn die Wirkung außerhalb der Unsicherheit früher liegt; after, wenn sie entsprechend später liegt; within-skew, wenn der Zahlenunterschied die Toleranz nicht überlebt; und indeterminate, wenn Herkunft oder Synchronisation keinen Vergleich tragen.

Monotone Zähler, Kanalreihenfolgen, vertrauenswürdige Zeitstempel, Checkpoints oder unabhängige Beobachtungen können helfen. Jede Quelle hat eine eigene Hoheit. Ein Zähler des Deciders schafft keine Unabhängigkeit; eine Kanalfolge zeigt nicht, wann eine Policy den Agenten erreichte. Selbst ein belastbares „danach“ beweist zeitliche Präzedenz unter Annahmen, nicht Ursache oder Schuld.

Running Code muss auch Zweifel transportieren

Die Implementation-Status-Sektion nach RFC 7942 nennt zwanzig Konformitätsfälle und vier Offline-Fixtures im autorengeführten Repository. Sie legt zugleich offen, dass Revision 02 nur Text ändert und keinen Fall ergänzt: Die Uhrenordnung wird beschrieben, aber nicht durchgesetzt. Ein echter Kanal-Log wurde nicht gemessen, eine unabhängige Implementierung ist nicht bekannt und die öffentlichen Testzeiten wurden ohne zeitlichen Vorabnachweis nachträglich gesetzt.

Der nächste überprüfbare Schritt wäre eine Suite mit klarer Vorher-, klarer Nachher-, Skew-, Unvergleichbarkeits- und Nachtragslage. Der wichtigste Test erzwingt nicht mehr Alarme. Er weist nach, dass indeterminate vom Verifier bis zur Entscheidung erhalten bleibt.

Quellen

  1. IETF Datatracker: Cedulon Decision Profile
  2. IETF-Archiv: draft-dogru-cedulon-decision-profile-02
  3. Cedulon-Companion-Repository
  4. IETF Datatracker: Cedulon Core Draft
  5. RFC 7942: Improving Awareness of Running Code
  6. RFC Editor: How RFCs Are Created
  7. Heng Lu: The Bill of Rights of Uniqueness Coordination