Draft: draft-ietf-ohai-ohttp

Commentary: On top of so that I do n't have to deal with merge conflicts . 
 Thanks -- fixed directly on .
The identity of an Oblivious Gateway Resource.  This might include
some information about what Oblivious Target Resources the
Oblivious Gateway Resource supports.
The identity of an Oblivious Gateway Resource.  This might include
some information about what Target Resources the Oblivious Gateway
Resource supports.
This information allows the client to make a request of an Oblivious
Target Resource with that resource having only a limited ability to
correlate that request with the client IP or other requests that the
client might make to that server.
The client constructs an HTTP request for an Oblivious Target
Resource.
This information allows the client to make a request of an Target
Resource with that resource having only a limited ability to
correlate that request with the client IP or other requests that the
client might make to that server.
The client constructs an HTTP request for a Target Resource.
The Oblivious Target Resource answers this HTTP request with an
HTTP response.
The Target Resource answers this HTTP request with an HTTP
response.
The client role in this protocol acts as an HTTP client both with
respect to the Oblivious Relay Resource and the Oblivious Target
Resource.  For the request the clients makes to the Oblivious Target
Resource, this diverges from typical HTTP assumptions about the use
of a connection (see HTTP) in that the request and response are
encrypted rather than sent over a connection.  The Oblivious Relay
Resource and the Oblivious Gateway Resource also act as HTTP clients
toward the Oblivious Gateway Resource and Oblivious Target Resource
respectively.
The client role in this protocol acts as an HTTP client both with
respect to the Oblivious Relay Resource and the Target Resource.  For
the request the clients makes to the Target Resource, this diverges
from typical HTTP assumptions about the use of a connection (see
HTTP) in that the request and response are encrypted rather than sent
over a connection.  The Oblivious Relay Resource and the Oblivious
Gateway Resource also act as HTTP clients toward the Oblivious
Gateway Resource and Target Resource respectively.
An Oblivious Gateway Resource, if it receives any response from the
Oblivious Target Resource, sends a single 200 response containing the
encapsulated response.  Like the request from the client, this
response MUST only contain those fields necessary to carry the
encapsulated response: a 200 status code, a header field indicating
the content type, and the encapsulated response as the response
content.  As with requests, additional fields MAY be used to convey
information that does not reveal information about the encapsulated
response.
An Oblivious Gateway Resource, if it receives any response from the
Target Resource, sends a single 200 response containing the
encapsulated response.  Like the request from the client, this
response MUST only contain those fields necessary to carry the
encapsulated response: a 200 status code, a header field indicating
the content type, and the encapsulated response as the response
content.  As with requests, additional fields MAY be used to convey
information that does not reveal information about the encapsulated
response.
An Oblivious Gateway Resource acts as a gateway for requests to the
Oblivious Target Resource (see HTTP).  The one exception is that any
information it might forward in a response MUST be encapsulated,
unless it is responding to errors it detects before removing
encapsulation of the request; see errors.
An Oblivious Gateway Resource acts as a gateway for requests to the
Target Resource (see HTTP).  The one exception is that any
information it might forward in a response MUST be encapsulated,
unless it is responding to errors it detects before removing
encapsulation of the request; see errors.
Errors detected by the Oblivious Gateway Resource after successfully
removing encapsulation and errors detected by the Oblivious Target
Resource MUST be sent in an Encapsulated Response.
Errors detected by the Oblivious Gateway Resource after successfully
removing encapsulation and errors detected by the Target Resource
MUST be sent in an Encapsulated Response.
To achieve the stated privacy goals, the Oblivious Relay Resource
cannot be operated by the same entity as the Oblivious Gateway
Resource.  However, colocation of the Oblivious Gateway Resource and
Oblivious Target Resource simplifies the interactions between those
resources without affecting client privacy.
To achieve the stated privacy goals, the Oblivious Relay Resource
cannot be operated by the same entity as the Oblivious Gateway
Resource.  However, colocation of the Oblivious Gateway Resource and
Target Resource simplifies the interactions between those resources
without affecting client privacy.
A server that operates both Oblivious Gateway and Oblivious Target
Resources is responsible for removing request encryption, generating
a response to the Encapsulated Request, and encrypting the response.
If separate entities provide the Oblivious Gateway Resource and
Oblivious Target Resource, these entities might need an arrangement
similar to that between server and relay for managing denial of
service; see dos.  It is also necessary to provide confidentiality
protection for the unprotected requests and responses, plus
protections for traffic analysis; see ta.
A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to
the Encapsulated Request, and encrypting the response.
If separate entities provide the Oblivious Gateway Resource and
Target Resource, these entities might need an arrangement similar to
that between server and relay for managing denial of service; see
dos.  It is also necessary to provide confidentiality protection for
the unprotected requests and responses, plus protections for traffic
analysis; see ta.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
Gateway resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Oblivious Target Resource is
willing to use trial decryption, a limited set of key configurations
that share an identifier.  An Oblivious Relay Resource can link
requests using the public key corresponding to KeyConfig.key_id.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
Gateway resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Target Resource is willing
to use trial decryption, a limited set of key configurations that
share an identifier.  An Oblivious Relay Resource can link requests
using the public key corresponding to KeyConfig.key_id.