draft-kampanakis-tls-scas.xml

<?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 ipr="trust200902" docName="draft-kampanakis-tls-scas-latest-03" category="exp">

  <front>
    <title abbrev="Suppress CAs">Suppressing CA Certificates in TLS 1.3</title>

    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization>AWS</organization>
      <address>
        <email>kpanos@amazon.com</email>
      </address>
    </author>
    <author initials="C." surname="Bytheway" fullname="Cameron Bytheway">
      <organization>AWS</organization>
      <address>
        <email>bythewc@amazon.com</email>
      </address>
    </author>
    <author initials="B.E." surname="Westerbaan" fullname="Bas Westerbaan">
      <organization>Cloudflare</organization>
      <address>
        <email>bas@cloudflare.com</email>
      </address>
    </author>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>

    <date year="2023" month="January" day="05"/>

    <area>Transport</area>
    <workgroup>TLS</workgroup>
    

    <abstract>


<t>A TLS client or server that has access to the complete set of published
intermediate certificates can inform its peer to avoid sending
certificate authority certificates, thus reducing the size of
the TLS handshake.</t>



    </abstract>


  </front>

  <middle>


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

<t>The most data heavy part of a TLS handshake is authentication. It usually
consists of a signature, an end-entity certificate and Certificate Authority
(CA) certificates used to authenticate the end-entity to a trusted root CA.
These chains can sometime add to a few kB of data which could be problematic
for some use cases. <xref target="EAPTLSCERT"/> and
<xref target="EAP-TLS13"/> discuss the issues big certificate
chains in EAP authentication. Additionally, it is known that IEEE 802.15.4
<xref target="IEEE802154"/> mesh networks and Wi-SUN <xref target="WISUN"/> Field Area Networks
often notice significant delays due to EAP-TLS authentication in
constrained bandwidth mediums.</t>

<t>To alleviate the data exchanged in TLS
<xref target="RFC8879"/> shrinks certificates by compressing them.
<xref target="CBOR-CERTS"/> uses different
certificate encodings for constrained environments. On the other hand,
<xref target="CTLS"/> proposes the use of certificate dictionaries
to omit sending CA certificates in a Compact TLS handshake.</t>

<t>In a post-quantum context
<xref target="I-D.hoffman-c2pq"/><xref target="NIST_PQ"/><xref target="I-D.ietf-tls-hybrid-design"/>, the TLS
authentication data issue is exacerbated. <xref target="CONEXT-PQTLS13SSH"/><xref target="NDSS-PQTLS13"/>
show that post-quantum certificate chains exceeding the initial TCP
congestion window (10MSS <xref target="RFC6928"/>) will slow down the handshake due
to the extra round-trips they introduce. <xref target="PQTLS"/> shows that big certificate
chains (even smaller than the initial TCP congestion window) will
slow down the handshake in lossy environments. <xref target="TLS-SUPPRESS"/>
quantifies the post-quantum authentication data in QUIC and TLS
and shows that even the leanest post-quantum signature algorithms
will impact QUIC and TLS. <xref target="CL-BLOG"/> also shows that 9-10 kilobyte
certificate chains (even with 30MSS initial TCP congestion window)
will lead to double digit TLS handshake slowdowns. What’s more, it
shows that some clients or middleboxes cannot handle chains larger
than 10kB. <xref target="QUIC-CERTS"/> also shows discusses how classical RSA
certificate chains often exceed the QUIC amplification, an issue
which will happen almost always with post-quantum certicates.</t>

<t>Mechanisms like
<xref target="RFC8879"/><xref target="CBOR-CERTS"/>
would not alleviate the issue with post-quantum certificates
as the bulk of the certificate size is in the post-quantum
public key or signature which is incompressible.</t>

<t>Thus, this document introduces a backwards-compatible mechanism
to shrink the certificate data exchanged in TLS 1.3. In some uses
of public key infrastructure (PKI), intermediate CA certificates
sign end-entity certificates.  In the web PKI, clients require
that certificate authorities disclose all intermediate certificates
that they create. Although the set of intermediate certificates
is large, the size is bounded. Additionally, in some use cases the
set of communicating peers is limited.</t>

<t>For a client or server that has the necessary intermediates,
receiving them during the TLS handshake, increases the data
transmission unnecessarily. This
document defines a signal that a client or server can send to
inform its peer that it already has the intermediate CA
certificates. A peer that receives this signal can
limit the certificate chain it sends to just the
end-entity certificate, saving on handshake size.</t>

<t>This mechanism is intended to be complementary with
certificate compression <xref target="RFC8879"/> in that it
further reduces the size of the handshake especially
for post-quantum certificates.</t>

<t>It is worth noting that <xref target="RFC7924"/> attempted to address the
issue by omitting all certificates in the handshake if the client
or server had cached the peer certificate. This standard has not
seen wide adoption and could allow for TLS session correlation.
Additionally, the short lifetime certificates used today and the
large size of peers in some use cases make the peer certificate
cache update and maintenance mechanism challenging — not the
least because of privacy concerns.  The
mechanism proposed in this document is not susceptible to
these challenges.</t>

</section>
<section anchor="terms-and-definitions" title="Terms and Definitions">

<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"/> <xref target="RFC8174"/> when,
and only when, they appear in all capitals, as shown here.</t>

</section>
<section anchor="suppress-ca-certificates-flag" title="Suppress CA Certificates Flag">

