<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.19 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-privacypass-http-api-01" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.1 -->
  <front>
    <title abbrev="PP http api">Privacy Pass HTTP API</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-http-api-01"/>
    <author initials="S." surname="Valdez" fullname="Steven Valdez">
      <organization>Google LLC</organization>
      <address>
        <email>svaldez@chromium.org</email>
      </address>
    </author>
    <date year="2021" month="July" day="12"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document specifies an integration for Privacy Pass over an HTTP
API, along with recommendations on how key commitments are stored and
accessed by HTTP-based consumers.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Privacy Pass protocol as described in <xref target="draft-ietf-privacypass-protocol" format="default"/>
can be integrated with a number of different settings, from server to
server communication to browsing the internet.</t>
      <t>In this document, we will provide an API to use for integrating Privacy
Pass with an HTTP framework. Providing the format of HTTP requests and
responses needed to implement the Privacy Pass protocol.</t>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>We use the same definition of server and client that is used in
<xref target="draft-ietf-privacypass-protocol" format="default"/> and <xref target="draft-ietf-privacypass-architecture" format="default"/>.</t>
        <t>We assume that all protocol messages are encoded into raw byte format
before being sent. We use the TLS presentation language <xref target="RFC8446" format="default"/> to
describe the structure of protocol messages.</t>
      </section>
      <section anchor="layout" numbered="true" toc="default">
        <name>Layout</name>
        <ul spacing="normal">
          <li>
            <xref target="wrapping" format="default"/>: Describes the wrapping of messages within HTTP
requests/responses.</li>
          <li>
            <xref target="server-config" format="default"/>: Describes how HTTP clients retrieve server
configurations and key commitments.</li>
          <li>
            <xref target="issuance" format="default"/>: Describes how issuance requests are performed via a HTTP
API.</li>
          <li>
            <xref target="redemption" format="default"/>: Describes how redemption requests are performed via a
HTTP API.</li>
        </ul>
      </section>
      <section anchor="requirements" numbered="true" toc="default">
        <name>Requirements</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
      </section>
    </section>
    <section anchor="wrapping" numbered="true" toc="default">
      <name>Privacy Pass HTTP API Wrapping</name>
      <t>Messages from HTTP-based clients to HTTP-based servers are performed as
GET and POST requests. The messages are sent via the
<tt>Sec-Privacy-Pass</tt> header.</t>
      <t><tt>Sec-Privacy-Pass</tt> is a Dictionary Structured Header
<xref target="draft-ietf-httpbis-header-structure-15" format="default"/>. The dictionary has two keys:</t>
      <ul spacing="normal">
        <li>
          <tt>type</tt> whose value is a String conveying the function that is being
performed with this request.</li>
        <li>
          <tt>body</tt> whose value is a byte sequence containing a Privacy Pass
protocol message.</li>
      </ul>
      <t>Note that the requests may contain addition Headers, request data and
URL parameters that are not specified here, these extra fields should be
ignored, though may be used by the server to determine whether to
fulfill the requested issuance/redemption.</t>
    </section>
    <section anchor="server-config" numbered="true" toc="default">
      <name>Server key registry</name>
      <t>A client SHOULD fetch a server's current public key information prior to
performing issuance and redemption. This configuration is accessible via
a <tt>CONFIG_ENDPOINT</tt>, either provided by the server or by a global
registry that provides consistency and anonymization guarantees.</t>
      <section anchor="commitment-registry" numbered="true" toc="default">
        <name>Key Registry</name>
        <t>To ensure that a server isn't providing different views of their public
key material to different users, servers are expected to write their
commitments to a verifiable data structure.</t>
        <t>Using a verifiable log-backed map (<xref target="verifiable-data-structures" format="default"/>), the
server can publish their commitments to the log in a way that clients
can detect when the server is attempting to provide a split-view of
their key commitments to different clients.</t>
        <t>The key to the map is the <tt>server_origin</tt>, with the value being:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque public_key<1..2^16-1>;
    uint64 expiry;
    uint8 supported_methods; # 3:Issue/Redeem, 2:Redeem, 1:Issue
    opaque signature<1..2^16-1>;
} KeyCommitment;

struct {
    opaque server_id<1..2^16-1>;
    uint16 ciphersuite;
    opaque verification_key<1..2^16-1>;
    KeyCommitment commitments<1..2^16-1>;
}
]]></artwork>
        <t>The addition to the log is made via a signed message to the log
operator, which verifies the authenticity against a public key
associated with that server origin (either via the Web PKI or a
out-of-band key). The signature should be computed under a long-term
signing key that is associated with the server identity.</t>
        <t>The server SHOULD then store an inclusion proof of the current key
