Summary

  • Vaara Receipt Revision 12 kann pro Boundary seq und runningCount signiert binden. Bleibt ein späterer Beleg erhalten, wird ein ausgelassener mittlerer Wert zur nachweisbaren Lücke.
  • Der zusammenhängende Präfix 0..k verrät keinen entfernten Suffix. Ein terminales Seal fixiert N, doch wer Suffix und Seal unterdrückt, hinterlässt im gehaltenen Satz keinen Widerspruch.
  • Ein RFC-3161-Anker über dem Abschlusszähler schafft einen externen Zeitpunkt. Signatur, Coverage, innere Vollständigkeit, Abschluss, Zeugenschaft und Wirkung bleiben eigenständige Nachweise.

Eine korrekte Akte mit falschem Schlusspunkt

Die leichte Manipulation liegt in der Mitte. Fehlt Beleg 5, während 6 vorhanden ist, verlangt dessen runningCount mehr Datensätze als gehalten werden. Die Lücke trägt eine Nummer.

Die schwere Manipulation entfernt alles ab 6. Beleg 5 bleibt wahr: Bis zu ihm gab es sechs Belege. Der Prüfer besitzt sechs. Keine lokale Prüfung kann aus einem damals gültigen Präfix ableiten, dass später ein weiterer Datensatz erzeugt wurde.

draft-sirkkavaara-vaara-receipt-12 macht daraus keine magische Eigenschaft der Signatur. Der Entwurf ordnet die Nachweise: Beobachtungsgrenze, Datensatzintegrität, Kontinuität, Abschluss und externer Zeuge.

Vollständigkeit beginnt mit Coverage

Ein optionaler coverage-Block benennt den Chokepoint, den Fingerprint der Werkzeug- oder Befehlsoberfläche und die Einschränkung, dass nur durch diesen Punkt geleitete Aufrufe beobachtet werden. Direkte oder alternative Wege bleiben außerhalb.

Darum beweist ein fehlender Ablehnungsbeleg nicht, dass keine Aktion stattfand. Mit Coverage heißt er höchstens „innerhalb dieser Boundary nicht abgelehnt“. Ohne Coverage heißt er nur „in diesem Satz nicht beobachtet“.

Der completeness-Block bindet boundaryId, eine bei null beginnende Sequenz und runningCount = seq + 1. Ein später gehaltener Datensatz verpflichtet den Aussteller damit auf die Zahl seiner Vorgänger. Das ist die belastbare Leistung: eine innere Auslassung wird ohne Online-Rückfrage sichtbar.

Das Seal verlagert Vertrauen

Ein abschließender Datensatz kann {sealed: true, total: N} erklären. Liegt er vor, muss der Prüfsatz N Einträge enthalten. Optional kann maxClass die höchste autorisierte Aktionsklasse und damit den Worst Case einer Lücke begrenzen.

Das Seal ist jedoch selbst ein entfernbarer Datensatz. Wer den Suffix kontrolliert, kann auch den Abschluss entfernen. Der verbleibende Präfix bleibt konsistent. Der Entwurf bezeichnet diesen Fall zu Recht als aus dem held set allein nicht auflösbar.

Deshalb soll ein RFC-3161-Zeitstempel den finalen Zähler extern festhalten: Zum Zeitpunkt T existierte ein signierter Payload für N Belege. Eine spätere Vorlage von nur k Belegen kollidiert mit einer Erwartung in anderer Verwahrung.

Ein selbst betriebener TSA kann protokollkonform und institutionell abhängig sein. Wenn dieselbe Administration Aktionen, Belege, Seal und Zeitdienst kontrolliert, bleiben mehrere kryptografische Formen in einer Unterdrückungsdomäne. Authority, Schlüssel, Prüfpolicy, Uhr und Aufbewahrer müssen benannt werden.

SCITT bezeugt Registrierung, nicht automatisch Schluss

Der Entwurf beschreibt zusätzlich die Registrierung bei einem SCITT Transparency Service. Dessen Receipt verpflichtet den registrierten Signed Statement unter der Servicepolicy. Es reist neben dem Vaara-Beleg und ist kein bloßer weiterer timestampAnchors-Eintrag.

RFC 3161 verbindet Digest und Zeitbehauptung. SCITT verbindet Statement und Registrierungsereignis. runningCount entdeckt innere Lücken. Das Seal nennt das Endtotal. Auch RFC 9162 trennt Inclusion- und Consistency-Proof. „Im transparenten Log“ ist daher keine hinreichende Kontrollbeschreibung.

Rechenbarkeit ist keine Welterkenntnis

RFC 8785 JCS gibt JSON eine deterministische Byteform. Öffentliche Vektoren und vom Ausstellercode unabhängige Checker können Signaturen, Evidence-Bindings, Backlinks und Lückenfälle neu berechnen. Das ist aussagekräftiges Running Code.

Ein passender Hash beweist jedoch nur, welches Evidence-Objekt gebunden wurde. Er beweist weder Wahrheit noch Vollständigkeit. Eine gültige Signatur benennt einen Schlüssel, nicht dessen heutigen Status. Der Entwurf definiert weder Revocation noch Key-Freshness; diese Politik muss das Deployment liefern.

Ebenso ist die Entscheidung nicht die Ausführung. Ein Decision Receipt hält allow, block oder escalate fest. Ein Execution Receipt kann per backLink darauf zeigen, executed oder refused signieren und ein Ergebnis binden. Ob das externe System seinen Zustand tatsächlich änderte, braucht einen eigenen Beobachter.

Lu Hengs Reality Layers verhindern die Abkürzung: kanonische Bytes sind kein vollständiger Satz; der Satz ist keine geschlossene Boundary; das Seal ist kein unabhängiger Zeuge; der Zeuge ist nicht die Aktion; die Aktion ist nicht ihr dauerhafter Effekt. Eine Minimum Initial Specification darf die Hülle vereinheitlichen, während lokale Verantwortliche Coverage, Abschluss und Folgeentscheidung behalten.

Sources and limits

Die Quellen belegen einen aktiven individuellen Internet-Draft und verwandte öffentliche Spezifikationen. Sie belegen keinen IETF-Konsens, keinen Vaara-Receipt-RFC, keine WG-Annahme, kein unabhängiges Audit, keine breite Einführung, keine vollständige Coverage, keine unabhängige Zeitautorität und kein beobachtetes Ergebnis. Dieser Artikel besitzt nur die Grenze zwischen innerer Lücke, Tail-Seal und externem Count-Anker in Revision 12.