<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.2.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ohai-svcb-config-07" number="9540" submissionType="IETF" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <front>
    <title abbrev="Oblivious Services in SVCB">Discovery of Oblivious Services via Service Binding Records</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ohai-svcb-config-07"/> name="RFC" value="9540"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="T." surname="Reddy" surname="Reddy.K" fullname="Tirumaleswar Reddy"> Reddy.K">
      <organization>Nokia</organization>
      <address>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <date year="2023" month="October" day="06"/>
    <area>Security</area>
    <workgroup>Oblivious HTTP Application Intermediation</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" month="February"/>
    <area>sec</area>
    <workgroup>ohai</workgroup>

<keyword>DNS</keyword>
<keyword>Oblivious HTTP</keyword>
<keyword>SVCB</keyword>

    <abstract>
      <?line 35?>
<t>This document defines a parameter that can be included in SVCB Service Binding (SVCB) and HTTPS
DNS resource records to denote that a service is accessible using Oblivious
HTTP, by offering an Oblivious Gateway Resource through which to access the
target. This document also defines a mechanism to learn for learning the key configuration
of the discovered Oblivious Gateway Resource.</t>

    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-ohai-svcb-config/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Oblivious HTTP Application Intermediation Working Group mailing list (<eref target="mailto:ohai@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ohai/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ohai/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-ohai/draft-ohai-svcb-config"/>.</t>
    </note>
  </front>
  <middle>
    <?line 43?>
<section anchor="introduction">
      <name>Introduction</name>
      <t>Oblivious HTTP <xref target="OHTTP"/> target="RFC9458"/> allows clients to encrypt
messages exchanged with an Oblivious Target Resource (target). The messages
are encapsulated in encrypted messages to an Oblivious Gateway Resource
(gateway), which offers Oblivious HTTP access to the target. The gateway is
accessed via an Oblivious Relay Resource (relay), which proxies the encapsulated
messages to hide the identity of the client. Overall, this architecture is
designed in such a way that the relay cannot inspect the contents of messages,
and the gateway and target cannot learn the client's identity from a single
transaction.</t>
      <t>Since Oblivious HTTP deployments typically involve very specific coordination
between clients, relays, and gateways, the key configuration is often shared
in a bespoke fashion. However, some deployments involve clients
discovering targets and their associated gateways more dynamically.
For example, a network might operate a DNS resolver that provides more optimized
or more relevant DNS answers and is accessible using Oblivious HTTP, and might
want to advertise support for Oblivious HTTP via mechanisms like Discovery of
Designated Resolvers (<xref target="DDR"/>) <xref target="RFC9462"/> and
Discovery of Network-designated Resolvers (<xref target="DNR"/>). <xref target="RFC9463"/>.
Clients can access these gateways through trusted relays.</t>
      <t>This document defines a way to use DNS resource records (RRs) to advertise that an HTTP
service supports Oblivious HTTP. This advertisement is a parameter that can be included in
SVCB
Service Binding (SVCB) and HTTPS DNS RRs <xref target="SVCB"/> target="RFC9460"/> (<xref target="svc-param"/>).
The presence of this parameter indicates that a service can act as a target and
has a gateway that can provide access to the target.</t>
      <t>The client learns the URI to use for the gateway using a well-known
URI suffix <xref target="WELLKNOWN"/>, target="RFC8615"/>, "ohttp-gateway", which is accessed on
the target (<xref target="gateway-location"/>). This means that for deployments that
support this kind of discovery, the gateway Gateway and target resources Target Resources need to
be located on the same host.</t>
      <t>This document also defines a way to fetch a gateway's key
configuration from the gateway (<xref target="config-fetch"/>).</t>
      <t>This mechanism does not aid in the discovery of relays;
relay configuration is out of scope for this document. Models in which
this discovery mechanism is applicable are described in <xref target="applicability"/>.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      <?line -18?>
</section>
    <section anchor="applicability">
      <name>Applicability</name>
      <t>There are multiple models in which the discovery mechanism defined
in this document can be used.</t> used. These include:</t>

      <ul spacing="normal">
        <li>
          <t>Upgrading regular (non-proxied) HTTP to Oblivious HTTP. In this model,
the client intends to communicate with a specific target service, service and
prefers to use Oblivious HTTP if it is available. The target service
has a gateway that it offers to allow access using Oblivious
HTTP. Once the client learns about the gateway, it "upgrades"
its requests from non-proxied HTTP to Oblivious HTTP to access
the target service.</t>
        </li>
        <li>
          <t>Discovering alternative Oblivious HTTP services. In this model,
the client has a default target service that it uses. For
example, this may be a public DNS resolver that is accessible over
Oblivious HTTP. The client is willing to use alternative
target services if they are discovered, which may provide more
optimized or more relevant responses.</t>
        </li>
      </ul>
      <t>In both of these deployment models, the client is configured with
a relay that it trusts for Oblivious HTTP transactions. This
relay either needs to provide generic either (1)&nbsp;generic access to gateways, gateways or
provide a
(2)&nbsp;a service to clients to allow them to check which gateways
are accessible.</t>
    </section>
    <section anchor="svc-param">
      <name>The ohttp &quot;ohttp&quot; SvcParamKey</name>
      <t>The "ohttp" SvcParamKey is used to indicate that a
service described in an a SVCB RR can be accessed as a target
using an associated gateway. The service that is queried by the client hosts
one or more target resources.</t> Target Resources.</t>
      <t>In order to access the service's target resources Target Resources using Oblivious HTTP, the client
needs to send encapsulated messages to the gateway resource Gateway Resource and the gateway's
key configuration (both of which can be retrieved using the method described in
<xref target="config-fetch"/>).</t>
      <t>Both the presentation and wire format wire-format values for the "ohttp" parameter
<bcp14>MUST</bcp14> be empty.</t>
      <t>Services can include the "ohttp" parameter in the mandatory parameter
list if the service is only accessible using Oblivious HTTP. Marking
the "ohttp" parameter as mandatory will cause clients that do not
understand the parameter to ignore that SVCB RR.
Including the "ohttp" parameter without marking it mandatory advertises
a service that is optionally available using Oblivious HTTP. Note also
that multiple SVCB RRs can be provided to indicate separate
configurations.</t>
      <t>The media type to use for encapsulated requests made to a target service
depends on the scheme of the SVCB RR. This document defines the
interpretation for the "https" scheme <xref target="SVCB"/> target="RFC9460"/> and the "dns" scheme <xref target="DNS-SVCB"/>
schemes. target="RFC9461"/>. Other schemes that want to use this parameter <bcp14>MUST</bcp14> define the
interpretation and meaning of the configuration.</t>
      <section anchor="use-in-https-service-rrs">
        <name>Use in HTTPS service Service RRs</name>
        <t>For the "https" scheme, which uses the HTTPS RR type instead of SVCB,
the presence of the "ohttp" parameter means that the target
being described is an Oblivious HTTP service that is accessible using
the default "message/bhttp" media type <xref target="OHTTP"/> target="RFC9458"/>
          <xref target="BINARY-HTTP"/>.</t> target="RFC9292"/>.</t>
        <t>For example, an HTTPS service RR for svc.example.com that supports
Oblivious HTTP could look like this:</t>

        <artwork><![CDATA[
svc.example.com. 7200  IN HTTPS 1 . ( alpn=h2 ohttp )
]]></artwork>
        <t>A similar RR for a service that only supports Oblivious HTTP
could look like this:</t>
        <artwork><![CDATA[
svc.example.com. 7200  IN HTTPS 1 . ( mandatory=ohttp ohttp )
]]></artwork>
      </section>
      <section anchor="use-in-dns-server-svcb-rrs">
        <name>Use in DNS server Server SVCB RRs</name>
        <t>For the "dns" scheme, as defined in <xref target="DNS-SVCB"/>, target="RFC9461"/>, the presence of
the "ohttp" parameter means that the DNS server being
described has a DNS over HTTP DNS-over-HTTPS (DoH) <xref target="DOH"/> service <xref target="RFC8484"/> that can
be accessed using Oblivious HTTP. Requests to the resolver are sent to
the gateway using binary HTTP with the default "message/bhttp"
media type <xref target="BINARY-HTTP"/>, target="RFC9292"/>, containing inner requests that use the
"application/dns-message" media type <xref target="DOH"/>.</t> target="RFC8484"/>.</t>
        <t>If the "ohttp" parameter is included in an a DNS server SVCB RR,
the "alpn" parameter <bcp14>MUST</bcp14> include at least one HTTP value (such as "h2" or
"h3").</t>
        <t>In order for DoH-capable recursive resolvers to function as Oblivious HTTP targets, their
associated gateways need to be accessible via a client-trusted relay.
DoH recursive resolvers used with the discovery mechanisms described
in this section can either be either publicly accessible, accessible or specific to a
network. In general, only publicly accessible DoH recursive resolvers will work
as Oblivious HTTP targets, unless there is a coordinated deployment
with a relay to access the network-specific DoH recursive resolvers.</t>
        <section anchor="ddr">
          <name>Use with DDR</name>
          <t>Clients can discover that a DoH recursive resolvers support resolver supports Oblivious HTTP using
DDR, either by either querying _dns.resolver.arpa to a locally configured
resolver or by querying using the name of a resolver <xref target="DDR"/>.</t> target="RFC9462"/>.</t>
          <t>For example, a DoH service advertised over DDR can be annotated
as supporting resolution via Oblivious HTTP using the following RR:</t>
          <artwork><![CDATA[
_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net (
     alpn=h2 dohpath=/dns-query{?dns} ohttp )
]]></artwork>
          <t>Clients still need to perform verification of oblivious DoH servers,
specifically servers --
specifically, the TLS certificate checks described in <xref section="4.2" sectionFormat="of" target="DDR"/>. target="RFC9462"/>.
Since the gateway Gateway and target resources Target Resources for discovered oblivious services
need to be on the same host, this means that the client needs to verify
that the certificate presented by the gateway passes the required checks.
These checks can be performed when looking up the configuration on the gateway
as described in <xref target="config-fetch"/>, which target="config-fetch"/> and can either be done either directly
or via the relay or another proxy to avoid exposing client IP addresses.</t>
          <t>Opportunistic discovery Discovery <xref target="DDR"/>, target="RFC9462"/>, where only the IP address is validated,
<bcp14>SHOULD NOT</bcp14> be used in general with Oblivious HTTP, since this mode
primarily exists to support resolvers that use private or local IP
addresses, which will usually not be accessible when using a
relay. If a configuration occurs where the resolver is accessible, accessible but
cannot use certificate-based validation, the client <bcp14>MUST</bcp14> ensure
that the relay only accesses the gateway and target using
the unencrypted resolver's original IP address.</t>
          <t>For the case of DoH recursive resolvers, clients also need to ensure that they are not
being targeted with unique DoH paths that would reveal their identity. See
<xref target="security"/> for more discussion.</t>
        </section>
        <section anchor="dnr">
          <name>Use with DNR</name>
          <t>The SvcParamKeys SvcParamKey defined in this document also can be used with Discovery
of Network-designated Resolvers (DNR) <xref target="DNR"/>. target="RFC9463"/>. In this
case, the oblivious configuration and path parameters can be included
in DHCP and Router Advertisement messages.</t>
          <t>While DNR does not require the same kind of verification as DDR, clients
that learn about DoH recursive resolvers still need to ensure that they are not being
targeted with unique DoH paths that would reveal their identity. See <xref target="security"/>
for more discussion.</t>
        </section>
      </section>
    </section>
    <section anchor="gateway-location">
      <name>Gateway Location</name>
      <t>Once a client has discovered that a service supports Oblivious HTTP
via the "ohttp" parameter in a SVCB or HTTPS RR, it needs to be
able to send requests via a relay to the correct gateway location.</t>
      <t>This document defines a well-known resource (<xref target="WELLKNOWN"/>), <xref target="RFC8615"/>,
"/.well-known/ohttp-gateway", which is an Oblivious Gateway Resource
available on the same host as the target resource.</t> Target Resource.</t>
      <t>Some servers might not want to operate the gateway on a well-known URI.
In such cases, these servers can use 3xx redirection (Redirection) responses
(<xref section="15.4" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) to direct clients and relays to the correct
location of the gateway. Such redirects would apply both to requests both (1)&nbsp;requests
made to fetch key configurations (as defined in <xref target="config-fetch"/>) and to
encapsulated
(2)&nbsp;encapsulated requests made via a relay.</t>
      <t>If a client receives a redirect when fetching the key configuration from the
well-known gateway resource, Gateway Resource, it <bcp14>MUST NOT</bcp14> communicate the redirected
gateway URI to the relay as the location of the gateway to use.
Doing so would allow the gateway to target clients by encoding
unique or client-identifying values in the redirected URI. Instead,
relays being used with dynamically discovered gateways <bcp14>MUST</bcp14> use the
well-known gateway resource Gateway Resource and follow any redirects independently of
redirects that clients received. The relay can remember such redirects
across oblivious requests for all clients in order to avoid added latency.</t>
    </section>
    <section anchor="config-fetch">
      <name>Key Configuration Fetching</name>
      <t>Clients also need to know the key configuration of a gateway before encapsulating
and sending requests to the relay.</t>
      <t>If a client fetches the key configuration directly from the gateway, it
will expose identifiers like a client IP address to the gateway. The
privacy and security implications of fetching the key configuration are
discussed more in <xref target="security"/>. Clients can use an HTTP proxy to
hide their IP addresses when fetching key configurations. Clients can
also perform consistency checks to validate that they are not receiving
unique key configurations, as discussed in <xref target="consistency"/>.</t>
      <t>In order to fetch the key configuration of a gateway discovered
in the manner described in <xref target="gateway-location"/>, the client issues a GET request
(either through a proxy or directly) to the URI of the gateway specifying
the "application/ohttp-keys" (<xref target="OHTTP"/>) media type <xref target="RFC9458"/> in the Accept header.</t>
      <t>For example, if the client knows an oblivious gateway Oblivious Gateway URI,
"https://svc.example.com/.well-known/ohttp-gateway",
https://svc.example.com/.well-known/ohttp-gateway, it could fetch the
key configuration with the following request:</t>
      <artwork><![CDATA[
GET /.well-known/ohttp-gateway HTTP/1.1
Host: svc.example.com
Accept: application/ohttp-keys
]]></artwork>
      <t>Gateways that coordinate with targets that advertise Oblivious HTTP
support <bcp14>SHOULD</bcp14> support GET requests for their key configuration in this
manner, unless there is another out-of-band configuration model that is
usable by clients. Gateways respond with their key configuration in the
response body, with a content type of "application/ohttp-keys".</t>
    </section>
    <section anchor="security">
      <name>Security and Privacy Considerations</name>
      <t>Attackers on a network can remove SVCB information from cleartext DNS
answers that are not protected by DNSSEC <xref target="DNSSEC"/>. target="RFC4033"/>. This
can effectively downgrade clients. However, since SVCB indications
for Oblivious HTTP support are just hints, a client can mitigate this by
always checking for a gateway configuration (<xref target="config-fetch"/>)
on the well-known gateway location (<xref target="gateway-location"/>).
Use of
Using encrypted DNS along with DNSSEC can also be used as provide such a mitigation.</t>
      <t>When clients fetch a gateway's configuration (<xref target="config-fetch"/>),
they can expose their identity in the form of an IP address if they do not
connect via a proxy or some other IP-hiding mechanism. In some circumstances,
this might not be a privacy concern, since revealing that a particular
client IP address is preparing to use an Oblivious HTTP service can be
expected. However, if a client is otherwise trying to hide its IP
address or location (and not merely decouple its specific requests from its
IP address), or if revealing its IP address facilitates key targeting attacks
(if a gateway service uses IP addresses to associate specific configurations
with specific clients), a proxy or similar mechanism can be used to fetch
the gateway's configuration.</t>
      <t>When discovering designated oblivious DoH recursive resolvers using this mechanism,
clients need to ensure that the designation is trusted in lieu of
being able to directly check the contents of the gateway server's TLS
certificate. See <xref target="ddr"/> for more discussion, as well as the Security
Considerations Section&nbsp;<xref target="RFC9461" section="8"
sectionFormat="bare">"Security Considerations"</xref> of <xref target="DNS-SVCB"/>.</t> target="RFC9461"/>.</t>
      <section anchor="consistency">
        <name>Key Targeting Attacks</name>
        <t>As discussed in <xref target="OHTTP"/>, target="RFC9458"/>, client requests using Oblivious HTTP
can only be linked by recognizing the key configuration. In order to
prevent unwanted linkability and tracking, clients using any key
configuration discovery mechanism need to be concerned with attacks
that target a specific user or population with a unique key configuration.</t>
        <t>There are several approaches clients can use to mitigate key targeting
attacks. <xref target="CONSISTENCY"/> target="I-D.ietf-privacypass-key-consistency"/> provides an overview
of the options for ensuring that the key configurations are consistent between
different clients. Clients <bcp14>SHOULD</bcp14> employ some technique to mitigate key
targeting attacks, such as the option of confirming the key with a shared
proxy as described in <xref target="CONSISTENCY"/>. target="I-D.ietf-privacypass-key-consistency"/>. If a client detects that a gateway
is using per-client targeted key configuration, the client can stop using
the gateway, and potentially gateway and, potentially, report the targeting attack to let so that other
clients can avoid using this gateway in the future.</t>
      </section>
      <section anchor="dohpath-targeting-attacks">
        <name>dohpath Targeting Attacks</name>
        <t>For oblivious DoH servers, an attacker could use unique <tt>dohpath</tt> <tt>"dohpath"</tt> values
to target or identify specific clients. This attack is very similar to
the generic OHTTP key targeting attack described above.</t>
        <t>A client can avoid these targeting attacks by only allowing a single
<tt>dohpath</tt>
<tt>"dohpath"</tt> value, such as the commonly used "/dns-query{?dns}" or
another pre-known value. If the client allows arbitrary <tt>dohpath</tt> <tt>"dohpath"</tt>
values, it <bcp14>SHOULD</bcp14> mitigate targeting attacks with a consistency check,
such as using a mechanism one of the mechanisms described in <xref target="CONSISTENCY"/> target="I-D.ietf-privacypass-key-consistency"/> to validate the
<tt>dohpath</tt>
<tt>"dohpath"</tt> value with another source. Clients might choose to only
employ a consistency check on a percentage of discovery events,
depending on the capacity of consistency check options and their
deployment threat model.</t>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <section anchor="svcb-service-parameter">
        <name>SVCB Service Parameter</name>
        <t>This document adds the following entry to the SVCB Service Parameters "Service Parameter Keys (SvcParamKeys)" registry (<xref target="SVCB"/>). The definition of this <xref target="RFC9460"/>. This parameter is defined in <xref target="svc-param"/>.</t>

        <table>
          <thead>
            <tr>
              <th align="left">Number</th>
              <th align="left">Name</th>
              <th align="left">Meaning</th>
	      <th align="left"> Change Controller</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">8 (Early Allocation)</td> align="left">8</td>
              <td align="left">ohttp</td>
              <td align="left">Denotes that a service operates an Oblivious HTTP target</td>
	      <td align="left">(This document)</td> align="left">IETF</td>
              <td align="left">RFC 9540, <xref target="svc-param"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="well-known-uri">
        <name>Well-Known URI</name>
        <t>IANA is requested to add has added one new entry in the "Well-Known URIs" registry <xref target="WELLKNOWN"/>.</t>
        <t>URI suffix: ohttp-gateway</t>
        <t>Change controller: IETF</t>
        <t>Specification document: This document</t>
        <t>Status: permanent</t>
        <t>Related information: N/A</t> target="RFC8615"/>.</t>
    <dl newline="false">
        <dt>URI Suffix:</dt><dd>ohttp-gateway</dd>
        <dt>Change Controller:</dt><dd>IETF</dd>
        <dt>Reference:</dt><dd>RFC 9540</dd>
        <dt>Status:</dt><dd>permanent</dd>
        <dt>Related Information:</dt><dd>N/A</dd>
    </dl>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="RFC9458" to="OHTTP"/>
<displayreference target="RFC9462" to="DDR"/>
<displayreference target="RFC9463" to="DNR"/>
<displayreference target="RFC9460" to="SVCB"/>
<displayreference target="RFC8615" to="WELLKNOWN"/>
<displayreference target="RFC9461" to="DNS-SVCB"/>
<displayreference target="RFC9292" to="BINARY-HTTP"/>
<displayreference target="RFC8484" to="DOH"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC4033" to="DNSSEC"/>
<displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTENCY"/>

    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="OHTTP">
          <front>
            <title>Oblivious HTTP</title>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="25" month="August" year="2023"/>
            <abstract>
              <t>   This document describes Oblivious HTTP, a protocol for forwarding
   encrypted HTTP messages.  Oblivious HTTP allows a client to make
   multiple requests to an origin server without that server being able
   to link those requests to the client or to identify the requests as
   having come from the same client, while placing only limited trust in
   the nodes used to forward the messages.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-10"/>
        </reference>
        <reference anchor="DDR">
          <front>
            <title>Discovery of Designated Resolvers</title>
            <author fullname="Tommy Pauly" initials="T." surname="Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Eric Kinnear" initials="E." surname="Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Patrick McManus" initials="P." surname="McManus">
              <organization>Fastly</organization>
            </author>
            <author fullname="Tommy Jensen" initials="T." surname="Jensen">
              <organization>Microsoft</organization>
            </author>
            <date day="5" month="August" year="2022"/>
            <abstract>
              <t>   This document defines Discovery of Designated Resolvers (DDR), a
   mechanism for DNS clients to use DNS records to discover a resolver's
   encrypted DNS configuration.  An encrypted DNS resolver discovered in
   this manner is referred to as a "Designated Resolver".  This
   mechanism can be used to move from unencrypted DNS to encrypted DNS
   when only the IP address of a resolver is known.  This mechanism is
   designed to be limited to cases where unencrypted DNS resolvers and
   their designated resolvers are operated by the same entity or
   cooperating entities.  It can also be used to discover support for
   encrypted DNS protocols when the name of an encrypted DNS resolver is
   known.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-ddr-10"/>
        </reference>
        <reference anchor="DNR">
          <front>
            <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
              <organization>Nokia</organization>
            </author>
            <author fullname="Dan Wing" initials="D." surname="Wing">
              <organization>Citrix Systems, Inc.</organization>
            </author>
            <author fullname="Neil Cook" initials="N." surname="Cook">
              <organization>Open-Xchange</organization>
            </author>
            <author fullname="Tommy Jensen" initials="T." surname="Jensen">
              <organization>Microsoft</organization>
            </author>
            <date day="27" month="April" year="2023"/>
            <abstract>
              <t>   The document specifies new DHCP and IPv6 Router Advertisement options
   to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-
   TLS, DNS-over-QUIC).  Particularly, it allows a host to learn an
   authentication domain name together with a list of IP addresses and a
   set of service parameters to reach such encrypted DNS resolvers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-dnr-16"/>
        </reference>
        <reference anchor="SVCB">
          <front>
            <title>Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)</title>
            <author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz">
              <organization>Google</organization>
            </author>
            <author fullname="Mike Bishop" initials="M." surname="Bishop">
              <organization>Akamai Technologies</organization>
            </author>
            <author fullname="Erik Nygren" initials="E." surname="Nygren">
              <organization>Akamai Technologies</organization>
            </author>
            <date day="11" month="March" year="2023"/>
            <abstract>
              <t>   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTP origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration), and are extensible to support future uses
   (such as keys for encrypting the TLS ClientHello).  They also enable
   aliasing of apex domains, which is not possible with CNAME.  The
   HTTPS RR is a variation of SVCB for use with HTTP [HTTP].  By
   providing more information to the client before it attempts to
   establish a connection, these records offer potential benefits to
   both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc
   (https://github.com/MikeBishop/dns-alt-svc).  The most recent working
   version of the document, open issues, etc. should all be available
   there.  The authors (gratefully) accept pull requests.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-12"/>
        </reference>
        <reference anchor="WELLKNOWN">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="May" year="2019"/>
            <abstract>
              <t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="DNS-SVCB">
          <front>
            <title>Service Binding Mapping for DNS Servers</title>
            <author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz">
              <organization>Meta Platforms, Inc.</organization>
            </author>
            <date day="26" month="June" year="2023"/>
            <abstract>
              <t>   The SVCB DNS resource record type expresses a bound collection of
   endpoint metadata, for use when establishing a connection to a named
   service.  DNS itself can be such a service, when the server is
   identified by a domain name.  This document provides the SVCB mapping
   for named DNS servers, allowing them to indicate support for
   encrypted transport protocols.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-svcb-dns-09"/>
        </reference>
        <reference anchor="BINARY-HTTP">
          <front>
            <title>Binary Representation of HTTP Messages</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document defines a binary format for representing HTTP messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9292"/>
          <seriesInfo name="DOI" value="10.17487/RFC9292"/>
        </reference>
        <reference anchor="DOH">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>

<!-- draft-ietf-ohai-ohttp (RFC 9458: published) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9458.xml"/>

<!-- draft-ietf-add-ddr (RFC 9462; published) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml"/>

<!-- draft-ietf-add-dnr (RFC 9463; published) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"/>

<!-- draft-ietf-dnsop-svcb-https (RFC 9460; published) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- draft-ietf-add-svcb-dns (RFC 9461; published) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9461.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9292.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="DNSSEC">
          <front>
            <title>DNS Security Introduction and Requirements</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4033"/>
          <seriesInfo name="DOI" value="10.17487/RFC4033"/>
        </reference>
        <reference anchor="CONSISTENCY">
          <front>
            <title>Key Consistency and Discovery</title>
            <author fullname="Alex Davidson" initials="A." surname="Davidson">
              <organization>Brave Software</organization>
            </author>
            <author fullname="Matthew Finkel" initials="M." surname="Finkel">
              <organization>The Tor Project</organization>
            </author>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="10" month="July" year="2023"/>
            <abstract>
              <t>   This document describes the consistency requirements of protocols
   such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
   privacy.  It presents definitions for consistency and then surveys
   mechanisms for providing consistency in varying threat models.  In
   concludes with discussion of open problems in this area.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-consistency-01"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>

<!-- draft-ietf-privacypass-key-consistency (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-privacypass-key-consistency.xml"/>

      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61c3XLjxnK+n6cY0xeWUiRlrffEtnJ8fGRp7VV5V9pI2my5
UqkcEBiSkyUBBgNQS8vys+RZ8mTpv/kBCMqnkuzNkiAw09PT/fXXPQ1NJhPV
2GZlzvTo0rq82pp6p6u5vpmt7NZWrdN3pt7a3Di9tZn/on+wZWHLhb41eVUX
bqSy2aw2Wxhl4EFb6rt/ufhhpPKsMYuq3p1p1xTKNbXJ1mf66tX9j0oVVV5m
a5CjqLN5M7GmmU+qZWYnbpvPJnlVzu1i8uXXKoOHYJo7k7e1bXYj9VDVHxd1
1W46k7++v3+nzzeblYVJbVXqq7Ix9doUlr6O1EezgyeLM/6hNM3kEidWW1O2
5kxp/b8YU+tmt0FVfgCZUD0/4Rh4fZ3ZFVzHBf0Vlzat6gVez+p8CdeXTbNx
ZycneBteslsz9bed4IWTWV09OHOCA5zggwvbLNvZmSY9PSxIVSesur7WlIJ9
+UqprG2WVQ1Lm8DzWrO276v1eqffZe1qR1dhwqy0v9KCzmixBpaZT+lHw8to
Nnj7XzP8cZpX696Itm7X2cq4h6wG+yiKoYGvq482S8f8WJVFY+u/LvArDarK
ql7D7VvYDWXLefJNTSYTnc3AgLK8Uep+aZ0G+2nXpmx0Yea2BKvL9CarQSLY
It0ss0bnWalnBqwxX7WFKbxZ6qwsaGvv1OX1na6Nq9oaTLxm09ZNBUOWVWN4
lEw78QGYNMvBvp2dgZJahxsejEXhiGM9Q2eamxp/g+mjLf0ErvCQ7UBBMl2z
BFtZLPXD0uZLnJTHhutGNVm9MM1UdxearVyVrHZt8iVo2K3x4ZXJ6hKf1WDn
mu2grUn5CrwbfyjE3UETh8Wasq7XtihWRqnP0eTrqmhzGkn1fOPx8bMb/PDd
1eRy2vfjCo386QnEXoEp63xlYRGkXlPm9W7TqDWsN1vAYswnXMoCJHsAM+8q
7p50EfV2xMo5Ru0Y7YdAmMBxs41rV7Am2m2ZB76EmVDPz22LOlrwleOx7Axt
p9O9lfvNqki1cb+MlufBWhTfBNMjknamvTWr1BaOavweptzU1SdryBQ6a1Lp
Mpa2MHQH/F8CpBOK43dW9FTfwF6D7sdwES0XUaYxedPWaMmqMM4uStaTa2HS
TKPUZPI4CkmELgSeAPe4DTzKw1cAgriRMJ2XZ6zQp5pk9fSdd07GiBbKAn7h
ouTzulqjo4HXgNWBl5cuI4sDc7wD/zV99Rdms6p2azao3QbwebUClZfbarU1
mmIaSmznNgeBwa1tyb4wM82DMaW3xjGvE/5HgUV4Nx52JASAag6L124J5lYA
SIHQM+M21Uej55lbosT6dfVgQIKxdtXadCT18snkynskggUry2lRpK115lyV
W7JlL5heV7B7xQ6Al5c8VT9WNbhPtgZohkVoiGsYH8GBF8tGVxswAQCyTHuk
g+kFHcHItrABMma1aeza/gqLgvHoCijGbDOAHXwUNuQBvQClexYGNcMg3kci
qAccAr2ugJkb6wxY22ZT1Y0GgO9vK/pJgDWnVxb0mrIUdUlWSzq5ldU4fQQw
dHl52wehrCgmRVE/PR2jOKrDdq5ZTZPi4HjXw+OVON5UXQiYYYiJuO1M3CkP
703dOhye7Wx6OHiR91WgT6MHw9LR7a077mqS41NJulM+Sol6+4glwSQ8TLPb
vytqqm7UJPFAGER//KWvp6J01Yb5CNEcCAGgUfg+oZlIfwiUG1iiQd8m3AJR
oiBINpE7un4IZn3DFRRc8AU3d0kXPPiEdYiND6O1IinYFxmdGHHf3175jUAT
TVGNjR32yqxWk49l9VAqvNu187n9hPr48OrNm5+vbz5cf3f748U3/3j6p6en
MbJA0MNEBhl5lA9+BEoGZIqSobrk5smqYuqJWuMdXJusFL2geB0khIvKuxep
FEhpgfr1SLMbH0Jpb28OIAQEaiqASk2zk3j0mIPt0cvKNXtm3KMmYstz01Bg
kekA8QFTVRdTCfpTmWDxQv7pcTIXJSv3hKeoUE4IKpmlAJbSG/Jv9rZ/UhLF
9lC8bfAueGDjNzlZzVS/rQqzojyGtkrxz2GCKAjuIecHiIXIQQBR8trOOLA+
Pvpf7Qri3NPTFCnVRVVuMfBVJQPqJerN0ne2SYw8D+T0o7fv7+7BYuh/fX1D
n29f/fP7q9tXl/j57vX5mzfhg5I77l7fvH9zGT/FJy9u3r59dX3JD8NV3bmk
Rm/PfxkxfI9u3t1f3VyfvxmxhjvbDQuF/SWYAH8FT0YryYhVxNX/cPHuv//r
9CX6BXjDi9PTbwEK+Ms3p1+/hC8PS1PybFUJ8Zu/wmbuFOgNPBJHgTAHvryx
DdjYGB3fLcHv9BKILGjzH/4VNfNvZ/rPs3xz+vIvcgEX3Lnodda5SDrbv7L3
MCtx4NLANEGbnes9TXflPf+l893rPbn45+9X4Fl6cvrN939RaELnqVnpx8+7
ZkZWVLM9rttVYzGpW3dtuucziW+RFxO56W66BAbAxQKzBP1+s6gzKgrUZgEE
tdZHZVVOmLwWxxzRwUr6cehKBiaBxioyQjKmkjMwSAjXbUlBQHKCSOgEsSQm
kP0oMEGi6QLcPV5h59pytNtiwg2+yly9O9JQFLGNTwAw8mIm44PJUP4HpLvM
TUJyfVzJZgg5CcyNceRRSyo0bqQswHdt/rM1Dj4QJia6PKDKmDSmwUMWQ1t0
mRDMbIVlD8qo++PII+65vWHdgHFkYFC9uYKqQPUwCFBSFSgpDwfqnCEN3bQw
cz7ARrukEmVW+/wlGooDo1itiDfzhierU13hHO4+YgrDc0iCfRhG2TxPQOKr
AhXWe1S4Rq5f4iKVAlXNKjDMGIDFxcbp/oOkPvpIdqsyya280oghuiE6nCRC
jqO/BDQD44DmMFKTYXr5F6aEzc4TvhNTGtiUQIfixlVpXs72DUNTSSFfmvyj
KMkPQ2l23CgKZ7gvxHD03TZ/hxzuZ4OYFBkfRzWmQaPOXdYRnuB0nvMJ5Qt8
thNSMinh3N56OAoUKqGESnhaOZBDsR11DddpcLwaHW22SzcPqY5TFSCvt4Q+
WWI7gFCNdpyWcPwMwHn2CNZwyhTnVWFfgR8X3apGWgFIWVNIF3qJ+BdO7eex
R2S4QIB4c0WTEMRBB1uYhAVsqLzSLKuiswdqiJ/9gAM2gdQ3PA/K8mBrolhr
UPQ2WwHABVbtDSLwfkWhG0Qx602zw9zfuzCKKBnJ8KOeBa5hzqypIKLFUVfW
NQICaS2PKMcfZLJABTOq7KrhWTOXzIiQBJIiHAWnQvsqKuSqqi3BSlzjNyhJ
u8D4FyWZF94uBj4Fy8IF+63YnxzRBMPKmkVELInChEQPfHbP3BHiqpJqJiEi
Hlj/NRZCkd4rejjQCZHSeesRbOm6sjMobWO6nN9J6kWFdKqgp/lWx9xDSFxn
Bd2V9WM2wC9xBp+iAGqtjS+FeVXq4aQbS62BwEo64m2TUtcR0FUcA6uYSIkh
tcVLn0H8mgylvlgioMQXbnx6UiwMQPcNwbV85V3wdZGW8vhO9ktewDIOiUi1
FUgCcbd8yS9VL4Ly5/q9Q3IuGbvff9gvRRWjdIkslg+HGMLpZ34SgJY2yJau
MRnlkrhwpgbdDH7IRJNkNVIUyCxR9gRUXLc6mpKSIXpAlkoSeD4yElw8mbEE
iWk9PlKJGrYDNu6Hq+vz218mVLOGNOTbF9++oKSsW0XbVxvZBezsVG7CAwuW
zJdb+qXxvGpXBSTQ1UcuY+Eenyn1+++/q944U/31iy+/1PrqWqY91VN9BD63
Kb9bvpDQekxPqnPtgJsg1xaZer5NmHagAqT+zyIFdPmOheqIFm0O2R1KBfvv
USKxOvIhb3OAn5JvcLrsHQvLJj0LO4DAPQtL5iYrSzJSZrB4AxJA3qWjy+r1
MXn0zWsq2bz8BvPSjk4B4FRKNIZx8tYjlQTmQG+RMWFIxJLKfi1pZssM0JqE
oTznGatWHatOTBm1hWX5zBIo2BJYYIROWgTDjFGjLB5nnsBWTGSKnsuAOsgv
rg45tnWdc7VsaNcZJEZoyCMGNR/CM0qMHNqrkcovUgN9xCcRDrDpxQgZ62j5
1eg4JVlo87BnE4gRFLRqPBZ2mNPUoX6Llae2zBks905upNA+5iq7GqqySwUs
0ktCHTrEkcg+6ZR1pwpEGhSFyG3c1/1020UYDBm3Myw7RlZh+hhgKXXqUBYk
9UlaDNFRSf2fMjnKBrLVmFFh4Hl9SGxiMjiOekZ/bbkSslvz2Wg8aTFFkhYp
yd8l6+mwZBF3EhZxQCKKaQwwNNrl5S1kGFjdV51avNewrxsfWqAvkvbWxoEF
Bh8Hxe8oN9ihX/07+MvUjzHN6k3GjASrpEilYqKngvdX3SEis8azc4ybWUQK
cLvL24FwRKvwkBR4XcEwhprwqRCes9E5YRZWyOUZmKAlk0IbHloziTSvMP+j
Lo9biQsDS46hgdz8FGjVMsSOEqvXdMwf4hf8vMma5XeENqSIx++RHnWjh99E
16DpeQfcmBpTBzzQQ+tg/gNKq8ISvGpgU8fKWxHtBq7o/s2dzlFdc+ajlNK6
fo32Tvzt5fQFDi6bwOeOf1gtpxp8PFmPkvnyg0rQpF9H9+WRbgyT7DNkgbT6
nYq/JyuSfCumrl7YDQCbMDmMBBaF4+XT6YsLyvD8nVWNcLU0JbEEMtjNPsH0
y5CpVLan0W6COE7yzIhnBWJ/AXLlzWqHp45om/HkGbkNmDPejFUwBo5tZSEf
/rSpyGZFT1fvwCmKGoMz4sQN2X0L4NoAnkTIFe9CYRCwCBNxuvg4ghjEIVug
D41VLPH6sicuTkCVYaifwzuxGamgqU1tITmzMJP5ZIUceOhJ4pUP0HD7FjcV
1k6YArKpsDSvRcLm1rVk5HgG0o1StHtS/+BqEcSCOYFzZwtzBEXRRYevdKj2
WM/aRskJPiW20fYms4x6G1hjMGin8EXx3pQO4FD1mgqSxFssdMDDIsdvy9jH
4aX8AhK+2i4g1qySDZxGmpmDbOTMwwFgHDJ0OrnyLsryBk/kkiHm7pyxsGg+
ooOJAZzRDAhwPq8jkl2brQHR+CDftzlM9Z0xkIU4aWUDojn3hSW00xZ0Lulb
GuquKdSVtZTRkvJZhzw3+wdyScVexvLeoP7wDBymPSZCjmDo68IK1crbHIGu
a1i4haiOyBVd/0gZic7l64t3dO9t1SKfPO+cS/sqF+jiw9IiUQElhEM/wbMI
pf6UsxMmAJUokPtmC9odbkLhavxBbtAJQYdMQtKL/w+T0KlJqAMmETqV3siJ
MBjF3iExoB8CUJYW7ZPg1DtMP5QneiAeLLJlHParOhQI6CgjBKuZUUTMffUy
pCFMnwMJ5KhSI/wH9/freK5LIpy8x5Ln0eNjOHd/ejoeq9HJNN53cvj0/dlG
sFgY60dtNK3kwMXLgfVK7PgROiItOGgqvtbj23FSyENLTVf1/vYKK3/ck4Xu
xpmKi+OiNyEUf/XpE8zNERTtIRxOqKPIaU7/NH2JrvFZKHmcnn6JLTHY5UiP
RiQsfZdKb3+U3xdf5wml9DsU0svgxNAxw9zx2QiM4/df+QoeNwXsFaUBcvrF
gF6ZmaNDpZ4pECY2xslr8AQQ0ICbO/pZFk6hkkb3DHi/VO7bE1SyRf2aOzmA
P3XunFxyzOPpAPf8g9JhEiOiGNQBPUuZELNMFBSAXRTtj2vSG33TnWwqsELQ
V4VVZCXoBK4rSSyj0JwyE6nNSxk9Ck0GCfhP5b+xEgPheBgDS9KSlgJOyKhJ
O74G8YwqaY85D4GPu8S2AOKp0gsSr6gVLP7EVRpZsGx0wec8oYsRPq3NeoZV
2I7NqiyvK6B+MZzFU1ikoFjRl5FtetBDTBRoBywSDbHMdwTSeKZ10TGgH719
PX7eseeY8nQYCKrlgClSsugVNjPzqtPxihuMykPQ5aSvX4/adwqSRCjY/nye
m++16KC9K6KhRMV9B+rcIjpRZTHb5+a9AyvaHkWEN2fe50OgtutQoaIm0z/w
UIjHSkIlno+hVgg9Ykid6rREQKfFXOENmYXyzbQQmtN0ogcR+6DVGVrRTvqc
FW50wPnRNHyqhbmc5BcDhIItN3HU/em4YBoW61HSz8Mlu8RMGWv/DnOKPqvi
QRpWEXuJ3X5bWu+027WEsT+9uvcWqI4k5/MdkZmonRJnNrFjbx2IjD3w46R+
F87g0gImh3ZYmxshC5BC/3Fay5TlnEO6sQFCBCBm6n6FxaaN0+SCRA4iJiTA
DezCv7zRK5o/SzogQnD5PWzJwLlsKBTGSowoUcoxqNbD05BNn5xOT9VrYCln
/fMKxTo408Ma5DrMT7F/FUE1FPRENmlSZiIZ+lB7/NFnuJJA+6+JTYQzYPC3
gTZrSTbYBAcKjVIXABI/qeaQhgJ6dEegRgx/cqRaRzQOQqFA+VSHZTJpijXa
wwIZ5QkWcJsCQFDKmtIPz9YGtnvIQCk++LeYCPHeCfpdoAcXxvOgx88DdCl1
3jRZ/hGBlYiib++WiAYuy3Q8vC7jKUuOmU5jPlH7tvLt27xvgjfghQ2HeNAM
3HX36gI8/Hv+hFTx5ZdffYXoec+ZX6nNfI60cmswyoP5UfNSVGpsfKcyiAhW
eCxXAx0u3jZQpv9ogVoDzmJtOQQQnHZtG7tgzLTIaABnae8IVdFJ+CDMe0Gv
12GPRyrh8wM0JBCwAx246j1XFWJBgprjVxUIIck6qZHalDEY+Oybjp5kHZzg
fFjGtxAGGmX/aBF0tsLMRoJwN7H0uEehCKG+7BS6pCNKOhNg7BIJMdPngM70
/gK72tW7CYRI1HU4uaCiAN2S2xryNOxsyPFVEC5/heSH+77E1GGm3NSlNxHO
iTm2U2oKqWZjc2wmVPsMAg/Ja+woSPu+Dp4bc9FBgXbIyBPztAkFwmYIXOED
9dNzkd6/XIM9ebEC56tyvCHov7i6NWASeoMBdMe2CHwmHGZ0G/rgJxVXc0yH
N3ae6IDnC8udZzm2c1IbPGISgy8V9ggUIM+zaQz3C6cT/A6LQcLqj7nS92JS
asGnNPFHtszjcccg5Ow5NoumFSbPN9JTzr4le8NP33xJ6k/duv7wgRpbS9oO
Plbejw4UbcIU0v7tD+/AR+DBFrMJTmh85SJQX+6Ba3qvPXXoCWXlsM77N3cq
qY76yg69gTJU5yMuhxjksz8fG1QvHsCE6cE4t3dgonEfDIKjhOMcI7BBiB57
bPEmnBf7vFhMdOhUm0CfqrX4LoAtP3KswDdSFqX99SAnJ2jwJBRbc7HdHcI4
1kEwYYKRfOsy5fR1Rjgei7K+f2838MLAUM9ycsQiCBNeJRRXYVOQF0aimYPh
0hndptpQEuVJWKYPcfBp2lztDL1jh4yqrjLKpfJeqgFShfjV8WIlok0x6F7c
XN9d3d2/ur74hXqKqJtIQBNPcpBCTDpMP76/hXu0Rd83D/5VT+7vctJPBb5w
cKscrSOMjHBNL8hBSoVtzxSCfXz3qY7wOrPGE14OAUAklqyw3nrVHmqNtT/k
j5KijZNY9TqV1Dd+89t2DEP7h02J7qhUnaB7YZpYIQhIqay3MMjVJnJrKOTu
qaiT4eC2uqbaJOcTISum0neFWrRUCIFYxS/imD3s5ld2G449Ab64qpBAXHiX
VIJ5i29vMgDIseo+CHBuM3xCSi2xwiglH0EbFVv/m4z5NykGqVhOqjyzmO/2
YoR/s4wXhmdo9PqlxArf9SKdyYQ/g+Es2dZsBgY9xW6nROusHC6F7hkVvXdN
x0o+cQpvk/ZW1TU/LNbRcxTBRv0zaupBiceQRugiDUSWlliGvOac1TMLgAYa
CBMrViclgeI7kdLurSSmFd3ywVh5wf1baOk7G4c9old12FOIf+WaFyml7ODr
zOPyZVUxlqGylHj+gJCcpYBb5dgEvDCdd880xQFgiFzJo/5FeSM42wDZ4VeY
B8bcxHeluGkn6blvlrXJpPWeUqyr8+vz/ZTKZmX2RI5DaYn/sxbvQpNw/4W2
onC9VBwu1+HoYngU7M9fgPA1vcbG8VpeVC/CS15D7zs6qVnFlyRhLb/p65ZK
lho+4eFD/PebfisdoM/8+03fGsLw3D/6G4w54X86fDp0Yejf/k005jf66FVW
gxudrzxFPhYRuMsjkemS/rbC3pudcjYy1AkqGATPHnU26Rjmxh39gIncz/70
RCmyABsquUwNYEOp26w0D7KTAqqj7uNupMMeds6VYEPiu55nulN5UeqC/n4B
scQaLMbU/s+c3PmeFCYvIvpZtyMZbgOe37ozdJ11VtIl/BsBzFJDbn+mr0/O
+S80zAAs1P8AAeu4e85FAAA=

-->
</rfc>