<t>The goal is when a client or server has the intermediate CAs
to build the certificate chain for the peer it is establishing
a TLS connection with, to signal to the peer to not send
these certificates. TLS <xref target="RFC5246"/>
<xref target="RFC8446"/> allows for the root CA certificate to be
omitted from the handshake under the assumption that
the remote peer already possesses it in order to validate
its peers. Thus, a client or server in possession of
the CA certificates would only need the peer end-entity
certificate to validate its identity which would alleviate
the data flowing in TLS.</t>

<t>This draft assumes that the endpoint can keep as set of ICAs
in memory to use them while building certificate chains to
authenticate a peer. Most usually the set will be stored locally
in non-volatile memory. In constrained devices the intermediates
could be cached, kept and updated only in volatile memory
especially when the communicating peers’ PKI domains are
limited.</t>

<t>How CA certificates are identified and stored is dependent on
the use case. In some use cases (e.g. WebPKI <xref target="ICA-PRELOAD"/>) the
peer may assume that all intermediates are assembled, distributed
and updated regularly using an out-of-band mechanism. In other
use cases when the communicating peers’ PKI domains are
limited and not all CA certificates can be stored (i.e.,
constrained devices), or distributed, intermediates could be
cached and updated dynamically using a caching mechanism. 
Such mechanisms are discussed in <xref target="TLS-SUPPRESS"/>.</t>

<t>Although this document uses mechanisms to minimize TLS
authentication failures due to stale or incomplete ICA lists,
an endpoint is expected to re-attempt a TLS connection if it
failed to authenticate a peer certificate after requesting ICA
suppression. [EDNOTE: draft-ietf-tls-esni already requires
the client to retry a connection when ECH is “securely replaced
by the server” or “securely disabled by the server”. ]</t>

<t>[EDNOTE: To prevent failuers, one additional option
could be to use a TLS extension like the one defined
in <xref target="RFC7924"/> to include the chain fingerprint so the
peer can confirm that he does not need to send the chain because
the peer asking for suppression has the correct chain to validate the
server. That could prevent inadvertent mistakes where the client thinks
it has the intermediates to validate the server, but what it has is wrong.
The shortcoming is that could be used as a cookie.
Alternatively we could HMAC the chain to make it indistinguisable.
Another option is for the server to provide a ticket so client returning
visits tell the server that the client has the ICAs and it does not
need to send them. These options require further evaluation only if
we think that the complexity is worth the benefit.]</t>

<t>The 0xTBD1 flag used to signal CA suppression can only be sent
in a ClientHello or CertificateRequest message as defined below.
Endpoints that receive a 0xTBD1 flag with a value of 1 in any other
handshake message MUST generate a fatal illegal_parameter alert.</t>

<section anchor="client" title="Client">

<t>A client that believes that it has a current, complete set of intermediate
certificates to authenticate the server sends the tls_flags extension
<xref target="TLS-FLAGS"/> with the 0xTBD1 flag set to 1 in
its ClientHello message.</t>

<t>To prevent a failed TLS connection, a client MAY choose not to send the
flag if its list of ICAs hasn’t been updated in TBD3 time or has any other
reason to believe it does not include the ICAs for its peer.</t>

<t>A server that receives a value of 1 in the 0xTBD1 flag of a ClientHello
message SHOULD omit all certificates other than the end-entity certificate
from its Certificate message that it sends in response. Otherwise if it
does not support CA certificate suppression, the server SHOULD ignore the
0xTBD1 flag.</t>

<t>To prevent a failed TLS connection, a server could choose to send its
intermediates regardless of the flag from the client, if it has a reason
to believe the issuing CAs do not exist in the client ICA list. For
example, if the server’s certificate chain contains ICAs with
technical constraints which are not disclosed, the server SHOULD send
the chain back to the client regardless of the suppression flag in the
ClientHello.</t>

<t>If the connection still fails because the client cannot build the
certificate chain to authenticate the server, the client MUST NOT
send the flag in a subsequent connection to the server.</t>

</section>
<section anchor="server-mutual-tls-authentication" title="Server (mutual TLS authentication)">

<t>In a mutual TLS authentication scenario, a server that believes that it
has a current, complete set of intermediate certificates to authenticate
the client, sends the tls_flags extension <xref target="TLS-FLAGS"/>
with the 0xTBD1 flag set to 1 in its CertificateRequest message.</t>

<t>To prevent a failed TLS connection, a server MAY choose not to send the
flag if its list of ICAs hasn’t been updated in TBD3 time or has any other
reason to believe it does not include the ICAs for its peer.</t>

<t>A client that receives a value of 1 in the 0xTBD1 flag in a CertificateRequest
message SHOULD omit all certificates other than the end-entity certificate
from the Certificate message that it sends in response. Otherwise if it
does not support CA certificate suppression, the client SHOULD ignore the
0xTBD flag.</t>

<t>To prevent a failed TLS connection, a client could choose to send its
intermediates regardless of the flag from the server, if it has a reason
to believe the issuing CAs do not exist in the server ICA list. For
example, if the client’s certificate chain contains ICAs with technical
constraints which are not disclosed, the client SHOULD send the chain
back to the server regardless of the CA suppression flag in the
CertificateRequest. [EDNOTE: MSRP 2.8 may require constrained
intermediates which would mean this could change for WebPKI.]</t>

<t>If the connection still fails because the server cannot build the
certificate chain to authenticate the client, the server MUST NOT
send the flag in a subsequent connection from the client.
[EDNOTE: There is a challenge with this in that the server needs to keep
track of failed client connections.]</t>

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

