Zusammenfassung

  • draft-nikolaichuk-scitt-continuity-receipts-01 schlägt eine signierte Recovery Statement und ein RFC-9942-Receipt vor, das deren Registrierung in einem SCITT Transparency Service belegt.
  • Der Entwurf verlangt Messwerte in ihrem nativen Algorithmus und ihrer nativen Länge. Als Gegenbeispiel nennt er angrenzenden Code, der 48-Oktett-SHA-384-Messungen von AWS Nitro und AMD SEV-SNP auf 32 Oktette kürzt.
  • Weder ein Entry Identifier nach HTTP 202 noch das spätere Receipt beweist die tatsächliche Wiederherstellung oder die Gleichwertigkeit des Ergebnisses. Beide belegen engere Verfahrensschritte.

Wenn ein Feld korrekt aussieht und den Gegenstand verloren hat

Hashwerte besitzen eine beruhigende Form. Eine feste Länge, hexadezimale Darstellung und ein Algorithmusname lassen sie wie harte Tatsachen wirken. Doch ein Messwert, der von 48 auf 32 Oktette gekürzt wurde, ist nicht mehr das Objekt, das die ursprüngliche Policy verglichen hat.

Genau diesen Fehler dokumentiert draft-nikolaichuk-scitt-continuity-receipts-01. AWS Nitro PCR0 und das AMD-SEV-SNP-Launch-MEASUREMENT verwenden in dem beschriebenen Zusammenhang SHA-384 mit 48 Oktetten. Der benachbarte Referenzcode drückt beide in ein 32-Oktett-Feld. Das kostet nicht nur Entropie. Es verhindert Byte-Gleichheit mit dem vollständigen Wert, den etwa eine KMS-Bedingung auswertet.

Der Entwurf vom 29. September 2026 ist ein individueller Internet-Draft mit angestrebtem Status Informational. Er ist weder vom SCITT-WG angenommen noch ein RFC. Sein Thema ist eine Recovery Statement für zustandsbehaftete Assets und deren Registrierung mit bestehenden SCITT- und COSE-Receipt-Bausteinen. Die Messwertabweichung ist kein Produktionsvorfall. Sie zeigt, wie schnell eine Beweiskette formvollendet und sachlich unbrauchbar werden kann.

Die Wiederherstellung endet nicht bei der Schlüsselentscheidung

Der Ablauf beginnt mit Evidence aus der Recovery Environment. Ein Verifier bewertet sie und erzeugt Attestation Results. Ein eigener Mechanismus gibt versiegeltes Schlüsselmaterial frei. Erst danach entschlüsselt die Umgebung das versiegelte Material, setzt das Asset zusammen und berechnet recovered-digest über die tatsächlich entstandenen Klartextbytes.

Die Recovery Authority formuliert die Claims und signiert sie als RFC-9943-Signed-Statement. Ein Transparency Service wendet seine Registration Policy an, fügt die Erklärung dem Log hinzu und stellt ein RFC-9942-Receipt aus. Ein Relying Party prüft anschließend Receipt, Issuer, Claims, Attestation-Verweise und seine lokale Policy, bevor es handelt.

Diese Rollen sind keine Stationen eines einzigen Wahrheitsautomaten. Die Schlüsselfreigabe bestätigt eine Autorisierung, nicht das Ergebnis. Die Recovery Authority liefert eine zurechenbare Aussage, nicht notwendig eine unabhängige Prüfung. Der Transparency Service sieht die registrierte Aussage, nicht den Rekonstruktionsvorgang. Der Verbraucher trägt die Wirkung der Nutzung.

Lu Hengs Trennung von Realitätsschichten ist hier praktisch: Ein symbolischer Nachweis darf nur für den Schritt sprechen, den er wirklich abbildet. Sonst wird aus einer dünnen gemeinsamen Spezifikation eine unverdiente Kontrollinstanz.

Der genaue Gegenstand des Receipts

Ein Continuity Receipt beweist, dass eine bestimmte Recovery Statement eines bestimmten Issuers bei einem bestimmten Transparency Service an einer bestimmten Position des append-only Logs registriert wurde und der Service diesen Tatbestand signiert hat.

