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

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-privacypass-architecture-16"
number="9576"
category="info"
tocInclude="true"
submissionType="IETF"
consensus="true"
obsoletes=""
updates=""
sortRefs="true"
symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.10 -->
version="3"
xml:lang="en">

  <front>
    <title abbrev="Privacy Pass Architecture">The Privacy Pass Architecture</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-architecture-16"/> name="RFC" value="9576"/>
    <author initials="A." surname="Davidson" fullname="Alex Davidson">
      <organization>LIP</organization>
      <organization>NOVA LINCS, Universidade NOVA de Lisboa</organization>
      <address>
        <postal>
          <city>Lisbon</city>
          <street>Largo da Torre</street>
          <city>Caparica</city>
          <country>Portugal</country>
        </postal>
        <email>alex.davidson92@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Iyengar" fullname="Jana Iyengar">
      <organization>Fastly</organization>
      <address>
        <email>jri@fastly.com</email>
      </address>
    </author>
    <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94107</code>
          <country>United States of America</country>
        </postal>
        <email>caw@heapingbits.net</email>
      </address>
    </author>

    <date year="2023" month="September" day="25"/>
    <keyword>Internet-Draft</keyword> year="2024" month="June"/>

    <area>sec</area>
    <workgroup>privacypass</workgroup>

    <abstract>
      <t>This document specifies the Privacy Pass architecture and requirements for
its constituent protocols used for authorization based on privacy-preserving
authentication mechanisms. It describes the conceptual model of Privacy Pass
and its protocols, its security and privacy goals, practical deployment models,
and recommendations for each deployment model that helps model, to help ensure that the desired
security and privacy goals are fulfilled.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Privacy Pass is an architecture for authorization based on privacy-preserving
authentication mechanisms. In other words, relying parties authenticate clients Clients
in a privacy-preserving way, i.e., without learning any unique, per-client per-Client
information through the authentication protocol, and then make authorization
decisions on the basis of that authentication succeeding or failing. Possible
authorization decisions might be to provide clients Clients with read access to a
particular resource or write access to a particular resource.</t>
      <t>Typical approaches for authorizing clients, Clients, such as through the use of long-term
state (cookies), are not privacy-friendly privacy friendly, since they allow servers to track
clients
Clients across sessions and interactions. Privacy Pass takes a different
approach: instead of presenting linkable state-carrying information to servers,
e.g., a cookie indicating whether or not the client Client is an authorized user or
has completed some prior challenge, clients Clients present unlinkable proofs that
attest to this information. These proofs, or tokens, are private in the sense
that a given token cannot be linked to the protocol interaction where that
token was initially issued.</t>
      <t>At a high level, the Privacy Pass architecture consists of two protocols:
redemption and issuance. The redemption protocol, described in
<xref target="AUTHSCHEME"/>, target="RFC9577"/>, runs between Clients and
Origins (servers). It allows Origins to challenge Clients to present tokens
for consumption. Origins verify the token to authenticate the Client -- without
learning any specific information about the Client -- and then make an authorization
decision on the basis of the token verifying successfully or not. Depending
on the type of token, e.g., whether or not it can be cached, the Client
either presents a previously obtained token or invokes an issuance protocol,
such as
e.g., the protocols described in <xref target="ISSUANCE"/>, target="RFC9578"/>, to acquire a token to
present as authorization.</t>
      <t>This document describes requirements for both redemption and issuance
protocols and how they interact. It also provides recommendations on how
the architecture should be deployed to ensure the privacy of clients Clients and
the security of all participating entities.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<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>
      <t>The following terms are used throughout this document:</t>
      <dl>
        <dt>Client:</dt>
        <dd>
          <t>An entity that seeks authorization to an Origin. Using terminology from <xref target="RFC9334"/> terminology, target="RFC9334"/>,
Clients implement the RATS Remote ATtestation procedureS (RATS) Attester role.</t>
        </dd>
        <dt>Token:</dt>
        <dd>
          <t>A cryptographic authentication message used for authorization decisions,
produced as output from an issuance mechanism or protocol.</t>
        </dd>
        <dt>Origin:</dt>
        <dd>
          <t>An entity that consumes tokens presented by Clients and uses them to make authorization decisions.</t>
        </dd>
        <dt>Token challenge:</dt>
        <dd>
          <t>The mechanism by which Origins request tokens from Clients, often denoted TokenChallenge.</t>
        </dd>
        <dt>Token request:</dt>
        <dd>
          <t>A message used by Clients to request a token from an Issuer, often denoted TokenRequest.</t>
        </dd>
        <dt>Token response:</dt>
        <dd>
          <t>A message used by Issuers to send tokens to a Client, often denoted TokenResponse.</t>
        </dd>
        <dt>Redemption:</dt>
        <dd>
          <t>The mechanism by which Clients present tokens to Origins for the
purposes of authorization.</t>
        </dd>
        <dt>Issuer:</dt>
        <dd>
          <t>An entity that issues tokens to Clients for properties
attested to by the Attester.</t>
        </dd>
        <dt>Issuance:</dt>
        <dd>
          <t>The mechanism by which an Issuer produces tokens for Clients.</t>
        </dd>
        <dt>Attester:</dt>
        <dd>
          <t>An entity that attests to properties of Clients for the
purposes of token issuance. Using terminology from <xref target="RFC9334"/> terminology, target="RFC9334"/>, Attesters implement the RATS Verifier role.</t>
        </dd>
        <dt>Attestation procedure:</dt>
        <dd>
          <t>The procedure by which an Attester determines whether or not a Client
has the specific set of properties that are necessary for token issuance.</t>
        </dd>
      </dl>
      <t>The trust relationships between each of the entities in this list is are further
elaborated upon in <xref target="privacy-and-trust"/>.</t>
    </section>
    <section anchor="architecture">
      <name>Architecture</name>
      <t>The Privacy Pass architecture consists of four logical entities --
Client, Origin, Issuer, and Attester -- that work in concert
for token redemption and issuance. This section presents an overview
of Privacy Pass, a high-level description of the threat model and
privacy goals of the architecture, and the goals and requirements of
the redemption and issuance protocols. Deployment variations for the
Origin, Issuer, and Attester in this architecture, including
considerations for implementing these entities, are further discussed
in <xref target="deployment"/>.</t>
      <section anchor="overview">
        <name>Overview</name>
        <t>This section describes the typical interaction flow for Privacy Pass.</t> Pass, as shown in <xref target="fig-overview"/>.</t>
        <ol spacing="normal" type="1"><li>A Client interacts with an Origin by sending a request or otherwise
interacting with the Origin in a way that triggers a response containing
a token challenge. The token challenge indicates a specific Issuer to use.</li>
          <li>If the Client already has a token available that satisfies the token
challenge, e.g., because the Client has a cache of previously issued tokens,
it can skip to <xref format="none" target="step-redemption">step 6</xref> and redeem its
token; see <xref target="hoarding"/> for security considerations of regarding cached tokens.</li>
          <li>If the Client does not have a token available and decides it wants to
obtain one (or more) bound to the token challenge, it then invokes the
issuance protocol. As a prerequisite to the issuance protocol, the Client
runs the deployment-specific attestation process that is required for the
designated Issuer. Client attestation can be done via proof of solving a
CAPTCHA, checking device or hardware attestation validity, etc.; see
<xref target="attester"/> for more details.</li>
          <li>If the attestation process completes successfully, the client Client creates a
token request to send to the designated Issuer (generally via the Attester,
though it is not required to be sent through the Attester).
The Attester and Issuer might be functions on the same server, depending on the
deployment model (see <xref target="deployment"/>). Depending on the attestation process, it
is possible for attestation to run alongside the issuance protocol, e.g., where
Clients send necessary attestation information to the Attester along with their
token request. If the attestation process fails, the Client receives an error
and issuance aborts without a token.</li>
          <li>The Issuer generates a token response based on the token request, which
is returned to the Client (generally via the Attester). Upon receiving the
token response, the Client computes a token from the token challenge and token
response. This token can be validated by anyone with the per-Issuer key, key but
cannot be linked to the content of the token request or token response.</li>
          <li>
            <t anchor="step-redemption">If the Client has a token, it includes it in a subsequent request to
the Origin, as authorization. This token is sent only once in reaction to a
challenge; Clients do not send tokens more than once, even if they receive
duplicate or redundant challenges. The Origin
validates that the token was generated by the expected Issuer and has not
already been redeemed for the corresponding token challenge.  If the Client
does not have a token, perhaps because issuance failed, the client Client does not
reply to the Origin's challenge with a new request.</t>
          </li>
        </ol>

        <figure anchor="fig-overview">
          <name>Privacy pass redemption Pass Redemption and issuance protocol interaction</name> Issuance Protocol Interaction</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224" width="520" viewBox="0 0 520 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
                <path d="M 40,64 L 40,208" fill="none" stroke="black"/>
                <path d="M 80,32 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,32 L 184,64" fill="none" stroke="black"/>
                <path d="M 216,64 L 216,208" fill="none" stroke="black"/>
                <path d="M 256,32 L 256,64" fill="none" stroke="black"/>
                <path d="M 336,32 L 336,64" fill="none" stroke="black"/>
                <path d="M 376,64 L 376,144" fill="none" stroke="black"/>
                <path d="M 376,192 L 376,208" fill="none" stroke="black"/>
                <path d="M 424,32 L 424,64" fill="none" stroke="black"/>
                <path d="M 440,32 L 440,64" fill="none" stroke="black"/>
                <path d="M 472,64 L 472,208" fill="none" stroke="black"/>
                <path d="M 512,32 L 512,64" fill="none" stroke="black"/>
                <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 256,32" fill="none" stroke="black"/>
                <path d="M 336,32 L 424,32" fill="none" stroke="black"/>
                <path d="M 440,32 L 512,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,64 L 256,64" fill="none" stroke="black"/>
                <path d="M 336,64 L 424,64" fill="none" stroke="black"/>
                <path d="M 440,64 L 512,64" fill="none" stroke="black"/>
                <path d="M 48,96 L 88,96" fill="none" stroke="black"/>
                <path d="M 168,96 L 216,96" fill="none" stroke="black"/>
                <path d="M 40,112 L 56,112" fill="none" stroke="black"/>
                <path d="M 192,112 L 208,112" fill="none" stroke="black"/>
                <path d="M 224,126 L 240,126" fill="none" stroke="black"/>
                <path d="M 224,130 L 240,130" fill="none" stroke="black"/>
                <path d="M 352,126 L 368,126" fill="none" stroke="black"/>
                <path d="M 352,130 L 368,130" fill="none" stroke="black"/>
                <path d="M 216,160 L 288,160" fill="none" stroke="black"/>
                <path d="M 408,160 L 464,160" fill="none" stroke="black"/>
                <path d="M 224,176 L 288,176" fill="none" stroke="black"/>
                <path d="M 416,176 L 472,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 64,192" fill="none" stroke="black"/>
                <path d="M 192,192 L 216,192" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="472,160 460,154.4 460,165.6" fill="black" transform="rotate(0,464,160)"/>
                <polygon class="arrowhead" points="376,128 364,122.4 364,133.6" fill="black" transform="rotate(0,368,128)"/>
                <polygon class="arrowhead" points="232,176 220,170.4 220,181.6" fill="black" transform="rotate(180,224,176)"/>
                <polygon class="arrowhead" points="232,128 220,122.4 220,133.6" fill="black" transform="rotate(180,224,128)"/>
                <polygon class="arrowhead" points="216,112 204,106.4 204,117.6" fill="black" transform="rotate(0,208,112)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,96 44,90.4 44,101.6" fill="black" transform="rotate(180,48,96)"/>
                <g class="text">
                  <text x="44" y="52">Origin</text>
                  <text x="220" y="52">Client</text>
                  <text x="380" y="52">Attester</text>
                  <text x="476" y="52">Issuer</text>
                  <text x="128" y="100">Request</text>
                  <text x="124" y="116">TokenChallenge</text>
                  <text x="296" y="132">Attestation</text>
                  <text x="348" y="164">TokenRequest</text>
                  <text x="352" y="180">TokenResponse</text>
                  <text x="128" y="196">Request+Token</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+--------+            +--------+         +----------+ +--------+
| Origin |            | Client |         | Attester | | Issuer |
+---+----+            +---+----+         +----+-----+ +---+----+
    |                     |                   |           |
    |<----- Request ------+                   |           |
    +-- TokenChallenge -->|                   |           |
    |                     |<== Attestation ==>|           |
    |                     |                   |           |
    |                     +--------- TokenRequest ------->|
    |                     |<-------- TokenResponse -------+
    |<-- Request+Token ---+                   |           |
    |                     |                   |           |
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="use-cases">
        <name>Use Cases</name>
        <t>Use cases for Privacy Pass are broad and depend greatly on the deployment model
as discussed in <xref target="deployment"/>. The initial motivating use case for Privacy Pass
<xref target="PrivacyPassCloudflare"/> was to help rate-limit malicious or otherwise abusive
traffic from services such as Tor <xref target="DMS2004"/>. The generalized and evolved
architecture described in this document also work works for this use case. However,
for added clarity, some more possible use cases are described below.</t>
        <ul spacing="normal">
          <li>Low-quality, anti-fraud signal for open Internet services. Tokens can attest that
the Client behind the user agent is likely not a bot attempting to perform some
form of automated attack such as credential stuffing. Example attestation procedures
for this use case might be solving some form of CAPTCHA or presenting evidence of a
valid, unlocked device in good standing.</li>
          <li>Privacy-preserving authentication for proprietary services. Tokens can attest that
the Client is a valid subscriber for a proprietary service, such as a deployment of
Oblivious HTTP <xref target="OHTTP"/>.</li> target="RFC9458"/>.</li>
        </ul>
      </section>
      <section anchor="privacy-and-trust">
        <name>Privacy Goals and Threat Model</name>
        <t>The end-to-end flow for Privacy Pass described in <xref target="overview"/> involves three
different types of contexts:</t>
        <dl>
          <dt>Redemption context:</dt>
          <dd>
            <t>The interactions and set of information shared
between the Client and Origin, i.e., the information that is provided or
otherwise available to the Origin during redemption that might be used
to identify a Client and construct a token challenge. This context includes all
information associated with redemption, such as the timestamp of the event,
Client-visible information (including the IP address), and the Origin name.</t>
          </dd>
          <dt>Issuance context:</dt>
          <dd>
            <t>The interactions and set of information shared between the Client, Attester,
and Issuer, i.e., the information that is provided or otherwise available
to the Attester and Issuer during issuance that might be used to identify a Client.
This context includes all information associated with issuance, such as the
timestamp of the event, any Client-visible information (including the IP
address), and the Origin name (if revealed during issuance). This does not
include the token challenge in its entirety, as that is kept secret from the
Issuer during the issuance protocol.</t>
          </dd>
          <dt>Attestation context:</dt>
          <dd>
            <t>The interactions and set of information shared between
the Client and Attester only, for the purposes of attesting the validity of
the Client, that is provided or otherwise available during attestation that
might be used to identify the Client. This context includes all information
associated with attestation, such as the timestamp of the event and any
Client-visible information, including information needed for the attestation
procedure to complete.</t>
          </dd>
        </dl>
        <t>The privacy goals of Privacy Pass assume a threat model in which Origins trust
specific Issuers to produce tokens, and Issuers in turn trust one or more
Attesters to correctly run the attestation procedure with Clients. This
arrangement ensures that tokens which that validate for a given Issuer were only
issued to a Client that successfully completed attestation with an Attester
that the Issuer trusts. Moreover, this arrangement means that if an Origin
accepts tokens issued by an Issuer that trusts multiple Attesters, then a
Client can use any one of these Attesters to issue and redeem tokens for the
Origin. Whether or not these different entities in the architecture collude
for learning redemption, issuance, or attestation contexts, as well as the
necessary preconditions for context unlinkability, depends on the deployment
model; see <xref target="deployment"/> for more details.</t>
        <t>The mechanisms for establishing trust between each entity in this arrangement
are deployment-specific. deployment specific. For example, in settings where Clients interact with
Issuers through an Attester, Attesters and Issuers might use
mutually authenticated TLS to authenticate one another. In settings where
Clients do not communicate with Issuers through an Attester, the Attesters
might convey this trust via a digital signature that Issuers can verify.</t>
        <t>Clients explicitly trust Attesters to perform attestation correctly and in a
way that does not violate their privacy. In particular, this means that Attesters
which
that may be privy to private information about Clients are trusted to not disclose
this information to non-colluding parties. Colluding parties are assumed to have
access to the same information; see <xref target="deployment"/> for more about different
deployment models and non-collusion assumptions. However, Clients assume that Issuers and
Origins are malicious.</t>
        <t>Given this threat model, the privacy goals of Privacy Pass are oriented around
unlinkability based on redemption, issuance, and attestation contexts, as
described below.</t>
        <ol spacing="normal" type="1"><li>Origin-Client unlinkability. This means that given two redemption contexts,
the Origin cannot determine if both redemption contexts correspond to the same
Client or two different Clients. Informally, this means that a Client in a
redemption context is indistinguishable from any other Client that might use
the same redemption context. The set of Clients that share the same redemption
context is referred to as a redemption anonymity set.</li>
          <li>Issuer-Client unlinkability. This is similar to Origin-Client unlinkability
