<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 1.7.30 (Ruby 3.4.4) 2.5.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-esni-25" category="std" consensus="true" submissionType="IETF" number="9849" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 3.31.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni-25" rel="prev"/>
  <front>
    <title abbrev="TLS Encrypted Client Hello">TLS Encrypted Client Hello</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-25"/> name="RFC" value="9849"/>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Independent</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <author initials="K." surname="Oku" fullname="Kazuho Oku">
      <organization>Fastly</organization>
      <address>
        <email>kazuhooku@gmail.com</email>
      </address>
    </author>
    <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
      <organization>Cryptography Consulting LLC</organization>
      <address>
        <email>nicholas.sullivan+ietf@gmail.com</email>
      </address>
    </author>
    <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <organization>Apple</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date year="2025" month="June" day="14"/> year="2026" month="February"/>
    <area>SEC</area>
    <workgroup>tls</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 67?> 108?>

<!-- [rfced] References

a) Regarding [WHATWG-IPV4], this reference's date is May 2021.
The URL provided resolves to a page with "Last Updated 12 May 2025".

Note that WHATWG provides "commit snapshots" of their living standards and
there are several commit snapshots from May 2021 with the latest being from 20
May 2021. For example: 20 May 2021
(https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-ipv4-parser)

We recommend updating this reference to the most current version of the WHATWG
Living Standard, replacing the URL with the more general URL to the standard
(https://url.spec.whatwg.org/), and adding a "commit snapshot" URL to the
reference.

Current:
[WHATWG-IPV4]
           WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May
           2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.

d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML stage.

OK.
-->

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<t>This document describes a mechanism in Transport Layer Security (TLS) for
encrypting a ClientHello <tt>ClientHello</tt> message under a server public key.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/tlswg/draft-ietf-tls-esni">https://github.com/tlswg/draft-ietf-tls-esni</eref>.</t>
    </note>
  </front>
  <middle>
    <?line 72?> 141?>

<section anchor="intro">
      <name>Introduction</name>
      <t>Although TLS 1.3 <xref target="RFC8446"/> encrypts most of the handshake, including the
server certificate, there are several ways in which an on-path attacker can
learn private information about the connection. The plaintext Server Name
Indication (SNI) extension in ClientHello <tt>ClientHello</tt> messages, which leaks the target
domain for a given connection, is perhaps the most sensitive information
left unencrypted in TLS 1.3.</t>
      <t>This document specifies a new TLS extension, extension called Encrypted Client
Hello
(ECH), (ECH) that allows clients to encrypt their ClientHello <tt>ClientHello</tt> to the
TLS server.  This protects the SNI and other potentially sensitive
fields, such as the
Application Layer Application-Layer Protocol Negotiation (ALPN) list
<xref target="RFC7301"/>. Co-located servers with consistent externally visible
TLS configurations and behavior, including supported versions and cipher suites and
how they respond to incoming client connections, form an anonymity set. (Note
that implementation-specific choices, such as extension ordering within TLS
messages or division of data into record-layer boundaries, can result in
different externally visible behavior, even for servers with consistent TLS
configurations.) Usage of this mechanism reveals that a client is connecting
to a particular service provider, but does not reveal which server from the
anonymity set terminates the connection. Deployment implications of this
feature are discussed in <xref target="deployment"/>.</t>
      <t>ECH is not in itself sufficient to protect the identity of the server.
The target domain may also be visible through other channels, such as
plaintext client DNS queries or visible server IP addresses. However,
encrypted DNS mechanisms such as
DNS over HTTPS <xref target="RFC8484"/>, DNS over TLS/DTLS <xref target="RFC7858"/> <xref target="RFC8094"/>, and
DNS over QUIC <xref target="RFC9250"/>
provide mechanisms for clients to conceal
DNS lookups from network inspection, and many TLS servers host multiple domains
on the same IP address. Private origins may also be deployed behind a common
provider, such as a reverse proxy. In such environments, the SNI remains the
primary explicit signal available to observers to determine the
server's identity.</t>
      <t>ECH is supported in TLS 1.3 <xref target="RFC8446"/>, DTLS 1.3 <xref target="RFC9147"/>, and
newer versions of the TLS and DTLS protocols.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. All TLS
notation comes from <xref section="3" sectionFormat="comma" target="RFC8446"/>.</t>
    </section>
    <section anchor="overview">
      <name>Overview</name>
      <t>This protocol is designed to operate in one of two topologies illustrated below,
which we call "Shared Mode" and "Split Mode". These modes are described in the
following section.</t>
      <section anchor="topologies">
        <name>Topologies</name>
        <figure anchor="shared-mode">
          <name>Shared Mode Topology</name>
          <artwork><![CDATA[
                +---------------------+
                |                     |
                |   2001:DB8::1111    |
                |                     |
Client <----->  | private.example.org |
                |                     |
                | public.example.com  |
                |                     |
                +---------------------+
                        Server
          (Client-Facing and Backend Combined)
]]></artwork>
        </figure>
        <t>In Shared Mode, shared mode, the provider is the origin server for all the domains whose DNS
records point to it. In this mode, the TLS connection is terminated by the
provider.</t>
        <figure anchor="split-mode">
          <name>Split Mode Topology</name>
          <artwork><![CDATA[
           +--------------------+     +---------------------+
           |                    |     |                     |
           |   2001:DB8::1111   |     |   2001:DB8::EEEE    |
Client <----------------------------->|                     |
           | public.example.com |     | private.example.org |
           |                    |     |                     |
           +--------------------+     +---------------------+
            Client-Facing Server            Backend Server
]]></artwork>
        </figure>
        <t>In Split Mode, split mode, the provider is not the origin server for private domains.
Rather, the DNS records for private domains point to the provider, and the
provider's server relays the connection back to the origin server, who
terminates the TLS connection with the client. Importantly, the service provider
does not have access to the plaintext of the connection beyond the unencrypted
portions of the handshake.</t>
        <t>In the remainder of this document, we will refer to the ECH-service provider as
the "client-facing server" and to the TLS terminator as the "backend server".
These are the same entity in Shared Mode, shared mode, but in Split Mode, split mode, the client-facing
and backend servers are physically separated.</t>
        <t>See <xref target="security-considerations"/> for more discussion about the ECH threat model
and how it relates to the client, client-facing server, and backend server.</t>
      </section>
      <section anchor="encrypted-clienthello-ech">
        <name>Encrypted ClientHello (ECH)</name>
        <t>A client-facing server enables ECH by publishing an ECH configuration, which
is an encryption public key and associated metadata. Domains which wish to
use ECH must publish this configuration, using the key associated
with the client-facing server. This document
defines the ECH configuration's format, but delegates DNS publication details
to <xref target="RFC9460"/>. See
<xref target="ECH-IN-DNS"/> target="RFCYYY1"/> for specifics about how ECH configurations
are advertised in SVCB and HTTPS records. Other delivery mechanisms are
also possible. For example, the client may have the ECH configuration
preconfigured.</t>
        <t>When a client wants to establish a TLS session with some backend server, it
constructs a private ClientHello, <tt>ClientHello</tt>, referred to as the ClientHelloInner. <tt>ClientHelloInner</tt>.
The client then constructs a public ClientHello, <tt>ClientHello</tt>, referred to as the
ClientHelloOuter.
<tt>ClientHelloOuter</tt>. The ClientHelloOuter <tt>ClientHelloOuter</tt> contains innocuous values for
sensitive extensions and an "encrypted_client_hello" extension
(<xref target="encrypted-client-hello"/>), which carries the encrypted ClientHelloInner. <tt>ClientHelloInner</tt>.
Finally, the client sends ClientHelloOuter <tt>ClientHelloOuter</tt> to the server.</t>
        <t>The server takes one of the following actions:</t>
        <ol spacing="normal" type="1"><li>
            <t>If it does not support ECH or cannot decrypt the extension, it completes
the handshake with ClientHelloOuter. <tt>ClientHelloOuter</tt>. This is referred to as rejecting ECH.</t>
          </li>
          <li>
            <t>If it successfully decrypts the extension, it forwards the ClientHelloInner <tt>ClientHelloInner</tt>
to the backend server, which completes the handshake. This is referred to
as accepting ECH.</t>
          </li>
        </ol>
        <t>Upon receiving the server's response, the client determines whether or not ECH
was accepted (<xref target="determining-ech-acceptance"/>) and proceeds with the handshake
accordingly. When ECH is rejected, the resulting connection is not usable by
the client for application data. Instead, ECH rejection allows the client to
retry with up-to-date configuration (<xref target="rejected-ech"/>).</t>
        <t>The primary goal of ECH is to ensure that connections to servers in the same
anonymity set are indistinguishable from one another. Moreover, it should
achieve this goal without affecting any existing security properties of TLS 1.3.
See <xref target="goals"/> for more details about the ECH security and privacy goals.</t>
      </section>
    </section>
    <section anchor="ech-configuration">
      <name>Encrypted ClientHello Configuration</name>
      <t>ECH uses HPKE Hybrid Public Key Encryption (HPKE) for public key encryption <xref target="HPKE"/>. target="RFC9180"/>.
The ECH configuration is defined by the following <tt>ECHConfig</tt> structure.</t>
      <artwork><![CDATA[
    opaque HpkePublicKey<1..2^16-1>;
    uint16 HpkeKemId;              // Defined in RFC9180 RFC 9180
    uint16 HpkeKdfId;              // Defined in RFC9180 RFC 9180
    uint16 HpkeAeadId;             // Defined in RFC9180 RFC 9180
    uint16 ECHConfigExtensionType; // Defined in Section 11.3

    struct {
        HpkeKdfId kdf_id;
        HpkeAeadId aead_id;
    } HpkeSymmetricCipherSuite;

    struct {
        uint8 config_id;
        HpkeKemId kem_id;
        HpkePublicKey public_key;
        HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>;
    } HpkeKeyConfig;

    struct {
        ECHConfigExtensionType type;
        opaque data<0..2^16-1>;
    } ECHConfigExtension;

    struct {
        HpkeKeyConfig key_config;
        uint8 maximum_name_length;
        opaque public_name<1..255>;
        ECHConfigExtension extensions<0..2^16-1>;
    } ECHConfigContents;

    struct {
        uint16 version;
        uint16 length;
        select (ECHConfig.version) {
          case 0xfe0d: ECHConfigContents contents;
        }
    } ECHConfig;
]]></artwork>
      <t>The structure contains the following fields:</t>
      <dl>
        <dt>version</dt>
        <dt>version:</dt>
        <dd>
          <t>The version of ECH for which this configuration is used. The version
is the same as the code point for the
"encrypted_client_hello" extension. Clients MUST ignore any <tt>ECHConfig</tt>
structure with a version they do not support.</t>
        </dd>
        <dt>length</dt>
        <dt>length:</dt>
        <dd>
          <t>The length, in bytes, of the next field. This length field allows
implementations to skip over the elements in such a list where they cannot
parse the specific version of ECHConfig.</t> <tt>ECHConfig</tt>.</t>
        </dd>
        <dt>contents</dt>
        <dt>contents:</dt>
        <dd>
          <t>An opaque byte string whose contents depend on the version. For this
specification, the contents are an <tt>ECHConfigContents</tt> structure.</t>
        </dd>
      </dl>
      <t>The <tt>ECHConfigContents</tt> structure contains the following fields:</t>
      <dl>
        <dt>key_config</dt>
        <dt>key_config:</dt>
        <dd>
          <t>A <tt>HpkeKeyConfig</tt> structure carrying the configuration information
associated with the HPKE public key (an "ECH key"). Note that this
structure contains the <tt>config_id</tt> field, which applies to the entire
ECHConfigContents.</t>
<tt>ECHConfigContents</tt>.</t>
        </dd>
        <dt>maximum_name_length</dt>
        <dt><tt>maximum_name_length</tt>:</dt>
        <dd>
          <t>The longest name of a backend server, if known. If not known, this value can
be set to zero. It is used to compute padding (<xref target="padding"/>) and does not
constrain server name lengths. Names may exceed this length if, e.g.,
the server uses wildcard names or added new names to the anonymity set.</t>
        </dd>
        <dt>public_name</dt>
        <dt>public_name:</dt>
        <dd>
          <t>The DNS name of the client-facing server, i.e., the entity trusted
to update the ECH configuration. This is used to correct misconfigured clients,
as described in <xref target="rejected-ech"/>.</t>
        </dd>
        <dt/>
        <dd>
          <t>See <xref target="auth-public-name"/> for how the client interprets and validates the
public_name.</t>
        </dd>
        <dt>extensions</dt>
        <dt>extensions:</dt>
        <dd>
          <t>A list of ECHConfigExtension values that the client must take into
consideration when generating a ClientHello <tt>ClientHello</tt> message. Each ECHConfigExtension
has a 2-octet type and opaque data value, where the data value is encoded
with a 2-octet integer representing the length of the data, in network byte
order. ECHConfigExtension values are described below (<xref target="config-extensions"/>).</t>
        </dd>
      </dl>
      <t>The <tt>HpkeKeyConfig</tt> structure contains the following fields:</t>
      <dl>
        <dt>config_id</dt>
        <dt><tt>config_id</tt>:</dt>
        <dd>
          <t>A one-byte identifier for the given HPKE key configuration. This is used by
clients to indicate the key used for ClientHello <tt>ClientHello</tt> encryption. <xref target="config-ids"/>
describes how client-facing servers allocate this value.</t>
        </dd>
        <dt>kem_id</dt>
        <dt>kem_id:</dt>
        <dd>
          <t>The HPKE Key Encapsulation Mechanism (KEM) identifier corresponding
to <tt>public_key</tt>. Clients MUST ignore any <tt>ECHConfig</tt> structure with a
key using a KEM they do not support.</t>
        </dd>
        <dt>public_key</dt>
        <dt><tt>public_key</tt>:</dt>
        <dd>
          <t>The HPKE public key used by the client to encrypt ClientHelloInner.</t> <tt>ClientHelloInner</tt>.</t>
        </dd>
        <dt>cipher_suites</dt>
        <dt>cipher_suites:</dt>
        <dd>
          <t>The list of HPKE KDF Key Derivation Function (KDF) and AEAD Authenticated Encryption with Associated Data (AEAD) identifier pairs clients can use for encrypting
ClientHelloInner.
<tt>ClientHelloInner</tt>. See <xref target="real-ech"/> for how clients choose from this list.</t>
        </dd>
      </dl>
      <t>The client-facing server advertises a sequence of ECH configurations to clients,
serialized as follows.</t>
      <artwork><![CDATA[
    ECHConfig ECHConfigList<4..2^16-1>;
]]></artwork>
      <t>The <tt>ECHConfigList</tt> structure contains one or more <tt>ECHConfig</tt> structures in
decreasing order of preference. This allows a server to support multiple
versions of ECH and multiple sets of ECH parameters.</t>
      <section anchor="config-ids">
        <name>Configuration Identifiers</name>
        <t>A client-facing server has a set of known ECHConfig values, <tt>ECHConfig</tt> values with corresponding
private keys. This set SHOULD contain the currently published values, as well as
previous values that may still be in use, since clients may cache DNS records
up to a TTL or longer.</t>
        <t><xref target="client-facing-server"/> describes a trial decryption process for decrypting the
ClientHello.
<tt>ClientHello</tt>. This can impact performance when the client-facing server maintains
many known ECHConfig <tt>ECHConfig</tt> values. To avoid this, the client-facing server SHOULD
allocate distinct <tt>config_id</tt> values for each ECHConfig <tt>ECHConfig</tt> in its known set. The
RECOMMENDED strategy is via rejection sampling, i.e., to randomly select
<tt>config_id</tt> repeatedly until it does not match any known ECHConfig.</t> <tt>ECHConfig</tt>.</t>
        <t>It is not necessary for <tt>config_id</tt> values across different client-facing
servers to be distinct. A backend server may be hosted behind two different
client-facing servers with colliding <tt>config_id</tt> values without any performance
impact. Values may also be reused if the previous ECHConfig <tt>ECHConfig</tt> is no longer in the
known set.</t>
      </section>
      <section anchor="config-extensions">
        <name>Configuration Extensions</name>
        <t>ECH configuration extensions are used to provide room for additional
functionality as needed. The format is as defined in
<xref target="ech-configuration"/> and mirrors <xref section="4.2" sectionFormat="of" target="RFC8446"/>. However,
ECH configuration extension types are maintained by IANA as described
in <xref target="config-extensions-iana"/>.  ECH configuration extensions follow
the same interpretation rules as TLS extensions: extensions MAY appear
in any order, but there MUST NOT be more than one extension of the
same type in the extensions block. Unlike TLS extensions, an extension
can be tagged as mandatory by using an extension type codepoint with
the high order bit set to 1.</t>
        <t>Clients MUST parse the extension list and check for unsupported mandatory
extensions. If an unsupported mandatory extension is present, clients MUST
ignore the <tt>ECHConfig</tt>.</t>
        <t>Any future information or hints that influence ClientHelloOuter <tt>ClientHelloOuter</tt> SHOULD be
specified as ECHConfig <tt>ECHConfig</tt> extensions. This is primarily because the outer
ClientHello
<tt>ClientHello</tt> exists only in support of ECH. Namely, it is both an envelope for
the encrypted inner ClientHello <tt>ClientHello</tt> and an enabler for authenticated key mismatch
signals (see <xref target="server-behavior"/>). In contrast, the inner ClientHello <tt>ClientHello</tt> is the
true ClientHello <tt>ClientHello</tt> used upon ECH negotiation.</t>
      </section>
    </section>
    <section anchor="encrypted-client-hello">
      <name>The "encrypted_client_hello" Extension</name>
      <t>To offer ECH, the client sends an "encrypted_client_hello" extension in the
ClientHelloOuter.
<tt>ClientHelloOuter</tt>. When it does, it MUST also send the extension in
ClientHelloInner.</t>
      <artwork><![CDATA[
<tt>ClientHelloInner</tt>.</t>
      <t>~~
    enum {
       encrypted_client_hello(0xfe0d), (65535)
    } ExtensionType;
]]></artwork>
~~</t>
      <t>The payload of the extension has the following structure:</t>
      <artwork><![CDATA[
    enum { outer(0), inner(1) } ECHClientHelloType;

    struct {
       ECHClientHelloType type;
       select (ECHClientHello.type) {
           case outer:
               HpkeSymmetricCipherSuite cipher_suite;
               uint8 config_id;
               opaque enc<0..2^16-1>;
               opaque payload<1..2^16-1>;
           case inner:
               Empty;
       };
    } ECHClientHello;
]]></artwork>
      <t>The outer extension uses the <tt>outer</tt> variant and the inner extension uses the
<tt>inner</tt> variant. The inner extension has an empty payload, which is included
because TLS servers are not allowed to provide extensions in ServerHello
which were not included in ClientHello. <tt>ClientHello</tt>. The outer extension has the following
fields:</t>
      <dl>
        <dt>config_id</dt>
        <dt><tt>config_id</tt>:</dt>
        <dd>
          <t>The ECHConfigContents.key_config.config_id <tt>ECHConfigContents.key_config.config_id</tt> for the chosen ECHConfig.</t> <tt>ECHConfig</tt>.</t>
        </dd>
        <dt>cipher_suite</dt>
        <dt><tt>cipher_suite</tt>:</dt>
        <dd>
          <t>The cipher suite used to encrypt ClientHelloInner. <tt>ClientHelloInner</tt>. This MUST match a value
provided in the corresponding <tt>ECHConfigContents.cipher_suites</tt> list.</t>
        </dd>
        <dt>enc</dt>
        <dt>enc:</dt>
        <dd>
          <t>The HPKE encapsulated key, key used by servers to decrypt the corresponding
<tt>payload</tt> field. This field is empty in a ClientHelloOuter <tt>ClientHelloOuter</tt> sent in response to
HelloRetryRequest.</t>
        </dd>
        <dt>payload</dt>
        <dt>payload:</dt>
        <dd>
          <t>The serialized and encrypted EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> structure, encrypted
using HPKE as described in <xref target="real-ech"/>.</t>
        </dd>
      </dl>
      <t>When a client offers the <tt>outer</tt> version of an "encrypted_client_hello"
extension, the server MAY include an "encrypted_client_hello" extension in its
EncryptedExtensions message, as described in <xref target="client-facing-server"/>, with the
following payload:</t>
      <artwork><![CDATA[
      <t>~~
    struct {
       ECHConfigList retry_configs;
    } ECHEncryptedExtensions;
]]></artwork>
~~</t>
      <t>The response is valid only when the server used the ClientHelloOuter. <tt>ClientHelloOuter</tt>. If the
server sent this extension in response to the <tt>inner</tt> variant, then the client
MUST abort with an "unsupported_extension" alert.</t>
      <dl>
        <dt>retry_configs</dt>
        <dt>retry_configs:</dt>
        <dd>
          <t>An ECHConfigList <tt>ECHConfigList</tt> structure containing one or more ECHConfig <tt>ECHConfig</tt> structures, in
decreasing order of preference, to be used by the client as described in
<xref target="rejected-ech"/>. These are known as the server's "retry configurations".</t>
        </dd>
      </dl>
      <t>Finally, when the client offers the "encrypted_client_hello", if the payload is
the <tt>inner</tt> variant and the server responds with HelloRetryRequest, it MUST
include an "encrypted_client_hello" extension with the following payload:</t>
      <artwork><![CDATA[
      <t>~~
    struct {
       opaque confirmation[8];
    } ECHHelloRetryRequest;
]]></artwork>
~~</t>
      <t>The value of ECHHelloRetryRequest.confirmation is set to
<tt>hrr_accept_confirmation</tt> as described in <xref target="backend-server-hrr"/>.</t>
      <t>This document also defines the "ech_required" alert, which the client MUST send
when it offered an "encrypted_client_hello" extension that was not accepted by
the server. (See <xref target="alerts"/>.)</t>
      <section anchor="encoding-inner">
        <name>Encoding the ClientHelloInner</name>
        <t>Before encrypting, the client pads and optionally compresses ClientHelloInner <tt>ClientHelloInner</tt>
into a EncodedClientHelloInner an <tt>EncodedClientHelloInner</tt> structure, defined below:</t>
        <artwork><![CDATA[
        <t>~~
    struct {
        ClientHello client_hello;
        uint8 zeros[length_of_padding];
    } EncodedClientHelloInner;
]]></artwork>
~~</t>
        <t>The <tt>client_hello</tt> field is computed by first making a copy of ClientHelloInner <tt>ClientHelloInner</tt>
and setting the <tt>legacy_session_id</tt> field to the empty string. In TLS, this
field uses the ClientHello <tt>ClientHello</tt> structure defined in <xref section="4.1.2" sectionFormat="of" target="RFC8446"/>.
In DTLS, it uses the ClientHello structured <tt>ClientHello</tt> structure defined in
<xref section="5.3" sectionFormat="of" target="RFC9147"/>. This does not include Handshake structure's
four-byte header in TLS, nor twelve-byte header in DTLS. The <tt>zeros</tt> field MUST
be all zeroes of length <tt>length_of_padding</tt> (see <xref target="padding"/>).</t>
        <t>Repeating large extensions, such as "key_share" with post-quantum algorithms,
between ClientHelloInner <tt>ClientHelloInner</tt> and ClientHelloOuter <tt>ClientHelloOuter</tt> can lead to excessive size. To
reduce the size impact, the client MAY substitute extensions which it knows
will be duplicated in ClientHelloOuter. <tt>ClientHelloOuter</tt>. It does so by removing and replacing
extensions from EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> with a single "ech_outer_extensions"
extension, defined as follows:</t>
        <artwork><![CDATA[
        <t>~~
    enum {
       ech_outer_extensions(0xfd00), (65535)
    } ExtensionType; ExtensionType;</t>
        <artwork><![CDATA[
ExtensionType OuterExtensions<2..254>; ~~
]]></artwork>
        <t>OuterExtensions contains the removed ExtensionType values. Each value references
the matching extension in ClientHelloOuter. <tt>ClientHelloOuter</tt>. The values MUST be ordered
contiguously in ClientHelloInner, <tt>ClientHelloInner</tt>, and the "ech_outer_extensions" extension MUST
be inserted in the corresponding position in EncodedClientHelloInner. <tt>EncodedClientHelloInner</tt>.
Additionally, the extensions MUST appear in ClientHelloOuter <tt>ClientHelloOuter</tt> in the same
relative order. However, there is no requirement that they be contiguous. For
example, OuterExtensions may contain extensions A, B, and C, while ClientHelloOuter <tt>ClientHelloOuter</tt>
contains extensions A, D, B, C, E, and F.</t>
        <t>The "ech_outer_extensions" extension can only be included in
EncodedClientHelloInner,
<tt>EncodedClientHelloInner</tt> and MUST NOT appear in either ClientHelloOuter <tt>ClientHelloOuter</tt> or
ClientHelloInner.</t>
<tt>ClientHelloInner</tt>.</t>
        <t>Finally, the client pads the message by setting the <tt>zeros</tt> field to a byte
string whose contents are all zeros and whose length is the amount of padding
to add. <xref target="padding"/> describes a recommended padding scheme.</t>
        <t>The client-facing server computes ClientHelloInner <tt>ClientHelloInner</tt> by reversing this process.
First
First, it parses EncodedClientHelloInner, <tt>EncodedClientHelloInner</tt>, interpreting all bytes after
<tt>client_hello</tt> as padding. If any padding byte is non-zero, the server MUST
abort the connection with an "illegal_parameter" alert.</t>
        <t>Next
        <t>Next, it makes a copy of the <tt>client_hello</tt> field and copies the
<tt>legacy_session_id</tt> field from ClientHelloOuter. <tt>ClientHelloOuter</tt>. It then looks for an
"ech_outer_extensions" extension. If found, it replaces the extension with the
corresponding sequence of extensions in the ClientHelloOuter. <tt>ClientHelloOuter</tt>. The server MUST
abort the connection with an "illegal_parameter" alert if any of the following
are true:</t>
        <ul spacing="normal">
          <li>
            <t>Any referenced extension is missing in ClientHelloOuter.</t> <tt>ClientHelloOuter</tt>.</t>
          </li>
          <li>
            <t>Any extension is referenced in OuterExtensions more than once.</t>
          </li>
          <li>
            <t>"encrypted_client_hello" is referenced in OuterExtensions.</t>
          </li>
          <li>
            <t>The extensions in ClientHelloOuter <tt>ClientHelloOuter</tt> corresponding to those in OuterExtensions
do not occur in the same order.</t>
          </li>
        </ul>
        <t>These requirements prevent an attacker from performing a packet amplification
attack,
attack by crafting a ClientHelloOuter <tt>ClientHelloOuter</tt> which decompresses to a much larger
ClientHelloInner.
<tt>ClientHelloInner</tt>. This is discussed further in <xref target="decompression-amp"/>.</t>
        <t>Implementations SHOULD construct the ClientHelloInner <tt>ClientHelloInner</tt> in linear
time. Quadratic time implementations (such as may happen via naive
copying) create a denial of service denial-of-service risk.
<xref target="linear-outer-extensions"/> describes a linear-time procedure that may be used
for this purpose.</t>
      </section>
      <section anchor="authenticating-outer">
        <name>Authenticating the ClientHelloOuter</name>
        <t>To prevent a network attacker from modifying the <tt>ClientHelloOuter</tt>
while keeping the same encrypted <tt>ClientHelloInner</tt>
(see <xref target="flow-clienthello-malleability"/>), ECH authenticates ClientHelloOuter <tt>ClientHelloOuter</tt>
by passing ClientHelloOuterAAD <tt>ClientHelloOuterAAD</tt> as the associated data for HPKE sealing
and opening operations. The ClientHelloOuterAAD <tt>ClientHelloOuterAAD</tt> is a serialized
ClientHello
<tt>ClientHello</tt> structure, defined in <xref section="4.1.2" sectionFormat="of" target="RFC8446"/> for TLS and
<xref section="5.3" sectionFormat="of" target="RFC9147"/> for DTLS, which matches the ClientHelloOuter <tt>ClientHelloOuter</tt> except
that the <tt>payload</tt> field of the "encrypted_client_hello" is replaced with a byte
string of the same length but whose contents are zeros. This value does not
include Handshake structure's four-byte header in TLS nor twelve-byte header in
DTLS.</t>
      </section>
    </section>
    <section anchor="client-behavior">
      <name>Client Behavior</name>
      <t>Clients that implement the ECH extension behave in one of two ways: either they
offer a real ECH extension, as described in <xref target="real-ech"/>; target="real-ech"/>, or they send a
Generate Random Extensions And Sustain Extensibility (GREASE) <xref target="RFC8701"/>
ECH extension, as described in <xref target="grease-ech"/>. Clients of the latter type do not
negotiate ECH. Instead, they generate a dummy ECH extension that is ignored by
the server. (See <xref target="dont-stick-out"/> for an explanation.) The client offers ECH
if it is in possession of a compatible ECH configuration and sends GREASE ECH
(see <xref target="grease-ech"/>) otherwise.</t>
      <section anchor="real-ech">
        <name>Offering ECH</name>
        <t>To offer ECH, the client first chooses a suitable ECHConfig <tt>ECHConfig</tt> from the server's
ECHConfigList.
<tt>ECHConfigList</tt>. To determine if a given <tt>ECHConfig</tt> is suitable, it checks that
it supports the KEM algorithm identified by <tt>ECHConfig.contents.kem_id</tt>, at
least one KDF/AEAD algorithm identified by <tt>ECHConfig.contents.cipher_suites</tt>,
and the version of ECH indicated by <tt>ECHConfig.contents.version</tt>. <tt>ECHConfig.version</tt>. Once a
suitable configuration is found, the client selects the cipher suite it will
use for encryption. It MUST NOT choose a cipher suite or version not advertised
by the configuration. If no compatible configuration is found, then the client
SHOULD proceed as described in <xref target="grease-ech"/>.</t>
        <t>Next, the client constructs the ClientHelloInner <tt>ClientHelloInner</tt> message just as it does a
standard ClientHello, <tt>ClientHello</tt>, with the exception of the following rules:</t>
        <ol spacing="normal" type="1"><li>
            <t>It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure
the backend server does not negotiate a TLS version that is incompatible with
ECH.</t>
          </li>
          <li>
            <t>It MUST NOT offer to resume any session for TLS 1.2 and below.</t>
          </li>
          <li>
            <t>If it intends to compress any extensions (see <xref target="encoding-inner"/>), it MUST
order those extensions consecutively.</t>
          </li>
          <li>
            <t>It MUST include the "encrypted_client_hello" extension of type <tt>inner</tt> as
described in <xref target="encrypted-client-hello"/>. (This requirement is not applicable
when the "encrypted_client_hello" extension is generated as described in
<xref target="grease-ech"/>.)</t>
          </li>
        </ol>
        <t>The client then constructs EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> as described in
<xref target="encoding-inner"/>. It also computes an HPKE encryption context and <tt>enc</tt> value
as:</t>
        <artwork><![CDATA[
        <t>~~
    pkR = DeserializePublicKey(ECHConfig.contents.public_key)
    enc, context = SetupBaseS(pkR,
                              "tls ech" || 0x00 || ECHConfig)
]]></artwork>
~~</t>
        <t>Next, it constructs a partial ClientHelloOuterAAD <tt>ClientHelloOuterAAD</tt> as it does a standard
ClientHello,
<tt>ClientHello</tt>, with the exception of the following rules:</t>
        <ol spacing="normal" type="1"><li>
            <t>It MUST offer to negotiate TLS 1.3 or above.</t>
          </li>
          <li>
            <t>If it compressed any extensions in EncodedClientHelloInner, <tt>EncodedClientHelloInner</tt>, it MUST copy the
corresponding extensions from ClientHelloInner. <tt>ClientHelloInner</tt>. The copied extensions
additionally MUST be in the same relative order as in ClientHelloInner.</t> <tt>ClientHelloInner</tt>.</t>
          </li>
          <li>
            <t>It MUST copy the legacy_session_id field from ClientHelloInner. <tt>ClientHelloInner</tt>. This
allows the server to echo the correct session ID for TLS 1.3's compatibility
mode (see <xref section="D.4" sectionFormat="of" target="RFC8446"/>) when ECH is negotiated. Note that
compatibility mode is not used in DTLS 1.3, but following this rule will
produce the correct results for both TLS 1.3 and DTLS 1.3.</t>
          </li>
          <li>
            <t>It MAY copy any other field from the ClientHelloInner <tt>ClientHelloInner</tt> except
ClientHelloInner.random.
<tt>ClientHelloInner.random</tt>. Instead, It it MUST generate a fresh
ClientHelloOuter.random
<tt>ClientHelloOuter.random</tt> using a secure random number generator. (See
<xref target="flow-client-reaction"/>.)</t>
          </li>
          <li>
            <t>It SHOULD place the value of <tt>ECHConfig.contents.public_name</tt> in the
"server_name" extension. Clients that do not follow this step, or place a
different value in the "server_name" extension, risk breaking the retry
mechanism described in <xref target="rejected-ech"/> or failing to interoperate with
servers that require this step to be done; see <xref target="client-facing-server"/>.</t>
          </li>
          <li>
            <t>When the client offers the "pre_shared_key" extension in ClientHelloInner, <tt>ClientHelloInner</tt>, it
SHOULD also include a GREASE "pre_shared_key" extension in ClientHelloOuter, <tt>ClientHelloOuter</tt>,
generated in the manner described in <xref target="grease-psk"/>. The client MUST NOT use
this extension to advertise a PSK to the client-facing server. (See
<xref target="flow-clienthello-malleability"/>.) When the client includes a GREASE
"pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes"
from the ClientHelloInner <tt>ClientHelloInner</tt> into the ClientHelloOuter.</t> <tt>ClientHelloOuter</tt>.</t>
          </li>
          <li>
            <t>When the client offers the "early_data" extension in ClientHelloInner, <tt>ClientHelloInner</tt>, it
MUST also include the "early_data" extension in ClientHelloOuter. <tt>ClientHelloOuter</tt>. This
allows servers that reject ECH and use ClientHelloOuter <tt>ClientHelloOuter</tt> to safely ignore any
early data sent by the client per <xref section="4.2.10" sectionFormat="comma" target="RFC8446"/>.</t>
          </li>
        </ol>
        <t>The client might duplicate non-sensitive extensions in both messages. However,
implementations need to take care to ensure that sensitive extensions are not
offered in the ClientHelloOuter. <tt>ClientHelloOuter</tt>. See <xref target="outer-clienthello"/> for additional
guidance.</t>
        <t>Finally, the client encrypts the EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> with the above values,
as described in <xref target="encrypting-clienthello"/>, to construct a ClientHelloOuter. <tt>ClientHelloOuter</tt>. It
sends this to the server, server and processes the response as described in
<xref target="determining-ech-acceptance"/>.</t>
        <section anchor="encrypting-clienthello">
          <name>Encrypting the ClientHello</name>
          <t>Given an EncodedClientHelloInner, <tt>EncodedClientHelloInner</tt>, an HPKE encryption context and <tt>enc</tt> value,
and a partial ClientHelloOuterAAD, <tt>ClientHelloOuterAAD</tt>, the client constructs a ClientHelloOuter <tt>ClientHelloOuter</tt> as
follows.</t>
          <t>First, the client determines the length L of encrypting EncodedClientHelloInner <tt>EncodedClientHelloInner</tt>
with the selected HPKE AEAD. This is typically the sum of the plaintext length
and the AEAD tag length. The client then completes the ClientHelloOuterAAD <tt>ClientHelloOuterAAD</tt> with
an "encrypted_client_hello" extension. This extension value contains the outer
variant of ECHClientHello <tt>ECHClientHello</tt> with the following fields:</t>
          <ul spacing="normal">
            <li>
              <t><tt>config_id</tt>, the identifier corresponding to the chosen ECHConfig <tt>ECHConfig</tt> structure;</t>
            </li>
            <li>
              <t><tt>cipher_suite</tt>, the client's chosen cipher suite;</t>
            </li>
            <li>
              <t><tt>enc</tt>, as given above; and</t>
            </li>
            <li>
              <t><tt>payload</tt>, a placeholder byte string containing L zeros.</t>
            </li>
          </ul>
          <t>If configuration identifiers (see <xref target="ignored-configs"/>) are to be
ignored, <tt>config_id</tt> SHOULD be set to a randomly generated byte in the
first ClientHelloOuter <tt>ClientHelloOuter</tt> and, in the event of a HelloRetryRequest (HRR),
MUST be left unchanged for the second ClientHelloOuter.</t> <tt>ClientHelloOuter</tt>.</t>
          <t>The client serializes this structure to construct the ClientHelloOuterAAD. <tt>ClientHelloOuterAAD</tt>.
It then computes the final payload as:</t>
          <artwork><![CDATA[
          <t>~~
    final_payload = context.Seal(ClientHelloOuterAAD,
                                 EncodedClientHelloInner)
]]></artwork>
~~</t>
          <t>Including <tt>ClientHelloOuterAAD</tt> as the HPKE AAD binds the <tt>ClientHelloOuter</tt>
to the <tt>ClientHelloInner</tt>, thus preventing attackers from modifying
<tt>ClientHelloOuter</tt> while keeping the same <tt>ClientHelloInner</tt>, as described in
<xref target="flow-clienthello-malleability"/>.</t>
          <t>Finally, the client replaces <tt>payload</tt> with <tt>final_payload</tt> to obtain
ClientHelloOuter.
<tt>ClientHelloOuter</tt>. The two values have the same length, so it is not necessary
to recompute length prefixes in the serialized structure.</t>
          <t>Note this construction requires the "encrypted_client_hello" be computed after
all other extensions. This is possible because the ClientHelloOuter's <tt>ClientHelloOuter</tt>'s
"pre_shared_key" extension is either omitted, omitted or uses a random binder
(<xref target="grease-psk"/>).</t>
        </section>
        <section anchor="grease-psk">
          <name>GREASE PSK</name>
          <t>When offering ECH, the client is not permitted to advertise PSK identities in
the ClientHelloOuter. <tt>ClientHelloOuter</tt>. However, the client can send a "pre_shared_key" extension
in the ClientHelloInner. <tt>ClientHelloInner</tt>. In this case, when resuming a session with the client,
the backend server sends a "pre_shared_key" extension in its ServerHello. This
would appear to a network observer as if the server were sending this
extension without solicitation, which would violate the extension rules
described in <xref target="RFC8446"/>. When offering a PSK in ClientHelloInner, <tt>ClientHelloInner</tt>,
clients SHOULD send a GREASE "pre_shared_key" extension in the
ClientHelloOuter
<tt>ClientHelloOuter</tt> to make it appear to the network as if the extension were
negotiated properly.</t>
          <t>The client generates the extension payload by constructing an <tt>OfferedPsks</tt>
structure (see <xref section="4.2.11" sectionFormat="comma" target="RFC8446"/>) as follows. For each PSK identity
advertised in the ClientHelloInner, <tt>ClientHelloInner</tt>, the client generates a random PSK identity
with the same length. It also generates a random, 32-bit, unsigned integer to
use as the <tt>obfuscated_ticket_age</tt>. Likewise, for each inner PSK binder, the
client generates a random string of the same length.</t>
          <t>Per the rules of <xref target="real-ech"/>, the server is not permitted to resume a
connection in the outer handshake. If ECH is rejected and the client-facing
server replies with a "pre_shared_key" extension in its ServerHello, then the
client MUST abort the handshake with an "illegal_parameter" alert.</t>
        </section>
        <section anchor="padding">
          <name>Recommended Padding Scheme</name>
          <t>If the ClientHelloInner <tt>ClientHelloInner</tt> is encrypted without padding, then the length of
the <tt>ClientHelloOuter.payload</tt> can leak information about <tt>ClientHelloInner</tt>.
In order to prevent this this, the <tt>EncodedClientHelloInner</tt> structure
has a padding field. This section describes a deterministic mechanism for
computing the required amount of padding based on the following
observation: individual extensions can reveal sensitive information through
their length. Thus, each extension in the inner ClientHello <tt>ClientHello</tt> may require
different amounts of padding. This padding may be fully determined by the
client's configuration or may require server input.</t>
          <t>By way of example, clients typically support a small number of application
profiles. For instance, a browser might support HTTP with ALPN values
["http/1.1", "h2"] and WebRTC media with ALPNs ["webrtc", "c-webrtc"]. Clients
SHOULD pad this extension by rounding up to the total size of the longest ALPN
extension across all application profiles. The target padding length of most
ClientHello
<tt>ClientHello</tt> extensions can be computed in this way.</t>
          <t>In contrast, clients do not know the longest SNI value in the client-facing
server's anonymity set without server input. Clients SHOULD use the ECHConfig's <tt>ECHConfig</tt>'s
<tt>maximum_name_length</tt> field as follows, where L M is the <tt>maximum_name_length</tt>
value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If the ClientHelloInner <tt>ClientHelloInner</tt> contained a "server_name" extension with a name of
length D, add max(0, L M - D) bytes of padding.</t>
            </li>
            <li>
              <t>If the ClientHelloInner <tt>ClientHelloInner</tt> did not contain a "server_name" extension (e.g., if
the client is connecting to an IP address), add L M + 9 bytes of padding. This
is the length of a "server_name" extension with an L-byte M-byte name.</t>
            </li>
          </ol>
          <t>Finally, the client SHOULD pad the entire message as follows:</t>
          <ol spacing="normal" type="1"><li>
              <t>Let L be the length of the EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> with all the padding
computed so far.</t>
            </li>
            <li>
              <t>Let N = 31 - ((L - 1) % 32) and add N bytes of padding.</t>
            </li>
          </ol>
          <t>This rounds the length of EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> up to a multiple of 32 bytes,
reducing the set of possible lengths across all clients.</t>
          <t>In addition to padding ClientHelloInner, <tt>ClientHelloInner</tt>, clients and servers will also need to
pad all other handshake messages that have sensitive-length fields. For example,
if a client proposes ALPN values in ClientHelloInner, <tt>ClientHelloInner</tt>, the server-selected value
will be returned in an EncryptedExtension, so that handshake message also needs
to be padded using TLS record layer padding.</t>
        </section>
        <section anchor="determining-ech-acceptance">
          <name>Determining ECH Acceptance</name>
          <t>As described in <xref target="server-behavior"/>, the server may either accept ECH and use
ClientHelloInner
<tt>ClientHelloInner</tt> or reject it and use ClientHelloOuter. <tt>ClientHelloOuter</tt>. This is determined by
the server's initial message.</t>
          <t>If the message does not negotiate TLS 1.3 or higher, the server has rejected
ECH. Otherwise, it is either a ServerHello or HelloRetryRequest.</t>
          <t>If the message is a ServerHello, the client computes <tt>accept_confirmation</tt> as
described in <xref target="backend-server"/>. If this value matches the last 8 bytes of
<tt>ServerHello.random</tt>, the server has accepted ECH. Otherwise, it has rejected
ECH.</t>
          <t>If the message is a HelloRetryRequest, the client checks for the
"encrypted_client_hello" extension. If none is found, the server has rejected
ECH. Otherwise, if it has a length other than 8, the client aborts the handshake
with a "decode_error" alert. Otherwise, the client computes
<tt>hrr_accept_confirmation</tt> as described in <xref target="backend-server-hrr"/>. If this value
matches the extension payload, the server has accepted ECH. Otherwise, it has
rejected ECH.</t>
          <t>If the server accepts ECH, the client handshakes with ClientHelloInner <tt>ClientHelloInner</tt> as
described in <xref target="accepted-ech"/>. Otherwise, the client handshakes with
ClientHelloOuter
<tt>ClientHelloOuter</tt> as described in <xref target="rejected-ech"/>.</t>
          <!-- [rfced] In the following sentence, does "length other than 8" refer to
bytes? If yes, may we update as follows?

Current:
Otherwise, if it has a length other than 8, the client aborts the
handshake with a "decode_error" alert.

Perhaps:
Otherwise, if it has a length other than 8 bytes, the client aborts
the handshake with a "decode_error" alert.  -->

</section>
        <section anchor="accepted-ech">
          <name>Handshaking with ClientHelloInner</name>
          <t>If the server accepts ECH, the client proceeds with the connection as in
<xref target="RFC8446"/>, with the following modifications:</t>
          <t>The client behaves as if it had sent ClientHelloInner <tt>ClientHelloInner</tt> as the ClientHello. <tt>ClientHello</tt>. That
is, it evaluates the handshake using the ClientHelloInner's <tt>ClientHelloInner</tt>'s preferences, and,
when computing the transcript hash (<xref section="4.4.1" sectionFormat="of" target="RFC8446"/>), it uses
ClientHelloInner
<tt>ClientHelloInner</tt> as the first ClientHello.</t> <tt>ClientHello</tt>.</t>
          <t>If the server responds with a HelloRetryRequest, the client computes the updated
ClientHello
<tt>ClientHello</tt> message as follows:</t>
          <ol spacing="normal" type="1"><li>
              <t>It computes a second ClientHelloInner <tt>ClientHelloInner</tt> based on the first ClientHelloInner, <tt>ClientHelloInner</tt>, as
in <xref section="4.1.4" sectionFormat="of" target="RFC8446"/>. The ClientHelloInner's <tt>ClientHelloInner</tt>'s
"encrypted_client_hello" extension is left unmodified.</t>
            </li>
            <li>
              <t>It constructs EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> as described in <xref target="encoding-inner"/>.</t>
            </li>
            <li>
              <t>It constructs a second partial ClientHelloOuterAAD <tt>ClientHelloOuterAAD</tt> message. This message MUST
be syntactically valid. The extensions MAY be copied from the original
ClientHelloOuter unmodified,
<tt>ClientHelloOuter</tt> unmodified or omitted. If not sensitive, the client MAY
copy updated extensions from the second ClientHelloInner <tt>ClientHelloInner</tt> for compression.</t>
            </li>
            <li>
              <t>It encrypts EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> as described in
<xref target="encrypting-clienthello"/>, using the second partial ClientHelloOuterAAD, <tt>ClientHelloOuterAAD</tt>, to
obtain a second ClientHelloOuter. <tt>ClientHelloOuter</tt>. It reuses the original HPKE encryption
context computed in <xref target="real-ech"/> and uses the empty string for <tt>enc</tt>.  </t>
              <t>
The HPKE context maintains a sequence number, so this operation internally
uses a fresh nonce for each AEAD operation. Reusing the HPKE context avoids
an attack described in <xref target="flow-hrr-hijack"/>.</t>
            </li>
          </ol>
          <t>The client then sends the second ClientHelloOuter <tt>ClientHelloOuter</tt> to the server. However, as
above, it uses the second ClientHelloInner <tt>ClientHelloInner</tt> for preferences, and both the
ClientHelloInner
<tt>ClientHelloInner</tt> messages for the transcript hash. Additionally, it checks the
resulting ServerHello for ECH acceptance as in <xref target="determining-ech-acceptance"/>.
If the ServerHello does not also indicate ECH acceptance, the client MUST
terminate the connection with an "illegal_parameter" alert.</t>
        </section>
        <section anchor="rejected-ech">
          <name>Handshaking with ClientHelloOuter</name>
          <t>If the server rejects ECH, the client proceeds with the handshake,
authenticating for ECHConfig.contents.public_name <tt>ECHConfig.contents.public_name</tt> as described in
<xref target="auth-public-name"/>. If authentication or the handshake fails, the client MUST
return a failure to the calling application. It MUST NOT use the retry
configurations. It MUST NOT treat this as a secure signal to
disable ECH.</t>
          <t>If the server supplied an "encrypted_client_hello" extension in its
EncryptedExtensions message, the client MUST check that it is syntactically
valid and the client MUST abort the connection with a "decode_error" alert
otherwise. If an earlier TLS version was negotiated, the client MUST NOT enable
the False Start optimization <xref target="RFC7918"/> for this handshake. If both
authentication and the handshake complete successfully, the client MUST perform
the processing described below and then abort the connection with an "ech_required"
alert before sending any application data to the server.</t>
          <t>If the server provided "retry_configs" and if at least one of the
values contains a version supported by the client, the client can
regard the ECH configuration as securely replaced by the server. It
SHOULD retry the handshake with a new transport connection, connection using the
retry configurations supplied by the server.</t>
          <t>Clients can implement a new transport connection in a way that best
suits their deployment. For example, clients can reuse the same server
IP address when establishing the new transport connection or they can
choose to use a different IP address if provided with options from
DNS. ECH does not mandate any specific implementation choices when
establishing this new connection.</t>
          <t>The retry configurations are meant to be used for retried connections. Further
use of retry configurations could yield a tracking vector. In settings where
the client will otherwise already let the server track the client, e.g.,
because the client will send cookies to the server in parallel connections,
using the retry configurations for these parallel connections does not
introduce a new tracking vector.</t>
          <t>If none of the values provided in "retry_configs" contains a supported
version, the server did not supply an "encrypted_client_hello"
extension in its EncryptedExtensions message, or an earlier TLS
version was negotiated, the client can regard ECH as securely disabled
by the server, and it SHOULD retry the handshake with a new transport
connection and ECH disabled.</t>
          <t>Clients SHOULD NOT accept "retry_config" in response to a connection
initiated in response to a "retry_config".  Sending a "retry_config"
in this situation is a signal that the server is misconfigured, e.g.,
the server might have multiple inconsistent configurations so that the
client reached a node with configuration A in the first connection and
a node with configuration B in the second. Note that this guidance
does not apply to the cases in the previous paragraph where the server
has securely disabled ECH.</t>
          <t>If a client does not retry, it MUST report an error to the calling
application.</t>
        </section>
        <section anchor="auth-public-name">
          <name>Authenticating for the Public Name</name>
          <t>When the server rejects ECH, it continues with the handshake using the plaintext
"server_name" extension instead (see <xref target="server-behavior"/>). Clients that offer
ECH then authenticate the connection with the public name, name as follows:</t>
          <ul spacing="normal">
            <li>
              <t>The client MUST verify that the certificate is valid for
ECHConfig.contents.public_name.
<tt>ECHConfig.contents.public_name</tt>. If invalid, it MUST abort the connection with
the appropriate alert.</t>
            </li>
            <li>
              <t>If the server requests a client certificate, the client MUST respond with an
empty Certificate message, denoting no client certificate.</t>
            </li>
          </ul>
          <t>In verifying the client-facing server certificate, the client MUST
interpret the public name as a DNS-based reference identity
<xref target="RFC6125"/>. target="RFC9525"/>. Clients that incorporate DNS names and IP addresses into
the same syntax (e.g. <xref section="7.4" sectionFormat="of" target="RFC3986"/> and <xref target="WHATWG-IPV4"/>)
MUST reject names that would be interpreted as IPv4 addresses.
Clients that enforce this by checking ECHConfig.contents.public_name <tt>ECHConfig.contents.public_name</tt>
do not need to repeat the check when processing ECH rejection.</t>
          <t>Note that authenticating a connection for the public name does not authenticate
it for the origin. The TLS implementation MUST NOT report such connections as
successful to the application. It additionally MUST ignore all session tickets
and session IDs presented by the server. These connections are only used to
trigger retries, as described in <xref target="rejected-ech"/>. This may be implemented, for
instance, by reporting a failed connection with a dedicated error code.</t>
          <t>Prior to attempting a connection, a client SHOULD validate the <tt>ECHConfig</tt>.
Clients SHOULD ignore any
<tt>ECHConfig</tt> structure with a public_name that is not a valid host name in
preferred name syntax (see <xref section="2" sectionFormat="of" target="DNS-TERMS"/>). target="RFC9499"/>).  That is, to be
valid, the public_name needs to be a dot-separated sequence of LDH labels, as
defined in <xref section="2.3.1" sectionFormat="of" target="RFC5890"/>, where:</t>
          <ul spacing="normal">
            <li>
              <t>the sequence does not begin or end with an ASCII dot, and</t>
            </li>
            <li>
              <t>all labels are at most 63 octets.</t>
            </li>
          </ul>
          <t>Clients additionally SHOULD ignore the structure if the final LDH
label either consists of all ASCII digits (i.e. (i.e., '0' through '9') or is
"0x" or "0X" followed by some, possibly empty, sequence of ASCII
hexadecimal digits (i.e. (i.e., '0' through '9', 'a' through 'f', and 'A'
through 'F'). This avoids public_name values that may be interpreted
as IPv4 literals.</t>
        </section>
        <section anchor="impact-of-retry-on-future-connections">
          <name>Impact of Retry on Future Connections</name>
          <t>Clients MAY use information learned from a rejected ECH for future
connections to avoid repeatedly connecting to the same server and
being forced to retry. However, they MUST handle ECH rejection for
those connections as if it were a fresh connection, rather than
enforcing the single retry limit from <xref target="rejected-ech"/>. The reason
for this requirement is that if the server sends a "retry_config"
and then immediately rejects the resulting connection, it is
most likely misconfigured. However, if the server sends a "retry_config"
and then the client tries to use that to connect some time
later, it is possible that the server has changed
its configuration again and is now trying to recover.</t>
          <t>Any persisted information MUST be associated with the ECHConfig <tt>ECHConfig</tt> source
used to bootstrap the connection, such as a DNS SVCB ServiceMode record
<xref target="ECH-IN-DNS"/>. target="RFCYYY1"/>. Clients MUST limit any sharing of persisted ECH-related
state to connections that use the same ECHConfig <tt>ECHConfig</tt> source. Otherwise, it
might become possible for the client to have the wrong public name for
the server, making recovery impossible.</t>
          <t>ECHConfigs learned from ECH rejection can be used as a tracking
vector. Clients SHOULD impose the same lifetime and scope restrictions
that they apply to other server-based
tracking vectors such as PSKs.</t>
          <t>In general, the safest way for clients to minimize ECH retries is to
comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH
configuration.</t>
        </section>
      </section>
      <section anchor="grease-ech">
        <name>GREASE ECH</name>
        <t>The GREASE ECH mechanism allows a connection between and an ECH-capable client
and a non-ECH server to appear to use ECH, thus reducing the extent to
which ECH connections stick out (see <xref target="dont-stick-out"/>).</t>
        <section anchor="client-greasing">
          <name>Client Greasing</name>
          <t>If the client attempts to connect to a server and does not have an ECHConfig <tt>ECHConfig</tt>
structure available for the server, it SHOULD send a GREASE <xref target="RFC8701"/>
"encrypted_client_hello" extension in the first ClientHello <tt>ClientHello</tt> as follows:</t>
          <ul spacing="normal">
            <li>
              <t>Set the <tt>config_id</tt> field to a random byte.</t>
            </li>
            <li>
              <t>Set the <tt>cipher_suite</tt> field to a supported HpkeSymmetricCipherSuite. The
selection SHOULD vary to exercise all supported configurations, but MAY be
held constant for successive connections to the same server in the same
session.</t>
            </li>
            <li>
              <t>Set the <tt>enc</tt> field to a randomly-generated randomly generated valid encapsulated public key
output by the HPKE KEM.</t>
            </li>
            <li>
              <t>Set the <tt>payload</tt> field to a randomly-generated randomly generated string of L+C bytes, where C
is the ciphertext expansion of the selected AEAD scheme and L is the size of
the EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> the client would compute when offering ECH, padded
according to <xref target="padding"/>.</t>
            </li>
          </ul>
          <t>If sending a second ClientHello <tt>ClientHello</tt> in response to a HelloRetryRequest, the
client copies the entire "encrypted_client_hello" extension from the first
ClientHello.
<tt>ClientHello</tt>. The identical value will reveal to an observer that the value of
"encrypted_client_hello" was fake, but this only occurs if there is a
HelloRetryRequest.</t>
          <t>If the server sends an "encrypted_client_hello" extension in either
HelloRetryRequest or EncryptedExtensions, the client MUST check the extension
syntactically and abort the connection with a "decode_error" alert if it is
invalid. It otherwise ignores the extension. It MUST NOT save the
"retry_configs" value in EncryptedExtensions.</t>
          <t>Offering a GREASE extension is not considered offering an encrypted ClientHello <tt>ClientHello</tt>
for purposes of requirements in <xref target="real-ech"/>. In particular, the client
MAY offer to resume sessions established without ECH.</t>
          <!-- [rfced] It seems that "client" was intended to be "clients" (plural) in
the sentence below and updated as follows. Please let us know if that is not
accurate.

Original:
Correctly-implemented client will ignore those extensions.

Current:
Correctly implemented clients will ignore those extensions.
-->

</section>
        <section anchor="server-greasing">
          <name>Server Greasing</name>
          <t><xref target="config-extensions-iana"/> describes a set of Reserved extensions
which will never be registered. These can be used by servers to
"grease" the contents of the ECH configuration, as inspired by
<xref target="RFC8701"/>. This helps ensure clients process ECH extensions
correctly. When constructing ECH configurations, servers SHOULD
randomly select from reserved values with the high-order bit
clear. Correctly-implemented client Correctly implemented clients will ignore those extensions.</t>
          <t>The reserved values with the high-order bit set are mandatory, as
defined in <xref target="config-extensions"/>. Servers SHOULD randomly select from
these values and include them in extraneous ECH configurations.
Correctly-implemented
Correctly implemented clients will ignore these configurations because
they do not recognize the mandatory extension.  Servers SHOULD ensure
that any client using these configurations encounters a warning or error
message.  This can be accomplished in several ways, including:</t>
          <ul spacing="normal">
            <li>
              <t>By giving the extraneous configurations distinctive config IDs or
public names, and rejecting the TLS connection or inserting an
application-level warning message when these are observed.</t>
            </li>
            <li>
              <t>By giving the extraneous configurations an invalid public
key and a public name not associated with the server, server so that
the initial ClientHelloOuter <tt>ClientHelloOuter</tt> will not be decryptable and
the server cannot perform the recovery flow described
in <xref target="rejected-ech"/>.</t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="server-behavior">
      <name>Server Behavior</name>
      <t>As described in <xref target="topologies"/>, servers can play two roles, either as
the client-facing server or as the back-end backend server.
Depending on the server role, the <tt>ECHClientHello</tt> will be different:</t>
      <ul spacing="normal">
        <li>
          <t>A client-facing server expects a an <tt>ECHClientHello.type</tt> of <tt>outer</tt>, and
proceeds as described in <xref target="client-facing-server"/> to extract a
ClientHelloInner,
<tt>ClientHelloInner</tt>, if available.</t>
        </li>
        <li>
          <t>A backend server expects a an <tt>ECHClientHello.type</tt> of <tt>inner</tt>, and
proceeds as described in <xref target="backend-server"/>.</t>
        </li>
      </ul>
      <t>In split mode, a client-facing server which receives a <tt>ClientHello</tt>
with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an
"illegal_parameter" alert. Similarly, in split mode, a backend server
which receives a <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>outer</tt>
MUST abort with an "illegal_parameter" alert.</t>
      <t>In shared mode, a server plays both roles, first decrypting the
<tt>ClientHelloOuter</tt> and then using the contents of the
<tt>ClientHelloInner</tt>.  A shared mode server which receives a
<tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an
"illegal_parameter" alert, because such a <tt>ClientHello</tt> should never
be received directly from the network.</t>
      <t>If <tt>ECHClientHello.type</tt> is not a valid <tt>ECHClientHelloType</tt>, then
the server MUST abort with an "illegal_parameter" alert.</t>
      <t>If the "encrypted_client_hello" is not present, then the server completes the
handshake normally, as described in <xref target="RFC8446"/>.</t>
      <section anchor="client-facing-server">
        <name>Client-Facing Server</name>
        <t>Upon receiving an "encrypted_client_hello" extension in an initial
ClientHello,
<tt>ClientHello</tt>, the client-facing server determines if it will accept ECH, ECH prior
to negotiating any other TLS parameters. Note that successfully decrypting the
extension will result in a new ClientHello <tt>ClientHello</tt> to process, so even the client's TLS
version preferences may have changed.</t>
        <t>First, the server collects a set of candidate ECHConfig <tt>ECHConfig</tt> values. This list is
determined by one of the two following methods:</t>
        <ol spacing="normal" type="1"><li>
            <t>Compare ECHClientHello.config_id <tt>ECHClientHello.config_id</tt> against identifiers of each known ECHConfig <tt>ECHConfig</tt>
and select the ones that match, if any, as candidates.</t>
          </li>
          <li>
            <t>Collect all known ECHConfig <tt>ECHConfig</tt> values as candidates, with trial decryption
below determining the final selection.</t>
          </li>
        </ol>
        <t>Some uses of ECH, such as local discovery mode, may randomize the
ECHClientHello.config_id
<tt>ECHClientHello.config_id</tt> since it can be used as a tracking vector. In such
cases, the second method SHOULD be used for matching the ECHClientHello <tt>ECHClientHello</tt> to a
known ECHConfig. <tt>ECHConfig</tt>. See <xref target="ignored-configs"/>. Unless specified by the application
profile or otherwise externally configured, implementations MUST use the first
method.</t>
        <t>The server then iterates over the candidate ECHConfig <tt>ECHConfig</tt> values, attempting to
decrypt the "encrypted_client_hello" extension as follows.</t>
        <t>The server verifies that the ECHConfig <tt>ECHConfig</tt> supports the cipher suite indicated by
the ECHClientHello.cipher_suite <tt>ECHClientHello.cipher_suite</tt> and that the version of ECH indicated by the
client matches the ECHConfig.version. <tt>ECHConfig.version</tt>. If not, the server continues to the next
candidate ECHConfig.</t> <tt>ECHConfig</tt>.</t>
        <t>Next, the server decrypts ECHClientHello.payload, <tt>ECHClientHello.payload</tt>, using the private key skR
corresponding to ECHConfig, <tt>ECHConfig</tt>, as follows:</t>
        <artwork><![CDATA[
        <t>~~
    context = SetupBaseR(ECHClientHello.enc, skR,
                         "tls ech" || 0x00 || ECHConfig)
    EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
                                           ECHClientHello.payload)
]]></artwork>
        <t>ClientHelloOuterAAD
~~</t>
        <t><tt>ClientHelloOuterAAD</tt> is computed from ClientHelloOuter <tt>ClientHelloOuter</tt> as described in
<xref target="authenticating-outer"/>. The <tt>info</tt> parameter to SetupBaseR is the
concatenation "tls ech", a zero byte, and the serialized ECHConfig. <tt>ECHConfig</tt>. If
decryption fails, the server continues to the next candidate ECHConfig. <tt>ECHConfig</tt>.
Otherwise, the server reconstructs ClientHelloInner <tt>ClientHelloInner</tt> from
EncodedClientHelloInner,
<tt>EncodedClientHelloInner</tt>, as described in <xref target="encoding-inner"/>. It then stops
iterating over the candidate ECHConfig <tt>ECHConfig</tt> values.</t>
        <t>Once the server has chosen the correct ECHConfig, <tt>ECHConfig</tt>, it MAY verify that the value
in the ClientHelloOuter <tt>ClientHelloOuter</tt> "server_name" extension matches the value of
ECHConfig.contents.public_name,
<tt>ECHConfig.contents.public_name</tt> and abort with an "illegal_parameter" alert if
these do not match. This optional check allows the server to limit ECH
connections to only use the public SNI values advertised in its ECHConfigs.
The server MUST be careful not to unnecessarily reject connections if the same
ECHConfig
<tt>ECHConfig</tt> id or keypair is used in multiple ECHConfigs with distinct public
names.</t>
        <t>Upon determining the ClientHelloInner, <tt>ClientHelloInner</tt>, the client-facing server checks that the
message includes a well-formed "encrypted_client_hello" extension of type
<tt>inner</tt> and that it does not offer TLS 1.2 or below. If either of these checks
fails, the client-facing server MUST abort with an "illegal_parameter" alert.</t>
        <t>If these checks succeed, the client-facing server then forwards the
ClientHelloInner
<tt>ClientHelloInner</tt> to the appropriate backend server, which proceeds as in
<xref target="backend-server"/>. If the backend server responds with a HelloRetryRequest, the
client-facing server forwards it, decrypts the client's second ClientHelloOuter <tt>ClientHelloOuter</tt>
using the procedure in <xref target="client-facing-server-hrr"/>, and forwards the resulting
second ClientHelloInner. <tt>ClientHelloInner</tt>. The client-facing server forwards all other TLS
messages between the client and backend server unmodified.</t>
        <t>Otherwise, if all candidate ECHConfig <tt>ECHConfig</tt> values fail to decrypt the extension, the
client-facing server MUST ignore the extension and proceed with the connection
using ClientHelloOuter, <tt>ClientHelloOuter</tt> with the following modifications:</t>
        <ul spacing="normal">
          <li>
            <t>If sending a HelloRetryRequest, the server MAY include an
"encrypted_client_hello" extension with a payload of 8 random bytes; see
<xref target="dont-stick-out"/> for details.</t>
          </li>
          <li>
            <t>If the server is configured with any ECHConfigs, it MUST include the
"encrypted_client_hello" extension in its EncryptedExtensions with the
"retry_configs" field set to one or more ECHConfig <tt>ECHConfig</tt> structures with up-to-date
keys. Servers MAY supply multiple ECHConfig <tt>ECHConfig</tt> values of different versions.
This allows a server to support multiple versions at once.</t>
          </li>
        </ul>
        <t>Note that decryption failure could indicate a GREASE ECH extension (see
<xref target="grease-ech"/>), so it is necessary for servers to proceed with the connection
and rely on the client to abort if ECH was required. In particular, the
unrecognized value alone does not indicate a misconfigured ECH advertisement
(<xref target="misconfiguration"/>). Instead, servers can measure occurrences of the
"ech_required" alert to detect this case.</t>
        <section anchor="client-facing-server-hrr">
          <name>Sending HelloRetryRequest</name>
          <t>After sending or forwarding a HelloRetryRequest, the client-facing server does
not repeat the steps in <xref target="client-facing-server"/> with the second
ClientHelloOuter.
<tt>ClientHelloOuter</tt>. Instead, it continues with the ECHConfig <tt>ECHConfig</tt> selection from the
first ClientHelloOuter <tt>ClientHelloOuter</tt> as follows:</t>
          <t>If the client-facing server accepted ECH, it checks that the second ClientHelloOuter <tt>ClientHelloOuter</tt>
also contains the "encrypted_client_hello" extension. If not, it MUST abort the
handshake with a "missing_extension" alert. Otherwise, it checks that
ECHClientHello.cipher_suite
<tt>ECHClientHello.cipher_suite</tt> and ECHClientHello.config_id <tt>ECHClientHello.config_id</tt> are unchanged, and that
ECHClientHello.enc
<tt>ECHClientHello.enc</tt> is empty. If not, it MUST abort the handshake with an
"illegal_parameter" alert.</t>
          <t>Finally, it decrypts the new ECHClientHello.payload <tt>ECHClientHello.payload</tt> as a second message with the
previous HPKE context:</t>
          <artwork><![CDATA[
          <t>~~
    EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
                                           ECHClientHello.payload)
]]></artwork>
          <t>ClientHelloOuterAAD
~~</t>
          <t><tt>ClientHelloOuterAAD</tt> is computed as described in <xref target="authenticating-outer"/>, but
using the second ClientHelloOuter. <tt>ClientHelloOuter</tt>. If decryption fails, the client-facing
server MUST abort the handshake with a "decrypt_error" alert. Otherwise, it
reconstructs the second ClientHelloInner <tt>ClientHelloInner</tt> from the new EncodedClientHelloInner <tt>EncodedClientHelloInner</tt>
as described in <xref target="encoding-inner"/>, using the second ClientHelloOuter <tt>ClientHelloOuter</tt> for
any referenced extensions.</t>
          <t>The client-facing server then forwards the resulting ClientHelloInner <tt>ClientHelloInner</tt> to the
backend server. It forwards all subsequent TLS messages between the client and
backend server unmodified.</t>
          <t>If the client-facing server rejected ECH, or if the first ClientHello <tt>ClientHello</tt> did not
include an "encrypted_client_hello" extension, the client-facing server
proceeds with the connection as usual. The server does not decrypt the
second ClientHello's ECHClientHello.payload <tt>ClientHello</tt>'s <tt>ECHClientHello.payload</tt> value, if there is one.
Moreover, if the server is configured with any ECHConfigs, it MUST include the
"encrypted_client_hello" extension in its EncryptedExtensions with the
"retry_configs" field set to one or more ECHConfig <tt>ECHConfig</tt> structures with up-to-date
keys, as described in <xref target="client-facing-server"/>.</t>
          <t>Note that a client-facing server that forwards the first ClientHello <tt>ClientHello</tt> cannot
include its own "cookie" extension if the backend server sends a
HelloRetryRequest.  This means that the client-facing server either needs to
maintain state for such a connection or it needs to coordinate with the backend
server to include any information it requires to process the second ClientHello.</t> <tt>ClientHello</tt>.</t>
          <!-- [rfced] May we rephrase the following text for an improved sentence flow?

Original:
The backend server embeds in `ServerHello.random` a string derived from
the inner handshake.

Perhaps:
A string derived from the inner handshake is embedded into
`ServerHello.random` by the backend server.  -->

</section>
      </section>
      <section anchor="backend-server">
        <name>Backend Server</name>
        <t>Upon receipt of an "encrypted_client_hello" extension of type <tt>inner</tt> in a
ClientHello,
<tt>ClientHello</tt>, if the backend server negotiates TLS 1.3 or higher, then it MUST
confirm ECH acceptance to the client by computing its ServerHello as described
here.</t>
        <t>The backend server embeds in ServerHello.random <tt>ServerHello.random</tt> a string derived from the inner
handshake. It begins by computing its ServerHello as usual, except the last 8
bytes of ServerHello.random <tt>ServerHello.random</tt> are set to zero. It then computes the transcript
hash for ClientHelloInner <tt>ClientHelloInner</tt> up to and including the modified ServerHello, as
described in <xref section="4.4.1" sectionFormat="comma" target="RFC8446"/>. Let transcript_ech_conf denote the
output. Finally, the backend server overwrites the last 8 bytes of the
ServerHello.random
<tt>ServerHello.random</tt> with the following string:</t>
        <artwork><![CDATA[
        <t>~~
   accept_confirmation = HKDF-Expand-Label(
      HKDF-Extract(0, ClientHelloInner.random),
      "ech accept confirmation",
      transcript_ech_conf,
      8)
]]></artwork>
~~</t>
        <t>where HKDF-Expand-Label is defined in <xref section="7.1" sectionFormat="comma" target="RFC8446"/>, "0" indicates a
string of Hash.length bytes set to zero, and Hash is the hash function used to
compute the transcript hash. In DTLS, the modified version of HKDF-Expand-Label
defined in <xref section="5.9" sectionFormat="comma" target="RFC9147"/> is used instead.</t>
        <t>The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or
below. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see
<xref section="4.1.3" sectionFormat="comma" target="RFC8446"/>).</t>
        <section anchor="backend-server-hrr">
          <name>Sending HelloRetryRequest</name>
          <t>When the backend server sends HelloRetryRequest in response to the ClientHello, <tt>ClientHello</tt>,
it similarly confirms ECH acceptance by adding a confirmation signal to its
HelloRetryRequest. But instead of embedding the signal in the
HelloRetryRequest.random (the value of which is specified by <xref target="RFC8446"/>), it
sends the signal in an extension.</t>
          <t>The backend server begins by computing HelloRetryRequest as usual, except that
it also contains an "encrypted_client_hello" extension with a payload of 8 zero
bytes. It then computes the transcript hash for the first ClientHelloInner, <tt>ClientHelloInner</tt>,
denoted ClientHelloInner1, up to and including the modified HelloRetryRequest.
Let transcript_hrr_ech_conf denote the output. Finally, the backend server
overwrites the payload of the "encrypted_client_hello" extension with the
following string:</t>
          <artwork><![CDATA[
          <t>~~
   hrr_accept_confirmation = HKDF-Expand-Label(
      HKDF-Extract(0, ClientHelloInner1.random),
      "hrr ech accept confirmation",
      transcript_hrr_ech_conf,
      8)
]]></artwork>
~~</t>
          <t>In the subsequent ServerHello message, the backend server sends the
accept_confirmation
<tt>accept_confirmation</tt> value as described in <xref target="backend-server"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="deployment">
      <name>Deployment Considerations</name>
      <t>The design of ECH as specified in this document necessarily requires changes
to client, client-facing server, and backend server. Coordination between
client-facing and backend server requires care, as deployment mistakes
can lead to compatibility issues. These are discussed in <xref target="compat-issues"/>.</t>
      <t>Beyond coordination difficulties, ECH deployments may also induce challenges
for use cases of information that ECH protects. In particular,
use cases which depend on this unencrypted information may no longer work
as desired. This is elaborated upon in <xref target="no-sni"/>.</t>
      <section anchor="compat-issues">
        <name>Compatibility Issues</name>
        <t>Unlike most TLS extensions, placing the SNI value in an ECH extension is not
interoperable with existing servers, which expect the value in the existing
plaintext extension. Thus Thus, server operators SHOULD ensure servers understand a
given set of ECH keys before advertising them. Additionally, servers SHOULD
retain support for any previously-advertised previously advertised keys for the duration of their
validity.</t>
        <t>However, in more complex deployment scenarios, this may be difficult to fully
guarantee. Thus Thus, this protocol was designed to be robust in case of
inconsistencies between systems that advertise ECH keys and servers, at the cost
of extra round-trips due to a retry. Two specific scenarios are detailed below.</t>
        <section anchor="misconfiguration">
          <name>Misconfiguration and Deployment Concerns</name>
          <t>It is possible for ECH advertisements and servers to become inconsistent. This
may occur, for instance, from DNS misconfiguration, caching issues, or an
incomplete rollout in a multi-server deployment. This may also occur if a server
loses its ECH keys, or if a deployment of ECH must be rolled back on the server.</t>
          <t>The retry mechanism repairs inconsistencies, provided the TLS server
has a certificate for the public name. If server and advertised keys
mismatch, the server will reject ECH and respond with
"retry_configs". If the server does
not understand the "encrypted_client_hello" extension at all, it will ignore it
as required by <xref section="4.1.2" sectionFormat="of" target="RFC8446"/>. Provided the server can present a certificate
valid for the public name, the client can safely retry with updated settings,
as described in <xref target="rejected-ech"/>.</t>
          <t>Unless ECH is disabled as a result of successfully establishing a connection to
the public name, the client MUST NOT fall back to using unencrypted
ClientHellos, as this allows a network attacker to disclose the contents of this
ClientHello,
<tt>ClientHello</tt>, including the SNI. It MAY attempt to use another server from the
DNS results, if one is provided.</t>
          <t>In order to ensure that the retry mechanism works successfully successfully, servers
SHOULD ensure that every endpoint which might receive a TLS connection
is provisioned with an appropriate certificate for the public name.
This is especially important during periods of server reconfiguration
when different endpoints might have different configurations.</t>
        </section>
        <section anchor="middleboxes">
          <name>Middleboxes</name>
          <!--[rfced] How may we update this sentence to make it clear whether
all the requirements or only some of the requirements require
proxies to act as conforming TLS client and server?

For background, in general, the RPC recommends using nonrestrictive "which"
and restrictive "that". (More details are on
https://www.rfc-editor.org/styleguide/tips/) However, edits to that
usage have not been made in this document. In this specific sentence,
we are asking about the usage because it can affect the understanding
of the statement.

Original:
  The requirements in [RFC8446], Section 9.3 which require proxies to
  act as conforming TLS client and server provide interoperability with
  TLS-terminating proxies even in cases where the server supports ECH
  but the proxy does not, as detailed below.

Option A (all requirements require it):
  The requirements in [RFC8446], Section 9.3, which require proxies to
  act as conforming TLS client and server, provide interoperability with
  TLS-terminating proxies even in cases where the server supports ECH
  but the proxy does not, as detailed below.

Option B (some requirements require it):
  The requirements in [RFC8446], Section 9.3 that require proxies to
  act as conforming TLS client and server provide interoperability with
  TLS-terminating proxies even in cases where the server supports ECH
  but the proxy does not, as detailed below.
-->

<t>The requirements in <xref section="9.3" sectionFormat="comma" target="RFC8446"/> which require proxies to
act as conforming TLS client and server provide interoperability
with TLS-terminating proxies even in cases where the server supports
ECH but the proxy does not, as detailed below.</t>
          <t>The proxy must ignore unknown parameters, parameters and
generate its own ClientHello <tt>ClientHello</tt> containing only parameters it understands. Thus,
when presenting a certificate to the client or sending a ClientHello <tt>ClientHello</tt> to the
server, the proxy will act as if connecting to the ClientHelloOuter <tt>ClientHelloOuter</tt>
server_name, which SHOULD match the public name (see <xref target="real-ech"/>), target="real-ech"/>) without
echoing the "encrypted_client_hello" extension.</t>
          <t>Depending on whether the client is configured to accept the proxy's certificate
as authoritative for the public name, this may trigger the retry logic described
in <xref target="rejected-ech"/> or result in a connection failure. A proxy which is not
authoritative for the public name cannot forge a signal to disable ECH.</t>
        </section>
      </section>
      <section anchor="no-sni">
        <name>Deployment Impact</name>
        <t>Some use cases which depend on information ECH encrypts may break with the
deployment of ECH. The extent of breakage depends on a number of external
factors, including, for example, whether ECH can be disabled, whether or not
the party disabling ECH is trusted to do so, and whether or not client
implementations will fall back to TLS without ECH in the event of disablement.</t>
        <t>Depending on implementation details and deployment settings, use cases
which depend on plaintext TLS information may require fundamentally different
approaches to continue working. For example, in managed enterprise settings,
one approach may be to disable ECH entirely via group policy and for
client implementations to honor this action. Server deployments which
depend on SNI -- e.g., for load balancing -- may no longer function properly
without updates; the nature of those updates is out of scope of this
specification.</t>
        <t>In the context of <xref target="rejected-ech"/>, another approach may be to
intercept and decrypt client TLS connections. The feasibility of alternative
solutions is specific to individual deployments.</t>
      </section>
    </section>
    <section anchor="compliance">
      <name>Compliance Requirements</name>
      <t>In the absence of an application profile standard specifying otherwise,
a compliant ECH application MUST implement the following HPKE cipher suite:</t>
      <ul spacing="normal">
        <li>
          <t>KEM: DHKEM(X25519, HKDF-SHA256) (see <xref section="7.1" sectionFormat="of" target="HPKE"/>)</t> target="RFC9180"/>)</t>
        </li>
        <li>
          <t>KDF: HKDF-SHA256 (see <xref section="7.2" sectionFormat="of" target="HPKE"/>)</t> target="RFC9180"/>)</t>
        </li>
        <li>
          <t>AEAD: AES-128-GCM (see <xref section="7.3" sectionFormat="of" target="HPKE"/>)</t> target="RFC9180"/>)</t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This section contains security considerations for ECH.</t>
      <section anchor="goals">
        <name>Security and Privacy Goals</name>
        <t>ECH considers two types of attackers: passive and active. Passive attackers can
read packets from the network, but they cannot perform any sort of active
behavior such as probing servers or querying DNS. A middlebox that filters based
on plaintext packet contents is one example of a passive attacker. In contrast,
active attackers can also write packets into the network for malicious purposes,
such as interfering with existing connections, probing servers, and querying
DNS. In short, an active attacker corresponds to the conventional threat model
<xref target="RFC3552"/> for TLS 1.3 <xref target="RFC8446"/>.</t>
        <t>Passive and active attackers can exist anywhere in the network, including
between the client and client-facing server, as well as between the
client-facing and backend servers when running ECH in Split Mode. split mode. However,
for Split Mode split mode in particular, ECH makes two additional assumptions:</t>
        <ol spacing="normal" type="1"><li>
            <t>The channel between each client-facing and each backend server is
authenticated such that the backend server only accepts messages from trusted
client-facing servers. The exact mechanism for establishing this authenticated
channel is out of scope for this document.</t>
          </li>
          <li>
            <t>The attacker cannot correlate messages between a client and client-facing
server with messages between client-facing and backend server. Such correlation
could allow an attacker to link information unique to a backend server, such as
their server name or IP address, with a client's encrypted ClientHelloInner. <tt>ClientHelloInner</tt>.
Correlation could occur through timing analysis of messages across the
client-facing server, or via examining the contents of messages sent between
client-facing and backend servers. The exact mechanism for preventing this sort
of correlation is out of scope for this document.</t>
          </li>
        </ol>
        <t>Given this threat model, the primary goals of ECH are as follows.</t>
        <ol spacing="normal" type="1"><li>
            <t>Security preservation. Use of ECH does not weaken the security properties of
TLS without ECH.</t>
          </li>
          <li>
            <t>Handshake privacy. TLS connection establishment to a server name
within an anonymity set is indistinguishable from a connection to
any other server name within the anonymity set. (The anonymity set
is defined in <xref target="intro"/>.)</t>
          </li>
          <li>
            <t>Downgrade resistance. An attacker cannot downgrade a connection that
attempts to use ECH to one that does not use ECH.</t>
          </li>
        </ol>
        <t>These properties were formally proven in <xref target="ECH-Analysis"/>.</t>
        <t>With regards to handshake privacy, client-facing server configuration
determines the size of the anonymity set. For example, if a
client-facing server uses distinct ECHConfig <tt>ECHConfig</tt> values for each server
name, then each anonymity set has size k = 1. Client-facing servers
SHOULD deploy ECH in such a way so as to maximize the size of the
anonymity set where possible. This means client-facing servers should
use the same ECHConfig <tt>ECHConfig</tt> for as many server names as possible. An
attacker can distinguish two server names that have different
ECHConfig
<tt>ECHConfig</tt> values based on the ECHClientHello.config_id <tt>ECHClientHello</tt>.<tt>config_id</tt> value.</t>
        <t>This also means public information in a TLS handshake should be
consistent across server names. For example, if a client-facing server
services many backend origin server names, only one of which supports some
cipher suite, it may be possible to identify that server name based on the
contents of the unencrypted handshake message. Similarly, if a backend
origin reuses KeyShare values, then that provides a unique identifier
for that server.</t>
        <t>Beyond these primary security and privacy goals, ECH also aims to hide, to some
extent, the fact that it is being used at all. Specifically, the GREASE ECH
extension described in <xref target="grease-ech"/> does not change the security properties of
the TLS handshake at all. Its goal is to provide "cover" for the real ECH
protocol (<xref target="real-ech"/>), as a means of addressing the "do not stick out"
requirements of <xref target="RFC8744"/>. See <xref target="dont-stick-out"/> for details.</t>
      </section>
      <section anchor="plaintext-dns">
        <name>Unauthenticated and Plaintext DNS</name>
        <t>ECH supports delivery of configurations through the DNS using SVCB or HTTPS
records,
records without requiring any verifiable authenticity or provenance
information <xref target="ECH-IN-DNS"/>. target="RFCYYY1"/>. This means that any attacker which can inject
DNS responses or poison DNS caches, which is a common scenario in
client access networks, can supply clients with fake ECH configurations (so
that the client encrypts data to them) or strip the ECH configurations from
the response. However, in the face of an attacker that controls DNS,
no encryption scheme can work because the attacker can replace the IP
address, thus blocking client connections, or substitute a unique IP
address for each DNS name that was looked up.  Thus, using DNS records
without additional authentication does not make the situation significantly
worse.</t>
        <t>Clearly, DNSSEC (if the client validates and hard fails) is a defense
against this form of attack, but encrypted DNS transport is also a
defense against DNS attacks by attackers on the local network, which
is a common case where ClientHello <tt>ClientHello</tt> and SNI encryption are
desired. Moreover, as noted in the introduction, SNI encryption is
less useful without encryption of DNS queries in transit.</t>
      </section>
      <section anchor="client-tracking">
        <name>Client Tracking</name>
        <t>A malicious client-facing server could distribute unique, per-client ECHConfig <tt>ECHConfig</tt>
structures as a way of tracking clients across subsequent connections. On-path
adversaries which know about these unique keys could also track clients in this
way by observing TLS connection attempts.</t>
        <t>The cost of this type of attack scales linearly with the desired number of
target clients. Moreover, DNS caching behavior makes targeting individual users
for extended periods of time, e.g., using per-client ECHConfig <tt>ECHConfig</tt> structures
delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate
this problem by flushing any DNS or ECHConfig <tt>ECHConfig</tt> state upon changing networks
(this may not be possible if clients use the operating system resolver
rather than doing their own resolution).</t>
        <t>ECHConfig
        <t><tt>ECHConfig</tt> rotation rate is also an issue for non-malicious servers,
which may want to rotate keys frequently to limit exposure if the key
is compromised. Rotating too frequently limits the client anonymity
set. In practice, servers which service many server names and thus
have high loads are the best candidates to be client-facing servers
and so anonymity sets will typically involve many connections even
with fairly fast rotation intervals.</t>
      </section>
      <section anchor="ignored-configs">
        <name>Ignored Configuration Identifiers and Trial Decryption</name>
        <t>Ignoring configuration identifiers may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the client-facing
server in the "encrypted_client_hello" extension. In such settings, clients send
a randomly generated config_id <tt>config_id</tt> in the ECHClientHello. <tt>ECHClientHello</tt>. Servers in these settings
must perform trial decryption since they cannot identify the client's chosen ECH
key using the config_id <tt>config_id</tt> value. As a result, ignoring configuration
identifiers may exacerbate DoS attacks. Specifically, an adversary may send
malicious ClientHello <tt>ClientHello</tt> messages, i.e., those which will not decrypt with any
known ECH key, in order to force wasteful decryption. Servers that support this
feature should, for example, implement some form of rate limiting mechanism to
limit the potential damage caused by such attacks.</t>
        <t>Unless specified by the application using (D)TLS or externally configured,
implementations MUST NOT use this mode.</t>
      </section>
      <section anchor="outer-clienthello">
        <name>Outer ClientHello</name>
        <t>Any information that the client includes in the ClientHelloOuter <tt>ClientHelloOuter</tt> is visible to
passive observers. The client SHOULD NOT send values in the ClientHelloOuter <tt>ClientHelloOuter</tt>
which would reveal a sensitive ClientHelloInner <tt>ClientHelloInner</tt> property, such as the true
server name. It MAY send values associated with the public name in the
ClientHelloOuter.</t>
<tt>ClientHelloOuter</tt>.</t>
        <t>In particular, some extensions require the client send a server-name-specific
value in the ClientHello. <tt>ClientHello</tt>. These values may reveal information about the
true server name. For example, the "cached_info" ClientHello <tt>ClientHello</tt> extension
<xref target="RFC7924"/> can contain the hash of a previously observed server certificate.
The client SHOULD NOT send values associated with the true server name in the
ClientHelloOuter.
<tt>ClientHelloOuter</tt>. It MAY send such values in the ClientHelloInner.</t> <tt>ClientHelloInner</tt>.</t>
        <t>A client may also use different preferences in different contexts. For example,
it may send different ALPN lists to different servers or in different
application contexts. A client that treats this context as sensitive SHOULD NOT
send context-specific values in ClientHelloOuter.</t> <tt>ClientHelloOuter</tt>.</t>
        <t>Values which are independent of the true server name, or other information the
client wishes to protect, MAY be included in ClientHelloOuter. <tt>ClientHelloOuter</tt>. If they match
the corresponding ClientHelloInner, <tt>ClientHelloInner</tt>, they MAY be compressed as described in
<xref target="encoding-inner"/>. However, note that the payload length reveals information
about which extensions are compressed, so inner extensions which only sometimes
match the corresponding outer extension SHOULD NOT be compressed.</t>
        <t>Clients MAY include additional extensions in ClientHelloOuter <tt>ClientHelloOuter</tt> to avoid
signaling unusual behavior to passive observers, provided the choice of value
and value itself are not sensitive. See <xref target="dont-stick-out"/>.</t>
      </section>
      <section anchor="inner-clienthello">
        <name>Inner ClientHello</name>
        <t>Values which depend on the contents of ClientHelloInner, <tt>ClientHelloInner</tt>, such as the
true server name, can influence how client-facing servers process this message.
In particular, timing side channels can reveal information about the contents
of ClientHelloInner. <tt>ClientHelloInner</tt>. Implementations should take such side channels into
consideration when reasoning about the privacy properties that ECH provides.</t>
      </section>
      <section anchor="related-privacy-leaks">
        <name>Related Privacy Leaks</name>
        <t>ECH requires encrypted DNS to be an effective privacy protection mechanism.
However, verifying the server's identity from the Certificate message,
particularly when using the X509 CertificateType, may result in additional
network traffic that may reveal the server identity. Examples of this traffic
may include requests for revocation information, such as OCSP Online Certificate Status Protocol (OCSP) or CRL Certificate Revocation List (CRL) traffic, or requests for repository information, such as authorityInformationAccess. It may also include implementation-specific traffic for additional information sources as part of verification.</t>
        <t>Implementations SHOULD avoid leaking information that may identify the server.
Even when sent over an encrypted transport, such requests may result in indirect
exposure of the server's identity, such as indicating a specific CA or service
being used. To mitigate this risk, servers SHOULD deliver such information
in-band when possible, such as through the use of OCSP stapling, and clients
SHOULD take steps to minimize or protect such requests during certificate
validation.</t>
        <t>Attacks that rely on non-ECH traffic to infer server identity in an ECH
connection are out of scope for this document. For example, a client that
connects to a particular host prior to ECH deployment may later resume a
connection to that same host after ECH deployment. An adversary that observes
this can deduce that the ECH-enabled connection was made to a host that the
client previously connected to and which is within the same anonymity set.</t>
      </section>
      <section anchor="cookies">
        <name>Cookies</name>
        <t><xref section="4.2.2" sectionFormat="of" target="RFC8446"/> defines a cookie value that servers may send in
HelloRetryRequest for clients to echo in the second ClientHello. <tt>ClientHello</tt>. While ECH
encrypts the cookie in the second ClientHelloInner, <tt>ClientHelloInner</tt>, the backend server's
HelloRetryRequest is unencrypted.This unencrypted. This means differences in cookies between
backend servers, such as lengths or cleartext components, may leak information
about the server identity.</t>
        <t>Backend servers in an anonymity set SHOULD NOT reveal information in the cookie
which identifies the server. This may be done by handling HelloRetryRequest
statefully, thus not sending cookies, or by using the same cookie construction
for all backend servers.</t>
        <t>Note that, if the cookie includes a key name, analogous to <xref section="4" sectionFormat="of" target="RFC5077"/>, this may leak information if different backend servers issue
cookies with different key names at the time of the connection. In particular,
if the deployment operates in Split Mode, split mode, the backend servers may not share
cookie encryption keys. Backend servers may mitigate this by either by handling
key rotation with trial decryption, decryption or by coordinating to match key names.</t>
      </section>
      <section anchor="attacks-exploiting-acceptance-confirmation">
        <name>Attacks Exploiting Acceptance Confirmation</name>
        <t>To signal acceptance, the backend server overwrites 8 bytes of its
ServerHello.random
<tt>ServerHello.random</tt> with a value derived from the ClientHelloInner.random. <tt>ClientHelloInner.random</tt>. (See
<xref target="backend-server"/> for details.) This behavior increases the likelihood of the
ServerHello.random
<tt>ServerHello.random</tt> colliding with the ServerHello.random <tt>ServerHello.random</tt> of a previous session,
potentially reducing the overall security of the protocol. However, the
remaining 24 bytes provide enough entropy to ensure this is not a practical
avenue of attack.</t>
        <t>On the other hand, the probability that two 8-byte strings are the same is
non-negligible. This poses a modest operational risk. Suppose the client-facing
server terminates the connection (i.e., ECH is rejected or bypassed): if the
last 8 bytes of its ServerHello.random <tt>ServerHello.random</tt> coincide with the confirmation signal,
then the client will incorrectly presume acceptance and proceed as if the
backend server terminated the connection. However, the probability of a false
positive occurring for a given connection is only 1 in 2^64. This value is
smaller than the probability of network connection failures in practice.</t>
        <t>Note that the same bytes of the ServerHello.random <tt>ServerHello.random</tt> are used to implement
downgrade protection for TLS 1.3 (see <xref section="4.1.3" sectionFormat="comma" target="RFC8446"/>). These
mechanisms do not interfere because the backend server only signals ECH
acceptance in TLS 1.3 or higher.</t>
      </section>
      <section anchor="comparison-against-criteria">
        <name>Comparison Against Criteria</name>
        <t><xref target="RFC8744"/> lists several requirements for SNI encryption.
In this section, we re-iterate reiterate these requirements and assess the ECH design
against them.</t>
        <section anchor="mitigate-cut-and-paste-attacks">
          <name>Mitigate Cut-and-Paste Attacks</name>
          <t>Since servers process either ClientHelloInner <tt>ClientHelloInner</tt> or ClientHelloOuter, <tt>ClientHelloOuter</tt>, and because
ClientHelloInner.random
<tt>ClientHelloInner</tt>.random is encrypted, it is not possible for an attacker to "cut
and paste" the ECH value in a different Client Hello and learn information from
ClientHelloInner.</t>
<tt>ClientHelloInner</tt>.</t>
        </section>
        <section anchor="avoid-widely-shared-secrets">
          <name>Avoid Widely Shared Secrets</name>
          <t>This design depends upon DNS as a vehicle for semi-static public key
distribution. Server operators may partition their private keys
however they see fit provided each server behind an IP address has the
corresponding private key to decrypt a key. Thus, when one ECH key is
provided, sharing is optimally bound by the number of hosts that share
an IP address. Server operators may further limit sharing of private
keys by publishing different DNS records containing ECHConfig <tt>ECHConfig</tt> values
with different public keys using a short TTL.</t>
        </section>
        <section anchor="sni-based-denial-of-service-attacks">
          <name>SNI-Based Denial-of-Service Attacks</name>
          <t>This design requires servers to decrypt ClientHello <tt>ClientHello</tt> messages with ECHClientHello <tt>ECHClientHello</tt>
extensions carrying valid digests. Thus, it is possible for an attacker to force
decryption operations on the server. This attack is bound by the number of valid
transport connections an attacker can open.</t>
        </section>
        <section anchor="dont-stick-out">
          <name>Do Not Stick Out</name>
          <t>As a means of reducing the impact of network ossification, <xref target="RFC8744"/>
recommends SNI-protection mechanisms be designed in such a way that network
operators do not differentiate connections using the mechanism from connections
not using the mechanism. To that end, ECH is designed to resemble a standard
TLS handshake as much as possible. The most obvious difference is the extension
itself: as long as middleboxes ignore it, as required by <xref target="RFC8446"/>, the rest
of the handshake is designed to look very much as usual.</t>
          <t>The GREASE ECH protocol described in <xref target="grease-ech"/> provides a low-risk way to
evaluate the deployability of ECH. It is designed to mimic the real ECH protocol
(<xref target="real-ech"/>) without changing the security properties of the handshake. The
underlying theory is that if GREASE ECH is deployable without triggering
middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH
should be deployable as well. Thus, the strategy for mitigating network
ossification is to deploy GREASE ECH widely enough to disincentivize
differential treatment of the real ECH protocol by the network.</t>
          <t>Ensuring that networks do not differentiate between real ECH and GREASE ECH may
not be feasible for all implementations. While most middleboxes will not treat
them differently, some operators may wish to block real ECH usage but allow
GREASE ECH. This specification aims to provide a baseline security level that
most deployments can achieve easily, easily while providing implementations enough
flexibility to achieve stronger security where possible. Minimally, real ECH is
designed to be indifferentiable from GREASE ECH for passive adversaries with
following capabilities:</t>
          <ol spacing="normal" type="1"><li>
              <t>The attacker does not know the ECHConfigList <tt>ECHConfigList</tt> used by the server.</t>
            </li>
            <li>
              <t>The attacker keeps per-connection state only. In particular, it does not
track endpoints across connections.</t>
            </li>
          </ol>
          <t>Moreover, real ECH and GREASE ECH are designed so that the following features
do not noticeably vary to the attacker, i.e., they are not distinguishers:</t>
          <ol spacing="normal" type="1"><li>
              <t>the code points of extensions negotiated in the clear, and their order;</t>
            </li>
            <li>
              <t>the length of messages; and</t>
            </li>
            <li>
              <t>the values of plaintext alert messages.</t>
            </li>
          </ol>
          <t>This leaves a variety of practical differentiators out-of-scope. including,
though not limited to, the following:</t>
          <ol spacing="normal" type="1"><li>
              <t>the value of the configuration identifier;</t>
            </li>
            <li>
              <t>the value of the outer SNI;</t>
            </li>
            <li>
              <t>the TLS version negotiated, which may depend on ECH acceptance;</t>
            </li>
            <li>
              <t>client authentication, which may depend on ECH acceptance; and</t>
            </li>
            <li>
              <t>HRR issuance, which may depend on ECH acceptance.</t>
            </li>
          </ol>
          <t>These can be addressed with more sophisticated implementations, but some
mitigations require coordination between the client and server, and even
across different client and server implementations. These mitigations are
out-of-scope for this specification.</t>
        </section>
        <section anchor="maintain-forward-secrecy">
          <name>Maintain Forward Secrecy</name>
          <t>This design does not provide forward secrecy for the inner ClientHello <tt>ClientHello</tt>
because the server's ECH key is static.  However, the window of
exposure is bound by the key lifetime. It is RECOMMENDED that servers
rotate keys regularly.</t>
        </section>
        <section anchor="enable-multi-party-security-contexts">
          <name>Enable Multi-party Security Contexts</name>
          <t>This design permits servers operating in Split Mode split mode to forward connections
directly to backend origin servers. The client authenticates the identity of
the backend origin server, thereby allowing the backend origin server
to hide behind the client-facing server without the client-facing
server decrypting and reencrypting the connection.</t>
          <t>Conversely, if the DNS records used for configuration are
authenticated, e.g., via DNSSEC,
spoofing a client-facing server operating in Split Mode split mode is not
possible. See <xref target="plaintext-dns"/> for more details regarding plaintext
DNS.</t>
          <t>Authenticating the ECHConfig <tt>ECHConfig</tt> structure naturally authenticates the included
public name. This also authenticates any retry signals from the client-facing
server because the client validates the server certificate against the public
name before retrying.</t>
        </section>
        <section anchor="support-multiple-protocols">
          <name>Support Multiple Protocols</name>
          <t>This design has no impact on application layer protocol negotiation. It may
affect connection routing, server certificate selection, and client certificate
verification. Thus, it is compatible with multiple application and transport
protocols. By encrypting the entire ClientHello, <tt>ClientHello</tt>, this design additionally
supports encrypting the ALPN extension.</t>
        </section>
      </section>
      <section anchor="padding-policy">
        <name>Padding Policy</name>
        <t>Variations in the length of the ClientHelloInner <tt>ClientHelloInner</tt> ciphertext could leak
information about the corresponding plaintext. <xref target="padding"/> describes a
RECOMMENDED padding mechanism for clients aimed at reducing potential
information leakage.</t>
      </section>
      <section anchor="active-attack-mitigations">
        <name>Active Attack Mitigations</name>
        <t>This section describes the rationale for ECH properties and mechanics as
defenses against active attacks. In all the attacks below, the attacker is
on-path between the target client and server. The goal of the attacker is to
learn private information about the inner ClientHello, <tt>ClientHello</tt>, such as the true SNI
value.</t>
        <section anchor="flow-client-reaction">
          <name>Client Reaction Attack Mitigation</name>
          <t>This attack uses the client's reaction to an incorrect certificate as an oracle.
The attacker intercepts a legitimate ClientHello <tt>ClientHello</tt> and replies with a ServerHello,
Certificate, CertificateVerify, and Finished messages, wherein the Certificate
message contains a "test" certificate for the domain name it wishes to query. If
the client decrypted the Certificate and failed verification (or leaked
information about its verification process by a timing side channel), the
attacker learns that its test certificate name was incorrect. As an example,
suppose the client's SNI value in its inner ClientHello <tt>ClientHello</tt> is "example.com," and
the attacker replied with a Certificate for "test.com". If the client produces a
verification failure alert because of the mismatch faster than it would due to
the Certificate signature validation, information about the name leaks. Note
that the attacker can also withhold the CertificateVerify message. In that
scenario, a client which first verifies the Certificate would then respond
similarly and leak the same information.</t>
          <figure anchor="flow-diagram-client-reaction">
            <name>Client reaction attack</name>
            <artwork><![CDATA[
          <t>~~
 Client                         Attacker               Server
   ClientHello
   + key_share
   + ech         ------>         ------&gt;      (intercept)     ----->     -----&gt; X (drop) (drop)</t>
          <figure anchor="flow-diagram-client-reaction">
            <name>Client Reaction Attack</name>
            <artwork><![CDATA[
                         ServerHello
                         + key_share
               {EncryptedExtensions}
               {CertificateRequest*}
                      {Certificate*}
                {CertificateVerify*}
             <------    Alert
             ------> ~~
]]></artwork>
          </figure>
          <t>ClientHelloInner.random
          <t><tt>ClientHelloInner.random</tt> prevents this attack. In particular, since the attacker
does not have access to this value, it cannot produce the right transcript and
handshake keys needed for encrypting the Certificate message. Thus, the client
will fail to decrypt the Certificate and abort the connection.</t>
        </section>
        <section anchor="flow-hrr-hijack">
          <name>HelloRetryRequest Hijack Mitigation</name>
          <t>This attack aims to exploit server HRR state management to recover information
about a legitimate ClientHello <tt>ClientHello</tt> using its own attacker-controlled ClientHello. <tt>ClientHello</tt>.
To begin, the attacker intercepts and forwards a legitimate ClientHello <tt>ClientHello</tt> with an
"encrypted_client_hello" (ech) extension to the server, which triggers a
legitimate HelloRetryRequest in return. Rather than forward the retry to the
client, the attacker attempts to generate its own ClientHello <tt>ClientHello</tt> in response based
on the contents of the first ClientHello <tt>ClientHello</tt> and HelloRetryRequest exchange with the
result that the server encrypts the Certificate to the attacker. If the server
used the SNI from the first ClientHello <tt>ClientHello</tt> and the key share from the second
(attacker-controlled) ClientHello, <tt>ClientHello</tt>, the Certificate produced would leak the
client's chosen SNI to the attacker.</t>
          <figure anchor="flow-diagram-hrr-hijack">
            <name>HelloRetryRequest hijack attack</name>
            <artwork><![CDATA[
          <t>~~
 Client                         Attacker                   Server
   ClientHello
   + key_share
   + ech         ------>         ------&gt;       (forward)        ------->        -------&gt;
                                              HelloRetryRequest
                                                    + key_share
                              (intercept)       <-------       &lt;-------</t>
          <figure anchor="flow-diagram-hrr-hijack">
            <name>HelloRetryRequest Hijack Attack</name>
            <artwork><![CDATA[
                          ClientHello
                          + key_share'
                          + ech'           ------->
                                                ServerHello
                                                + key_share
                                      {EncryptedExtensions}
                                      {CertificateRequest*}
                                             {Certificate*}
                                       {CertificateVerify*}
                                                 {Finished}
                                            <-------
                     (process server flight) ~~
]]></artwork>
          </figure>
          <t>This attack is mitigated by using the same HPKE context for both ClientHello <tt>ClientHello</tt>
messages. The attacker does not possess the context's keys, so it cannot
generate a valid encryption of the second inner ClientHello.</t> <tt>ClientHello</tt>.</t>
          <t>If the attacker could manipulate the second ClientHello, <tt>ClientHello</tt>, it might be possible
for the server to act as an oracle if it required parameters from the first
ClientHello
<tt>ClientHello</tt> to match that of the second ClientHello. <tt>ClientHello</tt>. For example, imagine the
client's original SNI value in the inner ClientHello <tt>ClientHello</tt> is "example.com", and the
attacker's hijacked SNI value in its inner ClientHello <tt>ClientHello</tt> is "test.com". A server
which checks these for equality and changes behavior based on the result can be
used as an oracle to learn the client's SNI.</t>
        </section>
        <section anchor="flow-clienthello-malleability">
          <name>ClientHello Malleability Mitigation</name>
          <t>This attack aims to leak information about secret parts of the encrypted
ClientHello
<tt>ClientHello</tt> by adding attacker-controlled parameters and observing the server's
response. In particular, the compression mechanism described in
<xref target="encoding-inner"/> references parts of a potentially attacker-controlled
ClientHelloOuter
<tt>ClientHelloOuter</tt> to construct ClientHelloInner, <tt>ClientHelloInner</tt>, or a buggy server may
incorrectly apply parameters from ClientHelloOuter <tt>ClientHelloOuter</tt> to the handshake.</t>
          <t>To begin, the attacker first interacts with a server to obtain a resumption
ticket for a given test domain, such as "example.com". Later, upon receipt of a
ClientHelloOuter,
<tt>ClientHelloOuter</tt>, it modifies it such that the server will process the
resumption ticket with ClientHelloInner. <tt>ClientHelloInner</tt>. If the server only accepts resumption
PSKs that match the server name, it will fail the PSK binder check with an
alert when ClientHelloInner <tt>ClientHelloInner</tt> is for "example.com" but silently ignore the PSK
and continue when ClientHelloInner <tt>ClientHelloInner</tt> is for any other name. This introduces an
oracle for testing encrypted SNI values.</t>
          <t>~~
      Client              Attacker                       Server</t>
          <figure anchor="tls-clienthello-malleability">
            <name>Message flow Flow for malleable Malleable ClientHello</name>
            <artwork><![CDATA[
      Client              Attacker                       Server
                                handshake and ticket
                                   for "example.com"
                                   <-------->

  ClientHello
  + key_share
  + ech
     + ech_outer_extensions(pre_shared_key)
  + pre_shared_key
              -------->
                    (intercept)
                    ClientHello
                    + key_share
                    + ech
                       + ech_outer_extensions(pre_shared_key)
                    + pre_shared_key'
                                      -------->
                                                     Alert
                                                     -or-
                                               ServerHello
                                                        ...
                                                  Finished
                                      <-------- ~~
]]></artwork>
          </figure>
          <t>This attack may be generalized to any parameter which the server varies by
server name, such as ALPN preferences.</t>
          <t>ECH mitigates this attack by only negotiating TLS parameters from
ClientHelloInner
<tt>ClientHelloInner</tt> and authenticating all inputs to the ClientHelloInner
(EncodedClientHelloInner <tt>ClientHelloInner</tt>
(<tt>EncodedClientHelloInner</tt> and ClientHelloOuter) <tt>ClientHelloOuter</tt>) with the HPKE AEAD. See
<xref target="authenticating-outer"/>. The decompression process in <xref target="encoding-inner"/>
forbids "encrypted_client_hello" in OuterExtensions. This ensures the
unauthenticated portion of ClientHelloOuter <tt>ClientHelloOuter</tt> is not incorporated into
ClientHelloInner.
<tt>ClientHelloInner</tt>. An earlier iteration of this specification only
encrypted and authenticated the "server_name" extension, which left the overall
ClientHello
<tt>ClientHello</tt> vulnerable to an analogue of this attack.</t>
        </section>
        <section anchor="decompression-amp">
          <name>ClientHelloInner Packet Amplification Mitigation</name>
          <t>Client-facing servers must decompress EncodedClientHelloInners. A malicious
attacker may craft a packet which takes excessive resources to decompress
or may be much larger than the incoming packet:</t>
          <ul spacing="normal">
            <li>
              <t>If looking up a ClientHelloOuter <tt>ClientHelloOuter</tt> extension takes time linear in the number of
extensions, the overall decoding process would take O(M*N) time, where
M is the number of extensions in ClientHelloOuter <tt>ClientHelloOuter</tt> and N is the
size of OuterExtensions.</t>
            </li>
            <li>
              <t>If the same ClientHelloOuter <tt>ClientHelloOuter</tt> extension can be copied multiple times,
an attacker could cause the client-facing server to construct a large
ClientHelloInner
<tt>ClientHelloInner</tt> by including a large extension in ClientHelloOuter, <tt>ClientHelloOuter</tt>
of length L, L and an OuterExtensions list referencing N copies of that
extension. The client-facing server would then use O(N*L) memory in
response to O(N+L) bandwidth from the client. In split-mode, split mode, an
O(N*L) sized
O(N*L)-sized packet would then be transmitted to the
backend server.</t>
            </li>
          </ul>
          <t>ECH mitigates this attack by requiring that OuterExtensions be referenced in
order, that duplicate references be rejected, and by recommending that
client-facing servers use a linear scan to perform decompression. These
requirements are detailed in <xref target="encoding-inner"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="update-of-the-tls-extensiontype-registry">
        <name>Update of the TLS ExtensionType Registry</name>
        <t>IANA is requested to create has created the following entries in the existing registry for
"TLS ExtensionType Values" registry (defined in <xref target="RFC8446"/>):</t>
        <ol spacing="normal" type="1"><li>
            <t>encrypted_client_hello(0xfe0d),
            <t>encrypted_client_hello (0xfe0d), with "TLS 1.3" column values set to
"CH, HRR, EE", "DTLS-Only" column set to "N", and "Recommended" column set
to "Yes".</t> "Y".</t>
          </li>
          <li>
            <t>ech_outer_extensions(0xfd00),
            <t>ech_outer_extensions (0xfd00), with the "TLS 1.3" column values set to "CH",
"DTLS-Only" column set to "N", "Recommended" column set to "Yes", "Y", and the
"Comment" column set to "Only appears in inner CH."</t>
          </li>
        </ol>
      </section>
      <section anchor="alerts">
        <name>Update of the TLS Alert Registry</name>
        <t>IANA is requested to create has created an entry, ech_required(121) ech_required (121) in the existing "TLS
Alerts" registry
for Alerts (defined in <xref target="RFC8446"/>), with the "DTLS-OK" column
set to "Y".</t>
      </section>
      <section anchor="config-extensions-iana">
        <name>ECH Configuration Extension Registry</name>
        <t>IANA is requested to create has created a new "ECHConfig "TLS ECHConfig Extension" registry in a new
"TLS Encrypted Client Hello (ECH) Configuration Extensions" page. registry group. New
registrations need to will list the following attributes:</t>
        <dl spacing="compact">
          <dt>Value:</dt>
          <dd>
            <t>The two-byte identifier for the ECHConfigExtension, i.e., the
ECHConfigExtensionType</t>
          </dd>
          <dt>Extension Name:</dt>
          <dd>
            <t>Name of the ECHConfigExtension</t>
          </dd>
          <dt>Recommended:</dt>
          <dd>
            <t>A "Y" or "N" value indicating if the extension is TLS WG Working Group recommends that the
extension be supported. This column is assigned a value of "N" unless
explicitly requested. Adding a value with a value of "Y" requires Standards
Action <xref target="RFC8126"/>.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>The specification where the ECHConfigExtension is defined</t>
          </dd>
          <dt>Notes:</dt>
          <dd>
            <t>Any notes associated with the entry</t>
          </dd>
        </dl>
        <t>New entries in the "ECHConfig "TLS ECHConfig Extension" registry are subject to the
Specification Required registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126"/>), with the policies described in <xref section="17" sectionFormat="comma" target="RFC8447"/>. IANA
[shall add/has added]
has added the following note to the TLS "TLS ECHConfig Extension Extension"
registry:</t>
        <t>Note:  The role of the designated expert is described in RFC 8447.
      The designated expert <xref target="RFC8126"/> ensures that the specification is
      publicly available.  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a document from
      another standards body, industry consortium, university site, etc.
      The expert may provide more in depth in-depth reviews, but their approval
      should not be taken as an endorsement of the extension.</t>
        <t>This document defines several Reserved values for ECH configuration extensions
to be used for "greasing" as described in <xref target="server-greasing"/>.</t>
        <t>The initial contents for this registry consists of multiple reserved values, values
with the following attributes, which are repeated for each registration:</t>
        <dl spacing="compact">
          <dt>Value:</dt>
          <dd>
            <t>0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A,
0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFA</t>
          </dd>
          <dt>Extension Name:</dt>
          <dd>
            <t>RESERVED</t>
          </dd>
          <dt>Recommended:</dt>
          <dd>
            <t>Y</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>This document</t>
            <t>RFC 9849</t>
          </dd>
          <dt>Notes:</dt>
          <dd>
            <t>Grease entries.</t>
            <t>GREASE entries</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9180" to="HPKE"/>
    <displayreference target="RFC9499" to="DNS-TERMS"/>
    <displayreference target="I-D.kazuho-protected-sni" to="PROTECTED-SNI"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7918.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8447.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7918">
          <front>
            <title>Transport Layer Security (TLS) False Start</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <author fullname="B. Moeller" initials="B." surname="Moeller"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7918"/>
          <seriesInfo name="DOI" value="10.17487/RFC7918"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9147">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t>This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9460">
          <front>
            <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title>
            <author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
            <author fullname="M. Bishop" initials="M." surname="Bishop"/>
            <author fullname="E. Nygren" initials="E." surname="Nygren"/>
            <date month="November" year="2023"/>
            <abstract>
              <t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9460"/>
          <seriesInfo name="DOI" value="10.17487/RFC9460"/>
        </reference>
        <reference anchor="ECH-IN-DNS"> anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcYYY1">
          <front>
            <title>Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title>
            <author initials="B." surname="Schwartz" fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz">
              <organization>Meta Platforms, Inc.</organization> Schwartz">
              <organization/>
            </author>
            <author fullname="Mike Bishop" initials="M." surname="Bishop">
              <organization>Akamai Technologies</organization> surname="Bishop" fullname="Mike Bishop">
              <organization/>
            </author>
            <author fullname="Erik Nygren" initials="E." surname="Nygren">
              <organization>Akamai Technologies</organization> surname="Nygren" fullname="Erik Nygren">
              <organization/>
            </author>
            <date day="12" month="February" year="2025"/>
            <abstract>
              <t>   To use TLS Encrypted ClientHello (ECH) the client needs to learn the
   ECH configuration for a server before it attempts a connection to the
   server.  This specification provides a mechanism for conveying the
   ECH configuration information via DNS, using a SVCB or HTTPS record.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-svcb-ech-07"/>
        </reference>
        <reference anchor="HPKE">
          <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
            <author fullname="B. Lipp" initials="B." surname="Lipp"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
              <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9180"/>
          <seriesInfo name="DOI" value="10.17487/RFC9180"/>
        </reference>
        <reference anchor="RFC6125">
          <front>
            <title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="J. Hodges" initials="J." surname="Hodges"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6125"/>
          <seriesInfo name="DOI" value="10.17487/RFC6125"/>
        </reference>
        <reference anchor="RFC5890">
          <front>
            <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5890"/>
          <seriesInfo name="DOI" value="10.17487/RFC5890"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <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="RFC8447">
          <front>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <author fullname="J. Salowey" initials="J." surname="Salowey"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</t>
              <t>This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</t>
            </abstract> year="2025" month="December"/>
          </front>
          <seriesInfo name="RFC" value="8447"/> value="YYY1"/>
          <seriesInfo name="DOI" value="10.17487/RFC8447"/> value="10.17487/RFCYYY1"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="WHATWG-IPV4" target="https://url.spec.whatwg.org/#concept-ipv4-parser">
          <front>
            <title>URL Living Standard - IPv4 Parser</title>
            <author>
              <organization/>
              <organization>WHATWG</organization>
            </author>
            <date year="2021" month="May"/>
          </front>
          <refcontent>WHATWG Living Standard</refcontent>
        </reference>
        <reference anchor="ECH-Analysis" target="https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf">
          <front>
            <title>A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="RFC7301">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <author fullname="S. Friedl" initials="S." surname="Friedl"/>
            <author fullname="A. Popov" initials="A." surname="Popov"/>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="E. Stephan" initials="E." surname="Stephan"/>
            <date month="July" year="2014"/>
            <abstract>
              <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7301"/>
          <seriesInfo name="DOI" value="10.17487/RFC7301"/>
        </reference>
        <reference anchor="RFC8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RFC7858">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="D. Wessels" initials="D." surname="Wessels"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
              <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="RFC8094">
          <front>
            <title>DNS over Datagram Transport Layer Security (DTLS)</title>
            <author fullname="T. Reddy" initials="T." surname="Reddy"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <author fullname="P. Patil" initials="P." surname="Patil"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.</t>
              <t>This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8094"/>
          <seriesInfo name="DOI" value="10.17487/RFC8094"/>
        </reference>
        <reference anchor="RFC9250">
          <front>
            <title>DNS over Dedicated QUIC Connections</title>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9250"/>
          <seriesInfo name="DOI" value="10.17487/RFC9250"/>
        </reference>
        <reference anchor="RFC8701">
          <front>
            <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title>
            <author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
            <date month="January" year="2020"/>
            <abstract>
              <t>This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8701"/>
          <seriesInfo name="DOI" value="10.17487/RFC8701"/>
        </reference>
        <reference anchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="DNS-TERMS">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="March" year="2024"/>
            <abstract>
              <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t>This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="9499"/>
          <seriesInfo name="DOI" value="10.17487/RFC9499"/>
        </reference>
        <reference anchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> surname="Bhargavan">
              <organization>Inria</organization>
            </author>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. 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="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC8744">
          <front>
            <title>Issues and Requirements for Server Name Identification (SNI) Encryption in TLS</title> initials="V." surname="Cheval">
              <organization>Inria</organization>
            </author>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/> surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date month="July" year="2020"/>
            <abstract>
              <t>This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.</t>
              <t>In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.</t>
            </abstract> year="2022" month="November"/>
          </front>
          <seriesInfo name="RFC" value="8744"/>
          <seriesInfo name="DOI" value="10.17487/RFC8744"/>
        </reference>
        <reference anchor="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"/>
            <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 value="10.1145/3548606.3559360"/>
          <refcontent>CCS '22: Proceedings 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="RFC5077">
          <front>
            <title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
            <author fullname="J. Salowey" initials="J." surname="Salowey"/>
            <author fullname="H. Zhou" initials="H." surname="Zhou"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5077"/>
          <seriesInfo name="DOI" value="10.17487/RFC5077"/>
        </reference>
        <reference anchor="I-D.kazuho-protected-sni">
          <front>
            <title>TLS Extensions for Protecting SNI</title>
            <author fullname="Kazuho Oku" initials="K." surname="Oku">
         </author>
            <date day="18" month="July" year="2017"/>
            <abstract>
              <t>   This memo introduces TLS extensions 2022 ACM SIGSAC Conference on Computer and a DNS Resource Record Type
   that can be used to protect attackers from obtaining the value of the
   Server Name Indication extension being transmitted over a Transport
   Layer Security (TLS) version 1.3 handshake.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kazuho-protected-sni-00"/> Communications Security, pp. 365-379</refcontent>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kazuho-protected-sni.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8744.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"/>
      </references>
    </references>
    <?line 2017?> 2143?>

<section anchor="linear-outer-extensions">
      <name>Linear-time
      <name>Linear-Time Outer Extension Processing</name>
      <t>The following procedure processes the "ech_outer_extensions" extension (see
<xref target="encoding-inner"/>) in linear time, ensuring that each referenced extension
in the ClientHelloOuter <tt>ClientHelloOuter</tt> is included at most once:</t>
      <ol spacing="normal" type="1"><li>
          <t>Let I be initialized to zero and N be set to the number of extensions
in ClientHelloOuter.</t> <tt>ClientHelloOuter</tt>.</t>
        </li>
        <li>
          <t>For each extension type, E, in OuterExtensions:  </t>
          <ul spacing="normal">
            <li>
              <t>If E is "encrypted_client_hello", abort the connection with an
"illegal_parameter" alert and terminate this procedure.</t>
            </li>
            <li>
              <t>While I is less than N and the I-th extension of
ClientHelloOuter
<tt>ClientHelloOuter</tt> does not have type E, increment I.</t>
            </li>
            <li>
              <t>If I is equal to N, abort the connection with an "illegal_parameter"
alert and terminate this procedure.</t>
            </li>
            <li>
              <t>Otherwise, the I-th extension of ClientHelloOuter <tt>ClientHelloOuter</tt> has type E. Copy
it to the EncodedClientHelloInner <tt>EncodedClientHelloInner</tt> and increment I.</t>
            </li>
          </ul>
        </li>
      </ol>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This document draws extensively from ideas in <xref target="I-D.kazuho-protected-sni"/>, but
is a much more limited mechanism because it depends on the DNS for the
protection of the ECH key. Richard Barnes, Christian Huitema, Patrick McManus,
Matthew Prince, Nick Sullivan, Martin Thomson, and David Benjamin <contact fullname="Richard Barnes"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Patrick McManus"/>,
<contact fullname="Matthew Prince"/>, <contact fullname="Nick Sullivan"/>, <contact fullname="Martin Thomson"/>, and <contact fullname="David Benjamin"/> also provided
important ideas and contributions.</t>
    </section>
    <section anchor="change-log">
      <name>Change Log</name>
      <ul empty="true">
        <li>
          <t><strong>RFC Editor's Note:</strong> Please remove this section prior to publication of a
final version of this document.</t>
        </li>
      </ul>
      <t>Issue and pull request numbers are listed with a leading octothorp.</t>
      <section anchor="since-draft-ietf-tls-esni-16">
        <name>Since draft-ietf-tls-esni-16</name>
        <ul spacing="normal">
          <li>
            <t>Keep-alive</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-15">
        <name>Since draft-ietf-tls-esni-15</name>
        <ul spacing="normal">
          <li>
            <t>Add CCS2022 reference and summary (#539)</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-14">
        <name>Since draft-ietf-tls-esni-14</name>
        <ul spacing="normal">
          <li>
            <t>Keep-alive</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-13">
        <name>Since draft-ietf-tls-esni-13</name>
        <ul spacing="normal">
          <li>
            <t>Editorial improvements</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-12">
        <name>Since draft-ietf-tls-esni-12</name>
        <ul spacing="normal">
          <li>
            <t>Abort on duplicate OuterExtensions (#514)</t>
          </li>
          <li>
            <t>Improve EncodedClientHelloInner definition (#503)</t>
          </li>
          <li>
            <t>Clarify retry configuration usage (#498)</t>
          </li>
          <li>
            <t>Expand on config_id generation implications (#491)</t>
          </li>
          <li>
            <t>Server-side acceptance signal extension GREASE (#481)</t>
          </li>
          <li>
            <t>Refactor overview, client implementation, and middlebox
sections (#480, #478, #475, #508)</t>
          </li>
          <li>
            <t>Editorial iprovements (#485, #488, #490, #495, #496, #499, #500,
#501, #504, #505, #507, #510, #511)</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-11">
        <name>Since draft-ietf-tls-esni-11</name>
        <ul spacing="normal">
          <li>
            <t>Move ClientHello padding to the encoding (#443)</t>
          </li>
          <li>
            <t>Align codepoints (#464)</t>
          </li>
          <li>
            <t>Relax OuterExtensions checks for alignment with RFC8446 (#467)</t>
          </li>
          <li>
            <t>Clarify HRR acceptance and rejection logic (#470)</t>
          </li>
          <li>
            <t>Editorial improvements (#468, #465, #462, #461)</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-10">
        <name>Since draft-ietf-tls-esni-10</name>
        <ul spacing="normal">
          <li>
            <t>Make HRR confirmation and ECH acceptance explicit (#422, #423)</t>
          </li>
          <li>
            <t>Relax computation of the acceptance signal (#420, #449)</t>
          </li>
          <li>
            <t>Simplify ClientHelloOuterAAD generation (#438, #442)</t>
          </li>
          <li>
            <t>Allow empty enc in ECHClientHello (#444)</t>
          </li>
          <li>
            <t>Authenticate ECHClientHello extensions position in ClientHelloOuterAAD (#410)</t>
          </li>
          <li>
            <t>Allow clients to send a dummy PSK and early_data in ClientHelloOuter when
applicable (#414, #415)</t>
          </li>
          <li>
            <t>Compress ECHConfigContents (#409)</t>
          </li>
          <li>
            <t>Validate ECHConfig.contents.public_name (#413, #456)</t>
          </li>
          <li>
            <t>Validate ClientHelloInner contents (#411)</t>
          </li>
          <li>
            <t>Note split-mode challenges for HRR (#418)</t>
          </li>
          <li>
            <t>Editorial improvements (#428, #432, #439, #445, #458, #455)</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-tls-esni-09">
        <name>Since draft-ietf-tls-esni-09</name>
        <ul spacing="normal">
          <li>
            <t>Finalize HPKE dependency (#390)</t>
          </li>
          <li>
            <t>Move from client-computed to server-chosen, one-byte config
identifier (#376, #381)</t>
          </li>
          <li>
            <t>Rename ECHConfigs to ECHConfigList (#391)</t>
          </li>
          <li>
            <t>Clarify some security and privacy properties (#385, #383)</t>
          </li>
        </ul>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8y9a3PcyJE2+r1+BZaKEyLt7h6RI81IGo93KYozYoxur6jx
rMPrVwS70SSsbqANoEm1ZZ3ffvJalVVAk5S9H45i1xqRuBSqsrLy8uST4/HY
dWW3KJ5m71+eZsfVtNmsumKWHS3KouqyF8ViUbv8/Lwprm68ZFZPq3wJj5k1
+bwbl0U3H3eLdly0VTk+eOSmeVdc1M3madZ2M+fKVfM065p12x08ePDkwYFr
1+fLsm3Luuo2K3jMyfH7n1zeFPnT7PT4yF3XzceLpl6v4K5F6z4WG/jJDC6r
uqKpim78HF/rXNvl1exDvqgreMamaN2qfJr9pauno6ytm64p5i3812aJ//FX
5/J1d1k3T102dhn/Kav2aXY8yd4V7bRuFrn+nD/uuCmnvV/VzUVelf/IOxg8
jmhWrAr4n6rTC4plXi6eZsXH5r+abr6cTOulS1/5yyR783Edv+2X/B/ry9r+
PH7VT3nbLTbJWz7STfXH9X9d4A8GX/Z6kp2uF4vyKq/iN74upx97v4pfeoSr
X180+epykx3VVbtedGV1kb18eZSMpCqnl/UibyetPPD3KBU3DOtokh1Ost/q
ehaP6uiyKduuXl0WTXpBMrZFvZ7NFyA2yVCm+fV/XRb5CgZ6XnbtBCTGOVfV
zRLuvCpAALJ3Px0d7O8/kf/8/sn+46cgptXcXvPbi8P3v/08Pnn7p4f4z0x2
zs6v715mL8srnIZTFMC8mWXj7OTt1cPsbd60RbNDV+fNRdE9zS67btU+/eab
dbOYtKtiOrm+zLvriwl8yzf3pnU1LVawgVZXD8cruhnvncH2eZq9yjfZwYOD
ffjJ8dGL8WGVLzZt2dJY/GAOs9PN8rxegKTqBVk9z942sATTTQYfRPt4f/Jt
dl12l1s29A4/Mxny9fX1ZNpO6k+TfDpZf/xmVdSrRfENfPkU7pxML4urfPHN
an2+KNtvnh39Np5O24ODyWo2p8fxV7yur4rlOawlfMoB/Zy3oXxHFqTCb41n
lzCQ3MgkLjzutabMh2/60wTEBkdz5zuOYsni641EOTcej7P8vO2afAri8/4S
JhbU3nqJkzYDpdCU50Wb5dmymF6CVLZLeHD2vsmrdgW6J3uZb+CjT4vpuim7
TbYLq7CHy+EKXgEUn1wWgdYAHtS2+UWRrUGdNPA7EIYr+A+a32kGSnDCg1qW
s9kCRngP9WFTz9ZT3A/Z53sl/vOLc4cLmOD1xaVf+c+f/wOk/PHDh999+ZLJ
+9tsWbcdykp3WWTwBbP2Mv9YjOArpov1DIcHv3AyiGnRdOW8RL0+wp83RQaz
BEOEX+aL7DrftPj515egBbK8yuoKxBnELe+6fPoRHwCruSjypspWKJpdkfnd
BmPPz+t1RwOBHVEV9EGT7D38e7XI4bOKTx1MJY3kNSgJB2oXx4K37p6+PtnL
4IKiwvMERzEwqXAO8NhgDB9behNLOxxloDQq2ih5dgFbvzJjgNlos1XRXOYr
vonmrMVXoZaw3wBfN+9g7Qq/wVAceAEmqfygIoDpJPmpimu6zn/CCCZrsYAH
bDl8d0Eb7OEq5F0GF9bXbTal38MQa11eHG3ZRFMBv8RPwHfxqk54VKum7uBz
+QNhNmH9ZlmNi5yt4DdVV8JbNuarYeCLGZ6sa1xsus8drlYLXRIW/bfw2Hpa
L7LXYArAM3i1Dl++fb3nQGF0IJX/ibr32wf7X77A/q3Hixrlayaja1lhwWKA
TsNh0Aw1FQ3mqmzL8wV9jIMr5uXFuqE3tDT68+Iyvyrrxkpzu17hxoTn48P9
pdOSTpp2XXYF/cRd1tf4SZusKWArwyUwcfCYeolP4Zk2IgLzgDKAQp9XdbVZ
4m5vi26S7b6G2XO0TOUSFCeuPI1xLMs/zeDILKeFmcogx2DwFA2+EWeBRcmp
MMMvs1mJc4AXzlHT5jBEGGdTgLEyGy9oBWBT4elU4gtg/+H3wPENF7pZOZ/D
Hh6e0zB5Be4G3BnbVqQ//ZO97FfSYqRYQLqCegSjssgXrQiuziRcopNZXTj4
hDyDg7Arp2vQw/RimCGU0asSJmSUnYOimNUwB1XdySNla4uqmjf1kkQyWo4M
PhMWMMdFTvXM82K1qDe0MXGhRIxb/QQ3L/JuLRpvVrbTddvy9v78eeZvBRl2
DnYmfhAODX4NtkexmMPazmGt6WPh82S30SBKtBtxgKKFw7ZU9ZSJelqCLQBz
V8Pi+HXqLhvS8rxVcZarYhFkyQXVKVP9/PVp9vd1gQKBEqTPkXk7eZvlsxnI
SFu0k+xFfY26feSCPsPb/Wq2/jX44xof8OL9+7ensqsfP3z88MuXUeZ/CZLy
zXNUPbLrHz96DGeRXPzgCV2Mm8/f8H9+PTmS3z85ePTgyxcnMmDHgLJpdB+Z
U2AE4EMWaBWD1iZxAAsQfQo8+leq2XHzL/NqYxRim12ifl+ikQsbVia/dbDL
aHng6DHTNGErC46yuikv4LpolVgyCtJFJbwKBL5eLuGcCKKsmz4nOQbjD4Xj
02YC5zr/rqiuyqauULzakVfPTUGjIhmHw3SZNxvYxii3JZws5QXs5gysp3KR
k5TUWX2unwf/mBW8EwpzvN9vvSgGIQ76MhxkkSUBqxv/+Mn+w+91HeFUg0X0
mlYEHK/HeacbV3JAtBO0ZcC5uMIhqF5+XszLqqR/O9oQYABl6Aa22c6rX0/f
74z47+z1G/rvd8cgMe+On+N/n744fPnS/4decfriza8v4fdO/ivcefTm1avj
18/5Zvhplvzo1eGfd1hgdt68fX/y5vXhyx2cFdIO/lBH9dDR2uO2a1ZNgZMH
66vWIs3ks6O32f5DmDFxQWgX0KTufw+7wF1fFiKcdQVKmf9Jx1G+WoEBhc8A
dQ0KfVV2Oe53eEMLZ1aVoVkGThX8EvUyKCE+c0HuCtkH9FZcvRFapvTbb0lx
3cveXKGqLa5dMAro9C5p/CBVBR2ENVhDbL3B+FjLX6NpsaoX9QUqlnKxWKPR
3JHog3Uycqyerwuya2AdwLyHX76qZ8UOT+opCG/HPyCrr0VDa4bHMWpcO3so
s/MajR460kWDw/jvZe/9GJz7f+GPN+31z+/HQ39+37vun+kP+KeD1x08eLD/
9Pmzx0+f7sOf7dcNPU+Muj/QMP6I14lpPCk+5WgwoI/4Fc/rX8eug38cCMLX
jC/9yV3nT/+wwW5+vctfPP4pn5L3A0v/DL0D+PuoXp6DTprt8dJ9fprda0lM
xigI7O3+aCVHl3uzAw4P6EvzK9aUqmZRgPHfrKO9kYDmPggj/ka0PGy1GgQP
zg7HVhRsgrrkQ7vsSCmzQeNfgUos2BH0IjUyQPY3oqB5GJO+UA7O5+/vOtWD
q/bPuy7ooOz+c+BXx/CH747EddufP97p3QNyqe++dQv8e9/97815FguweKTm
j4qziH6QZVRwsSh7ldeTZP+bviCjYTkszOpVizBP3LsczUJ+BNpDKtMDFwc5
t+/jQ8jKMJgJ8samWKDHHxvS2Tl8vT4lGiE637VLLPBk95BrQQ+kOYb9tkTz
I6+6xWbkrWPrCzjvBoC/Atb5FDyp1n+FN37F9LDjLDY1f5r11x2+zhorPiYy
oXXBH7HphYuh7o2e/iM8367h8INrwLXSYWDgLh03Gs34ux3+0vGcpYmnik9E
46rrrKHC4onbORcpkzvIX2jZPfFmqjgWZaIZ0Xsq+zIWjcSRBx29g0/i1eWm
LacSDAAnDfUczM1pUYBh0Uqka0zu4awQfxDMG5S4ZR18pzjgg9YmeDLgYpFm
XdDb0QUvOxIzEpfajHKUDc0bS2s8arYL0igKB0MoiOLc4eDDYPbQdm5pcKDI
OcR5yYcW/TByeiW25Eq0XDUAg18ZQnc0urxt62lJp8Oy6HL02sH59KcPGUnw
Gvhct255ZpZgS+nrWeCSN69bidTxW/wbXLKf4g9EK8sIr5uhsS37svd590lp
LPNOnO9iUVzQsqBa4U9kQxNcC/A6WnTixSF4+N0DjO2AhDj4CW6Gk9djuO3H
k/Hzic8atVfT8zE4dSIrGh1pRUpQGHqDajFdBJ7YFQYmxR0//dPRM5po9kRF
402yN+Qgw7hLuHpj/UeM9JLDtqpbcoYn2U8wAjl87N4g3470zOAcgY4s9Ae0
KX4Duz0EOa5zjc61Xc6LmYvfyfuBVqsFQz0R4RFsA4ywgEW9xhBd7nW3EeYR
65yGLXTREub3J6D5JKog4+kuOcxpHsuiestTnfn9m3XHghS9i36Kj+5Iqsuq
Ahmr1212lS/WBUmSC5FEH+5inw92z47Xxx94rB8uKUERLnW7nz/7i8Yi3XTR
ly97Guad5g2FOXAmiiEFIHPyU0mxr2ilYXhwTva+SZSQVy3v/T+yDg6J1vtD
8PPgouQcJHzq3D4caXPUav7YEg+bpKmmEDn+dFb4AK6NCZcYdESphJ1H+SV7
QrH8DC0O7HL4v2Qlm+JvHG/DV0/CyNo1naHzNap4GUc7MBBYxOscjYkhQaPB
8Vylsixro5+RnLJDo8WHYYRkimkyP2D366rGcOa04DRcWJf7rURt23j3+qgH
KtqC9AHMOE43PNBd+1fAS3cxqsdXw7NRL435d3k1LUDESFLhLJ8WxawNZov/
DgdXg96BexebSUZ6QCIqPO3FbCS2hCZTYx8CB7VuKXZzvnHmG8hnMWF2Pj9O
YBMXOTwTXyILW1eaGDC3w2Q2RQf6j4a8Xo27eowpuliR4efrOFkn74msa6jp
os4XKOfyUZRyaNdke+RRYBx/peZDGSJoSVwW1TiYVGWLU7EGzUhfTtEK3FBw
Ma7WBIyVpqhFI2K8Y72YwUxflgWpZBgIjQu/Dc+MfD4XCccIX/GJH5+pkYLr
t8KToyBrz6dp2JTBJ8WGCx9sidXiH8YCwQlXupcCKsN2x1E02Z/voXhFC/CF
A3BgALTZi7e/HLPBHgwJY17AkYpX/Eiht8d40tJC9Q4njuHgCa9uqVFQZ3A5
D+os4+MA1tJ6q/Uq//u6yF6sPhZvaRi/FJs/7E8mB/93/7vx/h9/oIvWYGzv
f0cX/VIsT2Y/xD7YN99wPI/PaRlv78bZ/F+78RDkP73z1hv9Zx+ranu/WRU/
JDdqlGwfxMPR7TxH2WfvF/qhZx9n8w/l7IfoNzy2LIe//O++0G9ON0uwApty
ekQZqFNMQP2w5R045seyqL1X0ISDbCx7v/HrJQL0AQQovmJoEJIS+8ApsT88
lKV++Ec7engoT9+2IQ/Pb4Z4nzAEkS3UZH94kIjUl4FHbHtZNCLcJh+mMrh4
Bpf5p3K5Xn5ApMmHRVFddJe9wchU4SUk5o8e/fGHG77K2DA3fQL8L2bM2ptW
GKRSAuY/pD9Px9qCEQ737/rnT+TOPfPMDEwK8CMefJoXD2ZP+2MhM40HpTd8
Scf9AysCtnZUPQT7LtYlnBgGW0cG456SeSj/0kMDFRpbAn2HBlUVqL7ZxN7o
JIRHjm2uYYdZIXELfB7aprebjhNRxW1GmYPyokLtjieE0YIufCadlLkfP0Xh
Z7W13UBR8tLIp/I/MO0MmrbDxKtYhBWGImh+xM7hK/lHclq7OE3MB+jHcsUJ
MTLD+Nd0nnL2KKNU+jUhMmh8bEU6AhPxrGmyOV4GERvnVAjgCw4r3QQ4eFxv
SkBTXFQvyxjwlklOTB7KfhPlQ/R94qBK7IXvJZ+tMrOtohifPTiTN15zqwAG
FYCflZ1FCiJ6EDgKG7UhE1E04A7junuLj05nczLvovuCAg7/2NmbZJj+Z6OI
52V48Gdeq5/x8NVMJlMvBD8woAPeam9WYLoGtJqKY11dgMtJyDpc97zvXs6z
j1V9XZELgIJN/xrx1iSfjaA75wUn0evsH0VTw8Wd7lTOuy5X4HBkq3xGUAuw
IeU/1V5Wn0d82TwEL2loPGhw1RHdw3nU4hMa2DwO2SvlfJQVk4vJyAWDnw2l
63IxmyIOr6L70VCezeBuxNbwj2QWY4iGc0bZy5RhUEOna1v4BKZtUkxGfl3g
cYRuLWYY+1ivyKwejBMEJyfMHbg6oMqXZRsCCJrUHrk0fZha5/ANTzM2WxFX
N+YPGuMXiAUrcBaPt9DcJLvcsMTlTGOydjrgweFko01EmsYqj3AGinMvwh5i
Jhi9QueYwCkuigxSZjO7KCr69zYw3CQ7BiN/4JXukhLnB+Ma5qIjs4KTpsGi
4FGNgnI0P8UVgOMCDhGJlIVH4QRdUIwbZqnF5RXtIFIocoHPIj2v2AJUmY5Q
O5MbpijOaFKCFLcLL/04zHjwu27QXbcoQa9ZaPnAmxqTWudUP1zV6NEpuDdS
aKjJbhJZ8EkN4qJkIF7hI5B0DT7WLmbwWSaZ/9ZyBh/pApIS5XRos7V0OspL
VClNUMUv+dPeqy5GQxe8rnwFjjXL2CsPPtr95fjVnv102neE7xLc0Vmwkc/u
ZChkqaHgeAJYmOF9WwyG8B47eHOQyDzHzrsH9vWDWC4y2FX1y27lmXn+E+2O
w+PD53YSVnnZBPQgYsQw8IzLF1CqrvdC0TdNkS9M2DasX4u4NrQZBIqFGhxG
I/I8GHD3gdyWgK+whatpoQZjAvBDpanqEW4vQYP9g4EWvAda67365Qr/9RLG
4r0aNNWDhXsWXTS41yjKJ3GBQWFoCWBXTGF6SBRIJeCnrCiuhR8mW0piNB7p
i+aehAQVgqSWdKtzQaglxSe1qMXlF5iPWWLcquW0RxxoOPFr3maf75kduDUF
wvoVD/1aTAQzl6zMRooHtDtJ49MgyK18Jz5EIDcyjSza6wYhiAufXylm/sHw
8msQOIKxNcVVaSLIdMighdB2mG4juA2K7ShrEZjuZRAvmcLhEaU/3XpFMdDs
/fuXuIxkIOEWArVkZ2HMswCibaHeHQqbBkYpwYNhwJaTqvpjAU6bXSPTgNsL
LPwcDvtV0ZBtieOlc3CbpZFhcogEzxFWbXgh4AXwTVd1yfbSQE5PH8fL4LxG
5bgbjMiaoSFUnxXR6SugRhkFgVxh1ziDlsoY+nOxwfPiqsxNRLLFnAoMxRtP
ddaANNdLSieiO+vsIOD4LdDeht+uQXQXUeQcrHLCmfcmBFO1nUZRqwIXB2OW
+CkDX5hPmxpWL6Bh4zyoQc2dh6mawFkaW9EkanAFggcD4A9xUf7Jbvhkk/2z
ABuMYnH9IfqAJnyrkRrHgjTJ/sSXWeRhU9ABUs4lnS/bx6wiTo+IvoKqwpIO
aI/jkKbxysOYKhyxjJ0nm9kBTanWrmI4mxpOhjnb6QTyyxduvq6m/J8UVIVB
ggOgoQB2xXDoeQhmgqL9/LkfQf3CWrJsmhrV3WcN4j2cHKAy8wBGg3K94QPI
tuSv0M3Ix/PJ4evDCN7nyD7vzc+4zKsc3zYQmTXTxIeX84EOb6jzlc0aE9Lw
uqhWoH1qH/Hq8M+CEsShoMjQ4cN5247MYIVMoqDQGQbqlKF8Bno+Z2wojoIM
a1HY5k3noD8+TrJfq0X5sUiGNKIsuDfUUe2dI5754oJP6SXWTHU1bMtzby6l
803xHQ7v4A6gWbksEexMp+k55gDYH90HgY2MtRD5CI8kY4jQ/pfF9CMJ3roK
AFc/IuPykEOMBtHQdbbeBLGS5CeM/NGD43BiNHaRWXEGoz2EdZmvyaqwNTBo
QpVkVlPFQDVfsBHUS0TKUXpeaKiFpzXsb/sRartz9qZcoKKa5muZoRof6CJT
HVMlLWNPKcjE9ggbGeyfY7q0pK14XneXDHm4AkdmRbvUxSnXEi3GyBnAZWB8
hcDw1piN7kqu/UD7F1xhUvCOwcxtttsKxAS15ljrE9BFQlQe2hRN3nZ87PVf
yNFDB/ZZNJmsk9aYScR9WYUqFVgjd4+0ztaQYvDrPt/bkowGi7KGeUMwEDx/
IMN8p2y36ud+bpcyi3Io0oKQ9NMhgM9PdgCoygHHQa3kolovQ+B4eFC7HEfe
G2W73z169O2jPQ0VR/kT523pVb5Z1PlM/eUwlMs89Vi97fzUWO48JhbR3Qd7
I17Z3f09CU+Hr+EXD8bV+xfGGQgbRzcGG14TR9I5lE6DeWp/rNmHWxMpP6R3
bc3pxOkIWIxeXqF/lUx2Ly9nB0/z1xv88XLVhaTQF5u4CBNifSSaA7OcFIAj
LUe/QcsFzOSqU/ig7Mj+De6MfuNv4IM+vZr8EFAxOEz9TA2Romqj+i44e1Wt
2WoOPLPRECRHKzZAzFlGaT68gcvrFK0u9+oLksJCHmw6Fz3RdoPBGMnSJoHc
ELOe+It9hGaKQfjY0LXSJQ+1xWze5toaOODDgdSGGNRsdSrgUxH3sYc3EJmf
RAGIM/X24cU2wlH40Azr+ZEPdETlKQH9EjuWZ7L4Z1EahfMnGM0jAUGzp39i
thz49NAQxELQr98hIOIdhhtowPIGGbSNLdCZpWfaMQcO0/kMamwULnZs4NAE
DMVyNYTSg4zRyZFsrJDAueHsCDZMgM3C4NA2FFm++8kDzp7zOAbjBUh0djTw
ScNu9MinTUz5hkz303AODalvH47JCL4iW6Q1impghOYc8ovOscPSFNbY+eHd
MgBmI0OwC6XQLQPoyjaeKiNbvGixchsx5i4YAY6P63O0rjh8CItijM0P/uk7
oL8KihxGE8D5uniGevEqCkCZiFUwEkO8anR7wGokPvBAZDKRANdLUEhBD+pi
djJFR3rA1g7DkuIo3w58rgfnJSESuze2yfHI+79ihpQMuk6WxR9SHthO+kY8
856O8HaW+7qt5HOGXyP8crTTvIiT8JfHfzVy3xuekXrOcrDZ3ld19pmZROhA
J55dNs0HBrt9sJecDexzCYHIDh/DnaTE4jp3skYtuHgHZOJDA6Mom2Imgj3y
aAC/wLQ30IqlcjicdFry4o4QUXahENVHp78i+wROpxDoXUmb4RhaGPyewsVr
ZT/oHZls7dPvxyRIYOU/K+a4s0LAPDL1V/mslcQUxzYWG0qXcp1tHzxJVdz5
XY4Yj+jCHNINYhT5PHbCUnAMZnbbv3CW60M9/yAp3CBxw2MyQndmH38WzmbJ
D5PqAKHCEtv8I6dJpvWKyp97E5FTeK3z2bczRJ1PNx8EMR3y5T5BTgYAYxbI
LwRLkPPYbIQFQ9VOSNCYIagUhYz206AR1oI8p2eX3S3PnMWRKn3oo8m38kiu
mPVo/KK1Jmf2wsN7/RPvw8fU64YTeZdFPuMIHg2nQlPxulhcFemvcbhssJ7R
IuvMkSYDtY6VcPgLRkNKnvOsJwln6oiH5D7s+HcUqMVlWmDJehQI0grnHbRt
qaBvh3Xhqm678d/XoIHBycsXF3UDP122IxgNfEJR9XceykMfZw7qYAGfSWbu
J4z2Iqq8BZsNQ+JwXs7WU0HBwM8k+h7tTzSL2vV525UdIhiMWyAuBiMiWnct
yYbZmhG4PY9AjQUJU2MsFikklvWVFjs2xWrBkWUb9sMc2bbtLqlpPJYXojzJ
FgzGQRvZeypuIRf2dKuTP/AsdPFnDx7c5uJzYi2C9dHHB/PrDwcInHv4R9EN
yW/jxDVNEVrV0QM1sUHpfz7MvDXCJzm5LDi127hfTIGCBNPpWDkv2MIB2xzH
ASZHvW452pXOvy+B2zL15tW6leCrCi2a77tOIPalYIu2rfnEHfqQuBYm2BAv
WY2+Ery3IyzQmsqncEMIKkGj3RIK5jSAHMZLtmoZv0HZjDA5BO5yvigmXU1K
tElez4z0cJQ9G2VHdLov+ma180IQ3/NcbzseZT9JyvjW2Z9SDJuCm9Zhd1vm
mNfVh8LDdBYlTk1/VutmKHo2VDxC5z2Jp7A5kXtrjrFIAdNZT8CRYawd4eVE
ObMZwRcoIIpflS/rNVnFCsAiGpXZbGJVdZTIxGzocom8dTMP2mqnl8WyuClJ
L8d432phTUfuKX0m8wegOsYKGzzvy47j8u02sR+FfAepS1S2G2LkmaOwJJYF
6DcZtoTpN/4zGOKCol2NcdpiJxh3KftcgveLyk/RuAQ1D4bG4oPPpwf36zVi
OEsyXmgW1Xbptpk+lHGoV6XGu7aaMHQIDJ4l5DUilwnnY/PK3bYZaEbmSP0z
4hpKPHS0FKrnkbhYQVnoRRwiG3aN3/+vzC36apStSqqnqMYP4/Zwiv0uw7yJ
PwNmcQqG2CSri8ETQO+NbjAPgnt6Ks1kxqYFPWGr13Hbw+ju95dpyHGgZs4u
BBm1NUVt0wfC8SuYono6XUcqXzS9k4pgo9spS3VFPlkVWNlI7iStzPb4Cn8B
F2GuXkG8jq8f4TafIvNmD67HX8AW06ww/g0puCVagWQcDqhRn6EKzErzdUNq
WBiW9HEwkjGMi9zMkwQpHeAl4v4Mem8lZgIrTI92Jai67P+s8xnGG6YZ/jtL
4de7ar5y7SecEhVhGqocDlWHux8mYi/DwAnonBy+vCq5NkpLvpuy/TgBy5/f
OqZdG4H8Iq0sV9FYSH/OfFmVIAww/uLmgrTOVusGDIqCM/aHIY024L3yAn2+
l0dX8YA4U+XFwwMaYylZgtc790jps/TZZ46P+Y9FsfIleVyIrmHTs3Q9zpz4
E3PY7pI8o001XiIBXn5eIhKAqjoJ+mQShf36TId12jlrgfR3h4fPNepkgNyE
BsXJpOBsW+QLLX6vYaUpErbSMvbhOld8bikALgkVR8nUAW/9Fu/SE3Yih9J2
j5EuYyeUNx0Zw31X9I3kJzAA4jw6N4mkq9q9WcPRKTJTj8TaLEpeFoDchDcY
MGXIjJEdzza9x4Xf6PNmW3ze7S6vI5eXeKXYLnsmSeMAFoiJ+TxcO5wSlGdO
mY6Q6fKp2oloKjtO8aJNBXs/esJQeDxE/H/IOLWz4XRt7n5mLHSRvSNYlEXd
HCKnyLolE1t+zJsj2/353fHh6fGeUql9j2yK7tZhXGCwt9AIrU6JrCR4DVTw
jH4YnzROs+MFwwB80SmN/0IHDipwvVxuknnkiW4FRbstDDcDQRmDGz79iFpJ
RJxwISB5Fefl97Jgm2oQGOt3y7kAEuDbsJJfiuqp4AFPD7gbi0r78BsOMmG8
l6eRniZKyU7RHpPsXZeqbd/gy6UeGdSqX9Ubkv4c+GJkLOmMddnlMiyJySt1
oY+Nuyi8TzC/wN+GRpMgty0Qlajb+NFcNY6QFxZ3V3ocMqsKBCn76EsABlOg
LjxzMg0pSsRcn4FEdcjmighjGMgvz3/6hpDFX/OoOGU4cuppJ8ViCjDf+hy5
/mySvUG7NXd+XnuFZWIUR0CMhWc+jXKnZUdkLi6FQ5N53QXXUYDOeXx37Znv
OADtWSqc5k5igD2V3lhJvWHoUQ5JzB6pRr9tn7MHE02A4YAYtJjUi/0bVnLA
4xWEmTP3OpbcmHtClk/OnIAmM5kPQrIJIYKZSt41YDAGXcN12Qc4nxTlDsZi
gHb6+nMlRUiwmT6qGh7L1Buhqk/UU2UWgEBnnICcbB0oVvAvuSxAVU7g2z4Q
IlocdmBYQCcX1Y0UTaFZKxXqXteL+knyDGgEae4Jc0OUo2MPoYgCa1iVjkGf
xSYauJ6vNx70MQQQ1b+my3LinEiEaxsLB+h0WicbWhJIrvAXwBTj83xe7y7Z
6NafMz1Bx2clsr7nbuI72RZv7Scz02WgGaW0lo+G5JXHNygunLTTJ84unsHP
Bc7rchuPXX18l/2YPS+88ejLtXcH9FyoGtmTaO505N/zY3ZadOvVM/j+0114
7mgrKR//2ekWLUaAd7J//jN78OnBA/zbv3SPo7asLMpISQg5L1g6W2xsryAy
VRDuf0NBbFUO31Kx33l9VZhd5h3QWbq5tsddA4SOwjoYGkHgVOSUp2H7IWe2
4IiPiU/Q1slNUNfHoa3nHgdraSr7AeloS+s4Mw4r/Y/Glf6HcEODcSXjctOg
AklIKEEBsahD6Hraed128ty2E7jf+gOLLFF8HhHcif46RHd5Vn7Knk8eRi7O
Hm97pUrW9ZyZglmeefNwfrInR2EFpOyzDG8O4kO+McoQH+G404glv4i+iulX
OKpGOFaVJ89PS4wgMt+Hf+bppigV2f5mggdPTnG64vwrzz+XPRgrWlfUGNJz
GN9lcjeHs/huX2dGLCSFlFJk1Zp6LciDajGvWT8aL3sMqnLKWHnQlPyNakug
n8eWmEIIhswuUyl6phhVVCwsR/TzwcJ7Om0lfMVLxusFM7Ea4V7m91PXhlCX
ITWbclgMv2NE0ZbsHD7to0YgCFlCkukLAW+spsUBzPNyIRE4Ckkr462aBB6s
hl8iR1z4Bi0WAbv4h4x3wjAiikTrtxuALaDBOGU6Q6W/szXN5bUXDk4WkQ4o
D1FR5+bOjyRBozMkHLky+cucpHvYzFy1HwXwEwE50GiCTcsGWoSbojyFGMcw
zrenv8Rcfylr3aAwD4WMwFVM51amo/XzQfK6dUoSSLVXtjvwkXjpB9jgIFIX
xQeiKqYOKtu1AcE6BkPot4lBkTeLzQeMVd1RBMKYY5vvDs8xrGHmeEgEHveL
L0VE/6gXb8I6xnxeYE7VF87i82gIHHYjEF0MJFthgLLPT/1wcjDZfyDYolBZ
Xl5cdiEXT9meQVo5JOJA7a6tE0zNTxrurQrGy1LB+lTYvC231TBvHeOEnQKU
tqZKOMzBIWAjuBrpCHVQF+tylnPaYSjD6Pu3UMTqJuAAxTvRNNKyygE2gQBb
igc1Ej59Caf3o/14ZjiOndCmjujxRoEkrVWEjAdI9o3sm/jWKN7i2bQGQtuh
AiP9COd+puhIfoPRd3fjnUMUNxrA21zrgVxJ3rpQrUw50m18dWzhUVj1JaXl
wkxs+arA/cnxDZhm+kaM0QQXGvw7IXOlK9dLNcQDda5wiWhohmI8XX4hP48U
vXhYltlvyEOgQ/ROGD4ZaFBVQkZioSNcvqRQTqGmMJIxALv0ePyxrbaU0qEt
7AD+TEow+CFE/QM9zkS0zuxq3m/1VhslontQvCg+y3E82q0/UPB/HML0I5Q6
NIsu6wVVvxlyHoPzfSnxdefAC0oiSKb8W+xzicZK6WRLRC3awEBq18AytRWp
vu5MS+/yUMAb7ATOvwtTP4U8+7JPqWmpKbziAw8e1oOpZrsv3r3bGzl1l6TD
Eh+7oTSiRebVPjgsPjC8k92qraa4v0jPbZHbiTsxIr5WCZ+jevYI48i5p199
0F/9qEplclrki90h1XGLx46xqOHdLt76iW901MvNwePPNP/FigB24nlZCVJl
IJenGPZexg7Feu1zyeSBSJawTdKErv/YbEuKcOg1/UPiNotv+LT08IeQ9CKt
cBYt0Bm3ScGdtIXiFnM/giLzLMAm44UNJyUHEVWeO+nJxPxIosYRV19+KgIr
Zig0sSxY4g4zRRr/oiTaU3I5boa/M4BLULcMoUFIDbuug/WhQoAclYemU3G/
dTf5EK3mxepl2RHPaS38TKopSOpgLLuxy7Anh7z4KegGfL5nLpDamNokXaJF
lllf4ZGJL479CnyctLcpmZ1j2ECz8Dh/iOeVpOducBVc3+aTQIv2jMD6Oylj
oKCxuu6G/Dm8lOmtkjC2lIze4sMhOYOpZRNT/hrJUhXlRnpbU/zaGYjCTbYH
Fde/4Us1ohJgpp6ToK2p55DlQM/4XVdlvVBWoHAfxfVcYoCaavx4kdkdHHJ0
PAGRnEiyQHfycruBWlqckyWxVHVmlnDsHgrhp8fMAsxQyIvOhFIWw+723NGD
McVf6clwvjG7myvhz96wK/G2/dhaNkI5uIc9pH06wAMFDvOYI3jWiP/GxYTp
Q0IbiX8Yvd/B0eOCoRlUYYiQ9+8eZd8ejM9LsHXXlfQUUrotIb3PteTtfL5u
KfH3AXPCRfcBvLezSfay/FhgGnYU6Em4YhTHxdqFvsBt/4KtsAVYubdCtMhs
C3CJzdhHUMIhnaMJIWfAbzLNXClqyK5PPIOyhqA82DiKfThfmcR0gALA+Co9
EBKHOi2m+AzfmBCJ34KDRFX9ziBI3wr08pQQpKC6FXRKluhwPKQ1wCDVJ3Kb
SXN6yjU3aKhM/PEthQAfs35X0b51QSUckkELwCf2YvE1Wwwtw/Ek7HOKObUF
qdKTKgJ2ef8W8Q0mFol0CXxKh4All0b1Mb1wIOCuFdrNAJFkFS4tkTFbflXO
1mCV2qwg9X6kTomDrUsz6SSIk1w2xrtbtyPeYqkKHWBZQISajN60l+TPaM13
yDTpVwmwTSnnxev17ZOCAxX5M3Vj3+e3ZAUzCfL5bIMwHYawCmZdT4zg9Cqz
BRzDaEhq5Bw9kcCxjpXQc7BZRZ+C30lRCXTIzhtQs5ghp0iUPg07T/Aewkan
YjG6v+xgS+Vv9if72E3u8mDnr7TXfyvO370/AnmYlXm4qc3+snNdnDfdFC+e
juW//+pj6D7rn8/SeCrisBEpgDPLTFe4WF3d4dJjBYwifIQXFN9nDnbhQ8Lp
sETzYRLIEubGlLqAgRURe+MmXCKRCFqTVJrn4Tpxd51A4qFLJUkCrL6Jxowt
EKN8wJC6vN/GVJ/BZrGi4rMSMqNq93oPHwzeswF2VY/v9uetsky+VEz+4G1O
uQv3tai4rxnFoS/I5BzOdOgZIDSl6DnKKjwfYSARaa53H4xgMOPs+Z7g6M0O
dAfbXz8rZzTtWtCxfRC7RMUKdpECL4IxPvUNXcncrEzTzD0e4cvs99mT/sh8
6LlsY/1/62RU2UuGAAp36ZAvGO0bZdT1EJeoZgoW6CVIzUtiLrpMuT9vLteS
tnJaiyG5TBJ7MIrmeUMLgI9/nf2YfbsPq7S7i2u1v5f9P2AgMWMuztLrgbXj
Clva5ekcbRuWct553kC49tsDIajmIjnvjzPfn/cGhZjXagbZn7xtNWxNB6lo
hL5FqVs6r2xzZ9QyaCZK3N3hugQnNZgkvusxBeHJ+/bH2NjSaLdx9x5HADnN
LoB1TsA7o5eHsyjBxhv78CmjN7QEsCnABhAwL8eWE/oBigbIaJOvCJ9MfZLO
WU6QiIjyuZh3ZqrCjHs4h3VHq+t5CJST9XjoA+Vgdd0QRXfusBf577EpReYt
UTCzN8/PsSmfHoofD2TJDJXd1sSQwfrbg96gQbERLTZ9heNKCYC9DakTOADo
MlAQJAmLV5FIWdTGdgRfpYZQ7EVwzEa/1BrN+LR+5XxvOIT/Tm3tkAOQaOHZ
lqr61BuOq+oJbiSN5vjIszjvBeIvH3sV4c6s58++zllvInwx/MBE9CZq+GMH
WBHsJzPc9GtI+Qn+WBUJRPNOqzfXcedeD3aMzIaN+TgaGHk7Sc8h5X7ewSqT
WfGhQMpAdXTsiwbW9N9nS4jX1tm17QUKvnYhnfcqo4XUcA/d3PYCaX5i2l5H
KQXIpRKr41As+fCkJQ/uh2DuwHOOClDLA6hWcnCEn+9FI7rrl/cbOhkfnsBY
zsSqRkOpJQp9a/P4p1EUiEsJWokj0QrNOAc+BEFMDDNUm4jdZpa3AoUl73XP
Mo0A00febw2TC7EzzkbMqxH7nmB/V7gCKxKgS6QlDyGmh5P9GMXl6Q/6h4GS
YKXZn54Yxmwrt2oWm3phkv243GabJXdi7s0H0kVSwxr51+nYNV3M1mlaxBMj
3HrFQrIMBDi5E9JVMl0sUdRPUD/jayGsA0jioaf5abkJ3uk5+ekY19lWSDLm
BTfgNEw78bCJbGmSlj4ilO7cgyQ9Yob7xeaLIcibmQlKKUh6wbes8NZgyuzA
tvdqo9LSA3AOpw95IvEEM6WHftY8/uKuIGLCK23HWYSNe/sSjKQlHqeqBoU5
lA4TD3AbzW6KdeAJ4mS/9c0jcncx5+RgMiwrTKuMKewJcUK81/yiPtKTV1tS
dw60iIkMcuSL7BhuR24bPk0SRwSERPtgWoSQLyER/I2T7F0RZjEaAZFiM5hJ
y17T7UF5RTiQx5fl3+DXtD962HEFumzNNiftIUMyCTQGZfVjupibhC5V1gxg
ShIXUXmGN7dSHT7JYjIJWw6E/BDagdCavfgosvWDb8Fg5NtwOqLb7bO8rS54
NGkWET8+3rWoTXyn6PQgvmt0+iYzQUthI/uifzL9jQqDbjcT/Ak8cnFxrU7k
DcjZgSx3v4kLMxyYR3P8Mz79EbTa9ieSPVXcRfB7ATvQNSAOlG0KUb64xkUj
YQygjanZ4is7at1MO1k6BhAemal7UV3NylbL3HoGAIZNF+Wdab3uwkiYTIEw
PnORD/l60SHlmBEwzryk2ZGeAA76Cy6UCAp1NOIdEUxkq42IlMwnDfvDxSll
dmRyi3+CjQNbqsuRgxlU9rL8h3SORGP0+yf7jwU/SAsQp5dQbbhEcPRDg+Qo
Zitq/tofl5AE0KAE14cClLayIWV5MwlExADnmP/hnDnUNN+MKPu002mv/24s
SZ6ydCciSeR26hgIQjSbFiwKwblEgTykLHR6C5TfEUY1hQbA/rrAEjiJGafF
pa1shsUm1E/L8/SYOPE1fEyCOJSMoy5WpNgpxRDm1NgObohDMWyv+K2hBlpa
UkgJ9PY3Ma8qJlVoI52DaU51lnSOlAgHXy3qDT4kaaA9NS8ieyTkXHkwLoSG
GR/hO2Treb51TFo+jQshdZgdsXpjxs1noMzzy3kQE5pa5uRjW9A9f31KjZts
l4mKOnlRgZ920YtRwwjsK6fcVbhyydipvOXaDHmijKQDa0X9BYqce/0o1eac
4mpgbGFLsNBZFyaZKTIoZQ7SPPjEKUExNpypwCmc0nl4BQ+pGZsixEQtJy9s
r2EKdXqFBgoOtPxsA1uos5uOnhntD27PZjFE9oEE1JjW9UfT184nZKiDDRzr
C/ulIxcMu8GPFMOnLQZvt/wCnRQBeSmPpoP0SWVaeItysFTIqWoxisMrDG3Y
E8VrNKlC+3FzN/JeTePfeNhJiXw4Z9wdzhnei6S4yBAzakrOal+nbNHcpU+g
3FVVWRgEPoE2l7zBKCF5KjFxcag5muidlF03NyvsOFwsbkt8VfyUSQaWqRwv
ya+cZiPBi1z7kuvc2zDKmxGQH1GzvoGmhJwUplSFT7pgfTGsX9txLCNW1LV/
iyI0sELrkrKAFda+SacYe74cagJUmAWiyXbb73sWcIfohKSNKjOtP3DBeiex
9bZjG6CLvrsM7r6LJl9dmnZ7ouEvhyQsmIM+ReNfR4sT6m/g7KREPQg6mluJ
DeusDcvW/2HfDscbuLyWWlgIE05kaAvIcJsTwHWw8EDtyrM1/ubx825byrLk
wr+b+lro5qBlIUwckXqwfWWIcAbNLBoFfy2+ehRHxMa9Ai14eznfBEGfIkZs
zs/3rNkIVslucWi4ALeiG0wB1TZ70HHiGFawqVcN1+aLFzfOUoeMAoJtEBcz
yL65KpFFtTrhRRy4ODJf5rXorACpw9Wr6oGHc6KTp0iXOIIceHq8GwbkPLtd
ujjsNYHxMeYApHf+A8ru8+f/AGP/u/2DR5asRdrETOsGtgd+j3Yu5TxrsHto
t4IjFiwv9IA+cQLfBDK/5zAm0sh8++TxdxL5+fz5txeH73/7eXzy9k8PQTSd
zC8l+6S3KrEtk7VxbvoWcZ3+ydurh2Ekk5h+p0AQ0lRQzgiFRGdNkps3iJkT
bIhWbHGvMJ5zcvfIkjRuCm4d34ksQKvhnsRnt2eLVxx2tYJONJsQeVX0Yg61
cdgTHb/EXvROnmg1ohizFkveuuCJ+ba1iZ/erybXSjuyshhWzLjJVpiUtYbb
tyvqOyPvyY6KBgOPJF5N6SXhwBS94OaoaJS2wwxHKf172SrMy08GnpqoUAKi
iigkcUp4GTBgERm9amGALSaEMHwaoB+OwM2m5KMBuYuWq95ijoLiEHtDO9/S
FEQdmhLDxBQx3tT90zaOz5RUhCRFFCi2h2MhKhFYhvsckX6V3ZJ8IOiOJG6w
/0Td8P743avTH5H/6+GTJ3RAUFIoo2Z/VLIjOjfIKw+EkAbiUsDk1d24LfCs
JjSKIXt8+fxFtsjBiac1dYN0ZQeTbzkLhOro0eMnDygRhsc98TOyKMkj/T45
Ly5K8tWKoI6zw9OjkxMcDZmWcC/KLb+eOU87QpNl332bUVPe1piLkezHS0Qj
8MsiiG0u0oHvc/QCzfWLMUbgGny7DAk2L/xsF1sUZvcf3M8EGpndf3J/D7+i
bN3Og087+J87D/57R45VaWNS41kr2JkNnzijaJbpJe4S3OMZuJNLbCZ5wwtH
2f3c/GB+nw3x+4f3nf/hT/f3tJsohbqjxU87Zsba2al2XpTws3zRivl0wj0q
MaNFhj6s/E/cruwoqAbTdO3wz+R0W0DpAlySStM7eWZz0aQouf2Zs6qm0w6W
pvFjjCNLIgckOeeFWHhTPQlgxHEphyhItNSEAyz0pOR+ZXWq9TRLS0UQmoKw
ugT2j6IMHJ9hPofDVN3sIi3KJZ4MOAmDbTHQyG/BifEBvIQxh7VIHDHVOpDY
g5G4HkZzCE7acdDpb57dKsT67XdQRNTRVsNGfotN7NmYify6URjrh84JDcyw
hVnrGGjHEPemw3KRRuE4Hn6Wul7oSkj5n8NtkwTcLigpVs1Y86InuhHZQUwV
h74OuZEmOWKzSGi1zNBQRHpr2tR81msQNqfNlc7rusOep6vEvg3c92TcZad/
OnpGqZFyWrxCx4xRXmDbwaPHJ6/HcJG17mgwLD8UfrrMtWghDB7vJNoYmA04
RrvCTC3vKZy+KOiWfkeCHHHsuJ4juL8Iy+CbUMmS1qEG7rqpkdfcWEjaA1Bj
B9LqQVZggzaAPHfiAr9dG+uMeJsKepjmPG9NMMtpMCs9svEdtkivnBdEq0q2
0BRbFcKGwHZtrMwC8bl3dRlHpK4ZmuYuiRm1fonfnv4ieEguN1lI9CefI2AZ
w6aUTFbLt84wh7ZEPDZ/J+8RKqKnegBsT8Qn5YaVT4XhS65JEdgtytT79y/b
PflWb8whg2FML+eIsTAQHIbaOmEshLvMb0N5gu9Pbaww7c8g8ZzxNF8x2R59
nJTIIxsDPiqQCoWyKhRHyaqtUeEZ8Ck5yNSIhmvJJKTuxZnYIbGSRu2klDNS
6whZGrKfpaORzxUoEoxNxNZqIooYhYMl2C8k6bmp+jYVWfkVWKm53SEq9CFY
FhenRSydd+7+2IejpB79qTiWtl7bUMxr9eWG3Fl7ua1Zt3eEDMi27obc+1lb
KOJgvWEttHyfCjgXW3FK/PPi0BeTNzEoBB52iQMgXApGwnFWxRnCkpXEXEjt
Adv6IFOPJ/5cYnPozctiMw7162yrR73qRLt9LBCXAIK2WnvuEgIb/HL8Kn5N
wq+77VWhEO3l748Eji3hsyPnMfC8RIRmKD6tctuiN/A7ECCCGfxJfH0dglR9
SKRlG2TFBurJj9eK5et+3S3jleGB+RRPMDlgTacBDuv5XN4A1qEfqx1Gfmks
NHDoK2j/DlvHA3xo86T92DW8MgUbnKG1lKGQMimuWvDVsd4MUUqs7VsX4+5z
RANIz+VSeukSVbtWkXLzjXywB+HJkKF11+w4+zb956K7MpBI2J4tN5AtF6O6
SMN/ZWo8U4JeJ7FBCmKE9BK7bwnyNYYZtGJwuDQJ40uBBr4PpvNNKCcWFRwB
7aTUpS2pIYwpPq5MfaIRHTLVhXe95cybodhPezpijo3QXFPQJFFlrUONlxKJ
ispqQw7UFEdyvBxPNwbYmNNte8/xqApRajveFSRbEUGh1G7jDqjQ3ucqhws0
MxvpwI4+kjHDoq6dbocNih2VCab81mqZNDM+YkBRuyqFDtqeiuLNgnSvWmVf
UstJInoxv3TrhNJvsZES8qiguvd2bEslI+cDy3kWE+kGTJqj0WkSJzqE/MFE
Hvs25KCiwLABA1THMDYxrij56WMUMWerzwnf6XW0iNyKXlqR98M1PWHAST2N
Pjkb+mTHeVQZALlRgUBsmXF3H7ixwHxPf1on7qY5aJNJkEijTYJJ1tiRHS4R
XvQaLio8w3AuBvqvU1ov+jRhA+boLhjQsgY+P9N/MQJk1xgXaQnk0DD3f8MB
RudRryyYsgnw8MMeGbRHsVE6bhs4OZAffiQTB4+hwNizDdL7GCtXJzEZxwzr
g6tpJ7YOemkYr6W8i/GwBBUo7pE8FUPNMTaCO1GxMsPTOoSQxwsY7MJ/qQJ5
lY1XmnXK6TebfM0nIJ6EVbyMGN6MLd2FOsu4iRQZHfC01YKWlKgYLloV1MPx
sc6iOKP2DiaDHINDmT1JYd2kXh89fomJiEuKENAQxnbZtgIEVb3aTAA8qTR3
N1Rp1dWrelFfgAmDAVNVPihIqwVCaq7hBKgXuK5ah9QaLEaSZao9vh5rSsaB
ImTinhcrMbrqOI9ZLyQjdRYTZJ1lvqud4mW4087wq8H8LBgsnjyH+qWfEVUo
tyoeyfx7uORd+wSz34COdkccoH0EPmK51O3i1j4pVcpdhlkqzdBtw+wVZJGb
38Je6oiUNuQVksniIxVErCip8iPiITjjwqPbxmfTp5rJ3A59zU7LJcxLQ0Df
dIzxHLmbR5fdMjpe5MEOxjcAc3HeiLDCD0qxe7ALWkY5yz5gf1f2s0LcBgil
fMAxZN8T6yO6S+gfMpAZM5JtK+a+ak7+hRUbebIlDiQli9BekitGBpkjg4xG
NoPNysdscHGEp4bdh+ExJsmo5CLsucjFgpXFsXztCt/eSIZ0MCcgDc+HaTDn
+QNdwFZUGKMlWGp/g5rGrBTn4o8a/8SbURT253uD6sa5X1fEqIUTK2b/3Rwt
OufoSIrpzbeqbUPoKLkFqn/2pbXgV2MG0xmKc0XCciQSD3g/5a0F7Vjgbrpn
bJk8ubeYBWA0J0K1rE9OVChkX9Phi6Qo5nPutxG8zNQoSHcstFk4Mh8TWvql
XSwKrTQiPwTOvxknYENQWrt+kqW1wI7mJRq3lhXEQPTw4DTldwWY1jMp+TpC
9nDpd262go+Oca4An2+YEZEwBKtLuE15CPhR9chMTWVK8lchrdZNL0fSwI7k
039XS3X+R/zhFARLHuxNbXuTlhYiJZxfTa7UYYi1KcIw+U0fhYPZP8Xg/Voc
VJItDVQv6inlHFsxfFgRE5UKOQRiaLut0wZqdko8WVtD8hG+FF7rCC+mskCR
IF4pwyfpsa6+p6vmXGL5zF0yg8qq2yOznGS/Vgt0FQW3G+LjA+wuVFPmgxG4
ZRpt1B0wfilbMKlGza1wiIm/Sxw6Hzqi/uXCQVVfabBtq/CPLIIByydYBG5W
rIbCJVCAReMg/FKpUpuktGxLoLgNjum+4/prEjXxkcNYI2U3tPExkT1b8xxW
VW7WAr9EkSgIz3O0fQIvvD+fUbsbr4W1di/+Dl9kbVB8TXmFz0Pvpf34zvUY
Yf2LEnidMoBO+7053u0m76UmHu2N/Tpua9VxAzOooR19A57Bv0g76ulHB6dM
2EeHykVt4/fBBqdbyp+KtD+hJMvPMFl7Fg5BXIQwtRLwxtwXChp3DAuzh+Ym
0uNSmD30dTbUm0apnMxd0Ly2tuomGRza0xOXlMN7NKOpve0XAWIwZjtj9e0F
vr5xbAuuZ+tY/ZBfeLv+wZhpNbUAXsm6E4ExW9jcQcNsgJJTOCmOlHkNtjCi
byX0sTrBB9xvBgSOTFj6Lt1mJdQlQSZ6oRgdXBIChyRHwgc7pHBaXhKtNiOl
UDlWIBzs8HRVbRaTL5aihvjImlhlrUgEJKFHFCAOElOnlfLKlh7dESXFykBp
GCYMTBw84ECPrfKS0OvaQMVD000WnmZPA1Eaw6Go00Ss5dT+6EvoViPYtKKj
veppRUJrhmt4zhgjNFjKdec+Vc73qdIzqDR4co6z95uJwemihLVzjQzSCF2v
nDL5kH/JL/KPZ4s9rspIXkC7F6bhOm+47rhf+xugoR48HTv5SslqoxukZLeQ
zPQ4Z+9Gz+AGP8CPHck+/bEb+RNbKqmdPYO1Ce7WkBFTqfD+t/MVAE9uS621
pa/fNvhAR4XOj6+2VhCEyZ5RnXY8fRF/Q0xaQzxaW1UwnTi4vtb2M41Jtk66
RQJH94R2DDbUaspo1oN9c+9Ec/K7LMr2buHw0BHCKeH70qBTc4c9rvBaYcyF
vfrYAhpa6rPjsm09REFf4W6eyEjNYMrWWPgBcRO0YShhMJmQuw36huot33o9
61WUMV5A6PXJ0224F/lAzwF50Ho17uoxyhGH2tuQ68HJlpKzvqpXWYPpNH2W
2PCGyZJsh4cAhdNPqS79I/UmRO1Ku/QQnEjsKMrmUVjLkwHkFnxk6AVxUZMu
rJZl3TeAJJCIT0XeKOWcNllsND4e8Gysy0t2Vq5zj8ScDeVw3bryeSlJ2MFE
4XL5I8d8XYSo5Io7tQPQnUQudHNJzl259kx3MJswWMJs4BwSnEDiLxLojAur
xdTpuGHsVKAI6Iv7LDLv2D5WYDhYRorWuUPkkvfbvfa68sbNPxwRg7lynOPz
1RvYQau9MT9g8kSo1QfY+v28DVdsmZ3kgUsaR93asML6dxGWLPkmS8qVsG1s
Pe6kvZRpa3JnzrRuoMbK9Woyd0C8UL1/8LcPMZwlnYJvc/S3B9ZAOn2PjpE3
yNIHwicS8R5i5G/4mj4z9Q0JEMP6WXax0YHBzmEH1rNWcGRKUqGqon19o2WV
MU7+//897767OOxjE2DJ9ciIBvbXPFXqQ5ay61vKQ8tJcCF81nbqvbJzkbs8
PLjgOYf13tId6XYHeoCUqacTEOaM1oIPhM/6oI67mfYGm7/FyHexZUn+fWSj
tutzLjPpyM25xVB1NxmqN6k3W8dBxee+xCaFp0rFuwu23h202vbDwt1Gz7du
1/mCLXpzvNBRbIzoAVfg/rZYoDT9ihB7cMRP3Cuwx+qBmoh/0Zr8X7Il/3ct
SbQjhyJNw4dyXFC5TerzLpb6vtAwRMPLDH4zRvt3mDEimpFBf1XAkgOwykwp
6/LKRMCHQQ4cEdC6OaccZhlXWAgk+TJGxeNW6EKtHQwYLSLtGmrH6oIhHfbG
JqpDKX1b0dYk5bYoI7LmsmcyET7dmbj4NtG54nZbd8p0pm3AMXEYJzyHV8Iz
T7RbuHkr38x8ysypKeVY1AaUu6QoV2XS3CISU4dbVbRvCgtZnuPywCf0eXKp
XXXDhEYN5dj9SUJf7iyzktQ0treOipTSSDoB08OYstd5Vu+hkTS+vxrGq0Ms
N6K/DDxvjrg6USx7h4fwfnsgnx5pqu1j2uI+tetAp5mHE4JoInl5GMIH9Dxw
HbmSnvUa4+QnWUTEniwJqtHrptSPSgiN6TEDMzQQk+DFC3bZACsvmGQvfnn+
0/gYMfSz8UusBd0VG0x+QbAjJM7vhYr4zXtqs6Grpbl7+44dvWBgbvRXj8Vu
Y5x/b0jMjm3QnL1F+B6XYJTtPNjxXiYqvVBM8AKJ/4QNmefSyBNb5HiJVgiw
/KwrfroWemsBQCxsQip4ws23R7E0mZRf77Nc+k1P9h9+H77p0eQJ+HYhNE0e
3PA29ojwgOSLSSTnrIp9X6YQ93US9zXRiZqkp5aqBy+P9GEzOHwumnzmyexM
93MNTwxsEfhtqES6ycse4IQ2HCSDZ1v/MUklRRKQHyEzQauwMJXVNlW2oMiE
uz+P5Dmw+BHv3sC5+mzdeTYThE+gjvV6Ru6Wrlv9u2U/79pEj8SsyyRzb3A+
xDzsDCGnf0teGQ95UHiGFHd/TgdUN/Ivd1nsqt/tCB2KXuJG5EPgVvWeefU+
aDNJQzTWu32HaH90+yEwUISSqHfkOR9Q8dkdVLxLVLyZhrtFOoKFu13bb+Fh
/3c0/n5P5cNLsq9Q+3bOUtV/IqC34LRZwyFishzUAjgbQ98rkci7YFixlYRS
9mFZPxXACLIFO0no76Q8FB4Iu0zBHLndnMqdNauna3panKMUO5bjQdTyghd6
NGh9jwbyKAihEnPaFKAmCZCB9Et4N5hU4sz4T16WLbb5bp00Dpux2b5cwUu4
oyiooFawaIqIR9zUum1DnQVePubraFafFZuaGe7CeDG4jrHjjuhSiALND4Ox
c8qNi+R0ME8LPLqLliqN1q3ybdXzpGNXzh05wDvA8G6bxqlduJU16ozA4Rz5
xoO2CvVN9sE4oKrmZktNhqBSiZeUUgjEDTyKBcZ06Hxdr9hF/fy5qsdtVQpX
P0Pw/Gye0CxhbDmaNXBMKmQeYLoPPFxDEGVETY9VX0Vtn7get1fKxSxLZAtg
DQCpjuITJbNVwlrNijJK3IAMtCGxXO9CG+yoJ/W69dYr2Rx1Wnni4/VrbEaI
hawzMM+4v7NAH3Hs6GIr76kmBORblyltc1qvVLBDKokYah+PrAYSq1xsxgZp
QO/R82PmG6iR/i0bpo2BBYI1C1wPFYcKGI77ye6bdlpUsLVrCvkFXh8v5LiN
CIjqLtY5aMOuKGTS6HKU1npaLyjFwkpFaBSKrKnP12zQoNgi5sMw5k1LE81q
N/CjpTjyoc+rn1XTZgjRdBIuajtHHeFASXP7pDEcIysYxlpqUIU75P11Hdg+
/feyAqBUopLdion3Kkne0Otj7TotGtKrvTyPw77SlvDCk2/bFFHcOIlmi/gZ
LKOgtM7C9aDcEPfHDPRK5M8iaUA6BlDEOWMueUsKqSRNvjADN3jyrgU2TGm/
scfTBd5Xz/NE+owGQalutQQWVDIpqJeMI0y1XGIkTLbHEmXhnN9dsG6Pq1oi
LtXAWdAUiHJps0R2RoHIEx+BisawE+YR490A7deEc9yeHSDZXw4mVYDAJiAo
iOu/CVZKirYCL10as5sk6WmfIAuKxN3RaMoJbzzyOHPBBJRk2/oek1R5aR2X
g6SNxVs7Z6GOSgH88bw5TxOYzl6/o3I+Z34aXDuJPc6EkooZaUcDUfpePZZA
fKWNqmeWpAUVpDt8TwSPjxh6oxCeEORtG7Z3O+cYbydxJDILfI45S21wjCOo
XZRG9w2FpWs6JWhhRy6UriQuXynbJNoWmfBwJHKR9OGfFTTsGZAry18SEpyo
AXhqWordSdsl3RxcpeNbo8qB5gOm6WbDT2njCRYt5eIjkcn+CHIORsgKvO5O
jmEmnJHSFpiguI7R6dhQqkNUPQI93bZ1nbdZSKsTsBs5UxqimIATEacTjvKy
ntGsW4hmUJPcMCcgJfQzWsv1Gn6dlsbqUTGbLYrz+hNsbNFeafV4L6DwBMMJ
vjaJ+53Cx39iViVHhXKceagb6itOMxhASVpjxSucGQuJDDMuRIN7xtp0gaZD
XkBFIHIitz1mVw8cJ2pS5jvgwW18+kUM7+TcfO+vIz0v6mldMbw/lLlwgZ4y
ZviMQJQ0YHecqx5hacPN1HDDq85WGto64YYkDSZawEhQHHeuA9QhT4tlOJ/E
Xkv4binr6YREbNpjMOvl/w0KVm1T2Tx0pKTyrNw3gWZgb6QkAa5AOnLRDndA
Ebi4ZBRmpruM2UDipBaaSVMfzKYPxta85gxA3buGsTTUFv5qcEca01HpJINy
wTrZqYnnD2h+bjYYCpmMEheIEdjPuhwaTULv4NaRaZEw/ArbSJnwV9zE4l7k
Pgtf3ud74v+EApwtDpj1t8iN0Y5CZE032MbaRz16lpFpqEQ/ouupLyI9H5OU
eM74bsZazuLAU0ZnxRwi0kNdufp1+am0n8t79EwNv4QbcCo5ltN0SuisTAsY
U27WrfRDn4ElLRHn+H5lwUiLamj3RCcsajNDgeG9tCv5fBkhmaCJOCfMq4ID
ZHYn49GoxREWzKULFlxBYnRN3GXVynNQNjm9jwrx9CxwdFjlDGmvPSSJDs8S
e95GDRPQ98orWE/kICKqRnRtglmEB7Y+UL2vWD6FIgcbcJV5dgGuzgr8CxDx
jYJktfgmnX3kdasr5SLMuZxMc4o2akHz48L8oG8+HjMNOskUxfjO8wX4HrgY
8Ls4ruDTDSs6ixZ8DOEasyHY/sAojpxotsgUQgNJfkmp+DUbd8TlpraSum3K
e3ZSBZvqE12f6pKRt5T6k8rRBFJ3LDOMI5DJiw0V6Y09R0oWiXgQryjtPVQ3
rq0Xa0Hpt8G/7LgrkvRsN3NMMbojopigEP07aylwFIV/88V/Zn7eKs8om0hp
A++MDkLk/ef3EzmiL3wDkzvTx4rDYh7BuAXfKiROvzE4yhSOESfZL8evnmbP
X8Bfu/998OjR/pMRh11PXxwePPpuLyW7/Z65ZfFZSDMN9z//6am9o3/DQXwD
kmA9hf89He8fPB7/fPSqf8e39g4idAA3FVcrjoFKl+VW+Qc15N/q5dM4ZCpu
Ox8N/pkoNW+xjAy23s81uMXIvId/fyHiQ/+QlipZMdHObLTiG7RPQcUy8xn5
nEQMAk6Z/kwvk040OXaOI8bnXl24klFxsxRLg0HckhhEwvfSC5xSWfiiUZCe
cxNAQxX+93XB1JrUNOUQbGAxbAXnUS7IAGPaxEiB8hCDm8OoGtV/3Ol7lXwh
xTan2iDe8Tjj7+egA+fudBaQ9NzOglSYgkhzxwJhcRo5/VDa70IAFccOzUYf
pfPB55vOCLeRIaqDuiF64ywZbxYqCX39GDwfDzSuPOouqaUW1uYuhBrp20eP
DgTOrgnIuPL9bU9QkvmhT8HlZiNejlEvH94mcFtqG7ZE61sq2MG/zX23xual
1U+zrnwna4RlEGEFkqMG3lmKgodfSJsYD8amSBF1lcUdFJihkVlmvVxpicK+
1HqA21oVCz9UKvbuj5V+nCQT4HCxhO8z3hzeMU5xDeiIaKfZ0KOPdiVbR4P1
G63admhOBi+bjLReZ6FoOE4/LT0ZPbOwpmcmOhlBHFkjkFQuTF+EsKTbxMD5
QBfslS13bRcCsCyY+57fiz42VwZQsCT0a9Sau+pjZHmtq/LvGrlN655kQzsK
cXtMEhr4MB2hMcJIk7O+JGmQ840hIMxutZCuTwwXoBinUnFjczb60HyxaUvS
5H5O8mlTt+3A3tARw7jQWkM1GCrrbCzIP4oCb3dNgt0gUZgtEA+Ye99gwx6k
ZTCfeQdpcj+XTBRBaJKguNQnLpdYo0Gnnk8fNkVcpr4/CWfmionQpNXBr9ze
KurKdQ3+jqcN8XehGYkpNua6TN0GknptCim13VOM9cesWX6XLbUsxAoPPhef
yfknsBurzRJfjkkdjDBVXDZ5sYYHMCkss5/HQUZEJ3lSDyua8miy5OyzJ9nu
+/Rn1IQ4AQpRhys4DPbwW5977ArMZ8lJADioq962DyCXeKBMvRVR5QpzrwJK
BUAjqyK/5NhOW9gVIRb1uVC4UCCqkIQhEggfyn6hY+w33I/cm4rdkXTJhtPG
cbjNGa4VBoj8w1OGJDMbu15gewzX1RGXhi+K7ZfraVtaSSn44LEcMbGoUDsk
HNLH7MdsX6mrk5NA46fsEegJKcBTJJRuCWGIVNL5p1J5O+ynuvitfOx75m2L
hx08ioR9yG1hD58zDdmS7McgxFRjGl5yWDkrb5nZIHRgR3eSPMVhVNeb6qhJ
99YaFLp4IkY8WYb8pRLqicC2lQSdg6gJ79I5cQlowy7R4HbEA+IzDF7Hv0pm
yoHpUg3NjWKiJ46EK7YySChPzoFc+c46WZTeEW81MObXSmkjdfhWxdjZc/Z0
sWiAMBGe+dASi83DeevkE6TR9C/F5hRZtTyRScdYtrzT6DNmQOTcDrw70v3A
DzXgKDrRJHyGtNatEnXABwvbgbTOeblkxVEisQ1WK+KscbSMjyQMg2WmHSx3
kGAeG8qawedqGMGDmkKFomFUStJTtlIx6EUGvtx0Wmk+Msy7juMEFgc/kJnh
fQh/h8h7dnwAEyPBNDSfXd9NwsOUEeMtgA4WWz8+TiwsCJ5dfcdFaQmKmjA/
68OHTCU6xL2e1NqiI/xrFdvM5A97TxBTUZ/vec9wPKvUL/YiD3ZESUkjsksi
oklvdV1y4yvOxFGXBRjHi/fv3546brHQ+vC4ROqUV4vYKkpmi9RxUuCmkUOK
muBZZZE2a0iLCqhvrSo83r7UYbXCkJPm3girSV70qi5beCr+fErxwVGIV1Ms
ZokQTEEgYOm+GuKUb1PnrR1xTpULffkSqehAIuoBptZst61dUgURgtCm2e6S
Wt4g3G6lCrfXf1OIY/2X2Z4hle44H5TyFj2+nVz6GgxDmIGRq2rTmF65zPHL
yHe3LUWjM0U669IvTt46b9pTe4HzRc2kVJp8tn48hTjOQYS7NRXqimYKDwkH
u7ZW43FfE5NW/ZHAT1Rbsm61ZIwXmeTOxzStXxq3YzatZj/qCa4tKDH5QFqo
6jA+WjdUunuEdMOoluBFp8dH2W4ZtTbQplYc5r7EWB9V6O2xTIHBCMoLbANh
PyOznQJBPu7EsaJwHOAHhfa7ep7mTh7lidTwOn4C4WtD9EEOa6Ye8wEHDiFb
QSfUj7Dfm0wbfgfGl41swBnjPCItlGPlNJUKSaRUJ7V8ZZRL8gxw6Ak8ADKF
DCu6VOYKmBH8JgzslNLwEqeh7CaGZzB7r51I3KGJLW0xUtGsQBsITg0UORa4
EQbjxrJ+A10mpK86Gn1o2SnNmm50NUwCmDSKSr+pxqsc+4AjYgVRmT4fhblW
rMzkyGCrw2EIlXriyMJLTX71dQL3dDgcZOMjkmCfdjY1eeI4aCUkwvskTM8l
RV7gYKvn2NgEPHwS7VDfIWscklmuy5uLQkPwrV18VaI4FB/BlNAQ3UQIpxBq
h3VvGGNJBzqCXAwGAHvFSFtX2ddDa2Qq6JwcVVgGAX48nT/Zu3eih7Hwibq1
jDzAkzI/RzKpqMeQ8DwDc728wDyqouUwtYXzPF+sBbMCRwx+Kwec/TgwbkNA
TLI38EI9Hdyuz7YKTbK3FTE/LSNQ1Sp1FCi0BLJDtV4v0Ig1La+kbIKjK5iP
p4sou7Fne/pkYI+wLmukkyjrjoqhZqResVVM2DcaUpUMHA76Wlpi07NEOucN
izp36mE6puITfJdp+4bdOqQOGo4ohGpNsnc0HsrF1/Yh9ATLThNcNkd+ImJr
G+qBUAQ0ptjnbNwPuUJkwq5bR04NyQDmxRhKSFFDLDYIzI+Cgxx0x7iJYx27
kpIvhe0kvRnK6goXi8diiaEw1OPEJChxj82x1MovDwW+r7QDXHbCbIrZUQRr
PDFMmTia98RQ+TyUgn++l9IwOkePkgi6eZZl3RQPRhRxWRnMJZ8GXtNVW8Km
yuPlRYWbeFjLzeu54QimnBh3Il4QNzzkjXV8iBRxodFLFhq9BM+0HPRcPWNL
qQTs+nRH+Bhf6pSQggodp03sGOfPUC0Jexs6CchnGLElRz5zdhjAcyPG5fRW
z6Wrh+HFojmnHrS1twJSPwrNPzmENnQbzVfY+/bQ12gnDGFSTEaS/rVdKkxh
t5ZaB3JQ3PxkfnokG7eZBcOtIykLUxjmXrh0GVNNZ9y84PwzBwQStETIhVIT
OzWiSNORPiGuJB9y7WrHeorCojX6o7SW+RKxG2TbclMNCvHIDHqI400sprKa
u8/38AiWA61PYNrDWnhEI+t+PCO4lSpoAKY4sCvy+R7xRMgZSNviCzfT65Ul
WPiQErtt4wDE7tKlRi6cJv608U5rObpsn3hqqiUhoS2P1p4mZMiIRsBwLlpw
+I5etax45ZvAlttRJdZaYV6KBGbApR3CUB8DCyuSCrgelwal7m0+i0QpVEB4
aImZUuknJkWD+PixoglcVMgQKZj3trUHg1a260iHH51FHx1FukhVksc6+4AP
2IkkJTQO4rDB908OHn75QjaO5NHpAVTXxuleX7fge054k9m24b5dFIbWIf2W
rYsRLSyJwFYBk4yQ0z4JAfaOeymgQC1LdlnF8FCMeSQhRCfxPBpBuPjw5dvX
RIbdMtJHf27y8fbhzuqG8CI/Vt6jmKkRcLLCY/LWbI8ww1RqqRd5WTOTMyDW
f5ImNrQFc8o3M1pIUFtDCzPyNMyJSvFkwdfYbUVDYVj1NJLGcapnZoPDEVj9
hvGU3FkjIvPt1VPy5fJssiCLtu1z6bgh6lUf/ah8lXFnCh+lLpu3X2u/1PH+
0+okrwPyxo6BKdBIYZlr+CYKHqMKQfcFa0EUPhp/LilyUyxgNlP0uZO4x6+n
qwjRDDOCgYn3LX0d4ygZKk+VtcFFw8VMtX5SrIGYVo4gMZ9srhse8cDFYk4z
RBFMld5tMUoxb2n24sONZjQ53CIhtuVzcWa2Lz3m/Oip0pFEBMGhI7DWJTjh
w0Zt4P0oPYhgkh4YknRGGJHCG1oJi91kA8vw3cDwJ4hnjQwFyYd0lBsh0zd6
G8JsXISHEnQH9TYmn9W/WMP2JgJuKxkpR8CL9I772nr81MsiB1/Wcb9UKexM
glTc47zKClCEDIExr+skLuEtskmod6NA8CYQPuH8g9HMZm5n2mwcGaC4lum6
sBwYu4ibkfz3owdP7F3YZkP49gOA2e8np0ClrsnnhA7Uxt3aljBA73Vwk+yY
T482hFf4bqoF003bcGk3hzThafVUPT8vH0Fu3xydvkVlfPTupT4MlbNLHgL+
dknNuAYfomDrzUn47SEFrumkhcE5KXwVtp9I6sI5o3NBGcegeqxgcyvjFsHn
uBikKSi2H4CgiUiLyuOG44uCOxT3DFmaQOtPaYLqGDPYtNSExqi5LMzIow+Y
ynz4mYuXHuNRSKXtfPCing/LYJhX4fzgkgQ/S0eHmdBggqp0IacFll/to0os
Hk3ZfkxLSjXTwm+xh1JZjc8Fv135yJFVcSENs2awBklP2+WrBUHMA2rIJ7VZ
kxDVo+2FzHkXIquMJ01qdHq1Zrq6hxJ2pkVTfk/tQez3EoraPGAu/O725cTO
hi+b4jboS2wT59a80idxV3ujsEHdozvfyMkXV4OTcFAfdG0ImdshdbW4qGjE
0nNy4uKMH8IgD+9n0x1ysLau0wZ2s4KqzW0viHFRcfmceeU1pfhngrKid3ru
bvlcY7zLjVInQjIjySwDbaHRxygMqRZHjq/WRRWJB0lFogBeOGmA14sdYLLH
bbCgwUDrc3skjbixYEYN/AFyrey3y5JR9c7nx/gApbdvvdEQoceArPsDLCpZ
XI4/MVlFNerFgeDXeohdwuPXmj4vZGWSa0D9Kcm+R8uurvDL+QhCvTdggA4d
Ms49SwCcQyAoY0gOmB9lZaZOvHMfSbIU+6aUGEtQEA1xvqH0+GKQr8VR+JvK
DyXtJ8bgjENXNGfkXZzb0BdJoiykp5fEaaCTRkpQLJTOsNx53jMvCJ7AHuNr
2pIgX9QXGNqi/sherDGRgY7xowfff48VCD4+ny4IviS4eymElmLoTkVCePv1
Yh1Fq/Xv6BLo6RJ2eI81Qj7LVh2tpHdNhNAdku2QZKDmajI0m1JjeupUlPCu
+IiCdRIaPl11Clv6ePVghyRa4UC9wRV37AP52WBdo+fF8Sf4Sg7UHQYypCND
qeIcHJ9SBRb4km7jMjMUZkibtI3CLBft1aOc20I/Nsl2T4l0KuVziaAXe7x7
vIMFoknAFKFYKz/CSX9Z10rBMzQ67NVVzjwKHu8buCqK3WTSuxjMYY1tUoE3
HDO633CCiKtUYTAijYpaMa4zjqspllLWefBQ5lMBMEVFNkeB+d3VJipU5kpf
bnQnGRuwq3Ow19Ym5Ug9TnhQXsp8Eee5VMbKUXddZ4/H+H6hHQrpG1IgJZbo
V+OquFiUFwZaxw2ic4qptl3gJwNBQgMMwc+rlS/6HspJaD1u0SabNtvloLjU
23lSVlJw6EwXs72noqBcyqmX0BSGJQc5wbm1/KopD9jIdZdxZQCTC1S+ATPB
d8lyCfvJth7ItUdJSkHrP3bW01BWKqL1IQGcgxNROHJFKIZAvOgoNaTFM6Zd
MXOn/dj3UZ8d/N/vHsp6SUChdS3CVDXROfBK9dH6VaekIjVNGHGiemmx1Ibb
yB+FgS84RC5gdI0jm5LRDfM1Chkdx3+dd359ykxLXooIYDNUzsAiQGwLzqwu
fHKP4dPw/zSEcDoUjMgR6kdQ285ZRJnENrWDcgQ+o/KPCLkx4XK3UJ01yq7R
vx1LkzVJoEVPoaqYtlUWVbaY8YMMEKZYej4XOYqO1t0YicPeYtZIDw3nTinn
lkZp5LzqZRViXk7pqkFAfel2vUXZE2GBmoQjbXqAlVuWKiYpktiZrjsKj61w
yDv+YwNvkjERBMASUDZoKMbFyQTuGoh74zQdku/8G+gMEI5T7qYKctcUnVbP
CWmY1iUTPIFQQqgXrwowAOUr2mJZjtGIAzdN0iaYvfdIGVuGGkiX0Gwg00XD
xGVjm7a17pIVBwdzcYfMyy5EFg1gGw/LEkWkMsUhhNMmRycKntq2cKZDC9l9
wjDAvjKarZKKRLWi7x2RccR0O9RsilHx50hIpMm9ULyNLpdmJsmmioa4ZVLm
64ZkkfON+jp4mozdMfXUhueaYSVBLAyAzXIrpEhslxicYd1asbFzLoFD3IuS
Yb4+GT8jCPLzogILYVzPx6cCn/Dby4qOj/QZ7iOd8aF0MZ9ecXLdmSD1NG+4
bJGpamblBcYXdNnKPhVTsr8oi2xbw/ljvU3IiaR7CgOc0BwbXl8ahwvwOovZ
yONiDXxXJRP5vEYO0+yUELugU5CyLw51Uxtyg/mNLLGSCQvMYYbfrOGyUQT3
JRDtckk7GNdvKJTacvN1YfOK6xRIduU1LsipHD9efpjJxXx98NNM2VJDloq/
iMmR+hdS0IspZ9CuU34gQzeGRUZLAv76mmiXYLBhL2n9qymaEKK6+pyt3uCf
K5tuyH5ycuIpt13F/dCGMlm0FZSSaZRwMsH0/4ePeLDV0xRMXsZ5Ux1i8k2I
SM0ILa0DZ1J8BuCZHjseJn4TgN0g9hf19RhtVl5P2FCoAXIlySVP0dhHRFHB
rGZ2dEtQRlP5GIar+3G4GK7usZgeytZtBc/HM0IL5IjyZaHhfIpPiwoF09NM
Q9n6wQtXIEU/mJEE7fBQ1LwsW/WnRkLjJd+Ak96qQ0JEhuENUgCBBpMvKbGv
lOJZVT/0lR2aMBfc1Eh8YgPmc3afSlWAVAiZD7vmM1kGxeQQaLPALrsq/wH6
K2y6BSeClV5kcHm81vI9xo/R2+L5DZt7y57WalD/WJw+M1jMAwgukckTVPOi
YxFH7TUaRzvQbiWPCKKPQSdlGUZB/IkIq4gPyWuqQaoZIR5Gt6b2L4iApipU
F0YqKj2imPDlJuqZ5lRig0jWILALMEIWHBamkVsiDapcn16WcEmGX4+DvaaP
5CeSnZDkLnhd3XxRfFKqCeLl4aeABDHFhn9/Wvn1CuPtDMnyn01dtiM2Rkwz
+HX0xYxm4aiGVKvOLbgYme0CNcQ0X7FygN+FSmx/sHkAPKGRFRpHhsZLLFhX
WJTNvqTP+FhgJoEAusEnY0gsei69Dl6mNaRj0l6QgMDnJYBqi6J2punHNkFm
fkiZw7YOjl+YC8GTwVzzToH/B9MHZncDhkCz8R0d5cMC+A1MSM1xmxI6ZIig
GWWPGd1D/gJh/RGjx1ChawgWLX3fAxcxvAiT+0EfJRAFU3T8A2Ev5dehb1xg
deBmY3q5Vt7Ba67oBLlC0eDjwQdlIj2BuxK0LxqElG6ZGJIih4oZFBl+PZm0
JKOjeG7DRHgicR/EGECd/jB4NQMjwMrxv0ab4Epo7cM8apkO6pGAC4g51ekR
CiaOij7udLdO+It37yjQy2HH22/09bdC4CSeggKiiNa1rVeXKEVclJWoFy7/
oKo5PX8sEG06QMVsA0KBcY7li4DHsqMM/KlHT9dT9fwVdgjo/lgZCSm5lPaH
vHht2/IT95xh33S6SXxTVT+qwKVDDWpPvNrX2JUpZsTZeIlP1waHL2N/dpLF
8SuQ1RkounoeUr6pd4D3L8o5gXjUknp3fPTm1avj18+Pn0fJLmdR8U1xwSgE
mYJjSuhlr4iwlcm6LN0N4cLi6VhhFK4L7laoBoiC/+IK0URZc5yT2QzKH6xy
jfGctjiQjWefk5WyyMGH0EQ2BdYYqWLdeq2TUlD18HvBVpU/b/5ti8aq0yc0
C02hEakApNaIpXNHSOfSgCGw8Yki61bToUaJyJg3GP17WzCpFShYUcLlXiMH
fmI9F9rCoQ/ZtmRCgRfMAEZIxeWXnEkgJaFsaVyMT5EPvZQobsDBjNrIxWd3
qIxhDi+KcQyst8D2XES1G6q24zu42xqSBGos0mdMBpfM7tBeeZzJclr6RxMP
tM2vlaibXo+lOxLQELT4K22F+lZs5mRfXVJpmve7Y3KuRb5h9DFb23rMcHZO
gDKEaLIh56am5hWjoW/wfS0t+CJGT1h0TBT9UAp8ZU/3TV7tiMlw0JiFrzrG
zN4mS7ZFQVx0UUsSgVHwzOSG59z5ut/kIQSAtayVMPVvpWHJW2K2Q7BeU8pB
IVZOMGOGcmpCVyaJcXTOMPvqtuHlohCgboQJbiAeB2ET2JvGZjxWX8sVCf2K
L2opl1x57iM0PoEWDWbBLI+SwGR4G8fMNGBd9nnLwpDIs5MEVGAZN750Tt0v
aYTTlntBUX1n67dERCvF/QbQSQsWa8v0rqPIiEXXouYaxMheiCr5jCXAJwRV
vStlR3gSVVFQlFrDsMPr1Tut+5h+NPOc8kTcC/Wc7wrmPexPbvb53hxDIaJr
Grnwi9JM8PVrzbT62hu9kFExIVsW6x2K99VgHC8E6R4+W1kIKRZTXJQYM+76
RbJYCO2RAHnU28sZCOLI4hH/RMhH1hM/gV8ITsXMFN+Q66jwd6M/tE1qaIWT
7YBS7XYGyZhnNWZyBXxvUdzEmYbwbGdUtBy0kgi0iEtir2QeYavAsl0knERS
oNnA9kVzJrpaEzZoPwzBZ/c4/eynn+RNA0gYjKeiPTMsJu/J27CyXEVVBVx/
28v13m/jhhYlldamuGQQqx15yAQ082gnUw54PzxedWXGjuYL55+WBe8N7PIe
uIW10aStovnRLt3s0ukZKntRee6pflCTpLimXNpMfFwuXTc6rckWCKi90Zad
S5OJi9lym65AUxDFwpntDz75sl70BIWFOrCXnAidkdYVGrAeO1TcVYlnQXav
HT9/XMeYZjoFXGipJYmzjwYRED5sIi2KRLds+3Oonxb/4R2MIQrrd8A/f4/2
/gdOCNE/sS+R/hnTnz/yP3a98tgLv/xj9t/Z7gxU/567uQexUSE3X5gMKP3z
eaBz6ZfBC820C7jrd4MXDly/5cLPPcEYuvAPPGv4i0OU+/4VMq20np+fZnwU
zMr8osmX6ZEAaqVbFD/uyLL7H7MI73xxW5O+QsqmXQMYrJLGr3zRp98Tzvux
VGos/CAUTlJoAzf4FvJP3vpsFBB7vek3hhom5BjIscS+puKxJJbZACDehrOF
5VlYncuFzd8NaffQJzpyp/B47qMmX5R/Gz6gL5tmfEm/TM5mjdYWjPtS2xlj
LBwuZOZlJX9Dd+0qrkYSiOTWc5iTUUpTr8szFqKTRcwrOEFwGXWkS00mc+Iz
Y7N0et72Wt8afVv98i5oiD1T8iORRnWoWQ1K6gNPBPOeLS0HQZ+D6/DOkAJo
RICTCJ2PZwpSOPlGSyx3I7+/bXDo+WRFREynjKF+wtTpsjf84pNwMnmOdQHk
B6gOy0WE+LWimsRpk74tjgE8l9yyyruow8PTgA/pznAxI4rd7oAE7aXOVDw2
2dszObX0aHJpKTiOLf2Of+u0wj//CydWtitytBf/GlTv1hEN/unDhL/ufv5z
y8lm/qRHrT9Uxrecsulc3W0092+9FKb4vvnBvziN/OfOlsDW0dx1Gu2fO9sN
2+7/SnPiDo/5uvvvZnzc6UnqnX39/V4Mt16xqz6RdgtaoFGwN2zrhNNVzZy+
ipXfB3snQcMo2ns2gMhnLnkpSUaT47wGNW33iE8zbUklYoxToX7yINB73HAM
C87UDgp9ZXIBBMXsT0ER910zrClLwhMcRQITolytFwqP6JeGMGsjWV2Gi8ep
s6x42FqbyPiwgHQ29kgR0+gmPmSsdRkw8FwJNN8yqpTLcplflFURnxwcWc8X
sec6GG9JPdcdn230jjU8kMWkmN3VFTa+7KEetsKyd1lwARgmjchO/fs6XyhZ
pDQfDZj4iEVUTn9OmPHhHU07Qmso5pR671HgiEf5CrHDCobZFjoim2y8NJdu
sVN79SBsfVJuqiOXwBs/gw3IbF/nAVPUCBDOUqDysiktF3j90tLjy1AsHsHB
bquRzwwrgv+IPLOFAwPD7RE2SDMVzjQMFF8R/vt8fXHhaZkwlG7B6jkxJqb7
aOg9XQQzctsMd7bxyBDIp50PxYU9XZ9TTpIZdpif3iFmr+givDrFmDhsFiKX
0X6aZC9zghITqpbap624iUNvnljhcLdn6okVU9f7BBj4aKHknI1iHmEmI6Sv
GSgXj5oWRtT35ivfnv4iQbRASxCVxWurQvYT4bdwR3aOvBENb2/v5XBkikC2
vag+0xnGc8UZ7XJBYCDF3ckbCC0dWvLc9MzA2m3SVMoxSBF0JxqDdHnBnSNC
TbBXcu3Ed67OskFr+wYTG/+ImX0nS8AgGlEB00re1YTozeRdb1STA6zN6Cut
Adk3CclkDa+gf34gTMaHAGcBW6Xgu2Yf4AF7/t745wMjHd9qARsTfus1dzHW
72LtJh+75YK7fv7Q7fGVt/kL9s/tM3Xrny1RtDuPoG5usFe3//l3/RT9M5lM
/sX71U7/itv9bvEGd7dot9oKanW/khwMGhba2QYvWkShodT4lqJatnwX5T+0
WNscgxoNCgr6ipF95xsXaWw9mCg9a6iOmALSG/lRMJM4Q/GI8GluoQ5NTuFe
hJTjgzHkgDCi1Wrd+T466V1u9xiNj2I2+Lj0pNwL1W/khWA/KQJKgBETv3pM
+5IpoBErYe0gPUQJU53aPmjnn5ezdjvVINxGgwkurxw1XOPIh/M6YdbGtLl4
LUMUa1zpBYbPSnq2E2dLv7DnEBsWNPBjuKtTMhelFYmRr7iILhxuyepIAGyH
5YV6WxoSRQ04Loo52yBSGhrZrlfrRSV93DlxyuXUa9/tLdRyJlY4L/BbbjR1
iA3N/KgjkzxatjGccj4wn1LxEAljuDzbIlTEsuUJDUMKETfdtMnnVJTKw5I9
Rvy0xSeUF8ytI48qUZlIoFze5+pGNy5B+xeYOzcVitSqm6AD9PCnzv0OrTLE
phMPyCpuXvom4X/iUVCBOHPw+u5Qnnc3M4DSkV0yGqUURrHYXweyoDe7r/7n
d6/3hE2XksnwpFdaKhH3qLyBRwqF67XcBQ/QJhfpNpHP9pGEGz5Z0JHTeoW5
Uw9yId6skcvi2hv6oBRKlMCuIl8k5xVyWV8qz5WShyFcdJ0Z18DX43DgYwXN
8pId6bynJKiI0ntW+PTX/HniIlI7F0Nj+n7bl5hsJ37xm93X//O7l3vg3S2Z
6gce4+Px8NXw+9/Dr5Ej5rqcIcFsjMliwlTEoY2XxBuQ4xP0qS2dQLonwpux
/yKmpOAMET4RXvqkg9QtB02g+yfHI50x7C6vhxa5qgSDHvHFszXjnQrrrdId
XG0tRZybzNdH6Xu2cNRSV27dYC0KINYNCLFrpIq0WjcuYfWYPC3X6VHPYT/D
k8PXh71ehtiKgTpnarQAD1w/EchJlb0Dbxakd+McPaFslX2HZx8pBCSiFeDs
MC7PjI4hCG2W18izqNVo/JrdqGNRKHPaY/z28Jm4++DTvHgwkzbH2Y7UG+8g
T8F6WSkgHRlIuL/SDtbevHj3bpQdH++Msp3n2N76DRxY/ha+Ntt5LYGpnXe6
isXMXkT1AXDdn4t2hwoPBm1yGN/swQMdHx18N44RB7gzopHePLRtw/JjCmE1
+my6tutd+abiYAdIXsu0UxRdezHZ2SIbZL17mYCjklxu4nO+QTqIAQuuH9Es
aZxyd/9gf2+rjFDck17XbhcOO7E8Yb8k3+h2/rzD0DhUCDFvtZdA+0GMvB2H
RRyXYF/c9oFgtV5nOwHl6h+9E4SewjtwnSMZOE4aykm59S48Y2/bONsd0IiY
SH8NT5HnCrQRM/FMed6mxSWg9ritABaFEHXhU/eU1Hx3XTOBRah/8Ngs/y3H
wTjzVSeu/1vcxS5s6uw1HLT4ntd5oJfp3+WcEWS8/BDEdwcjdCDmPvLrec0E
Mm2OxZbE8refM1ON6pmownXnhRI4E/MZk5uSmJREDsvFOXmo+sDXr4liGfH4
aLh1i01Ye7DnJHwqt0S8LXj/n3dCkfKpVJK27pDxHszIsH/ALTrf6Tmi6xIb
1FymNTx/ptcb00q0NIkVse1s4b2lrYjeZLuig+jHHcL2Tjt0CUGyUvV9i1jj
+dOuz/Hw0+P4NBr/O81LWInVxtO7sp9hLjw7hXs4STY3XYxDSgpTRRV8H4gt
9r9H3wv3qvtLix0VMM79DcKs4e9i9tdkbzAVax3Ovv6n6kbbPKWQFU7y04yW
qakXXrQZtUwTDfJSNFrmGkYLQ81wrBo/eD94119kMv5qvDqNx0azWrbyHAaj
ox6/AhsgJwi/FIe0ayS4KwW1wgigCswuZAEvuvFz9DzkKbsMY6SaZnXbKiJJ
EC4An/yAAe5xCF0J79gv5+do02wtnsYSlhlRrs/WJC5oDKNPul6OsK8I1VAh
Sxi1LSu6qZ0emRPic5AyHCpBKIk7gslyy+K69V2MS+nWDdtQHiP1tVJI2lGD
SP4OUBXYOcdWuFok+XtL6efp5ZSK5F0hdNSm0V+vB5LxXhzXTvr6jh0qqQYJ
3Empg0GqhcFbLyEd8Z68uZIqcz2+xdc5+c0ofem4Mag6L0082JHz+2rokBgZ
cuamWBUknb7fkd3D9jh58OkB/BnB3/uH+4f498HhAf397eG39PfDw4f096PD
R/T3d4ff0d/fH35Pfz8+fHw4cg8+PTl8Qv8+hD/497PDZ/T30eER/f388Dn9
fXx4TH//dPjT4dDB8+749Pjdn46f946YP/c0rllpo0V/pqp31YaTbRpzPB6T
94FG9ksy4sfkMbNnGcb1lt1gnOzP99ja52CRsTW+8EKHZSHfeYYIWfGiBYW6
M2RumkAKEf8MZNjI3hJXQ1rZRCXbssbe9zGkBdt5+j3HNrV4RRIEmlm0il+C
EXbCVcMkuxpX/EfR1OK9nxdqjm5z/d0wlfi+pKZzy4pNLYTAvB8NhMtYgVMo
4Jjz0MORttEg3NBnmUiv7JSLRXGRLz748OSOAKPJ7lbSqkzb9fAqTmQEXK5+
klEpLKXVQCG99rivk3FnP4kb12b9uY/BndQ8iT58yr5hdjIJX0wvo+Q3TvXr
m79x6PN4DHf/xjd4DlyXrZDi9b6p/znEq0MfMQELeCWpmtLLxk0R2/ijsRAG
68bBJWbUZttT6E1+3ep4rpAVgcITcMTkEqD9z5Px88nH/B/ry1q5TYrZuK1K
5N4ATcktyijsRoeSViCHbLdC5MvOUx0JsgBr/sTQdoY3JZjJTBr0DvQwAief
5XBeg2I+umzQS4L1eYFtPpf5KHubg3ZCsOv0VV6tQbe/Ak1+CUbc26akyuDX
+NvT9WJRXuVgwr/CPH0FOq9etloH9jyHozV7VlR/wx7TDKFXViJsDgJygv1z
eG40Lar8S8ScCCMj4OTL+sK5P2a/+x0aO8czJIG+37LJ9LvfZW8XpFBhneor
kRqtR/LEt2zN+PhyDk+bE7REi601xmsaTZ9Qzyhit4LvVCNdVAkHSNAtCrUQ
MA7mu592NXJRr9hDZP6uGVpF47Lo5mPMthSw4uP970DPZ78UxWqcIx3ybZc/
wsvBQ8iOjk4PHhwcBJXKBU3rJTUu3b336Nsne7c97OHXvftbvJznHo2Fckkt
K2UT3HzrAQ2b9ALWiPlAVxofg3HvP9zDi0/46Vu3JtlNzMMFNz34lm46WuRU
h8FY4NhkYpqN3XsPnzyma48/rXIuZw8NiQSdRVbw0hcftnTXPt3F2b4xVe8Y
Sjrh6wxaSFga4MbH/19hV9PTMAxD/wrS7lPSfLQ5ViBuXLmiCRBCGvQASPDv
8XtO2qSt1EumdbWT2Y6T2LGtgLIxkGV90qSd2FuWIk6rOHSdOHOqEdieS34i
IJON0Mn3A9sgbTD53yxsWbhCCLzlB0IkQic+SZFtIg4Dy5B8Wn7zbBV7j9Ya
tvZQoCyG8jC1pW7maMSsbMvOAaPzyrfxisBMMDqnk5Cfos90u15+N3KSL19p
1haBpeblHMwmHGLoG6HAnftVjki1rDLWcXp7fwZQb9b0/GgJGknKSCLGju0x
YQwJAwcFRtHkucQ42oQKN8UugO46dtG5ihjYIv58X2rFvhVFgJLdPqngUqCF
DOvFcRzvarkXOMd/6LvMGjh7cW+egbZYwdpkZ2Sj8qoKz17XG6v9LZo5c9/1
gNEIQmuqzqvc2bkS0YuouT/e1mHCB0RFPbGG7J4rBzds4F/RaGI499ABhNzb
oBIyO9nKIf22HITkVaMEfMxx3MtL53JcOuvaQp8jkTsgD7GF24YDV51Y1RLM
37m4LubSjfkgCOHBy5s5v5LRjhx0FB2XyE3Ka+DzEI7k1STgv8fyCMcXPdOl
mA5MKyeXlEGc65ojTT0QKpu6Fc+nTb39jzrjr2oTVH0rLKmMg4Kyh0Zys7r8
bKq/f+Xc9VWeHozCNjOcOZd2a3ZXUccCRp3oBplT/8MMB+yehAEA
H4sIAKtogmkAA9y963IbyZUu+j+fooYdJ0TaAFrUpVtS2z1DUWpL0bptUe2e
Do+3VAQKZFkAClNVIAVrtJ99r2vmyqwESdn+cc5hxIxbQCErryvX5VvfGo/H
rq/7RfWoePfipHi6mrbbdV/NiuNFXa364lm1WDSuPD1tq4srH5k101W5hGZm
bTnvx3XVz8f9ohtX3aoe37nvpmVfnTXt9lHR9TO32ixPq/ZR8fDBvYeuXsN/
9e2m6+/cvv3w9h3XbU6XddfVzarfrqHJ50/f/eQ26xk00T1yzWnXLCr6T/zk
UXHn9p3vxvCzabPqqlW36ai1ykGH77qyrcpHxcnTY3fZtB/P2mazhq8XnftY
beGT2SPnur5czd6Xi2YFjW2rzq3rR8Vf+mY6Krqm7dtq3sF/bZf4H391rtz0
5037yBXjAv941E/belq8rbpp0y5KV/BfvYKuPJ0MPm/aMxjUalatK/h/q14/
r5ZlvXhUVB/b/2j7+XIybZYufs3P5d83503x+uMmesfPE/sRNf9T2fWLbdLy
R/p583HzH2f4QeYFr+rpx+Jks1jUF+UqeseryeBzetEx7obmrC3X59viGJZg
s+jr1Vnx4sVx8vZVPT1vFmU36aSd3+Mu2dmV4/O27vpmfV61xdGk+LVpZlGH
jifpx9Sfo/V6USVvnpaX/3FelWvo12ndd5NV1TvnVk27LPv6ooK1LN7+dHzn
8PCh/Of3Dw8fwM6g/4b/vP2IG5zV3XpRwh5+9ubnp87Vq3nSxG+//XbIz8qh
+lF68rhp+q6HScI+ZM8RHaPisu7PiyevToqTqr2op1XxuF7N4CcdN1q2Z1X/
qDjv+3X36NtvLy8vJ+18Oq5mdd+0Exj/t9inb+Ez7An9pqvauurwYxkE9vNR
4b8viievnz8qDm9PDr+/9+D7b2UU9B2fryfVtMLjigftPn3ujwD9jXW2eV0e
w0aZnl+Wbf93/0W3aXlRB9/MYS/wV4+r1d/KZb0qXg4aSN4ADzyuu/NmPWw/
+Ty0/rL+WMXfJo3COX21PWur1bDR5PPQKJz6j/otfP3rs6N3v/5p/PzNn+/R
3JhpkpfRDuXHXNgke7+8fQFb//mbi3vFm7KFFdtzmdXetItJt66mk8vzsr88
o+X+BoTetFqDwF1f3Buv6cfOr9zLcouLRosJ0gue7WGnybrtcT+KF/UF7skT
lIJlO9vDkTw9fjY+WpWLbVd30X7eOypOtsvTZgHiTh8omnnxpoUDPd0WcCBo
dx9O7vJezl8Xezu387SbNJ8m5XSy+fjtumrgLH8L3ZvCLyfT8+qiXHy73pwu
6u7bx8e/jqfT7s6dyXo2N7v1VXPhd+udHSfA7/jDe/e/vXv/3oPvbn83uXv/
/sO7392mRwaTVewdH58Ut+7ceQRDbaZVRYcSR96fV/Sq4uj4ZXHy/E8nR8co
BucVbAo4v80K/rVcb3roEUww/mO5AUkIUgNkJRzz6aat++2oWK8nxd3v7o/v
fv9w7/pDBhL/8TlMX2nEsd4rbV3mf/TnCQhVnMMb/+I4FrAi8RfNZjZfwM2q
EvLew4ephAQZNn739O3LE3zm+fjJhO+e8bpt+moK+2EMikH6ozdvX797evzu
6ZPxyavnzo3H46I8RbE5BXn9h3+Df/4FRFs1+ytcqTLBHVzIB/DPM9i6uI3/
Yg7hX0ewOrA/W334VkebpIDP9GhM3DtYQDyA0LOLegYbta1AwbiouqJvirJY
l2cVb+W9F3CnFr+QHjIrDu9oG/f3Js69gmHB28pejrc21xV7cLUt677oVuUa
xE/f7cm2qdtiwWevk7PX4RZx8FVbFTC9sHMvqrZcFGkLxbxtln4I3DvchwvU
kPritMJG6Zk7t50fafETHM7qU7lcL0hrCuJh/yoRwy8f+5d/e3j64PTB9P79
6vTeaTV7OD+8+3D6sLx39+H89HB6eDq/f/+7706/O3yYFU4Hzv1awRRjq6D9
FKTWYXfjlcK5xxEtGxgPHJEWRQdMBiqFeupEjibyawSNwG6acpu8tH6Clg3M
6lm1olnFb+Q1ugBXz8TBiI5wOaOdVg5Wds806fxQYHMc8wAeuWh3+lNV6NUx
yl0FoyIvqEe4frYNXMpR8YevvS5+hA7ODoqffns+UhWm2E+0+O5iejqupucH
MJWLBWwwXjc4BjMQXzLT//nyBU7kGY749c8TOL4/Jqf2zaIquwpFS9X2MJfb
QrTwrtg/rbYNTC7IvE4OEihLVdnC03gi+AI6oAtm05FcvUIL6uCH0/NJQV14
hzsL7JPNEjcRHMlpW5/CwSyLJQypXNXdEl5SvGvLVbcGhb94UW5BWqtoLvbh
QqMXu4ovM179D0Zv+wBNdR1Kig1o9CDp8dKB7VrQZTXFYU5Yni3r2Qz0U/cN
iN2+bWabKV4ExedvavznF+eOFjAFm7Nzf41+/vxvsCwP7t377suXQnrQ8cGQ
gwBjmHXn5cdqBOOYLjYzWREnnZjCbNdzvHMqlIipdLkstx1OwOU5KOiwKjC3
sDXgxJR9X04/YgNwycDStSuQanDPowRV1Rf6Xp42m546ArtrVdGAJgWKVTiH
MKzqU0/qLDT0CtQmB5aP3H/FPsj5A5BJcNPSyYZeZKcVDDDuHfTiY0fvYuUB
7E5Q8Ve0LcriDDTxlenFCCX9umrP4XwGcYJGYo1Kux0FjG/ew+pVXl/BLcFL
MEn3EB4rmFDaQ6vqkp4Lg5iWiwX8PtV8HGv4+6BbHcgGh39fdsWUvqbrRt4u
t0M8FSJX8F28rpOioG7JlcojhAklIdXgOhfrBnWYGl60DcN20PPFDG3aDa43
/w7NJlmVMe9/0HPABm4WxSsw3KENXrCjF29eHcC91fXu8+d/R1Pp7u3DL19A
s2jGi2ZKMoG717HYRascnsZpwykClRo7c1F39emCRwNPzOuzTSsqEfb+tDov
L+qmtRu626zxdEL7cg/wo9OaLMRuU/cV35/nzSUOaYsX+ZpkSoPNNEtshSfb
7BGYB9wEuO/LVbPaLvHId1U/KfbxTne0UjXembj0PEGy/tMCDFow0sxUhl0A
Uq0i0YizwHvJ6W6GL0HpwTng2wxEaQldhH7ixdjOxgtaAThXKOlrfAEcQRwP
GNcoEGf1nG6X3JyayavwOODR2LUi2Kl4+icHxS8kyEi2wO4KMrKF5spFJ3tX
ZxIe0clcnTlRmUDeTDegIdKL0YwVbQj6dAqyYtbAHKyaXpqUsy3SivQW3OnR
chQwTFhAVHAGouYJXPjNlk4mLpRXrmUIbl6V/UaEHuia003X8fn+/Hnmfwp7
2Dk4mzgg7Bp8XfddtZjD2s5hrWmwMDw5bdSJGr032EERxHIuSaVk+VSIfFqC
qgVz1+DVqevUn7ck6Pmo4iyvqkXYSy5IT5lq9Av894asGdxB2o7M2/M3qJnA
HumqblI8ay5RvI9cEGj4c7+anX8NftxgA8/evXtzUvCpfnDvwb0vX0aF/xJ2
yrdP8LTKqX9w/wFcR/Lw7Yf0MB4+/4P/9cvzY/n+4Z37t798cbIHbB9wbxrx
R9oJmCfYyAL9VGtRdVdVj+471BzWKtrx8C9RhwgSsSvOUcAv0QUFB1Ymv3Nw
ymh54PYx0zRhqxVus6atz+C5aJV4Z1Qki2rU+kgLh4sibGU99CXtY9ClcHN8
2k7gaufvqtVF3TYr3F7dyIvntqJe0R6H+3RZtls4xrhvUZesz+A0F2DX1YuS
dklTNKc6PPjHrOKTUJkbHuwa3YphEwd5GW6ySJmA1Y0/fnh473tdR7jWYBG9
pJUNjs/jvNMP13JBdBNUZ8DmvcAuqFx+Us3rVU3/dnQgQAcqWNfbe/nLyTvQ
a+l/i1ev6b/fPoUd8/bpE/zvk2dHL174/9AnTp69/uUFfO/kv8Ivj1+/fPn0
1RP+MXxaJB+9PPptjzfM3us3756/fnX0Yg9nhaSDv9VRPPS09njs2nVb4eTB
+qrKSDP5+PhNcXgPZkw8hnQKaFIPv4dT4C7PK9mczQqEMv+TriOvz+LFDwJ9
Xfclnnd4A1gPl6DQgkifFEfwJcplEEJ858K+q+Qc0Ftx9UaontK3d0lwfVO8
vkBRW12KrqKLgzsB+g+7qqKLsAF1iBU46B9L+UtQLJp1s2jOULCAfr9Bk7un
rQ8KysixeL6sSLOBdTiHmZoVL5tZtceTegKbt+cPSPHrUNNC25ckrp093LPz
BvUeutJFgkP/vyne+T4493/+z/+xlg39/X6c+/v94Ln/ST/gT7PP3bl9+/DR
k8cPHj06hL/dz+XaE3/WH6gbP+JzohxPxMZGS+Qr2hs+x8aDbw72wdf0L/3k
pvOnf6yym6/3ecTjn9i4xpV/jPYBe7VOQSTNDmjlPj8qvulok4xxG7Dp9ke7
b3Sxt3tg8aC05K/waZaTKmRx++K/WUJ7FQG1fdiK+I3IeDhoaDjCzeFYh4Ij
0NR8Zdc9iWRWZ/wrRPUULYJepCoG7PytiGfuxmSwJbOz+fubTnR2zf7npsuZ
3bn/k/nqKfzxr6PNuuvvxxu9O7Mr9d3XHoB/btz/3JwX8fYVi9T86WaWje93
Mgq3eCN7cTfYx/RNfhujUpnfympUy1aeuLclqoTcBOpCuqMzD4ddbt/HF5Dd
waAiyBvbaoEGf6xEF6cweG0l6iFa3o1LtO/k7Hj/GutycNqWqHqUq36xHXnN
2NoBzpsAYKuAZj4FK6rzo/CKr6gdtp/qJqqsse7wdVZR8S6RCa0LfsRqFy6G
mjZ684/wbiPHFjnttBsYBEn7jQozfrfHIx3PeTPxVPFtKL/GKdJZQ3HFE7d3
KptMfkG2QsemiVdRxaioE7mIllM93GNRTxxZz9E7+BZen2+7eiqOADDQUMrB
3JxUFSgVnbi6xmQaziqxBUG1wR1HTlOxm2J/D2qaYMWAeUX9WdDb0fyue9pm
feXXlHs5KnLzxrs17jXrBPkgKblQnDvKNgazh3pzR50DMc7honO+sejDyOAV
x5KrUWtV/wuOMnju2Onbdc20prthWfUlWuxgePq7hxQkeA0M16F7Et+zBD1K
X88bLnnzplPXKb3Fv8El5yke4KSInFFuhoq2nMvB8G6R0FiWvRje1aI6o2VB
scJDZCUTzAqwODo04MUYuPfdbfTrwA5xpHaiY1h2hPo/OtkLuOSDV3eIvQBb
6wK9j2Jwn/z5+DFNJ9uaItcmxWsygaF3NTy9tRYiRpnIJFs3HZm7URjDngCy
3kiaZGcCJGGlH9DW/xU08+DGuCzVBdf1JS9ZKZYl73pakw5U8WSjjmCzE/Sk
bzfohCu9hI7cdyOWLS1r4SIN7BPPQcS1H9h3IH3qz9mbaZrmTXlty84+8RqD
jx/YIzv8HF/Q0y6uVyvYU82mKy7KxaaineOCs9S7tti+g9Oy5+Xve+7x+3MK
7oZH3f7nz/6hsexmeujLlwP16U7LllwaOCPBW5Gbm59q8nRFqw4dhJsxMy4N
7ag4eef/UfRwMXTe/oHPg0lSslPwkXOHcI3NUZL5q0osatpbDXnF8dNZ5X22
YeC4K9BwWxNSiaL59lbi3ZRfJDjbGgkLa9pWf2MPG758EvrWbejmREjCVnvS
ZboCS3lJAcb8tqMO8nylu1vWSIeS3K65/hL0oaM7fR267H5ZN+jCnFYcxgpr
c6sTT20Xn2fv6UABW5GEgFnHKYcG3aV/Bbx0Hz15/DS0jZGqMX9XrqYVbDXa
sWsO3HdBXfHjcPB0QwHkxXZSkGQQLwpPfDUbiQ6h8KbYcsBObTry15xunRkD
WSrBtV7wvfEcjnRVQpv4ElnaZqXxAPNzmMy26kEiUpc363HfjCmCHYk2HL72
E8cOA5b9ru6ls6Zc4F6XQVGkodu0EmgzznD8StWGOnjNEl8sCnbEJXU4FRuQ
lTRy8lDgoYKHcbUmoCK3VSMyEn0cm8UMZvq8rkhIQ0eoXzg2vEXK+Vz2OHr1
qk/cfKHKCa7fGu+SirQ8H5thFQZbihUWvtASbcU3xhuCQSv0W3Ki5PWN42iy
P3+D2ytagC/sdIOLvyuebU/bela8YUn9M1zsT4NSsY/AMQ5iGv3CaB100yLi
DL0673L3GDt08MpXK9VIrw/wOPf2Q8G3BiyyMV6bdfnfm6p4tv5YcQehf384
nEzu/O/D78aHP/5AD21A+T78jh76uVo+n/0Qm2Tffsu+Pb7RobsF9nfwy9n8
H/zlEZyM9KfX/9IP/KnKvXfbdfVD8kt1mh3CznEMDqJZKj57S9F3vvg4m7+v
Zz9E33DnihL+x3/3hb452S5BMWzr6TEFpE4wHvXDjndgnx/Isg5eQXMO+2I5
+MYvmWye97B54idynZAI2XuOkP3hnqz2vR9t76FRnr5dXc7Pb4EA3dAF2V4o
5P5wO9lVXzJN7HpZ1CM8Iu+n0rl4Bpflp3q5Wb5HNN77RbU6688HnZGpwkdo
p9+//+MPV4zKqDlXDeGY0WHdVSsMu1L85z+kn6d97UAvh9/v+/Yn8ssD02YB
GgeYFrc/zavbs0fDvhRT3yn9wZe03z+QKGBdSOVD0ABjYcJhYtCEpC+P3CPS
IQ0MB6UTCjNWEoY2DgorkIqzif2hE58e2bqleiJmlbgysD1UYa/XLicipbuC
Agn12QoFP14eRg66ME66REvff3LKzxqr2oGo5KXRsfK/MAwNwrbHQKxojCt0
T9AMiQ7ET/JHcpO7OGzMl+vHes0BMlLS+Gu6azmaRKF11HfYIbAVLdMRVoen
TYPPZh3MeGEIug9wEEcrPQjYf1x0ikmTs1SfKxiJXkiYTNplQ4tCJPpKsVvF
JcO/JSNvZXqg2zG+gcj4uOqZa3dhEAM0ruJDJCWilsCg2KqOmexHg/gwJr3X
CPF+tlfzPpo5uMvhH3sHkyLA/Hhi8r3/4EX7B+6/qtGkCganCDp6wL7NzAvM
2IeMdPvg92WzOkOoH36HG6AcWqXz4uOquVyRpYBbnP4liEgy8AjWc1pxdL0p
/l61DTzc65nlgCxBV4u1YN5A0ZT/VKVajSMxgcvg2aSucbfBwkfkDwdYq0+o
hXM/5NDU81FRTc4mIxesAtamLuvFDJZzRq1R1BteD79G1A1/JFMZYzecM2Jf
5wxdHjpfu5wrMG+TajLyqwPtUWZKNUPPCIPe8v6FYAqFyQODCKT6su6C40HD
3SOXBhZTHR4G8ahg5RahwGMe0RhHIHquAF08EkOjlmygwxrXM/XY2vmAhsMl
x2eJhA7L8/Q+FF+A7PngbEHnFtrRhFtxkeOQgp4Cs7wKLDcpnoI1kHmpO6eo
+p1xA9PRk5LBEdWgX3C/RkFSmk9xEeDygCtFXGmhKZyjM3KCw0R1uMIiJmQn
ytbAtkjoK/AAhacjSM/kikmKw50UPcUjw6s/DpMeDLQrhNg14tDIGF5DsLzG
JOMZCgAPtnqXCjCOhBtKtas2LtivBpFRM1av8l5KegabjVc0mDCTwg+4nsFI
XQBc4n7NHbqO7kt5jUqnCUp81IH1+FLvxZ4q12CH81576fFJ+z8/fXlgR08H
kCBgAk36EPTmDzdSHopUeXA8B7yp4X07lAj7oqj/5mqR2Y7NfY8AzLm/XKTJ
+6tAzq6fnycVOSBxcn7arNjg2f/5yU8ssI826Fbsa4bqGduUBngU7sQneJ72
j54ePYkmdV3WbcAsIiwN/d24IwI61mV6L6KsrcoFyzcvwnxb5w1qJYL/wtsB
RibnJOvp977ljgC3IBoo42Ke8UWTPFbJiwkhIBz/zugOPludsZL9+of/egFd
8aYT2gNejf4QPZM9weRoFLdEdnN1hOmrpjA5tLVI0OBA1gFFzqdUXEQeX4wa
pXglFfWk6nqnM0FAKYVEdXg9yBcYBlqi26zjaEvs53ju17wrPn9jjvTOyAtL
bVQnGlE+ouGKkBQMoj2a6jGHY9HJQLEVgfnIPPJBYST9wsd1qpm0SziaS9hw
BJ1rq4vaeLLp9kLlo+sFv17Tvh0VHSYX+S2Ij0zhTorCrm6z5lSQd+9e4DqS
7oUeZRB0dhrGPA2wsy3GvMe9pq5ZCiyhG7LjYK5+LHjtSKbKROAJAzuiBEVi
XbWkvWKP6YrdpcUUGJaivecIIbdrLeAVMK6LpmZ1LBNP1AZ5KZyX0+z7gz5Z
VTeEDYoKL3b7QoZTSk8IXguHxxmcVsGgo7Mt3kQXdWn8oh3GeqAzXjlrihY2
dbOkYCZazvY2xLu9QgkG325gBy8iHz7o/gRyz0wKhop79eauKlwk9J3SZTcc
ZTltG1jFgMSN47AGsXcapmsC93SsqNOWgycQuBjAhojJ8i27/J0p52gBWh65
/oZd9I5VGK3ZO46306T4Mz9mUY9tRddSPRc4gRyjaCVxguQQKKQrLGtGkDwN
gSMvR4wuxL7T2EyzsSYQmqpRK4K0beCKmLMxQBDDcuHmctWBYEf3LnQSrAz1
PLDRh10vg/cUZO7nz0Nf7hcWmHXbNij5PqvP8N7kDso1D580GNsrBkDKK49C
DyVf+8+PXh1F4EJHNsBgfsZ1uSrxbRlXsJkmvsWc96t4Y4CfbDcYEofXRakK
3SPbxMuj3wSjiF3BTUP3EEeOe9KzFbCJW4WuMxCsDCQ0wPc5I1OxF6S5i+g2
bzoFKfJxUvyyWmBWbtylEcXhvSWA4u8U0dRnZ3xdLzH7qW/gYJ56TSydb3In
sTcJzwDNynmNUGu6WE8xGsFG7yFmZ1k9MPhZQpOkYVGuwXk1/cgpSKsAr/U9
MmYVWd2oG+WeswkviNQkQ2TkLyHshxN9tI80DBRRR7Au8w0pGDYJB3WpmpR2
yldYzResDWUCo3Ktnlbq1+GJtWfcDkStA44l1QsUV9NyI7PUYJsuMQYwdNMx
/pUcW6ygsNbBrgAM4tZ0IE+b/pyhFxdgL63prLo4FFyjBpkYHBKCZrCHIAIj
zRZVbLC8Sd47RlV3xX4neBcUoWNNlEBzDAGCqGi0ZdfzPZh7K3suHdJLJN+Q
iNpgiBOP6SqkzMCSuW9ICO10aAY78vM3O6LloGs2MIGIToL2MwHwG4XjVVzn
As8U9JSbktaGjgPdC/iG5EiA7MxaKKJBV6vNMniu8/3aZ0f2wajY/+7+/bv3
D9RXHQVwnOrZ63K7aMqZWuihK+dlaiN7vfpR0Om5R7xd928fjHh59w8PxDse
xsKvzbr1hw/GARDrxg/PTfCZ2JHPnnzqzCP7sQY/ro3j/JD+amdIKY6GwFIM
whrDp2SuB5FB23mav0Hnny7XfYhJfbFxkzAhxnqiKTCLSU4/EnoNC6sLEDnl
qlc8o5zK4Q/cB/rG/4Dv/fRpslBAamAvdZTqm0UpR8lmcBWrhLOpJXiFo2ZI
Jlisj5irjYKM+AOmxVHovPxWXzBIdOTuprMx2Npul/sn716fBJ/5xLqkxSs0
xShAqgJ/sNvMt22z7Lw6doWvgm8NEiGicbNS6nyWvRp01hDMDSHyeXxQnwC8
OvKrVN4nJKJfvStR5kwA6sT25wfZCh+iiA6HctCXSNsFdaLcddqx79VjWBC0
Qd+/ReTGW3RLUJflHdpt64SAvW2AT0/ZdTmY1CDXRuFxxyoQTULOo6zelgHg
jS6T5KyFgNIV10nQcgK0F7YGao+yvW9+GYFJ6DzmwtgJ4iAeZYaUN7lHPoRj
0kv8jOu1lJPn3nVTENJGjktnJFemg+Fa8qvOfsvapP3Y2eEjkwXgkarYh2zt
jqF/dRdPldle3FAs70aMFgx6geP7+xQ1L/ZdwqIYdfS9b30PRFpFbstoBiR6
eK1/ixxW13q4Rte7uEZiLGcco8k2cINYiWQdoYxmW1Qkp0eY7TGOKvYKInGH
xxQmHhV7QHZt5pE3lEU5qRkdnqyNv7w8Ap8kj5jwA1nhtS/3defJBzG/4gTI
hU/TIqbEXx781Wz+Qe/C1udYC2v1Q4FnmyzEoQeS8cN5275nbN57+8iHzFEX
T4kc8jH8kuRYnItPGqrFQO/BjnjfQi/qtprJ3h55hIJfXjoeqNlSxh5OOS14
dUNkK9tZCEIknUCBiIL+U6T2vsTvsA8ddP5AUe2NcjQUqZhnG4C+H9M2At3/
cTXHkxUc7JEBsC6ZOAYWkx0giy0FbjkVOIf2pFRzCtrf4KrxYDMMZ+3eSRFi
zk5aCtrBOHP3F463vW/m7yWgHDZdvk9h332wrX8I17QEq0l2wL7CRODyI0dq
ps2akrQzc1GSK673gcAPiJCfbt8L7jvE8H3QnrQBBlKQ2QhKIofVWTszOmxk
IQbBGRxQkXvpMHUwYebKE2q97r+mVRdavT+5K21ycq9PHqg6q5AWzzwy2Td4
C8bTbFqOKZ5X5YzdfdSfFWqQl9Xiokq/xv4K1JwWWieP5BkId0zbwy8YxClR
1w+D3fBBTfUAN4CT/5Y8u7hSC8yuj7xGmoy9hzov5c3ssURcN10//u8NyGGw
AMvFWdPCp8tuBL2BIVSrzKag05SDysOZWcBQSfn9hA5iBMZ3oMShJx2uz9lm
KiAd+Ezc9tFZRS2p25x2fd0jrsIYDmKEME6jc8qzM9sweHhoM3jtQbzb6MBF
zotlc6HpmZ4JyVlPIcbXdp98CZjjJb0QYUrqYdAXukgF1G0XImmPdrkBMk2h
E2B2+/Z1TgAOy0XIQxp+0Mj+cAexffd+ZDGRfBkH02mKMPYZtacREYIk8NXW
BpIx/B0ZMji1O/lqbKaF+ODpmjmtWN8BdR17AgpIs+nYOTbcfD53b8fkm9fr
oWJCpV1GFRyAutfe7lr3iTvyvnTNsLC+YVImfQJ75mxYtDjlfuHREMSEOsrF
i8wRBLmil6zuMrqEQiFhigiC5nyuT7qqFK2T4KDp69GoeMyTeEz3/iKndTu/
JeJfPqEfww+fchM/SQD62rWYkiOcvKPWzHe7Txo27x3qYW6rGmcpN8VNm3e6
5dJiSCmgXSvEVGQLm2suks4U3iSMSx4gSCA/kdysa/ADit/iV5XLZkOKs+LF
iA5mNptYOR4FRz0PHMyVYsy66Xm1rK6K+8tFn1NtWASSIaucchJvxeyhVpRr
cvJ3uw/DKIRPSJSiKN4SvdCcvN2xAgKST/ouXv+tHwvjcXC7r8Y4d7HFjKeX
DTQBKkb5tKiGwiUA2sjivY/UB1vtFWw9GsySkpmCjtPvUpEogtGsa3WY7VR0
+IbIXzVkZSI3C8d5y5W77mTQpMyRymjEeaF4J2m618B4cbHssqiO2Mu2y5h+
9y+ZYDTsKAKW5IdRTiO6/+GS+12BsRh/SczisA4xWMMI8leE/jr6iWkKfjWQ
dibeRqyCv9ttplzXGP363XnqucxmB9rlIBW4Ie9v2iRc0QKDaqbTTWvvA7kG
nOQ6G8FP0a8LMuNWgW6O9p8ErFl/X+MX8BDiABSH7Ph5PPFTZCscAg1lCKxZ
zSpjE5G8W6LGSIpkVq76wFegjJpvWpLNQh2lDUJnxtA1Mk6fJ5DvgGERgynd
tyK3agwzrjD22tcg/Yr/tSln6KWYFvjvIkWS76u6y0mvcHmsCDSxKpHgDUUB
TMdBge4WkEAljH5Vl4txM/cZ7W3dfZyApcBvHdMBjiCKkaCWp6gvJFBnPntM
AAzotXFzQYwX600LakfFcAADOctYvbRKYPWW0VPcIY57+T3i4ZjxVlmCtTz3
gO/MXc9KwMeqWvvMQ86z351s6sT+mMO5l1Acna3xEtn9ytMaYQaUxEoQKxN6
zCWjOkxEL1kgDL49OnryQf1VBpNOeFacUPLtdlW50Pz+BlabfGhrzdTfkdxL
LdcCFxNvs9thP45uapZ6jmekidptadJjbL3yAST1OWPDyilFe2rdO48zTnzy
KomvFnl0tczUhrEKjTK0BVA6wRoyeg7pOHL62Q7wGPcrreVih7W821h2ZCwT
eRYrbY8lIB0wCTH7oEeeh2uDYtgpnRMyej5SRRLVasehY1S4ykXcQs7HHsIG
o4JjRVsOApfuT4zqroq3hMCy4J4j5E7ZdKSOy8d8TIr9P719enTy9ED54r5H
ykh3bTfO0FlcqYdXp0RWEiwMlBsE9+CLx2nUvWKcgc+ypf6facdBGG6Wy20y
jzzRneCAdznyZrBRxmC8Tz+ifJJNTvAT2HkrjvcfFEFxVScyJizXc0E8wNiQ
zEB4BSh5A28S+DVm0Q5RPuyhQn8xTyO1JuLJTtEBMwle1ip3X+PLJQEbBKxf
1SvABOw3YyQuyY1N3VNyr/XqK0Oj9667JEhAuMJAVIe6lEDQEyCZNs/p8oiu
4S3vao+mZoGBUGvvuwlwZPL1hTYn0xD4ROg42tI9MtciQho68vOTn75FQPNX
NRUHIEdOrfMkDU6R8mk78hjMyWvUY0vnp3SQKSdKcoTtWHhm1ygEW/dEWONS
7DWp230wKwVTXca/bjyzH3uvPUeH07BLnCBAGUR2k17R9SgGJdqPZN5fd8TV
qDETYNgvdihOat/+DRNS4AUK9iydknqndBk+TsJXTsCsmcAJ4eWEBMJMJx8a
0B6DqOE89Ds4p+QhD3pjgJD6fHslgkgwoN4dG5pl8pGQqijSaWUWgaBtHMWc
7OwoMhYsOa9BJU6o0XBHyHax24FTAm1flDaS/4UarmTke1Ev0icJVKA2pKEr
jC1RiI/thSryxWEWPvqHFtuo43q9XnnPx0BDlP4abSuJZyPZYLvYR0Ckv2PG
+eCFEuiv8DWcchkZHxa8SUS789fMYLNjW8l+P3BXsb1c4TgaREPThaA5pciY
95WUK4+UUCQ6ibhPHJ78AJ8LcNiVxoW7/vi2+GPxpPIKpE9C38/IypD2ciAO
4OnIv+aPxUnVb9aPYQJO9qHd0U7qQf7b6xcdOo33iv/5n+L2p9u38X/9Sw/I
0eu9IGbihIAYFJ2dqrYXEoH5/18jJHYKiLuUu3jaXFTmpHmLdJYesKtctQGd
Ry4fdJogKCsy1Af+/qx9W7E/yHgu6AiVxhPsHdjWno/9uzShOU92dLi1rwW7
nf5L/U7/Bff0Lr+TtcSpY4EgJeS/wA5pgtd72ns59/yJLUdzq/MXGCml2B6R
+oksO0IbelZ/Kp5M7kX2zgGLAKWG1nWdmWRgnn/TOLfsiWFYGCnbLgOqwzbi
yhebBXPQYVtrKgxQRaNi6hn2uhFmVveV5+MlNhSZ8aPfeMLJh0VmgJniHTep
WGDw/sGXE863+GCUat2DRq+eQx/P09/TudPf+9Q54mGpJI2j4HJw2lQj+jZL
TGOAj0F4ThmjD7KTR6oaBhp+rJYpKiGny5ksWI1Y4Fv2eDfR51l+Abp/xb3F
C8erBnOxJhOJ309VdEJGiCSjyvWRf8eIHDHFKQztozonCKpC+9PnNl6ZKYwd
mJf1Qjx05LtWnl9VEjwODkcil14Yg6apgJL8Q8HnIY+zog326xVIGZBnHH2d
4S2wtztWFmQZdk+Wka4sj3pRe+fmjbIvgS6WcBHLAixLglfkFdB191FQRBE+
BFUpOL6stkWILIpsiNoMPX1z8nPMdJhy9mU3dM6jBPZjOr8yIZ2fEdqzOycl
QW97wbsHg8RH38NBh211Vr0nkmaqNnWVXCC0yA53+3XboSrbxfY9urJuvBVC
z2N98CYtWRY1c2Ekmx/Pjs+MRAsqzx7XlfMKg7Q+MxhbpG6wb46AejFObY2e
zCFH973JncnhbQEvhRT6+uy8DwF+ChJl6faQfAQlvpaPMJlHqV94VTE0lzLz
p8Jobrm+8nx+DE92ioC6IrzCfhD2FptNrK6QkI91tqlnJQcqcvFJX8iGXnQ1
GoEco6g6aapnhjshYKPibo2kroB433MBArxHHDtY6JBHxIGBOa5TAI5HYg71
8KtI6Mgn4ynGMo7wkP2RjsK5P5H35CrI1ugrNHx2YlyjJ++yw7MxlrJzIY9a
Aq3m54bKj1VAcsC+oKhemI+dYwuEqOwQgemmkaIvJ9jbYAwKwy09uVmqxh74
hPnF3oVDvqC+PJPPI/kv5pilPcybE3TD3ggzKF0N0ktoWCw4hfOpFDiqaoz1
2Gdgnj4rYGzTQCWNaQcfgr+uBkkAwan9AzVo8wHsqt7q9MfWuUS/wa1GHl32
+tHh/YECBuPg2B/hDkS96bxZUFqeISgy2OIX4pF3DoymxPFkUtRFjRf/reR0
dkRTo3UdJKkOlFebLOvT4TQnsAzZxUGJ4Ei+FDAgJ2nuFFCMW9IdL/guhOYG
4Nhi/9nbtwcjp7aV1J7iW3nm8zM6JKzNAdHie8Sb5p0qdAoJjETfzh08cc/N
dt/obp+j1PbIZusToG/e6zd/VCkzOanKxX7mDdcZ+ujDyp98NvKf+xpQV8bO
WCTAiT6tVxmmU4nEZXQZFaD9+cYHpMlMkShjl4QZM/lzxY4QYxbeNbg2rlMJ
81eoR1KEUBnTykbr84EryOBp2skKjDEjwat5AmUTKcM62BK7iFLjnRSsYo4o
EeqI568/VYE+NOS5WD4wsZ2ZMI6/qIkfliyTq2H3DBITsC9DchCiw3ZuNnVV
uKOjzNXhZNzq3FWmRqcRtWZZ9/jqRkiqVGDQxoPO7MdmxYHc/GLNoKnw+Rvz
gGTmNCZaE62zTPsab1B6b2R7YHNS/KdmIpFdqptF4fl7vVxJZO8Kg8Jl9EF1
zWhdDcwJlBwKcjmrmW/Is8NrmecrcYJLHus11h6SSJgEO1H1L5FaVjF0JMIV
KaC1k8hJZat0cVIevlR9MAHV6pkTuoaqMlmm+ILfdVE3C+VFCr8jj6BLVFPD
GBAvNJuNeWPIkzDJ9SSLdCOLuM+m+OK8LImwqzczhf33qAo/RWYmYJZCYHUm
JLzouLdXkN6TKapL74jTrTnmnLH/4TUbG2+6j50laZR7PG9DHdJ9Hjh7mAse
EbvmGGxdTDq/W9xn+u/PctRg0D+DVAw+9uGvR8XdO+PTGpTgzUpqLynzmBQI
UAb45nS+6Shu+B7DylX/Hiw8OFcv6o8VRnJHgU6Fk1mxXyxnaARu9wh2Ih9g
7d4IASXzQsAjcdDfHJOc9NGgkjOQOploTmE1BOHPPeu0Oq08vjnylDifHMUU
iYLh+CppEAKQOi0mCQ7fmBCwXwOxRKH91iBU3wiq84QQqiDEFdRKquku70ln
cEYqV+SHJmDq+efy4nvib3PJQfhYDEuw5jzwz1cahws4qsD1c4MEIOHiU0Sr
TZCV8l0RUMxbwIiSMA5MZHXgOzt4OTlFawgbhpsBj67QkQbsJctyGvEjirdf
1LMN6Kg2uEhlMqmoZLbMayFFF3GWsf62t/s2MCN0ylJJmuWBQMyb9N/U4uSB
dGYkMlE6LoHKKVu/2MS+2lQwqyIrp2nt+/y5XMFcwiZ9vEW4D+NjBSevV0cw
iJWCA25kVC3V4Y7WSSCnx9zsOWixIlbBIiXPBZpppy1IWyQrIpeVtoZFPIQ2
7sWbV6JBur/sYWHmbw8nh1h67/zO3l/pwP9anb59dww7YlaX4Udd8Ze9y+q0
7af48HQs//1X73r3EIJylrpgEeqNsAOcWabowuXqmx4XH/NvFCkkXKn4PnPH
C4ETTodl6A+TQJoxV/HUBQwskVhJeEB7Em1Dq6RKrUFcKS5IFKhGdLEkuoDZ
P1GvsWJkFEjISc1bXUyAGhQYu1l8OEPm1GvCwfZHLE+Od1Yh5P7qVebNlwr+
z/7MKZXjoWY550SkGPsVaaH5MIleB8LfigalrMWTEXodkQp8//YIujMunhwI
Wt+cQ3fnqg7M6hlNviaT7O7GPtHUgpqkSI6go099FdyCsytDpdED7uPL4vfF
w2HfvLe67uKr4NrpWBUvGVIotK45KzE6P0o57FEzUdYWLNIL2DsviHDpPOVE
vS5lTOrxaeqHhERp+4OONC9bWgR8wavij8XdQ1ip/X0sdn94UPw/oC8xPSXO
06vM+nHWL533dJZ2d0yJ+zz7ITx9944weXO6nrfWmbXQW4pCXGylhJxUPsDq
6aZ7VaRDTsnU412ubF1slDmoOYq73uHqBBM2aCm+YDT57sk299fa2DKOd3FZ
JEeQOw1KgMpOcD4jpXeFYILiN/auVgaFaEJiW4FWIDBhLKg1IEcgb4H0NxlH
GDQVmjrl3YLESRQWxiA2cy4WXAA7rD6qYk+Cc51UyiPvXAdV7ArPu3NHg3DB
gAEq0nmJppptfW7HRosyuQJ4RUtYqe6viCqZnAJ7+RukKVbyxaq5cIUpSbJX
LnUSM2gxgzFBnjM18g0vpyrfjqCxVG+LzQv26+horTaNrQ3z+gfdIXx5qoSH
uIGmau3I+U+N5Tjnn5BMUq2PL0GLIl8grvOBFxbug3UMCOJgMBE+VT8zEYOJ
yg82w9hgh8ww1q8pY0D4ylWVYEBvtHpz7XfpJWLPqG84nA+ijpEZlBRwUn7s
PcxmmVXvK2Q9VAvIviizpv88l0O8ts6u7cCH8LUL6by5GS2keoPox93A1+Yn
phuW6PLou3TPak8UqZ6ftqTpnIfmBpTwf/i38bj4SzufVrO/Fs8TC4lC0kyl
QkJiL7Ml9nyRS0cH599xEbZI0IJS77JSkvugGfy7c8dMu/vI/dNbz6UmeH7r
kYfivFx3X/NKLdExeLHL2f479nwxHv/I941meVA+LP4k3QuYtGSX/qabbFiI
zPhRCEznjNdwlIv4USxCTBZU3YwvjjNCOvHm0XzNGKuQ3cwDnZhuKYTgMw1g
hWezHFR+M8Urh83e6gytDzF6zkZMsxK7AMAEWuF2X9OiniNXfnD33Zscxjg8
T4ORu4GVKW0QmvswOPsx/c614tzGxPhspDlUu5Tp5+bXZS6apznLkbtjMIIQ
NyIjIc3OitGKw0wwXRICDd0IwyzhSN5jVCtTB/P14OQMSjzXnp+eq6G7vnAE
6VE67wo4xxDuFiy4aS9uDyLkmqSJrgiOPPXQV4984qrH5SILYPxg5gP1IgkB
+eIqXitP2T7YDlpvdesMkLl9PtArs4lahEkz9VPn4TM3R4kT+Gw3TCac55us
xEjqPHJgMb+7TdY40Up30TSnWBWeKIZpWL9JVDJAVGtREQwRD7N0I+xgQmQh
7zQerE16RnRbKoDdYGKwwIbyCZWMoSRjGluTKB/hW1FTm1bBK08YEv/DSfG2
CjMZ9YB41hmVprnO6UmhODCoRuPz+m/wNR2VQYqAIpWuwAcktU9D5A9ECGEx
Ykahq7dfKskZi5bGmOJsHK/+piJ+UsQ0IzbtC3lDtLymNUOwKbK/gr3HiPPr
8FYi9m1b3nYSgKFUN4mbj88wChdf/jy9rW8aRrhKl9AE6EjXG15af6NMsOt1
CX9Fj1ycUs1n5DpU9BCdMKw+xDwXpnH2UscKAiKSu+FUsv8ATxN8LyAVegY2
BIUGgy82TmlSbyWjo2Miv/jJniqS04mWihQENmcSaBRcs5prteYsA3RuL+ob
08DdhMQymQKhEeecLrK+o1vLMY1kHCRLA1mDLZjVZl1ICBU+coSvIhTMJpcR
iZ2P8A67i1PKPNukR/8ERwcOVV8ipTeI7mX99zLULv3+4eEDAYPSAsSRQBQd
Ltk4OtCwcxR1F1U3HvZLGCKoU4LQxA2UFmCS9ldXzd4qYQ10TAJyyrx7ChLA
ZIq0mO+gzHS8mzzd7V7ErblHvUInHWISNT1VmPPFQ+dhgaFiYeCSj2DHKaID
ztgZ5j3ip5l04k4OxGIbMualPb0wnvvUTabNzNpPWIONxDsFg8yc+gvQ5Ug3
wwmLXxqS3qXkieS8X/Ei0jww+kVn6RRUd8qupcukRqj/etFssZGkaPzUvIhU
E+4Hxha4My747hnT4qvC69W+s0+aL4/rINm3WDmOsgRCqNC0X8/DLqGZZRpH
Vg/dk1cnVHHMVjBZsYGOKZ1aCzLGgSMus55y3eyVS/pOSUyXpssTZbLNrBXV
rahKrk2l3KxzcneC3lXNTDPogmZ+FAI4wGbOtjgl+MyWw0k4hVO6FC+gEUz8
eb5SmqqOI0y2mjb5oL1MAxkHgn62hRPU2zNHbUbHg2sLWvCXbZCgNdOm+Wgq
M/q4GRVJgrt9YUc6ckHHyw5StJ+uyv7cEkr0kurld3k0HSROVqZQvcgGy6Kd
ShYjN7y80JpQkRNNo150Hrc3o3xW0MWV951wIoSrxt3gquGzSHKLtDEjpeS6
9tnpWqqRZKiPcN1UUlnQCrZAh0veYISQtErcbBwDiCZ6L+VkLs0KO/bhiwUT
PxW3MilAPZXbJfnKadAYDMuNT7QvvRqjRCkBpxMVmsxU1OToPUWRfEQMM8ph
/bqefR2xoG78WxRPgxl45xSoXWGGo9QgstfLkcaphUoimmy3+3ePA2AUrZG0
1Gqh+SQuqPC0bb362AXMqa9bhKfvrC3X56ZOpEj489wOCxqhj57519HihNwq
uDoJUQEbHTWuRI11Vo1lE+BoqIzjD6RQPBZFERKkSNcWcOguS4Azn6FBX1lt
l5fOJ0G4XTHlmlM7ryqSooeDloVwjMTiwuqV4UDKalnUCx7tSko/B3fZeJB7
By+v59uwz6cI6Ztz855sHWFFxbVGDedbr+gnJjtulz7oOLQPS9g265bpGMSW
GxepWUYewy7sF9PNocoqrkfVOuFF7MQ4NmPzYnRWwbbD5Vs1mcY5DM2TpGsc
QUM8W+IVHXKe5zC3OiVWwRuzd9I7AQIo8vPnf0O2p/t37lt6Hqk/NG1aOB84
Hi27yzHwoPjQcQVjLKheaAV9YoiF8XF+zx5OJA66+/DBd+IF+vz512dH7379
0/j5mz/fg73pZH4pCCuVgYmhm9SNU1MQi6kZnr+5uBd6MokJlyoEjE0Fn47Y
VTTY6qg+RX6jOUHxaBoel6LjWSejj5RJY6zg6fGF7gIsHn6T2O72evGyw65X
EIvmHCKPjj7Mjjf2hqL5l6iM3tQTwUYEc1ZpKTsX7DFfdjmx1ofUAZo+SYoW
o8EZ6NoJ9bYm6/tKWENz5B2pUlFnoEliW5VaJA600TMu7It6aZdntUpLBtSd
QvL8ZODFiUIloN+IURSnhJcB3RaR3qtKBqhjQgDEFwJa4xjHamu+HZCvarke
LOYoiA5RObRwMwdXbHGWRDcxmalX1awtzA4tlEmGdooIUaw9yJuoRhAgnnTE
Za7soeQ7Qc+kMsI9vPfwIV0MFDIqCFZKmVYiasMm5bcT9ENMCZixph93Fd7R
BBIyVJ8vnjwrFiXY77SQLstMd2dylyNEKIXuP3h4m0JleM0TNyfvH2nSH47T
6qwmG60KUrg4Ojl+/hx7Qyol/BY3K7+emW97gvsV390tqIp0Z9TEaMPH60I9
8GshyHrOqoLxOXqBAi9ECSPME75dugQnFj7b57KXt27fKgS+Wtx6eOsAh1F3
bu/2pz38z73b/7knF6qUvmmWsH0F0bTlm2YUTTO9xZ2DXTwDO3KJdUqveiN8
UJoP5rdYBb91dMv5D3+6daClasnfHS1/Wo01FstOxfKihs/KRSeK03Oufoo7
jlT8Busa05weB4lgyvgd/UbmtkX9LsAYWWmwpywsNIDkIxfUc1bC9FoZ1ZQT
jSF+ic+A9s5pJbrdVC8A6HGceiNyEXU0oXsLlU659l2TCjuN5FLKisYhrAiB
E6RhcMeXlw/mMI87G0eLeokXAk5CtoIKqvcdmC/ee5ewI7HwiN2lmrUT2y7e
6VYvCfHbs7fpb57NLLj67TjIHerosGFpyMU2tmnMRH5dL4zaQ9eDumRYuWy0
D3RkiHDVYXJPq+gojwpMjS40IiRr0+G5STxtZxQbW81Y4KINupW9gzA3dnod
cXFWMsFm0abV7FDDCer16EjeNxvYbk6rcp02TY+1dNeJahtKJJBeV5z8+fgx
xUbqafUSjTKG3jH04Lfffju0Wh31hbcP+Z3OS80tCX2HLo2JGQgmAy7PvjIz
y0cKZy/ytg2HkSB5HNusp5iFUYV18BXMZE2bkLd42TbIeW80Iy0oqW4DqQoi
S7DFu1/anVAtWu5QFwuN+JwKvpumvOyMH8upHyu9qvEdNrGynldEpks60BTr
XsKJwIp/LM0CIb63chnpolYZKuUucRd1foXfnPwsOFXOC1qI46ecI6QcPaYU
WFadtykwhrZEzDyPkw8JcSFQ1gZWtOLLcsvSZ4WeS04eEkg0bql37150BzJW
r8QhW2XMJ+iInTKQWYZ0SGGnhF+Zb0MSia9+brQvreJREkXTeFqumVyRxiY8
B8isgS0F0qiQAIf7UYJqGxR4BhNMpjFVLeLMP/Gl+/1MRKCY8aTqUUoPqpmf
vBmKP0nxKx8kUJASa4adlUTkKzIUFF6DoY1eRgn7JnuuvAD1tLRHRHd9cJTF
qYQRJeuNS4jmgDapQX8iVqVNtjflBjRndku2rH3cEg7YX4Twx64amVxVXAtx
Yne9Ti00jJ8quBs7sUd8e7Hjiwm6GCYCjZ1jBwirgn5wnFexgzC3KFEZUp3A
VsUo1NiJh0u0HIN5icgHWE2PahyKgPtYIUABNtt647loCHXw89OX8WsSOuVd
rwpJgy9+f6yAOnaeHTufosBLRLCG6tO6tIWfA0UHISO4mgNt4Rf6a0nOETfL
bgSLddSTGa+p5pfDfGkGkkOT5RRvMblmTd0Jduv5UF4O9PBh6K3NY8PUGxqq
KWhexQ0OkEf90BFyA+idelimoI4z5pmiFJLVxqklPqvZKyRKe7b7CKPvfY6w
AKnnXUuFZqLr18xfrs5SZgtYPs+pXDcNkrOdM2wXLZdMMGF30NxAuVyM9iJZ
/5UR8kJZmZ24B8mLEUJMbMolkOQYbdCJ5uHSQIzP2sqMD6bzdUgDF1EcgfAk
H6mrqW6QSRpf7eCt/0BquxDvdxx/M4UW0nqgGGkjiNcUJEpECuBQ8qUEsiK6
uhAJNems7DWPocmIiauWovTtccu8CZlfVpTVSr+DCdtfL0AELw6UxEDRzCaQ
ryg6mwP+BiPoFUUB4QanBDrazN7R4Urc4uwzfS3ws0fumIkVF9uxcf5EgUFv
x8cMthODh/aNFMNGumta8UBjBigZ9eDzZ95Eph7DuC5XZVKUQXKW3lZ0JCMW
T6EqwPev0GDizJ0zVNTJjhKPmlFjo1q5bo8Vsj09SkyPLxJ+gCkYMSCrW9dC
nW6VCnEHgFBYd0pFphMkntCYi71zU51VYUyIuAMGb8fib9Jzvu2dv9ekIDeJ
3FanSbwQIVoCJsaYk6RPweKYot4PCvw/sbJaGfYm76NVpDA7xfUbjDGlLq/B
bsBZPYnGXOTG7DgGLR0gQzRQ6i0LLpsFP6wwVjac18lXbW9x0doAokTcHRky
4hpHs+tshRoAzoUftJWu6dCEO5vd4mCByBn1sa3hixFyvEHPUkcAkZbLZbTs
mXUeRcw7U04BKg5YX4YkW40whAu0nKiYwkgmDpoh5+LjLTJbGTtBJzHpxwzT
4FfTXjRF+Ioc3RS0MiaqACvFvpRW0Ucf40q4zBtfAqjpBN/7eAGdXfiRKjBa
uaulMq5oDbPJ1wwBsTh8NUqP4c1YYFsY5IydTS7ljK9CFQaOJovWp1luOSol
klrkrNWa3WTRoH+tsC3Cwgk1BTpNxK0kRj1CaUMAwBU70mm88NXSG2CLpoHP
XP5g36ybRXMG2h96nVX84E5aLxCPdAkXZ7PAhdXMus4AWZIIXdNq+kJMiTNx
T6q1KKxNHANuFpUyOAzo4aRwpGKNuFJV/s2gvJNHTu3J0NAEqdU/UHotVwcf
yfx7wOlNS3Oz2YWuip4IcrPMn/NguXJtrJQd6EY9rUMBxat7OsgyJF9JB+ep
J+rmEJRJJozvVdhlVU05NokGxjlj1/TPRp81ELwbP1yc1EuYmJbQ0mkf40ly
V/euuKZ3vM7ZuuFXoJtx3oiexXdKoY9wEDoGi8tRYJ+BHGmFCOZp9NhtG9AL
iQqSrdcFm8b0ZNeKua+ak39gxUaeZYy9cWnB3nMyZUkrc6SVUc9mcGDlqvUG
ovAysemV72MSyUsewsKmnAG7sjigr13h6ysvkRjm6K3htDHlGj2Jpsn/W6Gn
m5C9wwNqiiCTs5AHNf6JD6PI7M/fZCWOc7+siUoOJ1ZMppsZqXTX0b2UlgPY
KbsNs6nEaCi5P2SNrzH+60xFAEUSsz8Xb3k/551FPVnwc3poLBEE+QYwmMJw
WMS6xTuOmH9Iz6ZMF+QAMuO51UUIPZPtIbXlUHXhEEdM7epXd8E1arw9Arfg
jAPY1r2v9XVJ5QIti4zumAPH4BzxAjXZjhXo2DPJqjtGov12cPNNjJeRAi/4
BsMPigQ5mK+D9mHsPaWMnJnqzQSVWIUoZT89H0k1SNqofnQd8Vkc8/DJnzho
2mve9meaz4m0iH5dOf+J7VyT1GJCxt6lCatwgsGQjVj55P5Sx/+imVIUtxM1
iGUy0QeRfSB6t7ti8kDmTokkbmeQIwLrwosdge90V5BbjVfMcKt64LCvopzV
XtC95QbzqLTTA3LXSfHLaoEGpAChQ9Qhw2tEeXves4NHiDO8vMaL2I+UUJtk
pcas2GPHYxMrz/vhMNbZCwVbIx9deRRGFhGCSSm8Fa6WtYa+KHhAop4QIqzW
/TuIFdqiWnFFKVO/ymXWZhK75fmOVufjFaWwjLs0qgCYq5DFyZSJeFF0oycr
/AQ2em5eo/pRXjz7PMl4NIGE2EAk2/oC20Tzpvv41g34ks3LRtmC59NhqZu3
+8mbqSZOd2X5m+sq31zBmGvoeF+D7fAP0vEaYt7stDEv7856kz5/c0cl4R1J
ZlVa/VOzmTEq/iFck7gUYX4lqoAxRtx0XIUvTCFqpEggTbGMUFvd0NJGgub5
3AWZbHPYrtqP+XM+cQkRhMeM2kTqTNIlem6u4nm/PsPaV2ruwFDtHAsmMiNv
IpnQTbqaWrS0AB2I7JvVcS5KEx2ImmNmKW6XuT12lhTYSXFlpYWPblyfvuiD
ADep8SwOMnFN0RtFQ+EkHLhLOe6QrTzEeAiJb9sooCITWaqwi8TzuHVFTE9a
M5ZbUAcTK8sVAYKFHBB0iZ3EkPVKKZhrj6qJApEKjsGoY1RxkXLXQbyty5oy
BrQ0kU8HMPAHmj91YKnvh7xVE9GwU0XlapLVFJYcqj3S8fUMO6HYySU0NEbX
DubP3bgenPP14PSKqg2Kn+Maw6J9cPUou/NcfYrUQzfIY00G8g9ZU755VvPj
XJjkBXSQYRouy3bW7bB+DR7XY9Zj54DSF1uvCEneHYxLA37mm9FmuOwQfO+R
EtffyZERsjOZ3dkLWitP7/Q3MbMQy3k7ZwFw5namu9v6D7sGEFja0Gry6e6K
QjFRS0qVj6cw4tSIeW2IYO4KmUxXEa6yVRNNyZ+dU29B2NFvQmUT66w1SUyb
fLnqbAWKlI/md0UUbN9BsaJdhFvDF31CQ+gGh12hzUIwDYf2gUWUdFTGyhW7
avaC6MJjPZGems7UnbEHAuopCMaQQGKCKTfr9BXJczqn2FASR2bAhhSnIBsZ
rKimTRR7hQBJU5v1uG/GuJnYX9+FgBFOt+T8ebmf2XAwpaaUGevoMGESNPFQ
rHAdKi2sb1R/hADqhksBBfdGomVRVJA8Y56UobQgMEPBiQubVD62FQp81VVC
6viQ5pVbnaMvi6262QOukAV7zYbNZekhsbNcAN1tVj68JXE/mChcMn//mNFF
0FZOelTFAA1QLCNgHim58N2BKcFnww5LmA2cQ0JziP9GfKVxarvoPj0XaJ4K
EgQt+IlGo/nUDqEaeX8bSVznjrAOgz/yjReZVwqAvEsN5spxqNBnz2CRuu7K
KIMJN6F4z9a6sMULM2lz0XnyCDJ1x15R9sVaghG0LxmZpaxLS15b70nmEpRS
bqZS0I2JBftMyluGhg32Ggr89/7nORrApEz39T6Cq7x0sF190ZuRV9cGjRJA
DjkqMYHhijEN2d2vCKsYsty6j1US8qDucBd4QhF2ckmYVWW3zzu1xD/BO/D/
CZN9aF3mTXOCkbkBa1T22M1TaZ/Tp91Qn84tKsG4sK3dXJV17yIbe0f3jLlt
1n1XCbLrre4Mh1ZGWCAaHRUK72efDaEjNzMDTA7FToPAJRFldAxEumy3OeWM
oJ6MomsUWneVQnuV5LMZN0QQ4NOhhjBi4SVwQSW8gazbfZ+46+gWN92mXLDu
b24guq2Nsp0zG5DocKek4Ep7Ea4SNIGJewmqW5PJYfkHFc9/kdr5r1Y6UeXM
uaryt3ec+bpr/5d9vP9zm4cxIX7v4LgxmLDH/B7RrGStXIG1ZgCwhZIOlitz
Y+dhFexJ0GxHp+RzBafFCIT8PE5kwEPRhwxJ6DAqT1rD1/bVBZ07nJFtlDtU
+yK/nYn/7RJNH1L05kumggUF7LwtNfgRClajy3POLB/1ErlIqlkAayLy5t8t
0PLdcJar5SkOE0nIM5zNVJa9ZS6nlmLjCmaTYhyBVMrwxB7lflRkfsS6BHSA
CVRgfbKdkEBSKkCVH7Z4LF/4YHTiSLFh6DVXArxRHFrcWB57gFHdNByd37ue
WaXbQQi+UgnCCTntMuXVi0oYc9Um5WtNSu1ER9uhgJO761+w0mHRnKUPk+zd
7tp+kUAfST1zaoyZwp0vK5DvS+tLQGLAIDjRIwrYQGjoiLOWSPWG16+UHvCQ
S1UMPImo6cEowymdqX91b0JoWqygEDrxHo07XE2mi+A7gfNBJkVUDyJZGLyC
Lttah5VwqbObMTdLGecPL6HXczOM4KDiPvv5yU/jp5gsMhu/wNTnfdFp5QsC
iGEJj3Qu5c0HqgOjOasAC/uOPX0gMzn61QPWgjmfZdAjJuY3uNvBInyPSzAq
9m7veUMeL4uQNPMMOS6Fmprn0uwotnHwEc2E4R20WSlvGnMZaJpLvN2EP/P5
qngCp3sU7yYTgR0My6Vjenh47/swpvuTh2A+h2AAmcj5w+xzHgLkMmZNnfMV
5qvFBT+7Ez+7cQA1tHcaye3x+5EGNoNL+6wtZ561EY+ZCjXxAGWOCHwbsu6u
cmRk6OgN005WJxg2k2QLpSGQDyOk3+gUvqebtUuFLogzKSBSRhs6EFYSxWRG
I3m86T1rD+Jb6FILmd/0a6kHOPy1eEv3bXxNYgR1AqgweCxi4XaGg9a/pVwZ
z0N2++TE93BWMwIc2cj7InaB3OwyzbmJ8SjyVXCtiC+8iM/rm1qskWXvbCC7
DkfXXwSZVKtExGOZhYyYL24g5l0i5s1E3MyHFCyEnfJ+RxWIf0bmHw6EPryk
+ArBb6csEf5SNMEYvlZ9iEhbs3KAbsZs1Qtx+N4EbYzVbJScEmksKM1LIEdY
zEa/k2xoaBDOmeJrSns8lSVu1kw31FocGxYbgL1sVHWHF3qUtVxGmagVYtzE
FDH51kmwKRPsCu8GxUpMQT/kZQ2m0EfokJQznLHJs1zDS7jsMQihTgCDmr+A
sLZN14WsGHx8zM/RrD6utg1zOYb+YgwDXfQ9sQIR2Z/vBkMclQoaaRhhnhZ4
fVcdZdNtOmWWa+ZJGcFS4Z0NetG7NBzgwk9Zps4Iys8BBrxsVyGLzzaMHVo1
XP2tLRD+K56nWvK2uH5QtUAPGd2xmzWb+J8/r5pxt6p5f33DOEk/m89pltCF
H80aGCkrZNpgghu8YIMzakTV2VVeRXXoONl+kLDIdGKkD2DCBomO6hNBCHSH
dRqHZkC/QXdo3XR53nnCOuvQ5kKNqsKS4tGkiUI+LrLBKqmYtT0DHY0r0QtE
FTuPHgpl+NXAiwx2mdKUp/llFVvzEvBiU3jraQcxFzVAPOg9eoXMfFFHEsB1
y0xJsEKwaIHcZMW+FkZOf7IHp5tWKzjbDXlQA3+V3+V4jggy7M42JcjDvqp0
1uh53K/NtFlQLIvFis/EbJvTDas1uHERbmPYIae18Qp2W/hIkztDLWo/raba
GcIcxenW9Y7KVIKc5kpuY7hI1tCNjWRbC1vOu8smMNv6AbMIoLitcjuLovcy
iZLR62P5Oq1akqyDgBrcBzHFi2ebt7G4uH4bzRYRklj2TKnjhwtCQTiu3Bt4
xMiyRZaMtA8gikuGxPKhFAJVmnwhwm7x7t0Iwpviq2MPcAwcx57QjCQadYKg
BaoLLCgxWPBGBXvoGnnEbDE5H0vcC6f87oqle5yFFPEGB5KOtkJ0UVcke2cU
SGuxCRQ10i2u52PpHTP8dhMGFHg+jOSAOZhUwWobl6qA4wkfpRXcLAVj6vWc
JFgAH4k0kuSGalNJkPCRzwgQBAboziaGzLq1NV+UWE2LubyxcxbS3jTZIp43
5zkx09kb1nwv58zIhGsnvtuZ0LAx+/IoE/EYpM8J+loKPHsWVVpQSUqA8USZ
DBEbdeQAFS7IXd32xucc4xa0HYm+Bdsxt6kzuiR7oPsIr+CLnVMFDvaiomKx
UH6eONWo7ga+t0iNh2uR6QCOflM8t+f7XlnKnhBHRhnAk9ORJ08qv+nx4Jwq
X7RZ7jTvcE6PGw6mS5jyRVC5+FpkaktKCwBNZA3mdy93MZMsSSYSzFGceuq0
c7ixQ2giwppdd3qdV1xIsBPsHnmCWuJUgVsR5xOu87qZ0cRbqGyQlFxDKqBS
dBidpTYOX6fZzHpbzGaL6rT5BGebvN7q9IbrN6mBxvTL6thGmiRyH0PLmCOO
6bW4wE5Ln0Z8C5hsgDBQohQTcyt6QOtHwyR+EkoySpHkMFCDwEouiWnwZDwt
/+4c0tnjEThruV5gnTA9vX1zTJNHpcs7OSWrZuVJpmCi9mjx9wT8Yj7HjQKy
cB8jVYqUEsZNh7Wdu0fffnt5eTmBeRtXoLs07aRpz77t+u2iQprm6tservVv
DwJbGz4liOkSg8YYNafF4jTfCvXeWTWwZSZc4S64I6Z+NUbuko2CsqOUFK6A
jkPn1jUHT/JYStgTom0GWY5appLWYGCGXmkjF4WQ4sU0Gn8R+fzX4Hl6OLnr
Ew25SndYVeKkudG6qggojBrN2ruwEsOvxlqKhg6MvIRSukRt6wZU1yHpA6HK
hdC/cBe3PtYpFlqiXr1eC6n3fklX6XD/wgwffN1Mjf4FUzX6f+9cPS726cz/
ayaLpfb/v3YVRdByU5Dx6T5Ej+7uDfPPzgFnbP+TM0Ac6F+zU97550jJFt1w
s+LEt5AOSpAL5ebysewk4M0OUeYIgPvG/Lq2imsnZqATCmrSH0UHM5d3HAFs
AqIvzWMWfIkexzB0SYDthbZ0OuBMzaDbTAqISgfRXUipT9UJ5dsLdEYHykXk
Kqx9IsrZDSByLuZYkCvdzkGMy6Bb2scVacS3ukgJR+V3A31pa8whvMjqQ8Z4
V+LqoNshr8TUBFczqjcXnA5Jv0aLFjDtBGS2rIe69IkJ6bqeKakGfIUVLU0M
Ii6a9U3kwRSK3s/fiAsqpKju8IFZlxd5krSeIfkzYF0/BsfzwDQ1FR3pI3qe
KmNT+4izQUWfivsV7HGgVE83L4km0+jwbKT7wkC6/MSFw+mvatSEL+EHOJXs
Tm97rR6h3EQY2ms3xIiKs9aABshu1fj3SraVJpzS8YlMHJRohmnLO8ouZPjS
Q9Feou2ccLx7XQ4JJY1PSU2+sGAuXbDgjSPu+MRjqZJ5DvKmpPdR0rpq4o5M
hZLTuRoPvSXbBV6cVGdC71e5gvVEykNih0bfUrBL0V7SBtX/Fe9PYePDCqB1
WaCOvC7WDWzxreaFaEpqOvvIJNuslP645IRrhXhYxzHNjwvzg+7R8ZhrrtCe
ojDLabkoV+RChe9i166P+q7pPlrwVYRrzMZH9wOtMtxIBOtGNRUtVPmS0GQb
tq6JPVaNVVWUlWn1uSbs8eLBY6ksGXlDdTip7NAlccd7huFwMnmxmciu+mKO
JGaiYBCZOZ09FDeuaxYbSVAzGn3PdRjhet5QQryfYwqTHBMnE8VJ31ptgR3Z
/M0XP8zytFNuczZQfa02zQGnuxCLDPH7iY/ZJ4WPXFlos+IxMk0w9M7XJYsx
EIz4NQnVRIH689OXj4onz+B/9v/zzv37hw9HHPo6eXZ05/53Bymt/ve+5PHD
wwe3saoFNPHkp0f2R8Pf3Bn8Bpk3H8H/Pxkf3nkw/tPxy+GP7iY/IiakKdjh
WI0kikc5tt07pT7WAGynj0/j8JU4UPmO8G3i9nmD+dVwBv/UlAtcwTP83y/E
uewb6Yj6AQFQzIUvXpruEchaZlwl7x9ZqpPijX6mj0n5uxLL11KRiQGbitJf
cok2yx9FxNboz8f30gucckB5fgXYRqcmmIGy/L83FdN6U6m2o2Kp/gVBLNYL
UsaYsTmSpNzF4HBihKgKQupGGLWMkExi/EVbdv3IcT/j8bP7l7EUOgsIc7Oz
IFQMsLe5TpKwRo6cDpQOvlBOxnEcc+JH6XzwRaczwsXriCCoaam4QpH0twgp
9j6hGtrHm42zb/tzquWJNBYLYRW8e//+HcniUkBIzBfzZrBRkvmhoeBys0Yv
96nfH145cDuy+nZETjtKWMX/Nb+7Nk4qBQbbzWrlNQhL8xQ47ykiGb4o6jj/
iHz2GFOlExTqUiAn22a51sy8Q8lyPIfNXy18V4kbZdhX+jgJ7MItY2vMzPhw
eAdlijNDo4RV5s6UB6ZTyWpSNm+xUyUP9crg7SRtbVDPMOqO06GlV6SvauDd
SzoZYTuyRKBduTDFmMKSljs3gvNBBzgtg99dtw1AyeCCO/xmdHZyOhw5rkPJ
aM08X32MlLDNqv5vjaKleb9ypB3FGz1WFHV9mJBQj2mkYBmfkpvnmZVcWeaG
XEi9SYZwUcRJS4FgZVgaarnYdjVJcz8r5bRtui5zPrTP0DNU3VAUhvxy65n3
TVEY5KaghCt2FQZvxSJmjyOWCkQ2IzPMG+wo96ea+ZUI4ReEl1rI9RJTE+nm
83CO1tZC4xLv/t5cM42oVFj6hQtrRvVAL8H48YRb/leoUyLkgXm2UxuCdr7W
pBbikylGXmPOSX/SWOExlPQrJjSnNhkPAErkarvEl2OMHZ39KyYPONtAA0xJ
z9VX4pAPAkY9G5bdnNI0qXW27Umx/y79DFtJwZtUWxMuhAMc6xOPJ4T5rDkk
C5f1anD0A/Aw7igzV0ZU/VI5QBMkBNQoqyJfsrOnq+yKUBWXuZCfkWeqEgAH
FjA4kvNCV9mveCK5KibbJumS5WE8ceTDGY4yhuz93UckkpmN7TDQP/I55UQ9
5akhcsnq2A5eHRLi9cE8uWjizUKlGLFTH4s/FodaOyO5DzSYxQaCvyc5jQIr
WnSE/aYgzadaia7sYF38Vr78fekPm92RvZCEuc/tLGAyZx7PJemRYSMT00J4
zdHK2T1XmENCF3f0S9pTcVTLZaabS/RJcD7l1JrY+gv0g4mo9KQn8ojFAxSl
kKwkEhg2nXAXnhLZjhYNFVlu+53ZSPnULPyfmqnmYNJUVnOluqjFkXDVrwxK
1Tug0d3urO1FYXcxYkPtnkb54IScxgobO4MuIZuMsFphMjyLsCXonIf718kw
qMB0V/xcbU+QndKzf/WMNi57dU5jdFru8UBcJ7WYfHcDyq0XucI3SmcNLREO
fM2wZkhrXdZLFiM1ssJhyj7OHDvS+IJCD1lhKtNzPSumgCNEAwxXPQwechrS
9A0xYQIdsOn6QUoyLPGqu0uxImHetR/PYYFwgFymxnv494j5bs/7NtFHTF3z
yKf9yHE8YrQCHwM0uVgb8i5k4QbytV72XBzmnfsKKvfuMS13rhJMQjqBpvEv
q1iLJgvZ24YIEvj8jbcVx7OVWsp+24NWUVM0n7SUiLTZ62DnXH+T479U8Qn6
8ezduzcnjss9dV4t4GHVwk55QTRyzLus3SSXTis3FtXitfIiqhuVpsphk17s
8fGlKu8r9EQpIoKQ9GRTr5u6gybx8ym5DUfBjU0umiXC4wUZhjQ2qpQTCkJN
uW7EWBfmuuBHJFMRC2FkGM8xdOeS3L7gm56VfSlW6pKq72HMnMtsZZryOWs6
Mlu9bKWnzfuqvHaPbycDvwEVEWZg5FaN9oGyAriiCo6MLHlb1jy6WdoK8Zv8
xfM3zqv5VOjodNEwl6OCgqxVTw6PU9i+/YaYKkQqhUbCBa/VXbnfl0RB2Xwk
WCplTG46TYvmRaY9512d1ko1WeYoPkK5+496k2sZbIxJkARa9eg2bVrirjhG
TAaKJHjRydPjYr+OiixpVU32fp+jC5Ay0Q94T4HqCIILdAShDiUFntxC3gvF
nqNwFeCAfFXxQu/T0klTnoUUn+MWKPch+CLkwmbOTu9+YM+y3eiExmR1JSm4
hOmHr57b3QE3jPNo4ZBqXNJkKlyc4qBUeJ7xh0kbYOATrAt2FbKO6WKZJ2BO
cFTo6Kml7DZORN1PDFtv8U6Lorkj42vaobCiYoG6ENwZuOl4y43QOTeWFcxW
vOpYfKMCiLe1MpTqYVflJID9I4f169V4XfbnjtCEiJn3oSoqI+JBJZ12iOGt
apkjpT2+0b9OACwOu4OEtkS476PSJutczAjN90fwtXjwOfnTbzo47iVWWQOL
n7Z3yL+TVQ5xLteX7Vml3vnOLr8KUuyK92mKs4h+ROjT4IWHlW8ZAU8XOgIQ
DTgLC9dJeXk52/lVMvnhTi4rTFUDu55uoOLtW5HGmKJKxeNGHoBPYaFjmVaU
Zlg/pADlvT7DIKtimTHuhTM9X2wEUQgXDY4WszKjnqA3h6DypHMQHEpuCbfv
g7FSdcDrjBi/lj6oiJVsN9y6BIJG8d4sUJk1RTgluY09Lhizp4co+IHZabZn
oJWwVGulsDlLkRWDgUnQYvm6cH7U1SohOkKslWyeU1uyR+ctb3guHshUhdUn
GJkpRovVw4T7Ay4rBNNOirfUH4rWN7YRasFytgUjzpHtiPkPLVVjqgJgXjR1
VvNzphEpspvOkZFD+wADZww3I28ipoQF8mRBqmcNNK4n3cTGpQRU4VBJlah6
dYHLxX2xpIno/nGiHNR40uaYEuuXhxziF1qVtnjOVMTFcQQ8f24Ip7E374jk
+UkgP/n8Tcph7Bw1JZ5105YlrxZbRgRyvTKoeL4XvLxb7XCnKsel3ypcTswq
cAFCl/Vrys1xI9ohMcxDYFn7h2gSly08Z63Ueocl6ynMai1rom9wBKTxaakJ
t7ZwWtugjzEFDQmhUJyiuYAkwIHPZWhDF0cB5DxiCM9gDV26huh4rNpTPKRP
Gq8VpDYVqoNyIW3pZzRrQQLESoB6QqETVLSZ48S2AJQhMlFaEeHYljwAUkg9
4piqF6Mq19NuC9MY5l8I6jn9hW68ecWBanYRJLCKEDQlZJyqVSTxSK7URPKu
7ti+cSyvyGXaoHVK61kuEeRB2i7XqyLnj8yhB6NfRQUuK7r/5AAvZLnehizg
A1CGx57zLYC3BVd3B0lAECabwQiHnDiS5Eak4/GFC/0OUsgszkiJT3dT5cJ7
EYXN3gynoUEtBthZ/krFT1GFOnSqiKtoZ+NaMoxUG5EO6O5FrQ7fkuE4EEt9
G+jne8qe3SgsTDM3GB5vu5GrE2RRSJK1nGGToli/jXvRlgpZax6LYqZWKp5K
sje+YKzwAxclnw2LMYbyWYxz2S01HQ68iAYeecFIeJI1O3uPDewl5ziUNWSH
wvcP79z78oV0H4m5UxOUkcyh4ZBuppWdvDod8GgTd/2myK1GOporliRaYNoK
uzebRo+cViQKCUt4tgJ43xaiqFcxqh89IomT0YnHj/oQHj568eYVVZvoGCKk
n5v4vW3cWVkRXuT7ymcWozqSVqK4mrIzRyXMMiXK60N+z5npyW7wP0vBODqQ
JUWoGWgkgK/c8ox8dYNEyHj2/UusbKauMsxZHUmJW5U8sx0dkqSoLWMxuYxV
xIy/g/d5q+2Tfll13ZBdzuW4y72XZOW5Ihhrx6nrwq7BR7Gzo3V8FjW/1EuE
srV9YK5QogQyz/CPfMYGmjiYy6fg03jAJN5Nspc5VtFwySvBik/EcRu8HqYH
2cmnoNtFU88cAzE52Yn4EYIhh0ua3gVJuh2CYtnXxHTspR5+RBVXiznNEfk5
dRfv8mSK+kvzF196NKfJpRdtZZsCHUdzczvI3CkD0ToS7yGYfYT3OgdjPa/2
Buar2sMPJukVIqFqBCApMKITF9pVWrIMwGUHMEFQbKRESPSkp0gKqcfR+4iJ
KsJSCTKkKrtmFee4qIPf+MptRjpFE3ih3lZcL1qxVy+qEixex2XeJUE/cWmR
hYUwGcqZwV1lXteLB8Nra5OQtkw+422gQMQVAKWaleDeFLY6NoBzJVxwYUHQ
yxGX//rP+7cf2l9hYSspaxNQ0P5UOQU59W05J4ghl/Lx93fonu/cpHjKN0kX
HDH8a8ro1aPbMkUHO0ChtWaq1qHfIWHnvl6h1yYa7QlsBtDg3/hYxOvjkzfk
S7ZPvQ0Nv0Co0v7x2xcH2p8Rg7+jfoBZX1MVzWw/FPS9fR6+PSJPOV3dhgNB
SPOijRuuLZ1OCnQGGWZPR9ds2qmEPEuG0nEkIQBSk1MhspOEHDJBfGRXVKIn
0xpYk02jYU8xeE67hYAgDecHmy3tPbQyH37m4t2Dzi8saeG8j6SZ57dxmFeh
gOLsCD9Lx0eFEE+DxHUhgAbqZOMdWLzD2rr7mJILaFiH32Jvt3o1PhUc+cq7
qKycDDGfDeNEcHOh62u9IKh7gCz5aDoLIyJXxsh5veLIOUd5iB46njTJ1Bwk
HevqHomfW7KWmFEb/VcElNDjiFttHuAeXkB4ZglnfaVtdR3qJla0S6utaUuc
X2mkPtwZ6DFo5QKNiUFoc6DgbLX+dWm7JImMDAGgdkpiv44bYXyJN+TpF3I/
d67XyrNwQ2+mRs1BDEi14jxq88pLQhbMBOJF7/SlM2S4xh6QH0q+Cu0ZiZ4Z
VA31PgaACHEIUmV2WIY6pKbfSVLTBWvDUQp8XtQJE6rugkIOmt6Q6AnXUf1C
mOgMOopaDFmOyuLX85rx/c6H5Pgepvfv/qmtRRLjwW5laLWKmJ0limWqoSBG
Cb/Zg/wSdtzOlGUjnZXMDUodJpsB9cRmhcPnqwyFX0adzV1Wzj1OQKQ5EJZR
SzOKTL0ysyfWv/dX2VI3hlgC82EQg3G6pYD8Isvg5cjZLqnoFGwUxXLGDjKa
M7rFTq2LjbajrKUnb8ZpoOtG8mEslM9wxnpGTL8XfBEZ9OOxyohIxOYMHWiw
28zextAJGtz3b3//PaZD+GhAuiD4kmBCpjBe8tc73RJSPUcf1l50yoaCBoZe
MeGYD1iEZFg2BWotReaSYrDDzR1CGlQWVbpmw3hcFyLdSvir+J4SPluz6uQe
9b7xbEFDWeBAxsQZgGxT+flgkaPXxtNPME52Bx4Fgrxjw7LlHNyikpQWOPSu
Y7g0xJZIpbeb2LIUMTagIx3IE/3dpNg/ITrClOUrgnwc8BnyJhtsUALECPlm
/REu/fOmUWK2fA+x1GY984h86lbuucg7BLPREUG2855UIv6AW0dPHk4UcYEr
BEf2pSJmjEmOfWurpSSc3rkn86rgm2pFKkiF0eX1NqKvYPoHLlYrcSLQ1EtQ
3zYm3Emlx7hTtOVwv/nk0lNNXOab77IpHozx/UJIF4JGJEpqpG5ZjVfV2aI+
MxA/SnRAxA8cm64P7JWwoVAfQyD2eu3JQHKREE0Vrrrk+Bb77IKXNEBPek4n
AU30anbwSESVSxlXMbq2Y9lht+DsWv7ylCVy5PrzOFOBaWdWUqptwVBiUmXC
ybIlgEqtG5aSvPvhzgbSyu6LaIVoC87Bqqgc2Sbkm6DSJLhvSKIXzMhlZo/y
X6Cjhyjb7vzv7+7JiomjonMdQmY1xJp5pdp9w3RYEpcanozYxv1+sdS3uwmC
haM12EguIIaNeZzSleYZfYWulP3MzpvUPlinSThVBPLJJVjwJuBcfLO+MOgB
E7Rhh2sJZXUkOJVjlJUgxJ2ziDbxnnYVCYk4ZR9HGWNHJs4zdlQCLiEecSmN
KlG7qBFK0+k6pSdnHRrHY7A41dJTfcm9dLzpx0gr+QbDVHp/OHdCgb7U+SP3
VyaEkZA3vw6l7nXKc6XGhTq1Nq6TkZYfwoQyyyWWZG7sTTc9ed/W2PE9P+RA
rWe0BsHRCLH1iuzjNk6e5mKROQc7TtcRWdW/gvCAPXLCxdFh+7VVr2l9wiyp
mdOEkCDAEorIiwq0QhlHVy3rMWp2YMBJpAbhAx6yYxNlAzEf6hKkz6g3um5t
mdXOnbMEYX8xHpR53QfXpcGQ491Z41ZZmZwVgo6TCRT5Z20hV1MyjZRBZcMj
Kxp1WYmBonzR945IY2JGNqoEyVD9U+Ta0ahiSC9HY0xDoqRoRV3cMSnzTUt7
kgOd+jpoTfrumJ5wy3PN2JawMQyWzhJADKHhLtFDw8opKVDJ2XkIv1He5FfP
x48JD/2kWoG6MG7m4xNBcPiDZjePdyQagjyd83ysmq+yNL7vjDd8WracVcmc
ZrP6DP0Punj1kLMvOWcUxLalXP093yUsdlLPjNFWqKPlV5n64QLez0JHyjiP
BN+1ksl80iDldXFC8GEQL8juGnvUnTuKAMiRalYzsYK523DM6k4bRdhjZwif
cA1z3tqOTDilfYwTKGgHy2tc2K1yF/k9xHxfZvTBhDMZVag3m4eYRW/4IDnF
mJgMFT0lkjO8lJj/tCQYss/ddgkgHE6UpueabA7hNG1OWQ0OpruSr4eAK8dA
HnEBdTwTXcjiRdVBufsIRxmT9/2b94iwEoREWkoqFVWcsGNCiGxB0G3tONeg
YTSgqXrnMetXoelN+sCiuRyjEsvr2bgKpUCpnOpkRBp1iag0mP7S9m4JImkq
g2HsvO+H28+SrgRMXb8TyR/PCC2QI3aahUYMyH8tghQ0UTMNdec7L7Sy5Bhh
5hRUzEPO9bLu1MgaCd+jjAEnvVMLhThvwxskGwO1J5/jYl8pub2BSZVsDpjY
My4zKOayQRU6e04lRUFSl8zALvlmlk4xiQVqMHDKLuq/g/wKh27BcWelQcku
j5da3AfYT0/R/OL5DYd7x5nWVFXfLE6f6SxcW04AkkzyoJIX7YzYq6++OjqB
9ih5QBINBm2WZegFURcSXV50VV5SalTDkPXQO+F52/ScIutCT0WkR1QYPvdF
TdWScn4oQOM37AJUkQW7jannlvCDEuun5zU8UuDoKUiFY+QGSVlIQhu8rG6+
qD4pIwbRB3EjsIGYCcS/Ps1Ie4nueIaE+VHXVCnEsvZiFMIvo0+zNOtG2a2a
E2+Bzkj/FRgspuWaZQN8F/LE/b3mAfmEjPbwPNI2MEj1oVBYlg3PpK18rDDU
QHDhYKMxOBftmEFRTVO62THDO2yBQPso8G6L6XamwNauncxMwjKLXRMMwTAb
gmeD2eajAv8H+g/M7xY0gXbr6y3LwAL4DjRJjaWb1D5ksKA5ZQsajUUegdAT
idZjSmeoexZVfl+2HtHECNP7QZsSMIRJiP6BMKDydSjlGlgnuP6nPq65gPCa
C7pCLnBz8P3g3TSRoMBjCeIXtUKKx0wMm5JDyQySDEdPmi3t0lE8t2EifNkJ
79TIoF9/yD7NEAxQc/zXqBRcSBmUMI+aOISCJOAP4goc1ISCmqM0lBv9Wif8
2du35ARmh+T1P/S5wcI0JQaDgrCIAbxr1ue4izhFLBEwnJBCOXx6AVkA3DRD
228dRJZNkbgeEAAtJ8rArQZcegNZz6OwXUAryO6RELNL+YnIqNfyaD9xdTc2
UafbxERVAaQSXGrBofzEp33GH2N7IsPDWf+Jj+gGy69gw3ZSxB4t2K0zEHbN
PESFUwMBf7+o5wQYUmXq7dPj1y9fPn315OmTKB7mLD6/rc4Y6yCT8JRifsVL
IvdmXjFLyENItHhC1uiX64PVFTITotCAWEM0VVYj53g3pwdkM29jPKlNVmT9
2YdtJU0z2whNZFth3pMvH7frWSepqWrqDxywugO9BrjLQ6t2n5BAtJV6qAKT
hPownTtGwpkWdIGtDyNZ+5quNYpVxhzzaOjbBE7NiMH8Fk5BGzkwFZu5kCzm
BrJryYStL6gCjMWK00E5wrC0JL1MFUAuEH2USHjAxoyKuCb3t8nUYcIxcndk
VlyAgi4iZg+55PEvuMopMhqqd9JHU7KLZs/oIGnPREEtXaVxEYpvw3E+N9d1
oNdjKpF4NgSx/lIrlCsOJzlZ55Qu543vmElsUW6ZUJRVbr1qOHpHyAEnbMNG
xWkbKnc0yo3Bl5q2CI0YYmEhNJELREumaLUNX3vd9piUB3Vc+DxojPxti+Rg
VEScl5SxErQFz01pCmM4n4ucNEOwW0uyCZP/RopcvSEiPoQGtrVcF6LrBGUm
G3H7IPxqEjxHKw0jtG4XOi/yCOpxmOAx4p4QiIHNaiziZqW2PJFQxPgkG5D1
lA/vXTU+tBZ1ZsG0lBLiZCgdO9DUj10P+dVCl8jEk9BUqEthjOqSalBTD6cd
1xCkzNPOH4uI/opr1ChZuc9IRU7aUaTMopHRcGZkpDdE+YVGI+B7gnLxlVYk
tETZHOS2Vq9sfr0yt/YwrwAVPqccFt+ETNO3FVM1Dqe3+PwNFiQVWOq4lQe/
KAUGP7/RSKzPBNIHGUAT4mix9CHXXwNq8kJw9mHgSpxIbpnqrEYncp9L4MU0
bY8YKKO6kM6AAkcWIfhnQlqyvPgJrEQwMGYmEYgMSTlU5ldOC5aHImrFHgjX
fi/L3z9rMM4r4H+LHyd+N4SFOyOq5cqVIKFFMxLlJhMgW0FW7CNLJpIXzTJH
GBWb6GmN5aAmkQPsHnBw2i8A7Tn1JqF/nhIJTbeYZKjswtpyTtcq5BR0g0jw
rS4uhFRT0u9g5+K+35NmJiCjR3tkJERHg9ddyylEM4YrQAuDvw1VSTzOCzO3
SWZFMyShTjHw9DaVE6n1USirUUOouKqceE3cYS5dObq3SSsIIL/RjvNL04nL
2XGRx0CjELnGmZsQhnzeLAZbhbd1YFZ5LsRLmu1osH1sXnFFPp4FOcG2/zy4
nlHUdBe4UI5R4mkfDWIgDGzCxe1EvOz6O9KRxX98hNFfYfYE/vP3qPq/5yAR
/RMr2unfmP5+5H/se/lxEL78sfjPYn8G8v/AuZ19Ch3wr939l3Qo/fucKRn+
JfugmXVBgf0u+2Dm+R0Pfh7si9yDf+BZwy+OcNsPn5BpxeX8/Kjgy2BWl2dt
uUwvBRAr/aL6417+UtmDO2MnCkjp47TaDINZUm+WT0P1Z8J5q5YSoIW/hJxL
CnwYSQ0LMX0FLQqqAZU8MbUqUcKEkAMZmVhNXKyXREPLQPCtd1vIqYWMul7Y
kF5OvmM1Op8VEUwrvKKHAMtn9d/yl/R5247P6cvkflbnbcX4MNWi0ePCzkMm
jFaaOjTdLuJMKAFTXnEXc3RKSfZ1gcZCxbKoBiXT3zVc0TRVnszNz2TTXLH+
ildLVq7bmVu9D4LiwCQcifdRTWwWhhIPwXvBvGlH2VqQ6mBKvDWUBeoj4MhC
732cAi9ORmmJ8K6pUGDL5HoWXNkqEc/WsL4qa0jDIVSfhDnKk8QLkj9AeniH
REBhu2kT/21S+csxzOecyx56s3VXB9URRII0PM5QZLef2UsHQxMr7p+c9Jnc
YXpRuTRVHfuXjuWfubvw719wfxX7sp0O4q9BEO/sUfZviC7+ut/z3zX3nPlL
L15/xYyvuXPTubpZb25d+yhM8S3zwT84jfx3Y71gZ29uOo3278ZaxK7ff6Vy
cYNmvu73N1NFbtSSGmtf/3u/DXc+sa8mkhacW6CGcJDVfMJNq0rPzms6aD8J
UEYx4rMMjp/p8CU5GtWP0wYBP5FP3oegdgQa0fupqEBpCuQel63EbDXVikKF
nFLQQjFTVRDFOVMNU9ISpwX7lkClqNebhaIncikpzDNJephhDXJqQCt+1hd2
884C9DPXvqzTzBbtiS+buPhgwM9zMtF8Z89SBs5leVYTR625QRqpcxZbtDt8
MalFu+djkt7khiZ5S1WzmxvJxso90stX+AHPK84kw+ASabD/vSkXSnEpBa0D
oj7iQBVtgANrfJlH048YHPJJpZZ95FZi3OVLxBwramaXY4n0tPHSPLpDgx3k
lLBeSjGsnowFrw6FkpbxtKEHhN2TOSU1rh5lKMhs6MsFTsI0Ffo8JLBHyLHr
8vYLw9fgh1EWNukg090MnYRUiOGIRDaPi9Djp5uzM08mhU53C3UvifExPVX5
d/URLsntUutZ9yPtoJz23l0XznhzSjFM5gRivn2HIL+qj/Du5Idi11rwb0Yn
a1K8wMzDEYNxqSrnmotSZGaLRRCsBDlA6j4h4/cBM7DjQio8q8vcx0L6yIjM
XBp7VBI3ovM3I31z8rM42wJpQpSwr4Vw2ZqEb+EXxSkyW7R81L0VxP4rwudm
YgBMyxjPGMfB6wVhiBSuJ+8gsHWoOHR1q4GJ3IS2lCuRPO5OJAjJ+IorYoRk
Yy/2OlHC6S+niV+hfuOfqOA30hIMEhIlMi3nTdWLwVTe9IeqjmApP/5kqP8O
1UVSZ8Mr6J/vCcrxPqBgQI+p+Fez99DAgf9t/Hmmp+NrtWOj3u985iaK/E00
4WSwOx646fBzP4+fvM6WsH/Xz9S1fzv8bTfuQdNeocvu/vtnbRj9m0wm/+Dv
VYf/ip/706LKeL/odmoOqpG/lGjNT1gABA+qaCIgfcwWTRVzSdOVasD13zUH
3FyH6i8KIvqCEYGnWxfJbL2eKJxrCJkmTCCiBkDk9CTeU7wkfGBc6E+T2ziT
tMKexBioQODS1Xqj5YNzcWG3/+EpaiPVLN/k8NY8CLl0ZKlgwSwCWYBiE3dg
TMeTKa0RZ2F1I71QCZKd6kNoBZzWs243YSL8jHoTrGK5cDhnki/qTcISjuF2
sWvyBHGcNwaqEDwpQMK+yWUIITsBUsrW6LPslXJGyU9i8CwuqAvXXLJO4irb
471DVTwNHaS6JxfVnHUSSTdNtNqLzQJ3rDD1Uy47pmtvfGm7kCGaaOjMRfSG
i2kdYfU23+9IXY8WbwxX3helZ0pJg4hMMjxe7NhdxAzmaRlD6BGP4LQt55Tq
yt2SE0eMu9Un3DUYl0dWWOZLYfe6vM81rR5jyg9YYNzdZD3i8lL8kxt/5Nzv
UEtDgDuRjayTYq2yOYz7mJl/MQWdeYV9DSzPJVwYWOrILhv1U7KsePtfBlqj
1/sv/+t3rw6EIZjC0NDSS824iEtyXsl7hVvslfwOmtAyHumBkaF7v8OVwxac
5bRZY9zVQ2WI62uEBZVXqQ8gBSQl8K3IUil5naCdjGQ7VQohBoPRk6Zn2TmA
lmDEAop5wYduIDIoPdPbXtj6Kx6gmJFUtsZQs77bNRYTK8Uxv95/9V+/e3EA
9t+SeYWgGe/Fh3HD97+Hr5GQ5rKeIWlujO1iEljDT1BiC9LquKN7Sc9GeDMW
ncSAFtwsQl7Cy5/Uyrrm+gmVDMggSWfstAq2KhmzBKke8cOzDeOmKmvP0i84
l1tyQ7eFT7bS9+zg3cXJLPWYdbgFMQlBiGojkaR5wHF2rEf3ae7PgDAPazc+
P3p1NKjbiEUmqFyoehTwGvYTgRxaxVuwdGH/bp2jFhD4hsQEKtIDHh4646ne
0Tch1QDd3rBN5nzbQzAitV3sR3WZQsbUASPB8/djsX/707y6PTuQumR7ksi8
hzQIm+VKse1IdMJlpPYwj+fZ27ej4unTvVGx9wTLer+Gm8v/hJ8t9l6J92rv
rS5iNbMPUaoBPPfbHmUw5LR06t7s9m3tHl2AV3YR+7c3oo5e3bNdvZIuBccb
jZme7AfPvV6xGwR2Xcf8VkTY92yyt2NfkDrv9wNcl2SGEz91ujOIXwseGtHM
eCfm/uGdw4N0g9CkOGr8RlvCTidP0886NhfmgCF1KARi/m2/Ee1AGLc7Dms3
rkG3yA4MlNZLXkaPjQ1tmu6Tnweele3/fxu72p7EgSD8vb+i4b5oQokoipqY
yyp4R6KcAXMXc7lcqjRn77AQCuJL/O8388zsdgvF6JeNUNrd7e687TzPOMOo
BNjeontsb+qgPxkoUNwI+3Q//cyvBQ0BX96MJOqkTAKDSrDdjoNjiPb5ciKU
GAV+wuVzuSF1C9PMoVaC9W95M5OkdVPaJwXLz+nHBXXN+q+CwFu+fLnhF8Yx
O1rcLibsiNPSYgX+kGrQ4RfUa/bArI7oqlCYt4mln3YMTboBUtDZCrQnLjAj
/PAFCKI5l59Ntvn42fKa8T2MhlS9n9zUCmjzULGneWAkKUQIHZq7UnN0YJWF
fRFl+1mQXdUT5hWuE16KHLOWgbpnAzkvth87kvkU2uakhkTguzl7g7SOVsX1
B5Y0K5p8cctazurdYWkMA7vP/TVqy2pv6Sam+XAEF0GrsbKjcTF3awXOqvu/
XXBjNNvscvEGDXiDxqPRmkYSdtjJ++OzG+r5GGEqnt7jEC9oNhm7VSypzZhi
WhzJzEJiiz5SB0PuoY0ZXFf+6qdOwS/PhbOB2NJcprneR3LWWVQ/koqPkeuv
KJJ8wWR5qaa0SHpQRlYVE5Yn86jDDobeZUuyHIF/tv5ZBloFZQ9w5x/UwW2J
n1vyPHHG5T62ELgFWjPWZQR2+NECi4StXXZAFw91LogCuBWTjaHmWjK/86dH
5wQMEIrYAVYhzaJRMhUG3zRZ5q4gc6oVyGkD6m0Ui6ug0znqXMo4SC5w2R8f
Deunm1/79ICOqs5ymAwSZcv2qhWuFXDyXJRAgJYOCFID/JrWYG2Vz5jWspKM
20sgHa7htKVA8bqkFweJcltQi+pJfVPrnczKnQ3cZqpSB3WPNHqWTEWruVpN
/sb1FcfO0w791altmqbhdtfsot0ze2hbpoV23+yjPTAHaNumjfbQHJp6sPN0
ZI7wv6E/bk/NKdozc4a2Yzpou6aL9tycmyoVM+gOu4Pv3c6aMrlZEbW8L48O
W0ee5FScp0rATUIyiiJ4FWw8X8A4j67ZHxY2/6JHV+Lk8jS/fhIrXkJCnj3x
Jm+4eCHwjEecN6s+suam1qosSS9UAqqgirM1WFXqQmjxnRKuW9+u82k8ZoP3
agk43m8UqWWuBMwqm7wXZGr1BF2MZWvjiC/JbKK++W1ijc1Nrn2wieC8qcfT
sc/TjcJHZLvXKwJjIr3h6nflJLo6plavTER0J0sQKjUyqpI/8fi3C0jWNGUa
drUluwptiSF5kw3tgeDaeyEgszhMI2nUd1lgvWjuD0mK74ZV819O/ETRJwz9
Tjy/sNcoxozH4fibp7v//iirBii9+Pgov7EaWKa5EuutjapqQKDiwTAaZPRO
9XwmdSvk/RhteeAMl2GcOTm9ktXJ+1iWWDI6qYFYzAW+Czk/i5e57ecjEysg
KEGaJ9Yg7ede1Gn8i18W9xNLj5KMojxLmb6DJKiUXUPQDbrKYpiLU3CbVp/O
HWeS5hwwZlBN7cCjXikMZWEfeiXDkUQ0Z1qexqTJ8zd+Nn16dj9jl4le4Feu
YfoQ2y+uYpJknC97dxlnC1xPMuL1ksT+PZl6VzPOKrYX9/nK4WI8Th/jzH54
yQf8GWnlyUM+kU95zumbTkyKOTxNsr9caJu+kQR9S4TEhVBopXHNIJlFe5hq
KZ/yRvAf4JYS8UOQAQA=

-->

</rfc>