<?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-00" 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-00"/>
    <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="17"/>
    <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 secp256r1_kyber768_d00.</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>0x6400</t>
        </dd>
        <dt>Description:</dt>
        <dd>
          <t>secp256r1_kyber768_d00</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+1OyEtKbLjaNputZa80fimWE7TTDaT
gUhIwpoiGQC0o3j8Ln2WPlm/A5ASKTvr3ezMWgSBc/nOdy5gEATMKpvIHh9n
xgZfC5HaYskXq6lWMR8eD94Og9PVVGp+Kle8P9dSLmVq+SzT/PpsctsOXzEx
nWp526vvZpGwcp7pVY+rdJYxFmdRKpZQE2sxs8HNnRL2JrszNyqwiQlkFC9k
cENHgwRHjWWmmC6VMSpL7SrHwdHw+oTzF1wkJuvxHZXGMpf4X2p3XvKdUf9n
/IFRO6Or65MdlhZLyOqxGMJ6zFiRxl9EkqUQtJKGRVlqZGoK0+NWF5LB+ldM
5do9Gttptd60OgzKtBQ93r8a9tldpm/mOivyHr+AHHYjV1iKe4wH3BlOP/Ia
iOxWpgWUc14eA1548N58gDSVzvkv9Iq2KLsopj2+sDY3vf19/xxG2XK/LjOI
9Cq32VyLfLHafxZLCPZobgT/UFpYqlTZ83L3GROFXWSavAsQYuB4GvLTzQms
c+4jfqqVefQq03ORqu/CIr7g3rvJQskkfsnPrgfuvVwKlfT4Dc7+SyyzdD5d
wQ/CY6NxDI1imYtU3ChTUzgWaWa2XzUV9j9MGmpyOgJF4nuWOiUszfQSm29d
AJ3ToGAwCKOZngcmWtyJaQUyI4rXdvvk8duVtDOHnl8MYmnUPCUaJEbBvK1d
ehYddbuvp87ot6eDkx4fXI7Cditsv+4evd6/Ojk+ODp8g5dItkm/55zAvzKH
d8bFNFGRy9XjWmxdutqF5CcqFWmkRMInUt+qSBo+SmMwnjL1GhuGSaJyCxHH
hb6VfKDACtoNo4UttOT9BGkNpiz5rjNhb6eyYcOI8h8gB9JLqVUkUn7hoCdZ
lIxCx6TawPDCyuqMy1aO7DsI2u1q0UAAUAPGNdn9i8moR//n/3kTHnYCOsOC
IOBiCmdEZBm7XoB3jso8ljOVwldRFTYkLxfbxYyjmAElYTkYMKUDTDQymp8O
z/kdnOeygikqYZrNlAzeYnkJV3ddJdwLmbNoqeI4kQzVZJRancVFREDg+QU/
z8AZhwvzRVaRjWScTCORmyJxL/lSAtqY70L/HvcUkjG3GZ9KrvFI9c3Ss0to
0CpZkXHCWhHdGG9y5QN8ywG5NuE6EmVa8GzGy1oPP2GK/JbLyK41AUORqO94
VimC1OnCwSG2aEUoehEQyKXQyQpm5km2ojeGyihMKxzxcqEtaSI6LhX46c5B
QwPpRmXi13irs2VmJVTD9gxKxVQlyq68qMzIhkLrYp9FhYsvzt4qwMYN/FEz
0LFyN9cyUUv4pVcVNRpmNHniYSiMR6BiDKTbLMoSoIEYH2cp6j7JNw6MAVFP
uWeipHQiqXEYvnP+fnJNzYv+8otL9/tq+O796Go4oN+Tt/2zs/UPVu6YvL18
fzbY/NqcPL48Px9eDPxhrPLGEts573/EG7Jq53J8Pbq86J/tkCdNtChY3lOH
NSAiCgjDgGCk1dR7//Px+H//bXf5/f1fUJQ67fabh4fy4Qi1Cg93C5l6bVkK
PvhHRH3FRJ6DIyRFJAkH0anGGOxFhBbZXcoXUkvA+bdPhMznHv/7NMrb3X+W
C+RwY7HCrLHoMHu88uiwB/GJpSfUrNFsrG8h3bS3/7HxXOFeWyTWXGBYsuiQ
wNZNBKYqX1VQ1hUMmMWxKkupKfI803TKjRjAWEULTtW24ilKG3uW2CgFxMxn
a6MiDlh0TE8ByuD7e38K8XalNuQfpCsxlJF2IxQdE/J8JaJlPyVSnUHQvXNO
5v2966mVOM8fOuBKaiUGNQSd3mpXjEgmaxbkhkhqFb5L8E+uZX12Qi9GYNJk
zI9araB9dMju738aTCb/KNvtYatztE9bwsk4LLc8PIQ+hVN5VwIO/mKmgTat
bmmcI6SMdFMr4Wj4dIU40JuT0XgSgPgoRbKCw4SMVPy1LExUHF3/9uWJtB4c
HusOQPlpMsbPHxrntj08sFK+cYgVRswlFTmaIyCD/lBauhDcZTxG21BpZJFz
SHnYJCOkuqGAYFCe018SM1Ma0zgmXuoIZfOIyS+x5RP8DTBqCnhgFo473suQ
/5xBpQ8gIS98kBgU5p2DQ93muy4Y4wBPe67+NCVDWT1aB4d9/aoCpf87oGAb
gfI42PyPBBvOajTXPEtjBDBZha5lo75jwKh6uGMDqFg1NGLGJimfSjzPG0C5
9v6LY/zrw6MvcasFJR9QKH1JXu9N1+XBVVAeJQr4Em8odH5qmKlvMg4MUgKG
p3T/Sqs2x2oJ5A4QJC4DIcJTjqLnq0B9n/IUoAms7Py3IilkJbJIiQ/AiCoN
nYOr6BkYSWhxMxM00nEiHXa8G3bCo7BDyJVto9t1KXZdlQcYJ3NikKZSVzdo
Y3MFPCbeXwCbsTLnu0bKTSHZ25gjYyZcCc0w1YCeKCDp3HvtcIMsj+xGW7vT
PeL+7uGjDSxunWl/DPofwh4puAaWfLMMWVdoQmeGGWdr8tvypTTW2fD7kWJV
pPifiNT72rYxbbjajiT7E5Gs29qw8lkMHF/XOMhnw8qfCCurh/Vx1Nrtg846
sHQtSpKVT65GOfQBfhTVTUJV/ck3tGYpfZRQdal06FsQZRgFod3KutimnO3b
xlbonnT/B6F6HXZ/FCg/+T9lZkmlLZqijWD/FluztKKhCzqG7j36KBPL2i5W
7apyze16JpqNJBWPzTzsroP5grwtNN0NqFhDur9jlPO3oXJtqh1RY4fvef4y
UZt1a0MOehJmWYzH5IBrUAITlxu10KUag3TIRss8cVMUbluurQGtrNBoy+5K
hVNcVVtKAxq3ObIsiBYiTWVSXeZeclkOC2THwo9ZdGX1Qx/Zp7wxWroLkz9H
9z13Be1f9J+ApT5qavm1QB83+1rOYYuz3TU2vNRr32nSuQCUcfUJaxdxnqxb
n1ukqJIIjcwSUeSYPq8EALpIxgUcBsQMGFccPXSZ4D+PlOQkoOhLH+5uFZS1
u5gbAL1MyoxApYFVFGR/26OuhVMO3vUNtxxfETAdc9iaxoxeluNY41voWGe/
wbRyuFamJrc+sIbMcbRu59q6cpBCkXnJCfWZ2kw1Lyvr2Ma6O4V70bTuAZVB
7WXRtQnD22yGSxLdDNzYzfivn/hwgKvIsPfIjurrz7YFpWJq5+v0z4okpmsx
pOOKDY7BzI0yRzWXu9ly6a515CPjny7fTbCGKzhFwHzefeI7Ji7t6frLoxEz
6VaMSfanSTbdh4TgEguTydmXNv0XuFkSu76awErkCSBwDzdyGdDnoHAZ7/Ff
PzPG/00Fqsd4j7e+HXZbLSwNXALn7nMfvXh63KKNYHJweeo2fcTzlSTf6Mty
7NYu3JrzP/I6GumCt8duv3Xvjt2XI6L5Zrp1/daFDrgGZv35awO/Rx82+S9G
UyQs+z/V93EImxcAAA==

-->

</rfc>
