<?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.29 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-mls-pq-01" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="MLS Cipher Suites with ML-KEM">ML-KEM and Hybrid Cipher Suites for Messaging Layer Security</title>
    <seriesInfo name="Internet-Draft" value="draft-mahy-mls-pq-01"/>
    <author initials="R." surname="Mahy" fullname="Rohan Mahy">
      <organization>Rohan Mahy Consulting Services</organization>
      <address>
        <email>rohan.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="R. L." surname="Barnes" fullname="Richard L. Barnes">
      <organization>Cisco</organization>
      <address>
        <email>rlb@ipv.sx</email>
      </address>
    </author>
    <date year="2025" month="July" day="07"/>
    <area>sec</area>
    <workgroup>MLS</workgroup>
    <keyword>ML-KEM</keyword>
    <keyword>Kyber</keyword>
    <keyword>post-quantum</keyword>
    <keyword>post quantum KEM</keyword>
    <keyword>KEM</keyword>
    <keyword>PQ/T</keyword>
    <keyword>hybrid</keyword>
    <keyword>hybrid KEM</keyword>
    <keyword>Key Exchange Mechanism</keyword>
    <abstract>
      <?line 51?>

<t>This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers.
These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms.</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-mahy-mls-pq/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        MLS Working Group mailing list (<eref target="mailto:mls@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mls/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mls/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/rohanmahy/mahy-mls-xwing/"/>.</t>
    </note>
  </front>
  <middle>
    <?line 56?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The potential availability of a cryptographically-relevant quantum computer has caused concern that well-funded adversaries could overturn long-held assumptions about the security assurances of classical Key Exchange Mechanisms (KEMs) and classical cryptographic signatures, which are fundamental to modern security protocols, including the MLS protocol <xref target="RFC9420"/>.</t>
      <t>Of particular concern are "harvest now, decrypt later" attacks, by which an attacker could collect encrypted traffic now, before a quantum computer exists, and later use a quantum computer to break the confidentiality protections on the collected traffic.</t>
      <t>In response to these concerns, the cryptographic community has defined "post-quantum" algorithms, which are designed to be resilient to attacks by quantum computers.
Symmetric algorithms can be made post-quantum secure simply by using longer keys and hashes.
For asymmetric operations such as KEMs and signatures, entirely new algorithms are needed.</t>
      <t>In this document, we define ciphersuites that use the post-quantum secure Module-Lattice-Based KEM (ML-KEM) <xref target="MLKEM"/> together with appropriate symmetric algorithms and traditional signature algorithms.  These cipher suites address the risk of "harvest now, decrypt later" attacks, while not taking on the additional cost of post-quantum signatures.</t>
      <t>Following the pattern of base MLS, we define several variations, to allow for users that prefer to only use NIST-approved cryptography, users that prefer a higher security level, and users that prefer a PQ/traditional hybrid KEM over pure ML-KEM:</t>
      <ul spacing="normal">
        <li>
          <t>ML-KEM-768 + X25519 (Medium security, Non-NIST, PQ/T hybrid)</t>
        </li>
        <li>
          <t>ML-KEM-768 + P-256 (Medium security, NIST, PQ/T hybrid)</t>
        </li>
        <li>
          <t>ML-KEM-1024 + P-384 (High security, NIST, PQ/T hybrid)</t>
        </li>
        <li>
          <t>ML-KEM-768 (Medium security, NIST, pure PQ)</t>
        </li>
        <li>
          <t>ML-KEM-1024 (High security, NIST, pure PQ)</t>
        </li>
      </ul>
      <t>For all the cipher suites defined in this document, we use AES256 GCM <xref target="GCM"/> as the Authenticated Encryption with Authenticated Data (AEAD) <xref target="RFC5116"/> algorithm;
HMAC <xref target="RFC2104"/> with SHA-384 <xref target="SHS"/> as the hash function;
and XOF(SHAKE256) (Section 3.2 of <xref target="FIPS202"/>) as the Key Derivation Function (KDF).</t>
      <t>For the PQ/T hybrid KEMs and the pure ML-KEM HPKE integration, we use the KEMs defined in <xref target="I-D.ietf-hpke-pq"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="mls-cipher-suites">
        <name>MLS Cipher Suites</name>
        <t>This document requests that IANA add the following entries to the "MLS Cipher Suites" registry, replacing "XXXX" with the RFC number assigned to this document:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Name</th>
              <th align="left">Rec</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBD1</td>
              <td align="left">MLS_128_KitchenSink-KEM(ML-KEM-768,X25519)_AES256GCM_SHA384_Ed25519</td>
              <td align="left">Y</td>
              <td align="left">RFCXXXX</td>
            </tr>
            <tr>
              <td align="left">TBD2</td>
              <td align="left">MLS_128_QSF-KEM(ML-KEM-768,P-256)_AES256GCM_SHA384_P256</td>
              <td align="left">Y</td>
              <td align="left">RFCXXXX</td>
            </tr>
            <tr>
              <td align="left">TBD3</td>
              <td align="left">MLS_192_QSF-KEM(ML-KEM-1024,P-384)_AES256GCM_SHA384_P384</td>
              <td align="left">Y</td>
              <td align="left">RFCXXXX</td>
            </tr>
            <tr>
              <td align="left">TBD4</td>
              <td align="left">MLS_128_ML_KEM_768_AES256GCM_SHA384_P256</td>
              <td align="left">Y</td>
              <td align="left">RFCXXXX</td>
            </tr>
            <tr>
              <td align="left">TBD5</td>
              <td align="left">MLS_192_ML_KEM_1024_AES256GCM_SHA384_P384</td>
              <td align="left">Y</td>
              <td align="left">RFCXXXX</td>
            </tr>
          </tbody>
        </table>
        <t>The mapping of cipher suites to HPKE primitives <xref target="I-D.ietf-hpke-hpke"/>, HMAC hash functions, and TLS signature schemes <xref target="RFC8446"/> is as follows:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">KEM</th>
              <th align="left">KDF</th>
              <th align="left">AEAD</th>
              <th align="left">Hash</th>
              <th align="left">Signature</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0xTBD1</td>
              <td align="left">0x0051</td>
              <td align="left">0x0011</td>
              <td align="left">0x0002</td>
              <td align="left">SHA384</td>
              <td align="left">ed25519</td>
            </tr>
            <tr>
              <td align="left">0xTBD2</td>
              <td align="left">0x0050</td>
              <td align="left">0x0011</td>
              <td align="left">0x0002</td>
              <td align="left">SHA384</td>
              <td align="left">ecdsa_secp256r1_sha256</td>
            </tr>
            <tr>
              <td align="left">0xTBD3</td>
              <td align="left">0x0052</td>
              <td align="left">0x0011</td>
              <td align="left">0x0002</td>
              <td align="left">SHA384</td>
              <td align="left">ecdsa_secp384r1_sha384</td>
            </tr>
            <tr>
              <td align="left">0xTBD4</td>
              <td align="left">0x0041</td>
              <td align="left">0x0011</td>
              <td align="left">0x0002</td>
              <td align="left">SHA384</td>
              <td align="left">ecdsa_secp256r1_sha256</td>
            </tr>
            <tr>
              <td align="left">0xTBD5</td>
              <td align="left">0x0042</td>
              <td align="left">0x0011</td>
              <td align="left">0x0002</td>
              <td align="left">SHA384</td>
              <td align="left">ecdsa_secp384r1_sha384</td>
            </tr>
          </tbody>
        </table>
        <t>The hash used for the MLS transcript hash is the one referenced in the cipher suite name. "SHA384" refers to the SHA-384 functions defined in <xref target="SHS"/>.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This ciphersuites defined in this document combine a post-quantum (or PQ/T hybrid) KEM with a traditional signature algorithm. As such, they are designed to provide confidentiality against quantum and classical attacks, but provide authenticity against classical attacks only.  Thus, these cipher suites do not provide full post-quantum security, only post-quantum confidentiality.
Cipher suites using post-quantum secure signature algorithms may be defined in the future.</t>
      <t>For security considerations related to the KEMs used in this document, please see the documents that define those KEMs <xref target="I-D.ietf-hpke-pq"/> and <xref target="I-D.irtf-cfrg-hybrid-kems"/>.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="SHS">
          <front>
            <title>Secure hash standard</title>
            <author>
              <organization/>
            </author>
            <date year="2015"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
        </reference>
        <reference anchor="MLKEM">
          <front>
            <title>Module-lattice-based key-encapsulation mechanism standard</title>
            <author>
              <organization/>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.fips.203"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
        </reference>
        <reference anchor="FIPS202">
          <front>
            <title>SHA-3 standard :: permutation-based hash and extendable-output functions</title>
            <author>
              <organization/>
            </author>
            <date year="2015"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.fips.202"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
        </reference>
        <reference anchor="GCM">
          <front>
            <title>Recommendation for block cipher modes of operation :: GaloisCounter Mode (GCM) and GMAC</title>
            <author fullname="M J Dworkin" initials="M." surname="Dworkin">
              <organization/>
            </author>
            <date year="2007"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-38d"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>
        <reference anchor="RFC9420" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9420.xml">
          <front>
            <title>The Messaging Layer Security (MLS) Protocol</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/>
            <author fullname="R. Robert" initials="R." surname="Robert"/>
            <author fullname="J. Millican" initials="J." surname="Millican"/>
            <author fullname="E. Omara" initials="E." surname="Omara"/>
            <author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9420"/>
          <seriesInfo name="DOI" value="10.17487/RFC9420"/>
        </reference>
        <reference anchor="RFC5116" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml">
          <front>
            <title>An Interface and Algorithms for Authenticated Encryption</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5116"/>
          <seriesInfo name="DOI" value="10.17487/RFC5116"/>
        </reference>
        <reference anchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2104"/>
          <seriesInfo name="DOI" value="10.17487/RFC2104"/>
        </reference>
        <reference anchor="I-D.ietf-hpke-pq">
          <front>
            <title>Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE</title>
            <author fullname="Richard Barnes" initials="R." surname="Barnes">
              <organization>Cisco</organization>
            </author>
            <date day="30" month="June" year="2025"/>
            <abstract>
              <t>   Updating key exchange and public-key encryption protocols to resist
   attack by quantum computers is a high priority given the possibility
   of "harvest now, decrypt later" attacks.  Hybrid Public Key
   Encryption (HPKE) is a widely-used public key encryption scheme based
   on combining a Key Encapsulation Mechanism (KEM), a Key Derivation
   Function (KDF), and an Authenticated Encryption with Associated Data
   (AEAD) scheme.  In this document, we define KEM algorithms for HPKE
   based on both post-quantum KEMs and hybrid constructions of post-
   quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3
   that is suitable for use with these KEMs.  When used with these
   algorithms, HPKE is resilient with respect to attacks by a quantum
   computer.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-hpke-pq-01"/>
        </reference>
        <reference anchor="I-D.ietf-hpke-hpke">
          <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="Richard Barnes" initials="R." surname="Barnes">
              <organization>Cisco</organization>
            </author>
            <author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan">
              <organization>Inria</organization>
            </author>
            <author fullname="Benjamin Lipp" initials="B." surname="Lipp">
              <organization>Inria</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Apple</organization>
            </author>
            <date day="24" month="June" year="2025"/>
            <abstract>
              <t>   This document describes a scheme for hybrid public key encryption
   (HPKE).  This scheme provides a variant of public key encryption of
   arbitrary-sized plaintexts for a recipient public key.  It also
   includes a variant that authenticates possession of a pre-shared key.
   HPKE works for any combination of an asymmetric KEM, key derivation
   function (KDF), and authenticated encryption with additional data
   (AEAD) encryption function.  We provide instantiations of the scheme
   using widely used and efficient primitives, such as Elliptic Curve
   Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation
   function (HKDF), and SHA2.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-hpke-hpke-01"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.irtf-cfrg-hybrid-kems">
          <front>
            <title>Hybrid PQ/T Key Encapsulation Mechanisms</title>
            <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
              <organization>SandboxAQ</organization>
            </author>
            <date day="25" month="February" year="2025"/>
            <abstract>
              <t>   This document defines generic techniques to achive hybrid post-
   quantum/traditional (PQ/T) key encapsulation mechanisms (KEMs) from
   post-quantum and traditional component algorithms that meet specified
   security properties.  It then uses those generic techniques to
   construct several concrete instances of hybrid KEMs.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-hybrid-kems-03"/>
        </reference>
      </references>
    </references>
    <?line 118?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This work would not be possible without the hard work of the CFRG Hybrid KEM design team: Aron Wussler, Bas Westerbaan, Deirdre Connolly, Mike Ounsworth, Nick Sullivan, and Stephen Farrell.
Thanks also to Joël Alwen, Marta Mularczyk, and Britta Hale.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIALE0bGgAA51Z23LbyBF9x1d06BcpISiSlhyZW1tZWhdLsWTLpip2amtL
NQSG5JRw88yAMlfWF+Uz8mM5PQOQhEhZrvCBAoGe7p7u06d7oDAMA6tsIgd0
eRG+O7kkkcV0thhrFdORKmZS06hUVhqa5JoupTFiqrIpXYgFP5JRqZVdBGI8
1nLOSkaPlt0pO6t0B3EeZSKFrViLiQ1TMVuEaWLC4mvY7QWq0AOyujS23+2+
7vYDU45TZYzKM7sosOr85PqU6AWJxOQDaqksloXEV2ZbbWqdD9/gD5xsnX+6
Pm0JLcWAhLbBXa5vpzovC+de4B8YGQWRsHKa68WAVDbJg1u5gGg8CCisHcbV
u8VYar4ocmPDr6XIbJnWv6n6TbWw/3P1ce+a/85cHFdXSzG5oJNv0UxkU4mY
8oUyaRAYi+jfiCTPsNuFNEGhBvS7zaM2mVxbLScGV4uUL/4IgrnMSgl3aW13
RD5Wn7FpztNbfoS7qVDJgBDs35S0k06up7gpdDQb0Mzawgz29liE76i57NRC
e3xjb6zzOyP3sHqPrSGj5XhAOoffnMO9ZSK/3cHmXvCCKEFsjV0p94s6UZ7u
PbnOrwkCUdpZrl0ekBkzoE8duoQobBN5AH1iHaub8BQh/FNYYGX9IR3lmSkT
y5EYST1XEYLKC6SPh3PFbfa3Kd9h/9bNXnTojdBZtagyrZAvHVPzWdODI2Wi
vGEoGf+minnHfAuCIMt1CsG5y93obDSg4w/nnV6386rbP9x7fz667pyeX406
vcNuuA+Rywvg5imhfvclRPiy3+0/LdSH0NujbVpGV53Dbjd8eXgcBFwHS9+C
MAxJjI3VIkJWrmfKECq4TFFwpOVUGSu1oUzeUeRL3jzPFLQDlO7SWBgZU55R
a72sWihtFCSgkgLodzNEGhiVyIblOo/J5jSWsG1UotgL/BbWiuiWxotlLSKH
RcmudeCzNPKRd6wwAizANJGFztKwl3Ym3U4u87hMZHgBtQCLr9QsEgVQ5HK7
KlfeCZPELkin4EciSRZwle2PVealHfshgLHyEiSTREE6IoRjLpkQsFObT6Vl
F524KAqdF1qhGohLARtVTFUxySzSC2erTTNhZm3H1kZNYa3EtlbR6/jspSqO
ExmgIM8zq7G1iBdzLiX4y7Jm+CTmXPljxBT5ySckyJnJp1oUyAHvK9QykXPE
dyPK7AhFouR8IqyR1BmCKSzdYavhpHR5E/Ec+RBaIf5RXiZIPW7A54xAdtNw
JnFLGFOmbndI0jgvrUuKqYHDj7WAAcM+Rgl+s29PkKmhHY7trovQSrixsVXk
GmhjnwWDHPIAWJrHvKelH0gOGDlPsEZlUVLGNXy499UP6f7+L59Oj17v97sP
D0jGhwkV6EUqAoz0Mk5srQUymYP2KMvv2hRL56GjT92qwA1LgHflYFbdlLqK
JKwlMrI1OLhK0F0n2J7TOJYoR0BjM3HyGyrYeAw5eyiFrYJcdWiat26X8H2i
Yo+cOhwy8lnLs0rEebTyBAE4z7hsC0hJ1md9Yfo4cAXwskZuYD0tM7bAAIvl
RGVQ+FN0EUtO7I/owjzBF6NFmkqrYX6lGeDOWE0qYtkYAjwkgFCVFqh8aPRU
wohG1DBOGBdbrlQJ5aegRWGWFvJCauHjZkr23Dg2aJY09sWhRvUtHD2tucU7
zaREefnw2nV+RjhkFbSK/ir2c6XJebaz7btpEmD4xhE1D4Y13TG0XUd6ePgB
cZltkeStrZPhVuYi2sracYxoGOe2VuaWOeDnSge4SBCpHOkXbiSqUAqNtR8R
j3JQ2IzHMgeI7ykgnd/VlV5AOdcvlnAj48pfD7iRIDeonQuOBWe47aDHKlxz
RPx1lYoCs5wvsTxLFi4z3JVDF8s5c+qqKhbtLSsFzdTUBaomKBC1THxZbxPH
cLqeg9Vk6jiZCgcCl2qMAH+tLsO/vzqkv9GX/sFB7zWgIGNVQwYm2/Q+z0L2
u+1m30rp7uPlV2H/4NW21T9Y2ev2993Sl4f7tHOGvf7kQjb5lCm3yauPj81s
V78U9hWcJJ6tGvCs+Ultq0NO6vBkxHvHCIb6wTeKR3g0Dxst/mTZ4n1NNZ8e
CytoZ3gyPN6tOsxBr/eKddX180twdjk8qh72e919PHSKRmdDF8L7e0ycK+tM
TtzxHIP/EjBovnw43YH0uxM4vEs7I8/u9LLTZ8Df31ez5sPDbq2EW/Cx1Gru
h57TSh1a8PHpbsfHjeXWErXiOldQK9DR2dW7EzfxTT09LkPoLPGqtWBjn+fh
sZvgw1lxK3GUdP2WJ57h+6Gb/9GtKqLF7RebR9TN0fZrCVap6sapAVc485Ml
DUDQTTO+l1FrQ2urGpE1cKRlkYiIl7W+4NOqxkKsQ5IoK9MxV6ZZda0GhlCG
3+lfIikl0Xd6j9GEfu7znT7JyH2j8jEeSPoefB/86j/Li5/5OOHB2pIBNNH1
m+Me1GPrN73+4c07ZSNgdaSyW07kzqoO2543dm98FQD+NwAY0HhzEntGcd7S
v53Pp0ccJKos9NcsfBydPtbsKGWL4iuuNvqB3pe13tf9x3qZC9qOcLYp5iL6
gd79NX8vL26g7wZ+PungE1oO1ryrtLBXT7mzqcWN+Cm6iOt4k0d0BYi5MkOz
ThWf9sxmJfHXw0ObHJ80aKKaGa8B+VUHN8h96vXAi8P9faYloFiYqmpME8dc
6j6MIAl/wbzmLs7YGl+MluqbwN4G481bz2Odo939VuG4+63bPehRddWrb3UZ
gT7auJArwD7yyCvq14q6zymKYiNu0GsKJFT3bsxMMCKWil7Wivo/rQi/vSL3
oFa0X63af3Zrz3h0UCv6vz1yoHRQcsfFSdUWmDsxkmQm0jgbewHlO0ue8fxe
0VfVXpu9172V6VDLW2956SUv111vCd315vE7OuEfHe4Vy7cTj/uF6wyNAfqp
Tl8d+/kA1Rgjd7DJ9QHFAd+Py8/Nwh0a+rOBOx8tNs42PCHC2Y0jmZgKla29
nGwegVdnytIuVSzfM6yv31jjZlQ3oJf+zLYxpse5m7RrtZMS09LmKcMNV27e
bTx7tI9OcNTQ7U9X209gm+cIkN+Cj22NfLFHLFfNJMuROWqkHRhK3LhVgcgN
HQ6xm+NdkUg+ARjp55P6QTU8VAcCO8tNpWbrwOIydH//D/dE40k00dPQAya8
lalxMw2/0BkjDQzYYXSLQ08i46mzFtwP/BQh419bE5EY2XqowMtvv/HFbwo4
M2N36jNqjDMRo7B+zeJeaTpZNAu+cXT66W39jwCGrAceWSnSAQ01prvPpTGJ
1G3CGZE+S34bOBYC89qxVBqnNS6mDNSPXF+qW0kfyszAggWc36voFnNSkmBk
zHw3GVmJZGN4FBrhT/jdncgAOX7Zz4n4Z/7f/yQ0TO4kFlwKjUH4kl+mRH8u
br2GN0gl7p6JBPn9H+IqHonZGAAA

-->

</rfc>
