rfc8778xml2.original.xml   rfc8778.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-rfc2629 version 1.2.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-cose-hash-sig-09" category="std"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-cose-hash-sig-09" number="8778" category="std"
consensus="true" obsoletes="" updates="" submissionType="IETF"
xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.39.0 -->
<front> <front>
<title abbrev="HSS/LMS HashSig with COSE">Use of the HSS/LMS Hash-based Sign ature Algorithm with CBOR Object Signing and Encryption (COSE)</title>
<title abbrev="HSS/LMS HashSig with COSE">Use of the HSS/LMS Hash-Based
Signature Algorithm with CBOR Object Signing and Encryption (COSE)</title>
<seriesInfo name="RFC" value="8778"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon, VA</city> <city>Herndon</city>
<code>20170</code> <region>VA</region>
<country>US</country> <code>20170</code>
<country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2020" month="April" />
<date year="2019" month="December" day="11"/>
<area>Security</area> <area>Security</area>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document specifies the conventions for using the Hierarchical
<t>This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with the CBOR Object Signing and Encryption (COSE) signature algorithm with the CBOR Object Signing and Encryption (COSE)
syntax. The HSS/LMS algorithm is one form of hash-based digital syntax. The HSS/LMS algorithm is one form of hash-based digital
signature; it is described in RFC 8554.</t> signature; it is described in RFC 8554.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<section anchor="intro" title="Introduction"> <name>Introduction</name>
<t>This document specifies the conventions for using the Hierarchical
<t>This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with with the CBOR Object Signing and Encryption signature algorithm with the CBOR Object Signing and Encryption
(COSE) <xref target="RFC8152"/> syntax. The LMS system provides a one-time digi (COSE) <xref target="RFC8152" format="default"/> syntax. The LMS system
tal provides a one-time digital
signature that is a variant of Merkle Tree Signatures (MTS). The HSS is signature that is a variant of Merkle Tree Signatures (MTS).
built on top of the LMS system to efficiently scale for a larger numbers
of signatures. The HSS/LMS algorithm is one form of hash-based digital The HSS is
signature, and it is described in <xref target="HASHSIG"/>. The HSS/LMS signatu built on top of the LMS system to efficiently scale for a larger number
re of signatures. The HSS/LMS algorithm is one form of a hash-based digital
algorithm can only be used for a fixed number of signing operations. The signature, and it is described in <xref target="RFC8554"
number of signing operations depends upon the size of the tree. The format="default"/>. The HSS/LMS signature
algorithm can only be used for a fixed number of signing operations. The
number of signing operations depends upon the size of the tree. The
HSS/LMS signature algorithm uses small public keys, and it has low HSS/LMS signature algorithm uses small public keys, and it has low
computational cost; however, the signatures are quite large. The HSS/LMS computational cost; however, the signatures are quite large. The HSS/LMS
private key can be very small when the signer is willing to perform private key can be very small when the signer is willing to perform
additional computation at signing time; alternatively, the private key additional computation at signing time; alternatively, the private key
can consume additional memory and provide a faster signing time. The can consume additional memory and provide a faster signing time. The
HSS/LMS signatures <xref target="HASHSIG"/> are currently defined to use exclusi HSS/LMS signatures <xref target="RFC8554" format="default"/> are currently
vely defined to use exclusively
SHA-256 <xref target="SHS"/>.</t> SHA-256 <xref target="SHS" format="default"/>.</t>
<section anchor="motivation" numbered="true" toc="default">
<section anchor="motivation" title="Motivation"> <name>Motivation</name>
<t>Recent advances in cryptanalysis <xref target="BH2013"
<t>Recent advances in cryptanalysis <xref target="BH2013"/> and progress in the format="default"/> and progress in the
development of quantum computers <xref target="NAS2019"/> pose a threat to widel development of quantum computers <xref target="NAS2019" format="default"/>
y pose a threat to widely
deployed digital signature algorithms. As a result, there is a need deployed digital signature algorithms. As a result, there is a need
to prepare for a day that cryptosystems such as RSA and DSA that to prepare for a day that cryptosystems, such as RSA and DSA, that
depend on discrete logarithm and factoring cannot be depended upon.</t> depend on discrete logarithm and factoring cannot be depended upon.</t>
<t>If large-scale quantum computers are ever built, these computers will <t>If large-scale quantum computers are ever built, these computers
have more than a trivial number of quantum bits (qubits) and they will will
have more than a trivial number of quantum bits (qubits), and they will
be able to break many of the public-key cryptosystems currently in be able to break many of the public-key cryptosystems currently in
use. A post-quantum cryptosystem <xref target="PQC"/> is a system that is secur use. A post-quantum cryptosystem <xref target="PQC" format="default"/> is a
e system that is secure against such large-scale quantum computers. When it will
against against such large-scale quantum computers. It is open to be feasible to build such computers
conjecture when it will be feasible to build such computers; however, is open to conjecture; however,
RSA <xref target="RFC8017"/>, DSA <xref target="DSS"/>, ECDSA <xref target="DSS" RSA <xref target="RFC8017" format="default"/>, DSA <xref target="DSS"
/>, and EdDSA <xref target="RFC8032"/> are format="default"/>, Elliptic Curve Digital Signature Algorithm (ECDSA) <xref
target="DSS" format="default"/>, and Edwards-curve Digital Signature Algorithm
(EdDSA) <xref target="RFC8032" format="default"/> are
all vulnerable if large-scale quantum computers come to pass.</t> all vulnerable if large-scale quantum computers come to pass.</t>
<t>Since the HSS/LMS signature algorithm does not depend on the
<t>Since the HSS/LMS signature algorithm does not depend on the difficulty difficulty
of discrete logarithm or factoring, the HSS/LMS signature algorithm is of discrete logarithm or factoring, the HSS/LMS signature algorithm is
considered to be post-quantum secure. The use of HSS/LMS hash-based considered to be post-quantum secure. The use of HSS/LMS hash-based
signatures to protect software update distribution will allow the signatures to protect software update distribution will allow the
deployment of future software that implements new cryptosystems. By deployment of future software that implements new cryptosystems. By
deploying HSS/LMS today, authentication and integrity protection of deploying HSS/LMS today, authentication and integrity protection of
the future software can be provided, even if advances break current the future software can be provided, even if advances break current
digital signature mechanisms.</t> digital-signature mechanisms.</t>
</section>
</section> <section anchor="terms" numbered="true" toc="default">
<section anchor="terms" title="Terminology"> <name>Terminology</name>
<t>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
“OPTIONAL” in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ey appear in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
all capitals, as shown here.</t> to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section anchor="overview" title="LMS Digital Signature Algorithm Overview"> </section>
</section>
<t>This specification makes use of the hash-based signature algorithm <section anchor="overview" numbered="true" toc="default">
specified in <xref target="HASHSIG"/>, which is the Leighton and Micali adaptati <name>LMS Digital Signature Algorithm Overview</name>
on <t>This specification makes use of the hash-based signature algorithm
<xref target="LM"/> of the original Lamport-Diffie-Winternitz-Merkle one-time specified in <xref target="RFC8554" format="default"/>, which is the Leighton
signature system <xref target="M1979"/><xref target="M1987"/><xref target="M1989 and Micali adaptation
a"/><xref target="M1989b"/>.</t> <xref target="LM" format="default"/> of the original
Lamport-Diffie-Winternitz-Merkle one-time
<t>The hash-based signature algorithm has three major components:</t> signature system <xref target="M1979" format="default"/><xref target="M1987"
format="default"/><xref target="M1989a" format="default"/><xref
<figure><artwork><![CDATA[ target="M1989b" format="default"/>.</t>
o Hierarchical Signature System (HSS) -- see Section 2.1; <t>The hash-based signature algorithm has three major components:</t>
<ul spacing="normal">
o Leighton-Micali Signature (LMS) -- see Section 2.2; and <li>Hierarchical Signature System (HSS) -- see <xref target="hss"/></li>
<li>Leighton-Micali Signature (LMS) -- see <xref target="lms"/></li>
o Leighton-Micali One-time Signature Algorithm (LM-OTS) -- see <li>Leighton-Micali One-time Signature (LM-OTS) Algorithm-- see <xref
Section 2.3. target="lmots"/></li>
]]></artwork></figure> </ul>
<t>As implied by the name, the hash-based signature algorithm depends on
<t>As implied by the name, the hash-based signature algorithm depends on a collision-resistant hash function. The hash-based signature
a collision-resistant hash function. The hash-based signature algorithm specified in <xref target="RFC8554" format="default"/> currently
algorithm specified in <xref target="HASHSIG"/> currently makes use of the SHA-2 makes use of the SHA-256
56 one-way hash function <xref target="SHS" format="default"/>, but it also
one-way hash function <xref target="SHS"/>, but it also establishes an IANA regi establishes an IANA registry
stry
to permit the registration of additional one-way hash functions in the to permit the registration of additional one-way hash functions in the
future.</t> future.</t>
<section anchor="hss" numbered="true" toc="default">
<name>Hierarchical Signature System (HSS)</name>
<t>The hash-based signature algorithm specified in <xref
target="RFC8554" format="default"/> uses a
hierarchy of trees.
<section anchor="hss" title="Hierarchical Signature System (HSS)"> The N-time Hierarchical Signature System (HSS)
<t>The hash-based signature algorithm specified in <xref target="HASHSIG"/> uses
a
hierarchy of trees. The Hierarchical N-time Signature System (HSS)
allows subordinate trees to be generated when needed by the allows subordinate trees to be generated when needed by the
signer. Otherwise, generation of the entire tree might take signer. Otherwise, generation of the entire tree might take
weeks or longer.</t> weeks or longer.</t>
<t>An HSS signature, as specified in <xref target="RFC8554"
<t>An HSS signature as specified in <xref target="HASHSIG"/> carries the number format="default"/>, carries the number of
of
signed public keys (Nspk), followed by that number of signed public keys, signed public keys (Nspk), followed by that number of signed public keys,
followed by the LMS signature as described in <xref target="lms"/>. The public followed by the LMS signature, as described in <xref target="lms"
key format="default"/>. The public key
for the top-most LMS tree is the public key of the HSS system. The LMS for the topmost LMS tree is the public key of the HSS system. The LMS
private key in the parent tree signs the LMS public key in the child private key in the parent tree signs the LMS public key in the child
tree, and the LMS private key in the bottom-most tree signs the actual tree, and the LMS private key in the bottom-most tree signs the actual
message. The signature over the public key and the signature over the message. The signature over the public key and the signature over the
actual message are LMS signatures as described in <xref target="lms"/>.</t> actual message are LMS signatures, as described in <xref target="lms"
format="default"/>.</t>
<t>The elements of the HSS signature value for a stand-alone tree (a top <t>The elements of the HSS signature value for a stand-alone tree (a top
tree with no children) can be summarized as:</t> tree with no children) can be summarized as:</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
u32str(0) || u32str(0) ||
lms_signature /* signature of message */ lms_signature /* signature of message */
]]></artwork></figure> ]]></artwork>
<t>where the notation comes from <xref target="RFC8554"
<t>where, the notation comes from <xref target="HASHSIG"/>.</t> format="default"/>.</t>
<t>The elements of the HSS signature value for a tree with Nspk signed
<t>The elements of the HSS signature value for a tree with Nspk signed public public keys can be summarized as:</t>
keys can be summarized as:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(Nspk) || u32str(Nspk) ||
signed_public_key[0] || signed_public_key[0] ||
signed_public_key[1] || signed_public_key[1] ||
... ...
signed_public_key[Nspk-2] || signed_public_key[Nspk-2] ||
signed_public_key[Nspk-1] || signed_public_key[Nspk-1] ||
lms_signature /* signature of message */ lms_signature /* signature of message */
]]></artwork></figure> ]]></artwork>
<t>As defined in <xref target="RFC8554" sectionFormat="of"
<t>where, as defined in Section 3.3 of <xref target="HASHSIG"/>, a signed_public section="3.3"/>, a signed_public_key is
_key is
the lms_signature over the public key followed by the public key the lms_signature over the public key followed by the public key
itself. Note that Nspk is the number of levels in the hierarchy of itself. Note that Nspk is the number of levels in the hierarchy of
trees minus 1.</t> trees minus 1.</t>
</section>
</section> <section anchor="lms" numbered="true" toc="default">
<section anchor="lms" title="Leighton-Micali Signature (LMS)"> <name>Leighton-Micali Signature (LMS)</name>
<t>Subordinate LMS trees are placed in the HSS structure, as discussed i
<t>Subordinate LMS trees are placed in the the HSS structure discussed in n
<xref target="hss"/>. Each tree in the hash-based signature algorithm specified <xref target="hss" format="default"/>. Each tree in the hash-based signature
in algorithm specified in
<xref target="HASHSIG"/> uses the Leighton-Micali Signature (LMS) system. LMS <xref target="RFC8554" format="default"/> uses the Leighton-Micali Signature
systems have two parameters. The first parameter is the height of (LMS) system. LMS
systems have two parameters. The first parameter is the height of
the tree, h, which is the number of levels in the tree minus one. the tree, h, which is the number of levels in the tree minus one.
The <xref target="HASHSIG"/> includes support for five values of this The <xref target="RFC8554" format="default"/> includes support for five values
parameter: h=5; h=10; h=15; h=20; and h=25. Note that there are 2^h of this
leaves in the tree. The second parameter is the number of bytes parameter: h=5, h=10, h=15, h=20, and h=25. Note that there are 2^h
leaves in the tree. The second parameter is the number of bytes
output by the hash function, m, which is the amount of data output by the hash function, m, which is the amount of data
associated with each node in the tree. The <xref target="HASHSIG"/> specificati associated with each node in the tree. The <xref target="RFC8554"
on format="default"/> specification
supports only SHA-256, with m=32. An IANA registry is defined so that supports only SHA-256 with m=32. An IANA registry is defined so that
other hash functions could be used in the future.</t> other hash functions could be used in the future.</t>
<t>The <xref target="RFC8554" format="default"/> specification
supports five tree sizes:</t>
<ul spacing="normal">
<li>LMS_SHA256_M32_H5</li>
<li>LMS_SHA256_M32_H10</li>
<li>LMS_SHA256_M32_H15</li>
<li>LMS_SHA256_M32_H20</li>
<li>LMS_SHA256_M32_H25</li>
</ul>
<t>The <xref target="HASHSIG"/> specification supports five tree sizes:</t> <t>The <xref target="RFC8554" format="default"/> specification establishes an
IANA registry to permit the registration of additional hash functions and
<figure><artwork><![CDATA[ additional tree sizes in the future.</t>
LMS_SHA256_M32_H5; <t>The <xref target="RFC8554" format="default"/> specification defines
LMS_SHA256_M32_H10; the value I as the private key
LMS_SHA256_M32_H15;
LMS_SHA256_M32_H20; and
LMS_SHA256_M32_H25.
]]></artwork></figure>
<t>The <xref target="HASHSIG"/> specification establishes an IANA registry to pe
rmit
the registration of additional hash functions and additional tree
sizes in the future.</t>
<t>The <xref target="HASHSIG"/> specification defines the value I as the private
key
identifier, and the same I value is used for all computations with the identifier, and the same I value is used for all computations with the
same LMS tree. The value I is also available in the public key. In same LMS tree. The value I is also available in the public key.
addition, the <xref target="HASHSIG"/> specification defines the value T[i] as t
he
m-byte string associated with the ith node in the LMS tree, where and
the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the m-byte
string associated with the root of the LMS tree.</t>
<t>The LMS public key can be summarized as:</t>
<figure><artwork><![CDATA[ In
addition, the <xref target="RFC8554" format="default"/> specification defines
the value T[r] as the
m-byte string associated with the ith node in the LMS tree, and
the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the m-byte
string associated with the root of the LMS tree.</t>
<t>The LMS public key can be summarized as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
]]></artwork></figure> ]]></artwork>
<t>As specified in <xref target="RFC8554" format="default"/>, the LMS
<t>As specified in <xref target="HASHSIG"/>, the LMS signature consists of four signature consists of four elements:</t>
elements: <ul spacing="normal">
the number of the leaf associated with the LM-OTS signature, an LM-OTS <li>the number of the leaf associated with the LM-OTS signature,</li>
signature as described in <xref target="lmots"/>, a typecode indicating the part <li>an LM-OTS signature, as described in <xref target="lmots"
icular format="default"/>,</li>
LMS algorithm, and an array of values that is associated with the path <li>a type code indicating the particular LMS algorithm, and</li>
through the tree from the leaf associated with the LM-OTS signature to <li>an array of values that is associated with the path through the tree
the root. The array of values contains the siblings of the nodes on the from the leaf associated with the LM-OTS signature to the root.</li>
</ul>
<t>
The array of values contains the siblings of the nodes on the
path from the leaf to the root but does not contain the nodes on the path path from the leaf to the root but does not contain the nodes on the path
itself. The array for a tree with height h will have h values. The itself. The array for a tree with height h will have h values. The
first value is the sibling of the leaf, the next value is the sibling of first value is the sibling of the leaf, the next value is the sibling of
the parent of the leaf, and so on up the path to the root.</t> the parent of the leaf, and so on up the path to the root.</t>
<t>The four elements of the LMS signature value can be summarized
<t>The four elements of the LMS signature value can be summarized as:</t> as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(q) || u32str(q) ||
ots_signature || ots_signature ||
u32str(type) || u32str(type) ||
path[0] || path[1] || ... || path[h-1] path[0] || path[1] || ... || path[h-1]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="lmots" numbered="true" toc="default">
<section anchor="lmots" title="Leighton-Micali One-time Signature Algorithm (LM- <name>Leighton-Micali One-Time Signature (LM-OTS) Algorithm</name>
OTS)"> <t>The hash-based signature algorithm depends on a one-time signature
method. This specification makes use of the Leighton-Micali One-time
<t>The hash-based signature algorithm depends on a one-time signature Signature (LM-OTS) Algorithm <xref target="RFC8554" format="default"/>. An
method. This specification makes use of the Leighton-Micali One-time LM-OTS has five parameters:</t>
Signature Algorithm (LM-OTS) <xref target="HASHSIG"/>. An LM-OTS has five <dl newline="false" spacing="normal" indent="6">
parameters:</t> <dt>n:</dt>
<dd>The number of bytes output by the hash function. For
<figure><artwork><![CDATA[ SHA-256 [SHS], n=32.</dd>
n - The number of bytes output by the hash function. For <dt>H:</dt>
SHA-256 [SHS], n=32. <dd>A preimage-resistant hash function that accepts byte strings
of any length and returns an n-byte string.</dd>
H - A preimage-resistant hash function that accepts byte strings <dt>w:</dt>
of any length, and returns an n-byte string. <dd>The width in bits of the Winternitz coefficients. [HASHSIG]
supports four values for this parameter: w=1, w=2, w=4, and
w - The width in bits of the Winternitz coefficients. [HASHSIG] w=8.</dd>
supports four values for this parameter: w=1; w=2; w=4; and <dt>p:</dt>
w=8. <dd>The number of n-byte string elements that make up the LM-OTS
signature.</dd>
p - The number of n-byte string elements that make up the LM-OTS <dt>ls:</dt>
signature.
ls - The number of left-shift bits used in the checksum function,
which is defined in Section 4.5 of [HASHSIG].
]]></artwork></figure>
<t>The values of p and ls are dependent on the choices of the parameters
n and w, as described in Appendix B of <xref target="HASHSIG"/>.</t>
<t>The <xref target="HASHSIG"/> specification supports four LM-OTS variants:</t>
<figure><artwork><![CDATA[
LMOTS_SHA256_N32_W1;
LMOTS_SHA256_N32_W2;
LMOTS_SHA256_N32_W4; and
LMOTS_SHA256_N32_W8.
]]></artwork></figure>
<t>The <xref target="HASHSIG"/> specification establishes an IANA registry to p <dd>The number of left-shift bits used in the checksum function,
ermit which is defined in <xref target="RFC8554"
sectionFormat="of" section="4.4"/>.</dd>
</dl>
<t>The values of p and ls are dependent on the choices of the parameters
n and w, as described in <xref target="RFC8554" sectionFormat="of"
section="B"/>.</t>
<t>The <xref target="RFC8554" format="default"/> specification
supports four LM-OTS variants:</t>
<ul spacing="normal">
<li>LMOTS_SHA256_N32_W1</li>
<li>LMOTS_SHA256_N32_W2</li>
<li>LMOTS_SHA256_N32_W4</li>
<li>LMOTS_SHA256_N32_W8</li>
</ul>
<t>The <xref target="RFC8554" format="default"/> specification
establishes an IANA registry to permit
the registration of additional hash functions and additional parameter the registration of additional hash functions and additional parameter
sets in the future.</t> sets in the future.</t>
<t>Signing involves the generation of C, which is an n-byte random
<t>Signing involves the generation of C, which is an n-byte random value.</t> value.</t>
<t>The LM-OTS signature value can be summarized as the identifier of
<t>The LM-OTS signature value can be summarized as the identifier of the the LM-OTS variant, the random value, and a sequence of hash values
LM-OTS variant, the random value, and a sequence of hash values (y[0] (y[0] through y[p-1]), as described in <xref target="RFC8554"
through y[p-1]) as described in Section 4.5 of <xref target="HASHSIG"/>:</t> sectionFormat="of" section="4.5"/>:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(otstype) || C || y[0] || ... || y[p-1] u32str(otstype) || C || y[0] || ... || y[p-1]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="algids" numbered="true" toc="default">
<section anchor="algids" title="Hash-based Signature Algorithm Identifiers"> <name>Hash-Based Signature Algorithm Identifiers</name>
<t>The CBOR Object Signing and Encryption (COSE) <xref target="RFC8152"
<t>The CBOR Object Signing and Encryption (COSE) <xref target="RFC8152"/> suppor format="default"/> supports two
ts two signature algorithm schemes. This specification makes use of the
signature algorithm schemes. This specification makes use of the
signature with appendix scheme for hash-based signatures.</t> signature with appendix scheme for hash-based signatures.</t>
<t>The signature value is a large byte string, as described in <xref
<t>The signature value is a large byte string as described in <xref target="over target="overview" format="default"/>.
view"/>. The byte string is designed for easy parsing. The HSS, LMS, and LM-OTS
The byte string is designed for easy parsing. The HSS, LMS, and LMOTS
components of the signature value format include counters and type components of the signature value format include counters and type
codes that indirectly provide all of the information that is needed to codes that indirectly provide all of the information that is needed to
parse the byte string during signature validation.</t> parse the byte string during signature validation.</t>
<t>When using a COSE key for this algorithm, the following checks are
<t>When using a COSE key for this algorithm, the following checks are made:</t> made:</t>
<ul spacing="normal">
<figure><artwork><![CDATA[ <li>The 'kty' field <bcp14>MUST</bcp14> be 'HSS-LMS'.</li>
o The 'kty' field MUST be 'HSS-LMS'. <li>If the 'alg' field is present, it <bcp14>MUST</bcp14> be 'HSS-LMS'.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include
o If the 'alg' field is present, it MUST be 'HSS-LMS'. 'sign' when creating a hash-based signature.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'verify
o If the 'key_ops' field is present, it MUST include 'sign' when '
creating a hash-based signature. when verifying a hash-based signature.</li>
<li>If the 'kid' field is present, it <bcp14>MAY</bcp14> be used to identify
o If the 'key_ops' field is present, it MUST include 'verify' the
when verifying a hash-based signature. top of the HSS tree. In [HASHSIG], this identifier is called
o If the 'kid' field is present, it MAY be used to identify the
top of the HSS tree. In [HASHSIG], this identifier is called
'I', and it is the 16-byte identifier of the LMS public key 'I', and it is the 16-byte identifier of the LMS public key
for the tree. for the tree.</li>
]]></artwork></figure> </ul>
</section>
</section> <section anchor="seccons" numbered="true" toc="default">
<section anchor="seccons" title="Security Considerations">
<t>The Security considerations from <xref target="RFC8152"/> and <xref target="H <name>Security Considerations</name>
ASHSIG"/> are <t>The security considerations from <xref target="RFC8152"
format="default"/> and <xref target="RFC8554" format="default"/> are
relevant to implementations of this specification.</t> relevant to implementations of this specification.</t>
<t>There are a number of security considerations that need to be taken
<t>There are a number of security considerations that need to be taken
into account by implementers of this specification.</t> into account by implementers of this specification.</t>
<t>Implementations <bcp14>MUST</bcp14> protect the private
<t>Implementations MUST protect the private keys. Compromise of the keys. Compromise of the
private keys may result in the ability to forge signatures. Along private keys may result in the ability to forge signatures. Along
with the private key, the implementation MUST keep track of which with the private key, the implementation <bcp14>MUST</bcp14> keep track of which
leaf nodes in the tree have been used. Loss of integrity of this leaf nodes in the tree have been used. Loss of integrity of this
tracking data can cause a one-time key to be used more than once. As tracking data can cause a one-time key to be used more than once. As
a result, when a private key and the tracking data are stored on non- a result, when a private key and the tracking data are stored on nonvolatile
volatile media or stored in a virtual machine environment, failed media or in a virtual machine environment, failed
writes, virtual machine snapshotting or cloning, and other writes, virtual machine snapshotting or cloning, and other
operational concerns must be considered to ensure confidentiality and operational concerns must be considered to ensure confidentiality and
integrity.</t> integrity.</t>
<t>When generating an LMS key pair, an implementation
<t>When generating an LMS key pair, an implementation MUST generate each <bcp14>MUST</bcp14> generate each key pair independently of all other
key pair independently of all other key pairs in the HSS tree.</t> key pairs in the HSS tree.</t>
<t>An implementation <bcp14>MUST</bcp14> ensure that an LM-OTS private
<t>An implementation MUST ensure that a LM-OTS private key is used to key is used to generate a signature only one time and ensure that it
generate a signature only one time, and ensure that it cannot be used cannot be used for any other purpose.</t>
for any other purpose.</t> <t>The generation of private keys relies on random numbers. The use of
inadequate pseudorandom number generators (PRNGs) to generate these
<t>The generation of private keys relies on random numbers. The use of values can result in little or no security. An attacker may find it
inadequate pseudo-random number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys, much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute searching the resulting small set of possibilities rather than brute-force searc
force searching the whole key space. The generation of quality hing the whole key space. The generation of quality
random numbers is difficult, and <xref target="RFC4086"/> offers important guida random numbers is difficult, and <xref target="RFC4086" format="default"/>
nce offers important guidance
in this area.</t> in this area.</t>
<t>The generation of hash-based signatures also depends on random
<t>The generation of hash-based signatures also depends on random numbers. While the consequences of an inadequate PRNG to generate these values i
numbers. While the consequences of an inadequate pseudo-random s much less severe
number generator (PRNG) to generate these values is much less severe than in the generation of private keys, the guidance in <xref target="RFC4086"
than in the generation of private keys, the guidance in <xref target="RFC4086"/> format="default"/> remains important.</t>
remains important.</t> </section>
<section anchor="opcons" numbered="true" toc="default">
</section> <name>Operational Considerations</name>
<section anchor="opcons" title="Operational Considerations"> <t>The public key for the hash-based signature is the key at the root of
Hierarchical Signature System (HSS). In the absence of a public key
<t>The public key for the hash-based signature is the key at the root of infrastructure <xref target="RFC5280" format="default"/>, this public key is a
Hierarchical Signature System (HSS). In the absence of a public key trust anchor, and the
infrastructure <xref target="RFC5280"/>, this public key is a trust anchor, and
the
number of signatures that can be generated is bounded by the size of number of signatures that can be generated is bounded by the size of
the overall HSS set of trees. When all of the LM-OTS signatures have the overall HSS set of trees. When all of the LM-OTS signatures have
been used to produce a signature, then the establishment of a new been used to produce a signature, then the establishment of a new
trust anchor is required.</t> trust anchor is required.</t>
<t>To ensure that none of tree nodes are used to generate more than one <t>To ensure that none of the tree nodes are used to generate more than on e
signature, the signer maintains state across different invocations of signature, the signer maintains state across different invocations of
the signing algorithm. Section 12.2 of <xref target="HASHSIG"/> offers some the signing algorithm. <xref target="RFC8554"
practical implementation approaches around this statefulness. In sectionFormat="of" section="9.2"/> offers some
practical implementation approaches around this statefulness. In
some of these approaches, nodes are sacrificed to ensure that none some of these approaches, nodes are sacrificed to ensure that none
are used more than once. As a result, the total number of signatures are used more than once. As a result, the total number of signatures
that can be generated might be less than the overall HSS set of trees.</t> that can be generated might be less than the overall HSS set of trees.</t>
<t>A COSE Key Type Parameter for encoding the HSS/LMS private key and
<t>A COSE Key Type Parameter for encoding the HSS/LMS private key and
the state about which tree nodes have been used is deliberately not the state about which tree nodes have been used is deliberately not
defined. It was not defined to avoid creating the ability to save the defined. It was not defined to avoid creating the ability to save the
private key and state, generate one or more signatures, and then restore private key and state, generate one or more signatures, and then restore
the private key and state. Such a restoration operation provides the private key and state. Such a restoration operation provides
disastrous opportunities for tree node reuse.</t> disastrous opportunities for tree node reuse.</t>
</section>
</section> <section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA has added entries for the HSS/LMS hash-based signature
<t>IANA is requested to add entries for hash-based signatures in the algorithm in the "COSE Algorithms" registry and added HSS/LMS
“COSE Algorithms” registry and hash-based public keys in the “COSE hash-based signature public keys in the "COSE Key Types"
Key Types” registry.</t> registry and the "COSE Key Type Parameters" registry.
</t>
<section anchor="cose-algorithms-registry-entry" title="COSE Algorithms Registry <section anchor="cose-algorithms-registry-entry" numbered="true" toc="defa
Entry"> ult">
<name>COSE Algorithms Registry Entry</name>
<t>The new entry in the “COSE Algorithms” registry <xref target="IANA"/> has the <t>The new entry in the "COSE Algorithms" registry <xref target="IANA"
following columns:</t> format="default"/> appears as follows:</t>
<dl newline="false" spacing="compact">
<figure><artwork><![CDATA[ <dt>Name:</dt>
Name: HSS-LMS <dd>HSS-LMS</dd>
<dt>Value:</dt>
Value: TBD1 (Value between -256 and 255 to be assigned by IANA, <dd>-46</dd>
with a preferrence for -46) <dt>Description:</dt>
<dd>HSS/LMS hash-based digital signature</dd>
Description: HSS/LMS hash-based digital signature <dt>Reference:</dt>
<dd>RFC 8778</dd>
Reference: This document (Number to be assigned by RFC Editor) <dt>Recommended:</dt>
<dd>Yes</dd>
Recommended: Yes </dl>
]]></artwork></figure> </section>
<section anchor="cose-key-types-registry-entry" numbered="true" toc="defau
</section> lt">
<section anchor="cose-key-types-registry-entry" title="COSE Key Types Registry E <name>COSE Key Types Registry Entry</name>
ntry"> <t>The new entry in the "COSE Key Types" registry <xref target="IANA"
format="default"/> appears as follows:</t>
<t>The new entry in the “COSE Key Types” registry <xref target="IANA"/> has the <dl newline="false" spacing="compact">
following columns:</t> <dt>Name:</dt>
<dd>HSS-LMS</dd>
<figure><artwork><![CDATA[ <dt>Value:</dt>
Name: HSS-LMS <dd>5</dd>
<dt>Description:</dt>
Value: TBD2 (Value to be assigned by IANA) <dd>Public key for HSS/LMS hash-based digital signature</dd>
<dt>Reference:</dt>
Description: Public key for HSS/LMS hash-based digital signature <dd>RFC 8778</dd>
</dl>
Reference: This document (Number to be assigned by RFC Editor) </section>
]]></artwork></figure> <section anchor="cose-key-type-parameters-registry-entry"
numbered="true" toc="default">
</section> <name>COSE Key Type Parameters Registry Entry</name>
<section anchor="cose-key-type-parameters-registry-entry" title="COSE Key Type P <t>The new entry in the "COSE Key Type Parameters" registry <xref
arameters Registry Entry"> target="IANA" format="default"/> appears as follows:</t>
<dl newline="false" spacing="compact">
<t>The new entry in the “COSE Key Type Parameters” registry <xref target="IANA"/ <dt>Key Type:</dt>
> has <dd>5</dd>
the following columns:</t> <dt>Name:</dt>
<dd>pub</dd>
<figure><artwork><![CDATA[ <dt>Label:</dt>
Key Type: TBD2 (Value to be assigned above by IANA) <dd>-1</dd>
<dt>CBOR Type:</dt>
Name: pub <dd>bstr</dd>
<dt>Description:</dt>
Label: TBD3 (Value to be assigned by IANA) <dd>Public key for HSS/LMS hash-based digital signature</dd>
<dt>Reference:</dt>
CBOR Type: bstr <dd>RFC 8778</dd>
</dl>
Description: Public key for HSS/LMS hash-based digital signature </section>
</section>
Reference: This document (Number to be assigned by RFC Editor)
]]></artwork></figure>
</section>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="RFC8554" to="HASHSIG"/>
<reference anchor="HASHSIG" target="https://rfc-editor.org/rfc/rfc8554.txt">
<front>
<title>Leighton-Micali Hash-Based Signatures</title>
<author initials="D." surname="McGrew" fullname="David McGrew">
<organization>Cisco Systems</organization>
</author>
<author initials="M." surname="Curcio" fullname="Michael Curcio">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<organization>Cisco Systems</organization>
</author>
<date year="2019" month="April"/>
</front>
<seriesInfo name="RFC" value="8554"/>
</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>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<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 Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="RFC8152" target='https://www.rfc-editor.org/info/rfc8152'>
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<date year='2017' month='July' />
<abstract><t>Concise Binary Object Representation (CBOR) is a data format design
ed for small code size and small message size. There is a need for the ability
to have basic security services defined for this data format. This document defi
nes the CBOR Object Signing and Encryption (COSE) protocol. This specification
describes how to create and process signatures, message authentication codes, an
d encryption using CBOR for serialization. This specification additionally desc
ribes how to represent cryptographic keys using CBOR.</t></abstract>
</front>
<seriesInfo name='RFC' value='8152'/>
<seriesInfo name='DOI' value='10.17487/RFC8152'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'> <references>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="SHS" > <name>References</name>
<front> <references>
<title>Secure Hash Standard</title> <name>Normative References</name>
<author > <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization>National Institute of Standards and Technology (NIST)</organ ence.RFC.8554.xml"/>
ization> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</author> ence.RFC.2119.xml"/>
<date year="2008"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</front> ence.RFC.8152.xml"/>
<seriesInfo name="FIPS Publication" value="180-3"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</reference> ence.RFC.8174.xml"/>
<reference anchor="SHS">
<front>
<title>Secure Hash Standard</title>
<seriesInfo name="FIPS Publication" value="180-4"/>
<author>
<organization>National Institute of Standards and Technology (NIST
)</organization>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
</references>
</references> <references>
<name>Informative References</name>
<reference anchor="DSS" target="https://doi.org/10.6028/NIST.FIPS.186-4"
>
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>National Institute of Standards and Technology (NIST
)</organization>
</author>
<date month="July" year="2013"/>
</front>
<seriesInfo name="FIPS Publication" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
</reference>
<references title='Informative References'> <reference anchor="IANA" target="https://www.iana.org/assignments/cose">
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5280.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8017.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8032.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8610.xml"/>
<reference anchor="DSS" > <reference anchor="BH2013"
<front> target="https://media.blackhat.com/us-13/us-13-Stamos-The-Fact
<title>Digital Signature Standard (DSS)</title> oring-Dead.pdf">
<author > <front>
<organization>National Institute of Standards and Technology (NIST)</organ <title>The Factoring Dead: Preparing for the Cryptopocalypse</title>
ization> <author initials="T." surname="Ptacek" fullname="Thomas Ptacek">
</author> <organization>Matasano</organization>
<date year="2013"/> </author>
</front> <author initials="T." surname="Ritter" fullname="Tom Ritter">
<seriesInfo name="FIPS Publication" value="186-6"/> <organization>iSEC Partners</organization>
</reference> </author>
<reference anchor="IANA" target="https://www.iana.org/assignments/cose/cose.xhtm <author initials="J." surname="Samuel" fullname="Javed Samuel">
l"> <organization>iSEC Partners</organization>
<front> </author>
<title>IANA Registry for CBOR Object Signing and Encryption (COSE)</title> <author initials="A." surname="Stamos" fullname="Alex Stamos">
<author > <organization>Artemis Internet</organization>
<organization></organization> </author>
</author> <date year="2013" month="August"/>
<date year="n.d."/> </front>
</front> </reference>
</reference>
<reference anchor="RFC4086" target='https://www.rfc-editor.org/info/rfc4086'> <reference anchor="LM">
<front> <front>
<title>Randomness Requirements for Security</title> <title>Large provably fast and secure digital signature schemes
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz from secure hash functions</title>
ation /></author> <author initials="F." surname="Leighton" fullname="Frank T. Leighton
<author initials='J.' surname='Schiller' fullname='J. Schiller'><organization /> ">
</author> <organization/>
<author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></ </author>
author> <author initials="S." surname="Micali" fullname="Silvio Micali">
<date year='2005' month='June' /> <organization/>
<abstract><t>Security systems are built on strong cryptographic algorithms that </author>
foil pattern analysis attempts. However, the security of these systems is depen <date year="1995" month="July"/>
dent on generating secret quantities for passwords, cryptographic keys, and simi </front>
lar quantities. The use of pseudo-random processes to generate secret quantitie <seriesInfo name="U.S. Patent" value="5,432,852"/>
s can result in pseudo-security. A sophisticated attacker may find it easier to </reference>
reproduce the environment that produced the secret quantities and to search the
resulting small set of possibilities than to locate the quantities in the whole
of the potential number space.</t><t>Choosing random quantities to foil a resour
ceful and motivated adversary is surprisingly difficult. This document points o
ut many pitfalls in using poor entropy sources or traditional pseudo-random numb
er generation techniques for generating such quantities. It recommends the use
of truly random hardware techniques and shows that the existing hardware on many
systems can be used for this purpose. It provides suggestions to ameliorate the
problem when a hardware solution is not available, and it gives examples of how
large such quantities need to be for some applications. This document specifie
s an Internet Best Current Practices for the Internet Community, and requests di
scussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='106'/>
<seriesInfo name='RFC' value='4086'/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/>
</reference>
<reference anchor="RFC5280" target='https://www.rfc-editor.org/info/rfc5280'> <reference anchor="M1979">
<front> <front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo <title>Secrecy, Authentication, and Public Key Systems</title>
cation List (CRL) Profile</title> <author initials="R." surname="Merkle" fullname="Ralph Merkle">
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></au <organization/>
thor> </author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization <date month="June" year="1979"/>
/></author> </front>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></ <seriesInfo name="Technical Report" value="No. 1979-1"/>
author> <refcontent>Information Systems Laboratory, Stanford University</refcon
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></au tent>
thor> </reference>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></
author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author
>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificat
e revocation list (CRL) for use in the Internet. An overview of this approach a
nd model is provided as an introduction. The X.509 v3 certificate format is des
cribed in detail, with additional information regarding the format and semantics
of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with sta
ndard and Internet-specific extensions. An algorithm for X.509 certification pa
th validation is described. An ASN.1 module and examples are provided in the ap
pendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
<reference anchor="RFC8017" target='https://www.rfc-editor.org/info/rfc8017'> <reference anchor="M1987">
<front> <front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title> <title>A Digital Signature Based on a Conventional Encryption Functi
<author initials='K.' surname='Moriarty' fullname='K. Moriarty' role='editor'><o on</title>
rganization /></author> <author initials="R." surname="Merkle" fullname="Ralph Merkle">
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></ <organization/>
author> </author>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'><organization /></ <date year="1988"/>
author> </front>
<author initials='A.' surname='Rusch' fullname='A. Rusch'><organization /></auth <refcontent>Advances in Cryptology -- CRYPTO '87 Proceedings</refconten
or> t>
<date year='2016' month='November' /> <refcontent>Lecture Notes in Computer Science, Volume 291</refcontent>
<abstract><t>This document provides recommendations for the implementation of pu <seriesInfo name="DOI" value="10.1007/3-540-48184-2_32"/>
blic-key cryptography based on the RSA algorithm, covering cryptographic primiti </reference>
ves, encryption schemes, signature schemes with appendix, and ASN.1 syntax for r
epresenting keys and for identifying the schemes.</t><t>This document represents
a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography
Standards (PKCS) series. By publishing this RFC, change control is transferred
to the IETF.</t><t>This document also obsoletes RFC 3447.</t></abstract>
</front>
<seriesInfo name='RFC' value='8017'/>
<seriesInfo name='DOI' value='10.17487/RFC8017'/>
</reference>
<reference anchor="RFC8032" target='https://www.rfc-editor.org/info/rfc8032'> <reference anchor="M1989a">
<front> <front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title> <title>A Certified Digital Signature</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization <author initials="R." surname="Merkle" fullname="Ralph Merkle">
/></author> <organization/>
<author initials='I.' surname='Liusvaara' fullname='I. Liusvaara'><organization </author>
/></author> <date year="1990"/>
<date year='2017' month='January' /> </front>
<abstract><t>This document describes elliptic curve signature scheme Edwards-cur <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refconten
ve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with reco t>
mmended parameters for the edwards25519 and edwards448 curves. An example imple <refcontent>Lecture Notes in Computer Science, Volume 435</refcontent>
mentation and test vectors are provided.</t></abstract> <seriesInfo name="DOI" value="10.1007/0-387-34805-0_21"/>
</front> </reference>
<seriesInfo name='RFC' value='8032'/>
<seriesInfo name='DOI' value='10.17487/RFC8032'/>
</reference>
<reference anchor="RFC8610" target='https://www.rfc-editor.org/info/rfc8610'> <reference anchor="M1989b">
<front> <front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Expre <title>One Way Hash Functions and DES</title>
ss Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <author initials="R." surname="Merkle" fullname="Ralph Merkle">
<author initials='H.' surname='Birkholz' fullname='H. Birkholz'><organization /> <organization/>
</author> </author>
<author initials='C.' surname='Vigano' fullname='C. Vigano'><organization /></au <date year="1990"/>
thor> </front>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></ <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refconten
author> t>
<date year='2019' month='June' /> <refcontent>Lecture Notes in Computer Science, Volume 435</refcontent>
<abstract><t>This document proposes a notational convention to express Concise B <seriesInfo name="DOI" value="10.1007/0-387-34805-0_40"/>
inary Object Representation (CBOR) data structures (RFC 7049). Its main goal is </reference>
to provide an easy and unambiguous way to express structures for protocol messa
ges and data formats that use CBOR or JSON.</t></abstract>
</front>
<seriesInfo name='RFC' value='8610'/>
<seriesInfo name='DOI' value='10.17487/RFC8610'/>
</reference>
<reference anchor="BH2013" target="https://media.blackhat.com/us-13/us-13-Stamos <reference anchor="NAS2019" target="http://dx.doi.org/10.17226/25196">
-The-Factoring-Dead.pdf"> <front>
<front> <title>Quantum Computing: Progress and Prospects</title>
<title>The Factoring Dead: Preparing for the Cryptopocalypse</title> <author>
<author initials="T." surname="Ptacek" fullname="Thomas Ptacek"> <organization>National Academies of Sciences, Engineering, and Med
<organization>Matasano</organization> icine</organization>
</author> </author>
<author initials="T." surname="Ritter" fullname="Tom Ritter"> <date year="2019"/>
<organization>iSEC Partners</organization> </front>
</author> <refcontent>The National Academies Press</refcontent>
<author initials="J." surname="Samuel" fullname="Javed Samuel"> <seriesInfo name="DOI" value="10.17226/25196"/>
<organization>iSEC Partners</organization> </reference>
</author>
<author initials="A." surname="Stamos" fullname="Alex Stamos">
<organization>Artemis Internet</organization>
</author>
<date year="2013" month="August"/>
</front>
</reference>
<reference anchor="LM" >
<front>
<title>Large provably fast and secure digital signature schemes from secure
hash functions</title>
<author initials="F." surname="Leighton" fullname="Frank T. Leighton">
<organization></organization>
</author>
<author initials="S." surname="Micali" fullname="Silvio Micali">
<organization></organization>
</author>
<date year="1995" month="July" day="11"/>
</front>
<seriesInfo name="U.S. Patent" value="5,432,852"/>
</reference>
<reference anchor="M1979" >
<front>
<title>Secrecy, Authentication, and Public Key Systems</title>
<author initials="R." surname="Merkle" fullname="Ralph Merkle">
<organization></organization>
</author>
<date year="1979"/>
</front>
<seriesInfo name="Stanford University Information Systems Laboratory Technical
Report" value="1979-1"/>
</reference>
<reference anchor="M1987" >
<front>
<title>A Digital Signature Based on a Conventional Encryption Function</titl
e>
<author initials="R." surname="Merkle" fullname="Ralph Merkle">
<organization></organization>
</author>
<date year="1988"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science" value="crypto87"/>
</reference>
<reference anchor="M1989a" >
<front>
<title>A Certified Digital Signature</title>
<author initials="R." surname="Merkle" fullname="Ralph Merkle">
<organization></organization>
</author>
<date year="1990"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science" value="crypto89"/>
</reference>
<reference anchor="M1989b" >
<front>
<title>One Way Hash Functions and DES</title>
<author initials="R." surname="Merkle" fullname="Ralph Merkle">
<organization></organization>
</author>
<date year="1990"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science" value="crypto89"/>
</reference>
<reference anchor="NAS2019" target="http://dx.doi.org/10.17226/25196">
<front>
<title>Quantum Computing: Progress and Prospects</title>
<author >
<organization>National Academies of Sciences, Engineering, and Medicine</o
rganization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="PQC" target="http://www.pqcrypto.org/www.springer.com/cda/con
tent/document/cda_downloaddocument/9783540887010-c1.pdf">
<front>
<title>Introduction to post-quantum cryptography</title>
<author initials="D." surname="Bernstein" fullname="Daniel J. Bernstein">
<organization>Department of Computer Science, University of Illinois at Ch
icago</organization>
</author>
<date year="2009"/>
</front>
</reference>
<reference anchor="PQC" target="http://www.pqcrypto.org/www.springer.com
/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf">
<front>
<title>Introduction to post-quantum cryptography</title>
<author initials="D." surname="Bernstein" fullname="Daniel J. Bernst
ein">
<organization>Department of Computer Science, University of
Illinois at Chicago</organization>
</author>
<date year="2009"/>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-540-88702-7_1"/>
</reference>
</references>
</references> </references>
<section anchor="examples" title="Examples"> <section anchor="examples" numbered="true" toc="default">
<name>Examples</name>
<t>This appendix provides a non-normative example of a COSE full message signatu <t>This appendix provides a non-normative example of a COSE full message
re and signature and an example of a COSE_Sign1 message. This section is
an example of a COSE_Sign1 message. This section is formatted according to the formatted according to the extended CBOR diagnostic format defined by
extended CBOR diagnostic format defined by <xref target="RFC8610"/>.</t> <xref target="RFC8610" format="default"/>.</t>
<t>The programs that were used to generate the examples can be found at
<t>The programs that were used to generate the examples can be found at <eref target="https://github.com/cose-wg/Examples" brackets="angle"/>.</t>
https://github.com/cose-wg/Examples.</t> <section anchor="example-cose-full-message-signature" numbered="true"
toc="default">
<section anchor="example-cose-full-message-signature" title="Example COSE Full M <name>Example COSE Full Message Signature</name>
essage Signature"> <t>This section provides an example of a COSE full message
signature.</t>
<t>This section provides an example of a COSE full message signature.</t> <t>The size of binary file is 2560 bytes.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>Size of binary file is 2560 bytes.</t>
<t>{{{ RFC Editor: This example assumes that -46 will be assigned for
the HSS-LMS algorithm. If another value is assigned, then the
example needs to be regenerated. }}}</t>
<figure><artwork><![CDATA[
98( 98(
[ [
/ protected / h'a10300' / { / protected / h'a10300' / {
\ content type \ 3:0 \ content type \ 3:0
} / , } / ,
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signatures / [ / signatures / [
[ [
/ protected / h'a101382d' / { / protected / h'a101382d' / {
skipping to change at line 826 skipping to change at line 734
246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0ba 246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0ba
e71696cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c e71696cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c
29d4f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c10 29d4f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c10
7362f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9 7362f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9
ce949be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931b ce949be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931b
a7b3bd0d824a4570' a7b3bd0d824a4570'
] ]
] ]
] ]
) )
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="example-cosesign1-message" numbered="true" toc="default">
<section anchor="example-cosesign1-message" title="Example COSE_Sign1 Message"> <name>Example COSE_Sign1 Message</name>
<t>This section provides an example of a COSE_Sign1 message.</t>
<t>This section provides an example of a COSE_Sign1 message.</t> <t>The size of binary file is 2552 bytes.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>Size of binary file is 2552 bytes.</t>
<t>{{{ RFC Editor: This example assumes that -46 will be assigned for
the HSS-LMS algorithm. If another value is assigned, then the
example needs to be regenerated. }}}</t>
<figure><artwork><![CDATA[
18( 18(
[ [
/ protected / h'a101382d' / { / protected / h'a101382d' / {
\ alg \ 1:-46 \ HSS-LMS \ \ alg \ 1:-46 \ HSS-LMS \
} / , } / ,
/ unprotected / { / unprotected / {
/ kid / 4:'ItsBig' / kid / 4:'ItsBig'
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60 / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60
skipping to change at line 926 skipping to change at line 827
a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc56211 a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc56211
d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465 d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465
95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0bae716 95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0bae716
96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4 96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4
f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362 f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362
f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94 f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94
9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3 9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3
bd0d824a4570' bd0d824a4570'
] ]
) )
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="acknowledgements" numbered="false" toc="default">
<section anchor="acknowledgements" title="Acknowledgements"> <name>Acknowledgements</name>
<t>Many thanks to
<t>Many thanks to <contact fullname="Roman Danyliw"/>,
Roman Danyliw, <contact fullname="Elwyn Davies"/>,
Elwyn Davies, <contact fullname="Scott Fluhrer"/>,
Scott Fluhrer, <contact fullname="Ben Kaduk"/>,
Ben Kaduk, <contact fullname="Laurence Lundblade"/>,
Laurence Lundblade, <contact fullname="John Mattsson"/>,
John Mattsson, <contact fullname="Jim Schaad"/>, and
Jim Schaad, and <contact fullname="Tony Putman"/>
Tony Putman for their valuable review and insights. In addition, an extra
for their valuable review and insights. In addition, an extra special thank you to <contact fullname="Jim Schaad"/> for generating the
special thank you to Jim Schaad for generating the examples in examples in Appendix A.</t>
Appendix A.</t> </section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIALMK8V0AA9Wde3McR3bl/89PUUFFLEkvANb7QcVELEVKFsekJAuUJxzj
sSIrM4uoYaMb6uomhKHlz76/m1lV/QBAUdasw8sZgUB3VVbmfZx7zs1s8PT0
VG36zcI9jR78MLho1UWbCxd9fX7+5NXr8+hrPVyctnpwNjrv3y71Zrt20bPF
29W631xcRtd8jZ5/8e330bftX53Z+Iv65dtIL2305dKsb642/WoZPXr+7fmX
jx8o3bZr9/7pwfDcMo7DNcquzFJfMhu71t3mtHeb7tSsBnd6ITMZ+rencaOs
3nBFGifNaZKeJokyvMCcbp5Gw8Yq1V+tn0ab9XbYpHHcxKnSa6efRufObJn3
jXrnbq5Xa/s0erncuPXSbU5fyNOUGjZM/Ee9WC2dH8Cpq/5p9OfNypxEw2q9
Wbtu4LubS/nmL0rp7eZitX6qolMV8adfDk+j78+ir1fbYeFu/GthNd9vh+Hg
5dX67dPoX/q3/WKe1kn06tVz/+ZkpsP3/VsDc3Cbp1GRlBGTXrrhfb9YuOj7
lbb+AsOVGJhl2dXyJPqXZ+HVlQ0Wq+Lx5+1yI/b64dz/7C51v3gaXYQZ/p/3
8uDBmTOzulRquVpf6k3/3rHQ6Otn51+fv/zHp/62KXJeuf7txWa1PH3dG73o
Q9h8cRg2w4Owtslk/s/p+Pdkpxf6fW+j1+Yf1+56fsub9cXZ8cvehM/7wayi
85th4y6HewZlUhfaLaLn27XpV4fDvj47fvmThz03q80m+mqxvVi79eGo52e3
Xr9n2L1QjvPgYbfu3dAvu9VkpOjB9189f4CZ66LIgxU3ev1WwuBis7kanj55
su7MqbP9ZrU+40Hyo/wn159tft5wCyOkSdI8Dd/WSZHO31a5fItXD3zqo855
T0bnkhZ6be9woF/WN1qyXC/Ip4HbtxuPI9Ndg0eDN85cLFeL1dub6NE3L8/f
PD5Yflzfs/YHX7387jz6btsuiCx5itghqePT7AF5zoV7ofni/HAJL4jiDbPa
Idc0pegR1z7+f7ecJPttyylPS/Hry2ffPDtYgbwQfe/e9qT9TcRiPx1s7wyT
6+vrs14vtQ8SPQCny0u33AxPBGL9l7OfLzaXixAaeVyXY5QUaR1PAQOIzN9m
cxiVib/gi69l9Yfo8IaC8pU2BKfM9oXTIO93a3el/c+yKik5z2X+q6sVAHJz
NbhPQYs3F6tLPUTfbbRx7w4z8M3Z8cveta/1Rg96ubpvwNVl9H2/2RznM6Md
vexH68+/fB59p9ebpVsP8uo9w/5Rvxck1Jdbtzgc+I9nxy//poGfLdzPEpiX
q+Fw3Gdnxy/7cZ+tAZ5+mOveUdCejml4HDaXQIs+axfavLvQGykKT7bDaZKF
r6fhSae4+XR286m4+ezKdgz46vVRtZDho6v16r1uF4S1HjY+hocAOXZM22FO
28FcuEs3RN0a/4xXCR+Iuu3SSMx/Um35inL5Tlw5VatDk311641bgN8v3ver
KNS4W4C/93KwaNI0xWlcCT+RF+8Agx/OuO87Ll5uBAeKkzxLT+oildW8Tpqq
ObQbkLx2Bp7wjHVyzwghJ954AVOif3I3U325yyYjG9GLq4votVu/Wzi1twqo
y96L0yqq5r75CySSvjb6YQkErweoB6E1YjJINE4keqXb1VoTGDcBN8VSwNoV
jMrjH484TcZF19Xhop/dAeOBWfAAHT1fLd+LKTxe74HgV2Nk/L2MUN9boF4B
xTKpb1YbQrRfMqXLK2rGGoLQu6VxskQ/r1VdTYts9PEqn7v1pu961nVrvX+v
NTTx32MNzbyG9nAN3y5d9Cd9EyjDZP9QLV98ef4/cBHfPDsX4nW4in/e6uVm
ezneDJJJrVq9hb+GpfDDcMWT7kyvQ/rwzGgL3DIZoQ9hDsiHL5dv+6VzgpIh
dV8Dr4aXjgjhLSgGie3PZ3bV+/KdxGdJlablk7RImpKLv/vn54dLAeXXK7v1
fog2q+hqNWxOfxrXFwzxdq2vLm7u980LvexhzpSpLygYZHO/3HfRi9uvexM8
eCHVfSPcQtZ+7IiTfcDg/ZeLRb9cUZf0Jnp+ATq8XT04pId3GkPYzNVPYSHe
JPLCcCWGdWtfpYzVsJqlAOwTlOVWJiQv/mhX18sFkml+sanqrIDw1FWcxKcm
8aVLnZ6eIsYgX5Q1pd5cMMXpjkiiQBJ28OzFzDg0eEazHYTbeCndu7VeG1nW
Qu1RUY+N0SOk8OPoSXSsoHYXPkIoP/blLghxtauL+lCIexb1yfxwuFlu9M9n
UfRmT+/vRmSpqGBZy6W4aPf8qT7v5vF51G/keusGs+5bLiH54ISR1x/Bipe9
tWSy+uwgKD981suPv/zPt+1vMLAKBo4+fBiV1i+/RAfGFkMPYYpCgnrsRiXD
2qeb/tLdti/P1d7AOnoPZ9YhqQI2Rm/Wzu2J7OjR6zfnj3de5TbVbvvFJvIY
cDU1ePbmADK4ruslNTfQsQEbeb/zuIUk3Dpabi9bslVx7zyp4e8ROQH/7oie
Dx/GPsMvvxw9Z75X7Z5o9JJHMvfWERyMEGbf9T/zfZh8NM5d3LW6Imp8OIWx
1ccuYV5Xbonq216JBZnJ0P9t7pNJN2Yc5NYE90zCpIZouNSLRXQVeNo7dzPM
q8dE0WJ1rYzHyal8IMc2n0cXq2sHVJ6Mj579rHnAT9sebeqddGglBQi+Bzvl
Md46GIZBbsY5XMMe5/FYONa/7gWD3/oy4dbiOwU69vNU5okJRk9WknD9nGWK
mPAqfHET5rn3eCWPJ4MHMjvaG/LSXQofFAuMSSAeQwown/3x77PusB8j3hrI
gnUIYes6yqmVxWD5yP1sFmCGTE+df/3sNC1KbuZWggtE+uz1aiPTldRV3zsj
AKTtey3VWmLR5zWieXEz9PLUIHHloWHugRv03qLK4qzF6mqqfHO1HSug3D/S
DgagIMuqNxdrh1WZ7TVmYJKE3GJ1s0uYu2JKYveZQAJP3y423u6871ECdmGV
eNKL7CmZLdzMI0momMNIzoetuYgIwO/PnwWuxt9ymQqBL7hhe1LTSait3uoQ
0XJlN2t6fLxcbSTKwk1MXdIF677sQnyeBli5bQ+ZnwR45FHKL2Nwe+9LYKoL
BHREvHgoFNq/IcB6DLPL3Gnktt8Agj9t5e/HfpqMeBOGYX4oTieWbjH5u+hS
L2+mVA6Jeeoz5sBAu7iC5BBPYvi7uNQIpx8+QMRwrvfEBLEjgAftqvRbDX0i
ysa/vQs+aiae+dKPADAJjgMVy7+OfNdnMygiSxQXdE4P/bRMjGrD+PNYO0xR
4vNQpuKk+uWXE+/8Dx9enJ/LD18+P/jRVzn7YndLlobMU4Ip77cLoMSbt/81
n/Odn92VHgZi5Lwn1Q62He7CULsiHSXKdnEpt9heahcZcCPl6Y5IJfbnQD35
1adQLgWsyMN1ABAMeuDr4MIRbrdhx2Qa8C4iMfiFrtEkEIZh1W2uJeK3V0Jt
ZbpEcrv1wOr9hylX1yOSCAhMQNJtQydkGiBE1OXVwvkGHil/fRi2zPCLCUkk
Rac5blbgwIkn+7sWQihE8OS3stEwTVfeWHVKTHb8+LGmjMhtTySFl+L4GThD
go25o24D2aUzpHI/XA4eg9+49WU/NlQ/fEaUXA6eFYYSJrs1Q/Tg9Q/nbx6c
hL+jb77133//5T//8PL7L1/I94D7q1fzN+EKxQ/f/vBqfF++2935/NvXr7/8
5kW4mVejo5deP/vXBz7u1YNvv3vz8ttvnr16EIB+n6x6d/hAEQuuryT+rCDq
PqNRXzz/7n8t2+Hq8yQP+SPtePJnZIlVzveSySHPPJsJP3r40ldXTq9lHMk1
o6/EmkIgwBSyeRkJ+IshxcW3Gya7Hbtvyfv3PcHy4bPV+O3EvkfSPUbEpX6H
F7e7LcE9HndH4qiJsh/TtxOW0QM/feDyExcPwjfwcW31VSAX6sOHV68xxPhI
hkYqs5JX+lKaRacvJNnd6Z+8oZf95m+nIwueyPMeaZ7h2HfSfvnFf1NX0zeN
nr9rhQcgL324fXyZnqpJvSaA9V+BFgE1Hk4KPlXqP//zP2WcVXQgTKJ7hAmq
aBDuPmZaepZ8rsbbf02x3Lo1/dyH6T23fztJi7sighFPv30zDzr3NfdGz878
0hR8QyBHnNzeeA9Jl+DkE8JjZtH4WGM0yObA2KfgYy+brpvDfu4Ir3eNuUf7
7wu5vYp9K4pH/qckYK4hRAePnVjhCXVzIyWVHEMcMUGowXAhrHsZ9mTW456M
Cnz5kmtl9PFlPULnPt+984EzbQz46pHwU0Lnw2cXw4SPv2L4e43kNYlWF+Pj
Ag8isGdhtz+Pb47jZ386yhctYZItOE3CboIwGkZYfOuEGQgoeqoi7HSOIBUk
CM/8VgjsdT8QT+MNoxHFsFKq1mHU6FKCO9rgWXXt3LtBKvxi5Xs+hOjSq949
SwwfiRO9Xk9NhplJhhnZfaEWPfpmuHr3+AQiLSudJk8FPlSOh3edqMPLR9G9
P7Mjzbug6E16dzeQmnbIkO+nl3ARP443xQiqu2v3zm+MALjrORyIwhB3kcgD
ks8PJjMb5nnujTleSygskBVcejLx6nDl7WHb1WazugyTPRobKrbVC3WJZtKz
bN0ZRYrS8Zqmh92+SoXRonE0X4qPVOJ9Vg7J4yb+tG+3+THv9WI7qSd/NOTU
Hw0JS3qkxSHeHqE7tFwFE2HRxxNBQvVewkP/5gnBrkJssxSYeBQ/jv7jP+Rn
pvTj7rHRk3/YX2s3L+8fngQcvpZqH2AXQhwSRTj1uEO23zz5rcvcLUdC/jCq
lc+FT1qZz5dxcWGMH8MYPzLGn+O/3PtWMr3Fn7Ozs7svktFP0/sH8e/PI/3X
jOvjJrQRiJqpFmZnmdxzwG/07RmIjBA7Hz76rtg+hoi9tEfAukVHhsiGRoAb
75P+CLCihfQcplIS7QO6CjAMs94OUeLLy69Riw+fLTz1Pt8D8wlvglq/WmgT
rOJBaQqnzXob9KhosO0wBNr74YNUKgG1LzUsMKDW8lMYwz5qq1uFa59L3reU
GQAF/CY171sJm2sRn2vIyyiuJUm6fg1czS9Pdr7wT5mEUIC/iyNWe58vxnol
1gc3znwu7i8F4bvYSvt32F4JwfVJ2PXvx5wc85Vgmmf1NLr4Q4GC/0MS+6/+
+zT29E++Kw7iJfSExGnpv1+ohWPtB3Ob4Nehee3tpe+W1d5s3KBW2w0KfgrV
AyZzEl0e2URfyhkzuRmpqxVSf2X6wAIEXpyEw3Jl3R3z2TfRgSpRo52GIJBG
MncSRrz8Q5ZKb+aIooXecshk2Jxvba3EMMdUzKy2Czu3kMdZzcTso/OK5nl5
540l729uDxiJwR+ZL9P98XWW/vh18fldr+LVO1++++rR73e+VYyc/ePz/hi3
jWZuq36F2x4ZUkJx712xhvLW+I1GDV4L0RRq1MtID7cazL0VdghSrHe8ZCCQ
uTrc1Q97uwKLg272MG/sKH/LhHRjIE5PlV6eSAH9XveL0ONaHsG1dOiWc888
FOffsrQ3f+7/Mq5OXZ5Kvgmk+t2lo8yRewLf2CXPNG/JQZ/yREWgB3ZE7X5p
nWyHeIaQiG/Tf3908b+Tx6eJX+x2OGEOFM0xfcMc1EfmsF6tNvvbSd5uwadH
BPKTKIPUyhn9f9zcXDkhENO7q80wv/RSvshcZ1V6f/PhNu327b0hcKFutV3P
5OipOsQ8X8Cd7u5cfBDNu2El9MYX1ccpPisJrEHWY4IPrY+LcVNTds6lo6nX
6mBjLUS3tL/Xa+2Z/lgk5u3BO+Z5pTcXrGu92r692JUkHwS/aX3Sc56cPibH
8TRko1362SNXb2U/aWacIRBDz1bJpI7msFntYkrE99ztHUe9NUhY2cyRdhM6
5rFj/b4I/VVf/i/GKY97S6Hwz1ixN/39MBj5tvv53kvVnqI6uNEfblvJxLdX
89z3lzymzUE4HuzUHnH1T0qonyYCTsTtsdDw2njNlFPykkwqUPPwrSfQQsLn
Vy5Op5y7zSM/rcck7FIS4JNaF7ue0f72+K4TBFe5WFnvxF9vX943X/Xx+R7s
Qz+bUty3AaXU74jZnv2X0WkIyCP+FH2EPzH6V6vd8dJpm/LPPPwvJ9FSqI3v
7n0tYz+Tnb3+EtVyXwMtYII2xl0RSXvVZO9AKIm/vCFCl283FyFG1w47+AIe
LfdLUHj09bSs694SvuSk32sb7bvryZKy83kCSbE/jyb8y/zoHVuSgB/hI3Q5
cOQe173+Q/I5X1L5ks9cx/+5/kMdpnV129oHk98llLeJBMaUhiNez9OaIiEM
DI0/PRp44brN6XDRd5uw9n2maC6ceUdG7ijxbq4TL75DUeZnhYw8G2mPtu00
wJV3zyJU8nGLdbmZkNBcrHrjZk/sQlKFNvv1ya1C9OxKxuh/jr44krO/gemK
78Z0GI+lHNBdXp8Y6Tcw0j8ln9/9enrP6/ketz1+r/4kcvvfwm5na6vBbW4z
3OmIUL98v1q8HxnfYX/z+Z5w2mXemudQIH0MzKzqqCbfXwwCSZyJ8Rga6tBd
oaLtP2ikGAjCn7ZyUG86vzOF4iPp3cx04ubPVxSEx7eC6yi09xx0q0bt07rn
8mVsDk1lJzxirDm/8mG0l/NyB+oMZaS3U6H55FNxh4e2plDfXK/uPBk2nkv/
tAq0N4LnJXpKwTCKx7+7CuIwev/Y7f58gd9njw7VwjHlnPf5fgkNiP2rw7mr
0OSTCTg93EhIywm73ZGiEyEhITZ8LqrdrtcEOnd0Ey+FlYYGR/i8mT/uIQIN
jyvjuVygrphhjWsWN7ujQFC1ceR+70D5xHTHLQQ4qcw1NKH2l2W3/q+DSfXW
j4E1/yS7EOEQofafOhw7cWP92SPcPpV9h86fcvEI7zH4Ult3sOEnlnr4bnPz
EFrgFjbyW9Rk5UPMd4r1Hp5Nm3Mvw7Ie8pjpYil6ONpJSvabT7iX+f64uho+
dv9k+YdihId+52WuR0bOG4Xl3xVxv+txBFvf3Tzcq30YO7z4W57Y2/ue9uxf
5x4NED5iXNhLmp65d85RWpOjoH+53FXZk+DqPYTspbO9WLgdw3j48uH++UQZ
LSkDON9C1iPFO48xb914bRxgbPo8p3x2wR80GTsRHz4bnBF1OoLWfJ05vG7s
8e9wSuZ4dBhOrWE974UWio2mYyLjAGNT8RCvAsqM3UK9v7F1zzTC/pebT8nI
htxSwQJXwjt97w+iOz9bkv+eB8vW+8ujOfqgmo7NHHV8BHDlSDl26Hfwun8B
+XkzHoybKrJu+4WsgunhlLf7ZymF2csGotqp5t1YAQQOTRhm9845aORam3cy
BV/CldeyQabut4C96mydhx0niuXVavDm2J25mTq9fkCPYXqjfW03euuPCc4K
SNAq2Nxnwe5c3IqS7Y8Fqt2xQJ9/+mCTbmqSHT5K/D5sVuvwyZolSklBWVjv
Qg7r2F7LPut4QS9Dvu/XYfNNmwtYbeSWvLLyHyg8iTrdSy5dszb5zMPxtcNS
Xw0Xq41HITlGgf3nz0P47qyaj+D686esTJTJ5XbwxwwPz2i55TB2drqQmdq7
WujjbOAJ9yfu5RmAT1sxyZXufffwTkdP+9e+Z62my31HbWTiC+8/X7R8Z3m6
Zo6CGYb8DvVdDxnXEHTbRPUOtlaHCfTUPCG9v5UlHXG/O9lfjkRuf0xAbHdK
Uwby28r+/KOf8tV2LcdRR7JxyFAPUgtk6UMXZmSO4+nwgyNx2J0K+dNW7roa
3NauTg+unh6wwkSPvvv+m38cHosj54Vt5BSomhpL+GWXzLh2Iyd+1rLhOoFT
EOd6syGiGV3SH6Ul0K0u5fCjHImUzbcVA135zx8E0iCP3g/cYKvxipAlYSt/
cP4sxNiiC7PxFMMfqIb6ezuR1b3HmV6CnpVc+B0/Iejr7caJyY1st+yPdX2x
WgQPD1faTJ3nQwdgSIlodWhxz96m448nYxkYP7frD1F1/iJ/dEpKwdstHIhE
UtMRNvm1CHc6/E4eGlrge02ZMBu18/+fLgQsvCQlP0cNMYROQ3RfRKjjiAgB
cUc8TCqkFxyQE7Ny7nqQk6xOeSOPyXZ/8AYwn+wQ6PFsMGrmpe9fzhaTDdNv
92DoVsFeXe3V64Nd3fX9W5wjl/BIvNnvpKtPOPoTeEwoaMMk0fTBtvGyW+vd
bqxfoHx8O3TDhU3tnewYfKt06z+Aay5Wux2Uo89ETEdZ/fHxoDd3p3oYpaXe
7w71TB+R8Mpa5IfkiN8kDnkyHTPygLxH9Y8FbtitVXPhHI/S+uzV+733zfSB
hlnxT+dm5TD8tdpfokx3TSAiOawE/+oAJpeCoOMU93ZPpqfPAblfdJ06nMr0
sQqJptARZ1aC1mYtZV9S1vkmsTQFzEzK1HSrr02TCDnbHcRL0rP0SFBPST6s
LoUBabPxsXNUYJCa6xW1yy9GPDXSMJlVJ+e2hyFsX8kwozOEcsy3neyZYmAZ
Qt4OSu9sOzVb6w5acvhpBW7fHBzh3/ld3R1o4eRX60Lm+7E/GmEU26Dv5FPR
b1Cd8pn6cYvbq90lKnT+LNl4QPqIKQWvBP8R5ZuxV7MXH4fkLkjqBfJb5kxJ
puSqse8XTvFf6+kc+/wpFf1+1dudLDviq4M/snBIccOegkzrZBeUPnbXwfI7
Y8457auoEDh1xHF3g0m0+c+DjJeOKDph4Px5NWX7QUBmJScbfJdku/RVL0Df
ZBxG8R+YkM/9SfPtFoDKL6MAPv2bY17y3NEoVhjMZj2NendRGg9QPvB+nptB
w4Ndo8+fjNjdu3+ubywY/mY1Bcnevf7EzNHIu9/H8aX8Cp2A/XL8XuZ6czDk
3fP58EGWS+5ejNu9ex2G1WJ7udxro37jP4UbjY0Ar5T471+kDvLymy9eJNEj
/xMBuLmWGPTbBrLktChGlRB+0UdAZ3n0rjE9/wkdKRHawMna1xUx+WlePvbS
/IVvKflOWZjO0ecdbn9Syd/2vfNIZ/xkDw7NP/ompP3tGcoHR7/0v8rm8TiG
WV1e+g8VMcq/EnvjDtRBZv8mt9zh6d/jlSOXpJNL7rb+XQb97pA6/LfZ9y5L
7jDyv2TTvdvvsa466qodW3caabLmPeYEjQV39406+oUM9z++0q1bhFGyT/GJ
7xKPT5YPff9Pc5R8jrpF4OCyL3/WUuKH8aMbcy957/PEouDn39wVuXBDoETe
YRT+3cHZve42JY+6euv6H4WPJtH+ud3wgTZfF/ph7Pj6j74Y448Ovh23uJX7
eRM+FOgtbHv9drkaYCpTl3iqhO3N2Ncqk3jeivKfsNSXI/m8dnexMU/9RpNM
tKHzREdv1PRbbPDLxbYNvxdAfqPc9dsnkxk9zo8/BOt8JdZ5PVrnfOfLg1Xv
rH2Hwe4xsN8TCh8gbpFE8mudRDQxKsAdh41irvnw4cNeAExRMz2EMNleTnwc
kJ4/+zfHD5ZVI6s5PThFcuabrHoZVP9uK2G8ccel1fQw6fFNR/lJ6ImNnUW/
oJl8ZDb1I4L8z76sPJm6dkziSXTxUCdxFscP+f7DXHb+LRp/KYPfCuDH7Gk8
vvkLF55E40jb5f5YH36Z37jSN/LbG/juobdLP/+iABn17OF84R5ReDJOMJr/
vnOySVan9nC6YcpYkK/JUzH3v812/be9q/bmfuf89y59Er3r5bX86cOXm+GL
/u2uYf7LwRC7xJT5xYd/kvHvrEnSJrGuKo0rXZrbxKVaNW0Zp2VZJE1rauPq
uunqJLeujTsTx87ajLusy3TLlW2ns7bLKxvHla3zXHeVbatcNU43VZoUrk67
vChNa21eZXWSmlLHeapd1hRZUzd1VaSmlkfqtCqdqXXTOUbmQakqWtu5WLe1
q6pM68RkpXYpcykrUxZtW9ZlFudFrAvbpobX8jhrq6ordcOcbBbrOFVJY9vC
IDvqOrdVkeRdxmySJk3jOI3bTkZoY1eYsimKNkvrMu+Ssmsqy91dbFrmoyou
qtu4irPUZXEbZ3nKWG3dZdaUdZXkeerKrM7bJO6KoukKa4om18y1SXOT18aY
TGVVXNUYtiyyzlTMNccSNYGDZdsiKfIu7VLT4hJt40IbV2mjXYmfkja1cdNi
SpVUVZLaxMSJy3hcWegudUysK3SRJrrmr67NrE11meK6vGpZbeHStCxsVlZx
a8tENalr07Yr86wpc5dWdYbvtDNZnnW1y4oqcXlnurgx6BPd5K6O8yrWukoL
eXaVZbpQRVY0ceXK0lRt08VtXbdJ0ViT6oqVOpdXXZK5yiUZrmBBruhYuBYv
tRWPa1i2Suqsc0meJlUGjqVll9eVMbWtTUsIdTi/TarcOW6JCdMuawwOzyrj
OttlXeLKpFUFlxTEVpKbmIji2tRkDbNwBuMTDWXSEGKl0TZtmhiLOKIn0W1n
XdMkcWWqTlVp3RCUbZfqPGNptbM8NWnKpksz2zZ5o/FSy1qyOkssjmEliS6z
oujqjoBLSqNs15m87eqybpK2wUpFZciCVBPYJFqRmIa4z3NjkthwpWmc6do2
d3lSt87GXZblSjNUkWWNK7G3NXgiYZoF7nVJ62pdlKUtmpahbZLFDTFPNBIC
dWXLrMxLx3yU3OPwT0KaVDpJM9Zqsi6rCFNjsWyXS+zXeUwklk1SJSap6rpg
oRnx18S1zVSpy67WdVriGyJKZzk/6rjiCoLExGVsSc467vAGjiBB06xuYoeL
yyxrm9omlSosCevarqvjWPOYzpBizsRpnVXY38aEbyPz4W2jO1uUdVyQBlVG
SiWtxilWpZmrS2260ml5tU40ge8SAiQrE9MS4szBtYBPbDBVk7DYJJW52a4l
hI0m2EAyE2eFrbglZloJGQYY1k1qyN8a8OtKVlnGeZc7H01tG9dxVeR10jWk
cFxpVRSFJvRkeXlKypKXjJtAPcCGPMlaUkW7QrfkS1KQYriXSMHpmNA0ddq4
VmFPR3wWxjVl1sgdaa5zHmv5WrYV8VcUZQfGZnmdGyAjSQAaneSxZepZ0pWF
ypK4wKa2kUk0sc1dC+wYydiktkyiKUxsSYKy0VxGHmRlmxaEU9M2tjM8IVFY
vYtzEiRJstIIQmS1XCpuAaV5HBFIwoM6AiQa6AYgMpC96wqT6MrFNUBd1jwZ
tCxJOPwFjhE6VHD8kec14O6SxOYaRLZkWGObvMwswYbFwLHS5Y2iDOQgFZjU
ZKbOGKjiIjCorkuiizWnXUMyFUYnSRnDaJuyxD2pFpTD4PytWuZWVOQF8BCn
xCzFxHWF5GPaYUAHCuJgnNuV1CyTW8wXkw54hWIAUhirMCiZx3y5rTEpaERy
8cDUaUscJk3WFay8bqqYkpURMhi9IaESkMpgfZ0WKu0cC2rFglmT1QBZ6yoL
0DWUA+2qxlBCLXhS8b+urMTduLFLizxzNmuLNG0VCYHHKhAPpIirztgsJQ7T
TjdEV9VUeDcuWkP0UwGaAgMmxCLfp+BU12RJWYInLFw3FPWkZeaAINXUkkyg
hgHSYlPkMeWAimE1YMG9xtpOY31XYUOqfqG6RJvYaWpnmQIyBEGOHTKyT8oP
taQu4hgvcTvVJWWmRU2Bp+wAYF2D+12lYpO2VQMeupwka/OOMKDqS+E1HcEP
eKaNBnFq0LgVMMb6KdSkaHUptACwVDFADmonZZMRg12apx3uB3sMJagglEk5
zI2LU7iKaVoLDFtKuhO403Up/CQjCMX3liythRI4ErcGsOuq0XkFDOAQ17R5
glttV7fU+AQo4CpCmOJlkoziVad5UTjjgCd8RKnHEU6Lk6EWoHkSUxDJyjph
SGK9rQw8J3GUQeoskJIqoJEUInxJjLLNklwDoWlTEQptxWhUYOwZtwQbMwJQ
XZfVNYWP8MoyuAHLUJVrTJlSG0vbUavSAjZEubUpBV2KMmVeMD4vDEFdALcW
zC/zCr+Qr8wQ6FOy9LSF8RVVCSAYo6u2pGaVlLomp2LVVU7FAwsTipuuJdVa
WKM1ZAsvAxqJ6jqJohTCIFUc5HMQ47ikEMJ1SCCyOKOwlyQBQVwRbl1L0e5s
TdHLBZqzTHUFhb41BqPhP5C8q7oc5mQIQe5KKX4C4HDRStxtwBJTxQlepyDK
RIFAFVMssxSkI1Yo/lYnGYCc1pKwVHXm1zS6qlIYT0L6cB/J5ADcTKDZwiFa
TbAZzEiyEBWwmE6s31DDSpJNl9CUJG9jSwVssjjNWhLM5oKVWWN1U/vS21JG
M7IeCpbAyVKNQSmMMExmBKp01PWiwvAeOdq2KskzYaMVrCJpIU55Axm2FD0c
wDuWYI6FhiUVlQLf1SBc0VGxBTHhBtp1vmblpiJySixGCBkohapJBDCCjKlK
DFM4XcQFVaxr01jcCKeNcUICPy4rUqLFf1aqX0K5wHquqrVKOuKp4j9IsTCD
HPpNXGaQXDJKYkfoioEAWgIazGxK5wRtS82rUDzTVAqazqSAKLwEqalIDNQG
YUEEG0dYw3yEvMCiiMuqkCpbJwR150uJa+u4UTA4ogqu2WRMQCAGaIKjJTAJ
IKEu4DoOjwABlBkqR1PXXVxKqJVlzSypdKpGyxRlC3pnaVPHaAzIKjYqTa4h
znAJMA5MwNhwkAK5Ya2DWxjsxLqkTqB3iChEiygOUtflKaaDraJtCAqRTh3B
JiFUSDJDLGGRIFcqlTLFxBCBWEmWdUKtYG6pI0AS1AUVtBSCANZyJaZKK9fi
5A7pgCcAjxbylIDfsIDcKanYtfBJ6DE5T7EjqPmva7F8gVSrYfsljD3j+iJ2
FMayhAPKkzotHjOdcvA96r8m51An4FdDLEiVdqBMXoDyVV3Brkphc8BDUsRU
MAunrgGBmvwrneqod9i7K6qWbJbmDJAns4bON/ibWgu5SahcrRUOYDPAA5Pn
mNu0wmvA2NjbyFWdBai5VGRRRgVgXAklYI0yQQx2Bj7RgAKdM9bLSXyHu+Ic
CpqQSyChlDOT6c6UMRMG/0hkdBUogAqLQYGqBdUg/3AKm0NfeAAXJQgCG6uM
AaGRsHR0Umlxp4HoxPJbNKGcJsMOrkDEUr3rpsRFccrd5HQMfpRkN3pPpTlZ
1ZisQlNIYYPbaKAGEAXcgU0Es8uZPqhvkI6WymUrsAnIlwCk2qR4BxQFClgV
GooEpzQJP7KYOQZ+a6gDlZAyTQ508EAgNyFhqW6dI+UlQGqF5kUUpUh46CXW
djoHBaia4mGSmMrLxZUwMdLbiNRnKi2Yzhzkf2nXqdQ1FUyqw3WkGGieN5Q4
i9qG28HI4iZFz9Yi8Q3kPG2zEkJLEOC/OEngT0mtkEAdqATBcY6KXNeACFUD
SlDhDuR8lSPYpJRR44BtNALpHhPLpbCWRoJLUQZ0BuR2VY2gqg0sA0ynqLYd
yrGFveYFqhOSgVyAGmAbyn1MHrXOJB1mKa0ColA1TZxAZ9GoGIBaQRmsYjSu
I+xgWxUYGNddwirasY8iZZmyCVaC/UrIN3NtqZ4W8Cqk1BBE5G1MRlLTKyCW
lcqbeSsKiwonhQ7syyX9mjpXNUAEZjYtrsZz4C23NeArCAIwgqwIGRg2dzIb
kKfNKUsISbSQlhXhPYXziF3KdwqtQy8iy2DgFUqTSxkWY0PiNFLUolhLykop
LYQYfMTZMEPkhOKlRIqhRlf70p9Ar9OmgKhVBYbpYLLQTd5Oa50L5JKA8Fdk
BBlpYQNpSdhLwYQJUrDglwVZDq/MpPY4lDh11EAOYlEm8BGKAcybDG8KcTUs
Cm6ulavgfCVIhj4AJ7iXwIWyi4asCiIGjKLu8WZV1CAwzKKDByFR65z3MnLT
KLRHLqqR3E8tMtWhqJhcBrjnVro8MHvKuygVkY0VzxY5SkRDhwuHl5NYgUAp
oCsMhzlznxYWBVPCxSyXGluRp0gYdKYVccnPFK+kNqkhAl1O7VFAPtkiGUag
IVDBdjQgYZs24HoSi1iwhGYsbaWkgEVRMdAHdZd3FZUdco9AAFtbCwMR/Yg7
pn5g+NCMfP2Lmvdr9jvVY19+bFX/lgb1UUf/I33pIv3/sy+dfLwvfUer99fa
vB9rT6uPtnZ/T/P6rt5v/LHer/Rh1af2fimAVF5tKnKLOkg55moKLVQyRy42
TWpbEoCxRWAlpQHGYWOepsD9iflSUx4hqoaaFAPcDnVe5E1BxUwomwqVUMFS
8hzdDushCaHreSOSH+BD8cD1uhqChGKhrBdgaGYleWKHBEMZIoMUr1KYgK4C
dQ6HycB4oRzgQZNCEqAVtZFck/QG7h3QkWQdmEq6wr26hOqSO0itpu5D6ZvY
gk8ibJOmawQ5AUPbiNbVQB98A+1eNdZStwwcG2UKg0tKZVBzOf9lwBIFx4GC
rLuWpmIHADF5uEwH74Q4GXDFoHoR/6AISr3Owf8mU65uoflgoIjhLG5cJ4+H
SlCOXAm3zfKCctCUQpJZJbolEz1aCKRRiyHSrbJaaJLOxJXUM4huSQnQhYhJ
uABlupKuoBWcLmrYKAJJa7DHUWAojmArSq+EkVbU1Jx5IeoAUl0K4UhQ3UkD
HqPLcrhQLR0GxHUqDTWWLtI01rWJk1y1OfpH+oIZtmQSVro4VncwSwe2Iu8K
qmlXsFYDfdDCCXEyNNYVRQkpQkCoEtkfU3og1Bq5ZEovHak4DlIIAHfOagJP
ZFNNnQL50xKJaWvpDiTwTmShEpGHRi3xlssgUhRRqjxLQjZTUalmPI/riaUk
l26RFGFqRSLbAAA0nMOpgoAgzIhYIrDsMsoSQq+UlkomXWh8g8xIpBWDzKTI
U+CpQjXh0EG5KHY6VWmVZ+j7mmqCwfKWQlnHiUNVxWkhaoLamcCF8Sm8AAMh
vLgH7pt7bsdPmaIsIdEbVp4WcH5WZnkzIb5QHjkUHp4dp7IT1JJ05E+CTurS
Co0pDVi4RwGBYFLUfAQnOEAoVdK6atuU8ID9goPQ8lYuZjrQu7LR0JEqpZg1
Qv00zpFjeERynZsM9lmmFSGR2EIIXAuVgSTHTaZTnALYaCv9IyQHWgEhBL8i
cjUyBz6E82CsOUpJGpIaWov8RvzFjaRjghzQ5FwBKBG5mBR1ido10jSR9iAF
WDalCNzaVU0Kd8wSafdaSn6tRVtTvbEiE0R7S2O4ygpoJ1bTqGjP2xOok8pa
JpwmSLEqBz3TDvGhqfmF2CTlZRxQEdZN0+Tyzw4wEdK3MYITFk5PaBV4h6xo
gAJMgACyrIW3EZeiaKxfS+ObL0SG9EqgBfjNWREPJCrImjZAAeFtmSIQiAud
UGsAp5PdFDQe80Ro1hV0o8xTz8SKBG1ZYVbLq9JFtApZIeStMVCbNtXQbhFk
shdTZxhEeutQ2RR3ZIk0V7A3iFLK5kbctjm6CzypSxRHm7RevEJPBB5raYLl
DlqDFqhqi5XQ8SB7jUkJZQMGWNH1qMACmFSZiZk+RLmRXiIcEPQB0BrACreX
fMP9eQNf7lBNmKiEeiLPWT0kvURxFZUCOSCgABBaADDrQMAECVfF8OgyS4sY
JQD3BOrAP+lDoUXBlVpnpkYqSvPDKXxZtKW0zNBGCOUKMVaaEp3TgmtUKofM
J+ogu3GZZggA6eQClEXMFy7rdEcFzONKkg1a7PwuBIHW4C2RJa1QccohkJiJ
HsjRyYht0rnUYEtLilMMMCyJZGQvzSAPclARNGAhOVwZ2ZXEGfSdmKrQg8Rd
GlMgkc8gGaEEEyXXGrQE5RC8SQ3qOUM2Sn3HHYUoXiGV8EcqHuWqzlwCUBpT
YHtkV2Uy6rZLqgyimcO+KQ6yQwumQ7Z5JHikKb7UIgkKKwatwVHhyjZNidW2
QETDqKW9Hbeqcy20mLJW5Ln8GxRM2MghagteV9LRrNq2yDpUBqFN/NUIklZ6
xRL5Ce7DZ4qI6qTXJ30tK/ux+FrkggPcXILT4QlFkkLwgedOi7jibqBf9u7I
7yTVtZLGdWFENTucIq3+tsIGTZnVWkqyrsoalNJdnEqmGgDUOpR4nWcw8RQI
jdESSEFjS5EZumyk6GuKde11iHV10gLIEsDSs0G/dRCbxkjfmiJd6VIahQA1
HswIGdQE+ZPLfEhhNKE0cduSyedZ6xDDyFBAPHei0NMyc0UJOdI2xXnKQQMo
mCB6JvsvUANLrGf4BBtXubCm2G+2Ubl02pWGHOtQ3E0regK3odkVGSsVgapE
kJoSFKjqJJUdAOBDkykAe1kmqWwJUDGoT0a24RyBJ3aEKplM1TCEjqclFbDf
WMhMSRx04AMiSlgVeNGIKEe3xZ1EXkxZrJFf1BrM2oA6ClFDuaZqoVBR/bK3
jy1wJfKUhVKG0HbQAxKiBTxMLfvPiDVWjlx1sotZq7bAXAZL+YY43sEtYC8w
BDnNGaOTHcislc1RW8mWPCynk+4vTBivUFpiVTOY6RB7uZZtYXSmbJwh6C28
VlQkwVgZ2YdG8PKkVteFSFfrhTkklLQC7YGbCkgHHgEaaYZqmGBLZXBlJ71z
C0HOAQwtGwXSUcMyAE6cyz5aCW3ViqEbajnkrKVCwCiaMtayKdrkIu/hXy5H
/GICOCb+TAFLl8ZFIfXWiHh3scpyWJC07hAxBAe1hWoqvdpYagdkM0VZQing
kzggd+Bn0SWyAaPhv5mwi1Sh1KF9kEJN/ECVdMFo3MZaCS7oJoBGrGSdnP7g
hSSVIwPSo3BgHoMmuVapsBHdUmxJp7zV5KDsYSSaWCCG4Aukj8NBvo1vG6Iy
kcE6TZBDxCgoDowlzindOnTNUABEGE8JzSo4QUJcGeCc0tmB43FG1EB4KBjS
F89ls0y1wnoyKjZFicixVecyiFQOtuuUEgqJp34Rz67RLYFI5CXSzU5hKU0H
CwTsVAWT6RAwIFAMW427BuzvYEdJbnSF9eTfNIE2xR2lHIBBLmB+lGjF8gtp
s5PFXV35icMHKcawZ0e2pAW2JehKQeO4bqiL+IdikJFZwsW7VFCj1cLN6lKO
IHSNrA4XWQNdAGKFseEt2LWTa4WRAkUFgd7I5mmOAsgzWGxGeQQkK+VktwaG
Q4zmonEqKosgdwc5y1FWWUwhQfUVQLechEAVwgVKbuEpyKS463JlwDqiWNrx
LhUdQJ7XsvHVNXLKBxAoC+mzUhu1NNoAmxQcSyUwcvBQdvbxDjYupHGIAAFo
SrEba5cOT9dIGLs2J4EL08L5Sb4WlaEBi4qKQNEEzRuFH4ixQja/5eAO4YEP
IYFxBVBQk6zsAFXUtlZUKmWyMFCyrs3BK+QDTAb5Jr3c0kjF0xizYFU4DrVR
p+JHJBLCBAKAZMWXFmJA+ldII2YtFpKYbBQBWfnNamKyIdCbvMSfQJpjfbFI
aKKMhGVZJYgo/Wbp+xGc0tcWsJBNbqHFcnADnHJy2EXO/kDpZJcAjo7DZDub
FMKYbZaLykvBcgoIcly20/iiCvAT+ZEwFF87YfzS6ENgSPO1oX40Rg4aECbk
fomch5RxBSKQclWiFfCObFN0ZQN9Qu3zf2AYr0B7wTIKqejuTNSSEIUGMNGS
k0QM5iK5OhxtCmUJaxHJLQU5FxkhxCMhn6HX2sARbA3TpLTGuJqQceQXuA7W
N6kQImxnFZiclsIIoVngqi6hsgnFN/ZKDiEBOytTSggEMQF7AM64kClUsDVE
IRQ6U9wGZaZKkhGWyaddBzcUBY9o4IkwVt6mZMC2pt4vIUS5RFHpFvAhTjBR
l7egI/EiWj9BegOSMFhQQbafWsIXD0rHVY5hHPd+pfWrfm/vV1q/6vf2fqX1
q35v71dav+r39n6l9at+b+9XWr/q9/Z+pfWrfm/vV1q/6vf2fqX1q457v7tu
7zPzbrm6Xjj7NvwaI6Vey6d25dNP76T9qb5fXeql/EttN4v++kR9ubi+Wfp/
SNkNJ+rgHyk+UV+4ZfRP2m7fnahXehs+6PFqu7Ttgow4UX9cXSzl30jdDIP8
/qI/9pfRubnQ2oZ/BeHNigd/t93wvOmXUvehV+t/J+La+X9ZIPxbEoN8Vit8
rCza/VZE34ferHX45wLkl0PKMqKb1VYaubvn+dP1ex/VPjjg3S/V/PuLnp2p
/wsvKhazw3wAAA==
</rfc> </rfc>
 End of changes. 83 change blocks. 
1071 lines changed or deleted 579 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/