[SCITT] Re: Action requested: Focused Working Group Last Call on Section 4 of the CCF Profile

[Iman Schrock <[e-mail]>]

Hi Nicole and chairs,

Thanks for organizing this focused review. I worked through Section 4 and
reproduced the cases below. I support adding consistency receipts. I think
a small revision is needed to make the verifier's acceptance rules
unambiguous.

1. Multiple proofs: what does success cover?

Section 4.1 requires every proof to compute the same newer root. Section
4.2 only checks signatures against newer roots from proofs that match the
caller's older_root.

For example, take a valid signed receipt for R8 to R12 and append another
proof whose older root is not R8 and whose newer root is not R12. The
algorithm still accepts it. The R8-to-R12 proof remains sound; the receipt
as a whole no longer meets Section 4.1.

Could we align the algorithm with that requirement by checking that all
consistency proofs in the array compute one newer root, verifying the
signature against that root, and separately requiring at least one
older-root match? That would also need only one signature verification. If
the intent is to validate only the selected relation, could Section 4.1 say
that explicitly instead?

2. Is an unchanged tree an intended success case?

Section 4 specifies 0 < m < n. With a three-leaf tree, however, an anchor
at the third leaf and a single left sibling covering the first two leaves
produces (R3, R3). A genuine signature over R3 then passes the receipt
algorithm.

That establishes no growth, rather than a forged history. If strict
extension is intended, rejecting paths with no right sibling would exclude
this case. If unchanged trees should be accepted, could the definition and
examples say so explicitly?

Could Section 4 clarify whether the canonical-anchor MUST is a producer
requirement, since Section 4.2 says a verifier cannot check it without m?

Signed receipt-level vectors for these cases would help independent
implementations agree on the expected results. These look addressable
within Section 4, without redesigning the profile.

Best,
Team EMILIA

On Fri, 25 Sep 2026 17:44:45 +0000, Nicole Bates <nicolebates=
[e-mail]> wrote:

SCITT Working Group, The CCF Profile previously completed Working Group
Last Call, but the CCF specific consistency proof format and verification
algorithm now defined in Section 4 of draft 05 were not part of that
review. At the Area Director’s request, the chairs are conducting a focused
Working Group Last Call on Section 4 only. Please review Section 4 and
respond to the list by Friday, October 9, 2026, indicating whether: • You
support Section 4 and believe the document is ready to advance; or • You
believe changes to Section 4 are required before the document advances.
Please describe the specific changes or concerns. The other sections are
not being reopened because they were reviewed and accepted through the
previous Working Group Last Call. This focused confirmation is needed
before the document can continue through the publication process. Draft 04
discussed consistency proofs and the need to audit consistency between CCF
ledger states, but it did not define a CCF specific consistency proof
format or verification algorithm. Draft 05 adds that material in Section 4,
including: • The CCF consistency proof representation and canonical anchor
• Section 4.1, defining the COSE_Sign1 encoding and header requirements for
consistency receipts • Section 4.2, defining the consistency proof
verification algorithm Section 4 defines how a verifier can determine
whether an older CCF ledger state is consistent with a newer state,
complementing the inclusion proofs already reviewed by the Working Group.
Please consider whether the consistency proof definition is technically
correct, complete, and sufficiently clear for interoperable implementation.
Feedback would be particularly helpful on: • The proof representation and
canonical anchor definition • Computation of the older and newer Merkle
roots • Use of a previously trusted older root • COSE signature and
detached payload processing • Handling of multiple consistency proofs Draft
05: https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/
Diff from draft 04 to draft 05:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-scitt-receipts-ccf-profile-04&url2=draft-ietf-scitt-receipts-ccf-profile-05&difftype=--html
Thank you, Nicole For the SCITT chairs