<?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-rfc2629 version 1.5.6 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-thomson-http-oblivious-02" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.1 -->
  <front>
    <title>Oblivious HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-thomson-http-oblivious-02"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date year="2021" month="August" day="24"/>
    <area>ART</area>
    <workgroup>HTTPBIS</workgroup>
    <abstract>
      <t>This document describes a system for the forwarding of encrypted HTTP messages.
This allows a client to make multiple requests of a server without the server being able
to link those requests to the client or to identify the requests as having come
from the same client.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
  HTTP Working Group mailing list (http@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/http/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/unicorn-wg/oblivious-http"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The act of making a request using HTTP reveals information about the client
identity to a server. Though the content of requests might reveal information,
that is information under the control of the client. In comparison, the source
address on the connection reveals information that a client has only limited
control over.</t>
      <t>Even where an IP address is not directly attributed to an individual, the use
of an address over time can be used to correlate requests. Servers are able to
use this information to assemble profiles of client behavior, from which they
can make inferences about the people involved. The use of persistent
connections to make multiple requests improves performance, but provides
servers with additional certainty about the identity of clients in a similar
fashion.</t>
      <t>Use of an HTTP proxy can provide a degree of protection against servers
correlating requests. Systems like virtual private networks or the Tor network
<xref target="Dingledine2004" format="default"/>, provide other options for clients.</t>
      <t>Though the overhead imposed by these methods varies, the cost for each request
is significant. Preventing request linkability requires that each request
use a completely new TLS connection to the server. At a minimum,
this requires an additional round trip to the server in addition to that
required by the request. In addition to having high latency, there are
significant secondary costs, both in terms of the number of additional bytes
exchanged and the CPU cost of cryptographic computations.</t>
      <t>This document describes a method of encapsulation for binary HTTP messages
<xref target="BINARY" format="default"/> using Hybrid Public Key Encryption (HPKE;
<xref target="HPKE" format="default"/>). This protects the content of both requests and
responses and enables a deployment architecture that can separate the identity
of a requester from the request.</t>
      <t>Though this scheme requires that servers and proxies explicitly support it,
this design represents a performance improvement over options that perform just
one request in each connection. With limited trust placed in the proxy (see
<xref target="security" format="default"/>), clients are assured that requests are not uniquely attributed to
them or linked to other requests.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <dl>
        <dt>
Encapsulated Request:  </dt>
        <dd>
          <t>An HTTP request that is encapsulated in an HPKE-encrypted message; see
<xref target="request" format="default"/>.</t>
        </dd>
        <dt>
Encapsulated Response:  </dt>
        <dd>
          <t>An HTTP response that is encapsulated in an HPKE-encrypted message; see
<xref target="response" format="default"/>.</t>
        </dd>
        <dt>
Oblivious Proxy Resource:  </dt>
        <dd>
          <t>An intermediary that forwards requests and responses between clients and a
single oblivious request resource.</t>
        </dd>
        <dt>
Oblivious Request Resource:  </dt>
        <dd>
          <t>A resource that can receive an encapsulated request, extract the contents of
that request, forward it to an oblivious target resource, receive a response,
encapsulate that response, then return that response.</t>
        </dd>
        <dt>
Oblivious Target Resource:  </dt>
        <dd>
          <t>The resource that is the target of an encapsulated request.  This resource
logically handles only regular HTTP requests and responses and so might be
ignorant of the use of oblivious HTTP to reach it.</t>
        </dd>
      </dl>
      <t>This draft includes pseudocode that uses the functions and conventions defined
in <xref target="HPKE" format="default"/>.</t>
      <t>Encoding an integer to a sequence of bytes in network byte order is described
using the function <tt>encode(n, v)</tt>, where <tt>n</tt> is the number of bytes and <tt>v</tt> is
the integer value. The function <tt>len()</tt> returns the length of a sequence of
bytes.</t>
      <t>Formats are described using notation from <xref section="1.3" sectionFormat="of" target="QUIC" format="default"/>.</t>
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <name>Overview</name>
      <t>A client learns the following:</t>
      <ul spacing="normal">
        <li>The identity of an oblivious request resource.  This might include some
information about oblivious target resources that the oblivious request
resource supports.</li>
        <li>The details of an HPKE public key that the oblivious request resource accepts,
including an identifier for that key and the HPKE algorithms that are
used with that key.</li>
        <li>The identity of an oblivious proxy resource that will forward encapsulated
requests and responses to the oblivious request resource.</li>
      </ul>
      <t>This information allows the client to make a request of an oblivious target
resource without that resource having only a limited ability to correlate that
request with the client IP or other requests that the client might make to that
server.</t>
      <figure anchor="fig-overview">
        <name>Overview of Oblivious HTTP</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+---------+       +----------+       +----------+    +----------+
| Client  |       | Proxy    |       | Request  |    | Target   |
|         |       | Resource |       | Resource |    | Resource |
+---------+       +----------+       +----------+    +----------+
     |                 |                  |               |
     | Encapsulated    |                  |               |
     | Request         |                  |               |
     |---------------->| Encapsulated     |               |
     |                 | Request          |               |
     |                 |----------------->| Request       |
     |                 |                  |-------------->|
     |                 |                  |               |
     |                 |                  |      Response |
     |                 |     Encapsulated |<--------------|
     |                 |         Response |               |
     |    Encapsulated |<-----------------|               |
     |        Response |                  |               |
     |<----------------|                  |               |
     |                 |                  |               |
]]></artwork>
      </figure>
      <t>In order to make a request to an oblivious target resource, the following steps
occur, as shown in <xref target="fig-overview" format="default"/>:</t>
      <ol spacing="normal" type="1"><li>The client constructs an HTTP request for an oblivious target resource.</li>
        <li>The client encodes the HTTP request in a binary HTTP message and then
encapsulates that message using HPKE and the process from <xref target="request" format="default"/>.</li>
        <li>The client sends a POST request to the oblivious proxy resource with the
encapsulated request as the content of that message.</li>
        <li>The oblivious proxy resource forwards this request to the oblivious request
resource.</li>
        <li>The oblivious request resource receives this request and removes
the HPKE protection to obtain an HTTP request.</li>
        <li>The oblivious request resource makes an HTTP request that includes the target
URI, method, fields, and content of the request it acquires.</li>
        <li>The oblivious target resource answers this HTTP request with an HTTP
response.</li>
        <li>The oblivious request resource encapsulates the HTTP response following the
process in <xref target="response" format="default"/> and sends this in response to the request from the
oblivious proxy resource.</li>
        <li>The oblivious proxy resource forwards this response to the client.</li>
        <li>The client removes the encapsulation to obtain the response to the original
request.</li>
      </ol>
      <section anchor="applicability" numbered="true" toc="default">
        <name>Applicability</name>
        <t>Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being
able to carry state between requests, such as with cookies (<xref target="RFC6265" format="default"/>),
authentication (<xref section="11" sectionFormat="of" target="HTTP" format="default"/>), or even alternative services
(<xref target="RFC7838" format="default"/>).  Oblivious HTTP seeks to prevent this sort of linkage, which
requires that applications not carry state between requests.</t>
        <t>Oblivious HTTP is primarily useful where privacy risks associated with possible
stateful treatment of requests are sufficiently negative that the cost of
deploying this protocol can be justified.  Oblivious HTTP is simpler and less
costly than more robust systems, like Prio (<xref target="PRIO" format="default"/>) or Tor
(<xref target="Dingledine2004" format="default"/>), which can provide stronger guarantees at higher operational costs.</t>
        <t>Oblivious HTTP is more costly than a direct connection to a server.  Some costs,
like those involved with connection setup, can be amortized, but there are
several ways in which oblivious HTTP is more expensive than a direct request:</t>
        <ul spacing="normal">
          <li>Each oblivious request requires at least two regular HTTP requests, which adds
latency.</li>
          <li>Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and AEAD expansion.</li>
          <li>Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources.</li>
        </ul>
        <t>Examples of where preventing the linking of requests might justify these costs
include:</t>
        <ul spacing="normal">
          <li>DNS queries.  DNS queries made to a recursive resolver reveal information
about the requester, particularly if linked to other queries.</li>
          <li>Telemetry submission.  Applications that submit reports about their usage to
their developers might use oblivious HTTP for some types of moderately
sensitive data.</li>
        </ul>
      </section>
    </section>
    <section anchor="key-configuration" numbered="true" toc="default">
      <name>Key Configuration</name>
      <t>A client needs to acquire information about the key configuration of the
oblivious request resource in order to send encapsulated requests.</t>
      <t>In order to ensure that clients do not encapsulate messages that other entities
can intercept, the key configuration MUST be authenticated and have integrity
protection.</t>
      <t>This document describes the "application/ohttp-keys" media type; see
<xref target="ohttp-keys" format="default"/>.  This media type might be used, for example with HTTPS, as part
of a system for configuring or discovering key configurations.  Note however
that such a system needs to consider the potential for key configuration to be
used to compromise client privacy; see <xref target="privacy" format="default"/>.</t>
      <t>Specifying a format for expressing the information a client needs to construct
an encapsulated request ensures that different client implementations can be
configured in the same way. This also enables advertising key configurations in
a consistent format.</t>
      <t>A client might have multiple key configurations to select from when
encapsulating a request. Clients are responsible for selecting a preferred key
configuration from those it supports. Clients need to consider both the key
encapsulation method (KEM) and the combinations of key derivation function
(KDF) and authenticated encryption with associated data (AEAD) in this
decision.</t>
      <t>Evolution of the key configuration format is supported through the definition
of new formats that are identified by new media types.</t>
      <section anchor="key-config" numbered="true" toc="default">
        <name>Key Configuration Encoding</name>
        <t>A single key configuration consists of a key identifier, a public key, an
identifier for the KEM that the public key uses, and a set HPKE symmetric
algorithms. Each symmetric algorithm consists of an identifier for a KDF and an
identifier for an AEAD.</t>
        <t><xref target="format-key-config" format="default"/> shows a single key configuration, KeyConfig, that is
expressed using the TLS syntax; see <xref section="3" sectionFormat="of" target="TLS" format="default"/>.</t>
        <figure anchor="format-key-config">
          <name>A Single Key Configuration</name>
          <sourcecode type="tls-syntax"><![CDATA[
opaque HpkePublicKey[Npk];
uint16 HpkeKemId;
uint16 HpkeKdfId;
uint16 HpkeAeadId;

struct {
  HpkeKdfId kdf_id;
  HpkeAeadId aead_id;
} HpkeSymmetricAlgorithms;

struct {
  uint8 key_id;
  HpkeKemId kem_id;
  HpkePublicKey public_key;
  HpkeSymmetricAlgorithms cipher_suites<4..2^16-4>;
} KeyConfig;
]]></sourcecode>
        </figure>
        <t>The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, and AEAD
respectively. The definitions for these identifiers and the semantics of the
algorithms they identify can be found in <xref target="HPKE" format="default"/>. The Npk parameter
corresponding to the HpkeKdfId can be found in <xref target="HPKE" format="default"/>.</t>
      </section>
      <section anchor="ohttp-keys" numbered="true" toc="default">
        <name>Key Configuration Media Type</name>
        <t>The "application/ohttp-keys" format is a media type that identifies a
serialized collection of key configurations. The content of this media type
comprises one or more key configuration encodings (see <xref target="key-config" format="default"/>) that are
concatenated.</t>
        <dl>
          <dt>
Type name:  </dt>
          <dd>
            <t>application</t>
          </dd>
          <dt>
Subtype name:  </dt>
          <dd>
            <t>ohttp-keys</t>
          </dd>
          <dt>
Required parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Optional parameters:  </dt>
          <dd>
            <t>None</t>
          </dd>
          <dt>
Encoding considerations:  </dt>
          <dd>
            <t>only "8bit" or "binary" is permitted</t>
          </dd>
          <dt>
Security considerations:  </dt>
          <dd>
            <t>see <xref target="security" format="default"/></t>
          </dd>
          <dt>
Interoperability considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Published specification:  </dt>
          <dd>
            <t>this specification</t>
          </dd>
          <dt>
Applications that use this media type:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Fragment identifier considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Additional information:  </dt>
          <dd>
            <dl>
              <dt>Magic number(s):</dt>
              <dd>N/A</dd>
              <dt>Deprecated alias names for this type:</dt>
              <dd>N/A</dd>
              <dt>File extension(s):</dt>
              <dd>N/A</dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>N/A</dd>
            </dl>
          </dd>
          <dt>
Person and email address to contact for further information:  </dt>
          <dd>
            <t>see Authors' Addresses section</t>
          </dd>
          <dt>
Intended usage:  </dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>
Restrictions on usage:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Author:  </dt>
          <dd>
            <t>see Authors' Addresses section</t>
          </dd>
          <dt>
