Zusammenfassung

  • Revision 03 ordnet jede typisierte Referenz einem von vier Ergebnissen zu: Malformed, Unresolved, Failed oder Verified. Eine gültige Struktur im signierten Bereich beweist noch keine Bindung an das referenzierte Artefakt.
  • Verified setzt genau einen vom konsumierenden Profil autorisierten Digest-Kontext, die Beschaffung des Artefakts, die vorgeschriebene Konstruktion und einen Vergleich in der richtigen Darstellung voraus.
  • Signaturgültigkeit, Aussteller-Authentisierung, SCITT-Receipt, Artefaktbewertung und Autorisierung bleiben getrennte Nachweise mit getrennten Entscheidern.

Was Revision 03 tatsächlich ist

Steven Mih und Anton Sokolov veröffentlichten am 5. September 2026 Revision 03 von Canonical Payload Binding: A Signed Statement Construction Profile. Der Datatracker führt das Dokument als aktiven individuellen Internet-Draft. Die Autoren nennen SCITT als vorgesehene Arbeitsgruppe; eingetragen sind jedoch weder IETF-Stream noch zuständiger AD, Annahmebeschluss oder Konsens. Der Text kann sich ändern, ersetzt werden oder verfallen.

Diese Einschränkung gehört zur Einordnung. Es handelt sich nicht um die Meldung eines Standards oder einer produktiven Einführung. Relevant ist die präzisere operative Trennung, die der Entwurf anbietet. Seit -02 wurden die neutralen CPB-Mechanismen von Payload-spezifischen Formaten getrennt. Die typisierte Referenz ist nun ein Informationsmodell aus vier Elementen. Ein Payload-Profil darf einen eigenen Carrier definieren; daneben bietet CPB cpb-refs als optionalen Transport im geschützten COSE-Header an.

Zugleich entfernt die Revision die Vorstellung eines universellen Artefakttyp-Registers innerhalb von CPB. Das konsumierende Profil muss über eine stabile normative Referenz festlegen, welche Typen und Digest-Kontexte es akzeptiert. Der Text trennt den Full-Payload-Modus nach RFC 9943 vom Hash Envelope nach RFC 9995, verbietet zwei Referenz-Carrier in demselben Signed Statement und benennt vier Verarbeitungsergebnisse.

Malformed ist keine fehlgeschlagene Inhaltsprüfung

Malformed bezeichnet einen Aufnahmefehler. Ein Pflichtfeld fehlt, ein CBOR-Typ ist falsch, eine Größe oder Anzahl überschreitet die Grenze, ein Schlüssel oder dasselbe Vierertupel kommt doppelt vor oder eine unbekannte Taste erscheint in der geschlossenen Map. Für cpb-refs sind Schlüssel außerhalb von 1 bis 4 keine ignorierbaren Erweiterungen. Ist ein Eintrag missgebildet, darf der Verifizierer keinen anderen Eintrag desselben Headers durch Teilerfolg zu Verified erklären. Das Signaturergebnis kann dennoch separat ausgegeben werden.

Unresolved setzt hinter der Syntax an. Der Verifizierer kann nicht genau einen vom Profil erlaubten Kontext auswählen. Oder der Kontext ist eindeutig, das Artefakt aber nicht erreichbar. Oder Kontext und Artefakt liegen vor, die Konstruktion kann jedoch nicht ausgeführt werden. Damit ist weder eine Abweichung bewiesen noch eine Bindung hergestellt.

Failed liegt weiter hinten in der Kette. Ein eindeutiger Kontext wurde gewählt, doch Algorithmus oder Darstellung passen nicht zu ihm, ein Bezeichner ist endgültig nicht zugewiesen oder verboten, oder der berechnete Digest des beschafften Artefakts weicht ab. Wer Failed und Unresolved zusammenlegt, kann später nicht mehr unterscheiden, ob Aufbewahrung, Implementierungsfähigkeit, normative Autorität oder der Inhalt selbst versagt hat.

Verified verlangt einen geschlossenen Ablauf: autorisierter Kontext, beschafftes Artefakt, vorgeschriebene Feldauswahl und Ausschlüsse, Kanonisierung, gegebenenfalls Domain Separation, Preimage-Kodierung, Hashing, Ergebnisdarstellung und Gleichheitsvergleich. Das Resultat bleibt eng: Dieses Artefakt ist unter diesem Kontext an diese Referenz gebunden.

Ein Hashname ersetzt kein Profil

Ein Digest-Kontext ist mehr als „SHA-256“. Er umfasst die einbezogenen und ausgeschlossenen Felder, das Kanonisierungsverfahren, eine mögliche Domain Separation, die Kodierung des Preimage und die Darstellung des Ergebnisses. Zwei gleiche Hex-Zeichenfolgen bilden nur dann eine belastbare Verbindung, wenn auch diese Konstruktionen kompatibel sind.

Die Auswahl beginnt bei type und gegebenenfalls purpose. Erlaubt das Profil für einen Typ nur einen Kontext, kann purpose fehlen; ist es vorhanden, muss es passen. Sind mehrere Kontexte zulässig, braucht jeder ein unterschiedliches, nicht leeres purpose, und die Referenz muss auswählen. Keine oder mehrere Übereinstimmungen führen zu Unresolved.

Nicht zulässig sind Heuristiken nach Listenreihenfolge, Digest-Länge, Payload-Form, Bibliotheksgewohnheit oder einem nicht normativ eingebundenen Registry-Snapshot. Eine Implementierung kann JCS nach RFC 8785 beherrschen und trotzdem nicht wissen, welche Felder eine Organisation ausschließt oder welche Profilversion die maßgebliche Autorität besitzt.

Auch ein abgeleiteter Bezeichner im Payload ist laut Entwurf nur ein Hinweis. Der Verifizierer muss ihn nach dem normativen Ausschlusssatz und allen vorgeschriebenen Transformationen selbst berechnen. Den vom Erzeuger gelieferten Wert in eine lokale Spalte namens „verified“ zu kopieren, verdoppelt die Behauptung; es erzeugt keinen zweiten Befund.

Ein Carrier verhindert opportunistische Vereinigung

Ein Profil entscheidet sich entweder für cpb-refs im geschützten Envelope oder für einen eigenen Carrier im Payload. Beides zusammen ist untersagt, auch wenn die Einträge verschiedene Artefakte betreffen. Findet ein profilbewusster Verifizierer beide Formen, erklärt er das Statement für nicht konform. Er vereinigt sie nicht und bevorzugt nicht den zuerst geparsten Carrier.

Ohne diese Grenze könnte eine Payload-Referenz scheinbar eine geschützte Referenz korrigieren, Wiederholung könnte als Abstimmung wirken und zwei Stacks könnten verschiedene Referenzgraphen erzeugen. Eine einzige Eingangsstelle schafft dagegen einen nachvollziehbaren Aufnahmebeleg.

In der Envelope-Variante steht cpb-refs ausschließlich im geschützten Header. Das Array enthält eine bis 64 Referenzen. Jede geschlossene Map bindet Integer-Schlüssel an type, optionales purpose, digest_alg und digest und unterliegt Größenlimits. Doppelte Schlüssel müssen vor der Konvertierung in ein Datenmodell erkannt werden, das sie womöglich verwirft. First-wins, last-wins, Teilerfolg und Wiederholungsgewichtung sind ausgeschlossen.

CDDL begrenzt das Datenmodell, nicht eine einzige CBOR-Serialisierung. Testvektoren dürfen für reproduzierbare Tests konkrete Bytes festhalten. Ein konformer Verifizierer darf eine andere gültige CBOR-Kodierung nicht allein deshalb ablehnen, weil sie nicht bytegleich mit dem Fixture ist. Das ergänzt die frühere Berichterstattung über mehrere CBOR-Kodierungen; hier steht jedoch der Übergang von struktureller Aufnahme zu externer Inhaltsbindung im Mittelpunkt.

Beschaffung und Darstellung haben eigene Fehler

32 rohe Bytes, 64 kleingeschriebene Hex-Zeichen und eine präfixierte Form sind unterschiedliche Darstellungen. Eine stille Umwandlung ist keine harmlose Kompatibilitätshilfe, sondern eine nicht deklarierte Protokolloperation. Sie ist nur erlaubt, wenn Spezifikation oder Profil sowohl die Konvertierung als auch die Vergleichsdarstellung festlegt.

Die Beschaffung des Artefakts besitzt außerdem eine eigene Zeitachse. Bei eindeutigem Kontext und unerreichbarem Objekt lautet das Ergebnis Unresolved. Netzfehler, Zugriffsverweigerung, eine Retentionslücke oder ein unbekanntes Abrufschema beweisen keinen falschen Digest. Ein späterer Versuch kann ohne Änderung am ursprünglichen Statement erfolgreich sein; beide Beobachtungen gehören mit Zeit und Ursache in das Audit.

Kennt eine Instanz den Kontext, kann die Konstruktion aber nicht ausführen, darf lokale Policy an einen fähigen Verifizierer delegieren, aufschieben, eine genehmigte Fähigkeit installieren oder ablehnen. Sie darf nicht nur das grüne Ergebnis eines anderen Dienstes übernehmen und dessen Eingaben, Version, Kontext und Receipt verwerfen.

Signatur, Aussteller, Referenz und Receipt

Weil cpb-refs im geschützten Header liegt, umfasst eine gültige COSE-Signatur seine Integrität. Daraus folgt nicht, dass der Schlüssel für den behaupteten Aussteller sprechen durfte. Revision 03 trennt deshalb Signature-Valid von Issuer-Authenticated; Letzteres hängt von lokaler Schlüssel- und Identitätspolitik ab.

Ein Signature-Valid Statement kann Unresolved- oder Failed-Referenzen enthalten. Umgekehrt repariert Digest-Gleichheit keine ungültige Signatur und authentisiert keinen Autor. API, Protokoll und Bedienoberfläche sollten Signaturergebnis und Referenzergebnisse als getrennte Felder ausgeben.

Ein SCITT-Receipt belegt wiederum eine andere Tatsache. RFC 9943 erlaubt einem Transparency Service, ein Statement zu registrieren und einen von einer verifizierbaren Datenstruktur beherrschten Receipt auszustellen. Vertrauen setzt die Prüfung unter einem vertrauenswürdigen Dienstschlüssel und die Auswertung der VDS-Kennung im geschützten Receipt-Header voraus. Die Registrierung beschafft das referenzierte Artefakt nicht und macht aus Unresolved kein Verified.

CPB beweist außerdem weder Ausstellerbefugnis noch Gültigkeit, Umfang, Frische oder Widerrufsstatus des Artefakts, weder semantische Akzeptanz noch Policy-Konformität oder Handlungsfreigabe. Das Artefaktprofil bestimmt die Bedeutung der Übereinstimmung. Die Organisation, die die Folgen trägt, entscheidet über den Einsatz.

Geschützt heißt nicht vertraulich

Ein geschützter COSE-Header ist nach erfolgreicher Signaturprüfung integer, aber nicht verschlüsselt. cpb-refs offenbart Typ, purpose, Algorithmus, Digest und die Struktur des Referenzgraphen. Stabile Werte ermöglichen Korrelation über Statements hinweg. Artefakte mit geringer Entropie können Wörterbuchangriffe zulassen.

Ist diese Sichtbarkeit unerwünscht, empfiehlt der Entwurf, cpb-refs wegzulassen oder einen vertraulichen, vom Profil definierten Payload-Carrier zu verwenden. Die Wahl muss vor der Verteilung fallen. Eine später ergänzte Zugriffskontrolle kann einen bereits verbreiteten Graphen nicht zurückholen.

IANA-Antrag und IANA-Zuweisung sind nicht dasselbe

Revision 03 beantragt ein Canonicalization Algorithm Registry und die Registrierung des COSE-Parameters cpb-refs. Das sind Anträge des Entwurfs, kein Nachweis vollzogener IANA-Zuweisungen. Experimente sollten Revision, vorläufige Werte und Migrationspfad festschreiben.

Heng Lus Prinzip der minimalen Anfangsspezifikation bietet dafür eine brauchbare Grenze. Die gemeinsame Schicht muss nur eine kleine reproduzierbare Tatsache transportieren: Ein deklarierter Kontext wurde auf ein beschafftes Artefakt angewandt und ergab dieses Vergleichsergebnis. Künftige Profile und lokale Autoritäten können Bedeutung, Aktualität und Nutzung bestimmen. Running Code ist dann primär, wenn es Bytes, Entscheidungen und Belege für eine Wiederholung bewahrt.

Grenzen und Unsicherheit

Diese Analyse behauptet keine IETF-Annahme, keinen SCITT-Konsens, keine IANA-Aktion, keine Produktunterstützung und keinen Einsatz. Instanzbeispiele im Anhang beweisen keine allgemeine Interoperabilität. Untersucht wurden weder Dienste, Produkte, Bibliotheken, Register, Vorfälle, Exploits, Benchmarks noch Verbreitungsraten.

Kanonisierung macht ein Payload auch nicht wahr oder sicher. Die vier Zustände beschreiben einen begrenzten Nachweis. Signatur, Identität, Receipt, Referenzbindung, Bewertung, lokale Entscheidung und beobachtete Wirkung bleiben getrennt, weil sie verschiedene Verantwortliche und Folgen haben.

Quellen