in that a Client in an issuance context is indistinguishable from any other
Client that might use the same issuance context. The set of Clients that share
the same issuance context is referred to as an issuance anonymity set.</li>
          <li>Attester-Origin unlinkability. This is similar to Origin-Client and
Issuer-Client unlinkability. It means that given two attestation contexts,
the Attester cannot determine if both contexts correspond to the same Origin
or two different Origins. The set of Origins that share the same attestation
context is referred to as an attestation anonymity set.</li>
          <li>Redemption context unlinkability. Given two redemption contexts, the Origin
cannot determine which issuance and attestation contexts each redemption
corresponds to, even with the collaboration of the Issuer and Attester (should
these be different parties). This means that any information that may be learned
about the Client during the issuance and attestation flows cannot be used by the
Origin to compromise Client privacy.</li>
        </ol>
        <t>These unlinkability properties ensure that only the Client is Clients are able to correlate
information that might be used to identify them with activity on the Origin.
The Attester, Issuer, and Origin only receive the information necessary to perform
their respective functions.</t>
        <t>The manner in which these unlinkability properties are achieved depends on the
deployment model, type of attestation, and issuance protocol details. For example,
as discussed in <xref target="deployment"/>, in some cases it is necessary to use an anonymization
service that hides Client IP addresses, such as Tor <xref target="DMS2004"/> which hides Clients IP addresses. target="DMS2004"/>. In general,
anonymization services ensures ensure that all Clients which that use the service are indistinguishable
from one another, though in practice there may be small distinguishing features
(TLS fingerprints, HTTP headers, etc). etc.). Moreover, Clients generally trust these services
to not disclose private Client information (such as IP addresses) to untrusted parties.
Failure to use an anonymization service when interacting with Attesters, Issuers, or
Origins can allow the set of possible Clients to be partitioned by the Client's IP address, address
and can therefore lead to unlinkability violations. Similarly, malicious Origins
may attempt to link two redemption contexts together by using Client-specific
Issuer public keys. Public Keys. See <xref target="deployment-considerations"/> Sections&nbsp;<xref target="deployment-considerations" format="counter"/> and <xref target="privacy"/> target="privacy" format="counter"/> for more
information.</t>
        <t>The remainder of this section describes
        <t>Sections <xref target="redemption" format="counter"/> and <xref target="issuance-protocol" format="counter"/> describe the functional properties and security
requirements of the redemption and issuance protocols in more detail. <xref target="flow"/>
describes how information flows between the Issuer, Origin, Client, and Attester
through these protocols.</t>
      </section>
      <section anchor="redemption">
        <name>Redemption Protocol</name>
        <t>The Privacy Pass redemption protocol, described in
<xref target="AUTHSCHEME"/>, target="RFC9577"/>, is an authorization protocol
wherein Clients present tokens to Origins for authorization. Normally,
redemption is preceded by a challenge, wherein the Origin challenges
Clients for a token with a TokenChallenge (<xref section="2.1" sectionFormat="comma" target="AUTHSCHEME"/>) target="RFC9577"/>) and,
if possible, Clients present a valid Token token (<xref section="2.2" sectionFormat="comma" target="AUTHSCHEME"/>) target="RFC9577"/>)
in reaction to the challenge. This interaction is shown below.</t>

        <figure anchor="fig-redemption">
          <name>Challenge and redemption protocol interaction</name> Redemption Protocol Interaction</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="432" viewBox="0 0 432 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
                <path d="M 40,64 L 40,160" fill="none" stroke="black"/>
                <path d="M 80,32 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,32 L 184,64" fill="none" stroke="black"/>
                <path d="M 216,64 L 216,160" fill="none" stroke="black"/>
                <path d="M 256,32 L 256,64" fill="none" stroke="black"/>
                <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 256,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,64 L 256,64" fill="none" stroke="black"/>
                <path d="M 48,96 L 88,96" fill="none" stroke="black"/>
                <path d="M 168,96 L 216,96" fill="none" stroke="black"/>
                <path d="M 40,112 L 56,112" fill="none" stroke="black"/>
                <path d="M 192,112 L 208,112" fill="none" stroke="black"/>
                <path d="M 232,126 L 248,126" fill="none" stroke="black"/>
                <path d="M 232,130 L 248,130" fill="none" stroke="black"/>
                <path d="M 408,126 L 424,126" fill="none" stroke="black"/>
                <path d="M 408,130 L 424,130" fill="none" stroke="black"/>
                <path d="M 48,144 L 64,144" fill="none" stroke="black"/>
                <path d="M 192,144 L 216,144" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="432,128 420,122.4 420,133.6" fill="black" transform="rotate(0,424,128)"/>
                <polygon class="arrowhead" points="240,128 228,122.4 228,133.6" fill="black" transform="rotate(180,232,128)"/>
                <polygon class="arrowhead" points="216,112 204,106.4 204,117.6" fill="black" transform="rotate(0,208,112)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,96 44,90.4 44,101.6" fill="black" transform="rotate(180,48,96)"/>
                <g class="text">
                  <text x="44" y="52">Origin</text>
                  <text x="220" y="52">Client</text>
                  <text x="128" y="100">Request</text>
                  <text x="124" y="116">TokenChallenge</text>
                  <text x="292" y="132">Issuance</text>
                  <text x="364" y="132">protocol</text>
                  <text x="128" y="148">Request+Token</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+--------+            +--------+
| Origin |            | Client |
+---+----+            +---+----+
    |                     |
    |<----- Request ------+
    +-- TokenChallenge -->|
    |                     | <== Issuance protocol ==>
    |<-- Request+Token ---+
    |                     |
]]></artwork>
          </artset>
        </figure>
        <t>Alternatively, when configured to do so, Clients may opportunistically present
Token
token values to Origins without a corresponding TokenChallenge.</t>
        <t>The structure and semantics of the TokenChallenge and Token token messages depend
on the issuance protocol and token type being used; see <xref target="AUTHSCHEME"/> target="RFC9577"/> for
more information.</t>
        <t>The challenge provides the client Client with the information necessary to obtain
tokens that the server might subsequently accept in the redemption context.
There are a number of ways in which the token may vary based on this challenge,
including:</t>
including the following:</t>
        <ul spacing="normal">
          <li>Issuance protocol. The challenge identifies the type of issuance protocol
required for producing the token. Different issuance protocols have different
security properties, e.g., some issuance protocols may produce tokens that
are publicly verifiable, whereas others may not have this property.</li>
          <li>Issuer identity. Token challenges identify which Issuers are trusted for a
given issuance protocol. As described in <xref target="privacy-and-trust"/>, the choice
of Issuer determines the type of Attesters and attestation procedures possible
for a token from the specified Issuer, but the Origin does not learn exactly
which Attester was used for a given token issuance event.</li>
          <li>Redemption context. Challenges can be bound to a given redemption context,
which influences a client's Client's ability to pre-fetch and cache tokens. For
example, an empty redemption context always allows tokens to be issued and
redeemed non-interactively, whereas a fresh and random redemption context
means that the redeemed token must be issued only after the client Client receives
the challenge. See <xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> target="RFC9577"/> for more details.</li>
          <li>Per-Origin or cross-Origin. Challenges can be constrained to the Origin for
which the challenge originated (referred to as per-Origin tokens), tokens) or
can be used across multiple Origins (referred to as cross-Origin tokens).
The set of Origins for which a cross-Origin token is applicable is referred
to as the cross-Origin set. Opting into this set is done by explicitly agreeing
on the contents of the set. Every Origin in a cross-Origin set, by opting in,
agrees to admit tokens for any other Origin in the set. See
<xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> target="RFC9577"/> for more information on how this set is created.</li>
        </ul>
        <t>Origins that admit cross-Origin tokens bear some risk of allowing tokens
issued for one Origin to be spent in an interaction with another Origin.
In particular, cross-Origin tokens issued based on a challenge for
one Origin can be redeemed at another Origin in the cross-Origin set,
which can make it difficult to regulate token consumption. Depending on the
use case, Origins may need to maintain state to track redeemed tokens. For
example, Origins that accept cross-Origin tokens across shared redemption
contexts SHOULD <bcp14>SHOULD</bcp14> track which tokens have already been redeemed already in those
redemption contexts, since these tokens can be issued and then spent multiple
times for any such challenge. Note that Clients which that redeem the
same token to multiple Origins do risk those Origins being able to link
Client activity together, which can disincentivize this behavior. See
<xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> target="RFC9577"/> for discussion.</t>
        <t>How Clients respond to token challenges can have privacy implications.
For example, if an Origin allows the Client to choose an Issuer, then the choice
of Issuer can reveal information about the Client used to partition anonymity
sets; see <xref target="rotation-and-consistency"/> for more information about these privacy
considerations.</t>
      </section>
      <section anchor="issuance-protocol">
        <name>Issuance Protocol</name>
        <t>The Privacy Pass issuance protocol, protocols, such as those described in <xref target="ISSUANCE"/>, is a target="RFC9578"/>, are two-message
protocol
protocols that takes take as input a TokenChallenge from the redemption protocol
(<xref section="2.1" sectionFormat="comma" target="AUTHSCHEME"/>) target="RFC9577"/>) and produces produce a Token token
(<xref section="2.2" sectionFormat="comma" target="AUTHSCHEME"/>), target="RFC9577"/>), as shown in <xref target="fig-overview"/>.</t>
        <t>The structure and semantics of the TokenRequest and TokenResponse messages
depend on the issuance protocol and token type being used; see <xref target="ISSUANCE"/> target="RFC9578"/>
for more information.</t>
        <t>Clients interact with the Attester and Issuer to produce a token for
a challenge. The context in which an Attester vouches for a Client during
issuance is referred to as the attestation context. This context includes all
information associated with the issuance event, such as the timestamp of the
event and Client-visible information, including the IP address or other
information specific to the type of attestation done.</t>
        <t>Each issuance protocol may be different, e.g., in the number and types of
participants, underlying cryptographic constructions used when issuing tokens,
and even privacy properties.</t>
        <t>Clients initiate the issuance protocol using the token challenge, a randomly
generated nonce, and a public key for the Issuer, all of which are the Client's
private input to the protocol and ultimately bound to an output Token; token;
see <xref section="2.2" sectionFormat="of" target="AUTHSCHEME"/> target="RFC9577"/> for details. Future specifications
may change or extend the Client's input to the issuance protocol to produce
Tokens
tokens with a different structure.</t>
        <t>Token properties vary based on the issuance protocol. Important properties
supported in this architecture are described below.</t>
        <ol spacing="normal" type="1"><li>Public verifiability. This means that the Token token can be verified using the Issuer
public key.
Public Key. A Token token that does not have public verifiability can only be verified
using the Issuer secret key.</li>
          <li>Public metadata. This means that the Token token can be cryptographically bound to
arbitrary public information. See <xref target="metadata-privacy"/> for privacy considerations
of
regarding public metadata.</li>
          <li>Private metadata. This means that the Token token can be cryptographically bound to
arbitrary private information, i.e., information that the Client does not observe
during Token token issuance or redemption. See <xref target="metadata-privacy"/> for privacy
considerations of regarding private metadata.</li>
        </ol>
        <t>The issuance protocol itself can be any interactive protocol between the Client,
Issuer, or other parties that produces a valid token bound to the Client's
private input, subject to the following security requirements.</t>
        <ol spacing="normal" type="1"><li>Unconditional input secrecy. The issuance protocol MUST NOT <bcp14>MUST NOT</bcp14> reveal anything
about the Client's private input, including the challenge and nonce, to the
Attester or Issuer, regardless of the hardness assumptions of the underlying
cryptographic protocol(s). This property is sometimes also referred to as
blindness.</li>
          <li>One-more forgery security. The issuance protocol MUST NOT <bcp14>MUST NOT</bcp14> allow malicious
Clients or Attesters (acting as Clients) to forge tokens offline or otherwise
without interacting with the Issuer directly.</li>
          <li>Concurrent security. The issuance protocol MUST <bcp14>MUST</bcp14> be safe to run concurrently
with arbitrarily many Clients, Attesters Attesters, and Issuers.</li>
        </ol>
        <t>See <xref target="extensions"/> for requirements on new issuance protocol variants and
related extensions.</t>
        <t>In the sections below, we describe the Attester and Issuer roles in more
detail.</t>
        <section anchor="attester">
          <name>Attester Role</name>
          <t>In Privacy Pass, attestation is the process by which an Attester bears
witness to, confirms, or authenticates a Client so as to verify properties
about the Client that are required for Issuance. issuance. Issuers trust Attesters
to perform attestation correctly, i.e., to implement attestation procedures
in such a way that those procedures are not subverted or bypassed by malicious Clients.</t>
          <t><xref target="RFC9334"/> describes an architecture for attestation procedures. Using
that architecture as a conceptual basis, Clients are RATS attesters Attesters that
produce attestation evidence, and Attesters are RATS verifiers Verifiers that
appraise the validity of attestation evidence.</t>
          <t>The type of attestation procedure is a deployment-specific option and outside
the scope of the issuance protocol. Example attestation procedures are below.</t>
          <ul spacing="normal">
            <li>Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to
have this capability for the purpose of being ruled out as a bot or otherwise
automated Client.</li>
            <li>Presenting evidence of Client device validity. Some Clients run on trusted
hardware that are is capable of producing device-level attestation evidence.</li>
            <li>Proving properties about Client state. Clients can be associated with state state,
and the Attester can verify this state. Examples of state include the
Client's geographic region and whether the Client has a valid
application-layer account.</li>
          </ul>
          <t>Attesters may support different types of attestation procedures.</t>
          <t>Each attestation procedure has different security properties. For
example, attesting to having a valid account is different from attesting to
running on trusted hardware. Supporting multiple attestation procedures is
an important step towards ensuring equitable access for Clients; see <xref target="discrimination"/>.</t>
          <t>The role of the Attester in the issuance protocol and its impact on privacy
depends
depend on the type of attestation procedure, issuance protocol, and deployment
model. For instance, increasing the number of required attestation procedures
could decrease the overall anonymity set size. As an example, the number of Clients
that have solved a CAPTCHA in the past day, that have a valid account, and that
are running on a trusted device is less than the number of Clients that have
solved a CAPTCHA in the past day. See <xref target="rotation-and-consistency"/> for more discussion
of how the variety of attestation procedures can negatively impact Client privacy.</t>
          <t>Depending on the issuance protocol, the Issuer might learn
information about the Origin. To ensure Issuer-Client unlinkability, the Issuer
should be unable to link that information to a specific Client. For such
issuance protocols where the Attester has access to Client-specific
information, such as is the case for attestation procedures that involve
Client-specific information (such as application-layer account information)
or for deployment models where the Attester learns Client-specific information
(such as Client IP addresses), Clients trust the Attester to not share any
Client-specific information with the Issuer. In deployments where the Attester
does not learn Client-specific information, information or where the Attester and Issuer are
operated by the same entity (such as in the Joint Attester and Issuer model
described in <xref target="deploy-joint-issuer"/>), the Client does not need to explicitly
trust the Attester in this regard.</t>
          <t>Issuers trust Attesters to correctly and reliably perform attestation. However,
certain types of attestation procedures can vary in value over time, e.g., if the
attestation procedure is compromised. Broken
attestation procedures are considered exceptional events and require
configuration changes to address the underlying cause. For example, if
an attestation procedure is compromised or subverted because of a zero-day
exploit on devices that implement the attestation procedure, then the
corresponding attestation procedure should be untrusted until the exploit is
patched. Addressing changes in attestation quality is therefore a
deployment-specific task. In Split Attester Origin, Attester, and Issuer deployments (see
<xref target="deploy-split"/>), Issuers can choose to remove compromised Attesters from
their trusted set until the compromise is patched.</t>
          <t>From the perspective of an Origin, tokens produced by an Issuer with at least
one compromised Attester cannot be trusted trusted, assuming that the Origin does not know
which attestation procedure was used for issuance. This is because the Origin
cannot distinguish between tokens that were issued via compromised Attesters
and tokens that were issued via uncompromised Attesters Attesters, absent some
distinguishing information in the tokens themselves or from the Issuer. As a
result, until the attestation procedure is fixed, the Issuer cannot be trusted
by Origins. Moreover, as a consequence, any tokens issued by an Issuer with a
compromised attester Attester may no longer be trusted by Origins, even if those tokens
were issued to Clients interacting with an uncompromised Attester.</t>
        </section>
        <section anchor="issuer-role">
          <name>Issuer Role</name>
          <t>In Privacy Pass, the Issuer is responsible for completing the issuance protocol
for Clients that complete attestation through a trusted Attester. As described
in <xref target="attester"/>, Issuers explicitly trust Attesters to correctly and reliably
perform attestation. Origins explicitly trust Issuers to only issue tokens
from trusted Attesters. Clients do not explicitly trust Issuers.</t>
          <t>Depending on the deployment model case, issuance may require some form of
Client anonymization service, similar to an IP-hiding proxy, so that Issuers
cannot learn information about Clients. This can be provided by an explicit
participant in the issuance protocol, or it can be provided via external means,
such as through the use of an IP-hiding proxy service like Tor <xref target="DMS2004"/>.
In general, Clients SHOULD <bcp14>SHOULD</bcp14> minimize or remove identifying
information where possible when invoking the issuance protocol.</t>
          <t>Issuers are uniquely identifiable by all Clients with a consistent