Change controller:  </dt>
          <dd>
            <t>IESG</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="hpke-encapsulation" numbered="true" toc="default">
      <name>HPKE Encapsulation</name>
      <t>HTTP message encapsulation uses HPKE for request and response encryption.
An encapsulated HTTP message includes the following values:</t>
      <ol spacing="normal" type="1"><li>A binary-encoded HTTP message; see <xref target="BINARY" format="default"/>.</li>
        <li>Padding of arbitrary length which MUST contain all zeroes.</li>
      </ol>
      <t>The encoding of an HTTP message is as follows:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Plaintext Message {
  Message Length (i),
  Message (..),
  Padding Length (i),
  Padding (..),
}
]]></artwork>
      <t>An Encapsulated Request is comprised of a length-prefixed key identifier and a
HPKE-protected request message. HPKE protection includes an encapsulated KEM
shared secret (or <tt>enc</tt>), plus the AEAD-protected request message. An
Encapsulated Request is shown in <xref target="fig-enc-request" format="default"/>. <xref target="request" format="default"/> describes the
process for constructing and processing an Encapsulated Request.</t>
      <figure anchor="fig-enc-request">
        <name>Encapsulated Request</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Encapsulated Request {
  Key Identifier (8),
  KEM Identifier (16),
  KDF Identifier (16),
  AEAD Identifier (16),
  Encapsulated KEM Shared Secret (8*Nenc),
  AEAD-Protected Request (..),
}
]]></artwork>
      </figure>
      <t>The Nenc parameter corresponding to the HpkeKdfId can be found in <xref target="HPKE" format="default"/>.</t>
      <t>Responses are bound to responses and so consist only of AEAD-protected content.
<xref target="response" format="default"/> describes the process for constructing and processing an
Encapsulated Response.</t>
      <figure anchor="fig-enc-response">
        <name>Encapsulated Response</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Encapsulated Response {
  Nonce (Nk),
  AEAD-Protected Response (..),
}
]]></artwork>
      </figure>
      <t>The size of the Nonce field in an Encapsulated Response corresponds to the
size of an AEAD key for the corresponding HPKE ciphersuite.</t>
      <section anchor="request" numbered="true" toc="default">
        <name>Encapsulation of Requests</name>
        <t>Clients encapsulate a request <tt>request</tt> using values from a key configuration:</t>
        <ul spacing="normal">
          <li>the key identifier from the configuration, <tt>keyID</tt>, with the corresponding KEM
identified by <tt>kemID</tt>,</li>
          <li>the public key from the configuration, <tt>pkR</tt>, and</li>
          <li>a selected combination of KDF, identified by <tt>kdfID</tt>, and AEAD, identified by
<tt>aeadID</tt>.</li>
        </ul>
        <t>The client then constructs an encapsulated request, <tt>enc_request</tt>, as follows:</t>
        <ol spacing="normal" type="1"><li>Compute an HPKE context using <tt>pkR</tt>, yielding <tt>context</tt> and encapsulation
key <tt>enc</tt>.</li>
          <li>Construct associated data, <tt>aad</tt>, by concatenating the values of <tt>keyID</tt>,
<tt>kemID</tt>, <tt>kdfID</tt>, and <tt>aeadID</tt>, as one 8-bit integer and three 16-bit
integers, respectively, each in network byte order.</li>
          <li>Encrypt (seal) <tt>request</tt> with <tt>aad</tt> as associated data using <tt>context</tt>,
yielding ciphertext <tt>ct</tt>.</li>
          <li>Concatenate the values of <tt>aad</tt>, <tt>enc</tt>, and <tt>ct</tt>, yielding an Encapsulated
Request <tt>enc_request</tt>.</li>
        </ol>
        <t>Note that <tt>enc</tt> is of fixed-length, so there is no ambiguity in parsing this
structure.</t>
        <t>In pseudocode, this procedure is as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
enc, context = SetupBaseS(pkR, "request")
aad = concat(encode(1, keyID),
             encode(2, kemID),
             encode(2, kdfID),
             encode(2, aeadID))
ct = context.Seal(aad, request)
enc_request = concat(aad, enc, ct)
]]></artwork>
        <t>Servers decrypt an Encapsulated Request by reversing this process. Given an
Encapsulated Request <tt>enc_request</tt>, a server:</t>
        <ol spacing="normal" type="1"><li>
            <t>Parses <tt>enc_request</tt> into <tt>keyID</tt>, <tt>kemID</tt>, <tt>kdfID</tt>, <tt>aeadID</tt>, <tt>enc</tt>, and <tt>ct</tt>
(indicated using the function <tt>parse()</tt> in pseudocode). The server is then
able to find the HPKE private key, <tt>skR</tt>, corresponding to <tt>keyID</tt>.  </t>
            <t>
a. If <tt>keyID</tt> does not identify a key matching the type of <tt>kemID</tt>, the server
   returns an error.  </t>
            <t>
b. If <tt>kdfID</tt> and <tt>aeadID</tt> identify a combination of KDF and AEAD that the
   server is unwilling to use with <tt>skR</tt>, the server returns an error.</t>
          </li>
          <li>Compute an HPKE context using <tt>skR</tt> and the encapsulated key <tt>enc</tt>,
yielding <tt>context</tt>.</li>
          <li>Construct additional associated data, <tt>aad</tt>, from <tt>keyID</tt>, <tt>kdfID</tt>, and
<tt>aeadID</tt> or as the first five bytes of <tt>enc_request</tt>.</li>
          <li>Decrypt <tt>ct</tt> using <tt>aad</tt> as associated data, yielding <tt>request</tt> or an error
on failure. If decryption fails, the server returns an error.</li>
        </ol>
        <t>In pseudocode, this procedure is as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request)
aad = concat(encode(1, keyID),
             encode(2, kemID),
             encode(2, kdfID),
             encode(2, aeadID))
context = SetupBaseR(enc, skR, "request")
request, error = context.Open(aad, ct)
]]></artwork>
      </section>
      <section anchor="response" numbered="true" toc="default">
        <name>Encapsulation of Responses</name>
        <t>Given an HPKE context <tt>context</tt>, a request message <tt>request</tt>, and a response
<tt>response</tt>, servers generate an Encapsulated Response <tt>enc_response</tt> as
follows:</t>
        <ol spacing="normal" type="1"><li>Export a secret <tt>secret</tt> from <tt>context</tt>, using the string "response" as context.
The length of this secret is <tt>max(Nn, Nk)</tt>, where <tt>Nn</tt> and <tt>Nk</tt> are the length
of AEAD key and nonce associated with <tt>context</tt>.</li>
          <li>Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, called <tt>response_nonce</tt>.</li>
          <li>Extract a pseudorandom key <tt>prk</tt> using the <tt>Extract</tt> function provided by
the KDF algorithm associated with <tt>context</tt>. The <tt>ikm</tt> input to this
function is <tt>secret</tt>; the <tt>salt</tt> input is the concatenation of <tt>enc</tt> (from
<tt>enc_request</tt>) and <tt>response_nonce</tt></li>
          <li>Use the <tt>Expand</tt> function provided by the same KDF to extract an AEAD key
<tt>key</tt>, of length <tt>Nk</tt> - the length of the keys used by the AEAD associated
with <tt>context</tt>. Generating <tt>key</tt> uses a label of "key".</li>
          <li>Use the same <tt>Expand</tt> function to extract a nonce <tt>nonce</tt> of length <tt>Nn</tt> -
the length of the nonce used by the AEAD. Generating <tt>nonce</tt> uses a label of
"nonce".</li>
          <li>Encrypt <tt>response</tt>, passing the AEAD function Seal the values of <tt>key</tt>,
<tt>nonce</tt>, empty <tt>aad</tt>, and a <tt>pt</tt> input of <tt>request</tt>, which yields <tt>ct</tt>.</li>
          <li>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an Encapsulated Response
<tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed-length, so there is no
ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</li>
        </ol>
        <t>In pseudocode, this procedure is as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
secret = context.Export("response", Nk)
response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce)
prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct)
]]></artwork>
        <t>Clients decrypt an Encapsulated Request by reversing this process. That is,
they first parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>ct</tt>. They then
follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonce</tt>.</t>
        <t>The client uses these values to decrypt <tt>ct</tt> using the Open function provided by
the AEAD. Decrypting might produce an error, as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
reponse, error = Open(aead_key, aead_nonce, "", ct)
]]></artwork>
      </section>
    </section>
    <section anchor="http-usage" numbered="true" toc="default">
      <name>HTTP Usage</name>
      <t>A client interacts with the oblivious proxy resource by constructing an
