<?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"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-ietf-cose-hash-sig-09" category="std"> 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>

    <title abbrev="HSS/LMS HashSig with COSE">Use of the HSS/LMS Hash-based 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">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <street>516 Dranesville Road</street>
          <city>Herndon, VA</city>
          <city>Herndon</city>
	  <region>VA</region>
	  <code>20170</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date year="2019" month="December" day="11"/> year="2020" month="April" />
    <area>Security</area>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with the CBOR Object Signing and Encryption (COSE)
syntax. The HSS/LMS algorithm is one form of hash-based digital
signature; it is described in RFC 8554.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with with the CBOR Object Signing and Encryption
(COSE) <xref target="RFC8152"/> target="RFC8152" format="default"/> syntax. The LMS system
provides a one-time digital
signature that is a variant of Merkle Tree Signatures (MTS).

The HSS is
built on top of the LMS system to efficiently scale for a larger numbers number
of signatures. The HSS/LMS algorithm is one form of a hash-based digital
signature, and it is described in <xref target="HASHSIG"/>. target="RFC8554"
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
computational cost; however, the signatures are quite large. The HSS/LMS
private key can be very small when the signer is willing to perform
additional computation at signing time; alternatively, the private key
can consume additional memory and provide a faster signing time. The
HSS/LMS signatures <xref target="HASHSIG"/> target="RFC8554" format="default"/> are currently
defined to use exclusively
SHA-256 <xref target="SHS"/>.</t> target="SHS" format="default"/>.</t>
      <section anchor="motivation" title="Motivation"> numbered="true" toc="default">
        <name>Motivation</name>
        <t>Recent advances in cryptanalysis <xref target="BH2013"/> target="BH2013"
	format="default"/> and progress in the
development of quantum computers <xref target="NAS2019"/> target="NAS2019" format="default"/>
pose a threat to widely
deployed digital signature algorithms. As a result, there is a need
to prepare for a day that cryptosystems cryptosystems, such as RSA and DSA DSA, that
depend on discrete logarithm and factoring cannot be depended upon.</t>

        <t>If large-scale quantum computers are ever built, these computers
	will
have more than a trivial number of quantum bits (qubits) (qubits), and they will
be able to break many of the public-key cryptosystems currently in
use. A post-quantum cryptosystem <xref target="PQC"/> target="PQC" format="default"/> is a
system that is secure against against such large-scale quantum computers.  It is open to
conjecture when  When it will be feasible to build such computers; computers
is open to conjecture; however,
RSA <xref target="RFC8017"/>, target="RFC8017" format="default"/>, DSA <xref target="DSS"/>, ECDSA target="DSS"
format="default"/>, Elliptic Curve Digital Signature Algorithm (ECDSA) <xref target="DSS"/>,
target="DSS" format="default"/>, and EdDSA Edwards-curve Digital Signature Algorithm
(EdDSA) <xref target="RFC8032"/> target="RFC8032" format="default"/> are
all vulnerable if large-scale quantum computers come to pass.</t>
        <t>Since the HSS/LMS signature algorithm does not depend on the
	difficulty
of discrete logarithm or factoring, the HSS/LMS signature algorithm is
considered to be post-quantum secure. The use of HSS/LMS hash-based
signatures to protect software update distribution will allow the
deployment of future software that implements new cryptosystems. By
deploying HSS/LMS today, authentication and integrity protection of
the future software can be provided, even if advances break current
digital signature
digital-signature mechanisms.</t>
      </section>
      <section anchor="terms" title="Terminology">

<t>The numbered="true" toc="default">
        <name>Terminology</name>
        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
“OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in
BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="overview" title="LMS numbered="true" toc="default">
      <name>LMS Digital Signature Algorithm Overview"> Overview</name>
      <t>This specification makes use of the hash-based signature algorithm
specified in <xref target="HASHSIG"/>, target="RFC8554" format="default"/>, which is the Leighton
and Micali adaptation
<xref target="LM"/> target="LM" format="default"/> of the original
Lamport-Diffie-Winternitz-Merkle one-time
signature system <xref target="M1979"/><xref target="M1987"/><xref target="M1989a"/><xref target="M1989b"/>.</t> target="M1979" format="default"/><xref target="M1987"
format="default"/><xref target="M1989a" format="default"/><xref
target="M1989b" format="default"/>.</t>
      <t>The hash-based signature algorithm has three major components:</t>

<figure><artwork><![CDATA[
   o  Hierarchical
<ul spacing="normal">
   <li>Hierarchical Signature System (HSS) -- see Section 2.1;

   o  Leighton-Micali <xref target="hss"/></li>
   <li>Leighton-Micali Signature (LMS) -- see Section 2.2; and

   o  Leighton-Micali <xref target="lms"/></li>
   <li>Leighton-Micali One-time Signature Algorithm (LM-OTS) -- Algorithm-- see
         Section 2.3.
]]></artwork></figure> <xref
   target="lmots"/></li>
</ul>
      <t>As implied by the name, the hash-based signature algorithm depends on
a collision-resistant hash function. The hash-based signature
algorithm specified in <xref target="HASHSIG"/> target="RFC8554" format="default"/> currently
makes use of the SHA-256
one-way hash function <xref target="SHS"/>, target="SHS" format="default"/>, but it also
establishes an IANA registry
to permit the registration of additional one-way hash functions in the
future.</t>
      <section anchor="hss" title="Hierarchical numbered="true" toc="default">
        <name>Hierarchical Signature System (HSS)"> (HSS)</name>
        <t>The hash-based signature algorithm specified in <xref target="HASHSIG"/>
	target="RFC8554" format="default"/> uses a
hierarchy of trees.