identifier. In a web context, this identifier might be the Issuer host name. hostname.
Issuers maintain one or more configurations, including issuance key pairs, for
use in the issuance protocol. Each configuration is assumed to have a unique
and canonical identifier, sometimes referred to as a key identifier or key ID.
Issuers can rotate these configurations as needed to mitigate the risk of compromise;
see <xref target="rotation-and-consistency"/> for more considerations around configuration
rotation. The Issuer public key Public Key for each active configuration is made available
to Origins and Clients for use in the issuance and redemption protocols.</t>
        </section>
        <section anchor="metadata">
          <name>Issuance Metadata</name>
          <t>Certain instantiations of the issuance protocol may permit public or private
metadata to be cryptographically bound to a token. As an example, one
trivial way to include public metadata is to assign a unique Issuer
public key
Public Key for each value of metadata, such that N keys yields yield
log<sub>2</sub>(N) bits of metadata. Metadata may be public or private.</t>
          <t>Public metadata is metadata that which clients Clients can observe as part of the token
issuance flow. Public metadata can either be either transparent or opaque. For
example, transparent public metadata is a value that the client either the Client
generates itself, itself or the Issuer provides during the issuance flow and that the client
Client can check for correctness. Opaque public metadata is metadata
the client Client can see but cannot check for correctness. As an example, the
opaque public metadata might be a "fraud detection signal", computed on
behalf of the Issuer, during token issuance. Generally speaking, Clients
cannot determine if this value is generated in a way that permits tracking.</t>
          <t>Private metadata is metadata that which Clients cannot observe as part of the token
issuance flow. Such instantiations can be built on the Private Metadata Bit private metadata bit
construction from Kreuter et al. <xref al.&nbsp;<xref target="KLOR20"/>
or the attribute-based VOPRF Verifiable Oblivious Pseudorandom Function (VOPRF) from Huang et al. <xref al.&nbsp;<xref target="HIJK21"/>.</t>
          <t>Metadata can be arbitrarily long or bounded in length. The amount of permitted
metadata may be determined by an application or by the underlying cryptographic
protocol. The total amount of metadata bits included in a token is the sum of
public and private metadata bits. Every bit of metadata can be used to
partition the Client issuance or redemption anonymity sets; see
<xref target="metadata-privacy"/> for more information.</t>
        </section>
        <section anchor="extensions">
          <name>Future Issuance Protocol Requirements</name>
          <t>The Privacy Pass architecture and ecosystem are both intended to be receptive
to extensions that expand the current set of functionalities through new
issuance protocols. Each new issuance protocol and extension MUST <bcp14>MUST</bcp14> adhere
to the following requirements:</t>
          <ol spacing="normal" type="1"><li>Include a detailed analysis of the privacy impacts of the extension, why
these impacts are justified, and guidelines on how to use the protocol
to mitigate or minimize negative deployment or privacy consequences
discussed in <xref target="deployment-considerations"/> Sections&nbsp;<xref target="deployment-considerations" format="counter"/> and <xref target="privacy"/>, target="privacy" format="counter"/>, respectively.</li>
            <li>Adhere to the guidelines specified in <xref target="issuer-role"/> for managing Issuer
public key
Public Key data.</li>
            <li>Clearly specify how to interpret and validate TokenChallenge and Token token
messages that are exchanged during the redemption protocol.</li>
          </ol>
        </section>
      </section>
      <section anchor="flow">
        <name>Information Flow</name>
        <t>The end-to-end process of redemption and issuance protocols involves information
flowing between the Issuer, Origin, Client, and Attester. That information can
have implications on the privacy goals that Privacy Pass aims to provide
as outlined in <xref target="privacy-and-trust"/>. In this section, we describe the flow
of information between each party. How this information affects the privacy
goals in particular deployment models is further discussed in <xref target="deployment"/>.</t>
        <section anchor="challenge-flow">
          <name>Token Challenge Flow</name>
          <t>To use Privacy Pass, Origins choose an Issuer from which they are willing to
accept tokens. Origins then construct a token challenge using this specified
Issuer and information from the redemption context it shares with the Client.
This token challenge is then delivered to a Client. The token challenge conveys
information about the Issuer and the redemption context, such as whether the
Origin desires a per-Origin or cross-Origin token. Any entity that sees
the token challenge might learn things about the Client as known to the Origin.
This is why input secrecy is a requirement for issuance protocols, as it
ensures that the challenge is not directly available to the Issuer.</t>
        </section>
        <section anchor="attestation-flow">
          <name>Attestation Flow</name>
          <t>Clients interact with the Attester to prove that they meet some required
set of properties. In doing so, Clients contribute information to the
attestation context, which might include sensitive information such as
application-layer identities, IP addresses, and so on. Clients can choose
whether or not to contribute this information based on local policy or
preference.</t>
        </section>
        <section anchor="issue-flow">
          <name>Issuance Flow</name>
          <t>Clients use the issuance protocol to produce a token bound to a token
challenge. In doing so, there are several ways in which the issuance protocol
contributes information to the attestation or issuance contexts. For example, a
token request may contribute information to the attestation or issuance
contexts as described below.</t>
          <ul spacing="normal">
            <li>Issuance protocol. The type of issuance protocol can contribute information
about the Issuer's capabilities to the attestation or issuance contexts, as
well as the capabilities of a given Client. For example, if a Client is
presented with multiple issuance protocol options, then the choice of which
issuance protocol to use can contribute information about the Client's
capabilities.</li>
            <li>Issuer configuration. Information about the Issuer configuration, such as
its identity or the public key used to validate tokens it creates, can be
revealed during issuance and contribute to the attestation or issuance
contexts.</li>
            <li>Attestation information. The issuance protocol can contribute information to
the attestation or issuance contexts based on what attestation procedure the
Issuer uses to trust a token request. In particular, a token request that is
validated by a given Attester means that the Client which that generated the token
request must be capable of the completing the designated attestation procedure.</li>
            <li>Origin information. The issuance protocol can contribute information about
the Origin that challenged the Client in Client; see <xref target="challenge-flow"/>. In particular,
a token request designated for a specific Issuer might imply that the resulting
token is for an Origin that trusts the specified Issuer. However, this is not
always true, as some token requests can correspond to cross-Origin tokens,
i.e., they are tokens that would be accepted at any Origin that accepts the
cross-Origin token.</li>
          </ul>
          <t>Moreover, a token may contribute information to the issuance attestation or
contexts as described below.</t>
          <ul spacing="normal">
            <li>Origin information. The issuance protocol can contribute information about
the Origin in how it responds to a token request. For example, if an Issuer
learns the Origin during issuance and is also configured to respond in some way
on the basis of that information, and the Client interacts with the Issuer
transitively through the Attester, that response can reveal information to the
Attester.</li>
            <li>Token. The token produced by the issuance protocol can contain information
from the issuance context. In particular, depending on the issuance protocol,
tokens can contain public or private metadata, and Issuers can choose that
metadata on the basis of information in the issuance context.</li>
          </ul>
          <t>Exceptional cases in the issuance protocol, such as when either the
Attester or Issuer aborts the protocol, can contribute information to the
attestation or issuance contexts. The extent to which information in this
context harms the Issuer-Client or Attester-Origin unlinkability goals as discussed in
<xref target="privacy-and-trust"/> depends on the deployment model; see <xref target="deployment"/>.
Clients can choose whether or not to contribute information to these contexts
based on local policy or preference.</t>
        </section>
        <section anchor="redemption-flow">
          <name>Token Redemption Flow</name>
          <t>Clients send tokens to Origins during the redemption protocol. Any information
that is added to the token during issuance can therefore be sent to the Origin.
Information can either be explicitly either (1)&nbsp;explicitly passed in a token, token or it can be implicit (2)&nbsp;implicit
in the way the Client responds to a token challenge. For example, if a Client
fails to complete issuance, issuance and consequently fails to redeem a token for
a token challenge, this can reveal information to the Origin that
it might not otherwise have access to. However, an Origin cannot necessarily
distinguish between a Client that fails to complete issuance and one that
ignores the token challenge altogether.</t>
        </section>
      </section>
    </section>
    <section anchor="deployment">
      <name>Deployment Models</name>
      <t>The Origin, Attester, and Issuer portrayed in <xref target="fig-overview"/> can be
instantiated and deployed in a number of ways. The deployment model directly
influences the manner in which attestation, issuance, and redemption contexts
are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin
unlinkability.</t>
      <t>This section covers some expected deployment models and their corresponding
security and privacy considerations. Each deployment model is described in
terms of the trust relationships and communication patterns between the Client,
Attester, Issuer, and Origin. Entities drawn within the same bounding box are
assumed to be operated by the same party and are therefore able to collude.
Collusion can enable linking of attestation, issuance, and redemption contexts.
Entities not drawn within the same bounding box are assumed to not
collude, meaning that entities (i.e., operated by separate parties that do parties) are assumed to not collude. Mechanisms for enforcing non-collusion are out of scope for this architecture.</t>
      <section anchor="deploy-shared">
        <name>Shared Origin, Attester, Issuer</name>
        <t>In this model, the Origin, Attester, and Issuer are all operated by the same
entity, as shown in <xref target="fig-deploy-shared"/>.</t>

        <figure anchor="fig-deploy-shared">
          <name>Shared Deployment Model</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="528" viewBox="0 0 528 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
                <path d="M 80,48 L 80,80" fill="none" stroke="black"/>
                <path d="M 144,32 L 144,80" fill="none" stroke="black"/>
                <path d="M 168,48 L 168,80" fill="none" stroke="black"/>
                <path d="M 216,80 L 216,104" fill="none" stroke="black"/>
                <path d="M 216,120 L 216,160" fill="none" stroke="black"/>
                <path d="M 256,48 L 256,80" fill="none" stroke="black"/>
                <path d="M 304,48 L 304,80" fill="none" stroke="black"/>
                <path d="M 344,80 L 344,96" fill="none" stroke="black"/>
                <path d="M 344,128 L 344,192" fill="none" stroke="black"/>
                <path d="M 376,48 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,48 L 424,80" fill="none" stroke="black"/>
                <path d="M 456,80 L 456,208" fill="none" stroke="black"/>
                <path d="M 496,48 L 496,80" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,80" fill="none" stroke="black"/>
                <path d="M 144,32 L 504,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
                <path d="M 168,48 L 256,48" fill="none" stroke="black"/>
                <path d="M 304,48 L 376,48" fill="none" stroke="black"/>
                <path d="M 424,48 L 496,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
                <path d="M 168,80 L 256,80" fill="none" stroke="black"/>
                <path d="M 304,80 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,80 L 496,80" fill="none" stroke="black"/>
                <path d="M 160,96 L 208,96" fill="none" stroke="black"/>
                <path d="M 224,96 L 336,96" fill="none" stroke="black"/>
                <path d="M 352,96 L 448,96" fill="none" stroke="black"/>
                <path d="M 464,96 L 504,96" fill="none" stroke="black"/>
                <path d="M 48,112 L 304,112" fill="none" stroke="black"/>
                <path d="M 440,112 L 456,112" fill="none" stroke="black"/>
                <path d="M 48,142 L 72,142" fill="none" stroke="black"/>
                <path d="M 48,146 L 72,146" fill="none" stroke="black"/>
                <path d="M 184,142 L 208,142" fill="none" stroke="black"/>
                <path d="M 184,146 L 208,146" fill="none" stroke="black"/>
                <path d="M 40,176 L 128,176" fill="none" stroke="black"/>
                <path d="M 248,176 L 336,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 128,192" fill="none" stroke="black"/>
                <path d="M 256,192 L 344,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 208,224" fill="none" stroke="black"/>
                <path d="M 272,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 504,32 C 512.83064,32 520,39.16936 520,48" fill="none" stroke="black"/>
                <path d="M 160,96 C 151.16936,96 144,88.83064 144,80" fill="none" stroke="black"/>
                <path d="M 504,96 C 512.83064,96 520,88.83064 520,80" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="464,224 452,218.4 452,229.6" fill="black" transform="rotate(0,456,224)"/>
                <polygon class="arrowhead" points="344,176 332,170.4 332,181.6" fill="black" transform="rotate(0,336,176)"/>
                <polygon class="arrowhead" points="216,144 204,138.4 204,149.6" fill="black" transform="rotate(0,208,144)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fill="black" transform="rotate(180,48,112)"/>
                <g class="text">
                  <text x="44" y="68">Client</text>
                  <text x="212" y="68">Attester</text>
                  <text x="340" y="68">Issuer</text>
                  <text x="460" y="68">Origin</text>
                  <text x="372" y="116">TokenChallenge</text>
                  <text x="128" y="148">Attestation</text>
                  <text x="188" y="180">TokenRequest</text>
                  <text x="192" y="196">TokenResponse</text>
                  <text x="240" y="228">Token</text>
                  <text x="456" y="244">|</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
                 +---------------------------------------------.
+--------+       |  +----------+     +--------+     +--------+  |
| Client |       |  | Attester |     | Issuer |     | Origin |  |
+---+----+       |  +-----+----+     +----+---+     +---+----+  |
    |             `-------|---------------|-------------|------'
    |<-------------------------------- TokenChallenge --+
    |                     |               |             |
    |<=== Attestation ===>|               |             |
    |                     |               |             |
    +----------- TokenRequest ----------->|             |
    |<---------- TokenResponse -----------+             |
    |                                                   |
    +--------------------- Token ----------------------->
    |                                                   |
]]></artwork>
          </artset>
        </figure>
        <t>This model represents the initial deployment of Privacy Pass, as described in
<xref target="PrivacyPassCloudflare"/>. In this model, the Attester, Issuer, and Origin
share the attestation, issuance, and redemption contexts. As a result,
attestation mechanisms that can uniquely identify a Client, e.g., requiring
that Clients authenticate with some type of application-layer account, are
not appropriate, as they could lead to unlinkability violations.</t>
        <t>Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that
issuance and redemption events be separated over time, such as through the use
of tokens that correspond to token challenges with an empty redemption context
(see <xref target="redemption"/>), or that they be separated over space, such as through the use of an
anonymizing service when connecting to the Origin.</t>
      </section>
      <section anchor="deploy-joint-issuer">
        <name>Joint Attester and Issuer</name>
        <t>In this model, the Attester and Issuer are operated by the same entity
that is entity,
separate from the Origin. The Origin trusts the joint Attester
and Issuer to perform attestation and issue Tokens. tokens. Clients interact
with the joint Attester and Issuer for attestation and issuance. This
arrangement is shown in <xref target="fig-deploy-joint-issuer"/>.</t>

        <figure anchor="fig-deploy-joint-issuer">
          <name>Joint Attester and Issuer Deployment Model</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="520" viewBox="0 0 520 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
                <path d="M 80,48 L 80,80" fill="none" stroke="black"/>
                <path d="M 160,32 L 160,80" fill="none" stroke="black"/>
                <path d="M 184,48 L 184,80" fill="none" stroke="black"/>
                <path d="M 232,80 L 232,104" fill="none" stroke="black"/>
                <path d="M 232,120 L 232,160" fill="none" stroke="black"/>
                <path d="M 272,48 L 272,80" fill="none" stroke="black"/>
                <path d="M 320,48 L 320,80" fill="none" stroke="black"/>
                <path d="M 360,80 L 360,96" fill="none" stroke="black"/>
                <path d="M 360,128 L 360,192" fill="none" stroke="black"/>
                <path d="M 392,48 L 392,80" fill="none" stroke="black"/>
                <path d="M 416,48 L 416,80" fill="none" stroke="black"/>
                <path d="M 440,48 L 440,80" fill="none" stroke="black"/>
                <path d="M 472,80 L 472,208" fill="none" stroke="black"/>
                <path d="M 512,48 L 512,80" fill="none" stroke="black"/>
                <path d="M 160,32 L 400,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
                <path d="M 184,48 L 272,48" fill="none" stroke="black"/>
                <path d="M 320,48 L 392,48" fill="none" stroke="black"/>
                <path d="M 440,48 L 512,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
                <path d="M 184,80 L 272,80" fill="none" stroke="black"/>
                <path d="M 320,80 L 392,80" fill="none" stroke="black"/>
                <path d="M 440,80 L 512,80" fill="none" stroke="black"/>
                <path d="M 176,96 L 224,96" fill="none" stroke="black"/>
                <path d="M 240,96 L 352,96" fill="none" stroke="black"/>
                <path d="M 368,96 L 400,96" fill="none" stroke="black"/>
                <path d="M 48,112 L 320,112" fill="none" stroke="black"/>
                <path d="M 456,112 L 472,112" fill="none" stroke="black"/>
                <path d="M 48,142 L 80,142" fill="none" stroke="black"/>
                <path d="M 48,146 L 80,146" fill="none" stroke="black"/>
                <path d="M 192,142 L 224,142" fill="none" stroke="black"/>
                <path d="M 192,146 L 224,146" fill="none" stroke="black"/>
                <path d="M 40,176 L 144,176" fill="none" stroke="black"/>
                <path d="M 264,176 L 352,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 136,192" fill="none" stroke="black"/>
                <path d="M 264,192 L 360,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 224,224" fill="none" stroke="black"/>
                <path d="M 288,224 L 472,224" fill="none" stroke="black"/>
                <path d="M 400,32 C 408.83064,32 416,39.16936 416,48" fill="none" stroke="black"/>
                <path d="M 176,96 C 167.16936,96 160,88.83064 160,80" fill="none" stroke="black"/>
                <path d="M 400,96 C 408.83064,96 416,88.83064 416,80" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="480,224 468,218.4 468,229.6" fill="black" transform="rotate(0,472,224)"/>
                <polygon class="arrowhead" points="360,176 348,170.4 348,181.6" fill="black" transform="rotate(0,352,176)"/>
                <polygon class="arrowhead" points="232,144 220,138.4 220,149.6" fill="black" transform="rotate(0,224,144)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fill="black" transform="rotate(180,48,112)"/>
                <g class="text">
                  <text x="44" y="68">Client</text>
                  <text x="228" y="68">Attester</text>
                  <text x="356" y="68">Issuer</text>
                  <text x="476" y="68">Origin</text>
                  <text x="388" y="116">TokenChallenge</text>
                  <text x="136" y="148">Attestation</text>
                  <text x="204" y="180">TokenRequest</text>
                  <text x="200" y="196">TokenResponse</text>
                  <text x="256" y="228">Token</text>
                  <text x="472" y="244">|</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
                   +------------------------------.
+--------+         |  +----------+     +--------+  |  +--------+
| Client |         |  | Attester |     | Issuer |  |  | Origin |
+---+----+         |  +-----+----+     +----+---+  |  +---+----+
    |               `-------|---------------|-----'       |
    |<---------------------------------- TokenChallenge --+
    |                       |               |             |
    |<==== Attestation ====>|               |             |
    |                       |               |             |
    +------------- TokenRequest ----------->|             |
    |<----------- TokenResponse ------------+             |
    |                                                     |
    +----------------------- Token ----------------------->
    |                                                     |
]]></artwork>
          </artset>
        </figure>
        <t>This model is useful if an Origin wants to offload attestation and issuance to