commitment so that it can present it when delivering the key commitment
directly to the client or when the key commitment is being delivered by
a delegated party (other registries/preloaded configuration lists/etc).</t>
        <t>The client can then perform a request for the key commitment against
either the global registry or the server as described in
<xref target="key-commitment" format="default"/>. Note that the signature should be verified by the
client to ensure that the key material is owned by the server. This
requires that the client know the public verification key that is
associated with the server.</t>
        <t>To avoid user segregation as a result of server configuration/commitment
rotation, the log operator SHOULD enforce limits on how many active
commitments exist and how quickly the commitments are being rotated.
Clients SHOULD reject configurations/commitments that violate their
requirements for avoiding user segregation. These considerations are
discussed as part of <xref target="draft-ietf-privacypass-architecture" format="default"/>.</t>
      </section>
      <section anchor="config-retrieval" numbered="true" toc="default">
        <name>Server Configuration Retrieval</name>
        <t>Inputs:
- <tt>server_origin</tt>: The origin to retrieve a server configuration for.</t>
        <t>No outputs.</t>
        <ol spacing="normal" type="1"><li>The client makes an anonymous GET request to
<tt>CONFIG_ENDPOINT</tt>/.well-known/privacy-pass with a message of type
<tt>fetch-config</tt> and a body of:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque server_origin<1..2^16-1>;
}
]]></artwork>
        <ol spacing="normal" type="1"><li>The server looks up the configuration associated with the origin
<tt>server_origin</tt> and responds with a message of type <tt>config</tt> and
a body of:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque server_id<1..2^16-1>;
    uint16 ciphersuite;
    opaque commitment_id<1..2^8-1>;
    opaque verification_key<1..2^16-1>;
}
]]></artwork>
        <ol spacing="normal" type="1"><li>The client then stores the associated configuration state under the
corresponding <tt>server_origin</tt>.</li>
        </ol>
        <t>(TODO: This might be mergable with key commitment retrieval if server_id
= server_origin)</t>
      </section>
    </section>
    <section anchor="key-commitment" numbered="true" toc="default">
      <name>Key Commitment Retrieval</name>
      <t>The client SHOULD retrieve server key commitments prior to both an
issuance and redemption to verify the consistency of the keys and to
monitor for key rotation between issuance and redemption events.</t>
      <t>Inputs:
- <tt>server_origin</tt>: The origin to retrieve a key commitment for.</t>
      <t>No outputs.</t>
      <ol spacing="normal" type="1"><li>The client fetches the configuration state <tt>server_id</tt>,
<tt>ciphersuite</tt>, <tt>commitment_id</tt> associated with <tt>server_origin</tt>.</li>
        <li>The client makes an anonymous GET request to
<tt>CONFIG_ENDPOINT</tt>/.well-known/privacy-pass with a message of type
<tt>fetch-commitment</tt> and a body of:</li>
      </ol>
      <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque server_id<1..2^16-1> = server_id;
    opaque commitment_id<1..2^8-1> = commitment_id;
}
]]></artwork>
      <ol spacing="normal" type="1"><li>The server looks up the current configuration, and constructs a list
of commitments to return, noting whether a key commitment is valid
for issuance or redemption or both.</li>
        <li>The server then responds with a message of type <tt>commitment</tt> and a
body of:</li>
      </ol>
      <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque public_key<1..2^16-1>;
    uint64 expiry;
    uint8 supported_methods; # 3:Issue/Redeem, 2:Redeem, 1:Issue
    opaque signature<1..2^16-1>;
} KeyCommitment;

struct {
    opaque server_id<1..2^16-1>;
    uint16 ciphersuite;
    opaque verification_key<1..2^16-1>;
    KeyCommitment commitments<1..2^16-1>;
    opaque inclusion_proofs<1..2^16-1>;
}
]]></artwork>
      <ol spacing="normal" type="1"><li>The client then verifies the signature for each key commitment and
stores the list of commitments to the current scope. The client
SHOULD NOT cache the commitments beyond the current scope, as new
commitments should be fetched for each independent issuance and
redemption request. The client SHOULD verify the <tt>inclusion_proofs</tt>
to confirm that the key commitment has been submitted to a trusted
registry. Once the client receives the <tt>ciphersuite</tt> for the
server, it should implement all Privacy Pass API functions (as
detailed in <xref target="draft-ietf-privacypass-protocol" format="default"/>) using this ciphersuite.</li>
      </ol>
    </section>
    <section anchor="issuance" numbered="true" toc="default">
      <name>Privacy Pass Issuance</name>
      <t>Inputs:
- <tt>server_origin</tt>: The origin to request token issuance from.
- <tt>count</tt>: The number of tokens to request issuance for.</t>
      <t>Outputs:
- <tt>tokens</tt>: A list of tokens that have been signed via the Privacy
  Pass protocol.</t>
      <ol spacing="normal" type="1"><li>When a client wants to request tokens from a server, it should first
fetch a key commitment from the server via the process described in
<xref target="key-commitment" format="default"/> and keep the result as <tt>commitment</tt>.</li>
        <li>The client should then call the <tt>Generate</tt> function requesting
<tt>count</tt> tokens storing the resulting <tt>input</tt> data.</li>
        <li>The client then makes a POST request to
&lt;<tt>server_origin</tt>&gt;/.well-known/privacy-pass with a message of type
<tt>request-issuance</tt> and a body of:</li>
      </ol>
      <artwork name="" type="" align="left" alt=""><![CDATA[
enum { Normal(0) } IssuanceType;

struct {
    IssuanceType type = 0;
    opaque msg<0..2^16-1> = input.msg;
}
]]></artwork>
      <ol spacing="normal" type="1"><li>The server, upon receipt of the <tt>request</tt> should call the <tt>Issue</tt>
function with the <tt>public_key</tt>, <tt>secret_key</tt> and the value of
<tt>msg</tt> with a result of <tt>resp</tt>.</li>
        <li>The server should then respond to the POST request with a message of
type <tt>issue</tt> and a body of:</li>
      </ol>
      <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    IssuanceType type = request.type;
    IssuanceResp resp = resp;
}
]]></artwork>
      <ol spacing="normal" type="1"><li>The client should then should call the <tt>Process</tt> function with the
<tt>public_key</tt>, stored <tt>inputs</tt> and resulting <tt>resp</tt>, to extract
a list of <tt>redemption_tokens</tt>.</li>
        <li>The client should store the <tt>public_key</tt> associated with these
tokens and the elements of <tt>redemption_tokens</tt> under storage
partitioned by    the <tt>server_origin</tt>, accessible only via the
Privacy Pass API.</li>
      </ol>
    </section>
    <section anchor="redemption" numbered="true" toc="default">
      <name>Privacy Pass Redemption</name>
      <t>There are two forms of Privacy Pass redemption that could function under
the HTTP API. Either passing along a token directly to the target
endpoint, which would perform its own redemption <xref target="token-redemption" format="default"/>,
or the client redeeming the token and passing the result along to the
target endpoint. These two methods are described below.</t>
      <t>In the HTTP ecosystem, redemption contexts should generally be keyed
by the same privacy boundary used for cookies and other local
storage. Generally this is the top-level origin. Any redemption context should be built following the principles outlined in <xref target="draft-ietf-privacypass-architecture" format="default"/> and later in <xref target="privacy" format="default"/>.</t>
      <section anchor="token-redemption" numbered="true" toc="default">
        <name>Generic Token Redemption</name>
        <t>Inputs:
- <tt>context</tt>: The request context to use.
- <tt>server_id</tt>: The server ID to redeem a token against.
- <tt>ciphersuite</tt>: The ciphersuite for this token.
- <tt>public_key</tt>: The public key associated with this token.
- <tt>redemption_token</tt>: A Privacy Pass token.
- <tt>info</tt>: Additional data to bind to this token redemption.</t>
        <t>Outputs:
- <tt>result</tt>: The result of the redemption from the server.</t>
        <ol spacing="normal" type="1"><li>The client should check whether the <tt>server_id</tt> is present in the
<tt>context</tt>. If it isn't and the size of the <tt>context</tt> is beneath
the client's limit, it should be added.</li>
          <li>The client should call the <tt>Redeem</tt> function with
<tt>redemption_token</tt> and additional data of <tt>info</tt> storing the
resulting <tt>data</tt> and <tt>tag</tt>.</li>
          <li>The client makes a POST request to
&lt;<tt>server_origin</tt>&gt;/.well-known/privacy-pass with a message of type
<tt>token-redemption</tt> and a body of:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque server_id<1..2^16-1> = server_id;
    opaque data<1..2^16-1> = data;
    opaque tag<1..2^16-1> = tag;
    opaque info<1..2^16-1> = info;
}
]]></artwork>
        <ol spacing="normal" type="1"><li>The server, upon receipt of <tt>request</tt> should call the <tt>Verify</tt>
interface with <tt>public_key</tt>, <tt>secret_key</tt> and the received
<tt>data</tt>, <tt>tag</tt>, <tt>info</tt> storing the resulting <tt>resp</tt>.</li>
          <li>The server should then respond to the POST request with a message of
type <tt>redemption-result</tt> and a signed body of:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque info<1..2^16-1> = info;
    uint8 result = resp;
    // signature of info and result using
    // the server's verification key.
    opaque signature<1..2^16-1>;
}
]]></artwork>
        <ol spacing="normal" type="1"><li>The client upon receipt of this message should verify the
