jiebi/TextFlow huggingface dataset:
Original text:
inclusion proof which increases the size of multiple payload signed inclusion proofs.  6. <del> TBD </del>  6.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:
inclusion proof which increases the size of multiple payload signed inclusion proofs. <ins> Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. </ins> 6.  <ins> See the privacy considerations section of: </ins> 6.1.
Original text:
7.1.1. <del> IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point. </del>  Name: tree_alg <del> Label: TBD </del>  Value type: tree_alg

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:
7.1.1.  <ins> This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Algorithm Parameters' registries in the 'Standards Action With Expert Review category. 7.1.1.1. </ins> Name: tree_alg  <ins> Label: TBD_1 </ins> Value type: tree_alg
Original text:
Description: Merkle tree algorithm used to produce a COSE Sign1 payload. <del> 7.2. </del>  <del> IANA will be asked to add a new registry "TBD" to the list that appears at IANA Assignments [1]. </del>  <del> The rest of this section defines the subregistries that are to be created within the new "TBD" registry. </del>  <del> 7.2.1. </del>  IANA will be asked to establish a registry of tree algorithm identifiers, named "Tree Algorithms" to be administered under a

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:
Description: Merkle tree algorithm used to produce a COSE Sign1 payload.  <ins> Name: inclusion_proof Label: TBD_2 Value type: inclusion_proof Value registry: See Description: Merkle tree inclusion proof for the given tree_alg. </ins>  <ins> Name: consistency_proof </ins>  <ins> Label: TBD_2 </ins>  <ins> Value type: consistency_proof Value registry: See Description: Merkle tree consistency proof for the given tree_alg. 7.1.2. </ins> IANA will be asked to establish a registry of tree algorithm identifiers, named "Tree Algorithms" to be administered under a
Original text:
Reference: Where this algorithm is defined Initial contents: Provided in <del> 8.  References 8.1.  URIs [1] https://www.iana.org/assignments/ </del>

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:
Reference: Where this algorithm is defined Initial contents: Provided in
Original text:
One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. <del> 3.2.1. </del> 3.3. 3.3.1.

Reviewer comments:
Feedback gathered from URL
Consider attempting better CDDL by applying URL We would like some time to discuss this draft at IETF 117: URL https://ietf-URL We've made several changes that were requested at 116. We provide a sample implementation demonstrating how to use RFC9162 tree algorithm with COSE Sign1 to create signed "inclusion" and "consistency" proofs. We updated the draft to support registration of other tree algorithms which can be specified in separate documents. If there are other changes folks would like to see, we are happy to try to get them in before the cut off date. Regards, OS ORIE STEELE Chief Technology Officer www.transmute.industries

Revised text:
One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture.  3.3. 3.3.1.
Original text:
 5.1. In cases where a single merkle root and multiple inclusion paths are

Reviewer comments:
Feedback gathered from URL
Consider attempting better CDDL by applying URL We would like some time to discuss this draft at IETF 117: URL https://ietf-URL We've made several changes that were requested at 116. We provide a sample implementation demonstrating how to use RFC9162 tree algorithm with COSE Sign1 to create signed "inclusion" and "consistency" proofs. We updated the draft to support registration of other tree algorithms which can be specified in separate documents. If there are other changes folks would like to see, we are happy to try to get them in before the cut off date. Regards, OS ORIE STEELE Chief Technology Officer www.transmute.industries

Revised text:
<ins> Although the word transparency implies to some degree read access, it is important to note that transparency logs might include sensitive information. Depending on the leaf algorithm used, a log operator might be able to count unique entries. In the case that a leaf is produced from a cose sign 1 envelope, adding information to the unprotected header can be used to produce a unique leaf entry. However, this could impact privacy, and some transparency service operators might prefer only integrity protected content be made transparent. </ins> 5.1. In cases where a single merkle root and multiple inclusion paths are
Original text:
6. <del> See the privacy considerations section of: </del> 

