rfc9921.original   rfc9921.txt 
COSE H. Birkholz Internet Engineering Task Force (IETF) H. Birkholz
Internet-Draft Fraunhofer SIT Request for Comments: 9921 Fraunhofer SIT
Intended status: Standards Track T. Fossati Category: Standards Track T. Fossati
Expires: 2 March 2026 Linaro ISSN: 2070-1721 Linaro
M. Riechert M. Riechert
Microsoft Microsoft
29 August 2025 February 2026
COSE Header parameter for RFC 3161 Time-Stamp Tokens Concise Binary Object Representation (CBOR) Object Signing and
draft-ietf-cose-tsa-tst-header-parameter-08 Encryption (COSE) Header Parameter for Timestamp Tokens as Defined in
RFC 3161
Abstract Abstract
This document defines two CBOR Signing And Encrypted (COSE) header This document defines two Concise Binary Object Representation (CBOR)
parameters for incorporating RFC 3161-based timestamping into COSE Object Signing and Encryption (COSE) header parameters for
message structures (COSE_Sign and COSE_Sign1). This enables the use incorporating timestamping based on RFC 3161 into COSE message
of established RFC 3161 timestamping infrastructure in COSE-based structures (COSE_Sign and COSE_Sign1). This enables the use of
established timestamping infrastructure per RFC 3161 in COSE-based
protocols. protocols.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-cose-tsa-tst-header-
parameter/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-scitt/draft-birkholz-cose-tsa-tst-header-
parameter.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 2 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9921.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Use Cases
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation
2. Modes of Use . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Modes of Use
2.1. COSE then Timestamp (CTT) . . . . . . . . . . . . . . . . 4 2.1. COSE, then Timestamp (CTT)
2.2. Timestamp then COSE (TTC) . . . . . . . . . . . . . . . . 5 2.2. Timestamp, then COSE (TTC)
3. RFC 3161 Time-Stamp Tokens COSE Header Parameters . . . . . . 6 3. Timestamp Tokens per RFC 3161: COSE Header Parameters
3.1. 3161-ctt . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. 3161-ctt
3.1.1. MessageImprint Computation for COSE_Sign1 . . . . . . 7 3.1.1. MessageImprint Computation for COSE_Sign1
3.1.2. MessageImprint Computation for COSE_Sign . . . . . . 8 3.1.2. MessageImprint Computation for COSE_Sign
3.2. 3161-ttc . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. 3161-ttc
4. Timestamp Processing . . . . . . . . . . . . . . . . . . . . 10 4. Timestamp Processing
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations
5.1. Avoiding Semantic Confusion . . . . . . . . . . . . . . . 11 5.1. Avoiding Semantic Confusion
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations
7. Normative References . . . . . . . . . . . . . . . . . . . . 12 7. Normative References
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Examples
A.1. TTC . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.1. TTC
A.2. CTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. CTT
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses
1. Introduction 1. Introduction
RFC 3161 [RFC3161] provides a method to timestamp a message digest to RFC 3161 [RFC3161] provides a method for timestamping a message
prove that it was created before a given time. digest to prove that it was created before a given time.
This document defines two new CBOR Object Signing and Encryption This document defines two new CBOR Object Signing and Encryption
(COSE) [STD96] header parameters that carry the TimestampToken (TST) (COSE) [STD96] header parameters that carry the TimeStampToken (TST)
output of RFC 3161, thus allowing existing and widely deployed trust output [RFC3161], thus allowing existing and widely deployed trust
infrastructure to be used with COSE structures used for signing infrastructure to be used with COSE structures used for signing
(COSE_Sign and COSE_Sign1). (COSE_Sign and COSE_Sign1).
1.1. Use Cases 1.1. Use Cases
This section discusses two use cases, each representing one of the This section discusses two use cases, each representing one of the
two modes of use defined in Section 2. As the security two modes of use defined in Section 2. As the security
characteristics of the two cases differ, care must be taken when characteristics of the two cases differ, care must be taken when
choosing the appropriate mode for a given application. See choosing the appropriate mode for a given application. See
Section 5.1 for a discussion on the security of the implementations. Section 5.1 for a discussion on the security of the implementations.
The primary use case is that of "long-term signatures", i.e., The primary use case is that of "long-term signatures", i.e.,
signatures that can still be verified even after the signing signatures that can still be verified even after the signing
certificate has expired. This can address situations where it is certificate has expired. This can address situations where it is
important to prevent subsequent denial by the signer or to verify important to prevent subsequent denial by the signer or to verify
signatures made using (very) short-term certificates. To achieve signatures made using (very) short-term certificates. To achieve
this, the document signer acquires a fresh TST for the document's this, the document signer acquires a fresh TST for the document's
signature from a trusted TSA and concatenates it with the document. signature from a trusted Time Stamping Authority (TSA) [RFC3161] and
Later, when a relying party verifies the signed document and its concatenates it with the document. Later, when a relying party
associated TST, they can be certain that the document was signed _at verifies the signed document and its associated TST, they can be
least_ at the time specified by the TSA, and that the signing certain that the document was signed _at least_ at the time specified
certificate was valid at the time the signature was made. by the TSA and that the signing certificate was valid at the time the
signature was made.
This primary usage scenario motivates the "COSE then Timestamp" mode This primary usage scenario motivates the "COSE, then Timestamp" mode
described in Section 2.1. described in Section 2.1.
The second use case is new. It is the notarization of a signed The second use case is new. It is the notarization of a signed
document by registering it with a transparency service. This is document by registering it with a transparency service. This is
common practice for ensuring the accountability and auditability of common practice for ensuring the accountability and auditability of
issued documents, which are typically referred to as "statements" in issued documents, which are typically referred to as "statements" in
this context. It is also common practice to only register the signed this context. It is also common practice to only register the signed
parts of a statement (the "signed statement" portion) with a parts of a statement (the "signed statement" portion) with a
transparency service, in order to reduce the complexity of transparency service, in order to reduce the complexity of
consistency checks at a later stage, as well as avoiding the need to consistency checks at a later stage and to avoid the need to retrieve
retrieve or reconstruct unsigned parts. Once the signed parts of a or reconstruct unsigned parts. Once the signed parts of a document
document have been registered in the append-only log at a have been registered in the append-only log at a transparency
transparency service, the log entry cannot be changed. In order to service, the log entry cannot be changed. In order to avoid losing
avoid losing the TST during the registration process, the TST must be the TST during the registration process, the TST must be included in
included in the signed statement. To achieve this, the issuer the signed statement. To achieve this, the issuer acquires a TST
acquires a TST from a TSA, includes it in the to-be-signed part of from a TSA, includes it in the to-be-signed part of the statement so
the statement so that the resulting signed statement includes the that the resulting signed statement includes the TST, and then
TST, and then registers the signed parts (rendering it a "transparent registers the signed parts (rendering it a "transparent statement").
statement"). Later on, a relying party consuming the transparent Later on, a relying party consuming the transparent statement
statement including the TST can be certain that the statement was including the TST can be certain that the statement was signed by the
signed by the issuer _at least_ at the time specified by the TSA. If issuer _at least_ at the time specified by the TSA. If the issuer's
the issuer's signing key has expired (or been compromised), the signing key has expired (or has been compromised), the authenticity
authenticity of the statement can be ascertained by ensuring that no of the statement can be ascertained by ensuring that no revocation
revocation information was made public before the time asserted by information was made public before the time asserted by the issuer
the issuer and registered at the transparency service. and registered at the transparency service.
This new usage scenario motivates the "Timestamp then COSE" mode This new usage scenario motivates the "Timestamp, then COSE" mode
defined in Section 2.2. defined in Section 2.2.
1.2. Requirements Notation 1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 4, line 31 skipping to change at line 158
There are two different modes of composing COSE protection and There are two different modes of composing COSE protection and
timestamping, motivated by the usage scenarios discussed above. timestamping, motivated by the usage scenarios discussed above.
The diagrams in this section illustrate the processing flow of the The diagrams in this section illustrate the processing flow of the
specified modes. For simplicity, only the COSE_Sign1 processing is specified modes. For simplicity, only the COSE_Sign1 processing is
shown. Similar diagrams for COSE_Sign can be derived by allowing shown. Similar diagrams for COSE_Sign can be derived by allowing
multiple private-key parallelogram boxes and replacing the label multiple private-key parallelogram boxes and replacing the label
[signature] with [signatures]. [signature] with [signatures].
2.1. COSE then Timestamp (CTT) 2.1. COSE, then Timestamp (CTT)
Figure 1 shows the case where the signature(s) field of the signed Figure 1 shows the case where the signature(s) field of the signed
COSE object is digested and submitted to a TSA to be timestamped. COSE object is digested and submitted to a TSA to be timestamped.
The obtained timestamp token is then added back as an unprotected The obtained timestamp token is then added back as an unprotected
header into the same COSE object. header into the same COSE object.
This mode is utilized when a record of the timing of the signature This mode is utilized when a record of the timing of the signature
operation is desired. operation is desired.
.--------. .-----. .--------. .-----.
skipping to change at page 5, line 37 skipping to change at line 200
| v v '------+------' | v v '------+------'
| .-------+------------+-----. | | .-------+------------+-----. |
'--->+ rfc3161-ctt COSE +<-----' '--->+ rfc3161-ctt COSE +<-----'
'--------------------------' '--------------------------'
Figure 1: COSE, then Timestamp (CTT) Figure 1: COSE, then Timestamp (CTT)
In this context, timestamp tokens are similar to a countersignature In this context, timestamp tokens are similar to a countersignature
made by the TSA. made by the TSA.
2.2. Timestamp then COSE (TTC) 2.2. Timestamp, then COSE (TTC)
Figure 2 shows the case where a datum is first digested and submitted Figure 2 shows the case where a datum is first digested and submitted
to a TSA to be timestamped. to a TSA to be timestamped.
This mode is used to wrap the signed document and its timestamp This mode is used to wrap the signed document and its timestamp
together in an immutable payload. together in an immutable payload.
A signed COSE message is then built as follows: A signed COSE message is then built as follows:
* The obtained timestamp token is added to the protected headers, * The obtained timestamp token is added to the protected headers.
* The original datum becomes the payload of the signed COSE message. * The original datum becomes the payload of the signed COSE message.
.--------. .-----. .--------. .-----.
| Signer | | TSA | | Signer | | TSA |
+--------+----------------------------------. +-----+-------------. +--------+----------------------------------. +-----+-------------.
| .-------------. .-------. | | .-------------. | | .-------------. .-------. | | .-------------. |
| / private-key / | nonce +-------->+ / private-key / | | / private-key / | nonce +-------->+ / private-key / |
| '-+-----------' '-------' | | '------+------' | | '-+-----------' '-------' | | '------+------' |
| | .---------. | | | | | | .---------. | | | |
skipping to change at page 6, line 35 skipping to change at line 244
| | | | .-----. | | | | | .-----. |
[protected] [payload] [signature] | | ... | | [protected] [payload] [signature] | | ... | |
| | | | '-----' | | | | | '-----' |
| v v '------+------' | v v '------+------'
| .-------+------------+-----. | | .-------+------------+-----. |
'--->+ rfc3161-ttc COSE +<-----' '--->+ rfc3161-ttc COSE +<-----'
'--------------------------' '--------------------------'
Figure 2: Timestamp, then COSE (TTC) Figure 2: Timestamp, then COSE (TTC)
3. RFC 3161 Time-Stamp Tokens COSE Header Parameters 3. Timestamp Tokens per RFC 3161: COSE Header Parameters
The two modes described in Section 2.2 and Section 2.1 use different The two modes described in Sections 2.2 and 2.1 use different inputs
inputs into the timestamping machinery, and consequently create into the timestamping machinery and consequently create different
different kinds of binding between COSE and TST. To clearly separate kinds of bindings between COSE and TST. To clearly separate their
their semantics two different COSE header parameters are defined as semantics, two different COSE header parameters are defined as
described in the following subsections. described in the following subsections.
3.1. 3161-ctt 3.1. 3161-ctt
The 3161-ctt COSE _unprotected_ header parameter MUST be used for the The 3161-ctt COSE _unprotected_ header parameter MUST be used for the
mode described in Section 2.1. mode described in Section 2.1.
The 3161-ctt unprotected header parameter contains a DER-encoded The 3161-ctt unprotected header parameter contains a DER-encoded
RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). TimeStampToken [RFC3161] wrapped in a CBOR byte string (Major type
2).
The MessageImprint sent in the request to the TSA MUST be: The MessageImprint sent in the request to the TSA MUST be
* the hash of the CBOR-encoded signature field of the COSE_Sign1 * the hash of the CBOR-encoded signature field of the COSE_Sign1
message, or message, or
* the hash of the CBOR-encoded signatures field of the COSE_Sign * the hash of the CBOR-encoded signatures field of the COSE_Sign
message. message.
In either case, to minimize dependencies, the hash algorithm SHOULD In either case, to minimize dependencies, the hash algorithm SHOULD
be the same as the algorithm used for signing the COSE message. This be the same as the algorithm used for signing the COSE message. This
may not be possible if the timestamp token has been obtained outside may not be possible if the timestamp token has been obtained outside
the processing context in which the COSE object is assembled. the processing context in which the COSE object is assembled.
Refer to Section 3.1.1 and Section 3.1.2 for concrete examples of Refer to Sections 3.1.1 and 3.1.2 for concrete examples of
MessageImprint computation. MessageImprint computation.
3.1.1. MessageImprint Computation for COSE_Sign1 3.1.1. MessageImprint Computation for COSE_Sign1
The following illustrates how MessageImprint is computed using a The following illustrates how MessageImprint is computed using a
sample COSE_Sign1 message. sample COSE_Sign1 message.
Given the COSE_Sign1 message Given the COSE_Sign1 message
18( 18(
skipping to change at page 9, line 38 skipping to change at line 386
80 3F AD A2 91 2D 6B 7A 83 3A 27 BD 96 1C C0 5B 80 3F AD A2 91 2D 6B 7A 83 3A 27 BD 96 1C C0 5B
C1 CC 16 47 59 B1 C5 6F 7A A7 71 E4 E2 15 26 F7 C1 CC 16 47 59 B1 C5 6F 7A A7 71 E4 E2 15 26 F7
} }
3.2. 3161-ttc 3.2. 3161-ttc
The 3161-ttc COSE _protected_ header parameter MUST be used for the The 3161-ttc COSE _protected_ header parameter MUST be used for the
mode described in Section 2.2. mode described in Section 2.2.
The 3161-ttc protected header parameter contains a DER-encoded The 3161-ttc protected header parameter contains a DER-encoded
RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). TimeStampToken [RFC3161] wrapped in a CBOR byte string (Major type
2).
The MessageImprint sent to the TSA (Section 2.4 of [RFC3161]) MUST be The MessageImprint sent to the TSA (Section 2.4 of [RFC3161]) MUST be
the hash of the payload of the COSE signed object. This does not the hash of the payload of the COSE signed object. This does not
include the bstr-wrapping, only the payload bytes. (For an example, include the bstr wrapping -- only the payload bytes. (For an
see Appendix A.1.) example, see Appendix A.1.)
To minimize dependencies, the hash algorithm used for signing the To minimize dependencies, the hash algorithm used for signing the
COSE message SHOULD be the same as the algorithm used in the RFC3161 COSE message SHOULD be the same as the algorithm used in the
MessageImprint. However, this may not be possible if the timestamp MessageImprint [RFC3161]. However, this may not be possible if the
requester and the COSE message signer are different entities. timestamp requester and the COSE message signer are different
entities.
4. Timestamp Processing 4. Timestamp Processing
RFC 3161 timestamp tokens use CMS as signature envelope format. Timestamp tokens [RFC3161] use Cryptographic Message Syntax (CMS) as
[STD70] provides the details about signature verification, and the signature envelope format. [STD70] provides details about
[RFC3161] provides the details specific to timestamp token signature verification, and [RFC3161] provides details specific to
validation. The payload of the signed timestamp token is the TSTInfo timestamp token validation. The payload of the signed timestamp
structure defined in [RFC3161], which contains the MessageImprint token is the TSTInfo structure defined in [RFC3161], which contains
that was sent to the TSA. The hash algorithm is contained in the the MessageImprint that was sent to the TSA. The hash algorithm is
MessageImprint structure, together with the hash itself. contained in the MessageImprint structure, together with the hash
itself.
As part of the signature verification, the receiver MUST make sure As part of the signature verification, the receiver MUST make sure
that the MessageImprint in the embedded timestamp token matches a that the MessageImprint in the embedded timestamp token matches a
hash of either the payload, signature, or signature fields, depending hash of either the payload, signature, or signature fields, depending
on the mode of use and type of COSE structure. on the mode of use and type of COSE structure.
Appendix B of [RFC3161] provides an example that illustrates how Appendix B of [RFC3161] provides an example that illustrates how
timestamp tokens can be used to verify signatures of a timestamped timestamp tokens can be used to verify signatures of a timestamped
message when utilizing X.509 certificates. message when utilizing X.509 certificates.
skipping to change at page 10, line 36 skipping to change at line 432
Please review the Security Considerations section in [RFC3161]; these Please review the Security Considerations section in [RFC3161]; these
considerations apply to this document as well. considerations apply to this document as well.
Also review the Security Considerations section in [STD96]. These Also review the Security Considerations section in [STD96]. These
considerations apply to this document as well, particularly with considerations apply to this document as well, particularly with
regard to the need for implementations to protect private key regard to the need for implementations to protect private key
material. Additionally, solutions based on the COSE header material. Additionally, solutions based on the COSE header
parameters defined in this document must be able to report parameters defined in this document must be able to report
compromised keys promptly. compromised keys promptly.
The following scenario assumes an attacker can manipulate the clocks The following scenario assumes that an attacker can manipulate the
on the COSE signer and its relying parties, but not the TSA. It is clocks on the COSE signer and its relying parties, but not the TSA.
also assumed that the TSA is a trusted third party, so the attacker It is also assumed that the TSA is a trusted third party, so the
cannot impersonate the TSA and create valid timestamp tokens. In attacker cannot impersonate the TSA and create valid timestamp
such a setting, any tampering with the COSE signer's clock does not tokens. In such a setting, any tampering with the COSE signer's
have an impact because, once the timestamp is obtained from the TSA, clock does not have an impact, because once the timestamp is obtained
it becomes the only reliable source of time. However, in both CTT from the TSA, it becomes the only reliable source of time. However,
and TTC mode, a denial of service can occur if the attacker can in both CTT mode and TTC mode, a denial of service can occur if the
adjust the relying party's clock so that the CMS validation fails. attacker can adjust the relying party's clock so that the CMS
This could disrupt the timestamp validation. validation fails. This could disrupt the timestamp validation.
In CTT mode, an attacker could manipulate the unprotected header by In CTT mode, an attacker could manipulate the unprotected header by
removing or replacing the timestamp. To avoid that, the signed COSE removing or replacing the timestamp. To avoid that, the signed COSE
object should be integrity protected during transit and at rest. object should be integrity protected during transit and at rest.
In TTC mode, the TSA is given an opaque identifier (a cryptographic In TTC mode, the TSA is given an opaque identifier (a cryptographic
hash value) for the payload. While this means that the content of hash value) for the payload. While this means that the content of
the payload is not directly revealed, to prevent comparison with the payload is not directly revealed, to prevent comparison with
known payloads or disclosure of identical payloads being used over known payloads or disclosure of identical payloads being used over
time, the payload would need to be armored, e.g., with a nonce that 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. 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 Such a mechanism can be employed inside the parameters described in
specification, but is out of scope for this document. this specification but is out of scope for this document.
The resolution, accuracy, and precision of the TSA clock, as well as The resolution, accuracy, and precision of the TSA clock, as well as
the expected latency introduced by round trips to and from the TSA the expected latency introduced by round trips to and from the TSA,
must be taken into account when implementing solutions based on the must be taken into account when implementing solutions based on the
COSE header parameters defined in this document. COSE header parameters defined in this document.
5.1. Avoiding Semantic Confusion 5.1. Avoiding Semantic Confusion
CTT and TTC modes have different semantic meanings. An CTT mode and TTC mode have different semantic meanings. An
implementation must ensure that the contents of the CTT and TCC implementation must ensure that the contents of the CTT and TTC
headers are interpreted according to their specific semantics. In headers are interpreted according to their specific semantics. In
particular, symmetric to the signature and assembly mechanics, each particular, symmetric to the signature and assembly mechanics, each
mode has its own separate verification algorithm. mode has its own separate verification algorithm.
Implementers MUST clearly differentiate between RFC 3161 TSA Implementers MUST clearly differentiate between TSA timestamps
timestamps proving the existence of payload data at an earlier point [RFC3161] proving the existence of payload data at an earlier point
in time (TTC) and timestamps explicitly providing evidence of the in time (TTC) and timestamps explicitly providing evidence of the
existence of the cryptographic signature (CTT). Failure to clearly existence of the cryptographic signature (CTT). Failure to clearly
distinguish between these timestamp semantics can result in distinguish between these timestamp semantics can result in
vulnerabilities, such as incorrectly accepting signatures created vulnerabilities, such as incorrectly accepting signatures created
after key revocation based on older payload-only timestamps. after key revocation based on older payload-only timestamps.
Validators must not interpret protected-header payload timestamps as Validators must not interpret protected-header payload timestamps as
proof of signature creation time and should rely exclusively on RFC proof of signature creation time and should rely exclusively on TSA
3161 TSA timestamps explicitly covering signature data for timestamps [RFC3161] explicitly covering signature data for
determining signature validity timing. determining signature validity timing.
6. IANA Considerations 6. IANA Considerations
IANA has allocated the COSE header parameters defined in Table 1 in IANA has allocated the COSE header parameters defined in Table 1 in
the "COSE Header Parameters" registry [IANA.cose_header-parameters]. the "COSE Header Parameters" registry [IANA.cose_header-parameters]
as follows:
+==========+=======+=======+==========+=============+===========+ +==========+=======+=======+==========+=================+===========+
| Name | Label | Value | Value | Description | Reference | | Name | Label | Value | Value | Description | Reference |
| | | Type | Registry | | | | | | Type | Registry | | |
+==========+=======+=======+==========+=============+===========+ +==========+=======+=======+==========+=================+===========+
| 3161-ttc | 269 | bstr | - | RFC 3161 | RFCthis, | | 3161-ttc | 269 | bstr | - | timestamp | RFC 9921, |
| | | | | timestamp | Section | | | | | | token | Section |
| | | | | token: | 3.2 | | | | | | [RFC3161]: | 3.2 |
| | | | | Timestamp | | | | | | | Timestamp, | |
| | | | | then COSE | | | | | | | then COSE | |
+----------+-------+-------+----------+-------------+-----------+ +----------+-------+-------+----------+-----------------+-----------+
| 3161-ctt | 270 | bstr | - | RFC 3161 | RFCthis, | | 3161-ctt | 270 | bstr | - | timestamp | RFC 9921, |
| | | | | timestamp | Section | | | | | | token | Section |
| | | | | token: COSE | 3.1 | | | | | | [RFC3161]: | 3.1 |
| | | | | then | | | | | | | COSE, then | |
| | | | | Timestamp | | | | | | | Timestamp | |
+----------+-------+-------+----------+-------------+-----------+ +----------+-------+-------+----------+-----------------+-----------+
Table 1: New COSE Header Parameters Table 1: New COSE Header Parameters
7. Normative References 7. Normative References
[IANA.cose_header-parameters] [IANA.cose_header-parameters]
IANA, "COSE Header Parameters", IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose>. <https://www.iana.org/assignments/cose>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://doi.org/10.17487/RFC2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp "Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://doi.org/10.17487/RFC3161>. 2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://doi.org/10.17487/RFC8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STD70] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [STD70] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://doi.org/10.17487/RFC5652>. <https://www.rfc-editor.org/info/rfc5652>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://doi.org/10.17487/RFC9052>. <https://www.rfc-editor.org/info/rfc9052>.
Appendix A. Examples Appendix A. Examples
A.1. TTC A.1. TTC
The payload The payload
This is the content. 'This is the content.'
is hashed using SHA-256 to create the TimeStampReq object is hashed using SHA-256 to create the following TimeStampReq object
SEQUENCE { SEQUENCE {
INTEGER 1 INTEGER 1
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
NULL NULL
} }
OCTET STRING OCTET STRING
09 E6 38 D4 AA 95 FD 72 71 86 62 03 59 53 03 BC 09 E6 38 D4 AA 95 FD 72 71 86 62 03 59 53 03 BC
E2 32 F4 62 A9 4D 38 E3 93 77 3C D3 AA E3 F6 B0 E2 32 F4 62 A9 4D 38 E3 93 77 3C D3 AA E3 F6 B0
} }
BOOLEAN TRUE BOOLEAN TRUE
} }
which is sent to the Time Stamping Authority. which is sent to the TSA.
A TimeStampResp containing the following TimeStampToken is returned:
A TimeStampResp is returned which contains the TimeStampToken
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
[0] { [0] {
SEQUENCE { SEQUENCE {
INTEGER 3 INTEGER 3
SET { SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3) OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)
NULL NULL
} }
skipping to change at page 14, line 37 skipping to change at line 596
OCTET STRING OCTET STRING
09 E6 38 D4 AA 95 FD 72 71 86 62 03 59 53 03 BC 09 E6 38 D4 AA 95 FD 72 71 86 62 03 59 53 03 BC
E2 32 F4 62 A9 4D 38 E3 93 77 3C D3 AA E3 F6 B0 E2 32 F4 62 A9 4D 38 E3 93 77 3C D3 AA E3 F6 B0
} }
INTEGER 12096870 INTEGER 12096870
GeneralizedTime 29/08/2025 07:45:46 GMT GeneralizedTime 29/08/2025 07:45:46 GMT
BOOLEAN TRUE BOOLEAN TRUE
[...] [...]
The contents of the TimeStampToken are bstr-wrapped and added to the The contents of the TimeStampToken are bstr-wrapped and added to the
protected headers bucket which is then signed alongside the original protected headers bucket, which is then signed alongside the original
payload to obtain the COSE_Sign1 object payload to obtain the COSE_Sign1 object.
18([ 18([
<<{1: -7, 269: h'3082154906092a864886f70d010702a082153a308215 <<{1: -7, 269: h'3082154906092a864886f70d010702a082153a308215
36020103310f300d0609608648016503040203050030820184060b2a864886f70d010 36020103310f300d0609608648016503040203050030820184060b2a864886f70d010
9100104a08201730482016f3082016b02010106042a0304013031300d060960864801 9100104a08201730482016f3082016b02010106042a0304013031300d060960864801
65030402010500042009e638d4aa95fd7271866203595303bce232f462a94d38e3937 65030402010500042009e638d4aa95fd7271866203595303bce232f462a94d38e3937
73cd3aae3f6b0020400b89566180f32303235303832393037343534365a0101ffa082 73cd3aae3f6b0020400b89566180f32303235303832393037343534365a0101ffa082
0111a482010d308201093111300f060355040a13084672656520545341310c300a060 0111a482010d308201093111300f060355040a13084672656520545341310c300a060
355040b130354534131763074060355040d136d546869732063657274696669636174 355040b130354534131763074060355040d136d546869732063657274696669636174
65206469676974616c6c79207369676e7320646f63756d656e747320616e642074696 65206469676974616c6c79207369676e7320646f63756d656e747320616e642074696
skipping to change at page 18, line 17 skipping to change at line 768
11e33482e45c9b4f948bff15eba70'}>>, 11e33482e45c9b4f948bff15eba70'}>>,
{4: '11'}, {4: '11'},
'This is the content.', 'This is the content.',
h'f5f0f27964f178dcb2254b30fdfdc48abc4499beaea7cb80f4004f30403 h'f5f0f27964f178dcb2254b30fdfdc48abc4499beaea7cb80f4004f30403
f13a44bcca24fc61c5d71d3823bac04b923011dc7d31de35df1aefcd5a8ec5fe0fe6e f13a44bcca24fc61c5d71d3823bac04b923011dc7d31de35df1aefcd5a8ec5fe0fe6e
' '
]) ])
A.2. CTT A.2. CTT
Starting with the following COSE_Sign1 object Starting with the following COSE_Sign1 object,
18( 18(
[ [
/ protected h'a10126' / << { / protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ kid / 4:'11' / kid / 4:'11'
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4d / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4d
25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5a4 25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5a4
c345cacb36' c345cacb36'
] ]
) )
The CBOR-encoded signature field is hashed using SHA-256 to create the CBOR-encoded signature field is hashed using SHA-256 to create
the following TimeStampReq object the following TimeStampReq object
SEQUENCE { SEQUENCE {
INTEGER 1 INTEGER 1
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
NULL NULL
} }
OCTET STRING OCTET STRING
DD 94 71 EF E7 43 C4 05 13 35 DF 8F 6D 28 82 F3 DD 94 71 EF E7 43 C4 05 13 35 DF 8F 6D 28 82 F3
BA DC 38 77 00 F7 ED 3F 70 91 67 2A 3E EA F7 C8 BA DC 38 77 00 F7 ED 3F 70 91 67 2A 3E EA F7 C8
} }
BOOLEAN TRUE BOOLEAN TRUE
} }
which is sent to the Time Stamping Authority. which is sent to the TSA.
A TimeStampResp is returned which contains the following A TimeStampResp containing the following TimeStampToken is returned:
TimeStampToken
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
[0] { [0] {
SEQUENCE { SEQUENCE {
INTEGER 3 INTEGER 3
SET { SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3) OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)
NULL NULL
skipping to change at page 19, line 42 skipping to change at line 840
DD 94 71 EF E7 43 C4 05 13 35 DF 8F 6D 28 82 F3 DD 94 71 EF E7 43 C4 05 13 35 DF 8F 6D 28 82 F3
BA DC 38 77 00 F7 ED 3F 70 91 67 2A 3E EA F7 C8 BA DC 38 77 00 F7 ED 3F 70 91 67 2A 3E EA F7 C8
} }
INTEGER 12100074 INTEGER 12100074
GeneralizedTime 29/08/2025 07:53:00 GMT GeneralizedTime 29/08/2025 07:53:00 GMT
BOOLEAN TRUE BOOLEAN TRUE
[...] [...]
The contents of the TimeStampToken are bstr-wrapped and added to the The contents of the TimeStampToken are bstr-wrapped and added to the
unprotected headers bucket in the original COSE_Sign1 object to unprotected headers bucket in the original COSE_Sign1 object to
obtain the following obtain the following:
18( 18(
[ [
/ protected h'a10126' / << { / protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ 3161-ctt / 270 : h'3082154906092a864886f70d010702a082153a3082 / 3161-ctt / 270 : h'3082154906092a864886f70d010702a082153a3082
1536020103310f300d0609608648016503040203050030820184060b2a864886f70d0 1536020103310f300d0609608648016503040203050030820184060b2a864886f70d0
109100104a08201730482016f3082016b02010106042a0304013031300d0609608648 109100104a08201730482016f3082016b02010106042a0304013031300d0609608648
skipping to change at page 23, line 27 skipping to change at line 1018
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4 / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5 d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36' a4c345cacb36'
] ]
) )
Acknowledgments Acknowledgments
The editors would like to thank Alexey Melnikov, Carl Wallace, The authors would like to thank Alexey Melnikov, Carl Wallace,
Carsten Bormann, Deb Cooley, Eric Vyncke, Francesca Palombini, Carsten Bormann, Deb Cooley, Éric Vyncke, Francesca Palombini,
Leonard Rosenthol, Linda Dunbar, Michael B. Jones, Michael Prorock, Leonard Rosenthol, Linda Dunbar, Michael B. Jones, Michael Prorock,
Mike Bishop, Mohamed Boucadair, Orie Steele, Roman Danyliw, Shuping Mike Bishop, Mohamed Boucadair, Orie Steele, Roman Danyliw, Shuping
Peng, Stefan Santesson, Steve Lasker, and Yingzhen Qu for their Peng, Stefan Santesson, Steve Lasker, and Yingzhen Qu for their
reviews and comments. reviews and comments.
Contributors Contributors
Carsten Bormann Carsten Bormann
Email: cabo@tzi.org Email: cabo@tzi.org
Carsten contributed part of the security considerations. Carsten contributed part of the security considerations.
 End of changes. 54 change blocks. 
173 lines changed or deleted 167 lines changed or added

This html diff was produced by rfcdiff 1.48.