rfc9576.original.xml   rfc9576.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
2) --> ipr="trust200902"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft docName="draft-ietf-privacypass-architecture-16"
-ietf-privacypass-architecture-16" category="info" tocInclude="true" sortRefs="t number="9576"
rue" symRefs="true" version="3"> category="info"
<!-- xml2rfc v2v3 conversion 3.12.10 --> tocInclude="true"
submissionType="IETF"
consensus="true"
obsoletes=""
updates=""
sortRefs="true"
symRefs="true"
version="3"
xml:lang="en">
<front> <front>
<title abbrev="Privacy Pass Architecture">The Privacy Pass Architecture</tit le> <title abbrev="Privacy Pass Architecture">The Privacy Pass Architecture</tit le>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-architecture -16"/> <seriesInfo name="RFC" value="9576"/>
<author initials="A." surname="Davidson" fullname="Alex Davidson"> <author initials="A." surname="Davidson" fullname="Alex Davidson">
<organization>LIP</organization> <organization>LIP</organization>
<address> <address>
<postal> <postal>
<city>Lisbon</city> <city>Lisbon</city>
<country>Portugal</country> <country>Portugal</country>
</postal> </postal>
<email>alex.davidson92@gmail.com</email> <email>alex.davidson92@gmail.com</email>
</address> </address>
</author> </author>
skipping to change at line 37 skipping to change at line 50
<address> <address>
<email>jri@fastly.com</email> <email>jri@fastly.com</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<street>101 Townsend St</street> <street>101 Townsend St</street>
<city>San Francisco</city> <city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2023" month="September" day="25"/>
<keyword>Internet-Draft</keyword> <date year="2024" month="May"/>
<area>sec</area>
<workgroup>privacypass</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
<abstract> <abstract>
<t>This document specifies the Privacy Pass architecture and requirements for <t>This document specifies the Privacy Pass architecture and requirements for
its constituent protocols used for authorization based on privacy-preserving its constituent protocols used for authorization based on privacy-preserving
authentication mechanisms. It describes the conceptual model of Privacy Pass authentication mechanisms. It describes the conceptual model of Privacy Pass
and its protocols, its security and privacy goals, practical deployment models, and its protocols, its security and privacy goals, practical deployment models,
and recommendations for each deployment model that helps ensure the desired and recommendations for each deployment model, to help ensure that the desired
security and privacy goals are fulfilled.</t> security and privacy goals are fulfilled.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Privacy Pass is an architecture for authorization based on privacy-pres erving <t>Privacy Pass is an architecture for authorization based on privacy-pres erving
authentication mechanisms. In other words, relying parties authenticate clients authentication mechanisms. In other words, relying parties authenticate clients
in a privacy-preserving way, i.e., without learning any unique, per-client in a privacy-preserving way, i.e., without learning any unique, per-client
information through the authentication protocol, and then make authorization information through the authentication protocol, and then make authorization
decisions on the basis of that authentication succeeding or failing. Possible decisions on the basis of that authentication succeeding or failing. Possible
authorization decisions might be to provide clients with read access to a authorization decisions might be to provide clients with read access to a
particular resource or write access to a particular resource.</t> particular resource or write access to a particular resource.</t>
<t>Typical approaches for authorizing clients, such as through the use of long-term <t>Typical approaches for authorizing clients, such as through the use of long-term
state (cookies), are not privacy-friendly since they allow servers to track state (cookies), are not privacy friendly, since they allow servers to track
clients across sessions and interactions. Privacy Pass takes a different clients across sessions and interactions. Privacy Pass takes a different
approach: instead of presenting linkable state-carrying information to servers, approach: instead of presenting linkable state-carrying information to servers,
e.g., a cookie indicating whether or not the client is an authorized user or e.g., a cookie indicating whether or not the client is an authorized user or
has completed some prior challenge, clients present unlinkable proofs that has completed some prior challenge, clients present unlinkable proofs that
attest to this information. These proofs, or tokens, are private in the sense 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 that a given token cannot be linked to the protocol interaction where that
token was initially issued.</t> token was initially issued.</t>
<t>At a high level, the Privacy Pass architecture consists of two protocol s: <t>At a high level, the Privacy Pass architecture consists of two protocol s:
redemption and issuance. The redemption protocol, described in redemption and issuance. The redemption protocol, described in
<xref target="AUTHSCHEME"/>, runs between Clients and <xref target="RFC9577"/>, runs between Clients and
Origins (servers). It allows Origins to challenge Clients to present tokens Origins (servers). It allows Origins to challenge Clients to present tokens
for consumption. Origins verify the token to authenticate the Client -- without for consumption. Origins verify the token to authenticate the Client -- without
learning any specific information about the Client -- and then make an authoriza tion learning any specific information about the Client -- and then make an authoriza tion
decision on the basis of the token verifying successfully or not. Depending 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 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, either presents a previously obtained token or invokes an issuance protocol,
such as <xref target="ISSUANCE"/>, to acquire a token to e.g., the protocol described in <xref target="RFC9578"/>, to acquire a token to
present as authorization.</t> present as authorization.</t>
<t>This document describes requirements for both redemption and issuance <t>This document describes requirements for both redemption and issuance
protocols and how they interact. It also provides recommendations on how protocols and how they interact. It also provides recommendations on how
the architecture should be deployed to ensure the privacy of clients and the architecture should be deployed to ensure the privacy of clients and
the security of all participating entities.</t> the security of all participating entities.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in 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> <t>The following terms are used throughout this document:</t>
<dl> <dl>
<dt>Client:</dt> <dt>Client:</dt>
<dd> <dd>
<t>An entity that seeks authorization to an Origin. Using <xref target <t>An entity that seeks authorization to an Origin. Using terminology
="RFC9334"/> terminology, from <xref target="RFC9334"/>,
Clients implement the RATS Attester role.</t> Clients implement the Remote ATtestation procedureS (RATS) Attester role.</t>
</dd> </dd>
<dt>Token:</dt> <dt>Token:</dt>
<dd> <dd>
<t>A cryptographic authentication message used for authorization decis ions, <t>A cryptographic authentication message used for authorization decis ions,
produced as output from an issuance mechanism or protocol.</t> produced as output from an issuance mechanism or protocol.</t>
</dd> </dd>
<dt>Origin:</dt> <dt>Origin:</dt>
<dd> <dd>
<t>An entity that consumes tokens presented by Clients and uses them t o make authorization decisions.</t> <t>An entity that consumes tokens presented by Clients and uses them t o make authorization decisions.</t>
</dd> </dd>
skipping to change at line 140 skipping to change at line 166
<t>An entity that issues tokens to Clients for properties <t>An entity that issues tokens to Clients for properties
attested to by the Attester.</t> attested to by the Attester.</t>
</dd> </dd>
<dt>Issuance:</dt> <dt>Issuance:</dt>
<dd> <dd>
<t>The mechanism by which an Issuer produces tokens for Clients.</t> <t>The mechanism by which an Issuer produces tokens for Clients.</t>
</dd> </dd>
<dt>Attester:</dt> <dt>Attester:</dt>
<dd> <dd>
<t>An entity that attests to properties of Clients for the <t>An entity that attests to properties of Clients for the
purposes of token issuance. Using <xref target="RFC9334"/> terminology, Attester purposes of token issuance. Using terminology from <xref target="RFC9334"/>, Att
s implement esters implement the RATS Verifier role.</t>
the RATS Verifier role.</t>
</dd> </dd>
<dt>Attestation procedure:</dt> <dt>Attestation procedure:</dt>
<dd> <dd>
<t>The procedure by which an Attester determines whether or not a Clie nt <t>The procedure by which an Attester determines whether or not a Clie nt
has the specific set of properties that are necessary for token issuance.</t> has the specific set of properties that are necessary for token issuance.</t>
</dd> </dd>
</dl> </dl>
<t>The trust relationships between each of the entities in this list is fu rther <t>The trust relationships between each of the entities in this list are f urther
elaborated upon in <xref target="privacy-and-trust"/>.</t> elaborated upon in <xref target="privacy-and-trust"/>.</t>
</section> </section>
<section anchor="architecture"> <section anchor="architecture">
<name>Architecture</name> <name>Architecture</name>
<t>The Privacy Pass architecture consists of four logical entities -- <t>The Privacy Pass architecture consists of four logical entities --
Client, Origin, Issuer, and Attester -- that work in concert Client, Origin, Issuer, and Attester -- that work in concert
for token redemption and issuance. This section presents an overview for token redemption and issuance. This section presents an overview
of Privacy Pass, a high-level description of the threat model and of Privacy Pass, a high-level description of the threat model and
privacy goals of the architecture, and the goals and requirements of privacy goals of the architecture, and the goals and requirements of
the redemption and issuance protocols. Deployment variations for the the redemption and issuance protocols. Deployment variations for the
Origin, Issuer, and Attester in this architecture, including Origin, Issuer, and Attester in this architecture, including
considerations for implementing these entities, are further discussed considerations for implementing these entities, are further discussed
in <xref target="deployment"/>.</t> in <xref target="deployment"/>.</t>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>This section describes the typical interaction flow for Privacy Pass. </t> <t>This section describes the typical interaction flow for Privacy Pass, as shown in <xref target="fig-overview"/>.</t>
<ol spacing="normal" type="1"><li>A Client interacts with an Origin by s ending a request or otherwise <ol spacing="normal" type="1"><li>A Client interacts with an Origin by s ending a request or otherwise
interacting with the Origin in a way that triggers a response containing 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> 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 tok en <li>If the Client already has a token available that satisfies the tok en
challenge, e.g., because the Client has a cache of previously issued tokens, 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 re deem its it can skip to <xref format="none" target="step-redemption">step 6</xref> and re deem its
token; see <xref target="hoarding"/> for security considerations of cached token s.</li> token; see <xref target="hoarding"/> for security considerations regarding cache d tokens.</li>
<li>If the Client does not have a token available and decides it wants to <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 obtain one (or more) bound to the token challenge, it then invokes the
issuance protocol. As a prerequisite to the issuance protocol, the Client issuance protocol. As a prerequisite to the issuance protocol, the Client
runs the deployment-specific attestation process that is required for the runs the deployment-specific attestation process that is required for the
designated Issuer. Client attestation can be done via proof of solving a designated Issuer. Client attestation can be done via proof of solving a
CAPTCHA, checking device or hardware attestation validity, etc.; see CAPTCHA, checking device or hardware attestation validity, etc.; see
<xref target="attester"/> for more details.</li> <xref target="attester"/> for more details.</li>
<li>If the attestation process completes successfully, the client crea tes a <li>If the attestation process completes successfully, the client crea tes a
token request to send to the designated Issuer (generally via the Attester, token request to send to the designated Issuer (generally via the Attester,
though it is not required to be sent through 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 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 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 is possible for attestation to run alongside the issuance protocol, e.g., where
Clients send necessary attestation information to the Attester along with their Clients send necessary attestation information to the Attester along with their
token request. If the attestation process fails, the Client receives an error token request. If the attestation process fails, the Client receives an error
and issuance aborts without a token.</li> and issuance aborts without a token.</li>
<li>The Issuer generates a token response based on the token request, which <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 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 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, but response. This token can be validated by anyone with the per-Issuer key but
cannot be linked to the content of the token request or token response.</li> cannot be linked to the content of the token request or token response.</li>
<li> <li>
<t anchor="step-redemption">If the Client has a token, it includes i t in a subsequent request to <t anchor="step-redemption">If the Client has a token, it includes i t in a subsequent request to
the Origin, as authorization. This token is sent only once in reaction to a 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 challenge; Clients do not send tokens more than once, even if they receive
duplicate or redundant challenges. The Origin duplicate or redundant challenges. The Origin
validates that the token was generated by the expected Issuer and has not validates that the token was generated by the expected Issuer and has not
already been redeemed for the corresponding token challenge. If the Client already been redeemed for the corresponding token challenge. If the Client
does not have a token, perhaps because issuance failed, the client does not does not have a token, perhaps because issuance failed, the client does not
reply to the Origin's challenge with a new request.</t> reply to the Origin's challenge with a new request.</t>
</li> </li>
</ol> </ol>
<!-- [rfced] The SVG figures in this document have width or height
specified, which will make the artwork not scale. Please consider
whether scaling should be enabled. Scaling will allow the figures to
be resized when viewed on a mobile device; however, there may be
aesthetic trade-offs (e.g., a given image may appear too large on a
desktop screen, or different figures may scale differently based on
their relative sizes). Please review the HTML and PDF outputs,
noting that we will need you to update the edited copy of the XML and
specify the viewBox item where appropriate.
The warning:
Warning: Found SVG with width or height specified, which will make the
artwork not scale. Specify a viewBox only to let the artwork scale. -->
<figure anchor="fig-overview"> <figure anchor="fig-overview">
<name>Privacy pass redemption and issuance protocol interaction</name> <name>Privacy Pass Redemption and Issuance Protocol Interaction</name>
<artset> <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"> <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 8,32 L 8,64" fill="none" stroke="black"/>
<path d="M 40,64 L 40,208" 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 80,32 L 80,64" fill="none" stroke="black"/>
<path d="M 184,32 L 184,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 216,64 L 216,208" fill="none" stroke="black"/>
<path d="M 256,32 L 256,64" 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 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,64 L 376,144" fill="none" stroke="black"/>
skipping to change at line 288 skipping to change at line 328
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="use-cases"> <section anchor="use-cases">
<name>Use Cases</name> <name>Use Cases</name>
<t>Use cases for Privacy Pass are broad and depend greatly on the deploy ment model <t>Use cases for Privacy Pass are broad and depend greatly on the deploy ment model
as discussed in <xref target="deployment"/>. The initial motivating use case for Privacy Pass as discussed in <xref target="deployment"/>. The initial motivating use case for Privacy Pass
<xref target="PrivacyPassCloudflare"/> was to help rate-limit malicious or other wise abusive <xref target="PrivacyPassCloudflare"/> was to help rate-limit malicious or other wise abusive
traffic from services such as Tor <xref target="DMS2004"/>. The generalized and evolved traffic from services such as Tor <xref target="DMS2004"/>. The generalized and evolved
architecture described in this document also work for this use case. However, architecture described in this document also works for this use case. However,
for added clarity, some more possible use cases are described below.</t> for added clarity, some more possible use cases are described below.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Low-quality, anti-fraud signal for open Internet services. Tokens can attest that <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 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 proced ures form of automated attack such as credential stuffing. Example attestation proced ures
for this use case might be solving some form of CAPTCHA or presenting evidence o f a for this use case might be solving some form of CAPTCHA or presenting evidence o f a
valid, unlocked device in good standing.</li> valid, unlocked device in good standing.</li>
<li>Privacy-preserving authentication for proprietary services. Tokens can attest that <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 the Client is a valid subscriber for a proprietary service, such as a deployment of
Oblivious HTTP <xref target="OHTTP"/>.</li> Oblivious HTTP <xref target="RFC9458"/>.
<!-- [rfced] Section 3.2: This sentence seems to indicate that
Oblivious HTTP is a proprietary service, but we see it described
elsewhere as a standard. Should this sentence be rephrased? If yes,
please provide clarifying text.
Original:
Tokens can attest that the Client is a valid subscriber for a
proprietary service, such as a deployment of Oblivious HTTP
[OHTTP]. -->
</li>
</ul> </ul>
</section> </section>
<section anchor="privacy-and-trust"> <section anchor="privacy-and-trust">
<name>Privacy Goals and Threat Model</name> <name>Privacy Goals and Threat Model</name>
<t>The end-to-end flow for Privacy Pass described in <xref target="overv iew"/> involves three <t>The end-to-end flow for Privacy Pass described in <xref target="overv iew"/> involves three
different types of contexts:</t> different types of contexts:</t>
<dl> <dl>
<dt>Redemption context:</dt> <dt>Redemption context:</dt>
<dd> <dd>
<t>The interactions and set of information shared <t>The interactions and set of information shared
between the Client and Origin, i.e., the information that is provided or between the Client and Origin, i.e., the information that is provided or
otherwise available to the Origin during redemption that might be used otherwise available to the Origin during redemption that might be used
to identify a Client and construct a token challenge. This context includes all to identify a Client and construct a token challenge. This context includes all
information associated with redemption, such as the timestamp of the event, information associated with redemption, such as the timestamp of the event,
Client-visible information (including the IP address), and the Origin name.</t> Client-visible information (including the IP address), and the Origin name.</t>
</dd> </dd>
<dt>Issuance context:</dt> <dt>Issuance context:</dt>
<dd> <dd>
<t>The interactions and set of information shared between the Client , Attester, <t>The interactions and set of information shared between the Client , Attester,
and Issuer, i.e., the information that is provided or otherwise available and Issuer, i.e., the information that is provided or otherwise available
to Attester and Issuer during issuance that might be used to identify a Client. to the Attester and Issuer during issuance that might be used to identify a Clie nt.
This context includes all information associated with issuance, such as the This context includes all information associated with issuance, such as the
timestamp of the event, any Client-visible information (including the IP timestamp of the event, any Client-visible information (including the IP
address), and the Origin name (if revealed during issuance). This does not 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 include the token challenge in its entirety, as that is kept secret from the
Issuer during the issuance protocol.</t> Issuer during the issuance protocol.</t>
</dd> </dd>
<dt>Attestation context:</dt> <dt>Attestation context:</dt>
<dd> <dd>
<t>The interactions and set of information shared between <t>The interactions and set of information shared between
the Client and Attester only, for the purposes of attesting the validity of the Client and Attester only, for the purposes of attesting the validity of
the Client, that is provided or otherwise available during attestation that the Client, that is provided or otherwise available during attestation that
might be used to identify the Client. This context includes all information might be used to identify the Client. This context includes all information
associated with attestation, such as the timestamp of the event and any associated with attestation, such as the timestamp of the event and any
Client-visible information, including information needed for the attestation Client-visible information, including information needed for the attestation
procedure to complete.</t> procedure to complete.</t>
</dd> </dd>
</dl> </dl>
<t>The privacy goals of Privacy Pass assume a threat model in which Orig ins trust <t>The privacy goals of Privacy Pass assume a threat model in which Orig ins trust
specific Issuers to produce tokens, and Issuers in turn trust one or more specific Issuers to produce tokens, and Issuers in turn trust one or more
Attesters to correctly run the attestation procedure with Clients. This Attesters to correctly run the attestation procedure with Clients. This
arrangement ensures that tokens which validate for a given Issuer were only arrangement ensures that tokens that validate for a given Issuer were only
issued to a Client that successfully completed attestation with an Attester issued to a Client that successfully completed attestation with an Attester
that the Issuer trusts. Moreover, this arrangement means that if an Origin that the Issuer trusts. Moreover, this arrangement means that if an Origin
accepts tokens issued by an Issuer that trusts multiple Attesters, then a 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 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 Origin. Whether or not these different entities in the architecture collude
for learning redemption, issuance, or attestation contexts, as well as the for learning redemption, issuance, or attestation contexts, as well as the
necessary preconditions for context unlinkability, depends on the deployment necessary preconditions for context unlinkability, depends on the deployment
model; see <xref target="deployment"/> for more details.</t> model; see <xref target="deployment"/> for more details.</t>
<t>The mechanisms for establishing trust between each entity in this arr angement <t>The mechanisms for establishing trust between each entity in this arr angement
are deployment-specific. For example, in settings where Clients interact with are deployment specific. For example, in settings where Clients interact with
Issuers through an Attester, Attesters and Issuers might use Issuers through an Attester, Attesters and Issuers might use
mutually authenticated TLS to authenticate one another. In settings where mutually authenticated TLS to authenticate one another. In settings where
Clients do not communicate with Issuers through an Attester, the Attesters Clients do not communicate with Issuers through an Attester, the Attesters
might convey this trust via a digital signature that Issuers can verify.</t> might convey this trust via a digital signature that Issuers can verify.</t>
<t>Clients explicitly trust Attesters to perform attestation correctly a nd in a <t>Clients explicitly trust Attesters to perform attestation correctly a nd in a
way that does not violate their privacy. In particular, this means that Attester s way that does not violate their privacy. In particular, this means that Attester s
which may be privy to private information about Clients are trusted to not discl ose that may be privy to private information about Clients are trusted to not disclo se
this information to non-colluding parties. Colluding parties are assumed to have this information to non-colluding parties. Colluding parties are assumed to have
access to the same information; see <xref target="deployment"/> for more about d ifferent access to the same information; see <xref target="deployment"/> for more about d ifferent
deployment models and non-collusion assumptions. However, Clients assume Issuers and deployment models and non-collusion assumptions. However, Clients assume that Is suers and
Origins are malicious.</t> Origins are malicious.</t>
<t>Given this threat model, the privacy goals of Privacy Pass are orient ed around <t>Given this threat model, the privacy goals of Privacy Pass are orient ed around
unlinkability based on redemption, issuance, and attestation contexts, as unlinkability based on redemption, issuance, and attestation contexts, as
described below.</t> described below.</t>
<ol spacing="normal" type="1"><li>Origin-Client unlinkability. This mean s that given two redemption contexts, <ol spacing="normal" type="1"><li>Origin-Client unlinkability. This mean s that given two redemption contexts,
the Origin cannot determine if both redemption contexts correspond to the same 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 Client or two different Clients. Informally, this means that a Client in a
redemption context is indistinguishable from any other Client that might use redemption context is indistinguishable from any other Client that might use
the same redemption context. The set of Clients that share the same redemption the same redemption context. The set of Clients that share the same redemption
context is referred to as a redemption anonymity set.</li> context is referred to as a redemption anonymity set.</li>
skipping to change at line 390 skipping to change at line 442
<li>Redemption context unlinkability. Given two redemption contexts, t he Origin <li>Redemption context unlinkability. Given two redemption contexts, t he Origin
cannot determine which issuance and attestation contexts each redemption cannot determine which issuance and attestation contexts each redemption
corresponds to, even with the collaboration of the Issuer and Attester (should 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 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 about the Client during the issuance and attestation flows cannot be used by the
Origin to compromise Client privacy.</li> Origin to compromise Client privacy.</li>
</ol> </ol>
<t>These unlinkability properties ensure that only the Client is able to correlate <t>These unlinkability properties ensure that only the Client is able to correlate
information that might be used to identify them with activity on the Origin. information that might be used to identify them with activity on the Origin.
The Attester, Issuer, and Origin only receive the information necessary to perfo rm The Attester, Issuer, and Origin only receive the information necessary to perfo rm
their respective functions.</t> their respective functions.
<!-- [rfced] Section 3.3: To what does "them" refer in this
sentence - the properties, the Client/Clients, or something else?
If the suggested text is not correct, please provide clarifying text.
Original:
These unlinkability properties ensure that only the Client is able to
correlate information that might be used to identify them with
activity on the Origin.
Suggested (guessing "Clients"):
These unlinkability properties ensure that only the Clients are able
to correlate information that might be used to identify them with
activity on the Origin. -->
</t>
<t>The manner in which these unlinkability properties are achieved depen ds on the <t>The manner in which these unlinkability properties are achieved depen ds on the
deployment model, type of attestation, and issuance protocol details. For exampl e, deployment model, type of attestation, and issuance protocol details. For exampl e,
as discussed in <xref target="deployment"/>, in some cases it is necessary to us e an anonymization as discussed in <xref target="deployment"/>, in some cases it is necessary to us e an anonymization
service such as Tor <xref target="DMS2004"/> which hides Clients IP addresses. I service that hides Client IP addresses, such as Tor <xref target="DMS2004"/>. In
n general, general,
anonymization services ensures that all Clients which use the service are indist anonymization services ensure that all Clients that use the service are indistin
inguishable guishable
from one another, though in practice there may be small distinguishing features from one another, though in practice there may be small distinguishing features
(TLS fingerprints, HTTP headers, etc). Moreover, Clients generally trust these s ervices (TLS fingerprints, HTTP headers, etc.). Moreover, Clients generally trust these services
to not disclose private Client information (such as IP addresses) to untrusted p arties. to not disclose private Client information (such as IP addresses) to untrusted p arties.
Failure to use an anonymization service when interacting with Attesters, Issuers , or 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, Origins can allow the set of possible Clients to be partitioned by the Client's IP address
and can therefore lead to unlinkability violations. Similarly, malicious Origins and can therefore lead to unlinkability violations. Similarly, malicious Origins
may attempt to link two redemption contexts together by using Client-specific may attempt to link two redemption contexts together by using Client-specific
Issuer public keys. See <xref target="deployment-considerations"/> and <xref tar Issuer public keys. See Sections&nbsp;<xref target="deployment-considerations" f
get="privacy"/> for more ormat="counter"/> and <xref target="privacy" format="counter"/> for more
information.</t> information.
<t>The remainder of this section describes the functional properties and
security <!-- [rfced] Section 3.3: As it appears that Tor is an example of an
IP-hiding service and not the only type of service that can hide IP
addresses, we updated this sentence accordingly. If this is
incorrect, please provide clarifying text. *
* Please note, however, that we do not see any mention of
"anonymization", "hide", "hiding", or "Tor" in Section 4. Will this
sentence be clear to readers? Should Section 3.5.2 be cited instead?
Original:
For example, as discussed in Section 4, in some
cases it is necessary to use an anonymization service such as Tor
[DMS2004] which hides Clients IP addresses.
Currently:
For example, as discussed in Section 4, in some
cases it is necessary to use an anonymization service that hides
Client IP addresses, such as Tor [DMS2004]. -->
</t>
<t>Sections <xref target="redemption" format="counter"/> and <xref targe
t="issuance-protocol" format="counter"/> describe the functional properties and
security
requirements of the redemption and issuance protocols in more detail. <xref targ et="flow"/> requirements of the redemption and issuance protocols in more detail. <xref targ et="flow"/>
describes how information flows between Issuer, Origin, Client, and Attester describes how information flows between the Issuer, Origin, Client, and Attester
through these protocols.</t> through these protocols.</t>
</section> </section>
<section anchor="redemption"> <section anchor="redemption">
<name>Redemption Protocol</name> <name>Redemption Protocol</name>
<t>The Privacy Pass redemption protocol, described in <t>The Privacy Pass redemption protocol, described in
<xref target="AUTHSCHEME"/>, is an authorization protocol <xref target="RFC9577"/>, is an authorization protocol
wherein Clients present tokens to Origins for authorization. Normally, wherein Clients present tokens to Origins for authorization. Normally,
redemption is preceded by a challenge, wherein the Origin challenges redemption is preceded by a challenge, wherein the Origin challenges
Clients for a token with a TokenChallenge (<xref section="2.1" sectionFormat="co Clients for a token with a TokenChallenge (<xref section="2.1" sectionFormat="co
mma" target="AUTHSCHEME"/>) and, mma" target="RFC9577"/>) and,
if possible, Clients present a valid Token (<xref section="2.2" sectionFormat="c if possible, Clients present a valid Token (<xref section="2.2" sectionFormat="c
omma" target="AUTHSCHEME"/>) omma" target="RFC9577"/>)
in reaction to the challenge. This interaction is shown below.</t> in reaction to the challenge. This interaction is shown below.</t>
<figure anchor="fig-redemption"> <figure anchor="fig-redemption">
<name>Challenge and redemption protocol interaction</name> <name>Challenge and Redemption Protocol Interaction</name>
<artset> <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"> <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 8,32 L 8,64" fill="none" stroke="black"/>
<path d="M 40,64 L 40,160" 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 80,32 L 80,64" fill="none" stroke="black"/>
<path d="M 184,32 L 184,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 216,64 L 216,160" fill="none" stroke="black"/>
<path d="M 256,32 L 256,64" 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 8,32 L 80,32" fill="none" stroke="black"/>
<path d="M 184,32 L 256,32" fill="none" stroke="black"/> <path d="M 184,32 L 256,32" fill="none" stroke="black"/>
skipping to change at line 475 skipping to change at line 564
+-- TokenChallenge -->| +-- TokenChallenge -->|
| | <== Issuance protocol ==> | | <== Issuance protocol ==>
|<-- Request+Token ---+ |<-- Request+Token ---+
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Alternatively, when configured to do so, Clients may opportunisticall y present <t>Alternatively, when configured to do so, Clients may opportunisticall y present
Token values to Origins without a corresponding TokenChallenge.</t> Token values to Origins without a corresponding TokenChallenge.</t>
<t>The structure and semantics of the TokenChallenge and Token messages depend <t>The structure and semantics of the TokenChallenge and Token messages depend
on the issuance protocol and token type being used; see <xref target="AUTHSCHEME "/> for on the issuance protocol and token type being used; see <xref target="RFC9577"/> for
more information.</t> more information.</t>
<t>The challenge provides the client with the information necessary to o btain <t>The challenge provides the client with the information necessary to o btain
tokens that the server might subsequently accept in the redemption context. 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, 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"> <ul spacing="normal">
<li>Issuance protocol. The challenge identifies the type of issuance p rotocol <li>Issuance protocol. The challenge identifies the type of issuance p rotocol
required for producing the token. Different issuance protocols have different required for producing the token. Different issuance protocols have different
security properties, e.g., some issuance protocols may produce tokens that security properties, e.g., some issuance protocols may produce tokens that
are publicly verifiable, whereas others may not have this property.</li> are publicly verifiable, whereas others may not have this property.</li>
<li>Issuer identity. Token challenges identify which Issuers are trust ed for a <li>Issuer identity. Token challenges identify which Issuers are trust ed for a
given issuance protocol. As described in <xref target="privacy-and-trust"/>, the choice given issuance protocol. As described in <xref target="privacy-and-trust"/>, the choice
of Issuer determines the type of Attesters and attestation procedures possible 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 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> which Attester was used for a given token issuance event.</li>
<li>Redemption context. Challenges can be bound to a given redemption context, <li>Redemption context. Challenges can be bound to a given redemption context,
which influences a client's ability to pre-fetch and cache tokens. For which influences a client's ability to pre-fetch and cache tokens. For
example, an empty redemption context always allows tokens to be issued and example, an empty redemption context always allows tokens to be issued and
redeemed non-interactively, whereas a fresh and random redemption context redeemed non-interactively, whereas a fresh and random redemption context
means that the redeemed token must be issued only after the client receives means that the redeemed token must be issued only after the client receives
the challenge. See <xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/ > for more details.</li> the challenge. See <xref section="2.1.1" sectionFormat="of" target="RFC9577"/> f or more details.</li>
<li>Per-Origin or cross-Origin. Challenges can be constrained to the O rigin for <li>Per-Origin or cross-Origin. Challenges can be constrained to the O rigin for
which the challenge originated (referred to as per-Origin tokens), or which the challenge originated (referred to as per-Origin tokens) or
can be used across multiple Origins (referred to as cross-Origin tokens). 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 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 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, 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 agrees to admit tokens for any other Origin in the set. See
<xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> for more informat ion on how this set is created.</li> <xref section="2.1.1" sectionFormat="of" target="RFC9577"/> for more information on how this set is created.</li>
</ul> </ul>
<t>Origins that admit cross-Origin tokens bear some risk of allowing tok ens <t>Origins that admit cross-Origin tokens bear some risk of allowing tok ens
issued for one Origin to be spent in an interaction with another Origin. issued for one Origin to be spent in an interaction with another Origin.
In particular, cross-Origin tokens issued based on a challenge for In particular, cross-Origin tokens issued based on a challenge for
one Origin can be redeemed at another Origin in the cross-Origin set, 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 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 use case, Origins may need to maintain state to track redeemed tokens. For
example, Origins that accept cross-Origin tokens across shared redemption example, Origins that accept cross-Origin tokens across shared redemption
contexts SHOULD track which tokens have been redeemed already in those contexts <bcp14>SHOULD</bcp14> track which tokens have already been redeemed in those
redemption contexts, since these tokens can be issued and then spent multiple redemption contexts, since these tokens can be issued and then spent multiple
times for any such challenge. Note that Clients which redeem the times for any such challenge. Note that Clients that redeem the
same token to multiple Origins do risk those Origins being able to link same token to multiple Origins do risk those Origins being able to link
Client activity together, which can disincentivize this behavior. See Client activity together, which can disincentivize this behavior. See
<xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> for discussion.</ t> <xref section="2.1.1" sectionFormat="of" target="RFC9577"/> for discussion.</t>
<t>How Clients respond to token challenges can have privacy implications . <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 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 of Issuer can reveal information about the Client used to partition anonymity
sets; see <xref target="rotation-and-consistency"/> for more information about t hese privacy sets; see <xref target="rotation-and-consistency"/> for more information about t hese privacy
considerations.</t> considerations.</t>
</section> </section>
<section anchor="issuance-protocol"> <section anchor="issuance-protocol">
<name>Issuance Protocol</name> <name>Issuance Protocol</name>
<t>The Privacy Pass issuance protocol, described in <xref target="ISSUAN CE"/>, is a two-message <t>The Privacy Pass issuance protocol, described in <xref target="RFC957 8"/>, is a two-message
protocol that takes as input a TokenChallenge from the redemption protocol protocol that takes as input a TokenChallenge from the redemption protocol
(<xref section="2.1" sectionFormat="comma" target="AUTHSCHEME"/>) and produces a (<xref section="2.1" sectionFormat="comma" target="RFC9577"/>) and produces a To
Token ken
(<xref section="2.2" sectionFormat="comma" target="AUTHSCHEME"/>), as shown in < (<xref section="2.2" sectionFormat="comma" target="RFC9577"/>), as shown in <xre
xref target="fig-overview"/>.</t> f target="fig-overview"/>.
<!-- [rfced] Section 3.5: We see that two issuance protocols are
defined in [ISSUANCE]. Does this sentence refer to one issuance
protocol in particular or to the overall concept of issuance
protocols as defined in [ISSUANCE]?
Original:
The Privacy Pass issuance protocol, described in [ISSUANCE], is a
two-message protocol that takes as input a TokenChallenge from the
redemption protocol ([AUTHSCHEME], Section 2.1) and produces a Token
([AUTHSCHEME], Section 2.2), as shown in Figure 1. -->
</t>
<t>The structure and semantics of the TokenRequest and TokenResponse mes sages <t>The structure and semantics of the TokenRequest and TokenResponse mes sages
depend on the issuance protocol and token type being used; see <xref target="ISS UANCE"/> depend on the issuance protocol and token type being used; see <xref target="RFC 9578"/>
for more information.</t> for more information.</t>
<t>Clients interact with the Attester and Issuer to produce a token for <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 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 issuance is referred to as the attestation context. This context includes all
information associated with the issuance event, such as the timestamp of the information associated with the issuance event, such as the timestamp of the
event and Client-visible information, including the IP address or other event and Client-visible information, including the IP address or other
information specific to the type of attestation done.</t> information specific to the type of attestation done.</t>
<t>Each issuance protocol may be different, e.g., in the number and type s of <t>Each issuance protocol may be different, e.g., in the number and type s of
participants, underlying cryptographic constructions used when issuing tokens, participants, underlying cryptographic constructions used when issuing tokens,
and even privacy properties.</t> and even privacy properties.</t>
<t>Clients initiate the issuance protocol using the token challenge, a r andomly <t>Clients initiate the issuance protocol using the token challenge, a r andomly
generated nonce, and public key for the Issuer, all of which are the Client's 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; private input to the protocol and ultimately bound to an output Token;
see <xref section="2.2" sectionFormat="of" target="AUTHSCHEME"/> for details. Fu ture specifications see <xref section="2.2" sectionFormat="of" target="RFC9577"/> for details. Futur e specifications
may change or extend the Client's input to the issuance protocol to produce may change or extend the Client's input to the issuance protocol to produce
Tokens with a different structure.</t> Tokens with a different structure.</t>
<t>Token properties vary based on the issuance protocol. Important prope rties <t>Token properties vary based on the issuance protocol. Important prope rties
supported in this architecture are described below.</t> supported in this architecture are described below.</t>
<ol spacing="normal" type="1"><li>Public verifiability. This means the T oken can be verified using the Issuer <ol spacing="normal" type="1"><li>Public verifiability. This means that the Token can be verified using the Issuer
public key. A Token that does not have public verifiability can only be verified public key. A Token that does not have public verifiability can only be verified
using the Issuer secret key.</li> using the Issuer secret key.</li>
<li>Public metadata. This means that the Token can be cryptographicall y bound to <li>Public metadata. This means that the Token can be cryptographicall y bound to
arbitrary public information. See <xref target="metadata-privacy"/> for privacy considerations arbitrary public information. See <xref target="metadata-privacy"/> for privacy considerations
of public metadata.</li> regarding public metadata.</li>
<li>Private metadata. This means that the Token can be cryptographical ly bound to <li>Private metadata. This means that the Token can be cryptographical ly bound to
arbitrary private information, i.e., information that the Client does not observ e arbitrary private information, i.e., information that the Client does not observ e
during Token issuance or redemption. See <xref target="metadata-privacy"/> for p rivacy during Token issuance or redemption. See <xref target="metadata-privacy"/> for p rivacy
considerations of private metadata.</li> considerations regarding private metadata.</li>
</ol> </ol>
<t>The issuance protocol itself can be any interactive protocol between Client, <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 Issuer, or other parties that produces a valid token bound to the Client's
private input, subject to the following security requirements.</t> private input, subject to the following security requirements.</t>
<ol spacing="normal" type="1"><li>Unconditional input secrecy. The issua nce protocol MUST NOT reveal anything <ol spacing="normal" type="1"><li>Unconditional input secrecy. The issua nce protocol <bcp14>MUST NOT</bcp14> reveal anything
about the Client's private input, including the challenge and nonce, to the about the Client's private input, including the challenge and nonce, to the
Attester or Issuer, regardless of the hardness assumptions of the underlying Attester or Issuer, regardless of the hardness assumptions of the underlying
cryptographic protocol(s). This property is sometimes also referred to as cryptographic protocol(s). This property is sometimes also referred to as
blindness.</li> blindness.</li>
<li>One-more forgery security. The issuance protocol MUST NOT allow ma licious <li>One-more forgery security. The issuance protocol <bcp14>MUST NOT</ bcp14> allow malicious
Clients or Attesters (acting as Clients) to forge tokens offline or otherwise Clients or Attesters (acting as Clients) to forge tokens offline or otherwise
without interacting with the Issuer directly.</li> without interacting with the Issuer directly.</li>
<li>Concurrent security. The issuance protocol MUST be safe to run con <li>Concurrent security. The issuance protocol <bcp14>MUST</bcp14> be
currently safe to run concurrently
with arbitrarily many Clients, Attesters and Issuers.</li> with arbitrarily many Clients, Attesters, and Issuers.</li>
</ol> </ol>
<t>See <xref target="extensions"/> for requirements on new issuance prot ocol variants and <t>See <xref target="extensions"/> for requirements on new issuance prot ocol variants and
related extensions.</t> related extensions.</t>
<t>In the sections below, we describe the Attester and Issuer roles in m ore <t>In the sections below, we describe the Attester and Issuer roles in m ore
detail.</t> detail.</t>
<section anchor="attester"> <section anchor="attester">
<name>Attester Role</name> <name>Attester Role</name>
<t>In Privacy Pass, attestation is the process by which an Attester be ars <t>In Privacy Pass, attestation is the process by which an Attester be ars
witness to, confirms, or authenticates a Client so as to verify properties witness to, confirms, or authenticates a Client so as to verify properties
about the Client that are required for Issuance. Issuers trust Attesters about the Client that are required for issuance. Issuers trust Attesters
to perform attestation correctly, i.e., to implement attestation procedures to perform attestation correctly, i.e., to implement attestation procedures
in a way that are not subverted or bypassed by malicious Clients.</t> in such a way that those procedures are not subverted or bypassed by malicious C
lients.
<!-- [rfced] Section 3.5.1: As it appears that "are not subverted"
refers to the procedures (per "if an attestation procedure is
compromised or subverted" later in this section), we updated this
sentence accordingly. If this is incorrect, please clarify "in a
way that are".
Original:
Issuers
trust Attesters to perform attestation correctly, i.e., to implement
attestation procedures in a way that are not subverted or bypassed by
malicious Clients.
Currently:
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 <t><xref target="RFC9334"/> describes an architecture for attestation procedures. Using
that architecture as a conceptual basis, Clients are RATS attesters that that architecture as a conceptual basis, Clients are RATS Attesters that
produce attestation evidence, and Attesters are RATS verifiers that produce attestation evidence, and Attesters are RATS Verifiers that
appraise the validity of attestation evidence.</t> appraise the validity of attestation evidence.</t>
<t>The type of attestation procedure is a deployment-specific option a nd outside <t>The type of attestation procedure is a deployment-specific option a nd outside
the scope of the issuance protocol. Example attestation procedures are below.</t > the scope of the issuance protocol. Example attestation procedures are below.</t >
<ul spacing="normal"> <ul spacing="normal">
<li>Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to <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 have this capability for the purpose of being ruled out as a bot or otherwise
automated Client.</li> automated Client.</li>
<li>Presenting evidence of Client device validity. Some Clients run on trusted <li>Presenting evidence of Client device validity. Some Clients run on trusted
hardware that are capable of producing device-level attestation evidence.</li> hardware that is capable of producing device-level attestation evidence.
<li>Proving properties about Client state. Clients can be associated
with state <!-- [rfced] Section 3.5.1: As it appears that "capable of producing
device-level attestation evidence" refers to the hardware and not to
the Clients, we updated this sentence accordingly. If this is not
correct, please provide clarifying text.
Original:
Some Clients run
on trusted hardware that are capable of producing device-level
attestation evidence.
Currently:
Some Clients run
on trusted hardware that is capable of producing device-level
attestation evidence. -->
</li>
<li>Proving properties about Client state. Clients can be associated
with state,
and the Attester can verify this state. Examples of state include the and the Attester can verify this state. Examples of state include the
Client's geographic region and whether the Client has a valid Client's geographic region and whether the Client has a valid
application-layer account.</li> application-layer account.</li>
</ul> </ul>
<t>Attesters may support different types of attestation procedures.</t > <t>Attesters may support different types of attestation procedures.</t >
<t>Each attestation procedure has different security properties. For <t>Each attestation procedure has different security properties. For
example, attesting to having a valid account is different from attesting to example, attesting to having a valid account is different from attesting to
running on trusted hardware. Supporting multiple attestation procedures is running on trusted hardware. Supporting multiple attestation procedures is
an important step towards ensuring equitable access for Clients; see <xref targe t="discrimination"/>.</t> an important step towards ensuring equitable access for Clients; see <xref targe t="discrimination"/>.</t>
<t>The role of the Attester in the issuance protocol and its impact on privacy <t>The role of the Attester in the issuance protocol and its impact on privacy
depends on the type of attestation procedure, issuance protocol, and deployment depends on the type of attestation procedure, issuance protocol, and deployment
model. For instance, increasing the number of required attestation procedures model. For instance, increasing the number of required attestation procedures
could decrease the overall anonymity set size. As an example, the number of Clie nts could decrease the overall anonymity set size. As an example, the number of Clie nts
that have solved a CAPTCHA in the past day, that have a valid account, and that 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 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 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 privac of how the variety of attestation procedures can negatively impact Client privac
y.</t> y.
<!-- [rfced] Section 3.5.1: To what does "depends" refer in this
sentence - only to the role of the Attester, or to both the role of
the Attester and its impact on privacy (in which case "depends"
should be "depend")?
Original:
The role of the Attester in the issuance protocol and its impact on
privacy depends on the type of attestation procedure, issuance
protocol, and deployment model. -->
</t>
<t>Depending on the issuance protocol, the Issuer might learn <t>Depending on the issuance protocol, the Issuer might learn
information about the Origin. To ensure Issuer-Client unlinkability, the Issuer information about the Origin. To ensure Issuer-Client unlinkability, the Issuer
should be unable to link that information to a specific Client. For such should be unable to link that information to a specific Client. For such
issuance protocols where the Attester has access to Client-specific issuance protocols where the Attester has access to Client-specific
information, such as is the case for attestation procedures that involve information, such as is the case for attestation procedures that involve
Client-specific information (such as application-layer account information) Client-specific information (such as application-layer account information)
or for deployment models where the Attester learns Client-specific 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 (such as Client IP addresses), Clients trust the Attester to not share any
Client-specific information with the Issuer. In deployments where the Attester Client-specific information with the Issuer. In deployments where the Attester
does not learn Client-specific information, or where the Attester and Issuer are does not learn Client-specific information or where the Attester and Issuer are
operated by the same entity (such as in the Joint Attester and Issuer model 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 described in <xref target="deploy-joint-issuer"/>), the Client does not need to explicitly
trust the Attester in this regard.</t> trust the Attester in this regard.</t>
<t>Issuers trust Attesters to correctly and reliably perform attestati on. However, <t>Issuers trust Attesters to correctly and reliably perform attestati on. However,
certain types of attestation can vary in value over time, e.g., if the certain types of attestation can vary in value over time, e.g., if the
attestation procedure is compromised. Broken attestation procedure is compromised. Broken
attestation procedures are considered exceptional events and require attestation procedures are considered exceptional events and require
configuration changes to address the underlying cause. For example, if configuration changes to address the underlying cause. For example, if
an attestation procedure is compromised or subverted because of a zero-day an attestation procedure is compromised or subverted because of a zero-day
exploit on devices that implement the attestation procedure, then the exploit on devices that implement the attestation procedure, then the
corresponding attestation procedure should be untrusted until the exploit is corresponding attestation procedure should be untrusted until the exploit is
patched. Addressing changes in attestation quality is therefore a patched. Addressing changes in attestation quality is therefore a
deployment-specific task. In Split Attester and Issuer deployments (see deployment-specific task. In Split Attester and Issuer deployments (see
<xref target="deploy-split"/>), Issuers can choose to remove compromised Atteste rs from <xref target="deploy-split"/>), Issuers can choose to remove compromised Atteste rs from
their trusted set until the compromise is patched.</t> their trusted set until the compromise is patched.
<!-- [rfced] Section 3.5.1:
a) Should "types of attestation" be "types of attestation
procedures" here, or perhaps "types of attestations"?
Original:
Issuers trust Attesters to correctly and reliably perform
attestation. However, certain types of attestation can vary in value
over time, e.g., if the attestation procedure is compromised.
b) As we see that the title of Section 4.4 is "Split Origin,
Attester, Issuer", please confirm that "Split Attester and Issuer
deployments" (i.e., no mention of "Origin") will be clear to readers.
Original:
In Split Attester
and Issuer deployments (see Section 4.4), 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 wit h at least <t>From the perspective of an Origin, tokens produced by an Issuer wit h at least
one compromised Attester cannot be trusted assuming the Origin does not know one compromised Attester cannot be trusted, assuming that the Origin does not kn ow
which attestation procedure was used for issuance. This is because the Origin which attestation procedure was used for issuance. This is because the Origin
cannot distinguish between tokens that were issued via compromised Attesters cannot distinguish between tokens that were issued via compromised Attesters
and tokens that were issued via uncompromised Attesters absent some and tokens that were issued via uncompromised Attesters, absent some
distinguishing information in the tokens themselves or from the Issuer. As a distinguishing information in the tokens themselves or from the Issuer. As a
result, until the attestation procedure is fixed, the Issuer cannot be trusted 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 by Origins. Moreover, as a consequence, any tokens issued by an Issuer with a
compromised attester may no longer be trusted by Origins, even if those tokens compromised Attester may no longer be trusted by Origins, even if those tokens
were issued to Clients interacting with an uncompromised Attester.</t> were issued to Clients interacting with an uncompromised Attester.</t>
</section> </section>
<section anchor="issuer-role"> <section anchor="issuer-role">
<name>Issuer Role</name> <name>Issuer Role</name>
<t>In Privacy Pass, the Issuer is responsible for completing the issua nce protocol <t>In Privacy Pass, the Issuer is responsible for completing the issua nce protocol
for Clients that complete attestation through a trusted Attester. As described for Clients that complete attestation through a trusted Attester. As described
in <xref target="attester"/>, Issuers explicitly trust Attesters to correctly an d reliably in <xref target="attester"/>, Issuers explicitly trust Attesters to correctly an d reliably
perform attestation. Origins explicitly trust Issuers to only issue tokens perform attestation. Origins explicitly trust Issuers to only issue tokens
from trusted Attesters. Clients do not explicitly trust Issuers.</t> from trusted Attesters. Clients do not explicitly trust Issuers.</t>
<t>Depending on the deployment model case, issuance may require some f orm of <t>Depending on the deployment model case, issuance may require some f orm of
Client anonymization service, similar to an IP-hiding proxy, so that Issuers Client anonymization service, similar to an IP-hiding proxy, so that Issuers
cannot learn information about Clients. This can be provided by an explicit 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, 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="DMS 2004"/>. such as through the use of an IP-hiding proxy service like Tor <xref target="DMS 2004"/>.
In general, Clients SHOULD minimize or remove identifying In general, Clients <bcp14>SHOULD</bcp14> minimize or remove identifying
information where possible when invoking the issuance protocol.</t> information where possible when invoking the issuance protocol.</t>
<t>Issuers are uniquely identifiable by all Clients with a consistent <t>Issuers are uniquely identifiable by all Clients with a consistent
identifier. In a web context, this identifier might be the Issuer host name. identifier. In a web context, this identifier might be the Issuer hostname.
Issuers maintain one or more configurations, including issuance key pairs, for Issuers maintain one or more configurations, including issuance key pairs, for
use in the issuance protocol. Each configuration is assumed to have a unique 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. and canonical identifier, sometimes referred to as a key identifier or key ID.
Issuers can rotate these configurations as needed to mitigate risk of compromise ; Issuers can rotate these configurations as needed to mitigate the risk of compro mise;
see <xref target="rotation-and-consistency"/> for more considerations around con figuration see <xref target="rotation-and-consistency"/> for more considerations around con figuration
rotation. The Issuer public key for each active configuration is made available rotation. The Issuer public key for each active configuration is made available
to Origins and Clients for use in the issuance and redemption protocols.</t> to Origins and Clients for use in the issuance and redemption protocols.</t>
</section> </section>
<section anchor="metadata"> <section anchor="metadata">
<name>Issuance Metadata</name> <name>Issuance Metadata</name>
<t>Certain instantiations of the issuance protocol may permit public o r private <t>Certain instantiations of the issuance protocol may permit public o r private
metadata to be cryptographically bound to a token. As an example, one metadata to be cryptographically bound to a token. As an example, one
trivial way to include public metadata is to assign a unique Issuer trivial way to include public metadata is to assign a unique Issuer
public key for each value of metadata, such that N keys yields public key for each value of metadata, such that N keys yields
log<sub>2</sub>(N) bits of metadata. Metadata may be public or private.</t> log<sub>2</sub>(N) bits of metadata. Metadata may be public or private.
<t>Public metadata is that which clients can observe as part of the to
ken <!-- [rfced] Section 3.5.3: Are some words missing from this
issuance flow. Public metadata can either be transparent or opaque. For sentence, or should "N keys yields" be "N keys yield"?
example, transparent public metadata is a value that the client either
generates itself, or the Issuer provides during the issuance flow and Original:
the client can check for correctness. Opaque public metadata is metadata As an
example, one trivial way to include public metadata is to assign a
unique Issuer public key for each value of metadata, such that N keys
yields log_2(N) bits of metadata. -->
</t>
<t>Public metadata is metadata that clients can observe as part of the
token
issuance flow. Public metadata can be either transparent or opaque. For
example, transparent public metadata is a value that either the client
generates itself or the Issuer provides during the issuance flow and that the
client can check for correctness. Opaque public metadata is metadata
the client can see but cannot check for correctness. As an example, the the client can see but cannot check for correctness. As an example, the
opaque public metadata might be a "fraud detection signal", computed on opaque public metadata might be a "fraud detection signal", computed on
behalf of the Issuer, during token issuance. Generally speaking, Clients behalf of the Issuer, during token issuance. Generally speaking, Clients
cannot determine if this value is generated in a way that permits tracking.</t> cannot determine if this value is generated in a way that permits tracking.</t>
<t>Private metadata is that which Clients cannot observe as part of th <t>Private metadata is metadata that Clients cannot observe as part of
e token the token
issuance flow. Such instantiations can be built on the Private Metadata Bit issuance flow. Such instantiations can be built on the private metadata bit
construction from Kreuter et al. <xref target="KLOR20"/> construction from Kreuter et al.&nbsp;<xref target="KLOR20"/>
or the attribute-based VOPRF from Huang et al. <xref target="HIJK21"/>.</t> or the attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF) from H
uang et al.&nbsp;<xref target="HIJK21"/>.</t>
<t>Metadata can be arbitrarily long or bounded in length. The amount o f permitted <t>Metadata can be arbitrarily long or bounded in length. The amount o f permitted
metadata may be determined by application or by the underlying cryptographic 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 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 public and private metadata bits. Every bit of metadata can be used to
partition the Client issuance or redemption anonymity sets; see partition the Client issuance or redemption anonymity sets; see
<xref target="metadata-privacy"/> for more information.</t> <xref target="metadata-privacy"/> for more information.</t>
</section> </section>
<section anchor="extensions"> <section anchor="extensions">
<name>Future Issuance Protocol Requirements</name> <name>Future Issuance Protocol Requirements</name>
<t>The Privacy Pass architecture and ecosystem are both intended to be receptive <t>The Privacy Pass architecture and ecosystem are both intended to be receptive
to extensions that expand the current set of functionalities through new to extensions that expand the current set of functionalities through new
issuance protocols. Each new issuance protocol and extension MUST adhere issuance protocols. Each new issuance protocol and extension <bcp14>MUST</bcp14> adhere
to the following requirements:</t> to the following requirements:</t>
<ol spacing="normal" type="1"><li>Include a detailed analysis of the p rivacy impacts of the extension, why <ol spacing="normal" type="1"><li>Include a detailed analysis of the p rivacy impacts of the extension, why
these impacts are justified, and guidelines on how to use the protocol these impacts are justified, and guidelines on how to use the protocol
to mitigate or minimize negative deployment or privacy consequences to mitigate or minimize negative deployment or privacy consequences
discussed in <xref target="deployment-considerations"/> and <xref target="privac y"/>, respectively.</li> discussed in Sections&nbsp;<xref target="deployment-considerations" format="coun ter"/> and <xref target="privacy" format="counter"/>, respectively.</li>
<li>Adhere to the guidelines specified in <xref target="issuer-role" /> for managing Issuer <li>Adhere to the guidelines specified in <xref target="issuer-role" /> for managing Issuer
public key data.</li> public key data.</li>
<li>Clearly specify how to interpret and validate TokenChallenge and Token <li>Clearly specify how to interpret and validate TokenChallenge and Token
messages that are exchanged during the redemption protocol.</li> messages that are exchanged during the redemption protocol.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="flow"> <section anchor="flow">
<name>Information Flow</name> <name>Information Flow</name>
<t>The end-to-end process of redemption and issuance protocols involves information <t>The end-to-end process of redemption and issuance protocols involves information
flowing between Issuer, Origin, Client, and Attester. That information can flowing between the Issuer, Origin, Client, and Attester. That information can
have implications on the privacy goals that Privacy Pass aims to provide 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 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 of information between each party. How this information affects the privacy
goals in particular deployment models is further discussed in <xref target="depl oyment"/>.</t> goals in particular deployment models is further discussed in <xref target="depl oyment"/>.</t>
<section anchor="challenge-flow"> <section anchor="challenge-flow">
<name>Token Challenge Flow</name> <name>Token Challenge Flow</name>
<t>To use Privacy Pass, Origins choose an Issuer from which they are w illing to <t>To use Privacy Pass, Origins choose an Issuer from which they are w illing to
accept tokens. Origins then construct a token challenge using this specified accept tokens. Origins then construct a token challenge using this specified
Issuer and information from the redemption context it shares with the Client. 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 This token challenge is then delivered to a Client. The token challenge conveys
skipping to change at line 771 skipping to change at line 955
presented with multiple issuance protocol options, then the choice of which presented with multiple issuance protocol options, then the choice of which
issuance protocol to use can contribute information about the Client's issuance protocol to use can contribute information about the Client's
capabilities.</li> capabilities.</li>
<li>Issuer configuration. Information about the Issuer configuration , such as <li>Issuer configuration. Information about the Issuer configuration , such as
its identity or the public key used to validate tokens it creates, can be its identity or the public key used to validate tokens it creates, can be
revealed during issuance and contribute to the attestation or issuance revealed during issuance and contribute to the attestation or issuance
contexts.</li> contexts.</li>
<li>Attestation information. The issuance protocol can contribute in formation to <li>Attestation information. The issuance protocol can contribute in formation to
the attestation or issuance contexts based on what attestation procedure the 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 Issuer uses to trust a token request. In particular, a token request that is
validated by a given Attester means that the Client which generated the token validated by a given Attester means that the Client that generated the token
request must be capable of the completing the designated attestation procedure.< request must be capable of completing the designated attestation procedure.</li>
/li>
<li>Origin information. The issuance protocol can contribute informa tion about <li>Origin information. The issuance protocol can contribute informa tion about
the Origin that challenged the Client in <xref target="challenge-flow"/>. In par ticular, the Origin that challenged the Client; see <xref target="challenge-flow"/>. In p articular,
a token request designated for a specific Issuer might imply that the resulting 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 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, 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 i.e., they are tokens that would be accepted at any Origin that accepts the
cross-Origin token.</li> cross-Origin token.
<!-- [rfced] Section 3.6.3: This sentence did not parse. We updated
it as follows. If this is not correct, please clarify "the Client in
Section 3.6.1".
Original:
* Origin information. The issuance protocol can contribute
information about the Origin that challenged the Client in
Section 3.6.1.
Currently:
* Origin information. The issuance protocol can contribute
information about the Origin that challenged the Client; see
Section 3.6.1. -->
</li>
</ul> </ul>
<t>Moreover, a token may contribute information to the issuance attest ation or <t>Moreover, a token may contribute information to the issuance attest ation or
contexts as described below.</t> contexts as described below.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Origin information. The issuance protocol can contribute informa tion about <li>Origin information. The issuance protocol can contribute informa tion about
the Origin in how it responds to a token request. For example, if an Issuer 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 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 on the basis of that information, and the Client interacts with the Issuer
transitively through the Attester, that response can reveal information to the transitively through the Attester, that response can reveal information to the
Attester.</li> Attester.</li>
<li>Token. The token produced by the issuance protocol can contain i nformation <li>Token. The token produced by the issuance protocol can contain i nformation
from the issuance context. In particular, depending on the issuance protocol, from the issuance context. In particular, depending on the issuance protocol,
tokens can contain public or private metadata, and Issuers can choose that tokens can contain public or private metadata, and Issuers can choose that
metadata on the basis of information in the issuance context.</li> metadata on the basis of information in the issuance context.</li>
</ul> </ul>
<t>Exceptional cases in the issuance protocol, such as when either the <t>Exceptional cases in the issuance protocol, such as when either the
Attester or Issuer aborts the protocol, can contribute information to the Attester or Issuer aborts the protocol, can contribute information to the
attestation or issuance contexts. The extent to which information in this attestation or issuance contexts. The extent to which information in this
context harms the Issuer-Client or Attester-Origin unlinkability goals in context harms the Issuer-Client or Attester-Origin unlinkability goals as discus
<xref target="privacy-and-trust"/> depends on deployment model; see <xref target sed in
="deployment"/>. <xref target="privacy-and-trust"/> depends on the deployment model; see <xref ta
rget="deployment"/>.
Clients can choose whether or not to contribute information to these contexts Clients can choose whether or not to contribute information to these contexts
based on local policy or preference.</t> based on local policy or preference.</t>
</section> </section>
<section anchor="redemption-flow"> <section anchor="redemption-flow">
<name>Token Redemption Flow</name> <name>Token Redemption Flow</name>
<t>Clients send tokens to Origins during the redemption protocol. Any information <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. that is added to the token during issuance can therefore be sent to the Origin.
Information can either be explicitly passed in a token, or it can be implicit Information can be either (1)&nbsp;explicitly passed in a token or (2)&nbsp;impl icit
in the way the Client responds to a token challenge. For example, if a Client in the way the Client responds to a token challenge. For example, if a Client
fails to complete issuance, and consequently fails to redeem a token for fails to complete issuance and consequently fails to redeem a token for
a token challenge, this can reveal information to the Origin that a token challenge, this can reveal information to the Origin that
it might not otherwise have access to. However, an Origin cannot necessarily it might not otherwise have access to. However, an Origin cannot necessarily
distinguish between a Client that fails to complete issuance and one that distinguish between a Client that fails to complete issuance and one that
ignores the token challenge altogether.</t> ignores the token challenge altogether.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="deployment"> <section anchor="deployment">
<name>Deployment Models</name> <name>Deployment Models</name>
<t>The Origin, Attester, and Issuer portrayed in <xref target="fig-overvie w"/> can be <t>The Origin, Attester, and Issuer portrayed in <xref target="fig-overvie w"/> can be
instantiated and deployed in a number of ways. The deployment model directly instantiated and deployed in a number of ways. The deployment model directly
influences the manner in which attestation, issuance, and redemption contexts influences the manner in which attestation, issuance, and redemption contexts
are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin
unlinkability.</t> unlinkability.</t>
<t>This section covers some expected deployment models and their correspon ding <t>This section covers some expected deployment models and their correspon ding
security and privacy considerations. Each deployment model is described in security and privacy considerations. Each deployment model is described in
terms of the trust relationships and communication patterns between Client, terms of the trust relationships and communication patterns between the Client,
Attester, Issuer, and Origin. Entities drawn within the same bounding box are 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. assumed to be operated by the same party and are therefore able to collude.
Collusion can enable linking of attestation, issuance, and redemption contexts. Collusion can enable linking of attestation, issuance, and redemption contexts.
Entities not drawn within the same bounding box are assumed to not Entities not drawn within the same bounding box are assumed to not
collude, meaning that entities operated by separate parties that do not collude. collude, meaning that entities operated by separate parties that do not collude.
Mechanisms for enforcing non-collusion are out of scope for this architecture.</ Mechanisms for enforcing non-collusion are out of scope for this architecture.
t>
<!-- [rfced] Section 4: This sentence does not parse. If the
suggested text is not correct, please provide clarifying text.
Original:
Entities not drawn within the same bounding box are
assumed to not collude, meaning that entities operated by separate
parties that do not collude.
Suggested (the entities, rather than the parties, do not collude):
Entities not drawn within the same bounding box (i.e., operated by
separate parties) are assumed to not collude. -->
</t>
<section anchor="deploy-shared"> <section anchor="deploy-shared">
<name>Shared Origin, Attester, Issuer</name> <name>Shared Origin, Attester, Issuer</name>
<t>In this model, the Origin, Attester, and Issuer are all operated by t he same <t>In this model, the Origin, Attester, and Issuer are all operated by t he same
entity, as shown in <xref target="fig-deploy-shared"/>.</t> entity, as shown in <xref target="fig-deploy-shared"/>.</t>
<figure anchor="fig-deploy-shared"> <figure anchor="fig-deploy-shared">
<name>Shared Deployment Model</name> <name>Shared Deployment Model</name>
<artset> <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"> <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 8,48 L 8,80" fill="none" stroke="black"/>
<path d="M 40,80 L 40,240" fill="none" stroke="black"/> <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
skipping to change at line 932 skipping to change at line 1146
</figure> </figure>
<t>This model represents the initial deployment of Privacy Pass, as desc ribed in <t>This model represents the initial deployment of Privacy Pass, as desc ribed in
<xref target="PrivacyPassCloudflare"/>. In this model, the Attester, Issuer, and Origin <xref target="PrivacyPassCloudflare"/>. In this model, the Attester, Issuer, and Origin
share the attestation, issuance, and redemption contexts. As a result, share the attestation, issuance, and redemption contexts. As a result,
attestation mechanisms that can uniquely identify a Client, e.g., requiring attestation mechanisms that can uniquely identify a Client, e.g., requiring
that Clients authenticate with some type of application-layer account, are that Clients authenticate with some type of application-layer account, are
not appropriate, as they could lead to unlinkability violations.</t> not appropriate, as they could lead to unlinkability violations.</t>
<t>Origin-Client, Issuer-Client, and Attester-Origin unlinkability requi res that <t>Origin-Client, Issuer-Client, and Attester-Origin unlinkability requi res that
issuance and redemption events be separated over time, such as through the use 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 of tokens that correspond to token challenges with an empty redemption context
(see <xref target="redemption"/>), or be separated over space, such as through t he use of an (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> anonymizing service when connecting to the Origin.</t>
</section> </section>
<section anchor="deploy-joint-issuer"> <section anchor="deploy-joint-issuer">
<name>Joint Attester and Issuer</name> <name>Joint Attester and Issuer</name>
<t>In this model, the Attester and Issuer are operated by the same entit <t>In this model, the Attester and Issuer are operated by the same entit
y y,
that is separate from the Origin. The Origin trusts the joint Attester separate from the Origin. The Origin trusts the joint Attester
and Issuer to perform attestation and issue Tokens. Clients interact and Issuer to perform attestation and issue Tokens. Clients interact
with the joint Attester and Issuer for attestation and issuance. This with the joint Attester and Issuer for attestation and issuance. This
arrangement is shown in <xref target="fig-deploy-joint-issuer"/>.</t> arrangement is shown in <xref target="fig-deploy-joint-issuer"/>.</t>
<figure anchor="fig-deploy-joint-issuer"> <figure anchor="fig-deploy-joint-issuer">
<name>Joint Attester and Issuer Deployment Model</name> <name>Joint Attester and Issuer Deployment Model</name>
<artset> <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"> <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 8,48 L 8,80" fill="none" stroke="black"/>
<path d="M 40,80 L 40,240" 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 80,48 L 80,80" fill="none" stroke="black"/>
skipping to change at line 1029 skipping to change at line 1243
+------------- TokenRequest ----------->| | +------------- TokenRequest ----------->| |
|<----------- TokenResponse ------------+ | |<----------- TokenResponse ------------+ |
| | | |
+----------------------- Token -----------------------> +----------------------- Token ----------------------->
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This model is useful if an Origin wants to offload attestation and is suance to <t>This model is useful if an Origin wants to offload attestation and is suance to
a trusted entity. In this model, the Attester and Issuer share an attestation 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 and issuance context for the Client, separate from the Origin's
redemption context.</t> redemption context.
<t>Similar to the Shared Origin, Attester, Issuer model, Issuer-Client a
nd <!-- [rfced] Section 4.2: As it appears that "which is" refers to
Origin-Client unlinkability in this model requires issuance and redemption the attestation and issuance context and not to the Client, we
updated this sentence accordingly. If this update is not correct,
please provide clarifying text.
Original:
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.
Currently:
In this model, the Attester and Issuer
share an attestation and issuance context for the Client, separate
from the Origin's redemption context. -->
</t>
<t>Similar to the shared Origin, Attester, Issuer model, Issuer-Client a
nd
Origin-Client unlinkability in this model requires that issuance and redemption
events, respectively, be separated over time or space. Attester-Origin events, respectively, be separated over time or space. Attester-Origin
unlinkability requires that the Attester and Issuer do not learn the Origin unlinkability requires that the Attester and Issuer do not learn the Origin
for a particular token request. For this reason, issuance protocols that for a particular token request. For this reason, issuance protocols that
require the Issuer to learn information about the Origin, such as that which require the Issuer to learn information about the Origin, such as the issuance p
is described in <xref target="RATE-LIMITED"/>, are not rotocol described in <xref target="I-D.ietf-privacypass-rate-limit-tokens"/>, ar
appropriate since they could lead to Attester-Origin unlinkability violations e not
through the Origin name.</t> appropriate, since they could lead to Attester-Origin unlinkability violations
through the Origin name.
<!-- [rfced] Section 4.2: As it appears that "that which" refers to
the issuance protocol described in [RATE-LIMITED], we updated this
sentence accordingly. If this is incorrect, please provide
clarifying text.
Original:
For this
reason, issuance protocols that require the Issuer to learn
information about the Origin, such as that which is described in
[RATE-LIMITED], are not appropriate since they could lead to
Attester-Origin unlinkability violations through the Origin name.
Currently:
For this
reason, issuance protocols that require the Issuer to learn
information about the Origin, such as the issuance protocol described
in [RATE-LIMITED], are not appropriate, since they could lead to
Attester-Origin unlinkability violations through the Origin name. -->
</t>
</section> </section>
<section anchor="deploy-joint-origin"> <section anchor="deploy-joint-origin">
<name>Joint Origin and Issuer</name> <name>Joint Origin and Issuer</name>
<t>In this model, the Origin and Issuer are operated by the same entity, separate <t>In this model, the Origin and Issuer are operated by the same entity, separate
from the Attester, as shown in the figure below. The Issuer accepts token from the Attester, as shown in <xref target="fig-deploy-joint-origin"/>. The Iss uer accepts token
requests that come from trusted Attesters. Since the Attester and Issuer are requests that come from trusted Attesters. Since the Attester and Issuer are
separate entities, this model requires some mechanism by which Issuers separate entities, this model requires some mechanism by which Issuers
establish trust in the Attester (as described in <xref target="privacy-and-trust "/>). 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 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 directly communicates with the Issuer, one way to establish this trust is via
mutually-authenticated TLS. However, alternative authentication mechanisms are mutually authenticated TLS. However, alternative authentication mechanisms are
possible. This arrangement is shown in <xref target="fig-deploy-joint-origin"/>. possible. This arrangement is shown in <xref target="fig-deploy-joint-origin"/>.
</t>
<!-- [rfced] Section 4.3: Is "This arrangement" an example of an
alternative authentication mechanism? If yes, may we update as
suggested? If not, please clarify "This arrangement".
Original:
However, alternative authentication mechanisms
are possible. This arrangement is shown in Figure 5.
Suggested:
However, alternative authentication mechanisms, such as the
arrangement shown in Figure 5, are possible. -->
</t>
<figure anchor="fig-deploy-joint-origin"> <figure anchor="fig-deploy-joint-origin">
<name>Joint Origin and Issuer Deployment Model</name> <name>Joint Origin and Issuer Deployment Model</name>
<artset> <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"> <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 8,48 L 8,80" fill="none" stroke="black"/>
<path d="M 40,80 L 40,240" 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 80,48 L 80,80" fill="none" stroke="black"/>
<path d="M 168,48 L 168,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,80 L 216,104" fill="none" stroke="black"/>
<path d="M 216,120 L 216,160" fill="none" stroke="black"/> <path d="M 216,120 L 216,160" fill="none" stroke="black"/>
skipping to change at line 1143 skipping to change at line 1408
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This model is useful for Origins that require Client-identifying atte station, <t>This model is useful for Origins that require Client-identifying atte station,
e.g., through the use of application-layer account information, but do not e.g., through the use of application-layer account information, but do not
otherwise want to learn information about individual Clients beyond what is otherwise want to learn information about individual Clients beyond what is
observed during the token redemption, such as Client IP addresses.</t> observed during the token redemption, such as Client IP addresses.</t>
<t>In this model, attestation contexts are separate from issuer and rede mption <t>In this model, attestation contexts are separate from issuer and rede mption
contexts. As a result, any type of attestation is suitable in this model.</t> contexts. As a result, any type of attestation is suitable in this model.</t>
<t>Moreover, any type of token challenge is suitable assuming there is m <t>Moreover, assuming that there is more than one Origin involved, any t
ore than ype of token challenge is suitable, since no single party will have access to th
one Origin involved, since no single party will have access to the identifying e identifying
Client information and unique Origin information. Issuers that produce tokens Client information and unique Origin information. Issuers that produce tokens
for a single Origin are not suitable in this model since an Attester can for a single Origin are not suitable in this model, since an Attester can
infer the Origin from a token request, as described in <xref target="issue-flow" />. However, 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 since the issuance protocol provides input secrecy, the Attester does not learn
details about the corresponding token challenge, such as whether the token details about the corresponding token challenge, such as whether the token
challenge is per-Origin or cross-Origin.</t> challenge is per Origin or across Origins.</t>
</section> </section>
<section anchor="deploy-split"> <section anchor="deploy-split">
<name>Split Origin, Attester, Issuer</name> <name>Split Origin, Attester, Issuer</name>
<t>In this model, the Origin, Attester, and Issuer are all operated by d ifferent <t>In this model, the Origin, Attester, and Issuer are all operated by d ifferent
entities. As with the joint Origin and Issuer model, the Issuer accepts token entities. As with the joint Origin and Issuer model (<xref
target="deploy-joint-origin"/>), the Issuer accepts token
requests that come from trusted Attesters, and the details of that trust requests that come from trusted Attesters, and the details of that trust
establishment depend on the issuance protocol and relationship between establishment depend on the issuance protocol and relationship between the
Attester and Issuer; see <xref target="privacy-and-trust"/>. This arrangement is shown Attester and Issuer; see <xref target="privacy-and-trust"/>. This arrangement is shown
in <xref target="fig-overview"/>.</t> in <xref target="fig-overview"/>.</t>
<t>This is the most general deployment model, and is necessary for some <t>This is the most general deployment model and is necessary for some
types of issuance protocols where the Attester plays a role in token types of issuance protocols where the Attester plays a role in token
issuance; see <xref target="RATE-LIMITED"/> for one such type of issuance protoc ol.</t> issuance; see <xref target="I-D.ietf-privacypass-rate-limit-tokens"/> for one su ch type of issuance protocol.</t>
<t>In this model, the Attester, Issuer, and Origin have a separate view <t>In this model, the Attester, Issuer, and Origin have a separate view
of the Client: the Attester sees potentially sensitive Client identifying of the Client: the Attester sees potentially sensitive Client-identifying
information, such as account identifiers or IP addresses, the Issuer information, such as account identifiers or IP addresses; the Issuer
sees only the information necessary for issuance, and the Origin sees sees only the information necessary for issuance; and the Origin sees
token challenges, corresponding tokens, and Client source information, token challenges, corresponding tokens, and Client source information,
such as their IP address. As a result, attestation, issuance, and redemption 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 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> this model as long as there is more than a single Origin.</t>
<t>As in the Joint Origin and Issuer model in <xref target="deploy-joint -origin"/>, and as <t>As with the Joint Origin and Issuer model (<xref target="deploy-joint -origin"/>), and as
described in <xref target="issue-flow"/>, if the Issuer produces tokens for a si ngle Origin, described in <xref target="issue-flow"/>, if the Issuer produces tokens for a si ngle Origin,
then per-Origin tokens are not appropriate since the Attester can infer the then per-Origin tokens are not appropriate, since the Attester can infer the
Origin from a token request.</t> Origin from a token request.</t>
</section> </section>
</section> </section>
<section anchor="deployment-considerations"> <section anchor="deployment-considerations">
<name>Deployment Considerations</name> <name>Deployment Considerations</name>
<t><xref target="deployment"/> discusses deployment models that are possib le in practice. <t><xref target="deployment"/> discusses deployment models that are possib le in practice.
Beyond possible implications on security and privacy properties of the Beyond possible implications on security and privacy properties of the
resulting system, Privacy Pass deployments can impact the overall ecosystem resulting system, Privacy Pass deployments can impact the overall ecosystem
in two important ways: (1) discriminatory treatment of Clients and the gated in two important ways: (1)&nbsp;discriminatory treatment of Clients and the gate
access to otherwise open services, and (2) centralization. This section d
access to otherwise open services and (2)&nbsp;centralization. This section
describes considerations relevant to these topics.</t> describes considerations relevant to these topics.</t>
<section anchor="discrimination"> <section anchor="discrimination">
<name>Discriminatory Treatment</name> <name>Discriminatory Treatment</name>
<t>Origins can use tokens as a signal for distinguishing between Clients <t>Origins can use tokens as a signal for distinguishing between (1)&nbs p;Clients
that are capable of completing attestation with one Attester trusted by the that are capable of completing attestation with one Attester trusted by the
Origin's chosen Issuer, and Clients that are not capable of doing the same. A Origin's chosen Issuer and (2)&nbsp;Clients that are not capable of doing the sa me. A
consequence of this is that Privacy Pass could enable discriminatory treatment consequence of this is that Privacy Pass could enable discriminatory treatment
of Clients based on Attestation support. For example, an Origin could only of Clients based on attestation support. For example, an Origin could only
authorize Clients that successfully authenticate with a token, prohibiting acces s authorize Clients that successfully authenticate with a token, prohibiting acces s
to all other Clients.</t> to all other Clients.</t>
<t>The type of attestation procedures supported for a particular deploym ent depends <t>The types of attestation procedures supported for a particular deploy ment depend
greatly on the use case. For example, consider a proprietary deployment of Priva cy Pass greatly on the use case. For example, consider a proprietary deployment of Priva cy Pass
that authorizes clients to access a resource such as an anonymization service. I n this that authorizes clients to access a resource such as an anonymization service. I n this
context, it is reasonable to support specific types of attestation procedures th at context, it is reasonable to support specific types of attestation procedures th at
demonstrate Clients can access the resource, such as with an account or specific demonstrate that Clients can access the resource, such as with an account or spe cific
type of device. However, in open deployments of Privacy Pass that are used to type of device. However, in open deployments of Privacy Pass that are used to
safeguard access to otherwise open or publicly accessible resources, diversity safeguard access to otherwise open or publicly accessible resources, diversity
in attestation procedures is critically important so as to not discriminate agai nst in attestation procedures is critically important so as to not discriminate agai nst
Clients that choose certain software, hardware, or identity providers.</t> Clients that choose certain software, hardware, or identity providers.</t>
<t>In principle, Issuers should strive to mitigate discriminatory behavi or by <t>In principle, Issuers should strive to mitigate discriminatory behavi or by
providing equitable access to all Clients. This can be done by working with a 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 requir e set of Attesters that are suitable for all Clients. In practice, this may requir e
tradeoffs in what type of attestation Issuers are willing to trust so as to 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 enable more widespread support. In other words, trusting a variety of Attesters
with a diverse set of attestation procedures would presumably increase support with a diverse set of attestation procedures would presumably increase support
among Clients, though most likely at the expense of decreasing the overall value among Clients, though most likely at the expense of decreasing the overall value
of tokens issued by the Issuer.</t> of tokens issued by the Issuer.</t>
<t>For example, to disallow discriminatory behavior between Clients with and <t>For example, to disallow discriminatory behavior between Clients with and
without device attestation support, an Issuer may wish to support Attesters without device attestation support, an Issuer may wish to support Attesters
that support CAPTCHA-based attestation. This means that the overall attestation 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 value of a Privacy Pass token is bound by the difficulty in spoofing or
bypassing either one of these attestation procedures.</t> bypassing either one of these attestation procedures.</t>
</section> </section>
<section anchor="centralization"> <section anchor="centralization">
<name>Centralization</name> <name>Centralization</name>
<t>A consequence of limiting the number of participants (Attesters or Is suers) in <t>A consequence of limiting the number of participants (Attesters or Is suers) in
Privacy Pass deployments for meaningful privacy is that it forces concentrated Privacy Pass deployments for meaningful privacy is that it forces concentrated
centralization amongst those participants. centralization among those participants.
<xref target="CENTRALIZATION"/> discusses <xref target="RFC9518"/> discusses
several ways in which this might be mitigated. For example, a multi-stakeholder several ways in which this might be mitigated. For example, a multi-stakeholder
governance model could be established to determine what candidate participants governance model could be established to determine what candidate participants
are fit to operate as participants in a Privacy Pass deployment. This is 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> precisely the system used to control the Web's trust model.</t>
<t>Alternatively, Privacy Pass deployments might mitigate this problem t hrough <t>Alternatively, Privacy Pass deployments might mitigate this problem t hrough
implementation. For example, rather than centralize the role of attestation implementation. For example, rather than centralize the role of attestation
in one or few entities, attestation could be a distributed function performed 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 by a quorum of many parties, provided that neither Issuers nor Origins learn
which Attester implementations were chosen. As a result, Clients could have which Attester implementations were chosen. As a result, Clients could have
more opportunities to switch between attestation participants.</t> more opportunities to switch between attestation participants.</t>
</section> </section>
</section> </section>
<section anchor="privacy"> <section anchor="privacy">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>The previous section discusses the impact of deployment details on <t>The previous section discusses the impact of deployment details on
Origin-Client, Issuer-Client, and Attester-Origin unlinkability. Origin-Client, Issuer-Client, and Attester-Origin unlinkability.
The value these properties affords to end users depends on The value these properties afford to end users depends on
the size of anonymity sets in which Clients or Origins are the size of anonymity sets in which Clients or Origins are
unlinkable. For example, consider two different deployments, one wherein unlinkable. For example, consider two different deployments, one wherein
there exists a redemption anonymity set of size two and another there exists a redemption anonymity set of size two and another
wherein there redemption anonymity set of size 2<sup>32</sup>. Although 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 Origin-Client unlinkability guarantees that the Origin cannot link any two
requests to the same Client based on these contexts, respectively, the requests to the same Client based on these contexts, respectively, the
probability of determining the "true" Client is higher the smaller these smaller these sets become, the higher the probability of determining the "true"
sets become.</t> Client.
<!-- [rfced] Section 6: We changed "wherein there redemption
anonymity set" to "wherein there exists a redemption anonymity set"
in this sentence. If this is incorrect, please provide the missing
text.
Original:
For
example, consider two different deployments, one wherein there exists
a redemption anonymity set of size two and another wherein there
redemption anonymity set of size 2^32.
Currently:
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^32. -->
</t>
<t>In practice, there are a number of ways in which the size of anonymity sets <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 may be reduced or partitioned, though they all center around the concept of
consistency. In particular, by definition, all Clients in an anonymity set consistency. In particular, by definition, all Clients in an anonymity set
share a consistent view of information needed to run the issuance and share a consistent view of information needed to run the issuance and
redemption protocols. An example type of information needed to run these redemption protocols. The Issuer public key is an example of the type of informa
protocols is the Issuer public key. When two Clients have inconsistent tion needed to run these protocols. When two Clients have inconsistent
information, these Clients effectively have different redemption contexts and information, these Clients effectively have different redemption contexts and
therefore belong in different anonymity sets.</t> therefore belong in different anonymity sets.</t>
<t>The following sections discuss issues that can influence anonymity set size. <t>The following sections discuss issues that can influence anonymity set size.
For each issue, we discuss mitigations or safeguards to protect against the For each issue, we discuss mitigations or safeguards to protect against the
underlying problem.</t> underlying problem.
<!-- [rfced] Section 6: As written, "The following sections" appears
to point to Sections 6.1 through 6.3 and Section 7. Should "The
following sections" be "The following subsections" or perhaps
"The remainder of this section and Section 7"? Please let us know
your preference.
Original (the next sentence is included for context):
The following sections 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"> <section anchor="metadata-privacy">
<name>Partitioning by Issuance Metadata</name> <name>Partitioning by Issuance Metadata</name>
<t>Any public or private metadata bits of information can be used to fur ther <t>Any public or private metadata bits of information can be used to fur ther
segment the size of the Client's anonymity set. Any Issuer that wanted to segment the size of the Client's anonymity set. Any Issuer that wanted to
track a single Client could add a single metadata bit to Client tokens. For track a single Client could add a single metadata bit to Client tokens. For
the tracked Client it would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding the tracked 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 additional bits provides an exponential increase in tracking granularity
similarly to introducing more Issuers (though with more potential targeting).</t > in a manner similar to introducing more Issuers (though with more potential targ eting).</t>
<t>For this reason, deployments should take the amount of metadata used by an Issuer <t>For this reason, deployments should take the amount of metadata used by an Issuer
in creating redemption tokens must into account -- together with the bits in creating redemption tokens must into account, together with the bits
of information that Issuers may learn about Clients otherwise. Since this of information that Issuers may learn about Clients otherwise. Since this
metadata may be useful for practical deployments of Privacy Pass, Issuers metadata may be useful for practical deployments of Privacy Pass, Issuers
must balance this against the reduction in Client privacy.</t> must balance this against the reduction in Client privacy.
<!-- [rfced] Section 6.1: This sentence does not parse; for one
thing, the "should" and "must" conflict with each other. Also,
"tokens must into account" needs to be rephrased. Please provide
clarifying text.
Original:
For this reason, deployments should take the amount of metadata used
by an Issuer in creating redemption tokens must into account -
together with the bits of information that Issuers may learn about
Clients otherwise. -->
</t>
<t>The number of permitted metadata values often depends on deployment-s pecific <t>The number of permitted metadata values often depends on deployment-s pecific
details. In general, limiting the amount of metadata permitted helps limit the details. In general, limiting the amount of metadata permitted helps limit the
extent to which metadata can uniquely identify individual Clients. Failure to extent to which metadata can uniquely identify individual Clients. Failure to
bound the number of possible metadata values can therefore lead to reduction in bound the number of possible metadata values can therefore lead to a reduction i n
Client privacy. Most token types do not admit any metadata, so this bound is Client privacy. Most token types do not admit any metadata, so this bound is
implicitly enforced.</t> implicitly enforced.</t>
</section> </section>
<section anchor="rotation-and-consistency"> <section anchor="rotation-and-consistency">
<name>Partitioning by Issuance Consistency</name> <name>Partitioning by Issuance Consistency</name>
<t>Anonymity sets can be partitioned by information used for the issuanc e <t>Anonymity sets can be partitioned by information used for the issuanc e
protocol, including: metadata, Issuer configuration (keys), and Issuer protocol, including metadata, Issuer configuration (keys), and Issuer
selection.</t> selection.</t>
<t>Any issuance metadata bits of information can be used to partition th e Client <t>Any issuance metadata bits of information can be used to partition th e Client
anonymity set. For example, any Issuer that wanted to track a single 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 it could add a single metadata bit to Client tokens. For the tracked Client, it
would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding additional bit s provides an would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding additional bit s provides an
exponential increase in tracking granularity similarly to introducing more exponential increase in tracking granularity in a manner similar to introducing more
Issuers (though with more potential targeting).</t> Issuers (though with more potential targeting).</t>
<t>The number of active Issuer configurations also contributes to anonym ity set <t>The number of active Issuer configurations also contributes to anonym ity set
partitioning. In particular, when an Issuer updates their configuration and partitioning. In particular, when an Issuer updates their configuration and
the corresponding key pair, any Client that invokes the issuance protocol with the corresponding key pair, any Client that invokes the issuance protocol with
this configuration becomes part of a set of Clients which also ran the this configuration becomes part of a set of Clients that also ran the
issuance protocol using the same configuration. Issuer configuration updates, issuance protocol using the same configuration. Issuer configuration updates,
e.g., due to key rotation, are an important part of hedging against long-term 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 private key compromise. In general, key rotations represent a trade-off between
Client privacy and Issuer security. Therefore, it is important that key 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 rotations occur on a regular cycle to reduce the harm of an Issuer key
compromise.</t> compromise.</t>
<t>Lastly, if Clients are willing to issue and redeem tokens from a larg e number <t>Lastly, if Clients are willing to issue and redeem tokens from a larg e number
of Issuers for a specific Origin, and that Origin accepts tokens from all of Issuers for a specific Origin and that Origin accepts tokens from all
Issuers, partitioning can occur. As an example, if a Client obtains tokens from 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 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 Issuer, the Origin can learn information about the Client. This arrangement
might happen if Clients request tokens from different Issuers, each of which might happen if Clients request tokens from different Issuers, each of which
have different Attester preferences. Each per-Issuer token that a Client holds has different Attester preferences. Each per-Issuer token that a Client holds
essentially corresponds to a bit of information about the Client that Origin 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 learns. Therefore, there is an exponential loss in privacy relative to the
number of Issuers.</t> number of Issuers.</t>
<t>The fundamental problem here is that the number of possible issuance <t>The fundamental problem here is that the number of possible issuance
configurations, including the keys in use and the Issuer identities themselves, configurations, including the keys in use and the Issuer identities themselves,
can partition the Client anonymity set. To mitigate this problem, Clients can partition the Client anonymity set. To mitigate this problem, Clients
SHOULD bound the number of active issuance configurations per Origin as well as <bcp14>SHOULD</bcp14> bound the number of active issuance configurations per Ori
across Origins. Moreover, Clients SHOULD employ some form of consistency gin as well as
across Origins. Moreover, Clients <bcp14>SHOULD</bcp14> employ some form of cons
istency
mechanism to ensure that they receive the same configuration information and mechanism to ensure that they receive the same configuration information and
are not being actively partitioned into smaller anonymity sets. See are not being actively partitioned into smaller anonymity sets. See
<xref target="CONSISTENCY"/> for possible consistency <xref target="I-D.ietf-privacypass-key-consistency"/> for possible consistency
mechanisms. Depending on the deployment, the Attester might assist the Client mechanisms. Depending on the deployment, the Attester might assist the Client
in applying these consistency checks across clients. Failure to apply a in applying these consistency checks across clients. Failure to apply a
consistency check can allow Client-specific keys to violate Origin-Client consistency check can allow Client-specific keys to violate Origin-Client
unlinkability.</t> unlinkability.</t>
</section> </section>
<section anchor="partitioning-by-side-channels"> <section anchor="partitioning-by-side-channels">
<name>Partitioning by Side-Channels</name> <name>Partitioning by Side Channels</name>
<t>Side-channel attacks, such as those based on timing correlation, coul d be <t>Side-channel attacks, such as those based on timing correlation, coul d be
used to reduce anonymity set size. In particular, used to reduce anonymity set size. In particular,
for interactive tokens that are bound to a Client-specific redemption for interactive tokens that are bound to a Client-specific redemption
context, the anonymity set of Clients during the issuance protocol consists context, the anonymity set of Clients during the issuance protocol consists
of those Clients that started issuance between the time of the Origin's of those Clients that started issuance between the time of the Origin's
challenge and the corresponding token redemption. Depending on the number challenge and the corresponding token redemption. Depending on the number
of Clients using a particular Issuer during that time window, the set can of Clients using a particular Issuer during that time window, the set can
be small. Applications should take such side channels into consideration before be small. Applications should take such side channels into consideration before
choosing a particular deployment model and type of token challenge and choosing a particular deployment model and type of token challenge and
redemption context.</t> redemption context.</t>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document describes security and privacy requirements for the Priva cy Pass <t>This document describes security and privacy requirements for the Priva cy Pass
redemption and issuance protocols. It also describes deployment models built redemption and issuance protocols. It also describes deployment models built
around non-collusion assumptions and privacy considerations for using Privacy around non-collusion assumptions and privacy considerations for using Privacy
Pass within those models. Ensuring Client privacy -- separation of attestation Pass within those models. Ensuring Client privacy -- separation of attestation
and redemption contexts -- requires active work on behalf of the Client, and redemption contexts -- requires active work on behalf of the Client,
especially in the presence of malicious Issuers and Origins. Implementing especially in the presence of malicious Issuers and Origins. Implementing the
mitigations discussed in <xref target="deployment"/> and <xref target="privacy"/ mitigations discussed in Sections&nbsp;<xref target="deployment" format="counter
> is therefore necessary "/> and <xref target="privacy" format="counter"/> is therefore necessary
to ensure that Privacy Pass offers meaningful privacy improvements to end-users. to ensure that Privacy Pass offers meaningful privacy improvements to end users.
</t> </t>
<section anchor="hoarding"> <section anchor="hoarding">
<name>Token Caching</name> <name>Token Caching</name>
<t>Depending on the Origin's token challenge, Clients can request and ca che more <t>Depending on the Origin's token challenge, Clients can request and ca che more
than one token using an issuance protocol. Cached tokens help improve privacy by 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 separating the time of token issuance from the time of token redemption; they
also allow Clients to reduce the overhead of receiving new tokens via the also allow Clients to reduce the overhead of receiving new tokens via the
issuance protocol.</t> issuance protocol.</t>
<t>As a consequence, Origins that send token challenges which are compat ible with <t>As a consequence, Origins that send token challenges that are compati ble with
cached tokens need to take precautions to ensure that tokens are not replayed. 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 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 period of time in which cached tokens would be accepted for particular
challenges.</t> challenges.</t>
<t>Moreover, since tokens are not intrinsically bound to Clients, it is possible <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 for malicious Clients to collude and share tokens in a so-called "hoarding
attack." As an example of this attack, many distributed Clients could obtain attack". As an example of this attack, many distributed Clients could obtain
cacheable tokens and then share them with a single Client to redeem in a way cacheable tokens and then share them with a single Client to redeem the tokens i
n a way
that would violate an Origin's attempt to limit tokens to any one particular 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 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 , 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, comparing the issuance and redemption contexts can help detect hoarding attacks,
i.e., if the distribution of redemption contexts is noticeably different from th e i.e., if the distribution of redemption contexts is noticeably different from th e
distribution of issuance contexts. Rate limiting issuance, either at the Client, distribution of issuance contexts. Rate-limiting issuance, at either the Client,
Attester, or Issuer, can also help mitigate these attacks.</t> Attester, or Issuer, can also help mitigate these attacks.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <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-L
IMITED"/>
<displayreference target="RFC9518" to="CENTRALIZATION"/>
<displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTE
NCY"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="AUTHSCHEME">
<front>
<title>The Privacy Pass HTTP Authentication Scheme</title>
<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="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="12" month="September" year="2023"/>
<abstract>
<t> This document defines an HTTP authentication scheme for Priv
acy 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> <!-- draft-ietf-privacypass-auth-scheme (RFC 9577) -->
</abstract> <reference anchor="RFC9577" target="https://www.rfc-editor.org/info/rfc9577">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-auth-s <title>The Privacy Pass HTTP Authentication Scheme</title>
cheme-13"/> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
</reference> <organization>Apple Inc.</organization>
<reference anchor="RFC2119"> </author>
<front> <author initials="S." surname="Valdez" fullname="Steven Valdez">
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <organization>Google LLC</organization>
le> </author>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<date month="March" year="1997"/> <organization>Cloudflare</organization>
<abstract> </author>
<t>In many standards track documents several words are used to sig <date month="May" year="2024"/>
nify the requirements in the specification. These words are often capitalized. T </front>
his document defines these words as they should be interpreted in IETF documents <seriesInfo name="RFC" value="9577"/>
. This document specifies an Internet Best Current Practices for the Internet Co <seriesInfo name="DOI" value="10.17487/RFC9577"/>
mmunity, and requests discussion and suggestions for improvements.</t> </reference>
</abstract>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<seriesInfo name="BCP" value="14"/> 119.xml"/>
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC2119"/> 174.xml"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="PrivacyPassExtension" target="https://github.com/priv acypass/challenge-bypass-extension"> <reference anchor="PrivacyPassExtension" target="https://github.com/priv acypass/challenge-bypass-extension">
<front> <front>
<title>Privacy Pass Browser Extension</title> <title>Privacy Pass Browser Extension</title>
<author> <author/>
<organization/> <date month="March" year="2024"/>
</author>
<date>n.d.</date>
</front> </front>
<refcontent>commit b6ebca7</refcontent>
</reference> </reference>
<!-- [rfced] [PrivacyPassExtension] is not cited anywhere in this
document. Please let us know where it should be cited; otherwise,
the listing will be removed.
Original:
[PrivacyPassExtension]
"Privacy Pass Browser Extension", n.d.,
<https://github.com/privacypass/challenge-bypass-
extension>. -->
<reference anchor="PrivacyPassCloudflare" target="https://blog.cloudflar e.com/cloudflare-supports-privacy-pass/"> <reference anchor="PrivacyPassCloudflare" target="https://blog.cloudflar e.com/cloudflare-supports-privacy-pass/">
<front> <front>
<title>Cloudflare Supports Privacy Pass</title> <title>Cloudflare supports Privacy Pass</title>
<author initials="N." surname="Sullivan"> <author initials="N." surname="Sullivan">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
</author> </author>
<date>n.d.</date> <date month="November" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="DMS2004" target="https://svn.torproject.org/svn/proje cts/design-paper/tor-design.html"> <reference anchor="DMS2004" target="https://svn.torproject.org/svn/proje cts/design-paper/tor-design.html">
<front> <front>
<title>Tor: The Second-Generation Onion Router</title> <title>Tor: The Second-Generation Onion Router</title>
<author initials="R." surname="Dingledine"> <author initials="R." surname="Dingledine">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Mathewson"> <author initials="N." surname="Mathewson">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Syverson"> <author initials="P." surname="Syverson">
<organization/> <organization/>
</author> </author>
<date year="2004" month="August"/> <date year="2004" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="HIJK21" target="https://research.fb.com/privatestats" > <reference anchor="HIJK21" target="https://research.fb.com/privatestats" >
<front> <front>
<title>PrivateStats: De-Identified Authenticated Logging at Scale</t itle> <title>PrivateStats: De-Identified Authenticated Logging at Scale</t itle>
<author initials="S." surname="Huang"> <author initials="S." surname="Huang">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Iyengar"> <author initials="S." surname="Iyengar">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Jeyaraman"> <author initials="S." surname="Jeyaraman">
skipping to change at line 1508 skipping to change at line 1808
</author> </author>
<author initials="Y. C." surname="Sung"> <author initials="Y. C." surname="Sung">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Zhang"> <author initials="A." surname="Zhang">
<organization/> <organization/>
</author> </author>
<date year="2021" month="January"/> <date year="2021" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor="ISSUANCE">
<front>
<title>Privacy Pass Issuance Protocol</title>
<author fullname="Sofia Celi" initials="S." surname="Celi">
<organization>Brave Software</organization>
</author>
<author fullname="Alex Davidson" initials="A." surname="Davidson">
<organization>Brave Software</organization>
</author>
<author fullname="Steven Valdez" initials="S." surname="Valdez">
<organization>Google LLC</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="14" month="September" year="2023"/>
<abstract>
<t> This document specifies two variants of the two-message issu
ance
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> <!-- [rfced] [HIJK21]: We see that clicking the provided link for
</abstract> [HIJK21] results in a redirect. Also, we see a title mismatch.
</front> Assuming that the provided link is stable, the date (which we could
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-protoc not find) is correct, and the initials for Chen-Kuei Lee and Yen-Chieh
ol-14"/> Sung are appropriate, may we update as suggested?
</reference>
<reference anchor="RFC9334"> Original:
<front> [HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee,
<title>Remote ATtestation procedureS (RATS) Architecture</title> C. K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S.,
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/> Sung, Y. C., and A. Zhang, "PrivateStats: De-Identified
<author fullname="D. Thaler" initials="D." surname="Thaler"/> Authenticated Logging at Scale", January 2021,
<author fullname="M. Richardson" initials="M." surname="Richardson"/ <https://research.fb.com/privatestats>.
> Suggested:
<author fullname="N. Smith" initials="N." surname="Smith"/> [HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee,
<author fullname="W. Pan" initials="W." surname="Pan"/> C-K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S.,
<date month="January" year="2023"/> Sung, Y-C., and A. Zhang, "DIT: De-Identified
<abstract> Authenticated Telemetry at Scale", January 2021,
<t>In network protocol exchanges, it is often useful for one end o <https://research.fb.com/privatestats>. -->
f a communication to know whether the other end is in an intended operating stat
e. This document provides an architectural overview of the entities involved tha <!-- draft-ietf-privacypass-protocol (RFC 9578) -->
t make such tests possible through the process of generating, conveying, and eva <reference anchor="RFC9578" target="https://www.rfc-editor.org/info/rfc9578">
luating evidentiary Claims. It provides a model that is neutral toward processor <front>
architectures, the content of Claims, and protocols.</t> <title>Privacy Pass Issuance Protocol</title>
</abstract> <author initials="S." surname="Celi" fullname="Sofia Celi">
</front> <organization>Brave Software</organization>
<seriesInfo name="RFC" value="9334"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC9334"/> <author initials="A." surname="Davidson" fullname="Alex Davidson">
</reference> <organization>Brave Software</organization>
<reference anchor="OHTTP"> </author>
<front> <author initials="S." surname="Valdez" fullname="Steven Valdez">
<title>Oblivious HTTP</title> <organization>Google LLC</organization>
<author fullname="Martin Thomson" initials="M." surname="Thomson"> </author>
<organization>Mozilla</organization> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
</author> <organization>Cloudflare</organization>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo </author>
d"> <date month="May" year="2024"/>
<organization>Cloudflare</organization> </front>
</author> <seriesInfo name="RFC" value="9578"/>
<date day="25" month="August" year="2023"/> <seriesInfo name="DOI" value="10.17487/RFC9578"/>
<abstract> </reference>
<t> This document describes Oblivious HTTP, a protocol for forwa
rding <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
encrypted HTTP messages. Oblivious HTTP allows a client to make 34.xml"/>
multiple requests to an origin server without that server being able
to link those requests to the client or to identify the requests as <!-- draft-ietf-ohai-ohttp (RFC 9458; published) -->
having come from the same client, while placing only limited trust in <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
the nodes used to forward the messages. 58.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-10"/>
</reference>
<reference anchor="KLOR20" target="https://doi.org/10.1007/978-3-030-567 84-2_11"> <reference anchor="KLOR20" target="https://doi.org/10.1007/978-3-030-567 84-2_11">
<front> <front>
<title>Anonymous Tokens with Private Metadata Bit</title> <title>Anonymous Tokens with Private Metadata Bit</title>
<author fullname="Ben Kreuter" surname="Kreuter"/> <author fullname="Ben Kreuter" surname="Kreuter"/>
<author fullname="Tancrède Lepoint" surname="Lepoint"/> <author fullname="Tancrède Lepoint" surname="Lepoint"/>
<author fullname="Michele Orrù" surname="Orrù"/> <author fullname="Michele Orrù" surname="Orrù"/>
<author fullname="Mariana Raykova" surname="Raykova"/> <author fullname="Mariana Raykova" surname="Raykova"/>
<author> <author>
<organization>Springer International Publishing</organization> <organization>Springer International Publishing</organization>
</author> </author>
<date year="2020"/> <date year="2020"/>
</front> </front>
<refcontent>Advances in Cryptology – CRYPTO 2020, pp. 308-336</refcont ent> <refcontent>Advances in Cryptology - CRYPTO 2020, pp. 308-336</refcont ent>
<seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_11"/> <seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_11"/>
</reference> </reference>
<reference anchor="RATE-LIMITED">
<front>
<title>Rate-Limited Token Issuance Protocol</title>
<author fullname="Scott Hendrickson" initials="S." surname="Hendrick
son">
<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="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="6" month="July" year="2022"/>
<abstract>
<t> This document specifies a variant of the Privacy Pass issuan
ce
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 <!-- draft-ietf-privacypass-rate-limit-tokens (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pr
This note is to be removed before publishing as an RFC. ivacypass-rate-limit-tokens.xml"/>
Source for this draft and an issue tracker can be found at
https://github.com/tfpauly/privacy-proxy.
</t> <!-- draft-nottingham-avoiding-internet-centralizations (RFC 9518; published) --
</abstract> >
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="Internet-Draft" value="draft-privacypass-rate-limit- 518.xml"/>
tokens-03"/>
</reference>
<reference anchor="CENTRALIZATION">
<front>
<title>Centralization, Decentralization, and Internet Standards</tit
le>
<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 relat
e 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> <!-- draft-ietf-privacypass-key-consistency (Expired) -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pr
</front> ivacypass-key-consistency.xml"/>
<seriesInfo name="Internet-Draft" value="draft-nottingham-avoiding-int
ernet-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="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="10" month="July" year="2023"/>
<abstract>
<t> This document describes the consistency requirements of prot
ocols
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-co
nsistency-01"/>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgements">
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank Eric Kinnear, Scott Hendrickson, Tommy <t>The authors would like to thank <contact fullname="Eric Kinnear"/>, <co
Pauly, ntact fullname="Scott Hendrickson"/>, <contact fullname="Tommy Pauly"/>,
Christopher Patton, Benjamin Schwartz, Martin Thomson, Steven Valdez and other <contact fullname="Christopher Patton"/>, <contact fullname="Benjamin Schwartz"/
>, <contact fullname="Martin Thomson"/>, <contact fullname="Steven Valdez"/>, an
d other
contributors of the Privacy Pass Working Group for many helpful contributions contributors of the Privacy Pass Working Group for many helpful contributions
to this document.</t> to this document.</t>
</section> </section>
</back> </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
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
<!-- [rfced] Please let us know if any changes are needed for the
following:
a) The following terms were used inconsistently in this document.
We chose to use the latter forms. Please let us know any objections.
Attestation (1 instance in text) / attestation (~90 instances in text)
attester (2 instances) / Attester (approx. 108 instances)
RATS verifiers / RATS Verifiers (per Section 2 and "Verifier" in
published RFCs in this cluster, with the exception of RFC 9497)
b) The following term appears to be used inconsistently in this
document. Please let us know which form is preferred.
Client's anonymity set / Client anonymity set -->
</rfc> </rfc>
 End of changes. 155 change blocks. 
842 lines changed or deleted 660 lines changed or added

This html diff was produced by rfcdiff 1.48.