Reviewer comments:
Feedback gathered from URL
Consider attempting better CDDL by applying URL We would like some time to discuss this draft at IETF 117: URL https://ietf-URL We've made several changes that were requested at 116. We provide a sample implementation demonstrating how to use RFC9162 tree algorithm with COSE Sign1 to create signed "inclusion" and "consistency" proofs. We updated the draft to support registration of other tree algorithms which can be specified in separate documents. If there are other changes folks would like to see, we are happy to try to get them in before the cut off date. Regards, OS ORIE STEELE Chief Technology Officer www.transmute.industries

Revised text:
6.  <ins> See the security considerations section of: </ins>
Original text:
Abstract <del> This specification describes three CBOR data structures for primary use in COSE envelopes.  A CBOR encoding of Merkle Roots for use in COSE payloads.  A CBOR encoding of Inclusions Proofs for use in COSE unprotected headers.  A CBOR encoding of Consistency Proofs for use in COSE unprotected headers. </del>  1. <del> Merkle trees are verifiable data structures that support secure data storage, through their ability to protect the integrity of batches of documents or collections of statements. A merkle proof is a path from a leaf to a root in a merkle tree. Merkle proofs can be used to prove a document is in a database (proof of inclusion), or that a smaller set of statements are contained in a large set of statements (selective disclosure proofs). Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications. Differences in the representation of a merkle tree, merkle leaf and merkle inclusion proof can increase the burden for implementers, and create interoperability challenges. This document describes the three data structures necessary to use merkle proofs with COSE envelopes. </del>  1.1.

Reviewer comments:
This PR aligns the abstract and intro with generalizing away from specific merkle trees
LGTM

Revised text:
Abstract  <ins> This specification describes verifiable data structures and associated proof types for use with COSE.  The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. </ins> 1.  <ins> Merkle trees are one of many verifiable data structures that enable tamper evident secure information storage, through their ability to protect the integrity of batches of documents or collections of statements. Merkle trees can be constructed from simple operations such as concatenation and digest via a cryptographic hash function, however, more advanced constructions enable proofs of different properties of the underlying verifiable data structure. Verifiable data structure proofs can be used to prove a document is in a database (proof of inclusion), that a database is append only (proof of consistency), that a smaller set of statements are contained in a large set of statements (proof of disclosure, a special case of proof of inclusion), or proof that certain data is not yet present in a database (proofs of non inclusion). Differences in the representation of verifiable data structures, and verifiable data structure proof types, can increase the burden for implementers, and create interoperability challenges for transparency services. This document describes how to convey verifiable data structures, and associated proof types in COSE envelopes. </ins> 1.1.
Original text:
4.1. <del> For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is computed as: with extra data defined as: 4.2. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. 4.3. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is computed as: with extra data defined as: 4.4. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. 4.5. </del>  For n > 1 inputs, let k be the largest power of two smaller than n.

Reviewer comments:
For exploration purposes, the document had a number of tree algorithms that are not specified in RFCs or similar. This PR removes them again, transferring them to PRs for further evaluation.
I'm good to merge this from a process standpoint I still hope we can document these in some acceptable way for IETF.

Revised text:
4.1.  <ins> The "RFC9162_SHA256" tree algorithm uses the Merkle tree definition from RFC9162 with SHA-256 hash algorithm. </ins> For n > 1 inputs, let k be the largest power of two smaller than n.
Original text:
Abstract <del> This specification describes three CBOR data structures for primary use in COSE envelopes.  A CBOR encoding of Merkle Roots for use in COSE payloads.  A CBOR encoding of Inclusions Proofs for use in COSE unprotected headers.  A CBOR encoding of Consistency Proofs for use in COSE unprotected headers. </del>  1. <del> Merkle trees are verifiable data structures that support secure data storage, through their ability to protect the integrity of batches of documents or collections of statements. </del>  <del> A merkle proof is a path from a leaf to a root in a merkle tree. </del>  <del> Merkle proofs can be used to prove a document is in a database (proof of inclusion), or that a smaller set of statements are contained in a large set of statements (selective disclosure proofs). </del>  <del> Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </del>  <del> The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications. Differences in the representation of a merkle tree, merkle leaf and merkle inclusion proof can increase the burden for implementers, and create interoperability challenges. This document describes the three data structures necessary to use merkle proofs with COSE envelopes. </del>  1.1.

