Internet DRAFT - draft-ietf-cose-tsa-tst-header-parameter
draft-ietf-cose-tsa-tst-header-parameter
COSE H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track T. Fossati
Expires: 27 August 2024 Linaro
M. Riechert
Microsoft
24 February 2024
COSE Header parameter for RFC 3161 Time-Stamp Tokens
draft-ietf-cose-tsa-tst-header-parameter-02
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.,
COSE_Sign and COSE_Sign1) with existing RFC 3161-based timestamping
infrastructure.
Discussion Venues
This note is to be removed before publishing as an RFC.
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
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 August 2024.
Birkholz, et al. Expires 27 August 2024 [Page 1]
Internet-Draft TST Header February 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Modes of use . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Timestamp then COSE (TTC) . . . . . . . . . . . . . . . . 3
2.2. COSE then Timestamp (CTT) . . . . . . . . . . . . . . . . 3
3. RFC 3161 Time-Stamp Tokens COSE Header Parameters . . . . . . 4
3.1. 3161-ttc . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. 3161-ctt . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Timestamp Processing . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
RFC 3161 [RFC3161] provides a method to timestamp a message digest to
prove that it was created before a given time.
This document defines a new COSE [STD96] header parameter that
carries the TimestampToken (TST) output of RFC 3161, thus allowing
existing and widely deployed trust infrastructure to be used with
COSE structures used for signing (COSE_Sign and COSE_Sign1).
Birkholz, et al. Expires 27 August 2024 [Page 2]
Internet-Draft TST Header February 2024
1.1. Requirements Notation
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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Modes of use
There are two different modes of composing COSE protection and
timestamping.
2.1. Timestamp then COSE (TTC)
Figure 1 shows the case where a datum is first digested and submitted
to a TSA to be timestamped.
A signed COSE message is then built as follows:
* The obtained timestamp token is added to the protected headers,
* The original datum becomes the payload of the signed COSE message.
.---------. .---------------. .----------------------.
| payload +------------->| Sig_structure +---->| COSE_Sign/COSE_Sign1 |
'----+----' '---------------' '----------------------'
| ^
| .---. |
| | | .-----. |
'--->| TSA +---->| TST +---'
| | '-----'
'---'
Figure 1: Timestamp, then COSE (TTC)
The message imprint sent to the TSA (Section 2.4 of [RFC3161]) MUST
be the hash of the payload field of the COSE signed object.
2.2. COSE then Timestamp (CTT)
Figure 2 shows the case where the signature(s) field of the signed
COSE object is digested and submitted to a TSA to be timestamped.
The obtained timestamp token is then added back as an unprotected
header into the same COSE object.
Birkholz, et al. Expires 27 August 2024 [Page 3]
Internet-Draft TST Header February 2024
.----------------------. .-----.
| COSE_Sign/COSE_Sign1 |<--------+ TST |
'----+-----------------' '-----'
| ^
v |
.----------------------. |
| signatures/signature | |
'----+-----------------' |
| .---. |
| | | |
'------------------->| TSA +---'
| |
'---'
Figure 2: COSE, then Timestamp (CTT)
In this context, timestamp tokens are similar to a countersignature
[RFC9338] made by the TSA.
3. RFC 3161 Time-Stamp Tokens COSE Header Parameters
The two modes described in Section 2.1 and Section 2.2 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. 3161-ttc
The 3161-ttc COSE _protected_ header parameter MUST be used for the
mode described in Section 2.1.
The 3161-ttc protected header is defined as follows:
* Name: 3161-ttc
* Label: TBD
* Value Type: bstr
* Value Registry: [IANA.cose]
* Description: RFC 3161 timestamp token
* Reference: Section 3.1 of RFCthis
The content of the byte string are the bytes of the DER-encoded RFC
3161 TimeStampToken structure.
Birkholz, et al. Expires 27 August 2024 [Page 4]
Internet-Draft TST Header February 2024
3.2. 3161-ctt
The 3161-ctt COSE _unprotected_ header parameter MUST be used for the
mode described in Section 2.2.
The message imprint sent in the request to the TSA MUST be either:
* the hash of the signature field of the COSE_Sign1 message.
* the hash of the signatures field of the COSE_Sign message.
In either case, to minimize dependencies, the hash algorithm SHOULD
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
the processing context in which the COSE object is assembled.
The 3161-ctt unprotected header is defined as follows:
* Name: 3161-ctt
* Label: TBD
* Value Type: bstr
* Value Registry: [IANA.cose]
* Description: RFC 3161 timestamp token
* Reference: Section 3.2 of RFCthis
4. Timestamp Processing
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 payload of the signed timestamp token is the TSTInfo
structure defined in [RFC3161], which contains the message imprint
that was sent to the TSA. The hash algorithm is contained in the
message imprint structure, together with the hash itself.
As part of the signature verification, 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.
Appendix B of [RFC3161] provides an example that illustrates how
timestamp tokens can be used to verify signatures of a timestamped
message when utilizing X.509 certificates.
Birkholz, et al. Expires 27 August 2024 [Page 5]
Internet-Draft TST Header February 2024
5. Security Considerations
The security considerations made in [RFC3161] as well as those of
[RFC9338] apply.
6. IANA Considerations
IANA is requested to add the two COSE header parameters described in
Section 3 to the "COSE Header Parameters" subregistry of the
[IANA.cose] registry.
7. References
7.1. Normative References
[IANA.cose]
IANA, "CBOR Object Signing and Encryption (COSE)",
<http://www.iana.org/assignments/cose>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/rfc/rfc3161>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[STD70] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
7.2. Informative References
[RFC9338] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/rfc/rfc9338>.
Birkholz, et al. Expires 27 August 2024 [Page 6]
Internet-Draft TST Header February 2024
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org
Maik Riechert
Microsoft
United Kingdom
Email: Maik.Riechert@microsoft.com
Birkholz, et al. Expires 27 August 2024 [Page 7]
