jiebi/CodeConvo huggingface dataset:
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: Description: Merkle tree algorithm used to produce a COSE Sign1 payload. <del> 7.2. </del> <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> <del> IANA will be asked to add a new registry "TBD" to the list that appears at IANA Assignments [1]. </del> <ins> Name: consistency_proof </ins> <del> The rest of this section defines the subregistries that are to be created within the new "TBD" registry. </del> <ins> Label: TBD_2 </ins> <del> 7.2.1. </del> <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
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: Reference: Where this algorithm is defined Initial contents: Provided in <del> 8.  References 8.1.  URIs [1] https://www.iana.org/assignments/ </del>
Code change:
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

Related discussion:
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.
Code change:
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

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

Related discussion:
text: 6. <del> See the privacy considerations section of: </del> <ins> See the security considerations section of: </ins>
Code change:
This PR aligns the abstract and intro with generalizing away from specific merkle trees
LGTM

Related discussion:
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> <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. <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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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. <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> <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> <del> A merkle proof is a path from a leaf to a root in a merkle tree. </del> <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> <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> <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> <del> Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </del> <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> <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> <ins> This document describes how to convey verifiable data structures, and associated proof types in COSE envelopes. </ins> 1.1.
Code change:
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

Related discussion:
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> <ins> Depending on the verifiable data structure used, a service provider might be able to count unique entries. </ins> <del> In the case that a leaf is produced from a cose sign 1 envelope, </del> <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 <del> unique leaf entry. </del> <ins> unique entry. </ins> However, this could impact privacy, and some transparency service operators might prefer only integrity protected content be made
Code change:
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

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

Related discussion:
text: 8.1.1.1. <del> Name: verifiable_data_structure </del> <ins> Name: verifiable-data-structure </ins> <del> Label: TBD_1 </del> <ins> Label: TBD_1 (requested assignment 12) </ins> <del> Value type: verifiable_data_structure </del> <ins> Value type: int / tstr </ins> Value registry: See <del> Description: Merkle tree algorithm used to produce a COSE Sign1 payload. </del> <ins> Description: Tag indicating the Verifiable Data Structure, see sec-generic-verifiable-data-structures. </ins> <del> Name: inclusion_proof </del> <ins> Editors note: Authors are discussing how to avoid flooding the cose header parameters registry with new proof types. </ins> <del> Label: TBD_2 </del> <ins> Name: inclusion-proof </ins> <del> Value type: inclusion_proof </del> <ins> Label: TBD_2 (requested assignment 13) Value type: bstr </ins> Value registry: See <del> Description: Merkle tree inclusion proof for the given verifiable_data_structure. </del> <ins> Description: Tag indicating the "inclusion" Proof Type, see sec- generic-inclusion-proof. </ins> <del> Name: consistency_proof </del> <ins> Name: consistency-proof </ins> <del> Label: TBD_2 </del> <ins> Label: TBD_2 (requested assignment 14) </ins> <del> Value type: consistency_proof </del> <ins> Value type: bstr </ins> Value registry: See <del> Description: Merkle tree consistency proof for the given verifiable_data_structure. </del> <ins> Description: Tag indicating the "consistency" Proof Type, see sec- generic-consistency-proof. </ins> 8.1.2.
Code change:
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

Related discussion:
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>
Code change:
Informal references: URL URL TODO: Add CCF reference to Merkle tree definition (including details on the leaves). Change target branch to after is merged.

Related discussion:
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
Code change:
Informal reference: URL TODO: Add QLDB reference to Merkle tree definition. Change target branch to after is merged.

Related discussion:
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
Code change:
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?

Related discussion:
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> <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
Code change:
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?

Related discussion:
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
Code change:
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?

Related discussion:
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> <ins> defined below in the "COSE Header Parameters" registry at some point. </ins> 7.2.
Code change:
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?

Related discussion:
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
Code change:
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.

Related discussion:
text: 1. <del> Merkle proofs are verifiable data structures that support secure data </del> <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. <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> <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.
Code change:
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.

Related discussion:
text: 3. <del> This section describes representations of merkle tree structures in </del> <ins> This section describes representations of merkle proof structures in </ins> CBOR. Some of the structures such as the construction of a merkle tree
Code change:
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.

Related discussion:
text: several different representations. Some differences in representations are necessary to support <del> efficient verification of proofs and compatibility with deployed tree algorithms used in specific implementations. </del> <ins> efficient verification of different kinds of inclusion proofs and for compatibility with deployed tree algorithms used in specific implementations. </ins> 3.1. <del> A Merkle tree root is signed with COSE_Sign1, creating a Signed Merkle Tree Root: </del> <ins> A Merkle root is signed with COSE_Sign1: </ins> Protected header parameters:
Code change:
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.

Related discussion:
text: tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value type: int / tstr. <del> tree size (label: TBD): OPTIONAL.  Merkle tree size as the number of leaves.  Value type: uint. </del> A COSE profile of this specification may add further header <del> parameters, for example to identify the signer. </del> <ins> parameters, for example to identify the signer or add a timestamp. Envelope Payload: A Merkle tree root according to the tree alg. </ins> <del> Payload: Merkle tree root hash bytes according to tree alg (i.e., header params tell you what the alg id is here) </del> <ins> The envelope payload can be detached, since it can be recomputed by the verifier. </ins> <del> Note: The payload is just a byte string representing the Merkle tree root hash (and not some wrapper structure) so that it can be detached (see defintion of payload in https://www.rfc-editor.org/rfc/ rfc9052#section-4.1) and easily re-computed from an inclusion path and leaf bytes.  This allows to design other structures that force re-computation and prevent faulty implementations (forgetting to match a computed root with one embedded in a signature). </del> <ins> Forcing a verifier to perform re-computation can prevent faulty implementations. </ins> <del> One example of a Signed Merkle Tree Proof is a "transparent signed statement" or "claim" as defined in I-D.ietf-scitt-architecture. </del> <ins> One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. </ins> 3.2.