<t>This document creates an unencrypted signal in the ClientHello that
might be used to identify which clients believe that they have
intermediates to build the certificate chain for their peer.
Although it does not reveal any additional information about the
peers, it might allow clients to be more effectively fingerprinted
by peers or any passive observers in the network path. A
mitigation against this concern is to encrypt the ClientHello in
TLS 1.3 <xref target="ESNI"/> which would hide the CA certificate
suppression signal.</t>

<t>Even when the 0xTBD1 flag is encrypted in the handshake,
a passive observer could fingerprint the peers by analyzing the TLS
handshake data sizes flowing each direction. Widespread adoption of
the TLS CA suppression mechanism described in this document will deem
the use of the signal for fingerprinting impractical.
<!-- [EDNOTE: Commenting this out as the probabilistic TLS suppression for the same source-destination would reveal trying to hide TLS suppression. Maybe we can rethink it later] 
To alleviate this
concern the client or server could randomly choose to not request
suppression although it has the CA certificates to validate the peer.
That would prevent a passive attacker concluding if the CA certificate
suppression signal is supported by the client or server. The
probability distribution for chosing to request suppression or not
is a trade-off decision between the risk of fingerprinting and TLS
performance. --></t>

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

<t>This document registers the 0xTBD1 in the registry created by
<xref target="TLS-FLAGS"/>.</t>

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

<t>We would like to thank Ilari Liusvaara, Ryan Sleevi
Filippo Valsorda and for their valuable feedback contributions
to this document.</t>

<t>The authors would also like to thank Filippo Valsorda for his feedback
regarding ICA lists <xref target="FILOSOTTILE"/>.</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 fullname="S. Bradner" initials="S." surname="Bradner"/>
    <author>
      <organization>RFC Publisher</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"/>
  <format target="https://www.rfc-editor.org/info/rfc2119" type="TXT"/>
</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 fullname="B. Leiba" initials="B." surname="Leiba"/>
    <author>
      <organization>RFC Publisher</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"/>
  <format target="https://www.rfc-editor.org/info/rfc8174" type="TXT"/>
</reference>

<reference anchor="TLS-FLAGS" target="https://www.ietf.org/archive/id/draft-ietf-tls-tlsflags-10.txt">
  <front>
    <title>A Flags Extension for TLS 1.3</title>
    <author fullname="Yoav Nir" initials="Y." surname="Nir">
      <organization>Dell Technologies</organization>
    </author>
    <date day="26" month="July" year="2022"/>
    <abstract>
      <t>A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-tls-tlsflags-10"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-tls-tlsflags-10.txt" type="TXT"/>
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="IEEE802154" >
  <front>
    <title>IEEE Standard for Low-Rate Wireless Networks</title>
    <author >
      <organization></organization>
    </author>
    <date year="2020" month="July"/>
  </front>
  <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
</reference>
<reference anchor="WISUN" target="https://wi-sun.org/">
  <front>
    <title>WI-SUN Alliance</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="CL-BLOG" target="https://blog.cloudflare.com/sizing-up-post-quantum-signatures/">
  <front>
    <title>Sizing Up Post-Quantum Signatures</title>
    <author initials="B.E." surname="Westerbaan" fullname="Bas Westerbaan">
      <organization></organization>
    </author>
    <date year="2021" month="November"/>
  </front>
</reference>
<reference anchor="CONEXT-PQTLS13SSH" >
  <front>
    <title>Assessing the Overhead of Post-Quantum Cryptography in TLS 1.3 and SSH</title>
    <author initials="D." surname="Sikeridis" fullname="Dimitrios Sikeridis">
      <organization></organization>
    </author>
    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization></organization>
    </author>
    <author initials="M." surname="Devetsikiotis" fullname="Michael Devetsikiotis">
      <organization></organization>
    </author>
    <date year="2020" month="November"/>
  </front>
  <seriesInfo name="DOI" value="10.1145/3386367.3431305"/>
  <seriesInfo name="ISBN" value="9781450379489"/>
</reference>
<reference anchor="NDSS-PQTLS13" >
  <front>
    <title>Post-Quantum Authentication in TLS 1.3: A Performance Study</title>
    <author initials="D." surname="Sikeridis" fullname="Dimitrios Sikeridis">
      <organization></organization>
    </author>
    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization></organization>
    </author>
    <author initials="M." surname="Devetsikiotis" fullname="Michael Devetsikiotis">
      <organization></organization>
    </author>
    <date year="2020" month="February"/>
  </front>
  <seriesInfo name="DOI" value="10.14722/ndss.2020.24203"/>
</reference>
<reference anchor="PQTLS" target="https://ia.cr/2019/1447">
  <front>
    <title>Benchmarking Post-Quantum Cryptography in TLS</title>
    <author initials="C." surname="Paquin" fullname="Christian Paquin">
      <organization></organization>
    </author>
    <author initials="D." surname="Stebila" fullname="Douglas Stebila">
      <organization></organization>
    </author>
    <author initials="G." surname="Tamvada" fullname="Goutam Tamvada">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="TLS-SUPPRESS" target="https://www.amazon.science/publications/speeding-up-post-quantum-tls-handshakes-by-suppressing-intermediate-ca-certificates">
  <front>
    <title>Speeding up post-quantum TLS handshakes by suppressing intermediate CA certificates</title>
    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization></organization>
    </author>
    <author initials="M." surname="Kallitsis" fullname="Michael Kallitsis">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="ICA-PRELOAD" target="https://blog.mozilla.org/security/2020/11/13/preloading-intermediate-ca-certificates-into-firefox/">
  <front>
    <title>Preloading Intermediate CA Certificates into Firefox</title>
    <author initials="D." surname="Keeler" fullname="Dana Keeler">
      <organization></organization>
    </author>
    <date year="2020" month="November"/>
  </front>
</reference>
<reference anchor="NIST_PQ" target="https://csrc.nist.gov/projects/post-quantum-cryptography">
  <front>
    <title>Post-Quantum Cryptography</title>
    <author initials="." surname="NIST" fullname="National Institute of Standards and Technology">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="FILOSOTTILE" target="https://github.com/FiloSottile/intermediates">
  <front>
    <title>filippo.io/intermediates</title>
    <author initials="F." surname="Valsorda" fullname="Filippo Valsorda">
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>
<reference anchor="QUIC-CERTS" >
  <front>
    <title>On the Interplay between TLS Certificates and QUIC Performance</title>
    <author initials="M." surname="Nawrocki" fullname="Marcin Nawrocki">
      <organization></organization>
    </author>
    <author initials="P." surname="Tehrani" fullname="Pouyan Fotouhi Tehrani">
      <organization></organization>
    </author>
    <author initials="R." surname="Hiesgen" fullname="Raphael Hiesgen">
      <organization></organization>
    </author>
    <author initials="J." surname="Mucke" fullname="Jonas Mucke">
      <organization></organization>
    </author>
    <author initials="T." surname="Schmidt" fullname="Thomas C. Schmidt">
      <organization></organization>
    </author>
    <author initials="M." surname="Wahlisch" fullname="Matthias Wahlisch">
      <organization></organization>
    </author>
    <date year="2022" month="November"/>
  </front>
  <seriesInfo name="DOI" value="10.1145/3555050.3569123"/>
</reference>


<reference anchor="EAPTLSCERT" target="https://www.ietf.org/archive/id/draft-ietf-emu-eaptlscert-08.txt">
  <front>
    <title>Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods</title>
    <author fullname="Mohit Sethi" initials="M." surname="Sethi">
      <organization>Ericsson</organization>
    </author>
    <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson">
      <organization>Ericsson</organization>
    </author>
    <author fullname="Sean Turner" initials="S." surname="Turner">
      <organization>sn3rd</organization>
    </author>
    <date day="20" month="November" year="2020"/>
    <abstract>
      <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-emu-eaptlscert-08"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-emu-eaptlscert-08.txt" type="TXT"/>
</reference>

<reference anchor="EAP-TLS13" target="https://www.ietf.org/archive/id/draft-ietf-emu-eap-tls13-21.txt">
  <front>
    <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3</title>
    <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson">
      <organization>Ericsson</organization>
    </author>
    <author fullname="Mohit Sethi" initials="M." surname="Sethi">
      <organization>Ericsson</organization>
    </author>
    <date day="20" month="October" year="2021"/>
    <abstract>
      <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-tls13-21"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-emu-eap-tls13-21.txt" type="TXT"/>
</reference>

<reference anchor="RFC8879" target="https://www.rfc-editor.org/info/rfc8879">
  <front>
    <title>TLS Certificate Compression</title>
    <author fullname="A. Ghedini" initials="A." surname="Ghedini"/>
    <author fullname="V. Vasiliev" initials="V." surname="Vasiliev"/>
    <author>
      <organization>RFC Publisher</organization>
    </author>
    <date month="December" year="2020"/>
    <abstract>
      <t>In 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>
  <seriesInfo name="RFC" value="8879"/>
  <seriesInfo name="DOI" value="10.17487/RFC8879"/>
  <format target="https://www.rfc-editor.org/info/rfc8879" type="TXT"/>
</reference>

<reference anchor="CBOR-CERTS" target="https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-04.txt">
  <front>
    <title>CBOR Encoded X.509 Certificates (C509 Certificates)</title>
    <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson">
      <organization>Ericsson AB</organization>
    </author>
    <author fullname="Göran Selander" initials="G." surname="Selander">
      <organization>Ericsson AB</organization>
    </author>
    <author fullname="Shahid Raza" initials="S." surname="Raza">
      <organization>RISE AB</organization>
    </author>
    <author fullname="Joel Höglund" initials="J." surname="Höglund">
      <organization>RISE AB</organization>
    </author>
    <author fullname="Martin Furuhed" initials="M." surname="Furuhed">
      <organization>Nexus Group</organization>
    </author>
    <date day="10" month="July" year="2022"/>
    <abstract>
      <t>This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded-cert-04"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-04.txt" type="TXT"/>
</reference>

<reference anchor="CTLS" target="https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.txt">
  <front>
    <title>Compact TLS 1.3</title>
    <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
      <organization>Mozilla</organization>
    </author>
    <author fullname="Richard Barnes" initials="R." surname="Barnes">
      <organization>Cisco</organization>
    </author>
    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Arm Limited</organization>
    </author>
    <author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz">
      <organization>Google</organization>
    </author>
    <date day="3" month="January" year="2023"/>
    <abstract>
      <t>This document specifies a "compact" version of TLS and DTLS. It is logically isomorphic to ordinary TLS, but saves space by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS or DTLS, but it should eventually be possible for a single server port to offer cTLS alongside TLS or DTLS.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-tls-ctls-07"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.txt" type="TXT"/>
</reference>

