Summary

  • Revision 04 of the SCITT CCF receipt profile carries a leaf and a left/right path, but no explicit leaf index or tree size. For unbalanced trees, those direction bits do not uniquely recover the ordinal position.
  • This does not break inclusion verification. A verifier can still hash the candidate leaf along the supplied path and check the signed root. The narrower risk begins when a system treats that success as proof of sequence or position.

The smallest example is enough. Take the one-element path 1, read from a leaf toward the root. In a two-leaf tree it belongs to index 1. In trees of three, five and nine leaves, the same path belongs to indices 2, 4 and 8. Nothing about the bit changed. The tree around it did.

That result entered the public record during the IETF Last Call for CCF Profile for COSE Receipts, revision 04. The Datatracker record shows an IETF-stream Internet-Draft intended for Proposed Standard, submitted to the IESG and still “In Last Call”. The Last Call began on 24 August and ends on 7 September 2026. That status matters: this is precisely the stage at which a small semantic gap should be made visible, not evidence that the IETF has approved or rejected the text.

A correct root is not a coordinate

The profile follows a familiar Certificate Transparency-style tree construction. For a tree with more than one leaf, it splits at the largest power of two smaller than the tree size. Powers of two form balanced trees. Other sizes leave a smaller right-hand subtree.

The receipt's inclusion proof contains the candidate leaf and an array of sibling hashes. Each sibling is paired with a Boolean that says whether it is on the left. Section 3 says those values may be treated as the binary decomposition of the leaf index from leaf to root. That shortcut is exact for balanced power-of-two trees. It is not exact for all shapes created by the same split rule.

On 6 September, Henri Sirkkavaara corrected his own Last Call review after testing tree sizes 2 through 11. Every non-power-of-two size in that interval had at least one leaf whose path decoded to the wrong ordinal number. The three powers of two—2, 4 and 8—were exact.

Emek Can Dogru independently reproduced the result with a published eleven-line program. Extended from 2 through 1,024 leaves, only the ten powers of two were exact for every leaf. The other 1,013 tree sizes had at least one mismatch. The program itself is available as the frozen reproduction source.

The pattern is structural, not probabilistic. At size 3, ordinal leaf 2 yields a path that decodes to 1. At size 5, leaf 4 also decodes to 1. At size 9, leaf 8 does the same. A verifier holding only the path cannot know which surrounding tree produced it.

None of that prevents the operation defined in Section 3.2. Starting with the candidate leaf hash, the verifier combines it with each sibling on the stated side until it obtains a root. If that root is covered by the COSE signature, the candidate's inclusion is verified. The hash computation does not need to recover an ordinal coordinate in order to succeed.

The distinction is therefore exact: the proof can answer “is this candidate included under this signed root?” while failing to answer “which numbered leaf was it?” A cryptographic success becomes misleading only when a consumer silently substitutes the second question for the first.

Other profiles bind the missing coordinates

The omission is easier to see beside the standards that supplied the tree model. RFC 9162, Certificate Transparency version 2, verifies an inclusion proof with the tree size and leaf index as explicit inputs. RFC 9942 defines a COSE receipt profile for that tree and encodes both values. It says the index is relative to a particular tree size.

Those fields do more than help an implementation walk the path. They bind the coordinate system in which “position” has meaning. A leaf number without the tree size is incomplete, and a direction vector without either value may describe more than one ordinal location.

CCF deployments may possess additional context. Microsoft's CCF receipt-verification documentation shows receipts requested for a transaction identifier, and commit evidence may expose a full transaction ID. The SCITT profile also has an internal-evidence text string. But it permits a verifier to ignore that string and does not define it as a portable leaf-position grammar. Local knowledge can solve a local lookup; it does not make the proof self-describing across implementations.

This is also why the finding is not an attack. No one has demonstrated a forged signature, a hash collision or a candidate leaf accepted under the wrong root. Both reviewers called the issue non-blocking and continued to support publication. In his follow-up on remedies, Sirkkavaara concluded that path length alone still requires tree size and recommended an explicit index. That is a schema-meaning discussion, not a report of compromised code.

The control boundary sits after verification

Receipts are often fed into systems that attach consequences: software-release policy, evidence retention, transparency dashboards, audit trails or automated admission. Those systems may care only that an item was committed. If so, the current inclusion proof can be sufficient. The danger appears when “included” is promoted into “was the fifth entry”, “preceded another statement”, or “occupied this sequence number” without binding the inputs that make those claims true.

Heng Lu's Minimum Initial Specification offers the right scale for a remedy. Do not turn every receipt into a universal governance document. Define the smallest common assertion accurately, then allow local systems to adopt stronger claims when they need them. His account of reality layers explains the underlying discipline: a verified mathematical relation and an institution's narrative about order belong to different layers. Running-Code Primacy requires operators to preserve the values their verifier actually used rather than the meaning a dashboard later inferred.

The current profile can remain useful without pretending to carry a coordinate it does not contain. Call it an inclusion receipt when inclusion is all that was signed. If ordinal position is part of the claim, bind the tree size or an explicit index and verify that binding.

Sources

  1. IETF Datatracker document record
  2. IETF Datatracker event record
  3. CCF Profile for COSE Receipts, revision 04
  4. IETF Last Call announcement
  5. Henri Sirkkavaara's corrected review
  6. Emek Can Dogru's independent reproduction
  7. Henri Sirkkavaara's remedy follow-up
  8. Published reproduction source
  9. RFC 9162: Certificate Transparency Version 2.0
  10. RFC 9942: Merkle Tree Proofs using COSE Receipts
  11. RFC 9943: COSE Receipts
  12. CCF receipt verification documentation
  13. Heng Lu: Minimum Initial Specification
  14. Heng Lu: Reality Layers
  15. Heng Lu: Running-Code Primacy