<tt>signature</tt> using the <tt>verification_key</tt> from the configuration
and return the <tt>result</tt>.</li>
        </ol>
      </section>
      <section anchor="direct-redemption" numbered="true" toc="default">
        <name>Direct Redemption</name>
        <t>Inputs:
- <tt>context</tt>: The request context to use.
- <tt>server_origin</tt>: The server origin to redeem a token for.
- <tt>target</tt>: The target endpoint to send the token to.
- <tt>additional_data</tt>: Additional data to bind to this redemption
  request.</t>
        <ol spacing="normal" type="1"><li>When a client wants to redeem tokens for a server, it should first
fetch a key commitment from the server via the process described in
<xref target="key-commitment" format="default"/> and keep the result as <tt>commitment</tt>.</li>
          <li>The client should then look up the storage partition associated with
<tt>server_origin</tt> and fetch a <tt>redemption_token</tt> and
<tt>public_key</tt>.</li>
          <li>The client should verify that the <tt>public_key</tt> is in the current
<tt>commitment</tt>. If not, it should discard the token and fail the
redemption attempt.</li>
          <li>As part of the request to <tt>target</tt>, the client will include the
token as part of the request in the <tt>Sec-Privacy-Pass</tt> header along
with whatever other parameters are being passed as part of the
request to <tt>target</tt>. The header will contain a message of type
<tt>token-redemption</tt> with a body of:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque server_id<1..2^16-1> = server_id;
    uint16 ciphersuite = ciphersuite;
    opaque public_key<1..2^16-1> = public_key;
    RedemptionToken token<1..2^16-1> = redemption_token;
    opaque additional_data<1..2^16-1> = additional_data;
}
]]></artwork>
        <t>At this point, the <tt>target</tt> can perform a generic redemption as
described in <xref target="token-redemption" format="default"/> by forwarding the message included in
the request to <tt>target</tt>.</t>
      </section>
      <section anchor="delegated-redemption" numbered="true" toc="default">
        <name>Delegated Redemption</name>
        <t>Inputs:
- <tt>context</tt>: The request context to use.
- <tt>server_origin</tt>: The server origin to redeem a token for.
- <tt>target</tt>: The target endpoint to send the token to.
- <tt>additional_data</tt>: Additional data to bind to this redemption
  request.</t>
        <ol spacing="normal" type="1"><li>When a client wants to redeem tokens for a server, it should first
fetch a key commitment from the server via the process described in
<xref target="key-commitment" format="default"/> and keep the result as <tt>commitment</tt>.</li>
          <li>The client should then look up the storage partition associated with
<tt>server_origin</tt> and fetch a <tt>redemption_token</tt> and
<tt>public_key</tt>.</li>
          <li>The client should verify that the <tt>public_key</tt> is in the current
<tt>commitment</tt>. If not, it should discard the token and fail the
redemption attempt.</li>
          <li>The client constructs a bytestring <tt>info</tt> made up of the
<tt>target</tt>, the current <tt>timestamp</tt>, and <tt>additional_data</tt>:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque target<1..2^16-1>;
    uint64 timestamp;
    opaque additional_data<0..2^16-1>;
}
]]></artwork>
        <ol spacing="normal" type="1"><li>The client then performs a token redemption as described in
<xref target="token-redemption" format="default"/>. Storing the resulting <tt>redemption-result</tt>
message.</li>
          <li>As part of the request to <tt>target</tt>, the client will include the
redemption result as part of the request in the <tt>Sec-Privacy-Pass</tt>
header along with whatever other parameters are being passed as part
of the request to <tt>target</tt>. The header will contain a message of
type <tt>signed-redemption-result</tt> with a body of:</li>
        </ol>
        <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    opaque server_origin<1..2^16-1>;
    opaque target<1..2^16-1>;
    uint64 timestamp;
    opaque additional_data<1..2^16-1> = additional_data;
    opaque signed_redemption<1..2^16-1>;
}
]]></artwork>
        <t>At this point, the <tt>target</tt> can verify the integrity of
<tt>signed_redemption.info</tt> based on the values of <tt>target</tt>,
<tt>timestamp</tt>, and <tt>additional_data</tt> and verify the signature of the
redemption result by querying the current configuration of the Privacy
Pass server. The inclusion of <tt>target</tt> and <tt>timestamp</tt> proves that
the server attested to the validity of the token in relation to this
particular request.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security considerations for Privacy Pass are discussed in
<xref target="draft-ietf-privacypass-architecture" format="default"/>.</t>
    </section>
    <section anchor="privacy" numbered="true" toc="default">
      <name>Privacy considerations</name>
      <t>General privacy considerations for Privacy Pass are discussed in