<reference anchor="I-D.hoffman-c2pq" target="https://www.ietf.org/archive/id/draft-hoffman-c2pq-07.txt">
  <front>
    <title>The Transition from Classical to Post-Quantum Cryptography</title>
    <author fullname="Paul E. Hoffman" initials="P. E." surname="Hoffman">
      <organization>ICANN</organization>
    </author>
    <date day="26" month="May" year="2020"/>
    <abstract>
      <t>Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-hoffman-c2pq-07"/>
  <format target="https://www.ietf.org/archive/id/draft-hoffman-c2pq-07.txt" type="TXT"/>
</reference>

<reference anchor="I-D.ietf-tls-hybrid-design" target="https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.txt">
  <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="28" month="August" year="2022"/>
    <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-05"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.txt" type="TXT"/>
</reference>

<reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6928">
  <front>
    <title>Increasing TCP's Initial Window</title>
    <author fullname="J. Chu" initials="J." surname="Chu"/>
    <author fullname="N. Dukkipati" initials="N." surname="Dukkipati"/>
    <author fullname="Y. Cheng" initials="Y." surname="Cheng"/>
    <author fullname="M. Mathis" initials="M." surname="Mathis"/>
    <author>
      <organization>RFC Publisher</organization>
    </author>
    <date month="April" year="2013"/>
    <abstract>
      <t>This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected.  It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse.  The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6928"/>
  <seriesInfo name="DOI" value="10.17487/RFC6928"/>
  <format target="https://www.rfc-editor.org/info/rfc6928" type="TXT"/>
</reference>

<reference anchor="RFC7924" target="https://www.rfc-editor.org/info/rfc7924">
  <front>
    <title>Transport Layer Security (TLS) Cached Information Extension</title>
    <author fullname="S. Santesson" initials="S." surname="Santesson"/>
    <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
    <author>
      <organization>RFC Publisher</organization>
    </author>
    <date month="July" year="2016"/>
    <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"/>
  <format target="https://www.rfc-editor.org/info/rfc7924" type="TXT"/>
</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 fullname="T. Dierks" initials="T." surname="Dierks"/>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
    <author>
      <organization>RFC Publisher</organization>
    </author>
    <date month="August" year="2008"/>
    <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"/>
  <format target="https://www.rfc-editor.org/info/rfc5246" type="TXT"/>
</reference>

<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
    <author>
      <organization>RFC Publisher</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"/>
  <format target="https://www.rfc-editor.org/info/rfc8446" type="TXT"/>
</reference>

<reference anchor="ESNI" target="https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.txt">
  <front>
    <title>TLS Encrypted Client Hello</title>
    <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
      <organization>RTFM, Inc.</organization>
    </author>
    <author fullname="Kazuho Oku" initials="K." surname="Oku">
      <organization>Fastly</organization>
    </author>
    <author fullname="Nick Sullivan" initials="N." surname="Sullivan">
      <organization>Cloudflare</organization>
    </author>
    <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
      <organization>Cloudflare</organization>
    </author>
    <date day="3" month="October" year="2022"/>
    <abstract>
      <t>This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni).</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-15"/>
  <format target="https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.txt" type="TXT"/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAFAzt2MAA+Vba2/jRpb9Xr+i4nxIB5Bky3an28bOzrj9SHviVyxnexez
