<?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 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-spm-lake-pqsuites-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="EDHOC PQC">Quantum-Resistant Cipher Suites for EDHOC</title>
    <seriesInfo name="Internet-Draft" value="draft-spm-lake-pqsuites-00"/>
    <author initials="G." surname="Selander" fullname="Göran Selander">
      <organization>Ericsson</organization>
      <address>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization>Ericsson</organization>
      <address>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <date year="2025" month="July" day="07"/>
    <area>Security</area>
    <workgroup>LAKE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 58?>

<t>The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-KEM for key exchange and ML-DSA for digital signatures. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites.</t>
    </abstract>
  </front>
  <middle>
    <?line 62?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC) <xref target="RFC9528"/>, supports the use of multiple authentication methods and the negotiation of cipher suites based on COSE algorithms. Currently, four asymmetric authentication methods (0, 1, 2, and 3) are defined. In addition, a symmetric key-based authentication method is being developed, see <xref target="I-D.ietf-lake-edhoc-psk"/>.</t>
      <t>The cipher suites defined in <xref target="RFC9528"/> rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication, making them vulnerable in the event that a Cryptographically Relevant Quantum Computer (CRQC) is realized.</t>
      <t>This document specifies how EDHOC can operate in a post-quantum setting using both signature-based and PSK-based authentication, and defines corresponding cipher suites.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" 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.
