jiebi/TextFlow huggingface dataset:
Original text:
structure, together with the hash itself. As part of the signature verification, the receiver MUST make sure <del> that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use. </del>  RFC3161 provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing

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

Revised text:
structure, together with the hash itself. As part of the signature verification, the receiver MUST make sure  <ins> that the message imprint in the embedded timestamp token matches a hash of either the payload, signature, or signature fields, depending on the mode of use and type of COSE structure. </ins> RFC3161 provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing
Original text:
operation is desired. In this context, timestamp tokens are similar to a countersignature <del> RFC9338 made by the TSA. </del>  3.

Reviewer comments:
In , Orie commented that: The answer is obviously "no", but the fact that the question was raised seems to indicate that the reference to 9338 is potentially confusing. Note that if we removed it, nothing would change, which is an incentive to drop. Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >

Revised text:
operation is desired. In this context, timestamp tokens are similar to a countersignature  <ins> made by the TSA. </ins> 3.
Original text:
5. <del> The security considerations made in RFC3161 as well as those of RFC9338 apply. </del>  In the "Timestamp, then COSE" (TTC) sequence of operation, the TSA is given an opaque identifier (a cryptographic hash value) for the

Reviewer comments:
In , Orie commented that: The answer is obviously "no", but the fact that the question was raised seems to indicate that the reference to 9338 is potentially confusing. Note that if we removed it, nothing would change, which is an incentive to drop. Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >

Revised text:
5.  <ins> Please review the Security Considerations section in RFC3161; these considerations apply to this document as well. Also review the Security Considerations section in STD96; these considerations apply to this document as well, especially the need for implementations to protect private key material. </ins> In the "Timestamp, then COSE" (TTC) sequence of operation, the TSA is given an opaque identifier (a cryptographic hash value) for the
Original text:
This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE <del> message structures (COSE_Sign and COSE_Sign1).  This enables the use of established RFC 3161 timestamping infrastructure to prove the </del>  creation time of a message. 1.

Reviewer comments:
In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >

Revised text:
This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE  <ins> message structures ("COSE_Sign" and "COSE_Sign1").  This enables the use of established RFC 3161 timestamping infrastructure to prove the </ins> creation time of a message. 1.
Original text:
2. There are two different modes of composing COSE protection and <del> timestamping. </del>  2.1.

Reviewer comments:
In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >

Revised text:
2. There are two different modes of composing COSE protection and  <ins> timestamping, motivated by the usage scenarios discussed above. </ins> 2.1.
Original text:
There are two different modes of composing COSE protection and timestamping, motivated by the usage scenarios discussed above.  2.1. fig-timestamp-then-cose shows the case where a datum is first

Reviewer comments:
https://ietf-URL
NAME NAME please have a look
TSA is good enough

Revised text:
There are two different modes of composing COSE protection and timestamping, motivated by the usage scenarios discussed above. <ins> The diagrams in this section illustrate the processing flow of the specified modes.  For simplicity, only the "COSE_Sign1" processing is shown.  Similar diagrams for "COSE_Sign" can be derived by allowing multiple "private-key" boxes and replacing the label "[signature]" with "[signatures]". </ins> 2.1. fig-timestamp-then-cose shows the case where a datum is first
Original text:
The message imprint sent in the request to the TSA MUST be either: <del> the hash of the signature field of the COSE_Sign1 message. </del>  <del> the hash of the signatures field of the COSE_Sign message. </del>  In either case, to minimize dependencies, the hash algorithm SHOULD be the same as the algorithm used for signing the COSE message.  This

Reviewer comments:
https://ietf-URL
NAME NAME please have a look
TSA is good enough

Revised text:
The message imprint sent in the request to the TSA MUST be either:  <ins> the hash of the signature field of the "COSE_Sign1" message. </ins>  <ins> the hash of the signatures field of the "COSE_Sign" message. </ins> In either case, to minimize dependencies, the hash algorithm SHOULD be the same as the algorithm used for signing the COSE message.  This
Original text:
The original datum becomes the payload of the signed COSE message.  2.2. fig-cose-then-timestamp shows the case where the signature(s) field

Reviewer comments:
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat

Revised text:
The original datum becomes the payload of the signed COSE message. <ins> The message imprint sent to the TSA (RFC3161) MUST be the hash of the payload field of the COSE signed object. </ins> 2.2. fig-cose-then-timestamp shows the case where the signature(s) field
Original text:
3. <del> To carry RFC 3161 timestamp tokens in COSE signed messages, a new COSE header parameter, "rfc3161-tst", is defined as follows: </del>  <del> Name: rfc3161-tst </del>  Label: TBD

