[SCITT] Re: SCITT Working Group adoption call for MMR Receipt Profile

[Konrad Gruszka <[e-mail]>]

Nicole, all,

We support adoption of draft-bryce-cose-receipts-mmr-profile-03 and are willing to review it. Two initial review notes follow.

Reasoning

it adds another verifiable data structure alongside CCF, designed for append-only logs on commodity storage
it reuses the COSE Receipts conventions we use for CCF, with vds 395, vdp 396 and a detached payload

Note 1, all_ones in Appendix A.4

as written, all_ones returns false for 1, 3, 7 and 15, because most_sig_bit returns a mask and is then used as a shift
index_height in Section 9.1 hit our iteration guard for all 127 tested nodes
with pos == (1 << bit_length(pos)) - 1, all 127 heights match the post-order layout, including the MMR(8) figure in Section 1
Should A.4 use that expression?

Note 2, an empty inclusion path

Section 4 defines inclusion-path as [ + bstr ]
Section 5 allows an empty path, where the node is itself the peak
Should the CDDL read [ * bstr ]?

Limits

heights compared with our own reconstruction of the post-order layout, not with an existing MMR implementation
no receipt was built or verified

Best regards,

Konrad Gruszka
b7n0de · Verified AI Work
https://b7n0de.com

Created with AI assistance. Reviewed and published by me.
https://b7n0de.com

Nicole Bates <nicolebates=[e-mail]> schrieb am Freitag, 25. September 2026 um 18:26:

> SCITT Working Group,
>
> The chairs are issuing a formal Working Group adoption call for [COSE Receipts for MMRs](https://www.ietf.org/archive/id/draft-bryce-cose-receipts-mmr-profile-03.html). The draft defines a COSE Receipt profile for ledgers based on post order traversal binary Merkle trees, commonly known as Merkle Mountain Ranges. (datatracker.ietf.org)
>
> The profile has been presented to the Working Group, received comments and review, and was updated in response to that feedback. The Working Group also discussed bringing the profile into SCITT during the IETF 126 session. (datatracker.ietf.org)
>
> This call is to determine whether the Working Group agrees that the document is in scope and should be adopted as the basis for continued SCITT work. Adoption does not indicate that the document is complete or ready for publication. Technical issues and design questions may continue to be addressed after adoption.
>
> Please respond to the mailing list by Friday, October 9, 2026, indicating:
>
> • Whether you support or oppose adoption
> • The reasoning for your position
> • Whether you are willing to review, contribute to, or implement the specification
>
> Technical comments are also welcome, but do not need to be resolved before expressing support for adoption.
>
> Thank you,
>
> Nicole Bates
>
> SCITT Working Group Cochair