Zusammenfassung

  • Ein am 5. September 2026 veröffentlichter individueller Internet-Draft kombiniert sechs binäre CBOR-Codierungsfreiheiten für ein 165 Oktett langes COSE_Sign1-Objekt.
  • Die 64 Kombinationen erzeugen 64 verschiedene Bytefolgen und 64 verschiedene data-hash-Werte ohne Kollision. Ihre Sig_structure ist dagegen ein einziges, 109 Oktett langes Objekt; dieselbe Signatur ist überall gültig.
  • Der eingesetzte Standarddecoder weist keine Eingabe zurück. 31 Darstellungen werden nach Decodieren und erneutem Codieren still in die Ausgangsform A überführt.
  • Ein unabhängiger Lauf des veröffentlichten Skripts mit hashgleichen Artefakten reproduzierte A, 64 Hashes, null Zurückweisungen und 31 Normalisierungen.
  • Weder Signaturfälschung noch Produktivvorfall sind belegt. Die Governance-Frage lautet, welche Oktette der Bezeichner bindet und ob sein Aussteller sie später erneut vorlegen kann.

Zwei Integritätsaussagen mit unterschiedlichen Grenzen

Die Signatur eines COSE_Sign1 erfasst eine definierte Struktur. Nach RFC 9052 wird die Sig_structure aus Kontext, geschütztem Header, extern authentifizierten Daten und Nutzlast gebildet. Nicht jede Darstellungsentscheidung des umgebenden CBOR-Containers geht in diese Struktur ein.

Der im Messentwurf untersuchte data-hash umfasst dagegen die vollständig übertragenen Oktette. Er kann eine konkrete Auslieferungsform adressieren. Zwei Stellen dürfen deshalb dieselbe Signatur anerkennen und dennoch verschiedene Hashes erhalten, wenn sie unterschiedliche Codierungen verwahren.

Beides ist technisch korrekt. Die Signatur schützt ihren festgelegten Inhalt; der Hash unterscheidet Bytefolgen. Erst eine Betriebsregel, die semantische Gleichheit unbemerkt mit Bytegleichheit vertauscht, erzeugt den Beweisbruch.

Sechs Schalter ergeben mindestens 64 Formen

Ausgangspunkt A umfasst 165 Oktette. Das Experiment verändert keine Werte. Es schaltet CBOR-Tag 18 ein oder aus, verwendet für das äußere Array und die ungeschützte Header-Map jeweils bestimmte oder unbestimmte Länge und gibt die Bytefolgen für geschützten Header, Nutzlast sowie Signatur jeweils geschlossen oder in Segmenten aus.

Im veröffentlichten Artefakt stehen 64 Bytefolgen zwischen 164 und 170 Oktetten. Jede besitzt einen anderen SHA-256-Wert; Kollisionen gibt es nicht. Alle erzeugen jedoch dieselbe 109-Oktett-Sig_structure und verifizieren dieselbe Signatur.

Die Zahl 64 ist keine Obergrenze. Unterschiedliche Breiten der Integer-Codierung und die Reihenfolge von Map-Schlüsseln wurden nicht variiert. RFC 8949 beschreibt den weiteren CBOR-Spielraum. Eine Verbotsliste bekannter Rahmungen kann daher nicht beweisen, dass sie die Klasse vollständig schließt.

Der Decoder meldet Erfolg und ersetzt die Spur

Keine der 64 Eingaben wurde zurückgewiesen. Bei 31 davon führte der Zyklus aus Lesen und Schreiben exakt zu A. Für die Anwendung bleibt das Datenobjekt brauchbar; für den Nachweis der empfangenen Form ist die ursprüngliche Spur verschwunden.

Ein Dienst kann also B empfangen, hash(B) veröffentlichen, B decodieren und nur die neu ausgegebene Form A speichern. Die Signatur bleibt später prüfbar. Aus A lässt sich aber hash(B) nicht wiederherstellen. Sobald der Hash als Index, Deduplizierungsschlüssel oder Gegenstand einer weiteren Bestätigung dient, zeigen öffentlicher Name und gespeicherte Evidenz nicht mehr auf dasselbe.

„Still“ ist keine Unterstellung gegen den Parser. Geordnete Ausgabe kann sein vorgesehenes Verhalten sein. Der Versuch sagt auch nichts darüber, ob reale Transparency Services ihre Eingangsdaten so behandeln. Er belegt allein, dass eine erfolgreiche Decodierung keine Verwahrquittung darstellt.

Die eigene Reproduktion bestätigt genau den Kern

Startvektor, Ergebnistabelle und Skript sind öffentlich. Nachdem der rohe GitHub-Download scheiterte, wurde dasselbe Skript über die Contents API abgerufen und in einer temporären Python-Umgebung mit hashgleichen Kopien der JSON-Artefakte ausgeführt.

A entstand byteidentisch mit SHA-256 8595e4a4c8b93e7b1b7b798dc302a2b7d2890021f7eff372d79b32f78867e4ac. Der Lauf ergab erneut 64 verschiedene Daten-Hashes, null Zurückweisungen und 31 Normalisierungen. Er verwendete cbor2 5.7.1; der Entwurf nennt 6.1.3 auf CPython 3.13 und macOS arm64. Die Übereinstimmung über diese Versionen stützt den Zählwert, ersetzt aber keine breite Interoperabilitätsstudie.

Der Datatracker führt den Text als individuellen Entwurf ohne IETF-Billigung oder formale Stellung. Es gibt keinen RFC-Stream, zuständigen Area Director oder Telechat-Termin. Der Entwurf normiert nichts. Er meldet keine gefälschte Signatur, Hashkollision, gebrochene Primitive oder Störung eines eingesetzten Dienstes.

Die Wortwahl „wie registriert“ ist noch offen

Die Messung floss in die Last Call zum CCF Profile for COSE Receipts ein. Nicholas Templeman unterstützte in einer Nachricht vom 5. September das Voranschreiten und schlug zugleich vor, data-hash an die registrierten Oktette statt an eine spätere Re-Serialisierung zu binden. Er bezeichnete den Punkt ausdrücklich als nicht blockierend.

Das ist der Beitrag eines Teilnehmers, kein angenommener Wortlaut und kein IETF-Konsens. Der SCRAPI-Entwurf und das CCF-Profil bleiben WG-Arbeitstexte. RFC 9943 legt die veröffentlichte SCITT-Architektur fest, entscheidet aber diese spätere Präimagefrage nicht automatisch.

Der individuelle Entwurf Canonical Payload Binding bietet bereits as-transmitted: keine Kanonisierung, die genaue Oktettfolge als Präimage. jcs-n und cde-n sind als Withdrawn markiert. Die neue Messung beziffert die Klasse, die dieser Ansatz schließen soll; sie erhebt ihn nicht zum Standard.