jiebi/TextFlow huggingface dataset:
Original text:
Verify the certificate chain established by the node certificate embedded in the receipt and the fixed service certificate in the <del> TS parameters (see parameters) using the Issued At time from "sign_protected" to verify the validity periods of the certificates.  The chain MUST enable the use of the public key in the receipt certificate for signature verification with the </del>  Signature Algorithm of the TS parameters. Verify that "signature" is a valid signature value of the root

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
Verify the certificate chain established by the node certificate embedded in the receipt and the fixed service certificate in the  <ins> TS parameters (see parameters) using the Issued At time from the protected header of the Receipt to verify the validity periods of the certificates.  The chain MUST enable the use of the public key in the receipt certificate for signature verification with the </ins> Signature Algorithm of the TS parameters. Verify that "signature" is a valid signature value of the root
Original text:
item reflects that a CCF ledger records both signed envelopes and auxiliary entries.) <del> For each signed envelope, compute the "Countersign_structure" as described in cose_sign1_countersign. </del>  For each item in the list, compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data and,

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
item reflects that a CCF ledger records both signed envelopes and auxiliary entries.)  <ins> For each signed envelope, create the countersigner protected header and compute the "Countersign_structure" as described in cose_sign1_countersign. </ins> For each item in the list, compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data and,
Original text:
fixed "node_certificate" and "signature", and the bytestrings "internal_hash" and "internal_data" provided with the envelope. <del> Produce the receipt using the Service Identifier and this receipt contents. </del>  6.

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
fixed "node_certificate" and "signature", and the bytestrings "internal_hash" and "internal_data" provided with the envelope.  <ins> Produce the receipt using the countersigner protected header and this receipt's contents. </ins> 6.
Original text:
6. <del> The CCF 2 tree algorithm specifies an algorithm based on a binary </del>  Merkle tree over the sequence of all ledger entries, as implemented <del> in the CCF version 2 framework (see CCF_Merkle_Tree). </del>  6.1. The algorithm requires that the TS define additional parameters: <del> Hash Algorithm: The hash algorithm used in its Merkle Tree (see hash-alg-registry). Signature Algorithm: The signature algorithm used (see sig-alg- registry). </del>  Service Certificate: The self-signed X.509 certificate used as trust anchor to verify signatures generated by the transparency service using the Signature Algorithm. <del> All definitions in this section use the hash algorithm set in the TS parameters (see Section parameters).  We write HASH to refer to this algorithm, and HASH_SIZE for the fixed length of its output in bytes. </del>  6.2.

Reviewer comments:
Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.

Revised text:
6.  <ins> The CCF tree algorithm specifies an algorithm based on a binary </ins> Merkle tree over the sequence of all ledger entries, as implemented  <ins> in the CCF framework (see CCF_Merkle_Tree). </ins> 6.1. The algorithm requires that the TS define additional parameters:  <ins> Signature Algorithm: The ECDSA signature algorithm used to sign the Merkle tree root (see sig-alg-registry). </ins> Service Certificate: The self-signed X.509 certificate used as trust anchor to verify signatures generated by the transparency service using the Signature Algorithm.  <ins> All definitions in this section use the hash algorithm required by the signature algorithm set in the TS parameters (see Section parameters).  We write HASH to refer to this algorithm, and HASH_SIZE for the fixed length of its output in bytes. </ins> 6.2.
Original text:
The Receipt contents structure is a CBOR array.  The items of the array in order are: <del> "signature": the signature over the Merkle tree root as bstr. </del>  "node_certificate": a DER-encoded X.509 certificate for the public key for signature verification.  This certificate MUST be a valid

Reviewer comments:
Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.

Revised text:
The Receipt contents structure is a CBOR array.  The items of the array in order are:  <ins> "signature": the ECDSA signature over the Merkle tree root as bstr.  Note that the Merkle tree root hash is the prehashed input to ECDSA and is not hashed twice. </ins> "node_certificate": a DER-encoded X.509 certificate for the public key for signature verification.  This certificate MUST be a valid
Original text:
10.2.2. <del> IANA is asked to establish a registry of hash algorithm identifiers, named "Hash Algorithms", with the following registration procedures: TBD The "Hash 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 hash algorithm with no known preimage or collision attacks.  These attacks can damage the integrity of the ledger. 10.2.3. </del> IANA is asked to establish a registry of signature algorithm identifiers, named "Signature Algorithms", with the following registration procedures: TBD

Reviewer comments:
Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.

