Hi Jon, Thanks very much for the review. With respect to your review notes on https://www.ietf.org/archive/id/draft-bryce-cose-merkle-mountain-range-proofs-00.html
I believe I can sort that all out in short order. Absent any contradictory feedback on the list, I'll just go ahead and do that. Cheers, Robin On Tue, 12 Nov 2024 at 10:56, Jon Geater <[email protected]> wrote: > > As promised at the meeting last week I have reviewed both: > > https://www.ietf.org/archive/id/draft-bryce-cose-merkle-mountain-range-proofs-00.html > > https://www.ietf.org/archive/id/draft-birkholz-cose-receipts-ccf-profile-00.html > > This is my review of the Bryce draft profile, although it contains minor > references to the Birkholtz draft as I believe these and any future profiles > should share a roughly common structure. > > > REVIEW NOTES > > Overall very good, just a few comments: > > > > Small re-jig of the abstract and intro to make it clear it’s a profile of > cose-merkle-tree-proofs (I suggest you just copy the structure from Birkholtz > CCF draft) > > > > [Section 3]: “The integer identifier for this Verifiable Data Structure is 2” > > You can’t say that yet, we need to request assignment. This draft and CCF are > fighting it out over entries 2 and 3 😊 > > > > [Section 8.2]: Given that this is implementation defined and not relevant to > the cryptographic operations, is it actually required? What interoperability > promise is enabled by including these storage functions? > > > > [Section 8.3]: “Interior nodes in the MUST prefix the value provided” > > Typo/fragment? > > > > [Section 8.3.1]: “Editors note: How this draft accommodates hash alg agility > is tbd.” > > [Section 11]: “Editors note: Hash agility is desired. We can start with > SHA-256. […]” > > It would be good to have that decided and remove this note. In my opinion > hash agility is a virtue and readily accommodated by COSE/CBOR. Perhaps just > add an algorithm identifier in the appropriate spots in the structures so > that verifiers know what to do. That would enable hash agility within the > bounds of defined hash functions without the need for further > drafts/profiles. On the other hand the Birkholtz CCF draft has taken the > opposite path and explicitly fixed at SHA256 in its registry entry. Opinions > from the list? > > > > Security Considerations: Are you saying that there are really no additional > special security considerations to take into account when choosing this VDS > over other profile of cose-merkle-tree-proofs? Feels like that’s worth > explicitly stating rather than just sending people off to the normative > reference. > > > > [Appendix C]: This is interesting and highly validating of the idea but I > wonder if it’s necessary in the published profile. I suggest it be removed. > > > Jon > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
