From 6d7c5a3146105237c291ec7c89bd17c9c13f5f1e Mon Sep 17 00:00:00 2001 From: ID Bot Date: Fri, 30 Aug 2024 16:15:04 +0000 Subject: [PATCH] Script updating gh-pages from 9f87d7f. [ci skip] --- index.html | 8 + ...irkholz-cose-tsa-tst-header-parameter.html | 1956 +++++++++++++++++ ...birkholz-cose-tsa-tst-header-parameter.txt | 442 ++++ legenda/index.html | 45 + 4 files changed, 2451 insertions(+) create mode 100644 legenda/draft-birkholz-cose-tsa-tst-header-parameter.html create mode 100644 legenda/draft-birkholz-cose-tsa-tst-header-parameter.txt create mode 100644 legenda/index.html diff --git a/index.html b/index.html index 2ba9fdf..899d640 100644 --- a/index.html +++ b/index.html @@ -88,6 +88,14 @@

Preview for branch usecases

diff with main +

Preview for branch legenda

+ + + + + + +
TST Headerplain textdiff with main
+ + diff --git a/legenda/draft-birkholz-cose-tsa-tst-header-parameter.txt b/legenda/draft-birkholz-cose-tsa-tst-header-parameter.txt new file mode 100644 index 0000000..c4d7030 --- /dev/null +++ b/legenda/draft-birkholz-cose-tsa-tst-header-parameter.txt @@ -0,0 +1,442 @@ + + + + +COSE H. Birkholz +Internet-Draft Fraunhofer SIT +Intended status: Standards Track T. Fossati +Expires: 3 March 2025 Linaro + M. Riechert + Microsoft + 30 August 2024 + + + COSE Header parameter for RFC 3161 Time-Stamp Tokens + draft-birkholz-cose-tsa-tst-header-parameter-latest + +Abstract + + This document defines a CBOR Signing And Encrypted (COSE) header + parameter for incorporating RFC 3161-based timestamping into COSE + message structures (COSE_Sign and COSE_Sign1). This enables the use + of established RFC 3161 timestamping infrastructure to prove the + creation time of a message. + +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 3 March 2025. + +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 + 1.1. Requirements Notation + 2. Modes of use + 2.1. Timestamp then COSE (TTC) + 2.2. COSE then Timestamp (CTT) + 3. RFC 3161 Time-Stamp Tokens COSE Header Parameters + 3.1. 3161-ttc + 3.2. 3161-ctt + 4. Timestamp Processing + 5. Security Considerations + 6. IANA Considerations + 7. Normative References + Appendix A. Diagrams + Acknowledgments + Contributors + Authors' Addresses + +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 two new CBOR Object Signing and Encryption + (COSE) [STD96] header parameters that carry 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). + +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. + + This mode is utilized when the signature should also be performed + over the timestamp to provide an immutable timestamp. + + 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. + + This mode is utilized when a record of the timing of the signature + operation is desired. + + .----------------------. .-----. + | 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 + 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 parameter contains a DER-encoded + RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). + + To minimize dependencies, the hash algorithm used for signing the + COSE message SHOULD be the same as the algorithm used in the RFC3161 + MessageImprint. + +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 parameter contains a DER-encoded + RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). + +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 a + hash of either the payload, signature, or signature fields, depending + on the mode of use and type of COSE structure. + + 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. + +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 [STD96]; these + considerations apply to this document as well, especially the need + for implementations to protect private key material. + + The following scenario assumes 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 + 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 signed COSE + object 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 can be employed inside the ones described in this + specification, but is out of scope for this document. + +6. IANA Considerations + + IANA is requested to add the COSE header parameters defined in + Table 1 to the "COSE Header Parameters" registry + [IANA.cose_header-parameters]. + + +==========+=======+=======+==========+=================+===========+ + | Name | Label | Value | Value | Description | Reference | + | | | Type | Registry | | | + +==========+=======+=======+==========+=================+===========+ + | 3161-tcc | TBD1 | bstr | - | RFC 3161 | RFCthis, | + | | | | | timestamp | Section | + | | | | | token | 3.1 | + +----------+-------+-------+----------+-----------------+-----------+ + | 3161-ctt | TBD2 | bstr | - | RFC 3161 | RFCthis, | + | | | | | timestamp | Section | + | | | | | token | 3.2 | + +----------+-------+-------+----------+-----------------+-----------+ + + Table 1: New COSE Header Parameters + +7. Normative References + + [IANA.cose_header-parameters] + IANA, "COSE Header Parameters", + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [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, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [STD70] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + . + + [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): + Structures and Process", STD 96, RFC 9052, + DOI 10.17487/RFC9052, August 2022, + . + +Appendix A. Diagrams + + The diagrams in this appendix illustrate the processing flow of the + modes specified in Section 2.1 and Section 2.2 respectively. + + For simplicity, only the COSE_Sign1 processing is shown. Similar + diagrams for COSE_Sign can be derived by allowing multiple SK_cose + boxes and replacing the label [signature] with [signatures]. + + .--------. .-----. + | Signer | | TSA | + +--------+----------------------------------------. +-----+---------. + | .-------. .----. | | .-. | + | | datum +------------->| hash | | | | L | | + | '-+---+-' '-+--' | | '+' | + | | | | | | | | + | | | | | | v | + | | | v | | .---------. | + | | | .----------------. | | | timestamp | | + | | | | messageImprint +------+->| '---------' | + | | | '----------------' | | ^ | + | | | | | | | + | | | .-------. | | .---+----. | + | | | | nonce +---------------+->| / SK_tsa / | + | | | '-------' | | '--------' | + | | | | '-------+-------' + | | | .------------------. | | + | | | | phdr | | | + | | | .---------. | .-----. .-----. | | | + | | | / SK_cose / | | ... | | TST |<-----+---------' + | | | '----+----' | '-----' '-----' | | + | | | | '--+--+------------' | + | | | v | | | + | | | .-----. | | | + | | '-->| Sign1 |<-----' | .---------. | + | | '--+--' | | uhdr | | + | | | | | .-----. | | + | | | | | | ... | | | + | | [signature] [phdr] | '-----' | | + | | | | '----+----' | + | | | | | | + '---+------------+--------------+---------+-------' + | | | | + [payload] v v [uhdr] + | .------------------. | + '-------->| rfc3161-ttc COSE |<-----' + '------------------' + + + data key operation label clock + .------. .-----. .---------. .-. + Legenda | | / / | | [ ] | L | + '------' '-----' '---------' '-' + + Figure 3: Timestamp then COSE + +.--------. +| Signer | ++--------+------------------------------------------. +| .-----------. | +| | phdr | | +| .-------. .---------. | .-----. | | +| | datum | / SK_cose / | | ... | | | +| '--+-+--' '----+----' | '-----' | | +| | | | '-+-+-------' | +| | | v | | | +| | | .-----. | | | +| | '--->| Sign1 |<-----' | | +| | '-+-+-' | | .-----. +| | | | | .----. | | TSA | +| | | '----------)--->| hash | | +-----+---------. +| | | | '-+--' | | .-. | +| | | | | | | | L | | +| | | | v | | '+' | +| | | | .----------------. | | | | +| | | | | messageImprint +-+->| v | +| | | | '----------------' | | .---------. | +| | | | | | | timestamp | | +| | | | .-------. | | '---------' | +| | | | | nonce +----------+->| ^ | +| | | | '-------' | | | | +| | | | | | .---+----. | +| | [signature] [phdr] | | / SK_tsa / | +| | | | | | '--------' | +| | | | .-----------------. | | | +| | | | | uhdr | | '-------+-------' +| | | | | .-----. .-----. | | | +| | | | | | ... | | TST |<--+---------' +| | | | | '-----' '-----' | | +| | | | '--------+--------' | +| | | | | | +'----+----------+-------------+----------+----------' + | | | | + [payload] v v [uhdr] + | .------------------. | + '------>| rfc3161-ctt COSE |<-----' + '------------------' + + + data key operation label clock + .------. .-----. .---------. .-. +Legenda | | / / | | [ ] | L | + '------' '-----' '---------' '-' + + Figure 4: COSE then Timestamp + +Acknowledgments + + The editors would like to thank Carl Wallace, Leonard Rosenthol, + Michael B. Jones, Michael Prorock, Orie Steele, and Steve Lasker for + their reviews and comments. + +Contributors + + Carsten Bormann + Email: cabo@tzi.org + + +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 diff --git a/legenda/index.html b/legenda/index.html new file mode 100644 index 0000000..6c5f8fd --- /dev/null +++ b/legenda/index.html @@ -0,0 +1,45 @@ + + + + ietf-scitt/draft-birkholz-cose-tsa-tst-header-parameter legenda preview + + + + +

Editor's drafts for legenda branch of ietf-scitt/draft-birkholz-cose-tsa-tst-header-parameter

+ + + + + + +
TST Headerplain textsame as main
+ + +