<?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.6.31 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kwiatkowski-tls-ecdhe-kyber-01" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.1 -->
  <front>
    <title abbrev="ECDHE-Kyber">Post-quantum hybrid ECDHE-Kyber Key Agreement for TLSv1.3</title>
    <seriesInfo name="Internet-Draft" value="draft-kwiatkowski-tls-ecdhe-kyber-01"/>
    <author initials="K." surname="Kwiatkowski" fullname="Kris Kwiatkowski">
      <organization>PQShield, LTD</organization>
      <address>
        <email>kris@amongbytes.com</email>
      </address>
    </author>
    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization>AWS</organization>
      <address>
        <email>kpanos@amazon.com</email>
      </address>
    </author>
    <date year="2023" month="May" day="18"/>
    <workgroup>None</workgroup>
    <keyword>kyber</keyword>
    <keyword>post-quantum</keyword>
    <abstract>
      <t>This draft defines a hybrid key agreement for TLS 1.3 that combines
a post-quantum KEM with elliptic curve Diffie-Hellman (ECDHE).</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://post-quantum-cryptography.github.io/draft-kwiatkowski-tls-ecdhe-kyber/"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-kyber"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <section anchor="motivation">
        <name>Motivation</name>
        <t>Kyber is a key encapsulation method (KEM) designed to be resistant to cryptanalytic attacks with quantum computers. Standardization of Kyber KEM is expected to be finalized in 2024.</t>
        <t>Experimentation and early deployments are crucial part of the migration to post-quantum cryptography. To promote interoperability of those deployments this document provides specification of preliminary hybrid post-quantum key agreement to be used in TLS 1.3 protocol.</t>
      </section>
    </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>
    </section>
    <section anchor="negotiated-groups">
      <name>Negotiated Groups</name>
      <t>This document defines an additional supported group which can be used for
hybrid post-quantum key agreements. The hybrid key agreement for TLS 1.3 is
detailed in the <xref target="hybrid"/> draft. We compose the hybrid scheme with the Kyber
KEM as defined in <xref target="kyber"/> draft, and the ECDHE scheme parametrized with
elliptic curves defined in ANSI X9.62 <xref target="ECDSA"/> and NIST SP 800-186
<xref target="DSS"/>.</t>
      <t>The new group allows deriving TLS session keys by using FIPS-approved schemes.
NIST's special publication 800-56Cr2 <xref target="SP56C"/>
approves the usage of HKDF <xref target="HKDF"/> with two distinct shared secrets as long as the first
one is computed by a FIPS-approved key-establishment scheme. Both ECDHE and a curve
secp256r1 (NIST P-256) are FIPS-approved by NIST SP 800-56Ar3 <xref target="SP56A"/>
and NIST SP 800-186 <xref target="DSS"/> correspondingly.</t>
      <section anchor="construction">
        <name>Construction</name>
        <t>The name of the new supported hybrid post-quantum group is SecP256r1Kyber768Draft00.</t>
        <t>When this group is negotiated, the client's share is a fixed-size concatenation of
the ECDHE share and Kyber's public key. The ECDHE share is the serialized value of
the uncompressed ECDH point representation as defined in Section 4.2.8.2 of <xref target="RFC8446"/>.
The Kyber's ephemeral share is the public key of the KeyGen step (see <xref target="kyber"/>) represented
as an octet string. The size of client share is 1248 bytes.</t>
        <t>The server's share is a fixed-size concatenation of ECDHE share and Kyber's ciphertext
returned from encapsulation (see <xref target="kyber"/>). The server ECDHE share is the serialized
value of the uncompressed ECDH point representation UncompressedPointRepresentation as
defined in Section 4.2.8.2 of <xref target="RFC8446"/>. The server share is the Kyber's ciphertext
returned from the Encapsulate step (see <xref target="kyber"/>) represented as an octet string.
The size of server's share is 1152 bytes.</t>
        <t>Finally, the shared secret is a concatenation of the ECDHE and the Kyber