a trusted entity. In this model, the Attester and Issuer share an attestation
and issuance context for the Client, which is separate from the Origin's
redemption context.</t>
        <t>Similar to the Shared shared Origin, Attester, Issuer model, Issuer-Client and
Origin-Client unlinkability in this model requires that issuance and redemption
events, respectively, be separated over time or space. Attester-Origin
unlinkability requires that the Attester and Issuer do not learn the Origin
for a particular token request. For this reason, issuance protocols that
require the Issuer to learn information about the Origin, such as that which
is the issuance protocol described in <xref target="RATE-LIMITED"/>, target="I-D.ietf-privacypass-rate-limit-tokens"/>, are not
appropriate
appropriate, since they could lead to Attester-Origin unlinkability violations
through the Origin name.</t>
      </section>
      <section anchor="deploy-joint-origin">
        <name>Joint Origin and Issuer</name>
        <t>In this model, the Origin and Issuer are operated by the same entity, separate
from the Attester, as shown in the figure below. <xref target="fig-deploy-joint-origin"/>. The Issuer accepts token
requests that come from trusted Attesters. Since the Attester and Issuer are
separate entities, this model requires some mechanism by which Issuers
establish trust in the Attester (as described in <xref target="privacy-and-trust"/>).
For example, in settings where the Attester is a Client-trusted service that
directly communicates with the Issuer, one way to establish this trust is via
mutually-authenticated
mutually authenticated TLS. However, alternative authentication mechanisms are
possible. This arrangement is In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in <xref target="fig-deploy-joint-origin"/>.</t> the figure below.</t>

        <figure anchor="fig-deploy-joint-origin">
          <name>Joint Origin and Issuer Deployment Model</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="528" viewBox="0 0 528 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
                <path d="M 80,48 L 80,80" fill="none" stroke="black"/>
                <path d="M 168,48 L 168,80" fill="none" stroke="black"/>
                <path d="M 216,80 L 216,104" fill="none" stroke="black"/>
                <path d="M 216,120 L 216,160" fill="none" stroke="black"/>
                <path d="M 256,48 L 256,80" fill="none" stroke="black"/>
                <path d="M 280,32 L 280,80" fill="none" stroke="black"/>
                <path d="M 304,48 L 304,80" fill="none" stroke="black"/>
                <path d="M 344,80 L 344,96" fill="none" stroke="black"/>
                <path d="M 344,128 L 344,192" fill="none" stroke="black"/>
                <path d="M 376,48 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,48 L 424,80" fill="none" stroke="black"/>
                <path d="M 456,80 L 456,208" fill="none" stroke="black"/>
                <path d="M 496,48 L 496,80" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,80" fill="none" stroke="black"/>
                <path d="M 280,32 L 504,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
                <path d="M 168,48 L 256,48" fill="none" stroke="black"/>
                <path d="M 304,48 L 376,48" fill="none" stroke="black"/>
                <path d="M 424,48 L 496,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
                <path d="M 168,80 L 256,80" fill="none" stroke="black"/>
                <path d="M 304,80 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,80 L 496,80" fill="none" stroke="black"/>
                <path d="M 296,96 L 336,96" fill="none" stroke="black"/>
                <path d="M 352,96 L 448,96" fill="none" stroke="black"/>
                <path d="M 464,96 L 504,96" fill="none" stroke="black"/>
                <path d="M 48,112 L 304,112" fill="none" stroke="black"/>
                <path d="M 440,112 L 456,112" fill="none" stroke="black"/>
                <path d="M 48,142 L 72,142" fill="none" stroke="black"/>
                <path d="M 48,146 L 72,146" fill="none" stroke="black"/>
                <path d="M 184,142 L 208,142" fill="none" stroke="black"/>
                <path d="M 184,146 L 208,146" fill="none" stroke="black"/>
                <path d="M 40,176 L 136,176" fill="none" stroke="black"/>
                <path d="M 256,176 L 336,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 128,192" fill="none" stroke="black"/>
                <path d="M 256,192 L 344,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 208,224" fill="none" stroke="black"/>
                <path d="M 272,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 504,32 C 512.83064,32 520,39.16936 520,48" fill="none" stroke="black"/>
                <path d="M 296,96 C 287.16936,96 280,88.83064 280,80" fill="none" stroke="black"/>
                <path d="M 504,96 C 512.83064,96 520,88.83064 520,80" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="464,224 452,218.4 452,229.6" fill="black" transform="rotate(0,456,224)"/>
                <polygon class="arrowhead" points="344,176 332,170.4 332,181.6" fill="black" transform="rotate(0,336,176)"/>
                <polygon class="arrowhead" points="216,144 204,138.4 204,149.6" fill="black" transform="rotate(0,208,144)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fill="black" transform="rotate(180,48,112)"/>
                <g class="text">
                  <text x="44" y="68">Client</text>
                  <text x="212" y="68">Attester</text>
                  <text x="340" y="68">Issuer</text>
                  <text x="460" y="68">Origin</text>
                  <text x="372" y="116">TokenChallenge</text>
                  <text x="128" y="148">Attestation</text>
                  <text x="196" y="180">TokenRequest</text>
                  <text x="192" y="196">TokenResponse</text>
                  <text x="240" y="228">Token</text>
                  <text x="456" y="244">|</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
                                  +----------------------------.
