<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

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

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

<rfc docName="draft-ietf-tls-certificate-compression-02" category="std">

  <front>
    <title abbrev="TLS Certificate Compression">Transport Layer Security (TLS) Certificate Compression</title>

    <author initials="A." surname="Ghedini" fullname="Alessandro Ghedini">
      <organization>Cloudflare, Inc.</organization>
      <address>
        <email>alessandro@cloudflare.com</email>
      </address>
    </author>
    <author initials="V." surname="Vasiliev" fullname="Victor Vasiliev">
      <organization>Google</organization>
      <address>
        <email>vasilvv@google.com</email>
      </address>
    </author>

    <date year="2018" month="January" day="26"/>

    <area>Security</area>
    <workgroup>TLS</workgroup>
    

    <abstract>


<t>In Transport Layer Security (TLS) handshakes, certificate chains often take up
the majority of the bytes transmitted.</t>

<t>This document describes how certificate chains can be compressed to reduce the
amount of data transmitted and avoid some round trips.</t>



    </abstract>


  </front>

  <middle>


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

<t>In order to reduce latency and improve performance it can be useful to reduce
the amount of data exchanged during a Transport Layer Security (TLS) handshake.</t>

<t><xref target="RFC7924"></xref> describes a mechanism that allows a client and a server to avoid
transmitting certificates already shared in an earlier handshake, but it
doesn’t help when the client connects to a server for the first time and
doesn’t already have knowledge of the server’s certificate chain.</t>

<t>This document describes a mechanism that would allow certificates to be
compressed during full handshakes.</t>

</section>
<section anchor="notational-conventions" title="Notational Conventions">

<t>The words “MUST”, “MUST NOT”, “SHALL”, “SHOULD”, and “MAY” are used in this
document.  It’s not shouting; when they are capitalized, they have the special
meaning defined in <xref target="RFC2119"></xref>.</t>

</section>
<section anchor="negotiating-certificate-compression" title="Negotiating Certificate Compression">

<t>This extension is only supported with TLS 1.3 and newer; if TLS 1.2 or earlier
is negotiated, the peers MUST ignore this extension.</t>

<t>This document defines a new extension type (compress_certificate(TBD)), which
can be used to signal the supported compression formats for the Certificate
message to the peer.  Whenever it is sent by the client as a ClientHello message
extension (<xref target="I-D.ietf-tls-tls13"></xref>, Section 4.1.2), it indicates the support for
compressed server certificates.  Whenever it is sent by the server as a
CertificateRequest extension (<xref target="I-D.ietf-tls-tls13"></xref>, Section 4.3.2), it indicates
the support for compressed client certificates.</t>

<t>By sending a compress_certificate extension, the sender indicates to the peer
the certificate compression algorithms it is willing to use for decompression.
The “extension_data” field of this extension SHALL contain a
CertificateCompressionAlgorithms value:</t>

<figure><artwork><![CDATA[
    enum {
        zlib(0),
        brotli(1),
        (255)
    } CertificateCompressionAlgorithm;

    struct {
        CertificateCompressionAlgorithm algorithms<1..2^8-1>;
    } CertificateCompressionAlgorithms;
]]></artwork></figure>

<t>There is no ServerHello extension that the server is required to echo back.</t>

</section>
<section anchor="compressed-certificate-message" title="Compressed Certificate Message">

<t>If the peer has indicated that it supports compression, server and client MAY
compress their corresponding Certificate messages and send them in the form of
the CompressedCertificate message (replacing the Certificate message).</t>

<t>The CompressedCertificate message is formed as follows:</t>

<figure><artwork><![CDATA[
    struct {
         CertificateCompressionAlgorithm algorithm;
         uint24 uncompressed_length;
         opaque compressed_certificate_message<1..2^24-1>;
    } CompressedCertificate;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText='algorithm'>
  The algorithm used to compress the certificate.  The algorithm MUST be one of
the algorithms listed in the peer’s compress_certificate extension.</t>
  <t hangText='uncompressed_length'>
  The length of the Certificate message once it is uncompressed.  If after
decompression the specified length does not match the actual length, the
party receiving the invalid message MUST abort the connection with the
“bad_certificate” alert.</t>
  <t hangText='compressed_certificate_message'>
  The compressed body of the Certificate message, in the same format as it
would normally be expressed in. The compression algorithm defines how the
bytes in the compressed_certificate_message field are converted into the
Certificate message.</t>
</list></t>

<t>If the specified compression algorithm is zlib, then the Certificate message
MUST be compressed with the ZLIB compression algorithm, as defined in <xref target="RFC1950"></xref>.
If the specified compression algorithm is brotli, the Certificate message MUST
be compressed with the Brotli compression algorithm as defined in <xref target="RFC7932"></xref>.</t>

<t>If the received CompressedCertificate message cannot be decompressed, the
connection MUST be torn down with the “bad_certificate” alert.</t>

<t>If the format of the Certificate message is altered using the
server_certificate_type extension <xref target="RFC7250"></xref>, the resulting altered message is
compressed instead.</t>

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

<t>After decompression, the Certificate message MUST be processed as if it were
encoded without being compressed.  This way, the parsing and the verification
have the same security properties as they would have in TLS normally.</t>

<t>Since certificate chains are typically presented on a per-server name or
per-user basis, the attacker does not have control over any individual fragments
in the Certificate message, meaning that they cannot leak information about the
certificate by modifying the plaintext.</t>

<t>The implementations SHOULD bound the memory usage when decompressing the
CompressedCertificate message.</t>

<t>The implementations MUST limit the size of the resulting decompressed chain to
the specified uncompressed length, and they MUST abort the connection if the
size exceeds that limit.  TLS framing imposes 16777216 byte limit on the
certificate message size, and the implementations MAY impose a limit that is
lower than that; in both cases, they MUST apply the same limit as if no
compression were used.</t>

</section>
<section anchor="middlebox-compatibility" title="Middlebox Compatibility">

<t>It’s been observed that a significant number of middleboxes intercept and try
to validate the Certificate message exchanged during a TLS handshake. This
means that middleboxes that don’t understand the CompressedCertificate message
might misbehave and drop connections that adopt certificate compression.
Because of that, the extension is only supported in the versions of TLS where
the certificate message is encrypted in a way that prevents middleboxes from
intercepting it, that is, TLS version 1.3 <xref target="I-D.ietf-tls-tls13"></xref> and higher.</t>

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

<section anchor="update-of-the-tls-extensiontype-registry" title="Update of the TLS ExtensionType Registry">

<t>Create an entry, compress_certificate(TBD), in the existing registry for
ExtensionType (defined in <xref target="I-D.ietf-tls-tls13"></xref>), with “TLS 1.3” column values
being set to “CH, CR”.</t>

</section>
<section anchor="update-of-the-tls-handshaketype-registry" title="Update of the TLS HandshakeType Registry">

<t>Create an entry, compressed_certificate(TBD), in the existing registry for
HandshakeType (defined in <xref target="RFC5246"></xref>).</t>

</section>
<section anchor="registry-for-compression-algorithms" title="Registry for Compression Algorithms">

<t>This document establishes a registry of compression algorithms supported for
compressing the Certificate message, titled “Certificate Compression Algorithm
IDs”, under the existing “Transport Layer Security (TLS) Extensions” heading.</t>

<t>The entries in the registry are:</t>

<texttable>
      <ttcol align='left'>Algorithm Number</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>0</c>
      <c>zlib</c>
      <c>1</c>
      <c>brotli</c>
      <c>224 to 255</c>
      <c>Reserved for Private Use</c>
</texttable>

<t>The values in this registry shall be allocated under “IETF Review” policy for
values strictly smaller than 64, and under “Specification Required” policy
otherwise (see <xref target="RFC8126"></xref> for the definition of relevant policies).</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC1950" target='https://www.rfc-editor.org/info/rfc1950'>
<front>
<title>ZLIB Compressed Data Format Specification version 3.3</title>
<author initials='P.' surname='Deutsch' fullname='P. Deutsch'><organization /></author>
<author initials='J-L.' surname='Gailly' fullname='J-L. Gailly'><organization /></author>
<date year='1996' month='May' />
<abstract><t>This specification defines a lossless compressed data format.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t></abstract>
</front>
<seriesInfo name='RFC' value='1950'/>
<seriesInfo name='DOI' value='10.17487/RFC1950'/>
</reference>



<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="RFC5246" target='https://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference  anchor="RFC4366" target='https://www.rfc-editor.org/info/rfc4366'>
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials='S.' surname='Blake-Wilson' fullname='S. Blake-Wilson'><organization /></author>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></author>
<author initials='D.' surname='Hopwood' fullname='D. Hopwood'><organization /></author>
<author initials='J.' surname='Mikkelsen' fullname='J. Mikkelsen'><organization /></author>
<author initials='T.' surname='Wright' fullname='T. Wright'><organization /></author>
<date year='2006' month='April' />
<abstract><t>This document describes extensions that may be used to add functionality to Transport Layer Security (TLS).  It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.</t><t>The extensions may be used by TLS clients and servers.  The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4366'/>
<seriesInfo name='DOI' value='10.17487/RFC4366'/>
</reference>



<reference  anchor="RFC7250" target='https://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>



<reference  anchor="RFC7932" target='https://www.rfc-editor.org/info/rfc7932'>
<front>
<title>Brotli Compressed Data Format</title>
<author initials='J.' surname='Alakuijala' fullname='J. Alakuijala'><organization /></author>
<author initials='Z.' surname='Szabadka' fullname='Z. Szabadka'><organization /></author>
<date year='2016' month='July' />
<abstract><t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.</t></abstract>
</front>
<seriesInfo name='RFC' value='7932'/>
<seriesInfo name='DOI' value='10.17487/RFC7932'/>
</reference>



<reference  anchor="RFC7924" target='https://www.rfc-editor.org/info/rfc7924'>
<front>
<title>Transport Layer Security (TLS) Cached Information Extension</title>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2016' month='July' />
<abstract><t>Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs).  This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).</t><t>This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.</t></abstract>
</front>
<seriesInfo name='RFC' value='7924'/>
<seriesInfo name='DOI' value='10.17487/RFC7924'/>
</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>