The Hierarchical N-time Hierarchical Signature System (HSS)
allows subordinate trees to be generated when needed by the
signer. Otherwise, generation of the entire tree might take
weeks or longer.</t>
        <t>An HSS signature signature, as specified in <xref target="HASHSIG"/> target="RFC8554"
	format="default"/>, carries the number of
signed public keys (Nspk), followed by that number of signed public keys,
followed by the LMS signature signature, as described in <xref target="lms"/>. target="lms"
format="default"/>. The public key
for the top-most 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
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
actual message are LMS signatures signatures, as described in <xref target="lms"/>.</t> target="lms"
format="default"/>.</t>
        <t>The elements of the HSS signature value for a stand-alone tree (a top
tree with no children) can be summarized as:</t>

<figure><artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
   u32str(0) ||
   lms_signature  /* signature of message */
]]></artwork></figure>

<t>where,
]]></artwork>
        <t>where the notation comes from <xref target="HASHSIG"/>.</t> target="RFC8554"
	format="default"/>.</t>
        <t>The elements of the HSS signature value for a tree with Nspk signed
	public keys can be summarized as:</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
   u32str(Nspk) ||
   signed_public_key[0] ||
   signed_public_key[1] ||
      ...
   signed_public_key[Nspk-2] ||
   signed_public_key[Nspk-1] ||
   lms_signature  /* signature of message */
]]></artwork></figure>

<t>where, as
]]></artwork>
        <t>As defined in Section 3.3 of <xref target="HASHSIG"/>, target="RFC8554" sectionFormat="of"
	section="3.3"/>, a signed_public_key is
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
trees minus 1.</t>
      </section>
      <section anchor="lms" title="Leighton-Micali numbered="true" toc="default">
        <name>Leighton-Micali Signature (LMS)"> (LMS)</name>
        <t>Subordinate LMS trees are placed in the the HSS structure structure, as discussed in
<xref target="hss"/>. target="hss" format="default"/>. Each tree in the hash-based signature
algorithm specified in
<xref target="HASHSIG"/> target="RFC8554" format="default"/> uses the Leighton-Micali Signature
(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 <xref target="HASHSIG"/> target="RFC8554" format="default"/> includes support for five values
of this
parameter: h=5; h=10; h=15; h=20; 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
associated with each node in the tree. The <xref target="HASHSIG"/> target="RFC8554"
format="default"/> specification
supports only SHA-256, SHA-256 with m=32. An IANA registry is defined so that
other hash functions could be used in the future.</t>
        <t>The <xref target="HASHSIG"/> target="RFC8554" format="default"/> specification
	supports five tree sizes:</t>

<figure><artwork><![CDATA[
   LMS_SHA256_M32_H5;
   LMS_SHA256_M32_H10;
   LMS_SHA256_M32_H15;
   LMS_SHA256_M32_H20; and
   LMS_SHA256_M32_H25.
]]></artwork></figure>
<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"/> target="RFC8554" format="default"/> specification establishes an
IANA registry to permit the registration of additional hash functions and
additional tree sizes in the future.</t>
        <t>The <xref target="HASHSIG"/> target="RFC8554" format="default"/> specification defines
	the value I as the private key
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
addition, the <xref target="HASHSIG"/> target="RFC8554" format="default"/> specification defines
the value T[i] T[r] as the
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[
        <artwork name="" type="" align="left" alt=""><![CDATA[
   u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
]]></artwork></figure>
]]></artwork>
        <t>As specified in <xref target="HASHSIG"/>, target="RFC8554" format="default"/>, the LMS
	signature consists of four elements:
the elements:</t>
<ul spacing="normal">
  <li>the number of the leaf associated with the LM-OTS signature, an signature,</li>
  <li>an LM-OTS
signature signature, as described in <xref target="lmots"/>, a typecode target="lmots"
  format="default"/>,</li>
  <li>a type code indicating the particular LMS algorithm, and an and</li>
  <li>an array of values that is associated with the path through the tree
  from the leaf associated with the LM-OTS signature to the root. 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
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
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
	as:</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
   u32str(q) ||
   ots_signature ||
   u32str(type) ||
   path[0] || path[1] || ... || path[h-1]
]]></artwork></figure>
]]></artwork>
      </section>
      <section anchor="lmots" title="Leighton-Micali One-time numbered="true" toc="default">
        <name>Leighton-Micali One-Time Signature Algorithm (LM-OTS)"> (LM-OTS) Algorithm</name>
        <t>The hash-based signature algorithm depends on a one-time signature
method. This specification makes use of the Leighton-Micali One-time
Signature Algorithm (LM-OTS) Algorithm <xref target="HASHSIG"/>. target="RFC8554" format="default"/>. An
LM-OTS has five parameters:</t>

<figure><artwork><![CDATA[
   n -  The
<dl newline="false" spacing="normal" indent="6">
   <dt>n:</dt>
   <dd>The number of bytes output by the hash function. For
        SHA-256 [SHS], n=32.

   H -  A n=32.</dd>
   <dt>H:</dt>
   <dd>A preimage-resistant hash function that accepts byte strings
        of any length, length and returns an n-byte string.

   w -  The string.</dd>
   <dt>w:</dt>
   <dd>The width in bits of the Winternitz coefficients. [HASHSIG]
        supports four values for this parameter: w=1; w=2; w=4; and
        w=8.

   p -  The w=1, w=2, w=4, and
        w=8.</dd>
   <dt>p:</dt>
   <dd>The number of n-byte string elements that make up the LM-OTS
        signature.

   ls - The
        signature.</dd>
   <dt>ls:</dt>

   <dd>The number of left-shift bits used in the checksum function,
        which is defined in Section 4.5 of [HASHSIG].
]]></artwork></figure> <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 Appendix B of <xref target="HASHSIG"/>.</t> target="RFC8554" sectionFormat="of"
section="B"/>.</t>
        <t>The <xref target="HASHSIG"/> target="RFC8554" format="default"/> 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>
