<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.0.2) -->
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-reddy-cose-jose-pqc-hybrid-hpke-02" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="PQ/T Hybrid KEM: HPKE with JOSE/COSE">PQ/T Hybrid KEM: HPKE with JOSE/COSE</title>
    <seriesInfo name="Internet-Draft" value="draft-reddy-cose-jose-pqc-hybrid-hpke-02"/>
    <author fullname="Tirumaleswar Reddy">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig">
      <organization/>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>
    <date year="2024" month="October" day="03"/>
    <area>Security</area>
    <workgroup>COSE</workgroup>
    <keyword>PQC</keyword>
    <keyword>COSE</keyword>
    <keyword>JOSE</keyword>
    <keyword>Hybrid</keyword>
    <keyword>HPKE</keyword>
    <abstract>
      <?line 63?>

<t>This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        cose Working Group mailing list (<eref target="mailto:cose@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cose/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cose/"/>.
      </t>
    </note>
  </front>
  <middle>
    <?line 67?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The migration to Post-Quantum Cryptography (PQC) is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required data lifetimes. The traditional algorithms, such as RSA and elliptic curve, will fall to quantum cryptalanysis, while the post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs.</t>
      <t>During the transition from traditional to post-quantum algorithms, there is a desire or a requirement for protocols that use both algorithm types. Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography.</t>
      <t>HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. The specifications for the use of HPKE with JOSE and COSE are described in <xref target="I-D.rha-jose-hpke-encrypt"/> and <xref target="I-D.ietf-cose-hpke"/>, respectively. HPKE can be extended to support PQ/T Hybrid KEM as defined in <xref target="I-D.connolly-cfrg-xwing-kem"/>. This specification defines PQ/T Hybrid KEM in HPKE for use with JOSE and COSE.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>This document makes use of the terms defined in <xref target="I-D.ietf-pquip-pqt-hybrid-terminology"/>. For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes:</t>
      <t>"Traditional Algorithm":  An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. In the context of JOSE, examples of traditional key exchange algorithms include Elliptic Curve Diffie-Hellman Ephemeral Static <xref target="RFC6090"/> <xref target="RFC8037"/>. In the context of COSE, examples of traditional key exchange algorithms include Ephemeral-Static (ES) DH and Static-Static (SS) DH <xref target="RFC9052"/>.</t>
      <t>"Post-Quantum Algorithm":  An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Examples of PQC key exchange algorithms include ML-KEM.</t>
      <t>"Post-Quantum Traditional (PQ/T) Hybrid Scheme":  A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm.</t>
      <t>"PQ/T Hybrid Key Encapsulation Mechanism":  A multi-algorithm KEM made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
    </section>
    <section anchor="construction">
      <name>Construction</name>
      <t>ML-KEM is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameters sets for ML-KEMs are specified by <xref target="FIPS203"/>. In order of increasing security strength (and decreasing performance), these parameter sets
are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. <xref target="I-D.connolly-cfrg-xwing-kem"/> uses a multi-algorithm scheme,
where one component algorithm is a post-quantum algorithm and another one is a traditional algorithm. The Combiner function defined in Section 5.3 of <xref target="I-D.connolly-cfrg-xwing-kem"/> combines the output of a post-quantum KEM and a traditional KEM to generate a single shared secret.</t>
    </section>
    <section anchor="ciphersuite-registration">
      <name>Ciphersuite Registration</name>
      <t>This specification registers a number of PQ/T Hybrid KEMs for use with HPKE. A ciphersuite is thereby a combination of several algorithm configurations:</t>
      <ul spacing="normal">
        <li>
          <t>KEM algorithm (Traditional Algorithm + PQ KEM, for example, X25519MLKEM768)</t>
        </li>
        <li>
          <t>KDF algorithm</t>
        </li>
        <li>
          <t>AEAD algorithm</t>
        </li>
      </ul>
      <t>The "KEM", "KDF", and "AEAD" values are conceptually taken from the HPKE IANA registry <xref target="HPKE-IANA"/>. Hence, JOSE and COSE cannot use an algorithm combination that is not already available with HPKE.</t>
      <t>For readability the algorithm ciphersuites labels are built according to the following scheme:</t>
      <artwork><![CDATA[
   HPKE-<KEM>-<KDF>-<AEAD>
]]></artwork>
      <t>The HPKE PQ/T hybrid ciphersuites for JOSE and COSE are defined in <xref target="IANA"/>. Note that the PQ/T Hybrid KEM in HPKE is not an authenticated KEM. Authenticated KEM is only possible when both parties contribute a PQC KEM public key and a traditional public key to the overall session key. The HPKE Base mode can only be supported with the PQ/T Hybrid KEM.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. PQC KEMs used in the manner described in this document <bcp14>MUST</bcp14> explicitly be designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security. ML-KEM has such security properties.</t>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <section anchor="jose">
        <name>JOSE</name>
        <t>This document requests IANA to add new values to the "JSON Web Signature and Encryption Algorithms" registry.</t>
      </section>
      <section anchor="jose-algorithms-registry">
        <name>JOSE Algorithms Registry</name>
        <ul spacing="normal">
          <li>
            <t>Algorithm Name: HPKE-X25519MLKEM768-SHA256-AES256GCM</t>
          </li>
          <li>
            <t>Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the X25519MLKEM768 Hybrid 
KEM, the HKDF-SHA256 KDF, and the AES-256-GCM AEAD.</t>
          </li>
          <li>
            <t>Algorithm Usage Location(s): "alg, enc"</t>
          </li>
          <li>
            <t>JOSE Implementation Requirements: Optional</t>
          </li>
          <li>
            <t>Change Controller: IANA</t>
          </li>
          <li>
            <t>Specification Document(s): [[TBD: This RFC]]</t>
          </li>
          <li>
            <t>Algorithm Analysis Documents(s): TODO</t>
          </li>
          <li>
            <t>Algorithm Name: HPKE-X25519MLKEM768-SHA256-ChaCha20Poly1305</t>
          </li>
          <li>
            <t>Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the X25519MLKEM768 Hybrid<br/>
KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.</t>
          </li>
          <li>
            <t>Algorithm Usage Location(s): "alg, enc"</t>
          </li>
          <li>
            <t>JOSE Implementation Requirements: Optional</t>
          </li>
          <li>
            <t>Change Controller: IANA</t>
          </li>
          <li>
            <t>Specification Document(s): [[TBD: This RFC]]</t>
          </li>
          <li>
            <t>Algorithm Analysis Documents(s): TODO</t>
          </li>
        </ul>
      </section>
      <section anchor="cose">
        <name>COSE</name>
        <t>This document requests IANA to add new values to the 'COSE Algorithms' registry.</t>
        <section anchor="cose-algorithms-registry">
          <name>COSE Algorithms Registry</name>
          <ul spacing="normal">
            <li>
              <t>Name: HPKE-Base-X25519MLKEM768-SHA256-AES256GCM</t>
            </li>
            <li>
              <t>Value: TBD1</t>
            </li>
            <li>
              <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the X25519MLKEM768 Hybrid KEM, the<br/>
HKDF-SHA256 KDF, and the AES-256-GCM AEAD.</t>
            </li>
            <li>
              <t>Capabilities: [kty]</t>
            </li>
            <li>
              <t>Change Controller: IANA</t>
            </li>
            <li>
              <t>Reference: [[TBD: This RFC]]</t>
            </li>
            <li>
              <t>Name: HPKE-Base-X25519MLKEM768-SHA256-ChaCha20Poly1305</t>
            </li>
            <li>
              <t>Value: TBD2</t>
            </li>
            <li>
              <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the X25519MLKEM768 Hybrid    <br/>
KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.</t>
            </li>
            <li>
              <t>Capabilities: [kty]</t>
            </li>
            <li>
              <t>Change Controller: IANA</t>
            </li>
            <li>
              <t>Reference: [[TBD: This RFC]]</t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to Ilari Liusvaara and Orie Steele for the discussion and comments.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that 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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="FIPS203" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf">
          <front>
            <title>Module-Lattice-based Key-Encapsulation Mechanism Standard</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="HPKE-IANA" target="https://www.iana.org/assignments/hpke/hpke.xhtml">
          <front>
            <title>Hybrid Public Key Encryption (HPKE) IANA Registry</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.rha-jose-hpke-encrypt">
          <front>
            <title>Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)</title>
            <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
              <organization>Nokia</organization>
            </author>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
         </author>
            <author fullname="Aritra Banerjee" initials="A." surname="Banerjee">
              <organization>Nokia</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Transmute</organization>
            </author>
            <author fullname="Michael B. Jones" initials="M. B." surname="Jones">
              <organization>Self-Issued Consulting</organization>
            </author>
            <date day="31" month="March" year="2024"/>
            <abstract>
              <t>   This specification defines Hybrid Public Key Encryption (HPKE) for
   use with JSON Object Signing and Encryption (JOSE).  HPKE offers a
   variant of public key encryption of arbitrary-sized plaintexts for a
   recipient public key.

   HPKE works for any combination of an asymmetric key encapsulation
   mechanism (KEM), key derivation function (KDF), and authenticated
   encryption with additional data (AEAD) function.  Authentication for
   HPKE in JOSE is provided by JOSE-native security mechanisms or by one
   of the authenticated variants of HPKE.

   This document defines the use of the HPKE with JOSE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-rha-jose-hpke-encrypt-07"/>
        </reference>
        <reference anchor="I-D.ietf-cose-hpke">
          <front>
            <title>Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Transmute</organization>
            </author>
            <author fullname="Ajitomi, Daisuke" initials="A." surname="Daisuke">
              <organization>bibital</organization>
            </author>
            <author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
              <organization>Security Theory LLC</organization>
            </author>
            <date day="12" month="July" year="2024"/>
            <abstract>
              <t>   This specification defines hybrid public-key encryption (HPKE) for
   use with CBOR Object Signing and Encryption (COSE).  HPKE offers a
   variant of public-key encryption of arbitrary-sized plaintexts for a
   recipient public key.

   HPKE works for any combination of an asymmetric key encapsulation
   mechanism (KEM), key derivation function (KDF), and authenticated
   encryption with additional data (AEAD) function.  Authentication for
   HPKE in COSE is provided by COSE-native security mechanisms or by one
   of the authenticated variants of HPKE.

   This document defines the use of the HPKE with COSE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-hpke-09"/>
        </reference>
        <reference anchor="I-D.connolly-cfrg-xwing-kem">
          <front>
            <title>X-Wing: general-purpose hybrid post-quantum KEM</title>
            <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Peter Schwabe" initials="P." surname="Schwabe">
              <organization>MPI-SP &amp; Radboud University</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date day="16" month="August" year="2024"/>
            <abstract>
              <t>   This memo defines X-Wing, a general-purpose post-quantum/traditional
   hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML-
   KEM-768.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-connolly-cfrg-xwing-kem-04"/>
        </reference>
        <reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="Florence D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Michael P" initials="M." surname="P">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Britta Hale" initials="B." surname="Hale">
              <organization>Naval Postgraduate School</organization>
            </author>
            <date day="10" month="September" year="2024"/>
            <abstract>
              <t>   One aspect of the transition to post-quantum algorithms in
   cryptographic protocols is the development of hybrid schemes that
   incorporate both post-quantum and traditional asymmetric algorithms.
   This document defines terminology for such schemes.  It is intended
   to be used as a reference and, hopefully, to ensure consistency and
   clarity across different protocols, standards, and organisations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-04"/>
        </reference>
        <reference anchor="RFC6090">
          <front>
            <title>Fundamental Elliptic Curve Cryptography Algorithms</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="K. Igoe" initials="K." surname="Igoe"/>
            <author fullname="M. Salter" initials="M." surname="Salter"/>
            <date month="February" year="2011"/>
            <abstract>
              <t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6090"/>
          <seriesInfo name="DOI" value="10.17487/RFC6090"/>
        </reference>
        <reference anchor="RFC8037">
          <front>
            <title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)</title>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8037"/>
          <seriesInfo name="DOI" value="10.17487/RFC8037"/>
        </reference>
        <reference anchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91Z63LbxhX+j6fY0j8ipQJ1sZXYnNQJTcqREt1syk0zHk9n
