5. Security Considerations

Cette section conserve le texte RFC relatif aux COSE timestamp token header parameters, y compris CTT and TTC modes, TimeStampToken handling, MessageImprint computation, COSE_Sign and COSE_Sign1 examples, IANA registrations et security considerations.

Texte RFC original

5.  Security Considerations

   Please review the Security Considerations section in [RFC3161]; these
   considerations apply to this document as well.

   Also review the Security Considerations section in [RFC9052].  These
   considerations apply to this document as well, particularly with
   regard to the need for implementations to protect private key
   material.  Additionally, solutions based on the COSE header
   parameters defined in this document must be able to report
   compromised keys promptly.

   The following scenario assumes that 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 mode 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 COSE Signed
   Message 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 is out of scope for this document.

   The resolution, accuracy, and precision of the TSA clock, as well as
   the expected latency introduced by round trips to and from the TSA,
   must be taken into account when implementing solutions based on the
   COSE header parameters defined in this document.

5.1.  Avoiding Semantic Confusion

   CTT mode and TTC mode have different semantic meanings.  An
   implementation must ensure that the contents of the CTT and TTC
   headers are interpreted according to their specific semantics.  In
   particular, symmetric to the signature and assembly mechanics, each
   mode has its own separate verification algorithm.

   Implementers MUST clearly differentiate between TSA timestamps
   [RFC3161] proving the existence of payload data at an earlier point
   in time (TTC) and timestamps explicitly providing evidence of the
   existence of the cryptographic signature (CTT).  Failure to clearly
   distinguish between these timestamp semantics can result in
   vulnerabilities, such as incorrectly accepting signatures created
   after key revocation based on older payload-only timestamps.
   Validators must not interpret protected-header payload timestamps as
   proof of signature creation time and should rely exclusively on TSA
   timestamps [RFC3161] explicitly covering signature data for
   determining signature validity timing.