Es beweist nicht, dass das Recovery Event stattfand. Es beweist keine Übereinstimmung mit dem ursprünglichen Asset. Es zeigt nicht, dass referenzierte Attestation Results geprüft oder günstig waren. Es bestätigt den behaupteten Umgebungszustand nicht und sagt nicht, dass Registration Policy diese Fragen kontrollierte.

Diese Begrenzung ist eine Stärke. Der Service macht die Aussage dauerhaft, zurechenbar, geordnet und schwer heimlich zurückzunehmen. Er gibt sich nicht als Auditor für Hardware, Recovery-Code und Mandantenrichtlinien aus, die er nicht beherrscht.

Ein Verifier muss daher Issuer-Behauptungen und unabhängig festgestellte Tatsachen getrennt ausgeben. Ein gemeinsames „verifiziert“ wäre keine Vereinfachung, sondern eine falsche Delegation von Autorität.

Zwischen HTTP 202 und dem Receipt liegt eine Freigabeentscheidung

Der aktuelle SCRAPI-Entwurf erlaubt asynchrone Registrierung. Der Service kann mit HTTP 202 und einem Entry Identifier antworten; das Receipt wird später über die Entry Resource aufgelöst.

Der Identifier ist ein Bearbeitungsanker. Er ist kein Inclusion Proof. revision 01 verlangt deshalb eine ausdrückliche Wahl: auf das Receipt warten oder ohne Receipt fortfahren. Wer fortfährt, muss die Wiederherstellung bis zur Auflösung als unwitnessed führen.

Für zeitkritische Systeme kann eine solche Ausnahme vernünftig sein. Ein ausgefallener Witness darf nicht automatisch jede Notfallwiederherstellung blockieren. Vernünftig wird die Ausnahme aber erst durch eine benannte Entscheidungsrolle, Geltungsdauer, zugelassene Verbraucher, Ersatzkontrollen und eine Frist zur Nachregistrierung. Ein Dashboard darf die Beweisschuld nicht beim ersten grünen Prozessstatus löschen.

Ein gespeicherter Entry Identifier verspricht eine spätere Prüfung. Ohne Receipt ist er noch kein Beweis.

Der Output-Digest ist eine Messung, kein Sollwert

recovered-digest muss über den Klartext berechnet werden, der am Ende des Recovery Events tatsächlich vorliegt. Der Digest aus einem Backup-Katalog darf nicht kopiert werden. Er kann als Sollwert in einen Vergleich eingehen; als Istwert würde er die Schlussfolgerung vorwegnehmen.

Dasselbe gilt für die Recovery Environment. Algorithmus und Länge gehören zur Identität der Messung. Trunkierung, Re-Hashing, Padding oder Normalisierung schaffen ein neues Datenobjekt. Wenn die Policy den nativen Wert verwendete, muss der spätere Nachweis genau diesen Wert erhalten.

Running-Code Primacy bedeutet hier nicht, dass der Code recht hat. Sie verlangt, seine tatsächliche Ausgabe gegen die behauptete Semantik zu prüfen. Der schön benannte Datentyp darf den verlorenen Messgegenstand nicht verdecken.

Attestation Results können vorhanden und trotzdem unbrauchbar sein

Der Entwurf kennt referenzierte, eingebettete und separat registrierte Attestation Results. Eine Referenz hält die Statement klein, bindet die spätere Prüfung aber an die Verfügbarkeit exakt derselben Bytes. Einbettung erhöht die Selbständigkeit und kann Hardware-, Regions- oder Workload-Details veröffentlichen. Separate Registrierung gibt dem Ergebnis ein eigenes Receipt, erzeugt aber ein weiteres Beweisobjekt.

Freshness wird mit Nonce, Epoch-ID, Zeitstempel oder none beschrieben. none legt offen, dass Evidence nicht an eine Challenge gebunden und daher wiederholbar war. Das ist keine Formatverletzung, aber auch kein Beleg für einen aktuellen Zustand.

Ein authentisches Attestation Result kann außerdem ungünstig sein. Vorhandensein, Signaturprüfung, Frische und Bewertung dürfen nicht in einem Label verschwinden.

Betriebsfähigkeit bleibt eine schwache Gleichwertigkeit

Fehlt equivalence, gilt none. byte-identical setzt voraus, dass der gemessene Recovery-Digest mit dem beim Versiegeln gespeicherten Klartext-Digest übereinstimmt und der Issuer den Vergleich selbst geprüft hat. operational bedeutet nur, dass ein definierter Test bestanden wurde; Definition und Ergebnis müssen referenziert sein.

Der Entwurf nennt diesen Claim schwach. Eine Datenbank kann starten und Datensätze verloren haben. Ein Modell kann laden und anders reagieren. Ein Health Probe kann antworten, während Geschäftsregeln gebrochen sind.

Semantische und verhaltensbezogene Gleichwertigkeit erhalten bewusst keinen Codepunkt. Ein nicht implementierter Begriff würde dem Smoke Test eine Autorität verleihen, die er nicht besitzt. Das Receipt kann gültig sein, obwohl über Gleichwertigkeit nichts ausgesagt wird.

Zwei Ordnungen müssen getrennt geprüft werden

prev-event verbindet Recovery Statements eines Subjects zur Continuity Chain. Sie drückt die vom Issuer behauptete Abstammung aus. Das append-only Log liefert dagegen eine globale Registrierungsreihenfolge.

Eine Lücke zwischen beiden kann bedeuten, dass dem Issuer ein Zwischenereignis unbekannt war oder dass er es nicht anerkennen wollte. Der Verifier muss die Lücke melden, nicht reparieren. Entry ID und Leaf Index sind Suchhilfen; der Digest der vorherigen Statement ist die kryptografische Verbindung.

Über mehrere Transparency Services hinweg entsteht keine gemeinsame Ordnung. Jeder Dienst belegt seine eigene. Langfristig braucht ein Prüfer zudem Consistency Receipts zwischen alten und neuen Tree Heads. Inclusion in eine isolierte Root beweist nicht, dass das frühere Log fortgeschrieben statt ersetzt wurde.

Datenschutz entfernt zugleich Prüffläche

Ein angehängtes Claims-Payload ermöglicht inhaltliche Registration Policy, kann aber stabiles Subject, Recovery-Frequenz, Region, Dienstbeziehung und Hardwarekennung dauerhaft offenlegen. Ein detached Payload schützt die Details im Log. Dafür kann der Service keine Policy auf Claims anwenden, die er nicht besitzt, und der Relying Party braucht einen Nebenkanal.

Ein HMAC-basiertes Pseudonym erschwert öffentliche Korrelation. Es verhindert aber das Zusammenführen verschiedener Custodians, macht den Issuer-Key zu einem langlebigen Geheimnis und spaltet die Chain bei Rotation. Datenschutz entscheidet mit, wer später noch Kontinuität prüfen kann.

Referenzcode und Vorschlag sind nicht deckungsgleich

Der Entwurf erklärt offen, dass die angrenzende Referenzimplementierung das Dokument nicht implementiert. Sie erzeugt keine RFC-9942-COSE-Receipts, nutzt andere Logverkettungen, hat unvollständige Attestation-Prüfung und keine Nonce-Bindung. Ihre Rekonstruktion ist eine deterministische Markov-Kette dritter Ordnung über Bytes, kein Nachweis semantischer Wiederherstellung.

Das ist kein Beleg für ein Scheitern im Betrieb. Es ist ein belegter Unterschied zwischen Spezifikation und Code. Deployment und Interoperabilität bleiben unbelegt.

Quellen und Grenzen

Die Quellen beschreiben einen Arbeitsentwurf, bestehende Architekturen und selbst dokumentierte Grenzen angrenzenden Codes. Sie belegen weder Deployment, Vorfall, Angriff, tatsächliche Recovery, Interoperabilität, Adoption noch semantische Gleichwertigkeit. Das folgende Freigabedossier ist Daniel Kades Betriebsanalyse, keine bereits standardisierte Anforderung.