jiebi/CodeConvo huggingface dataset:
Code change:
Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged

Related discussion:
text: Abstract <del> Abstract Text </del> <ins> This document describes a tree algorithm for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to make the tree more tamper-resistant. </ins> 1. <del> Introduction Text </del> <ins> The Concise Encoding of Signed Merkle Tree Proofs (CoMeTre) I- D.steele-cose-merkle-tree-proofs defines a standard format for carrying COSE-encoded Merkle Tree proofs and the associated signed root value.  This is helpful to pove to a verifier that a given serializable element is recorded at a given index in the Merkle Tree, or to prove that a tree is an extension of another. In this document, we describe how to verify such CoMeTre proofs for a new type of trees associated with the Confidential Consortium Framework (CCF).  Compared to RFC9162, the leaves of CCF trees carry additional opaque infomation that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistance of committed transactions that happen between new signatures of the Merkle Tree root. </ins> 1.1.
Code change:
Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged

Related discussion:
text: 2. <del> Context </del> <ins> Recall the definition of CoMeTre inclusion proofs, which are parametrized by 3 CBOR data types that are specific to the Tree Algorithm: This document defines the "CCF-leaf" and "CCF-inclusion-proof" CBOR types.  The signed Merkle Root data type "smtr" is the same as in I- D.steele-cose-merkle-tree-proofs but MUST set the protected header parameter carrying the identifier of the tree algorithm, "tree_alg", to the value TBD_1. 2.1. The input of the Merkle Tree Hash (MTH) function is a list of n bytestrings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE bytestring, also called the tree root hash. This function is defined as follows: The hash of an empty list is the hash of an empty string: The hash of a list with one entry (also known as a leaf hash) is: For n > 1, let k be the largest power of two smaller than n (i.e., k < n <= 2k).  The Merkle Tree Hash of an n-element list D_n is then defined recursively as: where: || denotes concatenation : denotes concatenation of lists D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1). 2.2. Each leaf in a CCF Merkle Tree carries the following components: The "internal_hash" and "internal_data" bytestrings are internal to the CCF implementation.  Similarly, the auxiliary tree entries are internal to CCF.  They are opaque to receipt Verifiers, but they commit the TS to the whole tree contents and may be used for additional, CCF-specific auditing. 2.3. CCF inclusion proofs are one of the tree-specific fields of a "signed-inclusion-proof".  They consist of a list of digests tagged with a single left-or-right bit. Unlike some other tree algorithms, the index of the element in the tree is not explicit in the inclusion proof, but the list of left-or- right bits can be treated as the binary decomposition of the index, from the least significant (leaf) to the most significant (root). 2.4. When a client has received an inclusion proof and wishes to verify inclusion of a signed inclusion proof: 2.5. TBD </ins> 3.
Code change:
Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged

Related discussion:
text: 5.1.1. <del> 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. </del> <ins> This document requests IANA to add the following new value to the 'Tree Algorithms' registry: Identifier: TBD_1 Tree Algorithm: ccf_ledger Reference: This document </ins>
Code change:
This uses the new proof type registry and redefines the signature type. Unlike the CT-style log algorithm the proof type is part of the trusted headers

Related discussion:
text: Abstract <del> This document describes a tree algorithm for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to make the tree more tamper-resistant. </del> <ins> This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to provide stronger tamper-evidence guarantees. </ins> 1. The Concise Encoding of Signed Merkle Tree Proofs (CoMeTre) I- <del> D.steele-cose-merkle-tree-proofs defines a standard format for carrying COSE-encoded Merkle Tree proofs and the associated signed root value.  This is helpful to pove to a verifier that a given serializable element is recorded at a given index in the Merkle Tree, or to prove that a tree is an extension of another. In this document, we describe how to verify such CoMeTre proofs for a new type of trees associated with the Confidential Consortium Framework (CCF).  Compared to RFC9162, the leaves of CCF trees carry additional opaque infomation that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistance of committed transactions that happen between new signatures of the Merkle Tree root. </del> <ins> D.steele-cose-merkle-tree-proofs defines a common framework for defining different types of proofs, such as proof of inclusion, about verifiable data structures (also abbreviated as "logs" in this document).  For instance, inclusion proofs guarantee to a verifier that a given serializable element is recorded at a given state of the log, while consistency proofs are used to establish that an inclusion proof is still consistent with the new state of the log at a later time. In this document, we define a new type of log, associated with the Confidential Consortium Framework (CCF) ledger.  Compared to RFC9162, the leaves of CCF trees carry additional opaque information that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistence of committed transactions that happen between new signatures of the Merkle Tree root. </ins> 1.1.
Code change:
This uses the new proof type registry and redefines the signature type. Unlike the CT-style log algorithm the proof type is part of the trusted headers

