<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-jhoyla-tls-extended-key-schedule-03" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title>TLS 1.3 Extended Key Schedule</title>
    <seriesInfo name="Internet-Draft" value="draft-jhoyla-tls-extended-key-schedule-03"/>
    <author initials="J." surname="Hoyland" fullname="Jonathan Hoyland">
      <organization>Cloudflare Ltd.</organization>
      <address>
        <email>jonathan.hoyland@gmail.com</email>
      </address>
    </author>
    <author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date year="2020" month="December" day="04"/>
    <area>Security</area>
    <workgroup>jhoyla</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>TLS 1.3 is sometimes used in situations where it is necessary to inject extra
key material into the handshake. This draft aims to describe methods for doing
so securely. This key material must be injected in such a way that both parties
agree on what is being injected and why, and further, in what order.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t>Discussion of this document takes place on the
  TLS Working Group mailing list (tls@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/tls/">https://mailarchive.ietf.org/arch/browse/tls/</eref>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/jhoyla/draft-jhoyla-tls-key-injection">https://github.com/jhoyla/draft-jhoyla-tls-key-injection</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Introducing additional key material into the TLS handshake is a non-trivial
process because both parties need to agree on the injection content and context.
If the two parties do not agree then an attacker may exploit the mismatch in
so-called channel synchronization attacks, such as those described by
<xref target="SLOTH" format="default"/>.</t>
      <t>Injecting key material into the TLS handshake allows other protocols to be bound
to the handshake. For example, it may provide additional protections to the
ClientHello message, which in the standard TLS handshake only receives
protections after the server's Finished message has been received. It may also
permit the use of combined shared secrets, possibly from multiple key exchange
algorithms, to be included in the key schedule. This pattern is common for Post
Quantum key exchange algorithms, as discussed in
<xref target="I-D.ietf-tls-hybrid-design" format="default"/>. In particular, <xref target="I-D.ietf-tls-hybrid-design" format="default"/> uses the
concatenation pattern described in this draft, but does not add the requisite framing.</t>
      <t>The goal of this document is to provide a standardised way for binding extra
context into TLS 1.3 handshakes in a way that is easy to analyse from a security
perspective, reducing the need for security analysis of extensions that affect
the key schedule. It separates the concerns of whether an extension achieves its
goals from the concerns of whether an extension reduces the security of a TLS
handshake, either directly or through some unforseen interaction with another
extension.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</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" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="injection" numbered="true" toc="default">
      <name>Key Schedule Extension</name>
      <t>This section describes two places in which additional secrets can be injected
into the TLS 1.3 key schedule.</t>
      <section anchor="handshake-secret-injection" numbered="true" toc="default">
        <name>Handshake Secret Injection</name>
        <t>To inject extra key material into the Handshake Secret it is recommended to
prefix it, inside an appropriate frame, to the <tt>(EC)DHE</tt> input, where <tt>||</tt>
represents concatenation.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                                 |
                                 v
                           Derive-Secret(., "derived", "")
                                 |
                                 v
  KeyScheduleInput || (EC)DHE -> HKDF-Extract = Handshake Secret
                                 |
                                 v
]]></artwork>
      </section>
      <section anchor="main-secret-injection" numbered="true" toc="default">
        <name>Main Secret Injection</name>
        <t>To inject key material into the Main Secret it is recommended to prefix it,
inside an appropriate frame, to the <tt>0</tt> input.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                           |
                           v
                     Derive-Secret(., "derived", "")
                           |
                           v
  KeyScheduleInput || 0 -> HKDF-Extract = Main Secret
                           |
                           v
]]></artwork>
        <t>This structure mirrors the Handshake Injection point.</t>
      </section>
    </section>
    <section anchor="key-schedule-injection-negotiation" numbered="true" toc="default">
      <name>Key Schedule Injection Negotiation</name>
      <t>Applications which make use of additional key schedule inputs MUST define a
mechanism for negotiating the content and type of that input.  This input MUST
be framed in a KeyScheduleSecret struct, as defined in <xref target="structure" format="default"/>.
Applications must take care that any negotiation that takes place unambiguously
agrees a secret. It must be impossible, even under adversarial conditions, that
a client and server agree on the transcript of the negotiation, but disagree on
the secret that was negotiated.</t>
    </section>
    <section anchor="structure" numbered="true" toc="default">
      <name>Key Schedule Extension Structure</name>
      <t>In some cases, protocols may require more than one secret to be injected at a
particular stage in the key schedule. Thus, we require a generic and extensible
way of doing so.  To accomplish this, we use a structure - KeyScheduleInput -
that encodes well-ordered sequences of secret material to inject into the key
schedule. KeyScheduleInput is defined as follows:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    KeyScheduleSecretType type;
    opaque secret_data<0..2^16-1>;
} KeyScheduleSecret;

enum {
    (65535)
} KeyScheduleSecretType;

struct {
    KeyScheduleSecret secrets<0..2^16-1>;
} KeyScheduleInput;
]]></artwork>
      <t>Each secret included in a KeyScheduleInput structure has a type and
corresponding secret data.  Each secret MUST have a unique
KeyScheduleSecretType. When encoding KeyScheduleInput as the key schedule Input
value, the KeyScheduleSecret values MUST be in ascending sorted order. This
ensures that endpoints always encode the same KeyScheduleInput value when using
the same secret keying material.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><xref target="BINDEL" format="default"/> provides a proof that the concatenation approach in <xref target="injection" format="default"/> is
secure as long as either the concatenated secret is secure or the existing KDF
input is secure.</t>
      <t>[[OPEN ISSUE: Is this guarantee sufficient? Do we also need to guarantee that a malicious prefix can't weaken the resulting PRF output?]]</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requests the creation of a new IANA registry: TLS KeyScheduleInput Types.
This registry should be under the existing Transport Layer Security (TLS) Parameters
heading. It should be administered under a Specification Required policy <xref target="RFC8126" format="default"/>.</t>
      <t>[[OPEN ISSUE: specify initial registry values]]</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">DTLS-OK</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD</td>
            <td align="left">TBD</td>
            <td align="left">TBD</td>
            <td align="left">TBD</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="BINDEL">
          <front>
            <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
            <author initials="N." surname="Bindel" fullname="Nina Bindel">
              <organization/>
            </author>
            <author initials="J." surname="Brendel" fullname="Jacqueline Brendel">
              <organization/>
            </author>
            <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
              <organization/>
            </author>
            <author initials="B." surname="Goncalves" fullname="Brian Goncalves">
              <organization/>
            </author>
            <author initials="D." surname="Stebila" fullname="Douglas Stebila">
              <organization/>
            </author>
            <date year="2019"/>
          </front>
          <seriesInfo name="Post-Quantum Cryptography" value="pp. 206-226"/>
          <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
        </reference>
        <reference anchor="SLOTH">
          <front>
            <title>Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH</title>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization/>
            </author>
            <author initials="G." surname="Leurent" fullname="Gaetan Leurent">
              <organization/>
            </author>
            <date year="2016"/>
          </front>
          <seriesInfo name="Proceedings 2016 Network and Distributed System Security" value="Symposium"/>
          <seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>
        </reference>
        <reference anchor="I-D.ietf-tls-hybrid-design" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-hybrid-design-01.txt">
          <front>
            <title>Hybrid key exchange in TLS 1.3</title>
            <author initials="D" surname="Steblia" fullname="Douglas Steblia">
              <organization/>
            </author>
            <author initials="S" surname="Fluhrer" fullname="Scott Fluhrer">
              <organization/>
            </author>
            <author initials="S" surname="Gueron" fullname="Shay Gueron">
              <organization/>
            </author>
            <date month="October" day="15" year="2020"/>
            <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-01"/>
        </reference>
        <reference anchor="I-D.friel-tls-eap-dpp" target="http://www.ietf.org/internet-drafts/draft-friel-tls-eap-dpp-01.txt">
          <front>
            <title>Bootstrapped TLS Authentication</title>
            <author initials="O" surname="Friel" fullname="Owen Friel">
              <organization/>
            </author>
            <author initials="D" surname="Harkins" fullname="Dan Harkins">
              <organization/>
            </author>
            <date month="July" day="13" year="2020"/>
            <abstract>
              <t>This document defines a TLS extension that enables a server to prove to a client that it has knowledge of the public key of a key pair where the client has knowledge of the private key of the key pair. Unlike standard TLS key exchanges, the public key is never exchanged in TLS protocol messages.  Proof of knowledge of the public key is used by the client to bootstrap trust in the server.  The use case outlined in this document is to establish trust in an EAP server.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-friel-tls-eap-dpp-01"/>
        </reference>
        <reference anchor="I-D.ietf-tls-semistatic-dh" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-semistatic-dh-01.txt">
          <front>
            <title>Semi-Static Diffie-Hellman Key Establishment for TLS 1.3</title>
            <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author>
            <author initials="N" surname="Sullivan" fullname="Nick Sullivan">
              <organization/>
            </author>
            <author initials="C" surname="Wood" fullname="Christopher Wood">
              <organization/>
            </author>
            <date month="March" day="7" year="2020"/>
            <abstract>
              <t>TLS 1.3 [RFC8446] specifies a signed Diffie-Hellman exchange modelled after SIGMA [SIGMA].  This design is suitable for endpoints whose certified credential is a signing key, which is the common situation for current TLS servers.  This document describes a mode of TLS 1.3 in which one or both endpoints have a certified DH key which is used to authenticate the exchange.  Note to Readers  Source for this draft and an issue tracker can be found at https://github.com/ekr/draft-rescorla-tls13-semistatic-dh (https://github.com/ekr/draft-rescorla-tls13-semistatic-dh).</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-semistatic-dh-01"/>
        </reference>
      </references>
    </references>
    <section anchor="potential-use-cases" numbered="true" toc="default">
      <name>Potential Use Cases</name>
      <t>The draft provides a mechanism for importing additional information into the TLS key schedule.
Future applications and specifications can use this mechanism to layer TLS on to other protocols, 
as opposed to layering other protocols over TLS. For example, as discussed in <xref target="intro" format="default"/>, this can 
be used for hybrid key exchange, which, in effect, is layering TLS over a secondary AKE. 
Although the key exchanges are interleaved, the post-quantum AKE completes first, as demonstrated 
by its output key being used as an input for computing TLS's master secret.</t>
      <t>This can also be used in more direct ways, such as bootstrapping EAP-TLS as in
<xref target="I-D.friel-tls-eap-dpp" format="default"/>. This draft also allows for more direct
implementations of things such as semi-static DH <xref target="I-D.ietf-tls-semistatic-dh" format="default"/>. The aim of this draft is to be
sufficiently flexible that it can be used as the basis for layering TLS on top
of any protocol that outputs a secure channel binding, where secure is defined
by the goals of the overall layered protocol. This draft does not provide
security itself, it simply provides a standard format for layering.</t>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>We thank Karthik Bhargavan for his comments.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJ1/yV8AA61ZbXPbNhL+jl+Bcz40mRFV23lrlWt7ru2M3TixGzvXucnk
GoiERNQkwRKgbZ3t/vZ7dgFSlOUknWk97YQSgcW+PLv7YJUkifDGF3oiz45O
5db4sdy/8rrKdCZf6YU8TXOdtYUWmU0rVWJZ1qiZT37L7aJQiS9couP65Fwv
EhfXJ5uPRaq8nttmMZHOZ0KYuplI37TOb29ufru5LVSj1USe6rRtjF+IS9uc
zxvb1hMZpAsIxJfZRB5WXjeV9skeHS6E86rKflWFraDQQjtRm4l87206ks42
vtEzh6dFSQ8fhFCtz20zEVIm+F9KU7mJ/GksD+iUKuPvgnE/2Ur5XFUrr2wz
V5X5n/LGVhO5W9g2mxVQXh75bMwrdKlMAbXj7nEedv9rTt+PU1uuHr07ljtj
+Yu1w6N388Y4b+tcNytvP3X68OBUXf4r16o21XxqvBvDVUJUtimx60KT4W9f
7m5vbX07QRiq2fIF3vx4+GZv/2gi944Px1ub+G/z+dffPv8meYwQbibbT59u
bSbPf93aFkIkSSLV1PlGpZDf4cU4OL3U3pTaydYBOKaSzviWVXbyEhZpaTwt
rHSqnVPNQnqLZb/p1Evgp+FYS2ilG6MKvMFrn2sJZ2YuV+d6LM9y7GfwSWVK
RwIy7dLGTLXE6bnNnIRlMrPwgnBWOgKWLhZx68oBJVAosTGoEFVu01wqeamg
XK7w2vpc1qrxBgBT80ZraStYo9iSqcYxy/3QE68WI36YtQ2Ub0YkldcDxLoZ
BweWJsuQT+IBobqxWZuSm+T1A0Mfb4Xovib5KssMvYbK9zuIgtA7ifRSsrJV
4htzgXWibiw5HNqmCqFZsQnBgOKQ09tGAoNFpFFqkXWVZ4v4+cqPxeGMV/lL
24vJLI70UQpeVtghlfcqPQeUS7hTX9WFBQBoZ2kcrICnTYUgJakqCmiRwoZK
F8jZKs0b2+E9iqFk5uAg6rmFGV3gMzldiOvrH06Pjs8OvusQ/OT59vbXcIkb
b29uPRtvP36y9c3t7Zg8y7bBr3/GmdDMXjppKZQSjkR5sQXjbkqObFEd1lH6
EgjUV6qsCz0izJP52HthMj0MJokLbmaBECJ2CwNvH2icCjwjSeaQcJkbdhUf
w1VPNdkdPW1VLGSDxEJGOzGUjFyB6rxVNxe6+crJl6YyDiW6OwJyCB0IWpSQ
jeVhUFsVzopaN2WMHOHHzgCFcmoqSMDpDf2j00Z7hKi2zpkpdJk1tkSGFd7A
C+xqfUUBnmuhCjQE4/MS64MjTZUWbRYykE6h5V0TiZlbAwUo/4RuHF4CFpTn
J9Z58XOrKt+WK4fI4SGwLjMubV2oSwSWw2RvbLSfcfPKF9PGZAkAZeYVQIKk
DMBOWxTZkfzCenKK4/AhQ6jfVQG3ncpLoLJ5XQUbyWnrkTiUhJQ6Wca2N/r3
1qByarhQlcApMHuG7+cWkLGzKMCmbUl5aRg6Pbh6eBgylaoYeQmhygjwocjG
NA6I7+p3jyRHSg4KIA7QynGpVgDtwukQWhVKK/VswMPVBLcLgBVoCFWLbOHi
Qhp0a6MMCIUlzBlcgD8dpWYzSBHrAAAWnUZA4Fr2M1WiFJ5lKegsnJyoN71A
qdLc6AsyxjtBnnNB6z+1mU2IJ/WKY7Eib4neUyOpDW/ODNLGA/OW8gzkZZ5z
M5QtdVlHeWWIu6hQUi+xCwdySRH9qWNqBru2ukBUQ96i4u7pGVKVPwcQkF+I
DTm58frd6dnGKPwr3xzz89v9n98dvt3fo+fTg52jo/6hW3F6cPzuCO9FfFru
3D1+/XofLIA341t556vXO//ZCJ1t4/jk7PD4zc7RRgdo0eORGFGX0zC5RlWg
xuhWk+DH3RO59QR5FRkJcuj6+h/48M3W8ye3twJhqcJZXNfCR/gL+KlrrRrG
aFGA8tTGI7ic4i63l5UknsG+HBLXQGdd12Jjc7slnxJxib2uU9GFzlaoNGRD
qL+Dwh2rHY6vhvxBrPQQyqoVGEOpB/Kgr9inLEQedtpAmVU29In+tCYhkCpA
EGUxcHaPkg3Wa67wjviH49pQkfMaW0NcLC56FPuO/Phwf/fR3sH+R6yuWz+K
fO3jzc1H0WgIcwiukyv1DQb98ccfzEA/+3fz5SUXn1uyBwdc6CRY+3AMKGb8
TUao3Hj0tykAwHR4OSQnyJsbGd0ik+/lwau9l8n+FfNe+d1aGP4mNcijhJPX
CsD7HETuB8dw2324kEtciD+Fi82IiC8H+7PmfSLAfyG0XzzuvnBu3hPIgcv+
wnkct1BNcLtNPS4dYLlNg/p/J2v7aIIrIW7rtWq54A1uzt6oEPqdui5M2l+n
qCSVJC8ysjuXhK7qhOg5yV0io3aCiItSE0sCCefmXHXHxK495Px+UevAOogL
MBJkIGT8geWKaYRNFrjDwPMRisEngYixDrzy+rr3FTHzFQP5bubJvpRbCvOD
arHUlW8qKqxxoVij3yrQ0nlrW1cswm3NBaICJQKl7a58ZSSq1MXRcrE1IxqQ
gSDjZko5BS8EjxJLxUlCyZTZOfslcOnVWxMQVVEHqX3wmB5qG9mecd0WEekF
+YctuVSu3wAG/pkedtpD7PrB0oV0tQm8I1UgpKPBdYWYPPNKQqUN/qygw1IB
u3IRJmeLJQMmVjnXnyLnLY661L18Jee6Qhan7KfIb+BoQZQSfuGrOfQkHIFT
pihPiLvLmUiwJEK0GuQR7stryUwTK3KarlKLvo1tRZHwDZtvI7+3eKGZ4kUL
+1q5nDn0VRMWiaVFa2eZJWoVjRf4SjgJBTFoKa+5OqwB/4yyh1LoRZji1AqK
RY1+zZRX/9wcj7f/u/Us2fr+hbhdF/BCCF3hahPkP3z29Onjp4/uW3jGh3xB
nY64fPpUNvhFqGb7INGd94YXNLXuoWWs6CapQtWgyVlqG3CH2ob7RxRGhiP6
Q/lcnnJ1QYFvKwMviXtNHMtfaLbAUSeJa5oot4ZRyW/EhSpazSzyHsfwy1gl
OREgKNVRa9tQToTxDdc+xMTB2HhtwTKu5DC8AMZdxGS4PqAqrivJpzGrBdZp
UNUvje6A+nRyh1muBd2IlC4J1LgbFe8F78Pw7kN3C6QA4LEr2t2VZ3kv5Xav
wkjh+npJh2+BdBEGZuTHwtLsyXW3nFU5/Z1fBgJNe2xYpK+M416CPitMl0Fh
DSx5//74ZP+NPDw9fbc/kYcuXGjnLa53aDtwQTubmZQK7Q9yz1I9oBlEP6da
Lgw9AU5C1zAo+R23ASv/CtVUozFU8UbtaA4BjU7evpS29VDphw8fePq282Zn
zaFnKzdsqmva+XjxbHTwIV8HK30ZJDR6DptpyE3Mfy3ehFw3DnK7pXRdaYuM
0BZ6z4rrzqiV1ACePFILvOyD/xAHPJInitotwOFErhWhNFySe5EqK2nG47kc
xt4mT3FJN7PYYuXbUK8z0BA4cNFfwLaf8ZhsNUyOty4k30ZRRHsrQuKQM2/k
vxnW8ga0LrRBOiaQJ7kHvZPjV3h6q2fQCtUZlOpmkoS//mH5t/xq+BJ75NmP
e0FofBiQtP6r4cubMHOdqvScYn5iid2QFe/QaHapV4bLdZgrD7JolSYRZ2j8
nYFsP0i31eoIcfXq97Ll6qiGFIdpxDAk4UJJ3Y9TYnk6xBYMAxJMZMPeHUiO
pECm2hqsJqQJrydd704u7UWQc2dKeWdExnWBJtG3o6AMaUY8j0f75I0wA1uZ
ucVJJU+8Nc9yRpT5vSqsPbMmqgaW5lQLufNqfyzFTuFznpt0xbuT6XiiwLOE
QqM/ZKGCw06f/B7nfhAhmUVomg/NTOM6qlnCqb7haiWmCxoGxfTnM8L0ni2i
rlVFSkvWkbjWR6W/IgJFudQxyVgiyCdcmzq/wG5mV2EgRDO0wdB6aq0nZWr6
gUbu75wk5A/lBgPJWWN0EX5OU3WS1TXNIoc/edBhcSJNWg4OE4bsp4IVoRQm
hdXc9Qo4XZrE0ftU7h2sDTXpdXibZHk4WNOPLMuZI+tg4vBbLOs0TXsLlC6Q
vHhP8N1opHMuxWyqaO5Heq8igvBcCyqo1aIHahAUguW6YaPufyKIE81uThHf
LokaRdvHoanr2Dhhj6ZGfDwVvnjWio/7eWysA6KfAAI9upjxQN+RtxfDUtGP
5UM5WDGT2/dOel7Zy0JncwqSE9cT8Lop6fHdxgxK6o1b8Usg5ufyFah3bs7l
j7lq5upChWF3HmfftH8s/g+OL4e7tR0AAA==

-->

</rfc>