<xref target="draft-ietf-privacypass-architecture" format="default"/>.</t>
      <t>In order to implement this API with redemption contexts, a client
needs to maintain strong privacy boundaries between different
redemption contexts to avoid privacy leakage from redemptions across
them. Notably in the web/HTTP world, cross-site tracking and
fingerprinting will need to be considered and mitigated in order to
maintain these privacy boundaries.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="well-known-uri" numbered="true" toc="default">
        <name>Well-Known URI</name>
        <t>This specification registers a new well-known URI.</t>
        <t>URI suffix: "privacy-pass"</t>
        <t>Change controller: IETF.</t>
        <t>Specification document(s): this specification</t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization/>
          </author>
          <date month="August" year="2018"/>
          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="draft-ietf-httpbis-header-structure-15" target="https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15">
        <front>
          <title>Structured Headers for HTTP</title>
          <author initials="M." surname="Nottingham">
            <organization>Fastly</organization>
          </author>
          <author initials="P-H." surname="Kamp">
            <organization>The Varnish Cache Project</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="draft-ietf-privacypass-protocol" target="https://tools.ietf.org/html/draft-ietf-privacypass-protocol-00">
        <front>
          <title>Privacy Pass: The Protocol</title>
          <author initials="A." surname="Davidson">
            <organization>Cloudflare Portugal</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="draft-ietf-privacypass-architecture" target="https://tools.ietf.org/html/draft-ietf-privacypass-architecture-00">
        <front>
          <title>Privacy Pass: Architectural Framework</title>
          <author initials="A." surname="Davidson">
            <organization>Cloudflare Portugal</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="verifiable-data-structures" target="https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf">
        <front>
          <title>Verifiable Data Structures</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAKGn7GAAA+1b224bR5q+76coWBexATZpeTJGhkkGK8iOI8S2tJI8wSLI