<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="HASHSIG"/> target="RFC8554" format="default"/> specification
	establishes an IANA registry to permit
the registration of additional hash functions and additional parameter
sets in the future.</t>
        <t>Signing involves the generation of C, which is an n-byte random
	value.</t>
        <t>The LM-OTS signature value can be summarized as the identifier of
	the LM-OTS variant, the random value, and a sequence of hash values
	(y[0] through y[p-1]) y[p-1]), as described in Section 4.5 of <xref target="HASHSIG"/>:</t>

<figure><artwork><![CDATA[ target="RFC8554"
	sectionFormat="of" section="4.5"/>:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   u32str(otstype) || C || y[0] || ... || y[p-1]
]]></artwork></figure>
]]></artwork>
      </section>
    </section>
    <section anchor="algids" title="Hash-based numbered="true" toc="default">
      <name>Hash-Based Signature Algorithm Identifiers"> Identifiers</name>
      <t>The CBOR Object Signing and Encryption (COSE) <xref target="RFC8152"/> target="RFC8152"
      format="default"/> supports two
signature algorithm schemes. This specification makes use of the
signature with appendix scheme for hash-based signatures.</t>
      <t>The signature value is a large byte string string, as described in <xref target="overview"/>.
      target="overview" format="default"/>.
The byte string is designed for easy parsing. The HSS, LMS, and LMOTS LM-OTS
components of the signature value format include counters and type
codes that indirectly provide all of the information that is needed to
parse the byte string during signature validation.</t>
      <t>When using a COSE key for this algorithm, the following checks are
      made:</t>

<figure><artwork><![CDATA[
   o  The
<ul spacing="normal">
   <li>The 'kty' field MUST <bcp14>MUST</bcp14> be 'HSS-LMS'.

   o  If 'HSS-LMS'.</li>
   <li>If the 'alg' field is present, it MUST <bcp14>MUST</bcp14> be 'HSS-LMS'.

   o  If 'HSS-LMS'.</li>
   <li>If the 'key_ops' field is present, it MUST <bcp14>MUST</bcp14> include
   'sign' when creating a hash-based signature.

   o  If signature.</li>
   <li>If the 'key_ops' field is present, it MUST <bcp14>MUST</bcp14> include 'verify'
        when verifying a hash-based signature.

   o  If signature.</li>
   <li>If the 'kid' field is present, it MAY <bcp14>MAY</bcp14> 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
        for the tree.
]]></artwork></figure> tree.</li>
</ul>
    </section>
    <section anchor="seccons" title="Security Considerations"> numbered="true" toc="default">

      <name>Security Considerations</name>
      <t>The Security security considerations from <xref target="RFC8152"/> target="RFC8152"
      format="default"/> and <xref target="HASHSIG"/> target="RFC8554" format="default"/> are
relevant to implementations of this specification.</t>
      <t>There are a number of security considerations that need to be taken
into account by implementers of this specification.</t>
      <t>Implementations MUST <bcp14>MUST</bcp14> protect the private
      keys. Compromise of the
private keys may result in the ability to forge signatures. Along
with the private key, the implementation MUST <bcp14>MUST</bcp14> keep track of which
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
a result, when a private key and the tracking data are stored on non-
volatile nonvolatile
media or stored in a virtual machine environment, failed
writes, virtual machine snapshotting or cloning, and other
operational concerns must be considered to ensure confidentiality and
integrity.</t>
      <t>When generating an LMS key pair, an implementation MUST
      <bcp14>MUST</bcp14> generate each key pair independently of all other
      key pairs in the HSS tree.</t>
      <t>An implementation MUST <bcp14>MUST</bcp14> ensure that a an LM-OTS private
      key is used to generate a signature only one time, time and ensure that it
      cannot be used for any other purpose.</t>
      <t>The generation of private keys relies on random numbers. The use of
inadequate pseudo-random pseudorandom 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,
searching the resulting small set of possibilities, possibilities rather than brute
force brute-force searching the whole key space. The generation of quality
random numbers is difficult, and <xref target="RFC4086"/> target="RFC4086" format="default"/>
offers important guidance
in this area.</t>
      <t>The generation of hash-based signatures also depends on random
numbers. While the consequences of an inadequate pseudo-random
number generator (PRNG) PRNG to generate these values is much less severe
than in the generation of private keys, the guidance in <xref target="RFC4086"/> target="RFC4086"
format="default"/> remains important.</t>
    </section>
    <section anchor="opcons" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <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
infrastructure <xref target="RFC5280"/>, target="RFC5280" format="default"/>, this public key is a
trust anchor, and the
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
been used to produce a signature, then the establishment of a new
trust anchor is required.</t>

      <t>To ensure that none of the tree nodes are used to generate more than one
signature, the signer maintains state across different invocations of
the signing algorithm.  Section 12.2 of <xref target="HASHSIG"/> target="RFC8554"
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
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>
      <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
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
the private key and state. Such a restoration operation provides
disastrous opportunities for tree node reuse.</t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to add has added entries for the HSS/LMS hash-based signatures signature
  algorithm in the
“COSE Algorithms” "COSE Algorithms" registry and added HSS/LMS
  hash-based signature public keys in the “COSE "COSE Key Types"
  registry and the "COSE Key Types” registry.</t> Type Parameters" registry.
      </t>
      <section anchor="cose-algorithms-registry-entry" title="COSE numbered="true" toc="default">
        <name>COSE Algorithms Registry Entry"> Entry</name>
        <t>The new entry in the “COSE Algorithms” "COSE Algorithms" registry <xref target="IANA"/> has the
