> I don’t think that RFC 9126 mentions anything in this respect. Huh, I see that is correct, I must have imagined reading that! Ok, then I also think it makes more sense to require (or at least say SHOULD) detached for the consistency proof payload
On Wed, 7 Aug 2024 at 13:39, Felix Linker <[email protected]> wrote: > > 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) > > 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]