msXuIlmrZhe3qymaERzMg8y83DzJ/oeq6uoDbTnrALtAchFT3XX4j99/qOo0
TZNa14WaigcXlb6V2V5cSGvF99fXF+Lk4uxBIufzSt1OxcWFWNX1RsiNTnKT
lXINk/JKLupUq3qRbnj6BmanODCFgenj4ySXtZomGfx/aar9VOhyYZJEb6qp
qKutrZ88fvyXx0+SG7XfmSqfirOyVlWp6vQZrp0ktpZl/lYWpoT99somGz0V
P9UmGwlrqrpSCwu/9mv88XOSyG29MtU0EWki4D9d2qm4Gou/ySJXv9Ajpvyq
VreqjJ+bajkVL4xZFkq8fHlKz9Ra6mIq7C0N+7dsVZm13q7HMDZJktJUa1nr
W+BPiMvvTp8cH//F/fzqyy+f4s9IQCiUuQbhKJmrKrXAfVZvK5Ue/3lKm3lF
XPk3ufiexlqxMBWp5AEPlNVS1VPSh51OJrUxhR3jJkjYZFWvi8n9Nqblgsjo
v9T962T3aixem7rW5XIl1+EVyeo7aetiPzztIv1+LH6Q6017yvVKgcirUtuV
OJUZ/HVRmf9SWd0WVWxLm8qAsk3RllFsrLzshRv3m0Q0tGH6+PGAeIi7k7F4
Jm91bk2ZRNydFmabLwpZATVgmtulLA7zJatspWtFmvgQbyfNOFmI7yqwXnCU
m/81m/H+n4vVW1XphZbzQqXg9rIxNdvm8G9hHCxeSxEs3g6ztdT1ajsfZ2Y9
WZKDTupKF4WW5WRemPlkDZaoqgnAkp1s5AY8ZtJsgTs0G4w3+SJJ0jQVcg7k
STC95HqlrYDJ27Uqa2E3KoOpygpZggwAtypwclOSE7ZA0gC/OAg9MwGwHAmE
qaXYAbmiUkAuLJjTZBhcipXZCcA5gS90jZvBHiBBWxt0dsC5RGaZshb+mO9p
2XQu8a8MVgDqKjtm2tc6zwuVJEcIl5XJgTnYBDlRbRK9MQsJHCqbVXoOy+lS
3N19xPzfvwfQLsVcBRnAROJMinK7ngPrZiFyvVioisSmCCUAjBcAkvBnhdKp
TeJ+IdPbUmcsy9qIeWV2FmaIesV7IOoDf2fwNlbISOwUbFwUyAxYokKRg7Rx
ja1VpJagJljO8Z8Q/0wwqwgIc84zRrSApfzuCwJy5IfGVeq/t8qickAjYDMb
kD6YQ6lUDjKAbfV6UygylvqQwIGRoyNxraq1Lk1hlvsk+VERvTjFAiGgj4Uu
NYkDdnZigi1FVmheG2gCQWwtqSy5h8po+sFxscu/fz8miuA5SJn3kixjNpg1
2KFcKrZQVWYmJyqA+0ruwDxrL7ZkruCHAktBcVqgfCwiVq9fXsGiCp+z6gtZ
LrewsvjJxcmf0Uq8cbJ4vLuiYHoUsWhfyr3ZgvOmwO+ukpsN7P7+/VQ8cwtZ
Wsm/wYUCR2gU2rmtCNqeBE2PaVFWSAqut9CdldGRyVJYUxbWAECChMJpEVbl
advKeT/qpeP6vIsG+csyU/0N/JvIHEEgAG4odtDFrZbgio4J8AdeD4BErTe4
aX/F5t0H14TlfPrHor6Ewboig7eMMcgKpmtWPHj15ur6wYj/Fa/P6ffl839/
c3b5/Bn+vvr+5OXL8INHJPDH+ZuX7j3+amaenr969fz1M5786uQ/4B8U3oPz
i+uz89cnLx8geiFAJAGxkQcEFAcjYG2IVX3Ecykamf6RGMx3xY/eYO6OglUl
yStvOoRtMTA7A4Dto6dsBV3hSpu8eH5N3Fycg7C8DsaUv7T8Db2FlAE2nMxm
VypLHbkpkjubCU7mgJHBt4AaUjzTFBVktRe9lDL56X4J4s9MXN4stQK51juD
JgBRHWxuNqv3GwWb7lYGfB5S5a1iAmBXlCS4wq3aB6zdlhmHAAdvhBtgc42g
CLQpBjgRjWmbucn3Q9sQFlkcid4Cu9UScBW2ky0d4xYdKAHxQXLr0A+JC26x
lnu/kpB5zijtsvGRHyYwyaEg8ebypdhIDC816p3RFPRYmiafyEFnlRrhPkC/
egfJh4DHBTiRXZltATFfJXpZYi6Ao8x2uSI65opDAKQEBI4+soJ51xRfAOZW
Cl5RuF1siwUGy4gdtH8HJpMGA8gJrngx9OdKLTWofg+W34a+JDnxIck560LV
GeYBPO4LK7JtRUnAZjsvdEbLYZ1H5REIDoKQIeKcjlE5Ad7QHyKqBGVjLfgk
NVNipDFlBL9IJNjD6fnr785evAWwuDg/e309m42E0iQGlyh0RQY0wAMplpAz
Qr4aGCZ1uTm0tYXnYEx7ok2Wptyv9S9MCoSuSgLK+DD0A7B62UiuwffULw/y
uzYQQS3GM7YMT5C25Rd+Z5RJk03darWzGLSAfF05uWKRDBYBStdQCqABhPFg
IGiYMfCod2B4NScsu0qTmcNaSZx9wisZZe1s0MH/gcM3lh0pGgPJDMBcdgMr
r+VGPPzpcNb/8yMy95ACQiJGnNiV46tDC+oKlke0lmInnWYcxlI6iiaf1Wjv
ZaxZNJC6JhNCmDFNqgjuV+g6RXmCOBPetpuEt0Tpths3kc5RhtxqTitmM974
ran0Updoeg60PDIRqgE+/vrrrwkLRNxxm2EjwSmdRt/C8t8cj8dP/vP4aXr8
169pxBai2NMvUX+62jePvhJ2u9lAsaXyt4AzK5Pbr8WR+NP0DDxJTS7BhdR6
JJ5M/a9jfhPvagFfJKqmtel7tOLTII+vk0GKHcc6HyT4+KnI9Aacz27B1L6O
J7J9cOI/yHBr91gxbSpJlqSUgMixzSBo58qlRcgoGijjfDQuMYBBEgou0NhK
A4oxdS5dxAIYNtaZrsH5l4D+Ft21gbUEAonJdFMMkYUGfEFjEA8dCrn4Dcnw
XFz8cIbwIxPIWVOzAAfihPARx9eglyYUoBw2W9xnW+ZYGAisLVNE/ASHo6GT
cbow2ies8Y4cear3zqTdU4flyDBXoFzvZsXWMmYbgB9GoIDvKIFGP8Iat33N
vs1pPv5JDpqrQqN4XeRve12SQ0qZ1UVwLxdiQErBu9szQrLgFyaAh1AAf6ol
cQ4xGBT30JD8HQCDbidAWWFkzpV0FFgAiiDxh2j2yMnGEYHckGBcwALp+5iP
5eYAbc5YEqd7HMFhpomrbqIv9NrpKVR3sGLarAhZqmgnJ0NG4qzXR7rEl47t
gOPpDbEDJGl2ZTdAcuxNKk73bTPXrXpTQhGBfzt/iB07tsUBJwlbUDCUt0bn
FLPg8bJC5eES0pKc7baoo4q4pbFJZECQzNGzUcAA79vethXmIJBiFBrmhBbM
Wpbg3Bk2blvBUL3T6O3gmDgKZJDdFCyebsOGrZD2V/k4OXVFgNu1UtjR7FSA
k1a8QTndalPIEJWrqMYiGyMZ4TZdMRFiWMV5Sq5ChVkpcCmbbal9BKJEX0Ax
3r8dgPmMSwhPW25yyeUtGA5mOPgmrfyj98lZCTgFtUDaD4vcmnW4iK0DXyfL
Qe0i45STC4BJXBT+OGaEdCa4ljfcmOOszGytwJrKOyekmBBPBlLDyXiniiJF
Cy4nTgjppukQhUiBgAflDC9Dea5Lg6HyoGxQYBkCwz4Q21tCGIphTxzqswgK
Y26s2G6cqcXyGHIkXpYJ7Ijb5dLYxsgPcQazYoZwnU/g6dOjf2P3YfJXYe59
MgQnsz+17KCJWi5wN4JqS9Cij7oQigApsDVTORmhe/WECDb38Pr82fmUK5G1
Xq5qhNq1qpaUAJNcO/Af3EHoRSOr5Nu2LTzCkgsrhijdiX2rEwFaISmAS6vT
1EtlfakFKqXOZ3KgzsIhJHaPcE3R42I+Fvg0CZxqbUqNuIrARLWig16QS71T
qjxUzQk8ZCM3/m0g0ZHyR+GBHNaZxJAdhL11Djk7+1BkuJjHo3tEFote0nHC
IYt58n8ApTzVn45ULa8W3zaP7+PJML71puuxgyjn8smWjrjRh5ZIlGIygPkZ
kgD8duo1MJJtBVNKQyWfb4D0TAY8GHxLE87RSYE3VFPFdoqtAXAY0OSXLaoJ
Z+6DqF3h434fl/8fVeCnVoHRiqFWeUu1ymC1+Od+1GgVfE1OjcahZNZDdhcj
o1iDRjlgkbFd2wxS0XhrXKLpdEN9gWff3dRyrvYG8ba70AjTuVLtOHg145sy
gHEvb5jQEPA2qszZBRpsxiX6xwAtITkyo+Awm3VFPZvhQsA0OTDUR60yI5Ie
dovnGCDsdg7PXDtK8tUP5cjh+mgszpHIqN6A+lBBku5bLi2g9nUY6YZscoR1
pxNJc0CHZ1qtTj82+X0P2oqHEvvC2FaSurj3yegjSMq5qsVWZUNW/1zhzMv+
7iic9HxiMPQx4yYOs3gOwV3xzGwRdXheczBL4228QjOXoug5h1AmgkfjKifB
vP0KqNmVvFVOj9xY8b0Nf9gqeqefEJh/RHeTXps7GaA7YskdqcgBJYJhMfr7
dnM3G8CJUUXtaQIisFfcLq9hmX6F7Y7l1MZ1y6nyBIttA3ovvDv6CE0y6Xrt
s9kLVWI1RsbpDzkcr3zC0WjL846o4tsjvD2npBoNBIZhP3U8mPu6FKN1kuQS
i296RvXX35ZYuGVTbzkHEgsFVifuxGts9xcPHz8S74PZX8Na3UASv+P4+a14
3AL2tV1+8zjOR0gcY3gccL0VpUeQVpCsAS42tc9fA/1AttNYpCwKigxjQVmh
xJrNmsDMOaFVGWQc/DcnxaHTaxYsLSAPT6dYnk0XA8mwG7IiH42cvcZm5FIM
H0daWu2piLCXEw/NbHw84RuSukf/mrQUj7oEcogmGmU3Qe7HBx2hL+IL9sPY
HbyEWWJtIbtbMM74bVPNBq9gQY6ou/WO7+5Q9eoRC0f40PbWQ9oh7+WWZ1/b
QzW3VRzuyGe99lXhujWHdnZVJ24EesMVsCVDjWvuvOGaw4cJ0WmXKYt9OAqG
Gd1g1o85l018vzuK7gNQOYltXuR7Z+j6BlHfmh2XiHT6wljsNUg84TFKc0dA
PHenbjCdTovoEpR0Iavb5uW7XQAa+cZout1DbfgdbePbrdSt25UxMXd3tF4a
X3AYJa6nGhIGzHk9oPL+qC5PWYzyRCTTlDBNwtPkO2woJJdjk9CagDJXhdn5
u0pOFCozdg9JzXoUk42HyGCsIVlbUpAoCjrWBYODHMj3YPFOkMNm8GQQNB63
08kv5joZ1E98KS0X3N8uDDhb4sxrLF6ElSktcSdVtdmkBRTThcspxuKk3A8Q
GCWT860usNYugEcvNaCrhESnAAKg9i50+ZFcqd1bJKKx2VnxJDeSL2IcMeU6
E9eksJb59nTeTp4c8T798YjpeeIbYuM4z8KKfhqj8NkzzknQcoLRum6+y7Di
vJPnRo9cIorixqk8JQYUnhGdjPcBpj25CyWclrWcNBqN5+w0wp2JyYJPcbEF
pH1E8RuI1vF/KwVkv2gk6eMX+0xQSSfp6nVgfBhYqeymuZaw6rRe0DrDaVHZ
RISgz7E4W2AqyCfkHnKt/kU14T0M5oOhUsl6lThMZWq+sNz6j7PKOR0fYtv+
AOVNAOMSuhu/fG7UVRLH4I4WKDawiuJkj+ueJrLhWLcCJONySWFrsPP9uyZ8
XW/7vTpJyG57HD5pDQEhtEfAg071vzDtEfikm6gcShA/nBzS5eE9Z4d0pWwh
M+Wbf/dKDV3pmrNcWb0jr9vRoE0MpDrjDh+fJWVs1Jt6n3dadrXdx5V9SPZN
k8rhh88e8cVkEnVbQAU4JUrxuKT2IxuEAR/unjOO79HMGkpX+1UC9vedjJxo
m7aHO2Hxy2M+F5KI2azbzkKU8NDY6mpSikpcYsMyVCYseI5/zyhFagc+Tps+
Z+RrdxjaVxb6EZCaBNQaoNzIT+tkSjgRQDyP8q3a8LwGCd+y+X88RDXMNtdy
P9JJIJp9IwFPTf+/9hGwPe674y6la8qFbspw+PDPs3goQPULr157oesIrrHX
qZIwwyzjVqUP4BG/GMNL04q+eEItq9heiGqpiyYsBi9wV7q4KX/SnGjXkcGD
FTQ2OoqLAfpkgBqXufKLuy2Hl9LeOw9et+WqARcigN2BbBR5kat/wgXQ5pIA
xtz2eXzgc4ABVoTbjBgIl1DvHbEd9n+ukN1v6+OBz4Em/+B5BoxvnvPwBuqu
HWjA/9tTuvbb2qcDLu2ZnZchGJzUDDOu7mRde8nzBaZw22fpSpLYGm3SuU/e
L0ixqocVdmDiPlR4tTlLJBA5aMAuHoT7TO2Q4B//ERX+iAp/RIXQBPZ39uKD
Y/wmwPLnByHXpuuhIMwGg3uRw526wXMNflvLNfUbuSzrm+5haOVlD53phsU/
iGmP73Wa6SDLBhdtIdaAlfZBayyuDlYhvVIBF2m+nnj6meJy60jS+8knxmhc
Jw7TvzVGu/sGhzH6XjE6Kri4rEqH6q5PjdUDV8o+s9V9OJJ26i6Vv224Gqq/
Ph5yo2Nm/ogTb16D+LzYog3Gzo/5GytTNmcwrgcfzC25nwPT84iAVnmKltk3
S4jvwHwVvmYavMjizaf1JWpzxTa6udCm2/d/GtLpOwZ3EzeJghFioHWH6U4K
OmfJRSCqkewifHBLH81R9Mi2hayiWIrXPoETXOC0das0ScKLznXT3sfQ1CAP
908/9Llq795pc37R2eTuyHeKk8S1t0OH/Hek5wzvA+X8jVX8qa/m2wPu8+5e
i38UcpEEPxWmXGQNuEDYAE6NmNTp72ND31+hC1+gJANr060JujXtVyiUvEGo
oTylmYFfSlXGWrSWNd0gl/Ni73Fzp+YTOqzYmarIR4KGppY+DqpkdkPHN5AP
LOAHfkgJxNPtKkQ55Ml9Zullzx+tC4jtmvNV3UguCazTAdoA56T5s5PXJz2j
gxz4R2xf/oDtS/Hm8sx9o+8+pXOdIL44QlCOt2NE0/HEKfjx0uWZsNvFQr+b
in/9/R9xG/Rff/9nkpyuJLBJMq5MUahqKs6eX38HM69aG/kPTR/aR1M2gxYh
yf8AGB3Z00ZFAAA=

-->

</rfc>
