Hi Henk, You actually can recompute the current root hash from a consistency proof. A consistency proof is conceptually similar to an inclusion proof but for an inner node and not a leaf. The consistency proof PROOF(4, D[7]) at https://www.rfc-editor.org/rfc/rfc9162#name-example shows a case where it is a proof of inclusion for an inner node. Thus, you can recompute the current root hash from a proof of inclusion and thus, you could detach the payload in both cases.
Hope my explanation was clear! Best, Felix > On 5 Sep 2024, at 17:58, Henk Birkholz <[email protected]> wrote: > > Hi all, > > there are two topics here, right? Not sure, if I'll manage to separate them > cleanly, though. > > (1) symmetry or no symmetry wrt either detached or attached payloads with > both proof types > (2) MUST or SHOULD > > to (1): > > The inclusion proof is typically the thing you get when adding a new hash > (MTH) as a root (tree head) by adding it to the append-only log, right? > Hence, for that remote operation it seems to be more useful to have the > payload detached. > > The consistency proof is typically the thing you get when you come back with > a previous receipt (old tree head) and check it with current root (current > tree head). Hence, the 2nd root needs to be attached, because there is no way > to compute it from the consistency proof. > > Is there anything that would contradict these assumptions? > > to (2): > > There is a good reason to go with "payload MUST be detached" wrt to inclusion > proof: you are forced to compute the root before signature can be verified. > The alternative, "payload SHOULD be detached" + "if attached, the hash MUST > be checked against the reconstructed root" would allow for more wiggle room. > > There is a good reason to go with "payload MUST be attached" wrt to > consistency proof (as mentioned above): you need it as you cannot derive the > 2nd root without it > > Is there anything that would contradict these assumptions? > > > Viele Grüße, > > Henk > > On 08.08.24 03:07, Orie Steele wrote: >> In the context of RFC9162 inclusion and consistency proofs, if there is >> consensus to make both payloads detached, I'm fine with MUST. >> In general, I don't think detached payloads should be required for all data >> structures and proof types. >> Each registered structure and proof type should be able to specify the COSE >> structures necessary to support it, and we should leave that specification >> to the documents that add to the registry. >> If we feel it's important to constrain registration, we can consider adding >> guidance to the designated experts, advising them to reject registrations >> that encourage the use of attached payloads, but I don't think that is >> necessary. >> Regards, >> OS >> On Wed, Aug 7, 2024, 4:02 PM A.J. Stein <[email protected] >> <mailto:[email protected]> <mailto:[email protected]>> >> wrote: >> On Wed, Aug 7, 2024 at 9:36 AM Orie Steele >> <[email protected] <mailto:[email protected]>> wrote: >> Felix and Robin, thank you for your comments on this document, >> and especially the pull requests! >> I'm fine recommending both payload's be detached for consistency >> if that is what the group recommends. >> I filed >> >> https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/issues/30 >> <https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/issues/30> to >> track these discussions. >> I hope others will comment on this issue. >> Are there any objections to recommending the payload be detached >> for consistency proofs? >> Just to be clear: should or must be detached for consistency proofs; >> should or must be detached for inclusion proofs? Per 5.2.1 inclusion >> proofs MUST have detached payloads not SHOULD. Did I understand >> correctly? I ask because your email is very clear, and the shorthand >> summary in the GitHub issue says "both inclusion and consistency >> proofs should have detached payloads" and I wanted to circle back >> here and confirm the only change would be consistency proofs, like >> your previous email said. >> For the record, I do not have objections but did a double take when >> reading this email and the issue #30 I left open in another browser >> tab earlier today. >> Thanks to those proposing changes and authors quickly accepting >> feedback with consensus. >> _______________________________________________ >> COSE mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