Reviewer comments:
This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions

Revised text:
Abstract  <ins> This specification describes verifiable data structures and associated proof types for use with COSE.  The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. </ins> 1.  <ins> Merkle trees are one of many verifiable data structures that enable tamper evident secure information storage, through their ability to protect the integrity of batches of documents or collections of statements. </ins>  <ins> Merkle trees can be constructed from simple operations such as concatenation and digest via a cryptographic hash function, however, more advanced constructions enable proofs of different properties of the underlying verifiable data structure. </ins>  <ins> Verifiable data structure proofs can be used to prove a document is in a database (proof of inclusion), that a database is append only (proof of consistency), that a smaller set of statements are contained in a large set of statements (proof of disclosure, a special case of proof of inclusion), or proof that certain data is not yet present in a database (proofs of non inclusion). </ins>  <ins> Differences in the representation of verifiable data structures, and verifiable data structure proof types, can increase the burden for implementers, and create interoperability challenges for transparency services. </ins>  <ins> This document describes how to convey verifiable data structures, and associated proof types in COSE envelopes. </ins> 1.1.
Original text:
is important to note that transparency logs might include sensitive information. <del> Depending on the leaf algorithm used, a log operator might be able to count unique entries. </del>  <del> In the case that a leaf is produced from a cose sign 1 envelope, </del>  adding information to the unprotected header can be used to produce a <del> unique leaf entry. </del>  However, this could impact privacy, and some transparency service operators might prefer only integrity protected content be made

Reviewer comments:
This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions

Revised text:
is important to note that transparency logs might include sensitive information.  <ins> Depending on the verifiable data structure used, a service provider might be able to count unique entries. </ins>  <ins> In the case that an entry is produced from a cose sign 1 envelope, </ins> adding information to the unprotected header can be used to produce a  <ins> unique entry. </ins> However, this could impact privacy, and some transparency service operators might prefer only integrity protected content be made
Original text:
Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm.  7. See the security considerations section of:

Reviewer comments:
This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions

Revised text:
Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. <ins> 6.1.1. Implementers wishing to leverage multiple inclusion proofs to support selective disclosure, can prepend each payload with extra data before computing the inclusion proof, where extra data is a cryptographic nonce. </ins> 7. See the security considerations section of:
Original text:
8.1.1.1. <del> Name: verifiable_data_structure </del>  <del> Label: TBD_1 </del>  <del> Value type: verifiable_data_structure </del>  Value registry: See <del> Description: Merkle tree algorithm used to produce a COSE Sign1 payload. </del>  <del> Name: inclusion_proof </del>  <del> Label: TBD_2 </del>  <del> Value type: inclusion_proof </del>  Value registry: See <del> Description: Merkle tree inclusion proof for the given verifiable_data_structure. </del>  <del> Name: consistency_proof </del>  <del> Label: TBD_2 </del>  <del> Value type: consistency_proof </del>  Value registry: See <del> Description: Merkle tree consistency proof for the given verifiable_data_structure. </del>  8.1.2.

Reviewer comments:
This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions

Revised text:
8.1.1.1.  <ins> Name: verifiable-data-structure </ins>  <ins> Label: TBD_1 (requested assignment 12) </ins>  <ins> Value type: int / tstr </ins> Value registry: See  <ins> Description: Tag indicating the Verifiable Data Structure, see sec-generic-verifiable-data-structures. </ins>  <ins> Editors note: Authors are discussing how to avoid flooding the cose header parameters registry with new proof types. </ins>  <ins> Name: inclusion-proof </ins>  <ins> Label: TBD_2 (requested assignment 13) Value type: bstr </ins> Value registry: See  <ins> Description: Tag indicating the "inclusion" Proof Type, see sec- generic-inclusion-proof. </ins>  <ins> Name: consistency-proof </ins>  <ins> Label: TBD_2 (requested assignment 14) </ins>  <ins> Value type: bstr </ins> Value registry: See  <ins> Description: Tag indicating the "consistency" Proof Type, see sec- generic-consistency-proof. </ins> 8.1.2.
Original text:
Reference: Where the algorithm is defined Initial contents: Provided in 