<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='January' day='5' 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-23' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-23.txt' />
</reference>




    </references>



<section anchor="acknowledgements" title="Acknowledgements">

<t>Certificate compression was originally introduced in the QUIC Crypto protocol,
designed by Adam Langley and Wan-Teh Chang.</t>

<t>This document has benefited from contributions and suggestions from David
Benjamin, Ryan Hamilton, Ilari Liusvaara, Piotr Sikora, Ian Swett, Martin
Thomson, Sean Turner and many others.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAP35aloAA5VZb2/bNhp/z09BeC+WALaxuGm7JYfD0nRbA6TdLkk37Ipc
QUm0zVUSdSRl17vePvv9HpKS6MR2ewGKyjL5/P09fz2ZTJhTrpRn/M6I2jba
OH4tNtLwW5m3RrkNP7q7vj3ml9I4NVe5cJJf6qox0lqla1bovBYV7hdGzN1E
STefuNJO8uH8JB/OT0q8sI6JLDNyBa7Xt3tJ04uFNpszbl3BhJHirJeKrbX5
sDC6bTwNxqwTdfFelLqGLBtpWaPO+Dun8zG3UMrIucXTpgoPkLoSTaPqxT1j
onVLbc4YnzCOP1XbM34x5T8tZaFq5d8FFS9KSAY2Rm99qc3ijF+Wui3mJaQc
86s6n/pvZCVUecZFf+/7vD82hVW2WP465b8Kq0olVwnPX1XutNn+xjP8SetF
KVM2KzqzWn2/8N94+qzWphJOrSTU4zc/Xp589/Sb+Dg7OfkuPj6dnT6Lj6dP
nnWPz2f92effPZn1j7PT+PjtycyfvZq8nPaOx7+TJ2eMqXo+8GaTyYSLzDoj
csfYVf05uC1hLrsUHySclUCJ50sBY3E9d7LmDt/ztmFuKXkl/tD+vp5z+pxt
gDPuiEulnJPFlLG7pbLk+raSteOFtLlRGU4t9XoXk1zUPMOnCElZcKe5kUWb
S2LBRKVb0AHDQjiR8uKQnouVVgXAV0kOnOKFM6qx02CLShUFvMe+Alic0aDp
CPJkGW0K2GNgRRFT5xtPU0EUvZK8kcZbt8b3ynWStlbO23K46g3zQEr5EdrV
C8hYwN71gosvdgVEfxcBcJ9YT/BKEk1lK5hFOMC91Gt6nwOxYO2Nwa00q6CX
NwzrzUVCJNbHxRKhXmw4mEIPBAcocCkMqJlBmjHPWgflkYGkrb92fCnLhq+X
hAuoHXnnuq5l7qzn28kA0/kzc2Ws407BQ6DaE+r4LwUs/aHW61IWC9kBK9D4
2j5GzAGEPbLRWrdlESy1rTzkzCRLMBfdBMeWSVRMCTpvtBMEG1Eib9YrsMQH
S1JIMDCF5aPXb2/vRuPwP3/zs3++fXVxfR0efn57/RJP5KHR64vfRxwWJxh5
qzsowzplpghzB61r7eAY3ZLbzntzb/zFXDTKiVL9KYtxeOtN6K3WyFyJklUS
RoA6hZyrOrB5F3PRfdAJKd8p4VGxrzAEM8uPiAv6zPFB1yUA0zYEY5BdK7f0
teVk+sRrV8u1NOdczePbGcKswxTD/TqyjZIjwKSx3FtNLZBEpbfGwHOHr0kh
8jRYJbK5TSP5UefP94mvj+5evDw+HsOGKl+yIYR9mrHgCrd60/VaJXWUh+Rq
eywntoKRUW6AWNDpdIH7foOvJMEfCQOSW5I626TBIkj8S//8SgKaPBJigzpH
7x4n+/sxpQzCHj+dwrTQiVjURQfpQQkSNwV3DMg0Ag5LGi+QpCxR+Ub+u0Vb
wf8PQZ88EpQ9EDTN/F06SQVl7MWGhCtCGt3l40GgcRS/puSe2GZwkWe/lVQS
d4tyQeVtWdlolLUqS+ILAsCMF7eQyY2pzwKjnv97yv4jpDyJvONT2VYI+ZxA
2dIJyrepbZPIuxikWImypcL+119/hR6kbiv+H/9If3+WKjv65njcv8iMdqU6
OkleHc2ePj32n/7LP8PvnPlz6B9QKBM2n7mWmO1vJ9Pp7F/fTk7+fv5lLO25
143MiOinFKGBHkJfiI0kxCmhJ+DEWQM8KhNCGYkfOV3kH3x+uxwwlaa31zHS
2NW8BwSyp+2hUgQ2cH5EqE3xMe4Do+6xinzehxrRVARog0+NDpBN+cdIt54A
oZRuVKEKeHRVAI1H6KDAjvv8yMimFLlH5nZW6o4cT0OBOkxH+cxWUStFT76j
SND2CAhfjoTz4U6rajc75W09BPr7UtYLt0wO6UYgtyS5II3v91HegK7ZaQqv
XfpFTPXCMEwv1KP1Ynb5P3VcmhSQHbcv+BKFwoG5hzzE/YUkW5TKuq6cB1h9
bT+TquCgHSaJooYPXTO0y3U6NqVwYUqGGog5x4yITMe3c9XQISA9FR0Lasd8
u4E6ly+DXrlrURXDAZ9RQaoRBr2qkblUqw53qkZ+QvfdyeStJDJK7N6goSsk
1r5TCIRGmdhy7ogGN+NgjsPOj5ZJqkWmi80BE407d1iMeLGSE87RzPLYGfq5
rURPk5FjOrroMbdYbVWGvgWhcSZoFIagyOywErEy+DaOekkTUBPqE+O71Jj2
2Wrw3W7JAAUqCN5j9T6rsA7KiSE77/B/Xl+92E18TJZ70E7SlIt28sulC9Vp
vBfTJBrbI9oLf3cP7cey0Sh9P5gu4JaqwcF8iPaQQgEiDJETe1WWoLkzodOm
RgCtB3wfQHeUJOLwQGQrms0Qv5C2tTHUWCg8W5DyPe9QH9/FXcL9OGps29L3
9x2xgX7aG2IEd5jDfNXsR1LMOVahhRJx1LmgfLKdTQ57kayDGToPPCjo5pSs
MB2gzUW6KqJrMeHgqJ9N0xTmm/612MQpQRhvBxHqJYchAk+aUobZh6LcdhqA
eUOyUa21YUoKIe/PAyQ0oHThD+VvFeXTHesJClVYGu8oT5CIqPqQnvBHC4JJ
bAloj4Rph9ErlBeDXsQqGxQQzqExIQt2ydZLQX2g0SXXoaXY+C5kpQpKvnMj
FjTxWKb2hvKYd3Ne1xttOgSXUnzg/W6IZM3I1B7HCSG0+5Uu1HzTZXR0FchG
AFVsH1TVlJLkCEjgYZZF5m2jLypZabMBUMnzfk5NUBKxezDm9jDyICpVpWLP
h2m3i5kB2WmQBn8hJNl2MkqLY1/SIpI2ByqWmoe4I8byYy5lYYOZvVCEUQAI
XqpIEEivLVx78uz58+ezk2e+JETxQ+HdMnsXKUS8F+axCS5+j4SBtM4U1Jxa
hj6NljxLEdricwJ0ppGCcmGlHae6NU25GeIjkAnxWGuWZlOKTd8Y+VTw2m/O
Mv3RZ0xIlKmSFsLMrycyCUfrzEM/tszCD9NeQ3TFGFMySAiPVR0hXyKRRnLZ
hGWVMxuGwudbCLLKvnyya5cG2w8LM58u/M4juijl6V8UmjZOLU2FfoPNP9ti
s0otlkTJZtIHK90qkFQSjETiotCN2zdSTtkLmQuaHT16hQsZ4dBWJQY8koL1
THTYpqxpQno0vSZFA3nVbJpIQVD6DPJBFFpa2S2zzI2uWO8Pj2EvmsfX2DOM
Avjlzq4x35tkCTNJ4yFzdfHm4lHl+Oor/rbx7o3RS5R/6LS/oxJ2IxfongEG
dmkknaQ9JDIjsv/ehU7f28mPuEvim0jF7z62GRylvcEORWg7RPV7FFdZI/At
26oO07dloUBZ6WhkGF2+GvPLm9F0j26vOlh+qW7bjeKXaLfN4uhB50O/Mtwf
B/Fukmvpbo8P8/fDDZtEgGQYZ5Z+y9bzhYZ7FiUDcNOt04HRFDCj38IKmHL3
5nGQjl29tKNxCNxtg4w+s07vEWBHfIn+BndipSHzq6Ff7zVEocfo+2lgzt+E
JPaJv/Qb5sbXha2/T+zT2eTh345X/Veg/w1/8PfJd+0P33b0+cnj86GP3nN+
hlkbOJ09fdqfv5ExUxMMfjFqRQZ/i5z0KZgk4LxbRg8mAcjKklo52qCH9Uhw
xejqh7sfQXal5HrEG12qPEAzUsJtlTvKatRfdaXq2WkodpHGbajRoY/jN3GX
05FjKGfSrBWkPLJSemjTL2H3/S7W4175y0CnkaVcUenx1+Hg4/gbEO2EKD1d
5P2PDKGxSrdvW+Beoz4CAgtV+55PxZ+OhtT8j7dXl/ySkq2mRtNp5IsxKyRV
QJpLN/yiEBWAWS9KGX5S+k3Ukzu55JdUyh6ttWkFlckaCvk4Qm4OzaHK2lBo
/L6oXSwQnf6zP/JSoFlEfan/oC5kzG82MPIrPJeO+vOrUhjFr1VrV0IYMea/
KO0QKOqDpk9XOHy7lg5p/zVme1VDJl1ZunmLUsrvWlPHVVdFzan3h52y/wHj
FkQazR4AAA==

-->

</rfc>