following columns:</t>

<figure><artwork><![CDATA[
   Name:  HSS-LMS

   Value:  TBD1 (Value between -256 and 255 to be assigned by IANA,
                 with a preferrence for -46)

   Description:  HSS/LMS target="IANA"
	format="default"/> appears as follows:</t>
        <dl newline="false" spacing="compact">
	  <dt>Name:</dt>
	  <dd>HSS-LMS</dd>
	  <dt>Value:</dt>
	  <dd>-46</dd>
	  <dt>Description:</dt>
	  <dd>HSS/LMS hash-based digital signature

   Reference:  This document (Number to be assigned by RFC Editor)

   Recommended:  Yes
]]></artwork></figure> signature</dd>
	  <dt>Reference:</dt>
	  <dd>RFC 8778</dd>
	  <dt>Recommended:</dt>
	  <dd>Yes</dd>
	</dl>
      </section>
      <section anchor="cose-key-types-registry-entry" title="COSE numbered="true" toc="default">
        <name>COSE Key Types Registry Entry"> Entry</name>
        <t>The new entry in the “COSE "COSE Key Types” Types" registry <xref target="IANA"/> has the
following columns:</t>

<figure><artwork><![CDATA[
   Name:  HSS-LMS

   Value:  TBD2 (Value to be assigned by IANA)

   Description:  Public target="IANA"
	format="default"/> appears as follows:</t>
<dl newline="false" spacing="compact">
   <dt>Name:</dt>
   <dd>HSS-LMS</dd>
   <dt>Value:</dt>
   <dd>5</dd>
   <dt>Description:</dt>
   <dd>Public key for HSS/LMS hash-based digital signature

   Reference:  This document (Number to be assigned by RFC Editor)
]]></artwork></figure> signature</dd>
   <dt>Reference:</dt>
   <dd>RFC 8778</dd>
</dl>
      </section>
      <section anchor="cose-key-type-parameters-registry-entry" title="COSE
	       numbered="true" toc="default">
        <name>COSE Key Type Parameters Registry Entry"> Entry</name>
        <t>The new entry in the “COSE "COSE Key Type Parameters” Parameters" registry <xref target="IANA"/> has
the following columns:</t>

<figure><artwork><![CDATA[
   Key Type:  TBD2  (Value to be assigned above by IANA)

   Name:  pub

   Label:  TBD3 (Value to be assigned by IANA)

   CBOR Type:  bstr

   Description:  Public
	target="IANA" format="default"/> appears as follows:</t>
<dl newline="false" spacing="compact">
   <dt>Key Type:</dt>
   <dd>5</dd>
   <dt>Name:</dt>
   <dd>pub</dd>
   <dt>Label:</dt>
   <dd>-1</dd>
   <dt>CBOR Type:</dt>
   <dd>bstr</dd>
   <dt>Description:</dt>
   <dd>Public key for HSS/LMS hash-based digital signature

   Reference:  This document (Number to be assigned by RFC Editor)
]]></artwork></figure> signature</dd>
   <dt>Reference:</dt>
   <dd>RFC 8778</dd>
</dl>
      </section>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<displayreference target="RFC8554" to="HASHSIG"/>

    <references>

      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8554.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <reference anchor="HASHSIG" target="https://rfc-editor.org/rfc/rfc8554.txt"> anchor="SHS">
          <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>
            <title>Secure Hash Standard</title>
            <seriesInfo name="FIPS Publication" value="180-4"/>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2019" month="April"/> month="August" year="2015"/>
          </front>
	  <seriesInfo name="RFC" value="8554"/> name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>
        <reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> anchor="DSS" target="https://doi.org/10.6028/NIST.FIPS.186-4">
          <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 Community, and requests discussion
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization>National Institute of Standards and suggestions for improvements.</t></abstract> Technology (NIST)</organization>
            </author>
            <date month="July" year="2013"/>
          </front>
            <seriesInfo name='BCP' value='14'/> name="FIPS Publication" value="186-4"/>
	    <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 /></author>
<date year='2017' month='July' />
<abstract><t>Concise Binary Object Representation (CBOR) is a data format designed 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 defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t></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'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor="SHS" >
  <front>
    <title>Secure Hash Standard</title>
    <author >
      <organization>National Institute of Standards and Technology (NIST)</organization>
    </author>
    <date year="2008"/>
  </front>
  <seriesInfo name="FIPS Publication" value="180-3"/>
</reference>

    </references>

    <references title='Informative References'>

<reference anchor="DSS" >
  <front>
    <title>Digital Signature Standard (DSS)</title>
    <author >
      <organization>National Institute of Standards and Technology (NIST)</organization>
    </author>
    <date year="2013"/>
  </front>
  <seriesInfo name="FIPS Publication" value="186-6"/>
</reference>
<reference anchor="IANA" target="https://www.iana.org/assignments/cose/cose.xhtml">
  <front>
    <title>IANA Registry for CBOR Object Signing and Encryption (COSE)</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>

<reference  anchor="RFC4086" target='https://www.rfc-editor.org/info/rfc4086'>
<front>
<title>Randomness Requirements for Security</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<author initials='J.' surname='Schiller' fullname='J. Schiller'><organization /></author>
<author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></author>
<date year='2005' month='June' />
<abstract><t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to 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 resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number 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 specifies an Internet Best Current Practices for the Internet Community, and requests discussion 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'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<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 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described 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 extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [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'>
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author initials='K.' surname='Moriarty' fullname='K. Moriarty' role='editor'><organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></author>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'><organization /></author>
<author initials='A.' surname='Rusch' fullname='A. Rusch'><organization /></author>
<date year='2016' month='November' />
<abstract><t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing 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'>
<front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<author initials='I.' surname='Liusvaara' fullname='I. Liusvaara'><organization /></author>
<date year='2017' month='January' />
<abstract><t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves.  An example implementation and test vectors are provided.</t></abstract>
</front>
<seriesInfo name='RFC' value='8032'/>
<seriesInfo name='DOI' value='10.17487/RFC8032'/> name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>

        <reference  anchor="RFC8610" target='https://www.rfc-editor.org/info/rfc8610'> anchor="IANA" target="https://www.iana.org/assignments/cose">
          <front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
