jiebi/TextFlow huggingface dataset:
Original text:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <del> : </del> The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052.

Reviewer comments:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Revised text:
are capitalized.  To ensure readability, only a core set of terms is included in this section.  The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052.
Original text:
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE <del> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs). </del>  The Registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-

Reviewer comments:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Revised text:
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE  <ins> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs) that also provides the COSE header parameter semantics for label 394. </ins> The Registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-
Original text:
fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two Receipts in its unprotected header. <del> The label 394 "receipts" in unprotected header can contain multiple Receipts. </del>  fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable

Reviewer comments:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Revised text:
fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two Receipts in its unprotected header.  <ins> The type of label 394 "receipts" in the unprotected header is a CBOR array that can contain one or more Receipts (each entry encoded as a .cbor encoded Receipts). </ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable
Original text:
7. <del> TBD; mybody. </del> 7.1. <del> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.media-types in the manner described in RFC6838. To indicate that the content is an scitt configuration represented as JSON: Type name: application Subtype name: scitt-configuration+json Required parameters: n/a Optional parameters: n/a Encoding considerations: binary; application/scitt- configuration+json values are represented as a JSON Object; UTF-8 encoding SHOULD be employed for the JSON object. Security considerations: See the Security Considerations section of TBD. Interoperability considerations: n/a Published specification: TBD 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: TBD Intended usage: COMMON Restrictions on usage: none Author: TBD Change Controller: IETF Provisional registration?  No </del> 

Reviewer comments:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Revised text:
7.  7.1.  <ins> Pending WG discussion. </ins>
Original text:
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <del> At least one identifier for an identity document MUST be included in the protected header of the COSE Envelope, as one of "x5t" or "kid". Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </del>  When using x509, Support for "x5t" is mandatory to implement.

Reviewer comments:
Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL

Revised text:
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree.  <ins> At least one identifier representing one credential MUST be included in the protected header of the COSE Envelope, as one of "x5t" or "kid".  Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </ins> When using x509, Support for "x5t" is mandatory to implement.
Original text:
and 8192 characters in length that fits the regular expression of a distinguished name. <del> The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. </del> The "kid" header parameter MUST be present when "x5t" is not present. Key discovery protocols are out-of-scope of this document.

Reviewer comments:
Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL

Revised text:
and 8192 characters in length that fits the regular expression of a distinguished name.  The "kid" header parameter MUST be present when "x5t" is not present. Key discovery protocols are out-of-scope of this document.
Original text:
proof of Registration by a Transparency Service, in the form of a Receipt that countersigns the Signed Statement and witnesses its inclusion in the Append-only Log of a Transparency Service.  By <del> extension, the document may say an Artifact (a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. </del>  Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.  Any Artifact that may be verified, is

Reviewer comments:
changes "document" to "Signed Statement" (was a weird nit close to the suggested change)LGTM

Revised text:
proof of Registration by a Transparency Service, in the form of a Receipt that countersigns the Signed Statement and witnesses its inclusion in the Append-only Log of a Transparency Service.  By  <ins> extension, the Signed Statement may say an Artifact (for example, a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. </ins> Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.  Any Artifact that may be verified, is
Original text:
Artifacts, from the build and supply of software and IoT devices to advanced manufacturing and food supply. <del> SCITT is a generalization of Certificate Transparency RFC9162, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.  Considering CT in terms of SCITT: </del>  <del> CAs (Issuers) sign X.509 TBSCertificates (Artifacts) to produce X.509 certificates (Signed Statements) </del>  CAs submit the certificates to one or more CT logs (Transparency Services)

Reviewer comments:
removed "(Artifact)" which seems to have been an artifact....LGTM

Revised text:
Artifacts, from the build and supply of software and IoT devices to advanced manufacturing and food supply.  <ins> SCITT is a generalization of Certificate Transparency (CT) RFC9162, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.  Considering CT in terms of SCITT: </ins>  <ins> CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements) </ins> CAs submit the certificates to one or more CT logs (Transparency Services)
Original text:
Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.  For <del> instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. </del>  Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by

Reviewer comments:
I don't understand the motivation behind replacing "any other COSE compatible PKI trust anchor." with "a JSON Web Key Set". Is there an issue with COSE compatible PKI trust anchors that is driving this change?
NAME : What is an example of a "any other COSE compatible PKI trust anchor." besides the JSON Web Key Set?
Good question NAME if JSON Web Key Set is indeed the only possible COSE compatible PKI trust anchor then I see no issues with this change.
I support Steve's suggested change.
I think the point here is to keep it open and not limit to what exists today.
NAME I have not worked on COSE for one minute, but I get the impression that a SCITT Transparency statement could include identities other than X.509, which seems to imply that another form of "trust anchor" is plausible, i.e. a PGP chain of Trust or even a SCITT trusted party - am I mistaken.
These are just examples anyway and as such the list is unbounded. But if you give examples, as you do today, then it better might be good to give examples that are understandable by readers. That is what I have been trying to do. I listed the only COSE example I am aware of.
LGTM to changes

Revised text:
Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.  For  <ins> instance, a trust anchor could be an X.509 root certificate, a pointer to an OpenID Connect identity provider, or any other COSE- compatible trust anchor. </ins> Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by
Original text:
identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. <del> When using x509, Support for "x5t" is mandatory to implement. </del>  Support for "kid" in the protected header and "x5chain" in the <del> unprotected heaer is optional. </del>  When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a

Reviewer comments:
fiddled with the language that intended to be normative and made it normative languageLGTM

Revised text:
identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope.  <ins> When using x.509 certificates, support for "x5t" is REQUIRED to implement. </ins> Support for "kid" in the protected header and "x5chain" in the  <ins> unprotected header is OPTIONAL to implement. </ins> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a
Original text:
<del> A Client authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more Issuers. Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </del>  <del> The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. </del> 

Reviewer comments:
This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM

Revised text:
 <ins> A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture. </ins>  <ins> The Transparency Service MUST perform signature verification, as defined in RFC9052, and MAY perform additional checks as part of its Registration Policy. </ins>
Original text:
The Transparency Service MUST check that the Signed Statement <del> includes the required protected headers listed above.  The Transparency Service MAY verify the Statement payload format, content and other optional properties. </del> 

Reviewer comments:
This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM

Revised text:
The Transparency Service MUST check that the Signed Statement  <ins> includes the required protected headers.  The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. </ins>
Original text:
, which MAY be asynchronous from Registration.  The Transparency Service MUST be able to provide a Receipt for all registered <del> Statements.  A Receipt for a Signed Statement MAY be provided asynchronously.  Details about generating Receipts are described in Receipt. </del>  The last two steps may be shared between a batch of Signed Statements recorded in the Append-only Log.

Reviewer comments:
This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM

Revised text:
, which MAY be asynchronous from Registration.  The Transparency Service MUST be able to provide a Receipt for all registered  <ins> Signed Statements.  Details about generating Receipts are described in Receipt. </ins> The last two steps may be shared between a batch of Signed Statements recorded in the Append-only Log.
Original text:
Signed Statement can be tampered with by a malicious Transparency Service (e.g., one that does not incorporate remote attestation), which may replace the intermediate certificates and ultimately <del> connect to an unexpected root.  This modification can allow malicious TS to forge Claims that look genuine except for the wrong trust anchor.  Auditors MUST perform certification path validation in accordance with PKIX rules specified in RFC5280.  In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). </del>  6.1.

