jiebi/TextFlow huggingface dataset:
Original 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> 

Reviewer comments:
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

Revised text:
5.1.1.  <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>
Original 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>  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>  1.1.

Reviewer comments:
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

Revised text:
Abstract  <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-  <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.
Original 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>  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>  This function is defined as follows:

Reviewer comments:
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

Revised text:
2.  <ins> This documents extends the verifiable data structure registry of I- D.steele-cose-merkle-tree-proofs with the following value: </ins> 2.1.  <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:
Original text:
This documents extends the verifiable data structure registry of I- D.steele-cose-merkle-tree-proofs with the following value:  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>  This function is defined as follows:

Reviewer comments:
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

Revised 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.  <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:
Original 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>  3.

Reviewer comments:
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

Revised text:
Each leaf in a CCF ledger carries the following components:  <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.
Original 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>  "inclusion" proof type in the IANA registry of Verifiable Data <del> Structure Proof Type. </del>  The unprotected header for a CCF inclusion proof signature MUST include the following:

Reviewer comments:
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

Revised text:
the verifiable data structure algorithm identifier for "ccf- ledger" (TBD_1).  <ins> "label: int".  This header MUST be set to the value of the </ins> "inclusion" proof type in the IANA registry of Verifiable Data  <ins> Structure Proof Type (-1). </ins> The unprotected header for a CCF inclusion proof signature MUST include the following:
Original 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>  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

Reviewer comments:
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

Revised text:
"inclusion-proof: bstr .cbor CCF-inclusion-proof".  This contains the serialized CCF inclusion proof, as defined above.  <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
Original text:
3.2. <del> CCF uses the following algorithm to recompute the payload of the signature based on the "inclusion-proof" header: </del>  4.

Reviewer comments:
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

Revised text:
3.2.  <ins> CCF uses the following algorithm to verify an inclusion receipt: </ins> 4.
Original text:
Reference: This document  6.1.2. This document requests IANA to add the following new value to the <del> 'Tree Algorithms' registry: </del>  <del> Identifier: TBD_1 (requested assignment 2) </del>  <del> Tree Algorithm: ccf-ledger </del>  Reference: This document

Reviewer comments:
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

Revised 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  <ins> ''COSE Verifiable Data Structures' registry: Name: CCF_LEDGER_SHA256 </ins>  <ins> Value: TBD_1 (requested assignment 2) </ins>  <ins> Description: Historical transaction ledgers, such as the CCF ledger </ins> Reference: This document
Original 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>  Name: CCF_LEDGER_SHA256 Value: TBD_1 (requested assignment 2) <del> Description: Historical transaction ledgers, such as the CCF ledger </del>  Reference: This document

Reviewer comments:
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.

Revised text:
6.1.1. This document requests IANA to add the following new value to the  <ins> 'COSE Verifiable Data Structures' registry: </ins> Name: CCF_LEDGER_SHA256 Value: TBD_1 (requested assignment 2)  <ins> Description: Historical transaction ledgers produced by Trusted Execution Environments, such as the CCF ledger </ins> Reference: This document
Original text:
Name: CCF_LEDGER_SHA256 <del> Value: TBD_1 (requested assignment 2) </del>  <del> Description: Historical transaction ledgers produced by Trusted Execution Environments, such as the CCF ledger </del>  Reference: This document

Reviewer comments:
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

Revised text:
Name: CCF_LEDGER_SHA256  <ins> Value: 2 (requested assignment) </ins>  <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
Original 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>  2.1.

Reviewer comments:
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

Revised text:
This documents extends the verifiable data structure registry of I- D.ietf-cose-merkle-tree-proofs with the following value:  <ins> This document defines inclusion proofs for CCF ledgers. Corresponding CCF Verifiers MUST reject proof types they do not support. </ins> 2.1.
Original text:
5. <del> Privacy Considerations </del>  6. <del> Security Considerations </del>  7.

Reviewer comments:
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

Revised text:
5.  <ins> TBD </ins> 6.  <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.
Original text:
The "3161-ttc" protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2).  3.2. The "3161-ctt" COSE

Reviewer comments:
URL [ ] In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. [ ] In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” The draft looks good to me. I have two minor suggestions. In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” From: Michael Jones Date: Tuesday, July 30, 2024 at 1:53 PM To: "EMAIL" Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs _____ COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL

Revised text:
The "3161-ttc" protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). <ins> To minimize dependencies, the hash algorithm used for signing the COSE message SHOULD be the same as the algorithm used in the RFC3161 MessageImprint. </ins> 3.2. The "3161-ctt" COSE