<?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.2.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-rescorla-tls13-semistatic-dh-00" category="std">

  <front>
    <title abbrev="TLS 1.3 Semi-Static KX">Semi-Static Diffie-Hellman Key Establishment for TLS 1.3</title>

    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
      <organization>Cloudflare</organization>
      <address>
        <email>nick@cloudflare.com</email>
      </address>
    </author>

    <date year="2018" month="March" day="05"/>

    <area>General</area>
    <workgroup>TLS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>TLS 1.3 <xref target="I-D.ietf-tls-tls13"/> specifies a signed Diffie-Hellman
exchange modelled after SIGMA <xref target="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.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>DISCLAIMER: This is a work-in-progress draft and is currenty totally
handwavy, so it has not yet seen significant security analysis. It
should not be used as a basis for building production systems.</t>

<t>TLS 1.3 <xref target="I-D.ietf-tls-tls13"/> specifies a signed Diffie-Hellman
exchange modelled after SIGMA <xref target="SIGMA"/>. This design is suitable for
endpoints whose certified credential is a signing key, which is the
common situation for current TLS servers, which is why it was
selected for TLS 1.3.</t>

<t>However, it is also possible – although currently rare – for
endpoints to have a credential which is an (EC)DH key. This can happen
in one of two ways:</t>

<t><list style="symbols">
  <t>They may be issued a certificate with an (EC)DH key, as specified
for instance in <xref target="I-D.ietf-curdle-pkix"/></t>
  <t>They may have a signing key which they use to generate a delegated
credential <xref target="I-D.ietf-tls-subcerts"/> containing an (EC)DH key.</t>
</list></t>

<t>In these situations, a signed DH exchange is not appropriate, and
instead a design in which the server authenticates via its long-term
(EC)DH key is suitable. This document describes such a design modelled
on that described in OPTLS <xref target="KW16"/>.</t>

<t>This design has a number of potential advantages over the signed
exchange in TLS 1.3, specifically:</t>

<t><list style="symbols">
  <t>If the end-entity certificate contains an (EC)DH key, TLS can
operate with a single asymmetric primitive (Diffie-Hellman).
The PKI component will still need signatures, but the TLS stack
need not have one. Note that this advantage is somewhat limited
if the (EC)DH key is in a delegated credential, but that allows
for a clean transition to (EC)DH certificates.</t>
  <t>It is more resistant to random number generation failures on
the server because the attacker needs to have both the server’s
long-term (EC)DH key and the ephemeral (EC)DH key in order to
compute the traffic secrets. [Note: <xref target="I-D.cremers-cfrg-randomness-improvements"/>
describes a technique for accomplishing this with a signed exchange.]</t>
  <t>If the server has a comparatively slow signing cert (e.g., P-256)
it can amortize that signature over a large number of connections
by creating a delegated credential with an (EC)DH key from
a faster group (e.g., X25519).</t>
  <t>Because there is no signature, the server has deniability for
the existence of the communication. Note that it could always
have denied the contents of the communication.</t>
</list></t>

<t>This exchange is not generally faster than a signed
exchange if comparable groups are used. In fact, if delegated
credentials are used, it may be slower on the client as it has
to validate the delegated credential, though this operation
is cacheable.</t>

</section>
<section anchor="protocol-overview" title="Protocol Overview">

<t>The overall protocol flow remains the same as that in ordinary TLS 1.3,
as shown below:</t>

<figure><artwork><![CDATA[
       Client                                               Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*         -------->
                                                       ServerHello  ^ Key
                                                      + key_share*  | Exch
                                                 + pre_shared_key*  v
                                             {EncryptedExtensions}  ^  Server
                                             {CertificateRequest*}  v  Params
                                                    {Certificate*}  ^
                                              {CertificateVerify*}  | Auth
                                                        {Finished}  v
                                 <--------     [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}                -------->
       [Application Data]        <------->      [Application Data]
]]></artwork></figure>

<t>As usual, the client and server each supply an (EC)DH share in their
“key_share” extensions. However, in addition, the server supplies a
static (EC)DH share in its Certificate message, either directly in
its end-entity certificate or in a delegated credential. The client
and server then perform two (EC)DH exchanges:</t>

<t><list style="symbols">
  <t>Between the client and server “key_share” values to form an
