Yes, Flelix is correct. It might be VDS specific what makes sense here though.
It might be the case that this is more awkward, or not always true, for trees where the MTH changes for every addition (the kind of tree in Felix's example). For Merkle Mountain Ranges (flat base trees) it is certainly true. Consistency proofs in that case are essentially just inclusion proofs from the peaks at the previous state. Recomputing the "roots" of those inclusion proofs is a required part of verification, and I think forcing it for signature verification is a good thing On Thu, 5 Sept 2024 at 17:43, Felix Linker <[email protected]> wrote: > > 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]>> wrote: > On Wed, Aug 7, 2024 at 9:36 AM Orie Steele > <[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] > To unsubscribe send an email to [email protected] > > _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