<author initials='H.' surname='Birkholz' fullname='H. Birkholz'><organization /></author>
<author initials='C.' surname='Vigano' fullname='C. Vigano'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2019' month='June' />
<abstract><t>This document proposes a notational convention to express Concise Binary
            <title>CBOR Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages Signing and data formats that use CBOR or JSON.</t></abstract> Encryption (COSE)</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
<seriesInfo name='RFC' value='8610'/>
<seriesInfo name='DOI' value='10.17487/RFC8610'/>
        </reference>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>

        <reference anchor="BH2013"
		   target="https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf">
          <front>
            <title>The Factoring Dead: Preparing for the Cryptopocalypse</title>
            <author initials="T." surname="Ptacek" fullname="Thomas Ptacek">
              <organization>Matasano</organization>
            </author>
            <author initials="T." surname="Ritter" fullname="Tom Ritter">
              <organization>iSEC Partners</organization>
            </author>
            <author initials="J." surname="Samuel" fullname="Javed Samuel">
              <organization>iSEC Partners</organization>
            </author>
            <author initials="A." surname="Stamos" fullname="Alex Stamos">
              <organization>Artemis Internet</organization>
            </author>
            <date year="2013" month="August"/>
          </front>
        </reference>

        <reference anchor="LM" > 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>
              <organization/>
            </author>
            <author initials="S." surname="Micali" fullname="Silvio Micali">
      <organization></organization>
              <organization/>
            </author>
            <date year="1995" month="July" day="11"/> month="July"/>
          </front>
           <seriesInfo name="U.S. Patent" value="5,432,852"/>
        </reference>

        <reference anchor="M1979" > anchor="M1979">
          <front>
            <title>Secrecy, Authentication, and Public Key Systems</title>
            <author initials="R." surname="Merkle" fullname="Ralph Merkle">
      <organization></organization>
              <organization/>
            </author>
            <date month="June" year="1979"/>
          </front>
          <seriesInfo name="Stanford University Information Systems Laboratory Technical name="Technical Report" value="1979-1"/> value="No. 1979-1"/>
	  <refcontent>Information Systems Laboratory, Stanford University</refcontent>
        </reference>

        <reference anchor="M1987" > anchor="M1987">
          <front>
            <title>A Digital Signature Based on a Conventional Encryption Function</title>
            <author initials="R." surname="Merkle" fullname="Ralph Merkle">
      <organization></organization>
              <organization/>
            </author>
            <date year="1988"/>
          </front>
  <seriesInfo name="Lecture
	  <refcontent>Advances in Cryptology -- CRYPTO '87 Proceedings</refcontent>
          <refcontent>Lecture Notes in Computer Science" value="crypto87"/> Science, Volume 291</refcontent>
	  <seriesInfo name="DOI" value="10.1007/3-540-48184-2_32"/>
        </reference>

        <reference anchor="M1989a" > anchor="M1989a">
          <front>
            <title>A Certified Digital Signature</title>
            <author initials="R." surname="Merkle" fullname="Ralph Merkle">
      <organization></organization>
              <organization/>
            </author>
            <date year="1990"/>
          </front>
  <seriesInfo name="Lecture
	  <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refcontent>
          <refcontent>Lecture Notes in Computer Science" value="crypto89"/> Science, Volume 435</refcontent>
	  <seriesInfo name="DOI" value="10.1007/0-387-34805-0_21"/>
        </reference>

        <reference anchor="M1989b" > anchor="M1989b">
          <front>
            <title>One Way Hash Functions and DES</title>
            <author initials="R." surname="Merkle" fullname="Ralph Merkle">
      <organization></organization>
              <organization/>
            </author>
            <date year="1990"/>
          </front>
  <seriesInfo name="Lecture
	  <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refcontent>
          <refcontent>Lecture Notes in Computer Science" value="crypto89"/> Science, Volume 435</refcontent>
	  <seriesInfo name="DOI" value="10.1007/0-387-34805-0_40"/>
        </reference>

        <reference anchor="NAS2019" target="http://dx.doi.org/10.17226/25196">
          <front>
            <title>Quantum Computing: Progress and Prospects</title>
    <author >
            <author>
              <organization>National Academies of Sciences, Engineering, and Medicine</organization>
            </author>
            <date year="2019"/>
          </front>
	  <refcontent>The National Academies Press</refcontent>
	  <seriesInfo name="DOI" value="10.17226/25196"/>
        </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. Bernstein">
              <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>

    <section anchor="examples" title="Examples"> numbered="true" toc="default">
      <name>Examples</name>
      <t>This appendix provides a non-normative example of a COSE full message
      signature and an example of a COSE_Sign1 message. This section is
      formatted according to the extended CBOR diagnostic format defined by
      <xref target="RFC8610"/>.</t> target="RFC8610" format="default"/>.</t>
      <t>The programs that were used to generate the examples can be found at
https://github.com/cose-wg/Examples.</t>
<eref target="https://github.com/cose-wg/Examples" brackets="angle"/>.</t>
      <section anchor="example-cose-full-message-signature" title="Example numbered="true"
	       toc="default">
        <name>Example COSE Full Message Signature"> Signature</name>
        <t>This section provides an example of a COSE full message
	signature.</t>