ephemeral secret (ES). This is the same value as is computed
in TLS 1.3 currently.</t>
  <t>Between the client’s “key_share” and the server’s static
share, to form a static secret (SS).</t>
</list></t>

<t>Note that this means that the server’s static secret MUST be in
the same group as selected group for the ephemeral (EC)DH exchange.</t>

<t>The handshake then proceeds as usual, except that:</t>

<t><list style="symbols">
  <t>Instead of containing a signature, the CertificateVerify contains
a MAC of the handshake transcript, computed based on SS.</t>
  <t>SS is mixed into the key schedule at the last HKDF-Extract
stage (where currently a 0 is used as the IKM input).</t>
</list></t>

</section>
<section anchor="negotiation" title="Negotiation">

<t>In order to negotiate this mode, we treat the (EC)DH MAC as if it were a
signature and negotiate it with a set of new signature scheme values:</t>

<figure><artwork><![CDATA[
   enum {
     sig_p256(0x0901),
     sig_p384(0x0902),
     sig_p521(0x0903),
     sig_x52219(0x0904),
     sig_x448(0x0905),
   } SignatureScheme;
]]></artwork></figure>

<t>When present in the “signature_algorithms” extension or
CertificateVerify.signature_scheme, these values indicate DH MAC with
the specified key exchange mode. These values MUST NOT appear
in “signature_algorithms_cert”.</t>

<t>Before sending and upon receipt, endpoints MUST ensure that the
signature scheme is consistent with the ephemeral (EC)DH group
in use.</t>

</section>
<section anchor="certificate-format" title="Certificate Format">

<t>Like signing keys, static DH keys are carried in the Certificate
message, either directly in the EE certificate, or in a delegated
credential. In either case, the OID for the SubjectPublicKeyInfo
MUST be appropriate for use with (EC)DH key establishment. If
in a certificate, the key usage and EKU MUST also be set appropriately
See <xref target="I-D.ietf-curdle-pkix"/> and [[TBD: P-256, etc.]] for specific
details about these formats.</t>

</section>
<section anchor="cryptographic-details" title="Cryptographic Details">

<section anchor="certificate-verify-computation" title="Certificate Verify Computation">

<t>Instead of a signature, the server proves knowledge of the private
key associated with its static share by computing a MAC over the
handshake transcript using SS. The transcript thus far includes all
messages up to and including Certificate, i.e.:</t>

<figure><artwork><![CDATA[
Transcript-Hash(Handshake Context, Certificate)
]]></artwork></figure>

<t>The MAC key – SS-Base-Key – is derived from SS as follows:</t>

<figure><artwork><![CDATA[
    SS-Base-Key = HKDF-Extract(0, SS)
]]></artwork></figure>

<t>The MAC is then computed using the Finished computation described
in <xref target="I-D.ietf-tls-tls13"/> Section 4.4, with SS-Base-Key as the
Base Key value. Receivers MUST validate the MAC and terminate
the handshake with a “decrypt_error” alert upon failure.</t>

<t>Note that this means that the server sends two MAC computations in
the handshake, one in CertificateVerify using SS and the other in
Finished using the Master Secret. These MACs serve different
purposes: the first authenticates the handshake and the second proves
possession of the ephemeral secret.
[[OPEN ISSUE: Verify that this is OK because neither MAC is computed
with the mixed key. At least one version of OPTLS was somewhat like that,
however.]]</t>

</section>
<section anchor="key-schedule" title="Key Schedule">

<t>The final HKDF-Extract stage of the TLS 1.3 key schedule has
an HKDF-Extract with the IKM of 0. When static key exchange
is negotiated, that 0 is replaced with SS, as shown below.</t>

<figure><artwork><![CDATA[
...
           Derive-Secret(., "derived", "")
                 |
                 v
     SS -> HKDF-Extract = Master Secret
                 |
                 +-----> Derive-Secret(., "c ap traffic",
                 |                     ClientHello...server Finished)
                 |                     = client_application_traffic_secret_0
                 |
...
]]></artwork></figure>

</section>
</section>
<section anchor="client-authentication" title="Client Authentication">

<t>[[OPEN ISSUE]] In principle, we can do client authentication the same way,
with the client’s DH key in Certificate and a MAC in CertificateVerity.
However, it’s less good because the client’s static key doesn’t get mixed
in at all. Also, client DH keys seem even further off.</t>

