<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.5.1) -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-birkholz-cose-tsa-tst-header-parameter-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.46.0 -->
  <front>
    <title abbrev="TST Header">COSE Header parameter for RFC 3161 Time-Stamp Tokens</title>
    <seriesInfo name="Internet-Draft" value="draft-birkholz-cose-tsa-tst-header-parameter-00"/>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="M." surname="Riechert" fullname="Maik Riechert">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <country>UK</country>
        </postal>
        <email>Maik.Riechert@microsoft.com</email>
      </address>
    </author>
    <date year="2022" month="October" day="24"/>
    <area>Security</area>
    <workgroup>TBD</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Useful new COSE <xref target="RFC9052"/> header member that is the TST output of RFC 3161.</t>
      <section anchor="requirements-notation">
        <name>Requirements Notation</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
      <section anchor="mybody">
        <name>RFC 3161 Time-Stamp Tokens COSE Header Parameter</name>
        <t>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.</t>
        <t>The new COSE header parameter for carrying time-stamp tokens is defined as:</t>
        <ul spacing="normal">
          <li>Name: RFC 3161 time-stamp tokens</li>
          <li>Label: TBD</li>
          <li>Value Type: bstr / [+ bstr]</li>
          <li>Value Registry: none</li>
          <li>Description: One or more RFC 3161 time-stamp tokens.</li>
          <li>Reference: TBD</li>
        </ul>
        <t>The content of the bstr are the bytes of the DER-encoded RFC 3161 TimeStampToken structure. This matches the content of the equivalent header attribute defined in <xref target="RFC3161"/> for Cryptographic Message Syntax (CMS, see <xref target="RFC2630"/>) envelopes.</t>
        <t>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.</t>
        <t>Given that time-stamp tokens in this context are similar to a countersignature <xref target="I-D.ietf-cose-countersign"/>, the header parameter can is included in the unprotected header of a COSE envelope.</t>
        <t>When sending a request to an RFC 3161 Time Stamping Authority (TSA, see <xref target="RFC3161"/>) to obtain a time-stamp token, then the so-called message imprint of the request <bcp14>MUST</bcp14> be the hash of the bytes within the bstr 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.</t>
        <t>RFC 3161 time-stamp tokens use CMS as signature envelope format. <xref target="RFC2630"/> illustrates details of signature verification and <xref target="RFC3161"/> details specific to time-stamp token validation. The payload of the signed time-stamp token is a TSTInfo structure as defined in <xref target="RFC3161"/> and contains the message imprint that was sent to the TSA. As part of validation, the message imprint <bcp14>MUST</bcp14> be matched to the hash of the bytes within the bstr 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.</t>
        <t>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.</t>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
      <t>Similar to the same security considerations as described in RFC 3161 apply.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD</t>
      <t>IANA is requested to register the new COSE Header parameter described in section TBD in the "COSE Header Parameters" registry.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2630" target="https://www.rfc-editor.org/info/rfc2630">
          <front>
            <title>Cryptographic Message Syntax</title>
            <seriesInfo name="DOI" value="10.17487/RFC2630"/>
            <seriesInfo name="RFC" value="2630"/>
            <author fullname="R. Housley" initials="R." surname="Housley">
              <organization/>
            </author>
            <date month="June" year="1999"/>
            <abstract>
              <t>This document describes the Cryptographic Message Syntax.  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3161" target="https://www.rfc-editor.org/info/rfc3161">
          <front>
            <title>Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3161"/>
            <seriesInfo name="RFC" value="3161"/>
            <author fullname="C. Adams" initials="C." surname="Adams">
              <organization/>
            </author>
            <author fullname="P. Cain" initials="P." surname="Cain">
              <organization/>
            </author>
            <author fullname="D. Pinkas" initials="D." surname="Pinkas">
              <organization/>
            </author>
            <author fullname="R. Zuccherato" initials="R." surname="Zuccherato">
              <organization/>
            </author>
            <date month="August" year="2001"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <seriesInfo name="DOI" value="10.17487/RFC9052"/>
            <seriesInfo name="RFC" value="9052"/>
            <seriesInfo name="STD" value="96"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="August" year="2022"/>
            <abstract>
              <t>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.  </t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-cose-countersign" target="https://www.ietf.org/archive/id/draft-ietf-cose-countersign-10.txt">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-cose-countersign-10"/>
            <author fullname="Jim Schaad" initials="J." surname="Schaad">
              <organization>August Cellars</organization>
            </author>
            <author fullname="Russ Housley" initials="R." surname="Housley">
              <organization>Vigil Security, LLC</organization>
            </author>
            <date day="20" month="September" year="2022"/>
            <abstract>
              <t>   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.

              </t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAOXxVmMAA6VY3XLjthW+51Og9sVmU1O1nd1Nrel0IltO7KllbyW5bSaT
