jiebi/TextFlow huggingface dataset:
Original text:
by the Transparency Service MUST be checked. In essence, when using X.509 Signed Statements, the Transparency <del> Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t" located in the protected 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 the "x5t" value MAY be included in the unprotected header. </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:
by allowing the use of a single, protected header parameter instead of a protected and unprotected pair, for reasons described in the issue. This allows implementations to avoid the risk highlighted at the end of , at the expense of a slightly larger protected header. This is not a purely theoretical concern, the most widely used signing service inside Microsoft has implemented this choice, and the separate from Microsoft has too.
The current text mandates the presence of in the protected header when using x509: URL, and allows an unprotected x5chain: URL I propose that the specification allows in the protected header, ideally as a substitute for , but in addition otherwise. The motivation for this change is to add a degree of integrity protection over , and blame for malicious payload otherwise. The current set up does not authenticate or integrity protect the contents of x5chain, only the leaf, which opens up some opportunities for attacks targeting x509 parsers. I can see why this minimal binding can be desirable in some cases (caching large cert chains), but servers that wish to be stricter to reduce their attack surface should be able to.
Thanks for the fix. Seems quite valuable to the overall operation! LGTM!LGTM thanks. For completeness of the record, I was previously against mandatory x5chain and mandatory deep, possibly online checks of the links in the chain. This PR looks eminently sensible for people who want to rely on x5chainDiscussion at the editors meeting to approve. LGTM

Revised text:
by the Transparency Service MUST be checked. In essence, when using X.509 Signed Statements, the Transparency  <ins> Service MUST build and validate a complete certification path from an Issuer's certificate to one of the root certificates most recently registered as a trust anchor by the Transparency Service. The protected header of the COSE_Sign1 Envelope MUST include either the Issuer's certificate as "x5t" or the chain including the Issuer's certificate as "x5chain".  If "x5t" is included in the protected header, an "x5chain" with a leaf certificate corresponding to 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:
<del> The Transparency Service MUST perform signature verification, as defined in RFC9052, and MAY perform additional checks as part of its Registration Policy. The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC9360, using the signature algorithm and verification key of the Issuer. The Transparency Service MUST check that the Signed Statement 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. </del> 

Reviewer comments:
This editorial change attempts to per feedback from NAME
The three steps from Section 4.3 on Registration are essentially the same. To verify the signature you have to retrieve the issuer credentials and you have to do item 4. Issuer Verification: The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. Signature verification: The Transparency Service MUST verify the signature of the Signed Statement, as described in [RFC9360], using the signature algorithm and verification key of the Issuer. Signed Statement validation: The Transparency Service MUST check that the Signed Statement includes the required protected headers listed above. The Transparency Service MAY verify the Statement payload format, content and other optional properties.
LGTM for reduction and lack of duplicity

Revised text:
 <ins> The Transparency Service MUST perform signature verification per RFC9052 and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per RFC9360.  The Transparency Service MUST also check the Signed Statement 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:
contents of the Registry at the time of registration, and must then yield the same result. <del> The ordering of entries, their cryptographic contents, and the </del>  Registry governance may be non-deterministic, but they must be verifiable. <del> A Transparency Services SHOULD store evidence about the resolution </del>  of distributed identifiers into manifests. <del> A Transparency Service MAY additionally support verifiability of </del>  client authentication and access control. 5.2.3.4.

Reviewer comments:
This is a long sentence, maybe break it up into multiple 80 character lines? A policy could be 'unrecognized', 'unparsable', or 'not implemented'. Does 'unknown' imply all of these? Originally posted by NAME in URL

Revised text:
contents of the Registry at the time of registration, and must then yield the same result.  <ins> the ordering of entries, their cryptographic contents, and the </ins> Registry governance may be non-deterministic, but they must be verifiable.  <ins> a Transparency Services SHOULD store evidence about the resolution </ins> of distributed identifiers into manifests.  <ins> a Transparency Service MAY additionally support verifiability of </ins> client authentication and access control. 5.2.3.4.
Original text:
Many Issuers issue Signed Statements about different Artifacts under the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed <del> Statments what Artifact it is referring to.  This information is </del>  stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same

Reviewer comments:
With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1

Revised text:
Many Issuers issue Signed Statements about different Artifacts under the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed  <ins> Statements what Artifact it is referring to.  This information is </ins> stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same
Original text:
COSE Envelope of the Signed Statement.  The key of the map entry corresponds to the name of the policy, while its value (including its type) is policy-specific.  For instance, the "register_by" policy <del> defines the maximum timestamp by which a Signed Statemnet can be </del>  registered, hence the associated value contains an unsigned integer. While this design ensures that all verifiers get the same guarantee

Reviewer comments:
With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1