Related discussion:
text: 2. <del> Recall the definition of CoMeTre inclusion proofs, which are parametrized by 3 CBOR data types that are specific to the Tree Algorithm: This document defines the "CCF-leaf" and "CCF-inclusion-proof" CBOR types.  The signed Merkle Root data type "smtr" is the same as in I- D.steele-cose-merkle-tree-proofs but MUST set the protected header parameter carrying the identifier of the tree algorithm, "tree_alg", to the value TBD_1. </del> <ins> This documents extends the verifiable data structure registry of I- D.steele-cose-merkle-tree-proofs with the following value: </ins> 2.1. <del> The input of the Merkle Tree Hash (MTH) function is a list of n bytestrings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE bytestring, also called the tree root hash. </del> <ins> The input of the Merkle Tree Hash (MTH) function is a list of n byte strings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE byte string, also called the Merkle root hash. </ins> This function is defined as follows:
Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: This documents extends the verifiable data structure registry of I- D.steele-cose-merkle-tree-proofs with the following value: <ins> This document defines inclusion proofs for CCF ledgers.  Verifiers MUST reject all other proof types </ins> 2.1. <del> The input of the Merkle Tree Hash (MTH) function is a list of n byte strings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE byte string, also called the Merkle root hash. </del> <ins> A CCF ledger is a binary Merkle Tree constructed from a hash function H, which is defined from the log type.  For instance, the hash function for "CCF_LEDGER_SHA256" is "SHA256", whose "HASH_SIZE" is 32 bytes. The Merkle tree encodes an ordered list of "n" transactions T_n = {T[0], T[1], ..., T[n-1]}. We define the Merkle Tree Hash (MTH) function, which takes as input a list of serialized transactions (as byte strings), and outputs a single HASH_SIZE byte string called the Merkle root hash, by induction on the list: </ins> This function is defined as follows:
Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: Each leaf in a CCF ledger carries the following components: <del> The "internal_hash" and "internal_data" byte strings are internal to the CCF implementation.  Similarly, the auxiliary tree entries are internal to CCF.  They are opaque to receipt Verifiers, but they commit the TS to the whole tree contents and may be used for additional, CCF-specific auditing. </del> <ins> The "internal-transaction-hash" and "internal-evidence" byte strings are internal to the CCF implementation.  They can be safely ignored by receipt Verifiers, but they commit the TS to the whole tree contents and may be used for additional, CCF-specific auditing. </ins> 3.
Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: the verifiable data structure algorithm identifier for "ccf- ledger" (TBD_1). <del> "proof-type: int".  This header MUST be set to the value of the </del> <ins> "label: int".  This header MUST be set to the value of the </ins> "inclusion" proof type in the IANA registry of Verifiable Data <del> Structure Proof Type. </del> <ins> Structure Proof Type (-1). </ins> The unprotected header for a CCF inclusion proof signature MUST include the following:
Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: "inclusion-proof: bstr .cbor CCF-inclusion-proof".  This contains the serialized CCF inclusion proof, as defined above. <del> "leaf" (label TBD_2): "bstr .cbor CCF-leaf".  This contains the CCF-specific serialization of the leaf element The payload of the signature is the CCF ledger Markle root digest, </del> <ins> The payload of the signature is the CCF ledger Merkle root digest, </ins> and MUST be detached in order to force verifiers to recompute the root from the inclusion proof in the unprotected header.  This provides a safeguard against implementation errors that use the
Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: 3.2. <del> CCF uses the following algorithm to recompute the payload of the signature based on the "inclusion-proof" header: </del> <ins> CCF uses the following algorithm to verify an inclusion receipt: </ins> 4.
Code change:
NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call

Related discussion:
text: Reference: This document <ins> Label: TBD_3 Value type: "bstr" Reference: This document </ins> 6.1.2. This document requests IANA to add the following new value to the <del> 'Tree Algorithms' registry: </del> <ins> ''COSE Verifiable Data Structures' registry: Name: CCF_LEDGER_SHA256 </ins> <del> Identifier: TBD_1 (requested assignment 2) </del> <ins> Value: TBD_1 (requested assignment 2) </ins> <del> Tree Algorithm: ccf-ledger </del> <ins> Description: Historical transaction ledgers, such as the CCF ledger </ins> Reference: This document
Code change:
As discussed with NAME and NAME because the proof is scoped under , when , and is ultimately wrapped in bstr to make parsing optional, there is no need to obtain assignments for keys it uses internally. This PR is assigning values, and removing the requested assignments accordingly. Edit: I've found that it's possible to be more precise about sizes in CDDL, so I've tightened the schema a bit.
NAME if you have a minute to have a look ahead of today's meeting, that'd be wonderful :)
NAME CCF tests now automatically check some of the proofs against the schema: URL Since this is approved, can it be merged?
NAME yes :-)
lgtm! Thanks a ton.

Related discussion:
text: 6.1.1. This document requests IANA to add the following new value to the <del> 'COSE Header Parameters' registry: Label: TBD_2 (requested assignment 36) Value type: ccf-leaf Reference: This document Label: TBD_3 (requested assignment 37) Value type: [+ ccf-proof-element] Reference: This document 6.1.2. This document requests IANA to add the following new value to the ''COSE Verifiable Data Structures' registry: </del> <ins> 'COSE Verifiable Data Structures' registry: </ins> Name: CCF_LEDGER_SHA256 Value: TBD_1 (requested assignment 2) <del> Description: Historical transaction ledgers, such as the CCF ledger </del> <ins> Description: Historical transaction ledgers produced by Trusted Execution Environments, such as the CCF ledger </ins> Reference: This document
Code change:
In alignment with draft-bryce-cose-merkle-mountain-range-proofs (i.e. this I-D will request VDS reg entry "2" and mmrp will request vds reg entry "3").
2 is a good number. Thanks for cleaning out the attic

Related discussion:
text: Name: CCF_LEDGER_SHA256 <del> Value: TBD_1 (requested assignment 2) </del> <ins> Value: 2 (requested assignment) </ins> <del> Description: Historical transaction ledgers produced by Trusted Execution Environments, such as the CCF ledger </del> <ins> Description: Append-only logs that are integrity-protected by a Merkle Tree and signatures produced via Trusted Execution Environments containing a mix of public and confidential information, as specified by the Confidential Consortium Framework. </ins> Reference: This document
Code change:
URL As promised at the meeting last week I have reviewed both: URL URL This is my review of the Birkholtz draft profile. REVIEW NOTES Overall very good, just a few comments: BIRKHOLTZ [Section 2]: “This document defines inclusion proofs for CCF ledgers. Verifiers MUST reject all other proof types” It’s unclear to me how useful this normative language is. Does it pollute the implementer’s wider implementation of cose-merkle-tree-proofs? In which case I think it’s wrong: verifiers might well verify many different transparent statements from a plurality of logs with a plurality of proof types. Of course for any given transparent statement they need to implement the proof verification correctly but I don’t see the value of this rejection statement. Privacy Considerations could do with some content (or removal if we consider that leaves and log activity are not relevant leakage of privacy info) Security Considerations could do with some content: CCF ledgers have certain trade-offs and assumptions about the environment they run in: should these be noted? Possibly a small nit, but “Historical transaction ledgers produced by Trusted Execution Environments” feels wrong to me. The ledger isn’t produced ‘by’ the TEE. It’s produced by a lump of code running in a TEE protected environment of some flavour. Or at least you have to hope it is. See comment on security considerations. [Section 7] reference to cose-merkle-tree-proofs is broken. Please fix. [Appendix A. Attic]: Casual language “Not ready to throw these texts into the trash bin yet.” … but there’s nothing else in there! Please remove. Jon

Related discussion:
text: This documents extends the verifiable data structure registry of I- D.ietf-cose-merkle-tree-proofs with the following value: <del> This document defines inclusion proofs for CCF ledgers.  Verifiers MUST reject all other proof types </del> <ins> This document defines inclusion proofs for CCF ledgers. Corresponding CCF Verifiers MUST reject proof types they do not support. </ins> 2.1.
Code change:
URL As promised at the meeting last week I have reviewed both: URL URL This is my review of the Birkholtz draft profile. REVIEW NOTES Overall very good, just a few comments: BIRKHOLTZ [Section 2]: “This document defines inclusion proofs for CCF ledgers. Verifiers MUST reject all other proof types” It’s unclear to me how useful this normative language is. Does it pollute the implementer’s wider implementation of cose-merkle-tree-proofs? In which case I think it’s wrong: verifiers might well verify many different transparent statements from a plurality of logs with a plurality of proof types. Of course for any given transparent statement they need to implement the proof verification correctly but I don’t see the value of this rejection statement. Privacy Considerations could do with some content (or removal if we consider that leaves and log activity are not relevant leakage of privacy info) Security Considerations could do with some content: CCF ledgers have certain trade-offs and assumptions about the environment they run in: should these be noted? Possibly a small nit, but “Historical transaction ledgers produced by Trusted Execution Environments” feels wrong to me. The ledger isn’t produced ‘by’ the TEE. It’s produced by a lump of code running in a TEE protected environment of some flavour. Or at least you have to hope it is. See comment on security considerations. [Section 7] reference to cose-merkle-tree-proofs is broken. Please fix. [Appendix A. Attic]: Casual language “Not ready to throw these texts into the trash bin yet.” … but there’s nothing else in there! Please remove. Jon

Related discussion:
text: 5. <del> Privacy Considerations </del> <ins> TBD </ins> 6. <del> Security Considerations </del> <ins> Maybe a list of precursors that are specific to CCF VDS goes here (e.g., trade-offs, pro/con, use of TEE). </ins> 7.