6UDkkYgxRTAAaC2z43fps+TJ8h2ApChLm5teeESAOD845zvfOXQcx5FTLqeh
eHP1MLsWNyRTMqKURq7J4WmpjZh+fyW+OftwJuZqTfHMyXUp5vqJCvsmkouF
oeehmM/mjXCU6qSA9FCkRi5dvFDmKdP5r3GiLcXOSvy5OPNn485QfHoaWSeL
9L8y1wWEnakoUqXxT9adn55enJ5H0pAcihkllVGujjYrWL4cR0+bobgtoKYg
F4/ZbJRINxTWpVGphpEQTidDUZPFo9XGGVrabl2vt8tIVi7TZhjFQhXYuxmI
y+YCOBrudUPFU39XG7jxvZFVkeklYja7nWO3jczeC1pLlQ9FBi2DNjjfWeUG
y+7kICV2DG4SbjHNCL44I60l8e17vEl0yin78O784v0bXiMYQzGWZo0Yps6f
qApnsPkDmbUs6vY+k4GYKkoyMq67z0Sqp/4u7iML9at0Shd4qxKjrV66ress
MGgFvlu3BwaJXvdNP/4jigoN8049EycBQDr/8M3pUFxNZmHJsGLwjMLy4vT9
Od4CiVGkimVf9jYeDxS5ZYCRt0HGqhU87C2iKI5jhJ6jlbgo6qBbGv2sUrJC
CuAt0ykQIRzj2Xo887a1ckUiVSuyjl+zDAmXSSeUExtpRQL4OUrFguAbQWgF
7wqvZyDmmbIC4K/WVDiR0lIVsJfpjWDPpKsMlnopri4fpmKGLVWsxKhIxXWR
mLpkvV/x1d92ruAWVRLkElnAas9jnK4sa+iuyIWzEhvlMvhMoiBKcSh7XdG4
WCKNqf2hRBtoL3WRsqqt9kEI5FqlaU5RdMzVZXQKb4CJKHq0tKxymNj4ZInP
n2P+fXlpza1pvWBbPnbWm2KG0JUrK8dBaL2GoeNjMaVfKmWIA2fFvXYymJlD
7IlqsdEmteJo8jibH52EX3H/4J+n1/98vJ1ej/l5djO6u+seoubE7Obh8W68
fdpKXj1MJtf34yCMXbGzFR1NRj/iDThJHD18nN8+3I/ujlBFuE0/0aAkjimS
oxiFpSHOpLQR0JYYtcACMpdXH3/739k7ROpPXAVnZxcIVlj89ezbd1hsQAjB
mi7yulkicHUky5KkYS0yz5G8UjmZW5y1wgJeBYJuCIH8+ieOzM9D8bdFUp69
+3uzwRfe2WxjtrPpY7a/syccgnhg64CZLpo7+68ivevv6MeddRv33mYUfR6K
43W90Gn9EtDzxf4k+k3tY1sCAVgVyLQHxH3hE7x2qG7EHcS2UIVHZSiw/wze
n16IBPSnlgqthjgdea431ndMFCt9Utb5ouL2BSVg966eG8DAhTToYz8Hwa+u
qPYqlzX70t2tVSjzd2VQetJh9A0BB3Hv6b274Z4IjtzJBeWhiX4t/iXzCoVa
l5BiChV/ET/92T/93L2d0goXY3ov0KexPfYwL0OzeCgQVJQ/s+OX7Q4gNiX0
OSoSCsb91RONCio8PzBjeBd8efGidoE+eTG+nsaQ1UxwOwn0+fPp25Jnw8xo
JehXtqG9HUPMPs8y550m6NI5lG7lqAspUACWQ6dCqXIirpiy9crIMlOJmDSM
PasLJz+BxyezE2GJPDNOZi8vbwUVz5TrkqzPMxzay28fQIK5Pae92PnoVrlT
5YGXtsEVg0QFn/l6TTsZiNvlHyiGRwjLM9WUnnC/w7rMZRLUyNC1OAkcWKjw
2v7AE87bVl8jD79kzVHvKfLA5Uo4CaVAMsn2vVsQgx6eKHQI5ry+K1H0Q+jD
3G4OFEZD2T7rnwJjW7VWufTdUPYHCN+mOWu9vZcXT8T7CeOmrFh/klfpNt5V
gcnBUeK27Vdz5H1VtzCA0//OGKYUeq8UBjBsJg/o3YG18Lj284IfTzHuia+A
xQ5jHpdvWVQvnPQJex0Hf4fgoNVxArDBvXbSUOsSkewKonXFt49FKMBM2qyr
TF+MnK7myr5Um5fbMC4V5Wm77W//mgH78wzXaWNG5iu+ZLZGm4WhQqMw5bMX
8mXsFW4PeR7lsrHNVNXZa6HfmwT38cGdAEXq+2nne5snEabQQVfJQuV5xfMl
hyAlRDv3vLQVfSYTugK3C27oHXG0x21JCR95NYQGqIOJVOqFQ0RKWedapv3w
4rqH6lfykHWLubkXZ2kPUhi7xfUArNg+SXRI8LXEM69lWmQ//Qw3GoiR5RLw
WNm6enJQSYufwL1pq+b/hdLOFLyLq4MgampftlE45GqnATfRK3wioGq7Wdrr
A/NQvgSURpjHULSfxOXOALH9xODuD+dyP2DwB8A+5pp53iM3rZjFvgQgTx07
N25d5xGx+QjYn0d4sBYfDfpaUosrXVi4ZrxGfOT6jnvcfUcffj/bUqTPBUgP
YGgkkh2JgLLeuLv9KCnLvPa+3I7uR4cN+TfIUcM6ASfGzxn+G6I3E+39f2LH
KrzzIYPWNs1HBydAe9ToN3XzpbOQyVMU/Q7/VvdREBEAAA==

-->

</rfc>