Reviewer comments:
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat

Revised text:
3.  <ins> The two modes described in sec-timestamp-then-cose and sec-cose-then- timestamp use different inputs into the timestamping machinery, and consequently create different kinds of binding between COSE and TST. To clearly separate their semantics two different COSE header parameters are defined as described in the following subsections. 3.1. The "3161-ttc" COSE </ins>  <ins> header parameter MUST be used for the mode described in sec- timestamp-then-cose. The "3161-ttc" protected header is defined as follows: Name: 3161-ttc </ins> Label: TBD
Original text:
Description: RFC 3161 timestamp token <del> Reference: RFCthis </del>  The content of the byte string are the bytes of the DER-encoded RFC 3161 TimeStampToken structure. <del> When used as described in sec-timestamp-then-cose, the message imprint sent to the TSA (RFC3161) MUST be the hash of the payload field of the COSE signed object. </del>  <del> When used as described in sec-cose-then-timestamp, the message imprint sent in the request to the TSA MUST be either: </del>  the hash of the signature field of the COSE_Sign1.

Reviewer comments:
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat

Revised text:
Description: RFC 3161 timestamp token  <ins> Reference: sec-tst-hdr-ttc of RFCthis </ins> The content of the byte string are the bytes of the DER-encoded RFC 3161 TimeStampToken structure.  <ins> 3.2. The "3161-ctt" COSE </ins>  <ins> header parameter MUST be used for the mode described in sec-cose- then-timestamp. The message imprint sent in the request to the TSA MUST be either: </ins> the hash of the signature field of the COSE_Sign1.
Original text:
may not be possible if the timestamp token has been obtained outside the processing context in which the COSE object is assembled.  RFC 3161 timestamp tokens use CMS as signature envelope format. STD70 provides the details about signature verification, and RFC3161 provides the details specific to timestamp token validation.  The

Reviewer comments:
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat

Revised text:
may not be possible if the timestamp token has been obtained outside the processing context in which the COSE object is assembled. <ins> The "3161-ctt" unprotected header is defined as follows: Name: 3161-ctt Label: TBD Value Type: bstr Value Registry: none Description: RFC 3161 timestamp token Reference: sec-tst-hdr-ctt of RFCthis 4. </ins> RFC 3161 timestamp tokens use CMS as signature envelope format. STD70 provides the details about signature verification, and RFC3161 provides the details specific to timestamp token validation.  The
Original text:
As part of the signature verification, the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of <del> use.. </del>  <del> Guidance is illustrated in RFC3161 via an example that shows how timestamp tokens can be used during signature verification of a timestamped message when using X.509 certificates. </del>  <del> 4. </del>  The security considerations made in RFC3161 as well as those of RFC9338 apply. <del> 5. </del>  <del> IANA is requested to add the COSE Header parameter described in sec- tst-hdr to the "COSE Header Parameters" of the IANA.cose registry. </del> 

Reviewer comments:
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat

Revised text:
As part of the signature verification, the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of  <ins> use. </ins>  <ins> RFC3161 provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing X.509 certificates. </ins>  <ins> 5. </ins> The security considerations made in RFC3161 as well as those of RFC9338 apply.  <ins> 6. </ins>  <ins> IANA is requested to add the two COSE Header parameters described in sec-tst-hdr to the "COSE Header Parameters" of the IANA.cose registry. </ins>
Original text:
Trust in the TS itself is supported both by protecting their implementation (using, for instance, replication, trusted hardware, <del> and system attestation) and by enabling independent audits of the correctness and consistency of its ledger, thereby holding the </del>  organization accountable that operates it.  Unlike CT, where independent auditors are responsible for enforcing the consistency of multiple independent instances of the same global ledger, we require

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
Trust in the TS itself is supported both by protecting their implementation (using, for instance, replication, trusted hardware,  <ins> and remote attestation of systems) and by enabling independent audits of the correctness and consistency of its ledger, thereby holding the </ins> organization accountable that operates it.  Unlike CT, where independent auditors are responsible for enforcing the consistency of multiple independent instances of the same global ledger, we require
Original text:
of Supply Chain Integrity, Transparency, and Trust throughout this document.  When used in text, the corresponding terms are capitalized.  To ensure readability, only a core set of terms is <del> included in this section. </del>  4.

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
of Supply Chain Integrity, Transparency, and Trust throughout this document.  When used in text, the corresponding terms are capitalized.  To ensure readability, only a core set of terms is  <ins> included in this section.[^1] </ins> 4.