Zusammenfassung

  • draft-templeman-scitt-framing-space-00 wurde am 5. September 2026 als individueller Informational Internet-Draft angekündigt. Er ist weder RFC noch IETF-Konsens und schlägt keine normative Formulierung vor.
  • Die Kombination aus sechs binären CBOR-Freiheiten ergab 64 akzeptierte Bytefolgen und 64 verschiedene Data-Hashes. Alle lieferten genau einen Sig_structure und dieselbe gültige Signatur.
  • 31 Eingaben wurden beim Lesen und erneuten Kodieren ohne Warnung zur kanonischen Form A. Wer nur diese Neuausgabe speichert, kann die Präimage des bereits veröffentlichten Identifikators verlieren.

Ein Gateway meldet Erfolg: Daten lesbar, Signatur gültig, Datensatz gespeichert. Erst bei der späteren Rückgabe zeigt sich der Bruch. Die gespeicherten Bytes erzeugen nicht mehr den Identifikator, den das Gateway bei der Annahme ausgegeben hatte.

Der neue Entwurf von Nicholas Templeman, dokumentiert in der I-D-Ankündigung vom 5. September, misst diesen Fall. Er setzt bewusst eine enge Grenze: eine reproduzierbare Beobachtung für laufende SCITT-Arbeit, keine Spezifikation, keine neue Anforderung und keine Behauptung über ein konkretes Produkt.

Signaturgrenze und Containergrenze fallen auseinander

RFC 9052 bildet für COSE-Signaturen einen Sig_structure. Bei COSE_Sign1 enthält er Kontext, geschützte Attribute, extern authentifizierte Daten und Payload. Nicht jede Darstellungseigenschaft des äußeren CBOR-Containers wird Teil dieser Signiereingabe.

RFC 8949 erlaubt für manche Werte mehrere Serialisierungen. Arrays und Maps können definite oder indefinite Längen verwenden; Byte Strings können geschlossen oder in Chunks erscheinen; ein passendes Profil kann die Form mit und ohne Tag annehmen. Die dekodierte Bedeutung bleibt gleich, obwohl andere Oktette übertragen werden.

Ausgangspunkt A ist 165 Oktette lang. Die Messung schaltet Tag 18, die Längenform des äußeren Arrays und der ungeschützten Header-Map sowie die geschlossene oder stückweise Ausgabe von geschütztem Header, Payload und Signatur um.

Die 64 Kombinationen sind 164 bis 170 Oktette lang. cbor2 6.1.3 akzeptierte jede. Alle rekonstruierten denselben 109-Oktett-Sig_structure; deshalb verifizierte eine Signatur sämtliche Varianten.

Das SHA-256 über die Übertragungsbytes ergab dagegen 64 verschiedene Data-Hashes ohne Kollision. Beide Resultate sind erwartbar. Unterschiedliche Hash-Eingaben unterscheiden sich; dieselbe Signiereingabe behält ihre Signatur. Nur ein zusammenfassendes „gültig“ würde die beiden Grenzen verwechseln.

Die stille Reparatur ist der eigentliche Betriebsfehler

31 Varianten kehrten in einem Decode-Reencode-Zyklus exakt zu A zurück. Kein Fehler zwang den Betreiber hinzusehen. Eine übliche Normalisierung konnte somit die ursprüngliche Darstellung vernichten.

Wenn ein Empfangsdienst den Hash der angenommenen Bytes als öffentliche Kennung ausgibt, anschließend aber nur ein geparstes Objekt weitergibt, entsteht eine Nachweisschuld. Queue und Datenbank besitzen vielleicht nie den ursprünglichen Body. Bei einer Prüfung berechnet das System den Hash seiner bevorzugten Ausgabe statt den der angenommenen Eingabe.

Das ist relevant, sobald Data-Hash als Lookup-Key, Deduplizierungswert, Registrierungskoordinate, Receipt-Verweis oder Gegenstand einer weiteren Attestation dient. Dasselbe signierte Statement kann unter einem zweiten praktischen Namen erscheinen oder trotz Speicherung als fehlend gelten. Framing-Einfluss genügt; Payload-Änderung und Signaturfälschung sind nicht erforderlich.

Der veröffentlichte Framing-Space-Datensatz enthält Verfahren und Ergebnisse, der Data-Hash-Vector die Ausgangsbytes. Laufzeit und Plattform werden genannt; eine Achse wurde unabhängig mit anderer Software nachgerechnet.

Das stärkt die Mechanismusbehauptung. Es ist keine Verbreitungsmessung. Integerbreiten und Map-Key-Reihenfolgen wurden nicht variiert, weshalb 64 ausdrücklich keine Obergrenze bildet.

Ein Byte-Grenzwert ist stärker als eine Verbotsliste

Wer nur ungetaggte Objekte oder indefinite Arrays verbietet, reagiert auf einzelne Beispiele. Die übrigen unabhängigen Achsen bleiben. Eine wachsende Liste kann nicht beweisen, dass sie den kombinatorischen Raum geschlossen hat.

Für eine „as transmitted“-Identität muss der Eingang den vollständigen Body unveränderlich speichern, bevor Parser, Schema-Validierung oder Object Mapping beginnen. Der Identifikator wird auf diesem Objekt berechnet und mit einer benannten Byte-Produktion verbunden. Dekodierte und normalisierte Formen bleiben getrennte Ableitungen.

Ein Protokoll kann stattdessen genau eine deterministische Serialisierung wählen und andere Formen zurückweisen. RFC 8949 Section 4.2 bietet dafür eine Grundlage. Eine Encoder-Präferenz allein prüft jedoch nicht, dass der Eingang diese Regel erfüllt.

Der frühere as-transmitted-Profilentwurf vermeidet Canonicalization und verlangt einen Selektor für eine bereits im Format benannte Bytefolge. Auch er ist ein individueller Entwurf. Die neue Messung quantifiziert die Begründung für eine präzise Grenze, verleiht dem Profil aber keinen Standardstatus.

Vier Belege dürfen nicht zu einer Ampel werden

RFC 9943 trennt in SCITT Signed Statement, Transparency Service, Receipt und spätere Bewertung. Die aktuellen Arbeiten an SCITT Reference APIs und CCF Receipt Profile zeigen, warum ein Data-Hash zur realen Registrierungs- und Abrufkoordinate wird.

Jeder Beleg besitzt dennoch nur begrenzte Autorität. Raw Bytes zeigen, was eine Komponente empfing. Eine gültige Signatur zeigt die Integrität des Sig_structure unter einem Key; Identitätszuordnung und Berechtigung prüft die Anwendung. Ein Receipt zeigt Aufnahme nach den Regeln des Dienstes, nicht Wahrheit, Aktualität oder zulässige Verwendung.

Heng Lus Forderung nach Realität statt Advocacy verhindert eine falsche Schuldgeschichte. Ein toleranter Decoder und ein normalisierender Encoder können jeweils korrekt sein. Der Strukturfehler entsteht, wenn ihre Ausgaben als derselbe Nachweis gelten.

Running-Code Primacy verlangt den Test durch Gateway, Queue, Datenbank und Retrieval-API. Die Trennung von technischer Fähigkeit und Autorität macht klar: Eine Bibliothek kann Bytes neu schreiben, ohne damit die Befugnis zu erhalten, einen bereits vergebenen Nachweis umzubenennen.

Die Organisation muss sich nicht abstrakt zwischen Canonicalization und Wire Hash entscheiden. Sie muss konkret benennen, was der Identifikator bedeutet, und genau den Beleg behalten, mit dem diese Bedeutung später reproduziert werden kann.

Sources