CSzJrUAA3l2IZjzKs/RZ+mT9ztkFCUh07DpNf9TjEYG9nut3LojjOHLaZaon
Opcvdq/E8XJsdCp+PDrriePLH4/EQruZ+OFidLQ7wJ9OJMdjo24+eXkinZoW
ZtkT1qVRlBZJLue4LTVy4mKj0nQZJ4VV8T/oT/k2iWd8ZDwrr1Vkq/FcW6uL
3C1L7Do5unoe5dV8rEwvSnF0L0qK3KrcVrYnnKlUBNIeRtIoCRJHKqmMdstO
tCjM9dQUVYlRT9i1WmIw7UUiFpcvBvRDE/T7Q/j1zPETWIuiG5VXuFGI+iQi
vIN3T1znJ1yi86n4nqZpfC51FpZ9p5WbdAszpXFpkhnGZ86Vtre7S8toSN+o
br1slwZ2x6ZYWLVLB+zSxiiyTubp32VW5LhxqWxU6p547YpkR9jCOKMmFk/L
eXhwRiduRyTFfK5yhxEoYC7LEmS+iSJZuVlhSAQ4W4hJlWVeO1faVHOZKbuQ
RrwkJfEC0CVz/Yt0UEhPnBfXWvJ4Ahn3xDOZT0GYUTxm1JRX/ShNLp28DiuL
KndkDSd5GjarIKXrIk+dNt9N6b0Lijv36TqWea6suLLJrJioXE/vk7UmqH3h
98rMZb5sXTnj47pudRwuf9fNletEkYjyAjsclNKLIp1P1m8Chzw/uRwd7D30
l4jahc6KtMpUfCqd04mKx9IqOIdaxkd5IktbZUyjOFMJrtZ2LkakTmnSTjhH
mqlyPVFbRn6TldXYdrHWdafFzS490Mgu3b97fjK66tJTF6R0y3TiT2HHEBOZ
WVIF2W580j/vB1pXSg//ID2oA/MtVoJjX1bjTCfEggALZlky/Vt05jZvgnVM
QZNZbmZgsVh0tcylN2l48jRnQ9wl9+Y/3XczN8/uE+5HojiOhRzjApm4KLqa
aUsmXNEhoqhcpske3EwJwgEAQMIEFhMhRQugPAMbdbAF9NoWOm/zHG/mGWaA
pcA0449Z4Z2AIhlBuuLECVuqRE90oK1yOgv2SaSNC+wBR6mmEZnx1svCuvhF
JXNXzcWAbi1wRzlbii3A07aQGWAUl83hxHBuZYCdwhVCWnEHiXeYKPATxOLU
O0fXtqmMWLRznaYZhP0ADukMrJflR4JWmKuZxDUfIw96qXL9tlIiXAxNOeA+
XTwvUmVykeqpduA2ae7m1dKJXIFmZXhrSzQrtgX8kadLIuVtIKUxD9BnqFhS
ILDOi6c0hVOJI9OSrDw6wai3lSb58WimJ8rpOYBAXH3wdmBplcxI2i9HfZai
yjIN00gEYsyNIqFnGdluRtfW5DGvMgPwWI0zFjOdqd9kYiIT2EueKOMk7GwJ
44eZeyvKIcZsSREGSDRTBEeJZXAvMzgZNiJWVgpDVX6dF4tc3FRZrowcw/yc
pokZsGZBgiIObDFx/KJxgCKXYnVbr5GZvFGQOT1gaTWZ6EST1+FaBFUQQTIj
Xg0gj3xRJBl5eFKrGG6fLUlAQEOZXFu+s32VGFdTC1MchhO9+HPL8hcTU8xb
6iB9bpbbDu0lTnCLSJWFdgFseA6qZrwg9ZM9FEmRBSYrq7w7ro7iYA5TCP6E
NEGodwQVU+X9zhIZlWU1VJnT4Ke9qqFNq2mJzFVRWdglCQDaGuu85tYoAJLz
KELv0wJswmVA5o1OaZUNOYxQSD+EBrDBwsaQNjIAWumdfF7iFSw27oYokD5c
q5wBCW/zAuFLkl+Ml00x35Vq0z+7SDk4rysmzLoUN9LA1hhQSg+UzPwaKAl7
zVjjArOMrf4F95UZ2TJgyLIOSCuJLtma/BkkQO99ATiTYIm1x5KecHA7xVyB
Gbs+tJ4YPcZ1wJT37789iYddM5M+saRIEwcib295Y1hCCZfPQGnN7S2hKxFB
oT4DUXxlImGqCip2Ck7IwGKrskTCdRd8CSFSNUFYatIBFM4LIFOcTMw0freA
YiG2+e0tMQ3VtLgO++/hOocoooaEQgLZFHsIygdFDlvxAqSZIZ3HurYe2Ulj
lPxaZCyvRledHf8rzi/4+eXRi1cnL4+G9Dw67p+erh6isGJ0fPHqdLh+Wu8c
XJydHZ0P/WaMitZQ1Dnr/4wZoqpzcXl1cnHeP+34INCM7KRPyHisONaa0igy
W2mjlpKfDS7/9c/9RxDyn14+Hxzs7z+Bav3L4/2vH+FlMVO5v63I4X/+Ffa0
jJADK0mhnP0JiQGFJsAI1GdnBJ0EJ0CmL1+TZN70xDfjpNx/9DQMEMOtwVpm
rUGW2f2Re5u9EDcMbbhmJc3W+B1Jt+nt/9x6r+XeGPzmW0qkRLz/+Nun0d00
ay6vYYzBAxmikUpvsnJ2pRJ4W+Kvqws5Wq1h/cV0Sfb+vI7ilQHq4GA+tHHf
jtAMVzOVlQjnwQ7kOGOTSDVwUTUxigJMA/VyLHKLwgcjZZG7d64aIaRfL+30
hOhD+6iV5orKpA+dKXwWD7/kvA85CmI0Uhtt2Vt3BDsXUg+tMmQUGgYKaxXg
V9axqZ0qbF4DsRiVMTyvozsIRiQA63NEpJONGR1OfycpqHpJNlj9UFDSeZJV
kOFRTdWAqRpqhHgVH4NYFEriqAQNyB0yqlFoFZQMx/pq78keexm9PN57+DXp
9D5lg99HWX13HO7eOhpti+Exe7IfWs2M/Iwn6Mne4QERBKW3EtbP0DqnBxRD
VaYRetNghxyOQfQUEc26VWrj84FVBEU8rhzHSysWECj9NrKjerorjhoSQh79
UcmcncaIBN27/DUtfIvCxnYdN0YJiZLZ9ulKvGbR8hyhInHkRKak9XnFhoTC
p1ab0y/WS+sAXrwxk2baP60y20w1RcK5hCyqku0Kvg7fmRemSTZH4rX4NrD4
32OHA+6q9owiryO/B5vjEnoXW1QNqRgnxwjfyLrT7TumN18VpJwjIZEyKJhy
6Qgwi2B4CGIWKQjZSagDFNIxBslmVuXN0SeYYewLG4znTsplFLBYGgl3IIO1
KiRpfrGvqupqljPH9+9D7yN4PvIIYCI0ARs1kFgraYVYVD5FmrJFMk3VakWp
DHdUULVsc0i2DTKYCmriBSriw/2Dnfr5668e+5Ae3vf3Dh51P5poUfwihWz2
gZ3IW8hn2z7qJKpeP2IrnOEOuACgMIIyr5HvcSQdKT902H1IIv0oV76aCG0G
1GBl5Xzzo0UsewOR2aKLRmE3U0UlIqKRFKQZhFmLKhHkWNKW8waugcjGVhTn
QsNH1o2Ce+mr4QW+WvC9Wo9urWTWtrNYymu7cPakcZG2vqiDzcnA6KqFYgHJ
pilbCj4TPa08XRT24zYIiK2NaYD4MyjzXRMiKESsHfG3g8PD/Sdnp5iBwW3T
acPn69Pw3j/qDxsDnFh3sJwSX6yts1xa1kHVlFXKOxMITVTpKsmdCuRWdaGL
/Zzec1vNhLYaTGDVwCOHO0YRA/La5Q/KEyrUSZoyb8lkLbQ6ntFCmcENU4j1
hjrPlFmtlYD07znnIjL1fYMlU9Y4dK0iK7BbZZ6vcaVRycokASAw+hS8cQLD
LRYMCuxq0Myvv/5K3T3m6xtI7Cn+Dp/jL8nqKU+zNFkabDc+lWxfTeraVAU2
stJaaOeFU14ARNGHyqpaODm3SKmASjgdo4Ar+neHaDkXFfA0q1mGWOCbCQAy
ardwQoRqpWLnovDeht8NPtmYDPIr2NAzWDx/B1lXykzzM+Sm3F/jEpXpoSTF
16YgdNVYuMM0e3X9eYTjF7Lq4Dte+C0QsHXOkq7aexvaIyicKqTAY9VaLcVC
Lr30ZTKjXMqjVccf0aEMF9GAviCsOyIhiOBqknOddMHeCkzgtxWd73VBPphF
UZOybooEfXBls2JrTl8ETLuX0C5NufpT70qoSTsvbuo3TfO7KWI4kdo2bm18
DQXjVKPo8nVv0QuImD85H8aDQf9gFUq7dfieUYlK61dBNggQFsdqZfxoq1S8
f8C+gOkH/vPWnRqP2mTKQs+8mbKJNBW5WtTAFYyx88Po4lz8pMZiBI6pEeg7
iY0++QpZbWcFYt3VvY3p1ZcDQVi9BuRz/6WHwKENwjGK54PDr+L+0Qg/3w/O
WtuGrLLSf5ry8Ur4OFIDRey9PPdOc0ZOU/cAvUW2r6u9BVDF4YHxGTgVyKB4
4CGeJkBTTLSBKg4M3RZtr6yEIZ4WPkBu2e2e6MAsd6ht1on8B0dx0u6Mvlw3
Lm1PXJQeILB44M16QNgCbFUmfL2JxagVhodBt3zd69dXz4Y932xCnfTmTYu+
PnVqLabqPZY3XV0ML/5D3YA4/D/Yuyyy5f7DvcP/jYo+TUd3aft/UxRcbPD5
rv3FoO2eX7S915/9Aff9UjQtg3T3UdfFlr/S/SD+2XBf0Ptvm8fg881jZRqC
045P92EQNZDl6vMJtHPtlm94+AO6xdRL+khAWdomZX66qO55UktiB3+owPyn
V/E7nOoPkNwD0U/oq1am0imbfvS+F+oLlf6lw1+NO7dk/TK/ZrM+yaTR4lRX
9kaitGSaL4xWYuSUytTq4wL14yqfXYUvNHx+N/o3HnJMpx4jAAA=

-->

</rfc>