<t>Size
	<t>The 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[
        <artwork name="" type="" align="left" alt=""><![CDATA[
98(
  [
    / protected / h'a10300' / {
        \ content type \ 3:0
      } / ,
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected / h'a101382d' / {
            \ alg \ 1:-46 \ HSS-LMS \
          } / ,
        / unprotected / {
          / kid / 4:'ItsBig'
        },
        / signature / h'00000000000000010000000391291de76ce6e24d1e2a
9b60266519bc8ce889f814deb0fc00edd3129de3ab9b6bfa3bf47d007d844af7db74
9ea97215e82f456cbdd473812c6a042ae39539898752c89b60a276ec8a9feab900e2
5bdfe0ab8e773aa1c36ae214d67c65bb68630450a5db2c7c6403b77f6a9bf4d30a02
19db5cced884d7514f3cbd19220020bf3045b0e5c6955b32864f16f97da02f0cbfea
70458b07032e30b0342d75b8f3dc6871442e6384b10f559f5dc594a214924c48ccc3
37078665653fc740340428138b0fb5154f2f2cb291ad05ace7acae60031b2d09b2f4
17712d1c01e34b165af2e070f5a521a85a5fb3dd2a6288947bcbd5e2265d3670bd61
92eb2bf643964e2783d84aec343f8e3571e4fcf09cbeea94e80470aa7252d1c733a5
535907e66c7b9f0b88b159dc2a7370ee47f13e7e134d3d05e5f53fac640b784a9b0f
183fe14217325626f487cc8d8cb9eaf0abb174ee0b7076cf39c45037cefdf3f1e61b
5174581214c09870b72c39737ec4c46a96199b66cad2990bcbe5bb1abfde99107c7f
7289395bf2a433598ede0b1969f23db949afb5b4d33831dae6c641a6355f8f9bf16c
dffc4bf86891b93a557c2152ac8a1de51c995344cc10cc4bc9ecfbb4e418bed0f334
af165339e6725dc4fc1e995521e1be8a566d59b57cd130903b42d07087d63646ef8f
c1e9e9071bb67a123fdec3f37638cdaf0f4bf3084074069171c17885b9431ad908d3
6a6f8a826256d2aa34f8aa0731a357c060db8e80fefd61b1c323890e640633b98d17
5d4d6ebff800a71cfc864ec02837de9d0e079f0f400acafd56805cb273e631ba395d
23e86acf6eae63181a5afe1f0a361cbbd5fefeb7db0c95591ec3128e80dfbea9ca0f
89fc035d761c05d41e7a010892c42e8e2af62aa604f4e214c0bb08075481f9cc307a
555adf333b9424f209b89f161032e413b047ae5ab0aa15643bb4c643446d2c9829eb
256e7375ce9639047a24a44f4da446b7359556f3ab3484c56511c68a140dc0531f65
3105800d9f20990d4ebdc5ceea918d7ae95c0d7ec69a00d6a936b25fc19b9dfc5561
400f046191136c367038d6a9d0e0ae30dcdc4733712cbd5a2aee35315eff5c1a7e08
5b68c5cf0c64c495df2ca6f030db04480a2e11d4a0a0dbf29d9463d5b9e41e346e49
c894d5e43993c834c4746309c886d6131f2f92155ca1160bac9660802a947b5aba94
b35357d13fdf02d2aeabef568912f68ae5d3a60214f6d00c4dd9f0af09eb0bf961cd
9f27251d46899c28d87080ba2ead3e8193f51a789706ec32aacee9f4b14eeca91a25
2fe894b30dc3938abbbe7d217948cae79ce3adb4d7d7df6756f3099f2543ed3b522b
acab257503c9e07fcd32cc32fa9aa17977ec05bc5fe0f5954d51f160f52d33f93166
af68aa90261b3f5ad273adacf2d0cb5b0c5402bfa62da67a52dcddfa463e72d2c005
f1ac0ea3cb62364ee3419333612e07bf685006137a592e2fcd58398265c4ff9e11e7
0c2b79152e4604b4f94676e955bcff4dfc429a8a88728b95bfc2826e25ba6eab9cfb
066c9911693efff242f7b51c3cb88546143b8ab2142dd3c9bda55d16fe3084a86b74
3f294dd9d0aa84f3ce3b083a5879a4762a756e9b41f4bdf8b71418073b0a0d4a9c13
1882455ece23e50324c5feea217920b0f3109dcbdc81762e41b7ca271efac8e39cc2
6ebe085abdbf6b314a38929799fb7feebee2e20b97056ed17ef3881e6e89330314dd
7e9c629c46dfdb925c7c5f5d243f159d964691745cd46579fd0696479e1c49cbd2af
879a2bce8576619cca7b6e516e6c94c1087441a81f11b9a83535b24ddc725a81a9d1
ff62da2804c8d84c6e382065574282ea1f23eaf648cfa9767afb098fd81654d76133
f5f39bcc762c9bc31f7f4665cc0efa929b5c05dedd76143c63dc7018ab130c108ea9
01be32b9d911b66da13a1528c32a9694c899a772f8e1fe00c17eceb343e737d72cba
06cf5ddac9a4d3df7ef391cf6595a6d8c14b0d80f93023b1b3d4371239da98b67a1b
6a379422616282a16e8d1f97a130baf21e572bcca91abb760eac6957f9b1b05e49e2
d181874ac6dd160d1c717b73bd28ef55f08d47466d5aef754814c7e206fa9e2ec533
85d14d52f7769d95ea50524ffb20dc7275b04d71d1967e3bbc6ed481f1fc5a15e78a
1fd967d96045625645dbd173cccdd97661e995ce47d6b3ead96ee6d006a5ce6f4c97
77fe2e3f91bebe877cac8c6486dfce0315dc71bbb93879759b8981c5ff2e11deb809
abf4280ee93d1711e73645b410acb518538ce3d4bda1e355c988f068165668e99d6a
8de356b4b13298036ad05d526c4a5e2591612a477b7e86550adde128cd71ee651d44
99699000a02979e42bbccf32c83b1eb0ff99aa4d352e20e0b3382422df2c2ed4ce90
c94cf1a359e92ef971dc6db06047a333c2ebe827eb6d5f2811fdbe0bf0f12bf2094e
0dcd8e418f3f691a60ceb0cefb6f45f47883d6b9f320950e91266740c6dbfad6b3cf
e56de0aa6658b0dc893bb6e49e6294537a7878e86cfc8e6c150675db1a89d188ea6e
fe7d88ff57b39b8610e392811ee097ca61c4841e0fbd346ed3ff6a5e412acb0d9f13
022df2e7fdaa8e0face7366c8ffe6f446995b564fc3d59c70fecdb60a25e28650417
157f43f3e72c3afc601509641cfd099a78130e1f7ba8333502ad4f036f46411a43d0
35e2ca0ed0c346d9aac5df05196c95c38e6e52763ed896b6d02464a910dda6cca340
24e3b9c3723d26e2886ad724dd56ea285e8e4b60beec924d55dd700c38877b74552f
ea1f8741579b02061416131db390f628522885236b51f7aef23167d3a5fe5eadcd88
b0e99b2b6bc56b0dea4fb22146294766c28e5e7c834dbdcb6bfdd7bd8455252522ff
2e974f6fd3fda176749b7cdced5b9aba092b2982c89cb7d2b36348928c8f01170618
ecff14d9e0eed9d88d97e38bcf7a837f674be5243fc624c8afd3d105f462bfa939b8
143a3a98f78fbb8c915e00bdbbf707b12c45784f4d1cb1426b583a0d5fbec1f5ea6d
0067c090168cb788e532aca770c7be366ec07e7808f1892b00000006ed1ce8c6e437
918d43fba7bd9385694c41182703f6b7f704deedd9384ba6f8bc362c948646b3c984
8803e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e
7c81a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc5
6211d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d26
246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0ba
e71696cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c
29d4f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c10
7362f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9
ce949be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931b
a7b3bd0d824a4570'
      ]
    ]
  ]
)
]]></artwork></figure>
]]></artwork>
      </section>
      <section anchor="example-cosesign1-message" title="Example numbered="true" toc="default">
        <name>Example COSE_Sign1 Message"> Message</name>
        <t>This section provides an example of a COSE_Sign1 message.</t>

