rfc9458v5.xml   rfc9458.xml 
skipping to change at line 29 skipping to change at line 29
<address> <address>
<email>mt@lowentropy.net</email> <email>mt@lowentropy.net</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2023" month="November" /> <date year="2023" month="December" />
<area>Security</area> <area>Security</area>
<workgroup>Oblivious HTTP Application Intermediation</workgroup> <workgroup>Oblivious HTTP Application Intermediation</workgroup>
<keyword>privacy</keyword> <keyword>privacy</keyword>
<keyword>proxy</keyword> <keyword>proxy</keyword>
<keyword>partitioning</keyword> <keyword>partitioning</keyword>
<keyword>tunnel</keyword> <keyword>tunnel</keyword>
<abstract> <abstract>
<t>This document describes Oblivious HTTP, a protocol for forwarding encrypted H TTP messages. <t>This document describes Oblivious HTTP, a protocol for forwarding encrypted H TTP messages.
Oblivious HTTP allows a client to make multiple requests to an origin server wit hout that server Oblivious HTTP allows a client to make multiple requests to an origin server wit hout that server
being able to link those requests to the client or to identify the requests as h aving come from the being able to link those requests to the client or to identify the requests as h aving come from the
skipping to change at line 72 skipping to change at line 72
<t>To overcome these limitations, this document defines Oblivious HTTP, a protocol <t>To overcome these limitations, this document defines Oblivious HTTP, a protocol
for encrypting and sending HTTP messages from a client to a gateway. This uses a for encrypting and sending HTTP messages from a client to a gateway. This uses a
trusted relay service in a manner that mitigates the use of metadata such as IP trusted relay service in a manner that mitigates the use of metadata such as IP
address and connection information for client identification, with reasonable address and connection information for client identification, with reasonable
performance characteristics. This document describes:</t> performance characteristics. This document describes:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>an algorithm for encapsulating binary HTTP messages <xref target="B INARY"/> using Hybrid <t>an algorithm for encapsulating binary HTTP messages <xref target="B INARY"/> using Hybrid
Public Key Encryption (HPKE) <xref target="HPKE"/> to protect their contents,</t > Public Key Encryption (HPKE) <xref target="HPKE"/> to protect their contents,</t >
</li> </li>
<li> <li>
<t>a method for forwarding <iref item="Encapsulated Requests"/><xref t <t>a method for forwarding <xref target="dfn-enc-req" format="none">En
arget="dfn-enc-req" format="none">Encapsulated Requests</xref> between <iref ite capsulated Requests</xref> between <xref target="dfn-client" format="none">Clien
m="Clients"/><xref target="dfn-client" format="none">Clients</xref> and an ts</xref> and an
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> throu
">Oblivious Gateway Resource</xref> through a trusted <iref item="Oblivious Rela gh a trusted <xref target="dfn-relay" format="none">Oblivious Relay Resource</xr
y Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xr ef> using
ef> using
HTTP, and</t> HTTP, and</t>
</li> </li>
<li> <li>
<t>requirements for how the <iref item="Oblivious Gateway Resource"/>< <t>requirements for how the Oblivious Gateway Resource handles Encapsu
xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> handle lated Requests and produces <xref target="dfn-enc-res" format="none">Encapsulate
s <iref item="Encapsulated Requests"/><xref target="dfn-enc-req" format="none">E d Responses</xref> for the Client.</t>
ncapsulated
Requests</xref> and produces <iref item="Encapsulated Responses"/><xref target="
dfn-enc-res" format="none">Encapsulated Responses</xref> for the <iref item="Cli
ent"/><xref target="dfn-client" format="none">Client</xref>.</t>
</li> </li>
</ol> </ol>
<t>The combination of encapsulation and relaying ensures that <iref item=" <t>The combination of encapsulation and relaying ensures that Oblivious Ga
Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious teway
Gateway Resource never sees the Client's IP address and that the Oblivious Relay
Resource</xref> never sees the <iref item="Client"/><xref target="dfn-client" fo Resource never sees plaintext HTTP message content.</t>
rmat="none">Client</xref>'s IP address and that the <iref item="Oblivious Relay <t>Oblivious HTTP allows connection reuse between the Client and Oblivious
Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Relay
Resource</xref> never sees plaintext HTTP message content.</t> Resource, as well as between that relay and the Oblivious Gateway Resource, so t
<t>Oblivious HTTP allows connection reuse between the <iref item="Client"/ his
><xref target="dfn-client" format="none">Client</xref> and <iref item="Oblivious
Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref>, as well as between that relay and the <iref item="Oblivious Gat
eway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resou
rce</xref>, so this
scheme represents a performance improvement over using just one request in each scheme represents a performance improvement over using just one request in each
connection. With limited trust placed in the <iref item="Oblivious Relay Resour connection. With limited trust placed in the Oblivious Relay Resource (see
ce"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> (see <xref target="security"/>), Clients are assured that requests are not uniquely a
<xref target="security"/>), <iref item="Clients"/><xref target="dfn-client" form ttributed to
at="none">Clients</xref> are assured that requests are not uniquely attributed t
o
them or linked to other requests.</t> them or linked to other requests.</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>An Oblivious HTTP <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> must initially know the following:</t> <t>An Oblivious HTTP <xref target="dfn-client" format="none">Client</xref> must initially know the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The identity of an <iref item="Oblivious Gateway Resource"/><xref t <t>The identity of an <xref target="dfn-gateway" format="none">Oblivio
arget="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. This might us Gateway Resource</xref>. This might include some
include some information about what <xref target="dfn-target" format="none">Target Resources<
information about what Target Resources the <iref item="Oblivious Gateway Resour /xref> the Oblivious Gateway Resource
ce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>
supports.</t> supports.</t>
</li> </li>
<li> <li>
<t>The details of an HPKE public key for the <iref item="Oblivious Gat eway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resou rce</xref>, <t>The details of an HPKE public key for the Oblivious Gateway Resourc e,
including an identifier for that key and the HPKE algorithms that are used including an identifier for that key and the HPKE algorithms that are used
with that key.</t> with that key.</t>
</li> </li>
<li> <li>
<t>The identity of an <iref item="Oblivious Relay Resource"/><xref tar <t>The identity of an <xref target="dfn-relay" format="none">Oblivious
get="dfn-relay" format="none">Oblivious Relay Resource</xref> that will accept r Relay Resource</xref> that will accept relay requests
elay requests carrying an <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>
carrying an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format as its content and forward the content in
="none">Encapsulated Request</xref> as its content and forward the content in these requests to a particular Oblivious Gateway Resource. Oblivious HTTP
these requests to a particular <iref item="Oblivious Gateway Resource"/><xref ta uses a one-to-one mapping between Oblivious Relay and Gateway Resources; see
rget="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. Oblivious H
TTP
uses a one-to-one mapping between <iref item="Oblivious Relay and Gateway Resour
ces"/><xref target="dfn-relay" format="none">Oblivious Relay and Gateway Resourc
es</xref>; see
<xref target="proxy-state"/> for more details.</t> <xref target="proxy-state"/> for more details.</t>
</li> </li>
</ul> </ul>
<t>This information allows the <iref item="Client"/><xref target="dfn-clie <t>This information allows the Client to send HTTP requests to the Oblivio
nt" format="none">Client</xref> to send HTTP requests to the <iref item="Oblivio us
us Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource for forwarding to a Target Resource. The Oblivious Gateway
Gateway Resource</xref> for forwarding to a <iref item="Target Resource"/><xref Resource does not learn the Client's IP address or any other identifying
target="dfn-target" format="none">Target Resource</xref>. The <iref item="Obliv information that might be revealed from the Client at the transport layer, nor
ious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatew does the Oblivious Gateway Resource learn which of the requests it receives are
ay from the same Client.</t>
Resource</xref> does not learn the <iref item="Client"/><xref target="dfn-client
" format="none">Client</xref>'s IP address or any other identifying
information that might be revealed from the <iref item="Client"/><xref target="d
fn-client" format="none">Client</xref> at the transport layer, nor
does the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" for
mat="none">Oblivious Gateway Resource</xref> learn which of the requests it rece
ives are
from the same <iref item="Client"/><xref target="dfn-client" format="none">Clien
t</xref>.</t>
<figure anchor="fig-overview"> <figure anchor="fig-overview">
<name>Overview of Oblivious HTTP</name> <name>Overview of Oblivious HTTP</name>
<artset> <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"> <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 8,48 L 8,96" fill="none" stroke="black"/>
<path d="M 48,96 L 48,464" 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 88,48 L 88,96" fill="none" stroke="black"/>
<path d="M 152,48 L 152,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 192,96 L 192,464" fill="none" stroke="black"/>
<path d="M 240,48 L 240,96" fill="none" stroke="black"/> <path d="M 240,48 L 240,96" fill="none" stroke="black"/>
skipping to change at line 234 skipping to change at line 233
| | Response ] | | | | Response ] | |
| Relay |<-------------------+ | | Relay |<-------------------+ |
| Response | | | | Response | | |
| [+ Encapsulated | | | | [+ Encapsulated | | |
| Response ] | | | | Response ] | | |
|<----------------+ | | |<----------------+ | |
| | | | | | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In order to forward a request for a <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> to the <iref item="Obl ivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gat eway <t>In order to forward a request for a <xref target="dfn-target" format="n one">Target Resource</xref> to the <xref target="dfn-gateway" format="none">Obli vious Gateway
Resource</xref>, the following steps occur, as shown in <xref target="fig-overvi ew"/>:</t> Resource</xref>, the following steps occur, as shown in <xref target="fig-overvi ew"/>:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Cl ient</xref> constructs an HTTP request for a <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</t> <t>The <xref target="dfn-client" format="none">Client</xref> construct s an HTTP request for a Target Resource.</t>
</li> </li>
<li> <li>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Cl ient</xref> encodes the HTTP request in a binary HTTP message and then <t>The Client encodes the HTTP request in a binary HTTP message and th en
encapsulates that message using HPKE and the process from <xref target="request" />.</t> encapsulates that message using HPKE and the process from <xref target="request" />.</t>
</li> </li>
<li> <li>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Cl <t>The Client sends a POST request to the <xref target="dfn-relay" for
ient</xref> sends a POST request to the <iref item="Oblivious Relay Resource"/>< mat="none">Oblivious Relay Resource</xref> with the
xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> with the <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> as the cont
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca ent of that message.</t>
psulated Request</xref> as the content of that message.</t>
</li> </li>
<li> <li>
<t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" <t>The Oblivious Relay Resource forwards this request to the Oblivious
format="none">Oblivious Relay Resource</xref> forwards this request to the <ire Gateway
f item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Ob Resource.</t>
livious Gateway
Resource</xref>.</t>
</li> </li>
<li> <li>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gate way" format="none">Oblivious Gateway Resource</xref> receives this request and r emoves <t>The Oblivious Gateway Resource receives this request and removes
the HPKE protection to obtain an HTTP request.</t> the HPKE protection to obtain an HTTP request.</t>
</li> </li>
</ol> </ol>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" <t>The Oblivious Gateway Resource then handles the HTTP request. This typi
format="none">Oblivious Gateway Resource</xref> then handles the HTTP request. cally
This typically involves making an HTTP request using the content of the Encapsulated Request. O
involves making an HTTP request using the content of the <iref item="Encapsulate nce the
d Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Oblivious Gateway Resource has an HTTP response for this request, the following
. Once the steps occur to return this response to the Client:</t>
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway Resource</xref> has an HTTP response for this request, the f
ollowing
steps occur to return this response to the <iref item="Client"/><xref target="df
n-client" format="none">Client</xref>:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gate way" format="none">Oblivious Gateway Resource</xref> encapsulates the HTTP respo nse following the <t>The Oblivious Gateway Resource encapsulates the HTTP response follo wing the
process in <xref target="response"/> and sends this in response to the request f rom the process in <xref target="response"/> and sends this in response to the request f rom the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob livious Relay Resource</xref>.</t> Oblivious Relay Resource.</t>
</li> </li>
<li> <li>
<t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> forwards this response to the <ir ef item="Client"/><xref target="dfn-client" format="none">Client</xref>.</t> <t>The Oblivious Relay Resource forwards this response to the Client.< /t>
</li> </li>
<li> <li>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Cl ient</xref> removes the encapsulation to obtain the response to the original <t>The Client removes the encapsulation to obtain the response to the original
request.</t> request.</t>
</li> </li>
</ol> </ol>
<t>This interaction provides authentication and confidentiality protection between <t>This interaction provides authentication and confidentiality protection between
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> a the Client and the Oblivious Gateway, but importantly not between the Client and
nd the Oblivious Gateway, but importantly not between the <iref item="Client"/>< the Target Resource. While the Target Resource is a distinct HTTP resource from
xref target="dfn-client" format="none">Client</xref> and the Oblivious Gateway Resource, they are both logically under the control of the
the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Oblivious Gateway, since the Oblivious Gateway Resource can unilaterally dictate
Resource</xref>. While the <iref item="Target Resource"/><xref target="dfn-targ the responses returned from the Target Resource to the Client. This arrangement
et" format="none">Target Resource</xref> is a distinct HTTP resource from
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="
none">Oblivious Gateway Resource</xref>, they are both logically under the contr
ol of the
Oblivious Gateway, since the <iref item="Oblivious Gateway Resource"/><xref targ
et="dfn-gateway" format="none">Oblivious Gateway Resource</xref> can unilaterall
y dictate
the responses returned from the <iref item="Target Resource"/><xref target="dfn-
target" format="none">Target Resource</xref> to the <iref item="Client"/><xref t
arget="dfn-client" format="none">Client</xref>. This arrangement
is shown in <xref target="fig-overview"/>.</t> is shown in <xref target="fig-overview"/>.</t>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability</name> <name>Applicability</name>
<t>Oblivious HTTP has limited applicability. Importantly, it requires e xplicit <t>Oblivious HTTP has limited applicability. Importantly, it requires e xplicit
support from a willing <iref item="Oblivious Relay Resource"/><xref target="dfn- relay" format="none">Oblivious Relay Resource</xref> and <iref item="Oblivious G ateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Res ource</xref>, support from a willing <xref target="dfn-relay" format="none">Oblivious Relay Re source</xref> and <xref target="dfn-gateway" format="none">Oblivious Gateway Res ource</xref>,
thereby limiting the use of Oblivious HTTP for generic applications; thereby limiting the use of Oblivious HTTP for generic applications;
see <xref target="server-responsibilities"/> for more information.</t> see <xref target="server-responsibilities"/> for more information.</t>
<t>Many uses of HTTP benefit from being able to carry state between requ ests, such <t>Many uses of HTTP benefit from being able to carry state between requ ests, such
as with cookies <xref target="COOKIES"/>, authentication (<xref section="11" sec tionFormat="of" target="HTTP"/>), or even as with cookies <xref target="COOKIES"/>, authentication (<xref section="11" sec tionFormat="of" target="HTTP"/>), or even
alternative services <xref target="RFC7838"/>. Oblivious HTTP removes linkage a t the alternative services <xref target="RFC7838"/>. Oblivious HTTP removes linkage a t the
transport layer, which is only useful for an application that does not carry transport layer, which is only useful for an application that does not carry
state between requests.</t> state between requests.</t>
<t>Oblivious HTTP is primarily useful where the privacy risks associated with <t>Oblivious HTTP is primarily useful where the privacy risks associated with
possible stateful treatment of requests are sufficiently large that the cost of possible stateful treatment of requests are sufficiently large that the cost of
deploying this protocol can be justified. Oblivious HTTP is simpler and less deploying this protocol can be justified. Oblivious HTTP is simpler and less
skipping to change at line 342 skipping to change at line 341
search queries, or requesting location-specific content (such as retrieving search queries, or requesting location-specific content (such as retrieving
tiles of a map display).</t> tiles of a map display).</t>
<t>In addition to these limitations, <xref target="security"/> describes operational constraints <t>In addition to these limitations, <xref target="security"/> describes operational constraints
that are necessary to realize the goals of the protocol.</t> that are necessary to realize the goals of the protocol.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<?line -18?> <?line -18?>
<t>This document uses terminology from <xref target="HTTP"/> and defines several terms as <t>This document uses terminology from <xref target="HTTP"/> and defines several terms as
follows:</t> follows:</t>
<dl newline="true"> <dl newline="true">
<dt anchor="dfn-client"><iref item="Client"/><xref target="dfn-client" <!-- def: client -->
format="none">Client</xref>:</dt> <dt anchor="dfn-client">Client:</dt>
<dd> <dd>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Cl <t>A Client originates Oblivious HTTP requests. A Client is also an
ient</xref> originates Oblivious HTTP requests. A <iref item="Client"/><xref ta HTTP client
rget="dfn-client" format="none">Client</xref> is also an HTTP client in two ways: for the <xref target="dfn-target" format="none">Target Resource</xr
in two ways: for the <iref item="Target Resource"/><xref target="dfn-target" for ef> and for the <xref target="dfn-relay" format="none">Oblivious Relay
mat="none">Target Resource</xref> and for the <iref item="Oblivious Relay Resour
ce"/><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 us ed; see <xref target="http-usage"/>.</t> Resource</xref>. However, when referring to the HTTP definition of client (<xref section="3.3" sectionFormat="of" target="HTTP"/>), the term "HTTP client" is us ed; see <xref target="http-usage"/>.</t>
</dd> </dd>
<dt anchor="dfn-enc-req"><iref item="Encapsulated Request"/><xref targ <!-- def: Encapsulated Request -->
et="dfn-enc-req" format="none">Encapsulated Request</xref>:</dt> <dt anchor="dfn-enc-req">Encapsulated Request:</dt>
<dd> <dd>
<t>An HTTP request that is encapsulated in an HPKE-encrypted message ; see <t>An HTTP request that is encapsulated in an HPKE-encrypted message ; see
<xref target="request"/>.</t> <xref target="request"/>.</t>
</dd> </dd>
<dt anchor="dfn-enc-res"><iref item="Encapsulated Response"/><xref tar <!-- def: Encapsulated Response -->
get="dfn-enc-res" format="none">Encapsulated Response</xref>:</dt> <dt anchor="dfn-enc-res">Encapsulated Response:</dt>
<dd> <dd>
<t>An HTTP response that is encapsulated in an HPKE-encrypted messag e; see <t>An HTTP response that is encapsulated in an HPKE-encrypted messag e; see
<xref target="response"/>.</t> <xref target="response"/>.</t>
</dd> </dd>
<dt anchor="dfn-relay"><iref item="Oblivious Relay Resource"/><xref ta <!-- def: Oblivious Relay Resource -->
rget="dfn-relay" format="none">Oblivious Relay Resource</xref>:</dt> <dt anchor="dfn-relay">Oblivious Relay Resource:</dt>
<dd> <dd>
<t>An intermediary that forwards <iref item="Encapsulated Requests"/ <t>An intermediary that forwards <xref target="dfn-enc-req" format="
><xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> and Respo none">Encapsulated Requests</xref> and <xref target="dfn-enc-res" format="none">
nses between Responses</xref> between
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> and <xref target="dfn-client" format="none">Clients</xref> and a single <xref target
a single <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" fo ="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. In context, thi
rmat="none">Oblivious Gateway Resource</xref>. In context, this can be s can be
referred to simply as a "relay".</t> referred to simply as a "relay".</t>
</dd> </dd>
<dt anchor="dfn-gateway"><iref item="Oblivious Gateway Resource"/><xre <!-- def: Oblivious Gateway Resource -->
f target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>:</dt> <dt anchor="dfn-gateway">Oblivious Gateway Resource:</dt>
<dd> <dd>
<t>A resource that can receive an <iref item="Encapsulated Request"/ <t>A resource that can receive an <xref target="dfn-enc-req" format=
><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, extract t "none">Encapsulated Request</xref>, extract the contents of
he contents of that request, forward it to a <xref target="dfn-target" format="none">Target Res
that request, forward it to a <iref item="Target Resource"/><xref target="dfn-ta ource</xref>, receive a response, encapsulate
rget" format="none">Target Resource</xref>, receive a response, encapsulate that response, and then return the resulting <xref target="dfn-enc-res" format="
that response, and then return the resulting <iref item="Encapsulated Response"/ none">Encapsulated Response</xref>. In
><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>. In
context, this can be referred to simply as a "gateway".</t> context, this can be referred to simply as a "gateway".</t>
</dd> </dd>
<dt anchor="dfn-target"><iref item="Target Resource"/><xref target="df <!-- def: Target Resource -->
n-target" format="none">Target Resource</xref>:</dt> <dt anchor="dfn-target">Target Resource:</dt>
<dd> <dd>
<t>The resource that is the target of an <iref item="Encapsulated Re quest"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>. T his resource <t>The resource that is the target of an <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>. This resource
logically handles only regular HTTP requests and responses, so it might be logically handles only regular HTTP requests and responses, so it might be
ignorant of the use of Oblivious HTTP to reach it.</t> ignorant of the use of Oblivious HTTP to reach it.</t>
</dd> </dd>
</dl> </dl>
<t>This document includes pseudocode that uses the functions and convent ions <t>This document includes pseudocode that uses the functions and convent ions
defined in <xref target="HPKE"/>.</t> defined in <xref target="HPKE"/>.</t>
<t>Encoding an integer to a sequence of bytes in network byte order is d escribed <t>Encoding an integer to a sequence of bytes in network byte order is d escribed
using the function <tt>encode(n, v)</tt>, where <tt>n</tt> is the number of byte s and <tt>v</tt> is using the function <tt>encode(n, v)</tt>, where <tt>n</tt> is the number of byte s and <tt>v</tt> is
the integer value. ASCII <xref target="ASCII"/> encoding of a string <tt>s</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> indicated using the function <tt>encode_str(s)</tt>.</t>
<t>Formats are described using notation from <xref section="1.3" section Format="of" target="QUIC"/>. An extension <t>Formats are described using notation from <xref section="1.3" section Format="of" target="QUIC"/>. An extension
to that notation expresses the number of bits in a field using a simple to that notation expresses the number of bits in a field using a simple
mathematical function.</t> mathematical function.</t>
</section> </section>
</section> </section>
<section anchor="key-configuration"> <section anchor="key-configuration">
<name>Key Configuration</name> <name>Key Configuration</name>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</ <t>A <xref target="dfn-client" format="none">Client</xref> needs to acquir
xref> needs to acquire information about the <iref item="key configuration"/><xr e information about the key configuration of the
ef target="key-configuration" format="none">key configuration</xref> of the <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> in or
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none der to send <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref
">Oblivious Gateway Resource</xref> in order to send <iref item="Encapsulated Re >.
quests"/><xref target="dfn-enc-req" format="none">Encapsulated Requests</xref>. In order to ensure that Clients do not encapsulate messages that other entities
In order to ensure that <iref item="Clients"/><xref target="dfn-client" format=" can intercept, the key configuration <bcp14>MUST</bcp14> be authenticated and ha
none">Clients</xref> do not encapsulate messages that other entities ve integrity
can intercept, the <iref item="key configuration"/><xref target="key-configurati
on" format="none">key configuration</xref> <bcp14>MUST</bcp14> be authenticated
and have integrity
protection.</t> protection.</t>
<t>This document does not define how that acquisition occurs. However, in order to <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 help facilitate interoperability, it does specify a format for the keys. This
ensures that different <iref item="Client"/><xref target="dfn-client" format="no ensures that different Client implementations can be configured in the same way
ne">Client</xref> implementations can be configured in the same way and also enables advertising key configurations in a consistent format. This
and also enables advertising <iref item="key configurations"/><xref target="key-
configuration" format="none">key configurations</xref> in a consistent format.
This
format might be used, for example, with HTTPS, as part of a system for format might be used, for example, with HTTPS, as part of a system for
configuring or discovering <iref item="key configurations"/><xref target="key-co configuring or discovering key configurations. However, note that such a system
nfiguration" format="none">key configurations</xref>. However, note that such a needs to consider the potential for key configuration to be used to compromise
system Client privacy; see <xref target="privacy"/>.</t>
needs to consider the potential for <iref item="key configuration"/><xref target <t>A Client might have multiple key configurations to select from when
="key-configuration" format="none">key configuration</xref> to be used to compro encapsulating a request. Clients are responsible for selecting a preferred key
mise configuration from those it supports. Clients need to consider both the Key
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> priva
cy; see <xref target="privacy"/>.</t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</
xref> might have multiple <iref item="key configurations"/><xref target="key-con
figuration" format="none">key configurations</xref> to select from when
encapsulating a request. <iref item="Clients"/><xref target="dfn-client" format=
"none">Clients</xref> are responsible for selecting a preferred <iref item="key
configuration"/><xref target="key-configuration" format="none">key
configuration</xref> from those it supports. <iref item="Clients"/><xref target=
"dfn-client" format="none">Clients</xref> need to consider both the Key
Encapsulation Method (KEM) and the combinations of the Key Derivation Function Encapsulation Method (KEM) and the combinations of the Key Derivation Function
(KDF) and AEAD in this decision.</t> (KDF) and AEAD in this decision.</t>
<section anchor="key-config"> <section anchor="key-config">
<name>Key Configuration Encoding</name> <name>Key Configuration Encoding</name>
<t>A single <iref item="key configuration"/><xref target="key-configurat ion" format="none">key configuration</xref> consists of a key identifier, a publ ic key, an <t>A single <xref target="key-configuration" format="none">key configura tion</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 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 algorithms. Each symmetric algorithm consists of an identifier for a KDF and an
identifier for an AEAD.</t> identifier for an AEAD.</t>
<t><xref target="format-key-config"/> shows a single <iref item="key con figuration"/><xref target="key-configuration" format="none">key configuration</x ref>.</t> <t><xref target="format-key-config"/> shows a single key configuration.< /t>
<figure anchor="format-key-config"> <figure anchor="format-key-config">
<name>A Single Key Configuration</name> <name>A Single Key Configuration</name>
<sourcecode type="tls-presentation"><![CDATA[ <sourcecode type="tls-presentation"><![CDATA[
HPKE Symmetric Algorithms { HPKE Symmetric Algorithms {
HPKE KDF ID (16), HPKE KDF ID (16),
HPKE AEAD ID (16), HPKE AEAD ID (16),
} }
Key Config { Key Config {
Key Identifier (8), Key Identifier (8),
HPKE KEM ID (16), HPKE KEM ID (16),
HPKE Public Key (Npk * 8), HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16) = 4..65532, HPKE Symmetric Algorithms Length (16) = 4..65532,
HPKE Symmetric Algorithms (32) ..., HPKE Symmetric Algorithms (32) ...,
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>That is, a <iref item="key configuration"/><xref target="key-configur ation" format="none">key configuration</xref> consists of the following fields:< /t> <t>That is, a key configuration consists of the following fields:</t>
<dl newline="true"> <dl newline="true">
<dt>Key Identifier:</dt> <dt>Key Identifier:</dt>
<dd> <dd>
<t>An 8-bit value that identifies the key used by the <iref item="Ob livious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Ga teway Resource</xref>.</t> <t>An 8-bit value that identifies the key used by the <xref target=" dfn-gateway" format="none">Oblivious Gateway Resource</xref>.</t>
</dd> </dd>
<dt>HPKE KEM ID:</dt> <dt>HPKE KEM ID:</dt>
<dd> <dd>
<t>A 16-bit value that identifies the KEM used for the identified ke y as defined <t>A 16-bit value that identifies the KEM used for the identified ke y as defined
in <xref section="7.1" sectionFormat="of" target="HPKE"/> or <eref target="https in <xref section="7.1" sectionFormat="of" target="HPKE"/> or the <eref target="h
://www.iana.org/assignments/hpke" brackets="angle">the "HPKE KEM Identifiers" IA ttps://www.iana.org/assignments/hpke" brackets="angle">"HPKE KEM Identifiers" re
NA gistry</eref>.</t>
registry</eref>.</t>
</dd> </dd>
<dt>HPKE Public Key:</dt> <dt>HPKE Public Key:</dt>
<dd> <dd>
<t>The public key used by the gateway. The length of the public key is <tt>Npk</tt>, which is <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" sectionForm at="of" target="HPKE"/>.</t> determined by the choice of HPKE KEM as defined in <xref section="4" sectionForm at="of" target="HPKE"/>.</t>
</dd> </dd>
<dt>HPKE Symmetric Algorithms Length:</dt> <dt>HPKE Symmetric Algorithms Length:</dt>
<dd> <dd>
<t>A 16-bit integer in network byte order that encodes the length, i n bytes, of <t>A 16-bit integer in network byte order that encodes the length, i n bytes, of
the HPKE Symmetric Algorithms field that follows.</t> the HPKE Symmetric Algorithms field that follows.</t>
</dd> </dd>
<dt>HPKE Symmetric Algorithms:</dt> <dt>HPKE Symmetric Algorithms:</dt>
<dd> <dd>
<t>One or more pairs of identifiers for the different combinations o f HPKE KDF <t>One or more pairs of identifiers for the different combinations o f HPKE KDF
and AEAD that the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gat eway" format="none">Oblivious Gateway Resource</xref> supports:</t> and AEAD that the Oblivious Gateway Resource supports:</t>
<dl newline="true"> <dl newline="true">
<dt>HPKE KDF ID:</dt> <dt>HPKE KDF ID:</dt>
<dd> <dd>
<t>A 16-bit HPKE KDF identifier as defined in <xref section="7.2 <t>A 16-bit HPKE KDF identifier as defined in <xref section="7.2
" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assig " sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/a
nments/hpke" brackets="angle">the ssignments/hpke" brackets="angle">
"HPKE KDF Identifiers" IANA "HPKE KDF Identifiers"
registry</eref>.</t> registry</eref>.</t>
</dd> </dd>
<dt>HPKE AEAD ID:</dt> <dt>HPKE AEAD ID:</dt>
<dd> <dd>
<t>A 16-bit HPKE AEAD identifier as defined in <xref section="7. <t>A 16-bit HPKE AEAD identifier as defined in <xref section="7.
3" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assi 3" sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/
gnments/hpke" brackets="angle">the assignments/hpke" brackets="angle">"HPKE AEAD Identifiers" registry</eref>.</t>
"HPKE AEAD Identifiers" IANA
registry</eref>.</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="ohttp-keys"> <section anchor="ohttp-keys">
<name>Key Configuration Media Type</name> <name>Key Configuration Media Type</name>
<t>The "application/ohttp-keys" format is a media type that identifies a serialized <t>The "application/ohttp-keys" format is a media type that identifies a serialized
collection of <iref item="key configurations"/><xref target="key-configuration" collection of <xref target="key-configuration" format="none">key configurations<
format="none">key configurations</xref>. The content of this media type comprise /xref>. The content of this media type comprises one
s one or more key configuration encodings (see <xref target="key-config"/>). Each enc
or more <iref item="key configuration"/><xref target="key-configuration" format= oded
"none">key configuration</xref> encodings (see <xref target="key-config"/>). Ea
ch encoded
configuration is prefixed with a 2-byte integer in network byte order that configuration is prefixed with a 2-byte integer in network byte order that
indicates the length of the <iref item="key configuration"/><xref target="key-co nfiguration" format="none">key configuration</xref> in bytes. The length-prefix ed indicates the length of the key configuration in bytes. The length-prefixed
encodings are concatenated to form a list. See <xref target="iana-keys"/> for a definition encodings are concatenated to form a list. See <xref target="iana-keys"/> for a definition
of the media type.</t> of the media type.</t>
<t>Evolution of the <iref item="key configuration"/><xref target="key-co nfiguration" format="none">key configuration</xref> format is supported through the definition of <t>Evolution of the key configuration format is supported through the de finition of
new formats that are identified by new media types.</t> new formats that are identified by new media types.</t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client <t>A <xref target="dfn-client" format="none">Client</xref> that receives
</xref> that receives an "application/ohttp-keys" object with encoding errors an "application/ohttp-keys" object with encoding errors
might be able to recover one or more <iref item="key configurations"/><xref targ might be able to recover one or more key configurations. Differences in how key
et="key-configuration" format="none">key configurations</xref>. Differences in configurations are recovered might be exploited to segregate Clients, so Clients
how <iref item="key configurations"/><xref target="key-configuration" format="no <bcp14>MUST</bcp14> discard incorrectly encoded key configuration coll
ne">key ections.</t>
configurations</xref> are recovered might be exploited to segregate <iref item="
Clients"/><xref target="dfn-client" format="none">Clients</xref>, so <iref item=
"Clients"/><xref target="dfn-client" format="none">Clients</xref>
<bcp14>MUST</bcp14> discard incorrectly encoded <iref item="key config
uration"/><xref target="key-configuration" format="none">key configuration</xref
> collections.</t>
</section> </section>
</section> </section>
<section anchor="hpke-encapsulation"> <section anchor="hpke-encapsulation">
<name>HPKE Encapsulation</name> <name>HPKE Encapsulation</name>
<t>This document defines how a binary-encoded HTTP message <xref target="B INARY"/> is <t>This document defines how a binary-encoded HTTP message <xref target="B INARY"/> is
encapsulated using HPKE <xref target="HPKE"/>. Separate media types are defined to encapsulated using HPKE <xref target="HPKE"/>. Separate media types are defined to
distinguish request and response messages:</t> distinguish request and response messages:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An <iref item="Encapsulated Request"/><xref target="dfn-enc-req" fo rmat="none">Encapsulated Request</xref> format defined in <xref target="req-form at"/> is identified by the <t>An <xref target="dfn-enc-req" format="none">Encapsulated Request</x ref> format defined in <xref target="req-format"/> is identified by the
<xref target="iana-req">"<tt>message/ohttp-req</tt>" media type</xref>.</t> <xref target="iana-req">"<tt>message/ohttp-req</tt>" media type</xref>.</t>
</li> </li>
<li> <li>
<t>An <iref item="Encapsulated Response"/><xref target="dfn-enc-res" f ormat="none">Encapsulated Response</xref> format defined in <xref target="res-fo rmat"/> is identified by the <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>.</t> <xref target="iana-res">"<tt>message/ohttp-res</tt>" media type</xref>.</t>
</li> </li>
</ul> </ul>
<t>Alternative encapsulations or message formats are indicated using the m edia <t>Alternative encapsulations or message formats are indicated using the m edia
type; see Sections <xref format="counter" target="req-res-media"/> and <xref for mat="counter" target="repurposing"/>.</t> type; see Sections <xref format="counter" target="req-res-media"/> and <xref for mat="counter" target="repurposing"/>.</t>
<section anchor="req-format"> <section anchor="req-format">
<name>Request Format</name> <name>Request Format</name>
<t>A message in "<tt>message/ohttp-req</tt>" format protects a binary HT TP request <t>A message in "<tt>message/ohttp-req</tt>" format protects a binary HT TP request
message; see <xref target="fig-req-pt"/>.</t> message; see <xref target="fig-req-pt"/>.</t>
<figure anchor="fig-req-pt"> <figure anchor="fig-req-pt">
<name>Plaintext Request Structure</name> <name>Plaintext Request Structure</name>
<artwork><![CDATA[ <artwork><![CDATA[
Request { Request {
Binary HTTP Message (..), Binary HTTP Message (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This plaintext Request structure is encapsulated into a message in <t>This plaintext Request structure is encapsulated into a message in
"<tt>message/ohttp-req</tt>" form by generating an <iref item="Encapsulated Requ "<tt>message/ohttp-req</tt>" form by generating an <xref target="dfn-enc-req" fo
est"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>. An rmat="none">Encapsulated Request</xref>. An
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca Encapsulated Request comprises a key identifier; HPKE parameters for the chosen
psulated Request</xref> comprises a key identifier; HPKE parameters for the chos
en
KEM, KDF, and AEAD; the encapsulated KEM shared secret (or <tt>enc</tt>); and an KEM, KDF, and AEAD; the encapsulated KEM shared secret (or <tt>enc</tt>); and an
HPKE-protected binary HTTP request message.</t> HPKE-protected binary HTTP request message.</t>
<t>An <iref item="Encapsulated Request"/><xref target="dfn-enc-req" form <t>An Encapsulated Request is shown in <xref target="fig-enc-request"/>.
at="none">Encapsulated Request</xref> is shown in <xref target="fig-enc-request" <xref target="request"/> describes
/>. <xref target="request"/> describes the process for constructing and processing an Encapsulated Request.</t>
the process for constructing and processing an <iref item="Encapsulated Request"
/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>.</t>
<figure anchor="fig-enc-request"> <figure anchor="fig-enc-request">
<name>Encapsulated Request</name> <name>Encapsulated Request</name>
<artwork><![CDATA[ <artwork><![CDATA[
Encapsulated Request { Encapsulated Request {
Key Identifier (8), Key Identifier (8),
HPKE KEM ID (16), HPKE KEM ID (16),
HPKE KDF ID (16), HPKE KDF ID (16),
HPKE AEAD ID (16), HPKE AEAD ID (16),
Encapsulated KEM Shared Secret (8 * Nenc), Encapsulated KEM Shared Secret (8 * Nenc),
HPKE-Protected Request (..), HPKE-Protected Request (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>That is, an <iref item="Encapsulated Request"/><xref target="dfn-enc- req" format="none">Encapsulated Request</xref> comprises a Key Identifier, an HP KE KEM ID, an <t>That is, an <xref target="dfn-enc-req" format="none">Encapsulated Req uest</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 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 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 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> 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> bytes in length, as defined in <xref section="4" sectionFormat="of" target="HPKE "/>.</t>
</section> </section>
<section anchor="res-format"> <section anchor="res-format">
<name>Response Format</name> <name>Response Format</name>
<t>A message in "<tt>message/ohttp-res</tt>" format protects a binary HT TP response <t>A message in "<tt>message/ohttp-res</tt>" format protects a binary HT TP response
message; see <xref target="fig-res-pt"/>.</t> message; see <xref target="fig-res-pt"/>.</t>
<figure anchor="fig-res-pt"> <figure anchor="fig-res-pt">
<name>Plaintext Response Structure</name> <name>Plaintext Response Structure</name>
<artwork><![CDATA[ <artwork><![CDATA[
Response { Response {
Binary HTTP Message (..), Binary HTTP Message (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This plaintext Response structure is encapsulated into a message in <t>This plaintext Response structure is encapsulated into a message in
"<tt>message/ohttp-res</tt>" form by generating an <iref item="Encapsulated Resp "<tt>message/ohttp-res</tt>" form by generating an <xref target="dfn-enc-res" fo
onse"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>. A rmat="none">Encapsulated Response</xref>. An
n Encapsulated Response comprises a nonce and the AEAD-protected binary HTTP
<iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enc
apsulated Response</xref> comprises a nonce and the AEAD-protected binary HTTP
response message.</t> response message.</t>
<t>An <iref item="Encapsulated Response"/><xref target="dfn-enc-res" for <t>An Encapsulated Response is shown in <xref target="fig-enc-response"/
mat="none">Encapsulated Response</xref> is shown in <xref target="fig-enc-respon >. <xref target="response"/> describes
se"/>. <xref target="response"/> describes the process for constructing and processing an Encapsulated Response.</t>
the process for constructing and processing an <iref item="Encapsulated Response
"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.</t>
<figure anchor="fig-enc-response"> <figure anchor="fig-enc-response">
<name>Encapsulated Response</name> <name>Encapsulated Response</name>
<artwork><![CDATA[ <artwork><![CDATA[
Encapsulated Response { Encapsulated Response {
Nonce (8 * max(Nn, Nk)), Nonce (8 * max(Nn, Nk)),
AEAD-Protected Response (..), AEAD-Protected Response (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>That is, an <iref item="Encapsulated Response"/><xref target="dfn-enc -res" format="none">Encapsulated Response</xref> contains a Nonce and an AEAD-Pr otected <t>That is, an <xref target="dfn-enc-res" format="none">Encapsulated Res ponse</xref> contains a Nonce and an AEAD-Protected
Response. The Nonce field is either <tt>Nn</tt> or <tt>Nk</tt> bytes long, whic hever is Response. The Nonce field is either <tt>Nn</tt> or <tt>Nk</tt> bytes long, whic hever is
larger. The <tt>Nn</tt> and <tt>Nk</tt> values correspond to parameters of the AEAD used in 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" brackets="angle">the "H PKE AEAD HPKE, which is defined in <xref section="7.3" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assignments/hpke" brackets="angle">the "H PKE AEAD
Identifiers" IANA Identifiers" IANA
registry</eref>. <tt>Nn</tt> registry</eref>. <tt>Nn</tt>
and <tt>Nk</tt> refer to the size of the AEAD nonce and key, respectively, in by tes.</t> and <tt>Nk</tt> refer to the size of the AEAD nonce and key, respectively, in by tes.</t>
</section> </section>
<section anchor="request"> <section anchor="request">
<name>Encapsulation of Requests</name> <name>Encapsulation of Requests</name>
<t><iref item="Clients"/><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 target="key-configuration" format="none ">key <t><xref target="dfn-client" format="none">Clients</xref> encapsulate a request, identified as <tt>request</tt>, using values from a <xref target="key-c onfiguration" format="none">key
configuration</xref>:</t> configuration</xref>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the key identifier from the configuration (<tt>key_id</tt>) with the corresponding <t>the key identifier from the configuration (<tt>key_id</tt>) with the corresponding
KEM identified by <tt>kem_id</tt>,</t> KEM identified by <tt>kem_id</tt>,</t>
</li> </li>
<li> <li>
<t>the public key from the configuration (<tt>pkR</tt>), and</t> <t>the public key from the configuration (<tt>pkR</tt>), and</t>
</li> </li>
<li> <li>
<t>a combination of KDF (identified by <tt>kdf_id</tt>) and AEAD (id entified by <t>a combination of KDF (identified by <tt>kdf_id</tt>) and AEAD (id entified by
<tt>aead_id</tt>) that the <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> selects from those in the <iref item="key configuration"/> <xref target="key-configuration" format="none">key configuration</xref>.</t> <tt>aead_id</tt>) that the Client selects from those in the key configuration.</ t>
</li> </li>
</ul> </ul>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Clie nt</xref> then constructs an <iref item="Encapsulated Request"/><xref target="df n-enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>, from a binary-encoded HTTP request <xref target="BINARY"/> (<tt>request</tt>) as fol lows:</t> <t>The Client then constructs an <xref target="dfn-enc-req" format="none ">Encapsulated Request</xref>, <tt>enc_request</tt>, from a binary-encoded HTTP request <xref target="BINARY"/> (<tt>request</tt>) as follows:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Construct a message header (<tt>hdr</tt>) by concatenating the va lues of <tt>key_id</tt>, <t>Construct a message header (<tt>hdr</tt>) by concatenating the va lues of <tt>key_id</tt>,
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as one 8-bit integer and three 16-bit <tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as one 8-bit integer and three 16-bit
integers, respectively, each in network byte order.</t> integers, respectively, each in network byte order.</t>
</li> </li>
<li> <li>
<t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS CII-encoded string <t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS CII-encoded string
"message/bhttp request", a zero byte, and the header. Note: <xref target="repur posing"/> "message/bhttp request", a zero byte, and the header. Note: <xref target="repur posing"/>
discusses how alternative message formats might use a different <tt>info</tt> va lue.</t> discusses how alternative message formats might use a different <tt>info</tt> va lue.</t>
</li> </li>
<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 <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>.</t> the context <tt>sctxt</tt> and an encapsulation key <tt>enc</tt>.</t>
</li> </li>
<li> <li>
<t>Encrypt <tt>request</tt> by invoking the <tt>Seal()</tt> method o n <tt>sctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>) with e mpty associated data <tt>aad</tt>, yielding ciphertext <tt>ct</tt>.</t> <t>Encrypt <tt>request</tt> by invoking the <tt>Seal()</tt> method o n <tt>sctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>) with e mpty associated data <tt>aad</tt>, yielding ciphertext <tt>ct</tt>.</t>
</li> </li>
<li> <li>
<t>Concatenate the values of <tt>hdr</tt>, <tt>enc</tt>, and <tt>ct< <t>Concatenate the values of <tt>hdr</tt>, <tt>enc</tt>, and <tt>ct<
/tt>. This yields an <iref item="Encapsulated Request"/><xref target="dfn-enc-re /tt>. This yields an Encapsulated
q" format="none">Encapsulated Request (<tt>enc_request</tt>).</t>
Request</xref> (<tt>enc_request</tt>).</t>
</li> </li>
</ol> </ol>
<t>Note that <tt>enc</tt> is of fixed length, so there is no ambiguity i n parsing this <t>Note that <tt>enc</tt> is of fixed length, so there is no ambiguity i n parsing this
structure.</t> structure.</t>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
hdr = concat(encode(1, key_id), hdr = concat(encode(1, key_id),
encode(2, kem_id), encode(2, kem_id),
encode(2, kdf_id), encode(2, kdf_id),
encode(2, aead_id)) encode(2, aead_id))
info = concat(encode_str("message/bhttp request"), info = concat(encode_str("message/bhttp request"),
encode(1, 0), encode(1, 0),
hdr) hdr)
enc, sctxt = SetupBaseS(pkR, info) enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request) ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct) enc_request = concat(hdr, enc, ct)
]]></sourcecode> ]]></sourcecode>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway <t>An <xref target="dfn-gateway" format="none">Oblivious Gateway Resourc
" format="none">Oblivious Gateway Resource</xref> decrypts an <iref item="Encaps e</xref> decrypts an Encapsulated Request by reversing this
ulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</ process. To decapsulate an Encapsulated Request, <tt>enc_request</tt>:</t>
xref> by reversing this
process. To decapsulate an <iref item="Encapsulated Request"/><xref target="dfn-
enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<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 <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 < <tt>ct</tt> (indicated using the function <tt>parse()</tt> in pseudocode). The O
iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" blivious
>Oblivious Gateway Resource is then able to find the HPKE private key, <tt>skR</tt>,
Gateway Resource</xref> is then able to find the HPKE private key, <tt>skR</tt>,
corresponding to <tt>key_id</tt>. </t> corresponding to <tt>key_id</tt>. </t>
<ol spacing="normal" type="a"><li> <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 <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 Gateway Resource</xref> returns an error.</t> Oblivious Gateway Resource returns an error.</t>
</li> </li>
<li> <li>
<t>If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combinatio n of KDF and AEAD that the <t>If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combinatio n of KDF and AEAD that the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none Oblivious Gateway Resource is unwilling to use with <tt>skR</tt>, the Oblivious
">Oblivious Gateway Resource</xref> is unwilling to use with <tt>skR</tt>, the < Gateway Resource returns an error.</t>
iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none"
>Oblivious
Gateway Resource</xref> returns an error.</t>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS CII-encoded string <t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS CII-encoded string
"message/bhttp request"; a zero byte; <tt>key_id</tt> as an 8-bit integer; plus "message/bhttp request"; a zero byte; <tt>key_id</tt> as an 8-bit integer; plus
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as three 16-bit integers. </t> <tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as three 16-bit integers. </t>
</li> </li>
<li> <li>
<t>Create a receiving HPKE context, <tt>rctxt</tt>, by invoking <tt> SetupBaseR()</tt> <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>, <t t>enc</tt>, and <tt>info</tt>.</t> (<xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with <tt>skR</tt>, <t t>enc</tt>, and <tt>info</tt>.</t>
</li> </li>
<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 em pty associated data <tt>aad</tt>, yielding <tt>request</tt> or an error <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 em pty associated data <tt>aad</tt>, yielding <tt>request</tt> or an error
on failure. If decryption fails, the <iref item="Oblivious Gateway Resource"/><x ref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> returns an on failure. If decryption fails, the Oblivious Gateway Resource returns an
error.</t> error.</t>
</li> </li>
</ol> </ol>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request) key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"), info = concat(encode_str("message/bhttp request"),
encode(1, 0), encode(1, 0),
encode(1, key_id), encode(1, key_id),
encode(2, kem_id), encode(2, kem_id),
encode(2, kdf_id), encode(2, kdf_id),
encode(2, aead_id)) encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info) rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct) request, error = rctxt.Open("", ct)
]]></sourcecode> ]]></sourcecode>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatewa y" format="none">Oblivious Gateway Resource</xref> retains the HPKE context, <tt >rctxt</tt>, so that it can <t>The Oblivious Gateway Resource retains the HPKE context, <tt>rctxt</t t>, so that it can
encapsulate a response.</t> encapsulate a response.</t>
</section> </section>
<section anchor="response"> <section anchor="response">
<name>Encapsulation of Responses</name> <name>Encapsulation of Responses</name>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" <t><xref target="dfn-gateway" format="none">Oblivious Gateway Resources<
format="none">Oblivious Gateway Resources</xref> generate an <iref item="Encapsu /xref> generate an <xref target="dfn-enc-res" format="none">Encapsulated Respons
lated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response< e</xref> (<tt>enc_response</tt>)
/xref> (<tt>enc_response</tt>) from a binary-encoded HTTP response <xref target="BINARY"/> (<tt>response</tt>).
from a binary-encoded HTTP response <xref target="BINARY"/> (<tt>response</tt>). The Oblivious
The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format Gateway Resource uses the HPKE receiver context (<tt>rctxt</tt>) as the HPKE con
="none">Oblivious text
Gateway Resource</xref> uses the HPKE receiver context (<tt>rctxt</tt>) as the H
PKE context
(<tt>context</tt>) as follows:</t> (<tt>context</tt>) as follows:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Export a secret (<tt>secret</tt>) from <tt>context</tt>, using th e string "message/bhttp <t>Export a secret (<tt>secret</tt>) from <tt>context</tt>, using th e string "message/bhttp
response" as the <tt>exporter_context</tt> parameter to <tt>context.Export</tt>; see 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 secr et is <tt>max(Nn, Nk)</tt>, where <xref section="5.3" sectionFormat="of" target="HPKE"/>. The length of this secr et 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 as sociated with <tt>context</tt>. <tt>Nn</tt> and <tt>Nk</tt> are the length of the AEAD key and nonce that are as sociated with <tt>context</tt>.
Note: <xref target="repurposing"/> discusses how alternative message formats mig ht use a Note: <xref target="repurposing"/> discusses how alternative message formats mig ht use a
different <tt>context</tt> value.</t> different <tt>context</tt> value.</t>
</li> </li>
<li> <li>
skipping to change at line 734 skipping to change at line 737
<t>Use the same <tt>Expand</tt> function to create a nonce, <tt>nonc e</tt>, of length <tt>Nn</tt> -- <t>Use the same <tt>Expand</tt> function to create a nonce, <tt>nonc e</tt>, of length <tt>Nn</tt> --
the length of the nonce used by the AEAD. Generating <tt>aead_nonce</tt> uses a the length of the nonce used by the AEAD. Generating <tt>aead_nonce</tt> uses a
label of "nonce".</t> label of "nonce".</t>
</li> </li>
<li> <li>
<t>Encrypt <tt>response</tt>, passing the AEAD function Seal the val ues of <t>Encrypt <tt>response</tt>, passing the AEAD function Seal the val ues of
<tt>aead_key</tt>, <tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt> input of <tt>aead_key</tt>, <tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt> input of
<tt>response</tt>. This yields <tt>ct</tt>.</t> <tt>response</tt>. This yields <tt>ct</tt>.</t>
</li> </li>
<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">Enc apsulated Response</xref>, <t>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an Encapsulated Response,
<tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed length, so there is no <tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed length, so there is no
ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</t> ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</t>
</li> </li>
</ol> </ol>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
secret = context.Export("message/bhttp response", max(Nn, Nk)) secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk)) response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce) salt = concat(enc, response_nonce)
prk = Extract(salt, secret) prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk) aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn) aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response) ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct) enc_response = concat(response_nonce, ct)
]]></sourcecode> ]]></sourcecode>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients <t><xref target="dfn-client" format="none">Clients</xref> decrypt an Enc
</xref> decrypt an <iref item="Encapsulated Response"/><xref target="dfn-enc-res apsulated Response by reversing this process. That is,
" format="none">Encapsulated Response</xref> by reversing this process. That is Clients first parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>c
, t</tt>. Then, they
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> fir
st parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>ct</tt>. The
n, they
follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonc e</tt>, using follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonc e</tt>, using
their sending HPKE context, <tt>sctxt</tt>, as the HPKE context, <tt>context</tt >.</t> 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">Clie nt</xref> uses these values to decrypt <tt>ct</tt> using the AEAD function <tt>O pen</tt>. <t>The Client uses these values to decrypt <tt>ct</tt> using the AEAD fu nction <tt>Open</tt>.
Decrypting might produce an error, as follows:</t> Decrypting might produce an error, as follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
response, error = Open(aead_key, aead_nonce, "", ct) response, error = Open(aead_key, aead_nonce, "", ct)
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="req-res-media"> <section anchor="req-res-media">
<name>Request and Response Media Types</name> <name>Request and Response Media Types</name>
<t>Media types are used to identify <iref item="Encapsulated Requests"/> <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> and Respon ses; see <t>Media types are used to identify Encapsulated Requests and Responses; see
Sections <xref format="counter" target="iana-req"/> and <xref format="counter" t arget="iana-res"/> for definitions of these media types.</t> Sections <xref format="counter" target="iana-req"/> and <xref format="counter" t arget="iana-res"/> for definitions of these media types.</t>
<t>Evolution of the format of <iref item="Encapsulated Requests"/><xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> and Responses is supported <t>Evolution of the format of Encapsulated Requests and Responses is sup ported
through the definition of new formats that are identified by new media types. 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 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="repurposi ng"/> for guidance on HTTP message format than in <xref target="BINARY"/>; see <xref target="repurposi ng"/> for guidance on
reusing this encapsulation method. Alternatively, a new encapsulation method reusing this encapsulation method. Alternatively, a new encapsulation method
might be defined.</t> might be defined.</t>
</section> </section>
<section anchor="repurposing"> <section anchor="repurposing">
<name>Repurposing the Encapsulation Format</name> <name>Repurposing the Encapsulation Format</name>
<t>The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message <t>The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message
<xref target="BINARY"/>. The <iref item="Client"/><xref target="dfn-client" for mat="none">Client</xref> and <iref item="Oblivious Gateway Resource"/><xref targ et="dfn-gateway" format="none">Oblivious Gateway Resource</xref> agree on this e ncrypted <xref target="BINARY"/>. The <xref target="dfn-client" format="none">Client</xr ef> and <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xre f> agree on this encrypted
payload type by specifying the media type "message/bhttp" in the HPKE info payload type by specifying the media type "message/bhttp" in the HPKE info
string and HPKE export context string for request and response encryption, string and HPKE export context string for request and response encryption,
respectively.</t> respectively.</t>
<t>Future specifications may repurpose the encapsulation mechanism descr ibed in <t>Future specifications may repurpose the encapsulation mechanism descr ibed in
this document. This requires that the specification define a new media type. this document. This requires that the specification define a new media type.
The encapsulation process for that content type can follow the same process, 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> using new constant strings for the HPKE info and exporter context inputs.</t>
<t>For example, a future specification might encapsulate DNS messages, w hich use <t>For example, a future specification might encapsulate DNS messages, w hich use
the "application/dns-message" media type <xref target="RFC8484"/>. In creating a new, the "application/dns-message" media type <xref target="RFC8484"/>. In creating a new,
encrypted media types, specifications might define the use of string encrypted media types, specifications might define the use of string
"application/dns-message request" (plus a zero byte and the header for the full "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" value) for request encryption and the string "application/dns-message response"
for response encryption.</t> for response encryption.</t>
</section> </section>
</section> </section>
<section anchor="http-usage"> <section anchor="http-usage">
<name>HTTP Usage</name> <name>HTTP Usage</name>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</ <t>A <xref target="dfn-client" format="none">Client</xref> interacts with
xref> interacts with the <iref item="Oblivious Relay Resource"/><xref target="df the <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> by co
n-relay" format="none">Oblivious Relay Resource</xref> by constructing an nstructing an
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>. This Enca
psulated Request</xref>. This <iref item="Encapsulated Request"/><xref target=" psulated Request is included as the content of a
dfn-enc-req" format="none">Encapsulated Request</xref> is included as the conten POST request to the Oblivious Relay Resource. This request only needs those
t of a fields necessary to carry the Encapsulated Request: a method of POST, a target
POST request to the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel URI of the Oblivious Relay Resource, a header field containing the content type
ay" format="none">Oblivious Relay Resource</xref>. This request only needs thos (see <xref target="iana-req"/>), and the Encapsulated Request as the request con
e tent. In the
fields necessary to carry the <iref item="Encapsulated Request"/><xref target="d request to the Oblivious Relay Resource, Clients <bcp14>MAY</bcp14> include addi
fn-enc-req" format="none">Encapsulated Request</xref>: a method of POST, a targe tional
t fields. However, additional fields <bcp14>MUST</bcp14> be independent of the Enc
URI of the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" forma apsulated
t="none">Oblivious Relay Resource</xref>, a header field containing the content Request and <bcp14>MUST</bcp14> be fields that the Oblivious Relay Resource will
type remove before
(see <xref target="iana-req"/>), and the <iref item="Encapsulated Request"/><xre forwarding the Encapsulated Request towards the target, such as the <tt>Connecti
f target="dfn-enc-req" format="none">Encapsulated Request</xref> as the request on</tt>
content. In the
request to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" f
ormat="none">Oblivious Relay Resource</xref>, <iref item="Clients"/><xref target
="dfn-client" format="none">Clients</xref> <bcp14>MAY</bcp14> include additional
fields. However, additional fields <bcp14>MUST</bcp14> be independent of the <ir
ef item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsu
lated
Request</xref> and <bcp14>MUST</bcp14> be fields that the <iref item="Oblivious
Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource
</xref> will remove before
forwarding the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" for
mat="none">Encapsulated Request</xref> towards the target, such as the <tt>Conne
ction</tt>
or <tt>Proxy-Authorization</tt> header fields <xref target="HTTP"/>.</t> or <tt>Proxy-Authorization</tt> header fields <xref target="HTTP"/>.</t>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Client <t>The Client role in this protocol acts as an HTTP client both with respe
</xref> role in this protocol acts as an HTTP client both with respect to the ct to the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob Oblivious Relay Resource and the <xref target="dfn-target" format="none">Target
livious Relay Resource</xref> and the <iref item="Target Resource"/><xref target Resource</xref>. The request, which the Client
="dfn-target" format="none">Target Resource</xref>. The request, which the <ire makes to the Target Resource, diverges from typical HTTP assumptions about
f item="Client"/><xref target="dfn-client" format="none">Client</xref>
makes to the <iref item="Target Resource"/><xref target="dfn-target" format="non
e">Target Resource</xref>, 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 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="Obli response are encrypted rather than sent over a connection. The Oblivious Relay
vious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource and the <xref target="dfn-gateway" format="none">Oblivious Gateway Reso
Resource</xref> and the <iref item="Oblivious Gateway Resource"/><xref target="d urce</xref> also act as HTTP clients toward the
fn-gateway" format="none">Oblivious Gateway Resource</xref> also act as HTTP cli Oblivious Gateway Resource and Target Resource, respectively.</t>
ents toward the <t>In order to achieve the privacy and security goals of the protocol, a C
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none lient
">Oblivious Gateway Resource</xref> and <iref item="Target Resource"/><xref targ
et="dfn-target" format="none">Target Resource</xref>, respectively.</t>
<t>In order to achieve the privacy and security goals of the protocol, a <
iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
also needs to observe the guidance in <xref target="sec-client"/>.</t> also needs to observe the guidance in <xref target="sec-client"/>.</t>
<t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" for <t>The Oblivious Relay Resource interacts with the Oblivious Gateway Resou
mat="none">Oblivious Relay Resource</xref> interacts with the <iref item="Oblivi rce as an
ous Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatewa HTTP client by constructing a request using the same restrictions as the Client
y Resource</xref> as an request, except that the target URI is the Oblivious Gateway Resource. The
HTTP client by constructing a request using the same restrictions as the <iref i content of this request is copied from the Client. An Oblivious Relay Resource
tem="Client"/><xref target="dfn-client" format="none">Client</xref> <bcp14>MAY</bcp14> reject
request, except that the target URI is the <iref item="Oblivious Gateway Resourc requests that are obviously invalid, such as a request with no content. The Obli
e"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. vious Relay
The Resource <bcp14>MUST NOT</bcp14> add information to the request without the Clie
content of this request is copied from the <iref item="Client"/><xref target="df nt being aware of
n-client" format="none">Client</xref>. An <iref item="Oblivious Relay Resource"
/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> <bcp14>
MAY</bcp14> reject
requests that are obviously invalid, such as a request with no content. The <ire
f item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivi
ous Relay
Resource</xref> <bcp14>MUST NOT</bcp14> add information to the request without t
he <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> be
ing aware of
the type of information that might be added; see <xref target="relay-responsibil ities"/> for the type of information that might be added; see <xref target="relay-responsibil ities"/> for
more information on relay responsibilities.</t> more information on relay responsibilities.</t>
<t>When a response is received from the <iref item="Oblivious Gateway Reso <t>When a response is received from the Oblivious Gateway Resource, the Ob
urce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref livious
>, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="n Relay Resource forwards the response according to the rules of an HTTP proxy;
one">Oblivious see <xref section="7.6" sectionFormat="of" target="HTTP"/>. In case of timeout
Relay Resource</xref> forwards the response according to the rules of an HTTP pr or error, the Oblivious Relay
oxy; Resource can generate a response with an appropriate status code.</t>
see <xref section="7.6" sectionFormat="of" target="HTTP"/>. In case of timeout <t>In order to achieve the privacy and security goals of the protocol, an
or error, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" fo Oblivious
rmat="none">Oblivious Relay Relay Resource also needs to observe the guidance in <xref target="relay-respons
Resource</xref> can generate a response with an appropriate status code.</t> ibilities"/>.</t>
<t>In order to achieve the privacy and security goals of the protocol, an <t>An Oblivious Gateway Resource acts as a gateway for requests to the Tar
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob get
livious Resource (see <xref section="7.6" sectionFormat="of" target="HTTP"/>). The one
Relay Resource</xref> also needs to observe the guidance in <xref target="relay- exception is that any
responsibilities"/>.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway"
format="none">Oblivious Gateway Resource</xref> acts as a gateway for requests t
o the <iref item="Target Resource"/><xref target="dfn-target" format="none">Targ
et
Resource</xref> (see <xref section="7.6" sectionFormat="of" target="HTTP"/>). T
he one exception is that any
information it might forward in a response <bcp14>MUST</bcp14> be encapsulated, unless it is 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 responding to errors that do not relate to processing the contents of the
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca Encapsulated Request; see <xref target="errors"/>.</t>
psulated Request</xref>; see <xref target="errors"/>.</t> <t>An Oblivious Gateway Resource, if it receives any response from the Tar
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" get
format="none">Oblivious Gateway Resource</xref>, if it receives any response fro Resource, sends a single 200 response containing the <xref target="dfn-enc-res"
m the <iref item="Target Resource"/><xref target="dfn-target" format="none">Targ format="none">Encapsulated Response</xref>.
et Like the request from the Client, this response <bcp14>MUST</bcp14> only contain
Resource</xref>, sends a single 200 response containing the <iref item="Encapsul those fields
ated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response</ necessary to carry the Encapsulated Response: a 200 status code, a header field
xref>. indicating the content type, and the Encapsulated Response as the response
Like the request from the <iref item="Client"/><xref target="dfn-client" format=
"none">Client</xref>, this response <bcp14>MUST</bcp14> only contain those field
s
necessary to carry the <iref item="Encapsulated Response"/><xref target="dfn-enc
-res" format="none">Encapsulated Response</xref>: a 200 status code, a header fi
eld
indicating the content type, and the <iref item="Encapsulated Response"/><xref t
arget="dfn-enc-res" format="none">Encapsulated Response</xref> as the response
content. As with requests, additional fields <bcp14>MAY</bcp14> be used to conv ey information content. As with requests, additional fields <bcp14>MAY</bcp14> be used to conv ey information
that does not reveal information about the <iref item="Encapsulated Response"/>< that does not reveal information about the Encapsulated Response.</t>
xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.</t> <t>An Oblivious Gateway Resource that does not receive a response can itse
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" lf
format="none">Oblivious Gateway Resource</xref> that does not receive a response
can itself
generate a response with an appropriate error status code (such as 504 (Gateway 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 Timeout); see <xref section="15.6.5" sectionFormat="of" target="HTTP"/>), which is then encapsulated in the
same way as a successful response.</t> same way as a successful response.</t>
<t>In order to achieve the privacy and security goals of the protocol, an <t>In order to achieve the privacy and security goals of the protocol, an
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none Oblivious
">Oblivious Gateway Resource also needs to observe the guidance in
Gateway Resource</xref> also needs to observe the guidance in
<xref target="server-responsibilities"/>.</t> <xref target="server-responsibilities"/>.</t>
<section anchor="informational-responses"> <section anchor="informational-responses">
<name>Informational Responses</name> <name>Informational Responses</name>
<t>This encapsulation does not permit progressive processing of response s. <t>This encapsulation does not permit progressive processing of response s.
Though the binary HTTP response format does support the inclusion of Though the binary HTTP response format does support the inclusion of
informational (1xx) status codes, the AEAD encapsulation cannot be removed until informational (1xx) status codes, the AEAD encapsulation cannot be removed until
the entire message is received.</t> the entire message is received.</t>
<t>In particular, the <tt>Expect</tt> header field with 100-continue (se <t>In particular, the <tt>Expect</tt> header field with 100-continue (se
e <xref section="10.1.1" sectionFormat="of" target="HTTP"/>) cannot be used. <i e <xref section="10.1.1" sectionFormat="of" target="HTTP"/>) cannot be used. <x
ref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> <bcp1 ref target="dfn-client" format="none">Clients</xref> <bcp14>MUST NOT</bcp14> con
4>MUST NOT</bcp14> construct a request that includes a struct a request that includes a
100-continue expectation; the <iref item="Oblivious Gateway Resource"/><xref tar 100-continue expectation; the <xref target="dfn-gateway" format="none">Oblivious
get="dfn-gateway" format="none">Oblivious Gateway Resource</xref> <bcp14>MUST</b Gateway Resource</xref> <bcp14>MUST</bcp14> generate an error
cp14> generate an error
if a 100-continue expectation is received.</t> if a 100-continue expectation is received.</t>
</section> </section>
<section anchor="errors"> <section anchor="errors">
<name>Errors</name> <name>Errors</name>
<t>A server that receives an invalid message for any reason <bcp14>MUST< /bcp14> generate an HTTP <t>A server that receives an invalid message for any reason <bcp14>MUST< /bcp14> generate an HTTP
response with a 4xx status code.</t> response with a 4xx status code.</t>
<t>Errors detected by the <iref item="Oblivious Relay Resource"/><xref t <t>Errors detected by the <xref target="dfn-relay" format="none">Oblivio
arget="dfn-relay" format="none">Oblivious Relay Resource</xref> and errors detec us Relay Resource</xref> and errors detected by the
ted by the <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> befor
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none e removing protection (including being unable to
">Oblivious Gateway Resource</xref> before removing protection (including being
unable to
remove encapsulation for any reason) result in the status code being sent 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> without protection in response to the POST request made to that resource.</t>
<t>Errors detected by the <iref item="Oblivious Gateway Resource"/><xref <t>Errors detected by the Oblivious Gateway Resource after successfully
target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> after succ removing
essfully removing encapsulation and errors detected by the <xref target="dfn-target" format="none"
encapsulation and errors detected by the <iref item="Target Resource"/><xref tar >Target Resource</xref> <bcp14>MUST</bcp14> be sent in an
get="dfn-target" format="none">Target Resource</xref> <bcp14>MUST</bcp14> be sen <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>. This mig
t in an ht be because the <xref target="dfn-enc-req" format="none">Encapsulated Request<
<iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enc /xref> is
apsulated Response</xref>. This might be because the <iref item="Encapsulated R malformed or the Target Resource does not produce a response. In either case,
equest"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> is the Oblivious Gateway Resource can generate a response with an appropriate error
malformed or the <iref item="Target Resource"/><xref target="dfn-target" format=
"none">Target Resource</xref> does not produce a response. In either case,
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="
none">Oblivious Gateway Resource</xref> can generate a response with an appropri
ate error
status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections <x ref target="HTTP" section="15.5.1" sectionFormat="bare"/> and <xref target="HTTP " section="15.6.5" sectionFormat="bare"/> of <xref target="HTTP"/>, respectively ). This response is encapsulated in status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections <x ref target="HTTP" section="15.5.1" sectionFormat="bare"/> and <xref target="HTTP " section="15.6.5" sectionFormat="bare"/> of <xref target="HTTP"/>, respectively ). This response is encapsulated in
the same way as a successful response.</t> the same way as a successful response.</t>
<t>Errors in the encapsulation of requests mean that responses cannot be <t>Errors in the encapsulation of requests mean that responses cannot be
encapsulated. This includes cases where the <iref item="key configuration"/><xr encapsulated. This includes cases where the <xref target="key-configuration" fo
ef target="key-configuration" format="none">key configuration</xref> is incorrec rmat="none">key configuration</xref> is incorrect or
t or outdated. The Oblivious Gateway Resource can generate and send a response with
outdated. The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatewa a 4xx status code to the Oblivious Relay Resource. This response <bcp14>MAY</bc
y" format="none">Oblivious Gateway Resource</xref> can generate and send a respo p14> be
nse with forwarded to the <xref target="dfn-client" format="none">Client</xref> or treate
a 4xx status code to the <iref item="Oblivious Relay Resource"/><xref target="df d by the Oblivious Relay Resource as a failure.
n-relay" format="none">Oblivious Relay Resource</xref>. This response <bcp14>MA If a Client receives a response that is not an Encapsulated Response, this could
Y</bcp14> be indicate that the Client configuration used to construct the request is
forwarded to the <iref item="Client"/><xref target="dfn-client" format="none">Cl
ient</xref> or treated by the <iref item="Oblivious Relay Resource"/><xref targe
t="dfn-relay" format="none">Oblivious Relay Resource</xref> as a failure.
If a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
receives a response that is not an <iref item="Encapsulated Response"/><xref tar
get="dfn-enc-res" format="none">Encapsulated Response</xref>, this could
indicate that the <iref item="Client"/><xref target="dfn-client" format="none">C
lient</xref> configuration used to construct the request is
incorrect or out of date.</t> incorrect or out of date.</t>
</section> </section>
<section anchor="ohttp-key-problem"> <section anchor="ohttp-key-problem">
<name>Signaling Key Configuration Problems</name> <name>Signaling Key Configuration Problems</name>
<t>The problem type <xref target="PROBLEM"/> of <t>The problem type <xref target="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#ohttp-key" is defined in this "https://iana.org/assignments/http-problem-types#ohttp-key" is defined in this
section. An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" section. An <xref target="dfn-gateway" format="none">Oblivious Gateway Resource
format="none">Oblivious Gateway Resource</xref> <bcp14>MAY</bcp14> use this pro </xref> <bcp14>MAY</bcp14> use this problem type in a response
blem type in a response to indicate that an <xref target="dfn-enc-req" format="none">Encapsulated Reques
to indicate that an <iref item="Encapsulated Request"/><xref target="dfn-enc-req t</xref> used an outdated or incorrect <xref target="key-configuration" format="
" format="none">Encapsulated Request</xref> used an outdated or incorrect <iref none">key
item="key configuration"/><xref target="key-configuration" format="none">key
configuration</xref>.</t> configuration</xref>.</t>
<t><xref target="fig-key-problem"/> shows an example response in HTTP/1. 1 format.</t> <t><xref target="fig-key-problem"/> shows an example response in HTTP/1. 1 format.</t>
<figure anchor="fig-key-problem"> <figure anchor="fig-key-problem">
<name>Example Rejection of Key Configuration</name> <name>Example Rejection of Key Configuration</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json Content-Type: application/problem+json
Content-Length: 106 Content-Length: 106
{"type":"https://iana.org/assignments/http-problem-types#ohttp-key", {"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"} "title": "key identifier unknown"}
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>As this response cannot be encrypted, it might not reach the <iref it <t>As this response cannot be encrypted, it might not reach the <xref ta
em="Client"/><xref target="dfn-client" format="none">Client</xref>. A <iref ite rget="dfn-client" format="none">Client</xref>. A Client
m="Client"/><xref target="dfn-client" format="none">Client</xref> cannot rely on the <xref target="dfn-gateway" format="none">Oblivious Gateway Re
cannot rely on the <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga source</xref> using this problem type. A Client
teway" format="none">Oblivious Gateway Resource</xref> using this problem type.
A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
might also be configured to disregard responses that are not encapsulated on the 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 basis that they might be subject to observation or modification by an Oblivious
="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource. A Client might manage the risk of an outdated key configuration
Relay Resource</xref>. A <iref item="Client"/><xref target="dfn-client" format= using a heuristic approach whereby it periodically refreshes its key
"none">Client</xref> might manage the risk of an outdated <iref item="key config configuration if it receives a response with an error status code that has not
uration"/><xref target="key-configuration" format="none">key configuration</xref
>
using a heuristic approach whereby it periodically refreshes its <iref item="key
configuration"/><xref target="key-configuration" format="none">key
configuration</xref> if it receives a response with an error status code that ha
s not
been encapsulated.</t> been encapsulated.</t>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>In this design, a <iref item="Client"/><xref target="dfn-client" format <t>In this design, a <xref target="dfn-client" format="none">Client</xref>
="none">Client</xref> wishes to make a request to an <iref item="Oblivious Gatew wishes to make a request to an <xref target="dfn-gateway" format="none">Oblivio
ay Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway us Gateway
Resource</xref> that is forwarded to a <iref item="Target Resource"/><xref targe Resource</xref> that is forwarded to a <xref target="dfn-target" format="none">T
t="dfn-target" format="none">Target Resource</xref>. The <iref item="Client"/><x arget Resource</xref>. The Client wishes to make this
ref target="dfn-client" format="none">Client</xref> wishes to make this
request without linking that request with either of the following:</t> request without linking that request with either of the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The identity at the network and transport layer of the <iref item=" <t>The identity at the network and transport layer of the Client (that
Client"/><xref target="dfn-client" format="none">Client</xref> (that is, the is, the
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> IP ad Client IP address and TCP or UDP port number the Client uses to create a
dress and TCP or UDP port number the <iref item="Client"/><xref target="dfn-clie
nt" format="none">Client</xref> uses to create a
connection).</t> connection).</t>
</li> </li>
<li> <li>
<t>Any other request the <iref item="Client"/><xref target="dfn-client " format="none">Client</xref> might have made in the past or might make in the <t>Any other request the Client might have made in the past or might m ake in the
future.</t> future.</t>
</li> </li>
</ul> </ul>
<t>In order to ensure this, the <iref item="Client"/><xref target="dfn-cli <t>In order to ensure this, the Client selects a relay (that serves the
ent" format="none">Client</xref> selects a relay (that serves the <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref>) that it
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob trusts will protect this information
livious Relay Resource</xref>) that it trusts will protect this information by forwarding the Encapsulated Request and Response without passing it
by forwarding the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" to the server (that serves the Oblivious Gateway Resource).</t>
format="none">Encapsulated Request</xref> and Response without passing it
to the server (that serves the <iref item="Oblivious Gateway Resource"/><xref ta
rget="dfn-gateway" format="none">Oblivious Gateway Resource</xref>).</t>
<t>In this section, a deployment where there are three entities is conside red:</t> <t>In this section, a deployment where there are three entities is conside red:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Clie nt</xref> makes requests and receives responses.</t> <t>A Client makes requests and receives responses.</t>
</li> </li>
<li> <li>
<t>A relay operates the <iref item="Oblivious Relay Resource"/><xref t arget="dfn-relay" format="none">Oblivious Relay Resource</xref>.</t> <t>A relay operates the Oblivious Relay Resource.</t>
</li> </li>
<li> <li>
<t>A server operates both the <iref item="Oblivious Gateway Resource"/ ><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</t> <t>A server operates both the Oblivious Gateway Resource and the Targe t Resource.</t>
</li> </li>
</ul> </ul>
<t><xref target="separate-target"/> discusses the security implications fo r a case where <t><xref target="separate-target"/> discusses the security implications fo r a case where
different servers operate the <iref item="Oblivious Gateway Resource"/><xref tar different servers operate the Oblivious Gateway Resource and Target Resource.</t
get="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and <iref item >
="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xre <t>Requests from the Client to Oblivious Relay Resource and from Oblivious
f>.</t> Relay
<t>Requests from the <iref item="Client"/><xref target="dfn-client" format Resource to Oblivious Gateway Resource <bcp14>MUST</bcp14> use HTTPS in order to
="none">Client</xref> to <iref item="Oblivious Relay Resource"/><xref target="df provide
n-relay" format="none">Oblivious Relay Resource</xref> and from <iref item="Obli
vious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref> to <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga
teway" format="none">Oblivious Gateway Resource</xref> <bcp14>MUST</bcp14> use H
TTPS in order to provide
unlinkability in the presence of a network observer.</t> unlinkability in the presence of a network observer.</t>
<t>To achieve the stated privacy goals, the <iref item="Oblivious Relay Re <t>To achieve the stated privacy goals, the Oblivious Relay Resource canno
source"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> t be
cannot be operated by the same entity as the Oblivious Gateway Resource. However,
operated by the same entity as the <iref item="Oblivious Gateway Resource"/><xre colocation of the Oblivious Gateway Resource and Target Resource simplifies the
f target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. However, interactions between those resources without affecting Client privacy.</t>
colocation of the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gat
eway" format="none">Oblivious Gateway Resource</xref> and <iref item="Target Res
ource"/><xref target="dfn-target" format="none">Target Resource</xref> simplifie
s the
interactions between those resources without affecting <iref item="Client"/><xre
f target="dfn-client" format="none">Client</xref> privacy.</t>
<t>As a consequence of this configuration, Oblivious HTTP prevents linkabi lity <t>As a consequence of this configuration, Oblivious HTTP prevents linkabi lity
described above. Informally, this means:</t> described above. Informally, this means:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Requests and responses are known only to <iref item="Clients"/><xre <t>Requests and responses are known only to Clients and Oblivious Gate
f target="dfn-client" format="none">Clients</xref> and <iref item="Oblivious Gat way
eway Resources"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resources. In particular, the Oblivious Relay Resource knows the origin and
Resources</xref>. In particular, the <iref item="Oblivious Relay Resource"/><xr destination of an Encapsulated Request and Response, yet it does not know the
ef target="dfn-relay" format="none">Oblivious Relay Resource</xref> knows the or decrypted contents. Likewise, Oblivious Gateway Resources learn only the
igin and Oblivious Relay Resource and the decrypted request. No entity other than the
destination of an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" Client can see the plaintext request and response and can attribute them to
format="none">Encapsulated Request</xref> and Response, yet it does not know the the Client.</t>
decrypted contents. Likewise, <iref item="Oblivious Gateway Resources"/><xref t
arget="dfn-gateway" format="none">Oblivious Gateway Resources</xref> learn only
the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob
livious Relay Resource</xref> and the decrypted request. No entity other than t
he
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> can s
ee the plaintext request and response and can attribute them to
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>.<
/t>
</li> </li>
<li> <li>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway <t>Oblivious Gateway Resources, and therefore Target Resources, cannot
" format="none">Oblivious Gateway Resources</xref>, and therefore Target Resourc link
es, cannot link requests from the same Client in the absence of unique per-Client keys.</t>
requests from the same <iref item="Client"/><xref target="dfn-client" format="no
ne">Client</xref> in the absence of unique per-<iref item="Client"/><xref target
="dfn-client" format="none">Client</xref> keys.</t>
</li> </li>
</ol> </ol>
<t>Traffic analysis that might affect these properties is outside the scop e of this <t>Traffic analysis that might affect these properties is outside the scop e of this
document; see <xref target="ta"/>.</t> document; see <xref target="ta"/>.</t>
<t>A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS" />.</t> <t>A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS" />.</t>
<section anchor="sec-client"> <section anchor="sec-client">
<name>Client Responsibilities</name> <name>Client Responsibilities</name>
<t>Because <iref item="Clients"/><xref target="dfn-client" format="none" <t>Because <xref target="dfn-client" format="none">Clients</xref> do not
>Clients</xref> do not authenticate the <iref item="Target Resource"/><xref targ authenticate the <xref target="dfn-target" format="none">Target Resource</xref>
et="dfn-target" format="none">Target Resource</xref> when using Oblivious when using Oblivious
HTTP, <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xre HTTP, Clients <bcp14>MUST</bcp14> have some mechanism to authorize an <xref targ
f> <bcp14>MUST</bcp14> have some mechanism to authorize an <iref item="Oblivious et="dfn-gateway" format="none">Oblivious Gateway
Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> for use with a Target Resource. One possible means of authorizat
Resource</xref> for use with a <iref item="Target Resource"/><xref target="dfn-t ion is
arget" format="none">Target Resource</xref>. One possible means of authorization an allowlist. This ensures that Oblivious Gateway Resources are not misused to
is
an allowlist. This ensures that <iref item="Oblivious Gateway Resources"/><xref
target="dfn-gateway" format="none">Oblivious Gateway Resources</xref> are not m
isused to
forward traffic to arbitrary Target Resources. <xref target="server-responsibili ties"/> forward traffic to arbitrary Target Resources. <xref target="server-responsibili ties"/>
describes similar responsibilities that apply to <iref item="Oblivious Gateway R describes similar responsibilities that apply to Oblivious Gateway Resources.</t
esources"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resources< >
/xref>.</t> <t>Clients <bcp14>MUST</bcp14> ensure that the <xref target="key-configu
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients ration" format="none">key configuration</xref> they select for generating
</xref> <bcp14>MUST</bcp14> ensure that the <iref item="key configuration"/><xre <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> is integri
f target="key-configuration" format="none">key configuration</xref> they select ty protected and authenticated so that it can
for generating be attributed to the Oblivious Gateway Resource; see <xref target="key-configura
<iref item="Encapsulated Requests"/><xref target="dfn-enc-req" format="none">Enc tion"/>.</t>
apsulated Requests</xref> is integrity protected and authenticated so that it ca <t>Since Clients connect directly to the <xref target="dfn-relay" format
n ="none">Oblivious Relay Resource</xref> instead of the
be attributed to the <iref item="Oblivious Gateway Resource"/><xref target="dfn- Target Resource, application configurations wherein Clients make policy
gateway" format="none">Oblivious Gateway Resource</xref>; see <xref target="key-
configuration"/>.</t>
<t>Since <iref item="Clients"/><xref target="dfn-client" format="none">C
lients</xref> connect directly to the <iref item="Oblivious Relay Resource"/><xr
ef target="dfn-relay" format="none">Oblivious Relay Resource</xref> instead of t
he
<iref item="Target Resource"/><xref target="dfn-target" format="none">Target Res
ource</xref>, application configurations wherein <iref item="Clients"/><xref tar
get="dfn-client" format="none">Clients</xref> make policy
decisions about target connections, e.g., to apply certificate pinning, are decisions about target connections, e.g., to apply certificate pinning, are
incompatible with Oblivious HTTP. In such cases, alternative technologies such incompatible with Oblivious HTTP. In such cases, alternative technologies such
as HTTP CONNECT (<xref section="9.3.6" sectionFormat="of" target="HTTP"/>) can b e used. Applications could as HTTP CONNECT (<xref section="9.3.6" sectionFormat="of" target="HTTP"/>) can b e used. Applications could
implement related policies on <iref item="key configurations"/><xref target="key -configuration" format="none">key configurations</xref> and relay connections, t hough implement related policies on key configurations and relay connections, though
these might not provide the same properties as policies enforced directly on these might not provide the same properties as policies enforced directly on
target connections. Instead, when this difference is relevant, applications can target connections. Instead, when this difference is relevant, applications can
connect directly to the target at the cost of either privacy or performance.</t> 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 <t>Clients cannot carry connection-level state between requests as they
</xref> cannot carry connection-level state between requests as they only only
establish direct connections to the relay responsible for the <iref item="Oblivi establish direct connections to the relay responsible for the Oblivious Relay
ous Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource. However, the content of requests might be used by a server to
Resource</xref>. However, the content of requests might be used by a server to
correlate requests. Cookies <xref target="COOKIES"/> are the most obvious featu re that might correlate requests. Cookies <xref target="COOKIES"/> are the most obvious featu re that might
be used to correlate requests, but any identity information and authentication 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> also need to treat information credentials might have the same effect. Clients also need to treat information
learned from responses with similar care when constructing subsequent requests, learned from responses with similar care when constructing subsequent requests,
which includes the identity of resources.</t> which includes the identity of resources.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients </xref> <bcp14>MUST</bcp14> generate a new HPKE context for every request, using a good source <t>Clients <bcp14>MUST</bcp14> generate a new HPKE context for every req uest, using a good source
of entropy <xref target="RANDOM"/> for generating keys. Key reuse not only risks of entropy <xref target="RANDOM"/> for generating keys. Key reuse not only risks
requests being linked but also could expose request and response contents to the requests being linked but also could expose request and response contents to the
relay.</t> relay.</t>
<t>The request the <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> sends to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> only requires <t>The request the Client sends to the Oblivious Relay Resource only req uires
minimal information; see <xref target="http-usage"/>. The request that carries t he minimal information; see <xref target="http-usage"/>. The request that carries t he
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca Encapsulated Request and that is sent to the Oblivious Relay Resource <bcp14>MUS
psulated Request</xref> and that is sent to the <iref item="Oblivious Relay Reso T NOT</bcp14>
urce"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> <b include identifying information unless the Client can trust that this
cp14>MUST NOT</bcp14> information is removed by the relay. A Client <bcp14>MAY</bcp14> include informa
include identifying information unless the <iref item="Client"/><xref target="df tion only for
n-client" format="none">Client</xref> can trust that this the Oblivious Relay Resource in header fields identified by the <tt>Connection</
information is removed by the relay. A <iref item="Client"/><xref target="dfn-cl tt>
ient" format="none">Client</xref> <bcp14>MAY</bcp14> include information only fo header field if it trusts the relay to remove these, as required by <xref sectio
r n="7.6.1" sectionFormat="of" target="HTTP"/>. The Client needs to trust that the
the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none relay does not replicate the
">Oblivious Relay Resource</xref> in header fields identified by the <tt>Connect
ion</tt>
header field if it trusts the relay to remove these, as required by <xref sectio
n="7.6.1" sectionFormat="of" target="HTTP"/>. The <iref item="Client"/><xref tar
get="dfn-client" format="none">Client</xref> needs to trust that the relay does
not replicate the
source addressing information in the request it forwards.</t> source addressing information in the request it forwards.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients </xref> rely on the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel ay" format="none">Oblivious Relay Resource</xref> to forward <iref item="Encapsu lated Requests"/><xref target="dfn-enc-req" format="none">Encapsulated Requests< /xref> <t>Clients rely on the Oblivious Relay Resource to forward Encapsulated Requests
and Responses. However, the relay can only refuse to forward messages; it and Responses. However, the relay can only refuse to forward messages; it
cannot inspect or modify the contents of <iref item="Encapsulated Requests"/><xr ef target="dfn-enc-req" format="none">Encapsulated Requests</xref> or Responses. </t> cannot inspect or modify the contents of Encapsulated Requests or Responses.</t>
</section> </section>
<section anchor="relay-responsibilities"> <section anchor="relay-responsibilities">
<name>Relay Responsibilities</name> <name>Relay Responsibilities</name>
<t>The relay that serves the <iref item="Oblivious Relay Resource"/><xre <t>The relay that serves the <xref target="dfn-relay" format="none">Obli
f target="dfn-relay" format="none">Oblivious Relay Resource</xref> has a very si vious Relay Resource</xref> has a very simple function
mple function to perform. For each request it receives, it makes a request of the <xref target
to perform. For each request it receives, it makes a request of the <iref item=" ="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Gateway Resource</xref> that includes the same content. When it receives a respo nse, Gateway Resource</xref> that includes the same content. When it receives a respo nse,
it sends a response to the <iref item="Client"/><xref target="dfn-client" format it sends a response to the <xref target="dfn-client" format="none">Client</xref>
="none">Client</xref> that includes the content of the response that includes the content of the response
from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" for from the Oblivious Gateway Resource.</t>
mat="none">Oblivious Gateway Resource</xref>.</t>
<t>When forwarding a request, the relay <bcp14>MUST</bcp14> follow the f orwarding rules in <t>When forwarding a request, the relay <bcp14>MUST</bcp14> follow the f orwarding rules in
<xref section="7.6" sectionFormat="of" target="HTTP"/>. A generic HTTP intermed iary implementation is suitable <xref section="7.6" sectionFormat="of" target="HTTP"/>. A generic HTTP intermed iary implementation is suitable
for the purposes of serving an <iref item="Oblivious Relay Resource"/><xref targ for the purposes of serving an Oblivious Relay Resource, but additional care is
et="dfn-relay" format="none">Oblivious Relay Resource</xref>, but additional car needed to ensure that Client privacy is maintained.</t>
e is
needed to ensure that <iref item="Client"/><xref target="dfn-client" format="non
e">Client</xref> privacy is maintained.</t>
<t>Firstly, a generic implementation will forward unknown fields. For O blivious <t>Firstly, a generic implementation will forward unknown fields. For O blivious
HTTP, an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format= HTTP, an Oblivious Relay Resource <bcp14>SHOULD NOT</bcp14> forward unknown fiel
"none">Oblivious Relay Resource</xref> <bcp14>SHOULD NOT</bcp14> forward unknown ds. Though
fields. Though Clients are not expected to include fields that might contain identifying
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> are
not expected to include fields that might contain identifying
information, removing unknown fields removes this privacy risk.</t> information, removing unknown fields removes this privacy risk.</t>
<t>Secondly, generic implementations are often configured to augment req uests with <t>Secondly, generic implementations are often configured to augment req uests with
information about the <iref item="Client"/><xref target="dfn-client" format="non e">Client</xref>, such as the Via field or the Forwarded field information about the Client, such as the Via field or the Forwarded field
<xref target="FORWARDED"/>. A relay <bcp14>MUST NOT</bcp14> add information whe n forwarding <xref target="FORWARDED"/>. A relay <bcp14>MUST NOT</bcp14> add information whe n forwarding
requests that might be used to identify <iref item="Clients"/><xref target="dfn- requests that might be used to identify Clients, except for information that
client" format="none">Clients</xref>, except for information that a Client is aware of; see <xref target="differential"/>.</t>
a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> is
aware of; see <xref target="differential"/>.</t>
<t>Finally, a relay can also generate responses, though it is assumed to not be <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 able to examine the content of a request (other than to observe the choice of
key identifier, KDF, and AEAD); therefore, it is also assumed that it cannot key identifier, KDF, and AEAD); therefore, it is also assumed that it cannot
generate an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" forma t="none">Encapsulated Response</xref>.</t> generate an <xref target="dfn-enc-res" format="none">Encapsulated Response</xref >.</t>
<section anchor="differential"> <section anchor="differential">
<name>Differential Treatment</name> <name>Differential Treatment</name>
<t>A relay <bcp14>MAY</bcp14> add information to requests if the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> is aware o f the nature of <t>A relay <bcp14>MAY</bcp14> add information to requests if the <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> inclu de information the information that could be added. Any addition <bcp14>MUST NOT</bcp14> inclu de information
that uniquely and permanently identifies the <iref item="Client"/><xref target=" dfn-client" format="none">Client</xref>, including any pseudonymous identifier. that uniquely and permanently identifies the Client, including any pseudonymous identifier.
Information added by the relay -- beyond what is already revealed through Information added by the relay -- beyond what is already revealed through
<iref item="Encapsulated Requests"/><xref target="dfn-enc-req" format="none">Enc <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> from Clien
apsulated Requests</xref> from <iref item="Clients"/><xref target="dfn-client" f ts -- can reduce the size of the anonymity set of
ormat="none">Clients</xref> -- can reduce the size of the anonymity set of Clients at a gateway.</t>
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> at <t>A Client does not need to be aware of the exact value added for eac
a gateway.</t> h request
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Clie
nt</xref> does not need to be aware of the exact value added for each request
but needs to know the range of possible values the relay might use. How 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> mig a Client might learn about added information is not defined in this document.</t
ht learn about added information is not defined in this document.</t> >
<t>Moreover, relays <bcp14>MAY</bcp14> apply differential treatment to <t>Moreover, relays <bcp14>MAY</bcp14> apply differential treatment to
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> th Clients that engage in
at engage in
abusive behavior, e.g., by sending too many requests in comparison to other abusive behavior, e.g., by sending too many requests in comparison to other
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>, or as a response to rate limits signaled from the gateway. Any such Clients, or as a response to rate limits signaled from the gateway. Any such
differential treatment can reveal information to the gateway that would not be 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 i tem="Clients"/><xref target="dfn-client" format="none">Clients</xref> revealed otherwise and therefore reduce the size of the anonymity set of Clients
using a gateway. For example, if a relay chooses to rate limit or block an 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</xre abusive Client, this means that any Client requests that are not treated this
f>, this means that any <iref item="Client"/><xref target="dfn-client" format="n way are known to be non-abusive by the gateway. Clients need to consider the
one">Client</xref> requests that are not treated this
way are known to be non-abusive by the gateway. <iref item="Clients"/><xref targ
et="dfn-client" format="none">Clients</xref> need to consider the
likelihood of such differential treatment and the privacy risks when using a likelihood of such differential treatment and the privacy risks when using a
relay.</t> relay.</t>
<t>Some patterns of abuse cannot be detected without access to the req uest that is <t>Some patterns of abuse cannot be detected without access to the req uest that is
made to the target. This means that only the gateway or the target is in a made to the target. This means that only the gateway or the target is in a
position to identify abuse. A gateway <bcp14>MAY</bcp14> send signals toward the relay to 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 provide feedback about specific requests. For example, a gateway could respond
differently to requests it cannot decapsulate, as mentioned in <xref target="err ors"/>. A differently to requests it cannot decapsulate, as mentioned in <xref target="err ors"/>. A
relay that acts on this feedback could -- either inadvertently or by design -- relay that acts on this feedback could -- either inadvertently or by design --
lead to <iref item="Client"/><xref target="dfn-client" format="none">Client</xre f> deanonymization.</t> lead to Client deanonymization.</t>
</section> </section>
<section anchor="dos"> <section anchor="dos">
<name>Denial of Service</name> <name>Denial of Service</name>
<t>As there are privacy benefits from having a large rate of requests forwarded by <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="O the same relay (see <xref target="ta"/>), servers that operate the <xref target=
blivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious G "dfn-gateway" format="none">Oblivious Gateway Resource</xref>
ateway Resource</xref> might need an arrangement with <xref target="dfn-relay" format="none">Oblivious
might need an arrangement with <iref item="Oblivious Relay Resources"/><xref tar Relay Resources</xref>. This arrangement might
get="dfn-relay" format="none">Oblivious Relay Resources</xref>. This arrangement
might
be necessary to prevent having the large volume of requests being classified as be necessary to prevent having the large volume of requests being classified as
an attack by the server.</t> an attack by the server.</t>
<t>If a server accepts a larger volume of requests from a relay, it ne eds to trust <t>If a server accepts a larger volume of requests from a relay, it ne eds to trust
that the relay does not allow abusive levels of request volumes from that the relay does not allow abusive levels of request volumes from
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>. Th at is, if a server allows requests from the relay to be exempt from <xref target="dfn-client" format="none">Clients</xref>. That is, if a server all ows requests from the relay to be exempt from
rate limits, the server might want to ensure that the relay applies a rate limits, the server might want to ensure that the relay applies a
rate-limiting policy that is acceptable to the server.</t> rate-limiting policy that is acceptable to the server.</t>
<t>Servers that enter into an agreement with a relay that enables a hi gher request <t>Servers that enter into an agreement with a relay that enables a hi gher request
rate might choose to authenticate the relay to enable the higher rate.</t> rate might choose to authenticate the relay to enable the higher rate.</t>
</section> </section>
<section anchor="ta"> <section anchor="ta">
<name>Traffic Analysis</name> <name>Traffic Analysis</name>
<t>Using HTTPS protects information about which resources are the subj ect of <t>Using HTTPS protects information about which resources are the subj ect of
request and prevents a network observer from being able to trivially correlate 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 messages on either side of a relay. However, using HTTPS does not prevent
traffic analysis by such network observers.</t> 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> or Response messages are sent can <t>The time at which Encapsulated Request or Response messages are sen t can
reveal information to a network observer. Though messages exchanged between the reveal information to a network observer. Though messages exchanged between the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob livious Relay Resource</xref> and the <iref item="Oblivious Gateway Resource"/>< xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might be sent in a <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> and the < 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 single connection, traffic analysis could be used to match messages that are
forwarded by the relay.</t> forwarded by the relay.</t>
<t>A relay could, as part of its function, delay requests before forwa rding them. <t>A relay could, as part of its function, delay requests before forwa rding them.
Delays might increase the anonymity set into which each request is Delays might increase the anonymity set into which each request is
attributed. Any delay also increases the time that a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> waits for a attributed. Any delay also increases the time that a <xref target="dfn-client" f ormat="none">Client</xref> waits for a
response, so delays <bcp14>SHOULD</bcp14> only be added with the consent -- or a t least response, so delays <bcp14>SHOULD</bcp14> only be added with the consent -- or a t least
awareness -- of <iref item="Clients"/><xref target="dfn-client" format="none">Cl ients</xref>.</t> awareness -- of Clients.</t>
<t>A relay that forwards large volumes of exchanges can provide better privacy by <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> providing larger sets of messages that need to be matched.</t>
<t>Traffic analysis is not restricted to network observers. A maliciou s <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none"> Oblivious Relay Resource</xref> could <t>Traffic analysis is not restricted to network observers. A maliciou s Oblivious Relay Resource could
use traffic analysis to learn information about otherwise encrypted requests use traffic analysis to learn information about otherwise encrypted requests
and responses relayed between <iref item="Clients"/><xref target="dfn-client" fo and responses relayed between Clients and gateways. An Oblivious Relay Resource
rmat="none">Clients</xref> and gateways. An <iref item="Oblivious Relay Resource terminates
"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> termin TLS connections from Clients, so they see message boundaries. This privileged
ates
TLS connections from <iref item="Clients"/><xref target="dfn-client" format="non
e">Clients</xref>, so they see message boundaries. This privileged
position allows for richer feature extraction from encrypted data, which might position allows for richer feature extraction from encrypted data, which might
improve traffic analysis.</t> improve traffic analysis.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clien ts</xref> and <iref item="Oblivious Gateway Resources"/><xref target="dfn-gatewa y" format="none">Oblivious Gateway Resources</xref> can use padding to reduce th e <t>Clients and Oblivious Gateway Resources can use padding to reduce t he
effectiveness of traffic analysis. Padding is a capability provided by binary 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 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 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. <xref target="repurposing"/>), that message format might need to include padding support.
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">O blivious Relay Resources</xref> can also use padding for the same reason but nee d to Oblivious Relay Resources can also use padding for the same reason but need to
operate at the HTTP layer since they cannot manipulate binary HTTP messages; for 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 s ection="10.7" sectionFormat="of" target="HTTP3"/>).</t> example, see <xref section="10.7" sectionFormat="of" target="HTTP2"/> or <xref s ection="10.7" sectionFormat="of" target="HTTP3"/>).</t>
</section> </section>
</section> </section>
<section anchor="server-responsibilities"> <section anchor="server-responsibilities">
<name>Server Responsibilities</name> <name>Server Responsibilities</name>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatewa <t>The <xref target="dfn-gateway" format="none">Oblivious Gateway Resour
y" format="none">Oblivious Gateway Resource</xref> can be operated by a differen ce</xref> can be operated by a different entity than the
t entity than the <xref target="dfn-target" format="none">Target Resource</xref>. However, this m
<iref item="Target Resource"/><xref target="dfn-target" format="none">Target Res eans that the <xref target="dfn-client" format="none">Client</xref> needs to tru
ource</xref>. However, this means that the <iref item="Client"/><xref target="d st the
fn-client" format="none">Client</xref> needs to trust the Oblivious Gateway Resource not to modify requests or responses. This analysis
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway Resource</xref> not to modify requests or responses. This a
nalysis
concerns itself with a deployment scenario where a single server provides both 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 Gateway Resource</xref> and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</t> the Oblivious Gateway Resource and Target Resource.</t>
<t>A server that operates both Oblivious Gateway and Target Resources is <t>A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to the responsible for removing request encryption, generating a response to the
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca psulated Request</xref>, and encrypting the response.</t> <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, and encryp ting the response.</t>
<t>Servers should account for traffic analysis based on response size or generation <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 time. Techniques such as padding or timing delays can help protect against such
attacks; see <xref target="ta"/>.</t> attacks; see <xref target="ta"/>.</t>
<t>If separate entities provide the <iref item="Oblivious Gateway Resour ce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>, <t>If separate entities provide the Oblivious Gateway Resource and Targe t Resource,
these entities might need an arrangement similar to that between server and these entities might need an arrangement similar to that between server and
relay for managing denial of service; see <xref target="dos"/>. Moreover, the <i relay for managing denial of service; see <xref target="dos"/>. Moreover, the Ob
ref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none"> livious
Oblivious Gateway Resource <bcp14>SHOULD</bcp14> have some mechanism to ensure that the Ob
Gateway Resource</xref> <bcp14>SHOULD</bcp14> have some mechanism to ensure that livious Gateway
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format= Resource is not misused as a relay for HTTP messages to an arbitrary Target
"none">Oblivious Gateway Resource, such as an allowlist.</t>
Resource</xref> is not misused as a relay for HTTP messages to an arbitrary <ire
f item="Target Resource"/><xref target="dfn-target" format="none">Target
Resource</xref>, such as an allowlist.</t>
<t>Non-secure requests -- such as those with the "http" scheme as oppose d to the <t>Non-secure requests -- such as those with the "http" scheme as oppose d to the
"https" scheme -- <bcp14>SHOULD NOT</bcp14> be used if the Oblivious Gateway and Target "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 are not on the same origin. If messages are forwarded between these
resources without the protections afforded by HTTPS, they could be inspected or 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 modified by a network attacker. Note that a request could be forwarded without
protection if the two resources share an origin.</t> protection if the two resources share an origin.</t>
</section> </section>
<section anchor="key-management"> <section anchor="key-management">
<name>Key Management</name> <name>Key Management</name>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resource</xref> needs to have a plan for repla cing keys. This <t>An <xref target="dfn-gateway" format="none">Oblivious Gateway Resourc e</xref> needs to have a plan for replacing keys. This
might include regular replacement of keys, which can be assigned new key might include regular replacement of keys, which can be assigned new key
identifiers. If an <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga teway" format="none">Oblivious Gateway Resource</xref> receives a request that c ontains a identifiers. If an Oblivious Gateway Resource receives a request that contains a
key identifier that it does not understand or that corresponds to a key that has 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) been replaced, the server can respond with an HTTP 422 (Unprocessable Content)
status code.</t> status code.</t>
<t>A server can also use a 422 status code if the server has a key that corresponds <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 target=" dfn-enc-req" format="none">Encapsulated Request</xref> cannot be successfully to the key identifier, but the <xref target="dfn-enc-req" format="none">Encapsul ated Request</xref> cannot be successfully
decrypted using the key.</t> decrypted using the key.</t>
<t>A server <bcp14>MUST</bcp14> ensure that the HPKE keys it uses are no t valid for any other <t>A server <bcp14>MUST</bcp14> ensure that the HPKE keys it uses are no t valid for any other
protocol that uses HPKE with the "message/bhttp request" label. Designers of protocol that uses HPKE with the "message/bhttp request" label. Designers of
protocols that reuse this encryption format, especially new versions of this 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 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 HPKE. The "message/bhttp response" label was chosen for symmetry only as it
provides key diversity only within the HPKE context created using the provides key diversity only within the HPKE context created using the
"message/bhttp request" label; see <xref target="repurposing"/>.</t> "message/bhttp request" label; see <xref target="repurposing"/>.</t>
</section> </section>
<section anchor="replay"> <section anchor="replay">
<name>Replay Attacks</name> <name>Replay Attacks</name>
<t>A server is responsible for either rejecting replayed requests or ens uring that <t>A server is responsible for either rejecting replayed requests or ens uring that
the effect of replays does not adversely affect <iref item="Clients"/><xref targ the effect of replays does not adversely affect <xref target="dfn-client" format
et="dfn-client" format="none">Clients</xref> or resources.</t> ="none">Clients</xref> or resources.</t>
<t><iref item="Encapsulated Requests"/><xref target="dfn-enc-req" format <t><xref target="dfn-enc-req" format="none">Encapsulated Requests</xref>
="none">Encapsulated Requests</xref> can be copied and replayed by the <iref ite can be copied and replayed by the <xref target="dfn-relay" format="none">Oblivi
m="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious R ous Relay
elay
Resource</xref>. The threat model for Oblivious HTTP allows the possibility that an Resource</xref>. The threat model for Oblivious HTTP allows the possibility that an
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob Oblivious Relay Resource might replay requests. Furthermore, if a Client sends
livious Relay Resource</xref> might replay requests. Furthermore, if a <iref ite an Encapsulated Request in TLS early data (see <xref section="8" sectionFormat="
m="Client"/><xref target="dfn-client" format="none">Client</xref> sends of" target="TLS"/> and
an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">E
ncapsulated Request</xref> in TLS early data (see <xref section="8" sectionForma
t="of" target="TLS"/> and
<xref target="RFC8470"/>), a network-based adversary might be able to cause the request to <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 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> 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 <t>It is the responsibility of the application that uses Oblivious HTTP to either
reject replayed requests or ensure that replayed requests have no adverse reject replayed requests or ensure that replayed requests have no adverse
effect on their operation. This section describes some approaches that are effect on their operation. This section describes some approaches that are
universally applicable and suggestions for more targeted techniques.</t> universally applicable and suggestions for more targeted techniques.</t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client </xref> or <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" forma t="none">Oblivious Relay Resource</xref> <bcp14>MUST NOT</bcp14> automatically a ttempt to retry a <t>A Client or Oblivious Relay Resource <bcp14>MUST NOT</bcp14> automati cally attempt to retry a
failed request unless it receives a positive signal indicating that the request 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 sect ion="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 GOAW AY frame with a low enough identifier (in either protocol was not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (<xref sect ion="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 GOAW AY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred. HTTP/1.1 version) are all sufficient signals that no processing occurred. HTTP/1.1
<xref target="HTTP11"/> provides no equivalent signal. Connection failures or i nterruptions <xref target="HTTP11"/> provides no equivalent signal. Connection failures or i nterruptions
are not sufficient signals that no processing occurred.</t> are not sufficient signals that no processing occurred.</t>
<t>The anti-replay mechanisms described in <xref section="8" sectionForm at="of" target="TLS"/> are generally <t>The anti-replay mechanisms described in <xref section="8" sectionForm at="of" target="TLS"/> are generally
applicable to Oblivious HTTP requests. The encapsulated keying material (or 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. T his <tt>enc</tt>) can be used in place of a nonce to uniquely identify a request. T his
value is a high-entropy value that is freshly generated for every request, so 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> two valid requests will have different values with overwhelming probability.</t>
<t>The mechanism used in TLS for managing differences in <iref item="Cli ent"/><xref target="dfn-client" format="none">Client</xref> and server clocks <t>The mechanism used in TLS for managing differences in Client and serv er clocks
cannot be used as it depends on being able to observe previous interactions. cannot be used as it depends on being able to observe previous interactions.
Oblivious HTTP explicitly prevents such linkability.</t> Oblivious HTTP explicitly prevents such linkability.</t>
<t>The considerations in <xref target="RFC8470"/> as they relate to mana ging the risk of <t>The considerations in <xref target="RFC8470"/> as they relate to mana ging the risk of
replay also apply, though there is no option to delay the processing of a replay also apply, though there is no option to delay the processing of a
request.</t> request.</t>
<t>Limiting requests to those with safe methods might not be satisfactor y for some <t>Limiting requests to those with safe methods might not be satisfactor y for some
applications, particularly those that involve the submission of data to a 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 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 risk, though it is important to recognize that different idempotent requests
can be combined to be not idempotent.</t> can be combined to be not idempotent.</t>
<t>Even without replay prevention, the server-chosen <tt>response_nonce< /tt> field <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 ensures that responses have unique AEAD keys and nonces even when requests are
replayed.</t> replayed.</t>
<section anchor="use-of-date-for-anti-replay"> <section anchor="use-of-date-for-anti-replay">
<name>Use of Date for Anti-replay</name> <name>Use of Date for Anti-replay</name>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clien <t><xref target="dfn-client" format="none">Clients</xref> <bcp14>SHOUL
ts</xref> <bcp14>SHOULD</bcp14> include a <tt>Date</tt> header field in <iref it D</bcp14> include a <tt>Date</tt> header field in <xref target="dfn-enc-req" for
em="Encapsulated Requests"/><xref target="dfn-enc-req" format="none">Encapsulate mat="none">Encapsulated Requests</xref>, unless
d Requests</xref>, unless the Client has prior knowledge that indicates that the <xref target="dfn-gateway
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> h " format="none">Oblivious Gateway
as prior knowledge that indicates that the <iref item="Oblivious Gateway Resourc
e"/><xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref> does not use <tt>Date</tt> for anti-replay purposes.</t> 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 fi eld, the value of <t>Though HTTP requests often do not include a <tt>Date</tt> header fi eld, the value of
this field might be used by a server to limit the amount of requests it needs to 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> track if it needs to prevent replay attacks.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew <t>An Oblivious Gateway Resource can maintain state for requests for a
ay" format="none">Oblivious Gateway Resource</xref> can maintain state for reque small window
sts for a small window of time over which it wishes to accept requests. The Oblivious Gateway Resource
of time over which it wishes to accept requests. The <iref item="Oblivious Gate
way Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resour
ce</xref>
can store all requests it processes within this window. Storing just the <tt>en c</tt> can store all requests it processes within this window. Storing just the <tt>en c</tt>
field of a request, which should be unique to each request, is sufficient. The 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 Gateway Resource</xref> can reject any request that is the same as o ne that Oblivious Gateway 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 f ield was previously answered within that time window or if the <tt>Date</tt> header f ield
from the decrypted request is outside of the current time window.</t> from the decrypted request is outside of the current time window.</t>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway <t>Oblivious Gateway Resources might need to allow for the time it tak
" format="none">Oblivious Gateway Resources</xref> might need to allow for the t es requests
ime it takes requests to arrive from the Client, with a time window that is large enough to allow for
to arrive from the <iref item="Client"/><xref target="dfn-client" format="none">
Client</xref>, with a time window that is large enough to allow for
differences in clocks. Insufficient tolerance of time differences could result differences in clocks. Insufficient tolerance of time differences could result
in valid requests being unnecessarily rejected. Beyond allowing for multiple in valid requests being unnecessarily rejected. Beyond allowing for multiple
round-trip times -- to account for retransmission -- network delays are unlikely round-trip times -- to account for retransmission -- network delays are unlikely
to be significant in determining the size of the window, unless all potential to be significant in determining the size of the window, unless all potential
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> are known to have excellent timekeeping. A specific window size might Clients are known to have excellent timekeeping. A specific window size might
need to be determined experimentally.</t> need to be determined experimentally.</t>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resources</xref> <bcp14>MUST NOT</bcp14> treat the time window as secret <t>Oblivious Gateway Resources <bcp14>MUST NOT</bcp14> treat the time window as secret
information. An attacker can actively probe with different values for the <tt>Da te</tt> information. An attacker can actively probe with different values for the <tt>Da te</tt>
field to determine the time window over which the server will accept responses.< /t> field to determine the time window over which the server will accept responses.< /t>
</section> </section>
<section anchor="date-fix"> <section anchor="date-fix">
<name>Correcting Clock Differences</name> <name>Correcting Clock Differences</name>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew ay" format="none">Oblivious Gateway Resource</xref> can reject requests that con tain a <tt>Date</tt> value <t>An <xref target="dfn-gateway" format="none">Oblivious Gateway Resou rce</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 that is outside of its active window with a 400 series status code. The problem
type <xref target="PROBLEM"/> of type <xref target="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#date" is defined to allow the "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> 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> <t><xref target="fig-date-reject"/> shows an example response in HTTP/ 1.1 format.</t>
<figure anchor="fig-date-reject"> <figure anchor="fig-date-reject">
<name>Example Rejection of Request Date Field</name> <name>Example Rejection of Request Date Field</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json Content-Type: application/problem+json
Content-Length: 128 Content-Length: 128
{"type":"https://iana.org/assignments/http-problem-types#date", {"type":"https://iana.org/assignments/http-problem-types#date",
"title": "date field in request outside of acceptable range"} "title": "date field in request outside of acceptable range"}
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Disagreements about time are unlikely if both <iref item="Client"/> <t>Disagreements about time are unlikely if both <xref target="dfn-cli
<xref target="dfn-client" format="none">Client</xref> and <iref item="Oblivious ent" format="none">Client</xref> and Oblivious Gateway
Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource have a good source of time; see <xref target="NTP"/>. However, clock
Resource</xref> have a good source of time; see <xref target="NTP"/>. However, c
lock
differences are known to be commonplace; see Section 7.1 of differences are known to be commonplace; see Section 7.1 of
<xref target="CLOCKSKEW"/>.</t> <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> to cor rect <t>Including a <tt>Date</tt> header field in the response allows the C lient to correct
clock errors by retrying the same request using the value of the <tt>Date</tt> f ield clock errors by retrying the same request using the value of the <tt>Date</tt> f ield
provided by the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew ay" format="none">Oblivious Gateway Resource</xref>. The value of the <tt>Date< /tt> field can provided by the Oblivious Gateway Resource. The value of the <tt>Date</tt> fiel d can
be copied if the response is fresh, with an adjustment based on the <tt>Age</tt> field 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 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> <bcp1 4>MUST</bcp14> create a fresh encryption of the modified request, using a new HP KE Client <bcp14>MUST</bcp14> create a fresh encryption of the modified request, us ing a new HPKE
context.</t> context.</t>
<figure anchor="fig-retry-date"> <figure anchor="fig-retry-date">
<name>Retrying with an Updated Date Field</name> <name>Retrying with an Updated Date Field</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="304" width="464" viewBox="0 0 464 304" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="304" width="464" viewBox="0 0 464 304" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px">
<path d="M 8,32 L 8,80" fill="none" stroke="black"/> <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 48,80 L 48,288" fill="none" stroke="black"/>
<path d="M 88,32 L 88,80" 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 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,80 L 192,128" fill="none" stroke="black"/>
skipping to change at line 1337 skipping to change at line 1341
| | | + Date | | | | + Date |
|<============================+<-------------+ |<============================+<-------------+
| | | | | | | |
| Request | | | | Request | | |
| + Updated Date | | | | + Updated Date | | |
+============================>+------------->| +============================>+------------->|
| | | | | | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Retrying immediately allows the <iref item="Oblivious Gateway Resou <t>Retrying immediately allows the <xref target="dfn-gateway" format="
rce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> none">Oblivious Gateway Resource</xref> to measure the
to measure the round-trip time to the <xref target="dfn-client" format="none">Client</xref>. Th
round-trip time to the <iref item="Client"/><xref target="dfn-client" format="no e observed delay might reveal something about
ne">Client</xref>. The observed delay might reveal something about the location of the Client. Clients could delay retries to add some uncertainty
the location of the <iref item="Client"/><xref target="dfn-client" format="none"
>Client</xref>. <iref item="Clients"/><xref target="dfn-client" format="none">C
lients</xref> could delay retries to add some uncertainty
to any observed delay.</t> to any observed delay.</t>
<t>Intermediaries can sometimes rewrite the <tt>Date</tt> field when f orwarding responses. <t>Intermediaries can sometimes rewrite the <tt>Date</tt> field when f orwarding responses.
This might cause problems if the <iref item="Oblivious Gateway Resource"/><xref This might cause problems if the Oblivious Gateway Resource and intermediary
target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and interme clocks differ by enough to cause the retry to be rejected. Therefore, Clients
diary
clocks differ by enough to cause the retry to be rejected. Therefore, <iref ite
m="Clients"/><xref target="dfn-client" format="none">Clients</xref>
<bcp14>MUST NOT</bcp14> retry a request with an adjusted date more t han once.</t> <bcp14>MUST NOT</bcp14> retry a request with an adjusted date more t han once.</t>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resources</xref> that condition their response s on the <tt>Date</tt> header <t>Oblivious Gateway Resources that condition their responses on the < tt>Date</tt> header
field <bcp14>SHOULD</bcp14> either ensure that intermediaries do not cache respo nses (by field <bcp14>SHOULD</bcp14> either ensure that intermediaries do not cache respo nses (by
including a <tt>Cache-Control</tt> directive of <tt>no-store</tt>) or designate the response 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 includ ing the as conditional on the value of the <tt>Date</tt> request header field (by includ ing the
token "date" in a <tt>Vary</tt> header field).</t> token "date" in a <tt>Vary</tt> header field).</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clien ts</xref> <bcp14>MUST NOT</bcp14> use the date provided by the <iref item="Obliv ious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatew ay Resource</xref> for any <t>Clients <bcp14>MUST NOT</bcp14> use the date provided by the Oblivi ous Gateway Resource for any
other purpose, including future requests to any resource. Any request that uses other purpose, including future requests to any resource. Any request that uses
information provided by the <iref item="Oblivious Gateway Resource"/><xref targe t="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might be correla ted using information provided by the Oblivious Gateway Resource might be correlated using
that information.</t> that information.</t>
</section> </section>
</section> </section>
<section anchor="forward-secrecy"> <section anchor="forward-secrecy">
<name>Forward Secrecy</name> <name>Forward Secrecy</name>
<t>This document does not provide forward secrecy for either requests or <t>This document does not provide forward secrecy for either requests or
responses during the lifetime of the <iref item="key configuration"/><xref targe responses during the lifetime of the <xref target="key-configuration" format="no
t="key-configuration" format="none">key configuration</xref>. A measure of ne">key configuration</xref>. A measure of
forward secrecy can be provided by generating a new <iref item="key configuratio forward secrecy can be provided by generating a new key configuration
n"/><xref target="key-configuration" format="none">key configuration</xref>
then deleting the old keys after a suitable period.</t> then deleting the old keys after a suitable period.</t>
</section> </section>
<section anchor="post-compromise-security"> <section anchor="post-compromise-security">
<name>Post-Compromise Security</name> <name>Post-Compromise Security</name>
<t>This design does not provide post-compromise security for responses.< /t> <t>This design does not provide post-compromise security for responses.< /t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client </xref> only needs to retain keying material that might be used to compromise <t>A <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, 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> compromise.</t> so there is negligible risk associated with a Client compromise.</t>
<t>A server retains a secret key that might be used to remove protection from <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 messages over much longer periods. A server compromise that provided access to
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format=" none">Oblivious Gateway Resource</xref> secret key could allow an attacker to re cover the the <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> s ecret key could allow an attacker to recover the
plaintext of all requests sent toward affected keys and all of the responses plaintext of all requests sent toward affected keys and all of the responses
that were generated.</t> that were generated.</t>
<t>Even if server keys are compromised, an adversary cannot access messa ges <t>Even if server keys are compromised, an adversary cannot access messa ges
exchanged by the <iref item="Client"/><xref target="dfn-client" format="none">Cl exchanged by the Client with the <xref target="dfn-relay" format="none">Obliviou
ient</xref> with the <iref item="Oblivious Relay Resource"/><xref target="dfn-re s Relay Resource</xref> as messages are
lay" format="none">Oblivious Relay Resource</xref> as messages are protected by TLS. Use of a compromised key also requires that the Oblivious
protected by TLS. Use of a compromised key also requires that the <iref item="O Relay Resource cooperate with the attacker or that the attacker is able to
blivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious
Relay Resource</xref> cooperate with the attacker or that the attacker is able t
o
compromise these TLS connections.</t> compromise these TLS connections.</t>
<t>The total number of messages affected by server key compromise can be limited by <t>The total number of messages affected by server key compromise can be limited by
regular rotation of server keys.</t> regular rotation of server keys.</t>
</section> </section>
<section anchor="client-clock-exposure"> <section anchor="client-clock-exposure">
<name>Client Clock Exposure</name> <name>Client Clock Exposure</name>
<t>Including a <tt>Date</tt> field in requests reveals some information <t>Including a <tt>Date</tt> field in requests reveals some information
about the <iref item="Client"/><xref target="dfn-client" format="none">Client</x about the <xref target="dfn-client" format="none">Client</xref>
ref> clock. This might be used to fingerprint Clients <xref target="UWT"/> or to ide
clock. This might be used to fingerprint <iref item="Clients"/><xref target="df ntify Clients
n-client" format="none">Clients</xref> <xref target="UWT"/> or to identify <iref
item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
that are vulnerable to attacks that depend on incorrect clocks.</t> that are vulnerable to attacks that depend on incorrect clocks.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients </xref> can randomize the value that they provide for <tt>Date</tt> to obscure t he true <t>Clients can randomize the value that they provide for <tt>Date</tt> t o obscure the true
value of their clock and reduce the chance of linking requests over time. value of their clock and reduce the chance of linking requests over time.
However, this increases the risk that their request is rejected as outside the However, this increases the risk that their request is rejected as outside the
acceptable window.</t> acceptable window.</t>
</section> </section>
<section anchor="sec-media"> <section anchor="sec-media">
<name>Media Type Security</name> <name>Media Type Security</name>
<t>The <iref item="key configuration"/><xref target="key-configuration" <t>The <xref target="key-configuration" format="none">key configuration<
format="none">key configuration</xref> media type defined in <xref target="ohttp /xref> media type defined in <xref target="ohttp-keys"/> represents keying
-keys"/> represents keying material. The content of this media type is not active (see <xref section="4.6"
material. The content of this media type is not active (see <xref section="4.6" sectionFormat="of" target="RFC6838"/>), but it governs how a <xref target="dfn-
sectionFormat="of" target="RFC6838"/>), but it governs how a <iref item="Client client" format="none">Client</xref> might interact with an <xref target="dfn-gat
"/><xref target="dfn-client" format="none">Client</xref> might interact with an eway" format="none">Oblivious Gateway
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway
Resource</xref>. The security implications of processing it are described in Resource</xref>. The security implications of processing it are described in
<xref target="sec-client"/>; privacy implications are described in <xref target= "privacy"/>.</t> <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 <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. <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 However, these message media types are also encrypted encapsulations of HTTP
requests and responses.</t> requests and responses.</t>
<t>HTTP messages contain content, which can use any media type. In part icular, <t>HTTP messages contain content, which can use any media type. In part icular,
requests are processed by an Oblivious <iref item="Target Resource"/><xref targe t="dfn-target" format="none">Target Resource</xref>, which -- as an HTTP requests are processed by an Oblivious <xref target="dfn-target" format="none">T arget Resource</xref>, which -- as an HTTP
resource -- defines how content is processed; see <xref section="3.1" sectionFor mat="of" target="HTTP"/>. HTTP resource -- defines how content is processed; see <xref section="3.1" sectionFor mat="of" target="HTTP"/>. HTTP
clients can also use resource identity and response content to determine how clients can also use resource identity and response content to determine how
content is processed. Consequently, the security considerations of <xref sectio n="17" sectionFormat="of" target="HTTP"/> also apply to the handling of the cont ent of these media types.</t> content is processed. Consequently, the security considerations of <xref sectio n="17" sectionFormat="of" target="HTTP"/> also apply to the handling of the cont ent of these media types.</t>
</section> </section>
<section anchor="separate-target"> <section anchor="separate-target">
<name>Separate Gateway and Target</name> <name>Separate Gateway and Target</name>
<t>This document generally assumes that the same entity operates the <ir <t>This document generally assumes that the same entity operates the <xr
ef item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">O ef target="dfn-gateway" format="none">Oblivious
blivious Gateway Resource</xref> and the <xref target="dfn-target" format="none">Target R
Gateway Resource</xref> and the <iref item="Target Resource"/><xref target="dfn- esource</xref>. However, as the Oblivious Gateway
target" format="none">Target Resource</xref>. However, as the <iref item="Obliv Resource performs generic HTTP processing, the use of forwarding cannot be
ious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatew
ay
Resource</xref> performs generic HTTP processing, the use of forwarding cannot b
e
completely precluded.</t> completely precluded.</t>
<t>The scheme specified in the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> determines the se curity <t>The scheme specified in the <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 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> 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="non <t>A Target Resource that is operated on a different server from the Obl
e">Target Resource</xref> that is operated on a different server from the <iref ivious
item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Obli Gateway Resource is an ordinary HTTP resource. A Target Resource can privilege
vious requests that are forwarded by a given Oblivious Gateway Resource if it trusts
Gateway Resource</xref> is an ordinary HTTP resource. A <iref item="Target Reso the operator of the Oblivious Gateway Resource to only forward requests that
urce"/><xref target="dfn-target" format="none">Target Resource</xref> can privil meet the expectations of the Target Resource. Otherwise, the Target Resource
ege treats requests from an Oblivious Gateway Resource no differently than any
requests that are forwarded by a given <iref item="Oblivious Gateway Resource"/>
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> if it
trusts
the operator of the <iref item="Oblivious Gateway Resource"/><xref target="dfn-g
ateway" format="none">Oblivious Gateway Resource</xref> to only forward requests
that
meet the expectations of the <iref item="Target Resource"/><xref target="dfn-tar
get" format="none">Target Resource</xref>. Otherwise, the <iref item="Target Re
source"/><xref target="dfn-target" format="none">Target Resource</xref>
treats requests from an <iref item="Oblivious Gateway Resource"/><xref target="d
fn-gateway" format="none">Oblivious Gateway Resource</xref> no differently than
any
other HTTP client.</t> other HTTP client.</t>
<t>For instance, an <iref item="Oblivious Gateway Resource"/><xref targe <t>For instance, an Oblivious Gateway Resource might -- possibly with th
t="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might -- possibl e help of
y with the help of <xref target="dfn-relay" format="none">Oblivious Relay Resources</xref> -- be tr
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">O usted not to forward an excessive volume of
blivious Relay Resources</xref> -- be trusted not to forward an excessive volume requests. This might allow the Target Resource to accept a greater volume of
of requests from that Oblivious Gateway Resource relative to other HTTP clients.</t
requests. This might allow the <iref item="Target Resource"/><xref target="dfn-t >
arget" format="none">Target Resource</xref> to accept a greater volume of <t>An Oblivious Gateway Resource could implement policies that improve t
requests from that <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga he ability
teway" format="none">Oblivious Gateway Resource</xref> relative to other HTTP cl of the Target Resource to implement policy exemptions, such as only forwarding
ients.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway
" format="none">Oblivious Gateway Resource</xref> could implement policies that
improve the ability
of the <iref item="Target Resource"/><xref target="dfn-target" format="none">Tar
get Resource</xref> to implement policy exemptions, such as only forwarding
requests toward specific Target Resources according to an allowlist; see <xref t arget="server-responsibilities"/>.</t> requests toward specific Target Resources according to an allowlist; see <xref t arget="server-responsibilities"/>.</t>
</section> </section>
</section> </section>
<section anchor="privacy"> <section anchor="privacy">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>One goal of this design is that independent <iref item="Client"/><xref <t>One goal of this design is that independent <xref target="dfn-client" f
target="dfn-client" format="none">Client</xref> requests are only linkable by ormat="none">Client</xref> requests are only linkable by
their content. However, the choice of <iref item="Client"/><xref target="dfn-cl their content. However, the choice of Client configuration might be used to
ient" format="none">Client</xref> configuration might be used to correlate requests. A Client configuration includes the <xref target="dfn-relay
correlate requests. A <iref item="Client"/><xref target="dfn-client" format="no " format="none">Oblivious Relay
ne">Client</xref> configuration includes the <iref item="Oblivious Relay Resourc Resource</xref> URI, the Oblivious Gateway <xref target="key-configuration" form
e"/><xref target="dfn-relay" format="none">Oblivious Relay at="none">key configuration</xref>, and the <xref target="dfn-gateway" format="n
Resource</xref> URI, the Oblivious Gateway <iref item="key configuration"/><xref one">Oblivious Gateway
target="key-configuration" format="none">key configuration</xref>, and the <ire Resource</xref> URI. A configuration is active if Clients can successfully use i
f item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Ob t for
livious Gateway
Resource</xref> URI. A configuration is active if <iref item="Clients"/><xref ta
rget="dfn-client" format="none">Clients</xref> can successfully use it for
interacting with a target.</t> interacting with a target.</t>
<t><iref item="Oblivious Relay and Gateway Resources"/><xref target="dfn-r <t>Oblivious Relay and Gateway Resources can identify when requests use th
elay" format="none">Oblivious Relay and Gateway Resources</xref> can identify wh e same
en requests use the same configuration by matching the key identifier from the key configuration or the
configuration by matching the key identifier from the <iref item="key configurat Oblivious Gateway Resource URI. The Oblivious Gateway Resource might use the
ion"/><xref target="key-configuration" format="none">key configuration</xref> or source address of requests to correlate requests that use an Oblivious Relay
the Resource run by the same operator. If the Oblivious Gateway Resource is willing
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway Resource</xref> URI. The <iref item="Oblivious Gateway Reso
urce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref
> might use the
source address of requests to correlate requests that use an <iref item="Oblivio
us Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref> run by the same operator. If the <iref item="Oblivious Gateway
Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</
xref> is willing
to use trial decryption, requests can be further separated into smaller to use trial decryption, requests can be further separated into smaller
groupings based on active configurations that clients use.</t> groupings based on active configurations that clients use.</t>
<t>Each active <iref item="Client"/><xref target="dfn-client" format="none ">Client</xref> configuration partitions the <iref item="Client"/><xref target=" dfn-client" format="none">Client</xref> anonymity set. In <t>Each active Client configuration partitions the Client anonymity set. I n
practice, it is infeasible to reduce the number of active configurations to practice, it is infeasible to reduce the number of active configurations to
one. Enabling diversity in choice of <iref item="Oblivious Relay Resource"/><xre f target="dfn-relay" format="none">Oblivious Relay Resource</xref> naturally one. Enabling diversity in choice of Oblivious Relay Resource naturally
increases the number of active configurations. More than one configuration increases the number of active configurations. More than one configuration
might need to be active to allow for key rotation and server maintenance.</t> 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</xr <t>Client privacy depends on having each configuration used by many other
ef> privacy depends on having each configuration used by many other <iref item=" Clients.
Clients"/><xref target="dfn-client" format="none">Clients</xref>. It is critical to prevent the use of unique Client configurations, which might
It is critical to prevent the use of unique <iref item="Client"/><xref target="d be used to track individual Clients, but it is also important to avoid
fn-client" format="none">Client</xref> configurations, which might creating small groupings of Clients that might weaken privacy protections.</t>
be used to track individual <iref item="Clients"/><xref target="dfn-client" form <t>A specific method for a Client to acquire configurations is not include
at="none">Clients</xref>, but it is also important to avoid d in this
creating small groupings of <iref item="Clients"/><xref target="dfn-client" form
at="none">Clients</xref> that might weaken privacy protections.</t>
<t>A specific method for a <iref item="Client"/><xref target="dfn-client"
format="none">Client</xref> to acquire configurations is not included in this
specification. Applications using this design <bcp14>MUST</bcp14> provide accom modations to specification. Applications using this design <bcp14>MUST</bcp14> provide accom modations to
mitigate tracking using <iref item="Client"/><xref target="dfn-client" format="n mitigate tracking using Client configurations. <xref target="CONSISTENCY"/> pro
one">Client</xref> configurations. <xref target="CONSISTENCY"/> provides option vides options
s for ensuring that Client configurations are consistent between Clients.</t>
for ensuring that <iref item="Client"/><xref target="dfn-client" format="none">C
lient</xref> configurations are consistent between <iref item="Clients"/><xref t
arget="dfn-client" format="none">Clients</xref>.</t>
<t>The content of requests or responses, if used in forming new requests, can be <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, used to correlate requests. This includes obvious methods of linking requests,
like cookies <xref target="COOKIES"/>, but it also includes any information in e ither like cookies <xref target="COOKIES"/>, but it also includes any information in e ither
message that might affect how subsequent requests are formulated. For example, message that might affect how subsequent requests are formulated. For example,
<xref target="FIELDING"/> describes how interactions that are individually state less can be <xref target="FIELDING"/> describes how interactions that are individually state less can be
used to build a stateful system when a <iref item="Client"/><xref target="dfn-cl ient" format="none">Client</xref> acts on the content of a response.</t> used to build a stateful system when a Client acts on the content of a response. </t>
</section> </section>
<section anchor="deployment"> <section anchor="deployment">
<name>Operational and Deployment Considerations</name> <name>Operational and Deployment Considerations</name>
<t>This section discusses various operational and deployment consideration s.</t> <t>This section discusses various operational and deployment consideration s.</t>
<section anchor="performance-overhead"> <section anchor="performance-overhead">
<name>Performance Overhead</name> <name>Performance Overhead</name>
<t>Using Oblivious HTTP adds both cryptographic overhead and latency to requests <t>Using Oblivious HTTP adds both cryptographic overhead and latency to requests
relative to a simple HTTP request-response exchange. Deploying relay services relative to a simple HTTP request-response exchange. Deploying relay services
that are on path between <iref item="Clients"/><xref target="dfn-client" format= "none">Clients</xref> and servers avoids adding significant that are on path between <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 additional delay due to network topology. A study of a similar system
<xref target="ODOH-PETS"/> found that deploying proxies close to servers was mos t effective <xref target="ODOH-PETS"/> found that deploying proxies close to servers was mos t effective
in minimizing additional latency.</t> in minimizing additional latency.</t>
</section> </section>
<section anchor="proxy-state"> <section anchor="proxy-state">
<name>Resource Mappings</name> <name>Resource Mappings</name>
<t>This protocol assumes a fixed, one-to-one mapping between the <iref i <t>This protocol assumes a fixed, one-to-one mapping between the <xref t
tem="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious arget="dfn-relay" format="none">Oblivious Relay
Relay Resource</xref> and the <xref target="dfn-gateway" format="none">Oblivious Gatew
Resource</xref> and the <iref item="Oblivious Gateway Resource"/><xref target="d ay Resource</xref>. This means that any <xref target="dfn-enc-req" format="none"
fn-gateway" format="none">Oblivious Gateway Resource</xref>. This means that any >Encapsulated
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enc Request</xref> sent to the Oblivious Relay Resource will always be forwarded to
apsulated the
Request</xref> sent to the <iref item="Oblivious Relay Resource"/><xref target=" Oblivious Gateway Resource. This constraint was imposed to simplify relay
dfn-relay" format="none">Oblivious Relay Resource</xref> will always be forwarde configuration and mitigate against the Oblivious Relay Resource being used as
d to the a generic relay for unknown Oblivious Gateway Resources. The relay will only
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none forward for Oblivious Gateway Resources that it has explicitly configured and
">Oblivious Gateway Resource</xref>. This constraint was imposed to simplify rel
ay
configuration and mitigate against the <iref item="Oblivious Relay Resource"/><x
ref target="dfn-relay" format="none">Oblivious Relay Resource</xref> being used
as
a generic relay for unknown <iref item="Oblivious Gateway Resources"/><xref targ
et="dfn-gateway" format="none">Oblivious Gateway Resources</xref>. The relay wil
l only
forward for <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway"
format="none">Oblivious Gateway Resources</xref> that it has explicitly configu
red and
allowed.</t> allowed.</t>
<t>It is possible for a server to be configured with multiple <iref item <t>It is possible for a server to be configured with multiple Oblivious
="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">Oblivious R Relay
elay Resources, each for a different Oblivious Gateway Resource as needed. If the
Resources</xref>, each for a different <iref item="Oblivious Gateway Resource"/> goal is to support a large number of Oblivious Gateway Resources, <xref target="
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> as ne dfn-client" format="none">Clients</xref> might
eded. If the
goal is to support a large number of <iref item="Oblivious Gateway Resources"/><
xref target="dfn-gateway" format="none">Oblivious Gateway Resources</xref>, <ire
f item="Clients"/><xref target="dfn-client" format="none">Clients</xref> might
be provided with a URI template <xref target="TEMPLATE"/>, from which multiple be provided with a URI template <xref target="TEMPLATE"/>, from which multiple
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">O blivious Relay Resources</xref> could be constructed.</t> Oblivious Relay Resources could be constructed.</t>
</section> </section>
<section anchor="network-management"> <section anchor="network-management">
<name>Network Management</name> <name>Network Management</name>
<t>Oblivious HTTP might be incompatible with network interception regime s, such as <t>Oblivious HTTP might be incompatible with network interception regime s, such as
those that rely on configuring <iref item="Clients"/><xref target="dfn-client" f ormat="none">Clients</xref> with trust anchors and intercepting TLS those that rely on configuring <xref target="dfn-client" format="none">Clients</ xref> with trust anchors and intercepting TLS
connections. While TLS might be intercepted successfully, interception connections. While TLS might be intercepted successfully, interception
middlebox devices might not receive updates that would allow Oblivious HTTP to 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"/> be correctly identified using the media types defined in Sections <xref format=" counter" target="iana-req"/>
and <xref format="counter" target="iana-res"/>.</t> and <xref format="counter" target="iana-res"/>.</t>
<t>Oblivious HTTP has a simple key management design that is not trivial ly altered <t>Oblivious HTTP has a simple key management design that is not trivial ly altered
to enable interception by intermediaries. <iref item="Clients"/><xref target="d fn-client" format="none">Clients</xref> that are configured to enable to enable interception by intermediaries. Clients that are configured to enable
interception might choose to disable Oblivious HTTP in order to ensure that interception might choose to disable Oblivious HTTP in order to ensure that
content is accessible to middleboxes.</t> content is accessible to middleboxes.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA has registered the following media types in the "Media Types" regi stry at <t>IANA has registered the following media types in the "Media Types" regi stry at
<eref target="https://iana.org/assignments/media-types" brackets="angle"/>, foll owing the procedures of <eref target="https://iana.org/assignments/media-types" brackets="angle"/>, foll owing the procedures of
<xref target="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana- keys"/>), "<tt>message/ohttp-req</tt>" <xref target="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana- keys"/>), "<tt>message/ohttp-req</tt>"
(<xref target="iana-req"/>), and "<tt>message/ohttp-res</tt>" (<xref target="ian a-res"/>).</t> (<xref target="iana-req"/>), and "<tt>message/ohttp-res</tt>" (<xref target="ian a-res"/>).</t>
<t>IANA has added the following types to the "HTTP Problem Types" registry at <t>IANA has added the following types to the "HTTP Problem Types" registry at
<eref target="https://iana.org/assignments/http-problem-types" brackets="angle"/ >: "date" <eref 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> (<xref target="iana-problem-date"/>) and "ohttp-key" (<xref target="iana-problem -ohttp-key"/>).</t>
<section anchor="iana-keys"> <section anchor="iana-keys">
<name>application/ohttp-keys Media Type</name> <name>application/ohttp-keys Media Type</name>
<t>The "<tt>application/ohttp-keys</tt>" media type identifies a <iref i tem="key configuration"/><xref target="key-configuration" format="none">key conf iguration</xref> used by <t>The "<tt>application/ohttp-keys</tt>" media type identifies a <xref t arget="key-configuration" format="none">key configuration</xref> used by
Oblivious HTTP.</t> Oblivious HTTP.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>application</t> <t>application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>ohttp-keys</t> <t>ohttp-keys</t>
</dd> </dd>
skipping to change at line 1558 skipping to change at line 1563
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>RFC 9458</t> <t>RFC 9458</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>This type identifies a <iref item="key configuration"/><xref targ et="key-configuration" format="none">key configuration</xref> as used by Oblivio us HTTP and <t>This type identifies a key configuration as used by Oblivious HTT P and
applications that use Oblivious HTTP.</t> applications that use Oblivious HTTP.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<t> <br/> <t><br/></t>
</t> <dl spacing="normal">
<dl spacing="compact">
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
skipping to change at line 1650 skipping to change at line 1654
<dd> <dd>
<t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to <t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP requests.</t> identify encapsulated binary HTTP requests.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<t> <br/> <t><br/></t>
</t> <dl spacing="normal">
<dl spacing="compact">
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
skipping to change at line 1733 skipping to change at line 1736
<dd> <dd>
<t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to <t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP responses.</t> identify encapsulated binary HTTP responses.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<t> <br/> <t><br/></t>
</t> <dl spacing="normal">
<dl spacing="compact">
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
skipping to change at line 1802 skipping to change at line 1804
<name>Registration of "ohttp-key" Problem Type</name> <name>Registration of "ohttp-key" Problem Type</name>
<t>IANA has added a new entry in the "HTTP Problem Types" registry estab lished by <t>IANA has added a new entry in the "HTTP Problem Types" registry estab lished by
<xref target="PROBLEM"/>.</t> <xref target="PROBLEM"/>.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type URI:</dt> <dt>Type URI:</dt>
<dd> <dd>
<t>https://iana.org/assignments/http-problem-types#ohttp-key</t> <t>https://iana.org/assignments/http-problem-types#ohttp-key</t>
</dd> </dd>
<dt>Title:</dt> <dt>Title:</dt>
<dd> <dd>
<t>Oblivious HTTP <iref item="key configuration"/><xref target="key- configuration" format="none">key configuration</xref> not acceptable</t> <t>Oblivious HTTP key configuration not acceptable</t>
</dd> </dd>
<dt>Recommended HTTP Status Code:</dt> <dt>Recommended HTTP Status Code:</dt>
<dd> <dd>
<t>400</t> <t>400</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t><xref target="ohttp-key-problem"/> of RFC 9458</t> <t><xref target="ohttp-key-problem"/> of RFC 9458</t>
</dd> </dd>
</dl> </dl>
skipping to change at line 2322 skipping to change at line 2324
</references> </references>
<?line 1865?> <?line 1865?>
<section anchor="complete-example-of-a-request-and-response"> <section anchor="complete-example-of-a-request-and-response">
<name>Complete Example of a Request and Response</name> <name>Complete Example of a Request and Response</name>
<!-- Generated using ohttp (https://github.com/martinthomson/ohttp): <!-- 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 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. Note: "rust-hpke" doesn't log the client/sender keying material.
--> -->
<t>A single request and response exchange is shown here. Binary values (<iref it em="key configuration"/><xref target="key-configuration" format="none">key <t>A single request and response exchange is shown here. Binary values (<xref ta rget="key-configuration" format="none">key
configuration</xref>, secret keys, the content of messages, and intermediate val ues) configuration</xref>, secret keys, the content of messages, and intermediate val ues)
are shown in hexadecimal. The request and response here are minimal; the purpose 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 of this example is to show the cryptographic operations. In this example, the
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> is co nfigured with the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay " format="none">Oblivious Relay Resource</xref> URI of <xref target="dfn-client" format="none">Client</xref> is configured with the <xr ef 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 <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 Reso configured to map requests to this URI to the <xref target="dfn-gateway" format=
urce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref "none">Oblivious Gateway Resource</xref> URI
> URI <tt>https://example.com/oblivious/request</tt>. The <xref target="dfn-target" fo
<tt>https://example.com/oblivious/request</tt>. The <iref item="Target Resource" rmat="none">Target Resource</xref> URI, i.e., the
/><xref target="dfn-target" format="none">Target Resource</xref> URI, i.e., the resource the Client ultimately wishes to query, is <tt>https://example.com</tt>.
resource the <iref item="Client"/><xref target="dfn-client" format="none">Client </t>
</xref> ultimately wishes to query, is <tt>https://example.com</tt>.</t> <t>To begin the process, the Oblivious Gateway Resource generates a key pa
<t>To begin the process, the <iref item="Oblivious Gateway Resource"/><xre ir.
f target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> generates
a key pair.
In this example, the server chooses DHKEM(X25519, HKDF-SHA256) and generates In this example, the server chooses DHKEM(X25519, HKDF-SHA256) and generates
an X25519 key pair <xref target="X25519"/>. The X25519 secret key is:</t> an X25519 key pair <xref target="X25519"/>. The X25519 secret key is:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a 3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
]]></artwork> ]]></artwork>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> constructs a <iref item="key co nfiguration"/><xref target="key-configuration" format="none">key configuration</ xref> that includes the <t>The Oblivious Gateway Resource constructs a key configuration that incl udes the
corresponding public key as follows:</t> corresponding public key as follows:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e 01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003 79815500080001000100010003
]]></artwork> ]]></artwork>
<t>This <iref item="key configuration"/><xref target="key-configuration" f ormat="none">key configuration</xref> is somehow obtained by the <iref item="Cli ent"/><xref target="dfn-client" format="none">Client</xref>. Then, when a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> <t>This key configuration is somehow obtained by the Client. Then, when a Client
wishes to send an HTTP GET request to the target <tt>https://example.com</tt>, i t wishes to send an HTTP GET request to the target <tt>https://example.com</tt>, i t
constructs the following binary HTTP message:</t> constructs the following binary HTTP message:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
00034745540568747470730b6578616d706c652e636f6d012f 00034745540568747470730b6578616d706c652e636f6d012f
]]></artwork> ]]></artwork>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Client <t>The Client then reads the Oblivious Gateway Resource key configuration
</xref> then reads the <iref item="Oblivious Gateway Resource"/><xref target="df and
n-gateway" format="none">Oblivious Gateway Resource</xref> <iref item="key confi selects a mutually supported KDF and AEAD. In this example, the Client selects
guration"/><xref target="key-configuration" format="none">key configuration</xre HKDF-SHA256 and AES-128-GCM. The Client then generates an HPKE sending context
f> and
selects a mutually supported KDF and AEAD. In this example, the <iref item="Clie
nt"/><xref target="dfn-client" format="none">Client</xref> selects
HKDF-SHA256 and AES-128-GCM. The <iref item="Client"/><xref target="dfn-client"
format="none">Client</xref> then generates an HPKE sending context
that uses the server public key. This context is constructed from the following that uses the server public key. This context is constructed from the following
ephemeral secret key:</t> ephemeral secret key:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73 bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
]]></artwork> ]]></artwork>
<t>The corresponding public key is:</t> <t>The corresponding public key is:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472 4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
]]></artwork> ]]></artwork>
<t>The context is created with an <tt>info</tt> parameter of:</t> <t>The context is created with an <tt>info</tt> parameter of:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
6d6573736167652f626874747020726571756573740001002000010001 6d6573736167652f626874747020726571756573740001002000010001
]]></artwork> ]]></artwork>
<t>Applying the Seal operation from the HPKE context produces an encrypted <t>Applying the Seal operation from the HPKE context produces an encrypted
message, allowing the <iref item="Client"/><xref target="dfn-client" format="non e">Client</xref> to construct the following <iref item="Encapsulated Request"/>< xref target="dfn-enc-req" format="none">Encapsulated Request</xref>:</t> message, allowing the Client to construct the following <xref target="dfn-enc-re q" format="none">Encapsulated Request</xref>:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1 010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796 9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525 5e7d86b83dd440b2c0185204b4d63525
]]></artwork> ]]></artwork>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Client </xref> then sends this to the <iref item="Oblivious Relay Resource"/><xref targ et="dfn-relay" format="none">Oblivious Relay Resource</xref> in a POST request, <t>The Client then sends this to the Oblivious Relay Resource in a POST re quest,
which might look like the following HTTP/1.1 request:</t> which might look like the following HTTP/1.1 request:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /request.example.net/proxy HTTP/1.1 POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org Host: proxy.example.org
Content-Type: message/ohttp-req Content-Type: message/ohttp-req
Content-Length: 78 Content-Length: 78
<content is the Encapsulated Request above> <content is the Encapsulated Request above>
]]></sourcecode> ]]></sourcecode>
<t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" for <t>The Oblivious Relay Resource receives this request and forwards it to t
mat="none">Oblivious Relay Resource</xref> receives this request and forwards it he
to the Oblivious Gateway Resource, which might look like:</t>
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway Resource</xref>, which might look like:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /oblivious/request HTTP/1.1 POST /oblivious/request HTTP/1.1
Host: example.com Host: example.com
Content-Type: message/ohttp-req Content-Type: message/ohttp-req
Content-Length: 78 Content-Length: 78
<content is the Encapsulated Request above> <content is the Encapsulated Request above>
]]></sourcecode> ]]></sourcecode>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> receives this request, selects the key it <t>The <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 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="Oblivio message. As this request is directed to the same server, the Oblivious Gateway
us Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource does not need to initiate an HTTP request to the <xref target="dfn-targ
Resource</xref> does not need to initiate an HTTP request to the <iref item="Tar et" format="none">Target Resource</xref>. The
get Resource"/><xref target="dfn-target" format="none">Target Resource</xref>. T request can be served directly by the Target Resource, which generates a minimal
he
request can be served directly by the <iref item="Target Resource"/><xref target
="dfn-target" format="none">Target Resource</xref>, which generates a minimal
response (consisting of just a 200 status code) as follows:</t> response (consisting of just a 200 status code) as follows:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
0140c8 0140c8
]]></artwork> ]]></artwork>
<t>The response is constructed by exporting a secret from the HPKE context :</t> <t>The response is constructed by exporting a secret from the HPKE context :</t>
<!-- ikm for HKDF extract --> <!-- ikm for HKDF extract -->
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
62d87a6ba569ee81014c2641f52bea36 62d87a6ba569ee81014c2641f52bea36
]]></artwork> ]]></artwork>
<t>The key derivation for the <iref item="Encapsulated Response"/><xref ta rget="dfn-enc-res" format="none">Encapsulated Response</xref> uses both the enca psulated KEM <t>The key derivation for the <xref target="dfn-enc-res" format="none">Enc apsulated Response</xref> uses both the encapsulated KEM
key from the request and a randomly selected nonce. This produces a salt of:</t> key from the request and a randomly selected nonce. This produces a salt of:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472 4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
c789e7151fcba46158ca84b04464910d c789e7151fcba46158ca84b04464910d
]]></artwork> ]]></artwork>
<t>The salt and secret are both passed to the <tt>Extract</tt> function of the selected KDF <t>The salt and secret are both passed to the <tt>Extract</tt> function of the selected KDF
(HKDF-SHA256) to produce a pseudorandom key of:</t> (HKDF-SHA256) to produce a pseudorandom key of:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db 979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
]]></artwork> ]]></artwork>
skipping to change at line 2428 skipping to change at line 2430
field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):</t> field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
5d0172a080e428b16d298c4ea0db620d 5d0172a080e428b16d298c4ea0db620d
]]></artwork> ]]></artwork>
<t>With the same KDF and pseudorandom key, an info field of "nonce" is use d to <t>With the same KDF and pseudorandom key, an info field of "nonce" is use d to
generate a 12-byte nonce:</t> generate a 12-byte nonce:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
f6bf1aeb88d6df87007fa263 f6bf1aeb88d6df87007fa263
]]></artwork> ]]></artwork>
<t>The AEAD <tt>Seal()</tt> function is then used to encrypt the response, which is added <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> to the randomized nonce value to produce the Encapsulated Response:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd 857fbd
]]></artwork> ]]></artwork>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> constructs a response with the same content:</t> <t>The <xref target="dfn-gateway" format="none">Oblivious Gateway Resource </xref> constructs a response with the same content:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store Cache-Control: private, no-store
Content-Type: message/ohttp-res Content-Type: message/ohttp-res
Content-Length: 38 Content-Length: 38
<content is the Encapsulated Response> <content is the Encapsulated Response>
]]></sourcecode> ]]></sourcecode>
<t>The same response might then be generated by the <iref item="Oblivious <t>The same response might then be generated by the <xref target="dfn-rela
Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource y" format="none">Oblivious Relay Resource</xref>, which
</xref>, which might change as little as the <tt>Date</tt> header. The <xref target="dfn-client
might change as little as the <tt>Date</tt> header. The <iref item="Client"/><xr " format="none">Client</xref> is then able to use the
ef target="dfn-client" format="none">Client</xref> is then able to use the HPKE context it created and the nonce from the Encapsulated Response to
HPKE context it created and the nonce from the <iref item="Encapsulated Response
"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref> to
construct the AEAD key and nonce and decrypt the response.</t> construct the AEAD key and nonce and decrypt the response.</t>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This design is based on a design for Oblivious DNS (queries) over HTTPS (DoH), <t>This design is based on a design for Oblivious DNS (queries) over HTTPS (DoH),
described in <xref target="ODOH"/>. <contact fullname="David Benjamin"/>, <conta ct fullname="Mark Nottingham"/>, and described in <xref target="ODOH"/>. <contact fullname="David Benjamin"/>, <conta ct fullname="Mark Nottingham"/>, and
<contact fullname="Eric Rescorla"/> made technical contributions. The authors a lso thank <contact fullname="Eric Rescorla"/> made technical contributions. The authors a lso thank
<contact fullname="Ralph Giles"/>, <contact fullname="Lucas Pardue"/>, and <cont act fullname="Tommy Pauly"/> for invaluable <contact fullname="Ralph Giles"/>, <contact fullname="Lucas Pardue"/>, and <cont act fullname="Tommy Pauly"/> for invaluable
assistance.</t> assistance.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+2923bb2JUo+r6+Aq16aCkmaeouuaqcVklylbtsyW3JqZ2R
nRGBBCghJgE2AEpmXO5v2d9yvuzM67oAICWn0r3PGSM1du9YILAuc80175d+
v2/qrJ6mL6KNy9E0u8+KRRX9dH39bsMkxTiPZ/BLUsaTup+l9aRf3MUZ/H91
Pe9P4zqtajOG/7ktyuWLqKoTky9mo7R8ER3v7R+Z+xfRronLNIbBr9Lxoszq
5YZ5KMqPt2WxmLemjE7m82kGA2ZFHr3O67ScpUlGf26Y+zRfpC9MFP0d30ZR
vZzjFn+BubP8NvoRx8DnszibwnPc1r/hBgdFeYvP43J8B89xo9WL58/xNXyU
3acDfe05Png+KouHKn2OAzzHD2+z+m4xgk8JXA+3BLHnha61jyPieww9bwr/
/QGPMsiKxpfPO49icFfPphvmY7oE2CYIo340L7P7eLyUfxef5F9xCacNMAEg
0IN6kefp1Jh4Ud8VJX0K/xdFWV69iN4Oouu7YlYVOT1jZHiLQ+TBDwAMeF78
LZtOY3qQMlhn9b9Ni4c0r8tivhzkaR0Ofzo4GUS/FEXijX56V2ZVXczv0jLy
f6UpTqfFIpnAQaT+LOP44d/u0ngOWxpldUXzmLwoZ3D494Ax8O4Pry9O3v/x
RfT+1enxzvEOPEGU4b+3t4fyd//05PSn1xc/6vNteP4fH16f8t/DIb53/eaK
/jza2zvAz979fC6vHw2NyfJJMO/p5cXV66vr84tTmPx1/4xwpy9HM4+rqg9n
1h8XeQWbTnM6LlzJ9vYL2uH3upQd+jPJqvk0hpuG7zzfHmzL6zuNt3c73tZN
7zbe3et4d5eWfvnz63Pe7MHOwT5u5+zt1c5wuMcjKNW4BrQBbEgjuOFFnvR/
TPO05Gt4meP//75YwG3c4HkA619EOEh/uM/DxOVt6t+D6j4f1EUJOPvXdFzT
RYNHz+Xv6nmSVtlt3p/H87R8Di/2+YHcARzS4TL+12dkez+IzgBDpkAU8jT8
6WIASF3fpQ+Kz/aXd4PoanmflvgD/PLu/evLcPPvyqyA1/BA67QHWx0tqroX
xXkSXY3jaTyaptFpMZsvaoZIMYlObm/L9BZej67wYVVn4yoEzvZhf7jbDZxx
uZzXxaCqY8S0ZJAmC4AMkAkCx2CeTNaA4KcBrKUss9s47/+YjUZV+PPZIPqh
yNM73Onl2eVP/Xfn11fhdh3JPbu4igqADCHMVbR5eVb8tPUiOgFYxGPYUjxl
qIyX0Xl+F+fjdAZ0IKoL/DLc7s52f7gdbFd3+/DwMJindbWczYsqW8wIGfCD
55Nsmla86ep5VlWLdO/5vMB3+zzg8GgfodEJjMliOmVqc7VI7tK0uouuADVi
eBYrBWu+N4c9xDWQpwXsZh7ny67XgDSmH6M/xPflour6/Rq/i/4ArKnr13cp
XJPol0X3wA9xHr2Kl2nS8fPPCyDJwAbTbJaW044XLrLxR9jEFE4vzjt+X0V1
q7TM4HYBrin03hWEFdEfiuliltLp9aLXeADRXi+azwfR/uF+f/94R94/u3z9
ItoeDnb2Do9aJ0SYRpT35OLkzR+BVDZICxxICbzmbZGkU7w7TQmliUZHnWgk
zHRczJ6PLQd5zkIMnOp0CdT3EUT59wJOH1Ag+qlYTuF2r4AOTDHLYOaDo529
NE1xfx9+uQ439SGv4DogNUiT6Jd0FF3DjUGhpOvmBijwMbooauC9t3fxLCQY
+/3h4cob9LAr92a4/byOb5+DWPd84S2iX8sCnq/Y1S+7wAKvT36MXmV5goID
PH/1+vzNGfLKYG8nKCLVQKYXJRCAq3oJt5SIIVDX6IzoNB7jRVqjENgfxRXA
4KqY1A9wIpH3dVqth8b7YkkSSFzBotJpwuKMx1+GTZqy4YMESO5gMc6IfP7X
RAZ4Pl+MgL0ANUlLJtfP9ae/+E+ZyhrT7/ejeFQh9EDguL6DGwigXRCdA540
LrMR7D5EWWANKI3VxbiYRkDB8f9g7zhHBPwfqTtAhOTZWVpV8W1aDUxD0AUa
BSInDDSeZkJTZ/HHNJotpnU2B4ZTpv+5ANmywl8AZQug+HCJYP1Irx/gMgBD
hhMBcsbPzCjF+YlZwSfTLP8IPxdVOBIeocwI64YHWQL/ziZL+sW+CSdyF9/j
eHAZ0mhSFjN8wVRwbvJ9L3q4A/odgcQxxheLfLqEWeHmwN5roJ01MCQaNYeL
X0ULxBKYUGBFvzjo8EHMsiSZwoX7BmX/skgWhNzGEMTs4sr0PgXEtGIacOR4
hNCQjfGWasB/nI+hUwE9pOXiLuCoFzAACDo1AWLib14XFQEmLPIEgE0wK3BB
U31XQVDAH6XxV0InAp/OCrgLSTaZZGM4UVyIDjGG0wR5YTqNRqmFin8MhkcH
oJyDugRgTmEo+Og1YE2SwK2qcIK8AATNSrhoAHcQQosx6EkwGKIGvo23/D5L
YKM9GtSCbxYncqJZTYsZ4fbKMp3S9yQP1MCDCPHgwswQowjhkV8DBGR98B3i
SFEOIjguVkpgr3HZw63mKZ0dQBW2GGUz+PweDgRYPcEKRIlotKgNPs4QPeSY
ePkI4niUTUHTtLjssJhw/g5pTezNBOBqrAJHqYpFCVN5oJMTpKOdLhnFvdUi
alVGjwN/bp2ud4fu4KIEiG/xBDYjKCfgQgVhkt0CVRTSgPoc4igegYABNpSk
IFgilInCyLLi2xiEuxq2YXQbSu5pm0t4Oa1wQTDWAtcLGiEKp/BWkvaLyeRF
lE34TYQbYZ3QEAPKUM/iOIxBIEIeuMhVE8dvGDSMrfg2qaPftoY1dIA0Zhzl
6YMP3TxNE7qTivhIO9N4fGfvHvyW5hXAyELahIQPgIWIjzglS9bBYySmD/GS
r5qgs8WaHlzS8QLEZjhQZGAZ3MsY4OXjI54ZqKAJkqPrgv4k6gcTwXR0wgSO
CsEV8okJqCPruIShnTJrICoN3BTOizhGwCf4YvpcIY5QzYCNoRqfER2FnRqi
sABC3OeSoJPBFgBQMVxwAErJEIQ1Z/h9xUhfEWbN0joGHhtH1QJgD4Dz8ApX
5kHVR37cQ0BiJ4IfPb61ZRqDioUMyPhgHcNVBYqblqwlAbVYwWVB2d4eIAbH
01s49fpuFgnY4nkFV5ogN8ryuFw2gPb5M9sGvnyBLRJMl6MyI/nu3QIOZRz9
nKIKw/CHrWyiyr8F3+H/wlcAZ7luCKestHehZ8zOAGGawmVJmsz+3C4NTuK9
EqgRCEYpEO5TghWDlAV2hyA/8pnCR0Kh6ruyWNzCaUR6su7l93TG9lXaIg4n
WAaCrNkdEKoDP5jRnLjQu+KBTn3NrCAMJyjd+RvBke1ecO1z4sSNt3CMOdyF
lOfCeU6VbV3TzZzhUam+7B0i3tVcEJclJrzwQtdbazV2rXmKBKBKBZd5tn+t
fNrOQqqQ6Ab8OgcC4SWDg/5UBwilpw9b6ZbaWvxNj9wtjNayagk9vHQPKYgA
ceV9Cwvn66zC9uqT6wFnIypkqvEdnDl8KCwAyaB//YT10lUj3s435K8ooIHi
YEkvkA4kxcbjqKA04L0OhTqU9+APke1WIukmwNd8/lyJwfjLl62euxDIuquK
WKHsWtGtTEmwAdYDT1CwqWugDQuavjAw4wzlVhQImBORAGa/Rznym+jyHqlh
+mDMSd6gyXo4MxZPgTjCiS6jj7lclUmBBwzwAVr0O7KHiTC5RCSO8zUnonRt
lt3e4djj6SJB+WOGdqq2rPqA+74mtcYOUT1y6DBQtZjPgbvjTnl9CdDybFrJ
8pCcRXMmeR+B5OnVXINItDpcLPMlS9rTUr6GdeJQipM0haXQcm0t949UgOOv
Bo+CsYE29OEDCsfxeJzO9ULoAcP447gsl7LWLvqLVyqrKyvd47p9nUOfZ0iR
mbUHqpYnQq4/7RCzYDDmzHip+nXRx7s1i+dzYlpyxZvbxrU1R66+RdIEw33+
TCJWvwKpIwUehafBWgUf+UDU1QC3mD55ZIg0oFxEzqYmaNdjWpyhwekIMg10
JYzvwC1HaZMiZUVlmsZlvpJsw1RxvpS77InebcWKL9fIk0ZVNbVkl4k/CL55
hTclAjinoAzkRWloOY9wRF4pqLYgGYWKIaIV/HucZqjIoPvCzk1qsWV///Vf
/xXFcXV/KwaP9f8N+mv/G5hn9t/P5BP3RB792n4W/v2r+VUBhC/LR4yEkT76
Ff+fAoSf/apnzr+aX+2y/VEEdN4o4bPw7195R89aO3rWtaNn4Y6euR0Fy3D/
BU9uBAS/hkDVP/9VB7GQ6BpkxcNf3cdMeP6uj//0LKRiX/VxZCW16M9fOfOz
fuO/l97ZP2nmxiRNKHzVx00ofNXHUQMKX/FxCwoMiGAvT8O07hFfft3HX7Xn
7ocqlj/xYz3yX78L1v3sKR+7qb5m2Y8g/BOWbef98xM+5pvd2J5PO1d+vGp7
zeWEH//W+7xue2s/bu3wWce3/wgM8z4GTmc+v4i+mWS3/UKkbnYjfL+hUniH
x+cLmeqKkoyrziIcW10EhY+WuNESWlryRi+U4SNQo+cgXYxBBSGNqwKNGE0a
IFr5K/7yhS0P106KQGc+qDtj0oAD2al7bQMyE3gDgL5LVm+SmP3PyULTYcRQ
+ZrsBE5bVr1Y3xLzBsngIpCDlDhGKYqkkc+fZaIvXwZkFfDWhHIgCqjvLq+u
fYvbWj1O7bG4rFXiti9Wk8zkFgyL2Bs0xMTGDHL8FRvVVq5LD5tviEJ9vzl4
S6CzElswPFsgZmiTxhGtYuMZXVG7HIGknTdRQCwca405IOyrbaWJAmLHq5dz
dLBPlyDl3hdTXOEs/iiKTYAyfOYtIKed5zGILnNegVlr9/ERW+gNq3sOSI3r
ZLzrhMAp03pBQj19IWPIsTHGuWu1ZikNXE9bi9LbLEio6E7XWF8D9UhNqnLQ
Wd5alL3B6s2KopVY6S70k/G2CwKtOyg4R6+ENjGHbrzWcDi2gsccFuDjIW21
Tileo7COhIp8rqhIjZ3FjRwQpF3F5FnxcF0UVNOwX3XewB46btCsBNpVnKP3
CTW8bgsYDdhSG60nrkXiM6RPCRqK83FtMUHgDcdmHrOKWV/EqEDLVXHLd2yl
J699SXoRXDe+QevQdkyelgzRtqQZkmyMirrxT6+SS+LrqSu4muAL04a4BPX1
lmx2JlvDt8je9Y0GTbLDrGWzxLuuJrzYfxP9du4Ue6zekg25itJP+GJWGzE4
qV8CTTN4GVfeitDs2bY2oY6fjsRhpnRN/BKNhSM9usU4tGysCyf3y7emStMI
bYvoEuoLsDPaVJZWvqnEMyAArN6ilYGsNDAZTTGC4SeZ7C50oJOdKSLji0Vu
600iz4mJxV05LoqPGbkhJN7uy5de8wJufv58JZdte1vnJ6soujju4e7FU0Cl
nMIO1Z+DQ/7+/avTw6PdIzjtps3JUhO0h5IMwS6zlvGDzRmZ+CoBApMFBy6g
s8WLuCXObY02BAHTDYG2aRxGn5cZhvq4Kdh1zUIKh5GVWfWxarqrzbyo4PwA
7jQZflmXaVzPhNcF5uFqgT51vCzodsXL5HllCzRqT0ySzqfFkrGL1iWxGuLt
Rts3WjiTNkTxtgFpm6YlYTLw78rgqFP0zMPXhFUlBQhG1RI44gyQYZp9TDFQ
roDjwuhCwECA7TX83+fPEm2JGEGnYHx3L8iYBdxzQPNFDGdWo0sCtnKX3aIl
rJhLCCbFKqwCOq3IX2IsYQG+l4LMd3xfYM9X6NWkEXuG1s5xIiKHJIrU9usK
iNi8p9CLYcY6+1uaMCOoOTyhTOFW3iMtRCcs8V/GuhUrBgKTwqW9TxuLlrMm
+/u57xq2pCkmcyKKiA8ohNySpTYwbyrCj4vFNGH7NvomUwrXzsdslQ4Gz4ji
wYmzZ6OC7UkgRZJkcgRMkzCWqEKjeWq9iX0NnVC/KoeOnjgCAL95zkca+MRd
gTP4BAbcPDk/OdvidVRMsH4XnQH14zgcihm9LeP5Hdv2xa8It1cQPWV3qSfh
msjJEb5gG3+kG5738/R2CnIF3ryxi2+FvSrTRZQ7/xTjhSCiyRd6jtbX3FJv
pD4UAeTdVDbU8kVbipmdMM6IZwQOGKNP4XUMVIO/XkTe3xykQlhbogeJEAUX
Nb0nd8+KACAW6mQRSPicLR9uRzZpOY5kOpSk0inw2xpJ/mI0yyo8AVqVl5Gg
sSf4AiIkeWLc1Bn61pAMM0uHPxNY6BSvsQCEnQRdfK6iQIPlnME8A90Rrj46
wCq8JcQTELNY9ajovgGmuIOxgLcktyRpyocRqZ5Wv8Kd9PsGgAJ7eUhLG0zh
Qjx8p42w6TKiMC08XPI1WLKC7jm2neNWgOwSK7UxavQpYo0EjHSPjcsw8ypd
JEW+nAGAkEDTQdm9WscaHYIEU8jb8BCWsoT7z5oUUCTM7tBTJlYr+8fvpgUf
a7+ap2MMZrD61aYGRoD4Bl/iBTR1JqDGAIu5xtpvcdiRkgmBXDNcxPeDelGF
IYFHiwN6oytjXWpwHKhGl0vWt0Bs/xuz09sintpQJmVvIg2eFjndTsRXJBFn
GJ1Cq6tYcUVvHqaYVNHG2w9X1xs9/t/o4pL+/f78Pz68fn9+hv+++unkzRv7
DyNvXP10+eHNmfuX+/L08u3b84sz/hieRsEjs/H25I8bTB03Lt9dv768OHmz
wa5kPyIEt85RQqTaALkh2bUyCjoi0j+cvvt//s/2HgD3X0BE2tnePgbg8h9H
24fAcfEu5DwbyT38J2oIBsgmoAbdiCmKBXM4q2nlGYnw/iAB/hNC5s8vou9G
4/n23kt5gBsOHirMgocEs/aT1scMxI5HHdNYaAbPG5AO13vyx+Bvhbv38Lvf
A11Mo/720e9fmmYQLMnLmIiV5QXoU0u1M7H8StDV+CcVAPBtFPIMK+9I3X/3
J1ZwYNZvkkne5zgi+7hqPe+ybehLwHqB5/7nireqR19jlhi+Vq16rWq/t0r5
0TfJZx2819SD9E0J7VozZvX0QavHR+10ODdnaGio+jPHYBs0+ObpA2LM9xt1
uUg3vsAj7/C+OOsPppKcarQxGTDqVpicUyki9zbqwNOqsDYqQYuIaAWIfShi
vrDRDU2VWlz+nVFAnvUw+ql4QIztEWWAdUxSDhAU9kczJ5Z6UlgkL88pczDe
7mA30OfI/Qw3INrwlr4RceheQt59uD6Ut0DiAqnxAkFB2S9deM3wbNgGNdw4
9T8Qk+W7n8/7LhxdDLIuusA3FAfTV1+6I70aC1AD1W9ZgVrv3BIICb+stC/o
GjKbG1oueQnWHNcdlIc44ULW1N4VhUF6aPq5na6z+3CsM8kJn2qJA2W9iARP
xCCWn0iLXHJU6gZtasNtUi7olzUTye0pnUk55mhtsWevCn/pgahEyQzNkF6K
dnGxVj3rdsnqzuiOnpvJHnbPP2U3oP6oLgxnGiahHTMa2sGS/BHBE6N6OiC6
Gp4CPw+iTJy+NDdBULzmZXhwzNgAyx9JSFK3MZ3tcfo1LNSZFNW+T7JFpx4q
XgZBOgrZy1wMC1Kz27xAvd8TgjvsYCz7oQEHTb4N9izycBWx2IxeJytx8y4n
C84RsrG9Kh0a5tsJWxY5Ehb1PXRdaTAYnMote+lQ0IdtUaD0JBotaxLGgRVQ
FhA9EJceLk8FNeOcF7qO6IadY5sgjN1v3fREZbnJb/RcOP3cTYPrvrnHn8m6
qou6j6cLRKCTq9PXr1Hyo398D/LfcLgzBNkk1Z2Q1A7iNf77pqKBMD2CNfPV
K/wLfLJZbd0AUF6RFsUWKCeF8qd5IXmhIhlZOx8zBkw+JuMdkC1A8ZSUe0M8
Bo7Jfgx6PwZDpS0QYDAbqW5ke5A5YzFTmRnmvKKCh8maugGOg8SY51NJOuA5
Pn8jmcru2ReUzVAjCJ4iz2+92vVi1f2msZzcxvzHY7LfdGvtUWvglfZ5z1ng
+ZApxq2T8g8CX7OfXaCkPynI3OmRNhdZTi+yrUCTisiCR/wHAxR7K5ZPagJa
ywIrEGLyXXwvOIwKoXGGmUEr/0wtsXxRJaAbdUOEZSVSCfrjKk+Y8cBi7tLp
PJrEYzSN475o2aR2sguAjP40DevAS0QzOh4rQKGpid0SJojUxtwmuLd5bWU2
xEdct9hKbGqRTXsR3xZFy6F8SjwXxbyUsgbgdiWwgzojDG+jGt8Cm2dfy0qF
SBtZtw0RRGmrxxkEbDyQNAXKdSZVD61DQhvIlIsvG52T6EaJev4YHS7dS4K5
LdzhoFI1EKH1QAY19gbQytUNNS9q9sTRCtv442XJ0KcYxT3LqtQItMWgruKk
/EkE3N49BgXhm00r7AArXZ8pGl+JgKEwbMKkC2s2GgQx3NbzMmXnMY/CH8wt
84YZTbg38YWRzbl2Ic12bIRYADBy5iHUgKSZ88Bt+pYTMzZ/Pn+7ZX2WXvKB
tZIgNSRrKn/3Skil2fz57BV/ifZXZ4yA6yBW2G+6SKnlkj5N/YLAFxmyfaSC
uWJEwt9drDUlC9m4bRSlTCsQG/Zw/tY5O7ww7wWJFyLCskRD0QzVcoY2zWxs
XMD2gC3f9icv2yZYYCsSPI4AUprM0vwtJ+ihPPaZ72Hfg8oXMqpUTr5uwUai
Zutp1Zc0BuYjtIsru9QTF3b+Wep20KJen0Wb2wdbPX1GJ2kfwqm486MP8c/X
bgebR+5TBHFzOC+HaPNi/jH6XeR90Lm6N2l+CyiLo0TfR3uDwcH+/u7O+m82
d3e2osFggAu2gVVNWGp01QkVO5imbczE6KprFnJ7gmar0TCMl2LnxotOFT8E
maphR30QT1gQE8laX6ksXyQaNlo+4lAHDPDgL9rP9sEj4+PbNpPQmZXRt8dJ
C5XwTnYDecLZ4WBbrwm76/6En2+4Ndi9VhvR65OLE9LvbgFw5fLPm0EaepzH
XEmowsxCyr96fjf/mNL/N/iEJU2+wX/CMc76WVJt6V4dXlk9JbzUFm5eCiCG
qBNyqfXXfQFk6wbw88Y5fGHRScrGOzfY+K7IWIq3u3VwCqG052Cki16D7+Gp
qZjerSTQafpRcrwrEl9I6u+pzpquuTMsEov+T7bGdcuk9V3muAR2Qs7jrKR7
4MiZS2dzAk6TnSjdgeVZvtGRdtYSWJXTYSWE75Jp4469pKf1S4+qvfjuOTyg
50k0i8uPSfGQf7+xTe9aQNsPPKK86kAPBztttIfBNtys/x2In0wE8WErz5Mk
2KoQ66/YKzPqp2x2d81med7/ht3GaZy0t/s8mb40K4SJt2jIiq6XcxDlvuGS
Jih2f2F/zYYXovHc/bqhkjoFTZEtjDyILUJJLrqMnEcJSGLTqYAHQNMl0V43
Aw3RZe9GJ1E0oyCaHLOz+Sa12Ywq3xWlAsKp+ALBFgjOJIYwBUgaAiLFbMCJ
frL1DKKdPhGPx4mK1ex9sqLEsr1MJTeSzMSv93V243YRs4cUR87j2taywKCo
aUamoivaJuIJn94XEZucCdnIMhw4qchDMV14Km/HIt1BCwmhxElOGCZS5Rup
DWbdT8ReYV2JHmMENoCvuEVUvtIgNj1Nc8pXo18xwlpefEDW1AIyf1FWxmph
Gk4FI1L2aeGR30596kzI7pjtS6jztjQIVT9oSLQs62wYtlZkcjpVqjW6RLEg
C5z825CCjtod2UBzKhlAtTQEJTslJ707kmlKdCTQR9olZNg1dkeuco777usM
Qfy3l8NOqrZnyvCCvq2dDtEN9Fc2VtiDFPsU00LQ/zmU8naRVS7WxTdKWkMH
xducrMioFPQLaCyM1ufntOAGfjGd/dPGjYwveAMf3Wx46/3z5jd0XeD51qB7
BS42uWMJ1d+zhGrFEkguO/GC8IL4XMpS1LOaeNbALkMiDW9weNbPhSFhON93
CDhcOb0jDlR6PF+UWCAtv7VxnQp/Nj4Ca/CAjjfWVqqBS9oJaYGamJiqRuaB
IITx/TISYooTzdk1hKqILgR1px+8Ed7KAjYHg61AbbFDqL7yziba61hXlF+x
KFNWWDI/GV/fqfSdDgcTmaQdBMxqCCA23Eo9w9V5w2SgNZ3471heU23/VrIG
4CLOUM520uMYzRu5AeG6h2JVz0qK3zZiv2EelMCpoA1GsI9LUOA3YRQ0Qt9s
fasaNznT5CQRw9sH6eVcrLrJ7WBi8TiKJ9B3C7pAFVP7aSZF6dJjtJaJ/LgO
vIxJnav6O1Tyx7X+RroKDnLFML4SGB+BIn8B+7cj9N9Z8OrSujDbA5mid9e2
QkV8xYH4qBWCoGfz+Xn/PUUC2bv7XfbdnqS1516ATK3digzUXEewiMYKEnpg
FPRsQQi4EGGaL/vJLCtWauR0xBVULOr5wvrHbuijza0b56rxTGNenPMNnuuN
sV4qVS6fpucy7RXO4xHf6snEt3oC8eXxu6lvFVJfWcrXkd9qBfmVwdbTX3np
txHg6qkE2PqC2xRYFuLfk7zIxzZfjrC/my6appTTSRjllVWU0UYohNlG/yja
KDvvJI7eqV/QlolizeJPmxd5L7r4uEWEi/bvX2X5bDXl0sCNTtLFPz5Cu+yh
5JiwhGdyYc9ETMFuScY7X7z4/CpbbhCrMvKu3VzkNyhi3Vx8vBG377TA8mZ0
p6liD4jFFO9fykD0CfmG8RsyElZc+gvnIxXAY8xCQohSkWktYzLoUY2nGxE8
E4JpmxD+cQaEiDZp7CbJqaLxSRSl7m/LXQyUUhAMuIf7lJJ7VM9l8hY6UWAQ
GyhDUiZJAMaoQ8Z3jcYugsQTuIGw3sjzm55IwnIikjnUUuJI5VB91/cnaKZU
qHxt3sB7f8mSmy1XI9AdNlfEQjYSagHw0Qw/6ulkfnGcVRPNP76/2ZLCWr8j
l2NQywq532ZzmmTCa7MGwfANWNwNHiu/ZI2FNjN3SizCd4zl3bYAST61ynqa
N5KVu4OCUJj8izsgORMmlibQR1Wy8fTRTXu0W3jQLqpzG2tRy+QeM8AieijD
3dwlJXwyWnqGE1WRBDkAnHquSMzceVmQspRhgUc8HI0IR4GRmbkBVk5kQyGO
Jb9VvcZV4FiaLgMSZ33+sMimSWe8y+YNRi+s2hKFn1jlnsNNcB0byhdHSA4U
wBgHHf0tLQsa2wZPCfAGSPOxCi5yHU8zxPHQaLGgSBGyKngaa1M/ZbsIRhXF
njmbNyHhM5SgeorZViltWWoSInWTmCzcLKYGUY7HzRXmAv0QV+kVimFeVtv+
YJtcKlSYjoild1G9W2eL6pCFCQg+3jY+Y1qXxlwtSZTU5Gxdy001rj/VN8pp
whRaHJ60Js46l5QbR5iCnZA8eZXGU9yHlPfD0B+ZINgZ1cG2TED2lc7mdVB5
lUoq3sQxIulSag5H4wzrcfPax/UNp6yfOjti8zLgleHrqpiPX/kgaV5yr14f
IKh/z9GgcWGjEmhMSgKcRGxaVamYSslJwkgOUh1Qu9sF5mZkVFC10kQ6Y8VB
KbZqQ84kbo9EnUTExYBSoHfXvW5gl9H3coU2JRxsuxcxJSCxxvtPft/B32fr
fyeSsfp3ISJbW1RZqrkCCvdacVmbY0Zu0cPWb7C7LSSqAFlEJpjHuzWA7j0K
gtoyY/yJXhkQIm5s9HRC+l4P0i0URqYYzF40hldQtAtr3LVcTklKd2AlZ8Ar
gelU3iGLvAo4V+DnjvE/ibcwV3gHWAMIHfzCKoOl9p2k3iPz7goQXxjjnVwf
tIeomuJtznzU3Gqk8eNo7VCyilmpWqtBDvSq3c25MwRHZtxUQK/oxAPpI/L2
NsDa6hEI3WgB/H4j3iCyDWB57bidC+6ypZ/ZuASEe3ynmyOPC/NIgRWbNaNo
bTFRjr+lQyd7PC9oRxbAwA7Zqr+KDnGn5eZ8fA1UPlvTxQE4yIWIbjIAQ1+p
DPeUjfzPMehvfQb9rTs5rp0RyB/fgvLMu3hUgOGCKU5SsWJKgxUzg2wyYxi2
JAbVW8GW38MFwHV0cOaQfckx+JyG+S/xzrNUeOe4i21eztO8wTbLLrYZigM9
W5v8aazT8W2OMCIMIE6cR5M4myIfQowWGpfJ46qBW+uwiortCGL9JobGuKEc
SjmR5TiWaAMpZzLlUcb/Zm70GHt9lL8+ymA7OWzZZH3vN5klOv5nFUk6AniX
vhkQdiEvtDzu+tHzJDOEJdjty1JJuDWXvPfda156w2rdWPNGyArINiCzJjS5
UnNXF9dU+4wwR/7zZssEOlnoI7Q2m4ZSpt82K3G2y3nabACCjxW+VazeFEBt
aTknH4xm80b+1aH/nX+iQhOx9Vzc8D/gVdqQ/bTn8WwJxQ+xG3FKt7Sh67hJ
afy0/IuO42w6xHLl8YDXcaPJRZFPhzwDTuDmt+ENlbU533jmNU1NILIe2Jpi
qWrhhiHmqGVyxQ7T6MlgIYFhId3a3d+n2rFOaLU7CyhV8IBj/mjRMSphhXAu
HFMHK5c9BBvXCCxMdGEFwyLbX2hzN8ysziXVKBZSKGMjHDZv5uVHQAJ36Dfy
tme8lzoYYiBhOz5KGzYidTUM2QKYfZyhuIcuglrqYUeRGx8PVNCR3W43FcBU
v8hs5TKVE/i6s6K0SfWGcOuBSsVI0IYG8MwP0pQANoqlJLr36SLgcacY5CwM
P7c4pIaQ5U3PPyBEvH6/O6ilCqIFaSAHOhyuCb0fnTmeJROcTisYT+MRd2ra
gKcbrLLq5mjp7R16G2H0B9rLsAn3kOMe9KzDbfCtae6jY6k8rjZCiCJvvfQT
rvggUP+FTmI9iMriI0HJbgAVsFAXp1OwsOkFk/ecFCNSCwdf38wtdskAdvJQ
hxdbwGFoC2jilTUAeFLRKobS83DVTulp/82hPUNAv9sQgAN22gLUZN8cEs33
vK/fJEsJNf4+Cml7WxgSXtELfCImXBVKFUSVNoOXkA4EElcvCr/bAj34I7wh
RGsTP+gJo9gyihb0Al6FTXi7x/eFZjAOWZrvMI7CW7lYAEj31xFFhJI7xBYB
XpeaBEQUsIsP1+1JTTa/SWT5laJIywYQWRtApF4gO9okK7ELAAqxDXQTBX8V
DhPJ1gIMfPiOoqgHrUabQ4kMT70HiFSOQjlVSi8id8Ooqd5Kl/mypya9Xpds
0/PZsm9ZV4GpsiuhpXla0WIFJSHtCEYTFQpfYmYtfTSsKtNbewu8nFuRjkku
Xo0n9tz90CE/7dkLMxU3jxeIZMzbRhhZqzXVExKrWfzyw500vstFOmm4lcRH
uthF9dFVaSM2sRUhKa51+Ospyd5+2KRZGTYZ/T1hkxfhAxeI6GLwxPxeZTNs
PtywWEtwq5XeTBASKNukAlnkk1ThX4MFQuGR6uUtsoSbGeUGW5PYGx3Oy4o7
OtydiImuEW7Z1PWuaW7NxknYJRBMQ+XJC55wK+V75uoCzOPltIiTVmuIwB0V
RC1mzWgKgZhxIBJBv7MZS0s7irnnVm5BxSszujIyw8H5S5JkEObHP4a8aUPd
d0RqUNk1ovJoxEzEeo1VwOTnRgEvt+PUlg/rGd+bhanJCwrQ0CJGEq04o64Z
DPS0EXLGpzoGtMqqWeQX1TFBIR6X/i6l16zfMphM01Pjxv0Y6Dl70/qRElzS
QCLNObY8zqMVnKEnmeTSUgx75yrUXNCdBTcBT1VHC2QSzCrO5nZJoTGQ7jYE
5Sr7hgKsT6bxsho1AJebIkCCIOkkR6pKL/qhplLM8WjvaI/wEwtJoMzMCZOw
sZ7xi2VYqtJrnS0tTaBeu7oBYtFctRZrPoo20VrpWzcb3kcLUOzVaYj/bQW4
6dDRfqk6/erJRVwzPFALsSWkGq/zB46I/sYrkuJFqGu9W69Z4MpypGwH9gNy
OkMQFdNXBU1KlYWko9p1bL6mnrZ/pVLqwIT1czlDGP3+RiLogspfXIo0pK5e
XRjXngyWg4tBnJZqPR/ev1amuWpJ+LYeOwXlSFhPs+g04qKRXA7H1bec57oT
eAIw3a921kLkr11XysfA5npHvT35o60B54ozCti8LHivcKOAVDPyszxJQZJK
VhTSNr7opN/IEKt6izl8o9ZFXJYVvgNMT43fRWcVlOpCS0lrVZKebc5HJoVT
W43zBnNubt5Ra6ATaqyb/Y1u201wipUt0RXKtWUxTW2Ssy2MSrfJqwmuHT4x
71p6+xHPkXMyK/evuNDdKsgafJl4uggYM6OalIIFrUo0CRorbXdEqZwuHdmq
ajGbS1IIlpMwHkH0+4NqGpKaBcOyTQwSOV2/hKYlVFRx0ZLnMiYVmEQzarxJ
yS1BP9Jmd6RGF7rHe7xJCawxXSLvWCpBl8ZJtD+HGTqK+gTCg18bIx7fZel9
WK+Xq6pz7cLuqoNIPuQQab223EExosqQ9LIVS0mMhQG1Vphi50qEWkvs21sm
p06Awk0GYE/XM0fH1EAPOZhWyvF7aHl+ik/Uk8wiihQQQiKbPdZZivHBNDPr
vAq042KOekajoxUXjlkJH6SHZYqJWK7Dr9VeihF9MyX/XTxFP5RSFQcHgmte
ONK8Fm21/CES2LA1blhk33WotqRH6mtTl/BiYnz/9upGXzCNK5pGdbRWFPw2
zYLfEXVn5O5x4QeAc7+Qtz/QKMQp4h3AI4XmPX/L6tYAXin/eDwubDc1+mWh
JUVz1xJ4qeXNXQDqgSNUIjbGTN+wTTMCGcVZtih0MCd3dihe33qeAF2YumVB
dCsLuPn4M1biXiBOJuk/ikzkqwH2VMqxCgEGj8XBWAanqfS+ONtgPA5gm2tO
Qp1uGIvIdEE8Dnz78mXQvc7W/bJV1wL0UznDD7HvRYt8Sp0ukDqYMNSE0ywj
KdhOcSTS8Zhb2WrEuSfA6ZF0CsB6w3jcxwHai7hwsJcounTbaTQ78Br0aA8a
KQSyMxy6rxpy54pI+TdcsLzdzkPITE/pqg9aErNlfBa0RUoyTxO0pQAi5iHD
ir270RSeNfu4S3heKSkrfQjphbEEOTqpVArTAucd4i0wgqBiUH6PcdUOB01Y
3X9dEe2VWQrrL1lzgmb5QCJAWV2l04l5Kh1i46cHcVeceX+4F21qW6BrJoVb
isi2CNv+4GCwHxTotPH+FPLVyGqhG6IVqphiwHyII9iWwIsU+IeTxG7x7zGi
aNb0wRAT3Wt3xHDg1i4qWT+hfcae3hyLhpDN+rZEWnKf+mSFKo7LOGjmsSbV
rhQnm7xLdcaknwi+THpcJVnrWbDKze1Pn7b8Y5eoHjK1h0uWlvBULxL1rgTo
Zp1NDdu8aqw5Z7OUHJcXJ5WtD9+zrtsUjfuBQkx4uT0cYgob3OxFizFsDzHE
ynjqhFsUXsiBqzNq5ScrlTaLstuKjrEJ5kxpabTnbx+Tg2kWPwaFY6cyVIlW
DdqADkXCcDI/FrWSIu/N4gAiV/oma2EF2Au+vY4wL0vM33ufPjXkDZ6Yatdw
VlezfFCH2pl2frNOQWIFndEGsdrrkbDpeiKz2LrIJTbUiHYfImG47y0pe2or
3nnki4dDndGojOzN29G2KjAvaV8ErbyqtZMeBVibukzQNOpoGxUxZUCYcG+r
gduqvKxyTMV2ug5zm5cKlnn+klE6jhdiqF5hhDOzeIokAh6uqPvsiJd62hzB
JrlZHNcoPvceaSX1VcIy365OJrUH8sLmD7HdyBYu3udc0QrOVRlgXfuDbQJ/
k4uFevyWV6fWqjMNvmasovsIXxNMEswNMSHo8JHGtme9etos1QvqV+jqLGFD
+HudKrqqslSuJAcAzAB8EjvUVxyb9IRrnp9p0Zyn221VrCRxS417qe2ZYcud
cwujp9AuPAuNZzWvJ9ae4hFajyhI/WKE88pQEBaBuf2NxsxHzaSzEOKe3Chs
yZexqWCuO4+o4JxsPBMukHiV3QLbRsrWrm70riyAdGLNPlfbCDN28aE4A+Uv
dZP8y7v3lz+8OX/7/ev+2SBL60kfv4vnWb+cjA+PhoejDLV+kBo2NMOyO7sS
Z5Ox++RLcSvYaGR8coKLtd2tl3Tx9JlcsRXVLT7Q67DKbwj/VWkYBH74UREd
gewg3sqd5EKL2W0ASltmMVfnlkcQmPU+x0hwKZvKEQcEDnWf2leQanlEy5zF
GK34tsh70fAwepWOQA/a2YmGwxc7Ry+G+9GPb6/NKasrfYwveOG3FXsuC3z2
V2CN9jUpGQfiyAFsZgOBt/HiNxxnz2xQRvPGCwrD8TNKF/nHvHjAyoh+MrQH
OpsLLWB7TwY1zX/oqrB40mz76AQ+ayTuOa2f9aE4sHl7/Q6MfF1ix58if4x1
L4JAHYt7/oDaoqcqGjV4MYolq7AuUunVJncmw0Yl5ESWY0ZxlTkHyNJx7mrB
ZaCsiiKsAms8Jc6dOlquMwD5vR945BkgwK0o+ln1Uaxk9nq0WIbRuth3Kahc
Vc09A8sCYf4gPQczUmuyIpEK7mU6AQjcYYgIMLR2ndqmiaMtBLS1U4IQtlwE
QJpR2lAw2cd5pWrhqRS4Fb/u529smyDSTqQQLV4AZ2WHuWnJAG90mvjaQxHG
TzTbI1veETCtdi9jP3CiMRkRyaaJV/t/+e0FJEWS5a1moVHK/MZJbBMo4Uya
kUt2krCJoQ4i69qstTpBTclI8vj1O7SMoMLK3o/Td4iIH87eRTSSVFX3xuEw
Lxe8yq0IxIWjNamWUgHcqWlpV4llFM1FbJpjfzq8AoLLH/UXE0m0QcOCYOuS
y5aameGxmLJ536SNVWs9cZJkjs0dygU1BkPPpGgakbTIdbah0TJ6ip8yCCez
6osE1Wa10coErC02F7uGpkkfLY3Gp0AXKp2HjRypkprf2Izj7zFmR4uys/+E
b1OacDUze0bkW2w0ZZA77Vkx6BOGMjfmai261SIYv5C92k9srepHPHNdXlJD
1hwu66YtLfykAIatEA+st25DQrjSIPkFOGfBJQTwArXb2KONbTu8hrAuG1rX
sLYi7q7Vyun9lR6J4OtuKwaKWVSyPaj3LxH1ZpFT71OuZm9vX4klpMfiAlai
IgY0TPW6Dk121HU0sZY7MtZ1ulICNUM0HQFrGNuvZO1xp6AGLGBhTulH1w7Y
eMohcUMIWxrZeF2hbb8bMX2r3aCyVzgGZGH/aFhefkCSDhfd95ItRb3weGWv
GbcnPSKlN620JnahZvGouMfsPSZBU4w9lEKjQPU5s+h9eGFVUsG7T+IcG/Vr
W9GxO8jP7xdfsRWgafRbecg4jZShou5VmoycUANBe1arZHqfWPaiZVrbZguI
Oji4cASNK04T66uBlaKjA9hv2luDCFXEPRcZFOtbmluq42azVf2ji0JxtnCB
DTKg6osU6iBGblsqqjNakRrNoI2kruG4F0x0Zmg8k8wP2x19Z7Bud9ZjUrKl
roHylKFE9xCRjPPHmmSKrqMNHKNH8chSh0WewQcoFfblHWp3ARSijLHNMMwf
T5dW8hWpmi4LDsV9VefYs4JZENwlZEE887iY29tiNKZSrTx1LL0a+AK4idr9
fzJpdn+Jf/VPLk7e/PHq9ZU178vC3zfM/yxNapyFMT+Iha3R9cTvT9JpVKPe
aCxcO+kdV9ILbdokA1EbUxdaiuKlhCilj8imyMAWziTckkmxbLdtE01Ugq6e
HwCFVoo4576kUpJXPBxe25J1d0n1n1lWiTlE7TsojRI+4I7KUQZ/lssWOg7W
NSU3ru+nxoI3XxItDFv6rueMiKEB8P22Nt0WNVLatM2HNlYnP2WnP7hirJMm
NSo3ptzBJuxp00itxZgNvfZJ26zW3Ireh3ZjIsTvqwwvqm5VJHNpFc1AWkvA
s7yqU44sR1rWCobye583CgyTFAXXTucmGX5ewOvIxrg3iO39y+M6xQEIUzq4
HfQIXeg4x0gjJnzL5lmOTu4eNc1GI89sDpMiXhPyh7efWRZZk8ls2guyQuFQ
7qgtZ0auNe5JT0Tj9PLi4vz02k/IPx7sBgEM2qGHPVRBn2MxHWpHn0g7XBMA
Mqr93dVJhpkAHkEAi5r8g4YJpjOIaBd0S6Y9WordeXSuFIWEMVYJ0HNHZ3YL
5ihN0HFLP0fWnm01aXZvTdP7GGME4mC3gLarcEvmCRvMq2KrEiPcJ1g4UfKc
xGWLscyeOK7ArbU/xcbQLHda2cwpKBXfVmTqBp7EgBDVXburuw1baUQ5STee
daFAft8iP0yh3cJ75FIy/VbPZJmkeBOvfedpUXwkzvP59PLy59fnV5j0Izb+
GUGO49GiCSjbll5xZ+wgdKE5NneaR/+atRgEcQshTUJ9FvR5ehPd7p6O7gR0
4uGeX9Y62wmoaA0I9GMSszQ2zAmjdGGVnI9xrw9BRTZy9S1GLDvXbj9GYhDU
I1L7xhB2rncTes8jhZkQQZ0uanUF57N0cbZqFLstCiTU1MMQ0Tev4aotKSHh
5OLs8i02zdsbHh1oFpFLueX2Xz9TPUHkz4jO3PEwqz5WLuaQ3ZrSX51OCwFK
dIQSMaq0W1S0wUkSWUy4LEGhHfYWjh96jO5LS0bOWjGzLM9mYahLZxfWKJwz
5nur+tRKEV+tapWow2tXpu5/ozHsml1HBhQPpyX2y/fXoESOthxl8+SU8ULM
KhsAIaoow9IZQvzY+TBQckrmH/MIM20EmLfqrYdh6kEIBZtSxRTlaBY1BiB3
OjGHHvdcp3OjQV2f3cPBgRSxkThIz0hpY2QC8OgcXkAS03yazKhSxObCJvgz
7V4q/i/XX9a7kd3m+gbYuE0ECZGdgpYJkhUHIV0WZhrnitKTRRUMqflI36L1
TbgNSD1z8dORCX7pk/hqddakl5ajZULtXgI5VW8nneBKE18DDnfk5yTyxK0r
bcYsWg2FfQ4iSs1Co70HerXWsUOFrHnO6t00lrTjqMKoGssCbHgdxQJ3G/p7
JqttzGIzMMNvmBEMH8R4ewF9Twgs1tBkzxjrFVx1KEF0xEuV897nqGKKDFsV
QnzCFB70GVYw/WbKYRtHTp7NUAYhZzdr/5xVSKiERy9lCVYn7xA/cBGLxCiz
ijojMsNtt+W0shUahdDYEEvS6SvMP+dcVd1EY8lk6dYLIr6/SBOECMGaiuya
xUdXP11+eHNGIVsrx+QAOEsXrB+Ngqski1rorp9JxIKJhqV6nMCn6z0XnxTO
K5SzUkcggwvZMipOKQybIJi6gcSLLCZ1mje8g/HidubLKhww0R0mqhG3fqrS
HzLtVCvY8sp6mzhCFoSOV5fvfzl5f3Z+hnLH4c7usWClh9tdKQYP4c1oJDyE
8qqfuG7bv0j+xoSc62HGgbH+NUwulhwFFROsMR3kSdJLX2U5Gy1jj0STxGMF
NEtKVf/hOG5OWOIFigVZiw6i014zOv0EQ0vqNn3bXBgRanu6mWZfyaD5xNa3
zprW0wVRlpGuymny6MB8tIwVRX98Y5v2UEPTa5SeCYc+fxNADs1dcsQgiXQk
kNgDzQJnn3ci7CZk7UFySFq5Iyx0au4IxXIsLflx2NUhCXGINBsFpxzCi3Gw
cQ6rmC6bzQcV+12oIGooXMIhX86QlriDwDbE3hVKkoaYhqV9RukS65Y/iEAZ
TwGQyVIitVPb8mmFwYa4i5IgGI2bxVMcHPE8r1p4nOMCUdfgbqGOctUuQ8Jv
CmVlKNWQELr+kQDujrVRI29u0mDkBpmAldTU+o3FWW5pFGvc03IbFjK21BVr
re6m8g9sAWeixFM3pGLXQdkG+rgUd2Pewl0oSOKi6TiSnq02PvayUjgTIV8B
Jm0Mb6UHQjxaUKj0KAV1M8OEHLYDYe2AVJM30JeeLz1kz6m9QQykm68BXXNj
qVZRasKWkz/oUk5B8azRnIixV37ikm0XiZhPZqEVO2EcaSUCiICjqTK0yQe6
VUKyLErSUtFL0bDUPxHxbDcuq6jqyoMU/WziCO1dUYjP3sEAQTSaFmOMHLBn
EKSDsMVYU3NcgF0zYw73p4F7pGFRtKR1OTHmwyb69qQbDTpX9jBGnWOafUyn
2V3BqdrENVccjPpqfLZe+bb42GrKV2hzn8c1WgXZKD5aBAFJNmjXevvGWmvH
13FEjzUuxFitX1K6yoOh+pssigivF2sZeyxigwU/FKFcgdkRXeUT+y3eN4rS
ZET201utmmjUWDgBuI5iPGm68FoZwTNDNYo76CzMFSSLyt2H6TJkPMr6/NLH
pJbiscBWtD2ETZSKToynCVGemRYSsWvluYEmi90QpAfqdM7zI/IuJc4Hq6NN
0WRtaQz8ILfmbxr6Rxw3zRFj4LivUAIfY7mEpKg0NE2jJBR/RsDIJ5lyCSRO
dN2onwZfJN/05wKERksXOCwRKM5/tdWzwQWMFU+KMJDYNLogKDWVxAI4xiO0
f4eSuHShDz6wtsMgjUt8z7pNXA5vFOsIzcKtst1qPMUYFulkYdhziQenPn0N
HKDoXLGC4i2iyto8eNk1utT0JMiRvBWaKswqUwX5sCKlMWQtrryBZSoeXxnF
wNbqYnqpy6T6Uh2eUWuBob6JWMyOh/NYS8/bvXDbh5gZYNPjxKORWZ1SVyiE
hUahzApynFhTGYNO5d4Awlc+QqWomEqroZyr9Dg8UY4gb+JoeBh3sEwXq8W7
EUWLWIc6JQOnp4VFKmke8EwH4hhnunTqFT5RZ+3nb2osnfWBGzRSlIrt99RW
mdjoWwb+Rtq8hFCCIObbSG0IRTuGhU9REqoVjHDVM4prtAZ0bS5FJEloD/mn
C8tQfU/AwtuGl0tBqzB10yM+YtGitbZKrLeYnIwCJe+603zqF4KxS0WoVCKc
mG7hpCOoR3RwNwzoendIJxIv+OUJhSvWBN24kFfNbjGSxup8Mr2oBSerjqhe
ShXe3UJV9jA+1fXst05ropGIGWEIC+XN44UWM1oPOAX7gSxpI1EsjOubYWE6
EnN5O6C8YM5S2iGe0b3j0wstckAhrYeXZUyemTRJHVCKmSAS8A5tSGmc1RKw
5hW5qwoepFKDC4kYqsT5LX9yAj8wUxyBxH+45qSM5CjV4A9WrvSAJ03CJTHf
5wdEWRVdyGdnXZOAOrXn5wNuyL+Qr4OpPkCKBgjP09OT6LjJdNUKKsnUMM2l
J8Qq0LpPICvNYnSGIlquDkkjny3Zh1vBK4VoSW2a5AR4r7iJb5p2zi6Co3ef
/LgrkbJwrWtsadyJHsMkzfWbq8CV6WuvWoh0SeYXTS2E5eZJjP4YEQTwVLJp
eouF2lTQFG5Hyf3YN6y0vsaUC3lSsh7O5baLxec1K5gFimyGx9wGpGf7X19R
jrEIz2KOhgfO2Xc6kWH3I/B2QllUjpozRdE7+ZKK3QHx1CBHv5iwNHDya+BV
zQzo3cERzuAVxnstOntXmT+/GlyoKlNHByFhGkfstxXSc6I0GJQSTaNA4VZP
DHVheUNPHPTspAo3yRcerKTclbO9+fBWW7VIrpSNqhYI1CdUVhXxhSDIgeYV
xZwQ+okqAOp6NucacB1FBwHg6DuzKkcrNfhQbe873ECu+8ddLCnBXheWgboj
urqjix4tkS+hHn6wqn924nm2UX/t8k2eWypUBT07XcsPtzb7llTtQl1UZacX
SiK49FZglMaY1FyuImDrZ7ow8WoMIlyZFRIvbitNiNwkl4fDtB9LAe0OhQ6T
ocO47/ZgHWNUrpyHi9awRv52ib1e0Dyz6YbqtAayxVeHEB3IS/JUKbu6I+EE
K9MscjaMt+W8uOI0IDsxW3RcmAAaToHP42lhPBJaTyvrE9ALiUODOgD/Ej6P
KHmXTueOmNxiF4da4phIAasa4ZKv0eEkbc9t6L8fR/SV5bAkJskOtVo11SAP
zb1WJqhaFpUKm0pdGUpe4q2qll6xlm49CgXZDpzt8REfpghFK4Ism8rYmjhL
ETk0xDF2qSW48ICuSUJRM97Rr+aixaT8qEvsOZb3KU3BRfCgWOa8RIUGeuJi
N7hiagXcekbZsMUcvYsaOygpnvYFGMhzyalYna0KmXenbt4HihcHsjgewSHe
zB0DXcQTy50iUVGB5kYUPRvsNJe/wkDhQuV50qp6wlZUIxBPPaV7Gk6XU9ps
U6HoHtiGgCpLu3qKMpRbpazG+FUFGDowoqd9UsdxSqrjnTPvwUift5R7h2j/
WMUXS/EJMWOMC8+FnME/xy6ACMm4sRoHcfgyvV1wFCy+yrcMLgq+r9KYcC3O
AYWtYcgTpuk5t0pFHYC6QovdIgO/vh/dY9vXNpxm1gtmlWCQPGGuGpHJFa7V
7l98USgeUrP/OPNPdpYEZhQ2uXOHWk0jpGu3t7MTbX7IpcoKafWSK7tlwuoY
J/5YVvKJaQQ/F1GOXV7mAAy7Sm/9mrbVdB2OuqsBCeZZ+7JfQ8K45AJXXw/G
9VfdGbFMkWzUySKTrDy9pFxgRAtssG/EFq5khx2+TgM4otLdOIlbRcBdOiNr
K/cFtqOJRMOBbn4paKnwAdJqL6K6C2xnQXSksvm2djm3z5PqPmNqUEnbRMhS
EcsKxayRuDGYnzspjPtYcOhRVkoRS2pSLHUPVnVAkC8f4ITHSFz5DlbLGQj1
JQeSImHNamPln3BF9AYCz69brXGFY/GH2AM1a6HbWZzcVQtHVnPCzJ3rgsOD
Lx52uKRqKxuJ5YrLHLKMNGdV1JcaCdSah8rVfzhRg+ymc5I5nIEV7e8VOXn5
JdXrWPy0wZfdrlahS1KwkbVkWVF3tQcv8JZMY3cUYAoUP6VIlWbGh2ixxE/I
Lcqan7ivVhuxmMDyWnyPyKJEAM7Y6e8VmKDIJrMqfwlwAbX0NC7RFYod2hpl
j0ivhFe4tj+oe/9C5a0Ph1wWWHlYnyVIBjnKEa64o5guXe0Xl8tsqKATQ5XK
BZOALTHw4enGumWx2qstD43PtxzuYsIQkXSGCgMuqkx90S7cLwqctk1QoHPZ
NrZ+BoGjRY3jRAmNUNgwCq/B31RJUPMFYrDYnJUR1+julViwHqJ1Z10WbeSl
naDcqEnxvuFxkRMhIJomG8KDoeopi9tbzHbTHFMqsslePpTQrLjvBwsE+Lwi
/hVN8AUaojgTH72X6IAgKwmSrNhgRRQHAK8WosfO2eyDIjF5DqOg+F5YzNc8
xLY2EHIrLrFhpSa+l1T/Yid6f/7qw9X52V+urt+fn7yVJH8u6+MCUo8G24M9
T7Pf6llDwvPd6Kfdv7w//48P51fX8L//fn56fX7WPU50xF2T1QTA7v7ox8uT
X07+GE1KqtjDWi66hNKcQ4mcrLKZ5S4dgVmPEaa0RegNAIZjRJ2O77w6WclM
GRSLLMYgs5cIDC0EYriI9PY2XHHLOuAjDNEFvuzGo+h/W2pZqtlUXMWkho0v
uESzUab+lQti+0YMe+7LVbf6TxU0MFhBnWBWVlZRRPFQPMiy8vtNVIwQQSUM
YJnUzAX+KFGr2wShnXqFBZk01CgJxT7JPqYWQNgGRKOKvE6rLv+S5GMOn8nU
i9XXMH1+bqs3YM0KGEdjs5KuwP+qMCjts+zkhfIBLhAlcUKHhNsQjqEq+gA6
+UyqoY3E5ijwdzqnbhTpZajw2nwbCgHw2m+oyIphGpUZB/XxWDiJuC47OatC
15ZGuqEvio7KT272TYN0hOknPN8MXevWhUa6p5eKLDvS6AyJiST8cUzMZuK4
0qp2o0RauDCJUe5DgXQYOGRD/mqvrXYxV/dVIg6JZknFWN1/sLo36joNa9Ra
zbmKJ6nYbCsvpwrFcdhMNQHgFCUr9Uj3jZ/w1PNSoCmOo7CFpfL7YnpvvZKz
rJLyjMz/Uc8xzuFm66wDCGfzomYrsL+kEfelQMaz4CpEFoAMNIMwbERIZjO0
+IqfGah9cZujwYmri1q89ea0/gorl2EDY+uAkSbL8jb1E0pzq7TL4QmmsAvP
Kk19EadvVNTWplYcyhpkljpHCd0wSS3Wpn7sMaCvK7ysEs3qkr7K1FhxR9zN
Hxi6WHyJDvLE0T/niBBjiO2JEN3g+40Kllm3iFdpjWHjWXFRT5yXGcyHMU/A
g28tcnAlq84+CC1Dk9OdsVEYr4mVOEfENZCcbiNhQECDJT5ZMpXX7pAPTZta
chsb3vq6NDaJHiNBbkYWUD94wwvXQO83CJacxWKNHhpnEkif1aNlchFLNaRd
cgCDYtRcy6PCsgiApXlSPBip9c1dBiR3zC/OwwEVHvN6pEwe3ZSqLkQ88Les
8lHl9MGsknXAuFfwEV7fv4qFn7tlGon49qKV1YYjJuaRvREoDXvu5B6nGKg4
IGXyHwGfyNFeGKVlj9agh5bEnFGXhD9lHhTYWz1gnRi3RcTnjEQt3CfJLSzg
d+Cay+NoVVLwawCIhkASTB4MP1jfOzh0iHEokLqzaBRE2aCmjaG0dGqb16qG
LcKjvzsFFTvBRaT0pzINNs5Mm1KRPcGtLqbAObUkCI7vf2bj7RbT2sAYDVFE
q6pq4FZG6U1/JWsoTPQDh0LHUjGKhQwYKZtPgU6iJ7hfl9mcpiXjMl8C68VA
LQJOWRkYvKAGVfE+oEiIxWM+gkhmmE+gIEo52hzdgWGT6K62XSK8OFYGpK3Q
jneIuQvIhUEaiA0bJZ6A+QfTqWLDxzSdw+CU+WDjGOWIaDJ2RnuhBLqklHIq
QQqlfI4pdfJYh1FW6+LEVotIMlmsHZD9NA/y5Kv1mS2NUm6UJEMRQ1pypCIq
3xuhCyTzyNJbs3s0zbNWkqhqyVqQlfYNqBpUF5Hr1WDY75mHeJ+/wRJx/Un2
6ctTKLFVyf1QYM3JsbyGdmf04nhXHGNZGDC6Hy1qjIXiU0of9a23TJmlbJ/5
7693ibAISl3ae46GPMcJRYO2nN3fdzMbEqnpIndBfLYaJQGeAfr/12qUO0e/
oRolAdsvRJkQc1cRzKYsOvTxIiHJ19ioUekBdG2NSjXZkaj4CufDIpVnWWVj
Jm2tCorK84gfMjoyra1rlejEOnH0eAnlSv3V7vv7i+t3mNe1fzzcRx+njRwg
LhKwlmZgPQjusyIn7ZlHcwmMZCSBwU/fXJ7+fPXz+S/fn12+HmDh9e29/ee7
27u7x/sHA/hfQJZD9hW7tJxVMrHvFfeNrq62mVRgNbR2rYJN/XLr0vaBlBiT
Zlsh22Ldu08sQDT7gT/WNWj1UFpyRUzRWZhxas0FPetqihOU3MjZZh37NOjJ
rV2ejQlrhhLtDXbU4tU/PTn96fXFjxRQ9AurMgKSMGHVaPI58iDbI5xW5btX
ZG/WCdoqYaDlDox2hWaKEcfV/a151tf/nkX8n3vSb/7m/fTM/KqHHf0qX/4q
Nku8CHocv+pPEkAA/zT6vv9l5Fcb83/71TGdX3m1z1qr9Zf8LFztM1ltMJ37
79cV/6Z1/pZvlK48+Ztn36/572V4KC9/29rWfoMsQ3MUvw4Gz5iI6jffrdvQ
s+9C/PqfhfWvuNgPcy6Iy4t+9Jv/gfPx+RfRBOJiyr7eK5VQghRswLIu+1o2
o8T0mlx1jkKv60JTYHia+FJaykKYvM9WLDEvJmKYUy8aRZ6j7Qp1xFuvu2Cz
UKOt5+wKVaHuo+HYNdcQKSjjlW1hGMWGAmZNugf5tYM1EPuySfmZBDnSWkjh
KdOHMpPchYAdNFKkfdHZa7jA/ra51mVfGTwTxE75VQKYH2p5JWRjTov0nXl1
qRkmnm537TKQNf3PKiji/XGiZsC2OFg3FS/UHZXFoJi8dcqPCvSS/8vuMmes
U/7nSwiitohpTbwrvn8uCw9HLFRj9Kt5Q2+OlibzpZBTfKGPMmdZTG+kohOq
DoBIN3nRJ4vMDbWI4HQwl58iJSTiym0FA8vylZKGQjCQeTaxCrZdEV6PuvgI
GLMhagJpPH+AAw5lpa1mGSI8Kj1lOpGnSzQaycFShpoA/SxqacfsG76lu5it
Fd60+6DXNahR8BXrsQZCmzYjoQ6i7nkqMQcxSEEDFE7h/JbSR8mGSftdSDhl
Ud6v+P0wpMH6f43Dm0TjGDAPa5Ky5W9iQ3TCTgCYHCDkDiTk5lxiEffBEQST
SkRVo5Z6jVQECFFqY0eLaSJWbGobE9uiIFJRnbtAvCuqGtAbo+dnmFKghc4V
RJzi2ALQHD8bu89siWO/U3ToYvbaJpPLGJX1pn+uuyqEm4doOW1cSoVRyV6h
dFz3UAyaIkdQX6nQ2K91p7F4Qs9w2oJ4fNLbaXZLMSzkJwLVsRhnsebhuiAM
tyA/SIr3RG1ayDTjArdaO5IKSl68H+Xxudwvyt4jB1iRY8oKHxnllahXzgGf
5rD4YlOFH4uV9lbJ3E9SGD0bknhz7iUZ2tWQRSj7VmippEWIzOE5aeJ8KPhq
o7KOhHegTde5RdXRk010lzxEmXrbTXrMXTQ0RfySsm0FofGSyZa+hvh4A/K4
CqJJNSqTR7p+cwXU7INrVmyXRYAkh6KWMetwujS7aI4LzWqw67LA17DF4CG6
mqWrVYABGBPdSNDRpL6ihpsldfT9rCd7TlTqQMHtI5aQInK5cGaxjQAtaitP
eUcV1rdlQ985lpIDWtep3jcNLZUIcRL6sq6GDQs0rbZUesUmGV6cOZBlFyn2
+fOHX645o6Oj2IyxJQXuF1PESHFli5NIvJnk8I6o3pj2ehFbe1BDEm1DCUDx
b6nH7l0vDo/RKCjYaT4WIRgTMlLjSwmZeOIleM0Wa0A0Z5OOdnVwLIouLsb5
mzAZJMz4I2Kna8tc0wSK6/urFJENKiUbzwhmHSR48m9RwIrQgudaZnBVYxK9
JOulXeuWfuU8JK/ux+fPtlkMGlPLlMvEc+cPZPfKOMTm0uzU7I2q/ZdYeNts
Gkmw2JZ5/+r04Gj3iEJ6MJA2q6NbBCHQ9DskjGEREw1osALvahOcLK+7DwAW
UnExBRljoB8gY8L229+6Olv+MM2vYHvynu3YvXJ+wKBkqnKD5no54PlNlyhD
7D8xnUlO9Avz03tyzmG9f5YR47K2AbY2sA2DCQpaJ3DKaYCUadU9M4dDVYWX
/BckwVVq3XKlpYIUSNh6mCGhfgLBFT9unUKy86U3f6v6vDdLmXqBaY1eOe0m
7jxLvy+5F9pUkbkAPGYIM6IpGnOzIJ6hnSIYlFbkAcce/bFB5nYW17qlo5pn
6PCBVZiuVXDMmNRG5aAZD60aoTmwPC9v7tD12vTCblS3txioLtigHl8V4IRN
uZOsoo68LSQ5YU+OpshvY8ukjpbHrP12EN1tRToav65oD+Jl4a3qLOEM9VJR
sQpL/TniwOCWAB7PYuA6WyDvBhWAPX4pBV9oJJ7k4ojXMrXG9M44YosJYQMT
I5INeyc0vj+M7NeUUy/zpjvHp5mxWJFc5coZwEDvz08v3749vzg7P1P8X9c5
96RVCd96/zSJEuWIqNlopaN9fPuEKacxom7wfrtc1wurOTcnpUu+c6PwXSNJ
Cc0nt5havE5c9+uxkmjPmypsn6X1BjatGPvAXcS81YDakTLme61lbevjNkZf
qq+h1/WCIYd1s3rJ+nSfvIiC6j5oJnL2BgL1WNtPvKIAVUzsoXLwa8dlRg3U
VSqVLZ2UTWmMwPNX5yhTdTeGd5po6qsCkFykY+mybKvI2FMe+EKp9d220dOG
AcH5k5+l7BhM0XNtKwQOeKQC81KNzIfbEyKcSAN05eNtKXe+Qppdj6qIdIbp
xg8SrMNRllKrhuMYNaXQx8ewMiRrkTa8opWKi0EjpWbo+3mMT6ER5pvonYhP
rVZuKi8Zg60rsKeQlWDEDqJdRUDkJT0gtcpFEBbIm+PY1WkqFZlQfrft4cNS
7loJsrvPZ1O16a7kftL9cVDldmVTpw/vXzcb6yiGtGR12+FlHSuDAdFW0WoR
K/J3Nol8XSloaUxRpxQS5BoiWeeDljczrYvr+/7CQgNWzwvDN9UYiuy+0UUQ
CDKVAPGy4fz4fcsu2noMh9Ksi4UjyDzWEtfWT+SQj6DudRDw2Fl73xpYO6rk
uiMqF3nQAEvZias2sY4ZcWQ6mVxZzKzJgCfhdVIEN8y9mnBOk00HT7hcDUVN
pqW5LYsFBld56euCLY2WFewdEPRZcAdkjE6UtzuvAYnw+nnqAie84jmYsWTm
hG5jW2k1yyegJ2diCfC0bmdPWbHIwhQ5cMtzrE7FYfaauYfKh73xK61QVDGV
kh9CZf2RieH03nqulsbPJgxUxHyusTINF7WIaG0NPF4iAEXApnnQMMMqo14m
gBRxo5DRjpbFdLtsh0Zb9ofztkB/pQwjP1jXk3olILXrjKuwIIxnCpJI4ByO
IEsWMLYtWiNavpbUDcLY4/siSwyFP1BVEwrudUjqKhb5Nt6HNEbnjALFSy1n
S7EyNY65l7hhF7sSj0m+biKTGC+Elnu9j2U4zSILGsJ4LWeFe5EfSC1PyEVn
syJx+Cq5dynDi2I9K6+/XAvPsGfIxdXrq+vzi9M/+tlGhWQOTZopnt1DiX0X
mHFFOl+jWJHL+2j1O/F9DZQmqUkuqEbhpOgrcR1JmA6Z1U1LWm3PtfuJpkh0
GNl6VCIUDbnNRioWvbTIFo9JPVHCvgWSamjL8bQal6FVoKMpieoRM+3a7hfS
NJ8/v3p9/uaMIn68nEIcK+g0aDUSd0OADVOUO4XKNsA2WmToK+AXsBN9tYRz
mzF3tcjsqmq2KmPbkiYgi11qDiT1U0uiM1cWpiWeuZIxqs3bhEnbbvMeC8ks
KpdbKeN65WZCK4V4wVwroOgSSB16UrVGYDPRN0mkcgxxuuK2jOdAdsjWip/R
dHgc+TioU2p8AT3Whgp+8oQKrKmtbEZZ77hwRjjkD1KUxDNWE3eD5XTV+NJa
n0TLqkgLNLmoaePV+Ofgh4Tj/TX2ui7m2KxqySHP9SIRD5tm4PLhA65dnl3+
1H93fn1FDWkW2mUlsesH8vCJwiKmUtJRF4exqdRryJbYwuBzagGT/Y28BW6N
AtiBpKZrimo8Z6KMMnzxadkn3FQssfYJtfRgtftP6EcC/tiviz6yyRkPscJs
0RCdHq882K6/i9fet7Vof9anNaHh2Oop1msLS4dIxZVHV8L9jZCBE7yR08l9
liaknDLX7KeNO7V8Qav9rF2pZAlUUpfV2rJcxRrtibCuWZ409sFPaOvUWEuV
7zD9fkX4SMZpUV5modc0Ac1PJO+QeYwlD1vNXJJ5bJx12I2d9BDNa1iJIti5
AMUfHssZnNYF7HAFajKysgBuSAXlYoBSVM0WAHZi4NpmnLYXnspE1k0s+hSo
IxEmchMf/Pz599fnb9+9Obk+x3Dgg31MqeyxviOylSZ0rKntpslDtqWWpsdF
F0JU/Go1DfJqld12lz0lScS80GqSUYWrWwyvsnYF46VGarMfPT0nzEjyLBc9
A6p/hzHCNmKKxoZ3r99caZM5EXl+ucum7Gf11ilfpEmgx/aCdYJwlSTTdFR8
AopIBNzLAJX0+GhBcXWCvw+eS75VnMBo7Ms4aHLgV3Dpdt9oeDYKKt9hjDww
nf/88oXKRronbCppzMrFaIRvoYows6eoAqaaW7kku9a2pe6HQPBcrd7gBCm+
yY/N8qLyLJMLG57wMCYYplkwGGQCmqvZmbWrg3tc+94OjiRQnc8enDgeotcn
FycN4QRICD68o1ZYtyjGlpTjralQ/lmI2X3DeUqrDfkKw+hq893aFAYainMX
Xva8KWpNTU44i38itT3Yofki2rjxEyqcW/VmAysb0Lmzl3WrB+9qsRh+D1Dk
ZsPoa4QwW2wFar/pD0iIRG3iFTpcGRbX6q2cwCIMcIMO6R2HOX49dNoJHi8l
pcOtX3/Gp9hSk/ZhAeJWr+/Zn1y1x25Q+s7vz984kLL+suYAfDe161cSd5iX
RH9uXE3UkPDjPJ6lL4wJcmeMuVqM6uBXNzc3iafObWiSmaHXp6J3Lp6fAAGY
i9TV9SPIMgV7n4KrQC9scM3NDWpq1OUbpLeuxFirsQFfJIKWZHep2dLxGc3+
bkEdNlNnJ6Y36AXA+uh4b/8IFG5fH7ZGsUZoAH1DMtJTTiCurBGjqRhQp/G4
c8rWeb0qY+7Z5JkVV+31xIm/nt5Iv39Xv/xuVD5/+d1z+EcCqticKrh9v0G8
c1xvvIQlfZfUL9/GtyCDsdCwWW29+O55gl8kL2EG+Hei751hiAU3CY6nGYok
8cymCAqIVn78Cplj+gnoKGZwrpvmLS6zLioQkPAbAjzm2q385nkyfQmnDhgo
Qmk6i7OpNYly1446lk7JamlsgQthhWh3Qk2oq3+NTniA1OqSjIN5QrwUCBt9
h17Iywu8LVz1mf1jufcGHxSNanF73SSnpN/RossCzZ/01evz61cYiN86Rrga
RHhadLmD5iB9VpLTQccDBM+9sIpR4NgMqpxQfRP5XUoAK6sPonXkMw44CWiO
Jgiuokbw5T+JkRKjNmF5ElnpGg9lxch5QILiOB0HXv2TNP2TNH09aeqgTF3S
UJlWKylT9WTKJObDr6VM/NnfRZr+KSf93yVNLpTvn7Tpn7Tp62nTe9YfbcC6
pE75WqaSqEA5bCmunHyDNd6WVo9fq7DCxmO9gKC2ubIRjg59eP/6Bezh76lb
ACNghiZ+TqmYF0UdndjAbIQ7uvj4VGiZV1zV4hRQBj/aGw7xJcntxyefP9tC
HF+oSIGSiK+BrqdLrwOx06v/vwxnu0oP2A3a1lYSNR/ltxyEnVgX9MQT6WPc
Wjz+SLaqU4kHjbQEBflu1PPgtzE35rt/gS9/tBUK2ZJIq4g2FWq3WX23GA1g
vuczjKjI4arOKrVnbL0w7z9cXf/lzeWP3/OH47i8LaIaJ+v/7770dQHqWFU9
DuDoiZkdfs2LPrDseDGt3Yv9uawAfp9mI/wffhV4hZ9x+BebbYkV14GxomG3
fzf/CNccc9fyf62jacFWMp74ORbS5awVPwNtAPB7SZ567kHhN/dqueeoDNYd
ujIwg2wQ/cBcS8rqbCLSNCKnXMqVVMT1XKMaod5rpO7W2l91i0px8oQZzvkp
ToCnzzD94fpuxVptW0Hyp8XTb9lSyCmcRsPbtNyL+BruJF6x4eGcp875/zoP
vgzqRrC7KXCYrHUZoQ+imJgbxTLy4Q1kZLqkqo/qszyt+a0bF41Gf0fcccSz
Fc/ieeSHS9GqyevRdLl1hWq5RenUiPuFfqMLu+ETaMZCUlhdNkgHDB4bie+F
IKE/Zca58q42HIxZLqnKWtf0N0jS0C11K7RRIsRXRfDZ5WienVq25nFGTY7b
J2mTDKV169lPP5+/3fxfO/v728e96Kefz171r3462dk/YPOpHRgLU/NbdgJ0
KvEj6hx+uHeE+QoILXnRS0PMUHyjokLpp36ymM3N7nj74Oj4cP/gcG+0M4mP
0r2D/ePD4ejweHyUjCfD48n2+HBv+2DnYO9oOEr2xgfw78l4f3QQHx+l2zGV
Nni00446qrpNfhLx6eIojSvET45tlLHHnP5XiWG7tZHh9nC4M9zdTrcnw/34
cA/+3tne3t/ZGabH8eR4+2hyuHsEu4zT8fH+ZH8vGR2kw710dAhvx+lRag6P
j7b394fD4RH837b3f7u6x6zqWHzGmXR4o4sRJr40EyLpLPJeGL5hHC5Sm1dt
ePDj+bXL4vb7zXYjKkbRGQ+6oeG/ozFTC2qwvb3Dvf39veH+wdEh/PNweLg7
HB3sHx7BSSeHw4Pxwf5OerB7MDlIhts7E3fgGlXFQZ9x8mgVig5jb56YKp2m
jBmzRS2hMeyLBUjCRbCN2gedNNHVbadhjHd35Mur/vbOUf/H07d8K/xlexc2
5wL/2pJaKuoYV8Dcu7UOIZ3zn7J2bRwAOWVdHKs9E5POMUukxCoa9lo2D2U0
3t9O9tNjOIck3jnYPzo+Oh7G48Ph7s7kcBgn2zvpXjoe7R7Go9E2HNVoGzY7
Ph7vHR0fH48Pd90RrbxHbUIA1/9ocnS0vbu7mx4CUdibTMZ7x8dxcnx4fDA5
Ojyc7KXbw/3tND1IdrdHsIpjYI7HB+Od4dFo73DHn9QBQ9okaAbfDWo+N06N
B67UXMdBAri3e7gL2HcImDcByiN4uTM8BGAcbgOxwjf2+HruDPWq8gpQ1bZV
qK6wXIllq+48gl4OQN0x6jS0iWisWM/VW/SQTZpY0zk3Ll1Xuk83rdJ1fz3k
TQj6AwAG0O3j7d394+HB8fFOug1AG+8f7yU78fZwfHC8nxztH433hvFw5yCF
Uc1+epgcHYyOdpNkb2842hkPt4/2d4Z7o73kYHd/Z7/7llNvBFG4H4mnobIZ
7y6vLDnrGS94FGTF4mNEcX0h9Gx9uzKEnF8Dj0ZdLbG4Qu0/FTBA1BJ2GnXw
Wib8VgG8wyMQ3j3/9cqsrnhU3Kcvu1hiAzq2Xj/B0pcrbTfOrH489CgIyHUw
XQ20llzVBJbHXP5vgGl1nyIfUD0l9i53oDau9LtX1Dbot9OZYeCuOQUx0u1n
GUR+GUQnjWNC0ydVqbHRYRzfz8xhhZDYUQTatXfMatJCVAhoCACtBLHrO5vu
pqH/Wigpk4gVkUBWZMn6cqqoLbbUSrQpkcKSLEpFjeNoB0t3upqdW2slsb3h
+Mgdb7MuiHJHrJD0Cfk8FywQfthJo1+I9px9nHFPNpQLpHtphAplyEJ2kqPD
+GAU7x8cp+nRNixoDPLr9mR/Z5TGuwduadTxJ8VYcuYPUqi1gbVa6qTSloaU
yue/A8I79cvyGom7Kx1LqQIUbAhvUyl6bnu2Kv8BPJrWHTzxN/Pm8eHRcXq4
vb89GY/ivYNtYAbx0d5ouLd3sHe8PUwcRGgFHNlKx4GaLe15HleuAV10c87A
v7GtljWd0W4RjshsBpoMN0mlDI84mlfpIikYMnQO7W3D7kA0j9PhwcF4AsJ8
PNobHo52t+N07/jw4HCyuwfb3h9up3uH++OjvfQonoBgfzge78cHwNlGblet
yTSJ1urOsKE5/Nzej0qgMXcKdlW9N8gAF+xp+6A/WtaMVrbZqsKDqt5veuLo
VnO/+yBgH+7EoICkeztHIxC/d46Ba6fxEJSVHT2lX3TJRHR0ec0d9nTBkVsw
Id2G17PWEk1c+w6vnV5qrmxyMJoA2EdHR8lBAgg3HB5OQDL1JE3a3Q3KW5tb
HhCZDeQ2U0TkK7kj2uhaqreLdVJbr9kCH3JdtMaHg/jKu9pc/2P4f3QwOR5u
76Z7w71JCvDe3ksPR+levAdEY2d3b2KO9g8no+TrlV1L+x6CUxMu2cWorQSE
FPfyZyns+wtGU+8cRv8Op7oDim003Huxt/9ieMiFff0aai84OaYGuGr5tEdY
edVi5buPs3Le10ufcsw8Ws8iCZ39yCtAtKIXWJNDGQ02JCsgsJppVtfTVFP8
g8J0gVan+KalZTTDLxD4M9e/TW1bjGCWfHczAMoM9aV+bWTh+lj4YkSA5Bza
eDLW/hFkD0cbM/u+0uT7jUk8rbDYcVAYzG82G+vDMD777OIq2kSLVpZWW1yS
hhP8N8+Kn7Z6plG05PeYSICmouOd3SGaij5//nwW32dJ9EOa/zUGeeALxiTD
07dx+RF9Hsig7+IZPeamZp/PMeIcAAMK5jSGH6JZjIVrqPcVJpeRAykbLdSa
iUcUs9+Js3Uwfe4jjvQ+ns7voh+zKcYy8rxvFmM46HcgBi9SnRSfXxez2RKe
L6bLL5QEgZ40JArkBEA/A2etD8z/C5PGeeX9RQEA
</rfc> </rfc>
 End of changes. 214 change blocks. 
1522 lines changed or deleted 622 lines changed or added

This html diff was produced by rfcdiff 1.48.