</section>
<section anchor="rtt" title="0-RTT">

<t>[[OPEN ISSUE]] It seems like one ought to be able to publish the server’s
static key and use it for 0-RTT, but actually we don’t know how to
do the publication piece, so I think we should leave this out for now.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>[[OPEN ISSUE: This is a -00, so the security considerations are kind of sketchy.]]</t>

<t><list style="symbols">
  <t>This is intended to have roughly equivalent security properties to current TLS 1.3,
except for the points raised in the introduction.</t>
  <t>There are open questions about how much key mixing we want to do, especially with
respect to client authentication.</t>
  <t>I’m not sure I like the double extract of SS. I’ve looked it over and
the SS-Base-Key and the HKDF-Extract to make the MS should be independent,
but I’d like to give it another look-over to see if there is a cleaner
way to do it.</t>
</list></t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>IANA [SHOULD add/has added] the new code points specified
in <xref target="negotiation"/> to the TLS 1.3 signature scheme registry, with
a “recommended” value of TBD.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<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="I-D.ietf-tls-tls13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='March' day='4' 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></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-26' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-26.txt' />
</reference>



<reference anchor="I-D.ietf-curdle-pkix">
<front>
<title>Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure</title>

<author initials='S' surname='Josefsson' fullname='Simon Josefsson'>
    <organization />
</author>

<author initials='J' surname='Schaad' fullname='Jim Schaad'>
    <organization />
</author>

<date month='November' day='14' year='2017' />

<abstract><t>This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves.  The signature algorithms covered are Ed25519 and Ed448.  The key agreement algorithm covered are X25519 and X448.  The encoding for Public Key, Private Key and EdDSA digital signature structures is provided.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-curdle-pkix-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-07.txt' />
</reference>



<reference anchor="I-D.ietf-tls-subcerts">
<front>
<title>Delegated Credentials for TLS</title>

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

<author initials='S' surname='Iyengar' fullname='Subodh Iyengar'>
    <organization />
</author>

<author initials='N' surname='Sullivan' fullname='Nick Sullivan'>
    <organization />
</author>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='October' day='30' year='2017' />

<abstract><t>The organizational separation between the operator of a TLS server and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms.  This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking compatibility with clients that do not support this specification.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-subcerts-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-subcerts-00.txt' />
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="SIGMA" >
  <front>
    <title>SIGMA: the 'SIGn-and-MAc' approach to authenticated Diffie-Hellman and its use in the IKE protocols</title>
    <author initials="H." surname="Krawczyk">
      <organization></organization>
    </author>
    <date year="2003"/>
  </front>
  <seriesInfo name="Proceedings of CRYPTO 2003" value=""/>
</reference>
<reference anchor="KW16" target="https://eprint.iacr.org/2015/978">
  <front>
    <title>The OPTLS Protocol and TLS 1.3</title>
    <author initials="H." surname="Krawczyk">
      <organization></organization>
    </author>
    <author initials="H." surname="Wee">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
  <seriesInfo name="Proceedings of Euro S&quot;P 2016" value=""/>
</reference>




<reference anchor="I-D.cremers-cfrg-randomness-improvements">
<front>
<title>Randomness Improvements for Security Protocols</title>

<author initials='C' surname='Cremers' fullname='Cas Cremers'>
    <organization />
</author>

<author initials='L' surname='Garratt' fullname='Luke Garratt'>
    <organization />
</author>

<author initials='S' surname='Smyshlyaev' fullname='Stanislav Smyshlyaev'>
    <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='1' year='2018' />