<t>Size
        <t>The 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[
        <artwork name="" type="" align="left" alt=""><![CDATA[
18(
  [
    / protected / h'a101382d' / {
        \ alg \ 1:-46 \ HSS-LMS \
      } / ,
    / unprotected / {
      / kid / 4:'ItsBig'
    },
    / payload / 'This is the content.',
    / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60
266519bc8ce889f814deb0fc00edd3129de3ab9b9aa5b5ac783bdf0fe689f57fb204
f1992dbc1ce2484f316c74bce3f2094cfa8e96a4a9548cead0f78ee5d549510d1910
f647320448ae27ecce77249802a0c39c645bf8db08573af52c93d91fd0e217f245c7
52c176b81514eb6e3067e0fbb329225eaa88c7d21635e32ae84213f89018cb06f1b8
4e61eac348b690d7c6265c19f9d868952d99826aecd417b5279dd674cd951c306016
cfee4fee3bfcf5ee5a5ad08b5b4f53bc93995f26cfe7c0c1c5ba2574c1f2d8470993
e8bd47ef9b9cf309ef895226e92be60683459009611defbb9a43217956a0ab2959bb
da0feca39de37e7c4a6cd8a5314d6b02b377406d5a5e589e91feaa9f2e4ec1682ba1
f633c7784499323e40da651f71d3c19e38c634d898b0c508324c0bfcf7c5f0a8c014
b4af200a739f96cddba94daf86ce80c76158d4f5cf3cd2ba9f1393df47e556887f91
68540485242a05ec6bcc76659ec3d0d2fedae3fd1608a701c226f5fd83c9b1ed3152
ddac7426c30e3390bec8f1da6174abe8d3568c9b76b149eb077d61ac15b8fb11b8ce
5f9d14e448e216f375e1f96a52d39619459b131026143e8809bad408f5ef66cd3da2
27431e68670c0b4b2c3801e1e9025b1ebed218e0956967158ccc274c704adcd8cc23
c149a89eda25478742dadc15f233844535e4021000b5d557313d4f271875680e6d5e
7f6681fdd19f8b9a748cabb2377aac1387fdb80e618eb7d69a368729ca9a092af91e
be1c584c35fe62734d1d53d10b35dd02093a201c889ad37a558b610f1ab00179a11f
881600e944cedc47a7ae6d828009d7c61ffea9dd5aa5406408e2e85dc056e47b5758
9eaba18e792f4631af62d4588a1818167274273c69e7a0735be5dada7e224e3b178b
3b093212eb74e762f564a26d577aa22ebd8c7b4a999419908e2f2d9c8689dc923905
c198b9ee335d1e0de6d689655f446dffea997b6e58f5f648415233ede3b9d8a2db29
e8c3dde5d8dbd55e6348cd9f421783db090e087de46425d62d513597b00d7de32fad
87752a79cee8b2a38b1e0f2562836721cbbfba20f131130c009a436b93a0bb44fcbb
86228b1bf1a35f4fc626817924eaebd5b78d64a7970d18dade90cf0ad759b1c45d95
3c08cd1189685077c5a56069da0944669d797496f8f886fea6f792598db2ac66b657
af838ed3c3a914dffbb164170a1f63250b125eda53ecaeaf6ee0d2b8a3c804104d7e
d575b66469bc59f37eec6c6f6fb19e0f7ea02d7c85306230063adb58950589f6ffaf
f1407233828ae0dfbe5889e5de00bb640a4bc24c3f704488fa669676a9ebbbed399b
8a9ac0ee4cc944f864b21f642e04f610319ac9271f8bd820e77e41dac6553d234d94
80e26142c0fa37416651d6450e1f2082bd0213d6783e1ae3cc5c5af677c3316e173b
a4716d6bc8a9d89383f8b025a0859b99a43daeaf8ddaed46d223b9b503651a67560b
feb2f35ba544722620ec4086dcc77e6e87bb53f1f18c38368662be460ede31325cae
aebf018a6fa9d32e3c3a6898e15fe114dcce51241c61afabc36de3608b4d342712a8
33615c6131e89e1d46b713d9638a08b5a768d53af0298b9c874ded7084358223840c
2e78cd6fbfca695279a4c1883bb7de81b04a069de8277f7f5109c16938347a643713
c9ac36fffc8bf141e899f48bc25c7b636d43bebcfa7742d4e1462263e56732ad2021
eef8ce84023c4959cfd250343d62074724907de9d49ea2f6c968fd9e9bf28feafcdc
81702108805dec60f2781272d2425a6ee29c66122d2c557867c1a5aed82131e06fc3
84ecf49017e1c9d6cf63b9f2285ccf890cbb9bbf796e0fd02101948b7ef663849367
7b33fd787d9d3fc2c7cc7babc21af8c748afb80cf86b45dc89f0b9c7959621e85b98
b542dc263db9255273bb9054a7f194748f28373ba123d73fc71fef43e7e2ac9a8000
8e85cf2f04aa433075dfc54c4de24a341ebf7cf1e6b383dbba85898fdc368017fd67
c153e7a991a3a3cee6dae4fbe2fe6f25a8df314140a8176c8e6fd0c6f042ca66eb6a
bba9a2502bb6dfa52960ae86a942a673e4e45439594fefcd2974e20554d1dc70b8e0
34fd1787801343d5f6edc95ce0348c25727c771526e3fd4effb5f16e25a1ea3dcd82
82e778e91ae9b339a5013c77fd6ea2432704e293f5e82a24121c73900bea4b4ef14a
2adc1ab3c68224bae1de9c61a48b84e84c1b0e83701be3d988012a24fa40268c8d6e
f1fd2818ae8e4b6f52f89beab6bfdd1ff1b7ecd573edff3703b800b5b2a206f451f1
bf2713b4ae9085bd7fe34ad4306a290e4cdb7817ee9ab7ccfb816d002b619f77d46d
7dd0f8eefe10f5c0f9723ffdb14ca75a185543770f41508b9983d5eed78225bc6e21
f876bfdd08fe8bc63e0cb253c7dfc67c330897c515244f3f631682f2141eba48ca86
dfff9206f78edcb9dec4b2371aeddbe141ef96a10957e29a94747c4438fb30b14d37
e7428eb7fbe4f9d870e72f35f55847f230374bdf56dcae6c129b4468ebaedc340ff4
cc160c6b410e2d8989488ac8ef9a9febbf65ad4fdfba532a8122ef82dc1a4ffc361c
bf9f752b36aa9821683d5f3f5842f90134eb423d5cbc76858b4c0a7ba798ec94a089
fdb24b5b25f42d7b6bb8192f07b98eb2de1fe7bc8b6c740fa5cde6fb4890d2f17916
64a96c25a0a71a541025b5ec825eed91f393505473e21d0620177993982e6c1b6bf9
1b777b5ab5739b84946c518c7e6aa0e689e9ad1d34e6ef6ca0e709c4aefecd6f2594
b017940742aceb72c5a52d7d47a3a74f9d09eb84cf82b349de32278a771cebc31ebc
580c09b11799b1f0e6d11d75b17e389d259c531f957a1e699250711df2e36f64f21c
92eff698a392d92df0b2f91991408a076b83149e025a9ffba1ff1caed916a2fc1ac5
d3081c30b5c64b7d677c314b6e76ac20ed8bb4a4c0eb465ae5c0c265969264b27e6d
54c266f79e58e2fa6a381069090bec00189562abcf831adc86a05a2fc7ffaa70dbd3
fa60e09d447cd76b2ff2b851c38e72650ade093ba8bd000000067b95de445abf8916
1dff4b91a4a9e3bf156a39a4660f98f06bf3f017686d9dfc362c948646b3c9848803
e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e7c81
a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc56211
d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465
95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0bae716
96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4
f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362
f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94
9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3
bd0d824a4570'
  ]
)
]]></artwork></figure>
]]></artwork>
      </section>
    </section>
    <section anchor="acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Many thanks to
Roman Danyliw,
Elwyn Davies,
Scott Fluhrer,
Ben Kaduk,
Laurence Lundblade,
John Mattsson,
Jim Schaad, and
Tony Putman
<contact fullname="Roman Danyliw"/>,
<contact fullname="Elwyn Davies"/>,
<contact fullname="Scott Fluhrer"/>,
<contact fullname="Ben Kaduk"/>,
<contact fullname="Laurence Lundblade"/>,
<contact fullname="John Mattsson"/>,
<contact fullname="Jim Schaad"/>, and
<contact fullname="Tony Putman"/>
for their valuable review and insights. In addition, an extra
special thank you to Jim Schaad <contact fullname="Jim Schaad"/> for generating the
examples in Appendix A.</t>
    </section>

  </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>