rfc9921.original.xml   rfc9921.xml 
<?xml version='1.0' encoding='utf-8'?> <?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.7.19 (Ruby 2.5. <!DOCTYPE rfc [
1) --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!ENTITY zwsp "&#8203;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <!ENTITY nbhy "&#8209;">
-ietf-cose-tsa-tst-header-parameter-08" category="std" consensus="true" submissi <!ENTITY wj "&#8288;">
onType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> ]>
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-cose-tsa-tst-header-parameter-08" number="9921" updates="" obsoletes="" ca
tegory="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="
true" symRefs="true" version="3" xml:lang="en">
<!--[rfced] The document title has been updated as follows. Please let
us know any objections.
Original:
COSE Header parameter for RFC 3161 Time-Stamp Tokens
Currently:
Concise Binary Object Representation (CBOR) Object Signing and
Encryption (COSE) Header Parameter for Timestamp Tokens as
Defined in RFC 3161 -->
<front> <front>
<title abbrev="TST Header">COSE Header parameter for RFC 3161 Time-Stamp Tok <title abbrev="TST Header">Concise Binary Object Representation (CBOR) Objec
ens</title> t Signing and Encryption (COSE) Header Parameter for Timestamp Tokens as Defined
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-tsa-tst-header-para in RFC 3161</title>
meter-08"/> <seriesInfo name="RFC" value="9921"/>
<author initials="H." surname="Birkholz" fullname="Henk Birkholz"> <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization> <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
<address> <address>
<postal> <postal>
<street>Rheinstrasse 75</street> <street>Rheinstrasse 75</street>
<city>Darmstadt</city> <city>Darmstadt</city>
<code>64295</code> <code>64295</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>henk.birkholz@ietf.contact</email> <email>henk.birkholz@ietf.contact</email>
skipping to change at line 32 skipping to change at line 48
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>Linaro</organization> <organization>Linaro</organization>
<address> <address>
<email>thomas.fossati@linaro.org</email> <email>thomas.fossati@linaro.org</email>
</address> </address>
</author> </author>
<author initials="M." surname="Riechert" fullname="Maik Riechert"> <author initials="M." surname="Riechert" fullname="Maik Riechert">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>Maik.Riechert@microsoft.com</email> <email>Maik.Riechert@microsoft.com</email>
</address> </address>
</author> </author>
<date year="2025" month="August" day="29"/> <date year="2026" month="February"/>
<area>Security</area> <area>SEC</area>
<workgroup>COSE</workgroup> <workgroup>cose</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 54?>
<t>This document defines two CBOR Signing And Encrypted (COSE) header parameters <!-- [rfced] Please insert any keywords (beyond those that appear in the
for incorporating RFC 3161-based timestamping into COSE message structures (<tt title) for use on <https://www.rfc-editor.org/search>. -->
>COSE_Sign</tt> and <tt>COSE_Sign1</tt>).
This enables the use of established RFC 3161 timestamping infrastructure in COSE <!-- [rfced] Regarding the use of "<tt>" in this document and this
-based protocols.</t> note in your reply to our Document Intake email:
"We tried to <tt/> all COSE types (e.g., COSE_Sign1) and COSE header
names (e.g., 3161-ttc) ... I am not sure we were entirely
consistent, though. This also raises the question of why we did not
include the types from RFC3161."
For consistency of style, we made the following updates. Please let
us know any objections:
* bstr: We added <tt>s around this term in Table 1.
* MessageImprint: We added <tt>s around 4 instances of
"the MessageImprint".
* TimeStampToken: We added <tt>s around this term in the
Introduction.
Would you like us to add <tt>s around other terms from RFC 3161
(e.g., TSTInfo)? If yes, please specify which terms/types from
RFC 3161 you would like us to enclose in <tt>...</tt>. -->
<abstract>
<t>This document defines two Concise Binary Object Representation (CBOR) Object
Signing and Encryption (COSE) header parameters for incorporating timestamping b
ased on RFC 3161 into COSE message structures (<tt>COSE_Sign</tt> and <tt>COSE_S
ign1</tt>).
This enables the use of established timestamping infrastructure per RFC 3161 in
COSE-based protocols.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-cose-tsa-tst-header-parameter/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-scitt/draft-birkholz-cose-tsa-tst-
header-parameter"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 59?> <section anchor="introduction">
<section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>RFC 3161 <xref target="RFC3161"/> provides a method to timestamp a mess <t>RFC 3161 <xref target="RFC3161"/> provides a method for timestamping a
age digest to prove that it was created before a given time.</t> message digest to prove that it was created before a given time.</t>
<t>This document defines two new CBOR Object Signing and Encryption (COSE) <t>This document defines two new CBOR Object Signing and Encryption (COSE)
<xref target="STD96"/> header parameters that carry the TimestampToken (TST) ou <xref target="RFC9052"/> header parameters that carry the <tt>TimeStampToken</t
tput of RFC 3161, thus allowing existing and widely deployed trust infrastructur t> (TST) output <xref target="RFC3161"/>, thus allowing existing and widely depl
e to be used with COSE structures used for signing (<tt>COSE_Sign</tt> and <tt>C oyed trust infrastructure to be used with COSE structures used for signing (<tt>
OSE_Sign1</tt>).</t> COSE_Sign</tt> and <tt>COSE_Sign1</tt>).</t>
<section anchor="use-cases"> <section anchor="use-cases">
<name>Use Cases</name> <name>Use Cases</name>
<t>This section discusses two use cases, each representing one of the tw o modes of use defined in <xref target="modes"/>. <t>This section discusses two use cases, each representing one of the tw o modes of use defined in <xref target="modes"/>.
As the security characteristics of the two cases differ, care must be taken when choosing the appropriate mode for a given application. As the security characteristics of the two cases differ, care must be taken when choosing the appropriate mode for a given application.
See <xref target="sec-sema-confusion-avoidance"/> for a discussion on the securi ty of the implementations.</t> See <xref target="sec-sema-confusion-avoidance"/> for a discussion on the securi ty of the implementations.</t>
<t>The primary use case is that of "long-term signatures", i.e., signatu res that can still be verified even after the signing certificate has expired. <t>The primary use case is that of "long-term signatures", i.e., signatu res that can still be verified even after the signing certificate has expired.
This can address situations where it is important to prevent subsequent denial b y the signer or to verify signatures made using (very) short-term certificates. This can address situations where it is important to prevent subsequent denial b y the signer or to verify signatures made using (very) short-term certificates.
To achieve this, the document signer acquires a fresh TST for the document's sig To achieve this, the document signer acquires a fresh TST for the document's sig
nature from a trusted TSA and concatenates it with the document. nature from a trusted Time Stamping Authority (TSA) <xref target="RFC3161"/> and
Later, when a relying party verifies the signed document and its associated TST, concatenates it with the document.
they can be certain that the document was signed <em>at least</em> at the time Later, when a relying party verifies the signed document and its associated TST,
specified by the TSA, and that the signing certificate was valid at the time the they can be certain that the document was signed <em>at least</em> at the time
signature was made.</t> specified by the TSA and that the signing certificate was valid at the time the
<t>This primary usage scenario motivates the "COSE then Timestamp" mode signature was made.
described in <xref target="sec-cose-then-timestamp"/>.</t>
<!-- [rfced] Section 1.1: Does "primary" in these sentences indicate
that the primary use case is more important than the second use case
or perhaps was developed earlier? Please see the definition of
"primary" on <https://www.merriam-webster.com/dictionary/primary>,
and let us know if "primary" should be changed to "first".
Original:
The primary use case is that of "long-term signatures", i.e.,
signatures that can still be verified even after the signing
certificate has expired.
...
This primary usage scenario motivates the "COSE then Timestamp" mode
described in Section 2.1. -->
</t>
<t>This primary usage scenario motivates the "COSE, then Timestamp" mode
described in <xref target="sec-cose-then-timestamp"/>.</t>
<t>The second use case is new. <t>The second use case is new.
It is the notarization of a signed document by registering it with a transparenc y service. It is the notarization of a signed document by registering it with a transparenc y service.
This is common practice for ensuring the accountability and auditability of issu ed documents, which are typically referred to as "statements" in this context. This is common practice for ensuring the accountability and auditability of issu ed documents, which are typically referred to as "statements" in this context.
It is also common practice to only register the signed parts of a statement (the "signed statement" portion) with a transparency service, in order to reduce the complexity of consistency checks at a later stage, as well as avoiding the need to retrieve or reconstruct unsigned parts. It is also common practice to only register the signed parts of a statement (the "signed statement" portion) with a transparency service, in order to reduce the complexity of consistency checks at a later stage and to avoid the need to retr ieve or reconstruct unsigned parts.
Once the signed parts of a document have been registered in the append-only log at a transparency service, the log entry cannot be changed. Once the signed parts of a document have been registered in the append-only log at a transparency service, the log entry cannot be changed.
In order to avoid losing the TST during the registration process, the TST must b e included in the signed statement. In order to avoid losing the TST during the registration process, the TST must b e included in the signed statement.
To achieve this, the issuer acquires a TST from a TSA, includes it in the to-be- signed part of the statement so that the resulting signed statement includes the TST, and then registers the signed parts (rendering it a "transparent statement "). To achieve this, the issuer acquires a TST from a TSA, includes it in the to-be- signed part of the statement so that the resulting signed statement includes the TST, and then registers the signed parts (rendering it a "transparent statement ").
Later on, a relying party consuming the transparent statement including the TST can be certain that the statement was signed by the issuer <em>at least</em> at the time specified by the TSA. Later on, a relying party consuming the transparent statement including the TST can be certain that the statement was signed by the issuer <em>at least</em> at the time specified by the TSA.
If the issuer's signing key has expired (or been compromised), the authenticity If the issuer's signing key has expired (or has been compromised), the authentic
of the statement can be ascertained by ensuring that no revocation information w ity of the statement can be ascertained by ensuring that no revocation informati
as made public before the time asserted by the issuer and registered at the tran on was made public before the time asserted by the issuer and registered at the
sparency service.</t> transparency service.
<t>This new usage scenario motivates the "Timestamp then COSE" mode defi
ned in <xref target="sec-timestamp-then-cose"/>.</t> <!-- [rfced] Section 1.1: This sentence did not parse. We updated
it as follows. If this is incorrect, please clarify "in order to
reduce ... as well as avoiding".
Original:
It is also common practice to only register the signed
parts of a statement (the "signed statement" portion) with a
transparency service, in order to reduce the complexity of
consistency checks at a later stage, as well as avoiding the need to
retrieve or reconstruct unsigned parts.
Currently:
It is also common practice to only register the signed
parts of a statement (the "signed statement" portion) with a
transparency service, in order to reduce the complexity of
consistency checks at a later stage and to avoid the need to retrieve
or reconstruct unsigned parts. -->
</t>
<t>This new usage scenario motivates the "Timestamp, then COSE" mode def
ined in <xref target="sec-timestamp-then-cose"/>.</t>
</section> </section>
<section anchor="requirements-notation"> <section anchor="requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, are to be interpreted as described in BCP&nbsp;14
and only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<?line -18?> </section>
</section>
</section> </section>
<section anchor="modes"> <section anchor="modes">
<name>Modes of Use</name> <name>Modes of Use</name>
<t>There are two different modes of composing COSE protection and timestam ping, motivated by the usage scenarios discussed above.</t> <t>There are two different modes of composing COSE protection and timestam ping, motivated by the usage scenarios discussed above.</t>
<t>The diagrams in this section illustrate the processing flow of the spec ified modes. <t>The diagrams in this section illustrate the processing flow of the spec ified modes.
For simplicity, only the <tt>COSE_Sign1</tt> processing is shown. For simplicity, only the <tt>COSE_Sign1</tt> processing is shown.
Similar diagrams for <tt>COSE_Sign</tt> can be derived by allowing multiple <tt> private-key</tt> parallelogram boxes and replacing the label <tt>[signature]</tt > with <tt>[signatures]</tt>.</t> Similar diagrams for <tt>COSE_Sign</tt> can be derived by allowing multiple <tt> private-key</tt> parallelogram boxes and replacing the label <tt>[signature]</tt > with <tt>[signatures]</tt>.</t>
<section anchor="sec-cose-then-timestamp"> <section anchor="sec-cose-then-timestamp">
<name>COSE then Timestamp (CTT)</name> <name>COSE, then Timestamp (CTT)</name>
<t><xref target="fig-cose-then-timestamp"/> shows the case where the sig nature(s) field of the signed COSE object is digested and submitted to a TSA to be timestamped. <t><xref target="fig-cose-then-timestamp"/> shows the case where the sig nature(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 th e same COSE object.</t> The obtained timestamp token is then added back as an unprotected header into th e same COSE object.</t>
<t>This mode is utilized when a record of the timing of the signature op eration is desired.</t> <t>This mode is utilized when a record of the timing of the signature op eration is desired.</t>
<figure anchor="fig-cose-then-timestamp"> <figure anchor="fig-cose-then-timestamp">
<name>COSE, then Timestamp (CTT)</name> <name>COSE, then Timestamp (CTT)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="448" width="616" viewBox="0 0 616 448" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="448" width="616" viewBox="0 0 616 448" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
<path d="M 8,32 L 8,288" fill="none" stroke="black"/> <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
<path d="M 48,224 L 48,336" fill="none" stroke="black"/> <path d="M 48,224 L 48,336" fill="none" stroke="black"/>
<path d="M 48,368 L 48,400" fill="none" stroke="black"/> <path d="M 48,368 L 48,400" fill="none" stroke="black"/>
skipping to change at line 279 skipping to change at line 345
| v v '------+------' | v v '------+------'
| .-------+------------+-----. | | .-------+------------+-----. |
'--->+ rfc3161-ctt COSE +<-----' '--->+ rfc3161-ctt COSE +<-----'
'--------------------------' '--------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In this context, timestamp tokens are similar to a countersignature m ade by the TSA.</t> <t>In this context, timestamp tokens are similar to a countersignature m ade by the TSA.</t>
</section> </section>
<section anchor="sec-timestamp-then-cose"> <section anchor="sec-timestamp-then-cose">
<name>Timestamp then COSE (TTC)</name> <name>Timestamp, then COSE (TTC)</name>
<t><xref target="fig-timestamp-then-cose"/> shows the case where a datum is first digested and submitted to a TSA to be timestamped.</t> <t><xref target="fig-timestamp-then-cose"/> shows the case where a datum is first digested and submitted to a TSA to be timestamped.</t>
<t>This mode is used to wrap the signed document and its timestamp toget her in an immutable payload.</t> <t>This mode is used to wrap the signed document and its timestamp toget her in an immutable payload.</t>
<t>A signed COSE message is then built as follows:</t> <t>A signed COSE message is then built as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The obtained timestamp token is added to the protected headers,</l i> <li>The obtained timestamp token is added to the protected headers.</l i>
<li>The original datum becomes the payload of the signed COSE message. </li> <li>The original datum becomes the payload of the signed COSE message. </li>
</ul> </ul>
<figure anchor="fig-timestamp-then-cose"> <figure anchor="fig-timestamp-then-cose">
<name>Timestamp, then COSE (TTC)</name> <name>Timestamp, then COSE (TTC)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="464" width="616" viewBox="0 0 616 464" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="464" width="616" viewBox="0 0 616 464" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
<path d="M 8,32 L 8,304" fill="none" stroke="black"/> <path d="M 8,32 L 8,304" fill="none" stroke="black"/>
<path d="M 40,112 L 40,232" fill="none" stroke="black"/> <path d="M 40,112 L 40,232" fill="none" stroke="black"/>
<path d="M 48,272 L 48,352" fill="none" stroke="black"/> <path d="M 48,272 L 48,352" fill="none" stroke="black"/>
<path d="M 48,384 L 48,416" fill="none" stroke="black"/> <path d="M 48,384 L 48,416" fill="none" stroke="black"/>
skipping to change at line 465 skipping to change at line 531
| v v '------+------' | v v '------+------'
| .-------+------------+-----. | | .-------+------------+-----. |
'--->+ rfc3161-ttc COSE +<-----' '--->+ rfc3161-ttc COSE +<-----'
'--------------------------' '--------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-tst-hdr"> <section anchor="sec-tst-hdr">
<name>RFC 3161 Time-Stamp Tokens COSE Header Parameters</name> <name>Timestamp Tokens per RFC 3161: COSE Header Parameters</name>
<t>The two modes described in <xref target="sec-timestamp-then-cose"/> and <t>The two modes described in Sections&nbsp;<xref target="sec-timestamp-th
<xref target="sec-cose-then-timestamp"/> use different inputs into the timestam en-cose" format="counter"/> and <xref target="sec-cose-then-timestamp" format="c
ping machinery, and consequently create different kinds of binding between COSE ounter"/> use different inputs into the timestamping machinery and consequently
and TST. create different kinds of bindings between COSE and TST.
To clearly separate their semantics two different COSE header parameters are def To clearly separate their semantics, two different COSE header parameters are de
ined as described in the following subsections.</t> fined as described in the following subsections.</t>
<section anchor="sec-tst-hdr-ctt"> <section anchor="sec-tst-hdr-ctt">
<name><tt>3161-ctt</tt></name> <name><tt>3161-ctt</tt></name>
<t>The <tt>3161-ctt</tt> COSE <em>unprotected</em> header parameter <bcp 14>MUST</bcp14> be used for the mode described in <xref target="sec-cose-then-ti mestamp"/>.</t> <t>The <tt>3161-ctt</tt> COSE <em>unprotected</em> header parameter <bcp 14>MUST</bcp14> be used for the mode described in <xref target="sec-cose-then-ti mestamp"/>.</t>
<t>The <tt>3161-ctt</tt> unprotected header parameter contains a DER-enc <t>The <tt>3161-ctt</tt> unprotected header parameter contains a DER-enc
oded RFC3161 <tt>TimeStampToken</tt> wrapped in a CBOR byte string (Major type 2 oded <tt>TimeStampToken</tt> <xref target="RFC3161"/> wrapped in a CBOR byte str
).</t> ing (Major type 2).</t>
<t>The <tt>MessageImprint</tt> sent in the request to the TSA <bcp14>MUS <t>The <tt>MessageImprint</tt> sent in the request to the TSA <bcp14>MUS
T</bcp14> be:</t> T</bcp14> be</t>
<!-- [rfced] Sections 3.1 and subsequent: We see that this document
uses "MessageImprint" in text but RFC 3161 uses "messageImprint" in
its text (e.g., "The messageImprint field" in its Section 2.4.1).
Please confirm that you wish to keep the currently capitalized form
in this document. -->
<ul spacing="normal"> <ul spacing="normal">
<li>the hash of the CBOR-encoded signature field of the <tt>COSE_Sign1 </tt> message, or</li> <li>the hash of the CBOR-encoded signature field of the <tt>COSE_Sign1 </tt> message, or</li>
<li>the hash of the CBOR-encoded signatures field of the <tt>COSE_Sign </tt> message.</li> <li>the hash of the CBOR-encoded signatures field of the <tt>COSE_Sign </tt> message.</li>
</ul> </ul>
<t>In either case, to minimize dependencies, the hash algorithm <bcp14>S HOULD</bcp14> be the same as the algorithm used for signing the COSE message. <t>In either case, to minimize dependencies, the hash algorithm <bcp14>S HOULD</bcp14> 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 pr ocessing context in which the COSE object is assembled.</t> This may not be possible if the timestamp token has been obtained outside the pr ocessing context in which the COSE object is assembled.</t>
<t>Refer to <xref target="ctt-sign1"/> and <xref target="ctt-sign"/> for concrete examples of <tt>MessageImprint</tt> computation.</t> <t>Refer to Sections&nbsp;<xref target="ctt-sign1" format="counter"/> an d <xref target="ctt-sign" format="counter"/> for concrete examples of <tt>Messag eImprint</tt> computation.</t>
<section anchor="ctt-sign1"> <section anchor="ctt-sign1">
<name><tt>MessageImprint</tt> Computation for <tt>COSE_Sign1</tt></nam e> <name><tt>MessageImprint</tt> Computation for <tt>COSE_Sign1</tt></nam e>
<t>The following illustrates how <tt>MessageImprint</tt> is computed u sing a sample <tt>COSE_Sign1</tt> message.</t> <t>The following illustrates how <tt>MessageImprint</tt> is computed u sing a sample <tt>COSE_Sign1</tt> message.</t>
<t>Given the <tt>COSE_Sign1</tt> message</t> <t>Given the <tt>COSE_Sign1</tt> message</t>
<sourcecode type="cbor-diag">
<!-- [rfced] Please review each artwork element and let us know if
any should be marked as sourcecode instead.
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, you may
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute unset.
Please note that per
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>,
we changed instances of sourcecode type "asn1" to "asn.1". -->
<sourcecode type="cbor-diag"><![CDATA[
18( 18(
[ [
/ protected h'a10126' / <&lt; { / protected h'a10126' / <&lt; {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >&gt;, } >&gt;,
/ unprotected / { / unprotected / {
/ kid / 4:'11' / kid / 4:'11'
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4 / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5 d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36' a4c345cacb36'
] ]
) )
</sourcecode> ]]></sourcecode>
<t>the <tt>bstr</tt>-wrapped <tt>signature</tt></t> <t>the <tt>bstr</tt>-wrapped <tt>signature</tt></t>
<sourcecode type="cbor-pretty"> <sourcecode type="cbor-pretty"><![CDATA[
58 40 # bytes(64) 58 40 # bytes(64)
8eb33e4ca31d1c465ab05aac34cc6b23 8eb33e4ca31d1c465ab05aac34cc6b23
d58fef5c083106c4d25a91aef0b0117e d58fef5c083106c4d25a91aef0b0117e
2af9a291aa32e14ab834dc56ed2a2234 2af9a291aa32e14ab834dc56ed2a2234
44547e01f11d3b0916e5a4c345cacb36 44547e01f11d3b0916e5a4c345cacb36
</sourcecode> ]]></sourcecode>
<t>(including the heading bytes <tt>0x5840</tt>) is used as input for computing the <tt>MessageImprint</tt>.</t> <t>(including the heading bytes <tt>0x5840</tt>) is used as input for computing the <tt>MessageImprint</tt>.</t>
<t>When using SHA-256, the resulting <tt>MessageImprint</tt> is</t> <t>When using SHA-256, the resulting <tt>MessageImprint</tt> is</t>
<sourcecode type="asn1"> <sourcecode type="asn.1"><![CDATA[
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
44 C2 41 9D 13 1D 53 D5 55 84 B5 DD 33 B7 88 C2 44 C2 41 9D 13 1D 53 D5 55 84 B5 DD 33 B7 88 C2
4E 55 1C 6D 44 B1 AF C8 B2 B8 5E 69 54 76 3B 4E 4E 55 1C 6D 44 B1 AF C8 B2 B8 5E 69 54 76 3B 4E
} }
</sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="ctt-sign"> <section anchor="ctt-sign">
<name><tt>MessageImprint</tt> Computation for <tt>COSE_Sign</tt></name > <name><tt>MessageImprint</tt> Computation for <tt>COSE_Sign</tt></name >
<t>The following illustrates how <tt>MessageImprint</tt> is computed u sing a sample <tt>COSE_Sign</tt> message.</t> <t>The following illustrates how <tt>MessageImprint</tt> is computed u sing a sample <tt>COSE_Sign</tt> message.</t>
<t>Given the <tt>COSE_Sign</tt> message</t> <t>Given the <tt>COSE_Sign</tt> message</t>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
98( 98(
[ [
/ protected / h'', / protected / h'',
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signatures / [ / signatures / [
[ [
/ protected h'a10126' / <&lt; { / protected h'a10126' / <&lt; {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >&gt;, } >&gt;,
/ unprotected / { / unprotected / {
/ kid / 4:'11' / kid / 4:'11'
}, },
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a' 98f53afd2fa0f30a'
] ]
] ]
] ]
) )
</sourcecode> ]]></sourcecode>
<t>the <tt>signatures</tt> array</t> <t>the <tt>signatures</tt> array</t>
<sourcecode type="cbor-pretty"> <sourcecode type="cbor-pretty"><![CDATA[
81 # array(1) 81 # array(1)
83 # array(3) 83 # array(3)
43 # bytes(3) 43 # bytes(3)
a10126 a10126
a1 # map(1) a1 # map(1)
04 # unsigned(4) 04 # unsigned(4)
42 # bytes(2) 42 # bytes(2)
3131 # "11" 3131 # "11"
58 40 # bytes(64) 58 40 # bytes(64)
e2aeafd40d69d19dfe6e52077c5d7ff4 e2aeafd40d69d19dfe6e52077c5d7ff4
e408282cbefb5d06cbf414af2e19d982 e408282cbefb5d06cbf414af2e19d982
ac45ac98b8544c908b4507de1e90b717 ac45ac98b8544c908b4507de1e90b717
c3d34816fe926a2b98f53afd2fa0f30a c3d34816fe926a2b98f53afd2fa0f30a
</sourcecode> ]]></sourcecode>
<t>is used as input for computing the <tt>MessageImprint</tt>.</t> <t>is used as input for computing the <tt>MessageImprint</tt>.</t>
<t>When using SHA-256, the resulting <tt>MessageImprint</tt> is</t> <t>When using SHA-256, the resulting <tt>MessageImprint</tt> is</t>
<sourcecode type="asn1"> <sourcecode type="asn.1"><![CDATA[
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
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
} }
</sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="sec-tst-hdr-ttc"> <section anchor="sec-tst-hdr-ttc">
<name><tt>3161-ttc</tt></name> <name><tt>3161-ttc</tt></name>
<t>The <tt>3161-ttc</tt> COSE <em>protected</em> header parameter <bcp14 >MUST</bcp14> be used for the mode described in <xref target="sec-timestamp-then -cose"/>.</t> <t>The <tt>3161-ttc</tt> COSE <em>protected</em> header parameter <bcp14 >MUST</bcp14> be used for the mode described in <xref target="sec-timestamp-then -cose"/>.</t>
<t>The <tt>3161-ttc</tt> protected header parameter contains a DER-encod ed RFC3161 <tt>TimeStampToken</tt> wrapped in a CBOR byte string (Major type 2). </t> <t>The <tt>3161-ttc</tt> protected header parameter contains a DER-encod ed <tt>TimeStampToken</tt> <xref target="RFC3161"/> wrapped in a CBOR byte strin g (Major type 2).</t>
<t>The <tt>MessageImprint</tt> sent to the TSA (<xref section="2.4" sect ionFormat="of" target="RFC3161"/>) <bcp14>MUST</bcp14> be the hash of the payloa d of the COSE signed object. <t>The <tt>MessageImprint</tt> sent to the TSA (<xref section="2.4" sect ionFormat="of" target="RFC3161"/>) <bcp14>MUST</bcp14> be the hash of the payloa d of the COSE signed object.
This does not include the <tt>bstr</tt>-wrapping, only the payload bytes. This does not include the <tt>bstr</tt> wrapping -- only the payload bytes.
(For an example, see <xref target="ex-ttc"/>.)</t> (For an example, see <xref target="ex-ttc"/>.)</t>
<t>To minimize dependencies, the hash algorithm used for signing the COS E message <bcp14>SHOULD</bcp14> be the same as the algorithm used in the RFC3161 MessageImprint. <t>To minimize dependencies, the hash algorithm used for signing the COS E message <bcp14>SHOULD</bcp14> be the same as the algorithm used in the <tt>Mes sageImprint</tt> <xref target="RFC3161"/>.
However, this may not be possible if the timestamp requester and the COSE messag e signer are different entities.</t> However, this may not be possible if the timestamp requester and the COSE messag e signer are different entities.</t>
</section> </section>
</section> </section>
<section anchor="timestamp-processing"> <section anchor="timestamp-processing">
<name>Timestamp Processing</name> <name>Timestamp Processing</name>
<t>RFC 3161 timestamp tokens use CMS as signature envelope format. <t>Timestamp tokens <xref target="RFC3161"/> use Cryptographic Message Syn
<xref target="STD70"/> provides the details about signature verification, and <x tax (CMS) as the signature envelope format.
ref target="RFC3161"/> provides the details specific to timestamp token validati <xref target="RFC5652"/> provides details about signature verification, and <xre
on. f target="RFC3161"/> provides details specific to timestamp token validation.
The payload of the signed timestamp token is the TSTInfo structure defined in <x The payload of the signed timestamp token is the TSTInfo structure defined in <x
ref target="RFC3161"/>, which contains the MessageImprint that was sent to the T ref target="RFC3161"/>, which contains the <tt>MessageImprint</tt> that was sent
SA. to the TSA.
The hash algorithm is contained in the MessageImprint structure, together with t The hash algorithm is contained in the <tt>MessageImprint</tt> structure, togeth
he hash itself.</t> er with the hash itself.</t>
<t>As part of the signature verification, the receiver <bcp14>MUST</bcp14> <t>As part of the signature verification, the receiver <bcp14>MUST</bcp14>
make sure that the MessageImprint in the embedded timestamp token matches a has make sure that the <tt>MessageImprint</tt> in the embedded timestamp token matc
h of either the payload, signature, or signature fields, depending on the mode o hes a hash of either the payload, signature, or signature fields, depending on t
f use and type of COSE structure.</t> he mode of use and type of COSE structure.</t>
<t><xref section="B" sectionFormat="of" target="RFC3161"/> provides an exa mple that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing X.509 certificates.</t> <t><xref section="B" sectionFormat="of" target="RFC3161"/> provides an exa mple that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing X.509 certificates.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Please review the Security Considerations section in <xref target="RFC3 161"/>; these considerations apply to this document as well.</t> <t>Please review the Security Considerations section in <xref target="RFC3 161"/>; these considerations apply to this document as well.</t>
<t>Also review the Security Considerations section in <xref target="STD96" />. <t>Also review the Security Considerations section in <xref target="RFC905 2"/>.
These considerations apply to this document as well, particularly with regard to the need for implementations to protect private key material. These considerations apply to this document as well, particularly with regard to the need for implementations to protect private key material.
Additionally, solutions based on the COSE header parameters defined in this docu ment must be able to report compromised keys promptly.</t> Additionally, solutions based on the COSE header parameters defined in this docu ment must be able to report compromised keys promptly.</t>
<t>The following scenario assumes an attacker can manipulate the clocks on the COSE signer and its relying parties, but not the TSA. <t>The following scenario assumes that an attacker can manipulate the cloc ks 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. 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 i In such a setting, any tampering with the COSE signer's clock does not have an i
mpact because, once the timestamp is obtained from the TSA, it becomes the only mpact, because once the timestamp is obtained from the TSA, it becomes the only
reliable source of time. reliable source of time.
However, in both CTT and TTC mode, a denial of service can occur if the attacker However, in both CTT mode and TTC mode, a denial of service can occur if the att
can adjust the relying party's clock so that the CMS validation fails. acker can adjust the relying party's clock so that the CMS validation fails.
This could disrupt the timestamp validation.</t> This could disrupt the timestamp validation.</t>
<t>In CTT mode, an attacker could manipulate the unprotected header by rem oving or replacing the timestamp. <t>In CTT mode, an attacker could manipulate the unprotected header by rem oving or replacing the timestamp.
To avoid that, the signed COSE object should be integrity protected during trans it and at rest.</t> To avoid that, the signed COSE object should be integrity protected during trans it and at rest.</t>
<t>In TTC mode, the TSA is given an opaque identifier (a cryptographic has h value) for the payload. <t>In TTC mode, the TSA is given an opaque identifier (a cryptographic has h value) for the payload.
While this means that the content of the payload is not directly revealed, to pr event comparison with known payloads or disclosure of identical payloads being u sed 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. While this means that the content of the payload is not directly revealed, to pr event comparison with known payloads or disclosure of identical payloads being u sed 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 Such a mechanism can be employed inside the parameters described in this specifi
, but is out of scope for this document.</t> cation but is out of scope for this document.
<t>The resolution, accuracy, and precision of the TSA clock, as well as th
e expected latency introduced by round trips to and from the TSA must be taken i <!-- [rfced] Section 5: As it appears that "the ones" means "the
nto account when implementing solutions based on the COSE header parameters defi parameters" (per "This document defines two ... parameters" as used
ned in this document.</t> in the Abstract and Introduction), we changed "ones" to "parameters".
If this is incorrect, please clarify the text.
Original:
Such a mechanism can be employed inside the ones described in this
specification, but is out of scope for this document.
Currently:
Such a mechanism can be employed inside the parameters described in
this specification but is out of scope for this document. -->
</t>
<t>The resolution, accuracy, and precision of the TSA clock, as well as th
e expected latency introduced by round trips to and from the TSA, must be taken
into account when implementing solutions based on the COSE header parameters def
ined in this document.</t>
<section anchor="sec-sema-confusion-avoidance"> <section anchor="sec-sema-confusion-avoidance">
<name>Avoiding Semantic Confusion</name> <name>Avoiding Semantic Confusion</name>
<t>CTT and TTC modes have different semantic meanings. <t>CTT mode and TTC mode have different semantic meanings.
An implementation must ensure that the contents of the CTT and TCC headers are i An implementation must ensure that the contents of the CTT and TTC headers are i
nterpreted according to their specific semantics. nterpreted according to their specific semantics.
In particular, symmetric to the signature and assembly mechanics, each mode has its own separate verification algorithm.</t> In particular, symmetric to the signature and assembly mechanics, each mode has its own separate verification algorithm.</t>
<t>Implementers <bcp14>MUST</bcp14> clearly differentiate between RFC 31 61 TSA timestamps proving the existence of payload data at an earlier point in t ime (TTC) and timestamps explicitly providing evidence of the existence of the c ryptographic signature (CTT). <t>Implementers <bcp14>MUST</bcp14> clearly differentiate between TSA ti mestamps <xref target="RFC3161"/> proving the existence of payload data at an ea rlier point in time (TTC) and timestamps explicitly providing evidence of the ex istence of the cryptographic signature (CTT).
Failure to clearly distinguish between these timestamp semantics can result in v ulnerabilities, such as incorrectly accepting signatures created after key revoc ation based on older payload-only timestamps. Failure to clearly distinguish between these timestamp semantics can result in v ulnerabilities, such as incorrectly accepting signatures created after key revoc ation based on older payload-only timestamps.
Validators must not interpret protected-header payload timestamps as proof of si gnature Validators must not interpret protected-header payload timestamps as proof of si gnature
creation time and should rely exclusively on RFC 3161 TSA timestamps explicitly covering signature data for determining signature validity timing.</t> creation time and should rely exclusively on TSA timestamps <xref target="RFC316 1"/> explicitly covering signature data for determining signature validity timin g.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA has allocated the COSE header parameters defined in <xref target=" tbl-new-hdrs"/> in the "COSE Header Parameters" registry <xref target="IANA.cose _header-parameters"/>.</t> <t>IANA has allocated the COSE header parameters defined in <xref target=" tbl-new-hdrs"/> in the "COSE Header Parameters" registry <xref target="IANA.cose _header-parameters"/> as follows:</t>
<table align="left" anchor="tbl-new-hdrs"> <table align="left" anchor="tbl-new-hdrs">
<name>New COSE Header Parameters</name> <name>New COSE Header Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Label</th> <th align="left">Label</th>
<th align="left">Value Type</th> <th align="left">Value Type</th>
<th align="left">Value Registry</th> <th align="left">Value Registry</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>3161-ttc</tt></td> <tt>3161-ttc</tt></td>
<td align="left">269</td> <td align="left">269</td>
<td align="left">bstr</td> <td align="left"><tt>bstr</tt></td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">RFC 3161 timestamp token: Timestamp then COSE</td> <td align="left">timestamp token <xref target="RFC3161"/>: Timestamp
<td align="left">RFCthis, <xref target="sec-tst-hdr-ttc"/></td> , then COSE</td>
<td align="left">RFC 9921, <xref target="sec-tst-hdr-ttc"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>3161-ctt</tt></td> <tt>3161-ctt</tt></td>
<td align="left">270</td> <td align="left">270</td>
<td align="left">bstr</td> <td align="left"><tt>bstr</tt></td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">RFC 3161 timestamp token: COSE then Timestamp</td> <td align="left">timestamp token <xref target="RFC3161"/>: COSE, the
<td align="left">RFCthis, <xref target="sec-tst-hdr-ctt"/></td> n Timestamp</td>
<td align="left">RFC 9921, <xref target="sec-tst-hdr-ctt"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC5652" to="STD70"/>
<displayreference target="RFC9052" to="STD96"/>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="STD70">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.565
<title>Cryptographic Message Syntax (CMS)</title> 2.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.316
<seriesInfo name="RFC" value="5652"/> 1.xml"/>
<seriesInfo name="STD" value="70"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905
<author fullname="R. Housley" initials="R." surname="Housley"/> 2.xml"/>
<date month="September" year="2009"/>
<abstract> <!-- [rfced] References: STD 96 consists of two RFCs: RFC 9052 and RFC
<t>This document describes the Cryptographic Message Syntax (CMS). T 9338 (Please type "STD 96" (unquoted) in the Search box on
his syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary <https://www.rfc-editor.org>). This makes the text "Also review
message content. [STANDARDS-TRACK]</t> the Security Considerations section in [STD96]" in Section 5
</abstract> problematic, as this text appears to refer to RFC 9052 only. If
</front> you don't wish to also refer to RFC 9338 ("CBOR Object Signing
</reference> and Encryption (COSE): Countersignatures", published December
<reference anchor="RFC3161"> 2022), we suggest changing "[STD96]" to "[RFC9052]".
<front>
<title>Internet X.509 Public Key Infrastructure Time-Stamp Protocol (T Also, STD 70 only consists of one RFC (RFC 5652). If you would like
SP)</title> to change "[STD96]" to "[RFC9052]", would you also like to change
<seriesInfo name="DOI" value="10.17487/RFC3161"/> "[STD70]" to "[RFC5652]"?
<seriesInfo name="RFC" value="3161"/>
<author fullname="C. Adams" initials="C." surname="Adams"/> Please advise regarding both of the above.
<author fullname="P. Cain" initials="P." surname="Cain"/>
<author fullname="D. Pinkas" initials="D." surname="Pinkas"/> Original:
<author fullname="R. Zuccherato" initials="R." surname="Zuccherato"/> Also review the Security Considerations section in [STD96].
<date month="August" year="2001"/> ...
<abstract> [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
<t>This document describes the format of a request sent to a Time St Structures and Process", STD 96, RFC 9052,
amping Authority (TSA) and of the response that is returned. It also establishes DOI 10.17487/RFC9052, August 2022,
several security-relevant requirements for TSA operation, with regards to proce <https://doi.org/10.17487/RFC9052>. -->
ssing requests to generate responses. [STANDARDS-TRACK]</t>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
</front> 9.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
<reference anchor="STD96"> 4.xml"/>
<front>
<title>CBOR Object Signing and Encryption (COSE): Structures and Proce
ss</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"/>
<date month="August" year="2022"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format desi
gned for small code size and small message size. There is a need to be able to d
efine basic security services for this data format. This document defines the CB
OR Object Signing and Encryption (COSE) protocol. This specification describes h
ow to create and process signatures, message authentication codes, and encryptio
n 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">
<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"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signi
fy the requirements in the specification. These words are often capitalized. Thi
s document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<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"/>
<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 on
ly UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
</reference>
<reference anchor="IANA.cose_header-parameters" target="https://www.iana.o rg/assignments/cose"> <reference anchor="IANA.cose_header-parameters" target="https://www.iana.o rg/assignments/cose">
<front> <front>
<title>COSE Header Parameters</title> <title>COSE Header Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
</references> </references>
<?line 405?>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<section anchor="ex-ttc"> <section anchor="ex-ttc">
<name>TTC</name> <name>TTC</name>
<t>The payload</t> <t>The payload</t>
<artwork><![CDATA[ <artwork><![CDATA[
This is the content. 'This is the content.'
]]></artwork> ]]></artwork>
<t>is hashed using SHA-256 to create the <tt>TimeStampReq</tt> object</t <t>is hashed using SHA-256 to create the following <tt>TimeStampReq</tt>
> object</t>
<sourcecode type="asn1"> <sourcecode type="asn.1"><![CDATA[
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
} }
</sourcecode> ]]></sourcecode>
<t>which is sent to the Time Stamping Authority.</t>
<t>A <tt>TimeStampResp</tt> is returned which contains the <tt>TimeStamp <!-- [rfced] Appendices A.1 and A.2: Please confirm that the
Token</tt></t> "OBJECT IDENTIFIER '1 2 3 4 1'" entries are correct and not some type
<sourcecode type="asn1"> of placeholder. We ask because (1) we don't see anything like it in
any published RFC except for RFC 4134, which appears to mostly use
similar entries as privacy mark tests and (2) "1.2.3.4.1" yields the
following error on <https://oid-base.com/>:
Sorry..
Error:
* OID 1.2.3 cannot exist: For examples, use
{joint-iso-itu-t(2) example(999)}
Original:
OBJECT IDENTIFIER '1 2 3 4 1'
...
OBJECT IDENTIFIER '1 2 3 4 1' -->
<t>which is sent to the TSA.</t>
<t>A <tt>TimeStampResp</tt> containing the following <tt>TimeStampToken<
/tt> is returned:</t>
<sourcecode type="asn.1"><![CDATA[
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 line 805 skipping to change at line 890
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
} }
INTEGER 12096870 INTEGER 12096870
GeneralizedTime 29/08/2025 07:45:46 GMT GeneralizedTime 29/08/2025 07:45:46 GMT
BOOLEAN TRUE BOOLEAN TRUE
[...] [...]
</sourcecode> ]]></sourcecode>
<t>The contents of the <tt>TimeStampToken</tt> are <tt>bstr</tt>-wrapped <t>The contents of the <tt>TimeStampToken</tt> are <tt>bstr</tt>-wrapped
and added to the protected headers bucket which is then signed alongside the or and added to the protected headers bucket, which is then signed alongside the o
iginal payload to obtain the <tt>COSE_Sign1</tt> object</t> riginal payload to obtain the <tt>COSE_Sign1</tt> object.</t>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
18([ 18([
<&lt;{1: -7, 269: h'3082154906092a864886f70d010702a082153a308215 <&lt;{1: -7, 269: h'3082154906092a864886f70d010702a082153a308215
36020103310f300d0609608648016503040203050030820184060b2a864886f70d010 36020103310f300d0609608648016503040203050030820184060b2a864886f70d010
9100104a08201730482016f3082016b02010106042a0304013031300d060960864801 9100104a08201730482016f3082016b02010106042a0304013031300d060960864801
65030402010500042009e638d4aa95fd7271866203595303bce232f462a94d38e3937 65030402010500042009e638d4aa95fd7271866203595303bce232f462a94d38e3937
73cd3aae3f6b0020400b89566180f32303235303832393037343534365a0101ffa082 73cd3aae3f6b0020400b89566180f32303235303832393037343534365a0101ffa082
0111a482010d308201093111300f060355040a13084672656520545341310c300a060 0111a482010d308201093111300f060355040a13084672656520545341310c300a060
355040b130354534131763074060355040d136d546869732063657274696669636174 355040b130354534131763074060355040d136d546869732063657274696669636174
65206469676974616c6c79207369676e7320646f63756d656e747320616e642074696 65206469676974616c6c79207369676e7320646f63756d656e747320616e642074696
d65207374616d70207265717565737473206d616465207573696e6720746865206672 d65207374616d70207265717565737473206d616465207573696e6720746865206672
65657473612e6f7267206f6e6c696e652073657276696365733118301606035504031 65657473612e6f7267206f6e6c696e652073657276696365733118301606035504031
30f7777772e667265657473612e6f72673122302006092a864886f70d010901161362 30f7777772e667265657473612e6f72673122302006092a864886f70d010901161362
skipping to change at line 967 skipping to change at line 1052
ec0a9a552298c52027e7bde806c153c1161d466d706455c0ae32d0cb108ca86209f57 ec0a9a552298c52027e7bde806c153c1161d466d706455c0ae32d0cb108ca86209f57
edc3a7f4b36215170994d9ecb9e69d31bab52567b84a3a1568540469984d9b5b6bf63 edc3a7f4b36215170994d9ecb9e69d31bab52567b84a3a1568540469984d9b5b6bf63
4f9d022999cbd6519516d53065f919bee0f520b6b539e2f8fca66f2590c1ce032cb5b 4f9d022999cbd6519516d53065f919bee0f520b6b539e2f8fca66f2590c1ce032cb5b
fdb170ad32125372e651ca4fa7a05ac72f7d5814ea324f99ad2c8110c06853fcf7d2a fdb170ad32125372e651ca4fa7a05ac72f7d5814ea324f99ad2c8110c06853fcf7d2a
f1f28543b0f9ceba2a0f1536faabb07587ebe1d1dddd59fc804697928276613f8d146 f1f28543b0f9ceba2a0f1536faabb07587ebe1d1dddd59fc804697928276613f8d146
f966812da7f25748cfcd298891acdfe041632b760677dfd53865d04d186ce7735d119 f966812da7f25748cfcd298891acdfe041632b760677dfd53865d04d186ce7735d119
0aee0b2cddc0c55e6c48acfda749ec20af4dc0739430d10388bc83efed192c22917f2 0aee0b2cddc0c55e6c48acfda749ec20af4dc0739430d10388bc83efed192c22917f2
f4a67474ac5f36e6608bb71631803fd5fb1a78d7973dd2a01c84dda46f9befccebfcb f4a67474ac5f36e6608bb71631803fd5fb1a78d7973dd2a01c84dda46f9befccebfcb
300ab73628716b8151acf94e58af15de27c141c8d5ef4f82a51bbebc54cb2e1d4ac2f 300ab73628716b8151acf94e58af15de27c141c8d5ef4f82a51bbebc54cb2e1d4ac2f
0c05be7d3db16b9687f5a2fd28fb110f78f82a0ad0370a16cd9cbb59dc0814cba99e1 0c05be7d3db16b9687f5a2fd28fb110f78f82a0ad0370a16cd9cbb59dc0814cba99e1
11e33482e45c9b4f948bff15eba70'}>&gt;, 11e33482e45c9b4f948bff15eba70'}>&gt;,
{4: '11'}, {4: '11'},
'This is the content.', 'This is the content.',
h'f5f0f27964f178dcb2254b30fdfdc48abc4499beaea7cb80f4004f30403 h'f5f0f27964f178dcb2254b30fdfdc48abc4499beaea7cb80f4004f30403
f13a44bcca24fc61c5d71d3823bac04b923011dc7d31de35df1aefcd5a8ec5fe0fe6e f13a44bcca24fc61c5d71d3823bac04b923011dc7d31de35df1aefcd5a8ec5fe0fe6e
' '
]) ])
</sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="ctt"> <section anchor="ctt">
<name>CTT</name> <name>CTT</name>
<t>Starting with the following <tt>COSE_Sign1</tt> object</t> <t>Starting with the following <tt>COSE_Sign1</tt> object,</t>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
18( 18(
[ [
/ protected h'a10126' / <&lt; { / protected h'a10126' / <&lt; {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >&gt;, } >&gt;,
/ 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'
] ]
) )
</sourcecode> ]]></sourcecode>
<t>The CBOR-encoded signature field is hashed using SHA-256 to create th <t>the CBOR-encoded signature field is hashed using SHA-256 to create th
e following <tt>TimeStampReq</tt> object</t> e following <tt>TimeStampReq</tt> object</t>
<sourcecode type="asn1"> <sourcecode type="asn.1"><![CDATA[
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
} }
</sourcecode> ]]></sourcecode>
<t>which is sent to the Time Stamping Authority.</t> <t>which is sent to the TSA.</t>
<t>A <tt>TimeStampResp</tt> is returned which contains the following <tt <t>A <tt>TimeStampResp</tt> containing the following <tt>TimeStampToken<
>TimeStampToken</tt></t> /tt> is returned:</t>
<sourcecode type="asn1"> <sourcecode type="asn.1"><![CDATA[
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 line 1045 skipping to change at line 1130
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
} }
INTEGER 12100074 INTEGER 12100074
GeneralizedTime 29/08/2025 07:53:00 GMT GeneralizedTime 29/08/2025 07:53:00 GMT
BOOLEAN TRUE BOOLEAN TRUE
[...] [...]
</sourcecode> ]]></sourcecode>
<t>The contents of the <tt>TimeStampToken</tt> are <tt>bstr</tt>-wrapped <t>The contents of the <tt>TimeStampToken</tt> are <tt>bstr</tt>-wrapped
and added to the unprotected headers bucket in the original <tt>COSE_Sign1</tt> and added to the unprotected headers bucket in the original <tt>COSE_Sign1</tt>
object to obtain the following</t> object to obtain the following:</t>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
18( 18(
[ [
/ protected h'a10126' / <&lt; { / protected h'a10126' / <&lt; {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >&gt;, } >&gt;,
/ unprotected / { / unprotected / {
/ 3161-ctt / 270 : h'3082154906092a864886f70d010702a082153a3082 / 3161-ctt / 270 : h'3082154906092a864886f70d010702a082153a3082
1536020103310f300d0609608648016503040203050030820184060b2a864886f70d0 1536020103310f300d0609608648016503040203050030820184060b2a864886f70d0
109100104a08201730482016f3082016b02010106042a0304013031300d0609608648 109100104a08201730482016f3082016b02010106042a0304013031300d0609608648
01650304020105000420dd9471efe743c4051335df8f6d2882f3badc387700f7ed3f7 01650304020105000420dd9471efe743c4051335df8f6d2882f3badc387700f7ed3f7
091672a3eeaf7c8020400b8a1ea180f32303235303832393037353330305a0101ffa0 091672a3eeaf7c8020400b8a1ea180f32303235303832393037353330305a0101ffa0
820111a482010d308201093111300f060355040a13084672656520545341310c300a0 820111a482010d308201093111300f060355040a13084672656520545341310c300a0
60355040b130354534131763074060355040d136d5468697320636572746966696361 60355040b130354534131763074060355040d136d5468697320636572746966696361
7465206469676974616c6c79207369676e7320646f63756d656e747320616e6420746 7465206469676974616c6c79207369676e7320646f63756d656e747320616e6420746
96d65207374616d70207265717565737473206d616465207573696e67207468652066 96d65207374616d70207265717565737473206d616465207573696e67207468652066
skipping to change at line 1221 skipping to change at line 1306
f54f303d462832675c8ac89f04c360a1d0d82f8d52ff7d815e74ad4aa19a68a9acfd2 f54f303d462832675c8ac89f04c360a1d0d82f8d52ff7d815e74ad4aa19a68a9acfd2
450855dcb3b2a528063d426dc30268f', 450855dcb3b2a528063d426dc30268f',
/ kid / 4:'11' / kid / 4:'11'
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4 / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5 d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36' a4c345cacb36'
] ]
) )
</sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The editors would like to thank <t>The authors would like to thank
Alexey Melnikov, <contact fullname="Alexey Melnikov"/>,
Carl Wallace, <contact fullname="Carl Wallace"/>,
Carsten Bormann, <contact fullname="Carsten Bormann"/>,
Deb Cooley, <contact fullname="Deb Cooley"/>,
Eric Vyncke, <contact fullname="Éric Vyncke"/>,
Francesca Palombini, <contact fullname="Francesca Palombini"/>,
Leonard Rosenthol, <contact fullname="Leonard Rosenthol"/>,
Linda Dunbar, <contact fullname="Linda Dunbar"/>,
Michael B. Jones, <contact fullname="Michael B. Jones"/>,
Michael Prorock, <contact fullname="Michael Prorock"/>,
Mike Bishop, <contact fullname="Mike Bishop"/>,
Mohamed Boucadair, <contact fullname="Mohamed Boucadair"/>,
Orie Steele, <contact fullname="Orie Steele"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Shuping Peng, <contact fullname="Shuping Peng"/>,
Stefan Santesson, <contact fullname="Stefan Santesson"/>,
Steve Lasker, <contact fullname="Steve Lasker"/>,
and and
Yingzhen Qu <contact fullname="Yingzhen Qu"/>
for their reviews and comments.</t> for their reviews and comments.
<!-- [rfced] Acknowledgments: As it appears that the authors did not
intend to list themselves as editors in the first-page header or in
the Authors' Addresses section, we changed "The editors" to "The
authors". Please let us know any concerns.
Original:
The editors would like to thank Alexey Melnikov, Carl Wallace, ...
Currently:
The authors would like to thank Alexey Melnikov, Carl Wallace, ... -->
</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="C." surname="Bormann" fullname="Carsten Bormann"> <contact initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization/> <organization/>
<address> <address>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</contact> </contact>
<t>Carsten contributed part of the security considerations.</t> <t>Carsten contributed part of the security considerations.</t>
<contact initials="O." surname="Steele" fullname="Orie Steele"> <contact initials="O." surname="Steele" fullname="Orie Steele">
<organization/> <organization/>
<address> <address>
<email>orie@transmute.industries</email> <email>orie@transmute.industries</email>
</address> </address>
</contact> </contact>
<t>Orie contributed an improved version of the diagrams.</t> <t>Orie contributed an improved version of the diagrams.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIALausWgAA+1963IbSXbm/3yKXHXEUtom2ZVZd267PRRJzcgrtdoi215H
R8cor2KNQIBGAVJzxPb/fYt9lt0X2+9kXVAAAd7ADdthc0ZNoCor8+S5ficz
T3Fvb499PuAxY7NqNnIHfOfo3ekJ/5NT1k35pZqqCzfDJz+Z8vevjngsMsHP
qgu3dzpTF5f8bPLJjesdprSeOnR0dnrWPszsxIzx9AG3U+Vne5Wb+T0zqd3e
rFb4N9s7D+32+kH2ooKpqVMH/NmpM/NpNbt6xr58POBEEvv05YC/HqPZ2M32
jqlLZtTsgNczy+oZHrvA/ZOzV+yzG8/dAeP8YzU7n+sDHkauTTWbfdeQoqvp
p/PJ6K+3k8OYms/OJ9MDtsebifzJjT/xl+3DGGAyBXGvpmo+Pp94MOn09Rmu
dqy4ccNdqGp0wM/Ry35Hwh+IuH0zGc+UmaENzcRhVu/PXTXGF1XXjucp7piJ
JfFkiSzTHfoO9hzwYzW9qGfKzkKL+Xg2xcU/uumFGl/1dJ+dTy5UzV9N6lrN
qoZwNa7+ii+T8QF/U43VdLIgcBaa7/um+R9G4fY+nuk7fKuqT/x95cy5m85u
9Pe2MtNJPfGzRZf0wH73wB8uugaY+MWQ8J//B2PEi2ml57Mh54/UtJ65MX85
oZmNFx0bpSd/mP21CuRRT+3DgZDuqf6qs6TSMz7xmKTjdatl1KCuIPwwgXq/
H/bdtHL8dObcyC2GnODiHyCZcX2BHversZ1DUJWrb4wfHh8Orsa8uricTj7j
82c3rdGqo8VW6iMUD4OzMU1yVn0OSnx6dpxH9IHzvzkgE0yzVIave5jg21N8
xEUySzK+w+aJMhs+UUaDJ8iUWDX2izGYG89Il+jRkzevYH14ZnZe1c8Y29vb
gz6THkI72Rkucpj1/AKPcOt8NXY1n32Z8KOX797z0+rjuBp/5Idjy0/GZnp1
SXN+TkO+4OcrHqUOLqUam8n0ckKMx4Odg9nTqsaTM7iZmrwM3avGs0mgnuNi
rT46MpW5mc2nIOH5B7rzZyLgA5hs+eK7+PBivyHcjZUeEb3g9hxWBcZT93pU
1ecYrfduK8N62GA3Er4GGloCIcnZxExGJDTi1EVlLTSFfUOOajqxeAgSZqzv
+uvXPcjo99/pyc9QuJorTAf2hslOFgOHq80kbfUR1+huUBsQr2a8mvEvsGcD
p0cc1g6sdHjoI+Q5Dt3s3yassfvSCOyd/oszs15uaiE3UsxWcKCZPoDomyIM
1Bg1nV4Frp51EwhRgT9HMHjBJ/PZ5TyYXMeGXTSeY+qj0eQLjet+q+pZR8AX
sGV0BXovR5MrUoIprGtVDGCHDkKk9rPzRi8G+hDukH7V7dTuUhD2zTf8Z+jE
EeRat7yDdwh8sFVt5nDDDfNIcwy12uVOmXM+dZcYkUwIw0zGrrNnansxIRHj
Aj3USMCSCn39Gu78/vs+O6xXPNG5IltzU2KJqYe9hVFBjUdE2SWuO35BvAEn
Zor4/eWcfN35ZFITLfSYuoTWXE4rqEkgJvCk0xPcHFUmuLx9duocyAIZezXc
HALj2M/JPe2pz5PKqrFxUIDm6ZYfwXeNl6lvqYWPGzlSu86fgqEOClxdKGhK
x0FetQqEp56NJuOPe5j2RRCZCmJ8tsurfbe/O7jUadwY0q5GI5o7/GjlKzDW
hUl5QiuBqFb0BhEHDQzx4BxW4367rKbOtk6BulLWomsIvJrNG4qJlWTtM6IR
s5lMZ2rcWiENM+P1XNfun+eNaY0rBVKu+mFBATiF1oG2qyH9FzAhcCDoJO5e
veA1IMasmfqAVDDtbMKhYJULVl/Vu02Y6Ay6HUeZf55X0+BIPH6dBwBGcho2
3qkXJKDZ5AKtg12Ba/BHwSAgcRp3TGMHB0N2Nexkn73BPWheUDMFxR9d0TQo
oF51UqgXPLALWqn/agYa63piKtUMexYmdBUkADHS3FU1bgS8NFNydW2Pf8a9
kYMj+DNvW5Gz4/WlM40OtELApHbDqH1v67SBOv6sRpVd6qxr3XCL2pDMOoe6
UOIQggwYNq3I0hFLA+vo8WfBH82IT71LfNYYIMzeAA10foAMrgGhaLzXBwDy
DMFmcH+CaQxNBt57n72eNdbj+HgyAwUN9CJLUje4D55M3Uf4E4iIIlorW1IB
YBiIz40NdNRNP1fGtWZBljG5uECXl+SOcCMoFaD+fNo7FxNwm9LViGyf2K3m
tuovgJiqrucDUmpSngpOk3zX7OoSYhiNiDp4tKkLMRDsfgYWzIL7qJ/xoBGB
GkD/32bdzNWontygEI9PxqPFbIe6SFpat/zpuufPg7DaFv3lZ5zsHex8cRuj
dom0yZQCIsYF9XPT6A6ogvf7reVAQJYEQg35dmc+1aRsio/IlmjMj+gJk/7i
4M3wO7jbjsNj1zBl6ghfwg9ABFPSiCbU8fl4OLt99m5s3IZJ99pwrtCPdlDN
jk2NLrbhwo3tXmDiaPKxoXT95Kk5NXEE3MmGoYfBjM/V+CN519cD7oRJoXkf
l8hJ2YUmNZQ06JtwjoE33u0bdkEOWHE0twtqV+W2wWMGHVxylMFFNl4wOIq2
4+D22r5nkz3t9gZs7FOGXnmggL13Qb/zUUAAq0QtOm+n0/mlgQDqmzJ7Dnbb
3l4Vf7aQwmygqS9apwy9373hkklP5hcdj9d20FI3FMsmd7x4ZuCPW3fbsvgB
3hn64QePtgGK6PiEkDAI0/w5dD6oK9kVhFYB2r1oJEvpOQEvM4AeCzLbiai6
nUoz/sCDgcYx2dbnSQOCeJ8V4XPn9/nlHAmC6TB2PynKy6ezGywg2Q7sqmPD
WkfbeFoC47cHkz6ENFpDsaUPJgNISaGkDyBNPKHIEkIJ0O17F/Q/uFX+46SB
Zk2QIZZ/gbHC9b79+fQMsCv85j++C5/fn/z9z6/fnxzT59M/Hb55039gbYvT
P737+c3x4tPiyaN3b9+e/HjcPIyrfOkSe/b28J+eNRbx7N1PZ6/f/Xj4ZuHz
F/ihh/wVLQABg4VkumZL0fTl0U//53+LBKz4L8g0pBAlIGvzpRB5gi+EXJrR
gotrvhIIYeT5FKWjlJVAdS4RxkZ18MzAZ1/GnPAgGPnffiHO/HrAv9fmUiQ/
tBdowksXO54tXQw8u3nlxsMNE9dcWjNMz82l6yucXqb38J+Wvnd8H1z8/m9H
0Cu+J4q//YFROvu2S2QoR/r6TZO9BOWhvHPa5CdNZkLy6vMestnG6wdERPly
m1QFJzhItHd7re9Natkq6j4Pg+Q1UuEWIXXrJr3WdGkb0oN5CCqN1bZhhWjx
yDt7f9E7p0D0PnsVssYLSo3gVnYbTaGWw4xx2FvVqghyqOqiGkGLepIIMg0T
z9YlkWP/3Myzz4EvKH4AN/APQJjEhj1Y5YeQa49GDpEWHXI9+Y0CWPAxlyNl
Or89UtqN+Idfetj664cGugwu1b9+aBzBGmyKVP8MmfrXbzbBUca+fvXVx/VQ
NUy/8VUBoza50xKMfl6/4GDyyPZsb+JHoGXSrEKQwYfFjrBOZinDuqhmsxYW
hjyl8QH90E0SB1SkW/++WECZhQWIBiKHBI/YrcynALHGAE6tKuJyu6oR1pcC
aQrufUBY56iDx8XvORLP6q+08tDlQQa+s0/UqxBxB9Ns8ojJZbu6GObp6iYF
Zf/yL//Clao/f2T7e+3PPr/PT9N8n12H1RvQf32vx64DHze0Zd92NPQfNv+A
zG/XtCWKOuoWTffXftsnQtY1v6ZOvuMDS8A3tFwI7Rr/s+DsRfjE1zZHJztL
FO5gqJ2l7923naaTnaXZU/NAScu5VU7e/HY9uDy4v+hkla9L33f4/Tq5j6QH
nex/u9CoRSefbz6zkML+aifX/A3+HY0msKCmk5XG+92na/62Xbm8Xu2E73y7
s0QJXQ/+NHDmh28J9503n14D68EiFwz7YSNPdpbk28iwk/RGxn5e6WQjV/eH
sxx0sjL/2zu5BtCk1Gwh7jCd64HDur6zk53l2fSUrMzzmoUL13v3+tkZPv/t
8DJbZfaGn1XbJQrCjWVdH377tp/B0A9fLx5dZ1vLXxZeY7/9ds1+6fv6lZr8
cqmuRhMVvgwiY9M4pDrX3zeTfcigOz2n19L6ec2XFa8yfGx/DXfaL73CsUUv
PzScm3oTdknMbNYEqsDupcksjbxW8BR62NcD/s2GuA5YB1A3/bSnRuDd3zwD
DAP0fkbdh53ivwmLXLtrkcQzAIbXyws3u6vBuQ64sW4hUwjxYTmJdsW6oBkS
sGHSSPhlTTrEn5+dHXX4ZV0O1OGXtfnRevyi2viCKfhqWs8eA05WgEPdNP8y
VZe3LpMOOfXRoWWTmNDe4cWcNqyAZhvdxhCHS1iq2zbqkI+eV6MZgR4/IaRZ
HyCF4XdhpgYutXBoFSjVu10P0+pjNVajlk8aMOiiTVlb6taBvZbA/zjQZ4Xs
1eB6P+gzmMRKJCGXsAH6DKnbGfSxGkluhT6beLsKFm5FLdfLs98IFu7q5NtW
1+4ACz90AeYm9BnghR4jrAMLt0EffluUHv7cAn02dLJGeW7lSYgwq1AONxZG
24+zEfqsIpzFUMsB9jboc90DuTYMtdrEV0Lt4Ooa6DOUzDIlg6g7pOQG9Nko
meVIuLPKk+Fwj8dPS5cfj5/44/HT2lHvh5/4w/DT/v7+wxHbvyXwNJuZJwJP
a0DF3eCpRzG7qzCGwNM3t5y148MDej8tzmK06IcOstlpszg3OISwZt9xPRgi
EHLLvmRzlKFf6avGl/NZvVg8WTo7c0GbMQjQV7vdDnO7ZT66as+uDHr6VI1t
WDPU+EBPazf74jrO0PPwI2GLx4ycmo5oIZ1Wx5rlvWrK6dzCOJyZWF6MDM/f
PLpC6LNbP1cr/KGZNIApbOnQVr/pTjIAgX7o0PeHZabTpZbxgyZh/D8PLPXP
N6jhYQ25O9HS7d4/Zr94MO6aNa7FgOHAYUUgnB+fvN9zYzpdaLuTZPwDad1p
f5LnQ8Cslw0Rqjk7pK9m4QhWOMnwVv2FiL66dFy+6EhpY3sbnT/wulGYdsMM
itCca2rBfceDgFDpWojvLYKkEXsiB0cZhkuKS+uzLczcBUq9d3f1pv4+DFAr
0hpXBUhOucIuTeCiGiOL+SvJirZP0W/l2r3HMKgafQRWnp1f8HYVX7vFQqNq
EPOizY2jS4HgJejcZBXqird7rpeTuq4oK6j8shG2kJ6208IWWg/6JzDayt5Y
GG9zNRJSs0/fj71Yo6WNrwsMRrnHe9q4JxZ8/QqVC9ulonch3ZX23BCdL6F9
G+5+U7RBHmz9ho7QhsF81p5Jgq19c7PJ0aLJygK7IHtcENKo4cKOFxsCNUfG
d7Pn5tDDZTip2RzRUSSksCq/RrlA4B+bA3cbtK/JcYyeTPdoS4CJ4jkiwC8h
yHw3TKx2lIiEzHZw9fvv+dc+Cn1HeoH/ioO9HL9Ojo5hJzLN+Hdtk9/5Dz/s
tv0N7f27vpPv4Fjpe3KwI0QT337vnujStO/4TnfooznAAC0Yz/Z3unYLg/sO
tBZOx7FLjIqFFSbJUqWjVCkTJ8ZkWsY2LbzzqYmKWESZSZiVqSqFcj7SkRC5
k8qXSuKKiqUTidJFnFiTZs5KJWWcJEma5C4SXggb66gUmUuZSjBAapTRcUbT
+JW9CEGYBebTCdUPe52T+tAT/GEgAto1nF2xtOBJxO/z803wcfXzLHlBjLhr
3tRmde6rU6c2d02f2qxjwZADzdSfL+/ek5MPgZOo5h+i39IiiT686JceVN2E
69YcSdG7R1dNAar9j4RKGis4/dPhHrRud+Wowxr7abP6eizY6cnf/3zy49FJ
0MSlL5y/e/l3J0dn/PXxyY9nr1+9PnnP63NFQ/DnkouMg24uOGyCxzzhuBQE
wH/8+c2bRoPx33dHZydn/PTs/esf/xguJgk/kjwRvDzmIubimKcxP055mqI/
/jLlx8c8jvnLnBcFWjbPnNBtccSzY3r+peCHr/hRwV9K/rLg6QnPSp4mPM94
/BKNGQ0dWP9AzzR0TP+f/NJdbmmjVyo3eCWy9Z0NzuXxLqTGl19a3/TLwNHd
wxveyyMue8XbPOMG7zjwkOu8H7yXU94mkc1KK0rrHUxTRnluUpt7n7gkKmQh
jXZes9TCCWifwMo9bL20ZSGVSVJlykIXaZKYMip0kka5dcKVkc5FbmIbJ4XI
vCtlpqSGfHwaY0jpVeTjSHVk/sq6/y77wgWrPwDkTtXVTR9YiHs5wOADQxfP
Gwss4gc9FL9oSU3u8VznbfuH8NMoAuu+3KeTC3XZEtv8RMmdj3Sn6J4ng+cS
eU965YslBY1FfAud3/BnQjxrH7hPJFqJQc3PXTo4aDnQxnXKOGD1HWq5aLmq
oKv62ajif5CgU0Q8fsUPj/mh5KXg8phnL3l+SJYSwzHl/OUxLzOKMEcRT1+G
Z44EPzqiEZOcpyUFnaOUZ6/oscOc54KfJPwE46dcZvxVPgw6bX43m5nV1BOX
llLP0KRJPZ8s8dx0umxl1H+Laecgz3z+9etpe0RI7ieUhTQ1OS96Zqymiyvb
GU2xSbOn0R0RaYttEN4oJ2vPfPJVbBrOOfUHirpug4Xvs+d08kiNu/xoF4RT
SYb7Lcj29/0XjBY/7p9s3plI3j8dbZP2TkzLHN5nf5p8cZ+pMmB278S0zf/b
E5M3KOuKG6bDFaJQpla5sAgz2AX8qc9fB4VWNzYbadnq6O0pV8NSCDf+7EaT
y3C2/UJhJlTr9PZ0WJ9FpFkHpR3VdOxsPhs83tQ8NIdHd9usd7W+a/h8e9bM
LNd6NTl6qENo896zjVto6w840crY67GfLCqglk+GNjR1Z+97G6Qnl0XZHIoN
53uXjaahaUXB2s1d1Q20pr+eoN3FVmZfWBK6q2a1G3nax6yXz1lv4HITDYwD
wm2914X6hOahKqw7q7xCRUubu4A3s2u4CNGb83AyvLP6dolnYKWDIiRaVFpd
hIIJNgbZVIEt3Ghb/BW0nPwUvi8Xq+3T3vRhOHhf/cZfLvzRoEawdwrNFFcT
hhvK3p4z7Dacb1YhhZKAwVZ1b3jhTFtzwo1m8j/306hcKUuC8XXV2ch4hnWz
jP1Ex79JQJ8r9yUwYUPTxSnNhYL+d3qgdivFuKFM7arRxaUzwU3NBGkO1YI8
eMimpjEo9kPH3A2aWpn5KKxDB4Weuo9q2m+ah8KNUN+6XAnX1nFSeOz2bMPp
6ws6xF8pzObQ2oqaUmEMdG4ymjcPNgWnrWZtWNIeGP0y3V0FRTg6EOpJqMJl
eKKeqKDiJlyZja72V1PU/mi6quv5RaOSajZT5lNYCCUTGleX81F32NbQdmm9
RG7n0tszDsNShRDB9HwWwkbvcQaFPs2og2ouiuN0s69iw3ynTe1E4FoTxAYE
hqgMTZ/Wk3FHZF/51mxFNJVgq7YUClnqOdUsQYFmsxDC1RjKQYYTYEjv0Abz
3KkbHiwwQai7aeq/lSFpGDWnBeRJV7OzGBkz61dqQ51KS+0u1YIMz1m01U6j
Kgi2nsynpqk/DRXAfViGPugJVcmenTUbKWdHwTlRyUhbvIiH2rqEIM6JgQl1
UXtJ0Mr+hZSpccODapN+wsOyGAq4i8DGPUXBru5yMh9ZOtI9nV/OVuY/jIXE
fqK7pXeodqGHFcVbs+kRyt8u4ErJM09XTk73gzbFQ6FOicjf3XRKuT4Pw7al
CB+Dn1kM2dU0Ub1H1RzoASvgcWfNTBacH2hxW40Lrl8qoCIOPzQmfwvanyse
yrHp+PcloncToMCfuXvRw/X+LNA/nlcj14Iwp8b1QhDteswqoK0a1bQVIuos
qNJnp0bO7g4rXclLwPZrKoohTf80pnqItouaWEoH80eTEIKp5i+Qb6BUfRvt
iCshHE0obhPXd5co+RK42tW7kauaXkymRInb/7i/2xXijVtrUbPm2L2adhXg
LS6oLqvBPG/kHzeczGlj2ReO6taq+qILne6iLT+vxv1GyWS8uo/a1Bu0qK4F
KDQEGXBT8l6bFl4ue+TWwUIxWge/S9WU86ky7V7pJc1l+HoI0pVgYEvVggHW
/HbZKB8ZARUYVe27B5oKg+lkTthjWl2G6EOdD33KSgl52MhtCzsbMNBHsBAH
niQeNbuoh12l42m7cUvxuik6b3PbjZXojK26srrxr4tkodsNDpaAUeB3Dscr
4biZe6gIczdspS+974dC0t4egQuJyVIpkqEagGD6k247ugP7/b50CCUL5IA4
dXVxQZWdpoMNC1AZPEez03bVaafpXjkQgCVt6lEgJWPsd8KHWHmB1Mn3dBMn
6gNs7nbRe5aFlwR0m+6L4wd0srFzknWDSVvfGV7b4MZNyOkMGX5bhbpRYFb0
T07sctKBcCqca45qLpX/hGK/UG8zumpRb3gtBKHftvsb4wVJLbnGBfPCGdR9
9grhpn1ZxGKy4UUT8wpetJtqAzoX0WdxjoB8QbPyRNR/no8Q2Jvi5oBYGlRQ
N+8waT0oFMFd9oWgLdru3tPRvJuA8N6g6LA3pMmoMZ/Ax6YGd8GhffYPTVCc
QH5BbZt1hlYFFyForzfDRh4DJqsgPvCO/FJHHQvEESFNWSOdbW1CHIV38Nwg
10CAwufJZrUYyM+Qh19iQKMT5AMt+QVawVi6HcI9xdGmdiZkGK8Pfzy8kV2E
i6T3VDVlVIP77uN9vn6d6dHe2H2hpbIaqVWbET5bf5TmWVeQfEXlgzTqPq11
/Xn1BVHhBR7smv9IKyfX/E2owrrm/0DhmZ9Rttd9ed/1d82PQwBp3rByzcMO
etBpOrw2WES75jIr8V9aPcKvPWq7YXHjYO2R6GvQ/l/pfT6U+bfrd4O1wt8H
A4bjIhgwj+474LoaslsGpHMxNCCdmBpKgrfHo0bOz551J6N+pLfTrJfL781r
dqiQi5TkpD1J0BwLRyT4+k27WsaGayhhfZit257ql6oJVvWba+3Kc/AbTWoQ
1vH6tcn37p8/tHBw09Lz6x/PTv548p6Lm8vQK18fvS49WJlu1qbXrE5zjuz9
JONxwY8TfnjIy5S/Oua5pFXmIuOZ5FFMa9BpTB9eHrVPnUgeS/4qoQaHJU+O
qYeTmJcxz3MeH/HjmHrDlVcZfxn1y+Mv3717c3L4Iz97//Ngr7RZdqpWFpXI
25x2J8UOw4vW4APCgfYhq+vLsP8JHzefjkPR3Y01rNVV401CWcPogO+PyT09
F2BtYLWI06QEx3MetnZ+iX7dJLlOynH7/RTcX+wu3mi+WdipkBuEPdwNGwp8
IfThpzVD3hxw1i4W3pxxSRQIPthqWky+7W2gYQAjY6Mu65B81Sv7tGsnP+SZ
WLl+k84doo+4IHZW2m7s/NZbW1ja8GdFCN3P7zeurbHG4c/jLHP48xgrvY3k
XjQyKrMiX33gj47gTyh9DcYry++i4jsZyZRH+UGSHiQZ/+Pbs5WnllzCL/v7
+782TuFsDdK+sf1DMHvlbE8AxrfWpyADM5/cjPduJ8SpNpVX9J6pRUbXlbD0
aGnSrrzcPNM1dPhLR7oWpxi+//6rOOB7+S7F7gN+vhNHhRSwrSiLSqmKLCmK
zOeRjUSUR1KFu7FqWrE4iyRuxLGgbVQ0wkNZRA9FIkujOEpwP47SKKIHIgFt
zSK90i0rRYRfiQpNcjxEvzPfPJLpMITAgwmGpy5FHMVidTjWjydoPDSOotJl
cWETpcrU21zmosgy0JOWKXrQxslY+iSTqkxsXLi4jHOWx8bGSrnYY2B0lkSR
Lso0y0SBKUo8J2N6usDvEr/zOMH3JM5SRVR6T7NgkRBChWlEtplGVMa4BqI9
iI7TFB0rfC2SLJcZvR4xShP0I8BJg1YKrVjTTNN0u5t5Fkd50ndhRZzZNMmK
rMxjGWUgA9NMsjLL8C/ORJ4w6jujSzkaJZnITGbyUkZ5HK658GCS+SzO08yC
Fpcn4ZrIXAYuhu6YpW7yOHRgoQgRkZ0LPJLS1fCAxb0ktEtD5w5zo8eLQAK+
MJopNc6EdBC/pAYY2YEmah6GCFNoyEc34FoRQwv6KceCxZHPww86adm33Gks
JCQFBbipwyVEk4FrkrVEGjyswKgYXM3DFHANHcWgy2J0dCSifvQcwijTPExb
4jkm0U0YMdIQW9k3xBiRpGOBA9No7hS4A75iyJI6yZyKGIwpioqgKQWpN36n
rlRkNqQ7cFjoOjLClQUIjKwq8El2JtBOkXVzhNK1Jieg6fdUO1hxFLkoY9FC
7fJUggs+hxYkTaNVWWwSBXuQLDaJgj1IFgtRLDOc3eD4LdKKhBOgDjODpcVQ
P/yjecLXQRnjMlXhtuxvN84o7e7eYe1ss7k/wNrZZnN/gLWzzeb+AGtnm839
AdbONpv7A6ydPVzF1mgYu4+K3WntbJO5Bw2RctV6F8bbxK+YWkXMt6FTQkdk
+A0L0ClCZlKYxCV4Lk5caQ3CoMy9kfDiIkPvWVkkmo5RYXymnfepyI03ceFx
3bgUnFBFnlilZSaFchEu5i6O0yx2kbOujBNvU1/AzYi09FFeMFAJUkjhyBVZ
3MKsINFEYpIUB0vrtS6EtmQQ3tCURaS8UIXB/7IUVEbMKRnrWBWldpm2iMOq
SFXpTCFzm0XgdAnfJ6XNVFokDl0VkXIixewj4xCkc7g+hQgrPe4kGQJ0jqkn
CQI6HSfTiPUJJuRhPkJaoEJEdJ1Z7zWumUKrFP/PMuVSyWKbgGjMAgqR2cQC
nziZQxg6N5EwKUJ/ZPNCSVzVINRaSQehC+ieSEEuvknBwMoykylQSAZBWJ1D
rtaJQlhwEuoT2SzzRS4lJiALnclC6RTThOiciwx8P2TPUuEKnxRpoXyhS1VK
C/ySZMpjEoao9sYrK7LCWA8slJRAGBp2Bg4KkRiFPhAb4XBSyNE5r9LYpHkK
9SgjE2Ga0sXSWpNnyiQ2MYnJAaqKWJe5t0I76JQ2kFeaClZkkC5mGsW4CB+k
M19C4mUKfVGwlVIZyEfQUXDwJlHWk+tJNO5rUViN9t4hTiOaSfgImGuOCJIZ
l7g812C9he06mIoH910O2TgNX+PyErosvYbRCV8AhiEGqERIY1ypwScMEqeQ
IWaSQylUBJSWKLghpyPodQYdwD98SuHJoZBWlA4kYEbCmdJnmQE3sjKVFn0Y
nZU6UiowQ4CnqUi9y62BDsN/l8ZalZZaQVXAaRcbx5QDhgTpeNQYm1tdepNG
WotUkz5mWUodgmGyKMmtWJtAOALzht5Bjs5bnTKVQb4pbD8rYTZe4x+6xIQQ
ajw8C7ww5m6KyAJxQnWsLaHoaZFn6MSAuAKSYBGcTarBPR0wNtxCJBR5DWF1
E4VsvnBSAoZE6Dgm14Jb7VVmEfMT+NtEgIk5wHmu4VV8aRwuGpVZCdaD2VLJ
MtExDAWdCt91iv4SUTBy2QAuCZQujWwBLoMVApjB+BwExirPDIKjxxwzlZRE
l+66wJQTcvQRIklmooX3R+9pg6lxu4uShaQHyUWmyEdiAk0IkoPrLNwgL5rA
5UekCPLGg+hMAkk5pIwJ/hfFSno5DDNsXfDy/feYwi46ztd0jCRD6KZjtqbn
dQFMhaSCEAUSil5emDZdkQwhQxq4f0UhAL4u20j2WqqJ2swwSV8Dmkt91k8D
FoEQZRYsR+YED05RSmgd/luE6QU4qRllQPENOUgKs4jj96SLtYQt3SCqcnBQ
BqkgNhtKtjYMRSxgD+HBhqHgd+E9wPnkhigJdVOaCKMqO7jcADNCOXlAFIS3
AmhiLWpaYKYOEKUELTI8kCPMyACNRIO3wr1BsoNoLwtcAmBJY1luxAd2gA8g
F5WaMkmcNJlXBjAzYRbPKjh1GIzGmBrOzYgEcTCmaGQyxDNtbAnHnyUIziWs
LBOUIGNWNhEqdc4iP8oproIBaQK0kkTwUwrqgsAGN1FQSNCgRlifGAM3K4EP
4UsVvChgF8zflXCryEngH61U1jmKOyLO0VJoCaRcAntYlcDritQW3pcOfhMx
r3BGwg9BCeA84OOdZQ7hGJg6965IFPnMQsMzpgZ02gJxCRFRxMBXRZzlaKTB
HCAUF2sZOyRYqY9S6+GlLJxR6RHU8V2m5Fsz8tslQgp8MOiBw8s1kAJmlMVS
w3nC38nSp1JlcHqIeSxySeyUKhCgklJlBjEjBl06JWADrfBQTQ/ZSgfM4hSp
cZ7hcQRugxkWubC2YA44hvy3RqAn5qVFWea5ihTQLDwuukVw1nChucnz0ksN
vUBohf0XhBogQgAuBhbBt5FYM1FKAoC5SYBBc2KGFZLUp3Ba0VJIESGwlAgy
El65xGwSOJ3EIw/QRsE3EzQofQ7clykwsADewHeECkNJJ+ANzcUIWZYJBsh0
EcNZpClADLCDiOExCwhIIkr5vIgB8fLIUWUIWqcyJnSXeFgP0lggIYAEJJdg
rEcCBHCEgKtKFSsmTGQSqXViEOaMiKFewuSeLAsiMrBBoFFoGgFLRD4Li8kB
HalmzWukqU4ZZxhASUGtFHBgQXgO8QsBHI7AwSiAKwqwArgSYMR5gXAshYBt
F4iWVGIAfA2nAAQPA3F5iidsbAGy0kSXYIbPckJoGtgMHZXwQTF6V9rbBDAm
Rgg1Jel7UYBWlpTIq/CpgCHD4RSphIpKSSl/7qA7JaUuDjZdKMR2R40UAh+a
gbXoCKTHlmH2IKLQADegHXYDt2KAegtZCg/tAbQGuBOuyRaAqNpFhHy4iMDW
rCJEt/uZNYsI7B6rCHcvIrDHpXgrdLLHpXgrGR67xyrC3YsI7B6rCAj0+Nwu
IiRh8SAOq4j9XUa3H7d0M2A6e/zSzYDp7PFLNwOms8cv3QyYzu5eurlHXs26
wLk+r87wGTkbAQ8P5sMGyiwxVgH6lhZwr3CiTKSC9xaxUsgOyijH7ayE2yzL
VFskRpREa2VLmDaSHqvg0RBjC0s5KSIF0iw8RwABERbBMstLqkaCbOAW4Z2Q
B0mkOj5B6oVQIZGzGySpMRx1TAi6TOCsNTjqAZbhPFlO+QDGhENFQxE5wHif
IAe3IoELRWZmMR8okUqRSKADePHMqFKTyOC+HaJZwrxDDpYbpOSIcYWNXdBC
JNwpXDQ4KAzCJEJvbGMPxwG2WOTowLmpRvxC+NHwuAxsRWSEI4W3lhSrtcyo
WBh+HsktQACy0BiwEsgbU8tjY0pdAF8imS1Sr5CTIZ4xaHUGXIPQGAFJC2Ab
V5B3lhaeUUKvDSVnuUVU1s5SwgEtBqApiwKJLtA0IpdlJkYsQnQsVIIpSA2d
Qxv4uyzLEDDTmPpEnkorIpEkTiEO4CJuAu7kOfJKoGYvkAYig5O+QPIG5x2B
0aAFCCZDwitiZzPgB+sQ3XwBewVuNSlMGdNDxoQp4n8MCo8wBQFDZzTEEAFj
SEK4hRYYNE+AQAqkqJi2zGxUIP0lDAMp5gJgRCOBzGNkn9qSRUUa7EI8kAao
CcAz8QCkEKZHl6DXF4ATiRVQL4A6sD6FASbWWKRExjJrFOJTQusqaWa9QYhH
juY0Aqn0NgWWRiIHXFgUFmDOg+1Q2gI0ZxKYJY8B/YDIpIXjoPiMeAWGhnTL
O2BjC9VGfEEYL9FSwSPAdsjDFbQwBdRVIAZCayjBZ2VWaARDPC4FcvfEUNxP
PaYVaWiPz2A4wBIQrtcFEqsCiBCKCEyispxgNqAiZgT5GbKfjFQRSDFFlhyn
ubXAO8oDEQHmpRpQHiATMRr5eFSYHLgidgJoUSPnT1kG7c5ABvooIVQTXN8w
r5ZJu3YHCIowupRXw/uEtkxQ5O2ccUhuuww2aeKwyQbp9yD7HqbO7PbcGfma
Gibg+C5DduaXcnB2RxIOOxelVni8LDYHHLZdmG/bsO3CfBtw2HZhvg04bLsw
3wYcRg5pPZ4KCXKfw0tDKxD4VyDSZPiXIK2SbarM7pm/3pK6+3atucvdTaMh
SfgvbZuqNqtNIgjcUyonwh4TsrClZJ49MptfzrDZI7P55aHYI7P55WSePTKb
X07m2SOz+eVknsU3VxjCKhVSu4ga3LWYFLjDHrSYtAnYs+UVBIRIeAjtQ/ST
Dgk9MmiNbEg76eGEjQEYQNcIaBmyZVumsEavWIpBTJHbqIQHKQs8BhUnN+oL
VRqgKmTmiEdaCGXInwITi6hwLnEeQAMRsEysY2WKMIJsHjkc2JciK4RzF8je
LPwsokOOcBaR/8d350zkNTxVqUWGxBKeHsEQWs6QYxlSpLAanVhCDw75ZeER
6vCfxJXIgC1SMV14q10Cf4yY40xuRALchRgrTQlJxwQAKX12WYSEE2AFFo0e
4VRTU0QEk1LMD4kVckMkhsg6EacM0B/YZqVPvWYIl5hoimhO5hkjj0II0xnF
GaHBcI147yGRwpRh1bjMtIKUkQgiqKKRN1GSMUMnIpBwO5P4wgIfOWlBBTiB
/FIqxCb4QIm0H/l64svShmV3RFUoE+YdE+FAQchdkdQapLSaJCtpPQGTRyIb
UapahFMRwKBIgGWYhkDwBMPQd6qQVUKZkfEpcMzFCW1TO5MKAMdIQjmizJdw
/xBNDCystaE0GtIHBBUqQnoOrhGDBMCsZWAnrAsZudUYBWgFERq4Okf4dbCS
vCBHDW6KPHUJgRk8ruMEgAm6iylY+PWcxeghpSMfNgHIALRDeIdsAR9ESgc8
AK4ULaNra5Lc03YONCUH9+GDBMBoSqvqLHWWDKkoSsCOBCjLxx5gBUgW8K0U
DsAsiwDtc03bSwpSgDgMUC3iK2ZeWNpbYA6EFvC6NnUiy1QRGyi9yQCjaFkf
ItOwLGi3IsAD+ApHiN8JQZAY2gycnbmcgRclLAITKgEugb2tTYGgYAQFwLmh
JSxIIQGqB+NNCReOPF8BaKBfQCSEX0gWkg6b0jrPlAUItyUYAxNPHfIHhIMS
yLPErChAWIQjGESudJkmiBdGGmAoWgNiqixjAccQF81Wdlw0R3xCwIBp3ysx
ZY/GCUOYwLY639HBBLbV+Y4OJrBH44QkXRzeYOtOb6w/L6XCyjtoU+vXPOjI
lV1zmKo9S4UHzVruhB1qSujY5oNMoFtv6FpGBjwzRBf+FUCHDXotAcZVbKEs
UDdawoLZwo6QhJQxkgvgfMB/MtUo8TfponWpBDkKVAKcLWKhEXlS5NIZLhZJ
juAD3wAfkSqYd2ISmFOCBBzeEPkGXBWSDp+yEg4NOTgmAOSPcWiZBY8i46D1
w7Sk7UdC815qWm4uHXISgY6RpsL5JDqmXUymszt25pMQNyNoM8KsSxPyFo4S
qgy+gbKZhLiLFA+pTAJS4B1zuG4rwzY0EoekgKHGgXRdJmlYnabzEIDicNaw
WQdx0KI90w6Wjiwv91lE+6ZxXCKhQ/CAV1FRTvmo1dAf5ItIueHBPMJWngOP
wrUJxCFaMmXwF4gQ2npLBy5cmWegKxwIiDTibaSy1KlCw1/Dd/sSgAQwFgkm
nA9yXQuXmsWaqcjSzmIaa3gXWVoNeEtb9Ql8b4zw7ClhVeSQkVgo2GvqkGND
iUuTwrehXwssBT+q4Ipo7bcwBJIoNbGuiOCc09iQ8VpgOIJc4Awa06Z1BAyB
jE3RfkTpgeCdNUhnPESGCEjzKAElSmc0AnwJq9YKbjbNckoiYyXSDJJATC0B
UmwJHck0MCPiES3qyLIsEVuQKpWUoMImstQD0WjnIk/4IkPELxHsACNUlnko
JowZ7jpGoEwR7cGJnFaIpZAIYnAtKfIzUgWkz4rWnHO4c5E4ADOK01AEU8Az
wj4LOiWB21IxBG5J6qIj2nvVSiKGkX55pTRCEBCFgzJAAvhJES3o6AN0ASAL
gFPEhBCAGXwJKI0cnNQQPrMwHpgEKXQJBGZ9yDVjiQgBVwiYgbnSoQyEL8RN
A0RDG+aIamC6g/Ubi/Bv0tRlMDgIFr0mJe3NKJ/gDkASzNnCxReFNkXsvINC
SAOGCgzPfKIIKEMlUmAceHKolEbSjvASxXS0BFg8L2yOjBbmquCwIByrEOYI
qRgwwRtNZwiUhtZKmCqwG4QNSsrE0TEJkVqEdwA4PIoIDKsopErJecD3JEB0
jjCkkZ7RAQjtEFohq0zTSWEPROutLEAFHb8o6FEIkfZflcgMHbkAZKJjNQI9
ISo6wYSAAcL6XZKaEuAQyFJD3SnK59HO78MXeH1NDji9nmvwVq7bXjZGP+c7
AI+RlwgoCRxRAcADSAwVjzxERSIgpAKU5ZRTuQG88wmckaegEUN/YpXA5xoF
JQN0oNcqCQuThLkagnsU54RF7I+FdRC0p1f8GTjLwtEWVkQvZGLNqfVfX/Tv
7jk6O2PsdEYFgMOq8UWV/f3OG/8HfIWkZU/wCkkFWLf+FZJnd71h9n4VQgNB
/rusFTo+5mUS3j/1ip/k9NK2o4RHKb1MMU758StevKL3JMqCF5K/6opeXh7y
4yOqPMhzHkX8Vc5PjumdWHlEL8TKci4PeXzCTw7p1lHxr1wrtE5G/1k19J9V
Q/9eqoYeZ6PDn8fY620kL6qGaHU/T1Zu3141lMYHoOFfoWro5ntC+rqhtvin
rw1aE5VX6oR6p/JvI1r3fxvqu1DS+7BCJEZAeetCJNYnz9sUIrHBeH0hkrVl
kgsA5DyJTRKldATAIp/IAEAL6Wm72CAXzSMgUWdjnzMK/7lUsXPK5wD7bSGS
Ek5tLERKw1GCaFGIxIjsrQuR2INKEzZVJrAHlSZsqkxgDypN2FSZwB5UmrCp
MoE9wYaWiNkTbGjJnD2oNGHTEhYLRrVtIRK7zxmiO0+zsEcuGi6Lgj1y0XBZ
FOyRi4bLDGcPWjTcdISILUqNtihEYrfVHd7b2tltdYf3tnZ2W93hva2d3VZ3
eG9rZ7fVHd7b2tmWB6YaDWP3U7E7rJ1tNvcHFCKxTQemHlSIRIui2xcisbx4
gkIkBh+zfSESK9QTFCKxVD5BIRKT4gkKkRidSdu6EAmx8QkKkRjt521diMS8
e4JCJMSAJyhEwoyeoBCJGfcEhUhMp09QiMTK9AkKkdjSUajHFiKxxmVvWYjE
yIVvXYjEhkc8Hl2IxDYdB3pQIRK77ymeWwuRWCSfoBCJIcptX4jEVs8uPero
ErvrPNG9ji6xRx2TWh2KrZ5detTRJbZ6dulRR5fY6tmlRxUiMZE8QSESs/IJ
CpGYSZ6gEIkBjWxfiMTgTLcvRGJKPEEhEgPR2xciMdzcvhAJecATFCIxET9B
IRKL1RMUIjFnnqAQiRGy2roQiaGn7QuRWGyfoBCJrV1FeGghEntoTczaRQT2
2HdNLNHJHvuuiaUMjz20JmbtIgK71+tM7ipEYs3tLQuR2DbvkOmZzrZ5h0zP
dLbNO2R6prP7LN3cmVezReDcohCJwZdsX4jE6DDI1oVIDN50+0IkppInKERi
iKvbFyIxIIjtC5EY0rjtC5GAmp+gEIkRAti6EIkhTdi+EInR6aKtC5EY4a6t
C5EYgNj2hUgMI25fiMSALLYvRGIhW922EIndlTvfqxCJ3ZmE36cQiW1bbxz1
pctb79uwbeuNQ8Bh29Ybh4DDKOJsXYjE7p2/3laIxJZz90cWIrFHv1ZkmGGz
R79WZDgUe/RrRYbJPHv0a0WGyTx79GtFhsk8a1d2titEYg9cTFoPhNjqCsKj
CpEY/Mz2hUgMkGD7QiT43ScoRGJItrYvRGJeP0EhEkuyJyhEQt74BIVIlPFt
X4jEIM/tC5EYnQ/ZuhCJxfIJCpGYKJ+gEIm5/AkKkRhEu30hEgO0374QiW1R
sLyACbeVot4/MWVbvmi2gQlsi4LlRSESW39644GFSO2ax5aFSCycYdhwkOne
hUisEd2WhUgsENYXItExbOHBQySHSKmlyYG+rXdIvYkpcEW0VgirNE6ROQF8
R4JWrCGg1IUyHUF7niUsA9btkYwVyHVs5jAJp1NAf60DOJMwAoVMGFKSsBYk
eAIR9paV96VCJHgo6eEAACMAq6Gz0Gl6q7W1jiW0DmsoGwJ38tJkaGAQxsAQ
2viLgfoRH2m1UFLtBdgFnwM3pDNk18gT0SGycoBHQxjOpUil0J1FmuMRR7IY
URNeM4G7RuAtMWtCeWkedj0VzARpAZJ5A1blLMsLqswqIRBoV4pnqOqntJhB
mijEAjgwi0AhSJaQkEJoQuwwwJOwxpjSS0kZn84xAxsjv6K1fSTEcFy0PlAW
CvZU5FFEybjOqbAKQgQMkTkCJR0DKDzCDnmGDKE/9R6JMyYEnVGIWJY26TOT
QgYx8j3EE0TvUDqEeZrC0R6nQ+6PNFshwhW07h2TkSW00RkTxxGLsxzhEUk4
eW0k9DnlgUlh6YRBqvICPg0+XtNSNBiOuUoGFdMKEU5iEiqBFwJtSNrpGAAE
nyJRzUuN2FnqmDZUbGyQOnphAXggRA9h2RJ8wWRLWkVxoJTq4hIK7wBrCGTA
SymtSSM9d8g4AaDgKUpbGksLzFFOq/YyhytjgALIzwg20SZOlpq8hOUYzEKW
oC/KaOGIrApxsPC0SYGZ5gjp2qZlrGMqW1IMygI3D9sVgCclOE8nFeC54d8t
0LxD4C2tyghtlBTkYXCWqmpy4aiazkKDkQc4XcoIuk1VL1JTzkJnGAF8IGgE
OsAO2J93kI2hZR9ACU0UWNxFaMrRrPDQXQUe5YDbHkFAW2WBloAIERbQjvJS
J2KMC5BhqJ4K9l0i/qdAXwiaIhTeFZ4ZnVBRGwIQsnIkrDBn0iXYMK2/OOha
nsLrANXR6YK4QHCOydIAMREIgPSQJhnm6X1rUWxhnfB2WQ4gp0xRknlBkRSy
cFtIMCeVnvhL3CMQqTCeAjYuqQgLGR9GhYQhKDhGEAoztggAltK7rPB9SdG/
fg0Ms09QA8NUsqEG5ht+aOgv+42c/Uh/J6xmXw/m4/H8Qrups+0f1HG2Cn+A
qvlrfaPqk2vOU6vxJ3Y4cr+5K/7WjcbVp8nnXXakpiP+j2o0UsaFb/THu/hL
+kvL4/EuO3aaH00mI3e1y/7v/6I/gvYPV2PzCU1fTemPvNVG8Z/UaHKhq3G1
y964yZj+wOr7CVWGnE9GuFSNreLH87FW0132tjLnyo34y33+d/SX+hZXfppO
pvSH83ABBL+s6vPJJb5MzhX9TdGXk7kBtqrQxbtpRXUmzo1AxfsJ6OTHanw1
qr7sstPzeag++cmNP+LbzHncPVUQcV1PxuHKZ8ffqPqTQ09qbNk/oflf6U9P
/P2ctX+qsZq2f6e2bv7w6OQisHqf/T/QDN9KhrUAAA==
<!-- [rfced] Terminology
a) The following terms were used inconsistently in this document.
We chose to use the latter forms on the right. Please let us
know any objections.
COSE then Timestamp -> COSE, then Timestamp
time-stamp tokens (3 instances - document title and title of
Section 3) -> timestamp token(s) (11 instances in text)
Timestamp then COSE -> Timestamp, then COSE
b) The following terms appear to be used inconsistently in this
document. Please let us know which form is preferred.
COSE signed object vs. signed COSE object
private-key (where used as a modifier)
(e.g., "private-key parallelogram boxes") vs.
private key (e.g., "private key material")
(un)protected header(s) (where used as a modifier)
(e.g., "unprotected header parameter", "protected header parameter",
and "protected headers bucket") vs.
protected-header (e.g., "protected-header payload timestamps")
c) We see that after "TST" is defined as "TimeStampToken" in
Section 1, the text alternates between using "TimeStampToken" and
"TST". Because this is a short document, would you like to change
the subsequent instances of "TimeStampToken" to "TST" once it's
defined? -->
<!-- [rfced] Please note that we added expansions for the following
abbreviations where first used, per Section 3.6 of RFC 7322 ("RFC
Style Guide" - <https://www.rfc-editor.org/info/rfc7322>). Please
review carefully to ensure correctness.
CBOR: Concise Binary Object Representation
CMS: Cryptographic Message Syntax (per cited RFC 5652)
TSA: Time Stamping Authority (per RFC 3161) -->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
</rfc> </rfc>
 End of changes. 75 change blocks. 
614 lines changed or deleted 424 lines changed or added

This html diff was produced by rfcdiff 1.48.