Zusammenfassung

  • draft-mih-scitt-checkpointed-local-log-01 bindet ein privates Log an Merkle-Mountain-Range-Prüfpunkte. Eine Konsistenzprüfung beweist jedoch nur, dass der gezeigte Zweig seinen eigenen Vorgänger fortsetzt.
  • Gegen Äquivokation hilft erst ein unabhängiger, prüfpunktbewusster Zeuge, der den zuletzt akzeptierten Zustand derselben Logidentität aufbewahrt. Eine gewöhnliche SCITT-Registrierung bedeutet Aufnahme, nicht automatisch Kontinuität.

Ein Betreiber legt einem Prüfer eine Folge signierter Entscheidungen vor. Jede Signatur stimmt, jeder Prüfpunkt verweist auf einen früheren Zustand, jede Inklusionsprüfung gelingt. Das wirkt wie eine geschlossene Historie.

Ein zweiter Prüfer könnte eine andere, ebenso geschlossene Historie erhalten haben.

Der Checkpointed Local Log hält Einträge beim Produzenten. Ihre Hashwerte fließen in eine Merkle Mountain Range; ein kompakter signierter Prüfpunkt bindet Loggröße und Akkumulator. So lässt sich ein externer Zeuge einschalten, ohne private Datensätze einzeln zu veröffentlichen.

Der Entwurf benennt aber die Stelle, an der Mathematik ohne externe Erinnerung nicht reicht.

Ein konsistenter Zweig beweist keinen einzigen Zweig

log_size und commitment beschreiben den aktuellen Zustand. prev_size und prev_commitment nennen den Vorgänger. Ein Beweis kann zeigen, dass der neue Zustand die frühere Folge erweitert, ohne bereits gebundene Einträge zu verändern.

Der Produzent kann trotzdem Zweig A und Zweig B führen. A2 erweitert A1 korrekt, B2 erweitert B1 ebenfalls. Wer nur A sieht, findet keinen Fehler; wer nur B sieht, auch nicht. Die Prüfung kennt keinen Zustand, der ihr nicht vorgelegt wurde.

Ein prüfpunktbewusster Zeuge hält deshalb den letzten akzeptierten Zustand für die Kombination aus Produzentenidentität und Logkennung fest. Beim nächsten Prüfpunkt muss der angegebene Vorgänger genau passen. Passt er nicht, verlangt der Entwurf Ablehnung und die Behandlung als Mutationsbeleg. Ein automatischer Retry wäre gefährlich: Er könnte den Konflikt so lange weiterreichen, bis ein zustandsloser Empfänger ihn annimmt.

Kontinuität entsteht damit aus externer Verwahrung und einer verbindlichen Ablehnung, nicht aus einem zusätzlichen Signaturfeld.

SCITT-Aufnahme ist noch keine Kontinuitätsprüfung

Der Prüfpunkt kann als Signed Statement nach RFC 9943 registriert werden. Der Transparency Service gibt einen COSE Receipt nach RFC 9942 zurück. Dieser Receipt belegt die Aufnahme unter dem Schlüssel des Dienstes. Zeit belegt er nur, wenn er tatsächlich eine signierte Zeitangabe trägt.

Ein Dienst kann den Prüfpunkt wie jede andere Erklärung registrieren, ohne den CLL-Vorgänger mit seinem eigenen letzten Zustand zu vergleichen. Sein Receipt bleibt gültig, besitzt aber keine Kontinuitätsbedeutung. Erst der zustandsbehaftete Vergleich macht den Dienst zum prüfpunktbewussten Zeugen.

Für Beschaffung und Audit muss deshalb geklärt werden: Speichert der Dienst den letzten Zustand pro Logidentität? Wie lange? Was geschieht bei einem Konflikt? Ist sein Ergebnis nur Inklusion, zusätzlich signierte Zeit oder auch Kontinuität?

Auch ein direkt gegenzeichnender Zeuge muss vorher vergleichen. Einen lokalen Test-Stub behandelt Revision 01 bewusst anders. Weil keine ausgelieferte Implementierung die vorgeschlagene RFC-9338-Struktur erzeugt, bleibt das Format Zukunftsarbeit. Eine private Markierung darf nicht als unabhängiges Zeugnis erscheinen.

Eine eigene Kopie bleibt eine Replik

Der Produzent muss benennen, auf welche Zeugen er sich beruft. Betreibt er den Zeugen selbst, nennt der Entwurf ihn Replik. Sie kann Ausfallsicherheit schaffen, verlagert aber nicht die Macht, zwei Zweige zu unterhalten.

Mehrere unabhängige Zeugen erschweren Äquivokation nur, wenn sie wirklich getrennte Autoritäten sind und ein Verifizierer mehrere von ihnen befragt. Gemeinsame Verwaltung, Kollusion oder Netzwerkpartition können aus vielen Endpunkten eine einzige Vertrauensgrenze machen.

Ebenso wichtig ist die zeitliche Grenze. Alles hinter dem letzten bezeugten Prüfpunkt ist so stark wie ein unbezeugtes Log. Der Receipt von gestern gilt nicht für den aktuellen Schwanz. Eine erklärte Höchstkadenz macht einen ausbleibenden Prüfpunkt erkennbar; das mögliche Rückdatierungsfenster bleibt Kadenz plus Zeugenlatenz.

Der Zeuge sieht Verpflichtungen, nicht Akten

Der Zeuge erhält keine Einträge. Er kann die Form der gebundenen Historie stützen: Existenz bis zu einem bestimmten Zeitpunkt, Reihenfolge, Integrität und Vollständigkeit eines vorgelegten Bereichs. Für einen einzelnen Datensatz braucht der Verifizierer weiterhin die Bytes und einen Inklusionsbeweis von einem anderen Verwahrer.

Fehlt ein archiviertes Segment, kann der Prüfpunkt zeigen, dass ein Eintrag existierte, ihn aber nicht wiederherstellen. „Aufbewahrungsfrist abgelaufen“ ist dann ehrlicher als „nie vorhanden“.

Auch Inhalt wird nicht wahr, nur weil das Log bezeugt ist. Berechtigung, tatsächliche Ausführung und beobachtete Wirkung benötigen andere Belege. CLL beweist weder, dass dies das einzige Log des Produzenten ist, noch dass er alle erzeugten Datensätze angehängt hat.

Revision 01 legt außerdem die Drahtdarstellung fest: eine kanonisch CBOR-codierte Liste der MMR-Spitzen. Eine zusammengefaltete Wurzel darf intern beschleunigen, ihr Fold ist aber nicht standardisiert und darf nicht in den Commitment-Feldern stehen. Das ist ein präziser Entwurfsvorschlag, kein Nachweis von Einsatz oder Interoperabilität. Das Dokument ist eine individuelle Einreichung ohne formellen IETF-Status.

Quellen