Code change:
considerations apply to this document as well, especially the need for implementations to protect private key material. <del> In the "Timestamp, then COSE" (TTC) sequence of operation, the TSA is given an opaque identifier (a cryptographic hash value) for the payload.  While this means that the content of the payload is not directly revealed, to prevent comparison with known payloads or disclosure of identical payloads being used over time, the payload would need to be armored, e.g., with a nonce that is shared with the recipient of the header parameter but not the TSA.  Such a mechanism can be employed inside the ones described in this specification, but is out of scope for this document. </del> <ins> The following scenario assumes an attacker can manipulate the clocks on the COSE signer and its relying parties, but not the TSA.  It is also assumed that the TSA is a trusted third party, so the attacker cannot impersonate the TSA and create valid timestamp tokens.  In such a setting, any tampering with the COSE signer's clock does not have an impact because, once the timestamp is obtained from the TSA, it becomes the only reliable source of time.  However, in both CTT and TTC mode, a denial of service can occur if the attacker can adjust the relying party's clock so that the CMS validation fails. This could disrupt the timestamp validation. In CTT mode, an attacker could manipulate the unprotected header by removing or replacing the timestamp.  To avoid that, the signed COSE object should be integrity protected during transit and at rest. In TTC mode, the TSA is given an opaque identifier (a cryptographic hash value) for the payload.  While this means that the content of the payload is not directly revealed, to prevent comparison with known payloads or disclosure of identical payloads being used over time, the payload would need to be armored, e.g., with a nonce that is shared with the recipient of the header parameter but not the TSA. Such a mechanism can be employed inside the ones described in this specification, but is out of scope for this document. </ins> 6.

Related discussion:
text: In CTT that can't happen unless you can predict the COSE signature, i.e., the content of the datum. Sorry, I don't understand this. You are making a similar point in which I am also failing to grok. To me, a timestamp asserts the existence of a datum at least at the point in time when the timestamp for that datum is created. I cannot fathom an attack in which pushing the existence of the datum back in time is an attack on the intended use of the datum.
In , Orie commented that: "Security considerations seem light."_ We could add prose that succinctly describes: the attacker model (i.e., a dodgy individual trying to manipulate the COSE signer's or the relying party's local clocks), and the trust model (i.e., local clocks are untrusted, and the TSA clock is trusted by both the COSE signer and its relying parties)
The only interesting attack is when the attacker moves the RP's clock in the future.
ltgm 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 >