COSE Header parameter for RFC 3161 Time-Stamp Tokens
Fraunhofer SIT
Rheinstrasse 75
Darmstadt
64295
Germany
henk.birkholz@sit.fraunhofer.de
Microsoft
UK
Maik.Riechert@microsoft.com
Security
TBD
Internet-Draft
RFC 3161 provides a method to time-stamp a message digest to prove that it was created before a given time. This document defines how signatures of CBOR Signing And Encrypted (COSE) message structures can be time-stamped using RFC 3161 along with the needed header parameter to carry the corresponding time-stamp.
Introduction
Useful new COSE header member that is the TST output of RFC 3161.
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 when, and only when, they
appear in all capitals, as shown here.
RFC 3161 Time-Stamp Tokens COSE Header Parameter
The use of RFC 3161 Time-Stamp Tokens, often in combination with X.509 certificates, allows for an existing trust infrastructure to be used with COSE.
The new COSE header parameter for carrying time-stamp tokens is defined as:
- Name: RFC 3161 time-stamp tokens
- Label: TBD
- Value Type: bstr / [2*bstr]
- Value Registry: none
- Description: One or more RFC 3161 time-stamp tokens.
- Reference: TBD
The content of the byte string are the bytes of the DER-encoded RFC 3161 TimeStampToken structure. This matches the content of the equivalent header attribute defined in for Cryptographic Message Syntax (CMS, see ) envelopes.
This header parameter allows for a single time-stamp token or multiple time-stamp tokens to be carried in the message. If a single time-stamp token is conveyed, it is placed in a CBOR byte string. If multiple time-stamp tokens are conveyed, a CBOR array of byte strings is used, with each time-stamp token being in its own byte string.
Given that time-stamp tokens in this context are similar to a countersignature , the header parameter can be included in the unprotected header of a COSE envelope.
When sending a request to an RFC 3161 Time Stamping Authority (TSA, see ) to obtain a time-stamp token, then the so-called message imprint () of the request MUST be the hash of the bytes within the byte string of the signature field of the COSE structure to be time-stamped. The hash algorithm does not have to match the algorithm used for signing the COSE message.
RFC 3161 time-stamp tokens use CMS as signature envelope format. illustrates details of signature verification and details specific to time-stamp token validation. The payload of the signed time-stamp token is a TSTInfo structure as defined in and contains the message imprint that was sent to the TSA. As part of validation, the message imprint MUST be matched to the hash of the bytes within the byte string of the signature field of the time-stamped COSE structure. The hash algorithm is contained in the message imprint structure, together with the hash itself.
Appendix B of RFC 3161 provides an example of how time-stamp tokens can be used during signature verification of a time-stamped message when using X.509 certificates.
Privacy Considerations
TBD
Security Considerations
TBD
Similar security considerations as described in RFC 3161 apply.
IANA Considerations
TBD
IANA is requested to register the new COSE Header parameter described in section TBD in the "COSE Header Parameters" registry.
References
Normative References
Cryptographic Message Syntax (CMS)
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]
Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]
CBOR Object Signing and Encryption (COSE): Structures and Process
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
This document, along with RFC 9053, obsoletes RFC 8152.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
CBOR Object Signing and Encryption (COSE): Countersignatures
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052.