Revised text:
10.2.2.  IANA is asked to establish a registry of signature algorithm identifiers, named "Signature Algorithms", with the following registration procedures: TBD
Original text:
verifiable cryptographic proof of endorsement of the signed envelope by the countersigner. <del> Compared with countersignatures on single COSE envelopes, - Receipts countersign the envelope in context, providing authentication both of the envelope and of its logical position in the authenticated data structure.  - Receipts are proof of commitment to the whole contents of the data structure, even if the Verifier knows only some of its contents.  - Receipts can be issued in bulk, using a single public- key signature for issuing a large number of Receipts. </del>  1.1.

Reviewer comments:
The first change is to address the fact that the current .md renders correctly as bullet list on Github but not in other contexts such as URL

Revised text:
verifiable cryptographic proof of endorsement of the signed envelope by the countersigner.  <ins> Compared with countersignatures on single COSE envelopes, Receipts countersign the envelope in context, providing authentication both of the envelope and of its logical position in the authenticated data structure. Receipts are proof of commitment to the whole contents of the data structure, even if the Verifier knows only some of its contents. Receipts can be issued in bulk, using a single public-key signature for issuing a large number of Receipts. </ins> 1.1.
Original text:
a Service identifier: An opaque identifier (e.g.  UUID) that uniquely identifies the service and can be used to securely <del> retrive all other Serivce parameters. </del>  The Tree algorithm used for issuing receipts, and its additional global parameters, if any.  This document creates a registry (see

Reviewer comments:
The first change is to address the fact that the current .md renders correctly as bullet list on Github but not in other contexts such as URL

Revised text:
a Service identifier: An opaque identifier (e.g.  UUID) that uniquely identifies the service and can be used to securely  <ins> retrive all other Service parameters. </ins> The Tree algorithm used for issuing receipts, and its additional global parameters, if any.  This document creates a registry (see
Original text:
Label: TBD <del> Value Type: Receipt / [+ Receipt] </del>  <del> Description: A COSE_Sign1 Countersign Receipt to be embedded in the unprotected header of the countersigned COSE_Sign1 message. </del>  9.1.1.2.

Reviewer comments:
Allowing both a receipt and an array of receipts as type is ambiguous here since the receipt is an array itself and not wrapped, so distinguishing the two cases wouldn't work. Having a single type also simplifies client code.

Revised text:
Label: TBD  <ins> Value Type: [+ Receipt] </ins>  <ins> Description: One or more COSE_Sign1 Countersign Receipts to be embedded in the unprotected header of the countersigned COSE_Sign1 message. </ins> 9.1.1.2.
Original text:
2.  2.1.  All messages are sent as HTTP GET or POST requests. If the Transparency Service cannot process a client's request, it

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
2. <ins> The SCITT REST API is designed to support identifier systems that are currently relevant to supply chains, including DID, x509 and PGP. In order to support these systems, the API must be aware of specific header parameters, in particular, "kid", "x5u" and "x5c". The API enables implementers to deploy interoperable URIs for disclosing information feeds related to supply chain actors, and artifacts accessible via transparency services. </ins> 2.1. <ins> TBD (comments on OAuth / Client Attestation). 2.2. TBD (comments on GAIN / OIDC). 2.3. TBD (comments on URLs / QR Codes). 3. 3.1. </ins> All messages are sent as HTTP GET or POST requests. If the Transparency Service cannot process a client's request, it
Original text:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. <del> 2.1.1. </del>  <del> 2.1.1.1. </del>  Headers:

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum.  <ins> 3.1.1. </ins>  <ins> 3.1.1.1. </ins> Headers:
Original text:
Body: SCITT COSE_Sign1 message <del> 2.1.1.2. </del>  One of the following:

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
Body: SCITT COSE_Sign1 message  <ins> 3.1.1.2. </ins> One of the following:
Original text:
Operation ID returned in the response.  Clients should always obtain a Receipt as a proof that Registration has succeeded. <del> 2.1.2. </del>  <del> 2.1.2.1. </del>  <del> 2.1.2.2. </del>  One of the following:

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
Operation ID returned in the response.  Clients should always obtain a Receipt as a proof that Registration has succeeded.  <ins> 3.1.2. </ins>  <ins> 3.1.2.1. </ins>  <ins> 3.1.2.2. </ins> One of the following:
Original text:
status.  This is because differentiating between the two may not be possible in an eventually consistent system. <del> 2.1.3. </del>  <del> 2.1.3.1. </del>  Query parameters:

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
status.  This is because differentiating between the two may not be possible in an eventually consistent system.  <ins> 3.1.3. </ins>  <ins> 3.1.3.1. </ins> Query parameters:
Original text:
Signed Statement is returned with the corresponding Registration Receipt embedded in the COSE unprotected header. <del> 2.1.3.2. </del>  One of the following:

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
Signed Statement is returned with the corresponding Registration Receipt embedded in the COSE unprotected header.  <ins> 3.1.3.2. </ins> One of the following:
Original text:
Error code: "entryNotFound" <del> 2.1.4. </del>  <del> 2.1.4.1. </del>  <del> 2.1.4.2. </del>  One of the following:

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
Error code: "entryNotFound"  <ins> 3.1.4. </ins>  <ins> 3.1.4.1. </ins>  <ins> 3.1.4.2. </ins> One of the following:
Original text:
The retrieved Receipt may be embedded in the corresponding COSE_Sign1 document in the unprotected header. <del> 3. </del>  Privacy Considerations <del> 4. </del>  Security Considerations <del> 5. </del>  Maybe 

Reviewer comments:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Revised text:
The retrieved Receipt may be embedded in the corresponding COSE_Sign1 document in the unprotected header.  <ins> 4. </ins> Privacy Considerations  <ins> 5. </ins> Security Considerations  <ins> 6. </ins> Maybe <ins> 6.1. This section requests registration of the "application/receipt+cose" media type RFC2046 in the "Media Types" registry in the manner described in RFC6838. TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. To indicate that the content is a SCITT Receipt: Type name: application Subtype name: receipt+cose Required parameters: n/a Optional parameters: n/a Encoding considerations: TODO Security considerations: TODO Interoperability considerations: n/a Published specification: this specification Applications that use this media type: TBD Fragment identifier considerations: n/a Additional information: Magic number(s): n/a File extension(s): n/ a Macintosh file type code(s): n/a Person & email address to contact for further information: TODO Intended usage: COMMON Restrictions on usage: none Author: TODO Change Controller: IESG Provisional registration?  No </ins>
Original text:
supply chain attacks across the entire software lifecycle while prioritizing data privacy. <del> Insert more detail on the development and deployment flows, threat landscape, and notional artifacts that allow security/compliance risk assessment. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!

Revised text:
supply chain attacks across the entire software lifecycle while prioritizing data privacy.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
2. <del> As illustrated in livecycle-threats, a supply chain attack may </del>  leverage one or more lifecycle stages and directly or indirectly target the component.  3. TBD

Reviewer comments:
Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!

Revised text:
2.  <ins> Supply chain security is paramount to protecting critical infrastructure, aerospace, and defense and avoiding impacts on security, the economy, public health, and safety.  It has historically focused on risk management practices to safeguard logistics, meet compliance regulations, demand forecasts, and optimize inventory.  While these elements are foundational to a healthy supply chain, an integrated cyber security-based perspective of the software supply chains remains broadly undefined.  Recently, the global community has experienced numerous supply chain attacks by cybercriminals targeting weaknesses in software supply chains.  As illustrated in lifecycle-threats, a software supply chain attack may </ins> leverage one or more lifecycle stages and directly or indirectly target the component. <ins> DevSecOps relies on third-party and open-source solutions, expanding supply chain complexity, and reducing the visibility of the lifecycle compliance.  One solution approach is to enhance the auditability and accountability of Digital Supply Chain Artifacts (DSCA) by using an interoperable, scalable, and flexible decentralized architecture with a transparent registry.  The required software artifacts are highly variable based on community policy requirements, and the solution approach should be artifact agnostic to enable adaptation to these broad policies.  Example artifacts may include commit signatures, build environment and parameters, software bill of materials, static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs. </ins> 3. TBD
Original text:
This eventually leads to a loss of reputation and company closure for Vendor OS-X. 

Reviewer comments:
Added a placeholder section to aggregate problem statements across use cases. Refine and complete this section as use cases stabilize.
:ship: it

Revised text:
This eventually leads to a loss of reputation and company closure for Vendor OS-X. <ins> 5. Consumers want to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package (4.1.1) Consumers want to obtain statements from producers and third- parties related to the software product in a timely and unambiguous fashion (4.2.1) Consumers want to attribute statements to an authoritative issuer (4.2.2) Consumers want to associate statements with other statements in a meaningful manner (4.2.3) Consumers want to consistently, efficiently, and homogeneously check the authenticity of statements (4.2.4) Consumers want to understand if a particular provider is actually the original provider or a promoter (4.3.1) Consumers want to know if and how the source, or resulting binary, of a promoted software component differs from the original software component (4.3.2) Consumers want to check the provenance and history of a software component's source back to its origin (4.3.3) Consumers want to assess whether to trust a promoter or not (4.3.4) To be continued... </ins>