jiebi/TextFlow huggingface dataset:
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. </del>  Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit

Reviewer comments:
I would not assume certain deployment situations. It is likely that there are many Transparency Services that are not necessarily publically accessible to everyone and the entire architecture would still be totally valid
I agree NAME I know of at least one registry (Transparency Service) that will not be publicly accessible.
NAME always public or not, should we not consider that as material for privacy considerations that follow the line your recommended deletion?Thanks for the updates LGTM

Revised text:
5.  <ins> 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. </ins> Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit
Original text:
Implementations of Transparency Services may protect their Append- only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an <del> offline, universally-verifiable proof that an entry is recorded in </del>  the Append-only Log.  Requesting a receipt can result in the production of a new receipt for the same signed statement.  A Receipt's verification key, signing algorithm, validity period,

Reviewer comments:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Revised text:
Implementations of Transparency Services may protect their Append- only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an  <ins> offline, universally-verifiable proof that an entry is registered in </ins> the Append-only Log.  Requesting a receipt can result in the production of a new receipt for the same signed statement.  A Receipt's verification key, signing algorithm, validity period,
Original text:
4.1. Transparency Services MUST feature an Append-only Log.  The Append- <del> only Log is the verifiable data structure that records Signed Statements and supports the production of Receipts. </del>  All Transparency Services MUST expose APIs for the Registration of Signed Statements and issuance of Receipts.

Reviewer comments:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Revised text:
4.1. Transparency Services MUST feature an Append-only Log.  The Append-  <ins> only Log is the verifiable data structure that records registered Signed Statements and supports the production of Receipts. </ins> All Transparency Services MUST expose APIs for the Registration of Signed Statements and issuance of Receipts.
Original text:
in Receipt. The last two steps may be shared between a batch of Signed Statements <del> recorded in the Append-only Log. </del>  A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt.

Reviewer comments:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Revised text:
in Receipt. The last two steps may be shared between a batch of Signed Statements  <ins> registered in the Append-only Log. </ins> A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt.
Original text:
If a Transparency Service is honest, then a Transparent Statement including a correct Receipt ensures that the associated Signed <del> Statement passed its Registration Policy and was recorded </del>  appropriately. Conversely, a corrupt Transparency Service may:

Reviewer comments:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Revised text:
If a Transparency Service is honest, then a Transparent Statement including a correct Receipt ensures that the associated Signed  <ins> Statement passed its Registration Policy and was registered </ins> appropriately. Conversely, a corrupt Transparency Service may:
Original text:
header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.  An "x5chain" with a leaf certificate that corresponds to <del> the "x5t" value MAY be included in the unprotected header in support of certain supply chain scenarios. </del>  The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of

Reviewer comments:
Remove ambiguous details reported in (.
x5t value MAY be included in the unprotected header in support of certain supply chain scenarios.
LGTMLGTM

Revised text:
header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.  An "x5chain" with a leaf certificate that corresponds to  <ins> the "x5t" value MAY be included in the unprotected header. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of
Original text:
statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the <del> specific verifiable data structure used.  Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value "1", which supports "-1" (inclusion proofs) and "-2" (consistency proofs). </del>  fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn.

Reviewer comments:
Address feedback from Hannes in .
Registry, RFC9162_SHA256 is value 1, which supports -1 (inclusion proofs) and -2 (consistency proofs). I believe this registry is defined in another document. The sentence needs to be changed to make the meaning clear.
Breaks circular relationship until one is completed.LGTM

Revised text:
statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the  <ins> specific verifiable data structure used.  Per the COSE Verifiable Data Structure Registry documented in I-D.draft-ietf-cose-merkle- tree-proofs, the COSE key type RFC9162_SHA256 is value "1".  Labels identify inclusion proofs ("-1") and consistency proofs ("-2"). </ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn.
Original text:
COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs. <del> This section describes at a high level, the three main roles and associated processes in SCITT: </del>  <del> Issuers and Signed Statements </del>  <del> Transparency Service and the registration process </del>  <del> Relying Parties of the Transparent Statements and the Receipt validation process </del>  The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and

Reviewer comments:
Editors call notes: Moving above the diagram is good clarity Changing from defining the roles to the overall diagram caused some confusion. If the PR can maintain the roles, and add diagram clarity, that would be preferred.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained
LGTM

Revised text:
COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs.  <ins> fig-concept-relationship illustrates entities and processes that comprise a Transparency Service independent of any one use case. </ins>  <ins> This section describes the three main roles and associated processes in SCITT: </ins>  <ins> Issuers that use their credentials to create Signed Statements about Artifacts </ins>  <ins> Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration.  The returned Receipt may be combined with the Signed Statement to create a Transparent Statement. Relying Parties that: collect Receipts of Signed Statements for subsequent registration of Transparent Statements; retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. verification); or replay all the Transparent Statements to check for the consistency of the Transparency Service's Append-only Log (e.g. auditing) </ins> The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and
Original text:
CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> Signed Certificate Timestamps are checked by Relying Parties </del>  The Append-only Log can be checked by Auditors

Reviewer comments:
I would argue that in CT Auditors are checking more than Signed Certificate Timestamps
NAME there is a lot of detail there and I am not sure how far you/others want to go, but I decided to keep it simple and I propose adding slightly more detail in URL I am sure you and others will let me know if that is too little (I doubt/hope it is not too much.)
NAME thanks for the issue. Did you have an intent for what to scope? Reading the , it implies a unique focus on x.509, rather than x.509 is one example of identity types that are supported. Considering CT in terms of SCITT: I'd suggest we limit the focus on x.509, and focus on the generalization that an issuer signs the protected header, which includes producing a timestamped signed statement and a timestamped receipt.
LGTM

Revised text:
CT logs produce Signed Certificate Timestamps (Transparent Statements)  <ins> Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties </ins> The Append-only Log can be checked by Auditors
Original text:
Statement pertains to.  (See Subject under terminology Terminology.) Issuers MAY use different signing keys (identified by "kid" in the <del> resolved key manifest) for different Artifacts, or sign all Signed </del>  Statements under the same key. An Issuer can make multiple Statements about the same Artifact.  For

Reviewer comments:
There is no explanation in draft, GitHub, or mailing lists about resolved key manifest. This change proposes replacement with protected header like other portions of the document.
resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. What does "resolved key manifest" mean?
LGTM

Revised text:
Statement pertains to.  (See Subject under terminology Terminology.) Issuers MAY use different signing keys (identified by "kid" in the  <ins> protected header) for different Artifacts, or sign all Signed </ins> Statements under the same key. An Issuer can make multiple Statements about the same Artifact.  For
Original text:
(see RFC8610) for of the protected header and unprotected header of Signed Statements and Receipts. <del> Everything that is optional in the following CDDL definition can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the Registration Policy. </del>  fig-signed-statement-edn illustrates an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that

Reviewer comments:
These proposed changes, if accepted,
potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields. I do not understand what you want to say with the second part of the sentence. Even the first part of the sentence do not convey any real meaning.
LGTM of URL

Revised text:
(see RFC8610) for of the protected header and unprotected header of Signed Statements and Receipts.  <ins> This definition specifies the minimal mandatory labels. Implementation-specific Registration Policies may define additional mandatory labels.  A Transparency Service implementation MUST reject registering Signed Statements that do not meet their current Registration Policy requirements.  Each implementation SHOULD provide details for their registration policies through documentation or discovery APIs. </ins> fig-signed-statement-edn illustrates an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that
Original text:
Statement is accepted to be registered to the Append-only Log. Transparency Services MUST maintain Registration Policies. <del> 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, a pointer to an OpenID Connect identity provider, or any other COSE- compatible trust anchor.

Reviewer comments:
Editors note: updated with a link to the referenced text: I don't understand the SHOULD. You have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.
It would seem this is correct contingent on your interpretation of , particularly points 2 and 3, so good point.
It's not the use of the anchor in verifying that is optional. It is the use of issuer verification as a gate to registration that is the problem. For ts implementations that naturaly have RBAC at the edge, the "spam" problem is not really a problem. Statements about statements seem to me to be a better way to deal with use cases where strong issuer verification is necessary. Registration time checks can only ever be "point in time"
My read of the Issue and the current state of the document is: This section is under , which implies the MUST refers to enabling the registration process. Currently, a registration can not be completed unless the issuer is verified, which can't occur without trust anchors. The SHOULD refers to verifiers which are not part of the Registration Policy. I think their inclusion in this section is confusing. See for a proposal.

Revised text:
Statement is accepted to be registered to the Append-only Log. Transparency Services MUST maintain Registration Policies.  <ins> Transparency Services MUST maintain a list of trust anchors (see definition of trust anchor in RFC4949).  Transparency Services MUST authenticate signed statements as part of a Registration Policy.  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.
Original text:
COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs. <del> This section describes at a high level, the three main roles and associated processes in SCITT: </del>  <del> Issuers and Signed Statements </del>  <del> Transparency Service and the registration process </del>  <del> Relying Parties of the Transparent Statements and the Receipt validation process </del>  The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and

Reviewer comments:
Note: This PR assumes is merged, and may need to be updated to fit within the context of 's final text.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained

Revised text:
COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs.  <ins> fig-concept-relationship illustrates the three main roles and associated processes that comprise a Transparency Service, independent of any one use case. </ins>  <ins> Issuers that use their credentials to create Signed Statements about Artifacts.  Issuer Credentials are also used to verify the Signed Statements within the Transparency Service registration process, and Transparent Statements. </ins>  <ins> Transparency Services that evaluate Signed Statements against Registration Policies, using credentials to sign Receipts upon successful Registration. </ins>  <ins> Relying Parties that: collect Receipts, combining them with the Signed Statements to create a Transparent Statement; retrieve Transparent Statements for analysis of Statements about Artifacts; uses credentials to authenticate the Signed Statement and the Receipts of the Transparent Statement (e.g. verification); replay segments of Transparent Statements checking for the consistency of the Transparency Service's Append-only Log (e.g. auditing) In addition, fig-concept-relationship illustrates multiple Transparency Services and multiple Receipts as a single Signed Statement MAY be registered with one or more Transparency Service. Each Transparency Service produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple Transparency Services. The arrows indicate the flow of information. </ins> The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and
Original text:
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <del> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. </del> For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE).

Reviewer comments:
Closes URL
external attacks and internal misbehavior by some or all of the operators of the Transparency Service. What does the term "each of these functions" refer to?
LGTM to Danny

Revised text:
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement.  For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE).