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]
