CBOR Object Signing and Encryption (COSE) Header Parameter for Timestamp Tokens as Defined in RFC 3161
Extracted elements (21)
The primary motivation for CTT is 'long-term signatures' — signatures that remain verifiable after the signing certificate expires. The signer acquires a fresh TST covering the signature from a TSA, which proves the signing certificate was valid at signing time, preventing subsequent denial by the signer.
TTC mode was introduced to support notarization via transparency services. The TST must be in the protected (signed) part of the COSE message so it survives immutable append-only log registration; placing it in unprotected headers would allow loss or tampering during registration.
Two distinct modes are defined because the semantic meaning differs: CTT (COSE, Then Timestamp) records when a signature was created by timestamping the signature field, while TTC (Timestamp, Then COSE) embeds a payload timestamp in the protected header to survive immutable registration at a transparency service. Because these semantics differ, two separate header parameters are required.
The 3161-ctt and 3161-ttc parameters are defined for COSE_Sign and COSE_Sign1 only. For COSE_Sign, the MessageImprint input in CTT mode is the entire CBOR-encoded signatures array (not individual signatures), enabling a single TST to cover all signers.
Timestamp tokens use CMS (RFC 5652) as the signature envelope format and RFC 3161 for timestamp token validation. The TSTInfo payload within the CMS SignedData contains the MessageImprint, including the hash algorithm OID, enabling receivers to identify the algorithm without out-of-band negotiation.
As part of signature verification, the receiver MUST verify that the MessageImprint in the embedded timestamp token matches a hash of either the payload, signature, or signatures field, depending on the mode of use and COSE structure type.
For 3161-ctt, the MessageImprint sent to the TSA MUST be the hash of the CBOR-encoded signature field of a COSE_Sign1, or the hash of the CBOR-encoded signatures field of a COSE_Sign. Importantly, the bstr heading bytes (e.g., 0x5840 for a 64-byte signature) are included in the input to the hash.
For 3161-ttc, the MessageImprint sent to the TSA MUST be the hash of the payload bytes of the COSE Signed Message, excluding the bstr wrapping — only the raw payload bytes are hashed.
Implementers MUST clearly differentiate between TSA timestamps 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). Failing to distinguish can lead to accepting signatures created after key revocation based on older payload-only timestamps.
In both modes, the hash algorithm used in the MessageImprint SHOULD be the same as the algorithm used for signing the COSE message, to minimize dependencies. An exception is permitted when the TST is obtained outside the COSE assembly context or when the timestamp requester and COSE signer are different entities.
The 3161-ctt COSE unprotected header parameter MUST be used for CTT mode (Section 2.1), where the signature or signatures field of the COSE message is digested and submitted to the TSA.
The 3161-ttc COSE protected header parameter MUST be used for TTC mode (Section 2.2), where the payload of the COSE message is digested and submitted to the TSA.
The 3161-ctt COSE unprotected header parameter carries a DER-encoded RFC 3161 TimeStampToken (TST) bstr-wrapped in CBOR (Major type 2). It is used in CTT mode, where the COSE message is signed first and then its signature field is submitted to the TSA.
The 3161-ttc COSE protected header parameter carries a DER-encoded RFC 3161 TimeStampToken (TST) bstr-wrapped in CBOR (Major type 2). It is used in TTC mode, where the payload is hashed and submitted to the TSA before the COSE message is signed.
IANA has allocated two entries in the 'COSE Header Parameters' registry: '3161-ttc' (label 269, bstr, protected header, Timestamp Token per RFC 3161: Timestamp, Then COSE) and '3161-ctt' (label 270, bstr, unprotected header, Timestamp Token per RFC 3161: COSE, Then Timestamp).
An attacker who can manipulate relying party clocks (but not the TSA) can cause CMS validation to fail, causing a denial of service for timestamp validation in both CTT and TTC modes. Once a TST is obtained from the TSA, the TSA clock becomes the only reliable time source; local clock manipulation does not affect the TST itself.
In CTT mode, an attacker can manipulate the unprotected header by removing or replacing the TST. To mitigate this, the COSE Signed Message SHOULD be integrity-protected during transit and at rest, since the unprotected header provides no cryptographic binding to the signature.
In TTC mode, the TSA receives only an opaque cryptographic hash of the payload. To prevent disclosure of identical payloads over time or comparison with known payloads, the payload should be armored with a nonce shared with the recipient but not the TSA. Such an armoring mechanism is out of scope for this document.
Semantic confusion between CTT and TTC modes can cause critical vulnerabilities: validators MUST NOT interpret protected-header payload timestamps (TTC) as proof of signature creation time. Only TSA timestamps explicitly covering signature data (CTT) may be used for determining signature validity timing.
The resolution, accuracy, and precision of the TSA clock, plus the expected latency of round trips to and from the TSA, must be accounted for in implementations. These factors bound the precision with which timestamp evidence can be asserted.
Both 3161-ctt (label 270) and 3161-ttc (label 269) carry a bstr-encoded value containing a DER-encoded RFC 3161 TimeStampToken. The CBOR Major type 2 byte string wraps the raw DER bytes; no additional CBOR encoding is applied to the TST internals.