[SCITT] Re: Last Call: <draft-ietf-scitt-receipts-ccf-profile-04.txt> (CCF Profile for COSE Receipts) to Proposed Standard

[Henri Sirkkavaara <[e-mail]>]

Emek,

Thank you for running it, and for pinning the script.

Your n = 2, 3, 5, 9 numbers settle the remedy choice I left to the authors. The path "1" of length one lands on index 1, 2, 4 and 8 in trees of 2, 3, 5 and 9, each being the right child of the split at the largest power of two below n. So the pair addresses a leaf only once the verifier already holds n, and the proof carries neither n nor the index today.

That makes the two remedies unequal. The path-length rule needs the tree size shipped with the proof. The index needs nothing added. So I withdraw the first and recommend the second.

Still non-blocking, and my support for -04 as Proposed Standard stands.


On Sunday, September 6th, 2026 at 14:42, Emek Can Dogru <[e-mail]> wrote:

> Henri,
> 
> Finding 1 reproduces from the text of -04 alone: sizes 2 to 11 exactly
> as you corrected them, and over sizes 2 to 1024 only the ten powers of
> two decode every leaf.
> 
> One measurement bears on the remedy. The (bits, length) pair identifies
> a leaf only when the verifier knows n: the one-element path "1" is
> index 1 in a tree of 2, index 2 in a tree of 3, index 4 in a tree of 5
> and index 8 in a tree of 9. The proof carries neither n nor the index,
> and the payload is the root. So the path-length rule needs the tree
> size to travel with the proof; carrying the index needs nothing added.
> 
> Script, eleven lines, pinned at
> https://gist.github.com/dogrucanemek-alt/a48eb01ae668314fbad889ff69e1e84c
> 
> Nothing here blocks -04.
> 
> Emek Can Dogru
> 
> On Sun, Sep 6, 2026 at 2:14 PM Henri Sirkkavaara <[e-mail]> wrote:
> > All,
> >
> > A correction to my own review of 4 September first. In finding 1 I listed n = 3, 5, 6, 7 and 11 as the sizes where the path bits decode to the wrong index. That enumeration is incomplete: 9 and 10 fail as well. Rechecking 2 through 11 against the definitions as written, every non-power-of-two size has at least one leaf that decodes wrong, and 2, 4 and 8 decode exactly. So the condition is that index recovery holds when the number of transactions is a power of two, and not otherwise.
> >
> > Then one ask, and it sits where the thread already is rather than off to the side. This week has settled that the document's defect class is unnamed preimages: Nicholas on internal-evidence, Konrad's sentence binding the octets of the Signed Statement as registered, Anton's as-transmitted registering the same rule.
> >
> > Finding 4 in my review is that defect one layer further out, and it is the largest instance in the document. Section 2.1 defines MTH over "a list of serialized transactions (as byte strings)" and gives MTH({d[0]}) = HASH(d[0]). Section 3.2 computes the leaf as HASH(internal-transaction-hash || HASH(internal-evidence) || data-hash). Nothing in the document says that d[i] is that concatenation. A builder working from 2.1 and a verifier working from 3.2 can produce different roots, and 2.1 is the definition that looks authoritative, because it is the one labelled Merkle Tree Hash.
> >
> > If the group is naming preimages before this document leaves, that is the one to name.
> >
> > On finding 1, I left the choice of remedy to the authors and will now say which I would take. Make the path length part of the decoding rule, or carry the index in the proof. Attaching the power-of-two condition to the sentence documents the hazard and leaves it in place, and an application whose author does not read that sentence still gets a wrong index and no error.
> >
> > Still non-blocking, and my support for -04 as Proposed Standard stands.
> 
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 

Henri Sirkkavaara
Vaara - Runtime execution layer for AI agents
Built to see over the noise.
vaara.io
Helsinki, Finland