Code change:
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

Related discussion:
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: <del> alg (label: 1): REQUIRED.  Signature algorithm.  Value type: int / tstr. tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value </del> <ins> alg (label: 1): REQUIRED.  Signature algorithm identifier.  Value </ins> 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> <ins> tree_alg (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. </ins> <del> Envelope Payload: A Merkle tree root according to the tree alg. </del> <ins> crit (label: 2): REQUIRED.  Criticality marker.  Value type: [ +label ] </ins> <del> The envelope payload can be detached, since it can be recomputed by the verifier. </del> <ins> The criticality header MUST contain the tree_alg label. </ins> <del> Forcing a verifier to perform re-computation can prevent faulty implementations. </del> <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. <del> 3.2. </del> <ins> 3.2.1. </ins> <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> <ins> 3.3. </ins> <del> RFC9162 changed the term from "merkle audit path" to "merkle inclusion proof". </del> <ins> 3.3.1. </ins> <del> We prefer to use the term "inclusion path" to avoid confusion with Signed Inclusion Proof. </del> <ins> 4. This document establishes a registry of merkle tree algorithms with the following initial contents: </ins> <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> <ins> Each tree algorithm defines: </ins> <del> Editors note: We recommend tree algorithm simple take the inclusion path as opaque bytes. </del> <ins> How to compute a leaf from a payload and extra data, such as the current size of the tree. </ins> <del> If the tree size and leaf index is known, then a compact inclusion path variant can be used: </del> <ins> How to compute the merkle root from a sequence of leaves. </ins> <del> Leaf index is also sometimes referred to as sequence number. </del> <ins> How to compute an inclusion-proof for a leaf. </ins> <del> Otherwise, the direction each path step must be included: </del> <ins> How to compute a consistency-proof for a leaf. </ins> <del> FIXME bit vector: 0 right, 1 left, so no bit labels </del> <ins> Each specification MUST define how to encode each of these parameters in CBOR, and map them to: </ins> <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> <ins> TBD_1 - (tree alg) </ins> <del> Presence of leaf index, and whether it is an input or an output is tree algorithm specific. </del> <ins> TBD_2 - (inclusion proof) </ins> <del> 3.3. </del> <ins> TBD_3 - (consistency proof) </ins> <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> <ins> See sec-rfc-9162-tree-alg-definition as an example. </ins> <del> 3.4. </del> <ins> 4.1. </ins> <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> <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> <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> <ins> 4.1.1. </ins> <del> 3.5. </del> <ins> The integer identifier for "tree-alg" is 1.  The string identifier for "tree-alg" is "RFC9162_SHA256". </ins> <del> 3.5.1. </del> <ins> 4.1.2. </ins> <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> <ins> See RFC9162, 2.1.1.  Definition of the Merkle Tree. </ins> <del> Note that the extra-data may be ommited if not required by the tree algorithm, and that leaf payloads may be detached. </del> <ins> 4.1.2.1. </ins> <del> TODO: refine multi-leaf variant of a signed inclusion proof like in: </del> <ins> The cbor representation of a merkle root is the bytestring represenation of MTH. </ins> <del> https://github.com/transmute-industries/merkle-proof </del> <ins> 4.1.2.2. </ins> <del> https://transmute-industries.github.io/merkle-disclosure-proof- 2021/ </del> <ins> See RFC9162, 2.1.3.1.  Generating an Inclusion Proof. </ins> <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> <ins> The cbor representation of the inclusion proof is: </ins> <del> 4. </del> <ins> 4.1.2.3. </ins> <del> This document establishes a registry of merkle tree algorithms with the following initial contents: </del> <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> <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> <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. <del> TBD </del> <ins> See the privacy considerations section of: </ins> 5.1.