Reviewer comments:
Here is the status: I do not believe there is a security problem. Roy says that Antoine thinks there is a problem. Antoine is, however, not at the meeting.
Antoine can object in the next iteration or during WGLC
The replacement loses the security issue and adds a new one. The modification of removing the certificate chain, which will save space in the ledger, opens up a problem of building the chain dynamically may result in the wrong trust anchor.LGTM

Revised text:
Signed Statement can be tampered with by a malicious Transparency Service (e.g., one that does not incorporate remote attestation), which may replace the intermediate certificates and ultimately  <ins> connect to an unexpected root.  This modification helps protect against person-in-the-middle attacks, but not denial-of-service. Auditors MUST perform certification path validation in accordance with PKIX rules specified in RFC5280.  In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). </ins> 6.1.
Original text:
be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. <del> Issuers and Transparency Services MUST rotate verification keys for signature checking in well-defined cryptoperiods (see KEY- MANAGEMENT). </del>  A Transparency Service MAY provide additional authenticity assurances about its secure implementation and operation, enabling remote

Reviewer comments:
I generalized the description. You need to rotate all keys.
I don't have strong opinions about the MUST vs. SHOULD requirement here. The group will have to sort this out
Was wondering whether the cases where keys are never rotated are actually valid. The implication is the following: if an end-entity certificate has an indefinite lifetime then the certificates of the subordinate and CA certificates also need to have an indefinite lifetime. Is this a realistic deployment? If so, can you describe this deployment?
Sitting in the SUITS meeting, the same question of MUST came up. Someone made the comment that the MIST could be required in the doc, but the doesn’t mean a service that doesn’t follow the MIST guidance, can’t physically operate or even interop with other services. It would mean it’s not conformant to informative guidance, and a security review could seem it not as secure. Which might be fine for a locked down, IoT scenario. After the SUITS discussion, I’m fine with a MUST for operational info, that enables a service to function as they deem fit
Keeping with MUST as it doesn't change the compatibility, and a service that doesn't rotate would still be interoperable, and be operationally not compliant.
LGTM!removed the hyphen from cryptoperiodsApproving the MUST text.

Revised text:
be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc.  <ins> Issuers and Transparency Services MUST rotate their keys in well- defined cryptoperiods, see KEY-MANAGEMENT. </ins> A Transparency Service MAY provide additional authenticity assurances about its secure implementation and operation, enabling remote
Original text:
5. <del> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </del>  6.

Reviewer comments:
NAME NAME PTAL at the latest if they resolve your requested changes.
Suggest we incorporate Option 1 suggestion from Steve!I see this change as constructive, I asked Steve for clarification on his comments too.Changes as of URL improve the previous text. LGTM

Revised text:
5.  <ins> Transparency Services MAY support anonymous access, Issuers MUST ensure Signed Statements submitted to public access services are acceptable for public disclosure.  In this case, Signed Statements MUST NOT carry confidential information.  Once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log.  In some deployments, a Relaying Party, such as an Auditor, might require access to Signed Statements and Statements, which can be made available through adjacent services. Transparency Services MUST enforce access control to the Append-only Log. </ins> 6.
Original text:
who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. <del> Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </del>  6.

Reviewer comments:
You have to explain what this means and include reference. Since you are likely not going to do this, I suggest to delete this sentence.
I think we should take NAME 's change, and that the current text is problematic.
LGTM

Revised text:
who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system.  <ins> Once a cryptographic digest of the Signed Statement is registered on the Append-only Log, the registration cannot be removed from the Append-only Log. </ins> 6.