+--------+          +----------+  |  +--------+     +--------+  |
| Client |          | Attester |  |  | Issuer |     | Origin |  |
+---+----+          +-----+----+  |  +----+---+     +---+----+  |
    |                     |        `------|-------------|------'
    |<-------------------------------- TokenChallenge --+
    |                     |               |             |
    |<=== Attestation ===>|               |             |
    |                     |               |             |
    +------------ TokenRequest ---------->|             |
    |<---------- TokenResponse -----------+             |
    |                                                   |
    +--------------------- Token ----------------------->
    |                                                   |
]]></artwork>
          </artset>
        </figure>
        <t>This model is useful for Origins that require Client-identifying attestation,
e.g., through the use of application-layer account information, but do not
otherwise want to learn information about individual Clients beyond what is
observed during the token redemption, such as Client IP addresses.</t>
        <t>In this model, attestation contexts are separate from issuer Issuer and redemption
contexts. As a result, any type of attestation is suitable in this model.</t>
        <t>Moreover, any type of token challenge is suitable assuming that there is more than one Origin involved, any type of token challenge is suitable, since no single party will have access to the identifying
Client information and unique Origin information. Issuers that produce tokens
for a single Origin are not suitable in this model model, since an Attester can
infer the Origin from a token request, as described in <xref target="issue-flow"/>. However,
since the issuance protocol provides input secrecy, the Attester does not learn
details about the corresponding token challenge, such as whether the token
challenge is per-Origin per Origin or cross-Origin.</t> across Origins.</t>
      </section>
      <section anchor="deploy-split">
        <name>Split Origin, Attester, Issuer</name>
        <t>In this model, the Origin, Attester, and Issuer are all operated by different
entities. As with the joint Joint Origin and Issuer model, model (<xref
target="deploy-joint-origin"/>), the Issuer accepts token
requests that come from trusted Attesters, and the details of that trust
establishment depend on the issuance protocol and relationship between the
Attester and Issuer; see <xref target="privacy-and-trust"/>. This arrangement is shown
in <xref target="fig-overview"/>.</t>
        <t>This is the most general deployment model, model and is necessary for some
types of issuance protocols where the Attester plays a role in token
issuance; see <xref target="RATE-LIMITED"/> target="I-D.ietf-privacypass-rate-limit-tokens"/> for one such type of issuance protocol.</t>
        <t>In this model, the Attester, Issuer, and Origin have a separate view
of the Client: the Attester sees potentially sensitive Client identifying Client-identifying
information, such as account identifiers or IP addresses, addresses; the Issuer
sees only the information necessary for issuance, issuance; and the Origin sees
token challenges, corresponding tokens, and Client source information,
such as their IP address. As a result, attestation, issuance, and redemption
contexts are separate, and therefore any type of token challenge is suitable in
this model as long as there is more than a single Origin.</t>
        <t>As in with the Joint Origin and Issuer model in <xref target="deploy-joint-origin"/>, (<xref target="deploy-joint-origin"/>), and as
described in <xref target="issue-flow"/>, if the Issuer produces tokens for a single Origin,
then per-Origin tokens are not appropriate appropriate, since the Attester can infer the
Origin from a token request.</t>
      </section>
    </section>
    <section anchor="deployment-considerations">
      <name>Deployment Considerations</name>
      <t><xref target="deployment"/> discusses deployment models that are possible in practice.
Beyond possible implications on security and privacy properties of the
resulting system, Privacy Pass deployments can impact the overall ecosystem
in two important ways: (1) discriminatory (1)&nbsp;discriminatory treatment of Clients and the gated
access to otherwise open services, services and (2) centralization. (2)&nbsp;centralization. This section
describes considerations relevant to these topics.</t>
      <section anchor="discrimination">
        <name>Discriminatory Treatment</name>
        <t>Origins can use tokens as a signal for distinguishing between Clients (1)&nbsp;Clients
that are capable of completing attestation with one Attester trusted by the
Origin's chosen Issuer, Issuer and Clients (2)&nbsp;Clients that are not capable of doing the same. A
consequence of this is that Privacy Pass could enable discriminatory treatment
of Clients based on Attestation attestation support. For example, an Origin could only
authorize Clients that successfully authenticate with a token, prohibiting access
to all other Clients.</t>
        <t>The type types of attestation procedures supported for a particular deployment depends depend
greatly on the use case. For example, consider a proprietary deployment of Privacy Pass
that authorizes clients Clients to access a resource such as an anonymization service. In this
context, it is reasonable to support specific types of attestation procedures that
demonstrate that Clients can access the resource, such as with an account or specific
type of device. However, in open deployments of Privacy Pass that are used to
safeguard access to otherwise open or publicly accessible resources, diversity
in attestation procedures is critically important so as to not discriminate against
Clients that choose certain software, hardware, or identity providers.</t>
        <t>In principle, Issuers should strive to mitigate discriminatory behavior by
providing equitable access to all Clients. This can be done by working with a
set of Attesters that are suitable for all Clients. In practice, this may require
tradeoffs
trade-offs in what type of attestation Issuers are willing to trust so as to
enable more widespread support. In other words, trusting a variety of Attesters
with a diverse set of attestation procedures would presumably increase support
among Clients, though most likely at the expense of decreasing the overall value
of tokens issued by the Issuer.</t>
        <t>For example, to disallow discriminatory behavior between Clients with and
without device attestation support, an Issuer may wish to support Attesters
that support CAPTCHA-based attestation. This means that the overall attestation
value of a Privacy Pass token is bound by the difficulty in spoofing or
bypassing either one of these attestation procedures.</t>
      </section>
      <section anchor="centralization">
        <name>Centralization</name>
        <t>A consequence of limiting the number of participants (Attesters or Issuers) in
Privacy Pass deployments for meaningful privacy is that it forces concentrated
centralization amongst among those participants.
<xref target="CENTRALIZATION"/> target="RFC9518"/> discusses
several ways in which this might be mitigated. For example, a multi-stakeholder
governance model could be established to determine what candidate participants
are fit to operate as participants in a Privacy Pass deployment. This is
precisely the system used to control the Web's trust model.</t>
        <t>Alternatively, Privacy Pass deployments might mitigate this problem through
implementation. For example, rather than centralize the role of attestation
in one or a few entities, attestation could be a distributed function performed
by a quorum of many parties, provided that neither Issuers nor Origins learn
which Attester implementations were chosen. As a result, Clients could have
more opportunities to switch between attestation participants.</t>
      </section>
    </section>
    <section anchor="privacy">
      <name>Privacy Considerations</name>
      <t>The previous section discusses the impact of deployment details on
Origin-Client, Issuer-Client, and Attester-Origin unlinkability.
The value these properties affords afford to end users depends on
the size of anonymity sets in which Clients or Origins are
unlinkable. For example, consider two different deployments, one wherein
there exists a redemption anonymity set of size two and another
wherein there exists a redemption anonymity set of size 2<sup>32</sup>. Although
Origin-Client unlinkability guarantees that the Origin cannot link any two
requests to the same Client based on these contexts, respectively, the
smaller these sets become, the higher the probability of determining the "true" Client is higher the smaller these
sets become.</t> Client.</t>
      <t>In practice, there are a number of ways in which the size of anonymity sets
may be reduced or partitioned, though they all center around the concept of
consistency. In particular, by definition, all Clients in an anonymity set
share a consistent view of information needed to run the issuance and
redemption protocols. An The Issuer Public Key is an example of the type of information needed to run these
protocols is the Issuer public key. protocols. When two Clients have inconsistent
information, these Clients effectively have different redemption contexts and
therefore belong in different anonymity sets.</t>
      <t>The following sections subsections discuss issues that can influence anonymity set size.
For each issue, we discuss mitigations or safeguards to protect against the
underlying problem.</t>
      <section anchor="metadata-privacy">
        <name>Partitioning by Issuance Metadata</name>
        <t>Any public or private metadata bits of information can be used to further
segment the size of the Client's Client anonymity set. Any Issuer that wanted to
track a single Client could add a single metadata bit to Client tokens. For
the tracked Client Client, it would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding
additional bits provides an exponential increase in tracking granularity
similarly
in a manner similar to introducing more Issuers (though with more potential targeting).</t>
        <t>For this reason, deployments should take the amount of metadata used by an Issuer
in creating redemption tokens must into account -- tokens, together with the bits of information that Issuers may learn about Clients otherwise. through other means, into account. Since this
metadata may be useful for practical deployments of Privacy Pass, Issuers
must balance this against the reduction in Client privacy.</t>
        <t>The number of permitted metadata values often depends on deployment-specific
details. In general, limiting the amount of metadata permitted helps limit the
extent to which metadata can uniquely identify individual Clients. Failure to
bound the number of possible metadata values can therefore lead to a reduction in
Client privacy. Most token types do not admit any metadata, so this bound is
implicitly enforced.</t>
      </section>
      <section anchor="rotation-and-consistency">
        <name>Partitioning by Issuance Consistency</name>
        <t>Anonymity sets can be partitioned by information used for the issuance
protocol, including: including metadata, Issuer configuration (keys), and Issuer
selection.</t>
        <t>Any issuance metadata bits of information can be used to partition the Client
anonymity set. For example, any Issuer that wanted to track a single Client
could add a single metadata bit to Client tokens. For the tracked Client Client, it
would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding additional bits provides an
exponential increase in tracking granularity similarly in a manner similar to introducing more
Issuers (though with more potential targeting).</t>
        <t>The number of active Issuer configurations also contributes to anonymity set
partitioning. In particular, when an Issuer updates their configuration and
the corresponding key pair, any Client that invokes the issuance protocol with
this configuration becomes part of a set of Clients which that also ran the
issuance protocol using the same configuration. Issuer configuration updates,
e.g., due to key rotation, are an important part of hedging against long-term
private key compromise. In general, key rotations represent a trade-off between
Client privacy and Issuer security. Therefore, it is important that key
rotations occur on a regular cycle to reduce the harm of an Issuer key
compromise.</t>
        <t>Lastly, if Clients are willing to issue and redeem tokens from a large number
of Issuers for a specific Origin, Origin and that Origin accepts tokens from all
Issuers, partitioning can occur. As an example, if a Client obtains tokens from
many Issuers and an Origin later challenges that Client for a token from each
Issuer, the Origin can learn information about the Client. This arrangement
might happen if Clients request tokens from different Issuers, each of which
have
has different Attester preferences. Each per-Issuer token that a Client holds
essentially corresponds to a bit of information about the Client that the Origin
learns. Therefore, there is an exponential loss in privacy relative to the
number of Issuers.</t>
        <t>The fundamental problem here is that the number of possible issuance
configurations, including the keys in use and the Issuer identities themselves,
can partition the Client anonymity set. To mitigate this problem, Clients
SHOULD
<bcp14>SHOULD</bcp14> bound the number of active issuance configurations per Origin as well as
across Origins. Moreover, Clients SHOULD <bcp14>SHOULD</bcp14> employ some form of consistency
mechanism to ensure that they receive the same configuration information and
are not being actively partitioned into smaller anonymity sets. See
<xref target="CONSISTENCY"/> target="I-D.ietf-privacypass-key-consistency"/> for possible consistency
mechanisms. Depending on the deployment, the Attester might assist the Client
in applying these consistency checks across clients. Clients. Failure to apply a
consistency check can allow Client-specific keys to violate Origin-Client
unlinkability.</t>
      </section>
      <section anchor="partitioning-by-side-channels">
        <name>Partitioning by Side-Channels</name> Side Channels</name>
        <t>Side-channel attacks, such as those based on timing correlation, could be
used to reduce anonymity set size. In particular,
for interactive tokens that are bound to a Client-specific redemption
context, the anonymity set of Clients during the issuance protocol consists
of those Clients that started issuance between the time of the Origin's
challenge and the corresponding token redemption. Depending on the number
of Clients using a particular Issuer during that time window, the set can
be small. Applications should take such side channels into consideration before
choosing a particular deployment model and type of token challenge and
redemption context.</t>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>This document describes security and privacy requirements for the Privacy Pass
redemption and issuance protocols. It also describes deployment models built
around non-collusion assumptions and privacy considerations for using Privacy
Pass within those models. Ensuring Client privacy -- separation of attestation
and redemption contexts -- requires active work on behalf of the Client,
especially in the presence of malicious Issuers and Origins. Implementing the
mitigations discussed in <xref target="deployment"/> Sections&nbsp;<xref target="deployment" format="counter"/> and <xref target="privacy"/> target="privacy" format="counter"/> is therefore necessary
to ensure that Privacy Pass offers meaningful privacy improvements to end-users.</t> end users.</t>
      <section anchor="hoarding">
        <name>Token Caching</name>
        <t>Depending on the Origin's token challenge, Clients can request and cache more
than one token using an issuance protocol. Cached tokens help improve privacy by
separating the time of token issuance from the time of token redemption, and redemption; they
also allow Clients to reduce the overhead of receiving new tokens via the
issuance protocol.</t>
        <t>As a consequence, Origins that send token challenges which that are compatible with
cached tokens need to take precautions to ensure that tokens are not replayed.
This is typically done via keeping track of tokens that are redeemed for the
period of time in which cached tokens would be accepted for particular
challenges.</t>
        <t>Moreover, since tokens are not intrinsically bound to Clients, it is possible
for malicious Clients to collude and share tokens in a so-called "hoarding
attack."
attack". As an example of this attack, many distributed Clients could obtain
cacheable tokens and then share them with a single Client to redeem the tokens in a way
that would violate an Origin's attempt to limit tokens to any one particular
Client. In general, mechanisms for mitigating hoarding attacks depend on the
deployment model and use case. For example, in the Joint Origin and Issuer model,
comparing the issuance and redemption contexts can help detect hoarding attacks,
i.e., if the distribution of redemption contexts is noticeably different from the
distribution of issuance contexts. Rate limiting Rate-limiting issuance, either at either the Client,
Attester, or Issuer, can also help mitigate these attacks.</t>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>

    <displayreference target="RFC9577" to="AUTHSCHEME"/>
    <displayreference target="RFC9578" to="ISSUANCE"/>
    <displayreference target="RFC9458" to="OHTTP"/>
    <displayreference target="I-D.ietf-privacypass-rate-limit-tokens" to="RATE-LIMITED"/>
    <displayreference target="RFC9518" to="CENTRALIZATION"/>
    <displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTENCY"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<!-- draft-ietf-privacypass-auth-scheme (RFC 9577) -->
<reference anchor="AUTHSCHEME"> anchor="RFC9577" target="https://www.rfc-editor.org/info/rfc9577">
   <front>
      <title>The Privacy Pass HTTP Authentication Scheme</title>
      <author fullname="Tommy Pauly" initials="T." surname="Pauly"> surname="Pauly" fullname="Tommy Pauly">
         <organization>Apple Inc.</organization>
      </author>
      <author fullname="Steven Valdez" initials="S." surname="Valdez"> surname="Valdez" fullname="Steven Valdez">
         <organization>Google LLC</organization>
      </author>
      <author fullname="Christopher A. Wood" initials="C. A." surname="Wood"> surname="Wood" fullname="Christopher A. Wood">
         <organization>Cloudflare</organization>
      </author>
      <date day="12" month="September" year="2023"/>
            <abstract>
              <t>   This document defines an HTTP authentication scheme for Privacy Pass,
   a privacy-preserving authentication mechanism used for authorization.
   The authentication scheme in this document can be used by clients to
   redeem Privacy Pass tokens with an origin.  It can also be used by
   origins to challenge clients to present Privacy Pass tokens.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-auth-scheme-13"/>
        </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> month="June" year="2024"/>
   </front>
   <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/> value="9577"/>
   <seriesInfo name="DOI" value="10.17487/RFC8174"/> value="10.17487/RFC9577"/>
</reference>

        <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"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="PrivacyPassExtension" target="https://github.com/privacypass/challenge-bypass-extension">
          <front>
            <title>Privacy Pass Browser Extension</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="PrivacyPassCloudflare" target="https://blog.cloudflare.com/cloudflare-supports-privacy-pass/">
          <front>
            <title>Cloudflare Supports supports Privacy Pass</title>
            <author initials="N." surname="Sullivan">
              <organization>Cloudflare</organization>
            </author>
            <date>n.d.</date>
            <date month="November" year="2017"/>
          </front>
        </reference>

        <reference anchor="DMS2004" target="https://svn.torproject.org/svn/projects/design-paper/tor-design.html">
          <front>
            <title>Tor: The Second-Generation Onion Router</title>
            <author initials="R." surname="Dingledine">
              <organization/>
            </author>
            <author initials="N." surname="Mathewson">
              <organization/>
            </author>
            <author initials="P." surname="Syverson">
              <organization/>
            </author>
            <date year="2004" month="August"/> month="May"/>
          </front>
        </reference>

        <reference anchor="HIJK21" target="https://research.fb.com/privatestats">
          <front>
            <title>PrivateStats:
            <title>DIT: De-Identified Authenticated Logging Telemetry at Scale</title>
            <author initials="S." surname="Huang">
              <organization/>
            </author>
            <author initials="S." surname="Iyengar">
              <organization/>
            </author>
            <author initials="S." surname="Jeyaraman">
              <organization/>
            </author>
            <author initials="S." surname="Kushwah">
              <organization/>
            </author>
            <author initials="C. K." initials="C-K." surname="Lee">
              <organization/>
            </author>
            <author initials="Z." surname="Luo">
              <organization/>
            </author>
            <author initials="P." surname="Mohassel">
              <organization/>
            </author>
            <author initials="A." surname="Raghunathan">
              <organization/>
            </author>
            <author initials="S." surname="Shaikh">
              <organization/>
            </author>
            <author initials="Y. C." initials="Y-C." surname="Sung">
              <organization/>
            </author>
            <author initials="A." surname="Zhang">
              <organization/>
            </author>
            <date year="2021" month="January"/>
          </front>
        </reference>

<!-- draft-ietf-privacypass-protocol (RFC 9578) -->
<reference anchor="ISSUANCE"> anchor="RFC9578" target="https://www.rfc-editor.org/info/rfc9578">
   <front>
      <title>Privacy Pass Issuance Protocol</title> Protocols</title>
      <author fullname="Sofia Celi" initials="S." surname="Celi"> surname="Celi" fullname="Sofia Celi">
         <organization>Brave Software</organization>
      </author>
      <author fullname="Alex Davidson" initials="A." surname="Davidson"> surname="Davidson" fullname="Alex Davidson">
         <organization>Brave Software</organization>
      </author>
      <author fullname="Steven Valdez" initials="S." surname="Valdez"> surname="Valdez" fullname="Steven Valdez">
         <organization>Google LLC</organization>
      </author>
      <author fullname="Christopher A. Wood" initials="C. A." surname="Wood"> surname="Wood" fullname="Christopher A. Wood">
         <organization>Cloudflare</organization>
      </author>
      <date day="14" month="September" year="2023"/>
            <abstract>
              <t>   This document specifies two variants of the two-message issuance
   protocol for Privacy Pass tokens: one that produces tokens that are
   privately verifiable using the issuance private key, and another that
   produces tokens that are publicly verifiable using the issuance
   public key.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-protocol-14"/>
        </reference>
        <reference anchor="RFC9334">
          <front>
            <title>Remote ATtestation procedureS (RATS) Architecture</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="N. Smith" initials="N." surname="Smith"/>
            <author fullname="W. Pan" initials="W." surname="Pan"/>
            <date month="January" year="2023"/>
            <abstract>
              <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
            </abstract> month="June" year="2024"/>
   </front>
<seriesInfo name="RFC" value="9334"/> value="9578"/>
<seriesInfo name="DOI" value="10.17487/RFC9334"/>
        </reference>
        <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"/> value="10.17487/RFC9578"/>
</reference>

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

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

        <reference anchor="KLOR20" target="https://doi.org/10.1007/978-3-030-56784-2_11">
          <front>
            <title>Anonymous Tokens with Private Metadata Bit</title>
            <author fullname="Ben Kreuter" surname="Kreuter"/>
            <author fullname="Tancrède Lepoint" surname="Lepoint"/>
            <author fullname="Michele Orrù" surname="Orrù"/>
            <author fullname="Mariana Raykova" surname="Raykova"/>
            <author>
              <organization>Springer International Publishing</organization>
            </author>
            <date year="2020"/>
          </front>
          <refcontent>Advances in Cryptology – - CRYPTO 2020, pp. 308-336</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_11"/>
        </reference>
        <reference anchor="RATE-LIMITED">
          <front>
            <title>Rate-Limited Token Issuance Protocol</title>
            <author fullname="Scott Hendrickson" initials="S." surname="Hendrickson">
              <organization>Google LLC</organization>
            </author>
            <author fullname="Jana Iyengar" initials="J." surname="Iyengar">
              <organization>Fastly</organization>
            </author>
            <author fullname="Tommy Pauly" initials="T." surname="Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Steven Valdez" initials="S." surname="Valdez">
              <organization>Google LLC</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="6" month="July" year="2022"/>
            <abstract>
              <t>   This document specifies a variant of the Privacy Pass issuance
   protocol that allows for tokens to be rate-limited on a per-origin
   basis.  This enables origins to use tokens for use cases that need to
   restrict access from anonymous clients.

Discussion Venues

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

   Source for this draft and an issue tracker can be found at
   https://github.com/tfpauly/privacy-proxy.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-privacypass-rate-limit-tokens-03"/>
        </reference>
        <reference anchor="CENTRALIZATION">
          <front>
            <title>Centralization, Decentralization, and Internet Standards</title>
            <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
         </author>
            <date day="14" month="September" year="2023"/>
            <abstract>
              <t>   This document discusses aspects of centralization that relate to
   Internet standards efforts.  It argues that while standards bodies
   have limited ability to prevent many forms of centralization, they
   can still make contributions that assist decentralization of the
   Internet.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-nottingham-avoiding-internet-centralization-14"/>
        </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>

<!-- draft-ietf-privacypass-rate-limit-tokens (I-D Exists) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-privacypass-rate-limit-tokens.xml"/>

<!-- draft-nottingham-avoiding-internet-centralizations (RFC 9518; published) -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9518.xml"/>

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

      </references>
    </references>

    <section anchor="acknowledgements"> anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Eric Kinnear, Scott Hendrickson, Tommy Pauly,
Christopher Patton, Benjamin Schwartz, Martin Thomson, Steven Valdez <contact fullname="Eric Kinnear"/>, <contact fullname="Scott Hendrickson"/>, <contact fullname="Tommy Pauly"/>,
<contact fullname="Christopher Patton"/>, <contact fullname="Benjamin Schwartz"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Steven Valdez"/>, and other
contributors of the Privacy Pass Working Group for many helpful contributions
to this document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1965bbRnbu/3oKRP5haZmkLXkyF2XsRCPL4x7rdtTtzEqy
sjJoEmzCIgEOAHablpRnOc9ynuzsa9WuQoHdGk/+RcnydLOJQl127fv+9nw+
d0M9bKvHxb2LTVW87urrcnksXpd9Xzzplpt6qJbDoavuufLysquuH09/xa3a
ZVPuYKhVV66HeV0N6/mev72HL89L8+X5w1+7VTlUj90S/nvVdsfHRd2sW+fq
ffe4GLpDPzz64ovfffHIva2ON223elycNUPVNdUw/wbHd64fymb1X+W2beCd
x6p3+/px8R9Du5wVfdsNXbXu4afjDn/4T+fKw7Bpu8eumLsC/tVN/7h4sii+
Ka/rVd829CHP/8m2+in+vO2uHhfPz17TL8t6gNk+r/tL+euyPTQDruA1vPZw
VW7p02pX1tvHRQmDLVYy2O8e/csVfrxYtrtoIn9aFGfHqrkqOzOPP5VNGX1M
0/i27Ift0b7ix67+lzV9Ohr36QLX+Oe2XZlxn266uh/a/abqor/S8E+37WG1
3pZwoPhZD/tYDY+Lh188LC7am6avmlVxPpiNOC+b4tuubJZ1v2zj/fihgfPG
r8MZ90W7Lp7sqq5elnbyy/LmXzZVua+bq8t66BdwwM41bbcrh/oa6MMhWfjf
CqU/JL9nPw1V09dt85gGFEKOCPQPXXvTwzL9V/mbZXeFi9oMw75//PnnV/Ww
OVzi5n1uCPbz5abcbmH3q/klU3BlRjHzCFsWTSR8XJwf9nugjT6aXHYql9v2
arH0T9Kcwq/zXgbSizWnidJInr4Lf/ovF/Dm7Ra+2cjH4yP+5sU5XLRfRTO/
dwEDFcgQzqtl26zmf6yaqoMjaJviVYP/fdMe4DLeo4foHhc4yPyL30aLuqer
6q+bxdB2+679Ee7/AmaBH30uv/efr6q+vmpgMfuq+xy+OOcPFptht72XWd2c
1/cGri/QzbZa1U0V/wmW/qIcNtWNXmH/l9ewKcfrquM/fHf2p+8fPYxXT4c0
VEi28P1vqvnZqmqGel0DLT+BeeAvyLZWxfP26gomUJRDcb6Em34ve6Zd1VfI
/BZrQ2NwI3B8s4Nw3WEXHz3MrVf+V871fFF8dyibq8m/WqaR+/ufqmPZlTtP
FuNvfH/oNzflJv934CrfL4rnVZX/87/D3w5t/m+w+y/aDRBttc1/ARjSm/Jq
c2jg9E7M73xT1m8npvdvC5zh+WFqg+AV/77B7XPz+bwoL4HHlUvgOhebui9A
ih12cMJFv6+WeOZ9MaSS0UqyAoRQ0VV/PdRdhc/1BbArB5wM2GDTA0kdcDCg
dBBM7bYvDj3QDXxFTrj+ma/VZYmfww/+YiPVdNdAXSS5hObwq7sKGFNT97se
Dnoo4Kosu/pS5gkvXVb74VBui127qrbIdSOmg9PF2fkZzejXvloeOuDntByZ
Q3HVlvj3PW4PvH0L79pv2yNtD43ezxwvH8gaPl3RBGkHiqpcbkbfhynCVdlU
231fACfF7cNJ423vqpWbnkSBXHR92K5r4MirBZ/crl6ttpVzn6Bq0LWrwxJf
71x0VnCkcK+iE/v77X5TtANKUVRQYKO6antEdrAvuwEJxzwKJ7OtkTxAnhVl
5j3FTXmEo1hUi1lxA/IIGGyxBbbREH9pjsWhqf96qOA0qm7OYwXRCPMaNl17
uNrQfiZT1qOe0b7in4pd+baK98CtgNx7Oj4arcJNqUlq06ElY/aH5bJCvnsF
MqVYgyiHHxegAfV9fQmHEu9vGHtXX22G4hLOvcV5gVrkd4aWDXtYrooSBoez
g++UjjZzeQBxBX/r20O3rPCVN0Aolf1ikfkiEMrFcU+kW+7hdUCTVR+dPy5A
3j/DRW2Kso/2Eu4r7gFomVdzEHk7VDvhxfeXbfsWzvjBjEizaQd/pusOhltt
j0Vfw13EQYCgt9v2psCjBsGD00WW89bpystlBxsHf+95l+iSorpbEkkDqUU0
PcDpwZeKVb1eVx1Sgq4Oteh+wC2EORNxwZHBEuF03pZwLgXNfr4su44oNaKg
Vic4c9XiCuiwLHiV8LUVHTyS6aYikoc9xEUTz6FV6E2TjYX7dOjpew7YPQy0
228rlJl9u6twr2AAr2DNPA3InIHa/ZRhZe26Jyp05YBykzYQmbWZ/gL1lV6/
PcP5De1bYDJ8QCJz4QmaMryjrxwTdnEFqmXD3wZ1tMFlAYHi+2G69KrK3yF7
LLgXxMFgYvz0TYlzqoca1nWEDekPxKye4Fs2QPlwo68ruIenJQoKDlDQ+e7d
tIFVP3bAJavdnl5ONAJvAM27osUX5o/hyqt4QIJy797985MfLr47f/rdsxfP
vjqbf7MYW2lwfvMe7smu+vABWNoByPGyGm4qWN5TJddm5V51Nag+fXFfaOYB
CSOi877QP8Lm+TP2T9PN51PmE3J4IXHRB579wj8PA9frI20XbzBedMtU8S88
bgECQfimi/imyPFlROvlJfLX+OmEOTYT/DHDHnV2PF18MbHHvgeJBXTAVwV0
1WoPjAFligwxHPfEXOjpWcGXLrlg9YA0iQS5RO61mplZu6qmr8p29iRYquu6
PfT42suhBL14JZOD8ermuiXO0XjKCZTilPsBkZydn//w5OXTCRLRR5A+8ECW
pPzAy/WMnJ5v2cebuEiVrKC8pCpUcdmSNMjSuwv6FH68Ad5KbFYvp9Bi72VM
P9JRYER4zJG4tJevBwrarnC/WXlhFmCUFdVL4NyW5j4wVxH9Bf4GVC8Sqd4z
50SiRbVggRrLBYiSumnB2jvinlTFW5g+qRHFvRc/nF/cm/H/Fi9f0c9vnv2f
H87ePPsGfz7/7snz5/4HJ984/+7VD8+/CT+FJ5++evHi2ctv+GH4tIg+cvde
PPm3e6wb3Hv1+uLs1csnz+8xo7RHhVwUduKy4l2GI0ZuXvbOcpjiD09f/7//
+/BXQET/8Obbp48ePvzdhw/yy28f/uZX8AvQd8NvaxugUv4VTw+FGFxcHAU3
b1nu64H0T6AiOJUbODBgt7B7tF/rFlkN7itKZVYQSbcW4c332yzgsXN8ax47
MAEaPo4jKzd9Vb1NSJUouxFOtCh+6PFVcDVgIb/78ktcyBCOcOaUudUo5mi/
kCDePLk4L56QzIJr2rVb0kjwltAkimV33A/tVVfuN8CgRppm35dX1ZTF4HWq
GVg3e1J/6TwKWPkeFr/u2l10073miqxALxDMh5eY2RVmyWhYEJtWNgNvuTxa
WYAzJOtjh5s2Vi3DVHX1QSrga/E4w+QukSZqYEUqBJAzsNCnWdC6nqrK1q6H
Cl8ArBLmRYM/1bH922QE3vNoW81CYOr6JuVkuoVnKMi77Mve8CPmVf0eFlrl
38UD9axqNStdEqmvPI+Jl/Cg8JY3niGe2LmniTIVXqN7iuQEB4aUc+j2bc/u
uZRX83QzlEGaTW/G1TeumbTARkFOB8OzwsZM9JIlud4HeQHS5om1+O1XGvev
xXfJe0nH4lEzs+U5iOKhc8P12lmPd4NpIKhYt7AAvy7DBGBEzwb+FZWDOrAB
/rq30ODyHjq/Ef6DaCM8J1lV/GaYaKIuKB3BmzcluwS8AtRXA5sFfg94e9B+
qVBdKbsj70W8cma45JNHE5cF6KbeB8WQjH1RhVTMeQmyBV0WjYP1ocOZOhjh
su3If3YAssbvvXunxhOwkzm96cMHkpNRhMGNYhSTevMa7D8w2q7I9vNTms+d
XjO+CTN/t5GP+f0FbZC2BgTyW5wfeVW6wYXNOaGI1+RNkXNVxQz0r2s09Ksb
l3hkZmIbzMk2EI2IR1blcgNGsXpQUNeIXSPyLbsV3tJX70nqo2rXpLBMrCJY
HKS0qgvnuuxq4+HBG3NyF5UA4pmBUbw9kBZM57USxzKP6W8OCXYy6PTwZuID
IiIC07dfHnpgq47IJziamG4+KV7pdrvoRGJv2SDOAWvUrdFSx7nYQ4IxHy6A
oYu1oN8Xn4XXE/C29qzjw6mqOIGxyE10U4PN6V+FtjQ+jPOQp8k1dFMK2xrg
wytkJ6WXKkiIqNSTX0otVi/uiHMkH6rpTv4CzwmEowJDPJBUeQQK89qaQ+UW
/TBH4iH6ovK6rLdkkbPOBMfWe/8ofcUZg56NmctqWaIHxQzNQ5IxI04KNVjY
Xlaz3Ynl07+t9zjT/wCa2he//s/7n+AP80C6D949Ltiy++pe0zbVvQ9C76sK
NJJ66Nk4/yfU8oBUNm3Z4QEB+8ZT9jp7Qo2o3pPBJfOBXfoy3aVVC6tHrrsp
r6vMPuE0UPdB+wNWc1OynuHYMgP9tyruwxR2bVc9AHvn0Hh3Q3KK6KNl21RN
OLx8o+sKFCo2IF32Hj1kMuDY3rN2JFn57InVezT3xFKmgqrvVQtQprLyDIED
N8TcmcgWnqTMMGLRrnAHruuSnTa45X27JWdo6Z4+eX3x9LsnM9iEavkWP1sB
obDvbwMneIPcwI55XW7rFRwkkN6wXNBpu3fvRP/o5LRxq1F6wgnhif7Kn2hu
keqz6iNzfmZ9XkvkzHi33GA1TaPgeQd3tCvF/SsKqaF7ADfA6kUzh16Mqw2e
ec305beZDTBW6oyTUh99sCAR6TkwEqC80Dte14dm6U1g0g/KXSWeP3QXiY9C
/upGLvz7fI0sx31gfBs6amZDkYqBaIu9OInZqDHfQxX8gNZf21zhXZyiXO8o
AZ1AdTja7qDG2GETJ+cQ7RC+yzPiuovP8SR5oNO7t9cIfQxVfc0Olqrr2s5F
UhXVHhEZaJ0KvwAy/Edm3XJSTBnMsYfIqAhxisAjZKYz1hId3UkQtE1wXcrk
TlAcnN8PqInx/EX0uvjd0ULxZhzsDMlSyjAu1kNINuhAoiJ5dyvSJN3dUizL
sjkiX/DCEQMesjVvK7h+l4fBTblpUT7iBCO3nJHD8Zpg63+d8nQj8YjrsrrC
DJzkc3+47HHAZjC3HQOMQZDPxo4vu2hSR3CS6P9AzRIHBkay9H4HHM7v4T95
O2XVEjewpiMxNIyU0kBwNdCVXa/ZHSb0iKOtDvstu0xbDI+sQNaUeJD6kp5J
kOePD+iRCK8Pu4k+biXRldp01U8gLQx7I69cScwLB1N14rIS1Rl0PC8z4NA6
PhHiHyOtJj4gWkxO7lJkbFOSVcJKh794eFPVc7qMRTcO1wErOyoF8Q582hsa
Zh0PmMuN5wv4GKgdMDqc8Vf3Eo3k3gfn/vu//7soy/76yn02l3+fFeZf5lP/
EX4Y/u7eq3743g7wXin2vfnI87X38H9yFu9pBp9lZ/BZZgafmRnwB44Hz/3L
fWo/e8/P/p7GLMRbUmT2Y/JZmELi14HHv77je/Nz/v1XXxXW/P7qq6/v/Owv
eG8438h3JLsBazo55/RZEQmeSvRbusmfsUPqzvv8t64XCN3BVfhkXV/N1cbl
VJqv7qkJhWGDW41Na4XhDQIj7gdY4FOQeb1z+OMSfxzZZmQXXnYtxo1J4UZN
pLhCzYz4a6LYshrjgDl5G7IY25DEDSWUB08MGD1E7nSQaYxmAbpmNiUMPd4l
+Z4w7aFArjnf1juQJjvgsEs0fSIDEbSEQ49Me+jKNarfJFopSWDJmigFaS7g
mXfvJHlL5ysSnoKvuBXVNajTYCJHXpLIXZ+4+DFiQj4PZs1179e7KL5rbypU
EckJUq5WMMASFkgaN8V0SRR53e7gz6uMXnpZgX2NCRzF8/Zm/tcDTBdHAGFU
z9ddeVgVpCpvaQotHKXP+/SbsOAr0JP2oBFhDMIWVpBfVptanCAUiC6vJEi9
rd9WQBjsLbts2TJBwiThg1IE1UVaE4xIP7NvtN2RyIOvl8u3/iSWSNcN0Uk/
HODIMA/i2U8l2g5jvRF9ej0PG29wUNDVBqJN1deLOcSuex/WrzC2hXcIJ+hE
aM8weN4uUSsSkwkO+qptVwVlzOL8YPdfjzNQkviD+nK7Guyl7viR249+H54P
aUx0+h1r/LlRQ/JFae9qu4ZRX11ua/IRFN9dXLxGD+wr/CEEJ9tNWcN/hmGv
3h+9mX/07q8LdqK9IBvm3SdjfyN7Fyv8vZ0jB8k6guLr8+6dcjy45miab69J
YerA9vTJGRTmZYcCaqc/Df1j68fXT9X1a/M+aObitrVWTA8WMNxrdb9axw08
oEooJxORDRUlCrHpLpHRFWZoGO4TnDxWHwL9sUMSMTycxvFEixEOsBiKmlMl
j94RTTOiVLjusAyhlchrVfe6CUHdhj9H+U2w9+2ypgsoeUI6E5u3A9Oud3jj
dnvvj75Gf6/YifPrmtmTHfq+d0nSA2evkb3BtaDkHmEhsg2YQG3iFn/72RXj
s5sZD0Aw3D/iGIvMMeKZ5NwBcp5eCI9Ps8id5sJNnlZx6rT0PdFZuYmzorSN
jzkvd/K84PtrIJfrqtwiS4wX/kDoz9sDsqSsMYsu2qEnjzQY2ccZr4PP4W21
RwkF0mDw1rCLNzvrzUgiQb+YoFzCDPzho7U58zZXFPajr+gM1Y+mMQIlzjsS
nC428uugdJgmrvCWE8zALtml5GVedhduQBsDRHaCKZg4RbTZTVWtjOlqXuxC
zA7TnsR3KMGzUcQmVmB7jLMjb7SRnrpJAuEkp1zixNewJoZGQ8abv+gchjt0
jcTv0LMiflAfMuU8LTTCl6gxowsu6/OitdF+a9iVjgvUy66E60ECmxNl1GnA
egKvQh0KogNw0p1ckBvMo0MCdT4GEAQIRxtsQlVIJrRz1FCMLst5x4WGO3AH
ekxA76qWvJ0SngrT31Vlo3d6HeI6DvNM94MPPcssyVnlR+eYDb6i2B22Q436
n9/iGbvvS6ceNHgQVT9kdXQmawl3RYdC77HRDBP6DuG3RfHnUVImjBQUkDgk
W6VR0y1eMlLrfeKcla6BdyfuWlVniA/eVHBHha8HN+y+owKSOkT49G5rgmfN
+j9bbf3YXHN0GTR4Y220nEM/SiKQRHSYLiiQ/YYYHF2CKGwtmQIhWOmpwbHl
MoqILIpvcVxW8ZFRIFdG/tlLRqhPBhLuTaTp/H0Vx70hVZs8YO8u80ygE7c7
YE4/0H4ZFaBcPD8f5UQiOZUNsWZKUY8n5xJnImbFHRp+km7QyWlar3EvLB1O
9Lo68u7x/qJ/GbOTrzCBi+254SCZsn58vAGcMLlwflLVT+imrJEN8VDRdVDT
LCZC5VucNA1XzEdQvZ8QrIetpIvWnTJj2pyQNC7cwHCAsFDmYLsSPZj0+JG5
ruYUp4mlPjmqk7wJZmk4FXQ6bFtKPo4TmPkLzZzvoykjWBRP049oYJYaNDD6
QV3IhfdRHTP86RvE0w755KNCD9pdP71edDxJ2O2DdyAsnWWanrZNGcbJe+cH
HP4fOf+a6McIQKa2WyQnyg3Mtydh0GEI1UWcJYRM8iyNNIEJnubGXouHmps8
Fz4evUzUF0NCklp+01rLyb/DGU1VIho+swflT5oCqw8aj7k9bpUtKBzgjYH/
e3F9xvQgUcx4qmVIboA7NH5rQeQK5IvM5AD8lLQ9SZE7SiGMFdmBeXl6HI/K
jivRan0qHkn8TSkZt8mjzkyoq2CJEhgtOVPCOBnb5rhDGoDhF5TjQMR46ugw
NFPvaqwh8dly2e+7uslsm8m2/Ihdc9ldM7c4GfOWPXOTD+Z2zEw52bAvF54D
zoVIP3bL8Naf3PSzIX9bslfSRZHbyQtzyy1RlW50S4Q9RbvrVe8MRVrd/+QG
28Uke/yrRTH2BKWb9MeTTMSYu260Jyy4zAnnuR1rQtEV061DgSJhRR+RRRnA
OXwmS81E/vwZ3edsescK6aXVSUWSPRjzTLwXI0+HyF5SUNGjndZv5EzsdLVr
qk0JoWPNyg2atFpucD3RqJWxVV8g9RI+jgWMSaf0VQKlBHcTf6i41WhzUR9x
42WeMpJ3YuIsh/qaDPTGnH2c+RFn5MniaEoSEx75k4LOHhQtx/oSUgKmz12b
5BHVtWEzOdOPKW04vUGktoDtAeS0SlT+kcox8+UxkXWfDx2pBRBp5rfEeFhz
Ryc7xykk3cbuA1toemmlEEg81lOhGNmJDWV9KXcOPsWK60YlVIOePjN2iPNE
djS6P3QkHt3LB5kLbuxIzDgSM8YcQF7BmUWNFvXSMKSP0f3qUTkozDh4qdYV
qe+9u4/mBgY4sPyjpvx78shvqnJFNm41LB9Y+1onHVJPWKtnMtHFukQ19oq1
l6zG96e7bnf0AZ1Vo5q26s3uW6AJ8cfkTtLv3g1n1iWJmcZ2Fy0WLWCvxVL0
g8o6hyAvfPjLVBWgyYAzwleGjAn+wqd2Iez2xXHpTNaomG+xlpNWZ68U2zOs
eZ+z8EWVLkQUZZIOj1XCWzgKjjElSODvV+xFgBkeKNdd3GNq96o7c38Ae3qJ
yTj4+sSqmMd5lB84GdMneBujw3I/YScdgoI0K/RkrFlBzeftKhsC69JyF/KP
cjqnS9Kd6bFb053xYhiPwgLmjULjwwcX3o/FZpYiWaqoS0HZrsZg1HtqxaIz
qXu9Tbam0JXRB14re3v3SZj6h0wa/F0qP//hIys/43LeuJLckSuhDhWhpytN
klSol2qDWCuDPMvAe1fiV7PJr/o2ay75xCXvO2C/oiQpccpOkjdy/927sAkz
BDehVz9aPPzw4QEe0czV4Q7PRqvTgCZnVkyO9ghGc0lKF6lNSczLZp3XWuOm
luZHJBDdmiB0awLQqQSQUwk8pxJ0TiaVYAbO2UiKf/XV16fSWE7O0qah2Cgl
J6I8jRISM9clTT55ssWkA0IdQs5KEgI4G4x+EN1+1YLyEGgEOW1L4DyHBsXn
ksSdUI4UhwH1cNmUvx0hFzROghsXsqGMoRCqYo70wCvR5ee5W3IGFPSm10oV
Wi8al1Yfj7Uon6zJqtdlJRkvK3UeBXpnPu6IWY75eAiZ+fpbk3vn7YhJ/ZMT
5J1yE/Xjc5KyKMkhDxN9f+SfV/92xs2A0+pYTyqL5rC7ZBlzUx77SHuV9eNp
XuNkTMZtbXICZ86Hhx5jLsuIltmKNKFDhRDyhSek2o7OwBVxTj1HdtS04YTh
4htvRWVEGOVEBk9eESocgqjUFGrSfjNj4PLjmJJmeBCWAsl/zCOmkraSeCXx
aKw+RRWCR/AZmrR38vbjQrYLzYYVO98lo8Qw9WD38Ml4N6JxqBK/hymx1yBf
DJFka2SqzCQrdNOCIgiDwZlo0DbU2NkTix31+fweL0Ik0WeUJa3YQiHIfynm
rKZbqOeaDF60aJYM+sbb4Q1sTC0L9cERkoXfEAp54q6PPQ2L4mnYcsnF9nUo
Otz4Ns38ROAGA0trlpQKvlSVVtVURnqYr8Es2HAeCFX9SEEN2mowkI+jYNI8
vOeYeSEo2nRTBV4iaBmXlcbi0NVUhNxidFV7lu55OFFoCedQ9TyhDv4DZzJ+
I4xlXBLKVKqdh1PYcSBJX0+2dbkeqs5yOi0IkNQoowCw2mw0kMVDoq6EwSbx
rXnxOjjjMJiGsDFzjQKOz5LzbhQFwhLYmvY+sL3AqVr6AkWX7ie+rH14OR/B
A7KICn0dUaJg2fgQqAcKSQazc9fhMK86433DjZAi2MxjpKnuKb2dgvjBBYfb
3moqQPQgOt+KV5zzB2TSqrFBLgAqSwId1ASjyquuQmmIHKIRHxhVGnjpSyM+
A454jKr50rfOcOBWX4wXiYbmGvAVpoWaEG/wq4ch/bvOCX7tzjRkZS1jX0Rr
5kKmlYcDUM8DTSlzVHDcZcfyo6v7t4J4IYAMjOoiN4PyOBtPeFLBtDcuc4uo
wzF8u+iFS8J0udloQF6ltTEfiNTNBIRW/XUmj2Nul0dHJ2FAHIBADmqOmOG8
BoYPuDpwmJGlmUW0SeujnOZ9zjyVk8is+H6gGUw1gow2pYBRCRMSHuo5aHx0
rBLldkvhpjhxaBxZ6QuBEOGXCpfgZ0mgx3UcWt1B+4ahzayb2qNh9V6nkKMI
HJyTJJg4lIFwlpi/D+T/MYz0ZTuIxzX2kGnCBGw1ees9ftCIMYEiTyRMc/ef
svKrLlt0nGiYxvtf1WEitVe0nFVN62zwKz+L5nNZwabVbcd39i43VryWrFB/
B1dV12bjGanKhK+n09GQKRZTSzIvOsOinAWT3OKlanBWE25T27LPTFUUOhuj
LAVVCd/MCXanQZbUqe3dYSEc4uCC9WpmgAZHI5CeJlX9oGQcp/iZf1HvF58U
l7NrxWvp6ljJuFIy5YaJEqngSOokQYfaXGwsD0wkegMDtaGJsScrL7HRvEKY
sUjdrd6KgIghA08/gi4JA6RD67AFG5Q3fVcbU50A3sL0xShqaTopwvjbLc2w
yS535CZlJEqyiRJUbL6rSZLz2jjWZ6bl8yH1MAO7cd0eAoBgHHkKxdjjEGCa
TGfCuH9L5nO0o5Ixeyrn0YWcx7vlOw5RErTP84wm5bMQtWB9HKshPQoO6llp
Q5CeBCTi4C1VtUlF+oqNToQi+fPO42lR6OGAjmIG3IxxlHy2OSWdEdNhDz/M
Iegn7G2nwKYyzGAgR/SFRUDDRDGyeMqD58C4LUsxL8BwCwWTTevzToIf3eeT
+qjdlpBbhQQ7C6Dwae9C4hFylRShkBCZQMZhtQqorsGeaxQaii7tP7k+sUEe
5WWRD60dGCBNTp4ZK0UYMN+OLIeCELJXcYAjmuV4A8PNdFJXIs7bECv2TMnD
LBmvf+qmyeVYF2c79MyVjMSr6EQCpm0qoWJg32zd0sNF8ZrPTb0fudSfSj0a
Ut/M2D8rQy180i7QAMKL8ENx7hqL9MwraXCyO80bXPoGzUnHN5jJ7+BUV+VQ
jsPvo8lHl4u8mkpSruwua9ARMdGTh40AOdnG1TfN4wiQ3rlYTqNSsU9mSLMW
iv+7T3ucwqcFF6PYvM020MNpL8kn6ST94CL2vHCpdaU2wF32IwXFIYSUZO0s
qTP1k0Nfbde6fk6j8B6Q8LUYzXPmPLqZ8HmfZEirNjoGBz+YzUVoJXnGhFLp
EvHd9WsBss+7JG2Uji/XD41PGCZ1EnkHkfDyKEWZo3UrTqLqoLDyYUMQOYkC
+mlfJDOMhV4MWyCcmifvk+Vxm3THwOAru9WWhCTrR4hM0lSa0r/3Z4h/C/LK
xfJKF3LfZ8Oor5TCQmBjswlE5ZmxbuHgqjT0Rromr5pqTqoSUNRVRdV1vNG3
bh1Hsn0A2Us/WG3weN6X8HjpExso8k4vU5uuXa+3NRcZBNAjDXNkwY/U31pz
Hi8t5Cns/aFj5n+XJaBLoVyTqYblC0v/OMheFidy5WvgA7tQX9RPZF4DLfJt
9S0fermncVy5IVSA8aQIKkuhQTnZZ1WEsbCETF05oqaQfAFLMsicSV0WAeR8
qNpJqBoNnE/C19/Ad4p3n3j4G3phAjtmIVJ61SEohzgLOocenx53s+E04xkH
xLodoy3bHPQ+qMc9q8CtYvka+TuyDz0cXRQCUattEVLT49Rwd1tquK+haw0+
50RpbozBpdjewMlg/gNXPXE3EI5Th5SLAEUYQQSGxIEsDH12EoI1KPjUkU5C
fvaA8U8gxCbpuhOwwdITNcVtvOljXqe1w3FughlDVAodAyHGy1ryjkyRWHZQ
xQzMWAWhlKiOi30D4lQbcjSAQlAcck7rst1rpUxOyTtddM0wAb76/FyRprS0
ehFydijZE2t5fdn1cuRaN8CWhLWoYa5luVf9LKm1w5mzodsdsBKR4r691KBH
7LIw1eZad4kV29m6b1VJuNRbDwa0DfTNer/RgXGrOXRGExYILU/mNPGtYLJp
0JFHFWjC/EHjxFraSpuKY8og2IcZtlc3MDFr6Vu4dLEfbKJvAAJHgcjDyWmT
eGUvqSndhHG8yL+qvKQFga2EpbiZhv0w9A/tIM5j771n8215RBa8pM5GBmyU
nbZiRxSZiu+J+y1Gcf5abCht0ds+4+ht4vU15ZtUCcJUzcqaTJmiGn5Izj43
TyH+W6O+aYmuKoEstHkR/t37TieuGBYDNshjxdgiyL6hhXFWktJI1AvMfWCA
PC5ZMUiuvkylRra5w0AU5jypewpFn3KAGGdyystUMygzOohab+m7pNzsJJ+a
5XyCgjQSFalx9ik2YODaEqBHDDiqdhmyDrx4m5BBS4IgX1X0ODNcdNShUyDK
Hy/6+ueKQf+a4NuN3yX7yrKE2BRxtlVgfLp/INSAhsujlPoKtlJER1pfXXJt
nCGb0hOOYk70xVaQApv8lMJr3G1TUtvpLo7h4DtHY1Kg4Ukhq8byytAuspkG
FHoOFyvNjFLAR0B3E8iKEeweRfFd3jeu0dsLjzJ/omLCju0CVP2hsYEK3tik
tMygf2qtNVIrOg7HQJJayBhdM2KPvsYszQ2NLGh1R4pa6QFzJrZe5kvwGS4Z
OJ/9O8mc7dcfYI0Hu7DSarbM8uiM+nRdUdm5f70cTZSDHLQwn+McBpcMZ64g
MZXn2VUmlhHli4cl5CbvknyRE6OTrp5ZvrEvsIYIZY0FeKMYGmfrhFOQW/qn
Fuy6POgkQS0l8RNeyvxHfGpOsb+OohM5/4rGQ0Mo3mV2V913bI974PKRoRDX
uXMm4Bbzl445+8FAHiH4M0Zjs3Kd9BN0JtWS4UfMmtzw3qfNjvhJNTjUnKwW
2LMQYzkntFj1EZFNiaYAO0vIzx+BPTtNWZSZkp9Wcg3YuR87JgoCzkvrm9cu
KWKamntBDEUtJYXhw+0qfq66dg6c3OFJtjUJY5YUev2jxgkTglhDkC7OlszP
zbJHFU7wU72lN+g8QGXZlwMC/YIg5U2hjZCtquOVC16VMDbJ0S9dzogZyv4t
Xd1zIN389bCX+j7j1crl6PEZuhW2XFpispRqsAMii/Y+UDnqd1K6o+tGZSGs
3ZQ4obNJlu/ctxqOhNvgS35aEyqeqZfH95uIIBAEiwOZUD9QzkVugqYCS6dH
3jLVk9IUuLdNeyOpFxOQFDYJLkFirwMcZBjb18mFOpeAx2NyTgmWQrITsKY9
u93OxzInnjo0+WMqL3t2kOwQLCqquLHSoDZor9xlo68IZgqFmx6YSgpUBRFp
FfT0mTnwycu7rn9SYMwQy48Px10eQ2lkKO1RTwTn4LIb4XgKH4OJw9m9UC+F
ZItSkzVyNHnCCO+20KatTyFxdrNNH4qRoxHhNrLnII4zmSS6zTKuMrM/tSZh
BAhjgSOZhPhxxr4ppLMKA5gkKDkCuOBX7+cYpbIy4n0Atg484jR6Ql7yuazk
0yyY0YgGdIZCT4xQon28iByTyffB8hfIialBc9r1CH6ac6b8HiPliLCLAPN8
sk6u4GtmK5aRQl/PN/VKXBg/EZ5hYbEqlF+wcjUJ96ABffZveJwkvgW6aBvE
nrRcSUkLnb/8UMhO0Ivcobin4Fdo25VpWjhemi95QxDEEYikM4WJ/tAkFQzY
M+zZzxLUIumjOdqU/mD1V9IufSncjcetPwWCZTO8udUlUpdkzZN1c3mMCyE5
SuytwMH5HHtWmUvgxJc+ZZk1xPAV04kyXG7gLINgvHkIFs3EM8hJRaRW9RFW
lC4No/r7ssaiQUw0ITziyfA0eYNiXa3uU4CPopSN0TLBtuHmFX5NMxMsGiEj
4ITM8ltC0y7OvglLpTSudpBchz5dJg4j8FeYRlcP9RV+VdM/A3PVzIK7WOtJ
uJMhPOIXOx0nQklPkieogF0inaON3JWrBBLPQ5H4pBj2QuWOaaJiqDeSg773
QuKzxbtPNFT7wbmnYjqwW2jQBipTXmwuvcDCg0GXqMHhoXI6rmTRToe4Pbh8
6hwCKgYLqr5GuFKKcrTebZrE3UnHRdpB/B5Pe+O8hbD9Yvys/RDiCCBW+pLq
RYtjXW1Xvdu2V78HS+HrR7//HP/n/ssHBXZ/tw8vwoYq8E66H3ACrzOTJiWM
MzKNy1lC9ZTHDiw4gogPHhCs5hwlSdDz0muRlBNgvDBGxVgr7b6EjUmcsvY7
mY0tZbN8YoEUDPBLXGgBwDF9bmdqiF+rqnKwB4Rbqi0JtU8FWQ/V8q0oLKQJ
UNi4eEXTz01Sf04HwtuN9SoiFSfGHXslXZt/lefEZXGPIYCx9oazkhgM+N5M
Ww5gko/DhNrtOgaemPm9SNp2/dHXnoNJU6IM8rJtjJdRS9kxn05tke7jwCBf
0Z4zpAlS16U5KgktmvCHyRy5EzmeH6jUJmIgWq1zqLeDKks6A39x/gD6hs2G
Y4Ph+646oNZdYV0N1jj/8/fPX7159MVX37w6Wzz8Av7/i998/rvf/Hb+5fyL
L7+Y/+Ovf/PbX80f/dfDhx8+uIB7CLoojDLnzKt/ffX6zbc8OnWmD2N/d/an
7x89JAf+C3ud8LhNTJ7acFDXT/RG0G5jvG3YMNMvd+Tcw9gUbTzaJbuEPfhT
ZJUreAg5ZjtydVjm6YIsprhli8Bl4aX+VcSkhGEKSfgaFHKTHUj5FAr3bcwt
VeAQWilyWcfD2zoabKPq86SNbyyfXRQHBnptfzORbJRJp0VRJhl+ozRpqsX1
SQ/vPjFJEbf1ZKMcy2XbH0H07zgEixg9aJ81oklQMQZ5sa5JNofR+fqA5qwx
wZATQvsWYABqSVhiFbipbjI+bVGz8gkbNE99MeeUlCvCyxslL9kMkMeUs3Qm
ErSUZEkqZii3R9Mg2OTkU98whSPVV2INwVG6iKAOIl/DDfsRTCTK7ePoy9UB
OP+W6hK1jqf1eCCmjDRS0vDMVYHXIEeEsx0n5IlN31OzjSkElVuRHmYGOUby
ep6s2PPMe2qWEioi6S3sFp5juE9JFnb0CrdfFJCisCqgTxR8ijbaVrs+H3V/
fMtamqOHIp0qmcbRfdW0j5BXP7FXcGXFbkYzlGIDYxF9iyL53SeEJTHCGdek
GwoM3g5QISDjNi6xFsr8GBAKZHRJlAi4jyNDwxaOqGyJcfhoT+JbX+8UihZV
E8eNaLfEjic7PBZn4rmXNKhx/hMuzSWAxxF8J/LII7nqixGiYrleV8uht/N3
PP/alpRl4kOhXeXJLhHMNjnrM5CRnLbPGZnrufM9jV1LHk4mqbdhYeoLNI9E
gTf1disheynv0jqwUPollWcTcOs+A7k2d06BXRhB00CbZMpTfLmCRLP6EK6K
IMJH2NkyN7zw15Uapgb3eQy3zcCi/UTc1Mw5P8UQhjS5Hgr0hR3ZKJxii1qT
ilpvQjXHtFt074bMhE2wt6AM1H5cAwXTQYe2BwUJ6F3srQYxEGe9srlghE7k
5g6sgVyyoO/FCMxRVqt0k9NMyzHYv7iRbS5hxMCMj1CJ+g5lOMIVgrVzBOZa
DVI9KrkQbtSdluOeLbfCCP4oPF3WPdMQdxpi83Qg8K10Omrt9ih3SQxGZS1M
MW4cXxasAgJPsHFf5qo9ukPjFCe+0C7pz0t+WL+AEcfydQzbFl07+xZmccQa
6z35cyS1LnI7yNGQxEwPRdWCU1UXnkekvgNnSqOikxg8lEZfUVpKBkZj7AQP
yx7B3qYhCkvfWkCaBCXThotUhnKKMqZeEGpeyz5T7jEJ7TGJ4MGHn52KS7nX
pyZfsK76u+4FgdMawO14EIq3MnSDzfSIaj+DMeFCV3e6uT7Fa7wwTsvsR5Wg
vlJprHSrbjq9JyMO+Sma5WE5Bi4k8ustIgVrJBai73pJ4Mh8E9QR9akYNVIL
VL2CqPEs3+lzJjaam2ooUUi/E3/F70Z9uEzLcKNCmovsFT6xp6Af3IWOAru5
CX3S0yjhEPpYHHqhUYrahO6U2iszrtNP/i5h/t7FzR6FUr2wSEp6hE6ZsQRn
THCVeAYgeBwmjVVD3SY2ZxqxZleLx+BRAH7JCRBBWnxnjvspR7UlcqxXJtri
h3Q7XbqdZilcj5p2dxZ5t6PmhgHFBGPDlFyufguurI/mKW0MyKORQNUYqO9B
VBZsmyIALfBgxXXGra+5lwmLVIwweTPgBDPn+92wzhuF1jWjg7VfRW84RpP3
vRowT2SszjlngthFgHs6LT3C9Y7u1K3S43+GmGo2/OtBAQF6I7fDhcyU/Iv1
LMluNt0iw8ZqqTmKgc/0/BQ9FQ5eIcWoHIGvXmxbhsY8nuajDuomq5E857Vk
YeaaHEt+auiJnkcfSOq28GZfsD4fbA2bxpLXk/RUyvgQnTeNUqY6YoNpR+VM
tFeBzuzLRsEOE1WxLSJsXhC12VFfYnokmZyS0dyde2byyQQWdzJGbcwrHx4Z
sqVy2vrYuqhmpwXYSJvPK4UX6kQj1dqDUsUrrXsP0A0m66435KZZtqbOLQt2
XqjfwGU9GRbMOPUm5DovLNzYVChOmgrj3enDPrgpu6EY2Q3srDBQYGI/BPs5
NSJsu2ETOr3FB0ZWs70x2j+KW0cqbADNJuU9MQSub3geG8xnsefKxOdMfokU
agVHfZJZwZ4ubEvOVM7xHdPQe8xdjVU0pVY7ag1emDZQfm0z1Q8DdqH/skDW
xPgUI1SBQXNMJnmelYauVlBxCjoN2q+LEwo0m9sI9aAJSKBKgRnr7dHlEubi
Pk3TK+dyrkbYFKgubafQemnP8K0i6yDNInSS3qcX7J1794m5S+xPVVdnEBIm
zxLLUTqw4lc54BNV6EN8rfKNZOEdSj0xZiQznlFyknpWnMHFwxWmMOkRonlM
GhnsJMemNgiVUhrJCIZ63G1hFrO02N0rTC1ujkJFNQZkeYm7Irqb7+idbwUz
UHpplIbrfKmSj3uN6vslBjPauDqGanQYyfNBEjY3qIoWx9jU+15ukbYuIs6D
m9o1AYpZ69tPYeLDfLQ31qorbzj3XlHWMOWdnCLkW29/osR4k5QD/CObJk8u
aYaH7CrDyAL+P3XcAhnge+kQA+MiDjwf0hbWH0kmC+fXQl6+O63HJhmhHi9z
m5Edxvy9NA3E7HqVImO8AN9WStb4IunGhdyKSguTZkLYyOdAHkAu81xrg1wb
TuTIyjnjlo2vvFx3ZQ9zBjj7IMXWmNEQ+gqdZBi0MQjBkjlex96DHJpS/FoM
DwQQ5xFksen2fod/izEK9PukY3wMCj369b0bdYx/n7SM589kD/TXAC2dwZH2
c/gseeln0a+f+TmMIZz/IlN8n6z4fe63Ty0a9Yl/Y0Dqj2liH/+uCNhfjbrG
fzVqQ5998m9+52ejFSUt4/Hf1/nZjp+MG8bbU7x9tqf/jWebvr3I/g0m/wve
aRG/o5unoN/CJ1L94d4HEXsserpKPKAsqrXne9SEOkVOSKTVZOv3EOA0nOeU
PHKhx9BHMn/KtxL3ziwynEw/RHZCUS58nGEbOvxqyRLHZTwKgUcYsJ0GuW6b
PD1aQDtVlzcj4Uk91/d7av8NA0gD3Qq1BHTs3NrsQtFJP0LjSQaTcJNgGkzl
eEol1aVVu0xR10TKNcaprbcq6T+V4jVqXcIU6LG7L2m0ofXDBwLczcyr35fL
6YlxLrhvNcMIPKb1CbywqZZaQm6NLBS30+V9XtBGtXxZcTtRZ5hXoFjCeovR
Kxre6eJrZo2xE1yWP0YTNr20iwmgEM21kIQQU7GgbirnvVQ/Tu5GWuBqMzgy
nXLrKfUhLow8rUTcqkZk9IbbNYf3SXeJRG24XXF4bxWHXPeJ2/SG97d2pzit
NnwaSabb9YWP1Rg+QmcYKQ2/RGv4eL3hl2gOJ1SHv5vucFp7+J/THyY0CHv5
VI+YZoC3qBY1ReDXh22Mt3tTSmcoxMpqy9Uk16A8H19QVUmvhDtyV601j/oU
RqOrT1RxalSKatPAScb7aZ+BeEbIrFBVhV++zU6TBcSO2NAoNguA4Gu9VXkT
cT4hyRn7tI8zEWcTgp3Kl1GQjhpfuhNKxOQBiCWs6UC++JSjdSb9LBO1kXL2
srfKn0kDJO1F695M2BsRICaK1KzRG/QETU939ahZxj+/eXLxbP787MXZxbNv
qGWU7RaFezffwoEPc9Z5MN9T4LKc0fEC7neq5Z1W1ILWZ9tl6RXiGq2gnSiS
9aRuwl0NTrkCPkIzmXnqCXEg40cwgp1SGCl0JjFBW8IUNZV3PkyqFaJ67cb1
lOe6pZPwDf7mhqSl3K0h3d3bBwH2TeseK+2dLj44WZF/6/3yLi1WHqTg46OG
6dGgdUCPm4f6dVZXie59/prpXT6KI1Kpk5Y4mXWELuVY5lGXvrP6fNRZ3XrF
QzsoawIl5hXuvJY9SjHoR2h8QqK3anzJv5MKYFb9S5S/9x/rNipS7e/9x7qN
ilT9e//RbqMwE/knCuH/uo1iipjS/v7XbZS/f7HSNxYNd1b5UMxHDTlUXAtr
M9XTka/Hsf8lZ8LfBfSIW0mx7uFCvA91zlPaATaPva5XiCmptu9ldWwJKI/T
tqRgLSp+UM1F1a2gWWQQkhYj4ZtJ1u0LG+xiCViHTO9Mr5LY88UoFBk4N2S+
CjsX6ZBxQpB5OpPB7kewgCWMpEElVQh2ZnvNSLXGSrufNC3+cLXVGBHm8yeh
WHZCmsr6TBNcQnjnctxcfpHHaDD4zR6igVPFeBJK3R7kNLc/MnWLBIuFIvBG
QU/UjlKEKhgrsyNXqZb2+CQ3D7Hk1cRMEo4vd40S4xPTJ4bAElhcm4AfYwaN
4uqZYoE0D5rQcqYbcHFwitB+7hCbIoSfv09oKnT7U3WPLkXisxrzMvPOX6aS
hvQu3XbNAaOvBj2S+OZdmoPYaK9GdF1G29Xkmmx10aQG5qYaoNQes26HUBAC
hjGKV2sbctO1Ei8WQfl4jLCM2ZbRdvdbamzHyJaapOgd07o8a4pJQRyyGS6v
n8pEHzPc28IPijPh+S9ujZMwPDOix/H0sRam2LeYgFVzkbWvq1DGlUcJCRfO
CzEPTkHYRnGRhUkQpFcS+AzHawJfjE8jjpkYTsX1O4k7fpbjD0LYHsr60C3j
XgEGfQXzIcKcU6l0l2COy8pAP33NIrijiMIsisDEYYpUYl32GZGVSgREuE3Q
/SaYRwbRT80YnnfZp/B/lv8rMp7BNeBmA7YJXjy3GebBNuNWhF6KZX0PMZqw
l13uhOxKc4+exkglNgcprYR1Ls728zWEfSabxpeXesAczP4k8CpM2vsDa2Hh
j0ltZjbpxiAxSw8gn/ddcCn2LK7etEh0S4bwxVou3DlFnvVV3JQrd9MamF/M
iHpc3H/4oDCwvS228sWiCY2h+hCi3EYsTF65oPgEZRUm77Ga5Aref/SgwLZq
MBXfR9zmLpkG7QmkDEiS6rr0+YMEHbavl9IS7Jt4whd+wnC+MQRx6IxIAdTQ
xY7QdRinQpu3WSy3OB2pd/68TaWCqVKwOisJcOTzoZQu4KIF8v2Uqkd7U/hr
YW0iHHvzTq7nUs8W8CtnKr+ZbFQaprW+7MeTfKWpI3fmyH16qjWEBTY7LewK
+Yf0FmT0ThvIV/GqgPki8YC1hcWMo8i0T/mE67CpL2veX3oEq/pJiyJVL0D3
X5jKrgkAztA1aOTINZdb8oHdFW4HzE6UHe36mCxaSRaHI+YFWhTs5XQOglCR
bkvvkW4oOZBuFAkfllhe0nqYiBgPzccUVALNCkLGFA+05q0pznmAuDwNcy7e
umrHXWiHKqqP1IvPRSk0UaOES2xcdQPyzAvSsJ4Pw4caJx2q5PsqxspN9i3c
BsXYwLYhV4eyWxWTnKjtQstr/hJxYp01cKgVljT3GLNO8EIjbHSwFmptDG8w
0rVBhiBS6mUCSX9VYlKqi2hecsUVkbZv1wPCtM88YDtnOGuNm5hOnVjfQFrN
siaaUytRYFJ7RIWqItCI5GZrG0tgPo6HzYK5y83KYuJpZ92btnsboBm19Neg
FeopeW2G7pod9iwISfVtByhALCJZVe16LVWp5ZC91boFcWm9uIf1XJzwOdKW
btAM3WO708C+YCbMRmBVK1RV8XEF4feo4wEv1Lc3Q5rxvY4nqIYrnjBD6bAj
oGIBla/0/a7coV7n29lgo52rDZsvCPKHNMuCHDN6m16uToRMryKeUI9MFgup
aj4A4ovDI9YF+wV0wu2DJgkmFoF6u1e+L5Bgxpdj6TAziAh4wDfkxA+8KGyr
SAT+WHDkBZ0ogrbMNQ7z6PomVOrRzMqEg2jdHNdLy+b4RsAUoQQrol1TEm/n
uFsMXRWuUCAgwbXoIpMNIkA3eRrpO4goEX0AGsmTIpHZFJAbNxywjROL++Ge
+QKd/gHaC5MqIQGwcEIwujY9mI1iN1MMecm6F08SVbt4ugURKtWBIgOzU1pg
y5ynz15evHny/Ozfn1ycvXpJ8UbgiLiYTbmbl9ct8Rtu6t5UoHPHm2GUbDdV
lo4Hr1hjyuVWqf7BFdDzHnu3btrtCuHYkD4axhtlEFKtQ/SODc6gDkBiN5Jp
t+I6YrtaSudfU6dv9eIoCpg/Iyo5mDgOj2yMpdtLkFJiCQvGktYwU+1Qy/i/
f64uP9Wwlzo9n4SQFobEJ8+ed8wLhUH6kwFL3KmT2nnwbrlj0Y7CAtmfhpVO
emhslWk7D3vvAtTmurox8cvYWax1oKRtc4nUyuNBaZIXgxeXxV8PbUfAXNz6
S/LVZwFXlai4kfupUqExDnz2KTIdhUBltOqegZ9ZE0/M/4BdgfOmlhckTlri
VofGV//3wBGXprbGcofowoBtqic2MkwVgInVWSCSa2pQpVUewRgl/4n0RlnH
2qt48ZpfmnC5oDko2CE3aA5dgtZrFJkUoUWXdo/bHirpuOkTYc6uE3yzcKtN
ozoP6gkKgE5iO6lqowkbeuIYipfIMXpJyIdSEfRTjX7QchJxjQoXiKxvWnZ8
cE95J+OI1+XWxx/9HkTY118SLub+ayCjLQv0kzkxqL8CWVQ2IyUu4qK2IOQ5
ummNW7cNmQ0ysG2k2lvEiTiBBo1PZAI6AyIf5n0qfe5hLfi9ADRRbICRiF+9
36HHquOXUOtvRGlvKacjUewUaiStwIrhRvJU4gQZEHadqnzbLrQeZ9hzDbEx
tDByJ3KxMxIKxQyo1Rpi+hkA21GNL/rgqzWljlOts4EpJqdZPC9J8rbYxeRo
Tat0A9gutu+KfOXcVjCDSVs88ZibwTF8asw+9Cz3vm/1xpnetH8myI+bgLDO
QGGNhV+2zl0mH/1yRUBcXNJND4aLl8llV/BSX/9JnkusUfdPxecshnvUX5SZ
ofA61mRN/ruvz8s1VGIFV7tWVwxKJgOJHGTvW1d461Gxz7BQSQ03uiUGcVKk
Jit3r5UQyUd0PAkjPA8cHatqp0vDPYhuAutmQCUV1wxu3ZVvt6HXJ7j5P+3j
neF6Xs0yo7SxspH2d4SBGvy0cuNZ1pWrVfiLnWbh0fo9hhkC6FLUDcfzre9Q
u2QrCA8I/y5P/+XhX1gA/eWLvwSTnbp4UPPXle8iS7vig4gMxg4cgEIWwaCi
JHJGcy2ugJ/i1UaTXrDitwKWPPjmeCTCVVu4L8yEQXRa8udKVKQYyu6KvHsP
xHqK0vussiXGOOqetNQMBOmhTzoroMZE6DQMTumvkxhxO07cYscQjTafF1pg
G2KEuEcp0J7FwCfri7MHItB7u/OalwaqaQrOapIihLtHYbWRo8b7JxwDu5Tb
Use214tZu1b6j5p1XcRWkELHhs0kxQRfPrDfaFzDHzpc+UboFiU/MrgypxXe
uam2+56/T4whRS2IQGDH9TnjBA24MDAfguhp3aUXWWa9GjNIlxvX12s+pt1K
l2xl8QL9CWz6stdPslvLFa4HNQsD+t3yOfGcgBi0yn57lPpP6jZzigk+DcIW
sQmmgOSRH0ZqoTZMCFIeh7U07RvFWHnqAiiFh/J/bFaUA5Uq7iOg+QMbnAee
umXJs2BO7eX1xzDoHOqvS5hx4jKf4MxFljO7v4kzF1nO7P4Gzlyc4MzuYzhz
cZIzu4/mzDG3kGYCuaMPsDge0Y4aiVgdb29Ie6QvUtVVcGwd9itKYR2kqN5S
mQdyj6LT2l2CD98CMFCjDbXtRqkVuAccFo7fwtp3gCIv1SjxLjvGLaAO5Mw9
MmBvB+9RJJMixWvLXSJZuma9raiZDC1PLz1nlUdtRXWWm2pFkMAqEFBPnKMV
4hvRv6Wsc21MEbNu+5I+lIFS/51yVc3b9dpnnsTsMCqzsO3JmaNq9CRMmE4G
3ufC+9olPMedMztQITF8tDwut5XnxKwAIF6NtnLhF+IwZknOPS977nFtQqyx
Q5tr2zTZAP02El7nsPcWL4FQPqoAenESWDFNS9IWoD4nwOYM6aDbrd6/WWGv
ArdiwLWPOgRYXML2EqMb0ZhuF/hcLya2TgH7q3e2ttLUrMoyBFMFJ4eqvdNQ
aWwrn6yeCFi1cVqRYxfZptzvuUOV77qsyHdmZ4IN4/eHTA2PoZjYRyFRyCP5
KIoG5kD4ug+SzBQ28e2MW+y0gfkzmpsTeIgg2gj+/Knl2qMW2LCI1H02SaJW
b9ueYZblynBC17UCIrrAaGUf1IgDnaEkp9rWuxn1Fd65kdFxLKLiRG8efJKa
kNQcv9dEBNnDgPCKn0qXtRn2iMiK5NQ+umjzTtLQbUI6KeVUNRE2tjTLihs4
aX/b0M9IyJ+upOzDXHO2pHcTWASgzUb9sQqjRrlQATL4JrQBqxfB+engsnw9
TUx1mmrArc5LNfutSkbWiPqAElMeO/1SOODVy/Oz84tnL5/+G8UC6mpYz20B
EpxkpqmQp4fs+mD4Ex3GkoRSvtUYu+nthaAQ737PJr33knltlbqhYFIbnc1y
rKrzw9QJL3mKw+IUSUsbuBLZIjApVUUlwD8jUJ+MZn0O1D1/ukEcom2PlXrw
65J/RS8zKFe9LQvDCE1wBdaU6kzcYysyWT3wTrVWkVm5/tQJkCXl5ml/vusY
4JEbRHgc4nQbxrlyfGYjX6rvOJfpjxOw/fgAek5wbPs0uwSUQ2r8og/6FpGo
CVO94NqID8StjToJjLW2NF0+Q41BCgcMZ44lmzwTLTDUxeFNxfncgJHY3vCW
4EZgnvaleFtB3O5N5ph1NNCxo1O8EIro+YZGiVSwemT4jvIPRjMaATrRBkxk
KSbOy1A/+glcfslmGwU1VM/ScotVuzxIrEITv7KpcLZbh7f7olSaW5suAAUP
rPqGd43z+KgTjxPfcQJuhNUCe7EcJrGxpAEZ7q3Mz1EwzkM4IYXyyxC2qufT
TzTT+VwTR/HFSWhtAjsEH/IlgXIpMUOjoFO3rZYUUotiAaxT1NoeApVnDkID
uYG1jyEnq615MXWmYTP00ll/6olOC0XSWqSIGvD6vF+XyK8oqNmiStVn49g7
wqffaQYVNuegYBTzUunvgKBrsOHvPtm0ZYd39kOmX6XPyBvVF9jcJ1UMuZHf
csPZJY5CpASRRw/LzW8ymd00m8rDMqJvSVfhV3V51DJQX66jTCtqkRWqu+O/
27IeEux4A6x46hNbBXWPDTqTqJMJKg2E81Xd6DSxfWXWcuSE46SfbFQ8FUAo
IwgVtko7xnmGhVK/SbRxl9H+aBtxYncYNS8PTHKpvhOnEoNNiHVWq9CdAVia
JHBRKhMu6G1V7WmDydeSQMCUEvOrdsHrhB1X65Z2iTbcB7LiOY+xjtcavyKe
G6RNH5UwSc5zvBJ0jsBepl0CfdYQG6yqPDluuKO32Jy2wLpxz4ONgWemhIW+
neMLYKr39I44Vi4W92Jrz+eX8p9nHJi3sfw4ZM72IJ+qpCPy+ljONoXHTdpp
7mccjQjwmrX0cXMGUVrVKm9RfkozQ/Knojl22noIVJwrHr85DLUNrYNhF0Pf
KasDWtHdUdUrLolxWWk6kTp6lyz9GTkMyrEqNCUQkEcRT+FGfKP5Kki3ZO/7
cxOZkxuSccLrZUVZbMG+Vebj0kEyYL9v8Iy8xz2UUUjiRgQZb3EffZrTTFRs
YGS0PGOwSTIWro40kbMnL5+MtZC6bMqRBrLBxqgtP1Fy4BGxv0GqXsJwONiT
JfZ8gYvBDoOeTV1O39WbTh15yTgum7fFsw7U3e9r0MbQX3i+bIeh+A5IBD5+
S1Gji3a3Q8F22B5n7ummg91r97gLr2EV+IU/VM2PJSju8PDmBgj151nxAum1
Aeu93dEY5wP11P7XcruqfmZ8VgoNescmzk5EfyRK/yz5m38EbWev7bmOtKco
V/3zDN8g4QDdr4X7/5LUI4939AAA

-->
</rfc>