Original text:
compatibility with deployed tree algorithms used in specific implementations.  3.1.  A Merkle root is signed with COSE_Sign1: Protected header parameters: <del> alg (label: 1): REQUIRED.  Signature algorithm.  Value type: int / tstr. tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value </del>  type: int / tstr. <del> A COSE profile of this specification may add further header parameters, for example to identify the signer or add a timestamp. </del>  <del> Envelope Payload: A Merkle tree root according to the tree alg. </del>  <del> The envelope payload can be detached, since it can be recomputed by the verifier. </del>  <del> Forcing a verifier to perform re-computation can prevent faulty implementations. </del>  One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. <del> 3.2. </del>  <del> RFC6962 defines a merkle audit path for a leaf in a merkle tree as the shortest list of additional nodes in the merkle tree required to compute the merkle root for that tree. </del>  <del> RFC9162 changed the term from "merkle audit path" to "merkle inclusion proof". </del>  <del> We prefer to use the term "inclusion path" to avoid confusion with Signed Inclusion Proof. </del>  <del> Editors note: We may want to move inclusion path representations to the specification that is required to register a new algorithm in the proposed tree algorithms registry. </del>  <del> Editors note: We recommend tree algorithm simple take the inclusion path as opaque bytes. </del>  <del> If the tree size and leaf index is known, then a compact inclusion path variant can be used: </del>  <del> Leaf index is also sometimes referred to as sequence number. </del>  <del> Otherwise, the direction each path step must be included: </del>  <del> FIXME bit vector: 0 right, 1 left, so no bit labels </del>  <del> For some tree algorithms, the direction is derived from the hashes themselves and both the index and direction can be left out in the path: </del>  <del> Presence of leaf index, and whether it is an input or an output is tree algorithm specific. </del>  <del> 3.3. </del>  <del> An inclusion proof is a CBOR array containing a merkle tree root, an inclusion path, extra data for the tree algorithm, and the payload. </del>  <del> 3.4. </del>  <del> A signed inclusion proof is a CBOR array containing a signed tree root, an inclusion path, extra data for the tree algorithm, and the payload. </del>  <del> "extra-data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  See sec-leaf- blinding-example for an example use case for this field to enable leaf blinding as described in sec-leaf-blinding. </del>  <del> 3.5. </del>  <del> 3.5.1. </del>  <del> This signed mulitple inclusion proof representation relies on 2 lists to enable proof of inclusion for multiple payloads in a given signed merkle root. </del>  <del> Note that the extra-data may be ommited if not required by the tree algorithm, and that leaf payloads may be detached. </del>  <del> TODO: refine multi-leaf variant of a signed inclusion proof like in: </del>  <del> https://github.com/transmute-industries/merkle-proof </del>  <del> https://transmute-industries.github.io/merkle-disclosure-proof- 2021/ </del>  <del> TODO: consider using sparse multiproofs, see https://medium.com/@jgm.orinoco/understanding-sparse-merkle- multiproofs-9b9f049e8f08 and https://arxiv.org/pdf/2002.07648.pdf </del>  <del> 4. </del>  <del> This document establishes a registry of merkle tree algorithms with the following initial contents: </del>  <del> Each tree algorithm defines how to compute the root node from a sequence of leaves each represented by payload and extra data.  Extra data is algorithm-specific and should be considered opaque. </del>  5. <del> TBD </del>  5.1.

Reviewer comments:
These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now

Revised text:
compatibility with deployed tree algorithms used in specific implementations. <ins> In case of RFC9162, this is defined in Section 2.1.1.  Definition of the Merkle Tree. </ins> 3.1. <ins> RFC6962 defines a merkle audit path for a leaf in a merkle tree as the shortest list of additional nodes in the merkle tree required to compute the merkle root for that tree. RFC9162 changed the term from "merkle audit path" to "merkle inclusion proof". We prefer to use the term "inclusion path" to avoid confusion with Signed Inclusion Proof. For tree algorithm "RFC9162_SHA256", we define the following compact encoding of an inclusion proof for a leaf: Leaf index is also sometimes referred to as sequence number. 3.2. </ins> A Merkle root is signed with COSE_Sign1: Protected header parameters:  <ins> alg (label: 1): REQUIRED.  Signature algorithm identifier.  Value </ins> type: int / tstr.  <ins> tree_alg (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. </ins>  <ins> crit (label: 2): REQUIRED.  Criticality marker.  Value type: [ +label ] </ins>  <ins> The criticality header MUST contain the tree_alg label. </ins>  <ins> The envelope payload MUST be computed by the process defined for the tree_alg. The envelope payload MUST be detached, and recomputed by the verifier. </ins> One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture.  <ins> 3.2.1. </ins>  <ins> 3.3. </ins>  <ins> 3.3.1. </ins>  <ins> 4. This document establishes a registry of merkle tree algorithms with the following initial contents: </ins>  <ins> Each tree algorithm defines: </ins>  <ins> How to compute a leaf from a payload and extra data, such as the current size of the tree. </ins>  <ins> How to compute the merkle root from a sequence of leaves. </ins>  <ins> How to compute an inclusion-proof for a leaf. </ins>  <ins> How to compute a consistency-proof for a leaf. </ins>  <ins> Each specification MUST define how to encode each of these parameters in CBOR, and map them to: </ins>  <ins> TBD_1 - (tree alg) </ins>  <ins> TBD_2 - (inclusion proof) </ins>  <ins> TBD_3 - (consistency proof) </ins>  <ins> See sec-rfc-9162-tree-alg-definition as an example. </ins>  <ins> 4.1. </ins>  <ins> This section defines how to map the data structures described in RFC9162 to the terminology defined in this document, using cbor and cose. </ins>  <ins> 4.1.1. </ins>  <ins> The integer identifier for "tree-alg" is 1.  The string identifier for "tree-alg" is "RFC9162_SHA256". </ins>  <ins> 4.1.2. </ins>  <ins> See RFC9162, 2.1.1.  Definition of the Merkle Tree. </ins>  <ins> 4.1.2.1. </ins>  <ins> The cbor representation of a merkle root is the bytestring represenation of MTH. </ins>  <ins> 4.1.2.2. </ins>  <ins> See RFC9162, 2.1.3.1.  Generating an Inclusion Proof. </ins>  <ins> The cbor representation of the inclusion proof is: </ins>  <ins> 4.1.2.3. </ins>  <ins> See RFC9162, 2.1.4.1.  Generating a Consistency Proof. The cbor representation of the consistency proof is: Editors note: tree-size-1, could be ommited, if an inclusion-proof is always present, since the inclusion proof contains, tree-size-1. </ins>  <ins> 4.2. In a signed inclusion proof, the previous merkle tree root, maps to tree-size-1, and is a detached payload.  In a signed consistency proof, the latest merkle tree root, maps to tree-size-2, and is an attached payload. </ins> 5.  <ins> See the privacy considerations section of: </ins> 5.1.