Hi Robin, Thanks for your comments! Having read them, I am more confident that I correctly understand what the draft intends to say. I opened a PR addressing the editing comments from my review: Editing after review by felixlinker · Pull Request #29 · cose-wg/draft-ietf-cose-merkle-tree-proofs (github.com) <https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/pull/29>
About attaching/detaching payloads for consistency proofs. I don’t see how attaching one and detaching the other is consistent with RFC 9126. I don’t think that RFC 9126 mentions anything in this respect. The data structure for consistency proofs does not seem to include the root hash w.r.t. to which consistency is proven. The data structure matches exactly what is included in the unprotected header. Following the reasoning presented in 5.2.1, I think the payload should be detached in both cases. Best, Felix > On 6 Aug 2024, at 17:57, Robin Bryce <[email protected]> wrote: > > Hi Felix, > > These are just general responses intended to be helpful, but not a > comment on the document itself. I've raised PR’s for all of mine :-) > > >> Wouldn’t a proof of inclusion be computed w.r.t. to the current merkle tree >> root? > > That very much depends on the specific verifiable data structure used. > For RFC 9162, the inclusion proof is only verifiable against the root > of the tree state for which the proof was generated. The tree-size > identifies that state. > >> Still in 5.2.1, it says: "Detaching the payload forces verifiers to >> recompute the root from the inclusion proof signature […].“ I don’t >> understand what „signature“ refers to here. > > Is the confusion here the implication that there could be both a > receipt signature and a further signature over the inclusion proof ? > If so, I agree the removal of the word “signature” from that specific > sentence could be helpful. The receipt has a payload, the payload is > the root obtained by combining the entry with its inclusion proof. By > detaching the payload after signing, it is impossible to > “accidentally” accept a proof based on signature verification alone. > >> Beyond that, I was only wondering why the payload of a receipt of inclusion >> is detached but attached for a receipt of consistency. > > I also am not clear on that. I believe it’s just because that is how > RFC 9162 defined it that way and this specification is illustrating > how COSE encoding of an existing standard can be accomplished. I > support the idea that this draft encourages using detached payloads > where possible. > > I think it’s useful and good that COSE Receipts places that sort of > choice firmly in the hands of the authors of the VDS specification. I > think it is hard for this draft to offer prescriptive guidance on this > without “breaking into jail”. > > Cheers, > > Robin > > _______________________________________________ > 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]