encapsulated request.  This encapsulated request is included as the content of a
POST request to the oblivious proxy resource.  This request MUST only contain
those fields necessary to carry the encapsulated request: a method of POST, a
target URI of the oblivious proxy resource, a header field containing
the content type (see (<xref target="media-types" format="default"/>), and the encapsulated request as the
request content.  Clients MAY include fields that do not reveal information
about the content of the request, such as Alt-Used <xref target="ALT-SVC" format="default"/>, or
information that it trusts the oblivious proxy resource to remove, such as
fields that are listed in the Connection header field.</t>
      <t>The oblivious proxy resource interacts with the oblivious request resource by
constructing a request using the same restrictions as the client request, except
that the target URI is the oblivious request resource.  The content of this
request is copied from the client.  The oblivious proxy resource MUST NOT add
information about the client to this request.</t>
      <t>When a response is received from the oblivious request resource, the oblivious
proxy resource forwards the response according to the rules of an HTTP proxy;
see <xref section="7.6" sectionFormat="of" target="HTTP" format="default"/>.</t>
      <t>An oblivious request resource, if it receives any response from the oblivious
target resource, sends a single 200 response containing the encapsulated
response.  Like the request from the client, this response MUST only contain
those fields necessary to carry the encapsulated response: a 200 status code, a
header field indicating the content type, and the encapsulated response as the
response content.  As with requests, additional fields MAY be used to convey
information that does not reveal information about the encapsulated response.</t>
      <t>An oblivious request resource acts as a gateway for requests to the oblivious
target resource (see <xref section="7.6" sectionFormat="of" target="HTTP" format="default"/>).  The one exception is that any
information it might forward in a response MUST be encapsulated, unless it is
responding to errors it detects before removing encapsulation of the request;
see <xref target="errors" format="default"/>.</t>
      <section anchor="informational-responses" numbered="true" toc="default">
        <name>Informational Responses</name>
        <t>This encapsulation does not permit progressive processing of responses.  Though
the binary HTTP response format does support the inclusion of informational
(1xx) status codes, the AEAD encapsulation cannot be removed until the entire
message is received.</t>
        <t>In particular, the Expect header field with 100-continue (see Section 10.1.1 of
<xref target="HTTP" format="default"/>) cannot be used.  Clients MUST NOT
construct a request that includes a 100-continue expectation; the oblivious
request resource MUST generate an error if a 100-continue expectation is
received.</t>
      </section>
      <section anchor="errors" numbered="true" toc="default">
        <name>Errors</name>
        <t>A server that receives an invalid message for any reason MUST generate an HTTP
response with a 4xx status code.</t>
        <t>Errors detected by the oblivious proxy resource and errors detected by the
oblivious request resource before removing protection (including being unable to
remove encapsulation for any reason) result in the status code being sent
without protection in response to the POST request made to that resource.</t>
        <t>Errors detected by the oblivious request resource after successfully removing
encapsulation and errors detected by the oblivious target resource MUST be sent
in an encapsulated response.</t>
      </section>
    </section>
    <section anchor="media-types" numbered="true" toc="default">
      <name>Media Types</name>
      <t>Media types are used to identify encapsulated requests and responses.</t>
      <t>Evolution of the format of encapsulated requests and responses is supported
through the definition of new formats that are identified by new media types.</t>
      <section anchor="messageohttp-req-media-type" numbered="true" toc="default">
        <name>message/ohttp-req Media Type</name>
        <t>The "message/ohttp-req" identifies an encapsulated binary HTTP request.  This
is a binary format that is defined in <xref target="request" format="default"/>.</t>
        <dl>
          <dt>
Type name:  </dt>
          <dd>
            <t>message</t>
          </dd>
          <dt>
Subtype name:  </dt>
          <dd>
            <t>ohttp-req</t>
          </dd>
          <dt>
Required parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Optional parameters:  </dt>
          <dd>
            <t>None</t>
          </dd>
          <dt>
Encoding considerations:  </dt>
          <dd>
            <t>only "8bit" or "binary" is permitted</t>
          </dd>
          <dt>
Security considerations:  </dt>
          <dd>
            <t>see <xref target="security" format="default"/></t>
          </dd>
          <dt>
Interoperability considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Published specification:  </dt>
          <dd>
            <t>this specification</t>
          </dd>
          <dt>
Applications that use this media type:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Fragment identifier considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Additional information:  </dt>
          <dd>
            <dl>
              <dt>Magic number(s):</dt>
              <dd>N/A</dd>
              <dt>Deprecated alias names for this type:</dt>
              <dd>N/A</dd>
              <dt>File extension(s):</dt>
              <dd>N/A</dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>N/A</dd>
            </dl>
          </dd>
          <dt>
Person and email address to contact for further information:  </dt>
          <dd>
            <t>see Authors' Addresses section</t>
          </dd>
          <dt>
Intended usage:  </dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>
Restrictions on usage:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Author:  </dt>
          <dd>
            <t>see Authors' Addresses section</t>
          </dd>
          <dt>
Change controller:  </dt>
          <dd>
            <t>IESG</t>
          </dd>
        </dl>
      </section>
      <section anchor="messageohttp-res-media-type" numbered="true" toc="default">
        <name>message/ohttp-res Media Type</name>
        <t>The "message/ohttp-res" identifies an encapsulated binary HTTP response. This
is a binary format that is defined in <xref target="response" format="default"/>.</t>
        <dl>
          <dt>
Type name:  </dt>
          <dd>
            <t>message</t>
          </dd>
          <dt>
Subtype name:  </dt>
          <dd>
            <t>ohttp-res</t>
          </dd>
          <dt>
Required parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Optional parameters:  </dt>
          <dd>
            <t>None</t>
          </dd>
          <dt>
Encoding considerations:  </dt>
          <dd>
            <t>only "8bit" or "binary" is permitted</t>
          </dd>
          <dt>
Security considerations:  </dt>
          <dd>
            <t>see <xref target="security" format="default"/></t>
          </dd>
          <dt>
Interoperability considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Published specification:  </dt>
          <dd>
            <t>this specification</t>
          </dd>
          <dt>
Applications that use this media type:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Fragment identifier considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Additional information:  </dt>
          <dd>
            <dl>
              <dt>Magic number(s):</dt>
              <dd>N/A</dd>
              <dt>Deprecated alias names for this type:</dt>
              <dd>N/A</dd>
              <dt>File extension(s):</dt>
              <dd>N/A</dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>N/A</dd>
            </dl>
          </dd>
          <dt>
Person and email address to contact for further information:  </dt>
          <dd>
            <t>see Authors' Addresses section</t>
          </dd>
          <dt>
Intended usage:  </dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>
Restrictions on usage:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Author:  </dt>
          <dd>
            <t>see Authors' Addresses section</t>
          </dd>
          <dt>
Change controller:  </dt>
          <dd>
            <t>IESG</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>In this design, a client wishes to make a request of a server that is
authoritative for the oblivious target resource. The client wishes to make this
request without linking that request with either:</t>
      <ol spacing="normal" type="1"><li>The identity at the network and transport layer of the client (that is, the
client IP address and TCP or UDP port number the client uses to create a
connection).</li>
        <li>Any other request the client might have made in the past or might make in
the future.</li>
      </ol>
      <t>In order to ensure this, the client selects a proxy (that serves the oblivious
proxy resource) that it trusts will protect this information by forwarding the
encapsulated request and response without passing the server (that serves the
oblivious request resource).</t>
      <t>In this section, a deployment where there are three entities is considered:</t>
      <ul spacing="normal">
        <li>A client makes requests and receives responses</li>
        <li>A proxy operates the oblivious proxy resource</li>
        <li>A server operates both the oblivious request resource and the oblivious
target resource</li>
      </ul>
      <t>To achieve the stated privacy goals, the oblivious proxy resource cannot be
operated by the same entity as the oblivious request resource. However,
colocation of the oblivious request resource and oblivious target resource
simplifies the interactions between those resources without affecting client
privacy.</t>
      <t>As a consequence of this configuration, Oblivious HTTP prevents linkability
described above. Informally, this means:</t>
      <ol spacing="normal" type="1"><li>Requests and responses are known only to clients and targets in possession
of the corresponding response encapsulation key and HPKE keying material.
In particular, the oblivious proxy knows the origin and destination of an
encapsulated request and response, yet does not know the decapsulated
contents. Likewise, targets know only the oblivious request origin, i.e.,
the proxy, and the decapsulated request. Only the client knows both the
plaintext request and response.</li>
        <li>Targets cannot link requests from the same client in the absence of unique
per-client keys.</li>
      </ol>
      <t>Traffic analysis that might affect these properties are outside the scope of this
document; see <xref target="ta" format="default"/>.</t>
      <t>A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS" format="default"/>.</t>
      <section anchor="client-responsibilities" numbered="true" toc="default">
        <name>Client Responsibilities</name>
        <t>Clients MUST ensure that the key configuration they select for generating
encapsulated requests is integrity protected and authenticated so that it can
be attributed to the oblivious request resource; see <xref target="key-configuration" format="default"/>.</t>
        <t>Since clients connect directly to the proxy instead of the target, application
configurations wherein clients make policy decisions about target connections,
e.g., to apply certificate pinning, are incompatible with Oblivious HTTP.  In
such cases, alternative technologies such as HTTP CONNECT
(<xref section="9.3.6" sectionFormat="of" target="HTTP" format="default"/>) can be used. Applications could implement related
policies on key configurations and proxy connections, though these might not
provide the same properties as policies enforced directly on target
connections. When this difference is relevant, applications can instead connect
directly to the target at the cost of either privacy or performance.</t>
        <t>Clients MUST NOT include identifying information in the request that is
encapsulated. Identifying information includes cookies <xref target="COOKIES" format="default"/>,
authentication credentials or tokens, and any information that might reveal
client-specific information such as account credentials.</t>
        <t>Clients cannot carry connection-level state between requests as they only
establish direct connections to the proxy responsible for the oblivious proxy
resource. However, clients need to ensure that they construct requests without
any information gained from previous requests. Otherwise, the server might be
able to use that information to link requests. Cookies <xref target="COOKIES" format="default"/> are
the most obvious feature that MUST NOT be used by clients. However, clients
need to include all information learned from requests, which could include the
identity of resources.</t>
        <t>Clients MUST generate a new HPKE context for every request, using a good source
of entropy (<xref target="RANDOM" format="default"/>) for generating keys. Key reuse not only risks
requests being linked, reuse could expose request and response contents to the
proxy.</t>
        <t>The request the client sends to the oblivious proxy resource only requires
minimal information; see <xref target="http-usage" format="default"/>. The request that carries the
encapsulated request and is sent to the oblivious proxy resource MUST NOT
include identifying information unless the client ensures that this information
is removed by the proxy. A client MAY include information only for the
oblivious proxy resource in header fields identified by the Connection header
field if it trusts the proxy to remove these as required by Section 7.6.1 of
<xref target="HTTP" format="default"/>. The client needs to trust that the proxy does not replicate the
source addressing information in the request it forwards.</t>
        <t>Clients rely on the oblivious proxy resource to forward encapsulated requests
and responses. However, the proxy can only refuse to forward messages, it
cannot inspect or modify the contents of encapsulated requests or responses.</t>
      </section>
      <section anchor="proxy-responsibilities" numbered="true" toc="default">
        <name>Proxy Responsibilities</name>
        <t>The proxy that serves the oblivious proxy resource has a very simple function
to perform. For each request it receives, it makes a request of the oblivious
request resource that includes the same content. When it receives a response,
it sends a response to the client that includes the content of the response
from the oblivious request resource. When generating a request, the proxy MUST
follow the forwarding rules in <xref section="7.6" sectionFormat="of" target="HTTP" format="default"/>.</t>
        <t>A proxy can also generate responses, though it assumed to not be able to
examine the content of a request (other than to observe the choice of key
identifier, KDF, and AEAD), so it is also assumed that it cannot generate an
encapsulated response.</t>
        <t>A proxy MUST NOT add information about the client identity when forwarding
requests. This includes the Via field, the Forwarded field
<xref target="FORWARDED" format="default"/>, and any similar information.  A client does not depend
on the proxy using an authenticated and encrypted connection to the oblivious request
resource, only that information about the client not be attached to forwarded
requests.</t>
        <section anchor="dos" numbered="true" toc="default">
          <name>Denial of Service</name>
          <t>As there are privacy benefits from having a large rate of requests forwarded by
the same proxy (see <xref target="ta" format="default"/>), servers that operate the oblivious request
resource might need an arrangement with proxies. This arrangement might be
necessary to prevent having the large volume of requests being classified as an
attack by the server.</t>
          <t>If a server accepts a larger volume of requests from a proxy, it needs to
trust that the proxy does not allow abusive levels of request volumes from
clients. That is, if a server allows requests from the proxy to be exempt from
rate limits, the server might want to ensure that the proxy applies a rate
limiting policy that is acceptable to the server.</t>
          <t>Servers that enter into an agreement with a proxy that enables a higher request
rate might choose to authenticate the proxy to enable the higher rate.</t>
        </section>
        <section anchor="ta" numbered="true" toc="default">
          <name>Linkability Through Traffic Analysis</name>
          <t>As the time at which encapsulated request or response messages are sent can
reveal information to a network observer. Though messages exchanged between the
oblivious proxy resource and the oblivious request resource might be sent in a
single connection, traffic analysis could be used to match messages that are
forwarded by the proxy.</t>
          <t>A proxy could, as part of its function, add delays in order to increase the
anonymity set into which each message is attributed. This could latency to the
overall time clients take to receive a response, which might not be what some
clients want.</t>
          <t>A proxy can use padding to reduce the effectiveness of traffic analysis.</t>
          <t>A proxy that forwards large volumes of exchanges can provide better privacy by
providing larger sets of messages that need to be matched.</t>
        </section>
      </section>
      <section anchor="server-responsibilities" numbered="true" toc="default">
        <name>Server Responsibilities</name>
        <t>A server that operates both oblivious request and oblivious target resources is
responsible for removing request encapsulation, generating a response the
encapsulated request, and encapsulating the response.</t>
        <t>Servers should account for traffic analysis based on response size or generation time.
Techniques such as padding or timing delays can help protect against such attacks;
see <xref target="ta" format="default"/>.</t>
        <t>If separate entities provide the oblivious request resource and oblivious
target resource, these entities might need an arrangement similar to that
between server and proxy for managing denial of service; see <xref target="dos" format="default"/>. It is
also necessary to provide confidentiality protection for the unprotected
requests and responses, plus protections for traffic analysis; see <xref target="ta" format="default"/>.</t>
        <t>An oblivious request resource needs to have a plan for replacing keys. This
might include regular replacement of keys, which can be assigned new key
identifiers. If an oblivious request resource receives a request that contains
a key identifier that it does not understand or that corresponds to a key that
has been replaced, the server can respond with an HTTP 422 (Unprocessable
Content) status code.</t>
        <t>A server can also use a 422 status code if the server has a key that
corresponds to the key identifier, but the encapsulated request cannot be
successfully decrypted using the key.</t>
      </section>
      <section anchor="replay-attacks" numbered="true" toc="default">
        <name>Replay Attacks</name>
        <t>Encapsulated requests can be copied and replayed by the oblivious proxy
resource. The design of oblivious HTTP does not assume that the oblivious proxy
resource will not replay requests. In addition, if a client sends an
encapsulated request in TLS early data (see <xref section="8" sectionFormat="of" target="TLS" format="default"/> and
<xref target="RFC8470" format="default"/>), a network-based adversary might be able to cause the request to
be replayed. In both cases, the effect of a replay attack and the mitigations
that might be employed are similar to TLS early data.</t>
        <t>A client or oblivious proxy resource MUST NOT automatically attempt to retry a
failed request unless it receives a positive signal indicating that the request
was not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (Section
8.1.4 of <xref target="RFC7540" format="default"/>), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1
of <xref target="QUIC-HTTP" format="default"/>), or a GOAWAY frame with a low enough
identifier (in either protocol version) are all sufficient signals that no
processing occurred. Connection failures or interruptions are not sufficient
signals that no processing occurred.</t>
        <t>The anti-replay mechanisms described in <xref section="8" sectionFormat="of" target="TLS" format="default"/> are generally
applicable to oblivious HTTP requests. Servers can use the encapsulated keying
material as a unique key for identifying potential replays. This depends on
clients generating a new HPKE context for every request.</t>
        <t>The mechanism used in TLS for managing differences in client and server clocks
cannot be used as it depends on being able to observe previous interactions.
Oblivious HTTP explicitly prevents such linkability.
Applications can still include an explicit indication of time to limit the span
of time over which a server might need to track accepted requests. Clock
information could be used for client identification, so reduction in precision
or obfuscation might be necessary.</t>
        <t>The considerations in <xref target="RFC8470" format="default"/> as they relate to managing the risk of
replay also apply, though there is no option to delay the processing of a
request.</t>
        <t>Limiting requests to those with safe methods might not be satisfactory for some
applications, particularly those that involve the submission of data to a
server. The use of idempotent methods might be of some use in managing replay
risk, though it is important to recognize that different idempotent requests
can be combined to be not idempotent.</t>
        <t>Idempotent actions with a narrow scope based on the value of a protected nonce
could enable data submission with limited replay exposure. A nonce might be
added as an explicit part of a request, or, if the oblivious request and target
resources are co-located, the encapsulated keying material can be used to
produce a nonce.</t>
        <t>The server-chosen <tt>response_nonce</tt> field ensures that responses have unique
AEAD keys and nonces even when requests are replayed.</t>
      </section>
      <section anchor="post-compromise-security" numbered="true" toc="default">
        <name>Post-Compromise Security</name>
        <t>This design does not provide post-compromise security for responses. A client
only needs to retain keying material that might be used compromise the
confidentiality and integrity of a response until that response is consumed, so
there is negligible risk associated with a client compromise.</t>
        <t>A server retains a secret key that might be used to remove protection from messages
over much longer periods. A server compromise that provided access to the
oblivious request resource secret key could allow an attacker to recover the
plaintext of all requests sent toward affected keys and all of the responses
that were generated. Accessing requests and responses also requires access to
requests and responses, which implies either compromise of TLS connections or
collusion with the oblivious proxy resource.</t>
        <t>The total number of affected messages affected by server key compromise can be
limited by regular rotation of server keys.</t>
      </section>
    </section>
    <section anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>One goal of this design is that independent client requests are only linkable
by the chosen key configuration. The oblivious proxy and request resources can link
requests using the same key configuration by matching KeyConfig.key_id, or, if
the oblivious target resource is willing to use trial decryption, a limited set
of key configurations that share an identifier. An oblivious proxy can link
requests using the public key corresponding to KeyConfig.key_id.</t>
      <t>Request resources are capable of linking requests depending on how KeyConfigs
are produced by servers and discovered by clients. Specifically, servers can
maliciously construct key configurations to track individual clients. A specific
method for a client to acquire key configurations is not included in this
specification. Clients need to consider these tracking vectors when choosing a
discovery method.  Applications using this design should provide accommodations
to mitigate tracking use key configurations.</t>
    </section>
    <section anchor="deployment" numbered="true" toc="default">
      <name>Operational and Deployment Considerations</name>
      <t>Using Oblivious HTTP adds both cryptographic and latency to requests relative to
a simple HTTP request-response exchange.  Deploying proxy services that are on
path between clients and servers avoids adding significant additional delay due
to network topology.  A study of a similar system <xref target="ODoH" format="default"/> found that deploying
proxies close to servers was most effective in minimizing additional latency.</t>
      <t>Oblivious HTTP might be incompatible with network interception regimes, such as
those that rely on configuring clients with trust anchors and intercepting TLS
connections.  While TLS might be intercepted successfully, interception
middleboxes devices might not receive updates that would allow Oblivious HTTP to
be correctly identified using the media types defined in <xref target="media-types" format="default"/>.</t>
      <t>Oblivious HTTP has a simple key management design that is not trivially altered
to enable interception by intermediaries.  Clients that are configured to enable
interception might choose to disable Oblivious HTTP in order to ensure that
content is accessible to middleboxes.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Please update the "Media Types" registry at
<eref target="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</eref> with the registration
information in <xref target="media-types" format="default"/> for the media types "message/ohttp-req",
"message/ohttp-res", and "application/ohttp-keys".</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="BINARY">
          <front>
            <title>Binary Representation of HTTP Messages</title>
            <author initials="M." surname="Thomson" fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <date year="2021" month="August" day="24"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-thomson-http-binary-message-00"/>
        </reference>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="Roy T. Fielding">
              <organization>Adobe</organization>
            </author>
            <author fullname="Mark Nottingham">
              <organization>Fastly</organization>
            </author>
            <author fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization>
            </author>
            <date day="18" month="August" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document describes the overall architecture of HTTP,
   establishes common terminology, and defines aspects of the protocol
   that are shared by all versions.  In this definition are core
   protocol elements, extensibility mechanisms, and the "http" and
   "https" Uniform Resource Identifier (URI) schemes.

   This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
   7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
   of RFC 7230.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-18"/>
        </reference>
        <reference anchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="HPKE">
          <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="Richard L. Barnes">
              <organization>Cisco</organization>
            </author>
            <author fullname="Karthik Bhargavan">
              <organization>Inria</organization>
            </author>
            <author fullname="Benjamin Lipp">
              <organization>Inria</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="2" month="August" year="2021"/>
            <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 which
   authenticates possession of a pre-shared key, and two optional ones
   which authenticate possession of a KEM private key.  HPKE works for
   any combination of an asymmetric key encapsulation mechanism (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 key agreement, HKDF, and SHA2.

   This document is a product of the Crypto Forum Research Group (CFRG)
   in the IRTF.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-hpke-11"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </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">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8470">
          <front>
            <title>Using Early Data in HTTP</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="W. Tarreau" initials="W." surname="Tarreau">
              <organization/>
            </author>
            <date month="September" year="2018"/>
            <abstract>
              <t>Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8470"/>
          <seriesInfo name="DOI" value="10.17487/RFC8470"/>
        </reference>
        <reference anchor="RFC7540">
          <front>
            <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
            <author fullname="M. Belshe" initials="M." surname="Belshe">
              <organization/>
            </author>
            <author fullname="R. Peon" initials="R." surname="Peon">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2015"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t>
              <t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7540"/>
          <seriesInfo name="DOI" value="10.17487/RFC7540"/>
        </reference>
        <reference anchor="QUIC-HTTP">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <author fullname="Mike Bishop">
              <organization>Akamai</organization>
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>   The QUIC transport protocol has several features that are desirable
   in a transport for HTTP, such as stream multiplexing, per-stream flow
   control, and low-latency connection establishment.  This document
   describes a mapping of HTTP semantics over QUIC.  This document also
   identifies HTTP/2 features that are subsumed by QUIC, and describes
   how HTTP/2 extensions can be ported to HTTP/3.

DO NOT DEPLOY THIS VERSION OF HTTP

   DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-http.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="Dingledine2004" target="https://svn.torproject.org/svn/projects/design-paper/tor-design.html">
          <front>
            <title>Tor: The Second-Generation Onion Router</title>
            <author initials="R." surname="Dingledine">
              <organization/>
            </author>
            <author initials="N." surname="Mathewson">
              <organization/>
            </author>
            <author initials="P." surname="Syverson">
              <organization/>
            </author>
            <date year="2004" month="August"/>
          </front>
        </reference>
        <reference anchor="PRIO" target="https://crypto.stanford.edu/prio/paper.pdf">
          <front>
            <title>Prio: Private, Robust, and Scalable Computation of Aggregate Statistics</title>
            <author initials="H." surname="Corrigan-Gibbs">
              <organization/>
            </author>
            <author initials="D." surname="Boneh">
              <organization/>
            </author>
            <date year="2017" month="March" day="14"/>
          </front>
        </reference>
        <reference anchor="ODoH" target="https://www.petsymposium.org/2021/files/papers/issue4/popets-2021-0085.pdf">
          <front>
            <title>Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancement to DNS</title>
            <author fullname="Sudheesh Singanamalla">
              <organization/>
            </author>
            <author fullname="Suphanat Chunhapanya">
              <organization/>
            </author>
            <author fullname="Marek Vavrusa">
              <organization/>
            </author>
            <author fullname="Tanya Verma">
              <organization/>
            </author>
            <author fullname="Peter Wu">
              <organization/>
            </author>
            <author fullname="Marwan Fayed">
              <organization/>
            </author>
            <author fullname="Kurtis Heimerl">
              <organization/>
            </author>
            <author fullname="Nick Sullivan">
              <organization/>
            </author>
            <author fullname="Christopher A. Wood">
              <organization/>
            </author>
            <date year="2021" month="January" day="07"/>
          </front>
        </reference>
        <reference anchor="OHTTP-ANALYSIS" target="https://github.com/cloudflare/ohttp-analysis">
          <front>
            <title>Tamarin Model of Oblivious HTTP</title>
            <author fullname="Jonathan Hoyland">
              <organization/>
            </author>
            <date year="2021" month="August" day="23"/>
          </front>
        </reference>
        <reference anchor="RFC6265">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth">
              <organization/>
            </author>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
        <reference anchor="RFC7838">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." surname="Reschke">
              <organization/>
            </author>
            <date month="April" year="2016"/>
            <abstract>
              <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7838"/>
          <seriesInfo name="DOI" value="10.17487/RFC7838"/>
        </reference>
        <reference anchor="ALT-SVC">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." surname="Reschke">
              <organization/>
            </author>
            <date month="April" year="2016"/>
            <abstract>
              <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7838"/>
          <seriesInfo name="DOI" value="10.17487/RFC7838"/>
        </reference>
        <reference anchor="COOKIES">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth">
              <organization/>
            </author>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
        <reference anchor="RANDOM">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <author fullname="J. Schiller" initials="J." surname="Schiller">
              <organization/>
            </author>
            <author fullname="S. Crocker" initials="S." surname="Crocker">
              <organization/>
            </author>
            <date month="June" year="2005"/>
            <abstract>
              <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.  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="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="FORWARDED">
          <front>
            <title>Forwarded HTTP Extension</title>
            <author fullname="A. Petersson" initials="A." surname="Petersson">
              <organization/>
            </author>
            <author fullname="M. Nilsson" initials="M." surname="Nilsson">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface.  In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.</t>
              <t>This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7239"/>
          <seriesInfo name="DOI" value="10.17487/RFC7239"/>
        </reference>
        <reference anchor="X25519">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley">
              <organization/>
            </author>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." surname="Turner">
              <organization/>
            </author>
            <date month="January" year="2016"/>
            <abstract>
              <t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
        <reference anchor="ODOH">
          <front>
            <title>Oblivious DNS Over HTTPS</title>
            <author fullname="Eric Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Patrick McManus">
              <organization>Fastly</organization>
            </author>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Tanya Verma">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="8" month="March" year="2021"/>
            <abstract>
              <t>   This document describes an extension to DNS Over HTTPS (DoH) that
   allows hiding client IP addresses via proxying encrypted DNS
   transactions.  This improves privacy of DNS operations by not
   allowing any one server entity to be aware of both the client IP
   address and the content of DNS queries and answers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-pauly-dprive-oblivious-doh-06"/>
        </reference>
      </references>
    </references>
    <section anchor="complete-example-of-a-request-and-response" numbered="true" toc="default">
      <name>Complete Example of a Request and Response</name>
      <!-- Generated using ohttp:
RUST_LOG=ohttp cargo test -p ohttp -\-lib -\- -\-nocapture request_response
-->

<t>A single request and response exchange is shown here. Binary values (key
configuration, secret keys, the content of messages, and intermediate values)
are shown in hexadecimal. The request and response here are absolutely minimal;
the purpose of this example is to show the cryptographic operations.</t>
      <t>The oblivious request resource generates a key pair. In this example the server
chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 key pair
<xref target="X25519" format="default"/>. The X25519 secret key is:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
cb14d538a70d8a74d47fb7e3ac5052a086da127c678d3585dcad72f98e3bff83
]]></artwork>
      <t>The oblivious request resource constructs a key configuration that includes the
corresponding public key as follows:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
01002012a45279412ea6ef11e9f839bb5a422fc1262b5c023d787e4e636e70ae
d3d56e00080001000100010003
]]></artwork>
      <t>This key configuration is somehow obtained by the client. Then when a client
wishes to send an HTTP request of a GET request to <tt>https://example.com</tt>, it
constructs the following binary HTTP message:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
00034745540568747470730b6578616d706c652e636f6d012f
]]></artwork>
      <t>The client then reads the oblivious request resource key configuration and
selects a mutually supported KDF and AEAD. In this example, the client selects
HKDF-SHA256 and AES-128-GCM. The client then generates an HPKE context that
uses the server public key. This results in the following encapsulated key:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b
]]></artwork>
      <t>The corresponding private key is:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
c20afd33a2f2663faf023acf5d56fc08fddd38aada29b21b3b96e16f4326ccf7
]]></artwork>
      <t>Applying the Seal operation from the HPKE context produces an encrypted
message, allowing the client to construct the following encapsulated request:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
01002000010001cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674
db72730623ca3b68b9e75a0576745da12c4fa5053b7ec06d7f625197564a6087
ec299f8d6fffa2a8addfc1c0f64b4b05
]]></artwork>
      <t>The client then sends this to the oblivious proxy resource in a POST request,
which might look like the following HTTP/1.1 request:</t>
      <sourcecode type="http-message"><![CDATA[
POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org
Content-Type: message/ohttp-req
Content-Length: 78

<content is the encapsulated request above>
]]></sourcecode>
      <t>The oblivious proxy resource receives this request and forwards it to the
oblivious request resource, which might look like:</t>
      <sourcecode type="http-message"><![CDATA[
POST /oblivious/request HTTP/1.1
Host: example.com
Content-Type: message/ohttp-req
Content-Length: 78

<content is the encapsulated request above>
]]></sourcecode>
      <t>The oblivous request resource receives this request, selects the key it
generated previously using the key identifier from the message, and decrypts
the message. As this request is directed to the same server, the oblivious
request resource does not need to initiate an HTTP request to the oblivious
target resource. The request can be served directly by the oblivious target
resource, which generates a minimal response (consisting of just a 200 status
code) as follows:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
0140c8
]]></artwork>
      <t>The response is constructed by extracting a secret from the HPKE context:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
9c0b96b577b9fc7a5beef536e0ff3a64
]]></artwork>
      <t>The key derivation for the encapsulated response uses both the encapsulated KEM
key from the request and a randomly selected nonce. This produces a salt of:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b
061d62d5df5832c6c9fa4617ceb848a7
]]></artwork>
      <t>The salt and secret are both passed to the Extract function of the selected KDF
(HKDF-SHA256) to produce a pseudorandom key of:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
a0ab55d3b1811694943bb72c386f59bd030e1278692a3db2f30d8aac2f89a5fc
]]></artwork>
      <t>The pseudorandom key is used with the Expand function of the KDF and an info
field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
1dae9d7fe263d23e51a768bcaf310aa5
]]></artwork>
      <t>With the same KDF and pseudorandom key, an info field of "nonce" is used to
generate a 12-byte nonce:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
e520beec147740e4f8a3b553
]]></artwork>
      <t>The AEAD Seal function is then used to encrypt the response, which is added
to the randomized nonce value to produce the encapsulated response:</t>
      <artwork type="hex-dump" name="" align="left" alt=""><![CDATA[
061d62d5df5832c6c9fa4617ceb848a7a6f694da45accc3c32ad576cb204f7cd
3bf23e
]]></artwork>
      <t>The oblivious request resource then constructs a response:</t>
      <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store
Content-Type: message/ohttp-res
Content-Length: 38

<content is the encapsulated response>
]]></sourcecode>
      <t>The same response might then be generated by the oblivious proxy resource which
might change as little as the Date header. The client is then able to use the
HPKE context it created and the nonce from the encapsulated response to
construct the AEAD key and nonce and decrypt the response.</t>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>This design is based on a design for oblivious DoH, described in
<xref target="ODOH" format="default"/>. David Benjamin and Eric Rescorla made
technical contributions.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJ4/JGEAA+192XbbWJLgO74CrXwYqZqkKWp3LtVKSZl2ZdpyS3Ll1Onu
SYHApYQSCLABULJK5fqW/pb5son1LiAopU/1zLyUTzotkcBd4sYecSOGw2HU
5m1hXscb59Miv8+rZRO/ubr6sBFlVVomc/gmq5NZO2xvq3lTlcPbtl0MK312
OJ5EadKam6p+fB03bRbli/p13NbLpp2Mx0fwdVKb5HV8fHEVPVT13U1dLRev
aYrv315GUdMmZfZrUlQlzPRommiRv47/ra3SQdxUdVubWQM/Pc75B1jTPFks
8vLmP6IoWcKa6tdRHA/hbxznZfM6fjeKr3il9Bnv4F1St3kZfFHVN/B59Ze8
KBL6wMyTvHgdz9t/KaoHU7Z1tXgclaYNhz8ZHY/iX6oq80Y/ua3zpq0Wt6aO
/W9pipOiWmazAoDgz5ImD/9yaxLcyDRvG5onKqt6nrT5vXkdwbPfv31/fPGn
1/SWHtH3eZnUj/GFWdSmgTXC01UZVzMCZ/zONE1yY5oNeieDU3kdT8aT7eH4
cDjZpQ8bU+emyctZxQPH8duyNTVMPzzFU+497CnNOpzz8MPxmF510Mc/Q/nX
noIP62cPYuUw4FPczuv47fB0lJt2RquY5s2wAeiVbZ428Mi/fnx78jq++OHk
aEwLuvr5kn493N3djyLcoQ/MUwB0YbK8NICUuyFQr2AXsCITX5q0KrPhj6Y0
NUP2vMT/X1RLgFEI1fEuQJWHSeobA4DbwFU2r1+9au7LUVvVi7r6s0nbEewN
P3olvzevMjiAm3K4SBamfgUPDvmD0W07Lzb6QMsgvRh5uwi/ej8CwLa35sHB
VL75MIovH+9NjV/ANx8u3p6Hm/9Q5xU8Vuf3sLEBbHUKhDuIgSbjyzQpkmlh
4pNqvlg6XDu+uanNDTweX+KHDR5ICJztg+F4Z7i92w+ftH5ctNUICR8OKRuZ
bAnAyatXBJHRIps9A4U3I1hOXec3STn8MZ9Om/Dr01H8PXCSW9zs+Wn1Jtys
43Cn7y/jCuBCmHYZb+KzW8CkABJJChtKCoZJ+hiflbdJmZo5kFvcVvjmKn3B
fwfBZnWvDw8Po4VpgX8tqiZfzgkb8J1Xs7wwDW+5eZU3zdLsvlpU+OyQxxwf
7iEsekExWxYFE9TlMrs1prmNLwE3EvgsUX7WfW4B20haYFZL2NAiKR/7HgP6
NHfxH5N74N9931/he/EfDdBWz7cfDNBJ/Muyf+CHpIx/SB5N1vP1T0vgCyB4
TD43ddHzwPs8vYNNFHCASdnzfR8PRhzA8x0evz/++U+Xby87dA/AqoEZvasy
UyBidwVgDxfd6T3lm7y9XU5HaTV/lVp2/6oi5glALx6bvHnhHP9QweHACcVv
qscCqC+KouFwGCfTpkWMjKKrW4APiL8lISKwjLTOp6aJExCOTWvmMdBSDDwA
/31IamASN7gnUxK5mYxFhPDwZsTjAbJUDzhGWuSC3/PkzsTzZdHmCyD92vzn
0jRtg0MlKD2QZh5gu8ASaTb5aGpwPuQWEYxR5OUdfFs13gDwMT4vE+FaqzjP
4Od89kjf2CeTJr5N7nE8AKiJZnU156kAUPL+SMAzz7MMpoy+QjFWV9kyRSaF
wDIxQA1XDfuhpen48bLB3wkatbk3SdHEVloAg0umujWeKuJFto+4YAUB6RjL
m1t+rgIRWtJkdg/z/Oa2lfH94QcRHHIb5+GcyzIztR2rrggb3RJGsDuExQLQ
FRj5gKFRLevUREmWgSoA51Pq+6UhIPRujia3p32b4HvFI5zXPAcUiezsuMUo
Ors3ZfwAFAXALOO3H2KdDJZfVoCEeQ1zwftJ2wIyLhHLEEglzJkBJWXLpODF
LhsTIQaVdghivm2OJwqfTukRejsF7m4KlC4KTBBhBHTADFwJSqS2iuB5GLoD
SJy9AS0BnwF5SzwWYSkbnhpErKoexIRUD7d5Skf4GOEiCPNhNNgv8PvGw4SF
qZAY8vK+Ku5NNiJtARcAQyP/Bs6DmOKA3zxDSfkcVnYP48ObtHKYbBAD9HDF
ADRQgRvZLxIaQizHMQGRUlO3SV4CLrq1WfS020SQIKbCoQIfimZJcwuvw3l+
5BUjk0Hsh+k+PRL4ZWJ4KTMg23lfddUKJiU3MClQjiwr0iNCOvIOidhQA8gE
277P6xZOH0YhxSIGBROV/yYWJgU6l34WPT2F2tnnzwO7oqpFhl4tGKjI4mSP
IyRyS4KITaBOZwjcChFpSjwF9js3wIeyJr5PUPEdCJHAZnAsk8D5yw4iQCVU
w/IZSH+kuQ9IQKW/SeJryTQvENz4GeB/wzQVjISYkRDBFiAQgT5K84D6qU+d
wg6VnRwjWc7zMp8v58gjYDF2AqYaxQEwn0A3A3pbhGPQoctj/E3SRjKGwkNX
SAzFf1j47S1wrRhpr0wfCVRIb2C4eHCB2VBJRisEwQgQncIZ4eQg+ueNMq5y
OZ/iwc38pU8fW0Bu8ykFOXcDi0IlEx8++fCRzwRRmJTDmzpZAHESDEXz5BNf
JwP5mEXgJYtmWTBDwFNm8yWUf4B0bF99/qwC4XFa51n8YQlKQBr/ZFDxo8Xg
MJtvPvx09jW89E/4w7dkmNRgmKSz+mZ4u7gznz9vIVeA5QndNF3RQGByMg4k
PJztAvZFJ5zBupGzNUSDi6J6pC0mdXqb43DL2jCiIbk2BiQBUpVP/8RfdQIA
vRWbeuYewSCqp7eg0nawWPkOrge5A1BMbD4tACA5svlmuViASR7nraAoGy4w
iJijuHqPqymro60Qw1dCptnkyfjPYHFEoLRbMgNkInpy5AIKHbJCkVPsXYgX
RZLCLzlLPuZmm40xcEyApMsagALHMrBckaQHKNpID7QAdxrwDQq0ZZnDJ12B
BnsF9QoQCcmfhRSzJcv7UAE5qUpiF7g9hN+pmQE50++sj9wBSgG/A1608e7j
5dXGgP+N35/TzxdnYNFenJ3iz5dvjn/+2f4QyROXb84//nzqfnJvnpy/e3f2
/pRfhk/j4KNo493xnzbYpts4/3D19hzU4Q2Gm09PCAXY2xQFHWAQnCnuP2ki
JTSC9fcnH/73f23vxkALYG1PtrePgIT4l8PtA2DeqDGUPBspF/wrSdlksTAJ
c6oCpFmyyFvQUAao8TW31UMZI8dB3e7MEjFMesFgBjseDLRSNTdGFdWmjP8C
jg/PAaUOnforlP91jBgSw4pliM+fRyvzMV12JuQP/74ZeQya0hkbHwhzYVbS
6HRWOoM5CEXkXTSpKPZNwEVix0WmIE8NaGwW3+FbtNIakq6xddlZ4NUyZbAa
gXZnPfZZx4VA9zP5PamGASxk9AFwDjJdfEaI8gFW5FPfQPcFbEW0R7dSNrTs
5AM3qd33AMbz5tex5UucHJcKDLQMvwo2fcXzBHu+It7p7zpnpi6LYk2qb+uj
mEWBvg0rLKobdCoAOYDsy0grRdqozQ28Wgc43T1W/K2pxKKY4mDAc6s6YbHS
Ok20CsxXhGVNbDRvrehE3x5gVlosM1RAG7ME6gfzl/e3bAzvcLYsU8fJUo+z
ZcjVwFIAhBdhqPRTkcWZMOLemFrNJdgTigKUgCj+kVRE8aMPgK+i7cPChLlM
xALZX0h8bXAGswmc5H7reiBWyXV5rYfiFA6eBhd+fY9fRyQlZVH3SbE0rL+7
sQtTbm5dC5bwcPDRDQgcsXrtHiIaHDb8A5kcLDkce+SFgyQR5QNF8NPTpah8
26MdHBAdlwQ0EBrnIBTvc/MQRcdqoxTAIWURswrNcxgS8PF3tGZf2Q8IZYWk
BQUZa+TEAY3mhD8r5u5aihNRTTp2dzIYydKHqAYIGl5pZsBSKRq1NwBR4gWr
VigH1w/qhkzS1CxAwaQF4/oVv9hpkKOOQ9YEDIVjqjZJcyXFTQUKwO1cNsDu
d7IxyajSt0YvQpb1ipARPOQgvpRt+RyAQNJLxaKrP8uEr7rmrLhnPL+JmpXO
ndFdLx9gZBfsnDWJB1xR+IkJJVavUtsmMMOtIYGzCfDset5+QMUoVIfc6cpD
jIS0bjVMxO6Jor/97W/RPw/1zz9LPMB9svYj//for/EJTxX/VR7/q4jV2P9I
ZRt/9Fdl+/BjpA+Fjwu01n3k//7fsItgevdn9ZOVj/6q7waKzBe+a6Hz5fMO
O3++W13J+nlXJ+mu5Ave7a4ElxIO98y8Lw333Re9+5vXvPZd1URfejeA9V+/
CRf9G+Z18zyz5mcnwXle2O/aSXoWp++uzPJ/B87eu8iPnl7HX83ym2El0pkj
Bt9uqLTuiRV8jqK3pegyqzz6RbU2kPYx2O+LJqpSsGE924hULn9Znz+DXrDN
yoxwWlDVGjCOUxI/oaWEsvK5RQAvngRjscbF0icYibyLPU4VlcAUnvGkoggE
fUrcLSSlRWSDjE3RKSwKk2+Z7QRrakyZoZPhwzkYzh50Q9HaEdkqszrLsuo6
grjjrPEXDIvY5UWsncFaZtZx17supzf5UN/rDr6iCYnR0xme9Ys5upJxRKv6
eI5b9FRM0WPcxQaYdv/FaRGJV/GILSE1IZw9hGv4ePF2IK44MOtyU2TNQE0I
B1rP0QO7SNkBBSs66K6og6EwUvOA7ikCQ7AodpTzSgW8auQdvrjPDqqajsHv
6FJwSLGVCNLZ9GyoEYJKXMJzGlTBvtU3h6OtQypY+tEXol04mY2UbY8DGhKc
oWdCZ6lDF15sOB7o0zdA9BycdXgUffVVfLxAH6Foj75dTZDEMJPVMP0nwUh5
l5SPbHdqEsvUlGBjCoworBhJyCdOkxpYTtOiVqrODlU6B2CCgK2bSNAkrao7
9F5uPj39/uKHk/3J/h76AillCBX9lHe86Vln27oEchpidADDX0mB6TGUSELu
0RyOPpJRDw53Dsnx25EG6PC5I5V/wTEEcbmi7xTmoCjCjRlw/El99GqoMIDY
2kaf5HObHq3AmhzQOca1C4LrbFmIrbyQdIY6b+4wxtpUaU5ckOC1qJomx+gt
TYRvtbVJ2nk3ron2brOczfIUcYlCGzcMHKf0syc/Yjc20434xau0KjTeh15f
tOKyVfBRJAaDJzXRVAHEFuGoBRmOZTyvYBU1ZapI8BuOn8JOmM2Ch4p5LnAy
eIpXVY3n1Q0xbQn4g/gXyM6qRDfBzTJBB4tB/tdSWISc15IWhJG4ah34aXH+
ahOJk3aiPy6UHF9WcyPRlIi2waFzDTcqRtu3G9MuFwMFZAIztvlfTMZBRC9q
A7hXw1ofkkfiRrzfqn/F5tPClI0cpLfo2jpffxefJcH7jpFqoIq8FygjHqp+
15YCPckyFFoSahrZwa1goLgDHD77VhvY3kowlAYWIcM+QInWDNlwRQdsm2RJ
m7AMOj47PuVRGw6H/i4+NUAUlGgQRJ3uzKN4T4EYBYMlwcITvpETM4HMJalZ
wjKANApgmci8vDgWhvDUuYKes08JYjrxPyVUG3ckTxRwC8nl6GQXMAVpoJPw
JxLBTMeFOU7wAsY9Acm830CyZ4ZxsMZACR07Lqq4JzO+m7QAO3XxZhthGsQL
TOZL8ZQB1/PZSnxEJycfiykMnAeysuV0njd0BrFKDi8qRF8jUpE/yU2c18DP
UH9sK/Ig4wcZLLVAslSQkCc0RHA8NfR7xe3jgsE8B7UWw2fFIzrHEeuJgSGm
sFcOg38nVQm69lLyAJ++ApwYpv5nnz2fXWlMRvxetJk1CSXopQrGEH0oekY5
yT2rApWLXg0WQeybH7AnFzCUaEBWkTjxXeUaDOUH+czICwaHRhkRFINAL9xg
zfopgIU8yIlVieveJvfidcU4XOQI5JkwLs6x4QlAyaBCctyIKRRCh8gBlacn
9y1YCurvtE9Zhzl5/QYc72diY1ZCmX9kXyEec/jUS6XSjRLtAarlTYqGF/66
Agekr/ewwRgMNWS6kWAycjod0+II2mi55vssKtSL84TciT0Apnhc5HJjMKAK
1GOVOZHqBBLQRuVXspwuFyYF9sDJT4yOAgSM1loXe4CqKwhtDcpoTaxDcE1w
KMtnlD6jaBeTGJ9rpnIjMivSTbrwLSV3gaSSKHpSNJULiWcA0zZv+mEPI0QJ
Q5XScGSvI48+GRUIJW0+Ts9ARGIFSj1JDwJT1tOQ/SyykTgcWSMSOUCsnvgN
jcIvALABJLjTO8wzCk5X7AAS9q3zodux8RgClKEkAiHFKFTeJQNi86ezd1vW
sAaEQUOdtwcYjpvODOXk0PwSAok2fzr9gd8KKdkJVRG/Tm1EdhlvolDd0lAy
qHxpLsL1DHSXpcfjenBbcBK1Pd45xeVrm9ST2Qg6Eifm0Mwk6qIufRcLoAwX
fMQxgEaMk1VubqNVPlsnfi6h0tW1CnpJHiR+78IQAzxlG9tAZSNaiVGYGM7F
6cheKASNH1ZQUCNs2YZvHucoLPM0coGMEatI9isX4whXtxIhSWI4XZ5hZWXw
NB4hgOrpiaE79EDymVxPlGO6BjADBC9Dd6BB0kg4jA2IUcLXz5ewdOADn5RX
qeFFQTH4mpjW3/72t7gtmiE/GlWLBMgtfrO4M5yYA7P92/vF3X98HS1BuGzv
01c/mfnbLPwkm3U+OTZJhh9FzM7iJ7xloE/Gd9ns1xy+jb1n4wT+oU8/06eX
CvhjeyThcDjbIYLIG4qWBp/Nvc/sTgQNfoVX9LueSeI0x6zmX5slWNDNN7uj
0eR/be8Pd7/DhVnof+08l91jVPflMeWIwymuUAS6L9FDwCqSXffAQYgx1AOO
Td1NELMHiGJOzabUJjxeUM8eRxIPtOkwShKNR7+SdMTpbHLJQ7WjIJbnKO9R
DaAZZcQFEWmaEvAERTsIFtBiOGkR2TRRvvg0HAasH2sdF3lHnOYKVY2nrzxd
hEG5Vo9xXC/xtRWmHQUHfIkhMtAL0LADkisKoRZh4l3146rrvwx0oYgUh5zc
LCV6ctjmW2VzRjhjQ4lUAASfGWy5UCp8hAKiREmACh3ugPLYMXHC2zloIctp
G3zrYBFFF5qeaI+poWfevzoG03oh5lL3S9iCl3GgspEhwVNgVHPjcJq3G7jX
DfZVb5BzxNRgXWCkNrqUHLG+EXjzLosM1WtYAHkAJEba8xYtm6i7uYVNNaSA
CSToAXYD+R+D0FmxgGxmsztAN/wPdXJDarPHyNct5dgZy56WR99/kxXfAcv5
Jmu/e5fcgDDh/InNZuv1N6/gw2+y7DsYA37O9LlTzPITBb/IQW3GI1VixiwM
XOe6l3/IC/QxtIaM7+emeZekwEer5jbG7G0mDkr9WPfOK9xK9IHuOHEmJV6x
s4nmrD61mIiES50ta7JzugDBEz+m2xnN/4iP+V3YXWPkRgGeP7kjyAilVzDF
7vw9YnGDHFuUrNJ7gk9B7nz8hklOKDFWLwEUht96e3b5I9mlpBqc+VpfFAUB
mFAjJLcqvdPxXDi/hdPvRtFxR8EPRg4c/s4jTuk0DYehjiUmNOTAUTiACn1N
uh1hsOkDenPYtZHUQK01RpQk84b9RGRf0vFJzuBfgAgNpwIby638pHa7YLpH
wivFBaJ0/FBg8jxgod6UJLGtP//ME2/mWwPv083RiH7XtYZP6af81GeaBQHZ
l7+IS1I+nLEeyXsdoomQf2ILwadrTuCjrEKxnz27S6NTK0Efe1Rdiw3kdNTc
JshvAeNq0DU3AS8ws+p6axAviiWfLgrw5+Y7LnvTM0mPDwOVMPLQxfL8wF5o
9Ec2/sd2N+tUnO6TabhFsn/6ppY0kt5V4Qmj7H7rwLp5SGeHCrn/6fY+fwy6
cs/H5D3s+fysA+H4kiF8KRA+/N17AIMdYvjBAlZX6OOORp49yKn21rc71dtw
Cicm479D1blwaYegIEz5rkG1mo0oFgeLWrwTGiKNqCKjKAiQhZ6e337o/em5
/acujA2PHRSFFAj4/V0/9OXJ9eDX8Fcv/PlLPQByUIuhy9OSY1rygvuX6E5J
s8MiHUasMuIHaj+Gh0pEz4YB2QWipQbCAUe6UJfx01dKfCBmxL3g+wJdssK1
/HAt1hvzePZVJKs6I7ma1cD3rUu9f9CxF6/hubenmMJpU8mCnSGXijuGPbwz
x3d0Ks98XjvN4u7imiwSfCkRlwyhpnWJIIDIbunOBmRyeu3Mmc4DsLxrtA3h
GRFEmpyHucZhCkZ/ZjTy3F8VzINQUG2P5L61sYmTRE2f9Oai7OwREYx+l6+v
5RqJrx7EMQGJeDwneJzo8rq+HFhVkmQw8JQOWNR7Nd8FCQBgen44tp5LCDIF
Dm0M7Y3DIQh3m4LLdh7eMgMrFr7AgeS7ZhD7luOAr4H0Zgxzaohc0UFrJSm2
PNQl5KIN4SK6bisBpAKO9mLhyVRFAL9O22tO/zhxBk8XHgw1ArHsP2398+kw
gIhSoYTUfDyAiciHTDYADYciFWYg3WDIugIWxZAQH13CjBPA5pslGiQAJhAB
jQZcxTOxpAsVb0sv2XtgA7KpyZZ1v64E8w8s4n0L4qxdLr5PGnO5Ceg3iDdk
1RtbEewfHmCU2ZQ07e1BTGhCnNf7I19P8Ov5s18jPq3/mjFsaytKW54blzm6
BCTYhOUMlNK2Ig/AbpH0CG8QHiGdTW+YZoYRao2mgcSB8TEHZpVUo/jHnPIF
1mhHXZKX6C8T/Ac4N8Cm4Bmkicpxy1VSc2TWwT0E2ibewGVjrS+bHhHFYM57
7iPGFvsR9D5hY5O5NAFjlvs51nq3k5ye1w1xpRXVQzYwimicUfzWcpA4qwyn
OHi+JORWYJWlt7pmsv+Y7fD+W7tCQQ5N20duW9dVzVNNZSoCVsCW/OlWhYEL
FauzVqZxUFmWmP8t+0NjnZkNA8Atr29hkxeZO45iXWGB9LCMPGRXlosxR/T4
u7P+17F6Ep4eijkmTtxdAYZ+YrH88hrTlzBcytcs8GQ6TAy45alQEWKjbmwN
L/YFmUV9dkwT0ChFqoxnYNIjK8NDFRrN5ePmJaB/OfMjiAiPEl6kPMcyDmAn
TEXe9v9/M8NVdn2xScttOjzb3dFCGHks9HxhSuaPljWu0SvVIEDFUjT8KFIe
GKK2E7SemqmG+rXHFCkIosNF1/oTfKU3U2+4No9Zr1YLOsqbeH0x0K3OPtEV
1kRN4Gv+91powa3UsU307sCPGzroBiKMAgwP5Sq4MMROPh4dfrqeJ58234NG
CnaIu7j0vhSm9P7umi9e2jEI42fOAMDHSrIpuklbPukDZ/nRwiau4SXYDmkp
lHLGqwvWwhSMaURFASNaaP9Kkwk7OZM7fImQkAxMvGhR3117YLqWZ6+dnJG8
KlGaOQyGLNYGrtbviIB6nd/NUUYtlpJNy2VU7PgIXjm/r3kNTVK0+kZu03pV
mWXcZd1qEw+c2JzPvzgI2oUFMbWPjdF9YmZS/zZdLBs3iqkYCkBn0onm/AjY
4B0NIsLQQwMvbtrwxSUZnYZxgMPRurDTClbIVHEidgUmcZFMudLNBny6wbnH
ui1a9Ore/C0IGl4zUILFAzoP9YjD9fM73Q2Ea5QBO6vE8Tboqw3OV1Zt32cM
i8SlMhBk7MpRG+yxXcRy4SmBAc4XoDuLPGQGdL2wKITvOP7EPkmSV43aBgeh
bdDFnN9gEFjW5SGjbG8UexZBd+SXjQNSufrsA5OTD3xlSHQH8ra+XGYKx3Oi
hDntpmObxHaicE54nlnKpseatiIk40CODuLwva0IuA88ITxnE18YCNcFKYyR
W+RR+AAi9CY8PWCs51XQE7qC4BlGOHiqFOuCrQoZkaUtvwkPb7h1qa0hYsgu
Ply3J1fVC/N3mBxXHHDHagzoCiHljJSSrhRkW2IdbhKzfWRtnw/VcQT10sH7
lDhiyQn9UtcKFk/DduLD84zozeLGvk7jrWiJOC2qIP0ixDEPUTDxFc7tWVDx
J2PVvsEqgmJGIV0JV52HdZ21B+spQBxa+Mghg68ogElBHj8HkHLlEnT7WMfW
2sR9drH4Hs/I9DiKNKmtN++KbhiQpz/rucCSRF9yRcZdWOfHKexCrl2JvUSc
pMTZtnFpECWoLoEm5a9YK5o3HNRmwTUBoCO52PHx4q1KiXUrQ40RC/ugQ5E8
qrIgvBbgb5nMRIpZbz49Udx0SMkMlOjda06Fl3/sBVf1XMc2Cevd8Z/sBWoB
AOe6cUJlT7qsV0Ks996Lu6twXLTDjygan55+f/zz1fDyjyff2osFeAkhWqne
hVUSsPxJ8zyKkdMeL3rYySJ/8ahyFpgvZxPwTlx+uQ9woeO18zyL9ivZrFPK
gPMQ3z7iqdsJ1aXxYqqK3np/xdaXwNTUyCZVeViVd6HTez9+JWUi8ogrrRbo
7nX+ZSnF9vyVHK3ogtZ39FxZOdVnvZs0v6D72Nk/MX1JN7+8Zazf0iD8Plp/
Wci725OkaVX7YaJ6KcnoQZWwr6MwZ+tgtO9uy4wo5PncwvJZTCndco0N7/y4
61UrO4tWrkfqtT/JQpuMx+59xxBWaNzqGnBqP/O9itU7WHIegzi8RPXfwgKl
jgysHJeMV2uWTcwaVRIFbE3cdboLn62t5V96hMrAPIAwph4LUbrbF55PSDaC
3C2ovlfeg4WywnWsr26V3Xmo3bvAl9AjJu6BnqEYi8o+JI9+vsJq5YQuemiq
Ui9ubinBlkb4hdiNzAXLcKu5pgrbkjQBQWq2u7/NQbwsC7oNSKmPofOTNA36
KjNcFGxqZnR5CVkzaeJdx4qHokp0PIrNRHvrFgwHYR0xklYfDmiPjfOekJhv
KPn73vghVrpbIuMQwDAHl+Srf83XuxFJKWw0uNYE41RykJKNbCT3lxltbn/6
tOVTgHjt+FJOsOY0KXHFU4ESerDLNi8Ewdq8NpGX5KEcUmwWeyOFhwfNHtO5
A1IjktgejzGvDQhuKQhk7wGOR9sjvAsYPT0JDnlLQjrxdQNh906q+be+g5uy
STinoZXRjr/u4PcKgdAsvueLNdh89sygjIwWNuTEIzyiNGf2lUpJEMuV8cZZ
UuS2cpVkCCOzThq97eGvg67bWrTgDPF499Mn/6AxF5zJgGnA+QHWClGKY/a+
89xNmS5peSkxm66ADBeqXZZaRpRxrKdqoNv3Fs6xLFp7VcFtTobD2neRFloJ
UnFWbtEGarnewwpqs/wWgK3y0BkmfoCmhySNVYUfLSA69wTWA/eZm9fK+Wij
nNSwjteDteQyY9E97GvjUfTO5eeTEqqCxwZleu83hcV0+q4XCE8KCkCuHSC4
cxD13zmI/547B0JAkvgLi/BgIvnBK49sBOm/HQCHfNi3DiPKJJbvBQparUyq
delNdVdVIUzYlaWsTdaFN/+Rq/uPXN1/5Or+9lzdVRbQvMwCmi9gAWrYfCEL
8ApQfikP+Ee+/j94wD94wJfk61uMPQkOHHQii6lktXi1lAfuDu4DYqUrJB9W
/AtUeOAA3Fgib7kWh+aMri/25BeE6UwUOMJUqdUqBH7lVlb4OZbkKlHZQori
ldPUPXJi1EnZkLlYJI9crdPziG3KZgaadeNqDCpy4CBXJ1Rz8OPph5iGksqf
3kBLKbiYYgkTQzVwvfIZWxwtPwb9Pqhb6I/gXxhGHV1rTGNxC7w95Qoa5qWG
PWdLl2y3ehM/19rzWsiqIH9AonWrXf3tjuuy48fb6nqBqRal2BzxSkOE6aPf
DwTh2u8E9y+FWEPGC60KunWX+Yw9tjVyuC0EMwiLm3MqRKv1SmJOCtUCBOyD
ZboxGWUZu/vcVGOjo9uLGWuVfHqBgceVW7qQ7Zid9Lzs075gL1w/Z3uJe84d
WdylN5C2WBziNjf3xtqQKEelKM9NlWge01qr2DohIlldmG+gVPey5/sNFykY
RGlVVGngeXphl2v5SUT1elhvYU8QRwWI3WnVIm0Io5VlFc+S2Uxuy0vHFYEK
Og6pNw0epysjTBjVyfbulOGREiqN37DBq2KeTMHkH6kjrSgeByq/k1LShC76
7UZE07sSL7mQzoI8xiu2zUChWjtYT8lQkRNJ52lXEt39S1iefa4pP5RBBb9Q
jBNOGy+DUrZRj5urizO4RMEDKtpFA8L+Wy/XMemW6evnBoP40XjuXxxZDOUw
pVkLfI/I0w4iBeMRAg96iQHWi2O8yEGcj8xooOyUduJ83/58zgI+10GFMfDG
lWipWJu989W3uxFJLVmmEBg1L7K8pa/7kIqDZNooUnLnAJrQ1ENdjXmkq2p1
ggWzYu0ExRycZQjjvoTGF6SwEvNDRAPaQO7Hs6fVwmJ/pLVT9FZdm3AUhpX/
ws20UqiSw8bwStgYi14Ho0Wq6F5oPQukHCwGEwUOT7+8jKQodcuWYD6B1tIA
gXljk3165U/Dy5JiMSrNpJJMWJGiqawAhPOKsPZM0HzoeS6mAFut5kMVU3I8
TaVo0RhclyMZnUkMG+JgwxkhbUb1QXD3uVNdhMRd7srzk/qwqOBxrMnBhTNs
vSNmr05paQaRGd2MBlRkCKtSUS8gNktglLzEANiA/VMltYpqqRoJqWghCoyQ
hUQUFE4TLj7h1bgDwN+WFZarJ+c+h6kJc07O378/O7mKvJp5R6OdINji93Ia
hbWd0mpZZK4cTCw1uiICQE4X0/tKsmgnkscAFihKxGPXaKEfIN1I67j52SuW
oprYzmWQ82PvEHu2VLiLylh684xiCsmyei6VbVKJOhTmPinDA+fqNooYMk7U
RR852rBYnmZkqT4AJOP1URl16A/jy5qRoH5TFBNBKEuLOPqxiCagvpHeZ+x5
WYIWWkbx6en3J+fnP4Fl862tprhSTBHU7YyLGXGbp+rOlFrapHxc7UPm90iL
mCqGamwHTysaYrB6ibWF3EQeaIR9czDWneKwwCJhawooirr0SNIpgk8Scgas
VuxrQurvFvzpEcLRqsJlSV/r+nQYqZcV5FYoWlLUBSH25NLEANR3fH4HmHuO
+CRi2OnvtomE3uhY2o4mYRe1QAhiiuN6PKCCEDjHnHB5yiuZgell92axduoy
QbWP1wp0IoWOojje+/aXRx0SdOvdyoLCZ+RVVAL8yv5W+eySlItqkUc/SF+f
cS3Q+tGlnnC2SgJ6e5VpJz4KPVDXYK46evz+9Pwdgml3fLiPzDEUhKwd0N3k
2uAxIPJyUxCs0BlZBOAQE9fWG8izvEvzaeG1WAyNONXH9Gop4aQk8/QYvFK3
9oVKytKzhMs9RtSuLPRVqXz1UuSkGEvAiJBGxVRYb4+S3Vi+mLvmYrAvsUQJ
1Hu7DmqXdW3niPg8R6DF0GIgOjvUTw3zZyI4CV+I1i48DzOtmk5kqTcpK5J0
kVknD4yHtklfIhkT20WORvQyJMIId+AOsrXfuMuWq1lFU3iJICz4mMjUSGQ/
zQvCKHe9jDw6rI3I4RfS2vr6blg2EIWBQsdc3A5QSAsiz5ZNMKQWRARTpI1E
noA8pxwCKpqTabNSS15rA46UwuIClqhd20ZPHeX6yh3gOi9QFw63lC9DTIlL
5bpablh2mHWHUfxDp8mhn4Y1oHQXrvHt+xZfSEZYrf/NlpFmHZHKFGR7OVsy
yl0J925g3N6h7g6/kkMp2fK/ISVOVuMxXbtTHyOQg/iJz57HjNPhyGJam/vm
4RWVLbSyxJ6/VVhzunYNthsJOMkp0VQErE4JMr27aXc4m+yvpAK9VKubMIWf
v61ytkTxgolfmy4ozLVFVwRyLj+Fa7WrcTYVrspL8ugyaJfU5UFPUx6f7aTr
XMNYWdGDcuQUDWmB4x3/H/OE+SOf2A/8Fop//BBY2O9/OL/45fji9OyUUmcn
O0eYOqtap3RB9ReGmXG6JMvOMrMAxIwqv5ngUouOrJY3NbbLW7rS03O14L/L
ZBQvSEfhWoGUYkbbAvEyssx04w5axFW+ik9NiQVE4ewvuUB5/PRVVmGyxXHj
uVfVtpAC6+LakEZAeOsG7JKYDt0vNWyn1QR8tauk2aJ4H7bcFT0uJssuyhfg
oaabIajCKmuMp7BzmKqScw9KrQnqfW0V2SARU8uty6Zwct4WZovMw42xWpUW
6OQmkYsctYwI5HfWs6ptit56MRdpTKUwq/tGl2oZ4sTKnVSNnpeq1PEJ8GFJ
KXpkujTewDIVjx9ZFVrvgXBKmC6Tm0eterKsroCpjJ/wAhQPRwdGhfqbHqPh
IWFdrOv84dHIDGZmD6NENAolYbF/Q6PRDDo1PgIIX/roY9B/zLdWEC+wJ7HD
isQXlq5tqlRptzhGFY5p6cAcKxY0PiGHsDCSEQaf6UCJllX5Kv7Za/x7JelC
6tY7Vmfb01dACUp03Nsae4WRWdKr5XoqgqvFTBX2qYIuYGNPti2V7dagmogA
14/cDuO67Dr3+zO66EoMYzUAYOspN+ICTSLJx3YscIAhvtDZyaaKl2JM1/s7
tafRhPQ5jadtewIWR7IFmynHFNFa9B5KbgY2Xki1exuCA2mCeXyspyZlVT7O
8Rix1iohmBxQ4hZFmGq9isJ9eB9SsV6tqooq7BfSyFwU2VYanfX0qpTJrMcK
4fJAOh925tMBkNQ6igUqqgspNkZD020nhJLh6AnwPWqrPls5AW+ksI2ozxpZ
kRWcaYKmCIA/reeamj6Km42sUmaAjWFNODxUteOnhs/cJqIyqfcowmFmahiE
W8XMZyNSjcvGdm4amxuqQwShl0FXUbQdX/ut1EG34I6IHE9HUqbW3BL2qAOL
TMMuoUwTqgvnpYxyOSjnNEDqB0QbRVfopMWAg3PRKnLgyMB84SchBTzKW1Ms
bIzYdnOnN0ncNZpqLoEEkHa2x7SNx/rO1d8aJ1y9ysGGqR10vQKgipt2DFQ2
ptLNOoYRmHOA4g1vWnUhadaiHglUiMDOfcvZEqj6djQH3hy5n8W56IUiNCkY
974sbXzCOWkCs1OK6bl3m94T70Zvnr0kYa1ySkpIMK5VCk5jH2znUKKEsLDt
p7bi4EeNNnXB5/0uKFOqMJDfoG8NnWChJdFQ7Y1nm46GNp/v7+ErNAD4bpUw
tTusArQsgW03LWFRrW8HhdIS20E0Qit4yv5cbgYe6C3cpJheDBpExbuTSbz5
sZQLECj3oxO2t7Y6mevH/liENciIExrBTwPPZ/7EbJzbVa4WelspID7tv0Aj
VxJt4D/I75brs0GFH+5oijz2AiHyGB8zfXc6XFu0lWOXu26MxPje2iR9z6t9
RVFZagC/2nzYKbRkYDp1cd14nMeijqXE+loR7Up7b0k03LAbXP/lWdQBsOi4
oe4kXK0+vCh0aAuPU8Ub6WG+ezDmS6OqZA2ZMVMTAmIXVhFyfamWTXi5DPR8
ur/CsKQtkBCTgJuT22rg05bF9lBdDFXoG44sRV7ABLX2OSbR4KJQWXSMMtyv
3wEBm7S+fGdx2VaoZXKjalgN2QakbmDjliTCcjsehN3NJ4/wF5X0U0HMIN3V
u9mWBD1koodEbicxJRqieasHMoohOr2axBdnP3y8PDv99fLq4uz4ndyAIdrb
lPOMDkfbo10EKJ/kwd4un2Sro+zEb3Z+vTj7149nl1fw7x/OTq7OTvuGimGo
iAfCbs1DfPvbt8PTUW7a2fA/l3k6RA+3NgpL4h/Pj385/hOYUdTFgo0UNORM
STepPIa3CWhpg33SEYsu9+M9EzxOVCddhy2BompUlZZKJVGPDSJrhJPnJpZC
SeR/pCycermQUGrNMQY3eNQZPO4bnN2TWJF9KGg6N6gm5s3c69kdush8yoJZ
WX8BnIq0/RvTTYdnOIpXtUk13xXWyHkxkebF8O1BzsGwRTP9MIBrs8J7UJcC
e30w+GyV70AHfDkWJPCxMGEzR3hPqJrYCDLZJ0KY3DSQZUxRIasOL5vh1vLW
W6g4LhwM2QloQ4B+6tWo25/MfEL45xiOtjlSpAd6iVKjMMUZz6Bpc4rBSTyu
tONY6pYUMjSDKHqIlw1JIi4S6t5B36C1pA3AQueCmgpYzONOvASenMKOKACb
4K5maFdSEVnfy6gJ2+TwJHNJIxGYFU3JFhExxdmykQ1Y9mo1Qy1iEabvcslc
KytsDFn7ZVfuzInZ5c0dBluUyZPbFVM4/DQGW8+xWqiVT/q7GsLeTc0kcqj3
s/pZwtuyld7Ga5KZkfoLTWh1NrCZZgZ4UvGdAbZA/WyGTn8vHlVcl9SYjg/Y
dvPCtZGYRR0tcn4Jw125ZngwcybEzpKm9DU16VpS3zsHQAZahDD0nejoJJ5j
9q84peBIq5sSzaVOGyJvThsiskoP1v6zJqoUIpSn0Qhyr2omo3D2EuwUYO6c
k2XNNoSGLbiVeElMVFMkkpAtu5kITh7oaGDtkSmIQtFdqnl3LEWUXPQ+y9Rh
6UhRnSJeiAProOTrMjtdxmLkjOaEmhcOKS9U1ekezmszEv2MH9R6bB0WXrIQ
ECPDMEUUKlfr0HBMMwjGupRLsnckvU4raDWuKFrDbTopouCssdpTviT2VjXt
8MT1z9LcfO1Gxoqsuy8t9uACX/PabmnivpheNs6oilZEDn5rrIHihJXru0AL
tTmCnTcH+hu6digFxG2CnJyyuAn0erQHNk2extgOcsDIsRjXlJAYU7cCm1Wu
3YJ8O4g31Lj6eWrldLbjItG+BY0eaPURke8snpPw4aabCwAOMIWRS8MOgJLY
UyFHitwVaZ+/FOytkglQHOylKNvsIkT2wW4nE7mEUYRyUTiskmwEihRz3ibT
g/SKLIpuiFLU9gdjdSByJx6nys3X3E4lEaFpFm6va70NLFIpAxvpgbVLD3as
jAXZTBU2xCnktv6LBYuEjNuqBeSV+xYIHQWCc17rJ9NHPUMGvetbxw3glNdR
cSvxTlStVSTcuxzlwsau5H1cuUmjHe+i6Lw0lEdvc8SFpjXhFlQVUqKM604X
MAyiXNaDChOJ+SssayUzsb8zM59LiIKsQeG47vw6xW5W82enXhVc2+JpBM/9
+695pnw9Co+se2c757shXp3alpiPK5+KRq4eRGOoBWJfVzzyT9+SbeL3FsMr
NCsQeG6vXtX2lTLBK5sc8W3DEJIknZIFiVBppByQER8w6Ukl9mJ0wzYRh0BJ
OnnoybSkzR07mWmXevOPrgg0zigBwwNlLmy78HP2+lsKsk6LijLwriWKTB3/
2N4tjKRGFrdrcxWCtJ9oX9dDqZ2sNcC0B19wXfGZVoLsiKXFUZV/g6pgw4KU
AmZkZUQKmkfR2bo9W5euLJ3Qm/i6VYKiz3s+rzJ1ZFTq1/AmR+Ts6WpFlH/u
dV3Gszp1F4hWmIG7XAT84COtrGMAYeNhccUELX+pz7SL7ViMIp2e8qKrKNFU
G99adX0iNHqCvXZt62umCm0cboNdaHAuEliFerX9ayQWM++rHP1b7NhH2NK5
lkFpZ7YSMlCOMKFEwoJttcAU7kfKdGjaZSYqg7qKpCXp09P5afUGLBhuBcKq
sy49kuA7mqUcPNV1odeGcj1t6IlUdswGzP9CWOOW5zo8dw7Cqgur6eq6C9t9
NqegyA2YkK7Ne+TZI5o5pujjrhJpVTKKuSdlijc5rS7FY8OzIBzDtO/4l1u8
y4pC01unvIHM0vPDDoJ1RvM8ywozrT4ZJAg+dWd4aUhwucjkPhrqB55i0oES
+xGJW1IOuZch6PiqV34ivO4d1MFbPQJ2UwtOc+F1sLqMNuVFWta4Pa69xV7Z
7BnE+wJYOMOGzYOjmj7y7zS9dJ9WNmQJQM9KE6FJ6AbDdGP3wIloru6Flv6+
x5FmUOWqQeXiMfFOiDnM2+P3xx1eEkUfCooZ80ERmDe8siYbhI8NeUXb6Bt0
BjavX716eHgY5QDEUVXfvOJYCkKzeeWdxHdO3ZIxJNs0zJfsnJ6NPvmH3VND
ZBD1VBXgQOW6joQIhOFwCIZsekfwQCupMC1WT+J2ycQ7LjyzUYtORdE3/wRv
auFpRUoa/HV08fHy6tefz3/8ln7HpN8bkIY4xnDBz8TDfx8W+RT/wb8lWJ0L
yhoX5mormMICv/P6s/ZmPCv/dY2o0OYZxd9zXQSpO7q50oV34BkJeknXZd+5
lFDLNugIWq1kukWahe18dWs+JXibBzSEMPE5WKtNykqmDRayQQYm6dRfR6wr
1ZTbrbqsdq7OuUvxrWQqhkKsUlGpDdKeMYzUHtFI1SLJa4pTBNO5oFbEhNjE
p29+Onu3+T8ne3vbR4P4zU+nPwwv3xxP9va5dLY3bhnzU3Z8TNbjjyhT72D3
UFOP5UHPWsulbCsCdJgt54sonW7vZns7h8nBOIP/7Wa7B7PpgdlJ0r3x3iQZ
H+5nyfbkIN0/OMx29g73sjTJDiazo0OzM53NDne4mOsLYPG79/Tea+tkp3ba
inoqbrf+rNvIeHs8noy3J8nu3uTgaHd7YpJ9M9veNkewyqPpdC/ZnUxm6fZk
fzLdS8eTnezg8MDsmv2dfXMwTkyU7WR7+2Y8Hh/C323vr90jHOHq4pEuqrlB
3KmmLV8fmfrXJ+ksxJeiWmjkqgNQ+3mNoQbFCH48C0rNXis/FDQagYS/5pxq
B15OtNVGgn5xEyG5FbDB/nYPdvf2dsd7+4cH8OPB+GBnPN3fOzjc397PDsb7
6f7eBME0288AvjN34n6Dptok2UuXpHughyFCd2t/vmyXJAtd62q/ecgKJfVd
/o884pE3L4fbk8Phjyfvgoz81ktiZsIKYhIk7rTCsprODhNHWtsXa5g1movv
QN91763QXXYAAJ5lB3vbuzszwNbxzs7RYTY1k2k6Sw7NeDs53N6ZmIPp/v54
b7wPlDk9mMDJ7E920mRn6p1CSCuufUwftU/GySzb2Ukms8n+/s4smQEhJOls
D1B/lo4PZ1mWAS9IsmRyNJ1sT3emR/tme3+2uzPZT9PZgbRiRD+76klUEN7y
SJcPGQBTTEQtv8MRdi04OGAtzVbptHaaswGfga0gWT87UCr+cmhHIbj3D6dH
5mAvGe8dwJd7yBPT3VkCPHIHuGU6BkKZ7U+A2x7s7e8m++PDg8ikkyPgPdn+
bDZLJskh6O/AftLxbH93ujsd7/XTkVwZus1fvjdEZTT9yneDyE+EK6rqDox5
KdDqoEdBWyzG2IEcqi5ar4hGfaUREWU4YEK84jXoGNGbCqtRc06hPgZqmmZ+
DFGve71auM1+z40/X8cHh6D1eMrl2rQNqjLwXZ/U6UDHBs/9esDEEGyqXt6+
7OsMkwstTNcDzQ6l4OsCy2Pf/4/B9Hx2kQ+ngS2lYvNq2sg6W21YtHgMs2R6
OxU6KqdyCUT8TeR9M4qPO6dEN4Nr9nlqRjO69JgLd0syr2zJxhvcnUewnL3q
mr5YDcfqrejjpQxxpm59799yXlPnMeqikK8c6i0/q7tukgupaSUc+Wcyrb0C
xxG1EntW/9kdp4fuxLtBC2KkrJtI6xEOxot22Mu3u3McpWMQCNO9g4Pp0Sw9
SPamxsz2QIEaz2Y7yf6umx2RgTobuNKfPbiqoZbGrwmz0l03aEjpE7J25Cm0
KoKGBUU4O6kTU+uLavbfLoXH+9vZ/iTby2Z7hzuTdD89miW7+9sHqZke7oI+
7SBCK2BHFAGcO8HidYykaRyea2sg26qh0iQ42SBoN9FmYCBwoqUECFcaCq1u
Ohkn0729bGe6fbi9vX+0e7S7M4VdpTsAib2jaTbeGRtQ+Q/3jybJTjadzHbQ
NEjSyezwKNmbpW5PK5Pl0lTHGuPcBGRlN6rV0c3+WSX3L7WFTrgj7Gf52LoM
lAAaFLvc9FS8re5ut7PEHIF0NpP9nWyyY/a2kwOQ5mky29keJ4mI4V90wbbL
EKXCdvY30AXHbsHc2cTuvK0i79bz9oTXTg91V2b2JmMgoHR7F4y2sdmdHQJG
7e15JhXtjhQsvzkT6QkaDxRtKoiQ2dgVuTnZpUTf00byvyiZSGDdg/ZaGl3h
Ni/gfQLWwtFuBsZYkqbpTrozSTJQndLpZLw7O0izCKxHOIzfZD223QawK6vy
pbBVb5B3nv8UncI+Xse/YMR2chD/AQ5wMp5sx+Pd17t7r8cH8Y/vrqITvA82
POGCc69Vhx4AlIZNW9XmBTndrMjpnZflNO/gO59BzD2uzfoGbX3qxTlfrPJM
Jx+pl488NwlWbGrbQovaxwgSufkcWESKW2EZAxMFqnzeSgW4zKZUMjJZFt3P
5IEwQn2+rxWb0xAChGaP4nGKhYgKk1Hpxwb7SnPU1GTfbsySQhtHB0FKm0iS
6IezIGvztHozCBLu0J1yfnr+hjITF8myeBxmiBBmaF8aZtUt+lhOk/s8i783
5Z/xiimt/qwG8/AChqvqIqEqdxHVfsFwF1c0xOsv7Ez6P15C+gwmugAA

-->

</rfc>