Revised text:
COSE Envelope of the Signed Statement.  The key of the map entry corresponds to the name of the policy, while its value (including its type) is policy-specific.  For instance, the "register_by" policy  <ins> defines the maximum timestamp by which a Signed Statement can be </ins> registered, hence the associated value contains an unsigned integer. While this design ensures that all verifiers get the same guarantee
Original text:
details. Some Verifiers may systematically resolve Issuer DIDs to fetch the <del> latest corresponding DID documents.  This behaviour strictly enforces </del>  the revocation of compromised keys: once the Issuer has updated its Statement to remove a key identifier, all Signed Statements include the corresponding "kid" will be rejected.  However, others may

Reviewer comments:
With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1

Revised text:
details. Some Verifiers may systematically resolve Issuer DIDs to fetch the  <ins> latest corresponding DID documents.  This behavior strictly enforces </ins> the revocation of compromised keys: once the Issuer has updated its Statement to remove a key identifier, all Signed Statements include the corresponding "kid" will be rejected.  However, others may
Original text:
latest version, Issuers SHOULD use the "sequence_no" or "issuer_ts" attributes. <del> Once all the Envelope headers are set, an Issuer SHOULD use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed </del>  Statement). 6.3.

Reviewer comments:
NAME PTAL
Since the use of COSE is mandatory, shouldn't this be MUST? Originally posted by NAME in URL
It would seem more appropriate to just say , rather than introduce the notion of a "standard COSE implementation". The latter would seem to involve a need to have a certification program for COSE implementations or something unnecessarily involved like that. I don't follow the implications of this. Can it be spelled out some more? I'll also note LGTM!

Revised text:
latest version, Issuers SHOULD use the "sequence_no" or "issuer_ts" attributes.  <ins> Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed </ins> Statement). 6.3.
Original text:
Signed Statement Issuers rely on being discoverable and represented as the responsible parties for their registered Signed Statements via <del> Transparency Services in a believable manner.  Analogously, </del>  Transparent Statement Consumers rely on verifiable trustworthiness assertions associated with Transparent Statements and their processing provenance in a believable manner.  If trust can be put <del> into the operations that record Signed Statements (i.e., a believable notarization function) in a secure, append-only Registry via online operations, the same trust can be put into a corresponding Receipt that is the resulting documentation of these online operations issued by the Transparency Services and that can be validated in offline operations. </del>  The Transparency Services specified in this architecture can be implemented by various different types of services in various types

Reviewer comments:
NAME Incorporated Review Comments!
Thanks NAME lets see if we can agree on append-only log|registry today so we can adapt and merge.
For the sake of clarity, suggesting "append only log"
LGTM

Revised text:
Signed Statement Issuers rely on being discoverable and represented as the responsible parties for their registered Signed Statements via  <ins> Transparency Services in a believable manner.  The issuer of a Signed Statement should be authenticated and authorized according to the registration policy of the transparency service.  Analogously, </ins> Transparent Statement Consumers rely on verifiable trustworthiness assertions associated with Transparent Statements and their processing provenance in a believable manner.  If trust can be put  <ins> into the operations that record Signed Statements in a secure, append-only log via online operations, the same trust can be put into the resulting transparent statement, issued by the Transparency Services and that can be validated in offline operations. </ins> The Transparency Services specified in this architecture can be implemented by various different types of services in various types
Original text:
components are based on the Concise Signing and Encryption standard specified in RFC9052, which is used to sign released Statements about Artifacts and to build and maintain a Merkle tree that functions as <del> an append-only Registry for corresponding Signed Statements.  The format and verification process for Registry-based transparency receipts are described in I-D.birkholz-scitt-receipts. </del>  1.1.

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
components are based on the Concise Signing and Encryption standard specified in RFC9052, which is used to sign released Statements about Artifacts and to build and maintain a Merkle tree that functions as  <ins> an append-only Registry for corresponding Signed Statements. </ins> 1.1.
Original text:
of COSE, and used to indicate that a signed object is a Signed Statement). <del> 6.3. </del>  Transparency Service implementations MUST indicate their support for registration policies and MUST check that all the policies indicated

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
of COSE, and used to indicate that a signed object is a Signed Statement).  <ins> 6.4. </ins> Transparency Service implementations MUST indicate their support for registration policies and MUST check that all the policies indicated
Original text:
guarantee out of the registration policies regardless of where it is registered. <del> 6.4. </del>  The same Signed Statement may be independently registered in multiple Transparency Services.  To register a Signed Statement, the service

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
guarantee out of the registration policies regardless of where it is registered.  <ins> 6.5. </ins> The same Signed Statement may be independently registered in multiple Transparency Services.  To register a Signed Statement, the service
Original text:
re-issue Receipts for the Registry content, for instance after a transient fault during Signed Statement Registration. <del> 6.5. </del>  This section provides additional implementation considerations.  The high-level validation algorithm is described in validation; the <del> Registry-specific details of checking Receipts are covered in I- D.birkholz-scitt-receipts. </del>  Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
re-issue Receipts for the Registry content, for instance after a transient fault during Signed Statement Registration.  <ins> 6.6. </ins> This section provides additional implementation considerations.  The high-level validation algorithm is described in validation; the  <ins> Registry-specific details of checking Receipts are covered in -COMTRE. </ins> Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency