Summary

  • An individual Informational Internet-Draft announced on 5 September 2026 tested one COSE_Sign1 statement under six binary CBOR framing choices. It is a measurement, not an RFC, an IETF consensus position or a proposed change to protocol wording.
  • The experiment produced 64 accepted byte sequences and 64 different data-hashes, but only one Sig_structure. The same signature remained valid in every case; no signature was forged and no hash collision was found.
  • Thirty-one variants silently re-encoded to one canonical form when read. A service that discards the received octets and retains only its re-serialization can publish an identifier it later cannot reproduce.

The verifier said yes. The lookup said absent.

Both answers could be locally correct. A service received a signed CBOR statement, decoded it and verified its COSE signature. Another component computed an identifier over the statement's bytes as they crossed the wire. The first component saw the same signed meaning after re-encoding. The second saw different octets and therefore a different hash.

That split is the subject of a new eight-page Internet-Draft by Nicholas Templeman. The I-D announcement appeared on 5 September 2026. Its status matters: this is an individual Informational submission that specifies nothing and proposes no wording. Its value is narrower and more practical. It measures a failure class that can hide inside a successful decode and a successful signature check.

Two identities occupy the same object

RFC 9052 defines the COSE signing input as a Sig_structure. For COSE_Sign1, that structure includes the signature context, protected attributes, external authenticated data and payload. It does not include every representational choice in the outer CBOR container.

RFC 8949 deliberately permits more than one serialization for some CBOR data-model values. An array may have a definite or indefinite length. A byte string may be whole or chunked. A tag may be present or absent where the surrounding profile accepts both. These choices can alter the wire bytes without altering the decoded item used to reconstruct the signing input.

So the system carries two legitimate but non-interchangeable identities. Signature identity asks whether the protected signing input verifies under a key and algorithm. Wire identity asks which exact octet sequence a service received, stored, indexed or served. A green answer to the first question does not choose the bytes for the second.

The draft's starting object, A, was 165 octets. The test changed six binary framing choices: CBOR tag 18; the outer array's length form; the unprotected-header map's length form; and whole-versus-chunked encoding for the protected header, payload and signature byte strings. Element values did not change.

Six binary switches create 64 combinations. Every combination decoded. Every one reconstructed the same 109-octet Sig_structure. One signature therefore verified across the entire measured set.

Yet the 64 wire sequences, ranging from 164 to 170 octets, produced 64 distinct SHA-256 data-hashes. That is not a collision. It is the expected result of hashing different input bytes.

Sixty-four is a floor, not a catalogue

The draft's most useful number is not 64 by itself. It is the relationship between six independent freedoms and the size of the resulting space. A rule that bans one known variant can still leave dozens of combinations. The measurement did not vary integer-width representation or map-key ordering, so it does not claim to enumerate every possible framing.

This limits the policy response. A service cannot establish stable identity merely by adding “reject an untagged object” or “reject an indefinite outer array” to a checklist. Enumeration responds to examples; a byte boundary responds to the class.

The published framing-space artifact records inputs, variants, results and the minting script. A separate data-hash vector supplies the starting bytes. That makes the 64-result claim reproducible rather than rhetorical. It does not make the measurement a census of implementations or proof that a deployed service is vulnerable.

The environment is stated: cbor2 6.1.3 on CPython 3.13, macOS arm64. The draft also credits an independent recomputation of one framing axis on a different platform with a different reader and no COSE library. Those facts strengthen the evidence for the mechanism. They still do not justify a prevalence figure.

The dangerous operation looks like housekeeping

Thirty-one of the 64 encodings were silently transformed into A's canonical bytes by a decode-then-re-encode cycle. Nothing crashed. The decoder rejected none. The signature still verified. A normal-looking data ingestion step therefore destroyed the distinction between “bytes received” and “bytes I would emit”.

Suppose a receiving service hashes the statement and returns that data-hash to a client. It then decodes the statement and stores only its library's preferred serialization. Later, an API retrieves the stored statement and recomputes the hash. For 31 measured variants, the service can produce A rather than the bytes it originally accepted. The published identifier no longer names its retained representation.

That is not cosmetic drift if data-hash is a lookup key, deduplication key, index, receipt coordinate or subject of a later attestation. The issuer and verifier can both validate the same signature while one cannot find the other's identifier. An adversary who can affect framing may create unexpected keys or apparent absence without changing the signed payload and without defeating any primitive.

The running system therefore needs an evidence-preservation boundary before parsing. Retain the exact incoming octets. Compute the wire identifier over those immutable bytes. Record where they came from, when they arrived and which named byte production the identifier covers. Decode and normalize only into a separate representation. Never let the normalized copy overwrite the evidence copy.

The alternative can be a protocol-defined deterministic representation, but only if the protocol actually selects it and implementations enforce it. RFC 8949 offers deterministic-encoding requirements as a base; the generic existence of those rules does not retroactively make every accepted CBOR input deterministic.

The current as-transmitted profile draft takes the byte-boundary route: no canonicalization, and a required selector naming the exact format-defined byte sequence. That work predates this measurement and is also an individual draft. The new paper measures why such precision matters; it does not confer standards standing on the proposed profile.

Signature, storage, registration and authority need separate receipts

The SCITT architecture in RFC 9943 separates signed statements, transparency services, receipts and later appraisal. Current SCITT reference API and CCF receipt profile work give data-hash a practical role in registration and retrieval. That makes byte identity operationally consequential, but it does not collapse the rest of the chain.

A retained octet sequence can prove what one component received. A valid signature can prove integrity of the specified signing input under a key. It does not, by itself, prove that the key belongs to the claimed actor or that the actor was authorized; RFC 9052 assigns those checks to the application. A transparency-service receipt can prove registration under that service's rules. It does not prove the statement's semantic truth, freshness or fitness for a later decision.

Heng Lu's reality-first editorial discipline is useful because no villain is required here. A permissive decoder and a preferred encoder may each behave exactly as designed. The structural failure appears when their outputs are treated as the same evidence.

His running-code primacy moves the review from abstract format compliance to the deployed path: Which component first possesses the raw request body? Does it hash before decoding? Does a queue carry bytes or a parsed object? Can storage retrieve the original sequence? Do logs bind the returned identifier to the retained bytes?

The distinction between technical capability and authority completes the control map. A library can accept, repair and emit CBOR. That capability does not authorize it to redefine the identity a client was given. Operational authority belongs with the component that can freeze ingestion, preserve evidence, choose the named byte boundary and reconcile every later reference to it.

The lesson is not that canonicalization is bad or that wire bytes are always the right semantic identity. It is that the identity rule must be explicit, and the evidence needed to reproduce it must survive. When a system says “this hash names the statement as transmitted”, parsing is already too late to decide what “as transmitted” meant.

Sources