<?line -6?>
        </t>
        <t>Readers are expected to be familiar with EDHOC <xref target="RFC9528"/>.</t>
      </section>
    </section>
    <section anchor="edhoc-with-quantum-resistant-algorithms">
      <name>EDHOC with Quantum-Resistant Algorithms</name>
      <t>Method 0 in <xref target="RFC9528"/>, which uses digital signatures for authentication by both the Initiator and Responder, and also the PSK method in <xref target="I-D.ietf-lake-edhoc-psk"/>, is straightforward to use with standardized post-quantum algorithms.</t>
      <t>A quantum-resistant signature algorithm, such as ML-DSA <xref target="I-D.ietf-cose-dilithium"/>, is a drop-in replacement for classical signature algorithms such as ECDSA. For post-quantum secure key exchange, a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM <xref target="I-D.ietf-jose-pqc-kem"/>, can be applied directly to EDHOC, as is detailed in <xref target="KEM"/>.</t>
      <t>To enable post-quantum security in EDHOC it suffices to register new cipher suites using COSE registered algorithms, see <xref target="suites-registry"/>.  Additional post-quantum cipher suites may be specified.</t>
      <t>Methods 1–3 in <xref target="RFC9528"/> use a Diffie-Hellman/Non-Interactive Key Exchange (NIKE) based API for authentication. As of this writing, no standardized post-quantum algorithms for these methods exist. An alternative path to post-quantum EDHOC, not pursued in this document, would be to define new authentication methods based on Key Encapsulation Mechanisms (KEMs).</t>
      <section anchor="KEM">
        <name>Using KEMs for EDHOC Key Exchange</name>
        <t>Given a quantum-resistant KEM, such as ML-KEM-512, with encapsulation key ek, ciphertext c, and shared secret key K (using the notation of <xref target="FIPS203"/>). The Diffie-Hellman procedure in EDHOC is replaced by a KEM procedure as follows:</t>
        <ul spacing="normal">
          <li>
            <t>The Initiator generates a new encapsulation / decapsulation key pair matching the selected cipher suite.</t>
          </li>
          <li>
            <t>The encapsulation key ek is transported in the G_X field in message_1.</t>
          </li>
          <li>
            <t>The Responder calculates (K,c) = Encaps(ek).</t>
          </li>
          <li>
            <t>The ciphertext c is transported in the G_Y field in message_2.</t>
          </li>
          <li>
            <t>The Initiator calculates the shared secret K = Decaps(c).</t>
          </li>
          <li>
            <t>G_XY is the shared secret key K.</t>
          </li>
        </ul>
        <t>The security requirements and security considerations of EDHOC and the KEM algorithm used apply. For example, the Initiator MUST generate a new encapsulation / decapsulation key pair for each EDHOC session.</t>
        <t>Note that G_Y does not contain a public key when a KEM is used in this way.</t>
        <t>Note also that this use of KEM applies both to standalone KEM and hybrid KEMs such as, e.g., X-wing <xref target="I-D.connolly-cfrg-xwing-kem"/>.</t>
        <t>Conventions for using post-quantum KEMs within COSE are described in <xref target="I-D.ietf-jose-pqc-kem"/>. The shared secret key K corresponds to the initial shared secret SS' in that document.</t>
        <t>Compared to elliptic curve algorithms such as ECDHE, ECDSA, and EdDSA, ML-KEM-512 and ML-DSA-44 introduce significantly higher overhead <xref target="FIPS203"/><xref target="FIPS204"/>. In the future, more efficient post-quantum signature schemes such as FN-DSA and MAYO may be considered, but these are not standardized at the time of this document’s publication.</t>
        <t>Cipher suites using ML-KEM-512 <xref target="I-D.ietf-jose-pqc-kem"/> for key exchange and ML-DSA-44 <xref target="I-D.ietf-cose-dilithium"/> for digital signatures are specified in <xref target="suites-registry"/>. As both ML-KEM <xref target="FIPS203"/> and ML-DSA <xref target="FIPS204"/> internally use SHAKE256, it is natural to also use SHAKE256 for EDHOC's key derivation.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The cipher suites defined in <xref target="RFC9528"/> rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication, which would be broken by a Cryptographically Relevant Quantum Computer (CRQC). In contrast, the cipher suites specified in this document use the quantum-resistant algorithms ML-KEM for key exchange and ML-DSA for authentication. When used with Method 0 from <xref target="RFC9528"/>, where both the Initiator and Responder authenticate using digital signatures, or with the PSK method defined in <xref target="I-D.ietf-lake-edhoc-psk"/>, these cipher suites preserve the same security properties even in the presence of a quantum-capable adversary.</t>
      <t>Security considerations of ML-KEM are discussed in <xref target="I-D.sfluhrer-cfrg-ml-kem-security-considerations"/>.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="edhoc-method-type-registry">
        <name>EDHOC Method Type Registry</name>
        <t>IANA is requested to update the EDHOC Method Type registry with a column with heading "Requires DH/NIKE" indicating that the method requires Diffie-Hellman or Non-Interactive Key Exchange. Valid table entries in this column are "Yes" and "No".</t>
        <t>For the existing Method Types, the following entries are inserted in the new "Requires DH/NIKE" column:</t>
        <artwork><![CDATA[
Value: 0, Requires DH/NIKE: No
Value: 1, Requires DH/NIKE: Yes
Value: 2, Requires DH/NIKE: Yes
Value: 3, Requires DH/NIKE: Yes
]]></artwork>
      </section>
      <section anchor="suites-registry">
        <name>EDHOC Cipher Suites Registry</name>
        <t>IANA is requested to update the EDHOC Cipher Suites registry with a column with heading "Supports DH/NIKE" indicating that the cipher suite supports Diffie-Hellman or Non-Interactive Key Exchange. Valid table entries in this column are "Yes" and "No".</t>
        <t>For the existing EDHOC Cipher Suites, 0-6, 24, 25, the entry "Yes" is inserted in the new "Supports DH/NIKE" column.</t>
        <t>Furthermore, IANA is requested to register the following entries in the EDHOC Cipher Suites Registry:</t>
        <artwork><![CDATA[
Value: TBD1
Array: 30, -45, 16, TBD3, -48, 10, -16
Description: AES-CCM-16-128-128, SHAKE256, 16, MLKEM512, ML-DSA-44,
             AES-CCM-16-64-128, SHA-256
Supports DH/NIKE: No
Reference: [[This document]]
]]></artwork>
        <artwork><![CDATA[
Value: TBD2
Array: 3, -45, 16, TBD3, -48, 30, -16
Description: A256GCM, SHAKE256, 16, MLKEM512, ML-DSA-44,
             A256GCM, SHA-256
Supports DH/NIKE: No
Reference: [[This document]]
]]></artwork>
      </section>
    </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="RFC9528">
          <front>
            <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <date month="March" year="2024"/>
            <abstract>
              <t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9528"/>
          <seriesInfo name="DOI" value="10.17487/RFC9528"/>
        </reference>
        <reference anchor="I-D.ietf-cose-dilithium">
          <front>
            <title>ML-DSA for JOSE and COSE</title>
            <author fullname="Michael Prorock" initials="M." surname="Prorock">
              <organization>mesur.io</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Transmute</organization>
            </author>
            <author fullname="Rafael Misoczki" initials="R." surname="Misoczki">
              <organization>Google</organization>
            </author>
            <author fullname="Michael Osborne" initials="M." surname="Osborne">
              <organization>IBM</organization>
            </author>
            <author fullname="Christine Cloostermans" initials="C." surname="Cloostermans">
              <organization>NXP</organization>
            </author>
            <date day="12" month="June" year="2025"/>
            <abstract>
              <t>   This document describes JSON Object Signing and Encryption (JOSE) and
   CBOR Object Signing and Encryption (COSE) serializations for Module-
   Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum
   Cryptography (PQC) digital signature scheme defined in FIPS 204.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-dilithium-07"/>
        </reference>
        <reference anchor="I-D.ietf-jose-pqc-kem">
          <front>
            <title>Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE</title>
            <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
              <organization>Nokia</organization>
            </author>
            <author fullname="Aritra Banerjee" initials="A." surname="Banerjee">
              <organization>Nokia</organization>
            </author>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
            </author>
            <date day="6" month="May" year="2025"/>
            <abstract>
              <t>   This document describes the conventions for using Post-Quantum Key
   Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/.

   Discussion of this document takes place on the jose Working Group
   mailing list (mailto:jose@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/cose/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/jose/.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-jose-pqc-kem-01"/>
        </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="I-D.ietf-lake-edhoc-psk">
          <front>
            <title>EDHOC Authenticated with Pre-Shred Keys (PSK)</title>
            <author fullname="Elsa Lopez-Perez" initials="" surname="Lopez-Perez">
              <organization>Inria</organization>
            </author>
            <author fullname="Göran Selander" initials="G." surname="Selander">
              <organization>Ericsson</organization>
            </author>
            <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Rafael Marin-Lopez" initials="R." surname="Marin-Lopez">
              <organization>University of Murcia</organization>
            </author>
            <date day="1" month="March" year="2025"/>
            <abstract>
              <t>   This document specifies a Pre-Shared Key (PSK) authentication method
   for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange
   protocol.  The PSK method enhances computational efficiency while
   providing mutual authentication, ephemeral key exchange, identity
   protection, and quantum resistance.  It is particularly suited for
   systems where nodes share a PSK provided out-of-band (external PSK)
   and enables efficient session resumption with less computational
   overhead when the PSK is provided from a previous EDHOC session
   (resumption PSK).  This document details the PSK method flow, key
   derivation changes, message formatting, processing, and security
   considerations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lake-edhoc-psk-03"/>
        </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="3" month="May" year="2025"/>
            <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-07"/>
        </reference>
        <reference anchor="I-D.sfluhrer-cfrg-ml-kem-security-considerations">
          <front>
            <title>ML-KEM Security Considerations</title>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Quynh Dang" initials="Q." surname="Dang">
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Kevin Milner" initials="K." surname="Milner">
              <organization>Quantinuum</organization>
            </author>
            <author fullname="Daniel Shiu" initials="D." surname="Shiu">
              <organization>Arqit Quantum Inc</organization>
            </author>
            <date day="15" month="May" year="2025"/>
            <abstract>
              <t>   NIST standardized ML-KEM as FIPS 203 in August 2024.  This document
   discusses how to use ML-KEM and how to use it within protocols - that
   is, what problem it solves, and what you need to do to use it
   securely.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-sfluhrer-cfrg-ml-kem-security-considerations-03"/>
        </reference>
        <reference anchor="FIPS203" target="https://doi.org/10.6028/NIST.FIPS.203">
          <front>
            <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
            <author>
              <organization/>
            </author>
            <date year="2024" month="August"/>
          </front>
          <seriesInfo name="NIST" value="FIPS 203"/>
        </reference>
        <reference anchor="FIPS204" target="https://doi.org/10.6028/NIST.FIPS.204">
          <front>
            <title>Module-Lattice-Based Digital Signature Standard</title>
            <author>
              <organization/>
            </author>
            <date year="2024" month="August"/>
          </front>
          <seriesInfo name="NIST" value="FIPS 204"/>
        </reference>
      </references>
    </references>
    <?line 175?>

<section numbered="false" anchor="acknowledgment">
      <name>Acknowledgments</name>
      <t>This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8Va3XLbxhW+x1NsqYtIHYIWKdl1OE1ThqJtRaIki3ISTyaT
WQJLciMAC+8CklmNOnmHXvWqfYo+QPMmeZJ+ZxcAAYqU7U6m1YxtAPt3fr/z
nZV93/du+uzA8zKZRaLPXuc8yfLYvxRGmgzPbCjThdBskstMGDZTmo2OXp0P
PT6daoG19o1dvB56oQoSHmOTUPNZ5ps09iN+Lfz0nbGL/f19L+CZmCu97DOT
hZ7Jp7E0RqokW6ZYeDy6euF5MtV9luncZL39/c/3ex7XgvfZRAS5ltnSu1X6
eq5VnvbZ6eBkxL7Fu0zm7CV9867FEhNCbJZkQici849IHM8jdcIfeaQSnLQU
xktln32fqaDNjNKZFjODp2VMDz94XqBCbNpneTbzn3sez7OF0n3P9xh+ZGL6
7GUHMkXYVGj70Sn/8pd/aZ40R5TGRiMtA2NUYr+ImMuoz2AKnnRMMffPopjS
CVRcP+nrDrvQIv/lH2zMs6zaxB34tVokG4e3nvoTVnTiYmrzUC9RGiPyRvSx
4vLFsNftfl48fv6095wej/2jjhQwS6CM8EMZyWwh87gx9BMNpe8C/1pgwJPJ
rL5vNc3GhwgXKvBTc10OBSpJVBQt/WCm5/77W/jB7eOGzSzKF1poNxxHNOab
IjogVGIkjInD8ERrXhxfTHr7B31rgozrucj6bJFlqek/eRIq2YGhnnT3O8/2
e8+fnB1Prjq0ooMlboXLjLEK80j4pzCbDIT/FTciZCdi6Y+SgKcmj+yBbCyC
BU+kidmE4o3r0G5iYGWkFMzgxGCsRSe1+qxFhzEc1rIDZZzRc4hk6bNBPkcq
YEbvsFLm8NOVOfygMkdyLjMesYmcJzzLtfhUFQ4/RgXP832f8anJNA+QllcL
wU7lfJHdCvobc7OFSCAWVloDs9F7MulcsF1K9z2WaoWsVVGbjQBNMVwdQfbZ
TAr/lYiiGNmnbgBZw/PJiO1afNprMx4spLgBhKXKZP47h3OsDBs2XTIeUsaz
RNyywIGewy12iwBnxQpfV8jII6QvhmLCjTxYMG7Y+NQ/GY0tTAKImChFhx1p
7GgysGNhYWpTmtp02NVCGgYMzWOoz0wqAgmVDFuo2wJkVUphjU8yYXxdD3gS
wueG/p4qCFzt7U+te0mEi8lJ+bYyM4VtLOCzEIrQrFDMZIJjAqUhWaoSa5eG
TTrOjbEMw0jApzsEtxpRFdB2/yuvsru7Apfu78kHaQogNwxHwRCCqRmL8yiT
aSS26GvVpekJqlIm3RiWNf3vLIYRe/bK7R02zGGhJIuWbbg114iAZYytgajb
Dtzdb7Num/WcpQ/2GIpbYfCwAyPaKKQVmMBWuyGYHnMcQ+hMBXkpRIxHCJQQ
9hACBtqCtff3HeelpqqFJBRhNdsyLaIlGWAURTLF2aT4jWBDvUwzNdc8XSzh
kyE8sjHymzK3WcxtwcbHmN3kUQJnT+EjHEq+gAZIgGzBkWL1I7AcRYFdikjc
UP4VXIUNVZzmqPVsd3j5GiLAFiAMkfwLLEo6fiitAgotl1q/fWZ9Skbt7LAr
oWOJ4qfmS7bD7nay1fu98xcZlwiOYa3xG8Bv2/3Lzs7t8+Xo9Zvjy9ERPU9e
DU5PqwevmDF5df7m9Gj1tFo5PB+PR2dHbjG+ssYnrzUevG05fVrnF1fH52eD
05ZzWt3EFNCZQjhiCOKnWlDKc+OFwgRaTl10fTW8+Pc/u4eIst8VLANh5l6e
d/9wiJdbWNGdphK43b3CtEuPp6ng2voqiuC+lLCUsMswA7cmDFYVHe+PX0Yw
OvOfffknINSl4GAFxoon3iMMSCon54zHIDHY0QK9C4pa9HcsvrnPdsZDkjyo
MMHzxi4j99dyqA0NJIoEgMlswH+bOGu5jZpk442S4jiRhE80CRa5dEEktDMQ
tFd2FqKwQoTkseRvU5ZQCSZ0xtG3qPJkDYJNq6MpSj9lUTMhavjneYMNdbFS
ajW1USCpCNZEa7LIQjSOJkKlPpTQIo14IGxokY2CiKNjCOrGq4lUnTMa4pgO
e4EVDwu+aEAUIe1DLWyN2kLtdlHj9x4U/ZpOdfpLGhHEINAQuJGEPUOpEX8I
aljcxpWNXUoikYGhl/iLTR1MKyYSi5CbuQsmu+iUMH6OkhkgnrC1FnMoA4R5
SGkcmtl6Vs6iJK0zGls9is7NzdFLiMPYoKhQcEFDnuYJMV+SyiXgEhSPixrY
/fXnvx2slxiKPL5W8Z+cqcS3fRyoInqHNeJwdkzEwaHu4OJ4Qwp12MBQPbcI
dQvVoHWbJeqjwtvuh90gWFm9xXuYAZsS8lB3aTsalnJKUtXcp/BrojKW5trk
zqkNqAQkqDwKyUxY7WqE9dUW7lDxkEdi09jgNHuunLyxbqYPq869acS7HYoy
z3sJRZLNiTAar4e6/7QLAmNxQjTEsGl13S5CIRPvMxY4iDILThGGmEU9sPNO
2K6LQsu/VFaRr7u7omO7v98jWizWeSCoYiBCSuNV5JsSKEJL5Unq2jxO+keR
ukVD6P3e7rkC1LlICl7NrfWbKj2BY9ZVTLnUCPAMLUUhP1p4V1HqSdApz9pk
JBIZ+JsY4qxlcAj28sfvGHSN7IdYGMPn4sdutVMF/ICUKKAdBXm8HeyxL4qQ
2BXXe9X8uiO2nvj24Ym9zkM71U60Kjc8eoLzj6yhdgN3PDR5a498MNd6v6Cf
FYhp8S4HLFJeOFpejTQ7eooQ5/OSu5Orq6wlHAkt0C4d+ov3PEYD0F6ropYz
lZ7/NMdTJgm0k4UYqOd0gwV9zhS2sryVbBoqGIrSH/ID1S2xzKeRI/OWzhRh
Ko0TuoSHW74sNysKO8/cSNHUWIVtKTEFQSgBjS633DBss1hOtQxd9hf522ai
M++02Xc+XaoUFWvLdYstPUOVEBu3hie9XcY2gM7uT1ggywbJdjQ1rre1MLrs
3gQNK6JsKxn5TlrfRWvTJ5PPnOFgoxJXrdxxaqdhsSiblsA2LZvJwqtR23EG
B1ej0D6u4K7WwfuHh0RtbbcrLAtBgUOFp4K+AJ9CclKnugDhrGNZ+XhIeh+7
3JvlxF/QEClipVS5JfGcZpmvaI4JqDFeif3izHIpK9ng7XlZcst8oR5wmmdF
CSOvUDQ2Kp8NLMSsjEVVJksr/vrz300Rsa6WwqobOETNRFv9/Nh9CFnzETa4
5brEqlNxCxdkG7jKoEiQiqFV3qjfyNQ843qWxDaalG3onE5GvafP2sStYBx7
PCRBWNncrM9ZldjPjNUWPpA3pe12qgtsNKx1QPv/teGuIak4yFSra5G48vnp
bbeNaYI6zU3m0LapU8NbzZaRrEgLHrtj+9irtXUC+C0BrcVXy1eq7mymVbze
nyFnPthx1Q8QRQ48jM82U0U7udaWNTz7SHvmkrZpQbTSRpDDbUnlca16guqk
qPNUEej6pKztdkUS2ORecTtUNdtN8BAwZbimcjPZXm0Lw1tYlybIjanL/ym3
8bak7LALSotgQx58dWRvEgdngwdjO2UHXjjwapkSG3Kp7nl2jSWB73JhitY+
T+n62Rri4doSJpyXOPSO8jhxbwTd5NfWpSMlhh29ekLdBl13hDa0LO8r4LNw
ra4mr11bavZYH9Nh3/AIdTqzPkFk0TV7lSOFWGT81lthWu765Uy1YMkXrj9x
XYnF4pV+xqWgY700Vm7MLW02ok4Bifxs0NWdDcb8180/HgTPRZ/tt9n64j5U
Loe7m4ahSzne+8D4wbbxbWKtgqX5y8syXND0rNeKj42g5oYfFUOT8lr60Riq
Z/rqJvv/FkkbtG2zfR91sHeIP09ddNERy2I3aTaH1UP1nSB0aq4xTRP5abON
9q9uMDbHcnHOY77+cPQCdbreQGu+RKghlP1DaNeFphg4oNfneKXv3WfekaW1
KWFSnw1GE384HOO73+09pz/tGl+gHcanAE7bK1dcp1387qz4qe3x7LDawscO
3rrhbEpdihmKFBC9z77/vnG1/cMP2/PhwxboVRbYbICDjQaAmC+H4/9C69rC
31pX+rXUlAfX9tJ2EFwn6jYS4dz1lXSlzhvf7r27PkvyeEp8+YtWolr3xe8M
6L8ZoBczZTbSRRHX1IJE9teF30i0TTec+TYGJ7cCxXHBBugpUdqIiRzbcds7
TpaIYnAYmqtVPne0YPTmcnSCUjc6vToe+mej766ojv8kgowN315cjiaTjvcf
/eBKYKIhAAA=

-->

</rfc>
