For both inclusion and consistency, the issue at hand is how to represent the data structures in CBOR and sign them, ideally in a way that the proof needs to be checked before the signature can verify.
The verification process in RFC9162 starts with assuming you have 2 merkle tree roots. https://datatracker.ietf.org/doc/html/rfc9162#section-2.1.4.2 It would be nice to hear from someone more familiar with Trillion, if checking consistency in their API also starts with 2 roots. When designing the COSE structures, we want to balance ease of implementation, with secure operation. Detaching is a technique we use to ensure the proof is checked first... At least in the implementation of consistency proofs I have done, and based on the RFC... It seems like you need to start with 2 roots... Which means you need to attach one or both as payloads. We also don't want to encourage many different COSE structures (attached and detached, or different ways to pack the proofs) for binary merkle trees compatible with CT... That will reduce interoperability, without improving security. OS On Fri, Sep 6, 2024, 7:48 AM Robin Bryce <[email protected]> wrote: > 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]