Reviewer comments:
This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions

Revised text:
Reference: Where the algorithm is defined Initial contents: Provided in <ins> 9.  References 9.1.  URIs [1] https://github.com/ietf-scitt/draft-steele-cose-merkle-tree- proofs/issues/21 [2] https://github.com/ietf-scitt/draft-steele-cose-merkle-tree- proofs/issues/21 </ins>
Original text:
where "d(0)" is the payload.  This algorithm takes no extra data.  5. TBD

Reviewer comments:
Informal references: URL URL TODO: Add CCF reference to Merkle tree definition (including details on the leaves). Change target branch to after is merged.

Revised text:
where "d(0)" is the payload.  This algorithm takes no extra data. <ins> 4.2. The "CCF_SHA256" tree algorithm uses the Merkle tree definition from TBD with SHA-256 hash algorithm. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is computed as: with extra data defined as: </ins> 5. TBD
Original text:
where "d(0)" is the payload.  This algorithm takes no extra data.  5. TBD

Reviewer comments:
Informal reference: URL TODO: Add QLDB reference to Merkle tree definition. Change target branch to after is merged.

Revised text:
where "d(0)" is the payload.  This algorithm takes no extra data. <ins> 4.2. The "QLDB_SHA256" tree algorithm uses the Merkle tree definition from TBD with SHA-256 hash algorithm. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. </ins> 5. TBD
Original text:
FIXME bit vector: 0 right, 1 left, so no bit labels <del> For some tree algorithms, like Quantum Ledger Data Base (QLDB), the direction is derived from the hashes themselves and both the index and direction can be left out in the path: </del>  Note: Including the tree size and leaf index may not be appropriate in certain privacy-focused applications as an attacker may be able to

Reviewer comments:
and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?

Revised text:
FIXME bit vector: 0 right, 1 left, so no bit labels  <ins> 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: </ins> Note: Including the tree size and leaf index may not be appropriate in certain privacy-focused applications as an attacker may be able to
Original text:
where "d(0)" is the payload.  This algorithm takes no extra data. <del> 4.2. The "QLDB_SHA256" tree algorithm uses the Merkle tree definition from TBD with SHA-256 hash algorithm. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. </del> 5. TBD

Reviewer comments:
and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?

Revised text:
where "d(0)" is the payload.  This algorithm takes no extra data.  5. TBD
Original text:
7.1.1. IANA will be requested to register the new COSE Header parameters <del> defined below in the "COSE Header Parameters" registry at some point </del>  7.2.

Reviewer comments:
and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?

Revised text:
7.1.1. IANA will be requested to register the new COSE Header parameters  <ins> defined below in the "COSE Header Parameters" registry at some point. </ins> 7.2.
Original text:
The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as [TBD]. <del> 7.2.2. IANA might be asked to establish a registry of signature algorithm identifiers, named "Signature Algorithms", with the following registration procedures: TBD The "Signature Algorithms" registry initially consists of: The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as a cryptographic signature algorithm. </del> 8.  References 8.1.  URIs

Reviewer comments:
and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?

Revised text:
The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as [TBD].  8.  References 8.1.  URIs
Original text:
1. <del> Merkle proofs are verifiable data structures that support secure data </del>  storage, through their ability to protect the integrity of batches of documents or collections of statements. <del> Merkle proofs can be used to prove a document is in a database (proof of existence), or that a smaller set of statements are contained in a large set of statements (proof of disclosure). </del> A merkle proof is a path from a leaf to a root in a merkle tree. <del> Merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </del>  The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications.

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
1.  <ins> Merkle trees are verifiable data structures that support secure data </ins> storage, through their ability to protect the integrity of batches of documents or collections of statements.  A merkle proof is a path from a leaf to a root in a merkle tree.  <ins> Merkle proofs can be used to prove a document is in a database (proof of inclusion), or that a smaller set of statements are contained in a large set of statements (selective disclosure proofs). Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </ins> The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications.