<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 2.6.10) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ohai-ohttp-08"
docName="draft-ietf-ohai-ohttp-10" number="9458" submissionType="IETF" category="std"
consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes=""
xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.0 3.18.1 -->
  <front>
    <title>Oblivious HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-08"/> name="RFC" value="9458"/>
    <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="2023" month="March" day="15"/> year="2024" month="January" />
    <area>Security</area>
    <workgroup>Oblivious HTTP Application Intermediation</workgroup>
    <keyword>privacy</keyword>
    <keyword>proxy</keyword>
    <keyword>partitioning</keyword>
    <keyword>tunnel</keyword>
    <abstract>
<t>This document describes Oblivious HTTP, a system protocol for forwarding encrypted HTTP messages.
This
Oblivious HTTP allows a client to make multiple requests to an origin server without that server
being able to link those requests to the client or to identify the requests as having come from the
same client, while placing only limited trust in the nodes used to forward the messages.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Oblivious HTTP Application Intermediation Working Group mailing list (<eref target="mailto:ohai@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ohai/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ohai/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-ohai/oblivious-http"/>.</t>
    </note>
  </front>
  <middle>
<section anchor="introduction">
      <name>Introduction</name>
      <t>An HTTP request reveals
      <t>HTTP requests reveal information about the client's identity client identities to servers. While the server.
Some
actual content of that information is in the request content, and therefore message is under the control of the client. However, the source IP address of the underlying connection reveals client, other
information that the client has only limited is more difficult to control over.</t> can still be used to identify the
client.</t>
      <t>Even where an IP address is not directly associated with an individual, the
requests made from it can be correlated over time to assemble a profile of
client behavior.  In particular, connection reuse improves performance, performance but
provides servers with the ability to correlate link requests that share a connection.</t>
      <t><iref item="Client"/><xref target="dfn-client" format="none">Client</xref>-configured
      <t>In particular, the source IP address of the underlying connection reveals
identifying information that the client has only limited control over. While
client-configured HTTP proxies can provide a degree of protection against IP
address tracking, and systems like virtual private networks and they present an unfortunate trade-off: if they are used without
TLS, the Tor network
<xref target="DMS2004"/> provide additional options for clients.</t>
      <t>However, even when IP address tracking is mitigated using one contents of these techniques, each request
needs communication are revealed to be on the proxy; if they are used
with TLS, a completely new TLS connection needs to avoid the connection itself being be used for each request to correlate behavior. This imposes considerable performance and efficiency overheads, due
to the additional round trip to ensure that the
origin server (at cannot use the connection as a minimum), additional data exchanged, and
additional CPU cost of cryptographic computations.</t> way to correlate requests,
incurring significant performance overheads.</t>
      <t>To overcome these limitations, this document defines Oblivious HTTP, a protocol
for encrypting and sending HTTP messages from a client to a gateway through gateway. This uses a
trusted relay
service. In particular, the protocol service in this a manner that mitigates the use of metadata such as IP
address and connection information for client identification, with reasonable
performance characteristics.  This document describes:</t>
      <ol spacing="normal" type="1"><li>an type="1"><li>
          <t>an algorithm for encapsulating binary HTTP messages <xref target="BINARY"/> using Hybrid
Public Key Encryption (HPKE; (HPKE) <xref target="HPKE"/>) target="HPKE"/> to protect their contents,</li>
        <li>a contents,</t>
        </li>
        <li>
          <t>a method for forwarding these encapsulated messages <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> between clients <xref target="dfn-client" format="none">Clients</xref> and an
<iref item="Oblivious Gateway Resource"/><xref
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> through a trusted <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> using
HTTP, and</li>
        <li>requirements and</t>
        </li>
        <li>
          <t>requirements for how the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource handles encapsulated HTTP
messages Encapsulated Requests and produces encapsulated responses <xref target="dfn-enc-res" format="none">Encapsulated Responses</xref> for the client.</li> Client.</t>
        </li>
      </ol>
      <t>The combination of encapsulation and relaying ensures that <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>
Resource never sees the client's Client's IP address and that the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>
Resource never sees plaintext HTTP message content.</t>
      <t>Oblivious HTTP allows connection reuse between the client Client and <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay
Resource</xref>,
Resource, as well as between that relay and the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>, Resource, so this
scheme represents a performance improvement over using just one request in each
connection.  With limited trust placed in the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource (see
<xref target="security"/>), <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients are assured that requests are not uniquely attributed to
them or linked to other requests.</t>
    </section>
    <section anchor="overview">
      <name>Overview</name>
      <t>An Oblivious HTTP <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> must initially know the following:</t>
      <ul spacing="normal">
        <li>The
        <li>
          <t>The identity of an <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>.  This might include some
information about what Target Resources <xref target="dfn-target" format="none">Target Resources</xref> the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>
supports.</li>
        <li>The Resource
supports.</t>
        </li>
        <li>
          <t>The details of an HPKE public key for the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>, Resource,
including an identifier for that key and the HPKE algorithms that are used
with that key.</li>
        <li>The key.</t>
        </li>
        <li>
          <t>The identity of an <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> that will accept relay requests
carrying an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> as its content and forward the content in
these requests to a particular <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>. Resource.  Oblivious HTTP
uses a one-to-one mapping between <iref item="Oblivious Relay and Gateway Resources"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay and Gateway Resources</xref>; Resources; see
<xref target="proxy-state"/> for more details.</li> details.</t>
        </li>
      </ul>
      <t>This information allows the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client to send HTTP requests to the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource for forwarding to a <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>. Target Resource.  The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway
Resource</xref>
Resource does not learn the client's Client's IP address or any other identifying
information that might be revealed from the client Client at the transport layer, nor
does the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource learn which of the requests it receives are
from the same <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>.</t> Client.</t>
      <figure anchor="fig-overview">
        <name>Overview of Oblivious HTTP</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480" width="560" viewBox="0 0 560 480" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,48 L 8,96" fill="none" stroke="black"/>
              <path d="M 48,96 L 48,464" fill="none" stroke="black"/>
              <path d="M 88,48 L 88,96" fill="none" stroke="black"/>
              <path d="M 152,48 L 152,96" fill="none" stroke="black"/>
              <path d="M 192,96 L 192,464" fill="none" stroke="black"/>
              <path d="M 240,48 L 240,96" fill="none" stroke="black"/>
              <path d="M 288,48 L 288,96" fill="none" stroke="black"/>
              <path d="M 312,48 L 312,96" fill="none" stroke="black"/>
              <path d="M 360,96 L 360,464" fill="none" stroke="black"/>
              <path d="M 400,48 L 400,96" fill="none" stroke="black"/>
              <path d="M 440,48 L 440,96" fill="none" stroke="black"/>
              <path d="M 480,96 L 480,464" fill="none" stroke="black"/>
              <path d="M 528,48 L 528,96" fill="none" stroke="black"/>
              <path d="M 552,48 L 552,96" fill="none" stroke="black"/>
              <path d="M 304,32 L 536,32" fill="none" stroke="black"/>
              <path d="M 8,48 L 88,48" fill="none" stroke="black"/>
              <path d="M 152,48 L 240,48" fill="none" stroke="black"/>
              <path d="M 312,48 L 400,48" fill="none" stroke="black"/>
              <path d="M 440,48 L 528,48" fill="none" stroke="black"/>
              <path d="M 8,96 L 88,96" fill="none" stroke="black"/>
              <path d="M 152,96 L 240,96" fill="none" stroke="black"/>
              <path d="M 312,96 L 400,96" fill="none" stroke="black"/>
              <path d="M 440,96 L 528,96" fill="none" stroke="black"/>
              <path d="M 304,112 L 352,112" fill="none" stroke="black"/>
              <path d="M 368,112 L 472,112" fill="none" stroke="black"/>
              <path d="M 488,112 L 536,112" fill="none" stroke="black"/>
              <path d="M 48,192 L 184,192" fill="none" stroke="black"/>
              <path d="M 192,256 L 352,256" fill="none" stroke="black"/>
              <path d="M 360,272 L 472,272" fill="none" stroke="black"/>
              <path d="M 368,320 L 480,320" fill="none" stroke="black"/>
              <path d="M 200,384 L 360,384" fill="none" stroke="black"/>
              <path d="M 56,448 L 192,448" fill="none" stroke="black"/>
              <path d="M 304,32 C 295.16936,32 288,39.16936 288,48" fill="none" stroke="black"/>
              <path d="M 536,32 C 544.83064,32 552,39.16936 552,48" fill="none" stroke="black"/>
              <path d="M 304,112 C 295.16936,112 288,104.83064 288,96" fill="none" stroke="black"/>
              <path d="M 536,112 C 544.83064,112 552,104.83064 552,96" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="480,272 468,266.4 468,277.6" fill="black" transform="rotate(0,472,272)"/>
              <polygon class="arrowhead" points="376,320 364,314.4 364,325.6" fill="black" transform="rotate(180,368,320)"/>
              <polygon class="arrowhead" points="360,256 348,250.4 348,261.6" fill="black" transform="rotate(0,352,256)"/>
              <polygon class="arrowhead" points="208,384 196,378.4 196,389.6" fill="black" transform="rotate(180,200,384)"/>
              <polygon class="arrowhead" points="192,192 180,186.4 180,197.6" fill="black" transform="rotate(0,184,192)"/>
              <polygon class="arrowhead" points="64,448 52,442.4 52,453.6" fill="black" transform="rotate(180,56,448)"/>
              <g class="text">
                <text x="44" y="68">Client</text>
                <text x="184" y="68">Relay</text>
                <text x="352" y="68">Gateway</text>
                <text x="476" y="68">Target</text>
                <text x="196" y="84">Resource</text>
                <text x="356" y="84">Resource</text>
                <text x="484" y="84">Resource</text>
                <text x="80" y="132">Relay</text>
                <text x="88" y="148">Request</text>
                <text x="68" y="164">[+</text>
                <text x="132" y="164">Encapsulated</text>
                <text x="112" y="180">Request</text>
                <text x="152" y="180">]</text>
                <text x="232" y="196">Gateway</text>
                <text x="232" y="212">Request</text>
                <text x="212" y="228">[+</text>
                <text x="276" y="228">Encapsulated</text>
                <text x="256" y="244">Request</text>
                <text x="296" y="244">]</text>
                <text x="400" y="260">Request</text>
                <text x="436" y="308">Response</text>
                <text x="320" y="324">Gateway</text>
                <text x="316" y="340">Response</text>
                <text x="236" y="356">[+</text>
                <text x="300" y="356">Encapsulated</text>
                <text x="300" y="372">Response</text>
                <text x="344" y="372">]</text>
                <text x="160" y="388">Relay</text>
                <text x="148" y="404">Response</text>
                <text x="68" y="420">[+</text>
                <text x="132" y="420">Encapsulated</text>
                <text x="132" y="436">Response</text>
                <text x="176" y="436">]</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
                                    .------------------------------.
+---------+       +----------+     |  +----------+    +----------+  |
| Client  |       | Relay    |     |  | Gateway  |    | Target   |  |
|         |       | Resource |     |  | Resource |    | Resource |  |
+----+----+       +----+-----+     |  +-----+----+    +----+-----+  |
     |                 |            `-------|--------------|-------'
     | Relay           |                    |              |
     | Request         |                    |              |
     | [+ Encapsulated |                    |              |
     |    Request ]    |                    |              |
     +---------------->| Gateway            |              |
     |                 | Request            |              |
     |                 | [+ Encapsulated    |              |
     |                 |    Request ]       |              |
     |                 +------------------->| Request      |
     |                 |                    +------------->|
     |                 |                    |              |
     |                 |                    |     Response |
     |                 |            Gateway |<-------------+
     |                 |           Response |              |
     |                 |    [+ Encapsulated |              |
     |                 |         Response ] |              |
     |           Relay |<-------------------+              |
     |        Response |                    |              |
     | [+ Encapsulated |                    |              |
     |      Response ] |                    |              |
     |<----------------+                    |              |
     |                 |                    |              |
]]></artwork>
        </artset>
      </figure>
      <t>In order to forward a request for a <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref> to the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref>, the following steps occur, as shown in <xref target="fig-overview"/>:</t>
      <ol spacing="normal" type="1"><li>The <iref item="Client"/><xref type="1"><li>
          <t>The <xref target="dfn-client" format="none">Client</xref> constructs an HTTP request for a <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</li>
        <li>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Target Resource.</t>
        </li>
        <li>
          <t>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"/>.</li>
        <li>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> target="request"/>.</t>
        </li>
        <li>
          <t>The Client sends a POST request to the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> with the
<iref item="Encapsulated Request"/><xref
<xref target="dfn-enc-req" format="none">Encapsulated Request</xref> as the content of that message.</li>
        <li>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious message.</t>
        </li>
        <li>
          <t>The Oblivious Relay Resource</xref> Resource forwards this request to the Oblivious Gateway
resource.</li>
        <li>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Resource.</t>
        </li>
        <li>
          <t>The Oblivious Gateway Resource</xref> Resource receives this request and removes
the HPKE protection to obtain an HTTP request.</li> request.</t>
        </li>
      </ol>
      <t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource then handles the HTTP request. This typically
involves making an HTTP request using the content of the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>. Encapsulated Request. Once the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource has an HTTP response for this request, the following
steps occur to return this response to the client:</t> Client:</t>
      <ol spacing="normal" type="1"><li>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious type="1"><li>
          <t>The Oblivious Gateway Resource</xref> Resource encapsulates the HTTP response following the
process in <xref target="response"/> and sends this in response to the request from the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref>.</li>
        <li>The <iref item="Oblivious
Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Resource.</t>
        </li>
        <li>
          <t>The Oblivious Relay Resource</xref> Resource forwards this response to the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>.</li>
        <li>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client.</t>
        </li>
        <li>
          <t>The Client removes the encapsulation to obtain the response to the original
 request.</li>
 request.</t>
        </li>
      </ol>
      <t>This interaction provides authentication and confidentiality protection between
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client and the Oblivious Gateway, but importantly not between the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client and
the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>. Target Resource. While the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource is a distinct HTTP resource from
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>, Resource, they are both logically under the control of the
Oblivious Gateway, since the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource can unilaterally dictate
the responses returned from the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource to the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>. Client. This arrangement
is shown in <xref target="fig-overview"/>.</t>
      <section anchor="applicability">
        <name>Applicability</name>
        <t>Oblivious HTTP has limited applicability.  Imporantly,  Importantly, it requires expicit explicit
support from a willing <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> and <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>,
thereby limiting the use of Oblivious HTTP for generic applications;
see <xref target="server-responsibilities"/> for more information.</t>
        <t>Many uses of HTTP benefit from being able to carry state between requests, such
as with cookies (<xref target="COOKIES"/>), <xref target="COOKIES"/>, authentication (<xref section="11" sectionFormat="of" target="HTTP"/>), or even
alternative services (<xref target="RFC7838"/>). <xref target="RFC7838"/>.  Oblivious HTTP removes linkage at the
transport layer, which is only useful for an application that does not carry
state between requests.</t>
        <t>Oblivious HTTP is primarily useful where the privacy risks associated with
possible stateful treatment of requests are sufficiently large 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"/>) <xref target="PRIO"/> or Tor (<xref target="DMS2004"/>), <xref target="DMS2004"/>, 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
          <li>
            <t>Each request requires at least two regular HTTP requests, which could
increase latency.</li>
          <li>Each latency.</t>
          </li>
          <li>
            <t>Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and AEAD expansion.</li>
          <li>Deriving Authenticated Encryption with Associated Data
(AEAD) expansion.</t>
          </li>
          <li>
            <t>Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources.</li> resources.</t>
          </li>
        </ul>
        <t>Examples of where preventing the linking of requests might justify these costs
include:</t>
        <ul spacing="normal">
          <li>DNS queries.  DNS
        <dl>
          <dt>DNS queries:</dt>
          <dd>
            <t>DNS queries made to a recursive resolver reveal information about the
requester, particularly if linked to other queries.</li>
          <li>Telemetry submission.  Applications queries.</t>
          </dd>
          <dt>Telemetry submission:</dt>
          <dd>
            <t>Applications that submit reports about their usage to their developers might
use Oblivious HTTP for some types of moderately sensitive data.</li>
        </ul> data.</t>
          </dd>
        </dl>
        <t>These are examples of requests where there is information in a request that - --
if it were connected to the identity of the user - -- might allow a server to
learn something about that user even if the identity of the user is were
pseudonymous.  Other examples include the submission of submitting anonymous surveys, making
search queries, or requesting location-specific content (such as retrieving
tiles of a map display).</t>
        <t>In addition to these limitations, <xref target="security"/> describes operational constraints
that are necessary to realize the goals of the protocol.</t>
      </section>
      <section anchor="conventions-and-definitions">
        <name>Conventions and Definitions</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

<t>This document uses terminology from <xref target="HTTP"/> and defines several terms as
follows:</t>
        <dl>
          <dt><iref item="Client"/><xref target="dfn-client" format="none">Client</xref>:</dt>
        <dl newline="true">
<!-- def: client -->
          <dt anchor="dfn-client">Client:</dt>
          <dd>
            <t anchor="dfn-client">A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
            <t>A Client originates Oblivious HTTP requests.  A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client is also an HTTP client
in two ways: for the <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref> and for the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref>. However, when referring to the HTTP definition of client (<xref section="3.3" sectionFormat="of" target="HTTP"/>), the term "HTTP client" is used; see <xref target="http-usage"/>.</t>
          </dd>
          <dt><iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>:</dt>
<!-- def: Encapsulated Request -->
          <dt anchor="dfn-enc-req">Encapsulated Request:</dt>
          <dd>
            <t anchor="dfn-enc-req">An
            <t>An HTTP request that is encapsulated in an HPKE-encrypted message; see
<xref target="request"/>.</t>
          </dd>
          <dt><iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>:</dt>
<!-- def: Encapsulated Response -->
          <dt anchor="dfn-enc-res">Encapsulated Response:</dt>
          <dd>
            <t anchor="dfn-enc-res">An
            <t>An HTTP response that is encapsulated in an HPKE-encrypted message; see
<xref target="response"/>.</t>
          </dd>
          <dt><iref item="Oblivious
<!-- def: Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Resource -->
          <dt anchor="dfn-relay">Oblivious Relay Resource</xref>:</dt> Resource:</dt>
          <dd>
            <t anchor="dfn-relay">An
            <t>An intermediary that forwards Encapsulated Requests <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> and Responses <xref target="dfn-enc-res" format="none">Responses</xref> between
<iref item="Clients"/><xref
<xref target="dfn-client" format="none">Clients</xref> and a single <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>.  In context, this can be
referred to as simply as a "relay".</t>
          </dd>
          <dt><iref item="Oblivious
<!-- def: Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Resource -->
          <dt anchor="dfn-gateway">Oblivious Gateway Resource</xref>:</dt> Resource:</dt>
          <dd>
            <t anchor="dfn-gateway">A
            <t>A resource that can receive an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, extract the contents of
that request, forward it to a <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref>, receive a response, encapsulate
that response, and then return the resulting <iref item="Encapsulated Response"/><xref <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.  In
context, this can be referred to as simply as a "gateway".</t>
          </dd>
          <dt><iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>:</dt>
<!-- def: Target Resource -->
          <dt anchor="dfn-target">Target Resource:</dt>
          <dd>
            <t anchor="dfn-target">The
            <t>The resource that is the target of an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>.  This resource
logically handles only regular HTTP requests and responses and responses, so it might be
ignorant of the use of Oblivious HTTP to reach it.</t>
          </dd>
        </dl>
        <t>This document includes pseudocode that uses the functions and conventions
defined in <xref target="HPKE"/>.</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.  ASCII <xref target="ASCII"/> encoding of a string <tt>s</tt> is
indicated using the function <tt>encode_str(s)</tt>.</t>
        <t>Formats are described using notation from <xref section="1.3" sectionFormat="of" target="QUIC"/>.  An extension
to that notation expresses the number of bits in a field using a simple
mathematical function.</t>
      </section>
    </section>
    <section anchor="key-configuration">
      <name>Key Configuration</name>
      <t>A <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> needs to acquire information about the <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration of the
<iref item="Oblivious Gateway Resource"/><xref
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> in order to send Encapsulated Requests. <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref>.
In order to ensure that <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients do not encapsulate messages that other entities
can intercept, the <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration <bcp14>MUST</bcp14> be authenticated and have integrity
protection.</t>
      <t>This document does not define how that acquisition occurs. However, in order to
help facilitate interoperability, it does specify a format for the keys. This
ensures that different
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client implementations can be configured in the same way
and also enables advertising <iref item="key configurations"/><xref target="key-configuration" format="none">key configurations</xref> key configurations in a consistent format.  This
format might be used, for example example, with HTTPS, as part of a system for
configuring or discovering <iref item="key configurations"/><xref target="key-configuration" format="none">key configurations</xref>.  Note however key configurations.  However, note that such a system
needs to consider the potential for <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration to be used to compromise <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
Client privacy; see <xref target="privacy"/>.</t>
      <t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client might have multiple <iref item="key configurations"/><xref target="key-configuration" format="none">key configurations</xref> key configurations to select from when
encapsulating a request. <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients are responsible for selecting a preferred <iref item="key configuration"/><xref target="key-configuration" format="none">key
configuration</xref> key
configuration from those it supports. <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients need to consider both the key
encapsulation method Key
Encapsulation Method (KEM) and the combinations of key derivation function the Key Derivation Function
(KDF) and authenticated encryption with associated data (AEAD) AEAD in this decision.</t>
      <section anchor="key-config">
        <name>Key Configuration Encoding</name>
        <t>A single <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref> consists of a key identifier, a public key, an
identifier for the KEM that the public key uses, and a set of 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"/> shows a single <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref>.</t> key configuration.</t>
        <figure anchor="format-key-config">
          <name>A Single Key Configuration</name>
          <sourcecode type="tls-syntax"><![CDATA[ type="tls-presentation"><![CDATA[
HPKE Symmetric Algorithms {
  HPKE KDF ID (16),
  HPKE AEAD ID (16),
}

Key Config {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE Public Key (Npk * 8),
  HPKE Symmetric Algorithms Length (16) = 4..65532,
  HPKE Symmetric Algorithms (32) ...,
}
]]></sourcecode>
        </figure>
        <t>That is, a <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration consists of the following fields:</t>
        <dl>
        <dl newline="true">
          <dt>Key Identifier:</dt>
          <dd>
            <t>An 8 bit 8-bit value that identifies the key used by the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>.</t>
          </dd>
          <dt>HPKE KEM ID:</dt>
          <dd>
            <t>A 16 bit 16-bit value that identifies the Key Encapsulation Method (KEM) KEM used for the identified key as defined
in <xref section="7.1" sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids">the HPKE KDF IANA target="https://www.iana.org/assignments/hpke" brackets="angle">"HPKE KEM Identifiers" registry</eref>.</t>
          </dd>
          <dt>HPKE Public Key:</dt>
          <dd>
            <t>The public key used by the gateway. The length of the public key is <tt>Npk</tt>, which is
determined by the choice of HPKE KEM as defined in <xref section="4" sectionFormat="of" target="HPKE"/>.</t>
          </dd>
          <dt>HPKE Symmetric Algorithms Length:</dt>
          <dd>
            <t>A 16 bit 16-bit integer in network byte order that encodes the length, in bytes, of
the HPKE Symmetric Algorithms field that follows.</t>
          </dd>
          <dt>HPKE Symmetric Algorithms:</dt>
          <dd>
            <t>One or more pairs of identifiers for the different combinations of HPKE KDF
and AEAD that the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource supports:</t>
            <dl>
            <dl newline="true">
              <dt>HPKE KDF ID:</dt>
              <dd>
                <t>A 16 bit 16-bit HPKE KDF identifier as defined in <xref section="7.2" sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kdf-ids">the
HPKE target="https://www.iana.org/assignments/hpke" brackets="angle">
"HPKE KDF IANA Identifiers"
registry</eref>.</t>
              </dd>
              <dt>HPKE AEAD ID:</dt>
              <dd>
                <t>A 16 bit 16-bit HPKE AEAD identifier as defined in <xref section="7.3" sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids">the
HPKE target="https://www.iana.org/assignments/hpke" brackets="angle">"HPKE AEAD IANA Identifiers"  registry</eref>.</t>
              </dd>
            </dl>
          </dd>
        </dl>
      </section>
      <section anchor="ohttp-keys">
        <name>Key Configuration Media Type</name>
        <t>The "application/ohttp-keys" format is a media type that identifies a serialized
collection of <iref item="key configurations"/><xref <xref target="key-configuration" format="none">key configurations</xref>. The content of this media type comprises one
or more <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration encodings (see <xref target="key-config"/>) target="key-config"/>).  Each encoded
configuration is prefixed with a 2-byte integer in network byte order that
indicates the length of the key configuration in bytes.  The length-prefixed
encodings are concatenated;
see concatenated to form a list.  See <xref target="iana-keys"/> for a definition
of the media type.</t>
        <t>Evolution of the <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration format is supported through the definition of
new formats that are identified by new media types.</t>
        <t>A <xref target="dfn-client" format="none">Client</xref> that receives an "application/ohttp-keys" object with encoding errors
might be able to recover one or more key configurations.  Differences in how key
configurations are recovered might be exploited to segregate Clients, so Clients
          <bcp14>MUST</bcp14> discard incorrectly encoded key configuration collections.</t>
      </section>
    </section>

    <section anchor="hpke-encapsulation">
      <name>HPKE Encapsulation</name>
      <t>This document defines how a binary-encoded HTTP message <xref target="BINARY"/> is
encapsulated using HPKE <xref target="HPKE"/>.  Separate media types are defined to
distinguish request and response messages:</t>
      <ul spacing="normal">
        <li>An <iref item="Encapsulated Request"/><xref
        <li>
          <t>An <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> format defined in <xref target="req-format"/> is identified by the
<xref format="title" target="iana-req">"<tt>message/ohttp-req</tt>" media type</xref>.</li>
        <li>An <iref item="Encapsulated Response"/><xref type</xref>.</t>
        </li>
        <li>
          <t>An <xref target="dfn-enc-res" format="none">Encapsulated Response</xref> format defined in <xref target="res-format"/> is identified by the
<xref target="iana-res">"<tt>message/ohttp-res</tt>" media type</xref>.</li> type</xref>.</t>
        </li>
      </ul>
      <t>Alternative encapsulations or message formats are indicated using the media
type; see Sections <xref format="counter" target="req-res-media"/> and <xref format="counter" target="repurposing"/>.</t>
      <section anchor="req-format">
        <name>Request Format</name>
        <t>A message in "<tt>message/ohttp-req</tt>" format protects a binary HTTP request
message; see <xref target="fig-req-pt"/>.</t>
        <figure anchor="fig-req-pt">
          <name>Plaintext Request Content</name> Structure</name>
          <artwork><![CDATA[
Request {
  Binary HTTP Message (..),
}
]]></artwork>
        </figure>
        <t>This plaintext Request structure is encapsulated into a message in
"<tt>message/ohttp-req</tt>" form by generating an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>.  An <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>
Encapsulated Request comprises a key identifier; HPKE parameters for the chosen
KEM, KDF, and AEAD; the encapsulated KEM shared secret (or <tt>enc</tt>); and an
HPKE-protected binary HTTP request message.</t>
        <t>An <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request is shown in <xref target="fig-enc-request"/>. <xref target="request"/> describes
the process for constructing and processing an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>.</t> Encapsulated Request.</t>
        <figure anchor="fig-enc-request">
          <name>Encapsulated Request</name>
          <artwork><![CDATA[
Encapsulated Request {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE KDF ID (16),
  HPKE AEAD ID (16),
  Encapsulated KEM Shared Secret (8 * Nenc),
  HPKE-Protected Request (..),
}
]]></artwork>
        </figure>
        <t>That is, an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> comprises a Key Identifier, an HPKE KEM ID, an
HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared Secret, and an
HPKE-Protected Request.  The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE
AEAD ID fields are defined in <xref target="key-config"/>.  The Encapsulated KEM Shared
Secret is the output of the <tt>Encap()</tt> function for the KEM, which is <tt>Nenc</tt>
bytes in length, as defined in <xref section="4" sectionFormat="of" target="HPKE"/>.</t>
      </section>
      <section anchor="res-format">
        <name>Response Format</name>
        <t>A message in "<tt>message/ohttp-res</tt>" format protects a binary HTTP response
message; see <xref target="fig-res-pt"/>.</t>
        <figure anchor="fig-res-pt">
          <name>Plaintext Response Content</name> Structure</name>
          <artwork><![CDATA[
Response {
  Binary HTTP Message (..),
}
]]></artwork>
        </figure>
        <t>This plaintext Response structure is encapsulated into a message in
"<tt>message/ohttp-res</tt>" form by generating an <iref item="Encapsulated Response"/><xref <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.  An <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>
Encapsulated Response comprises a nonce and the AEAD-protected binary HTTP
response message.</t>
        <t>An <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref> Encapsulated Response is shown in <xref target="fig-enc-response"/>. <xref target="response"/> describes
the process for constructing and processing an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.</t> Encapsulated Response.</t>
        <figure anchor="fig-enc-response">
          <name>Encapsulated Response</name>
          <artwork><![CDATA[
Encapsulated Response {
  Nonce (8 * max(Nn, Nk)),
  AEAD-Protected Response (..),
}
]]></artwork>
        </figure>
        <t>That is, an <iref item="Encapsulated Response"/><xref <xref target="dfn-enc-res" format="none">Encapsulated Response</xref> contains a Nonce and an AEAD-Protected
Response.  The Nonce field is either <tt>Nn</tt> or <tt>Nk</tt> bytes long, whichever is
larger.  The <tt>Nn</tt> and <tt>Nk</tt> values correspond to parameters of the AEAD used in
HPKE, which is defined in <xref section="7.3" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids">the HPKE target="https://www.iana.org/assignments/hpke" brackets="angle">the "HPKE AEAD
Identifiers" IANA
registry</eref>.  <tt>Nn</tt>
and <tt>Nk</tt> refer to the size of the AEAD nonce and key key, respectively, in bytes.</t>
      </section>
      <section anchor="request">
        <name>Encapsulation of Requests</name>
        <t><iref item="Clients"/><xref
        <t><xref target="dfn-client" format="none">Clients</xref> encapsulate a request, identified as <tt>request</tt>, using values from a <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key
configuration</xref>:</t>
        <ul spacing="normal">
          <li>the
          <li>
            <t>the key identifier from the configuration, <tt>key_id</tt>, configuration (<tt>key_id</tt>) with the corresponding
KEM identified by <tt>kem_id</tt>,</li>
          <li>the <tt>kem_id</tt>,</t>
          </li>
          <li>
            <t>the public key from the configuration, <tt>pkR</tt>, and</li>
          <li>a configuration (<tt>pkR</tt>), and</t>
          </li>
          <li>
            <t>a combination of KDF, identified KDF (identified by <tt>kdf_id</tt>, <tt>kdf_id</tt>) and AEAD, identified AEAD (identified by
<tt>aead_id</tt>,
<tt>aead_id</tt>) that the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client selects from those in the <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref>.</li> key configuration.</t>
          </li>
        </ul>
        <t>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client then constructs an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>, from a binary
encoded binary-encoded HTTP request <xref target="BINARY"/>, <tt>request</tt>, target="BINARY"/> (<tt>request</tt>) as follows:</t>
        <ol spacing="normal" type="1"><li>Construct type="1"><li>
            <t>Construct a message header, <tt>hdr</tt>, header (<tt>hdr</tt>) by concatenating the values of <tt>key_id</tt>,
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt>, <tt>aead_id</tt> as one 8-bit integer and three 16-bit
integers, respectively, each in network byte order.</li>
          <li>Build <tt>info</tt> order.</t>
          </li>
          <li>
            <t>Build a sequence of bytes (<tt>info</tt>) by concatenating the ASCII-encoded string
"message/bhttp request", a zero byte, and the header.  Note: <xref target="repurposing"/>
discusses how alternative message formats might use a different <tt>info</tt> value.</li>
          <li>Create value.</t>
          </li>
          <li>
            <t>Create a sending HPKE context by invoking <tt>SetupBaseS()</tt> (<xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with the public key of the receiver <tt>pkR</tt> and <tt>info</tt>.  This yields
the context <tt>sctxt</tt> and an encapsulation key <tt>enc</tt>.</li>
          <li>Encrypt <tt>enc</tt>.</t>
          </li>
          <li>
            <t>Encrypt <tt>request</tt> by invoking the <tt>Seal()</tt> method on <tt>sctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>) with empty associated data <tt>aad</tt>, yielding ciphertext <tt>ct</tt>.</li>
          <li>Concatenate <tt>ct</tt>.</t>
          </li>
          <li>
            <t>Concatenate the values of <tt>hdr</tt>, <tt>enc</tt>, and <tt>ct</tt>, yielding <tt>ct</tt>. This yields an Encrypted Encapsulated
Request <tt>enc_request</tt>.</li> (<tt>enc_request</tt>).</t>
          </li>
        </ol>
        <t>Note that <tt>enc</tt> is of fixed-length, fixed length, so there is no ambiguity in parsing this
structure.</t>
        <t>In pseudocode, this procedure is as follows:</t>
        <artwork><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
hdr = concat(encode(1, key_id),
             encode(2, kem_id),
             encode(2, kdf_id),
             encode(2, aead_id))
info = concat(encode_str("message/bhttp request"),
              encode(1, 0),
              hdr)
enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct)
]]></artwork>
]]></sourcecode>
        <t>An <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> decrypts an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request by reversing this
process. To decapsulate an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, Encapsulated Request, <tt>enc_request</tt>:</t>
        <ol spacing="normal" type="1"><li>
            <t>Parses
            <t>Parse <tt>enc_request</tt> into <tt>key_id</tt>, <tt>kem_id</tt>, <tt>kdf_id</tt>, <tt>aead_id</tt>, <tt>enc</tt>, and
<tt>ct</tt> (indicated using the function <tt>parse()</tt> in pseudocode). The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource is then able to find the HPKE private key, <tt>skR</tt>,
corresponding to <tt>key_id</tt>.  </t>
            <t>
a. If
            <ol spacing="normal" type="a"><li>
                <t>If <tt>key_id</tt> does not identify a key matching the type of <tt>kem_id</tt>, the
   <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource returns an error.  </t>
            <t>
b. If error.</t>
              </li>
              <li>
                <t>If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combination of KDF and AEAD that the
   <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource is unwilling to use with <tt>skR</tt>, the <iref item="Oblivious    Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource returns an error.</t>
              </li>
          <li>Build <tt>info</tt>
            </ol>
          </li>
          <li>
            <t>Build a sequence of bytes (<tt>info</tt>) by concatenating the ASCII-encoded string
"message/bhttp
request", request"; a zero byte, byte; <tt>key_id</tt> as an 8-bit integer, integer; plus
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as three 16-bit integers.</li>
          <li>Create integers.</t>
          </li>
          <li>
            <t>Create a receiving HPKE context, <tt>rctxt</tt>, by invoking <tt>SetupBaseR()</tt>
(<xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with <tt>skR</tt>, <tt>enc</tt>, and <tt>info</tt>.</li>
          <li>Decrypt <tt>info</tt>.</t>
          </li>
          <li>
            <t>Decrypt <tt>ct</tt> by invoking the <tt>Open()</tt> method on <tt>rctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>), with an empty associated data <tt>aad</tt>, yielding <tt>request</tt> or an error
on failure. If decryption fails, the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource returns an
error.</li>
error.</t>
          </li>
        </ol>
        <t>In pseudocode, this procedure is as follows:</t>
        <artwork><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"),
              encode(1, 0),
              encode(1, key_id),
              encode(2, kem_id),
              encode(2, kdf_id),
              encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct)
]]></artwork>
]]></sourcecode>
        <t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource retains the HPKE context, <tt>rctxt</tt>, so that it can
encapsulate a response.</t>
      </section>
      <section anchor="response">
        <name>Encapsulation of Responses</name>
        <t><iref item="Oblivious Gateway Resources"/><xref
        <t><xref target="dfn-gateway" format="none">Oblivious Gateway Resources</xref> generate an <iref item="Encapsulated Response"/><xref <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>, <tt>enc_response</tt>, Response</xref> (<tt>enc_response</tt>)
from a binary encoded binary-encoded HTTP response <xref target="BINARY"/>, <tt>response</tt>. target="BINARY"/> (<tt>response</tt>).  The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource uses the HPKE receiver context, <tt>rctxt</tt>, context (<tt>rctxt</tt>) as the HPKE context,
<tt>context</tt>, context
(<tt>context</tt>) as follows:</t>
        <ol spacing="normal" type="1"><li>Export type="1"><li>
            <t>Export a secret, <tt>secret</tt>, secret (<tt>secret</tt>) from <tt>context</tt>, using the string "message/bhttp
response" as the <tt>exporter_context</tt> parameter to <tt>context.Export</tt>; see
<xref section="5.3" sectionFormat="of" target="HPKE"/>.  The length of this secret is <tt>max(Nn, Nk)</tt>, where
<tt>Nn</tt> and <tt>Nk</tt> are the length of the AEAD key and nonce that are associated with <tt>context</tt>.
Note: <xref target="repurposing"/> discusses how alternative message formats might use a
different <tt>context</tt> value.</li>
          <li>Generate value.</t>
          </li>
          <li>
            <t>Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, called
<tt>response_nonce</tt>.</li>
          <li>Extract
<tt>response_nonce</tt>.</t>
          </li>
          <li>
            <t>Extract a pseudorandom key, <tt>prk</tt>, 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 <tt>response_nonce</tt>.</t>
          </li>
          <li>
            <t>Use the <tt>Expand</tt> function provided by the same KDF to create 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>aead_key</tt> uses a label of "key".</li>
          <li>Use "key".</t>
          </li>
          <li>
            <t>Use the same <tt>Expand</tt> function to create a nonce, <tt>nonce</tt>, of length <tt>Nn</tt> - --
the length of the nonce used by the AEAD. Generating <tt>aead_nonce</tt> uses a
label of "nonce".</li>
          <li>Encrypt "nonce".</t>
          </li>
          <li>
            <t>Encrypt <tt>response</tt>, passing the AEAD function Seal the values of
<tt>aead_key</tt>, <tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt> input of <tt>response</tt>, which
<tt>response</tt>. This yields <tt>ct</tt>.</li>
          <li>Concatenate <tt>ct</tt>.</t>
          </li>
          <li>
            <t>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>, Encapsulated Response,
<tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed-length, fixed length, so there is no
ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</li> <tt>ct</tt>.</t>
          </li>
        </ol>
        <t>In pseudocode, this procedure is as follows:</t>
        <artwork><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
secret = context.Export("message/bhttp response", Nk) max(Nn, 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><iref item="Clients"/><xref
]]></sourcecode>
        <t><xref target="dfn-client" format="none">Clients</xref> decrypt an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref> Encapsulated Response by reversing this process.  That is,
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
Clients first parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>ct</tt>. They then Then, they
follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonce</tt>, using
their sending HPKE context, <tt>sctxt</tt>, as the HPKE context, <tt>context</tt>.</t>
        <t>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client uses these values to decrypt <tt>ct</tt> using the Open AEAD function provided by
the AEAD. <tt>Open</tt>.
Decrypting might produce an error, as follows:</t>
        <artwork><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
response, error = Open(aead_key, aead_nonce, "", ct)
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="req-res-media">
        <name>Request and Response Media Types</name>
        <t>Media types are used to identify Encapsulated Requests and Responses; see
Sections <xref format="counter" target="iana-req"/> and <xref format="counter" target="iana-res"/> for definitions of these media types.</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.
New media types might be defined to use a similar encapsulation with a different
HTTP message format than in <xref target="BINARY"/>; see <xref target="repurposing"/> for guidance on
reusing this encapsulation. encapsulation method.  Alternatively, a new encapsulation method
might be defined.</t>
      </section>
      <section anchor="repurposing">
        <name>Repurposing the Encapsulation Format</name>
        <t>The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message
<xref target="BINARY"/>.  The <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> and <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> agree on this encrypted
payload type by specifying the media type "message/bhttp" in the HPKE info
string and HPKE export context string for request and response encryption,
respectively.</t>
        <t>Future specifications may repurpose the encapsulation mechanism described in
this document.  This requires that the specification define a new media type.
The encapsulation process for that content type can follow the same process,
using new constant strings for the HPKE info and exporter context inputs.</t>
        <t>For example, a future specification might encapsulate DNS messages, which use
the "application/dns-message" media type <xref target="RFC8484"/>.  In creating a new,
encrypted media types, specifications might define the use of string
"application/dns-message request" (plus a zero byte and the header for the full
value) for request encryption and the string "application/dns-message response"
for response encryption.</t>
      </section>
    </section>
    <section anchor="http-usage">
      <name>HTTP Usage</name>
      <t>A <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> interacts with the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> by constructing an
<iref item="Encapsulated Request"/><xref
<xref target="dfn-enc-req" format="none">Encapsulated Request</xref>.  This <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request is included as the content of a
POST request to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>. Resource.  This request only needs those
fields necessary to carry the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>: Encapsulated Request: a method of POST, a target
URI of the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>, Resource, a header field containing the content type
(see <xref target="iana-req"/>), and the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request as the request content. In the
request to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>, <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Resource, Clients <bcp14>MAY</bcp14> include additional
fields. However, additional fields <bcp14>MUST</bcp14> be independent of the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated
Request</xref> Encapsulated
Request and <bcp14>MUST</bcp14> be fields that the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource will remove before
forwarding the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request towards the target, such as the Connection <tt>Connection</tt>
or Proxy-Authorization <tt>Proxy-Authorization</tt> header fields <xref target="HTTP"/>.</t>
      <t>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client role in this protocol acts as an HTTP client both with respect to the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious
Oblivious Relay Resource</xref> Resource and the <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref>.  For the  The request, which the <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Client
makes to the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>, this Target Resource, diverges from typical HTTP assumptions about
the use of a connection (see <xref section="3.3" sectionFormat="of" target="HTTP"/>) in that the request and
response are encrypted rather than sent over a connection.  The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay
Resource</xref>
Resource and the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> also act as HTTP clients toward the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource, respectively.</t>
      <t>In order to achieve the privacy and security goals of the protocol protocol, a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client
also needs to observe the guidance in <xref target="sec-client"/>.</t>
      <t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource interacts with the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource as an
HTTP client by constructing a request using the same restrictions as the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client
request, except that the target URI is the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>. Resource.  The
content of this request is copied from the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>. Client.  An <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource <bcp14>MAY</bcp14> reject
requests that are obviously invalid, such as a request with no content. The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay
Resource</xref>
Resource <bcp14>MUST NOT</bcp14> add information to the request without the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client being aware of
the type of information that might be added; see <xref target="relay-responsibilities"/> for
more information on relay responsibilities.</t>
      <t>When a response is received from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>, Resource, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious
Relay Resource</xref> Resource forwards the response according to the rules of an HTTP proxy;
see <xref section="7.6" sectionFormat="of" target="HTTP"/>.  In case of timeout or error, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay
Resource</xref>
Resource can generate a response with an appropriate status code.</t>
      <t>In order to achieve the privacy and security goals of the protocol protocol, an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious
Relay Resource</xref> Resource also needs to observe the guidance in <xref target="relay-responsibilities"/>.</t>
      <t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource acts as a gateway for requests to the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target
Resource</xref> Target
Resource (see <xref section="7.6" sectionFormat="of" target="HTTP"/>).  The one exception is that any
information it might forward in a response <bcp14>MUST</bcp14> be encapsulated, unless it is
responding to errors that do not relate to processing the contents of the
encapsulated request;
Encapsulated Request; see <xref target="errors"/>.</t>
      <t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>, Resource, if it receives any response from the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target
Resource</xref>, Target
Resource, sends a single 200 response containing the encapsulated response. <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.
Like the request from the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>, Client, this response <bcp14>MUST</bcp14> only contain those fields
necessary to carry the encapsulated response: Encapsulated Response: a 200 status code, a header field
indicating the content type, and the encapsulated response Encapsulated Response as the response
content.  As with requests, additional fields <bcp14>MAY</bcp14> be used to convey information
that does not reveal information about the encapsulated response.</t> Encapsulated Response.</t>
      <t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource that does not receive a response can itself
generate a response with an appropriate error status code (such as 504 (Gateway
Timeout); see <xref section="15.6.5" sectionFormat="of" target="HTTP"/>), which is then encapsulated in the
same way as a successful response.</t>
      <t>In order to achieve the privacy and security goals of the protocol protocol, an <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource also needs to observe the guidance in
<xref target="server-responsibilities"/>.</t>
      <section anchor="informational-responses">
        <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 <tt>Expect</tt> header field with 100-continue (see <xref section="10.1.1" sectionFormat="of" target="HTTP"/>) cannot be used.  <iref item="Clients"/><xref  <xref target="dfn-client" format="none">Clients</xref> <bcp14>MUST NOT</bcp14> construct a request that includes a
100-continue expectation; the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> <bcp14>MUST</bcp14> generate an error
if a 100-continue expectation is received.</t>
      </section>
      <section anchor="errors">
        <name>Errors</name>
        <t>A server that receives an invalid message for any reason <bcp14>MUST</bcp14> generate an HTTP
response with a 4xx status code.</t>
        <t>Errors detected by the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> and errors detected by the
<iref item="Oblivious Gateway Resource"/><xref
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> 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 <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource after successfully removing
encapsulation and errors detected by the <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref> <bcp14>MUST</bcp14> be sent in an
<iref item="Encapsulated Response"/><xref
<xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.  This might be because the <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> is
malformed or the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource does not produce a response.  In either case case,
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource can generate a response with an appropriate error
status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections <xref target="HTTP" section="15.5.1" sectionFormat="of" target="HTTP"/> sectionFormat="bare"/> and <xref target="HTTP" section="15.6.5" sectionFormat="of" sectionFormat="bare"/> of <xref target="HTTP"/>, respectively).  This response is encapsulated in
the same way as a successful response.</t>
        <t>Errors in the encapsulation of requests mean that responses cannot be
encapsulated.  This includes cases where the <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref> is incorrect or
outdated.  The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource can generate and send a response with
a 4xx status code to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>. Resource.  This response <bcp14>MAY</bcp14> be
forwarded to the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> or treated by the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource as a failure.
If a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client receives a response that is not an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>, Encapsulated Response, this could
indicate that the client Client configuration used to construct the request is
incorrect or out of date.</t>
      </section>

      <section anchor="ohttp-key-problem">
        <name>Signaling Key Configuration Problems</name>
        <t>The problem type <xref target="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#ohttp-key" is defined. defined in this
section.  An
<iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> <bcp14>MAY</bcp14> use this problem type in a response
to indicate that an <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> used an outdated or incorrect <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key
configuration</xref>.</t>
        <t><xref target="fig-key-problem"/> shows an example response in HTTP/1.1 format.</t>
        <figure anchor="fig-key-problem">
          <name>Example Rejection of Key Configuration</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 106

{"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"}
]]></sourcecode>
        </figure>
        <t>As this response cannot be encrypted, it might not reach the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref>.  A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client
cannot rely on the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> using this problem type.  A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client
might also be configured to disregard responses that are not encapsulated on the
basis that they might be subject to observation or modification by an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious
Relay Resource</xref>. Resource.  A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client might manage the risk of an outdated <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration
using a heuristic approach whereby it periodically refreshes its <iref item="key configuration"/><xref target="key-configuration" format="none">key
configuration</xref> key
configuration if it receives a response with an error status code that has not
been encapsulated.</t>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>In this design, a <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> wishes to make a request to an <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref> that is forwarded to a <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref>. The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client wishes to make this
request without linking that request with either:</t>
      <ol spacing="normal" type="1"><li>The either of the following:</t>
      <ul spacing="normal">
        <li>
          <t>The identity at the network and transport layer of the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client (that is, the
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
Client IP address and TCP or UDP port number the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client uses to create a
connection).</li>
        <li>Any
connection).</t>
        </li>
        <li>
          <t>Any other request the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client might have made in the past or might make in the future.</li>
      </ol>
future.</t>
        </li>
      </ul>
      <t>In order to ensure this, the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client selects a relay (that serves the
<iref item="Oblivious Relay Resource"/><xref
<xref target="dfn-relay" format="none">Oblivious Relay Resource</xref>) that it trusts will protect this information
by forwarding the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request and Response without passing it
to the server (that serves the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>).</t> Resource).</t>
      <t>In this section, a deployment where there are three entities is considered:</t>
      <ul spacing="normal">
        <li>A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
        <li>
          <t>A Client makes requests and receives responses</li>
        <li>A responses.</t>
        </li>
        <li>
          <t>A relay operates the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref></li>
        <li>A Resource.</t>
        </li>
        <li>
          <t>A server operates both the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource and the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref></li> Target Resource.</t>
        </li>
      </ul>
      <t><xref target="separate-target"/> discusses the security implications for a case where
different servers operate the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</t> Target Resource.</t>
      <t>Requests from the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client to <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource and from <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay
Resource</xref>
Resource to <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource <bcp14>MUST</bcp14> use HTTPS in order to provide
unlinkability in the presence of a network observer.</t>
      <t>To achieve the stated privacy goals, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource cannot be
operated by the same entity as the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>. Resource. However,
colocation of the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource simplifies the
interactions between those resources without affecting <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> 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 type="1"><li>
          <t>Requests and responses are known only to <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients and <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref>.
Resources.  In particular, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource knows the origin and
destination of an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request and Response, yet it does not know the
decrypted contents.  Likewise, <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref> Resources learn only the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious
Oblivious Relay Resource</xref> Resource and the decrypted request.  No entity other than the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
Client can see the plaintext request and response and can attribute them to
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>.</li>
        <li>Oblivous Client.</t>
        </li>
        <li>
          <t>Oblivious Gateway Resources, and therefore Target Resources, cannot link
requests from the same <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client in the absence of unique per-<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> keys.</li> per-Client keys.</t>
        </li>
      </ol>
      <t>Traffic analysis that might affect these properties are is outside the scope of this
document; see <xref target="ta"/>.</t>
      <t>A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS"/>.</t>
      <section anchor="sec-client">
        <name>Client Responsibilities</name>
        <t>Because <iref item="Clients"/><xref <xref target="dfn-client" format="none">Clients</xref> do not authenticate the <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref> when using Oblivious
HTTP, <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients <bcp14>MUST</bcp14> have some mechanism to authorize an <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref> for use with a <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>. Target Resource. One possible means of authorization is
an allowlist.  This ensures that <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref> Resources are not abused misused to
forward traffic to arbitrary Target Resources. <xref target="server-responsibilities"/>
describes similar responsibilities that apply to <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref>.</t>
        <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Resources.</t>
        <t>Clients <bcp14>MUST</bcp14> ensure that the <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref> they select for generating
Encapsulated Requests
<xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> is integrity protected and authenticated so that it can
be attributed to the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>; Resource; see <xref target="key-configuration"/>.</t>
        <t>Since <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients connect directly to the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> instead of the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>,
Target Resource, application configurations wherein <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> 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"/>) can be used. Applications could
implement related policies on <iref item="key configurations"/><xref target="key-configuration" format="none">key configurations</xref> key configurations and relay connections, though
these might not provide the same properties as policies enforced directly on
target connections. When Instead, when this difference is relevant, applications can instead
connect directly to the target at the cost of either privacy or performance.</t>
        <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
        <t>Clients cannot carry connection-level state between requests as they only
establish direct connections to the relay responsible for the Oblivious Relay
resource.
Resource.  However, the content of requests might be used by a server to
correlate requests.  Cookies <xref target="COOKIES"/> are the most obvious feature that might
be used to correlate requests, but any identity information and authentication
credentials might have the same effect.  <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>  Clients also need to treat information
learned from responses with similar care when constructing subsequent requests,
which includes the identity of resources.</t>
        <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
        <t>Clients <bcp14>MUST</bcp14> generate a new HPKE context for every request, using a good source
of entropy (<xref target="RANDOM"/>) <xref target="RANDOM"/> for generating keys. Key reuse not only risks
requests being linked, reuse linked but also could expose request and response contents to the
relay.</t>
        <t>The request the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client sends to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource only requires
minimal information; see <xref target="http-usage"/>. The request that carries the
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>
Encapsulated Request and that is sent to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource <bcp14>MUST NOT</bcp14>
include identifying information unless the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client can trust that this
information is removed by the relay. A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client <bcp14>MAY</bcp14> include information only for
the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource in header fields identified by the Connection <tt>Connection</tt>
header field if it trusts the relay to remove these these, as required by <xref section="7.6.1" sectionFormat="of" target="HTTP"/>. The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client needs to trust that the relay does not replicate the
source addressing information in the request it forwards.</t>
        <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
        <t>Clients rely on the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource to forward Encapsulated Requests
and responses. Responses. However, the relay can only refuse to forward messages, messages; it
cannot inspect or modify the contents of Encapsulated Requests or responses.</t> Responses.</t>
      </section>
      <section anchor="relay-responsibilities">
        <name>Relay Responsibilities</name>
        <t>The relay that serves the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> has a very simple function
to perform. For each request it receives, it makes a request of the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious
Gateway Resource</xref> that includes the same content. When it receives a response,
it sends a response to the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> that includes the content of the response
from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>.</t> Resource.</t>
        <t>When forwarding a request, the relay <bcp14>MUST</bcp14> follow the forwarding rules in
<xref section="7.6" sectionFormat="of" target="HTTP"/>.  A generic HTTP intermediary implementation is suitable
for the purposes of serving an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>, Resource, but additional care is
needed to ensure that <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client privacy is maintained.</t>
        <t>Firstly, a generic implementation will forward unknown fields.  For Oblivious
HTTP, an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource <bcp14>SHOULD NOT</bcp14> forward unknown fields.  Though
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
Clients are not expected to include fields that might contain identifying
information, removing unknown fields removes this privacy risk.</t>
        <t>Secondly, generic implementations are often configured to augment requests with
information about the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>, Client, such as the Via field or the Forwarded field
<xref target="FORWARDED"/>.  A relay <bcp14>MUST NOT</bcp14> add information when forwarding
requests that might be used to identify <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>, Clients, except for information that
a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client is aware of; see <xref target="differential"/>.</t>
        <t>Finally, a relay can also generate responses, though it is 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 AEAD); therefore, it is also assumed that it cannot
generate an
<iref item="Encapsulated Response"/><xref <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.</t>
        <section anchor="differential">
          <name>Differential Treatment</name>
          <t>A relay <bcp14>MAY</bcp14> add information to requests if the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> is aware of the nature of
the information that could be added.  Any addition <bcp14>MUST NOT</bcp14> include information
that uniquely and permanently identifies the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>, Client, including any pseudonymous identifier.
Information added by the relay - -- beyond what is already revealed through
encapsulated requests
<xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> from <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> - Clients -- can reduce the size of the anonymity set of
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
Clients at a gateway.</t>
          <t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client does not need to be aware of the exact value added for each request, request
but needs to know the range of possible values the relay might use.  How
a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client might learn about added information is not defined in this document.</t>
          <t>Moreover, relays <bcp14>MAY</bcp14> apply differential treatment to <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients that engage in
abusive behavior, e.g., by sending too many requests in comparison to other <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>,
Clients, or as a response to rate limits signalled signaled from the gateway. Any such
differential treatment can reveal information to the gateway that would not be
revealed otherwise and therefore reduce the size of the anonymity set of
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients
using a gateway. For example, if a relay chooses to rate limit or block an
abusive <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>, Client, this means that any <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client requests which that are not treated this
way are known to be non-abusive by the gateway. <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients need to consider the
likelihood of such differential treatment and the privacy risks when using a
relay.</t>
          <t>Some patterns of abuse cannot be detected without access to the request that is
made to the target. This means that only the gateway or the target are is in a
position to identify abuse. A gateway <bcp14>MAY</bcp14> send signals toward the relay to
provide feedback about specific requests. For example, a gateway could respond
differently to requests it cannot decapsulate, as mentioned in <xref target="errors"/>. A
relay that acts on this feedback could - -- either inadvertently or by design - --
lead to <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client deanonymization.</t>
        </section>
        <section anchor="dos">
          <name>Denial of Service</name>
          <t>As there are privacy benefits from having a large rate of requests forwarded by
the same relay (see <xref target="ta"/>), servers that operate the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>
might need an arrangement with <iref item="Oblivious Relay Resources"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resources</xref>. 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 relay, it needs to trust
that the relay does not allow abusive levels of request volumes from
<iref item="Clients"/><xref
<xref target="dfn-client" format="none">Clients</xref>. That is, if a server allows requests from the relay to be exempt from
rate limits, the server might want to ensure that the relay applies a rate
limiting
rate-limiting policy that is acceptable to the server.</t>
          <t>Servers that enter into an agreement with a relay that enables a higher request
rate might choose to authenticate the relay to enable the higher rate.</t>
        </section>
        <section anchor="ta">
          <name>Traffic Analysis</name>
          <t>Using HTTPS protects information about which resources are the subject of
request and prevents a network observer from being able to trivially correlate
messages on either side of a relay.  However, using HTTPS does not prevent
traffic analysis by such network observers.</t>
          <t>The time at which <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request or response Response messages are sent can
reveal information to a network observer. Though messages exchanged between the
<iref item="Oblivious Relay Resource"/><xref
<xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> and the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might be sent in a
single connection, traffic analysis could be used to match messages that are
forwarded by the relay.</t>
          <t>A relay could, as part of its function, delay requests before forwarding them.
Delays might increase the anonymity set into which each request is
attributed. Any delay also increases the time that a <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> waits for a
response, so delays <bcp14>SHOULD</bcp14> only be added with the consent - -- or at least
awareness - -- of <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>.</t> Clients.</t>
          <t>A relay that forwards large volumes of exchanges can provide better privacy by
providing larger sets of messages that need to be matched.</t>
          <t>Traffic analysis is not restricted to network observers. A malicious <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource could
use traffic analysis to learn information about otherwise encrypted requests
and responses relayed between <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients and gateways. An <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource terminates
TLS connections from <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>, Clients, so they see message boundaries. This privileged
position allows for richer feature extraction from encrypted data, which might
improve traffic analysis.</t>
          <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
          <t>Clients and <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref> Resources can use padding to reduce the
effectiveness of traffic analysis.  Padding is a capability provided by binary
HTTP messages; see <xref section="3.8" sectionFormat="of" target="BINARY"/>.  If the encapsulation method
described in this document is used to protect a different message type (see
<xref target="repurposing"/>), that message format might need to include padding support.
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">Oblivious
Oblivious Relay Resources</xref> Resources can also use padding for the same reason, reason but need to
operate at the HTTP layer since they cannot manipulate binary HTTP messages; for
example, see <xref section="10.7" sectionFormat="of" target="HTTP2"/> or <xref section="10.7" sectionFormat="of" target="HTTP3"/>).</t>
        </section>
      </section>
      <section anchor="server-responsibilities">
        <name>Server Responsibilities</name>
        <t>The <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> can be operated by a different entity than the
<iref item="Target Resource"/><xref
<xref target="dfn-target" format="none">Target Resource</xref>.  However, this means that the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> needs to trust the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource not to modify requests or responses.  This analysis
concerns itself with a deployment scenario where a single server provides both
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</t> Target Resource.</t>
        <t>A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to the
<iref item="Encapsulated Request"/><xref
<xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, and encrypting 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"/>.</t>
        <t>If separate entities provide the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>, Target Resource,
these entities might need an arrangement similar to that between server and
relay for managing denial of service; see <xref target="dos"/>. Moreover, the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource <bcp14>SHOULD</bcp14> have some mechanism to ensure that the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway
Resource</xref>
Resource is not misused as a relay for HTTP messages to an arbitrary <iref item="Target Resource"/><xref target="dfn-target" format="none">Target
Resource</xref>, Target
Resource, such as an allowlist.</t>
        <t>Non-secure requests - -- such as those with the "http" scheme as opposed to the
"https" scheme - -- <bcp14>SHOULD NOT</bcp14> be used if the Oblivious Gateway and Target
Resources are not on the same origin.  If messages are forwarded between these
resources without the protections afforded by HTTPS, they could be inspected or
modified by a network attacker.  Note that a request could be forwarded without
protection if the two resources share an origin.</t>
      </section>
      <section anchor="key-management">
        <name>Key Management</name>
        <t>An <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> needs to have a plan for replacing keys. This
might include regular replacement of keys, which can be assigned new key
identifiers. If an <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> 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 <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> cannot be successfully
decrypted using the key.</t>
        <t>A server <bcp14>MUST</bcp14> ensure that the HPKE keys it uses are not valid for any other
protocol that uses HPKE with the "message/bhttp request" label.  Designers of
protocols that reuse this encryption format, especially new versions of this
protocol, can ensure key diversity by choosing a different label in their use of
HPKE.  The "message/bhttp response" label was chosen for symmetry only as it
provides key diversity only within the HPKE context created using the
"message/bhttp request" label; see <xref target="repurposing"/>.</t>
      </section>
      <section anchor="replay">
        <name>Replay Attacks</name>
        <t>A server is responsible for either rejecting replayed requests or ensuring that
the effect of replays does not adversely affect <iref item="Clients"/><xref <xref target="dfn-client" format="none">Clients</xref> or resources.</t>
        <t>Encrypted requests
        <t><xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> can be copied and replayed by the Oblivious <xref target="dfn-relay" format="none">Oblivious Relay
resource.
Resource</xref>. The threat model for Oblivious HTTP allows the possibility that an
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious
Oblivious Relay Resource</xref> Resource might replay requests. Furthermore, if a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client sends
an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Encapsulated Request in TLS early data (see <xref section="8" sectionFormat="of" target="TLS"/> and
<xref target="RFC8470"/>), 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>It is the responsibility of the application that uses Oblivious HTTP to either
reject replayed requests or to ensure that replayed requests have no adverse
effects
effect on their operation.  This section describes some approaches that are
universally applicable and suggestions for more targeted techniques.</t>
        <t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client or <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource <bcp14>MUST NOT</bcp14> 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 (<xref section="8.1.4" sectionFormat="of" target="HTTP2"/>), the HTTP/3 H3_REQUEST_REJECTED error code (<xref section="8.1" sectionFormat="of" target="HTTP3"/>), or a GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred. HTTP/1.1
<xref target="HTTP11"/> provides no equivalent signal.  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"/> are generally
applicable to Oblivious HTTP requests. The encapsulated keying material (or
<tt>enc</tt>) can be used in place of a nonce to uniquely identify a request.  This
value is a high-entropy value that is freshly generated for every request, so
two valid requests will have different values with overwhelming probability.</t>
        <t>The mechanism used in TLS for managing differences in <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client and server clocks
cannot be used as it depends on being able to observe previous interactions.
Oblivious HTTP explicitly prevents such linkability.</t>
        <t>The considerations in <xref target="RFC8470"/> 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>Even without replay prevention, the server-chosen <tt>response_nonce</tt> field
ensures that responses have unique AEAD keys and nonces even when requests are
replayed.</t>
        <section anchor="use-of-date-for-anti-replay">
          <name>Use of Date for Anti-Replay</name>
          <t><iref item="Clients"/><xref Anti-replay</name>
          <t><xref target="dfn-client" format="none">Clients</xref> <bcp14>SHOULD</bcp14> include a <tt>Date</tt> header field in Encapsulated Requests, <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref>, unless
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client has prior knowledge that indicates that the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref> does not use <tt>Date</tt> for anti-replay purposes.</t>
          <t>Though HTTP requests often do not include a <tt>Date</tt> header field, the value of
this field might be used by a server to limit the amount of requests it needs to
track if it needs to prevent replay attacks.</t>
          <t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource can maintain state for requests for a small window
of time over which it wishes to accept requests.  The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource
can store all requests it processes within this window.  Storing just the <tt>enc</tt>
field of a request, which should be unique to each request, is sufficient.  The
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource can reject any request that is the same as one that
was previously answered within that time window or if the <tt>Date</tt> header field
from the decrypted request is outside of the current time window.</t>
          <t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious
          <t>Oblivious Gateway Resources</xref> Resources might need to allow for the time it takes requests
to arrive from the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>, Client, with a time window that is large enough to allow for
differences in clocks.  Insufficient tolerance of time differences could result
in valid requests being unnecessarily rejected.  Beyond allowing for multiple
round trip
round-trip times -- to account for retransmission -- network delays are unlikely
to be significant in determining the size of the window, unless all potential
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
Clients are known to have excellent time-keeping. timekeeping.  A specific window size might
need to be determined experimentally.</t>
          <t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious
          <t>Oblivious Gateway Resources</xref> Resources <bcp14>MUST NOT</bcp14> treat the time window as secret
information. An attacker can actively probe with different values for the <tt>Date</tt>
field to determine the time window over which the server will accept responses.</t>
        </section>
        <section anchor="date-fix">
          <name>Correcting Clock Differences</name>
          <t>An <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> can reject requests that contain a <tt>Date</tt> value
that is outside of its active window with a 400 series status code.  The problem
type <xref target="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#date" is defined to allow the
server to signal that the <tt>Date</tt> value in the request was unacceptable.</t>
          <t><xref target="fig-date-reject"/> shows an example response in HTTP/1.1 format.</t>
          <figure anchor="fig-date-reject">
            <name>Example Rejection of Request Date Field</name>
            <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 128

{"type":"https://iana.org/assignments/http-problem-types#date",
"title": "date field in request outside of acceptable range"}
]]></sourcecode>
          </figure>
          <t>Disagreements about time are unlikely if both <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> and <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway
Resource</xref>
Resource have a good source of time; see <xref target="NTP"/>. However, clock
differences are known to be commonplace; see Section 7.1 of
<xref target="CLOCKSKEW"/>.</t>
          <t>Including a <tt>Date</tt> header field in the response allows the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client to correct
clock errors by retrying the same request using the value of the <tt>Date</tt> field
provided by the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref>. Resource.  The value of the <tt>Date</tt> field can
be copied if the response is fresh, with an adjustment based on the <tt>Age</tt> field
otherwise; see <xref section="4.2" sectionFormat="of" target="HTTP-CACHING"/>.  When retrying a request, the
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
Client <bcp14>MUST</bcp14> create a fresh encryption of the modified request, using a new HPKE
context.</t>
          <figure anchor="fig-retry-date">
            <name>Retrying with an Updated Date Field</name>
            <artset>
              <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="464" viewBox="0 0 464 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                  <path d="M 8,32 L 8,80" fill="none" stroke="black"/>
                  <path d="M 48,80 L 48,288" fill="none" stroke="black"/>
                  <path d="M 88,32 L 88,80" fill="none" stroke="black"/>
                  <path d="M 152,32 L 152,80" fill="none" stroke="black"/>
                  <path d="M 192,80 L 192,128" fill="none" stroke="black"/>
                  <path d="M 192,160 L 192,192" fill="none" stroke="black"/>
                  <path d="M 192,224 L 192,256" fill="none" stroke="black"/>
                  <path d="M 288,80 L 288,288" fill="none" stroke="black"/>
                  <path d="M 312,32 L 312,80" fill="none" stroke="black"/>
                  <path d="M 368,32 L 368,80" fill="none" stroke="black"/>
                  <path d="M 408,80 L 408,288" fill="none" stroke="black"/>
                  <path d="M 456,32 L 456,80" fill="none" stroke="black"/>
                  <path d="M 8,32 L 88,32" fill="none" stroke="black"/>
                  <path d="M 152,32 L 312,32" fill="none" stroke="black"/>
                  <path d="M 368,32 L 456,32" fill="none" stroke="black"/>
                  <path d="M 8,80 L 88,80" fill="none" stroke="black"/>
                  <path d="M 152,80 L 312,80" fill="none" stroke="black"/>
                  <path d="M 368,80 L 456,80" fill="none" stroke="black"/>
                  <path d="M 48,142 L 280,142" fill="none" stroke="black"/>
                  <path d="M 48,146 L 280,146" fill="none" stroke="black"/>
                  <path d="M 288,144 L 400,144" fill="none" stroke="black"/>
                  <path d="M 56,206 L 288,206" fill="none" stroke="black"/>
                  <path d="M 56,210 L 288,210" fill="none" stroke="black"/>
                  <path d="M 296,208 L 408,208" fill="none" stroke="black"/>
                  <path d="M 48,270 L 280,270" fill="none" stroke="black"/>
                  <path d="M 48,274 L 280,274" fill="none" stroke="black"/>
                  <path d="M 288,272 L 400,272" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="408,272 396,266.4 396,277.6" fill="black" transform="rotate(0,400,272)"/>
                  <polygon class="arrowhead" points="408,144 396,138.4 396,149.6" fill="black" transform="rotate(0,400,144)"/>
                  <polygon class="arrowhead" points="304,208 292,202.4 292,213.6" fill="black" transform="rotate(180,296,208)"/>
                  <polygon class="arrowhead" points="288,272 276,266.4 276,277.6" fill="black" transform="rotate(0,280,272)"/>
                  <polygon class="arrowhead" points="288,144 276,138.4 276,149.6" fill="black" transform="rotate(0,280,144)"/>
                  <polygon class="arrowhead" points="64,208 52,202.4 52,213.6" fill="black" transform="rotate(180,56,208)"/>
                  <g class="text">
                    <text x="44" y="52">Client</text>
                    <text x="184" y="52">Relay</text>
                    <text x="224" y="52">and</text>
                    <text x="272" y="52">Gateway</text>
                    <text x="404" y="52">Target</text>
                    <text x="232" y="68">Resources</text>
                    <text x="412" y="68">Resource</text>
                    <text x="96" y="132">Request</text>
                    <text x="312" y="180">400</text>
                    <text x="364" y="180">Response</text>
                    <text x="352" y="196">+</text>
                    <text x="380" y="196">Date</text>
                    <text x="96" y="244">Request</text>
                    <text x="72" y="260">+</text>
                    <text x="112" y="260">Updated</text>
                    <text x="164" y="260">Date</text>
                    <text x="192" y="292">|</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art"><![CDATA[
+---------+       +-------------------+      +----------+
| Client  |       | Relay and Gateway |      | Target   |
|         |       |     Resources     |      | Resource |
+----+----+       +----+-----------+--+      +----+-----+
     |                 |           |              |
     |                 |           |              |
     |  Request        |           |              |
     +============================>+------------->|
     |                 |           |              |
     |                 |           | 400 Response |
     |                 |           |       + Date |
     |<============================+<-------------+
     |                 |           |              |
     |  Request        |           |              |
     |  + Updated Date |           |              |
     +============================>+------------->|
     |                 |           |              |
]]></artwork>
            </artset>
          </figure>
          <t>Retrying immediately allows the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> to measure the round
trip
round-trip time to the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref>. The observed delay might reveal something about
the location of the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>.  <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Client.  Clients could delay retries to add some uncertainty
to any observed delay.</t>
          <t>Intermediaries can sometimes rewrite the <tt>Date</tt> field when forwarding responses.
This might cause problems if the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource and intermediary
clocks differ by enough to cause the retry to be rejected.  Therefore, <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients
            <bcp14>MUST NOT</bcp14> retry a request with an adjusted date more than once.</t>
          <t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious
          <t>Oblivious Gateway Resources</xref> Resources that condition their responses on the <tt>Date</tt> header
field <bcp14>SHOULD</bcp14> either ensure that intermediaries do not cache responses (by
including a <tt>Cache-Control</tt> directive of <tt>no-store</tt>) or designate the response
as conditional on the value of the <tt>Date</tt> request header field (by including the
token "date" in a <tt>Vary</tt> header field).</t>
          <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
          <t>Clients <bcp14>MUST NOT</bcp14> use the date provided by the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource for any
other purpose, including future requests to any resource.  Any request that uses
information provided by the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource might be correlated using
that information.</t>
        </section>
      </section>

      <section anchor="forward-secrecy">
        <name>Forward Secrecy</name>
        <t>This document does not provide forward secrecy for either requests or
responses during the lifetime of the <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref>. A measure of
forward secrecy can be provided by generating a new <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration
then deleting the old keys after a suitable period.</t>
      </section>
      <section anchor="post-compromise-security">
        <name>Post-Compromise Security</name>
        <t>This design does not provide post-compromise security for responses.</t>
        <t>A <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> only needs to retain keying material that might be used to compromise
the confidentiality and integrity of a response until that response is consumed,
so there is negligible risk associated with a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> 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 <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> 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.</t>
        <t>Even if server keys are compromised, an adversary cannot access messages
exchanged by the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client with the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> as messages are
protected by TLS.  Use of a compromised key also requires that the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious
Relay Resource</xref> Resource cooperate with the attacker or that the attacker is able to
compromise these TLS connections.</t>
        <t>The total number of messages affected by server key compromise can be limited by
regular rotation of server keys.</t>
      </section>
      <section anchor="client-clock-exposure">
        <name>Client Clock Exposure</name>
        <t>Including a <tt>Date</tt> field in requests reveals some information about the <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref>
clock.  This might be used to fingerprint <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients <xref target="UWT"/> or to identify <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients
that are vulnerable to attacks that depend on incorrect clocks.</t>
        <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
        <t>Clients can randomize the value that they provide for <tt>Date</tt> to obscure the true
value of their clock and reduce the chance of linking of requests over time.
However, this increases the risk that their request is rejected as outside the
acceptable window.</t>
      </section>
      <section anchor="sec-media">
        <name>Media Type Security</name>
        <t>The <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref> media type defined in <xref target="ohttp-keys"/> represents keying
material.  The content of this media type is not active (see <xref section="4.6" sectionFormat="of" target="RFC6838"/>), but it governs how a <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> might interact with an <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref>.  The security implications of processing it are described in
<xref target="sec-client"/>; privacy implications are described in <xref target="privacy"/>.</t>
        <t>The security implications of handling the message media types defined in
<xref target="req-res-media"/> is covered in other parts of this section in more detail.
However, these message media types are also encrypted encapsulations of HTTP
requests and responses.</t>
        <t>HTTP messages contain content, which can use any media type.  In particular,
requests are processed by an Oblivious <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref>, which - -- as an HTTP
resource - -- defines how content is processed; see <xref section="3.1" sectionFormat="of" target="HTTP"/>.  HTTP
clients can also use resource identity and response content to determine how
content is processed.  Consequently, the security considerations of <xref section="17" sectionFormat="of" target="HTTP"/> also apply to the handling of the content of these media types.</t>
      </section>
      <section anchor="separate-target">
        <name>Separate Gateway and Target</name>
        <t>This document generally assumes that the same entity operates the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious
Gateway Resource</xref> and the <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref>.  However, as the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway
Resource</xref>
Resource performs generic HTTP processing, the use of forwarding cannot be
completely precluded.</t>
        <t>The scheme specified in the <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> determines the security
requirements for any protocol that is used between the Oblivious Gateway and
Target Resources.  Using HTTPS is <bcp14>RECOMMENDED</bcp14>; see <xref target="server-responsibilities"/>.</t>
        <t>A <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource that is operated on a different server from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious
Gateway Resource</xref> Resource is an ordinary HTTP resource.  A <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource can privilege
requests that are forwarded by a given <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource if it trusts
the operator of the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource to only forward requests that
meet the expectations of the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>. Target Resource.  Otherwise, the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource
treats requests from an <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource no differently than any
other HTTP client.</t>
        <t>For instance, an <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource might -- possibly with the help of
<iref item="Oblivious Relay Resources"/><xref
<xref target="dfn-relay" format="none">Oblivious Relay Resources</xref> -- be trusted not to forward an excessive volume of
requests. This might allow the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource to accept a greater volume of
requests from that <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource relative to other HTTP clients.</t>
        <t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource could implement policies that improve the ability
of the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> Target Resource to implement policy exemptions, such as only forwarding
requests toward specific Target Resources according to an allowlist; see <xref target="server-responsibilities"/>.</t>
      </section>
    </section>
    <section anchor="privacy">
      <name>Privacy Considerations</name>
      <t>One goal of this design is that independent <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> requests are only linkable by
their content.  However, the choice of <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client configuration might be used to
correlate requests.  A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client configuration includes the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref> URI, the Oblivious Gateway <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref>, and <iref item="Oblivious Gateway Resource"/><xref the <xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref> URI. A configuration is active if <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients can successfully use it for
interacting with a target.</t>
      <t><iref item="Oblivious Relay and Gateway Resources"/><xref target="dfn-relay" format="none">Oblivious
      <t>Oblivious Relay and Gateway Resources</xref> Resources can identify when requests use the same
configuration by matching the key ID identifier from the <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration or the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref> Resource URI.  The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource might use the
source address of requests to correlate requests that use an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref>
Resource run by the same operator.  If the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource is willing
to use trial decryption, requests can be further separated into smaller
groupings based on the keys active configurations that are used.</t> clients use.</t>
      <t>Each active <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client configuration partitions the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client anonymity set. In
practice, it is infeasible to reduce the number of active configurations to
one. Enabling diversity in choice of <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource naturally
increases the number of active configurations.  More than one configuration
might need to be active to allow for key rotation and server maintenance.</t>
      <t><iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
      <t>Client privacy depends on having each configuration used by many other <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>. Clients.
It is critical to prevent the use of unique <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client configurations, which might
be used to track individual <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>, Clients, but it is also important to avoid
creating small groupings of <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> Clients that might weaken privacy protections.</t>
      <t>A specific method for a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client to acquire configurations is not included in this
specification.  Applications using this design <bcp14>MUST</bcp14> provide accommodations to
mitigate tracking using <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client configurations.  <xref target="CONSISTENCY"/> provides options
for ensuring that <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client configurations are consistent between <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>.</t> Clients.</t>
      <t>The content of requests or responses, if used in forming new requests, can be
used to correlate requests.  This includes obvious methods of linking requests,
like cookies <xref target="COOKIES"/>, but it also includes any information in either
message that might affect how subsequent requests are formulated. For example,
<xref target="FIELDING"/> describes how interactions that are individually stateless can be
used to build a stateful system when a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client acts on the content of a response.</t>
    </section>
    <section anchor="deployment">
      <name>Operational and Deployment Considerations</name>
      <t>This section discusses various operational and deployment considerations.</t>
      <section anchor="performance-overhead">
        <name>Performance Overhead</name>
        <t>Using Oblivious HTTP adds both cryptographic overhead and latency to requests
relative to a simple HTTP request-response exchange.  Deploying relay services
that are on path between <iref item="Clients"/><xref <xref target="dfn-client" format="none">Clients</xref> and servers avoids adding significant
additional delay due to network topology.  A study of a similar system
<xref target="ODOH-PETS"/> found that deploying proxies close to servers was most effective
in minimizing additional latency.</t>
      </section>
      <section anchor="proxy-state">
        <name>Resource Mappings</name>
        <t>This protocol assumes a fixed, one-to-one mapping between the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref> and the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. This means that any encrypted
request <xref target="dfn-enc-req" format="none">Encapsulated
Request</xref> sent to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource will always be forwarded to the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref>. Resource. This constraint was imposed to simplify relay
configuration and mitigate against the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource being used as
a generic relay for unknown <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref>. Resources. The relay will only
forward for <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref> Resources that it has explicitly configured and
allowed.</t>
        <t>It is possible for a server to be configured with multiple <iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay
Resources</xref>,
Resources, each for a different <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource as needed.  If the
goal is to support a large number of <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resources</xref>, <iref item="Clients"/><xref Resources, <xref target="dfn-client" format="none">Clients</xref> might
be provided with a URI template <xref target="TEMPLATE"/>, from which multiple
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">Oblivious
Oblivious Relay Resources</xref> Resources could be constructed.</t>
      </section>
      <section anchor="network-management">
        <name>Network Management</name>
        <t>Oblivious HTTP might be incompatible with network interception regimes, such as
those that rely on configuring <iref item="Clients"/><xref <xref target="dfn-client" format="none">Clients</xref> with trust anchors and intercepting TLS
connections.  While TLS might be intercepted successfully, interception
middleboxes
middlebox devices might not receive updates that would allow Oblivious HTTP to
be correctly identified using the media types defined in Sections <xref format="counter" target="iana-req"/>
and <xref format="counter" target="iana-res"/>.</t>
        <t>Oblivious HTTP has a simple key management design that is not trivially altered
to enable interception by intermediaries.  <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>  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>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Please update
      <t>IANA has registered the following media types in the "Media Types" registry at
<eref target="https://iana.org/assignments/media-types">https://iana.org/assignments/media-types</eref> for target="https://iana.org/assignments/media-types" brackets="angle"/>, following the media types
"application/ohttp-keys" procedures of
<xref target="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana-keys"/>), "message/ohttp-req" "<tt>message/ohttp-req</tt>"
(<xref target="iana-req"/>), and "message/ohttp-res" "<tt>message/ohttp-res</tt>" (<xref target="iana-res"/>), following target="iana-res"/>).</t>
      <t>IANA has added the procedures of
<xref target="RFC6838"/>.</t>
      <t>Please update following types to the "HTTP Problem Types" registry at
<eref target="https://iana.org/assignments/http-problem-types">https://iana.org/assignments/http-problem-types</eref> for the types target="https://iana.org/assignments/http-problem-types" brackets="angle"/>: "date"
(<xref target="iana-problem-date"/>) and "ohttp-key" (<xref target="iana-problem-ohttp-key"/>).</t>
      <section anchor="iana-keys">
        <name>application/ohttp-keys Media Type</name>
        <t>The "application/ohttp-keys" "<tt>application/ohttp-keys</tt>" media type identifies a <iref item="key configuration"/><xref <xref target="key-configuration" format="none">key configuration</xref> used by
Oblivious HTTP.</t>
        <dl spacing="compact">
          <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>N/A</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>"binary"</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t>see
            <t>See <xref target="sec-media"/></t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t>this specification</t>
            <t>RFC 9458</t>
          </dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>This type identifies a <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration as used by Oblivious HTTP and
applications that use Oblivious HTTP.</t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Additional information:</dt>
          <dd>
            <t><br/></t>
            <dl spacing="compact"> spacing="normal">
              <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
            <t><br/>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
            <t>See Authors' Addresses section</t>
          </dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-req">
        <name>message/ohttp-req Media Type</name>
        <t>The "message/ohttp-req" "<tt>message/ohttp-req</tt>" identifies an encrypted binary HTTP request.  This
is a binary format that is defined in <xref target="request"/>.</t>
        <dl spacing="compact">
          <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>N/A</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>"binary"</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t>see
            <t>See <xref target="sec-media"/></t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t>this specification</t>
            <t>RFC 9458</t>
          </dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP requests.</t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Additional information:</dt>
          <dd>
            <t><br/></t>
            <dl spacing="compact"> spacing="normal">
              <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
            <t><br/>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
            <t>See Authors' Addresses section</t>
          </dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-res">
        <name>message/ohttp-res Media Type</name>
        <t>The "message/ohttp-res" "<tt>message/ohttp-res</tt>" identifies an encrypted binary HTTP response. This
is a binary format that is defined in <xref target="response"/>.</t>
        <dl spacing="compact">
          <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>N/A</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>"binary"</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t>see
            <t>See <xref target="sec-media"/></t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t>this specification</t>
            <t>RFC 9458</t>
          </dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP responses.</t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Additional information:</dt>
          <dd>
            <t><br/></t>
            <dl spacing="compact"> spacing="normal">
              <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
            <t><br/>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
            <t>See Authors' Addresses section</t>
          </dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-problem-date">
        <name>Registration of "date" Problem Type</name>
        <t>IANA are requested to create has added a new entry in the "HTTP Problem Type" Types" registry established by
<xref target="PROBLEM"/>.</t>
        <dl spacing="compact">
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#date</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Date Not Acceptable</t>
          </dd>
          <dt>Recommended HTTP Status Code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="date-fix"/> of this document</t> RFC 9458</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-problem-ohttp-key">
        <name>Registration of "ohttp-key" Problem Type</name>
        <t>IANA are requested to create has added a new entry in the "HTTP Problem Type" Types" registry established by
<xref target="PROBLEM"/>.</t>
        <dl spacing="compact">
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#ohttp-key</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Oblivious HTTP <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration not acceptable</t>
          </dd>
          <dt>Recommended HTTP Status Code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="ohttp-key-problem"/> of this document</t> RFC 9458</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="HTTP11" to="HTTP/1.1"/>
    <displayreference target="HTTP2" to="HTTP/2"/>
    <displayreference target="HTTP3" to="HTTP/3"/>
    <references>
      <name>References</name>
      <references>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="BINARY"> anchor="BINARY" target="https://www.rfc-editor.org/info/rfc9292">
          <front>
            <title>Binary Representation of HTTP Messages</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author> surname="Thomson"/>
            <author fullname="C. A. Wood" initials="C. A." surname="Wood">
              <organization/>
            </author> surname="Wood"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document defines a binary format for representing HTTP messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9292"/>
          <seriesInfo name="DOI" value="10.17487/RFC9292"/>
        </reference>
        <reference anchor="HTTP"> anchor="HTTP" target="https://www.rfc-editor.org/info/rfc9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author> surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author> surname="Reschke"/>
            <date month="June" year="2022"/>
            <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. </t> schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="HTTP-CACHING"> anchor="HTTP-CACHING" target="https://www.rfc-editor.org/info/rfc9111">
          <front>
            <title>HTTP Caching</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author> surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author> surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. </t> messages.</t>
              <t>This document obsoletes RFC 7234.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="98"/>
          <seriesInfo name="RFC" value="9111"/>
          <seriesInfo name="DOI" value="10.17487/RFC9111"/>
        </reference>
        <reference anchor="QUIC"> anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author> surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author> surname="Thomson"/>
            <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"> anchor="TLS" target="https://www.rfc-editor.org/info/rfc8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author> surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="HPKE"> anchor="HPKE" target="https://www.rfc-editor.org/info/rfc9180">
          <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes">
              <organization/>
            </author> surname="Barnes"/>
            <author fullname="K. Bhargavan" initials="K." surname="Bhargavan">
              <organization/>
            </author> surname="Bhargavan"/>
            <author fullname="B. Lipp" initials="B." surname="Lipp">
              <organization/>
            </author> surname="Lipp"/>
            <author fullname="C. Wood" initials="C." surname="Wood">
              <organization/>
            </author> surname="Wood"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
              <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9180"/>
          <seriesInfo name="DOI" value="10.17487/RFC9180"/>
        </reference>
        <reference anchor="RFC2119"> anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author> surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174"> anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author> surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="ASCII"> anchor="ASCII" target="https://www.rfc-editor.org/info/rfc20">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
              <organization/>
            </author> surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>

        <reference anchor="PROBLEM"> anchor="PROBLEM" target="https://www.rfc-editor.org/info/rfc9457">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
         </author>
            <author fullname="Erik Wilde" initials="E." surname="Wilde">
         </author>
            <author fullname="Sanjay Dalal" initials="S." surname="Dalal">
         </author>
            <date day="1" month="March" month="July" year="2023"/>
            <abstract>
              <t>   This
              <t>This document defines a "problem detail" to carry machine-readable details of errors erors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.

   This
              </t>
              <t>This document obsoletes RFC 7807.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-httpapi/rfc7807bis.

              </t> 7807.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis-06"/> name="RFC" value="9457"/>
          <seriesInfo name="DOI" value="10.17487/RFC9457"/>
        </reference>

        <reference anchor="RFC8470"> anchor="RFC8470" target="https://www.rfc-editor.org/info/rfc8470">
          <front>
            <title>Using Early Data in HTTP</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author> surname="Thomson"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="W. Tarreau" initials="W." surname="Tarreau">
              <organization/>
            </author> surname="Tarreau"/>
            <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="RFC6838"> anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed">
              <organization/>
            </author> surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author> surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen">
              <organization/>
            </author> surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
      </references>
      <references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="CONSISTENCY">
          <front>
            <title>Key Consistency and Discovery</title>
            <author fullname="Alex Davidson" initials="A." surname="Davidson">
              <organization>Brave Software</organization>
            </author>
            <author fullname="Matthew Finkel" initials="M." surname="Finkel">
              <organization>The Tor Project</organization>
            </author>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="24" month="October" year="2022"/> day="10" month="July" year="2023"/>
            <abstract>
              <t>   This document describes the key consistency and correctness requirements of protocols
   such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
   privacy.  It discusses several mechanisms presents definitions for consistency and
   proposals then surveys
   mechanisms for enabling user privacy providing consistency in varying threat models.  In
   concludes with discussion of open problems in this area.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-consistency-00"/> value="draft-ietf-privacypass-key-consistency-01"/>
        </reference>
        <reference anchor="HTTP11"> anchor="HTTP11" target="https://www.rfc-editor.org/info/rfc9112">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author> surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author> surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. </t> concerns.</t>
              <t>This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="HTTP2"> anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author> surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield">
              <organization/>
            </author> surname="Benfield"/>
            <date month="June" year="2022"/>
            <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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t>This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="HTTP3"> anchor="HTTP3" target="https://www.rfc-editor.org/info/rfc9114">
          <front>
            <title>HTTP/3</title>
            <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop">
              <organization/>
            </author> surname="Bishop"/>
            <date month="June" year="2022"/>
            <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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="COOKIES"> anchor="COOKIES" target="https://www.rfc-editor.org/info/rfc6265">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth">
              <organization/>
            </author> surname="Barth"/>
            <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="DMS2004" 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"/> month="May"/>
          </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"/> month="March"/>
          </front>
        </reference>
        <reference anchor="ODOH-PETS" 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> Singanamalla" initials="S." surname="Singanamalla"/>
            <author fullname="Suphanat Chunhapanya">
              <organization/>
            </author> Chunhapanya" initials="S." surname="Chunhapanya"/>
            <author fullname="Jonathan Hoylan" initials="J." surname="Hoyland"/>
            <author fullname="Marek Vavrusa">
              <organization/>
            </author> Vavruša" initials="M." surname="Vavruša"/>
            <author fullname="Tanya Verma">
              <organization/>
            </author> Verma" initials="T." surname="Verma"/>
            <author fullname="Peter Wu">
              <organization/>
            </author> Wu" initials="P." surname="Wu"/>
            <author fullname="Marwan Fayed">
              <organization/>
            </author> Fayed" initials="M." surname="Fayed"/>
            <author fullname="Kurtis Heimerl">
              <organization/>
            </author> Heimerl" initials="K." surname="Heimerl"/>
            <author fullname="Nick Sullivan">
              <organization/>
            </author> Sullivan" initials="N." surname="Sullivan"/>
            <author fullname="Christopher A. Wood">
              <organization/>
            </author> Wood" initials="C. A." surname="Wood"/>
            <date year="2021" month="January" day="07"/> month="January"/>
          </front>
	  <seriesInfo name="DOI" value="10.2478/popets-2021-0085"/>
          <refcontent>PoPETS Proceedings Volume 2021, Issue 4, pp. 575-592</refcontent>
        </reference>
        <reference anchor="OHTTP-ANALYSIS" target="https://github.com/cloudflare/ohttp-analysis">
          <front>
            <title>Tamarin Model of Oblivious HTTP</title>
            <author fullname="Jonathan Hoyland"> Hoyland" initials="J." surname="Hoyland">
              <organization/>
            </author>
            <date year="2021" month="August" day="23"/> year="2022" month="October"/>
          </front>
          <refcontent>commit 6824eee</refcontent>
        </reference>
        <reference anchor="UWT" target="https://www.w3.org/2001/tag/doc/unsanctioned-tracking/">
          <front>
            <title>Unsanctioned Web Tracking</title>
            <author fullname="Mark Nottingham">
              <organization/>
            </author>
            <date year="2015" month="July" day="17"/> month="July"/>
          </front>
          <refcontent>W3C TAG Finding</refcontent>
        </reference>
        <reference anchor="FIELDING" target="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">
          <front>
            <title>Architectural Styles and the Design of Network-based Software Architectures</title>
            <author fullname="Roy Thomas Fielding">
              <organization/>
            </author>
            <date year="2000"/> year="2000" month="January"/>
          </front>
        </reference>
        <reference anchor="RFC7838"> anchor="RFC7838" target="https://www.rfc-editor.org/info/rfc7838">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author> surname="McManus"/>
            <author fullname="J. Reschke" initials="J." surname="Reschke">
              <organization/>
            </author> surname="Reschke"/>
            <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="RFC8484"> anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author> surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author> surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RANDOM"> anchor="RANDOM" target="https://www.rfc-editor.org/info/rfc4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author> 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller">
              <organization/>
            </author> surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker">
              <organization/>
            </author> surname="Crocker"/>
            <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"> anchor="FORWARDED" target="https://www.rfc-editor.org/info/rfc7239">
          <front>
            <title>Forwarded HTTP Extension</title>
            <author fullname="A. Petersson" initials="A." surname="Petersson">
              <organization/>
            </author> surname="Petersson"/>
            <author fullname="M. Nilsson" initials="M." surname="Nilsson">
              <organization/>
            </author> surname="Nilsson"/>
            <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="NTP"> anchor="NTP" target="https://www.rfc-editor.org/info/rfc5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills">
              <organization/>
            </author> surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin">
              <organization/>
            </author> surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank">
              <organization/>
            </author> surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch">
              <organization/>
            </author> surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="CLOCKSKEW">
          <front>
            <title>Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors</title>
            <author fullname="Mustafa Emre Acer" initials="M." surname="Acer">
              <organization>Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Emily Stark" initials="E." surname="Stark">
              <organization>Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Adrienne Porter Felt" initials="A." surname="Felt">
              <organization>Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Sascha Fahl" initials="S." surname="Fahl">
              <organization>Leibniz University Hannover, Hannover, Germany</organization>
            </author>
            <author fullname="Radhika Bhargava" initials="R." surname="Bhargava">
              <organization>Purdue University, West Lafayette, IN, USA</organization>
            </author>
            <author fullname="Bhanu Dev" initials="B." surname="Dev">
              <organization>International Institute of Information Technology, Hyderabad, Hyderabad, India</organization>
            </author>
            <author fullname="Matt Braithwaite" initials="M." surname="Braithwaite">
              <organization>Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Ryan Sleevi" initials="R." surname="Sleevi">
              <organization>Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Parisa Tabriz" initials="P." surname="Tabriz">
              <organization>Google Inc., Mountain View, CA, USA</organization>
            </author>
            <date month="October" year="2017"/>
          </front>
          <seriesInfo name="Proceedings name="DOI" value="10.1145/3133956.3134007"/>
          <refcontent>Proceedings of the 2017 ACM SIGSAC Conference on
          Computer and Communications" value="Security"/>
          <seriesInfo name="DOI" value="10.1145/3133956.3134007"/> Communications Security</refcontent>
        </reference>
        <reference anchor="TEMPLATE"> anchor="TEMPLATE" target="https://www.rfc-editor.org/info/rfc6570">
          <front>
            <title>URI Template</title>
            <author fullname="J. Gregorio" initials="J." surname="Gregorio">
              <organization/>
            </author> surname="Gregorio"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author> surname="Fielding"/>
            <author fullname="M. Hadley" initials="M." surname="Hadley">
              <organization/>
            </author> surname="Hadley"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="D. Orchard" initials="D." surname="Orchard">
              <organization/>
            </author> surname="Orchard"/>
            <date month="March" year="2012"/>
            <abstract>
              <t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6570"/>
          <seriesInfo name="DOI" value="10.17487/RFC6570"/>
        </reference>
        <reference anchor="X25519"> anchor="X25519" target="https://www.rfc-editor.org/info/rfc7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley">
              <organization/>
            </author> surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg">
              <organization/>
            </author> surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner">
              <organization/>
            </author> surname="Turner"/>
            <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"> anchor="ODOH" target="https://www.rfc-editor.org/info/rfc9230">
          <front>
            <title>Oblivious DNS over HTTPS</title>
            <author fullname="E. Kinnear" initials="E." surname="Kinnear">
              <organization/>
            </author> surname="Kinnear"/>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author> surname="McManus"/>
            <author fullname="T. Pauly" initials="T." surname="Pauly">
              <organization/>
            </author> surname="Pauly"/>
            <author fullname="T. Verma" initials="T." surname="Verma">
              <organization/>
            </author> surname="Verma"/>
            <author fullname="C.A. Wood" initials="C.A." surname="Wood">
              <organization/>
            </author> surname="Wood"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. 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>
              <t>This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9230"/>
          <seriesInfo name="DOI" value="10.17487/RFC9230"/>
        </reference>
      </references>
    </references>
    <?line 1865?>

<section anchor="complete-example-of-a-request-and-response">
      <name>Complete Example of a Request and Response</name>
      <!-- Generated using ohttp (https://github.com/martinthomson/ohttp):
RUST_LOG=ohttp cargo test -\-features nss,client,server -\-no-default-features -p ohttp -\-lib -\- -\-nocapture request_response
Note: "rust-hpke" doesn't log the client/sender keying material.
-->

<t>A single request and response exchange is shown here. Binary values (<iref item="key configuration"/><xref (<xref target="key-configuration" format="none">key
configuration</xref>, secret keys, the content of messages, and intermediate values)
are shown in hexadecimal. The request and response here are minimal; the purpose
of this example is to show the cryptographic operations.  In this example, the
<iref item="Client"/><xref
<xref target="dfn-client" format="none">Client</xref> is configured with the <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> URI of
<tt>https://proxy.example.org/request.example.net/proxy</tt>, and the proxy is
configured to map requests to this URI to the <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> URI
<tt>https://example.com/oblivious/request</tt>. The <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref> URI, i.e., the
resource the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client ultimately wishes to query, is <tt>https://example.com</tt>.</t>
      <t>To begin the process, the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource generates a key pair.
In this example example, the server chooses DHKEM(X25519, HKDF-SHA256) and generates
an X25519 key pair <xref target="X25519"/>. The X25519 secret key is:</t>
      <artwork type="hex-dump"><![CDATA[
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
]]></artwork>
      <t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> Resource constructs a <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration that includes the
corresponding public key as follows:</t>
      <artwork type="hex-dump"><![CDATA[
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003
]]></artwork>
      <t>This <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> key configuration is somehow obtained by the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>. Client. Then, when a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client
wishes to send an HTTP GET request to the target <tt>https://example.com</tt>, it
constructs the following binary HTTP message:</t>
      <artwork type="hex-dump"><![CDATA[
00034745540568747470730b6578616d706c652e636f6d012f
]]></artwork>
      <t>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client then reads the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway Resource</xref> <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration</xref> Resource key configuration and
selects a mutually supported KDF and AEAD. In this example, the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client selects
HKDF-SHA256 and AES-128-GCM. The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client then generates an HPKE sending context
that uses the server public key. This context is constructed from the following
ephemeral secret key:</t>
      <artwork type="hex-dump"><![CDATA[
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
]]></artwork>
      <t>The corresponding public key is:</t>
      <artwork type="hex-dump"><![CDATA[
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
]]></artwork>
      <t>And
      <t>The context is created with an <tt>info</tt> parameter of:</t>
      <artwork type="hex-dump"><![CDATA[
6d6573736167652f626874747020726571756573740001002000010001
]]></artwork>
      <t>Applying the Seal operation from the HPKE context produces an encrypted
message, allowing the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client to construct the following <iref item="Encapsulated Request"/><xref <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>:</t>
      <artwork type="hex-dump"><![CDATA[
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525
]]></artwork>
      <t>The <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> Client then sends this to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> 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 <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Oblivious Relay Resource</xref> Resource receives this request and forwards it to the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource</xref>, 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 <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> 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 <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Oblivious Gateway
Resource</xref>
Resource does not need to initiate an HTTP request to the <iref item="Target Resource"/><xref <xref target="dfn-target" format="none">Target Resource</xref>. The
request can be served directly by the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>, Target Resource, which generates a minimal
response (consisting of just a 200 status code) as follows:</t>
      <artwork type="hex-dump"><![CDATA[
0140c8
]]></artwork>
      <t>The response is constructed by exporting a secret from the HPKE context:</t>
      <!-- ikm for HKDF extract -->
<artwork type="hex-dump"><![CDATA[
62d87a6ba569ee81014c2641f52bea36
]]></artwork>
      <t>The key derivation for the <iref item="Encapsulated Response"/><xref <xref target="dfn-enc-res" format="none">Encapsulated Response</xref> uses both the encapsulated KEM
key from the request and a randomly selected nonce. This produces a salt of:</t>
      <artwork type="hex-dump"><![CDATA[
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
c789e7151fcba46158ca84b04464910d
]]></artwork>
      <t>The salt and secret are both passed to the Extract <tt>Extract</tt> function of the selected KDF
(HKDF-SHA256) to produce a pseudorandom key of:</t>
      <artwork type="hex-dump"><![CDATA[
979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
]]></artwork>
      <t>The pseudorandom key is used with the Expand <tt>Expand</tt> 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"><![CDATA[
5d0172a080e428b16d298c4ea0db620d
]]></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"><![CDATA[
f6bf1aeb88d6df87007fa263
]]></artwork>
      <t>The AEAD <tt>Seal()</tt> function is then used to encrypt the response, which is added
to the randomized nonce value to produce the <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>:</t> Encapsulated Response:</t>
      <artwork type="hex-dump"><![CDATA[
c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd
]]></artwork>
      <t>The <iref item="Oblivious Gateway Resource"/><xref <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> constructs a response with the same content:</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 <iref item="Oblivious Relay Resource"/><xref <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> Resource</xref>, which
might change as little as the Date <tt>Date</tt> header. The <iref item="Client"/><xref <xref target="dfn-client" format="none">Client</xref> is then able to use the
HPKE context it created and the nonce from the <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref> Encapsulated Response to
construct the AEAD key and nonce and decrypt the response.</t>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This design is based on a design for Oblivious DoH, DNS (queries) over HTTPS (DoH),
described in <xref target="ODOH"/>. <contact fullname="David Benjamin"/>, <contact fullname="Mark Nottingham"/>, and
<contact fullname="Eric Rescorla"/> made technical contributions.  The authors also thank
<contact fullname="Ralph Giles"/>, <contact fullname="Lucas Pardue"/>, and <contact fullname="Tommy Pauly"/> for invaluable
assistance.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIALcxEmQAA+19aXfb2JXg9/cr0PKHlmKSpnbJtaRVklylLlt2W3LX5GRy
SiABSohJgA2AkhmX+7fMb5lfNnd9CwBScpLumTknPp0uGwTect99d1/6/b6p
s3qavow23o6m2X1WLKrop+vrdxsmKcZ5PINfkjKe1P0srSf94i7O4P/V9bw/
PDLjuE5vi3L5MqrqxNy/jHZNXKYxjHWVjhdlVi83zENRfrwti8W8NUN0Mp9P
MxgjK/LoIq/TcpYmGf1zw9yn+SJ9aaLor/g2iurlHHf0C8yd5bfRjzgGPp/F
2RSe4y7+BfczKMpbfB6X4zt4jvuqXr54ga/ho+w+HehrL/DBi1FZPFTpCxzg
BX54m9V3ixF8StB5uCUAvSh0rX0cEd+bAqSq2pvCf3/AowyyovHli07ID+7q
2XTDmHhR3xUlwqgP/4uiLK9eRm8G0fVdMauKnJ7xAb6JyzrLgx9gR/C8+Es2
ncb0IGXYzOp/mRYPaV6XxXw5yNM6HP50cDKIfimKxBv99K7MqrqY36Vl5P9K
U5xOi0UyAWim/izj+OFf7tJ4DoczyuqK5jF5Uc7gBO/h2OHdHy4uT97/4WX0
/tXp8c7xDjzBc+d/b28P5d/905PTny4uf9Tn2/D83z5cnPK/h0N87/r1Ff3z
aG/vAD979/O5vH40NCbLJ8G8p28vry6urs8vT2Hyi/4ZIUB/Xmb38Xg5j6uq
/zFd9sdFXsGm03y8lJVsb7+kHX6nS9mhfyZZNZ/GcEPwnRfbg215fafx9m7H
27rp3ca7ex3v7tLS3/58cc6bPdg52MftnL252hkO93gEvenXgDaADWkE17TI
k/6PaZ6WfJfe5vj/3xcLuFIbPA+g7ssIB8ErT8PE5W3qI3N1nw/qopyXxZ/T
cU23BR69kH9XL5K0ym7z/jyep+ULeLHPDwSRcUiHy/inz8j2fhCdAYZM4Wbn
afjT5QCQur5LHxSf7S/vBtHV8j4t8Qf45d37i7fh5t+VWQGv4YHWaQ+2OlpU
dS+K8yS6GsfTeDRNo9NiNl/UDJFiEp3c3pbpLbweXeHDqs7GVQic7cP+cLcv
J9OCz7hczutiUNUxIlsySJMFAAeuO0FkME8ma6Dw0wCWU5bZbZz3f8xGoyr8
+WwQ/VDk6R1u9u3Z25/6786vr8IdO9J5dnkVFQAcwpmraPPtWfHT1svoBMAR
j2FX8ZQBM15G5/ldnI/TGZCCqC7wy3DHO9v9IfzfYbBj3fDDw8NgntbVcjYv
qmwxI5TAb15Msmla8b6rF1lVLdK9F/MC3+3zmMOjfQRIJzwmi+mUac7VIrlL
0+ouugIEieFZrHSs+d4cthHXQKQWsKF5nC+7XgMCmX6M/j2+LxdV1+/X+F30
78Blun59l8JliX5ZdA/8EOfRq3iZJh0//7wAwgwcLc1maTnteOEyG3+ETUzh
AOO84/cu2ouIQLTx5PLk9R+AmDUuPwCrBG7wpkjSKWJ3k+83T/mov7PbecrC
tsbF7MXYkvkXLB0A0KdLIJGPnOO/FnA4cELRT8VyClcQF//hl+twxR/yClAR
L2OaRL+ko+gasBUZe9etCWD/MbosamB9t3fxLLyv+4C6/e3V2PuwKzg73H5R
x7cvQBh6sfDW0a9lDS9wya8uzl+fIRsK1n2CIkQNFHBRwsW6qpeA+kRngHBF
Z0QCEf6XaY1CUn8UV7C/q2JSPwAcI+/rtFq/0/fFkph7XEWvsnQK5PI2JN3D
brqEGwVSNliMM6JJ/zmRr1/MFyMg23A/05LJ4Av96Vf/KZMuY/r9fhSPKoQJ
MPLrO8BpANiCiAfQ+nGZjXDrUbUEnjmLgAji/2CbOGIEXBQJJGyeRLtZWlXx
bVoNeCC42SBzwcfjaSbEaBZ/TKPZYlpncyDWZfofCxCuKvwFMKkAUgnoDWtE
QvcAOArMDEAORECejVKcFQm9gU+mWf4Rfi6qcCQ8I5kRVgsPsgT+nk2W9It9
E0B+F9/jeHANUjMpixm9UMHByPe96OEOqF4E3HqMLxb5dAmzzjLccQ0UpwZK
Th/lcCWraIFoABMKhOgXBxMG9ixLEli+eYbCb1kkC0JLY05yhqGsD/57n8bT
KrJSDjC0eMQA0fX9cyV7q5e6cQbUwFzBnhBFCXr+GFmla9aZQJCoabOC4GUK
b6fRIk8A4jRZgSudGhpO5x7AxX+ANZY9nrdYlOM0ungXxUkCaF9F8jYNM10y
nPM8pe3q7oy/Mlqqd3h3cEIBxGUdxAcBnOegacABwXoRebyZYYt5AeiblTAb
fA+iXzEGFQOGQKTCt7M8AcqZLOJpL8AKM4uTNCJcyAAy8OYI91+W6ZS+JxZc
A80nlIXrNEOhI45AYEL+iJuW1Y9SxK6iHMA5mzmK8eMFUNleCAXAmCibwdf3
gD7AWQkawLx70QhOGp9niFh8qhUt3+B641E2lVO3q/MuAV2ZO6RFsTcfwOyU
FodC8CS7BfIkFxcm+pTBPLhhmRS+TFIQnmhP8KyWNce3MUgvNcDbKLyVoDIG
MaWo4NTgqt9nZQ1AjuYstEU5U0xHTEGg1Yfm82eReb98catIkgznhTGKOf6l
IhrEQMZLZbEwFXQIUEGXhjgBSJTd0ikuKr7NckNSOATY3l2eIfxgpHh8p8A0
eZomRFYAEXD7SC2AdtUpIFaePqCO4h8posV9kSV6cfQ56ErpdCIEDOmECY7O
YQtRzgylLzwPVFbg/pBo66EHgS+dTLJxhooMoSVoZQksPlkQbSQkcbADNRoB
XmbzkFBEm4ApMYAmz2aL2VbP/wZ4UByln8bA5G/ThA7XeD+fvvsA6wNMQJwn
Mfm2jOd32ZggJDI4ntB1QetDKivApgvNv+P1C3nOBFSGqiHa9PiK1cUYrj8A
wQjjIW6AOJfmxI8CLsTX2Oc+cYTn/xAjJwCI3AIpYDIOOIEHsTQIlWyc4qWN
/EuLELMLIPrZyShBD90eIH2Jp7fAzeo75piw2nhewUi04FGWx+WysdbPn1lt
BtRn7PxpOSozkjzfLQAW4+jnFEV73jYg1CZqw9/Ad/jfL1+2cH9yTXG1Wal0
veoZszPAQ06BVyZNFs4n4lYIoLCLGsHFTOFCyW0jULMw647nR4Ho+1RYQBu0
7uX3CGT3Ku0Uh5MzRilyd0BXD2j3jObE5d4VD3QCa2YFJE1QSAs2gsPi8HZD
uIE5Md3mq0At5oCOKU/osTkUivAmz/DYVK30DhRpQi7owyJRhWIf0+DVCwa6
gtevSulVj6F7xEtp5Er4uTEMiCgZHPenOsArxQHYRcMKJ7JZixnpkXt8GJfR
WILRJfRQjHpIp1P8r/s2rhkgHVtoAqIHogNdJ1ON7+DM4cM57J7xLaB5wifp
xhEf5ovyZxTDkJarPAPXEym48RhfFP2CjD8U3VCqg3+INLQSyJsAX2BNldhF
4ar1olO9EMhhq4oYqexapcsyJSFkQUwFhZAaqC8wdZIQkYfPUDpFEZZlxgIl
L/s9SovPorf3SI7SB5IOGwfISwBZmnYMRBlOdBl9zOWqTAo8YIAPkKTfkcXI
SoqAv3G+5kQAWsSEZtntHY49ni4SFPBmaMlpi6MPuO9rUlDsENUjhw4DVYv5
vChpp7y+JK3jbFrJ8pCqRXOmfB+B8umtXINItDpcLHMFFfuztJSvYZ04lOIk
TWEJtdxYPDdizxHLivrV4FEwNtCGPnzI8GaMx+lcL4QVNCMQtspyKWs992nR
e0FkuFIgNugdpnX7moU+z5AiMxkPFCqPga0/7RCzYLBFRTofXKp+XfTxbs3i
+Zx4l1zx5rZxbc2Rq2+QNMFwnz+jfLnsV8DzU2BweBozVDHkyAeieAa4xfQJ
93lq+Tey+UBLsvqeXY9pcYYmv0PINNCVML4DtyyZA1afslIxTeMyX0mxYao4
X8pdVrUTeVxLz+HLNUpFE4JTtwqokl1WhkCCzSu8KRHAGeXcHMQfWs4jHJFX
CgosCLOii1moZYiO4zRDrQMN/KHye6qc7z//8z+jOK7ub8Vusf7PoL/2z8A8
t39/Lp+4J/Lot/az8N+/md8UIfBl+YiRMNJHv+H/KUD42W965vyr+c0u2x9F
QOeNEj4L//0b7+h5a0fPu3b0PNzRc7ejYBnuT/DkRkDwWwhU/ec/6yAWEl2D
rHj4m/uYCc9f9fEfn4dU7Ks+hj86+Z++cubn/caf772zf9LMjUmaUPiqj5tQ
+KqPowYUvuLjFhQYEMFenoZp3SN+/3Uff9Weux++F4n8iR/rkf/2bbDu50/5
2E31Nct+BOGfsGw775+e8DHf7Mb2fNq58uNV22suJ/z4b73P67a39uPWDp93
fPv3wDDvY+B05vPL6Nkku+0XInWzN+C7DZXCOzwuX4y5QLs1WUqd3Te2uggK
Hy1xoyW0tOSNXijDR6BGz0G6GIMKQhpXBRoxGjFBtPJX/OULGyCundSEFiRQ
d8akvYcW5s61DchY4A0Aqi7Ztkli9j/P0BjWYctQ+ZrsBJ6OLQK2viVWDpLB
RSAHKXGMUhRJI58/y0RfvgzIKuCtCeVAFFDfvb26tutpAbUhkIs4T+7oVeK2
L1ar8VwWDIvYGzTExMYMcvwVW4dWrksPG9ZROqjvNwdvCXRWYguGZ+PDDA3I
OKJVbDyTLWqXI5C08yYKiHFjrTEHhH21rTRRQIyV9XKO/ufpEqTc+2KKK5zF
H0WxCVCGz7wF5LTzPAbR25xXYNbafXzEFnrD6p4DUuM6Ge86IXDKtF6UuX4h
YwSOJHet1iylgetpa1F6mwUJFd3pGutroB6pQVMOOstbi7I3WMT20CIXYqW7
0E/G23Ayqw2Ed1Bwjl4JzWEO3Xit4XDs5IvZZe7jIW21Timcocid7wNdp6hI
jZ2xjdwXpF3F5AXxcF0UVOMpjittUOxkQVt7Wcc5eopQw/MtYG4EGrClNv5C
7sGOn9DfEGOgT53l49pigsAbjs08ZhWD35dkjRgVaLkqbvmOtd1ycofal6QX
wXXjG7QObdHns8gzRNuSZkiyMSrqxj+9Si6Jr6eu4GqCL0wb4rJE7wHa7Ey2
hm+RveuZxgayc6tls8S7ria82H8T9PcLPEU6xB5rt2RCrqL0ExCnrDZiblKf
ABpm8CquvBOh0bNtayI/6Uh8k0rV0IDaEhKIGt1inFY21mWT6+MbU6VphJZF
9MT0BdQZbSlLK99Q4pkPAFJv0MZANhqYjKYYwfCTTHbnnOTkHkQrU0SmF4va
agfoAVjGd2TCReY4LoqP6AXc/PxZAtLI2Nm4gPDrlVy27W1dAb5o0NOBTrh4
CqiUU2BeJA4VGvT371+dHh7tHsHLLauTpSdoEQV2a1aZP9igkYlrGKAwWUxZ
lMl96Bri3dZssw4KbeM4jD4vMwy2cVOwo1miCaMyq9CJ2XAsz4sKzm+aGpoI
v6rLNK5nwukC43C1EPcd0p0pXiXPAS5utSSdTwuyHxFltg4o8Uuj5Rvtm0kb
mnjXMvRTloTJU+QzOOoUXV9xbgirSgqgU4dtjz22GGSHh4Xhd+hWAsiij3bT
c85u6SnAOow6akHKLOCmA6ovYryI6NiA7dxlt2gLK+YSphhPaR3dQKdVecsk
EopO/KaHVcMcoojiHGjEnqH1czyISCKJIrb9ugIyNu8pBGOYsc7+gt7NEUdW
oEG/hANEzwqsFS49cWDe74oVA41J4eLep41Fy3mTBf7c8yk76hSTQRGFxAcU
Q27JVhsYOC2oi8U0YQs3oBT6UGOKYR20Bs+I6MGps2+jgu1J2IPz3TJdwrig
Cs3mqXUr9jXQYZbWMTqA2ad/cn5yxqNWTIJ+F50BPePomcD3+zFdip8Q7uJS
CCN7QT2J1UROLvAF1fgj3de8n6e3U5ATkIZ53mR0ZKtxGQNAPsWI4kQG9Xoi
AbL0GGkJefq9u8eGV746SzGbE/4Y8XTQcWG4JXxQAjkEJPP+FVGACOFgiR4h
OnZc1PSe3DdozPXJNYao26gdWQSSMWebB1zPJi1HkE5Obod0Chy0RgK2GM2y
qmKXlhdIryEf+DOiF3lW3MQZ+spQ6aoLdhXAgwSWOsVrqSBB5tXBuSpy2y/n
DOZZgdEIGPyALhzEeqLyiCmsTFR0fwBX3NFY0PMZ8SVrmPtJmbQaE+6lD1Ax
sJmHtLSBFAyguuGFEc5bRn3ZCfkOLJHAT8gWbnArQEiJOdrIMvqS2FY2WT00
Ut8qXSRFvpwBeAbmLZ2S3aZ6yciGbg+JfUTyDTyH5SzhRot2VKWYmGDkpHuR
uyL467Tgo+1X83QMVH5sdaZNZdogksGXdAnrTIAdm1k81wjzrQHZJ/TiC/Ca
ARi+b9OL+QtJNloR0MNcGesmgxNB1bhcsg4FovhfGAC3RTy18V/KtETCOy1y
uqGIs0gmzjDeg1ZXsTKKHrqHArWRjTcfrq43evzf6PIt/f39+b99uHh/foZ/
v/rp5PVr+xcjb1z99PbD6zP3N/fl6ds3b84vz/hjeBoFj8zGm5M/bDC923j7
7vri7eXJ6412sAduncOBSF0BkkPyaGUUdER2fzh997//1/YeAPefQOrZ2d4+
BuDyP462DzHCCUOVeDaSZPifKPUbIJ2AGnQnpsjs53BW08oz/OANQsrwR4TM
n15G347G8+297+UBbjh4qDALHhLM2k9aHzMQOx51TGOhGTxvQDpc78kfgn8r
3L2HzahUEnwxbSjLC1CLlmouYjGUAKpBRMrF8W2U1gzr4Bim87s/sp4CEz1L
Jnmf9Xz7uGo97zJR6EvAP4Fx/kf7LWZx4WsVbnOF2qFvcjCS/15TA9E3JaBp
zZjV0wetHh+109HbnKGhGerPHMWsQYhwCJi/cKqRumQWqFuhX05Mj9zbFFxc
FdbyI6cU0W0FUQrFtpc2ZqCpqIojvctcaCJPu7ehhRRVWKaTtCzFhWzNO4ml
X17sp1ORYLzdwa6vJbFWAwgZbXhL38AtYdwB+cwBmykUn5g2KsdR9PklLHt8
V5TfbTi0RPtzF14yaBvGN44EboQ9iU3w3c/nfRfLLRZP5773LLGtlQjudyyF
kb+xFjUG/S2LUUvZytVUuJpV90EXlNncw3LJ67F2sC6YMrt6b+0hamiKXDAQ
Sr1oc7mdrjO4oLEiZ2b+qZbwR1ZHSCpGJGM5JxYdDi5dtEFXa6Njx/xDsN/m
jHLTSmfUjTm2WSzKqwJQeiDfUGKAb7JFxk5CpIt26lnHR1Z3xlf03EwWBXr+
2bsB9cear5wYZknExqwBuH2dWBYClYazYF0NVCFzXWDVnwCwjc0QNK95SR48
MzaFMo2T4KBuszZbxvRrmNoZ99TSThJBpz4o9n7FQrIVFzaaBCngbU6GME98
7bBJscSGhpS6Y/O8Cdp7wHpFylVZGB1DVojm7U8WnGZTqZ1WhT3DPDlh4x/H
rA6IZBQ2XgsO75bldZTdYb9ovYS1j5Y1idgaKE4PxOuGy1O5yzj/gq4jumH/
1SbIVvdbNz3RQW7yGz2wfDEboYFCp8F139zjz2QA1UXdx9MFYtnJ1enFBQpy
9JfvQJwbDneGIHekuhM8erSG4N9vKhoIsw3GXuR51wp/hU82q60bAMorUovY
TOSESv40LyS5UaQea4pjLoMZtADYCAkc3ISU9HWOB4djsh+DKo/xSmkLBBhv
RroYGQdkzlhsSaBaoDIfc7qhboBDFTE6+VSyCniOz88k3dY9+4JyFwr4wVMU
D1qvdr1Ydb9prFhgY/XjMRlYViTPtAZeaUL37Pmem5fC0Dp5xCBwB3MoMINe
mURSkD3So30uOpleZPWfVFDQCs1YLkaJMYS9FcsnqR/NWc5SiyoJrPIuvhcc
Rv3OOFvLoJXspaZSvqgSc42qHsKyEhEHXWaVJxllubHbvUun82gSj9F+jfui
ZZMWyVZ6MszTNKzSIgnm4zEqjaH1SDwHQRx1kk2AhKOIpwIg4iOuW8wfNlPH
5rWI+4kC2h5EcEWZ0aQ5msbhdiWwgzojDG+jGt8Cmyxey0qFehv+l4viQ9Gt
x7H+bBJgkxsl65LihvYeIQ02k87olEQ2StTax+gS6V4RTH0Jp4cHQ2HfYvEZ
3xk7psV/zRthDbyo2VVG62tjDymzRnPX0NwGpCWrrPdLbN4qmco/iXzbm8eA
IGyz2X0dQKXLM0XbKJEvlKtNmBxhrUCDIMjaOkem7N3lUfiDueXvMKMJ9ybO
KjIJ1y7m2I6NEAsARt42QUUT+jUlf2Lz5/M3W9ap6CUGkMkDN52klO1E8wuR
NJs/n73ir8JL6kyvYqR1LgXKv9lE0+uWWiGAi44zMcE+6yK6lp/61PcLHpTI
pe3jFxxn6xH97gKnKe/GBmGjtcK0oqrTCADifBdezDZKBT0Vi1kootCEajlD
c2Y2Ni76esBGbPuTl0ETLLAV1h1HAFnNTGn+lpPlGoD1+TPf2L4HlS9kTamc
zN6CjYTA1tOqXy2B1nwytP4ru8gTFz3+WQpU0HIuzqLN7YOtnj4j+7l9COfh
To4+xH9euLVvHrlPEbjN4byMoM3L+cfod5H3QefqXqf5LWAXjhJ9F+0NBgf7
+7s767/Z3N3ZigaDAS7Yxkc1oahBUieUzw9AbOEki5EkIfcEwVYjYBj2xB6K
lwwuBx/V4I5QXmHJTGRwfaWyjJLI2mj5iBMc8wgdsEVf2j54ZHzJyPJIxBuf
RNDUckdQMNePE85CqKJAJFZB7nCwrRcFMBS+/qMN6SHMOrk8IT3xFkBWLv+0
GWSEx3nMFW8qTFGnBKoXd/OPKf2/wSes2vEM/woHOOtnSbWlG3cYZdWb8CJb
IIpixLEgU0YrNfW6L4CB3wBm3jh/LSw6Sdls5wYDlSNjGd+CfxVc9hxUdNFr
MD08QhXiu1UIOlo/zI13hcIN6wQ9VXnTNbeFBWaxI5CVcd0yaX1vMQFVPPzz
OCvpBjgS5lLRrPjTYjeKF+hmUj+dJcVrxFnlhFiR4Ntk+j39p/7eI2Avv30B
D+h5Es3i8mNSPOTfbWxv4DMLWfuBR3lXY/ZOG7MDqvl3wu1kIrgNi3+RJMHm
hBJ/xe7oiydtb3f19njav8/+4jRO2ht8gae4Qip4g1au6Ho5B/ntGVf5QEn7
C3tcNrywiRfu1w0ReTmUiQxl5AdskUJytGXk/klA/JpOBSAiDTWl2Otm+B+6
0d3oJH9mFNySp0avR5trqL5dUYIenIPP2bci66WCRyhpoWk50YgbhDVD4IvI
EKEZFy+PWxKVGiimC//X9nocsORuUUogp8LSHfZnMJg5PhE13y7V4xAjTi53
i5CMQEKmgOe0i3aw7+OOXKAcn9tn6hZW6fBTjoE8B5ZYLzjXGmui6CoFLYY1
VrssMVLwfagLwyFvt6AxuogE32RltV1ys5+syHwTYAb3DEbr83NacANafNf+
uHEj4wsiw0c3G956/7T5jA4fnm99finzfLdBQszGl0H3mlxUaceiqr9mUdWK
RRFDPvHCpwINhPLL9PQmnpGoy75EwxscXhU3BCCul34RTxk+nS9KrPWU39ow
PD0GNkQBzfBgj7qErgFA0A1wAZWYG6pGoLiWVvBN+xIRiBPNOeQbRU5dCMrI
P3gjvJEFbA4GW4F4aodQufSdzYvWsU6Z9ljr5rz1RtsvQSbJx3ZNRgE89lsp
yrY6tZMNdJ2o7+hfbEJl7BsJ7IY7OENJyktVRwU3R/Gph4zUxex8QygYbAZl
LCoNgkHG4xLUsk0YBY2QN1vfiB7FPhg5PURlB3qjl9qFxa/aSTveU3xF4kvy
HUsu7sAEmQBF6TIYtNiD/LgOvIw9nav6K9StxzW6RkYBDnLFML4SGB+BknYJ
+7cj9N9Z8OrSurDZA5midNe2QiXrcdRqgKDnb57/YXjXvWC7vUf2yZgXbs/4
jo/08YkjnViHsrBmddD4HIdQy+f8MssjxyG2/2JRzxe11jW6oY82t26cbd6z
cHiRpzd4kDfOLaH6QtzwcnSrLkxghad4FLZ6MoWtnkBhefxuEluFJFaW8nU0
tlpBY2WwdURWXvlrqGz1VCprvYIrubm9DCbGiMOxzVsidOsmfi0pppP6uf11
kj/rvQ6zPv5eBFB23kkBvZO+pC0TWZrFnzYv8150+XGLqBPt36dO8tlq8qRO
/U76xD8+QqDsoeSYOILofGnPRKx4AUWx54uXnV9lBRyxKiMXys1lfoMC083l
R72r0wKLVNE9JhM6iL0UeV3KQPQJOQDxGzL8VFykCecjQ7HHfYVsEHUiC0mW
k8LvUYqnK4pNNfHvpyRGtC1jt0XWclsFCmP2/I24q4DCB24cV32fUl6F2EOE
iIWmLxjERkqQwEiMXYN9grvujPy96Eb+dtMT2VWgLnkaLT2L1AbVwHxzr62e
4L8N48N7v2YJGqIk/887UJwPSHtonAPSAh/N6COdzC9Esmqi+cf3N1LD6Hdc
JsyvGERiWXOWZMJLU3Gt8Qas6wbPkV+yZh2bBDklyu+7OPJu5VTy/LSQBoZW
hHmh3dEfKBT+6s5HjoTpoQlUSpVQnEoZnGxcRS7ybhur4srkHr3H8mUoD9zc
JSV8Mlp6mrvqNIIbAE57rJhGZo+rAVIPeFRKMI2O+r45kAk+lrjbPsAfcCz5
reo1cJ+DJbrsh5xg98MiA+pzgw7nm+7FU8CA1cQlQGBDOdwIr7lxKXEYiBr9
JS0LmsnWZhQwiS/wZVN/Ixfighz7wHpwOD8Xp6k6urjv2DMxyh444IGy/k4x
iSUlO4+UWUNaJcE2uFnMtqCQ5psrTK/4Ia7SK5SjvFSh/cE2Gbap2pdULLM3
0rtetlIJxQuVfK34NGldGj6zZFlQMl51LTfVuP5U3yjbCP13ODzpOZzKK7XU
HJ4GOyGB8CqNp7gP8fxhsIZMEOyM6oVbii77Smfzetly593EMaLjUkqyRuMM
CwDz2sf1DecBnzqTVRPt+XLQLgTHx7U/Ht9lDp3DVanoH1xlmIU8yURRaCzK
p5oAC/2UJn0VZ6kul8Tq5yCaAT27XWBgfEa18cTSgIW76C4vKCYZ6+bZ4CCJ
biN5JVnwSAEtQFECthR9J/dlU6J1tnsRX3ASSLw/8vsO/j5b/ztRgtW/C23Y
2qLaPM0VUDROeDntzWyOGblFD1u/we62kFYCOBFzYB7vigBu9yhGZcuM8Sd6
ZUBYt7HR0wnpez08t1AYmWLoetEYXkFIhlXCWjb/JCXEWEnwEf8xgcU7WZE0
B9F1gZ87Bv4klsHE/h2gCmBv8AsL+443d1Fwj3o7fCdyP8YLuD6mCvEzxaub
+fi41UiExtHakT4Vc0hNoAQJzqsXpoVMyR1+UyHPx1FCmcLb28AQFR5EF45p
uVgbW5mYJR2gyuM73QxZw5nVzVQC0Fr6a6sEYMwkHXJalkXJCxjJAhi4IXf0
V9GWWtp+pcfXgLHMuabYAjCQxRBRZICFzikZ7ikb+W/gs/aMuK5AIDD0QI2F
7XYgK51xAFMqJuFECytXNDgq87kmT0XhifhMbwV3fQ+ojXN2MNiQCwnAfYbB
bJRY4FkqLHDcxf3eztO8wf3KLu4XcvWerbH8NA7o2C8HbNBZE0PNo0mcTZGt
IO4K9crkcdXAonX4Q4VIBIW+nj8xQijDUcZiGYilwUCZmep4hO6/mLk8xi0f
ZZeP8stOhlk2Odn7TeZwjp1Z/Y7gDu/SNwNCKWRtlmVdP3qIZA+w9Ld9QyoJ
buV63b6x24s2X62yaiQ1meDYGLMulr5Su1MXE9TgdeF1/E+gDoHmFDU0JzXK
hKqTfNusTNgub2hDrwk8Vm5uwynugKK5kb91KGnnnyjtPhY3AXI7+otqgt6n
jgOvIbdiB9J13KQ0flr+quM42woxUHk84HXcaAJI5NMez5AikPIjUtACZ+29
N56ZS+PASZoIbD4xJ6h6wxDr07KhYh1ppP1bSKBD/imK2VO1MhzOU8wsoFQ3
A374o8XGqIQVwrlwvBKsXPYQbFwDWjDdgDUEi2u/0uZumEGdS+JHLNRSxmap
Z15+DA79Rt72DOdSFUCsGGxDR1nCBvWthiFb4rKPMxTe5gspoMT9SOz4eKCC
jt/wGiqAqX6R2UpOKhvwbWddZ5Pqr+DWfZGUgzM7oAF88kOV6kYxsb57ny7c
GHeKMaXC5HOLQ2qtWN70/ANCxOs30E6joYPYKxrHQQ5HawLvR2cVZ2EEZ9OC
rtN4xI1jNuDpBiubujdaeXuD3j4Y++H8GTThFuAS9fWkw13wnWluo2OlPKys
Fcdyy6WfcMEHgd6uBDbC7l5W/kMg2fWjMtVUoi1c+Dy8yXtObhE5haNXb+YW
t3AAb2Y29bI1QlX4w1CFb+LUar29g5d4eGpZgqe8N4d+XI8nUbVLlVezeXNI
NKHzvr5edhLy+10UEvO28CPMgYiUCVeAwgNRn03fUWHwvgeCVS8Kv9sC7fUj
vCHEaRM/6AlD2DKKA/QC4vwmvN3ji8GrcGjRfIexEd7KRW8njV1HFElJLgvr
8bwuVeSF49vFh+v2hCObNCJy+kq/SUtzj6zmHqnXxY42yUqsfo6yagO1RC1f
ha9EmukK55JJ7SiHOqzqgsPf7YVDD5ZHiZyWpDeOmwDUVJSiy8DYU6Nbtwjj
c1/fyq1yUWVXQkvzFB7HwFAs7eZdjlyJroSfMIeWPgJWZ+m10d/LdRQxmATg
1ZhiT96PwvHzTr1QPnGzeCE9xrxpBGZpUofV8J+Q2cqClgTJwQQ2UkhjlCRo
zgW0qSusShsBa62wOfFaw7+ekmLrx9KZlbF00V8TS3cZPnCJPC6UjUSwKpth
Q9GGJZk1XC8rKYirk01SLSBy/Klg7wKxfMmQyoMtsoR6HBS5wT4M9hoH86I7
2wmO6JWIaWedaSo2JVR2ZCMP7NwEylAj8sIR3BL5WrmM7Hm8nBZx0iqAH3iC
gpi/rBmfIKAyDjYivnsl+9ZohTH3JcotjMTgrSsj0xkcu+SZBSFx/GPIgDbU
c0aUBTVYI4qMjUFhbcU6GuTnRlkjt2OX1tMzviMJszsXaCqPtKyLRPbNqDcA
A50FsuapYh+erJpFfpkRE5QmcanFUl7KugyDyTTDL25ci4GeszetH4fAaeMS
ucuxunEerWAEPUnGxSnI14gpyQw1F7dmwU3AU4XQApkErooTYjWvDnF+0gFB
wXdf+8eqTRptqoIa3Gmi6UHMc5IjBaUX/bDMiCvWHe0d7RF+YoI5isKcdQYb
65nUK1NgiUmvdba0NIF67XKyGRxm1VqsTSjaJLujZ6dsuAMtQLGxoCF2txXg
ppdlpl+qpr56cpHJDA/UQmwJSMbr/IHjiZ95RSu83ECt6lk5h9/Ksots0fXD
XTqj+BTTV8UdSqJ60lHTNzZfUzXYv1Ip9Zmhtl+UZokud8MxaWEtJC42GFJX
rziHa8UEy8HFIE5LbZQP7y+UV65aEr6tx04hLxI00yyti7hoNr2Ad+LlW86V
3Ak8AZjuV/sHIfKj6f+JYHMdct6c/MEWx3IF6ARsXiKxV5xOQKpJzVmepCA1
JSvKBRtfTNJvZIiOTJhWUejpVEpPwnfY99CEvbG6oVQXWjBXKz70Iq3KRSEa
tuAgZjC8o+4nJ9QCNPsLkyv/BCtbvSgUYctimtr6U7b4I90kr+qx9hvExFW6
YMJv5IxW1kGxeNBuhvJKyElQPllO1MyoSJ8gQKvQBzMkNEHaDmxSH1r6TlXV
YiaN/Cgj33gE0W9WqGkdauwLy+gwWOKgrB75By2hoip0ljyXMSm3JJNVtoFU
0Byx2QMmbHRlobVOLKGSRGO6RN7RVIIujdNofw4zNEsVNWQHv7pAPL7L0ntm
KFqWlEtHczG37jJssGeVsTAZ3maMFyOqlkfvWmmUpFcYT8oNWfxciVJrSX17
w+ScCZC4Sf47SoeTlAFwwYw6wSO/T5DnevhEfZcsmkhpFiSx2WPdcxgbTDNP
yauxOS7mmV8NWcseRydrmkIhNSxTbK2uy/RUlmJE30zJDxdP0bWkNMXBgeCa
F44wr0VaLQeH5DUohtEoJO567VriI1WEqaFxMTG+R3p1MyOYxpWwospEK8oa
m2ZZ44g60HGHrPADwLlfyB8f6BPi6PAO4JFi2p4PZXX5c69ceTweF7ZjFP2y
0BKLuWuautSUMhfceeDIlAiNMVM3bBuLQEZhlg0GHazJnR0K17eedV8Xpu5V
ENzKAi4+/oz1hheIk0n6d6IS+Wp4EZl7jHCY1ec/eCxQxXI4267Tk2UbrMfB
a3PNQWwJdccYQCYL4kTgy5cvgwZdmWK0LWsVYJ8KGX70ei9a5FRkGV39lQlj
Qei0tZIJ13+Rtq/cs1ODuT3pTU8kzN0REOgF43EfB2gPS5sGLb/ypdtOo567
14NE22xIeYSd4dB91RA6G8tUp+trrsjc7lggVKanZNUHLcnYMj5L2Zr5sULK
7pwcxWxcsXc1mpKz1mXqkpydmNw5upOTJdHC0uPopFIxTCs4d8i2wAdGzjxH
dbKWQdngsHx5u66wV85oBewfuWTNCZr12Yj+cNdi81QyxFZOD+KuVu3+cC/a
1M4n10wJtxSRbRGr/cHBYD+olmhD6Skmq5EwQjfEVfghXF2MEUew9roHir83
RewW/Z5AE1fW+hfz3IU7YThvawqVLJrQNmMPb45VFcggfVsiKblPfapCFZhl
HCKDaEYlft6Z2aJZrlSnSZom4MukxGlR48xfptnc/vRpyz92Cc7hquHBmgGp
uMeGKF0J0M06mwoe11lpU5Z8Ji++p0Y/5vNPpOYEujBh5fZwiPlgcK8XLbaw
PdRAZNUk3JLwOg5cPUcVnowVSZs1qm09vDicM6WV0Y6/acgeLcyhWfyYEr5E
2WTNoMxiLGwosoV4ARX6karXXE/RUnwVKn0ztTCCuNIaYv46JNszuO7R3qdP
DWGDJ6baHpwu1ay10qF1pp3frNONWDdnpEGk9orGb7qmr9JdPZfQTSOKfYiC
4b63pLKkrRfmES8eDtVFowKyN29HX57AsqSF4rWwpRaaeRRgbeIyQauoo2xU
G5IB0ShRtRq4Lc1SpZiKTXQdljYvxyrzPCSjdBwvxEa9wv5mZvEUCQQ8XFGC
19Eu9aI5ck1Cs3ijUXZ+pFXOVwnKHF3YyaH2QFjY/CG2+6DWFz7bilawLQNs
a3/gtUIRf9kqrhamlmx5BUFZlOgoi2v13kf4nOCWfBHiRtAEIY1tm271tlk6
GMicujpL6vBEvFL+HZUw+G0MiB6jsmMAZIkd6itOUtpgNY/UtKjQ0424KmaS
+KWWvtR2FbC1qLlvy1OoGZ6Fhqmai4kzrzjS65EJKRSLcF4dPcila6nfhwa5
OyPG2Lb18yDuyZHCqHyZmwqQuvOICo5iwTPhMnJX2S2wcUqGa5WOeVcWQEyx
vpkrHIPJsfhQPIPyL/WZ/NO7929/eH3+5ruL/tkgS+tJH7+L51m/nIwPj4aH
owyNAMCBNzS1sTutEWeTsfvkWHEr2PCSK8nkso534GkzwWIzqltsqNehn1zg
LU0OVuRJELjhR0VsBKqDcFf2Hef/+qCzxedyWzHSmTeY+b5AQUXKTnIhOtq+
+k7tK0i4PLplzmIMQHyDSYnDw+hVOgI9aGcnGg5f7hy9HO5HP765NpKf3cdA
gpd+36QXssDnfwbmaF+TologkBzAZjYQeBsv/4bj6xkpufKSIm78RM5Fjj3s
sWqcn2fsgc6mGQvY3pM9TRMWuqrPnTQ72zmRz1qIe07rZ30I8/1Cu54aGOVr
UOGX7INeS9MWQUyOxT1/QO1aUhWNGqYYsZJVZXqLRghHqV0HjrCSbCLLMaO4
ypz3Y+l4d7UY/VlcA6yjCGvAKkuJ86WOlusMQH4hfh55BghwK4p+Vn0UI5m9
Hq0bYbSu8F0KKldVc2O0skCYP0hjtYz0mqxIpDR2mU4AAncYFgIMrF3ps2ni
aMsBbe2UIIRd5QCQZpQ2FEx2cF6pWngqJULFqfv5me2aQtoJOz5SvAA9xwUe
MloywBvdJr7+UITBE028McorAibV0bne8xc1Jgss1iLAGm2J5Ndvl4RFkrhc
p0vbB0c4j2a+kl0k7MqmyrKsY7PWRP+as4Xk+cU7NIWgisq+jtN3iHkfzt5F
NJSUofYG4hguF4HKmVbqsdniCOgTkOW5aLLTzdKuurQoj4tkNMeeW4j1gr4f
ST2X8FUOL2hYDWwtZ9lWMws7Fus17510sGqt+01KlGHF/HJB3ZHQFSn6RSSd
P509aLSMnuKYDGLFrNIi0bFZbTTtn3XE5mLX4KO0EtKges55j6VDHRUe87s7
cRg9BuloIWt2mfANShMu/mUPiTyKjQr3co8t1aMPGMbcmai15BC+9L7s035g
q/s+4obrUFkMWW+4AJoUyA/C+hmsQiuwPLUN/+AKc+QF4KwDF9LP69NeS4+2
6uzwEMKx2Oi5hnEV0XatGk7vr/Q/BF93my1QqqIS10F5dImfNIucejly8W97
8+BAU6nrH1uaIgYzTNC6Di101EkxsYY6ss11Ok4CLUIUGQFrGJ2vVO1xF6AG
J2BRQ+nG1Q7OeJIbl+rn28KxxutzaxuJiKVbDQWVvb0xIAt7Q8N63AMSbLhG
udcsQbSHoDZFI0ZPuuRJr01pturCyuJRcY85d0x9phhnKEUagegzf3gf3lXb
jQIrNaL0xjZ8wAW/N8qapCpKnOkw8a08Y5xFajhR46CI2z5h7UFtu7emB0dA
JnvRMvUs4TgyDSyxwmlifTK0SnRpAKNNe+v2ww3nBAqPWMOU7bj5bAX06LJQ
dC1c/IJ3w8cUziC2bC2x5GW3hkGJ1JIDDSJ1DSe9YHoza/V5Bp5K6+3cmfWL
lGyRa2A6pRbR9UPcsjSdcneUOtEttLFh9CgeWaKwyDP4BmW/vrxDTQGAMJQx
dkyF+ePp0sq3IjvTHcGhuKHkHCv7C0LCHUKuw1OPi7m4s724SbXn1LEUtWfE
dzO1+6dk0rb7Lf6rf3J58voPVxdX1owvK3/fMPOz0KjRFMb8IKa0RnMIv0J8
p/WM+lGxDO2EdFxJLzRek9xDDRxd+ChKkRKJlHaKoI4DIONaONtvS/TE+sXa
8papA925IM4pq0ycc0fGaeYC94LuDusukqo58UiMHGq1QRmU8AE3VI4y+Ge5
bKHjYF1/ZeOaHWqcd/Ml0bWwl+l6hogYGsDeb/7RbScj1UzbIWiPaPJGdsY8
VpF0SKdWHiopptznI2wq0EiJxcAMvfJJ21jW3Ipeh3b7FkTvK+oprlsVaVw6
3jKQ1hK8LK/qlIPHOzC7F7RwbjSPIOEJbp3OTWL7vIDXseUC90WwTU95XKcs
VD2TDm4HPUIXOs4x0ogJX7J5lqMruyfVVLE2HEw60jYe4eUnAzV3ziZjaC9I
54RDuaPGhBk50Ni2TDTj9O3l5fnptfGy548Hu0GYgvYxYU9U0OCVDIKu74lE
ECSGAJBRueSujhvMAPAIfFigsCHJFJi0oWYP28zZkmmfllaRnStF2WCMKf16
7tS9l+IHvHkGEUXuSEwgC71j8exN0/sYAwDiYJPkp2IMkXFME7XkaButssVf
oHIiXCdYN9HxnIRki7DMnTh4wC21P8V2uCsahIusuCR+buBJDPhQ3bV7U9vY
lEYkkzQt6Qr3sY6hyMXC+rEI7dbFI5dM6bW4NWR+pKASr2HiqXR09xq62xTn
GUGOY86iCSjYQK5MGM7l7MrNsblfNrrRrJkgCE4AsabRNh50eHoTfeueVu7E
cmLhnvvVutRxd2SPD6YgCUvjv5wISvdVqfkY9/oQlDtD6lotRiwx195+JNBA
3Ry1bwFhF3o3nfc8T5jrEJTGon5AcD5LF0mrlq/bokA6TZolom9ew01bYmWN
378/uTx7+wZbi+0Njw6QKoTcQbok/Uz1+ZA/I0JzxzjsSu8iC9l/yZ2le/Iu
kxFMtajSbinRRiBJ/DDhsgR+dlhYOEjoMbIvDe04L8XMsjybhfEsnX0vo3DO
mO+talErJXsyUeSPBqk7B78GqGuaHBlLPFyT2K6G4E12G2Xw5GTxQsgqG+Ag
uieD0Rk9/MD4MA5ySqYe8wgbbUSQtwqP+zHoQYgEG0rF6OSIFXUEJHc5M4XY
5hHRiM7beTg48J2dgQXSRsAEsNEpvGgjpvk0l1FViE2DTdhn2v9RnFmuTad3
E7tt8Q2YYS0nkR075SsTKLODkB4LD41zReXJogqGdJlGmXURACubi9ON7OtL
n7RXq9MgvYQbLbZp9xKIp3or6QBX2vIacLgjpyWRJe7r57pUofWG2eaAkgDI
C+KBXs1y7C0hs50zaTdNI+1YlzBoxpJ+GztH0kK3Fb+HveA1ILEZd2ELWzaH
D+K3vWi9JwQNa9ixZ3X1ypY6lCAi4iXBee9zxDDFfa0KDz5hug5qDKuVfk/a
sMcdZ8NmKHuktl+e5AsSKuHRSymB1Wk5xLVdOCIxyKyiNABm9e2ehVamQhMQ
mhhiSSd9hXnknIWqm2gsmUzaekHEsRdp6g8hWFN9XbP4yLUdXz2mRLf5rePI
SUaxU5ILLUTXzxFigURjTj024BP1ngs/CucVwlmpl4/BhcwY9aUUhk0QTN1A
EiPFpGYpxXP9xYvbmS+jcPRDdwyohtP6SUj/nmkbT8GWV9aVxOGvIGu8evv+
l5P3Z+dnKG4c7uweC1Z6uN2VPvAQ3oxGMkNLfrTp53IuNjdjQp7zMJvAWOcZ
pg1L/oGKB9Z0DnIkqaOvspxNlLFHokl0tIKZJaVW7cl4bExF4gWKN5juFl6C
T/FMczX91EFL6jZ9c1wY7+laWqGP0m+lF3Rm2KK6HJnXylxX4xR3XJUXDrMi
PgvZw7PozANMdI3SMuHO52cBxNC4JUcL4kdHUog9yCzw6Hknwb5A0hY0L6SV
D8JCpuaDUIDG0pIdh1Ud4g8rIGwDnHJcLka3xjmsYrpsNmBTrHcRgKiRcI2S
fDlDGuIOAHuzelcnSRqyWdSHFS+xzPeDuF7jKcAxWUr0dWr7+XQG5Yv7RSlP
XxpsU3AbcTqv0nac4/JQs+C2iI5e1S7pwW+vaSUn7VeJsPUPBDB2rK3qeGuT
BvvuGaT9VkCzZu4yzm9pGGvJ03IZFjC2IhUrqe6C8g9s62ZaxHM3JGHXVTax
6Yw2Z92YN0WZFiRo0XQcHc82Gh95OSZrJoK9Qkyat91KywA0E4LkYEYpaJcZ
5tiw1QeLAaSakIH+8Xzp4XpO3QBioNh8C/h2K7HCFM64KXbQnZyCnlmj8RDj
p6Z+MpLtkoeYT01aV2yFsaQV3S+Cjea/0C4f6FZxqILDSVorOiQahvmvRT2r
mOrKg6T7bOII7F1RiF/eAQHj/EbTYvyRAi75EMIcD7YPa76Ni5JT3kbqt/Br
o+F39CXFPFrPEiM/7KKv0zQbEzZ6uxrb2xXfmmYf02l2V3D2NbHLFSejfmDh
54aUa9/0LgBBHo8m9nlcoxWQbeCjRRBmZINxrVNvrNVyfOWG2B+JWS6okc1d
0hTZA6L1LSmOIJMX01jJd8FgAQ9FJ1fkdUQ3+cR+iNeNAi0Zj/10VasbWsvg
BIA6ivGc6b5rpQPP6NQo1qCzME+QxCh3G6bLkO1YxueVG6bKOngmsBVtpmBz
n6IT4+k/lDqmhUHsWnnuvhoJQWSg3s88PSx3RO5P2D28M0XboyUwsAy5MX/R
WD7itmmOyAInfYVS9xiLHyRFpbFmGgKhouAImPgkUxaBlInQh3pP8CXyzXwu
4kcKEEnGK4WXOE8VShASPsAI8aQYAgk2o7uBV7Uk+s8BHKGpO5S+tS23/wEN
hcQoyMsS77Juky4dbRSLAc3CrbKFajzFABWyXcTsLqprPDb12mtoAIXXisUT
LxDVsubBy67RpewmQY40VuV+Zr15grxVloqRZbjyBpapeHylnwNbZ4tppS6T
ykE1lhQYXTAI8ROWnOPhPL7S83YvrPYhZu7XdC7xaGRKZ60ZY1hpFEqWYB+J
RpQx6LS8dQDhKx+hUlRGpS1PzjV3HJ4oN5A3paV6dAfLdJFYvBtRrohtqPsx
cG9aWKSSuQHPdCAOUqZLpw7gE3XLfn5WY9GrD9yskOJQbD+ktprEHKYMPIu0
eYmJBF7o20NtkEQ7SoVPURKkFYxw1TMKVLTGcs1kIoIkpIc80YVlpr7Vf+Ft
w0uPoFWYuun8HrFY0VpbJZZaTDZGcZJ33Wkq9cu62KUiVCoRTEy3YNIRtiN6
txsG9Ls7pBOJF97yhFIUa8JqXAyrJqwYyUt1/pde1IKTVUVUF6Ua626hGktr
fKrrGWydxkQjESvCKBXKgsMLLaazHnAK9vlY0kZiWBi0NxuYM5ZxeTuguGAa
UtohmtG949MLrXBAIa0zl+VLnpm0SB1QSpMgEvAObYxonNUSkuaVp6sKHqRS
IwtJF6rA+a1zcgJ/n4p1k+gPt5w0kRzlmT6CRSmiA510RZY0e58bEF1VZGH/
n0oagDi159EDXsi/kE+DaT7AiQYIT9PTkeiwyVjVih7J1BTNhSTEDtC6TSAn
zWL0eiJSrg45o2wNsgi3olQKUZDaFMmJ7l6hkk5jNMPRu01+XJVIWLjWNdYz
br2NUZDm+vVV4LT0FVctF7okg4vmCsJy8yRGz4uIAXgq2TS9JQe0CJnC6yhX
HztslepVhAOuJdyN53LbxZLw6ntjcSKb4TG3AelZ+x8JJiMswrOYo8mBU/Cd
NmTY0QicnTAW1aLmTFH0Tr6kwnVAOjWI0S/3K32Q/Hp2VTOheXdwhDN4Re4u
RF/vKNln/MpuoZZMHRWEgGmIsN+zR8+Jslo2uX5jUGVwS/pHNWoUesKgZxlV
uEn672Al3a6ctc2Ht1qnRW7FNEu2PKtGpqKqSC8EQg4kryi6hPBP9ABQ1bM5
F3TrqCAIEJ94+oZpJfseqrl9h3utdf+4iyUi2NHCIlB36FZ3HNGjRewlqMOP
RvUPT5zMGttn2vWYPE9UqAR6JrqW621tPi1CFpkhe6XKTseThGrptUA9ekwK
LlcFsFUwXQh4NQYJrswKiQW3lSNEbJLbw2HYj2V1dsc6h+nNYVx3e7COMSpX
nsMFZli7frteXi/oM9n0PHX6oNnIq0OICuQlaaqQXd2RbIKFZhY528LbYl5c
cVqPnZiNOS4eAG2mwObxtDDyCA2nLu5IbyQODdoA/E3YPKLkXTqdO2pyi30W
arZVsf5VNeIiL9DHJB3AbVi/HzH0dafZM+xotkOt1kw1nkOzqZULqpJFdb+m
UieGkpF4q6qkV6ykWydCQYYDZ3d8xG0pMtGKaMqmLrYmoFJkjllWcQqhSxvB
hQd0TRKEmpGNfnUWrQ3lh1diZ6+8T3kILlgHxDLnFyo0oBPXusHVTyvg1jNy
+Rdz9CdqkKBkaNoX+r4PTmXqbFVEvDtz8z7QujhexbEIDuFm5hgoIp5M7rSI
KjVOifMLV7nc/AoDggsV5kml6glTUXVAXPOUvGk4+U0ps010oltgm+2pIO1K
I8pQbpWaZOVXCWDowIie6kn9tylFjnfOnAcDet5QJh0i/WP1Wyy9J7SMMfw7
F2IGfx27OCEk4saqG8Tgy/R2wdGu+CrfMXZY2UAo4Vmc0Qlbw9im0KFVUVue
tUlsoSPfD+OxfV4bPc6t+8tqwCB4wlw1IpOrQavNtviaUNyj5vJxHp/sLAls
KGxr51aumhRIl25vZyfa/JBL0RRS6SXzdcuE1S5O/LGs4BPTCH5moRy7vMwR
F3aV3vo1ISuEAktL+LxTcXd2Zb8mhHEJBK5YHozrr7ozMplC1qjXRCYpd3pJ
uWCIFswgdcXYgjjsqcPXaQBHU7obG3E3B7hLZ2Rp5Qa6djSRZzhGza/qLBU7
QFjtRVQ1gY0siI5U795WH+dudTQY5SDoNhGyVI+yQiFrJP4L5uZOBuNWExxr
lJVSj5K6+UrVglUdC+TLBzjhMdJWvoPVcgYyfckRo0hXMxtbWzVWRG8g8PwS
1BpAOBY/iD1Qsxa6nQXGXeFvZDQnzNq5xDc8+OJhh0uRtpKRmK24ZiFLSHPW
RH2ZkUCtWaUk2LGSxUbTOUkczrqKtveKvLv8kqp1LHzaKMvzlk6sRElKL7KG
LMvpLtTghdeSUeyOwkiB3KcUl9LM6hANlpgJeUNZ6xOn1WrzFVNXXovvCVmU
CD0sdShWYT9m0qxKTgJEQA09jUv0gGLPtEYNI9Ip4RWuNAKq3j9RmerDIZf3
VQbWZ+GR4Y0ihCvTKEZLV8jFpSWzc5GhSmV/SbaWQPfwaGPdstjr1YqHZudb
Dm5pBBSnM9QVcFFl6kt14X5R1rRNfAJ1y/aH9aLGPULUOE4Uzgh/DeNvN/I2
RLj2O8RgsQEqI64YEMTNhNSC1RCtIesSZCMvvwTFRs1x982Oi5woARE12RQe
DhU/WdzeYkab5pBSyUx28aGEZqV9P1AgwOkV4a5ogC/QEMWJ9ei2RPcDWUmQ
ZsUGC5o4CHilDT1+zmYflIjJaxgFtfTCwrzmIbbFfpBdccUMKzbx3aRyFjvR
+/NXH67Oz369un5/fvJGcva5UI8LQT0abA/2PMV+q2ftCC92o592f31//m8f
zq+u4b//en56fX7WPU505CqB7dIolKn749uTX07+EE1KKrjDSi46hNKcg4ec
sLKZ5S7xgHmPEa60RSgOAIZjRJWO7706WMlMGdR+LMYgspcIDK3rYbgo9PY2
XHPLO+AjDMoFxuzGozh/WzZZitFUXJSkho0vuNyyUa7+lQti80YMe+7Ldbfq
TxU0I1hBoWBW1lVRRvFQPEin8ntHVIwQQZAN8EzqvAL/KFGp2wSpnbp5BSkz
1M4I5T7JLqbmPdjJQ+OJvE6nLsmSBGQOncnUh9XXgHx+bosxYAkKGEejspKu
EP+qMCjus/DkBe8BLhApcVKHRNoQjqEm+gAq+UzKm43E5ijwdyqnbhRpZqjv
2gwbCmnxWmmozIoBGpUZBwXvWDqJuMY6EbXQsaWxbeiJoqPyk5d90yAdYfoJ
zzdDv7p1oJHu6aUay440LEOiIAl/HCOzOTeuUqrdKJEWrjNilANRCB3GDPm5
TbZ3dTFX51UiDolmicRYnX+wutfqOA1LzlrNuYonqdhsK69mDMrjsJlqAsAp
Stbpke4bP8Wp5+U4UwBHYetC5ffF9N76JGdZpdUWSQZARcc4d5utmQ4gnM2L
mq3A/pJG3GMCGc+CiwpZADLQKKKlEROZzdDiK15moPbFbY72Ji4WavHWm9P6
K6xshg2ErQNGmhzL29QSKM2t1i6HJ5jCDjyrNfVFnr5RWVvbUXHwapBB6hwl
dMMkh1jb7rHHgL6u8LJK/KpL7ypTY0UecTZ/YOhiLSU6yBOkfyxDO0eEWENs
f4PoBt+/CUtSZt1iXqUlg41nxEVFcV5mMB8GOwEPvrXIwYWpOnsatOxMTnnG
Fl+8JtbiHBHX0HG6jYQBAQ2WiGTJSF67Qz40bTvJqdW89XUJaxI3RsLcjAyg
fuhGGKyBwiWnrVirh0aZBBJo9WjVW8RSDWKXbL+gtjTX6qiw7AFgaZ4UD0Yq
d3PHAMkS82vtcDiFx7weqXJHN6WqCxEP/C2rfFQ5hRDj32gdMO4VfITX989i
4Od+lkZivL34ZDXiiIV5ZG8Eyrp+TCgnFag4IEXvHwGfyNJeBKVlj9aih5bE
nFGXhD9lHhTSWz1gCRi3RcTnjEQt3GfExU9pe21cc5kbrXIJ1PtQcv1FSyAJ
Jg+GH6xv7hs6xDgQSN1ZNAqibFCuxlD+OXW8axW3FuHR352Cip3gIlL6U5kG
G2emTTnHnuBWF1PgnFryA8f3P7OxdotpbWCMhiiiZVI1bCujhKY/kzkUJvqB
o6BpRerOm8FI2XwKdBI9wRjtMqdpq6jfl0tgnRioRcApKwODF9SiKs4HFAmx
OMxHEMkM8wkURCkZm2M7MF4S3dW254MXwcqAtAXX8Q4xdwG5MEj8sPGixBMw
42A6VWzof0zTOYxOyQ42iFHOiGZjb7QXS6BrSil9EsRQSuGYUl+OdShl1S7O
YbWYJJPF2qTYz+wgV77an9nWKOVCSTQUOaQlSCqm8sURwkBCjyy9NbtH1Dx7
Jcmqlq4FiWjPQNegOodckAYjfs88zPv8DEu+9SfZpy9PIcVWL/fTRzQNxzIb
2p0tiObdcQxlYcDofrRMMRZ+TylT1LffMmmWMnzmv75eJcLCL1XpLjqa8hwr
FBXasnZ/380ESCSni9zF8NnqkgR4Buj/r9Uld47+huqSBGy/sGRC3F1lMJul
6NDHC4QkX2Oj5qQH0LU1J9VuR7LiK5wPi06eZZUNmbRVKSgoz6N+yOnIvrau
76GT68TV4+WOK/lXy+/vL6/fYSrX/vFwH32cNnKA2EjAW5oh9SC5z4qc1Gce
zeUskpUEBj99/fb056ufz3/57uztxQBLqW/v7b/Y3d7dPd4/GMB/AVkO2Vfs
MnJWCcW+V9y3vLriZVJR1dData41tbqtS9vUUYJMml2CbBd07z6xBNFs2f1Y
E6DVQ2lxFbFHZ2GSqbUX9KyzKU5QdCN3m3Xs06Ant3Z5NiisGUu0N9hRk1f/
9OT0p4vLHymi6BfWZQQkYY6q0WRz5EG2jzetynewyN6sG7RVrUArGxjt48wU
I46r+1vzvK9/nkf8xz3pN3/zfnpuftPDjn6TL38ToyVeBD2O3/QnCSCAvxp9
3/8S/zi26/32m2M6v/Fqn7dW6y/5ebja57LaYDr357cVf6d1/i3fKF158jfP
v1vz5/vwUL7/29a29htkGZqe+HUweM5EVL/5dt2Gnn8b4td/L6x/w8V+mHOB
W170o9/8N5yPz7+IJhAXU/b1XqmEEqRgA5Z12deyGeWi1+SscxR6XVeZAsPT
xJsCtBC1BWO1hUapOW7JxPbFRCxz6kqjwHM0XqGSeOsynU2zEqOtz+xKUqHy
o9HYNZcLKSjZlY1hGMWGAmZNiU3k2Q7WQOzL5uFnEuVIayGNp0wfykxSFwJ2
0MiK9kVnr4UCO93mWld9ZfhMEDvlFwZgfqgVlZCNOTXS9+jVpSaYeMrdtSYI
2lJxxioo4v5xombAtjhaNxU31B1VwqCYvHXKjwr0kvrL/jJnrVP+50sIoraI
bU3cK76HLgsPR0xUY3SseUNvjpYm86WQU3yhjzJnWUxvpHgTqg6ASDd50SeT
zA11feBkMJeeIlUj4sptBQPL8pWShkIwkHk2saq1XRHicl18BIzZEDWBNJ5/
hwMOZaWtZsUhPCo9ZTqRp0s0GsvBUobaAP0Eaumt7Fu+pVuYrf3dNPyg6zUo
S/AV67EWQps1I8EOou55KjGHMUgNAxRO4fyW0hjJxkn7fUU4X1Her/j9MKjB
OoGNw5tEIxkwDWuSsulvYoN0wsr+mB0g5A4k5OZcYhL3wREEk0pMVaM2eo1U
BAhRamNHi2kiZmxqBBPbOiBSIZ27OLwrqhrQG8PnZ5hToIXLFUSc4NgC0Bw/
G7vPbA1jv+1z6GP2eiCTzxiV9aaDblUhMZ2HrN60cakKRjV5hdJxhUOxaIoc
oX2iPGu/1pTGugk9w3kL4vJJb6fZLUWxkKMIVMdinMWagesiMdyC/DAp3hO1
WSHTjAvdau1IaiZ5EX+UxudSvyh5jzxgRY45K3xklFiibjkHfJrD4otNEn4s
VtpbJXM/yWD0bEjizuHQ6dTYYrEEZd8MLZWzCJE5QCdNnBMFX20U05EYDzTq
Or+oenqyie6ShyhTb7tJj7mLxqeIY1K2rSA0Xi7Z0tcQH+8mHldBPKnGZfJI
16+vgJp9cJ2H7bIIkORR1IplHV6XZlfMcaFZDXZdFvgauBg8RF+z9KkKMABj
ohsZOprTV9Rws6RMvp/2ZM+JyhwouH3EElJEPhdOLLYxoEVt5SnvqMJCtmzo
O8eqcVglsEu9bxpaKhHiJPZlXdkaFmhajab0ik0yvDhzIMsuVuzz5w+/XHNG
R0d9GWM7ZNwvpoiR4ssWL5G4M8njHVGJMe3dIsb2oFwk2oYSgOJfUo/du94a
HqNRULDXfKxCcF0uUuNLCZm44iWCzdZpQDRnk452afBdYnx3MdTfhPkgYc4f
0TtdXuaaIlBw35+lYmzlV0U2nh3MOknw8N+gjBWhEc91weAKxiR9SeJLu7At
/cq5SF7Zj8+fbf8XtKeWKZeC52YeyPGVd4jZpdl72RtVWyix/LbZtJNgiS3z
/tXpwdHuEYX1YDRtVke3CEIg63dIG8MaJhrUYGXe1VY4WV53rX+so+LiCjJG
Qj9IxoQNtb9x1bX8YZpfwfbkPduDe+X8gETJVEUHzfdywKu8M6Essf/AjCY5
0S/MUu/JQYc1/VlMjMvaRtna4DYMKChoncAspwFSplX3zBwSVRVeAmCQCFep
gcsVlApr8pkw3c66CgRX/OB1isvOl978g2aJeW+WMvWC0xrtb9pFinmWvmRf
aKNE5gN9gS+jmSIxd//h8dtJgkE5RR5v7BEgG2duJ3G9WToqd4YeH1iF6VoF
R41JHVQOm/GQqhGcA8vzEucOjdfqzgbeqHJv8U+dsEENvirACJtzJ2lFHYlb
SHDCrhtNmd9Gl0kNLY9b+w0furuGdLRy7e7/4afhreod4Sz1UkWxCsv7OdLA
4JYQHs9k4HpXIPMGHYBdfimFX2gsnmTjiNsytdb0zmhiiwlhixIjog27JzTE
Pwzu16RTL/mmO82nmbJYkWDlyhnAQO/PT9++eXN+eXZ+pvi/rhfuSavmvXX/
aRYlChJRs5VKRzv49glTUmNE3d39/reuuVVzbk5Ll4znRrG7Rp4S2k9uMbl4
nbzul2Al2Z43VdhGSustbFoi9oHbgnmrAb0jlabQrlus7WXcxui36mzodb3A
ZZia1UvWZ/zkRRTU9kE7kTM4EKjH2mjiFYWoYm4PVX5fOy6z6X5fy5QtnZhN
eYzA8VdnKfextBvDO00091UBSD7SsfRNtlVk7CkPfKnUOm/b6GkDgeD8ydFS
dgym6Lm26QGHPFIteS1F5sHtCTFOjUrxtmo7XyHNr0ddRHq/dOMHSdbhKEup
VcORjJpU6ONjWA2S1UgbX9HKxcWwkVJz9P1ExqfQCPMseifCU6s3m0pLxmCT
CuwaZOUXMYRoAxEQeEkRSK12EQQG8uY4enWaSkUmFOBtv/ewbLut/mgNDIFk
3NBtuqu2n3R/HFS2Xdm26cP7i2bvHMWQlqTee8zhDIOhoaLV31Uk72wS+YpS
0KGYYk61wqdEDFvPg1Y1M61L6zv+wjIDVskLgzfVEoqsvtESEIgxFQDxkuGi
izPHItqaS7NIf5t3EEQe62NrCybyypiYaus7X6frrK1vrarrquGacpEHba2U
hbgaE+sYEMejy8VboDmOrHYSVCfFbsOsqwlnM9kc8IRL1FCsJDy+LYsFRlRJ
zroR6ziZfSyjpL4WxpxjDKLgUCeqk5AuHRWcwScokIO5SWZOaIXcQ8KX8wlo
wpmo+55q7YwmMm2jTQYWpciBI55jBSoOptcEPVQv7K1eaWqiiqiU4hCq449M
DKf1xvOnNH42YTgiZm6NlTG42EREY2vF8cL9Kc41zYMGGFbd9OL9pVAbBYZ2
9BWmW2R7LNriPpyhBRoq5RH5IbmeZCthp11nXIVlXzx7j8T75nAEWbKAsW1p
GtHjtWRuEKwe3xdZYijGgWqXUAivQ0pXl8g35D6kMXpgFCheBjmbg5VxcWS9
RAe7AJV4TDJ0E5nEPCH02lZzMTqc5ooF/V28PrHCocjZo+Yl5JSzWZE4fJUs
u5ThRRGdldclroVn2APk8uri6vr88vQPfk5RIflBk2YmZ/dQYsQFhluRXtco
SeSyO1r9S3yHAiVEaioLqko4KTpEXEcOpjtmdROSVm9y7WaiiRCeJc0OazDy
Cq21zcYoFr20kBaPST1Own4EklRoi+60+pCh5t/RZER1hZm2VvdLZZrPn19d
nL8+o7AeL3MQxwr6BVpi6m4IsFuKZaeA2AbYRosMHQL8AraLr5ZwbjPmohaZ
Xd3MVsVrW7cE5K23mulI3dGS6MzVfmmJYK4ujGrsNi3SNs28x2oxi8plUMq4
Xk2Z0BIhri7X2id6C6QO3aVaB7CZ0pskUh6GOFtxW8ZzIDtkTcXPaDo8jnwc
VCI1vhAea6MEP0VChdLU1i+j5HZcOCMc8gepPOJZpIm7wXK6KnlpPU+iZVWk
ZZhcbLTxavdzhEPCUf0aYV0Xc+w9teS45nqRiBtNc2358AHX3p69/an/7vwa
U/QmHNMtRnFZP5CHTxT7MJWyjbo4DECl3kG2kBaGmFNLl+wv5BJwaxTADiQD
XRNR4zkTZZTTi0/LPuGmYom1Qag1B6vYf0JnEfDHfl30kU3OeIgVpomGSPx4
dcF2eV289tZKaQtDPqmtDEdPT7EkW1geRIqqPLoMblaE3JuAjWxOLrP0EeWs
uGYHbNymZQpaz2ftSiURoJLCq9ZY5WrSaKODdY3vpEsPfkJbpy5Zql2HWfYr
AkQyznzykge9TgjUSwqFHRIdWeywtcolX8dGUof900nZ0NSFlfiB7QhQ9uGx
nEVpXUgOV5cmKypL24Z0TK73J3XTbIVfJwOugYRr3WgFIusIFqUJdI8Ic7WJ
CX7+/Pvr8zfvXp9cn2PA78E+Zk32WLkRwUpzNtaUb9P8INsfSzPgokuhKH5F
mgZttdpsu2Oe0iPiXGgWyaiG1S0GUFnDgfGyH7WDj56ek2QkP5bLmgHJv8Mo
YBsTRWPDu9evr8LOc9Evd9mUPaneOuWLNAmU1V6wTpCskmSajopP5Cwh+u2l
eUoOfLSg2DnB4AfP7d6qQmA0vmUc9DDw67R0+2fgkDH6HTjNf9haD/KATSCN
qbjOjPAqVAtm9vBUqFQzKhnBbM1aamAIdM7V4A0OjgKX/KArL9zOMraweQkP
Y4JhmoWAQQ6guZq9Vbvarse178XgEAHV87zzYjHl4uTypCGQGPNuSpVW+dgI
6BvOwVltEHZWFABXm2/XJh8QGDjr4Hubc+OdoNnwUx6c13MDaw/Q+bEPdKvn
ysrwW3DQ7iU69a0eVQJtvVf57/FY3IRIMYp8DQlXAphIjRB2iA46YUGgf8dR
iV8PknY+hoMMYzVHuRldtL6LT7HFHW3SgsptTt+zP7lKjd1A9r3Wn585aLNa
svJkfO+yazISd9iIRClu3D1Ue/DjPJ6lL40Jsl6MuVqM6uBXNzX3b6c2a2hX
maG7pqJ3Ll+cwA2fiyjV9eM50F12GwW4Ti9scLXMDepA1OXUo7fUyqou/S8S
+0oCuZRc6fiMZn+3oDaYqTPw0hv0AnuK/cegT/vqrrVxNXz79DVJQU85i7iy
Noqm3E+NtePOKVsn96qMudWSV9tj1a5PnHTrqYX0+7cJaFdzqr323QZxxHG9
8T0s49uk/v5NfAuSFYsCm9XWy29fwMNvk+R7GBX+nuh7ZxgXwW1842mGgkY8
s6l9ApaVH79Clpd+AjKJqZfrpnmDy6yLCsQe/IaAjTlyK795kUy/hzMH/BNR
M53F2VS79rGCntex9DJWY2ETRIhvJ9Qguvrn6IS/Ta1myMiXJ8QagdrRJ+g3
fHuJ14QrNbNHK/fe4HOhUZ80ySlpa7TeskDjJX11cX79CmPnWycId4LoTYtU
d5AapNlCaToou4/NuRcEMQockUFdEqpIIr9L0V5l4YGcIJ9xeEhAajSjbxUR
gi//QYPaNKhNT55ETbrGQxEwcv6LoLBNx9FX/6BI/6BIj1KkDoLUJfuUtkB1
lwj5NIIkFsCvJUj82V9Fkf4hFf2/QpFc5N0/SNI/SNKjJOk9a4w2olxym3y9
UilToAHCplBnj13qkTh9NGcZXUNYk22pwW5thdXpqwa+j/UaUvNqLfLgqNGH
9xcvYUN/TZUBGAHzKfFzSpy8LOroxMZQ4yGgr46PiFZ5xTUoTgF18KO94RBf
kkx8fPL5sy2b8cUFqkiA41fB21Oh1wHdqdP/30DeLtkDf4PStRVEzSf5W47G
TqwL+poz6mPsWTz+SHapU4npjLSOBPlm/Nb1mjZtzLf/BF/+aOsMsqmQlhJt
Kuhus/puMRrAfC9mGDGRw3WeVWrZ2Hpp3n+4uv719dsfv+MPx3F5W0Q1Ttb/
n33pzgLEs6p6HFzWE0s6/JoXfeDn8WJauxf7c1kB/D7NRvgffhXYh582+KtN
mcTC6cB10Xbbv5t/BEzBBLT8n+toWrCdiid+gSVxOfXETyMbAPy+J088N5Lw
G3S13G9UzOoOvRWYBjaIfmBGJrVxNhFzGtFPLm9Katt6rk/Xzz3Mv621QeoW
FdTkCTOc81OcAGefYQLD9d2KtdrWgOQvi6ffsK2O8zCNYpXWbBF3wp3EHDY8
mPPUOfcv8uDLoPgDe5QCn8harxC6GYqJuVEsIx/dQEamm6o6qj7L05rfuul5
bTPh3xG3DfHswrN4HvnhT7Rqcmw0vWpdoVduUTo14n6h3+jCbvgEmvGMFBqX
DdIBg8dG03shRugymXHCu6vwBmOWS6qV1jX9DdI19DzdCn2UKO9VUXh2OZos
p6ateZxRk+IQB2pXlkk7r5799PP5m83/sbO/v33ci376+exV/+qnk539Azaj
2nGxwjS/ZcdHtxE/oobfh3toDyZgyYteKmGGAh0VBko/9ZPFbG52x9sHR8eH
+weHe6OdSXyU7h3sHx8OR4fH46NkPBkeT7bHh3vbBzsHe0fDUbI3PoC/T8b7
o4P4+Cjdjqk8waPdctQV1W3yk6BNFwppXDl98luj/D3mFL5KbOKtjQy3h8Od
4e52uj0Z7seHe/Dvne3t/Z2dYXocT463jyaHu0ewyzgdH+9P9veS0UE63EtH
h/B2nB6l5vD4aHt/fzgcHsH/tr3/7eoes6pj8Rlnw+GFLkaYudJMaqSzyHth
dIZxqEh9WrVtwY/n1y4T2+8W242nGCRnPOji+85n0NFcqQU12N7e4d7+/t5w
/+DoEP56ODzcHY4O9g+P4KSTw+HB+GB/Jz3YPZgcJMPtnYk7cA2a4tjNOHm0
kkSHsTdPTJVOU8aM2aKWyBf2tgIk4SLY/uqDTpLoCrDTMMa7O/LlVX9756j/
4+kbvhX+sr37mnOZfm0pLVVxjKtE7t1ah5DOvU+Zt9bTT25XF5Zqz8Skc0z0
KLEShr2WzUMZjfe3k/30GM4hiXcO9o+Oj46H8fhwuLszORzGyfZOupeOR7uH
8Wi0DUc12obNjo/He0fHx8fjw113RCvvUZsQwPU/mhwdbe/u7qaHQBT2JpPx
3vFxnBwfHh9Mjg4PJ3vp9nB/O00Pkt3tEaziGHjj8cF4Z3g02jvc4UlPGJdv
UP+5cao8MJ/mfAcJ4Nju4S5g2SFg2AQojODfzvAQNn24DUQJ39jja7gz1Csp
M2GCknrGrrC0iOWeDu5B5wUg4hg8GtpFNOSr54ojekjF2h2fZ+NydWXmdNMk
XffXQ9iEID4AYAB9Pt7e3T8eHhwf76TbALTx/vFeshNvD8cHx/vJ0f7ReG8Y
D3cOUhjV7KeHydHB6Gg3Sfb2hqOd8XD7aH9nuDfaSw5293f2u28zNTMQtfuR
yBgqcfHu7ZUlWz3jxYCCSFh8pAbdDejZWnRlCDm/Xh2NulowcVXVfypggKgl
0zRq1rWM961idYdHIKN7LumVCVjxqLhPv+9ifQ3o2OL6BEtffLStM7P68SCi
IK7WwXQ10FriUxNYHhP5vwGm1V2FfED1lKjb0H7gdq5Ou1eBNuiO41uzLCVw
15xiEen2s6whvwyik8YxoS5IFWVsnBeH5TMTWCELdlRsdr0Ys5qUDWX2DUbf
yuW6vrOZaRqxr0WNMok8EUljRTqrL46KdmLLokSbEvAreZ1UgTiOdrDMpquv
ubVW4tobjo/c8TZreCgXxGpGn5Cfc3EB4XudNPqlKMnZxxn3T0P+L61GI9Qb
QxaykxwdxgejeP/gOE2PtmFBY5BTtyf7O6M03j1wS6P+PCmGhDN/kDCGBtZq
WZJK2w9S1p3/Dgjp1N3K6/ntrnQsZQVQgCG8TaVCuW2wqvwH8Ghad/DEv5kH
jw+PjtPD7f3tyXgU7x1sAzOIj/ZGw729g73j7WHiIEIr4ABVOg5UYGnP87hy
3eKic4G99kTWvEO7QTggsxnoK9zPlNI04mhepYukYLjQKbQ3DXsDATxOhwcH
4wmI7PFob3g42t2O073jw4PDye4ebHp/uJ3uHe6Pj/bSo3gC4vvheLwfHwBf
G7k9tSbTbFerIJ9/mhPxbexGpcyYW/q68tsbZHULdrR90B8ta0Yp2xVVoUHl
6Tc9kXOrudt9EKIPd2JQMtK9naMRiNg7x8Cx03gICsmOntAvumAiOLq85v56
uuDILZgQbsNrLmsJJq59h9dOLzVXNjkYTQDoo6Oj5CABZBsODycgfXrSJO3u
BmWtza0bB0RmAblN9hDZSu6H9qOWMusV95/WJmm2EIdcFa3F4SC+8p421/8Y
7h8dTI6H27vp3nBvkgK8t/fSw1G6F+8BwdjZ3ZuYo/3DySj5eoXW0r2H4NSE
Q3YxaSv9ILV9+7MU4P0FA6J3DqN/hVPdAeU1Gu693Nt/OTzkArx+rbOXnN9S
A1y1zNkjbLxqsfHdx9k47+t7n2rMPDrP4gid/cgrFLSicZcXTY2oYDR0kOx8
wGWmWV1PU03EJys810wL1DZFNq3/Ihl5JpD0M9dmTW1XjF2WbndTfsre9MV9
bTfhuk348kOA4RymeDLWLg9k9EYbMru+0uS7jUk8rbAicVC9y+8IG+vDMMT6
rPip16w48nuM9keDz/HO7hANPp8/fz6L77Mk+iHN/xwDt/+CscPw9E1cfkR/
BrLfu3hGj3ET8NN5mY1RYAE1cRrDD9Esxvox1IYKM8DIU4Rt6cUkiecQs4OJ
U2owx+0jjvQ+ns7vzI/ZFAMXed7XizGc5TsQchepP+l1MZst4fliuvxCmQro
LcNrz12yKpRJOMHt/wArpFpKEEEBAA==

-->
</rfc>