Code change:
This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.

Related discussion:
text: 3.3. <del> 3.3.1. </del> 4. <del> This document establishes a registry of merkle tree algorithms with the following initial contents: </del> <ins> This document establishes a registry of verifiable data structure algorithms values for TBD_1, with the following initial contents: Each algorithm defines: How to identify the data structures supported. How to identify the proof types supported. How to produce and consume the proof types supported. </ins> <del> Each tree algorithm defines: </del> <ins> Each specification MUST define how to encode the algorithm and proof types in CBOR. </ins> <del> How to compute a leaf from a payload and extra data, such as the current size of the tree. </del> <ins> For example, RFC9162_SHA256 requires the following: </ins> <del> How to compute the merkle root from a sequence of leaves. </del> <ins> TBD_1, the verifiable data structure algorithm (binary merkle tree using sha256) </ins> <del> How to compute an inclusion-proof for a leaf. </del> <ins> TBD_2, the inclusion proof type (binary merkle tree using sha256, inclusion proof) </ins> <del> How to compute a consistency-proof for a leaf. </del> <ins> TBD_3, the consistency proof type (binary merkle tree using sha256, consistency proof) </ins> <del> Each specification MUST define how to encode each of these parameters in CBOR, and map them to: </del> <ins> See sec-rfc-9162-verifiable-data-structure-definition as an example. </ins> <del> TBD_1 - (tree alg) </del> <ins> Proof types are specific to their associated "verifiable data structure", for example, different merkle trees might support different representations of "inclusion proof" or "consistency proof". </ins> <del> TBD_2 - (inclusion proof) </del> <ins> Implementers should not expect interoperability accross "verifiable data structures", but they should expect conceptually similar properties across registered proof types. </ins> <del> TBD_3 - (consistency proof) </del> <ins> For example, 2 different merkle tree based verifiable data structures might both support proofs of inclusion.  Protocols requireing proof of inclusion ought to be able to preserve their functionality, while switching from one verifiable data structure to another, so long as both structures upport the same proof types. 5. This document establishes a registry of verifiable data structure proof types tags, with the following initial contents: 5.1. </ins> <del> See sec-rfc-9162-tree-alg-definition as an example. </del> <ins> Inclusion proofs provide a mechanism for a verifier to validate set membership. </ins> <del> 4.1. </del> <ins> The integer identifier for this "verifiable-data-structure-proof- type" is TBD_2.  The string identifier for this "verifiable-data- structure-proof-type" is "inclusion proof". sec-rfc9162-sha256-inclusion-proof provides a concrete example. 5.2. Consistency proofs provide a mechanism for a verifier to validate the consistency of a verifiable data structure. The integer identifier for this "verifiable-data-structure-proof- type" is TBD_3.  The string identifier for this "verifiable-data- structure-proof-type" is "consistency proof". sec-rfc9162-sha256-consistency-proof provides a concrete example. 5.3. </ins> This section defines how to map the data structures described in RFC9162 to the terminology defined in this document, using cbor and cose. <del> 4.1.1. </del> <ins> 5.3.1. </ins> <del> The integer identifier for "tree-alg" is 1.  The string identifier for "tree-alg" is "RFC9162_SHA256". </del> <ins> The integer identifier for this "verifiable-data-structure" is 1. The string identifier for this "verifiable-data-structure" is "RFC9162_SHA256". </ins> <del> 4.1.2. </del> <ins> 5.3.2. </ins> See RFC9162, 2.1.1.  Definition of the Merkle Tree. <del> 4.1.2.1. </del> <ins> 5.3.2.1. </ins> The cbor representation of a merkle root is the bytestring represenation of MTH. <del> 4.1.2.2. </del> <ins> 5.3.2.2. </ins> See RFC9162, 2.1.3.1.  Generating an Inclusion Proof. The cbor representation of the inclusion proof is: <del> 4.1.2.3. </del> <ins> 5.3.2.3. </ins> See RFC9162, 2.1.4.1.  Generating a Consistency Proof.