<abstract><t>Randomness is a crucial ingredient for TLS and related security protocols.  Weak or predictable "cryptographically-strong" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes.  The Dual EC random number backdoor and Debian bugs are relevant examples of this problem.  This document describes a way for security protocol participants to mix their long- term private key into the entropy pool(s) from which random values are derived.  This augments and improves randomness from broken or otherwise subverted CSPRNGs.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-cremers-cfrg-randomness-improvements-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-cremers-cfrg-randomness-improvements-00.txt' />
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAKmynVoAA+VabXMbtxH+jl+BqjO15fBoSbbTmGnayJIScRTZGlNp0vE4
GvAOJK+6O1yAO9GMo/72PrvAvYlMJ87XcjKOdDwA+/Ls7rMLRVEkqrTK9ETO
dJ5Gs0pVaSxP08Ui1dG5zrJcFfJCb+SZq9Q8S90q10UlF8bK6+9m8nD8TKj5
3Oq7SfP7YKOLH0Vi4kLlOCCxalFFVrvY2ExFVeYOn0UOLzt+N0pW0cGBiFWl
l8ZuJtJViRBpaSeysrWrjg4OXh4cCWW1mshvdaGtysTa2NulNXXpj/8Bv6bF
Un5Lj8St3uD7ZCKnRaVtoavolEQQAgcWyY3KTAGxNtqJMp3Id5WJR9IZW1m9
cPhpk9MP74VQdbUydiJkJCQ+aeEm8mws3wZN+KFX8cxC58FzY5eqSH+BgqaY
yEvzS5qFb3Su0mwi9a392laLfBybfHDC67Gc1VmW3qmid8LrNL4dPh+ecJKZ
OllksFL/kAKrvo7br/gsIQpjcyy701BNvv3m5Ojw8OUEJi8W/S9m028vjye8
Gz4BLHv+qaxWWj7Cz0UEi0aXx/EjqcrSGhWvZGUkWQ5wScmpyUNUYYVMKydr
p6ExbzW9OJNYDU+YzO01Z7b295+o+SEY6nwsL6xax79sbptvnLapdqTIRF5Z
E2udABZOmoU8efuvq+s3Emh61rydQLpJ8+Tih8PPt7S9hmxvrghhV0E6lj4g
fu/hRoef/w5Bzmpr5OwvP9em+vJqsKhSdqmriVxVVekmT5/q0qZFNU5VbMfw
9lO8++Lpy79+8cfts+OVH7QGJEQURVLNXWVVjEBpQvrjxz9No9NxqqsFxa2P
3ft76Uodp/Cpk0q6dFlsOVnoD/FKFUstc5PgEV5ABGrrUYV9+f/392N5vUqd
TDTtIvGTq1PKN5oyjdBFUhqYwMn1ygAtsbYVHZvI2OqEAKYyWuSFoASA0B/h
5RQwxHNASwDyuSnwQlVzqHAKi2trKZ2RnnDVnbaukcTENWc6iBTbdI4koVgH
cl1jFqDWn4FEgjiUc1OtZCfsSt1pyNRKK07PSbBOLiA/eRgmHAeN1cbeIXma
JBnc82fKZNYkdUwaCHE6nZ18dzy9PHs78VKzDSgnRmkRIZCWyLbOJ14fbq5R
eYNzK5VlG4GDkrW621DuQzxCaicLUyEvVrCJLrxNFxCuoAdYn2K1KlS2cSnM
Na2EW5k6S3jVXHutFEkyV3iDDT2v04yQT9EdxEeCdZXO3fj/Ema9ZevVhuy+
Vk44nemYUmWvvsI+52atsWhEr9H5GTxVGudSkpwCNkMCqJer5qBsIy3SPH01
1AtYa0DZadQKgpz8+Oxk36M0mApex5Ky1AXqgsf5QlZrA3E3DsUiwmuAdK42
5PrUuZps35iOAb1OERWDvUcEj8apCXIRqYtEhLIccy3oAwE6AfxReZt+uL/v
nxc06fkiqFLRG1RVoO6SiUJFLwIYekmFCAf21H8IOlfPSXoH3MWmqFTKuw9t
I8SUCxbOaD0Nl3boPG9DmAxLgcFlEYkcAowoFgXpq1XCgnk4Fp38ASaDzODk
Xaq4YoK4LCPAOxedTH00/2YOwxvYvz2xCRZhSBvVvZiQML7gffxIFRGhgzDt
xc6KA7yo8zmkBCRKUwV7qgTMpFJLnGZIBdaGzdJFKXYP6B41OIgpGQFQT+R0
4XMgCAVtiWTTR1PwiXuIKNovZkpkSu9xjzucXSwRJgp8LtcVETR4IU+J3sjH
wzSyP8ZyqvVXF1MclJfAO8y3BmcDG6V/CxRw1kZVNXLrCImtYmk5tCsVU4nl
l8jnjFDsMZavDWd2RS9TpDU2Yq+ZXK/pq4zEYnim3gRD78JoPRD3INxIgS1g
RLN2IaIQhpmGmVDMC8CUshEiImzasymlYJidc0tukDegGZFyqI73sTgxeePq
EE+c2UAtyQjQEAf2QDvXseLwwyNVkVHwkIzSJSCulN2SRyRyi+q+3lS1GA3l
SudE+QdGQUayCWHMUEzDYXUooFAZjo2pXlldoUq9Iw9MgOZ/ULDjITZzUbyw
y8grWKBSRmmOIL3TFDSIf+zZRY6SlY5XRfpzrb1xYzqPGiJKD+zVFnCcA9oa
/r4H6mAhHz20gbJMtJGxHTzXJjPyjnysx8vxSF5FRy8+3ydUVJyOFXxUpb8E
PLVg9NGmZEbssReZCJhCc8UlI883BBycSTltJ5p25Gu5sNScYMFCOSqr3HI1
8v149OLF4ct9BtGrzvU2pL5OwtFDE+DEVM3TjGKcCpUM5Afg01QJjDca1dS6
IKhCiX4skUGYeaiMyhHWM7hoW52EpQXlJbd7q5DSHqZqj3Gko0ZdHFa0ju1l
sUXjQqrDbBO41XoGBGJEIRJXI3qvqz2dobt3ubCHEkowIMf5hijOUspAsJVn
ZgIBdKeyNGmY4u58EOgAo9KnQ+KLXM7jleYSQWyybWbewCN3qV6TQTyQoH7b
ickFQdNSL1k470P0oiSU9wJHYVoou2mzuqACvzLrAiphMfL6f/Bpuo4Tr9Wn
fWaMGyFoGCF/CntQ4jbiDB6Rv8rPCKs3bgWzPvFH0bMWfmj4lwbkdZW73tel
u72hZY1Xb6goNi/c0QtYyXsm9N6TVp4ofP4utmX9BIVYA1IIev3Bnfp6k1Jk
jk/faoemd5+2y8ezIrabEmA8+4Coc5Ry7km1xneftttJV6HeaqRdVz25J5fI
K0Rc7v6Qsfqb0m4/feIu/fX/RG+/2NAuv8pj8LQ/igP58RtwTLfSyf3vMvnf
GuTxb++OS1Qhn9DkqarUk/d+i58eKCtIRoi6S4UG7X1Jhp8ttG+d+/6hfH//
rRd9LhDH1ADXPl11mQ71PlQITUMkV2P1pleOGKBhXpRasddCfw95vEHdWHYt
EzJ3kjD7GdQf3phbSuHnj1sHENPu2UrmYAigbCOpUypvMkkt6mpGNETQu79B
WLm1+Y1aO2a26VUXPdWJ9EvkbRrEcbcVZGuSlO+8XulqTQ36bvP1LYOSgfgh
9sU7Mk3uGJUnSThjtj9u5whtmue1XIFcQ7GYorYUvus6x7uleuQGwjSUrqF+
0tsfe/ILo07M8E0r4GxGLOMBl85BcV3z+9auzdrL72fX3KEWotXMsxiqVE3b
7Z8QvdvJOXtjGfIbTU4g8q0O/vLzPUc7BmBjgS49NfetTej5PC1re8uHFGkr
Qtuuh0nY5fFJw2d6IhDJB1ctQTgaN9EABv8i7mYzpmezGXP89AN3eLAz7UEE
z4EWJDW1Sd6KGYiPPL84/SZCKudZoCSDgvQ8XjO16yYNSh60syzlwhj3EttD
BHIXeMZrvTSAux9aTTvSjqbAf6GDK1F6R3JNyuggSLA8qUwQXPCkhARA2LbM
lxDVbUVvBCYOx8NQhV73aDKp2sDa9YiJBmWWH316w9s3JVj344MPBy8PDvdH
vcfPvnjuHx8NHr84OvSPn/Uff3hxdHT40n/xfPDF8+df+Mcv/ON7OWtEnLGE
X4Y0+YPHlnYU32FOvreL1PQSICwstkA07hZ5G4zCCCNkh7RIfMYK9iYj+mBp
JjUMlcGojRNYtwVH2es31zTt0MrSyGinqDeUIPcAjld6QQ0ndEv8lCWRNbpu
kM1YM5S72RXvDfXIh020iy23cpIqHHcQAQc7Q5kjneQDbpkL9zP9N3z/IcR3
6a3uz5foVihckHFf5Bl8rKxN/cjkQfCK/1Ey+N2zs36pGG3XCtGvFYicsE+M
uPap4s30tM1Xs3r+b2x/Vc9Rb0Enp8XCiCbx9eZPvIC6NDZPr83T/Ts+nLcQ
LM1AxCZj1KQYO+zs4nvvHJ5LUgujB+OubCNmWqP13j3S4z3evbt+dTrxrS6s
VcXj9+9ZzGY6JBKNBEg909z4kYtjPeAn5/1HzNMsrSpX5B//Nr4Yejak0xNO
kG1CapPyViYOtZSnAk7eFmad6WTZdqZQ8I78zJMK50yccoFnuxIlaGoQUwpq
vflcn/M5i4diL3blcZiY3kTqZpbQ+6Ja1Q69JYElzuqESEyWNWBDKi75UoHm
/fw97XLS92E61mOf+cR1u2t0rtzq8XkryAm1zh8Qgr2l+7yGix+JT2qDhs5m
0SsAMrrwv/KQEIahMbY1ORUdRbcAPJrqd4L9dV8Nqs3jgxG+3Q8ZsDnOs5Ki
K2/eQOSIhreG7zzZbKeZgkfKO68WZn40Ip+Pn4+83/pS+Xom6He+BOc0Rze/
yE40xfe4HzTkXKmI4WiboycGOIZ1OpSmvURzr3SjrTUWpCijiQ/nvjBX+51M
h3OnY5JIR/f0dw3ZaQ8f8QAfxtgmGA3WWnZmONFgh9a0nbUv/VhkxtSqKQE4
3XmZkOYWC030QJS1LY1DneV1i9SCVgxn2kPrdNwQWTwJcSforgPg5sK2eJDP
Pb8bi3fv3lydvZbT2ez7s0kT553t8N+bi3YyWYQ8GlDV0tq2XniKxNcgx5XM
NNEhsh05PYjhx+NrNRjg3np/jcTK9x9IY5yDCDyzwLE8oBcARzYAfSBYQcOG
XA/YGU2A0AoNVrUyE+vC4oOxZMoQck+/ZNMEqOVJycibh9mb1WWm4iZ1zWb+
hqYb4IxD2I7H436DespxHnkgPB6PCNYc+Xv4cW9/u5f9dftR6HgBPXSMA82+
GgLtd+32WWg9tyWLUZOaufDeaMdmW0/o0xszQfcQck1I7FJw5y5fhU7oRnW9
8E2Q5cYj+OZgl35kb58EqcT5Hu+4ix+uX33ko2pOiS0i8adl5sk0zYwT03aI
g9Vdm7dWm1GH/7Zx6ybt/TJKYeor2HYyqdAG9i4ssUdGl9BLY5LBzUB7RA+o
idGueEQT2MqHIBMQvtZAIIJejBo1GgLmtM4lzkLarC3HtFksfNdxEL29vt42
D99q584HK19o1ssV33QQS6JJLn4sa+ZBwyuKnqBMVB33GsRS+Ch/DQPg1jw7
huUTQ8oQa5AIJbqlSHzLxdsHD5Qpqglfvk8pVRW3tDLcqCPx3IXeiFgPHVVw
MEK9WXMVf0J8NwlDXiceZMLu7wKigwM+JuRXvzgeLGY+e4tGgBKJuwUPW204
hUXtPikN1BP/dws8bbdkP+irf65BhjLd/ysB4oCEDj976F+D85A4tMcNfw1E
36rUdXQ67f3FwzjcN1PLRxceJdzOg0EvOzNDMnROt5zkJmCIataa4O1vsxJA
SDOp9E6iHsfyA/56Z5DwsdNHOV8OcP8xbVI9+bgmzOiQs2A3ImzTR7BMZswt
KVKFq5kiCTccA4oRKt4g80GSPMwV5OWsQQOPLxJdkv2LilIYAW76KAnSGLmk
S82UxkC+fJMEkSeZhmAfLhb91Uy4HuS5LKLfWwerPbymx6+Pt6DFD9/Nzt98
/90pjdWe8kVWAji8Z1mp047pj2SCK7s7fmZgRTcHAPUK44em0G21clYv0cbZ
jedlApwJzZPJc4ZfmGnxX+O8Oh03f7o0pxtY8V8aTsyo1igAAA==

-->

</rfc>

