jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: The "3161-ttc" protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). <ins> To minimize dependencies, the hash algorithm used for signing the COSE message SHOULD be the same as the algorithm used in the RFC3161 MessageImprint. </ins> 3.2. The "3161-ctt" COSE
Code change:
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

Related discussion:
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> <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
Code change:
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 >

Related discussion:
text: operation is desired. In this context, timestamp tokens are similar to a countersignature <del> RFC9338 made by the TSA. </del> <ins> made by the TSA. </ins> 3.
Code change:
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 >

Related discussion:
text: 5. <del> The security considerations made in RFC3161 as well as those of RFC9338 apply. </del> <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
Code change:
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 >

Related discussion:
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> <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.
Code change:
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 >

Related discussion:
text: (COSE) STD96 header parameters that carry the TimestampToken (TST) output of RFC 3161, thus allowing existing and widely deployed trust infrastructure to be used with COSE structures used for signing <del> (COSE_Sign and COSE_Sign1). </del> <ins> ("COSE_Sign" and "COSE_Sign1"). </ins> 1.1. <ins> This section discusses two use cases, each representing one of the two modes of use defined in modes. A first use case is a digital document signed alongside a trustworthy timestamp.  This is a common case in legal contracts.  In such scenario, the document signer wants to reinforce the claim that the document existed on a specific date.  To achieve this, the document signer acquires a fresh TST for the document from a TSA, combines it with the document, and then signs the bundle.  Later on, a relying party consuming the signed bundle can be certain that the document existed at the time specified by the TSA.  The relying party does not have to trust the signer's clock, which may have been maliciously altered or simply inaccurate. This usage scenario motivates the "Timestamp then COSE" mode defined in sec-timestamp-then-cose. A second use case is the notarization of a signed document by registering it at a Transparency Service.  This is common for accountability and auditability of issued documents.  Once a document is registered at a Transparency Service's append-only log, it cannot be changed.  In certain cases, the registration policy of a Transparency Service may require adding a trustworthy timestamp to the document at the time of registration.  This is done to enhance confidence in the timing of the registration, ensuring that the registration could not have occurred before a certain point in time. To achieve this, the Transparency Service acquires a TST from a TSA, bundles it alongside the signed document, and then registers it.  A relying party that wants to ascertain the time of registration of a given document does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. This usage scenario motivates the "COSE then Timestamp" mode described in sec-cose-then-timestamp. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
Code change:
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 >

Related discussion:
text: 2. There are two different modes of composing COSE protection and <del> timestamping. </del> <ins> timestamping, motivated by the usage scenarios discussed above. </ins> 2.1.
Code change:
https://ietf-URL
NAME NAME please have a look
TSA is good enough

Related discussion:
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
Code change:
https://ietf-URL
NAME NAME please have a look
TSA is good enough

Related discussion:
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> <ins> the hash of the signature field of the "COSE_Sign1" message. </ins> <del> the hash of the signatures field of the COSE_Sign message. </del> <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
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
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> <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> <del> Name: rfc3161-tst </del> <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
Code change:
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

Related discussion:
text: Description: RFC 3161 timestamp token <del> Reference: RFCthis </del> <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. <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> <ins> 3.2. The "3161-ctt" COSE </ins> <del> When used as described in sec-cose-then-timestamp, the message imprint sent in the request to the TSA MUST be either: </del> <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.
Code change:
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

Related discussion:
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