Summary

  • An individual Internet-Draft published on 5 September 2026 measures one 165-octet COSE_Sign1 object under every combination of six tested CBOR framing choices.
  • The experiment produced 64 distinct byte sequences and 64 distinct data-hash values, but only one 109-octet Sig_structure. The same signature therefore verified in every case.
  • A stock CBOR decoder rejected none of the inputs. A decode-and-re-encode cycle silently turned 31 of them into the starting representation, showing how identifier evidence can change without a parsing error.
  • I independently ran the published script against byte-identical artifacts and reproduced the 64 hashes, zero rejections and 31 normalizations. The test is not exhaustive and is not evidence of a deployed incident.
  • The narrow governance remedy is to define which octets an identifier names and preserve their custody. A valid signature, a decoded object and a reproducible wire-byte hash are three different claims.

The signature and the identifier observe different things

The starting object, called A in the measurement draft, is a 165-octet COSE_Sign1 message. Its signature is calculated over the COSE Sig_structure: a construction that incorporates the protected header and payload along with the prescribed context. It does not incorporate every representational choice in the surrounding CBOR container.

The proposed data-hash has a different field of view. It is a digest of the complete octet sequence used to convey the signed statement. Change the container's encoding while preserving the values inside it, and the signed structure can remain identical while the wire bytes—and therefore their digest—change.

That distinction is useful, not pathological. A signature answers whether the covered content verifies under a key. A wire-byte hash gives a client something exact to fetch, compare and address. Trouble begins only when an implementation calls both results “the same statement” without saying which representation is authoritative.

Six switches generate 64 byte identities

The experiment decodes A once and re-emits the same data item while toggling six binary choices. CBOR tag 18 is present or absent. The outer array uses a definite or indefinite length. The unprotected-header map does the same. The protected-header, payload and signature byte strings are each emitted whole or in chunks.

No element value changes. Six two-way choices yield 64 combinations. The published artifact records 64 different byte sequences, ranging from 164 to 170 octets, and 64 different SHA-256 values with no collisions. Across them all, there is one 109-octet Sig_structure with one digest. The signature does exactly what RFC 9052 asks it to do; it is the meaning assigned to the outer bytes that requires discipline.

The number 64 is a measured floor, not the size of the whole class. The draft did not vary integer-width encodings or map-key order, both of which sit within CBOR's broader representation space described by RFC 8949. A policy that merely forbids the six forms somebody has already noticed cannot prove that it has closed the remaining space.

A parser can erase the evidence politely

All 64 encodings were accepted by the stock decoder used in the reported run. More revealingly, 31 non-starting inputs emerged from a decode-and-re-encode cycle as A's exact bytes. There was no rejection to alert an operator that the received representation had disappeared.

That creates a mundane failure path. A service receives bytes B, computes identifier hash(B), decodes B, and stores only the library's serialization A. Later it can verify the signature and reconstruct the same semantic object, but it cannot reproduce hash(B) from the bytes it retained. If the digest is also a lookup key, deduplication key or the target of another attestation, the gap crosses from serialization into governance.

“Silent” here describes software behaviour, not malicious intent. The experiment neither surveys deployed Transparency Services nor proves that any named implementation follows this storage path. It simply demonstrates that successful parsing is not evidence of byte preservation.

The result is reproducible and deliberately narrow

The draft publishes the source vector, the 64-case artifact and a minting script. I retrieved the script through the GitHub Contents API after the raw endpoint failed, placed it with byte-identical copies of the two JSON artifacts in a temporary directory, and ran it in an isolated environment. It reproduced A's SHA-256 value 8595e4a4c8b93e7b1b7b798dc302a2b7d2890021f7eff372d79b32f78867e4ac, 64 distinct data hashes, zero decoder rejections and 31 normalizations.

The independent run used cbor2 5.7.1, whereas the draft records 6.1.3 on CPython 3.13 and macOS arm64. Agreement across those two stated environments strengthens the central count; it does not constitute an interoperability survey. It also does not change the institutional status. Datatracker describes the text as an individual submission with no IETF endorsement or formal standing. The document itself specifies nothing and proposes no normative wording.

No signature was forged. No digest collided. No cryptographic primitive failed. The tested messages were not a live Transparency Service and the result says nothing about incident frequency. Those boundaries are part of the finding, not caveats to be discarded after the headline.

Exact-as-registered wording is discussion, not a decision

The measurement entered a live discussion around the CCF Profile for COSE Receipts, then in IETF Last Call. In a 5 September message, Nicholas Templeman supported advancement while suggesting that data-hash be defined over the octets “as registered,” not over a later re-serialization. He explicitly presented the point as non-blocking.

That is participant input, not adopted text and not IETF consensus. The current SCITT Reference APIs draft and CCF profile remain works in progress. RFC 9943 supplies the published SCITT architecture, including the roles of Signed Statements, registration and Receipts, but it does not turn every later mailing-list proposal into a requirement.

There is also relevant prior individual work. Canonical Payload Binding revision 02 defines an as-transmitted option: no canonicalization, with the exact octet sequence as the pre-image. Its jcs-n and cde-n alternatives are marked Withdrawn. This establishes that exact-byte binding was already on the table; it does not make that individual draft an adopted SCITT rule.

The measured draft's useful contribution is therefore not ownership of a fix. It gives decision-makers a concrete scale for the representation class and a reproduction path against which proposed wording can be tested.