shared secrets. The ECDHE shared secret is the x-coordinate of the ECDH
shared secret elliptic curve point represented as an octet string as
defined in Section 7.4.2 of <xref target="RFC8446"/>. The Kyber shared secret is the
value returned from either encapsulation (on the server side) or decapsulation
(on the client side) represented as an octet string. The size of a shared secret is 64 bytes.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The same security considerations as those described in <xref target="hybrid"/> apply to the approach used by this document.
Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document requests/registers a new entry to the TLS Named Group
 (or Supported Group) registry, according to the procedures in
 <xref section="6" sectionFormat="of" target="tlsiana"/>. These identifiers are to be used with
 the point-in-time specified versions of Kyber in the third round
 of NIST's Post-quantum Project which is specified in <xref target="kyber"/>.
 The identifiers used with the final, ratified by NIST, version
 of Kyber will be specified later with in a different draft.
 [ EDNOTE: The identifiers for the final, ratified version of
 Kyber should preferrably by different that the commonly used
 <eref target="https://github.com/open-quantum-safe/openssl/blob/OQS-OpenSSL_1_1_1-stable/oqs-template/oqs-kem-info.md">OQS codepoints</eref> ]</t>
      <dl>
        <dt>Value:</dt>
        <dd>
          <t>0x639A</t>
        </dd>
        <dt>Description:</dt>
        <dd>
          <t>SecP256r1Kyber768Draft00</t>
        </dd>
        <dt>DTLS-OK:</dt>
        <dd>
          <t>Y</t>
        </dd>
        <dt>Recommended:</dt>
        <dd>
          <t>N</t>
        </dd>
        <dt>Reference:</dt>
        <dd>
          <t>This document</t>
        </dd>
        <dt>Comment:</dt>
        <dd>
          <t>Combining secp256r1 ECDH with pre-standards version of Kyber768</t>
        </dd>
      </dl>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="kyber">
          <front>
            <title>Kyber Post-Quantum KEM</title>
            <author fullname="Peter Schwabe" initials="P." surname="Schwabe">
              <organization>MPI-SPI &amp; Radboud University</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date day="31" month="March" year="2023"/>
            <abstract>
              <t>   This memo specifies a preliminary version ("draft00", "v3.02") of
   Kyber, an IND-CCA2 secure Key Encapsulation Method.

About This Document

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

   The latest revision of this draft can be found at
   https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg-
   schwabe-kyber.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/.

   Source for this draft and an issue tracker can be found at
   https://github.com/bwesterb/draft-schwabe-cfrg-kyber.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-cfrg-schwabe-kyber-02"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <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>
        <name>Informative References</name>
        <reference anchor="hybrid">
          <front>
            <title>Hybrid key exchange in TLS 1.3</title>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization>University of Waterloo</organization>
            </author>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Shay Gueron" initials="S." surname="Gueron">
              <organization>University of Haifa and Amazon Web Services</organization>
            </author>
            <date day="27" month="February" year="2023"/>
            <abstract>
              <t>   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.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository which contains
   the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-06"/>
        </reference>
        <reference anchor="tlsiana">
          <front>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
              <organization>Venafi</organization>
            </author>
            <author fullname="Sean Turner" initials="S." surname="Turner">
              <organization>sn3rd</organization>
            </author>
            <date day="27" month="March" year="2023"/>
            <abstract>
              <t>   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8447bis-04"/>
        </reference>
        <reference anchor="HKDF">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk">
              <organization/>
            </author>
            <author fullname="P. Eronen" initials="P." surname="Eronen">
              <organization/>
            </author>
            <date month="May" year="2010"/>
          </front>
          <seriesInfo name="RFC Editor" value="report"/>
          <seriesInfo name="DOI" value="10.17487/rfc5869"/>
        </reference>
        <reference anchor="ECDSA">
          <front>
            <title>Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
            <author>
              <organization>American National Standards Institute</organization>
            </author>
            <date year="2005" month="November"/>
          </front>
          <seriesInfo name="ANSI" value="ANS X9.62-2005"/>
        </reference>
        <reference anchor="DSS">
          <front>
            <title>Recommendations for Discrete Logarithm-based Cryptography:: Elliptic Curve Domain Parameters</title>
            <author fullname="Dustin Moody" initials="D." surname="Moody">
              <organization/>
            </author>
            <date year="2022"/>
          </front>
          <seriesInfo name="National Institute of Standards and Technology" value="report"/>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-186"/>
        </reference>
        <reference anchor="SP56C">
          <front>
            <title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title>
            <author fullname="Elaine Barker" initials="E." surname="Barker">
              <organization/>
            </author>
            <author fullname="Lily Chen" initials="L." surname="Chen">
              <organization/>
            </author>
            <author fullname="Richard Davis" initials="R." surname="Davis">
              <organization/>
            </author>
            <date month="August" year="2020"/>
          </front>
          <seriesInfo name="National Institute of Standards and Technology" value="report"/>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-56cr2"/>
        </reference>
        <reference anchor="SP56A">
          <front>
            <title>Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography</title>
            <author fullname="Elaine Barker" initials="E." surname="Barker">
              <organization/>
            </author>
            <author fullname="Lily Chen" initials="L." surname="Chen">
              <organization/>
            </author>
            <author fullname="Allen Roginsky" initials="A." surname="Roginsky">
              <organization/>
            </author>
            <author fullname="Apostol Vassilev" initials="A." surname="Vassilev">
              <organization/>
            </author>
            <author fullname="Richard Davis" initials="R." surname="Davis">
              <organization/>
            </author>
            <date month="April" year="2018"/>
          </front>
          <seriesInfo name="National Institute of Standards and Technology" value="report"/>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-56ar3"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VY63LbuBX+j6dAnR+1O6FsOY7jaNpuFcvZeHxTLKdpJpvZ