QVAiSxLHJEthkVYrjf7vc+6tIlmk5I4zO1hgsQHSlkWy6j7PPfcWPRwORZmU
qT6WO5NquSy0tUk+l6cn8lQXZTJLIlVqK5NcPlxN5Hh0sCPUdFrop2NZ34+b
rYhNlKsMy8SFmpXDR5UtVa4eEzssUzu0kbLDlFYqh3sHgtacm2J9LPXHpUiW
xbEsi8qW+3t7R3v7QhVaHcuHQuV2aYpSrEzxOC9MtTwmIYSwpcrjX1Rqcuy3
1lYsk2P5t9JEA2lxf6FnFp/WmfsAyTK1XEKrn4VQVbkwxbGQcoj/JfSyx/Ju
JH9o5OWvnSp3Kje2f8kU82N58mHCv+hMJemxfFzSnX9RmfrN5KPIZKK7welI
vluXC71S62D5U/xbmLx7advyU74hen79d6PzkfwA4+piqlQe7PFO2f4F3uE0
NVU8S2HpzkbK/iVqrmzZ6HokHxYmsybc41ohUPLOBd7j2vyWpKkKN8jKv6Rm
pfOyMMv1KNelELkpMlUmT/pYCJHks+BXKS/Pz8/f7u2PXx8e8zJ1qNL3ckJh
oIpY4hl5ZVbDe4SV/JAUOqWovNElBY7d4SetLhJtaX23kpRnt5fHcrw3Go/3
jnZpwcnD2Wh/b39vdDQ+PPzuaMz3xVjzWO4fyL9W6VrSZZLrw+Xkp5uOSB8u
h/hKnqRpovLIWbVUxVyXx3JRlkt7vLu7Soa2ykcwzi4tcno1fHd1+71bpg1M
+m/of37Bv1/0sRdqkvxGyfzTUt4ZZN6PlcrLKsPX81yVFXI3UPGtvDFPOpvq
grQcb1Vgmpr5qBsgu5b3GFbL4ZL2+NXtMbTNHk7X25vz/3wY3v2IBB4fTCbv
X6D12QiSPsJvsU+9VuWzJEvKIkF29u/orbGZ2r+T3hsrIOTP9JMubfKYmHJj
keskWiidbrmnjtUTaz2oIovl7ZMuFlrF0sy6Tjkt1svSzAu1XKwDuJWIcQl7
7QSuCh2197vRffh69+Dg7XcH370ZHRwejA/2XvtbLifvbo7l0Zu3uGXv4M3R
4dsjctXN2WRSO+r/j5c6vjiBwgApqn0JALr1BqBZ3umCQQpZDgiq4nXomgs9
LSpVrF/kmsM3+/u7eWytg539w33URtzExn+B6VFW7tSvVdIHhNNFkdgSONS9
vMVxpZ4mHqEDt5lqngJTuld7T3+PSqCyJxX3n/7eVKXKOhdrG7/TebTIVPFI
yfB7wR9adX9vfLQVkBI1iopdurwLzH5DxsOjQOK7u/vzyUts+C8JvR8UYB9x
9VzYda83fGupdUymqJYyxE4OtgXy3i7UI7jXdC1tQM2SHEif4UmqduBpUcDT
ukZ7BsVXq9XIUwkbJfCJ3l1W09RHu921Xq4NTCcm18o1nK6HgVzDUK5hpIah
XFzLT0+G8MrV7cnZy2DlB41CXvSDE64IrzT5i6pvFJvzsmegHpEtjbwAR5iZ
j1sxdXwwaJN3awHMHK/hOm51VBVJud6lR3bH493xwe6yEeWLNqGLZjhzonCR
vLmcPPxy9+MLrEN39gxzw95TKdRH7pcVdEeJqTmS5TryoKNFbqDD+nnsC1Px
ReEU2SIa5QCc0dw8QXnzdx2VdrcTOVGwKGl6cXl1O7l9eLi8On+Bthcj+R8q
BbXfAJuLJE2WS9O9XKs1cxdHidkN/dBPkv2tWs2TclFNmeFgEzMxZZmkursQ
afLjT5enw9Pz+4eXgA2g4katChM9Jn2kUEUE3Otd3cSqB71AW9R/+s5Ua6D9
hSlNtUh6N/UWuR/J9yhIc92vGvdwDoFV92rv6b+O5HUVPeres39F5NnOld5z
Dyg2wP4kLntPUteAR0+b6/XlZy34QS3SxEYLuWHCslwkxIX9DaITDbc58y8G
h2Wq1nKK/kBrV9o7EEGZQm4NK/1z9Gv/RfTr9evXe6/3Rgev0VXso8QPh0Op
prYsVIQO6IRFiFJAcYnOiVYDSYS0qkQZgDxRRP0McIsUQEQuU43strqkDGfo
tgsdi05hCJFGRopIDOkiUYYk8L2g5dSTSWKskxNWieAJH8XAtc46AwhQWVno
uIpqPgv6T0Aj6HOnbo2E0xM+jVMtxNdk+sLgUcIpIR7wQAaMIKMqCUr8tJZL
dJKkk+ouJRPLErWUbCQvS1nZCnV1LSIULcCPdU82jccAjpTQbUiPdTVhFwc+
Z8LH+opXpyffdo1XWR2ztVoJNKserE2X3QgD9xbGlKg7I1LRwhMLhdBlH1iT
6TLJsH/slpQzvZKP70hyNsNqAcYAF1dpjPiUANNpqqkfjgQ1ufQ8yYPF0FOM
5KdPfz4/uYOtCID+dDk8GyW6nA11Vg21WqJckyKfP5O6wt07ZFq/cSuV9vEB
7gRFjyoKtgVZ3VZEP5J5aBDh9QFaYb0Nv5zEceIKUboeINrId4+5WeUunrlx
R0c/Gr8eHUKmtsHH5pm2C5n7tp199CHhrvrTJ264cctFomGak0Krpr8XZlYi
jXNQ+kiz+1lS5FKskedWxpUmY3vtexJDDw4g5GKSw3lTbLsCDC0kZVKVWcTx
AzyVpvopqT3PvtIfYYl8jmccYSUL31+cvn375uhPxSyinxDYgovn0KYTUmB0
lMZF2xdmI3r89N3tvSsmrYciY0EdpqZArEUm1vHQOxVxAN2S2UwXUKeTvnwn
VrY8GgnV0/lTUpg8wxOIH4+JBv8UnG4DlgLKtPsT6YvwD3ZEOKKqaxcdFIYI
23DbOOHcVgSGAhY3aP9qeOkzVTKakqewAjBwAzku6WKHE0OJUn8sST4SbWFm
MwDzMNpf/vr586dPnjrRxz93RF+sp2g8h7GmwPj8eSA9UIleGLBLOeIpYvVH
FdE4BelMWbYxveAtgz7582dhF2blYrwrd2AfnzkIHE/8Octy5Ato28PpHQXi
XFuWZ5XkMRZ8Nd67nkykC63vjvbfUmjRz8+fv8U9aSptittil2A6wExEvfAl
A3YrFGCpAmChH1+yA6nPcnisSUVWhOPVrKzT45nEf4UeGlCWUUpwlcr7esgN
PZys4jlZEQupsXbdC89Pn8JmDjZmo0IcH4IdQ2/1Z+4KOXNf8jl+BgqyIrRQ
qlUOebsLNoUEyT+n4rDIrGCTJy5ow6U5Stw8j/AWbDTc6Gg43pOPoJHTNdlx
MyScTVfYQx6ww79sTSdGSmMkuDg2oACUfeCsvcJJBid7w5gfIMg3FiWXKmNS
ikA8LiuOf1giIK5kT81HRx2ArLxk2oibElkuBPt+vPf4jrRviXDXAL6iYClK
kChVwLwImt1PTrZZwoG5SxH2jbMyOI+7EVbgws6pKly9ZGss1HKJJ1XKpEKl
K4J+tuhmPjICAWauNUF4YjOolIC6bkPwPwjLYsXFm2zWrRkOW54RqG6TlQvs
aZU+Ergy3wtsxGQrYezsx79wLbx8RGITU2iC15mIH2pqDsKFyhrIHOEhrsUm
qijpWkxA/UUtjB5X1DwO6UnYnsIsq21G6OKq24acW+sjzc/A2/KGxVDlloHY
YKiFQqUCQyTBX939cPnt4IvjDkFqPsPxEPK0GYm20lOJxQZNjBf61wp9t+Do
38Z7E+0CF6hE6Z/KZ7m1W4PxNAIrKQGmJykWqeYLx48dS3/++cSn06Cl0/hq
SmBNxafHp/IeB6SHhN8DTsqqnJMEtYVIvqWlUprCYikhLhAY6guNBgmQa2o2
aILZaXUHosCF5KmmKygvRV3BOpBDMpIhappAoSBKOsrLkAGEYVVe75GkazpP
Svj00MVfrGfgKbbm8akTbovQTKfheQCg2Ght6JmEEhCCxOtGt14oiW60nAQP
O2VZBVjQi4ItBRtzI94Zu6QnO9yp/R2tAPtme3AOpFVsS9gjQGs4n/MSezZp
5lIXoBi7NmRat4BkL/ITQUoXSes0x+JbOWmS1yYSs6pg8sc9nXeZb+l6NVrb
pY4SbriIVD6LYcTemPWDnAPriJZznGA/J8ybo30i++jWdbYsfW8Vx3ySTBZz
QAmKTPSRH6YE7HPHHoHwWMlRItooWaBCRipa+FrCDg5WctEnbX2QSIECgZFQ
XI1jatTMkisv1XnXl0EaFDKyAQW+9YaOTFGg3eAmSHSTlm0KWCmRijPX/21r
MGO15l3IBowIjSN8Km/kfkaqb9NLsM6yWsZ1s5spjiE+tGhDCz9Ro/I5GZl6
dapavD3yF/xPR8qz/GWRPKmIuhYsUBCdgOW0aFfyrUHsXNOpKGxSaSs0o0tX
QpCyZd0a8/4cNV/LB2Sn6/vOCAbYhNZNCqg+IKCQXDvXP00edgbup7y55c/3
56AJ9+dn9Hny/uTqqvkg/B2T97c/XZ21n9onT2+vr89vztzD+FZ2vhI71yf/
tTNgqXZu7x4ub29OrnY21VSF9tnJKIMEpNBWgDZtoyKZOtO8A50bHyIRvkIi
7I/HnJX0Ewnhvnw7fnPIqYqf+HIFTjtg3mrydO1+ddWG6I4quI2i9FDLpATr
gqCWiRdwBX0hDWG+Dl/U6E66LlI1d/adGwAcJe2CONQm3D4DodzmTaskjZ/B
REqTJkLdNABUVvHIioZObtKDsEJN8Ay3XAzIkjX+m/Z5fOZQAhbWAdRBcFrK
Yczr/cPvyIr0E5zMo+Ch+5J+MkdNiZ/WEvqpTUcHdqhgHIL/ZoXJerhDRdo9
DlpbZQ4qCOt4HlbozJRe9roWIUsIMgjEiG3BxLHT7EmlCaWrqMsYKcQMbYs7
8KBfiDb047d+h+2YKMdNrkMEbGuS6GlbC8G1FPjnCpdn2TX6OVIrmkHIDHZ0
B1PcCQlfwfhFIGcX7RsNPzVbGoQRV/BHrZccsY7BXFJEYZkMhit4qkb4w3wD
MqTahRrttaVzAKp0RnSKlR3Ja+oH/KywoWTcMiBZbYl+KEb3GXFlS2iOlA+f
DCE5k10ShFlrOEWJYYK6WnZPBJrRnas6A2i4LBk8HBh7f2Cf3h6ira8uCf2s
t8/oviEmC9jJWGd6f6fmd1KI9yhM/SggYHKeRN8csyheafKRXhKxoNjKRT3V
oeLSIeq+3LzSozm9hjIlCT59Cs7zaBhBdYOjK6M6xl735K1Hn51IuENnKAYw
EYh2CYSsoIQILVXoeYVCCINUPCZDvJiqHJrZcMolrS4+LCvPsEQr7D9lQ7aO
b902DEnx2kbMq2SkRwOxJSrQsyBRA6UGPfXrGBGemYQ6x+tcZQkHY601hxJ9
ChQWkypatF84k9adNlea/uwEaRn0JWHl4jlisBSyLkPxzYh8bBmUzVSS0ms9
9VgVaI4gNoXvL/loAqEBrmNLS6WrzXgerCHKPekr9NCTQLlRBkDoiJ1iry3D
d7VBeCSghlnsrxVNSugQGPy+OZ2mwfR//+38DNX9vH5DsZkQapsnDTz7ztCK
lk46UUvgkeoUKgqw89P3pNUOHwPrlJ5fpipCIE9rrCG83iH7tDfBUYpCX3Zv
gow/C9HK+WBAq2gwVDqjI3IRWjmfHnh6KR07bWHHQ6azp/4IyscVgqYbbtSL
x12PRedFXUaOZ+HDtIrdrb6Aw5hEZ8h/1rRZTtkAa8ySIvMNJBY22pE9V26M
b9CatTyhFE0hUpZfBeGjjdZXDdlgTh2V/umwPLmul6xGRZKaeDZAba4kVzGu
lfQZbWfJr1GsiBDJ0K8Lmsyj3m5lN7a/oXfTAEUI9cO3mPQk0abC5HM+8HFM
H5nAFdHXvcY9TPXpSA9fmccE/AxJCULNbzwS8mt/7/vrk9PAcpST3OeQbgQt
WL1yUYQlcjfA951K0nKausGnQDJP3M9I5NCjZl96MyC2qyInMvaUWKr7pU7T
zuN16fYP1Naias3gBalq14u+6zNyEFE1J10ze5F156lh48pBiyuNM7HSzjfB
zowsH4mMNJ0lD8p0jmAuR5Q4ZPy9jw/vzsZgJGrenNt5IglICmOM4pf3I0in
ptGdR7CG72EAQykbkOV7By10RmXVnOpXnUdYAQRoJM49zNnOCAGLhkLx/E9R
XFXcWI2ZwOdrX79aZlnvw13OHGoWDvlmYFyop2Bhc5X+slSFynTJ/BKyMt3/
2mtBB8tNpNM4X+OXp5qK+dhFIFYFnR8NNg6Ww2TojEq2Hob6WPEDEHwBaP2F
VLYtDIGHf0VV6eLq5PveCRP+55up5Um8c0O7kUzYlszFBDl0lDeVO6irIUBJ
Xzy6hSVg0+jrkF2GJnzc97YxK3hLLkGW61jNTclk+TdkSmB/XbKJ9r47O5Dc
2BvXKrUepVGYyV0nwfYPs6WDt7wBZW7dAFDJ7uRgM5XqB1DfWnwQHphI1NHk
e18+mNuYqjgUaQ50tk+uBHdB7IKg/Nbr16HlwgCSId2WyHrwyVtafZVY7Wt7
YwPKShqO9HqvIFkHYYR5FZDUxsG5CDR/cQzUU0QGWx8FdQRAOdGtBGCiqoj5
rXI/F2MzNw2hi6iB08znlXO8CBxfnwK401BiYKw/YM2WtRd9bNYEaiQvTCH0
Rzr/0IN6zOWE/8Zu6bfpmJRZLUcTjwZLeumLj1waslpa39MRbSQZ6ll3vM3U
db9dV3EVPTYvo9QlpG+fEGpdNrF+IghKalgu/dyupVUobYhL8pttBlDBTv44
qhk5bB4hfQGdBuFK9fhINCSllhPRUU0t4T1t2Irmdfa8g5F24gz1KqvKik7r
Nl4v+NafZT97g7SRphNzE0TlVrgWfwCu5ZfgWoQR+0W8li/Ba/F7eN0Hi14l
/aMp+38DtsPC+2LYdhRkw1L/cvTmYdH/Mnp7gzyD3n8MvGss+NeAd40N/3Pw
9hH6ZfB2wr8QvGUD3uLF4N21dLcFEyF4e3E37dOjyh383ojOsLO+ntzfyf3R
W54B1UQ/GJH0PBPOFTOt/Ei9diudHXNiuYkTc/yX14v2mPCfqRc1PAYr/fF6
0aMHo7C15140YUCvz0Bq4luf7/vWx29PfRVDOY1M6UA14jcEfI40GVFvbtlc
NPv3L6jLU3pLMqY2oj5VCYdA7uyaEFBWuc75fW2s63snH98h6eYhd5bMF2XT
19L8wA0a65Fxfd7eJlF9Vr5QT1pstNsvOElICg+yzTQrBGbCDshLOB4MSZq/
KqRzvKmpymaMYfkVRaeGO9erRXZnOfS2jNSzGRmVG/RgHOKGPO5sjg7Wc3p/
FRkDPc3Uea05qfQvNeKGcjGSJzBcmcy9QHNK+bKOfT5f48GBkd4PG7ZHHtd/
HUZvdU5uLrvFmSZafHbUptci8eWqi9PhiMw7Gyh8zi8j1QPUToWysg2O/ins
QKgNC/hsDqdI9fSHX4NU2HH9W/AmQdAC8+ECnYHa5ohBK2gUJ4UL8pH8ALXs
kkZ37Ult8DJyD8ja48rOoVx3HMonA7HWWTMPrymtywWKw0AdHvNkS3qTm2B6
JP7tq+FQNol+ajJa1SmIbSj4/PiEXu5V04QqRRK5s+QQdOsRDvp7aU1VRJpe
YsRKLmycW328l8WadzDOz721RvJaraeah0uKirobriDw6S+yi59l/wXXhM4x
XCAGBSV498LtDUeZDDnRVmCXgo60hMqoIFfr6VF/vN6ftrks5+HeqjPca4NM
lSVgkAViQsa+mL0szCmUPXdpB7F9TXl2JRpHlet2rF/7CMpbb3uveceNuIOm
Yoz0AO1YD81shvCKEr5c/w0CbV4k1kF6N7jqdxeX7R8jjORw+O+S4f3y5Obk
d6Ad9T2hPw62YTb73HXXivrdJTLEi4Y01Lt9LU8ierMb9WfOL6NYfPlBe2+5
iTPXCcTaZYoWR14llX1SqlADeU9/rzJJNWJO9P+Ih1Vu4Z7ng/TawAwlkPkL
8aTaCda95BooPHKjQPcql22OLa3pybSxLW1JC9X7CMeM/GmCO9AA4AZ/u8TH
KvxXDny/+AfLdknkTkEAAA==

-->

</rfc>