gUhIwpoiGQC0o3jyLn2WPlm/c0BKpGyvd7MzaxEEzuU737mAURQJb3yqe3KY
Ox99LVXmy7mcLcbWJPLocPDuKDpZjLWVJ3oh+1Or9VxnXk5yK69ORzfdzguh
xmOrb3rN3SJWXk9zu+hJk01yIZI8ztQcahKrJj66vjXKX+e37tpEPnWRjpOZ
jq7paJTiqPPCleO5cc7kmV8UOHh8dPVWymdSpS7vyQ2TJbrQ+F/mN57LjeP+
G/yBURvHl1dvN0RWziGrJxII6wnnVZb8qtI8g6CFdiLOM6czV7qe9LbUAta/
EKaw/Oj87s7O651dAWVWq57sXx71xW1ur6c2L4uePIccca0XWEp6QkaSDacf
RQNEcaOzEsqlrI4BLzwEbz5Cmsmm8md6RVuMn5Xjnpx5X7je9nZ47sT5fLsp
M4rtovD51Kpitth+EksIDmiuBD8qrVOpNPnTcreFUKWf5Za8ixBi4HjSkSer
E1iXMkT8xBp371Vupyoz35VHfMG996OZ0WnyXJ5eDfi9niuT9uQ1zv5LzfNs
Ol7AD8JjpXEIjWpeqExdG9dQOFRZ7tZftRX2P45aago6AkXqe56xEpHldo7N
NxxAdhoUjAadeGKnkYtnt2pcgyyI4o3dIXnCdqP9hNELi1GinZlmRIPUGZi3
tstO4oO9vVdjNvrdyeBtTw4ujjvdnU731d7Bq+3Lt4cvD/Zf4yWSbdTvsRP4
V+XwxrAcpybmXD1sxJbT1c+0fGsylcVGpXKk7Y2JtZPHWQLGU6ZeYcNRmprC
Q8RhaW+0HBiwgnbDaOVLq2U/RVqDKXO5ySZsbdQ2rBhR/QPkQHqurYlVJs8Z
epJFyahsQqodDC+9rs9wtkpk38uo260XHQQANWDckN0/Hx336P/yP687+7sR
nRFRFEk1hjMq9kJczcA7prJM9MRk8FXVhQ3JK9V6MZMoZkBJeQkGjOmAUK2M
lidHZ/IWzktdwxRXME0mRkfvsDyHq5tcCbc6gi2amyRJtUA1Oc68zZMyJiDw
/Eye5eAM4yJCkTVkIxmns1gVrkz5pZxrQJvITejfkoFCOpE+l2MtLR6pvnl6
5oQGrdIFGae8V/G1CybXPsC3ApBb11lGokoLmU9kVevhJ0zR3wod+6UmYKhS
8x3PJkOQdvfg4BG2WEMoBhEQKLWy6QJmFmm+oDeOyihMK5l4hbKeNBEd5wb8
5HPQ0EK6VZnkFd7afJ57DdWwPYdSNTap8YsgKne6pdBz7PO45Pji7I0BbNLB
HzMBHWt3C6tTM4dfdlFTo2VGmycBhtIFBGrGQLrP4zwFGojxYZ6h7pN8x2AM
iHqGn4mSmkVS43By4+zD6IqaF/2V5xf8+/Lo/Yfjy6MB/R6965+eLn+Iasfo
3cWH08Hq1+rk4cXZ2dH5IBzGqmwtiY2z/ie8Ias2LoZXxxfn/dMN8qSNFgUr
eMpYAyKigHICCMbWjIP3bw6H//tvd0/e3f0FRWm3233940f1cIBahYfbmc6C
tjwDH8Ijor4QqijAEZKi0lSC6FRjHPYiQrP8NpMzbTXg/NtnQuZLT/59HBfd
vX9WC+Rwa7HGrLXImN1fuXc4gPjA0gNqlmi21teQbtvb/9R6rnFvLBJrzjEs
eXRIYMsTgavLVx2UZQUDZkliqlLqyqLILZ3iEQMYm3gmqdrWPEVpE08SG6WA
mPlkbTTEAY+OGShAGXx3F04h3lxqO/Kj5hJDGelXQtExIS9UIloOUyLVGQQ9
OMcy7+64p9biAn/oAJfUWgxqCDq9t1yMSKZoF+SWSGoVoUvIz9yyvrDQ82Mw
aTSUBzs7UfdgX9zd/TQYjf5Rtdv9nd2DbdrSGQ071ZYfPzohhTN9WwEO/mKm
gTZrbmicI6Sc5qmVcHRyvEAc6M3b4+EoAvFRinQNh+sIUvHXqjBRceT+HcoT
aX25f2h3AcpPoyF+Pmocb/vxQ1TyHSNWOjXVVORojoAM+kNpySG4zWWCtmGy
2CPnkPKwScdIdUcBwaA8pb8kZmIspnFMvNQRquaRkF9qzSf4G2HUVPDAzZg7
wcuOfJNDZQggIa9CkAQUFrsv921XbnIwhhGetrj+tCVDWTNaL/f79kUNSv93
QME2AuV+sOUfCTactWiuRZ4lCGC66HDLRn3HgFH3cGYDqFg3NGLGKikfSrzA
G0A50vGQvedUeLV/MCDC7+xAzUeUylCUl7uzZYHgGirj1ABhYg4FL8wNE/NN
J5FDUsD0jG5gWd3oRCOF+ACBwoohIpCO4hfqQHOfCSSgGazq/TcqLXUtssyI
EUCJag2dg7PoGhhKaHE1FbQSEp7z6l5nt3PQ2SXsqsaxt8dJdlUXCBinC+KQ
pWLXNGhlcw09Zt6fAZvzupCbTutVKdlamaMTobiI5phrQFCUkGwavGbcICsg
u9LW3d07kOH2EeINLG7YtD8G/aOwxwaugSffvEDelZbQmWDKWZv91nypjGUb
fj9Soo6U/BOR+tDYNqQNl+uRFH8ikk1bW1Y+iQHzdYmDfjKs8oGwimZY70et
2325uwwsXYzSdBGSq1UQQ4DvRXWVUHWHCi2tXUzvJVRTKh36FsU5hkFo97op
ti1n/b6xFroH3X8kVK86e48FKsz+D5lZUWmNpmgk2L/G1jyrachBx9i9RZ9l
Et3YJepdda7xriei2UpSdd/M/b1lMJ+Rt6Wl2wGVa0gPt4xqAndUsF29I27t
CF0vXCca025jzEFXwjSLAZkc4BalMHPxsIU+1RqlO+J4XqQ8R+G+xY0NaOWl
RWPmSxVOSVNvqQxo3efIsiieqSzTaX2dey51NS6QHbMwaNGlNYx9ZJ8JxljN
V6Zwjm58fAntn/cfgKU5bFr9tUQnd9tWT2EL286tDS/t0neadc4BZVJ/xNpE
nEfL5seLFFUSYZFZKo6Z6dNaAKCLdVLCYUAsgHHN0X3OhPCBpCInAUXf+nB7
q6Fs3MZ4BAwyKTMik0XeUJDDfY+6Fk4xvMs7bjXAImA2kbA1SwS9rAay1tfQ
oc1/g2nVeG1cQ25zZO0I5mjTzqV11SiFIvNcEuoTs5prntfWiZV1twY3o3HT
AyqDNsiiixPGt8kE1yS6G/DgLeQvn+XRAJeRo949O+rvP+sWVIqpnS/TPy/T
hC7GkI5LNjgGM1fKmGqcu/l8zhc78lHIzxfvR1jDJZwi4L5sPvAlE9f2bPnt
0amJ5hXn0u1xmo+3ISG6wMJodPprl/6LeJrErq8u8hp5Agj44VrPI/og1Jkn
W/KXL0LIf1OB6gnZkzvf9l+87mNpwAlc8Ac/evHYwEVbweXo4oS3fcLzpSbv
6OtywmvnvMYIxEFLK2Hw9pD3e353yF+PiOirCZc7LgcPyEZu+QlsFQBZmxW+
Go2RsuL/cBI3YZ8XAAA=

-->

</rfc>
