diff --git a/chris-wood-patch-7/draft-ietf-privacypass-architecture.html b/chris-wood-patch-7/draft-ietf-privacypass-architecture.html new file mode 100644 index 00000000..ce8ece92 --- /dev/null +++ b/chris-wood-patch-7/draft-ietf-privacypass-architecture.html @@ -0,0 +1,2884 @@ + + + + + + +The Privacy Pass Architecture + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftPrivacy Pass ArchitectureOctober 2023
Davidson, et al.Expires 5 April 2024[Page]
+
+
+
+
Workgroup:
+
Network Working Group
+
Internet-Draft:
+
draft-ietf-privacypass-architecture-latest
+
Published:
+
+ +
+
Intended Status:
+
Informational
+
Expires:
+
+
Authors:
+
+
+
A. Davidson
+
LIP
+
+
+
J. Iyengar
+
Fastly
+
+
+
C. A. Wood
+
Cloudflare
+
+
+
+
+

The Privacy Pass Architecture

+
+

Abstract

+

This document specifies the Privacy Pass architecture and requirements for +its constituent protocols used for authorization based on privacy-preserving +authentication mechanisms. It describes the conceptual model of Privacy Pass +and its protocols, its security and privacy goals, practical deployment models, +and recommendations for each deployment model that helps ensure the desired +security and privacy goals are fulfilled.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 5 April 2024.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+1. Introduction +

+

Privacy Pass is an architecture for authorization based on privacy-preserving +authentication mechanisms. In other words, relying parties authenticate clients +in a privacy-preserving way, i.e., without learning any unique, per-client +information through the authentication protocol, and then make authorization +decisions on the basis of that authentication succeeding or failing. Possible +authorization decisions might be to provide clients with read access to a +particular resource or write access to a particular resource.

+

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 +clients across sessions and interactions. Privacy Pass takes a different +approach: instead of presenting linkable state-carrying information to servers, +e.g., a cookie indicating whether or not the client is an authorized user or +has completed some prior challenge, clients present unlinkable proofs that +attest to this information. These proofs, or tokens, are private in the sense +that a given token cannot be linked to the protocol interaction where that +token was initially issued.

+

At a high level, the Privacy Pass architecture consists of two protocols: +redemption and issuance. The redemption protocol, described in +[AUTHSCHEME], runs between Clients and +Origins (servers). It allows Origins to challenge Clients to present tokens +for consumption. Origins verify the token to authenticate the Client -- without +learning any specific information about the Client -- and then make an authorization +decision on the basis of the token verifying successfully or not. Depending +on the type of token, e.g., whether or not it can be cached, the Client +either presents a previously obtained token or invokes an issuance protocol, +such as [ISSUANCE], to acquire a token to +present as authorization.

+

This document describes requirements for both redemption and issuance +protocols and how they interact. It also provides recommendations on how +the architecture should be deployed to ensure the privacy of clients and +the security of all participating entities.

+
+
+
+
+

+2. Terminology +

+

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL +NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", +"MAY", and "OPTIONAL" in this document are to be interpreted as +described in BCP 14 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.

+

The following terms are used throughout this document:

+
+
Client:
+
+

An entity that seeks authorization to an Origin. Using [RFC9334] terminology, +Clients implement the RATS Attester role.

+
+
+
Token:
+
+

A cryptographic authentication message used for authorization decisions, +produced as output from an issuance mechanism or protocol.

+
+
+
Origin:
+
+

An entity that consumes tokens presented by Clients and uses them to make authorization decisions.

+
+
+
Token challenge:
+
+

The mechanism by which Origins request tokens from Clients, often denoted TokenChallenge.

+
+
+
Token request:
+
+

A message used by Clients to request a token from an Issuer, often denoted TokenRequest.

+
+
+
Token response:
+
+

A message used by Issuers to send tokens to a Client, often denoted TokenResponse.

+
+
+
Redemption:
+
+

The mechanism by which Clients present tokens to Origins for the +purposes of authorization.

+
+
+
Issuer:
+
+

An entity that issues tokens to Clients for properties +attested to by the Attester.

+
+
+
Issuance:
+
+

The mechanism by which an Issuer produces tokens for Clients.

+
+
+
Attester:
+
+

An entity that attests to properties of Clients for the +purposes of token issuance. Using [RFC9334] terminology, Attesters implement +the RATS Verifier role.

+
+
+
Attestation procedure:
+
+

The procedure by which an Attester determines whether or not a Client +has the specific set of properties that are necessary for token issuance.

+
+
+
+

The trust relationships between each of the entities in this list is further +elaborated upon in Section 3.3.

+
+
+
+
+

+3. Architecture +

+

The Privacy Pass architecture consists of four logical entities -- +Client, Origin, Issuer, and Attester -- that work in concert +for token redemption and issuance. This section presents an overview +of Privacy Pass, a high-level description of the threat model and +privacy goals of the architecture, and the goals and requirements of +the redemption and issuance protocols. Deployment variations for the +Origin, Issuer, and Attester in this architecture, including +considerations for implementing these entities, are further discussed +in Section 4.

+
+
+

+3.1. Overview +

+

This section describes the typical interaction flow for Privacy Pass.

+
    +
  1. +

    A Client interacts with an Origin by sending a request or otherwise +interacting with the Origin in a way that triggers a response containing +a token challenge. The token challenge indicates a specific Issuer to use.

    +
    2. +
  2. +

    If the Client already has a token available that satisfies the token +challenge, e.g., because the Client has a cache of previously issued tokens, +it can skip to step 6 and redeem its +token; see Section 7.1 for security considerations of cached tokens.

    +
    3. +
  3. +

    If the Client does not have a token available and decides it wants to +obtain one (or more) bound to the token challenge, it then invokes the +issuance protocol. As a prerequisite to the issuance protocol, the Client +runs the deployment-specific attestation process that is required for the +designated Issuer. Client attestation can be done via proof of solving a +CAPTCHA, checking device or hardware attestation validity, etc.; see +Section 3.5.1 for more details.

    +
    4. +
  4. +

    If the attestation process completes successfully, the client creates a +token request to send to the designated Issuer (generally via the Attester, +though it is not required to be sent through the Attester). +The Attester and Issuer might be functions on the same server, depending on the +deployment model (see Section 4). Depending on the attestation process, it +is possible for attestation to run alongside the issuance protocol, e.g., where +Clients send necessary attestation information to the Attester along with their +token request. If the attestation process fails, the Client receives an error +and issuance aborts without a token.

    +
    5. +
  5. +

    The Issuer generates a token response based on the token request, which +is returned to the Client (generally via the Attester). Upon receiving the +token response, the Client computes a token from the token challenge and token +response. This token can be validated by anyone with the per-Issuer key, but +cannot be linked to the content of the token request or token response.

    +
    6. +
  6. +
    +

    If the Client has a token, it includes it in a subsequent request to +the Origin, as authorization. This token is sent only once in reaction to a +challenge; Clients do not send tokens more than once, even if they receive +duplicate or redundant challenges. The Origin +validates that the token was generated by the expected Issuer and has not +already been redeemed for the corresponding token challenge. If the Client +does not have a token, perhaps because issuance failed, the client does not +reply to the Origin's challenge with a new request.

    +
    +
    7. +
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Origin + Client + Attester + Issuer + Request + TokenChallenge + Attestation + TokenRequest + TokenResponse + Request+Token + + +
+
+
Figure 1: +Privacy pass redemption and issuance protocol interaction +
+
+
+
+
+
+

+3.2. Use Cases +

+

Use cases for Privacy Pass are broad and depend greatly on the deployment model +as discussed in Section 4. The initial motivating use case for Privacy Pass +[PrivacyPassCloudflare] was to help rate-limit malicious or otherwise abusive +traffic from services such as Tor [DMS2004]. The generalized and evolved +architecture described in this document also work for this use case. However, +for added clarity, some more possible use cases are described below.

+
    +
  • +

    Low-quality, anti-fraud signal for open Internet services. Tokens can attest that +the Client behind the user agent is likely not a bot attempting to perform some +form of automated attack such as credential stuffing. Example attestation procedures +for this use case might be solving some form of CAPTCHA or presenting evidence of a +valid, unlocked device in good standing.

    +
    • +
  • +

    Privacy-preserving authentication for proprietary services. Tokens can attest that +the Client is a valid subscriber for a proprietary service, such as a deployment of +Oblivious HTTP [OHTTP].

    +
    • +
+
+
+
+
+

+3.3. Privacy Goals and Threat Model +

+

The end-to-end flow for Privacy Pass described in Section 3.1 involves three +different types of contexts:

+
+
Redemption context:
+
+

The interactions and set of information shared +between the Client and Origin, i.e., the information that is provided or +otherwise available to the Origin during redemption that might be used +to identify a Client and construct a token challenge. This context includes all +information associated with redemption, such as the timestamp of the event, +Client-visible information (including the IP address), and the Origin name.

+
+
+
Issuance context:
+
+

The interactions and set of information shared between the Client, Attester, +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. +This context includes all information associated with issuance, such as the +timestamp of the event, any Client-visible information (including the IP +address), and the Origin name (if revealed during issuance). This does not +include the token challenge in its entirety, as that is kept secret from the +Issuer during the issuance protocol.

+
+
+
Attestation context:
+
+

The interactions and set of information shared between +the Client and Attester only, for the purposes of attesting the validity of +the Client, that is provided or otherwise available during attestation that +might be used to identify the Client. This context includes all information +associated with attestation, such as the timestamp of the event and any +Client-visible information, including information needed for the attestation +procedure to complete.

+
+
+
+

The privacy goals of Privacy Pass assume a threat model in which Origins trust +specific Issuers to produce tokens, and Issuers in turn trust one or more +Attesters to correctly run the attestation procedure with Clients. This +arrangement ensures that tokens which validate for a given Issuer were only +issued to a Client that successfully completed attestation with an Attester +that the Issuer trusts. Moreover, this arrangement means that if an Origin +accepts tokens issued by an Issuer that trusts multiple Attesters, then a +Client can use any one of these Attesters to issue and redeem tokens for the +Origin. Whether or not these different entities in the architecture collude +for learning redemption, issuance, or attestation contexts, as well as the +necessary preconditions for context unlinkability, depends on the deployment +model; see Section 4 for more details.

+

The mechanisms for establishing trust between each entity in this arrangement +are deployment-specific. For example, in settings where Clients interact with +Issuers through an Attester, Attesters and Issuers might use +mutually authenticated TLS to authenticate one another. In settings where +Clients do not communicate with Issuers through an Attester, the Attesters +might convey this trust via a digital signature that Issuers can verify.

+

Clients explicitly trust Attesters to perform attestation correctly and in a +way that does not violate their privacy. In particular, this means that Attesters +which may be privy to private information about Clients are trusted to not disclose +this information to non-colluding parties. Colluding parties are assumed to have +access to the same information; see Section 4 for more about different +deployment models and non-collusion assumptions. However, Clients assume Issuers and +Origins are malicious.

+

Given this threat model, the privacy goals of Privacy Pass are oriented around +unlinkability based on redemption, issuance, and attestation contexts, as +described below.

+
    +
  1. +

    Origin-Client unlinkability. This means that given two redemption contexts, +the Origin cannot determine if both redemption contexts correspond to the same +Client or two different Clients. Informally, this means that a Client in a +redemption context is indistinguishable from any other Client that might use +the same redemption context. The set of Clients that share the same redemption +context is referred to as a redemption anonymity set.

    +
    2. +
  2. +

    Issuer-Client unlinkability. This is similar to Origin-Client unlinkability +in that a Client in an issuance context is indistinguishable from any other +Client that might use the same issuance context. The set of Clients that share +the same issuance context is referred to as an issuance anonymity set.

    +
    3. +
  3. +

    Attester-Origin unlinkability. This is similar to Origin-Client and +Issuer-Client unlinkability. It means that given two attestation contexts, +the Attester cannot determine if both contexts correspond to the same Origin +or two different Origins. The set of Origins that share the same attestation +context is referred to as an attestation anonymity set.

    +
    4. +
  4. +

    Redemption context unlinkability. Given two redemption contexts, the Origin +cannot determine which issuance and attestation contexts each redemption +corresponds to, even with the collaboration of the Issuer and Attester (should +these be different parties). This means that any information that may be learned +about the Client during the issuance and attestation flows cannot be used by the +Origin to compromise Client privacy.

    +
    5. +
+

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. +The Attester, Issuer, and Origin only receive the information necessary to perform +their respective functions.

+

The manner in which these unlinkability properties are achieved depends on the +deployment model, type of attestation, and issuance protocol details. For example, +as discussed in Section 4, in some cases it is necessary to use an anonymization +service such as Tor [DMS2004] which hides Clients IP addresses. In general, +anonymization services ensures that all Clients which use the service are indistinguishable +from one another, though in practice there may be small distinguishing features +(TLS fingerprints, HTTP headers, etc). Moreover, Clients generally trust these services +to not disclose private Client information (such as IP addresses) to untrusted parties. +Failure to use an anonymization service when interacting with Attesters, Issuers, or +Origins can allow the set of possible Clients to be partitioned by the Client's IP address, +and can therefore lead to unlinkability violations. Similarly, malicious Origins +may attempt to link two redemption contexts together by using Client-specific +Issuer public keys. See Section 5 and Section 6 for more +information.

+

The remainder of this section describes the functional properties and security +requirements of the redemption and issuance protocols in more detail. Section 3.6 +describes how information flows between Issuer, Origin, Client, and Attester +through these protocols.

+
+
+
+
+

+3.4. Redemption Protocol +

+

The Privacy Pass redemption protocol, described in +[AUTHSCHEME], is an authorization protocol +wherein Clients present tokens to Origins for authorization. Normally, +redemption is preceded by a challenge, wherein the Origin challenges +Clients for a token with a TokenChallenge ([AUTHSCHEME], Section 2.1) and, +if possible, Clients present a valid Token ([AUTHSCHEME], Section 2.2) +in reaction to the challenge. This interaction is shown below.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + Origin + Client + Request + TokenChallenge + Issuance + protocol + Request+Token + + +
+
+
Figure 2: +Challenge and redemption protocol interaction +
+
+

Alternatively, when configured to do so, Clients may opportunistically present +Token values to Origins without a corresponding TokenChallenge.

+

The structure and semantics of the TokenChallenge and Token messages depend +on the issuance protocol and token type being used; see [AUTHSCHEME] for +more information.

+

The challenge provides the client with the information necessary to obtain +tokens that the server might subsequently accept in the redemption context. +There are a number of ways in which the token may vary based on this challenge, +including:

+
    +
  • +

    Issuance protocol. The challenge identifies the type of issuance protocol +required for producing the token. Different issuance protocols have different +security properties, e.g., some issuance protocols may produce tokens that +are publicly verifiable, whereas others may not have this property.

    +
    • +
  • +

    Issuer identity. Token challenges identify which Issuers are trusted for a +given issuance protocol. As described in Section 3.3, the choice +of Issuer determines the type of Attesters and attestation procedures possible +for a token from the specified Issuer, but the Origin does not learn exactly +which Attester was used for a given token issuance event.

    +
    • +
  • +

    Redemption context. Challenges can be bound to a given redemption context, +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 +redeemed non-interactively, whereas a fresh and random redemption context +means that the redeemed token must be issued only after the client receives +the challenge. See Section 2.1.1 of [AUTHSCHEME] for more details.

    +
    • +
  • +

    Per-Origin or cross-Origin. Challenges can be constrained to the Origin for +which the challenge originated (referred to as per-Origin tokens), or +can be used across multiple Origins (referred to as cross-Origin tokens). +The set of Origins for which a cross-Origin token is applicable is referred +to as the cross-Origin set. Opting into this set is done by explicitly agreeing +on the contents of the set. Every Origin in a cross-Origin set, by opting in, +agrees to admit tokens for any other Origin in the set. See +Section 2.1.1 of [AUTHSCHEME] for more information on how this set is created.

    +
    • +
+

Origins that admit cross-Origin tokens bear some risk of allowing tokens +issued for one Origin to be spent in an interaction with another Origin. +In particular, cross-Origin tokens issued based on a challenge for +one Origin can be redeemed at another Origin in the cross-Origin set, +which can make it difficult to regulate token consumption. Depending on the +use case, Origins may need to maintain state to track redeemed tokens. For +example, Origins that accept cross-Origin tokens across shared redemption +contexts SHOULD track which tokens have been redeemed already in those +redemption contexts, since these tokens can be issued and then spent multiple +times for any such challenge. Note that Clients which redeem the +same token to multiple Origins do risk those Origins being able to link +Client activity together, which can disincentivize this behavior. See +Section 2.1.1 of [AUTHSCHEME] for discussion.

+

How Clients respond to token challenges can have privacy implications. +For example, if an Origin allows the Client to choose an Issuer, then the choice +of Issuer can reveal information about the Client used to partition anonymity +sets; see Section 6.2 for more information about these privacy +considerations.

+
+
+
+
+

+3.5. Issuance Protocol +

+

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.

+

The structure and semantics of the TokenRequest and TokenResponse messages +depend on the issuance protocol and token type being used; see [ISSUANCE] +for more information.

+

Clients interact with the Attester and Issuer to produce a token for +a challenge. The context in which an Attester vouches for a Client during +issuance is referred to as the attestation context. This context includes all +information associated with the issuance event, such as the timestamp of the +event and Client-visible information, including the IP address or other +information specific to the type of attestation done.

+

Each issuance protocol may be different, e.g., in the number and types of +participants, underlying cryptographic constructions used when issuing tokens, +and even privacy properties.

+

Clients initiate the issuance protocol using the token challenge, a randomly +generated nonce, and public key for the Issuer, all of which are the Client's +private input to the protocol and ultimately bound to an output Token; +see Section 2.2 of [AUTHSCHEME] for details. Future specifications +may change or extend the Client's input to the issuance protocol to produce +Tokens with a different structure.

+

Token properties vary based on the issuance protocol. Important properties +supported in this architecture are described below.

+
    +
  1. +

    Public verifiability. This means the Token can be verified using the Issuer +public key. A Token that does not have public verifiability can only be verified +using the Issuer secret key.

    +
    2. +
  2. +

    Public metadata. This means that the Token can be cryptographically bound to +arbitrary public information. See Section 6.1 for privacy considerations +of public metadata.

    +
    3. +
  3. +

    Private metadata. This means that the Token can be cryptographically bound to +arbitrary private information, i.e., information that the Client does not observe +during Token issuance or redemption. See Section 6.1 for privacy +considerations of private metadata.

    +
    4. +
+

The issuance protocol itself can be any interactive protocol between Client, +Issuer, or other parties that produces a valid token bound to the Client's +private input, subject to the following security requirements.

+
    +
  1. +

    Unconditional input secrecy. The issuance protocol MUST NOT reveal anything +about the Client's private input, including the challenge and nonce, to the +Attester or Issuer, regardless of the hardness assumptions of the underlying +cryptographic protocol(s). This property is sometimes also referred to as +blindness.

    +
    2. +
  2. +

    One-more forgery security. The issuance protocol MUST NOT allow malicious +Clients or Attesters (acting as Clients) to forge tokens offline or otherwise +without interacting with the Issuer directly.

    +
    3. +
  3. +

    Concurrent security. The issuance protocol MUST be safe to run concurrently +with arbitrarily many Clients, Attesters and Issuers.

    +
    4. +
+

See Section 3.5.4 for requirements on new issuance protocol variants and +related extensions.

+

In the sections below, we describe the Attester and Issuer roles in more +detail.

+
+
+

+3.5.1. Attester Role +

+

In Privacy Pass, attestation is the process by which an Attester bears +witness to, confirms, or authenticates a Client so as to verify properties +about the Client that are required for Issuance. 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.

+

[RFC9334] describes an architecture for attestation procedures. Using +that architecture as a conceptual basis, Clients are RATS attesters that +produce attestation evidence, and Attesters are RATS verifiers that +appraise the validity of attestation evidence.

+

The type of attestation procedure is a deployment-specific option and outside +the scope of the issuance protocol. Example attestation procedures are below.

+
    +
  • +

    Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to +have this capability for the purpose of being ruled out as a bot or otherwise +automated Client.

    +
    • +
  • +

    Presenting evidence of Client device validity. Some Clients run on trusted +hardware that are capable of producing device-level attestation evidence.

    +
    • +
  • +

    Proving properties about Client state. Clients can be associated with state +and the Attester can verify this state. Examples of state include the +Client's geographic region and whether the Client has a valid +application-layer account.

    +
    • +
+

Attesters may support different types of attestation procedures.

+

Each attestation procedure has different security properties. For +example, attesting to having a valid account is different from attesting to +running on trusted hardware. Supporting multiple attestation procedures is +an important step towards ensuring equitable access for Clients; see Section 5.1.

+

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. For instance, increasing the number of required attestation procedures +could decrease the overall anonymity set size. As an example, the number of Clients +that have solved a CAPTCHA in the past day, that have a valid account, and that +are running on a trusted device is less than the number of Clients that have +solved a CAPTCHA in the past day. See Section 6.2 for more discussion +of how the variety of attestation procedures can negatively impact Client privacy.

+

Depending on the issuance protocol, the Issuer might learn +information about the Origin. To ensure Issuer-Client unlinkability, the Issuer +should be unable to link that information to a specific Client. For such +issuance protocols where the Attester has access to Client-specific +information, such as is the case for attestation procedures that involve +Client-specific information (such as application-layer account information) +or for deployment models where the Attester learns Client-specific information +(such as Client IP addresses), Clients trust the Attester to not share any +Client-specific information with the Issuer. In deployments where the Attester +does not learn Client-specific information, or where the Attester and Issuer are +operated by the same entity (such as in the Joint Attester and Issuer model +described in Section 4.2), the Client does not need to explicitly +trust the Attester in this regard.

+

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. Broken +attestation procedures are considered exceptional events and require +configuration changes to address the underlying cause. For example, if +an attestation procedure is compromised or subverted because of a zero-day +exploit on devices that implement the attestation procedure, then the +corresponding attestation procedure should be untrusted until the exploit is +patched. Addressing changes in attestation quality is therefore a +deployment-specific task. In Split Attester and Issuer deployments (see +Section 4.4), Issuers can choose to remove compromised Attesters from +their trusted set until the compromise is patched.

+

From the perspective of an Origin, tokens produced by an Issuer with at least +one compromised Attester cannot be trusted assuming the Origin does not know +which attestation procedure was used for issuance. This is because the Origin +cannot distinguish between tokens that were issued via compromised Attesters +and tokens that were issued via uncompromised Attesters absent some +distinguishing information in the tokens themselves or from the Issuer. As a +result, until the attestation procedure is fixed, the Issuer cannot be trusted +by Origins. Moreover, as a consequence, any tokens issued by an Issuer with a +compromised attester may no longer be trusted by Origins, even if those tokens +were issued to Clients interacting with an uncompromised Attester.

+
+
+
+
+

+3.5.2. Issuer Role +

+

In Privacy Pass, the Issuer is responsible for completing the issuance protocol +for Clients that complete attestation through a trusted Attester. As described +in Section 3.5.1, Issuers explicitly trust Attesters to correctly and reliably +perform attestation. Origins explicitly trust Issuers to only issue tokens +from trusted Attesters. Clients do not explicitly trust Issuers.

+

Depending on the deployment model case, issuance may require some form of +Client anonymization service, similar to an IP-hiding proxy, so that Issuers +cannot learn information about Clients. This can be provided by an explicit +participant in the issuance protocol, or it can be provided via external means, +such as through the use of an IP-hiding proxy service like Tor [DMS2004]. +In general, Clients SHOULD minimize or remove identifying +information where possible when invoking the issuance protocol.

+

Issuers are uniquely identifiable by all Clients with a consistent +identifier. In a web context, this identifier might be the Issuer host name. +Issuers maintain one or more configurations, including issuance key pairs, for +use in the issuance protocol. Each configuration is assumed to have a unique +and canonical identifier, sometimes referred to as a key identifier or key ID. +Issuers can rotate these configurations as needed to mitigate risk of compromise; +see Section 6.2 for more considerations around configuration +rotation. The Issuer public key for each active configuration is made available +to Origins and Clients for use in the issuance and redemption protocols.

+
+
+
+
+

+3.5.3. Issuance Metadata +

+

Certain instantiations of the issuance protocol may permit public or private +metadata to be cryptographically bound to a token. As an example, one +trivial way to include public metadata is to assign a unique Issuer +public key for each value of metadata, such that N keys yields +log2(N) bits of metadata. Metadata may be public or private.

+

Public metadata is that which clients can observe as part of the token +issuance flow. Public metadata can either be transparent or opaque. For +example, transparent public metadata is a value that the client either +generates itself, or the Issuer provides during the issuance flow and +the client can check for correctness. Opaque public metadata is metadata +the client can see but cannot check for correctness. As an example, the +opaque public metadata might be a "fraud detection signal", computed on +behalf of the Issuer, during token issuance. Generally speaking, Clients +cannot determine if this value is generated in a way that permits tracking.

+

Private metadata is that which Clients cannot observe as part of the token +issuance flow. Such instantiations can be built on the Private Metadata Bit +construction from Kreuter et al. [KLOR20] +or the attribute-based VOPRF from Huang et al. [HIJK21].

+

Metadata can be arbitrarily long or bounded in length. The amount of permitted +metadata may be determined by application or by the underlying cryptographic +protocol. The total amount of metadata bits included in a token is the sum of +public and private metadata bits. Every bit of metadata can be used to +partition the Client issuance or redemption anonymity sets; see +Section 6.1 for more information.

+
+
+
+
+

+3.5.4. Future Issuance Protocol Requirements +

+

The Privacy Pass architecture and ecosystem are both intended to be receptive +to extensions that expand the current set of functionalities through new +issuance protocols. Each new issuance protocol and extension MUST adhere +to the following requirements:

+
    +
  1. +

    Include a detailed analysis of the privacy impacts of the extension, why +these impacts are justified, and guidelines on how to use the protocol +to mitigate or minimize negative deployment or privacy consequences +discussed in Section 5 and Section 6, respectively.

    +
    2. +
  2. +

    Adhere to the guidelines specified in Section 3.5.2 for managing Issuer +public key data.

    +
    3. +
  3. +

    Clearly specify how to interpret and validate TokenChallenge and Token +messages that are exchanged during the redemption protocol.

    +
    4. +
+
+
+
+
+
+
+

+3.6. Information Flow +

+

The end-to-end process of redemption and issuance protocols involves information +flowing between Issuer, Origin, Client, and Attester. That information can +have implications on the privacy goals that Privacy Pass aims to provide +as outlined in Section 3.3. In this section, we describe the flow +of information between each party. How this information affects the privacy +goals in particular deployment models is further discussed in Section 4.

+
+
+

+3.6.1. Token Challenge Flow +

+

To use Privacy Pass, Origins choose an Issuer from which they are willing to +accept tokens. Origins then construct a token challenge using this specified +Issuer and information from the redemption context it shares with the Client. +This token challenge is then delivered to a Client. The token challenge conveys +information about the Issuer and the redemption context, such as whether the +Origin desires a per-Origin or cross-Origin token. Any entity that sees +the token challenge might learn things about the Client as known to the Origin. +This is why input secrecy is a requirement for issuance protocols, as it +ensures that the challenge is not directly available to the Issuer.

+
+
+
+
+

+3.6.2. Attestation Flow +

+

Clients interact with the Attester to prove that they meet some required +set of properties. In doing so, Clients contribute information to the +attestation context, which might include sensitive information such as +application-layer identities, IP addresses, and so on. Clients can choose +whether or not to contribute this information based on local policy or +preference.

+
+
+
+
+

+3.6.3. Issuance Flow +

+

Clients use the issuance protocol to produce a token bound to a token +challenge. In doing so, there are several ways in which the issuance protocol +contributes information to the attestation or issuance contexts. For example, a +token request may contribute information to the attestation or issuance +contexts as described below.

+
    +
  • +

    Issuance protocol. The type of issuance protocol can contribute information +about the Issuer's capabilities to the attestation or issuance contexts, as +well as the capabilities of a given Client. For example, if a Client is +presented with multiple issuance protocol options, then the choice of which +issuance protocol to use can contribute information about the Client's +capabilities.

    +
    • +
  • +

    Issuer configuration. Information about the Issuer configuration, such as +its identity or the public key used to validate tokens it creates, can be +revealed during issuance and contribute to the attestation or issuance +contexts.

    +
    • +
  • +

    Attestation information. The issuance protocol can contribute information to +the attestation or issuance contexts based on what attestation procedure the +Issuer uses to trust a token request. In particular, a token request that is +validated by a given Attester means that the Client which generated the token +request must be capable of the completing the designated attestation procedure.

    +
    • +
  • +

    Origin information. The issuance protocol can contribute information about +the Origin that challenged the Client in Section 3.6.1. In particular, +a token request designated for a specific Issuer might imply that the resulting +token is for an Origin that trusts the specified Issuer. However, this is not +always true, as some token requests can correspond to cross-Origin tokens, +i.e., they are tokens that would be accepted at any Origin that accepts the +cross-Origin token.

    +
    • +
+

Moreover, a token may contribute information to the issuance attestation or +contexts as described below.

+
    +
  • +

    Origin information. The issuance protocol can contribute information about +the Origin in how it responds to a token request. For example, if an Issuer +learns the Origin during issuance and is also configured to respond in some way +on the basis of that information, and the Client interacts with the Issuer +transitively through the Attester, that response can reveal information to the +Attester.

    +
    • +
  • +

    Token. The token produced by the issuance protocol can contain information +from the issuance context. In particular, depending on the issuance protocol, +tokens can contain public or private metadata, and Issuers can choose that +metadata on the basis of information in the issuance context.

    +
    • +
+

Exceptional cases in the issuance protocol, such as when either the +Attester or Issuer aborts the protocol, can contribute information to the +attestation or issuance contexts. The extent to which information in this +context harms the Issuer-Client or Attester-Origin unlinkability goals in +Section 3.3 depends on deployment model; see Section 4. +Clients can choose whether or not to contribute information to these contexts +based on local policy or preference.

+
+
+
+
+

+3.6.4. Token Redemption Flow +

+

Clients send tokens to Origins during the redemption protocol. Any information +that is added to the token during issuance can therefore be sent to the Origin. +Information can either be explicitly passed in a token, or it can be implicit +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 +a token challenge, this can reveal information to the Origin that +it might not otherwise have access to. However, an Origin cannot necessarily +distinguish between a Client that fails to complete issuance and one that +ignores the token challenge altogether.

+
+
+
+
+
+
+
+
+

+4. Deployment Models +

+

The Origin, Attester, and Issuer portrayed in Figure 1 can be +instantiated and deployed in a number of ways. The deployment model directly +influences the manner in which attestation, issuance, and redemption contexts +are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin +unlinkability.

+

This section covers some expected deployment models and their corresponding +security and privacy considerations. Each deployment model is described in +terms of the trust relationships and communication patterns between Client, +Attester, Issuer, and Origin. Entities drawn within the same bounding box are +assumed to be operated by the same party and are therefore able to collude. +Collusion can enable linking of attestation, issuance, and redemption contexts. +Entities not drawn within the same bounding box are assumed to not +collude, meaning that entities operated by separate parties that do not collude. +Mechanisms for enforcing non-collusion are out of scope for this architecture.

+
+
+

+4.1. Shared Origin, Attester, Issuer +

+

In this model, the Origin, Attester, and Issuer are all operated by the same +entity, as shown in Figure 3.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Client + Attester + Issuer + Origin + TokenChallenge + Attestation + TokenRequest + TokenResponse + Token + | + + +
+
+
Figure 3: +Shared Deployment Model +
+
+

This model represents the initial deployment of Privacy Pass, as described in +[PrivacyPassCloudflare]. In this model, the Attester, Issuer, and Origin +share the attestation, issuance, and redemption contexts. As a result, +attestation mechanisms that can uniquely identify a Client, e.g., requiring +that Clients authenticate with some type of application-layer account, are +not appropriate, as they could lead to unlinkability violations.

+

Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that +issuance and redemption events be separated over time, such as through the use +of tokens that correspond to token challenges with an empty redemption context +(see Section 3.4), or be separated over space, such as through the use of an +anonymizing service when connecting to the Origin.

+
+
+
+
+

+4.2. Joint Attester and Issuer +

+

In this model, the Attester and Issuer are operated by the same entity +that is separate from the Origin. The Origin trusts the joint Attester +and Issuer to perform attestation and issue Tokens. Clients interact +with the joint Attester and Issuer for attestation and issuance. This +arrangement is shown in Figure 4.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Client + Attester + Issuer + Origin + TokenChallenge + Attestation + TokenRequest + TokenResponse + Token + | + + +
+
+
Figure 4: +Joint Attester and Issuer Deployment Model +
+
+

This model is useful if an Origin wants to offload attestation and issuance to +a trusted entity. In this model, the Attester and Issuer share an attestation +and issuance context for the Client, which is separate from the Origin's +redemption context.

+

Similar to the Shared Origin, Attester, Issuer model, Issuer-Client and +Origin-Client unlinkability in this model requires issuance and redemption +events, respectively, be separated over time or space. Attester-Origin +unlinkability requires that the Attester and Issuer do not learn the Origin +for a particular token request. For this reason, issuance protocols that +require the Issuer to learn information about the Origin, such as that which +is described in [RATE-LIMITED], are not +appropriate since they could lead to Attester-Origin unlinkability violations +through the Origin name.

+
+
+
+
+

+4.3. Joint Origin and Issuer +

+

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 +requests that come from trusted Attesters. Since the Attester and Issuer are +separate entities, this model requires some mechanism by which Issuers +establish trust in the Attester (as described in Section 3.3). +For example, in settings where the Attester is a Client-trusted service that +directly communicates with the Issuer, one way to establish this trust is via +mutually-authenticated TLS. However, alternative authentication mechanisms are +possible. This arrangement is shown in Figure 5.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Client + Attester + Issuer + Origin + TokenChallenge + Attestation + TokenRequest + TokenResponse + Token + | + + +
+
+
Figure 5: +Joint Origin and Issuer Deployment Model +
+
+

This model is useful for Origins that require Client-identifying attestation, +e.g., through the use of application-layer account information, but do not +otherwise want to learn information about individual Clients beyond what is +observed during the token redemption, such as Client IP addresses.

+

In this model, attestation contexts are separate from issuer and redemption +contexts. As a result, any type of attestation is suitable in this model.

+

Moreover, any type of token challenge is suitable assuming there is more than +one Origin involved, since no single party will have access to the identifying +Client information and unique Origin information. Issuers that produce tokens +for a single Origin are not suitable in this model since an Attester can +infer the Origin from a token request, as described in Section 3.6.3. However, +since the issuance protocol provides input secrecy, the Attester does not learn +details about the corresponding token challenge, such as whether the token +challenge is per-Origin or cross-Origin.

+
+
+
+
+

+4.4. Split Origin, Attester, Issuer +

+

In this model, the Origin, Attester, and Issuer are all operated by different +entities. As with the joint Origin and Issuer model, the Issuer accepts token +requests that come from trusted Attesters, and the details of that trust +establishment depend on the issuance protocol and relationship between +Attester and Issuer; see Section 3.3. This arrangement is shown +in Figure 1.

+

This is the most general deployment model, and is necessary for some +types of issuance protocols where the Attester plays a role in token +issuance; see [RATE-LIMITED] for one such type of issuance protocol.

+

In this model, the Attester, Issuer, and Origin have a separate view +of the Client: the Attester sees potentially sensitive Client identifying +information, such as account identifiers or IP addresses, the Issuer +sees only the information necessary for issuance, and the Origin sees +token challenges, corresponding tokens, and Client source information, +such as their IP address. As a result, attestation, issuance, and redemption +contexts are separate, and therefore any type of token challenge is suitable in +this model as long as there is more than a single Origin.

+

As in the Joint Origin and Issuer model in Section 4.3, and as +described in Section 3.6.3, if the Issuer produces tokens for a single Origin, +then per-Origin tokens are not appropriate since the Attester can infer the +Origin from a token request.

+
+
+
+
+
+
+

+5. Deployment Considerations +

+

Section 4 discusses deployment models that are possible in practice. +Beyond possible implications on security and privacy properties of the +resulting system, Privacy Pass deployments can impact the overall ecosystem +in two important ways: (1) discriminatory treatment of Clients and the gated +access to otherwise open services, and (2) centralization. This section +describes considerations relevant to these topics.

+
+
+

+5.1. Discriminatory Treatment +

+

Origins can use tokens as a signal for distinguishing between Clients +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 +consequence of this is that Privacy Pass could enable discriminatory treatment +of Clients based on Attestation support. For example, an Origin could only +authorize Clients that successfully authenticate with a token, prohibiting access +to all other Clients.

+

The type of attestation procedures supported for a particular deployment depends +greatly on the use case. For example, consider a proprietary deployment of Privacy Pass +that authorizes clients to access a resource such as an anonymization service. In this +context, it is reasonable to support specific types of attestation procedures that +demonstrate Clients can access the resource, such as with an account or specific +type of device. However, in open deployments of Privacy Pass that are used to +safeguard access to otherwise open or publicly accessible resources, diversity +in attestation procedures is critically important so as to not discriminate against +Clients that choose certain software, hardware, or identity providers.

+

In principle, Issuers should strive to mitigate discriminatory behavior by +providing equitable access to all Clients. This can be done by working with a +set of Attesters that are suitable for all Clients. In practice, this may require +tradeoffs in what type of attestation Issuers are willing to trust so as to +enable more widespread support. In other words, trusting a variety of Attesters +with a diverse set of attestation procedures would presumably increase support +among Clients, though most likely at the expense of decreasing the overall value +of tokens issued by the Issuer.

+

For example, to disallow discriminatory behavior between Clients with and +without device attestation support, an Issuer may wish to support Attesters +that support CAPTCHA-based attestation. This means that the overall attestation +value of a Privacy Pass token is bound by the difficulty in spoofing or +bypassing either one of these attestation procedures.

+
+
+
+
+

+5.2. Centralization +

+

A consequence of limiting the number of participants (Attesters or Issuers) in +Privacy Pass deployments for meaningful privacy is that it forces concentrated +centralization amongst those participants. +[CENTRALIZATION] discusses +several ways in which this might be mitigated. For example, a multi-stakeholder +governance model could be established to determine what candidate participants +are fit to operate as participants in a Privacy Pass deployment. This is +precisely the system used to control the Web's trust model.

+

Alternatively, Privacy Pass deployments might mitigate this problem through +implementation. For example, rather than centralize the role of attestation +in one or few entities, attestation could be a distributed function performed +by a quorum of many parties, provided that neither Issuers nor Origins learn +which Attester implementations were chosen. As a result, Clients could have +more opportunities to switch between attestation participants.

+
+
+
+
+
+
+

+6. Privacy Considerations +

+

The previous section discusses the impact of deployment details on +Origin-Client, Issuer-Client, and Attester-Origin unlinkability. +The value these properties affords to end users depends on +the size of anonymity sets in which Clients or Origins are +unlinkable. For example, consider two different deployments, one wherein +there exists a redemption anonymity set of size two and another +wherein there redemption anonymity set of size 232. Although +Origin-Client unlinkability guarantees that the Origin cannot link any two +requests to the same Client based on these contexts, respectively, the +probability of determining the "true" Client is higher the smaller these +sets become.

+

In practice, there are a number of ways in which the size of anonymity sets +may be reduced or partitioned, though they all center around the concept of +consistency. In particular, by definition, all Clients in an anonymity set +share a consistent view of information needed to run the issuance and +redemption protocols. An example type of information needed to run these +protocols is the Issuer public key. When two Clients have inconsistent +information, these Clients effectively have different redemption contexts and +therefore belong in different anonymity sets.

+

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.

+
+
+

+6.1. Partitioning by Issuance Metadata +

+

Any public or private metadata bits of information can be used to further +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 +the tracked Client it would set the bit to 1, and 0 otherwise. Adding +additional bits provides an exponential increase in tracking granularity +similarly to introducing more Issuers (though with more potential targeting).

+

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. Since this +metadata may be useful for practical deployments of Privacy Pass, Issuers +must balance this against the reduction in Client privacy.

+

The number of permitted metadata values often depends on deployment-specific +details. In general, limiting the amount of metadata permitted helps limit the +extent to which metadata can uniquely identify individual Clients. Failure to +bound the number of possible metadata values can therefore lead to reduction in +Client privacy. Most token types do not admit any metadata, so this bound is +implicitly enforced.

+
+
+
+
+

+6.2. Partitioning by Issuance Consistency +

+

Anonymity sets can be partitioned by information used for the issuance +protocol, including: metadata, Issuer configuration (keys), and Issuer +selection.

+

Any issuance metadata bits of information can be used to partition the Client +anonymity set. For example, any Issuer that wanted to track a single Client +could add a single metadata bit to Client tokens. For the tracked Client it +would set the bit to 1, and 0 otherwise. Adding additional bits provides an +exponential increase in tracking granularity similarly to introducing more +Issuers (though with more potential targeting).

+

The number of active Issuer configurations also contributes to anonymity set +partitioning. In particular, when an Issuer updates their configuration and +the corresponding key pair, any Client that invokes the issuance protocol with +this configuration becomes part of a set of Clients which also ran the +issuance protocol using the same configuration. Issuer configuration updates, +e.g., due to key rotation, are an important part of hedging against long-term +private key compromise. In general, key rotations represent a trade-off between +Client privacy and Issuer security. Therefore, it is important that key +rotations occur on a regular cycle to reduce the harm of an Issuer key +compromise.

+

Lastly, if Clients are willing to issue and redeem tokens from a large number +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 +many Issuers and an Origin later challenges that Client for a token from each +Issuer, the Origin can learn information about the Client. This arrangement +might happen if Clients request tokens from different Issuers, each of which +have different Attester preferences. Each per-Issuer token that a Client holds +essentially corresponds to a bit of information about the Client that Origin +learns. Therefore, there is an exponential loss in privacy relative to the +number of Issuers.

+

The fundamental problem here is that the number of possible issuance +configurations, including the keys in use and the Issuer identities themselves, +can partition the Client anonymity set. To mitigate this problem, Clients +SHOULD bound the number of active issuance configurations per Origin as well as +across Origins. Moreover, Clients SHOULD employ some form of consistency +mechanism to ensure that they receive the same configuration information and +are not being actively partitioned into smaller anonymity sets. See +[CONSISTENCY] for possible consistency +mechanisms. Depending on the deployment, the Attester might assist the Client +in applying these consistency checks across clients. Failure to apply a +consistency check can allow Client-specific keys to violate Origin-Client +unlinkability.

+
+
+
+
+

+6.3. Partitioning by Side-Channels +

+

Side-channel attacks, such as those based on timing correlation, could be +used to reduce anonymity set size. In particular, +for interactive tokens that are bound to a Client-specific redemption +context, the anonymity set of Clients during the issuance protocol consists +of those Clients that started issuance between the time of the Origin's +challenge and the corresponding token redemption. Depending on the number +of Clients using a particular Issuer during that time window, the set can +be small. Applications should take such side channels into consideration before +choosing a particular deployment model and type of token challenge and +redemption context.

+
+
+
+
+
+
+

+7. Security Considerations +

+

This document describes security and privacy requirements for the Privacy Pass +redemption and issuance protocols. It also describes deployment models built +around non-collusion assumptions and privacy considerations for using Privacy +Pass within those models. Ensuring Client privacy -- separation of attestation +and redemption contexts -- requires active work on behalf of the Client, +especially in the presence of malicious Issuers and Origins. Implementing +mitigations discussed in Section 4 and Section 6 is therefore necessary +to ensure that Privacy Pass offers meaningful privacy improvements to end-users.

+
+
+

+7.1. Token Caching +

+

Depending on the Origin's token challenge, Clients can request and cache more +than one token using an issuance protocol. Cached tokens help improve privacy by +separating the time of token issuance from the time of token redemption, and +also allow Clients to reduce the overhead of receiving new tokens via the +issuance protocol.

+

As a consequence, Origins that send token challenges which are compatible with +cached tokens need to take precautions to ensure that tokens are not replayed. +This is typically done via keeping track of tokens that are redeemed for the +period of time in which cached tokens would be accepted for particular +challenges.

+

Moreover, since tokens are not intrinsically bound to Clients, it is possible +for malicious Clients to collude and share tokens in a so-called "hoarding +attack." 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 +that would violate an Origin's attempt to limit tokens to any one particular +Client. In general, mechanisms for mitigating hoarding attacks depend on the +deployment model and use case. For example, in the Joint Origin and Issuer model, +comparing the issuance and redemption contexts can help detect hoarding attacks, +i.e., if the distribution of redemption contexts is noticeably different from the +distribution of issuance contexts. Rate limiting issuance, either at the Client, +Attester, or Issuer, can also help mitigate these attacks.

+
+
+
+
+
+
+

+8. IANA Considerations +

+

This document has no IANA actions.

+
+
+
+

+9. References +

+
+
+

+9.1. Normative References +

+
+
[AUTHSCHEME]
+
+Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass HTTP Authentication Scheme", Work in Progress, Internet-Draft, draft-ietf-privacypass-auth-scheme-14, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
+
+
+
+
+

+9.2. Informative References +

+
+
[CENTRALIZATION]
+
+Nottingham, M., "Centralization, Decentralization, and Internet Standards", Work in Progress, Internet-Draft, draft-nottingham-avoiding-internet-centralization-14, , <https://datatracker.ietf.org/doc/html/draft-nottingham-avoiding-internet-centralization-14>.
+
+
[CONSISTENCY]
+
+Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, "Key Consistency and Discovery", Work in Progress, Internet-Draft, draft-ietf-privacypass-key-consistency-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01>.
+
+
[DMS2004]
+
+Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The Second-Generation Onion Router", , <https://svn.torproject.org/svn/projects/design-paper/tor-design.html>.
+
+
[HIJK21]
+
+Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee, C. K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S., Sung, Y. C., and A. Zhang, "PrivateStats: De-Identified Authenticated Logging at Scale", , <https://research.fb.com/privatestats>.
+
+
[ISSUANCE]
+
+Celi, S., Davidson, A., Valdez, S., and C. A. Wood, "Privacy Pass Issuance Protocol", Work in Progress, Internet-Draft, draft-ietf-privacypass-protocol-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-protocol-15>.
+
+
[KLOR20]
+
+Kreuter, B., Lepoint, T., Orrù, M., and M. Raykova, "Anonymous Tokens with Private Metadata Bit", Springer International Publishing, Advances in Cryptology – CRYPTO 2020 pp. 308-336, DOI 10.1007/978-3-030-56784-2_11, ISBN ["9783030567835", "9783030567842"], , <https://doi.org/10.1007/978-3-030-56784-2_11>.
+
+
[OHTTP]
+
+Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in Progress, Internet-Draft, draft-ietf-ohai-ohttp-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp-10>.
+
+
[PrivacyPassCloudflare]
+
+Sullivan, N., "Cloudflare Supports Privacy Pass", n.d., <https://blog.cloudflare.com/cloudflare-supports-privacy-pass/>.
+
+
[PrivacyPassExtension]
+
+"Privacy Pass Browser Extension", n.d., <https://github.com/privacypass/challenge-bypass-extension>.
+
+
[RATE-LIMITED]
+
+Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and C. A. Wood, "Rate-Limited Token Issuance Protocol", Work in Progress, Internet-Draft, draft-privacypass-rate-limit-tokens-03, , <https://datatracker.ietf.org/doc/html/draft-privacypass-rate-limit-tokens-03>.
+
+
[RFC9334]
+
+Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/rfc/rfc9334>.
+
+
+
+
+
+
+
+

+Appendix A. Acknowledgements +

+

The authors would like to thank Eric Kinnear, Scott Hendrickson, Tommy Pauly, +Christopher Patton, Benjamin Schwartz, Martin Thomson, Steven Valdez and other +contributors of the Privacy Pass Working Group for many helpful contributions +to this document.

+
+
+
+
+

+Authors' Addresses +

+
+
Alex Davidson
+
LIP
+
Lisbon
+
Portugal
+ +
+
+
Jana Iyengar
+
Fastly
+ +
+
+
Christopher A. Wood
+
Cloudflare
+
101 Townsend St
+
+San Francisco,
+
United States of America
+ +
+
+
+ + + diff --git a/chris-wood-patch-7/draft-ietf-privacypass-architecture.txt b/chris-wood-patch-7/draft-ietf-privacypass-architecture.txt new file mode 100644 index 00000000..e64c0ae2 --- /dev/null +++ b/chris-wood-patch-7/draft-ietf-privacypass-architecture.txt @@ -0,0 +1,1379 @@ + + + + +Network Working Group A. Davidson +Internet-Draft LIP +Intended status: Informational J. Iyengar +Expires: 5 April 2024 Fastly + C. A. Wood + Cloudflare + 3 October 2023 + + + The Privacy Pass Architecture + draft-ietf-privacypass-architecture-latest + +Abstract + + This document specifies the Privacy Pass architecture and + requirements for its constituent protocols used for authorization + based on privacy-preserving authentication mechanisms. It describes + the conceptual model of Privacy Pass and its protocols, its security + and privacy goals, practical deployment models, and recommendations + for each deployment model that helps ensure the desired security and + privacy goals are fulfilled. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 5 April 2024. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Architecture + 3.1. Overview + 3.2. Use Cases + 3.3. Privacy Goals and Threat Model + 3.4. Redemption Protocol + 3.5. Issuance Protocol + 3.5.1. Attester Role + 3.5.2. Issuer Role + 3.5.3. Issuance Metadata + 3.5.4. Future Issuance Protocol Requirements + 3.6. Information Flow + 3.6.1. Token Challenge Flow + 3.6.2. Attestation Flow + 3.6.3. Issuance Flow + 3.6.4. Token Redemption Flow + 4. Deployment Models + 4.1. Shared Origin, Attester, Issuer + 4.2. Joint Attester and Issuer + 4.3. Joint Origin and Issuer + 4.4. Split Origin, Attester, Issuer + 5. Deployment Considerations + 5.1. Discriminatory Treatment + 5.2. Centralization + 6. Privacy Considerations + 6.1. Partitioning by Issuance Metadata + 6.2. Partitioning by Issuance Consistency + 6.3. Partitioning by Side-Channels + 7. Security Considerations + 7.1. Token Caching + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. Acknowledgements + Authors' Addresses + +1. Introduction + + Privacy Pass is an architecture for authorization based on privacy- + preserving authentication mechanisms. In other words, relying + parties authenticate clients in a privacy-preserving way, i.e., + without learning any unique, per-client information through the + authentication protocol, and then make authorization decisions on the + basis of that authentication succeeding or failing. Possible + authorization decisions might be to provide clients with read access + to a particular resource or write access to a particular resource. + + 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 clients across sessions and interactions. + Privacy Pass takes a different approach: instead of presenting + linkable state-carrying information to servers, e.g., a cookie + indicating whether or not the client is an authorized user or has + completed some prior challenge, clients present unlinkable proofs + that attest to this information. These proofs, or tokens, are + private in the sense that a given token cannot be linked to the + protocol interaction where that token was initially issued. + + At a high level, the Privacy Pass architecture consists of two + protocols: redemption and issuance. The redemption protocol, + described in [AUTHSCHEME], runs between Clients and Origins + (servers). It allows Origins to challenge Clients to present tokens + for consumption. Origins verify the token to authenticate the Client + -- without learning any specific information about the Client -- and + then make an authorization decision on the basis of the token + verifying successfully or not. Depending on the type of token, e.g., + whether or not it can be cached, the Client either presents a + previously obtained token or invokes an issuance protocol, such as + [ISSUANCE], to acquire a token to present as authorization. + + This document describes requirements for both redemption and issuance + protocols and how they interact. It also provides recommendations on + how the architecture should be deployed to ensure the privacy of + clients and the security of all participating entities. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The following terms are used throughout this document: + + Client: An entity that seeks authorization to an Origin. Using + [RFC9334] terminology, Clients implement the RATS Attester role. + + Token: A cryptographic authentication message used for authorization + decisions, produced as output from an issuance mechanism or + protocol. + + Origin: An entity that consumes tokens presented by Clients and uses + them to make authorization decisions. + + Token challenge: The mechanism by which Origins request tokens from + Clients, often denoted TokenChallenge. + + Token request: A message used by Clients to request a token from an + Issuer, often denoted TokenRequest. + + Token response: A message used by Issuers to send tokens to a + Client, often denoted TokenResponse. + + Redemption: The mechanism by which Clients present tokens to Origins + for the purposes of authorization. + + Issuer: An entity that issues tokens to Clients for properties + attested to by the Attester. + + Issuance: The mechanism by which an Issuer produces tokens for + Clients. + + Attester: An entity that attests to properties of Clients for the + purposes of token issuance. Using [RFC9334] terminology, + Attesters implement the RATS Verifier role. + + Attestation procedure: The procedure by which an Attester determines + whether or not a Client has the specific set of properties that + are necessary for token issuance. + + The trust relationships between each of the entities in this list is + further elaborated upon in Section 3.3. + +3. Architecture + + The Privacy Pass architecture consists of four logical entities -- + Client, Origin, Issuer, and Attester -- that work in concert for + token redemption and issuance. This section presents an overview of + Privacy Pass, a high-level description of the threat model and + privacy goals of the architecture, and the goals and requirements of + the redemption and issuance protocols. Deployment variations for the + Origin, Issuer, and Attester in this architecture, including + considerations for implementing these entities, are further discussed + in Section 4. + +3.1. Overview + + This section describes the typical interaction flow for Privacy Pass. + + 1. A Client interacts with an Origin by sending a request or + otherwise interacting with the Origin in a way that triggers a + response containing a token challenge. The token challenge + indicates a specific Issuer to use. + + 2. If the Client already has a token available that satisfies the + token challenge, e.g., because the Client has a cache of + previously issued tokens, it can skip to step 6 and redeem its + token; see Section 7.1 for security considerations of cached + tokens. + + 3. If the Client does not have a token available and decides it + wants to obtain one (or more) bound to the token challenge, it + then invokes the issuance protocol. As a prerequisite to the + issuance protocol, the Client runs the deployment-specific + attestation process that is required for the designated Issuer. + Client attestation can be done via proof of solving a CAPTCHA, + checking device or hardware attestation validity, etc.; see + Section 3.5.1 for more details. + + 4. If the attestation process completes successfully, the client + creates a token request to send to the designated Issuer + (generally via the Attester, though it is not required to be sent + through the Attester). The Attester and Issuer might be + functions on the same server, depending on the deployment model + (see Section 4). Depending on the attestation process, it is + possible for attestation to run alongside the issuance protocol, + e.g., where Clients send necessary attestation information to the + Attester along with their token request. If the attestation + process fails, the Client receives an error and issuance aborts + without a token. + + 5. The Issuer generates a token response based on the token request, + which is returned to the Client (generally via the Attester). + Upon receiving the token response, the Client computes a token + from the token challenge and token response. This token can be + validated by anyone with the per-Issuer key, but cannot be linked + to the content of the token request or token response. + + 6. If the Client has a token, it includes it in a subsequent request + to the Origin, as authorization. This token is sent only once in + reaction to a challenge; Clients do not send tokens more than + once, even if they receive duplicate or redundant challenges. + The Origin validates that the token was generated by the expected + Issuer and has not already been redeemed for the corresponding + token challenge. If the Client does not have a token, perhaps + because issuance failed, the client does not reply to the + Origin's challenge with a new request. + + +--------+ +--------+ +----------+ +--------+ + | Origin | | Client | | Attester | | Issuer | + +---+----+ +---+----+ +----+-----+ +---+----+ + | | | | + |<----- Request ------+ | | + +-- TokenChallenge -->| | | + | |<== Attestation ==>| | + | | | | + | +--------- TokenRequest ------->| + | |<-------- TokenResponse -------+ + |<-- Request+Token ---+ | | + | | | | + + Figure 1: Privacy pass redemption and issuance protocol interaction + +3.2. Use Cases + + Use cases for Privacy Pass are broad and depend greatly on the + deployment model as discussed in Section 4. The initial motivating + use case for Privacy Pass [PrivacyPassCloudflare] was to help rate- + limit malicious or otherwise abusive traffic from services such as + Tor [DMS2004]. The generalized and evolved architecture described in + this document also work for this use case. However, for added + clarity, some more possible use cases are described below. + + * Low-quality, anti-fraud signal for open Internet services. Tokens + can attest that the Client behind the user agent is likely not a + bot attempting to perform some form of automated attack such as + credential stuffing. Example attestation procedures for this use + case might be solving some form of CAPTCHA or presenting evidence + of a valid, unlocked device in good standing. + + * Privacy-preserving authentication for proprietary services. + Tokens can attest that the Client is a valid subscriber for a + proprietary service, such as a deployment of Oblivious HTTP + [OHTTP]. + +3.3. Privacy Goals and Threat Model + + The end-to-end flow for Privacy Pass described in Section 3.1 + involves three different types of contexts: + + Redemption context: The interactions and set of information shared + between the Client and Origin, i.e., the information that is + provided or otherwise available to the Origin during redemption + that might be used to identify a Client and construct a token + challenge. This context includes all information associated with + redemption, such as the timestamp of the event, Client-visible + information (including the IP address), and the Origin name. + + Issuance context: The interactions and set of information shared + between the Client, Attester, 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. This + context includes all information associated with issuance, such as + the timestamp of the event, any Client-visible information + (including the IP address), and the Origin name (if revealed + during issuance). This does not include the token challenge in + its entirety, as that is kept secret from the Issuer during the + issuance protocol. + + Attestation context: The interactions and set of information shared + between the Client and Attester only, for the purposes of + attesting the validity of the Client, that is provided or + otherwise available during attestation that might be used to + identify the Client. This context includes all information + associated with attestation, such as the timestamp of the event + and any Client-visible information, including information needed + for the attestation procedure to complete. + + The privacy goals of Privacy Pass assume a threat model in which + Origins trust specific Issuers to produce tokens, and Issuers in turn + trust one or more Attesters to correctly run the attestation + procedure with Clients. This arrangement ensures that tokens which + validate for a given Issuer were only issued to a Client that + successfully completed attestation with an Attester that the Issuer + trusts. Moreover, this arrangement means that if an Origin accepts + tokens issued by an Issuer that trusts multiple Attesters, then a + Client can use any one of these Attesters to issue and redeem tokens + for the Origin. Whether or not these different entities in the + architecture collude for learning redemption, issuance, or + attestation contexts, as well as the necessary preconditions for + context unlinkability, depends on the deployment model; see Section 4 + for more details. + + The mechanisms for establishing trust between each entity in this + arrangement are deployment-specific. For example, in settings where + Clients interact with Issuers through an Attester, Attesters and + Issuers might use mutually authenticated TLS to authenticate one + another. In settings where Clients do not communicate with Issuers + through an Attester, the Attesters might convey this trust via a + digital signature that Issuers can verify. + + Clients explicitly trust Attesters to perform attestation correctly + and in a way that does not violate their privacy. In particular, + this means that Attesters which may be privy to private information + about Clients are trusted to not disclose this information to non- + colluding parties. Colluding parties are assumed to have access to + the same information; see Section 4 for more about different + deployment models and non-collusion assumptions. However, Clients + assume Issuers and Origins are malicious. + + Given this threat model, the privacy goals of Privacy Pass are + oriented around unlinkability based on redemption, issuance, and + attestation contexts, as described below. + + 1. Origin-Client unlinkability. This means that given two + redemption contexts, the Origin cannot determine if both + redemption contexts correspond to the same Client or two + different Clients. Informally, this means that a Client in a + redemption context is indistinguishable from any other Client + that might use the same redemption context. The set of Clients + that share the same redemption context is referred to as a + redemption anonymity set. + + 2. Issuer-Client unlinkability. This is similar to Origin-Client + unlinkability in that a Client in an issuance context is + indistinguishable from any other Client that might use the same + issuance context. The set of Clients that share the same + issuance context is referred to as an issuance anonymity set. + + 3. Attester-Origin unlinkability. This is similar to Origin-Client + and Issuer-Client unlinkability. It means that given two + attestation contexts, the Attester cannot determine if both + contexts correspond to the same Origin or two different Origins. + The set of Origins that share the same attestation context is + referred to as an attestation anonymity set. + + 4. Redemption context unlinkability. Given two redemption contexts, + the Origin cannot determine which issuance and attestation + contexts each redemption corresponds to, even with the + collaboration of the Issuer and Attester (should these be + different parties). This means that any information that may be + learned about the Client during the issuance and attestation + flows cannot be used by the Origin to compromise Client privacy. + + 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. The Attester, Issuer, and Origin only + receive the information necessary to perform their respective + functions. + + The manner in which these unlinkability properties are achieved + depends on the deployment model, type of attestation, and issuance + protocol details. For example, as discussed in Section 4, in some + cases it is necessary to use an anonymization service such as Tor + [DMS2004] which hides Clients IP addresses. In general, + anonymization services ensures that all Clients which use the service + are indistinguishable from one another, though in practice there may + be small distinguishing features (TLS fingerprints, HTTP headers, + etc). Moreover, Clients generally trust these services to not + disclose private Client information (such as IP addresses) to + untrusted parties. Failure to use an anonymization service when + interacting with Attesters, Issuers, or Origins can allow the set of + possible Clients to be partitioned by the Client's IP address, and + can therefore lead to unlinkability violations. Similarly, malicious + Origins may attempt to link two redemption contexts together by using + Client-specific Issuer public keys. See Section 5 and Section 6 for + more information. + + The remainder of this section describes the functional properties and + security requirements of the redemption and issuance protocols in + more detail. Section 3.6 describes how information flows between + Issuer, Origin, Client, and Attester through these protocols. + +3.4. Redemption Protocol + + The Privacy Pass redemption protocol, described in [AUTHSCHEME], is + an authorization protocol wherein Clients present tokens to Origins + for authorization. Normally, redemption is preceded by a challenge, + wherein the Origin challenges Clients for a token with a + TokenChallenge ([AUTHSCHEME], Section 2.1) and, if possible, Clients + present a valid Token ([AUTHSCHEME], Section 2.2) in reaction to the + challenge. This interaction is shown below. + + +--------+ +--------+ + | Origin | | Client | + +---+----+ +---+----+ + | | + |<----- Request ------+ + +-- TokenChallenge -->| + | | <== Issuance protocol ==> + |<-- Request+Token ---+ + | | + + Figure 2: Challenge and redemption protocol interaction + + Alternatively, when configured to do so, Clients may + opportunistically present Token values to Origins without a + corresponding TokenChallenge. + + The structure and semantics of the TokenChallenge and Token messages + depend on the issuance protocol and token type being used; see + [AUTHSCHEME] for more information. + + The challenge provides the client with the information necessary to + obtain tokens that the server might subsequently accept in the + redemption context. There are a number of ways in which the token + may vary based on this challenge, including: + + * Issuance protocol. The challenge identifies the type of issuance + protocol required for producing the token. Different issuance + protocols have different security properties, e.g., some issuance + protocols may produce tokens that are publicly verifiable, whereas + others may not have this property. + + * Issuer identity. Token challenges identify which Issuers are + trusted for a given issuance protocol. As described in + Section 3.3, the choice of Issuer determines the type of Attesters + and attestation procedures possible for a token from the specified + Issuer, but the Origin does not learn exactly which Attester was + used for a given token issuance event. + + * Redemption context. Challenges can be bound to a given redemption + context, 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 redeemed non-interactively, whereas + a fresh and random redemption context means that the redeemed + token must be issued only after the client receives the challenge. + See Section 2.1.1 of [AUTHSCHEME] for more details. + + * Per-Origin or cross-Origin. Challenges can be constrained to the + Origin for which the challenge originated (referred to as per- + Origin tokens), or can be used across multiple Origins (referred + to as cross-Origin tokens). The set of Origins for which a cross- + Origin token is applicable is referred to as the cross-Origin set. + Opting into this set is done by explicitly agreeing on the + contents of the set. Every Origin in a cross-Origin set, by + opting in, agrees to admit tokens for any other Origin in the set. + See Section 2.1.1 of [AUTHSCHEME] for more information on how this + set is created. + + Origins that admit cross-Origin tokens bear some risk of allowing + tokens issued for one Origin to be spent in an interaction with + another Origin. In particular, cross-Origin tokens issued based on a + challenge for one Origin can be redeemed at another Origin in the + cross-Origin set, which can make it difficult to regulate token + consumption. Depending on the use case, Origins may need to maintain + state to track redeemed tokens. For example, Origins that accept + cross-Origin tokens across shared redemption contexts SHOULD track + which tokens have been redeemed already in those redemption contexts, + since these tokens can be issued and then spent multiple times for + any such challenge. Note that Clients which redeem the same token to + multiple Origins do risk those Origins being able to link Client + activity together, which can disincentivize this behavior. See + Section 2.1.1 of [AUTHSCHEME] for discussion. + + How Clients respond to token challenges can have privacy + implications. For example, if an Origin allows the Client to choose + an Issuer, then the choice of Issuer can reveal information about the + Client used to partition anonymity sets; see Section 6.2 for more + information about these privacy considerations. + +3.5. Issuance Protocol + + 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. + + The structure and semantics of the TokenRequest and TokenResponse + messages depend on the issuance protocol and token type being used; + see [ISSUANCE] for more information. + + Clients interact with the Attester and Issuer to produce a token for + a challenge. The context in which an Attester vouches for a Client + during issuance is referred to as the attestation context. This + context includes all information associated with the issuance event, + such as the timestamp of the event and Client-visible information, + including the IP address or other information specific to the type of + attestation done. + + Each issuance protocol may be different, e.g., in the number and + types of participants, underlying cryptographic constructions used + when issuing tokens, and even privacy properties. + + Clients initiate the issuance protocol using the token challenge, a + randomly generated nonce, and public key for the Issuer, all of which + are the Client's private input to the protocol and ultimately bound + to an output Token; see Section 2.2 of [AUTHSCHEME] for details. + Future specifications may change or extend the Client's input to the + issuance protocol to produce Tokens with a different structure. + + Token properties vary based on the issuance protocol. Important + properties supported in this architecture are described below. + + 1. Public verifiability. This means the Token can be verified using + the Issuer public key. A Token that does not have public + verifiability can only be verified using the Issuer secret key. + + 2. Public metadata. This means that the Token can be + cryptographically bound to arbitrary public information. See + Section 6.1 for privacy considerations of public metadata. + + 3. Private metadata. This means that the Token can be + cryptographically bound to arbitrary private information, i.e., + information that the Client does not observe during Token + issuance or redemption. See Section 6.1 for privacy + considerations of private metadata. + + The issuance protocol itself can be any interactive protocol between + Client, Issuer, or other parties that produces a valid token bound to + the Client's private input, subject to the following security + requirements. + + 1. Unconditional input secrecy. The issuance protocol MUST NOT + reveal anything about the Client's private input, including the + challenge and nonce, to the Attester or Issuer, regardless of the + hardness assumptions of the underlying cryptographic protocol(s). + This property is sometimes also referred to as blindness. + + 2. One-more forgery security. The issuance protocol MUST NOT allow + malicious Clients or Attesters (acting as Clients) to forge + tokens offline or otherwise without interacting with the Issuer + directly. + + 3. Concurrent security. The issuance protocol MUST be safe to run + concurrently with arbitrarily many Clients, Attesters and + Issuers. + + See Section 3.5.4 for requirements on new issuance protocol variants + and related extensions. + + In the sections below, we describe the Attester and Issuer roles in + more detail. + +3.5.1. Attester Role + + In Privacy Pass, attestation is the process by which an Attester + bears witness to, confirms, or authenticates a Client so as to verify + properties about the Client that are required for Issuance. 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. + + [RFC9334] describes an architecture for attestation procedures. + Using that architecture as a conceptual basis, Clients are RATS + attesters that produce attestation evidence, and Attesters are RATS + verifiers that appraise the validity of attestation evidence. + + The type of attestation procedure is a deployment-specific option and + outside the scope of the issuance protocol. Example attestation + procedures are below. + + * Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be + attested to have this capability for the purpose of being ruled + out as a bot or otherwise automated Client. + + * Presenting evidence of Client device validity. Some Clients run + on trusted hardware that are capable of producing device-level + attestation evidence. + + * Proving properties about Client state. Clients can be associated + with state and the Attester can verify this state. Examples of + state include the Client's geographic region and whether the + Client has a valid application-layer account. + + Attesters may support different types of attestation procedures. + + Each attestation procedure has different security properties. For + example, attesting to having a valid account is different from + attesting to running on trusted hardware. Supporting multiple + attestation procedures is an important step towards ensuring + equitable access for Clients; see Section 5.1. + + 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. For instance, increasing the number + of required attestation procedures could decrease the overall + anonymity set size. As an example, the number of Clients that have + solved a CAPTCHA in the past day, that have a valid account, and that + are running on a trusted device is less than the number of Clients + that have solved a CAPTCHA in the past day. See Section 6.2 for more + discussion of how the variety of attestation procedures can + negatively impact Client privacy. + + Depending on the issuance protocol, the Issuer might learn + information about the Origin. To ensure Issuer-Client unlinkability, + the Issuer should be unable to link that information to a specific + Client. For such issuance protocols where the Attester has access to + Client-specific information, such as is the case for attestation + procedures that involve Client-specific information (such as + application-layer account information) or for deployment models where + the Attester learns Client-specific information (such as Client IP + addresses), Clients trust the Attester to not share any Client- + specific information with the Issuer. In deployments where the + Attester does not learn Client-specific information, or where the + Attester and Issuer are operated by the same entity (such as in the + Joint Attester and Issuer model described in Section 4.2), the Client + does not need to explicitly trust the Attester in this regard. + + 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. Broken + attestation procedures are considered exceptional events and require + configuration changes to address the underlying cause. For example, + if an attestation procedure is compromised or subverted because of a + zero-day exploit on devices that implement the attestation procedure, + then the corresponding attestation procedure should be untrusted + until the exploit is patched. Addressing changes in attestation + quality is therefore a deployment-specific task. In Split Attester + and Issuer deployments (see Section 4.4), Issuers can choose to + remove compromised Attesters from their trusted set until the + compromise is patched. + + From the perspective of an Origin, tokens produced by an Issuer with + at least one compromised Attester cannot be trusted assuming the + Origin does not know which attestation procedure was used for + issuance. This is because the Origin cannot distinguish between + tokens that were issued via compromised Attesters and tokens that + were issued via uncompromised Attesters absent some distinguishing + information in the tokens themselves or from the Issuer. As a + result, until the attestation procedure is fixed, the Issuer cannot + be trusted by Origins. Moreover, as a consequence, any tokens issued + by an Issuer with a compromised attester may no longer be trusted by + Origins, even if those tokens were issued to Clients interacting with + an uncompromised Attester. + +3.5.2. Issuer Role + + In Privacy Pass, the Issuer is responsible for completing the + issuance protocol for Clients that complete attestation through a + trusted Attester. As described in Section 3.5.1, Issuers explicitly + trust Attesters to correctly and reliably perform attestation. + Origins explicitly trust Issuers to only issue tokens from trusted + Attesters. Clients do not explicitly trust Issuers. + + Depending on the deployment model case, issuance may require some + form of Client anonymization service, similar to an IP-hiding proxy, + so that Issuers cannot learn information about Clients. This can be + provided by an explicit participant in the issuance protocol, or it + can be provided via external means, such as through the use of an IP- + hiding proxy service like Tor [DMS2004]. In general, Clients SHOULD + minimize or remove identifying information where possible when + invoking the issuance protocol. + + Issuers are uniquely identifiable by all Clients with a consistent + identifier. In a web context, this identifier might be the Issuer + host name. Issuers maintain one or more configurations, including + issuance key pairs, for use in the issuance protocol. Each + configuration is assumed to have a unique and canonical identifier, + sometimes referred to as a key identifier or key ID. Issuers can + rotate these configurations as needed to mitigate risk of compromise; + see Section 6.2 for more considerations around configuration + rotation. The Issuer public key for each active configuration is + made available to Origins and Clients for use in the issuance and + redemption protocols. + +3.5.3. Issuance Metadata + + Certain instantiations of the issuance protocol may permit public or + private metadata to be cryptographically bound to a token. As an + example, one trivial way to include public metadata is to assign a + unique Issuer public key for each value of metadata, such that N keys + yields log_2(N) bits of metadata. Metadata may be public or private. + + Public metadata is that which clients can observe as part of the + token issuance flow. Public metadata can either be transparent or + opaque. For example, transparent public metadata is a value that the + client either generates itself, or the Issuer provides during the + issuance flow and the client can check for correctness. Opaque + public metadata is metadata the client can see but cannot check for + correctness. As an example, the opaque public metadata might be a + "fraud detection signal", computed on behalf of the Issuer, during + token issuance. Generally speaking, Clients cannot determine if this + value is generated in a way that permits tracking. + + Private metadata is that which Clients cannot observe as part of the + token issuance flow. Such instantiations can be built on the Private + Metadata Bit construction from Kreuter et al. [KLOR20] or the + attribute-based VOPRF from Huang et al. [HIJK21]. + + Metadata can be arbitrarily long or bounded in length. The amount of + permitted metadata may be determined by application or by the + underlying cryptographic protocol. The total amount of metadata bits + included in a token is the sum of public and private metadata bits. + Every bit of metadata can be used to partition the Client issuance or + redemption anonymity sets; see Section 6.1 for more information. + +3.5.4. Future Issuance Protocol Requirements + + The Privacy Pass architecture and ecosystem are both intended to be + receptive to extensions that expand the current set of + functionalities through new issuance protocols. Each new issuance + protocol and extension MUST adhere to the following requirements: + + 1. Include a detailed analysis of the privacy impacts of the + extension, why these impacts are justified, and guidelines on how + to use the protocol to mitigate or minimize negative deployment + or privacy consequences discussed in Section 5 and Section 6, + respectively. + + 2. Adhere to the guidelines specified in Section 3.5.2 for managing + Issuer public key data. + + 3. Clearly specify how to interpret and validate TokenChallenge and + Token messages that are exchanged during the redemption protocol. + +3.6. Information Flow + + The end-to-end process of redemption and issuance protocols involves + information flowing between Issuer, Origin, Client, and Attester. + That information can have implications on the privacy goals that + Privacy Pass aims to provide as outlined in Section 3.3. In this + section, we describe the flow of information between each party. How + this information affects the privacy goals in particular deployment + models is further discussed in Section 4. + +3.6.1. Token Challenge Flow + + To use Privacy Pass, Origins choose an Issuer from which they are + willing to accept tokens. Origins then construct a token challenge + using this specified Issuer and information from the redemption + context it shares with the Client. This token challenge is then + delivered to a Client. The token challenge conveys information about + the Issuer and the redemption context, such as whether the Origin + desires a per-Origin or cross-Origin token. Any entity that sees the + token challenge might learn things about the Client as known to the + Origin. This is why input secrecy is a requirement for issuance + protocols, as it ensures that the challenge is not directly available + to the Issuer. + +3.6.2. Attestation Flow + + Clients interact with the Attester to prove that they meet some + required set of properties. In doing so, Clients contribute + information to the attestation context, which might include sensitive + information such as application-layer identities, IP addresses, and + so on. Clients can choose whether or not to contribute this + information based on local policy or preference. + +3.6.3. Issuance Flow + + Clients use the issuance protocol to produce a token bound to a token + challenge. In doing so, there are several ways in which the issuance + protocol contributes information to the attestation or issuance + contexts. For example, a token request may contribute information to + the attestation or issuance contexts as described below. + + * Issuance protocol. The type of issuance protocol can contribute + information about the Issuer's capabilities to the attestation or + issuance contexts, as well as the capabilities of a given Client. + For example, if a Client is presented with multiple issuance + protocol options, then the choice of which issuance protocol to + use can contribute information about the Client's capabilities. + + * Issuer configuration. Information about the Issuer configuration, + such as its identity or the public key used to validate tokens it + creates, can be revealed during issuance and contribute to the + attestation or issuance contexts. + + * Attestation information. The issuance protocol can contribute + information to the attestation or issuance contexts based on what + attestation procedure the Issuer uses to trust a token request. + In particular, a token request that is validated by a given + Attester means that the Client which generated the token request + must be capable of the completing the designated attestation + procedure. + + * Origin information. The issuance protocol can contribute + information about the Origin that challenged the Client in + Section 3.6.1. In particular, a token request designated for a + specific Issuer might imply that the resulting token is for an + Origin that trusts the specified Issuer. However, this is not + always true, as some token requests can correspond to cross-Origin + tokens, i.e., they are tokens that would be accepted at any Origin + that accepts the cross-Origin token. + + Moreover, a token may contribute information to the issuance + attestation or contexts as described below. + + * Origin information. The issuance protocol can contribute + information about the Origin in how it responds to a token + request. For example, if an Issuer learns the Origin during + issuance and is also configured to respond in some way on the + basis of that information, and the Client interacts with the + Issuer transitively through the Attester, that response can reveal + information to the Attester. + + * Token. The token produced by the issuance protocol can contain + information from the issuance context. In particular, depending + on the issuance protocol, tokens can contain public or private + metadata, and Issuers can choose that metadata on the basis of + information in the issuance context. + + Exceptional cases in the issuance protocol, such as when either the + Attester or Issuer aborts the protocol, can contribute information to + the attestation or issuance contexts. The extent to which + information in this context harms the Issuer-Client or Attester- + Origin unlinkability goals in Section 3.3 depends on deployment + model; see Section 4. Clients can choose whether or not to + contribute information to these contexts based on local policy or + preference. + +3.6.4. Token Redemption Flow + + Clients send tokens to Origins during the redemption protocol. Any + information that is added to the token during issuance can therefore + be sent to the Origin. Information can either be explicitly passed + in a token, or it can be implicit 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 a token + challenge, this can reveal information to the Origin that it might + not otherwise have access to. However, an Origin cannot necessarily + distinguish between a Client that fails to complete issuance and one + that ignores the token challenge altogether. + +4. Deployment Models + + The Origin, Attester, and Issuer portrayed in Figure 1 can be + instantiated and deployed in a number of ways. The deployment model + directly influences the manner in which attestation, issuance, and + redemption contexts are separated to achieve Origin-Client, Issuer- + Client, and Attester-Origin unlinkability. + + This section covers some expected deployment models and their + corresponding security and privacy considerations. Each deployment + model is described in terms of the trust relationships and + communication patterns between Client, Attester, Issuer, and Origin. + Entities drawn within the same bounding box are assumed to be + operated by the same party and are therefore able to collude. + Collusion can enable linking of attestation, issuance, and redemption + contexts. Entities not drawn within the same bounding box are + assumed to not collude, meaning that entities operated by separate + parties that do not collude. Mechanisms for enforcing non-collusion + are out of scope for this architecture. + +4.1. Shared Origin, Attester, Issuer + + In this model, the Origin, Attester, and Issuer are all operated by + the same entity, as shown in Figure 3. + + +---------------------------------------------. + +--------+ | +----------+ +--------+ +--------+ | + | Client | | | Attester | | Issuer | | Origin | | + +---+----+ | +-----+----+ +----+---+ +---+----+ | + | `-------|---------------|-------------|------' + |<-------------------------------- TokenChallenge --+ + | | | | + |<=== Attestation ===>| | | + | | | | + +----------- TokenRequest ----------->| | + |<---------- TokenResponse -----------+ | + | | + +--------------------- Token -----------------------> + | | + + Figure 3: Shared Deployment Model + + This model represents the initial deployment of Privacy Pass, as + described in [PrivacyPassCloudflare]. In this model, the Attester, + Issuer, and Origin share the attestation, issuance, and redemption + contexts. As a result, attestation mechanisms that can uniquely + identify a Client, e.g., requiring that Clients authenticate with + some type of application-layer account, are not appropriate, as they + could lead to unlinkability violations. + + Origin-Client, Issuer-Client, and Attester-Origin unlinkability + requires that issuance and redemption events be separated over time, + such as through the use of tokens that correspond to token challenges + with an empty redemption context (see Section 3.4), or be separated + over space, such as through the use of an anonymizing service when + connecting to the Origin. + +4.2. Joint Attester and Issuer + + In this model, the Attester and Issuer are operated by the same + entity that is separate from the Origin. The Origin trusts the joint + Attester and Issuer to perform attestation and issue Tokens. Clients + interact with the joint Attester and Issuer for attestation and + issuance. This arrangement is shown in Figure 4. + + +------------------------------. + +--------+ | +----------+ +--------+ | +--------+ + | Client | | | Attester | | Issuer | | | Origin | + +---+----+ | +-----+----+ +----+---+ | +---+----+ + | `-------|---------------|-----' | + |<---------------------------------- TokenChallenge --+ + | | | | + |<==== Attestation ====>| | | + | | | | + +------------- TokenRequest ----------->| | + |<----------- TokenResponse ------------+ | + | | + +----------------------- Token -----------------------> + | | + + Figure 4: Joint Attester and Issuer Deployment Model + + This model is useful if an Origin wants to offload attestation and + issuance to a trusted entity. In this model, the Attester and Issuer + share an attestation and issuance context for the Client, which is + separate from the Origin's redemption context. + + Similar to the Shared Origin, Attester, Issuer model, Issuer-Client + and Origin-Client unlinkability in this model requires issuance and + redemption events, respectively, be separated over time or space. + Attester-Origin unlinkability requires that the Attester and Issuer + do not learn the Origin for a particular token request. For this + reason, issuance protocols that require the Issuer to learn + information about the Origin, such as that which is described in + [RATE-LIMITED], are not appropriate since they could lead to + Attester-Origin unlinkability violations through the Origin name. + +4.3. Joint Origin and Issuer + + 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 requests that come from trusted Attesters. Since the + Attester and Issuer are separate entities, this model requires some + mechanism by which Issuers establish trust in the Attester (as + described in Section 3.3). For example, in settings where the + Attester is a Client-trusted service that directly communicates with + the Issuer, one way to establish this trust is via mutually- + authenticated TLS. However, alternative authentication mechanisms + are possible. This arrangement is shown in Figure 5. + + +----------------------------. + +--------+ +----------+ | +--------+ +--------+ | + | Client | | Attester | | | Issuer | | Origin | | + +---+----+ +-----+----+ | +----+---+ +---+----+ | + | | `------|-------------|------' + |<-------------------------------- TokenChallenge --+ + | | | | + |<=== Attestation ===>| | | + | | | | + +------------ TokenRequest ---------->| | + |<---------- TokenResponse -----------+ | + | | + +--------------------- Token -----------------------> + | | + + Figure 5: Joint Origin and Issuer Deployment Model + + This model is useful for Origins that require Client-identifying + attestation, e.g., through the use of application-layer account + information, but do not otherwise want to learn information about + individual Clients beyond what is observed during the token + redemption, such as Client IP addresses. + + In this model, attestation contexts are separate from issuer and + redemption contexts. As a result, any type of attestation is + suitable in this model. + + Moreover, any type of token challenge is suitable assuming there is + more than one Origin involved, since no single party will have access + to the identifying Client information and unique Origin information. + Issuers that produce tokens for a single Origin are not suitable in + this model since an Attester can infer the Origin from a token + request, as described in Section 3.6.3. However, since the issuance + protocol provides input secrecy, the Attester does not learn details + about the corresponding token challenge, such as whether the token + challenge is per-Origin or cross-Origin. + +4.4. Split Origin, Attester, Issuer + + In this model, the Origin, Attester, and Issuer are all operated by + different entities. As with the joint Origin and Issuer model, the + Issuer accepts token requests that come from trusted Attesters, and + the details of that trust establishment depend on the issuance + protocol and relationship between Attester and Issuer; see + Section 3.3. This arrangement is shown in Figure 1. + + This is the most general deployment model, and is necessary for some + types of issuance protocols where the Attester plays a role in token + issuance; see [RATE-LIMITED] for one such type of issuance protocol. + + In this model, the Attester, Issuer, and Origin have a separate view + of the Client: the Attester sees potentially sensitive Client + identifying information, such as account identifiers or IP addresses, + the Issuer sees only the information necessary for issuance, and the + Origin sees token challenges, corresponding tokens, and Client source + information, such as their IP address. As a result, attestation, + issuance, and redemption contexts are separate, and therefore any + type of token challenge is suitable in this model as long as there is + more than a single Origin. + + As in the Joint Origin and Issuer model in Section 4.3, and as + described in Section 3.6.3, if the Issuer produces tokens for a + single Origin, then per-Origin tokens are not appropriate since the + Attester can infer the Origin from a token request. + +5. Deployment Considerations + + Section 4 discusses deployment models that are possible in practice. + Beyond possible implications on security and privacy properties of + the resulting system, Privacy Pass deployments can impact the overall + ecosystem in two important ways: (1) discriminatory treatment of + Clients and the gated access to otherwise open services, and (2) + centralization. This section describes considerations relevant to + these topics. + +5.1. Discriminatory Treatment + + Origins can use tokens as a signal for distinguishing between Clients + 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 consequence of this is that Privacy Pass could + enable discriminatory treatment of Clients based on Attestation + support. For example, an Origin could only authorize Clients that + successfully authenticate with a token, prohibiting access to all + other Clients. + + The type of attestation procedures supported for a particular + deployment depends greatly on the use case. For example, consider a + proprietary deployment of Privacy Pass that authorizes clients to + access a resource such as an anonymization service. In this context, + it is reasonable to support specific types of attestation procedures + that demonstrate Clients can access the resource, such as with an + account or specific type of device. However, in open deployments of + Privacy Pass that are used to safeguard access to otherwise open or + publicly accessible resources, diversity in attestation procedures is + critically important so as to not discriminate against Clients that + choose certain software, hardware, or identity providers. + + In principle, Issuers should strive to mitigate discriminatory + behavior by providing equitable access to all Clients. This can be + done by working with a set of Attesters that are suitable for all + Clients. In practice, this may require tradeoffs in what type of + attestation Issuers are willing to trust so as to enable more + widespread support. In other words, trusting a variety of Attesters + with a diverse set of attestation procedures would presumably + increase support among Clients, though most likely at the expense of + decreasing the overall value of tokens issued by the Issuer. + + For example, to disallow discriminatory behavior between Clients with + and without device attestation support, an Issuer may wish to support + Attesters that support CAPTCHA-based attestation. This means that + the overall attestation value of a Privacy Pass token is bound by the + difficulty in spoofing or bypassing either one of these attestation + procedures. + +5.2. Centralization + + A consequence of limiting the number of participants (Attesters or + Issuers) in Privacy Pass deployments for meaningful privacy is that + it forces concentrated centralization amongst those participants. + [CENTRALIZATION] discusses several ways in which this might be + mitigated. For example, a multi-stakeholder governance model could + be established to determine what candidate participants are fit to + operate as participants in a Privacy Pass deployment. This is + precisely the system used to control the Web's trust model. + + Alternatively, Privacy Pass deployments might mitigate this problem + through implementation. For example, rather than centralize the role + of attestation in one or few entities, attestation could be a + distributed function performed by a quorum of many parties, provided + that neither Issuers nor Origins learn which Attester implementations + were chosen. As a result, Clients could have more opportunities to + switch between attestation participants. + +6. Privacy Considerations + + The previous section discusses the impact of deployment details on + Origin-Client, Issuer-Client, and Attester-Origin unlinkability. The + value these properties affords to end users depends on the size of + anonymity sets in which Clients or Origins are unlinkable. For + example, consider two different deployments, one wherein there exists + a redemption anonymity set of size two and another wherein there + redemption anonymity set of size 2^32. Although Origin-Client + unlinkability guarantees that the Origin cannot link any two requests + to the same Client based on these contexts, respectively, the + probability of determining the "true" Client is higher the smaller + these sets become. + + In practice, there are a number of ways in which the size of + anonymity sets may be reduced or partitioned, though they all center + around the concept of consistency. In particular, by definition, all + Clients in an anonymity set share a consistent view of information + needed to run the issuance and redemption protocols. An example type + of information needed to run these protocols is the Issuer public + key. When two Clients have inconsistent information, these Clients + effectively have different redemption contexts and therefore belong + in different anonymity sets. + + 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. + +6.1. Partitioning by Issuance Metadata + + Any public or private metadata bits of information can be used to + further 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 the tracked Client it would set the bit to 1, + and 0 otherwise. Adding additional bits provides an exponential + increase in tracking granularity similarly to introducing more + Issuers (though with more potential targeting). + + 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. Since this metadata may be useful for practical + deployments of Privacy Pass, Issuers must balance this against the + reduction in Client privacy. + + The number of permitted metadata values often depends on deployment- + specific details. In general, limiting the amount of metadata + permitted helps limit the extent to which metadata can uniquely + identify individual Clients. Failure to bound the number of possible + metadata values can therefore lead to reduction in Client privacy. + Most token types do not admit any metadata, so this bound is + implicitly enforced. + +6.2. Partitioning by Issuance Consistency + + Anonymity sets can be partitioned by information used for the + issuance protocol, including: metadata, Issuer configuration (keys), + and Issuer selection. + + Any issuance metadata bits of information can be used to partition + the Client anonymity set. For example, any Issuer that wanted to + track a single Client could add a single metadata bit to Client + tokens. For the tracked Client it would set the bit to 1, and 0 + otherwise. Adding additional bits provides an exponential increase + in tracking granularity similarly to introducing more Issuers (though + with more potential targeting). + + The number of active Issuer configurations also contributes to + anonymity set partitioning. In particular, when an Issuer updates + their configuration and the corresponding key pair, any Client that + invokes the issuance protocol with this configuration becomes part of + a set of Clients which also ran the issuance protocol using the same + configuration. Issuer configuration updates, e.g., due to key + rotation, are an important part of hedging against long-term private + key compromise. In general, key rotations represent a trade-off + between Client privacy and Issuer security. Therefore, it is + important that key rotations occur on a regular cycle to reduce the + harm of an Issuer key compromise. + + Lastly, if Clients are willing to issue and redeem tokens from a + large number 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 many Issuers and an Origin + later challenges that Client for a token from each Issuer, the Origin + can learn information about the Client. This arrangement might + happen if Clients request tokens from different Issuers, each of + which have different Attester preferences. Each per-Issuer token + that a Client holds essentially corresponds to a bit of information + about the Client that Origin learns. Therefore, there is an + exponential loss in privacy relative to the number of Issuers. + + The fundamental problem here is that the number of possible issuance + configurations, including the keys in use and the Issuer identities + themselves, can partition the Client anonymity set. To mitigate this + problem, Clients SHOULD bound the number of active issuance + configurations per Origin as well as across Origins. Moreover, + Clients SHOULD employ some form of consistency mechanism to ensure + that they receive the same configuration information and are not + being actively partitioned into smaller anonymity sets. See + [CONSISTENCY] for possible consistency mechanisms. Depending on the + deployment, the Attester might assist the Client in applying these + consistency checks across clients. Failure to apply a consistency + check can allow Client-specific keys to violate Origin-Client + unlinkability. + +6.3. Partitioning by Side-Channels + + Side-channel attacks, such as those based on timing correlation, + could be used to reduce anonymity set size. In particular, for + interactive tokens that are bound to a Client-specific redemption + context, the anonymity set of Clients during the issuance protocol + consists of those Clients that started issuance between the time of + the Origin's challenge and the corresponding token redemption. + Depending on the number of Clients using a particular Issuer during + that time window, the set can be small. Applications should take + such side channels into consideration before choosing a particular + deployment model and type of token challenge and redemption context. + +7. Security Considerations + + This document describes security and privacy requirements for the + Privacy Pass redemption and issuance protocols. It also describes + deployment models built around non-collusion assumptions and privacy + considerations for using Privacy Pass within those models. Ensuring + Client privacy -- separation of attestation and redemption contexts + -- requires active work on behalf of the Client, especially in the + presence of malicious Issuers and Origins. Implementing mitigations + discussed in Section 4 and Section 6 is therefore necessary to ensure + that Privacy Pass offers meaningful privacy improvements to end- + users. + +7.1. Token Caching + + Depending on the Origin's token challenge, Clients can request and + cache more than one token using an issuance protocol. Cached tokens + help improve privacy by separating the time of token issuance from + the time of token redemption, and also allow Clients to reduce the + overhead of receiving new tokens via the issuance protocol. + + As a consequence, Origins that send token challenges which are + compatible with cached tokens need to take precautions to ensure that + tokens are not replayed. This is typically done via keeping track of + tokens that are redeemed for the period of time in which cached + tokens would be accepted for particular challenges. + + Moreover, since tokens are not intrinsically bound to Clients, it is + possible for malicious Clients to collude and share tokens in a so- + called "hoarding attack." 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 that would violate an + Origin's attempt to limit tokens to any one particular Client. In + general, mechanisms for mitigating hoarding attacks depend on the + deployment model and use case. For example, in the Joint Origin and + Issuer model, comparing the issuance and redemption contexts can help + detect hoarding attacks, i.e., if the distribution of redemption + contexts is noticeably different from the distribution of issuance + contexts. Rate limiting issuance, either at the Client, Attester, or + Issuer, can also help mitigate these attacks. + +8. IANA Considerations + + This document has no IANA actions. + +9. References + +9.1. Normative References + + [AUTHSCHEME] + Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass + HTTP Authentication Scheme", Work in Progress, Internet- + Draft, draft-ietf-privacypass-auth-scheme-14, 25 September + 2023, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +9.2. Informative References + + [CENTRALIZATION] + Nottingham, M., "Centralization, Decentralization, and + Internet Standards", Work in Progress, Internet-Draft, + draft-nottingham-avoiding-internet-centralization-14, 14 + September 2023, . + + [CONSISTENCY] + Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, + "Key Consistency and Discovery", Work in Progress, + Internet-Draft, draft-ietf-privacypass-key-consistency-01, + 10 July 2023, . + + [DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The + Second-Generation Onion Router", August 2004, + . + + [HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee, + C. K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S., + Sung, Y. C., and A. Zhang, "PrivateStats: De-Identified + Authenticated Logging at Scale", January 2021, + . + + [ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood, + "Privacy Pass Issuance Protocol", Work in Progress, + Internet-Draft, draft-ietf-privacypass-protocol-15, 25 + September 2023, . + + [KLOR20] Kreuter, B., Lepoint, T., Orrù, M., and M. Raykova, + "Anonymous Tokens with Private Metadata Bit", Springer + International Publishing, Advances in Cryptology – CRYPTO + 2020 pp. 308-336, DOI 10.1007/978-3-030-56784-2_11, + ISBN ["9783030567835", "9783030567842"], 2020, + . + + [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in + Progress, Internet-Draft, draft-ietf-ohai-ohttp-10, 25 + August 2023, . + + [PrivacyPassCloudflare] + Sullivan, N., "Cloudflare Supports Privacy Pass", n.d., + . + + [PrivacyPassExtension] + "Privacy Pass Browser Extension", n.d., + . + + [RATE-LIMITED] + Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and + C. A. Wood, "Rate-Limited Token Issuance Protocol", Work + in Progress, Internet-Draft, draft-privacypass-rate-limit- + tokens-03, 6 July 2022, + . + + [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and + W. Pan, "Remote ATtestation procedureS (RATS) + Architecture", RFC 9334, DOI 10.17487/RFC9334, January + 2023, . + +Appendix A. Acknowledgements + + The authors would like to thank Eric Kinnear, Scott Hendrickson, + Tommy Pauly, Christopher Patton, Benjamin Schwartz, Martin Thomson, + Steven Valdez and other contributors of the Privacy Pass Working + Group for many helpful contributions to this document. + +Authors' Addresses + + Alex Davidson + LIP + Lisbon + Portugal + Email: alex.davidson92@gmail.com + + + Jana Iyengar + Fastly + Email: jri@fastly.com + + + Christopher A. Wood + Cloudflare + 101 Townsend St + San Francisco, + United States of America + Email: caw@heapingbits.net diff --git a/chris-wood-patch-7/draft-ietf-privacypass-auth-scheme.html b/chris-wood-patch-7/draft-ietf-privacypass-auth-scheme.html new file mode 100644 index 00000000..5b0db475 --- /dev/null +++ b/chris-wood-patch-7/draft-ietf-privacypass-auth-scheme.html @@ -0,0 +1,2670 @@ + + + + + + +The Privacy Pass HTTP Authentication Scheme + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftPrivacy Pass AuthenticationOctober 2023
Pauly, et al.Expires 5 April 2024[Page]
+
+
+
+
Workgroup:
+
Network Working Group
+
Internet-Draft:
+
draft-ietf-privacypass-auth-scheme-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Authors:
+
+
+
T. Pauly
+
Apple Inc.
+
+
+
S. Valdez
+
Google LLC
+
+
+
C. A. Wood
+
Cloudflare
+
+
+
+
+

The Privacy Pass HTTP Authentication Scheme

+
+

Abstract

+

This document defines an HTTP authentication scheme for Privacy Pass, +a privacy-preserving authentication mechanism used for authorization. +The authentication scheme in this document can be used by clients +to redeem Privacy Pass tokens with an origin. It can also be used by +origins to challenge clients to present Privacy Pass tokens.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 5 April 2024.

+
+
+ + +
+
+

+1. Introduction +

+

Privacy Pass tokens are unlinkable authenticators that can be used to +anonymously authorize a client (see +[ARCHITECTURE]). +Tokens are generated by token issuers, on the basis of authentication, +attestation, or some previous action such as solving a CAPTCHA. A client +possessing such a token is able to prove that it was able to get a token +issued, without allowing the relying party redeeming the client's token +(the origin) to link it with the issuance flow.

+

Different types of authenticators, using different token issuance protocols, +can be used as Privacy Pass tokens.

+

This document defines a common HTTP authentication scheme +([RFC9110], Section 11), PrivateToken, that allows clients to redeem various +kinds of Privacy Pass tokens.

+

Clients and relying parties (origins) interact using this scheme to perform the +token challenge and token redemption flow. In particular, origins challenge +clients for a token with an HTTP Authentication challenge (using the +WWW-Authenticate response header field). Clients can then react to that +challenge by issuing a new request with a corresponding token (using the Authorization +request header field). Clients generate tokens that match the origin's token +challenge by running the token issuance protocol +[ISSUANCE]. The act of presenting a token in an +Authorization request header field is referred to as token redemption. This +interaction between client and origin is shown below.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + Origin + Client + WWW-Authenticate: + TokenChallenge + (Run + issuance + protocol) + Authorization: + Token + + +
+
+
Figure 1: +Challenge and redemption protocol flow +
+
+

In addition to working with different token issuance protocols, this scheme +optionally supports use of tokens that are associated with origin-chosen +contexts and specific origin names. Relying parties that request and redeem +tokens can choose a specific kind of token, as appropriate for its use case. +These options allow for different deployment models to prevent double-spending, +and allow for both interactive (online challenges) and non-interactive +(pre-fetched) tokens.

+
+
+

+1.1. Terminology +

+

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL +NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", +"MAY", and "OPTIONAL" in this document are to be interpreted as +described in BCP 14 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.

+

Unless otherwise specified, this document encodes protocol messages in TLS +notation from [TLS13], Section 3.

+

This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", +and "Token" as defined in [ARCHITECTURE]. It additionally +uses the following terms in more specific ways:

+
    +
  • +

    Issuer key: Keying material that can be used with an issuance protocol +to create a signed token.

    +
    • +
  • +

    Token challenge: A request for tokens sent from an origin to a client, using +the "WWW-Authenticate" HTTP header field. This challenge identifies a specific +token issuer and issuance protocol. Token challenges optionally include +one or both of: a redemption context (see Section 2.1.1.2), and +a list of associated origins. These optional values are then +be bound to the token that is issued.

    +
    • +
  • +

    Token redemption: An action by which a client presents a token to an origin +in an HTTP request, using the "Authorization" HTTP header field.

    +
    • +
+
+
+
+
+
+
+

+2. HTTP Authentication Scheme +

+

Token redemption is performed using HTTP Authentication +([RFC9110], Section 11), with the scheme "PrivateToken". Origins challenge +clients to present a token from a specific issuer (Section 2.1). Once a +client has received a token from that issuer, or already has a valid token +available, it presents the token to the origin (Section 2.2). The process of +presenting a token as authentication to an origin is also referred to +as "spending" a token.

+

In order to prevent linkability across different transactions, clients +will often present a particular "PrivateToken" only once. Origins can link multiple +transactions to the same client if that client spends the same token value more +than once. As such, origins ought to expect at most one unique token +value, carried in one request, for each challenge.

+

The rest of this section describes the token challenge and redemption interactions +in more detail.

+
+
+

+2.1. Token Challenge +

+

Origins send a token challenge to clients in an "WWW-Authenticate" header field +with the "PrivateToken" scheme. This authentication scheme has two mandatory parameters: +one containing a token challenge and another containing the token-key used for +producing (and verifying) a corresponding token.

+

Origins that support the "PrivateToken" authentication scheme need to handle +the following tasks in constructing the WWW-Authenticate header field:

+
    +
  1. +

    Select which issuer to use, and configure the issuer name and token-key to +include in WWW-Authenticate token challenges. The issuer name is included in +the token challenge, and the issuer token-key is used to populate the +WWW-Authenticate header parameter.

    +
    2. +
  2. +

    Determine a redemption context construction to include in the +token challenge, as discussed in Section 2.1.1.2.

    +
    3. +
  3. +

    Select the origin information to include in the token challenge. This can +be empty to allow fully cross-origin tokens, a single origin name that +matches the origin itself for per-origin tokens, or a list of origin names +containing the origin itself. See Section 3.4 of [ARCHITECTURE] for more +information about the difference between cross-origin and per-origin tokens.

    +
    4. +
+

Once these decisions are made, origins construct the WWW-Authenticate header +by first constructing the token challenge as described in Section 2.1.1. +Origins send challenges as described in Section 2.1.2, and clients process +them as described in Section 2.1.3 and Section 2.1.4.

+
+
+

+2.1.1. Token Challenge Structure +

+

This document defines the default challenge structure that can be used across +token types, although future token types MAY extend or modify the structure +of the challenge; see Section 6.2 for the registry information +which establishes and defines the relationship between "token_type" and the +contents of the TokenChallenge message.

+

All token challenges MUST begin with a 2-octet integer that defines the +token type, in network byte order. This type indicates the issuance protocol +used to generate the token and determines the structure and semantics of the rest of +the structure. Values are registered in an IANA registry, Section 6.2. Client MUST +ignore challenges with token types they do not support.

+

Even when a given token type uses the default challenge structure, +the requirements on the presence or interpretation of the fields can differ +across token types. For example, some token types might require that "origin_info" +is non-empty, while others allow it to be empty.

+

The default TokenChallenge message has the following structure:

+
+
+struct {
+    uint16_t token_type;
+    opaque issuer_name<1..2^16-1>;
+    opaque redemption_context<0..32>;
+    opaque origin_info<0..2^16-1>;
+} TokenChallenge;
+
+
+

The structure fields are defined as follows:

+
    +
  • +

    "token_type" is a 2-octet integer, in network byte order, as described +above.

    +
    • +
  • +

    "issuer_name" is an ASCII string that identifies the issuer using the format of a +server name defined in Section 2.1.1.1. This name identifies the issuer that is allowed to +issue tokens that can be redeemed by this origin. The field that stores this string in the challenge +is prefixed with a 2-octet integer indicating the length, in network byte order.

    +
    • +
  • +

    "redemption_context" is a field that is either 0 or 32 bytes, prefixed with a single +octet indicating the length (either 0 or 32). If value is non-empty, it is a 32-byte value +generated by the origin that allows the origin to require that clients fetch tokens +bound to a specific context, as opposed to reusing tokens that were fetched for other +contexts. See Section 2.1.1.2 for example contexts that might be useful in +practice. Challenges with redemption_context values of invalid lengths MUST be ignored.

    +
    • +
  • +

    "origin_info" is an ASCII string that is either empty, or contains one or more +origin names that allow a token to be scoped to a specific set of origins. Each +origin name uses the format of a server name defined in Section 2.1.1.1. The string +is prefixed with a 2-octet integer indicating the length, in network byte order. +If empty, any non-origin-specific token can be redeemed. If the string contains +multiple origin names, they are delimited with commas "," without any whitespace. +If this field is not empty, the Origin MUST include its own name as one of the +names in the list.

    +
    • +
+

If "origin_info" contains multiple origin names, this means the challenge is valid +for any of the origins in the list, including the origin which issued the challenge +(which must always be present in the list if it is non-empty; see Section 2.1.3). +This can be useful in settings where clients pre-fetch and cache tokens for a particular +challenge -- including the "origin_info" field -- and then later redeem these tokens +with one of the origins in the list. See Section 2.1.4 for more discussion about +token caching.

+
+
+
+2.1.1.1. Server Name Encoding +
+

Server names contained in a token challenge are ASCII strings that contain a hostname +and optional port, where the port is implied to be "443" if missing. The names use the +format of the authority portion of a URI as defined in Section 3.2 of [URI]. +The names MUST NOT include a "userinfo" portion of an authority. For example, a valid +server name might be "issuer.example.com" or "issuer.example.com:8443", +but not "issuer@example.com".

+
+
+
+
+
+2.1.1.2. Redemption Context Construction +
+

The TokenChallenge redemption context allows the origin to determine the +context in which a given token can be redeemed. This value can be a unique +per-request nonce, constructed from 32 freshly generated random bytes. It +can also represent state or properties of the client session. Some example +properties and methods for constructing the corresponding context are below. +This list is not exhaustive.

+
    +
  • +

    Context bound to a given time window: Construct redemption context as +F(current time window), where F is a pseudorandom function.

    +
    • +
  • +

    Context bound to a client network: Construct redemption context as +F(client ASN), where F is a pseudorandom function.

    +
    • +
  • +

    Context bound to a given time window and client network: Construct redemption +context as F(current time window, client ASN), where F is a pseudorandom function.

    +
    • +
+

Preventing double spending on tokens requires the origin to keep state +associated with the redemption context. An empty redemption context is not +bound to any property of the client request, so state to prevent double spending +needs to be stored and shared across all origin servers that can accept tokens until +token-key expiration or rotation. For a non-empty redemption context, the +double spend state only needs to be stored across the set of origin servers that will +accept tokens with that redemption context.

+

Origins that share redemption contexts, i.e., by using the same redemption +context, choosing the same issuer, and providing the same origin_info field in +the TokenChallenge, must necessarily share state required to enforce double +spend prevention. Origins should consider the operational complexity of this +shared state before choosing to share redemption contexts. Failure to +successfully synchronize this state and use it for double spend prevention can +allow Clients to redeem tokens to one Origin that were issued after an +interaction with another Origin that shares the context.

+
+
+
+
+
+
+

+2.1.2. Sending Token Challenges +

+

When used in an authentication challenge, the "PrivateToken" scheme uses the +following parameters:

+
    +
  • +

    "challenge", which contains a base64url-encoded [RFC4648] TokenChallenge +value. This document follows the default padding behavior described in +Section 3.2 of [RFC4648], so the base64url value MUST include padding. +As an Authentication Parameter (auth-param from [RFC9110], Section 11.2), +the value can be either a token or a quoted-string, and might be required to +be a quoted-string if the base64url string includes "=" characters. This +parameter is required for all challenges.

    +
    • +
  • +

    "token-key", which contains a base64url encoding of the public key for +use with the issuance protocol indicated by the challenge. See [ISSUANCE] +for more information about how this public key is used by the issuance protocols +in that specification. The encoding of +the public key is determined by the token type; see Section 6.2. +As with "challenge", the base64url value MUST include padding. As an +Authentication Parameter (auth-param from [RFC9110], Section 11.2), the +value can be either a token or a quoted-string, and might be required to be a +quoted-string if the base64url string includes "=" characters. This parameter +MAY be omitted in deployments where clients are able to retrieve the issuer key +using an out-of-band mechanism.

    +
    • +
  • +

    "max-age", an optional parameter that consists of the number of seconds for +which the challenge will be accepted by the origin.

    +
    • +
+

The header field MAY also include the standard "realm" parameter, if desired. +Issuance protocols MAY define other parameters, some of which might be required. +Clients MUST ignore parameters in challenges that are not defined for the issuance +protocol corresponding to the token type in the challenge.

+

As an example, the WWW-Authenticate header field could look like this:

+
+
+WWW-Authenticate:
+  PrivateToken challenge="abc...", token-key="123..."
+
+
+
+
+
+2.1.2.1. Sending Multiple Token Challenges +
+

It is possible for the WWW-Authenticate header field to include multiple +challenges ([RFC9110], Section 11.6.1). This allows the origin to indicate +support for different token types, issuers, or to include multiple redemption +contexts. For example, the WWW-Authenticate header field could look like this:

+
+
+WWW-Authenticate:
+  PrivateToken challenge="abc...", token-key="123...",
+  PrivateToken challenge="def...", token-key="234..."
+
+
+

Origins should only include challenges for different types of issuance +protocols with functionally equivalent properties. For instance, both issuance +protocols in [ISSUANCE] have the same functional properties, albeit with +different mechanisms for verifying the resulting tokens during redemption. +Since clients are free to choose which challenge they want to consume when +presented with options, mixing multiple challenges with different functional +properties for one use case is nonsensical. If the origin has a preference +for one challenge over another (for example, if one uses a token type +that is faster to verify), it can sort it to be first in the list +of challenges as a hint to the client.

+
+
+
+
+
+
+

+2.1.3. Processing Token Challenges +

+

Upon receipt of a challenge, a client validates the TokenChallenge structure +before taking any action, such as fetching a new token or redeeming a token +in a new request. Validation requirements are as follows:

+
    +
  • +

    The token_type is recognized and supported by the client;

    +
    • +
  • +

    The TokenChallenge structure is well-formed; and

    +
    • +
  • +

    If the origin_info field is non-empty, the name of the origin that issued the +authentication challenge is included in the list of origin names. Comparison +of the origin name that issued the authentication challenge against elements +in the origin_info list is done via case-insensitive equality checks.

    +
    • +
+

If validation fails, the client MUST NOT fetch or redeem a token based on the +challenge. Clients MAY have further restrictions and requirements around +validating when a challenge is considered acceptable or valid. For example, +clients can choose to ignore challenges that list origin names for which the +current connection is not authoritative (according to the TLS certificate).

+

Caching and pre-fetching of tokens is discussed in Section 2.1.4.

+
+
+
+
+

+2.1.4. Token Caching +

+

Clients can generate multiple tokens from a single TokenChallenge, and cache +them for future use. This improves privacy by separating the time of token +issuance from the time of token redemption, and also allows clients to avoid +any overhead of receiving new tokens via the issuance protocol.

+

Cached tokens can only be redeemed when they match all of the fields in the +TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. +Clients ought to store cached tokens based on all of these fields, to +avoid trying to redeem a token that does not match. Note that each token +has a unique client nonce, which is sent in token redemption (Section 2.2).

+

If a client fetches a batch of multiple tokens for future use that are bound +to a specific redemption context (the redemption_context in the TokenChallenge +was not empty), clients SHOULD discard these tokens upon flushing state such as +HTTP cookies [COOKIES], or if there is a network +change and the client does not have any origin-specific state like HTTP cookies. +Using these tokens in a context that otherwise would not be linkable to the +original context could allow the origin to recognize a client.

+
+
+
+
+
+
+

+2.2. Token Redemption +

+

The output of the issuance protocol is a token that corresponds to the origin's +challenge (see Section 2.1).

+
+
+

+2.2.1. Token Structure +

+

A token is a structure that begins with a two-octet field that indicates a token +type, which MUST match the token_type in the TokenChallenge structure. This value +determines the structure and semantics of the rest of token structure.

+

This document defines the default token structure that can be used across +token types, although future token types MAY extend or modify the structure +of the token; see Section 6.2 for the registry information which +establishes and defines the relationship between "token_type" and the contents +of the Token structure.

+

The default Token message has the following structure:

+
+
+struct {
+    uint16_t token_type;
+    uint8_t nonce[32];
+    uint8_t challenge_digest[32];
+    uint8_t token_key_id[Nid];
+    uint8_t authenticator[Nk];
+} Token;
+
+
+

The structure fields are defined as follows:

+
    +
  • +

    "token_type" is a 2-octet integer, in network byte order, as described +above.

    +
    • +
  • +

    "nonce" is a 32-octet value containing a client-generated random nonce.

    +
    • +
  • +

    "challenge_digest" is a 32-octet value containing the hash of the +original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as defined +in [SHS]. Changing the hash function to something +other than SHA-256 would require defining a new token type and token structure +(since the contents of challenge_digest would be computed differently), +which can be done in a future specification.

    +
    • +
  • +

    "token_key_id" is a Nid-octet identifier for the token authentication +key. The value of this field is defined by the token_type and corresponding +issuance protocol.

    +
    • +
  • +

    "authenticator" is a Nk-octet authenticator that is cryptographically bound +to the preceding fields in the token; see Section 2.2.3 for more information +about how this field is used in verifying a token. The token_type and corresponding +issuance protocol determine the value of the authenticator field and how it is computed. +The value of constant Nk depends on token_type, as defined in Section 6.2.

    +
    • +
+

The authenticator value in the Token structure is computed over the token_type, +nonce, challenge_digest, and token_key_id fields. A token is considered a valid +if token verification using succeeds; see Section 2.2.3 for details about +verifying the token and its authenticator value.

+
+
+
+
+

+2.2.2. Sending Tokens +

+

When used for client authorization, the "PrivateToken" authentication +scheme defines one parameter, "token", which contains the base64url-encoded +Token struct. As with the challenge parameters (Section 2.1), the base64url +value MUST include padding. As an Authentication Parameter (auth-param from +[RFC9110], Section 11.2), the value can be either a token or a +quoted-string, and might be required to be a quoted-string if the base64url +string includes "=" characters. All unknown or unsupported parameters to +"PrivateToken" authentication credentials MUST be ignored.

+

Clients present this Token structure to origins in a new HTTP request using +the Authorization header field as follows:

+
+
+Authorization: PrivateToken token="abc..."
+
+
+

For context-bound tokens, origins store or reconstruct the contexts of previous +TokenChallenge structures in order to validate the token. A TokenChallenge can +be bound to a specific TLS session with a client, but origins can also accept +tokens for valid challenges in new sessions. Origins SHOULD implement some form +of double-spend prevention that prevents a token with the same nonce from being +redeemed twice. Double-spend prevention ensures that clients cannot replay tokens +for previous challenges. See Section 5.2 for more information about replay +attacks. For context-bound tokens, this double-spend prevention can require no state +or minimal state, since the context can be used to verify token uniqueness.

+
+
+
+
+

+2.2.3. Token Verification +

+

A token consists of some input cryptographically bound to an authenticator +value, such as a digital signature. Verifying a token consists of checking that +the authenticator value is correct.

+

The authenticator value is as computed when running and finalizing the issuance +protocol corresponding to the token type with the following value as the input:

+
+
+struct {
+    uint16_t token_type;
+    uint8_t nonce[32];
+    uint8_t challenge_digest[32];
+    uint8_t token_key_id[Nid];
+} AuthenticatorInput;
+
+
+

The value of these fields are as described in Section 2.2. The cryptographic +verification check depends on the token type; see Section 5.4 of [ISSUANCE] +and Section 6.4 of [ISSUANCE] for verification instructions for the issuance +protocols described in [ISSUANCE]. As such, the security properties of the +token, e.g., the probability that one can forge an authenticator value without +invoking the issuance protocol, depend on the cryptographic algorithm used by +the issuance protocol as determined by the token type.

+
+
+
+
+
+
+
+
+

+3. Client Behavior +

+

When a client receives one or more token challenges in response to a request, +the client has a set of choices to make:

+
    +
  • +

    Whether or not to redeem a token via a new request to the origin.

    +
    • +
  • +

    Whether to redeem a previously issued and cached token, or redeem a token freshly issued from the issuance protocol.

    +
    • +
  • +

    If multiple challenges were sent, which challenge to use for redeeming a +token on a subsequent request.

    +
    • +
+

The approach to these choices depends on the use case of the application, as +well as the deployment model (see Section 4 of [ARCHITECTURE] for discussion +of the different deployment models).

+
+
+

+3.1. Choosing to Redeem Tokens +

+

Some applications of tokens might require clients to always present a token +as authentication in order to successfully make requests. For example, a restricted +service that wants to only allow access to valid users, but do so without learning +specific user credential information, could use tokens that are based on attesting user +credentials. In these kinds of use cases, clients will need to always redeem a +token in order to successfully make a request.

+

Many other use cases for Privacy Pass tokens involve open services that must work +with any client, including those that either cannot redeem tokens, or can only sometimes redeem +tokens. For example, a service can use tokens as a way to reduce the incidence of +presenting CAPTCHAs to users. In such use cases, services will regularly encounter +clients that cannot redeem a token or choose not to. In order to mitigate the risk +of these services relying on always receiving tokens, clients that are capable of +redeeming tokens can ignore token challenges (and instead behave as if they were a client +that either doesn't support redeeming tokens or is unable to generate a new token, by not +sending a new request that contains a token to redeem) with some +non-trivial probability. See Section 5.1 of [ARCHITECTURE] for further considerations +on avoiding discriminatory behavior across clients when using Privacy Pass tokens.

+

Clients might also choose to not redeem tokens in subsequent requests when the +token challenges indicate erroneous or malicious behavior on the part of the +challenging origin. For example, if a client’s ability to generate tokens via an +attester and issuer is limited to a certain rate, a malicious origin could send +an excessive number of token challenges with unique redemption contexts +in order to cause the client to exhaust its ability to generate new tokens, or +to overwhelm issuance servers. The limits here will vary based on the specific +deployment, but clients SHOULD have some implementation-specific policy +to minimize the number of tokens that can be retrieved by origins.

+
+
+
+
+

+3.2. Choosing Between Multiple Challenges +

+

A single response from an origin can include multiple token challenges. +For example, a set of challenges could include different token types +and issuers, to allow clients to choose a preferred issuer or type.

+

The choice of which challenge to use for redeeming tokens is up to +client policy. This can involve which token types are supported or preferred, +which issuers are supported or preferred, or whether or not the +client is able to use cached tokens based on the redemption context +or origin information in the challenge. See Section 2.1.4 for more discussion +on token caching. Regardless of how the choice is made, it SHOULD be done in a +consistent manner to ensure that the choice does not reveal information about the +specific client; see Section 6.2 of [ARCHITECTURE] for more details on the privacy +implications of issuance consistency.

+
+
+
+
+
+
+

+4. Origin Behavior +

+

Origins choose what token challenges to send to clients, which will vary +depending on the use case and deployment model. The origin chooses +which token types, issuers, redemption contexts, and origin info to include +in challenges. If an origin sends multiple challenges, each challenge SHOULD +be equivalent in terms of acceptability for token redemption, since clients +are free to choose to generate tokens based on any of the challenges.

+

Origins ought to consider the time involved in token issuance. Particularly, +a challenge that includes a unique redemption context will prevent a client +from using cached tokens, and thus can add more delay before the client +is able to redeem a token.

+

Origins SHOULD minimize the number of challenges sent to a particular client +context (referred to as the "redemption context" in +Section 3.3 of [ARCHITECTURE]), to avoid overwhelming clients and issuers +with token requests that might cause clients to hit rate limits.

+
+
+

+4.1. Greasing +

+

In order to prevent clients becoming incompatible with new token challenges, +origins SHOULD include random token types, from the Reserved list of "greased" +types (defined in Section 6.2), with some non-trivial probability.

+

Additionally, for deployments where tokens are not required (such as when tokens +are used as a way to avoiding showing CAPTCHAs), origins SHOULD randomly
+choose to not challenge clients for tokens with some non-trivial probability. +This helps origins ensure that their behavior for handling clients that cannot +redeem tokens is maintained and exercised consistently.

+
+
+
+
+
+
+

+5. Security Considerations +

+

This section contains security considerations for the PrivateToken authentication +scheme described in this document.

+
+
+

+5.1. Randomness Requirements +

+

All random values in the challenge and token MUST be +generated using a cryptographically secure source of randomness ([RFC4086]).

+
+
+
+
+

+5.2. Replay Attacks +

+

Applications SHOULD constrain tokens to a single origin unless the use case can +accommodate replay attacks. Replaying tokens is not necessarily a security +or privacy problem. As an example, it is reasonable for clients to replay tokens +in contexts where token redemption does not induce side effects and in which +client requests are already linkable. One possible setting where this applies +is where tokens are sent as part of 0-RTT data.

+

If successful token redemption produces side effects, origins SHOULD implement an +anti-replay mechanism to mitigate the harm of such replays. See [TLS13], Section 8 +and [RFC9001], Section 9.2 for details about anti-replay mechanisms, as well as +[RFC8470], Section 3 for discussion about safety considerations for 0-RTT +HTTP data.

+
+
+
+
+

+5.3. Reflection Attacks +

+

The security properties of token challenges vary depending on whether the +challenge contains a redemption context or not, as well as whether the +challenge is per-origin or not. For example, cross-origin tokens with empty +contexts can be reflected from one party by another, as shown below.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + Origin + Attacker + Client + TokenChallenge + (reflect + challenge) + -> + Token + (reflect + token) + - + + +
+
+
Figure 2: +Replay attack example +
+
+
+
+
+
+

+5.4. Token Exhaustion Attacks +

+

When a Client holds cross-origin tokens with empty contexts, it +is possible for any Origin in the cross-origin set to deplete that Client +set of tokens. To prevent this from happening, tokens can be scoped to single +Origins (with non-empty origin_info) such that they can only be redeemed for +a single Origin. Alternatively, if tokens are cross-Origin, Clients can use +alternate methods to prevent many tokens from being redeemed at once. For +example, if the Origin requests an excess of tokens, the Client could choose to +not present any tokens for verification if a redemption had already +occurred in a given time window.

+

Token challenges that include non-empty origin_info bind tokens to one or more +specific origins. As described in Section 2.1, clients only accept such +challenges from origin names listed in the origin_info string. Even if multiple +origins are listed, a token can only be redeemed for an origin if the challenge +has a match for the origin_info. For example, if "a.example.com" issues +a challenge with an origin_info string of "a.example.com,b.example.com", a +client could redeem a token fetched for this challenge if and only if +"b.example.com" also included an origin_info string of +"a.example.com,b.example.com". On the other hand, if "b.example.com" had an +origin_info string of "b.example.com" or "b.example.com,a.example.com" or +"a.example.com,b.example.com,c.example.com", the string would not match and the +client would need to use a different token.

+
+
+
+
+

+5.5. Timing Correlation Attacks +

+

Context-bound token challenges require clients to obtain matching tokens when +challenged, rather than presenting a token that was obtained from a different +context in the past. This can make it more likely that issuance and redemption +events will occur at approximately the same time. For example, if a client is +challenged for a token with a unique context at time T1 and then subsequently +obtains a token at time T2, a colluding issuer and origin can link this to the +same client if T2 is unique to the client. This linkability is less feasible as +the number of issuance events at time T2 increases. Depending on the "max-age" +token challenge parameter, clients MAY try to add delay to the time between +being challenged and redeeming a token to make this sort of linkability more +difficult. For more discussion on correlation risks between token issuance and +redemption, see Section 6.3 of [ARCHITECTURE].

+
+
+
+
+

+5.6. Cross-Context Linkability Attacks +

+

As discussed in Section 2.1, clients SHOULD discard any context-bound tokens +upon flushing cookies or changing networks, to prevent an origin using the +redemption context state as a cookie to recognize clients.

+
+
+
+
+
+
+

+6. IANA Considerations +

+
+
+

+6.1. Authentication Scheme +

+

This document registers the "PrivateToken" authentication scheme in the +"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined +in [RFC9110], Section 16.4.

+
+
Authentication Scheme Name:
+
+

PrivateToken

+
+
+
Pointer to specification text:
+
+

Section 2 of this document

+
+
+
+
+
+
+
+

+6.2. Token Type Registry +

+

IANA is requested to create a new "Privacy Pass Token Type" registry in a new +"Privacy Pass Parameters" page to list identifiers for issuance protocols +defined for use with the Privacy Pass token authentication scheme. These +identifiers are two-byte values, so the maximum possible value is +0xFFFF = 65535.

+

New registrations need to list the following attributes:

+
+
Value:
+
+

The two-byte identifier for the algorithm

+
+
+
Name:
+
+

Name of the issuance protocol

+
+
+
Token Structure:
+
+

The contents of the Token structure in Section 2.2

+
+
+
Token Key Encoding:
+
+

The encoding of the "token-key" parameter in Section 2.2

+
+
+
TokenChallenge Structure:
+
+

The contents of the TokenChallenge structure in Section 2.1

+
+
+
Public Verifiability:
+
+

A Y/N value indicating if the output tokens have the +public verifiability property; see Section 3.5 of [ARCHITECTURE] +for more details about this property.

+
+
+
Public Metadata:
+
+

A Y/N value indicating if the output tokens can contain +public metadata; see Section 3.5 of [ARCHITECTURE] +for more details about this property.

+
+
+
Private Metadata:
+
+

A Y/N value indicating if the output tokens can contain +private metadata; see Section 3.5 of [ARCHITECTURE] +for more details about this property.

+
+
+
Nk:
+
+

The length in bytes of an output authenticator

+
+
+
Nid:
+
+

The length of the token key identifier

+
+
+
Reference:
+
+

Where this algorithm is defined

+
+
+
Notes:
+
+

Any notes associated with the entry

+
+
+
+

New entries in this registry are subject to the Specification Required +registration policy ([RFC8126], Section 4.6). Designated experts need to +ensure that the token type is defined to be used for both token issuance and +redemption. Additionally, the experts can reject registrations on the basis +that they do not meet the security and privacy requirements for issuance +protocols defined in Section 3.2 of [ARCHITECTURE].

+

[ISSUANCE] defines entries for this registry.

+
+
+

+6.2.1. Reserved Values +

+

This document defines several Reserved values, which can be used by clients +and servers to send "greased" values in token challenges and redemptions to +ensure that implementations remain able to handle unknown token types +gracefully (this technique is inspired by [RFC8701]). Implementations SHOULD +select reserved values at random when including them in greased messages. +Servers can include these in TokenChallenge structures, either as the only +challenge when no real token type is desired, or as one challenge in a list of +challenges that include real values. Clients can include these in Token +structures when they are not able to present a real token. The +contents of the Token structure SHOULD be filled with random bytes when +using greased values.

+

The initial contents for this registry consists of multiple reserved values, +with the following attributes, which are repeated for each registration:

+
+
Value:
+
+

0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, 0x7F3F, +0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057

+
+
+
Name:
+
+

RESERVED

+
+
+
Token Structure:
+
+

Random bytes

+
+
+
Token Key Encoding:
+
+

Random bytes

+
+
+
TokenChallenge Structure:
+
+

Random bytes

+
+
+
Publicly Verifiable:
+
+

N/A

+
+
+
Public Metadata:
+
+

N/A

+
+
+
Private Metadata:
+
+

N/A

+
+
+
Nk:
+
+

N/A

+
+
+
Nid:
+
+

N/A

+
+
+
Reference:
+
+

This document

+
+
+
Notes:
+
+

None

+
+
+
+
+
+
+
+
+
+
+

+7. References +

+
+
+

+7.1. Normative References +

+
+
[ARCHITECTURE]
+
+Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", Work in Progress, Internet-Draft, draft-ietf-privacypass-architecture-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-16>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC4648]
+
+Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/rfc/rfc4648>.
+
+
[RFC8126]
+
+Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
[RFC9110]
+
+Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
+
+
[SHS]
+
+Dang, Q., "Secure Hash Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.180-4, , <https://doi.org/10.6028/nist.fips.180-4>.
+
+
[TLS13]
+
+Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
+
+
[URI]
+
+Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
+
+
+
+
+
+
+

+7.2. Informative References +

+
+
[COOKIES]
+
+Bingler, S., West, M., and J. Wilander, "Cookies: HTTP State Management Mechanism", Work in Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-12>.
+
+
[ISSUANCE]
+
+Celi, S., Davidson, A., Valdez, S., and C. A. Wood, "Privacy Pass Issuance Protocol", Work in Progress, Internet-Draft, draft-ietf-privacypass-protocol-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-protocol-15>.
+
+
[RFC4086]
+
+Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfc-editor.org/rfc/rfc4086>.
+
+
[RFC8470]
+
+Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, , <https://www.rfc-editor.org/rfc/rfc8470>.
+
+
[RFC8701]
+
+Benjamin, D., "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility", RFC 8701, DOI 10.17487/RFC8701, , <https://www.rfc-editor.org/rfc/rfc8701>.
+
+
[RFC9001]
+
+Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/rfc/rfc9001>.
+
+
+
+
+
+
+
+

+Appendix A. Test Vectors +

+

This section includes test vectors for the HTTP authentication scheme specified +in this document. It consists of the following types of test vectors:

+
    +
  1. +

    Test vectors for the challenge and redemption protocols. Implementations can +use these test vectors for verifying code that builds and encodes +TokenChallenge structures, as well as code that produces a well-formed Token +bound to a TokenChallenge.

    +
    2. +
  2. +

    Test vectors for the HTTP headers used for authentication. Implementations +can use these test vectors for validating whether they parse HTTP +authentication headers correctly to produce TokenChallenge structures and the +other associated parameters, such as the token-key and max-age values.

    +
    3. +
+
+
+

+A.1. Challenge and Redemption Structure Test Vectors +

+

This section includes test vectors for the challenge and redemption +functionalities described in Section 2.1 and Section 2.2. Each test vector +lists the following values:

+
    +
  • +

    token_type: The type of token issuance protocol, a value from +Section 6.2. For these test vectors, token_type is 0x0002, corresponding +to the issuance protocol in [ISSUANCE].

    +
    • +
  • +

    issuer_name: The name of the issuer in the TokenChallenge structure, +represented as a hexadecimal string.

    +
    • +
  • +

    redemption_context: The redemption context in the TokenChallenge structure, +represented as a hexadecimal string.

    +
    • +
  • +

    origin_info: The origin info in the TokenChallenge structure, represented as +a hexadecimal string.

    +
    • +
  • +

    nonce: The nonce in the Token structure, represented as a hexadecimal string.

    +
    • +
  • +

    token_key: The public token-key, encoded based on the corresponding token +type, represented as a hexadecimal string.

    +
    • +
  • +

    token_authenticator_input: The values in the Token structure used to compute +the Token authenticator value, represented as a hexadecimal string.

    +
    • +
+

Test vectors are provided for each of the following TokenChallenge +configurations:

+
    +
  1. +

    TokenChallenge with a single origin and non-empty redemption context

    +
    2. +
  2. +

    TokenChallenge with a single origin and empty redemption context

    +
    3. +
  3. +

    TokenChallenge with an empty origin and redemption context

    +
    4. +
  4. +

    TokenChallenge with an empty origin and non-empty redemption context

    +
    5. +
  5. +

    TokenChallenge with a multiple origins and non-empty redemption context

    +
    6. +
+

These test vectors are below.

+
+
+// Test vector 1:
+//   token_type(0002), issuer_name(issuer.example),
+//   origin_info(origin.example), redemption_context(non-empty)
+token_type: 0002
+issuer_name: 6973737565722e6578616d706c65
+redemption_context:
+476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
+origin_info: 6f726967696e2e6578616d706c65
+nonce:
+e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+token_key_id:
+ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+14f235e41ef7e2378e6f202688abab8e1d5518ec82964255526efd8f9db88205a
+8ddd3ffb1db298fcc3ad36c42388fca572f8982a9ca248a3056186322d93ca147
+266121ddeb5632c07f1f71cd2708
+
+// Test vector 2:
+//   token_type(0002), issuer_name(issuer.example),
+//   origin_info(origin.example), redemption_context(empty)
+token_type: 0002
+issuer_name: 6973737565722e6578616d706c65
+redemption_context:
+origin_info: 6f726967696e2e6578616d706c65
+nonce:
+e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+token_key_id:
+ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+14f235e41ef7e2378e6f202688abab11e15c91a7c2ad02abd66645802373db1d8
+23bea80f08d452541fb2b62b5898bca572f8982a9ca248a3056186322d93ca147
+266121ddeb5632c07f1f71cd2708
+
+// Test vector 3:
+//   token_type(0002), issuer_name(issuer.example),
+//   origin_info(), redemption_context(empty)
+token_type: 0002
+issuer_name: 6973737565722e6578616d706c65
+redemption_context:
+origin_info:
+nonce:
+e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+token_key_id:
+ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+14f235e41ef7e2378e6f202688ababb741ec1b6fd05f1e95f8982906aec161289
+6d9ca97d53eef94ad3c9fe023f7a4ca572f8982a9ca248a3056186322d93ca147
+266121ddeb5632c07f1f71cd2708
+
+// Test vector 4:
+//   token_type(0002), issuer_name(issuer.example),
+//   origin_info(), redemption_context(non-empty)
+token_type: 0002
+issuer_name: 6973737565722e6578616d706c65
+redemption_context:
+476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
+origin_info:
+nonce:
+e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+token_key_id:
+ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+14f235e41ef7e2378e6f202688ababb85fb5bc06edeb0e8e8bdb5b3bea8c4fa40
+837c82e8bcaf5882c81e14817ea18ca572f8982a9ca248a3056186322d93ca147
+266121ddeb5632c07f1f71cd2708
+
+// Test vector 5:
+//   token_type(0002), issuer_name(issuer.example),
+//   origin_info(foo.example,bar.example),
+//   redemption_context(non-empty)
+token_type: 0002
+issuer_name: 6973737565722e6578616d706c65
+redemption_context:
+476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
+origin_info: 666f6f2e6578616d706c652c6261722e6578616d706c65
+nonce:
+e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+token_key_id:
+ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+14f235e41ef7e2378e6f202688ababa2a775866b6ae0f98944910c8f48728d8a2
+735b9157762ddbf803f70e2e8ba3eca572f8982a9ca248a3056186322d93ca147
+266121ddeb5632c07f1f71cd2708
+
+
+
+
+
+
+

+A.2. HTTP Header Test Vectors +

+

This section includes test vectors the contents of the HTTP authentication +headers. Each test vector consists of one or more challenges that comprise +a WWW-Authenticate header. For each challenge, the token-type, token-key, +max-age, and token-challenge parameters are listed. Each challenge also +includes an unknown (not specified) parameter that implementations are meant +to ignore.

+

The parameters for each challenge are indexed by their position +in the WWW-Authentication challenge list. For example, token-key-0 denotes +the token-key parameter for the first challenge in the list, whereas +token-key-1 denotes the token-key for the second challenge in the list.

+

The resulting wire-encoded WWW-Authentication header based on this +list of challenges is then listed at the end. Line folding is only +used to fit the document formatting constraints and not unsupported +in actual requests.

+
+
+token-type-0: 0x0002
+token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
+8016503040202a11a301806092a864886f70d010108300b060960864801650304020
+2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
+5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
+ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
+67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
+f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
+bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2
+91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106
+066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7
+e225a5f0203010001
+max-age-0: 10
+token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9
+8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+e2e6578616d706c65
+
+WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII
+o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==",
+ token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG
+SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM
+_KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi
+JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS
+bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE
+7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh
+CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow
+nChallengeAttribute="ignore-me", max-age="10"
+
+token-type-0: 0x0002
+token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
+8016503040202a11a301806092a864886f70d010108300b060960864801650304020
+2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
+5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
+ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
+67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
+f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
+bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2
+91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106
+066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7
+e225a5f0203010001
+max-age-0: 10
+token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9
+8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+e2e6578616d706c65
+token-type-1: 0x0001
+token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a
+53fabd489fac0f82bca86249a668f3a5bfab374c9
+max-age-1: 10
+token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9
+8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+e2e6578616d706c65
+
+WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII
+o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==",
+ token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG
+SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM
+_KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi
+JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS
+bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE
+7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh
+CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow
+nChallengeAttribute="ignore-me", max-age="10", PrivateToken challeng
+e="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPp
+LODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBem
+aF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ig
+nore-me", max-age="10"
+
+
+
+
+
+
+
+
+

+Authors' Addresses +

+
+
Tommy Pauly
+
Apple Inc.
+
One Apple Park Way
+
+Cupertino, California 95014,
+
United States of America
+ +
+
+
Steven Valdez
+
Google LLC
+ +
+
+
Christopher A. Wood
+
Cloudflare
+ +
+
+
+ + + diff --git a/chris-wood-patch-7/draft-ietf-privacypass-auth-scheme.txt b/chris-wood-patch-7/draft-ietf-privacypass-auth-scheme.txt new file mode 100644 index 00000000..6a99d8b0 --- /dev/null +++ b/chris-wood-patch-7/draft-ietf-privacypass-auth-scheme.txt @@ -0,0 +1,1205 @@ + + + + +Network Working Group T. Pauly +Internet-Draft Apple Inc. +Intended status: Standards Track S. Valdez +Expires: 5 April 2024 Google LLC + C. A. Wood + Cloudflare + 3 October 2023 + + + The Privacy Pass HTTP Authentication Scheme + draft-ietf-privacypass-auth-scheme-latest + +Abstract + + This document defines an HTTP authentication scheme for Privacy Pass, + a privacy-preserving authentication mechanism used for authorization. + The authentication scheme in this document can be used by clients to + redeem Privacy Pass tokens with an origin. It can also be used by + origins to challenge clients to present Privacy Pass tokens. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 5 April 2024. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Terminology + 2. HTTP Authentication Scheme + 2.1. Token Challenge + 2.1.1. Token Challenge Structure + 2.1.2. Sending Token Challenges + 2.1.3. Processing Token Challenges + 2.1.4. Token Caching + 2.2. Token Redemption + 2.2.1. Token Structure + 2.2.2. Sending Tokens + 2.2.3. Token Verification + 3. Client Behavior + 3.1. Choosing to Redeem Tokens + 3.2. Choosing Between Multiple Challenges + 4. Origin Behavior + 4.1. Greasing + 5. Security Considerations + 5.1. Randomness Requirements + 5.2. Replay Attacks + 5.3. Reflection Attacks + 5.4. Token Exhaustion Attacks + 5.5. Timing Correlation Attacks + 5.6. Cross-Context Linkability Attacks + 6. IANA Considerations + 6.1. Authentication Scheme + 6.2. Token Type Registry + 6.2.1. Reserved Values + 7. References + 7.1. Normative References + 7.2. Informative References + Appendix A. Test Vectors + A.1. Challenge and Redemption Structure Test Vectors + A.2. HTTP Header Test Vectors + Authors' Addresses + +1. Introduction + + Privacy Pass tokens are unlinkable authenticators that can be used to + anonymously authorize a client (see [ARCHITECTURE]). Tokens are + generated by token issuers, on the basis of authentication, + attestation, or some previous action such as solving a CAPTCHA. A + client possessing such a token is able to prove that it was able to + get a token issued, without allowing the relying party redeeming the + client's token (the origin) to link it with the issuance flow. + + Different types of authenticators, using different token issuance + protocols, can be used as Privacy Pass tokens. + + This document defines a common HTTP authentication scheme ([RFC9110], + Section 11), PrivateToken, that allows clients to redeem various + kinds of Privacy Pass tokens. + + Clients and relying parties (origins) interact using this scheme to + perform the token challenge and token redemption flow. In + particular, origins challenge clients for a token with an HTTP + Authentication challenge (using the WWW-Authenticate response header + field). Clients can then react to that challenge by issuing a new + request with a corresponding token (using the Authorization request + header field). Clients generate tokens that match the origin's token + challenge by running the token issuance protocol [ISSUANCE]. The act + of presenting a token in an Authorization request header field is + referred to as token redemption. This interaction between client and + origin is shown below. + + +--------+ +--------+ + | Origin | | Client | + +---+----+ +---+----+ + | | + +-- WWW-Authenticate: TokenChallenge -->| + | | + | (Run issuance protocol) + | | + |<------ Authorization: Token ----------+ + | | + + Figure 1: Challenge and redemption protocol flow + + In addition to working with different token issuance protocols, this + scheme optionally supports use of tokens that are associated with + origin-chosen contexts and specific origin names. Relying parties + that request and redeem tokens can choose a specific kind of token, + as appropriate for its use case. These options allow for different + deployment models to prevent double-spending, and allow for both + interactive (online challenges) and non-interactive (pre-fetched) + tokens. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + Unless otherwise specified, this document encodes protocol messages + in TLS notation from [TLS13], Section 3. + + This document uses the terms "Client", "Origin", "Issuer", "Issuance + Protocol", and "Token" as defined in [ARCHITECTURE]. It additionally + uses the following terms in more specific ways: + + * Issuer key: Keying material that can be used with an issuance + protocol to create a signed token. + + * Token challenge: A request for tokens sent from an origin to a + client, using the "WWW-Authenticate" HTTP header field. This + challenge identifies a specific token issuer and issuance + protocol. Token challenges optionally include one or both of: a + redemption context (see Section 2.1.1.2), and a list of associated + origins. These optional values are then be bound to the token + that is issued. + + * Token redemption: An action by which a client presents a token to + an origin in an HTTP request, using the "Authorization" HTTP + header field. + +2. HTTP Authentication Scheme + + Token redemption is performed using HTTP Authentication ([RFC9110], + Section 11), with the scheme "PrivateToken". Origins challenge + clients to present a token from a specific issuer (Section 2.1). + Once a client has received a token from that issuer, or already has a + valid token available, it presents the token to the origin + (Section 2.2). The process of presenting a token as authentication + to an origin is also referred to as "spending" a token. + + In order to prevent linkability across different transactions, + clients will often present a particular "PrivateToken" only once. + Origins can link multiple transactions to the same client if that + client spends the same token value more than once. As such, origins + ought to expect at most one unique token value, carried in one + request, for each challenge. + + The rest of this section describes the token challenge and redemption + interactions in more detail. + +2.1. Token Challenge + + Origins send a token challenge to clients in an "WWW-Authenticate" + header field with the "PrivateToken" scheme. This authentication + scheme has two mandatory parameters: one containing a token challenge + and another containing the token-key used for producing (and + verifying) a corresponding token. + + Origins that support the "PrivateToken" authentication scheme need to + handle the following tasks in constructing the WWW-Authenticate + header field: + + 1. Select which issuer to use, and configure the issuer name and + token-key to include in WWW-Authenticate token challenges. The + issuer name is included in the token challenge, and the issuer + token-key is used to populate the WWW-Authenticate header + parameter. + + 2. Determine a redemption context construction to include in the + token challenge, as discussed in Section 2.1.1.2. + + 3. Select the origin information to include in the token challenge. + This can be empty to allow fully cross-origin tokens, a single + origin name that matches the origin itself for per-origin tokens, + or a list of origin names containing the origin itself. See + Section 3.4 of [ARCHITECTURE] for more information about the + difference between cross-origin and per-origin tokens. + + Once these decisions are made, origins construct the WWW-Authenticate + header by first constructing the token challenge as described in + Section 2.1.1. Origins send challenges as described in + Section 2.1.2, and clients process them as described in Section 2.1.3 + and Section 2.1.4. + +2.1.1. Token Challenge Structure + + This document defines the default challenge structure that can be + used across token types, although future token types MAY extend or + modify the structure of the challenge; see Section 6.2 for the + registry information which establishes and defines the relationship + between "token_type" and the contents of the TokenChallenge message. + + All token challenges MUST begin with a 2-octet integer that defines + the token type, in network byte order. This type indicates the + issuance protocol used to generate the token and determines the + structure and semantics of the rest of the structure. Values are + registered in an IANA registry, Section 6.2. Client MUST ignore + challenges with token types they do not support. + + Even when a given token type uses the default challenge structure, + the requirements on the presence or interpretation of the fields can + differ across token types. For example, some token types might + require that "origin_info" is non-empty, while others allow it to be + empty. + + The default TokenChallenge message has the following structure: + + struct { + uint16_t token_type; + opaque issuer_name<1..2^16-1>; + opaque redemption_context<0..32>; + opaque origin_info<0..2^16-1>; + } TokenChallenge; + + The structure fields are defined as follows: + + * "token_type" is a 2-octet integer, in network byte order, as + described above. + + * "issuer_name" is an ASCII string that identifies the issuer using + the format of a server name defined in Section 2.1.1.1. This name + identifies the issuer that is allowed to issue tokens that can be + redeemed by this origin. The field that stores this string in the + challenge is prefixed with a 2-octet integer indicating the + length, in network byte order. + + * "redemption_context" is a field that is either 0 or 32 bytes, + prefixed with a single octet indicating the length (either 0 or + 32). If value is non-empty, it is a 32-byte value generated by + the origin that allows the origin to require that clients fetch + tokens bound to a specific context, as opposed to reusing tokens + that were fetched for other contexts. See Section 2.1.1.2 for + example contexts that might be useful in practice. Challenges + with redemption_context values of invalid lengths MUST be ignored. + + * "origin_info" is an ASCII string that is either empty, or contains + one or more origin names that allow a token to be scoped to a + specific set of origins. Each origin name uses the format of a + server name defined in Section 2.1.1.1. The string is prefixed + with a 2-octet integer indicating the length, in network byte + order. If empty, any non-origin-specific token can be redeemed. + If the string contains multiple origin names, they are delimited + with commas "," without any whitespace. If this field is not + empty, the Origin MUST include its own name as one of the names in + the list. + + If "origin_info" contains multiple origin names, this means the + challenge is valid for any of the origins in the list, including the + origin which issued the challenge (which must always be present in + the list if it is non-empty; see Section 2.1.3). This can be useful + in settings where clients pre-fetch and cache tokens for a particular + challenge -- including the "origin_info" field -- and then later + redeem these tokens with one of the origins in the list. See + Section 2.1.4 for more discussion about token caching. + +2.1.1.1. Server Name Encoding + + Server names contained in a token challenge are ASCII strings that + contain a hostname and optional port, where the port is implied to be + "443" if missing. The names use the format of the authority portion + of a URI as defined in Section 3.2 of [URI]. The names MUST NOT + include a "userinfo" portion of an authority. For example, a valid + server name might be "issuer.example.com" or + "issuer.example.com:8443", but not "issuer@example.com". + +2.1.1.2. Redemption Context Construction + + The TokenChallenge redemption context allows the origin to determine + the context in which a given token can be redeemed. This value can + be a unique per-request nonce, constructed from 32 freshly generated + random bytes. It can also represent state or properties of the + client session. Some example properties and methods for constructing + the corresponding context are below. This list is not exhaustive. + + * Context bound to a given time window: Construct redemption context + as F(current time window), where F is a pseudorandom function. + + * Context bound to a client network: Construct redemption context as + F(client ASN), where F is a pseudorandom function. + + * Context bound to a given time window and client network: Construct + redemption context as F(current time window, client ASN), where F + is a pseudorandom function. + + Preventing double spending on tokens requires the origin to keep + state associated with the redemption context. An empty redemption + context is not bound to any property of the client request, so state + to prevent double spending needs to be stored and shared across all + origin servers that can accept tokens until token-key expiration or + rotation. For a non-empty redemption context, the double spend state + only needs to be stored across the set of origin servers that will + accept tokens with that redemption context. + + Origins that share redemption contexts, i.e., by using the same + redemption context, choosing the same issuer, and providing the same + origin_info field in the TokenChallenge, must necessarily share state + required to enforce double spend prevention. Origins should consider + the operational complexity of this shared state before choosing to + share redemption contexts. Failure to successfully synchronize this + state and use it for double spend prevention can allow Clients to + redeem tokens to one Origin that were issued after an interaction + with another Origin that shares the context. + +2.1.2. Sending Token Challenges + + When used in an authentication challenge, the "PrivateToken" scheme + uses the following parameters: + + * "challenge", which contains a base64url-encoded [RFC4648] + TokenChallenge value. This document follows the default padding + behavior described in Section 3.2 of [RFC4648], so the base64url + value MUST include padding. As an Authentication Parameter (auth- + param from [RFC9110], Section 11.2), the value can be either a + token or a quoted-string, and might be required to be a quoted- + string if the base64url string includes "=" characters. This + parameter is required for all challenges. + + * "token-key", which contains a base64url encoding of the public key + for use with the issuance protocol indicated by the challenge. + See [ISSUANCE] for more information about how this public key is + used by the issuance protocols in that specification. The + encoding of the public key is determined by the token type; see + Section 6.2. As with "challenge", the base64url value MUST + include padding. As an Authentication Parameter (auth-param from + [RFC9110], Section 11.2), the value can be either a token or a + quoted-string, and might be required to be a quoted-string if the + base64url string includes "=" characters. This parameter MAY be + omitted in deployments where clients are able to retrieve the + issuer key using an out-of-band mechanism. + + * "max-age", an optional parameter that consists of the number of + seconds for which the challenge will be accepted by the origin. + + The header field MAY also include the standard "realm" parameter, if + desired. Issuance protocols MAY define other parameters, some of + which might be required. Clients MUST ignore parameters in + challenges that are not defined for the issuance protocol + corresponding to the token type in the challenge. + + As an example, the WWW-Authenticate header field could look like + this: + + WWW-Authenticate: + PrivateToken challenge="abc...", token-key="123..." + +2.1.2.1. Sending Multiple Token Challenges + + It is possible for the WWW-Authenticate header field to include + multiple challenges ([RFC9110], Section 11.6.1). This allows the + origin to indicate support for different token types, issuers, or to + include multiple redemption contexts. For example, the WWW- + Authenticate header field could look like this: + + WWW-Authenticate: + PrivateToken challenge="abc...", token-key="123...", + PrivateToken challenge="def...", token-key="234..." + + Origins should only include challenges for different types of + issuance protocols with functionally equivalent properties. For + instance, both issuance protocols in [ISSUANCE] have the same + functional properties, albeit with different mechanisms for verifying + the resulting tokens during redemption. Since clients are free to + choose which challenge they want to consume when presented with + options, mixing multiple challenges with different functional + properties for one use case is nonsensical. If the origin has a + preference for one challenge over another (for example, if one uses a + token type that is faster to verify), it can sort it to be first in + the list of challenges as a hint to the client. + +2.1.3. Processing Token Challenges + + Upon receipt of a challenge, a client validates the TokenChallenge + structure before taking any action, such as fetching a new token or + redeeming a token in a new request. Validation requirements are as + follows: + + * The token_type is recognized and supported by the client; + + * The TokenChallenge structure is well-formed; and + + * If the origin_info field is non-empty, the name of the origin that + issued the authentication challenge is included in the list of + origin names. Comparison of the origin name that issued the + authentication challenge against elements in the origin_info list + is done via case-insensitive equality checks. + + If validation fails, the client MUST NOT fetch or redeem a token + based on the challenge. Clients MAY have further restrictions and + requirements around validating when a challenge is considered + acceptable or valid. For example, clients can choose to ignore + challenges that list origin names for which the current connection is + not authoritative (according to the TLS certificate). + + Caching and pre-fetching of tokens is discussed in Section 2.1.4. + +2.1.4. Token Caching + + Clients can generate multiple tokens from a single TokenChallenge, + and cache them for future use. This improves privacy by separating + the time of token issuance from the time of token redemption, and + also allows clients to avoid any overhead of receiving new tokens via + the issuance protocol. + + Cached tokens can only be redeemed when they match all of the fields + in the TokenChallenge: token_type, issuer_name, redemption_context, + and origin_info. Clients ought to store cached tokens based on all + of these fields, to avoid trying to redeem a token that does not + match. Note that each token has a unique client nonce, which is sent + in token redemption (Section 2.2). + + If a client fetches a batch of multiple tokens for future use that + are bound to a specific redemption context (the redemption_context in + the TokenChallenge was not empty), clients SHOULD discard these + tokens upon flushing state such as HTTP cookies [COOKIES], or if + there is a network change and the client does not have any origin- + specific state like HTTP cookies. Using these tokens in a context + that otherwise would not be linkable to the original context could + allow the origin to recognize a client. + +2.2. Token Redemption + + The output of the issuance protocol is a token that corresponds to + the origin's challenge (see Section 2.1). + +2.2.1. Token Structure + + A token is a structure that begins with a two-octet field that + indicates a token type, which MUST match the token_type in the + TokenChallenge structure. This value determines the structure and + semantics of the rest of token structure. + + This document defines the default token structure that can be used + across token types, although future token types MAY extend or modify + the structure of the token; see Section 6.2 for the registry + information which establishes and defines the relationship between + "token_type" and the contents of the Token structure. + + The default Token message has the following structure: + + struct { + uint16_t token_type; + uint8_t nonce[32]; + uint8_t challenge_digest[32]; + uint8_t token_key_id[Nid]; + uint8_t authenticator[Nk]; + } Token; + + The structure fields are defined as follows: + + * "token_type" is a 2-octet integer, in network byte order, as + described above. + + * "nonce" is a 32-octet value containing a client-generated random + nonce. + + * "challenge_digest" is a 32-octet value containing the hash of the + original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is + as defined in [SHS]. Changing the hash function to something + other than SHA-256 would require defining a new token type and + token structure (since the contents of challenge_digest would be + computed differently), which can be done in a future + specification. + + * "token_key_id" is a Nid-octet identifier for the token + authentication key. The value of this field is defined by the + token_type and corresponding issuance protocol. + + * "authenticator" is a Nk-octet authenticator that is + cryptographically bound to the preceding fields in the token; see + Section 2.2.3 for more information about how this field is used in + verifying a token. The token_type and corresponding issuance + protocol determine the value of the authenticator field and how it + is computed. The value of constant Nk depends on token_type, as + defined in Section 6.2. + + The authenticator value in the Token structure is computed over the + token_type, nonce, challenge_digest, and token_key_id fields. A + token is considered a valid if token verification using succeeds; see + Section 2.2.3 for details about verifying the token and its + authenticator value. + +2.2.2. Sending Tokens + + When used for client authorization, the "PrivateToken" authentication + scheme defines one parameter, "token", which contains the base64url- + encoded Token struct. As with the challenge parameters + (Section 2.1), the base64url value MUST include padding. As an + Authentication Parameter (auth-param from [RFC9110], Section 11.2), + the value can be either a token or a quoted-string, and might be + required to be a quoted-string if the base64url string includes "=" + characters. All unknown or unsupported parameters to "PrivateToken" + authentication credentials MUST be ignored. + + Clients present this Token structure to origins in a new HTTP request + using the Authorization header field as follows: + + Authorization: PrivateToken token="abc..." + + For context-bound tokens, origins store or reconstruct the contexts + of previous TokenChallenge structures in order to validate the token. + A TokenChallenge can be bound to a specific TLS session with a + client, but origins can also accept tokens for valid challenges in + new sessions. Origins SHOULD implement some form of double-spend + prevention that prevents a token with the same nonce from being + redeemed twice. Double-spend prevention ensures that clients cannot + replay tokens for previous challenges. See Section 5.2 for more + information about replay attacks. For context-bound tokens, this + double-spend prevention can require no state or minimal state, since + the context can be used to verify token uniqueness. + +2.2.3. Token Verification + + A token consists of some input cryptographically bound to an + authenticator value, such as a digital signature. Verifying a token + consists of checking that the authenticator value is correct. + + The authenticator value is as computed when running and finalizing + the issuance protocol corresponding to the token type with the + following value as the input: + + struct { + uint16_t token_type; + uint8_t nonce[32]; + uint8_t challenge_digest[32]; + uint8_t token_key_id[Nid]; + } AuthenticatorInput; + + The value of these fields are as described in Section 2.2. The + cryptographic verification check depends on the token type; see + Section 5.4 of [ISSUANCE] and Section 6.4 of [ISSUANCE] for + verification instructions for the issuance protocols described in + [ISSUANCE]. As such, the security properties of the token, e.g., the + probability that one can forge an authenticator value without + invoking the issuance protocol, depend on the cryptographic algorithm + used by the issuance protocol as determined by the token type. + +3. Client Behavior + + When a client receives one or more token challenges in response to a + request, the client has a set of choices to make: + + * Whether or not to redeem a token via a new request to the origin. + + * Whether to redeem a previously issued and cached token, or redeem + a token freshly issued from the issuance protocol. + + * If multiple challenges were sent, which challenge to use for + redeeming a token on a subsequent request. + + The approach to these choices depends on the use case of the + application, as well as the deployment model (see Section 4 of + [ARCHITECTURE] for discussion of the different deployment models). + +3.1. Choosing to Redeem Tokens + + Some applications of tokens might require clients to always present a + token as authentication in order to successfully make requests. For + example, a restricted service that wants to only allow access to + valid users, but do so without learning specific user credential + information, could use tokens that are based on attesting user + credentials. In these kinds of use cases, clients will need to + always redeem a token in order to successfully make a request. + + Many other use cases for Privacy Pass tokens involve open services + that must work with any client, including those that either cannot + redeem tokens, or can only sometimes redeem tokens. For example, a + service can use tokens as a way to reduce the incidence of presenting + CAPTCHAs to users. In such use cases, services will regularly + encounter clients that cannot redeem a token or choose not to. In + order to mitigate the risk of these services relying on always + receiving tokens, clients that are capable of redeeming tokens can + ignore token challenges (and instead behave as if they were a client + that either doesn't support redeeming tokens or is unable to generate + a new token, by not sending a new request that contains a token to + redeem) with some non-trivial probability. See Section 5.1 of + [ARCHITECTURE] for further considerations on avoiding discriminatory + behavior across clients when using Privacy Pass tokens. + + Clients might also choose to not redeem tokens in subsequent requests + when the token challenges indicate erroneous or malicious behavior on + the part of the challenging origin. For example, if a client’s + ability to generate tokens via an attester and issuer is limited to a + certain rate, a malicious origin could send an excessive number of + token challenges with unique redemption contexts in order to cause + the client to exhaust its ability to generate new tokens, or to + overwhelm issuance servers. The limits here will vary based on the + specific deployment, but clients SHOULD have some implementation- + specific policy to minimize the number of tokens that can be + retrieved by origins. + +3.2. Choosing Between Multiple Challenges + + A single response from an origin can include multiple token + challenges. For example, a set of challenges could include different + token types and issuers, to allow clients to choose a preferred + issuer or type. + + The choice of which challenge to use for redeeming tokens is up to + client policy. This can involve which token types are supported or + preferred, which issuers are supported or preferred, or whether or + not the client is able to use cached tokens based on the redemption + context or origin information in the challenge. See Section 2.1.4 + for more discussion on token caching. Regardless of how the choice + is made, it SHOULD be done in a consistent manner to ensure that the + choice does not reveal information about the specific client; see + Section 6.2 of [ARCHITECTURE] for more details on the privacy + implications of issuance consistency. + +4. Origin Behavior + + Origins choose what token challenges to send to clients, which will + vary depending on the use case and deployment model. The origin + chooses which token types, issuers, redemption contexts, and origin + info to include in challenges. If an origin sends multiple + challenges, each challenge SHOULD be equivalent in terms of + acceptability for token redemption, since clients are free to choose + to generate tokens based on any of the challenges. + + Origins ought to consider the time involved in token issuance. + Particularly, a challenge that includes a unique redemption context + will prevent a client from using cached tokens, and thus can add more + delay before the client is able to redeem a token. + + Origins SHOULD minimize the number of challenges sent to a particular + client context (referred to as the "redemption context" in + Section 3.3 of [ARCHITECTURE]), to avoid overwhelming clients and + issuers with token requests that might cause clients to hit rate + limits. + +4.1. Greasing + + In order to prevent clients becoming incompatible with new token + challenges, origins SHOULD include random token types, from the + Reserved list of "greased" types (defined in Section 6.2), with some + non-trivial probability. + + Additionally, for deployments where tokens are not required (such as + when tokens are used as a way to avoiding showing CAPTCHAs), origins + SHOULD randomly + choose to not challenge clients for tokens with some non-trivial + probability. This helps origins ensure that their behavior for + handling clients that cannot redeem tokens is maintained and + exercised consistently. + +5. Security Considerations + + This section contains security considerations for the PrivateToken + authentication scheme described in this document. + +5.1. Randomness Requirements + + All random values in the challenge and token MUST be generated using + a cryptographically secure source of randomness ([RFC4086]). + +5.2. Replay Attacks + + Applications SHOULD constrain tokens to a single origin unless the + use case can accommodate replay attacks. Replaying tokens is not + necessarily a security or privacy problem. As an example, it is + reasonable for clients to replay tokens in contexts where token + redemption does not induce side effects and in which client requests + are already linkable. One possible setting where this applies is + where tokens are sent as part of 0-RTT data. + + If successful token redemption produces side effects, origins SHOULD + implement an anti-replay mechanism to mitigate the harm of such + replays. See [TLS13], Section 8 and [RFC9001], Section 9.2 for + details about anti-replay mechanisms, as well as [RFC8470], Section 3 + for discussion about safety considerations for 0-RTT HTTP data. + +5.3. Reflection Attacks + + The security properties of token challenges vary depending on whether + the challenge contains a redemption context or not, as well as + whether the challenge is per-origin or not. For example, cross- + origin tokens with empty contexts can be reflected from one party by + another, as shown below. + + +--------+ +----------+ +--------+ + | Origin | | Attacker | | Client | + +---+----+ +----+-----+ +---+----+ + | | | + +-- TokenChallenge -->| | + | +-- (reflect challenge) ->| + | |<-------- Token ---------+ + |<-- (reflect token) -+ | + | | + + Figure 2: Replay attack example + +5.4. Token Exhaustion Attacks + + When a Client holds cross-origin tokens with empty contexts, it is + possible for any Origin in the cross-origin set to deplete that + Client set of tokens. To prevent this from happening, tokens can be + scoped to single Origins (with non-empty origin_info) such that they + can only be redeemed for a single Origin. Alternatively, if tokens + are cross-Origin, Clients can use alternate methods to prevent many + tokens from being redeemed at once. For example, if the Origin + requests an excess of tokens, the Client could choose to not present + any tokens for verification if a redemption had already occurred in a + given time window. + + Token challenges that include non-empty origin_info bind tokens to + one or more specific origins. As described in Section 2.1, clients + only accept such challenges from origin names listed in the + origin_info string. Even if multiple origins are listed, a token can + only be redeemed for an origin if the challenge has a match for the + origin_info. For example, if "a.example.com" issues a challenge with + an origin_info string of "a.example.com,b.example.com", a client + could redeem a token fetched for this challenge if and only if + "b.example.com" also included an origin_info string of + "a.example.com,b.example.com". On the other hand, if "b.example.com" + had an origin_info string of "b.example.com" or + "b.example.com,a.example.com" or + "a.example.com,b.example.com,c.example.com", the string would not + match and the client would need to use a different token. + +5.5. Timing Correlation Attacks + + Context-bound token challenges require clients to obtain matching + tokens when challenged, rather than presenting a token that was + obtained from a different context in the past. This can make it more + likely that issuance and redemption events will occur at + approximately the same time. For example, if a client is challenged + for a token with a unique context at time T1 and then subsequently + obtains a token at time T2, a colluding issuer and origin can link + this to the same client if T2 is unique to the client. This + linkability is less feasible as the number of issuance events at time + T2 increases. Depending on the "max-age" token challenge parameter, + clients MAY try to add delay to the time between being challenged and + redeeming a token to make this sort of linkability more difficult. + For more discussion on correlation risks between token issuance and + redemption, see Section 6.3 of [ARCHITECTURE]. + +5.6. Cross-Context Linkability Attacks + + As discussed in Section 2.1, clients SHOULD discard any context-bound + tokens upon flushing cookies or changing networks, to prevent an + origin using the redemption context state as a cookie to recognize + clients. + +6. IANA Considerations + +6.1. Authentication Scheme + + This document registers the "PrivateToken" authentication scheme in + the "Hypertext Transfer Protocol (HTTP) Authentication Scheme + Registry" defined in [RFC9110], Section 16.4. + + Authentication Scheme Name: PrivateToken + + Pointer to specification text: Section 2 of this document + +6.2. Token Type Registry + + IANA is requested to create a new "Privacy Pass Token Type" registry + in a new "Privacy Pass Parameters" page to list identifiers for + issuance protocols defined for use with the Privacy Pass token + authentication scheme. These identifiers are two-byte values, so the + maximum possible value is 0xFFFF = 65535. + + New registrations need to list the following attributes: + + Value: The two-byte identifier for the algorithm + Name: Name of the issuance protocol + Token Structure: The contents of the Token structure in Section 2.2 + Token Key Encoding: The encoding of the "token-key" parameter in + Section 2.2 + TokenChallenge Structure: The contents of the TokenChallenge + structure in Section 2.1 + Public Verifiability: A Y/N value indicating if the output tokens + have the public verifiability property; see Section 3.5 of + [ARCHITECTURE] for more details about this property. + Public Metadata: A Y/N value indicating if the output tokens can + contain public metadata; see Section 3.5 of [ARCHITECTURE] for + more details about this property. + Private Metadata: A Y/N value indicating if the output tokens can + contain private metadata; see Section 3.5 of [ARCHITECTURE] for + more details about this property. + Nk: The length in bytes of an output authenticator + Nid: The length of the token key identifier + Reference: Where this algorithm is defined + Notes: Any notes associated with the entry + + New entries in this registry are subject to the Specification + Required registration policy ([RFC8126], Section 4.6). Designated + experts need to ensure that the token type is defined to be used for + both token issuance and redemption. Additionally, the experts can + reject registrations on the basis that they do not meet the security + and privacy requirements for issuance protocols defined in + Section 3.2 of [ARCHITECTURE]. + + [ISSUANCE] defines entries for this registry. + +6.2.1. Reserved Values + + This document defines several Reserved values, which can be used by + clients and servers to send "greased" values in token challenges and + redemptions to ensure that implementations remain able to handle + unknown token types gracefully (this technique is inspired by + [RFC8701]). Implementations SHOULD select reserved values at random + when including them in greased messages. Servers can include these + in TokenChallenge structures, either as the only challenge when no + real token type is desired, or as one challenge in a list of + challenges that include real values. Clients can include these in + Token structures when they are not able to present a real token. The + contents of the Token structure SHOULD be filled with random bytes + when using greased values. + + The initial contents for this registry consists of multiple reserved + values, with the following attributes, which are repeated for each + registration: + + Value: 0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, + 0x6D32, 0x7F3F, 0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, + 0xE944, 0xF057 + Name: RESERVED + Token Structure: Random bytes + Token Key Encoding: Random bytes + TokenChallenge Structure: Random bytes + Publicly Verifiable: N/A + Public Metadata: N/A + Private Metadata: N/A + Nk: N/A + Nid: N/A + Reference: This document + Notes: None + +7. References + +7.1. Normative References + + [ARCHITECTURE] + Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy + Pass Architecture", Work in Progress, Internet-Draft, + draft-ietf-privacypass-architecture-16, 25 September 2023, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + . + + [SHS] Dang, Q., "Secure Hash Standard", National Institute of + Standards and Technology, DOI 10.6028/nist.fips.180-4, + July 2015, . + + [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + +7.2. Informative References + + [COOKIES] Bingler, S., West, M., and J. Wilander, "Cookies: HTTP + State Management Mechanism", Work in Progress, Internet- + Draft, draft-ietf-httpbis-rfc6265bis-12, 10 May 2023, + . + + [ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood, + "Privacy Pass Issuance Protocol", Work in Progress, + Internet-Draft, draft-ietf-privacypass-protocol-15, 25 + September 2023, . + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . + + [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early + Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September + 2018, . + + [RFC8701] Benjamin, D., "Applying Generate Random Extensions And + Sustain Extensibility (GREASE) to TLS Extensibility", + RFC 8701, DOI 10.17487/RFC8701, January 2020, + . + + [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure + QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, + . + +Appendix A. Test Vectors + + This section includes test vectors for the HTTP authentication scheme + specified in this document. It consists of the following types of + test vectors: + + 1. Test vectors for the challenge and redemption protocols. + Implementations can use these test vectors for verifying code + that builds and encodes TokenChallenge structures, as well as + code that produces a well-formed Token bound to a TokenChallenge. + + 2. Test vectors for the HTTP headers used for authentication. + Implementations can use these test vectors for validating whether + they parse HTTP authentication headers correctly to produce + TokenChallenge structures and the other associated parameters, + such as the token-key and max-age values. + +A.1. Challenge and Redemption Structure Test Vectors + + This section includes test vectors for the challenge and redemption + functionalities described in Section 2.1 and Section 2.2. Each test + vector lists the following values: + + * token_type: The type of token issuance protocol, a value from + Section 6.2. For these test vectors, token_type is 0x0002, + corresponding to the issuance protocol in [ISSUANCE]. + + * issuer_name: The name of the issuer in the TokenChallenge + structure, represented as a hexadecimal string. + + * redemption_context: The redemption context in the TokenChallenge + structure, represented as a hexadecimal string. + + * origin_info: The origin info in the TokenChallenge structure, + represented as a hexadecimal string. + + * nonce: The nonce in the Token structure, represented as a + hexadecimal string. + + * token_key: The public token-key, encoded based on the + corresponding token type, represented as a hexadecimal string. + + * token_authenticator_input: The values in the Token structure used + to compute the Token authenticator value, represented as a + hexadecimal string. + + Test vectors are provided for each of the following TokenChallenge + configurations: + + 1. TokenChallenge with a single origin and non-empty redemption + context + + 2. TokenChallenge with a single origin and empty redemption context + + 3. TokenChallenge with an empty origin and redemption context + + 4. TokenChallenge with an empty origin and non-empty redemption + context + + 5. TokenChallenge with a multiple origins and non-empty redemption + context + + These test vectors are below. + + // Test vector 1: + // token_type(0002), issuer_name(issuer.example), + // origin_info(origin.example), redemption_context(non-empty) + token_type: 0002 + issuer_name: 6973737565722e6578616d706c65 + redemption_context: + 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb + origin_info: 6f726967696e2e6578616d706c65 + nonce: + e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab + token_key_id: + ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 + token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 + 14f235e41ef7e2378e6f202688abab8e1d5518ec82964255526efd8f9db88205a + 8ddd3ffb1db298fcc3ad36c42388fca572f8982a9ca248a3056186322d93ca147 + 266121ddeb5632c07f1f71cd2708 + + // Test vector 2: + // token_type(0002), issuer_name(issuer.example), + // origin_info(origin.example), redemption_context(empty) + token_type: 0002 + issuer_name: 6973737565722e6578616d706c65 + redemption_context: + origin_info: 6f726967696e2e6578616d706c65 + nonce: + e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab + token_key_id: + ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 + token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 + 14f235e41ef7e2378e6f202688abab11e15c91a7c2ad02abd66645802373db1d8 + 23bea80f08d452541fb2b62b5898bca572f8982a9ca248a3056186322d93ca147 + 266121ddeb5632c07f1f71cd2708 + + // Test vector 3: + // token_type(0002), issuer_name(issuer.example), + // origin_info(), redemption_context(empty) + token_type: 0002 + issuer_name: 6973737565722e6578616d706c65 + redemption_context: + origin_info: + nonce: + e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab + token_key_id: + ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 + token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 + 14f235e41ef7e2378e6f202688ababb741ec1b6fd05f1e95f8982906aec161289 + 6d9ca97d53eef94ad3c9fe023f7a4ca572f8982a9ca248a3056186322d93ca147 + 266121ddeb5632c07f1f71cd2708 + + // Test vector 4: + // token_type(0002), issuer_name(issuer.example), + // origin_info(), redemption_context(non-empty) + token_type: 0002 + issuer_name: 6973737565722e6578616d706c65 + redemption_context: + 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb + origin_info: + nonce: + e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab + token_key_id: + ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 + token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 + 14f235e41ef7e2378e6f202688ababb85fb5bc06edeb0e8e8bdb5b3bea8c4fa40 + 837c82e8bcaf5882c81e14817ea18ca572f8982a9ca248a3056186322d93ca147 + 266121ddeb5632c07f1f71cd2708 + + // Test vector 5: + // token_type(0002), issuer_name(issuer.example), + // origin_info(foo.example,bar.example), + // redemption_context(non-empty) + token_type: 0002 + issuer_name: 6973737565722e6578616d706c65 + redemption_context: + 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb + origin_info: 666f6f2e6578616d706c652c6261722e6578616d706c65 + nonce: + e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab + token_key_id: + ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 + token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 + 14f235e41ef7e2378e6f202688ababa2a775866b6ae0f98944910c8f48728d8a2 + 735b9157762ddbf803f70e2e8ba3eca572f8982a9ca248a3056186322d93ca147 + 266121ddeb5632c07f1f71cd2708 + +A.2. HTTP Header Test Vectors + + This section includes test vectors the contents of the HTTP + authentication headers. Each test vector consists of one or more + challenges that comprise a WWW-Authenticate header. For each + challenge, the token-type, token-key, max-age, and token-challenge + parameters are listed. Each challenge also includes an unknown (not + specified) parameter that implementations are meant to ignore. + + The parameters for each challenge are indexed by their position in + the WWW-Authentication challenge list. For example, token-key-0 + denotes the token-key parameter for the first challenge in the list, + whereas token-key-1 denotes the token-key for the second challenge in + the list. + + The resulting wire-encoded WWW-Authentication header based on this + list of challenges is then listed at the end. Line folding is only + used to fit the document formatting constraints and not unsupported + in actual requests. + + token-type-0: 0x0002 + token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 + 8016503040202a11a301806092a864886f70d010108300b060960864801650304020 + 2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 + 5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 + ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f + 67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b + f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c + bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2 + 91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106 + 066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7 + e225a5f0203010001 + max-age-0: 10 + token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9 + 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 + e2e6578616d706c65 + + WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII + o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", + token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG + SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM + _KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi + JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS + bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE + 7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh + CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow + nChallengeAttribute="ignore-me", max-age="10" + + token-type-0: 0x0002 + token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 + 8016503040202a11a301806092a864886f70d010108300b060960864801650304020 + 2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 + 5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 + ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f + 67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b + f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c + bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2 + 91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106 + 066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7 + e225a5f0203010001 + max-age-0: 10 + token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9 + 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 + e2e6578616d706c65 + token-type-1: 0x0001 + token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a + 53fabd489fac0f82bca86249a668f3a5bfab374c9 + max-age-1: 10 + token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9 + 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 + e2e6578616d706c65 + + WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII + o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", + token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG + SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM + _KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi + JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS + bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE + 7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh + CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow + nChallengeAttribute="ignore-me", max-age="10", PrivateToken challeng + e="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPp + LODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBem + aF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ig + nore-me", max-age="10" + +Authors' Addresses + + Tommy Pauly + Apple Inc. + One Apple Park Way + Cupertino, California 95014, + United States of America + Email: tpauly@apple.com + + + Steven Valdez + Google LLC + Email: svaldez@chromium.org + + + Christopher A. Wood + Cloudflare + Email: caw@heapingbits.net diff --git a/chris-wood-patch-7/draft-ietf-privacypass-protocol.html b/chris-wood-patch-7/draft-ietf-privacypass-protocol.html new file mode 100644 index 00000000..ddd91d30 --- /dev/null +++ b/chris-wood-patch-7/draft-ietf-privacypass-protocol.html @@ -0,0 +1,3569 @@ + + + + + + +Privacy Pass Issuance Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftPrivacy Pass IssuanceOctober 2023
Celi, et al.Expires 5 April 2024[Page]
+
+
+
+
Workgroup:
+
Network Working Group
+
Internet-Draft:
+
draft-ietf-privacypass-protocol-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Authors:
+
+
+
S. Celi
+
Brave Software
+
+
+
A. Davidson
+
Brave Software
+
+
+
S. Valdez
+
Google LLC
+
+
+
C. A. Wood
+
Cloudflare
+
+
+
+
+

Privacy Pass Issuance Protocol

+
+

Abstract

+

This document specifies two variants of the two-message issuance protocol +for Privacy Pass tokens: one that produces tokens that are privately +verifiable using the issuance private key, and another that produces tokens +that are publicly verifiable using the issuance public key.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 5 April 2024.

+
+
+ + +
+
+

+1. Introduction +

+

The Privacy Pass protocol provides a privacy-preserving authorization +mechanism. In essence, the protocol allows clients to provide cryptographic +tokens that prove nothing other than that they have been created by a given +server in the past [ARCHITECTURE].

+

This document describes the issuance protocol for Privacy Pass built on +[HTTP]. It specifies two variants: one that is privately verifiable +using the issuance private key based on the oblivious pseudorandom function from +[OPRF], and one that is publicly verifiable using the +issuance public key based on the blind RSA signature scheme +[BLINDRSA].

+

This document does not cover the Privacy Pass architecture, including +choices that are necessary for deployment and application specific choices +for protecting client privacy. This information is covered in [ARCHITECTURE].

+
+
+
+
+

+2. Terminology +

+

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL +NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", +"MAY", and "OPTIONAL" in this document are to be interpreted as +described in BCP 14 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.

+

This document uses the terms Origin, Client, Issuer, and Token as defined in +Section 2 of [ARCHITECTURE]. Moreover, the following additional terms are +used throughout this document.

+
    +
  • +

    Issuer Public Key: The public key (from a private-public key pair) used by +the Issuer for issuing and verifying Tokens.

    +
    • +
  • +

    Issuer Private Key: The private key (from a private-public key pair) used by +the Issuer for issuing and verifying Tokens.

    +
    • +
+

Unless otherwise specified, this document encodes protocol messages in TLS +notation from Section 3 of [TLS13]. Moreover, all constants are in +network byte order.

+
+
+
+
+

+3. Protocol Overview +

+

The issuance protocols defined in this document embody the core of Privacy Pass. +Clients receive TokenChallenge inputs from the redemption protocol +([AUTHSCHEME], Section 2.1) and use the issuance protocols to produce +corresponding Token values ([AUTHSCHEME], Section 2.2). The issuance protocol +describes how Clients and Issuers interact to compute a token using a one-round +protocol consisting of a TokenRequest from the Client and TokenResponse from +the Issuer. This interaction is shown below.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Origin + Client + Attester + Issuer + Request + TokenChallenge + Attestation + TokenRequest + TokenResponse + Request+Token + + +
+
+
Figure 1: +Issuance Overview +
+
+

The TokenChallenge inputs to the issuance protocols described in this +document can be interactive or non-interactive, and per-origin or cross-origin.

+

The issuance protocols defined in this document are compatible with any +deployment model defined in Section 4 of [ARCHITECTURE]. The details of +attestation are outside the scope of the issuance protocol; see +Section 4 of [ARCHITECTURE] for information about how attestation can +be implemented in each of the relevant deployment models.

+

This document describes two variants of the issuance protocol: one that is +privately verifiable (Section 5) using the issuance private key based on +the oblivious pseudorandom function from [OPRF], and one +that is publicly verifiable (Section 6) using the issuance public key +based on the blind RSA signature scheme +[BLINDRSA].

+
+
+
+
+

+4. Configuration +

+

Issuers MUST provide two parameters for configuration:

+
    +
  1. +

    Issuer Request URL: A token request URL for generating access tokens. +For example, an Issuer URL might be +https://issuer.example.net/request.

    +
    2. +
  2. +

    Issuer Public Key values: A list of Issuer Public Keys for the issuance +protocol.

    +
    3. +
+

The Issuer parameters can be obtained from an Issuer via a directory object, +which is a JSON object ([RFC8259], Section 4) whose values are other JSON +values ([RFC8259], Section 3) for the parameters. The contents of this JSON +object are defined in Table 1.

+
+ + + + + + + + + + + + + + + + + + +
+Table 1: +Issuer directory object description +
Field NameValue
issuer-request-uriIssuer Request URL value (as an absolute URL, or a URL relative to the directory object) as a percent-encoded URL string, represented as a JSON string ([RFC8259], Section 7)
token-keysList of Issuer Public Key values, each represented as JSON objects ([RFC8259], Section 4)
+
+

Each "token-keys" JSON object contains the fields and corresponding raw values +defined in Table 2.

+
+ + + + + + + + + + + + + + + + + + +
+Table 2: +Issuer 'token-keys' object description' +
Field NameValue
token-typeInteger value of the Token Type, as defined in Section 8.2, represented as a JSON number ([RFC8259], Section 6)
token-keyThe base64url-encoded [RFC4648] Public Key for use with the issuance protocol as determined by the token-type field, including padding, represented as a JSON string ([RFC8259], Section 7)
+
+

Each "token-keys" JSON object may also contain the optional field "not-before". +The value of this field is the UNIX timestamp (number of seconds since +January 1, 1970, UTC -- see Section 4.2.1 of [TIMESTAMP]) at which +the key can be used. If this field is present, Clients SHOULD NOT use a token +key before this timestamp, as doing so can lead to issuance failures. The +purpose of this field is to assist in scheduled key rotations.

+

Beyond staging keys with the "not-before" value, Issuers MAY advertise multiple +"token-keys" for the same token-type to facilitate key rotation. In this case, +Issuers indicate preference for which token key to use based on the order of +keys in the list, with preference given to keys earlier in the list. Clients +SHOULD use the first key in the "token-keys" list that either does not have a +"not-before" value or has a "not-before" value in the past, since the first such key is the +most likely to be valid in the given time window. Origins can attempt +to use any key in the "token-keys" list to verify tokens, starting with the most +preferred key in the list. Trial verification like this can help deal with Client +clock skew.

+

Altogether, the Issuer's directory could look like the following (with the +"token-key" fields abbreviated):

+
+
+ {
+    "issuer-request-uri": "https://issuer.example.net/request",
+    "token-keys": [
+      {
+        "token-type": 2,
+        "token-key": "MI...AB",
+        "not-before": 1686913811,
+      },
+      {
+        "token-type": 2,
+        "token-key": "MI...AQ",
+      }
+    ]
+ }
+
+
+

Clients that use this directory resource before 1686913811 in UNIX time would use the +second key in the "token-keys" list, whereas Clients that use this directory after +1686913811 in UNIX time would use the first key in the "token-keys" list.

+

A complete "token-key" value, encoded as it would be in the Issuer directory, +would look like the following (line breaks are inserted to fit within the per-line +character limits):

+
+
+$ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDAL \
+ BglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr_DhZAPhJM7 \
+ Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTvW6SKCh7ZPXEqCGR \
+ sq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWbjf21iaVjXJ2VdwdS-8O- \
+ 430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuID9OQm1nxfs1Z4PhWBzt93T2oz \
+ Tnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99aA-muXRFN4ZUwORrF7cAcCUD_-56_6 \
+ fh9s34FmqBGwIDAQAB \
+ | sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \
+ | openssl asn1parse -dump -inform DER
+    0:d=0  hl=4 l= 338 cons: SEQUENCE
+    4:d=1  hl=2 l=  61 cons: SEQUENCE
+    6:d=2  hl=2 l=   9 prim: OBJECT            :rsassaPss
+   17:d=2  hl=2 l=  48 cons: SEQUENCE
+   19:d=3  hl=2 l=  13 cons: cont [ 0 ]
+   21:d=4  hl=2 l=  11 cons: SEQUENCE
+   23:d=5  hl=2 l=   9 prim: OBJECT            :sha384
+   34:d=3  hl=2 l=  26 cons: cont [ 1 ]
+   36:d=4  hl=2 l=  24 cons: SEQUENCE
+   38:d=5  hl=2 l=   9 prim: OBJECT            :mgf1
+   49:d=5  hl=2 l=  11 cons: SEQUENCE
+   51:d=6  hl=2 l=   9 prim: OBJECT            :sha384
+   62:d=3  hl=2 l=   3 cons: cont [ 2 ]
+   64:d=4  hl=2 l=   1 prim: INTEGER           :30
+   67:d=1  hl=4 l= 271 prim: BIT STRING
+   ... truncated public key bytes ...
+
+
+

Issuer directory resources have the media type +"application/private-token-issuer-directory" and are located at the well-known location +/.well-known/private-token-issuer-directory; see Section 8.1 for the registration +information for this well-known URI. The reason that this resource is located +at a well-known URI is that Issuers are defined by an origin name in TokenChallenge +structures; see Section 2.1 of [AUTHSCHEME].

+

The Issuer directory and Issuer resources SHOULD be available on the same origin. If +an Issuer wants to service multiple different Issuer directories they MUST create +unique subdomains for each so the TokenChallenge defined in +Section 2.1 of [AUTHSCHEME] can be +differentiated correctly.

+

Issuers SHOULD use HTTP cache directives to permit caching of this resource +[RFC5861]. The cache lifetime depends on the Issuer's key rotation schedule. +Regular rotation of token keys is recommended to minimize the risk of key +compromise and any harmful effects that happen due to key compromise.

+

Issuers can control cache lifetime with the Cache-Control header, as follows:

+
+
+  Cache-Control: max-age=86400
+
+
+

Consumers of the Issuer directory resource SHOULD follow the usual HTTP caching +[RFC9111] semantics when processing this resource. Long cache lifetimes may +result in use of stale Issuer configuration information, whereas short +lifetimes may result in decreased performance. When use of an Issuer +configuration results in token issuance failures, e.g., because the +Issuer has invalidated its directory resource before its expiration +time and issuance requests using this configuration are unsuccessful, +the directory SHOULD be fetched and revalidated. Issuance will continue +to fail until the Issuer configuration is updated.

+
+
+
+
+

+5. Issuance Protocol for Privately Verifiable Tokens +

+

The privately verifiable issuance protocol allows Clients to produce Token +values that verify using the Issuer Private Key. This protocol is based +on the oblivious pseudorandom function from [OPRF].

+

Issuers provide a Issuer Private and Public Key, denoted skI and pkI respectively, +used to produce tokens as input to the protocol. See Section 5.5 +for how these keys are generated.

+

Clients provide the following as input to the issuance protocol:

+
    +
  • +

    Issuer Request URL: A URL identifying the location to which issuance requests +are sent. This can be a URL derived from the "issuer-request-uri" value in the +Issuer's directory resource, or it can be another Client-configured URL. The value +of this parameter depends on the Client configuration and deployment model. +For example, in the 'Joint Origin and Issuer' deployment model, the Issuer +Request URL might correspond to the Client's configured Attester, and the +Attester is configured to relay requests to the Issuer.

    +
    • +
  • +

    Issuer name: An identifier for the Issuer. This is typically a host name that +can be used to construct HTTP requests to the Issuer.

    +
    • +
  • +

    Issuer Public Key: pkI, with a key identifier token_key_id computed as +described in Section 5.5.

    +
    • +
  • +

    Challenge value: challenge, an opaque byte string. For example, this might +be provided by the redemption protocol in [AUTHSCHEME].

    +
    • +
+

Given this configuration and these inputs, the two messages exchanged in +this protocol are described below. This section uses notation described in +[OPRF], Section 4, including SerializeElement and DeserializeElement, +SerializeScalar and DeserializeScalar, and DeriveKeyPair.

+

The constants Ne and Ns are as defined in [OPRF], Section 4 for +OPRF(P-384, SHA-384). The constant Nk, which is also equal to Nh as defined +in [OPRF], Section 4, is defined by Section 8.2.1.

+
+
+

+5.1. Client-to-Issuer Request +

+

The Client first creates a context as follows:

+
+
+client_context = SetupVOPRFClient("P384-SHA384", pkI)
+
+
+

Here, "P384-SHA384" is the identifier corresponding to the +OPRF(P-384, SHA-384) ciphersuite in [OPRF]. SetupVOPRFClient +is defined in [OPRF], Section 3.2.

+

The Client then creates an issuance request message for a random 32-byte value nonce +with the input challenge and Issuer key identifier as described below:

+
+
+nonce = random(32)
+challenge_digest = SHA256(challenge)
+token_input = concat(0x0001, // Token type field is 2 bytes long
+                     nonce,
+                     challenge_digest,
+                     token_key_id)
+blind, blinded_element = client_context.Blind(token_input)
+
+
+

The Blind function is defined in [OPRF], Section 3.3.2. +If the Blind function fails, the Client aborts the protocol. +The Client stores the nonce and challenge_digest values locally +for use when finalizing the issuance protocol to produce a token +(as described in Section 5.3).

+

The Client then creates a TokenRequest structured as follows:

+
+
+struct {
+  uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */
+  uint8_t truncated_token_key_id;
+  uint8_t blinded_msg[Ne];
+} TokenRequest;
+
+
+

The structure fields are defined as follows:

+
    +
  • +

    "token_type" is a 2-octet integer, which matches the type in the challenge.

    +
    • +
  • +

    "truncated_token_key_id" is the least significant byte of the token_key_id +(Section 5.5) in network byte order (in other words, the last 8 +bits of token_key_id). This value is truncated so that Issuers cannot use +token_key_id as a way of uniquely identifying Clients; see Section 7 +and referenced information for more details.

    +
    • +
  • +

    "blinded_msg" is the Ne-octet blinded message defined above, computed as +SerializeElement(blinded_element).

    +
    • +
+

The values token_input and blinded_element are stored locally and used +later as described in Section 5.3. The Client then generates an HTTP +POST request to send to the Issuer Request URL, with the TokenRequest as the +content. The media type for this request is +"application/private-token-request". An example request for the Issuer Request URL +"https://issuer.example.net/request" is shown below.

+
+
+POST /request HTTP/1.1
+Host: issuer.example.net
+Accept: application/private-token-response
+Content-Type: application/private-token-request
+Content-Length: <Length of TokenRequest>
+
+<Bytes containing the TokenRequest>
+
+
+
+
+
+
+

+5.2. Issuer-to-Client Response +

+

Upon receipt of the request, the Issuer validates the following conditions:

+
    +
  • +

    The TokenRequest contains a supported token_type.

    +
    • +
  • +

    The TokenRequest.truncated_token_key_id corresponds to the truncated key ID +of a Public Key owned by the Issuer.

    +
    • +
  • +

    The TokenRequest.blinded_msg is of the correct size.

    +
    • +
+

If any of these conditions is not met, the Issuer MUST return an HTTP 422 +(Unprocessable Content) error to the client.

+

If these conditions are met, the Issuer then tries to deserialize +TokenRequest.blinded_msg using DeserializeElement from +Section 2.1 of [OPRF], yielding blinded_element. If this fails, the +Issuer MUST return an HTTP 422 (Unprocessable Content) error to the +client. Otherwise, if the Issuer is willing to produce a token to the Client, +the Issuer completes the issuance flow by computing a blinded response as +follows:

+
+
+server_context = SetupVOPRFServer("P384-SHA384", skI)
+evaluate_element, proof =
+  server_context.BlindEvaluate(skI, pkI, blinded_element)
+
+
+

SetupVOPRFServer is defined in [OPRF], Section 3.2 and BlindEvaluate is +defined in [OPRF], Section 3.3.2. The Issuer then creates a TokenResponse +structured as follows:

+
+
+struct {
+   uint8_t evaluate_msg[Ne];
+   uint8_t evaluate_proof[Ns+Ns];
+} TokenResponse;
+
+
+

The structure fields are defined as follows:

+
    +
  • +

    "evaluate_msg" is the Ne-octet evaluated message, computed as +SerializeElement(evaluate_element).

    +
    • +
  • +

    "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of +Scalar values, computed as +concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])).

    +
    • +
+

The Issuer generates an HTTP response with status code 200 whose content +consists of TokenResponse, with the content type set as +"application/private-token-response".

+
+
+HTTP/1.1 200 OK
+Content-Type: application/private-token-response
+Content-Length: <Length of TokenResponse>
+
+<Bytes containing the TokenResponse>
+
+
+
+
+
+
+

+5.3. Finalization +

+

Upon receipt, the Client handles the response and, if successful, deserializes +the content values TokenResponse.evaluate_msg and TokenResponse.evaluate_proof, +yielding evaluated_element and proof. If deserialization of either value +fails, the Client aborts the protocol. Otherwise, the Client processes the +response as follows:

+
+
+authenticator = client_context.Finalize(token_input, blind,
+                                        evaluated_element,
+                                        blinded_element,
+                                        proof)
+
+
+

The Finalize function is defined in [OPRF], Section 3.3.2. If this +succeeds, the Client then constructs a Token as follows:

+
+
+struct {
+  uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */
+  uint8_t nonce[32];
+  uint8_t challenge_digest[32];
+  uint8_t token_key_id[32];
+  uint8_t authenticator[Nk];
+} Token;
+
+
+

The Token.nonce value is that which was created in Section 5.1. +If the Finalize function fails, the Client aborts the protocol.

+
+
+
+
+

+5.4. Token Verification +

+

Verifying a Token requires creating a VOPRF context using the Issuer Private +Key and Public Key, evaluating the token contents, and comparing the result +against the token authenticator value:

+
+
+server_context = SetupVOPRFServer("P384-SHA384", skI)
+token_authenticator_input =
+  concat(Token.token_type,
+         Token.nonce,
+         Token.challenge_digest,
+         Token.token_key_id)
+token_authenticator =
+  server_context.Evaluate(token_authenticator_input)
+valid = (token_authenticator == Token.authenticator)
+
+
+
+
+
+
+

+5.5. Issuer Configuration +

+

Issuers are configured with Issuer Private and Public Keys, each denoted skI +and pkI, respectively, used to produce tokens. These keys MUST NOT be reused +in other protocols. A RECOMMENDED method for generating keys is as +follows:

+
+
+seed = random(Ns)
+(skI, pkI) = DeriveKeyPair(seed, "PrivacyPass")
+
+
+

The DeriveKeyPair function is defined in [OPRF], Section 3.3.1. +The key identifier for a public key pkI, denoted token_key_id, is computed +as follows:

+
+
+token_key_id = SHA256(SerializeElement(pkI))
+
+
+

Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD +ensure that the truncated form of new key IDs do not collide with other +truncated key IDs in rotation. Collisions can cause the Issuer to use +the wrong Issuer Private Key for issuance, which will in turn cause the +resulting tokens to be invalid. There is no known security consequence of +using the the wrong Issuer Private Key. A possible exception to this constraint +would be a colliding key that is still in use but in the process of being +rotated out, in which case the collision cannot reasonably be avoided but it +is expected to be transient.

+
+
+
+
+
+
+

+6. Issuance Protocol for Publicly Verifiable Tokens +

+

This section describes a variant of the issuance protocol in Section 5 +for producing publicly verifiable tokens using the protocol in [BLINDRSA]. +In particular, this variant of the issuance protocol works for the +RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic +blind RSA protocol variants described in Section 5 of [BLINDRSA].

+

The publicly verifiable issuance protocol differs from the protocol in +Section 5 in that the output tokens are publicly verifiable by anyone +with the Issuer Public Key. This means any Origin can select a given Issuer to +produce tokens, as long as the Origin has the Issuer public key, without +explicit coordination or permission from the Issuer. This is because the Issuer +does not learn the Origin that requested the token during the issuance protocol.

+

Beyond this difference, the publicly verifiable issuance protocol variant is +nearly identical to the privately verifiable issuance protocol variant. In +particular, Issuers provide an Issuer Private and Public Key, denoted skI and pkI, +respectively, used to produce tokens as input to the protocol. See +Section 6.5 for how these keys are generated.

+

Clients provide the following as input to the issuance protocol:

+
    +
  • +

    Issuer Request URL: A URL identifying the location to which issuance requests +are sent. This can be a URL derived from the "issuer-request-uri" value in the +Issuer's directory resource, or it can be another Client-configured URL. The value +of this parameter depends on the Client configuration and deployment model. +For example, in the 'Split Origin, Attester, Issuer' deployment model, the +Issuer Request URL might correspond to the Client's configured Attester, +and the Attester is configured to relay requests to the Issuer.

    +
    • +
  • +

    Issuer name: An identifier for the Issuer. This is typically a host name that +can be used to construct HTTP requests to the Issuer.

    +
    • +
  • +

    Issuer Public Key: pkI, with a key identifier token_key_id computed as +described in Section 6.5.

    +
    • +
  • +

    Challenge value: challenge, an opaque byte string. For example, this might +be provided by the redemption protocol in [AUTHSCHEME].

    +
    • +
+

Given this configuration and these inputs, the two messages exchanged in +this protocol are described below. The constant Nk is defined by +Section 8.2.2.

+
+
+

+6.1. Client-to-Issuer Request +

+

The Client first creates an issuance request message for a random 32-byte value +nonce using the input challenge and Issuer key identifier as follows:

+
+
+nonce = random(32)
+challenge_digest = SHA256(challenge)
+token_input = concat(0x0002, // Token type field is 2 bytes long
+                     nonce,
+                     challenge_digest,
+                     token_key_id)
+blinded_msg, blind_inv =
+  Blind(pkI, PrepareIdentity(token_input))
+
+
+

The PrepareIdentity and Blind functions are defined in +Section 4.1 of [BLINDRSA] and Section 4.2 of [BLINDRSA], respectively. +The Client stores the nonce and challenge_digest values locally for use +when finalizing the issuance protocol to produce a token (as described +in Section 6.3).

+

The Client then creates a TokenRequest structured as follows:

+
+
+struct {
+  uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */
+  uint8_t truncated_token_key_id;
+  uint8_t blinded_msg[Nk];
+} TokenRequest;
+
+
+

The structure fields are defined as follows:

+
    +
  • +

    "token_type" is a 2-octet integer, which matches the type in the challenge.

    +
    • +
  • +

    "truncated_token_key_id" is the least significant byte of the token_key_id +(Section 6.5) in network byte order (in other words, the +last 8 bits of token_key_id). This value is truncated so that Issuers cannot use +token_key_id as a way of uniquely identifying Clients; see Section 7 +and referenced information for more details.

    +
    • +
  • +

    "blinded_msg" is the Nk-octet request defined above.

    +
    • +
+

The Client then generates an HTTP POST request to send to the Issuer Request +URL, with the TokenRequest as the content. The media type for this request +is "application/private-token-request". An example request for the Issuer +Request URL "https://issuer.example.net/request" is shown below.

+
+
+POST /request HTTP/1.1
+Host: issuer.example.net
+Accept: application/private-token-response
+Content-Type: application/private-token-request
+Content-Length: <Length of TokenRequest>
+
+<Bytes containing the TokenRequest>
+
+
+
+
+
+
+

+6.2. Issuer-to-Client Response +

+

Upon receipt of the request, the Issuer validates the following conditions:

+
    +
  • +

    The TokenRequest contains a supported token_type.

    +
    • +
  • +

    The TokenRequest.truncated_token_key_id corresponds to the truncated key +ID of an Issuer Public Key.

    +
    • +
  • +

    The TokenRequest.blinded_msg is of the correct size.

    +
    • +
+

If any of these conditions is not met, the Issuer MUST return an HTTP 422 +(Unprocessable Content) error to the Client. Otherwise, if the +Issuer is willing to produce a token to the Client, the Issuer +completes the issuance flow by computing a blinded response as follows:

+
+
+blind_sig = BlindSign(skI, TokenRequest.blinded_msg)
+
+
+

The BlindSign function is defined in Section 4.3 of [BLINDRSA]. +The result is encoded and transmitted to the client in the following +TokenResponse structure:

+
+
+struct {
+  uint8_t blind_sig[Nk];
+} TokenResponse;
+
+
+

The Issuer generates an HTTP response with status code 200 whose content +consists of TokenResponse, with the content type set as +"application/private-token-response".

+
+
+HTTP/1.1 200 OK
+Content-Type: application/private-token-response
+Content-Length: <Length of TokenResponse>
+
+<Bytes containing the TokenResponse>
+
+
+
+
+
+
+

+6.3. Finalization +

+

Upon receipt, the Client handles the response and, if successful, processes the +content as follows:

+
+
+authenticator =
+  Finalize(pkI, nonce, blind_sig, blind_inv)
+
+
+

The Finalize function is defined in Section 4.4 of [BLINDRSA]. If this +succeeds, the Client then constructs a Token as described in [AUTHSCHEME] as +follows:

+
+
+struct {
+  uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */
+  uint8_t nonce[32];
+  uint8_t challenge_digest[32];
+  uint8_t token_key_id[32];
+  uint8_t authenticator[Nk];
+} Token;
+
+
+

The Token.nonce value is that which was sampled in Section 5.1. +If the Finalize function fails, the Client aborts the protocol.

+
+
+
+
+

+6.4. Token Verification +

+

Verifying a Token requires checking that Token.authenticator is a valid +signature over the remainder of the token input using the Issuer Public Key. +The function RSASSA-PSS-VERIFY is defined in Section 8.1.2 of [RFC8017], +using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask +generation function (MGF), and a 48-byte salt length (sLen).

+
+
+token_authenticator_input =
+  concat(Token.token_type,
+         Token.nonce,
+         Token.challenge_digest,
+         Token.token_key_id)
+valid = RSASSA-PSS-VERIFY(pkI,
+                          token_authenticator_input,
+                          Token.authenticator)
+
+
+
+
+
+
+

+6.5. Issuer Configuration +

+

Issuers are configured with Issuer Private and Public Keys, each denoted skI and +pkI, respectively, used to produce tokens. Each key SHALL be generated +securely, for example as specified in FIPS 186-5 [DSS]. +These keys MUST NOT be reused in other protocols.

+

The key identifier for an Issuer Private and Public Key (skI, pkI), +denoted token_key_id, is computed as SHA256(encoded_key), where encoded_key +is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) object carrying pkI +as a DER-encoded RSAPublicKey value [RFC5756] in the subjectPublicKey +field. Additionally, the SPKI object MUST use the id-RSASSA-PSS object +identifier in the algorithm field within the SPKI object, the parameters field +MUST contain a RSASSA-PSS-params value, and MUST include the hashAlgorithm, +maskGenAlgorithm, and saltLength values. The saltLength MUST match the output +size of the hash function associated with the public key and token type.

+

An example sequence of the SPKI object (in ASN.1 format, with the actual public key +bytes truncated) for a 2048-bit key is below:

+
+
+$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER
+    0:d=0  hl=4 l= 338 cons: SEQUENCE
+    4:d=1  hl=2 l=  61 cons: SEQUENCE
+    6:d=2  hl=2 l=   9 prim: OBJECT            :rsassaPss
+   17:d=2  hl=2 l=  48 cons: SEQUENCE
+   19:d=3  hl=2 l=  13 cons: cont [ 0 ]
+   21:d=4  hl=2 l=  11 cons: SEQUENCE
+   23:d=5  hl=2 l=   9 prim: OBJECT            :sha384
+   34:d=3  hl=2 l=  26 cons: cont [ 1 ]
+   36:d=4  hl=2 l=  24 cons: SEQUENCE
+   38:d=5  hl=2 l=   9 prim: OBJECT            :mgf1
+   49:d=5  hl=2 l=  11 cons: SEQUENCE
+   51:d=6  hl=2 l=   9 prim: OBJECT            :sha384
+   62:d=3  hl=2 l=   3 cons: cont [ 2 ]
+   64:d=4  hl=2 l=   1 prim: INTEGER           :30
+   67:d=1  hl=4 l= 271 prim: BIT STRING
+   ... truncated public key bytes ...
+
+
+

Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD +ensure that the truncated form of new key IDs do not collide with other +truncated key IDs in rotation. Collisions can cause the Issuer to use +the wrong Issuer Private Key for issuance, which will in turn cause the +resulting tokens to be invalid. There is no known security consequence of +using the the wrong Issuer Private Key. A possible exception to this constraint +would be a colliding key that is still in use but in the process of being +rotated out, in which case the collision cannot reasonably be avoided but it +is expected to be transient.

+
+
+
+
+
+
+

+7. Security considerations +

+

This document outlines how to instantiate the Issuance protocol +based on the VOPRF defined in [OPRF] and blind RSA protocol defined in +[BLINDRSA]. All security considerations described in the VOPRF and blind RSA +documents also apply in the Privacy Pass use-case. Considerations related to +broader privacy and security concerns in a multi-Client and multi-Issuer +setting are deferred to the architecture document [ARCHITECTURE]. In +particular, Section 4 and Section 5 of [ARCHITECTURE] discuss +relevant privacy considerations influenced by the Privacy Pass deployment +model, and Section 6 of [ARCHITECTURE] discusses privacy considerations that +apply regardless of deployment model. Notable considerations include those pertaining to +Issuer Public Key rotation and consistency, where consistency is as described +in [CONSISTENCY], and Issuer selection.

+
+
+
+
+

+8. IANA considerations +

+

This section contains considerations for IANA.

+
+
+

+8.1. Well-Known 'private-token-issuer-directory' URI +

+

This document updates the "Well-Known URIs" Registry [WellKnownURIs] with the +following values.

+
+ + + + + + + + + + + + + + + + + + + + +
+Table 3: +'private-token-issuer-directory' Well-Known URI +
URI SuffixChange ControllerReferenceStatusRelated information
private-token-issuer-directoryIETF[this document]permanentNone
+
+
+
+
+
+

+8.2. Token Type Registry Updates +

+

This document updates the "Privacy Pass Token Type" Registry with the +following entries.

+
+
+

+8.2.1. Token Type VOPRF (P-384, SHA-384) +

+
    +
  • +

    Value: 0x0001

    +
    • +
  • +

    Name: VOPRF (P-384, SHA-384)

    +
    • +
  • +

    Token Structure: As defined in Section 2.2 of [AUTHSCHEME]

    +
    • +
  • +

    Token Key Encoding: Serialized using SerializeElement from Section 2.1 of [OPRF]

    +
    • +
  • +

    TokenChallenge Structure: As defined in Section 2.1 of [AUTHSCHEME]

    +
    • +
  • +

    Public Verifiability: N

    +
    • +
  • +

    Public Metadata: N

    +
    • +
  • +

    Private Metadata: N

    +
    • +
  • +

    Nk: 48

    +
    • +
  • +

    Nid: 32

    +
    • +
  • +

    Reference: Section 5

    +
    • +
  • +

    Notes: None

    +
    • +
+
+
+
+
+

+8.2.2. Token Type Blind RSA (2048-bit) +

+
    +
  • +

    Value: 0x0002

    +
    • +
  • +

    Name: Blind RSA (2048-bit)

    +
    • +
  • +

    Token Structure: As defined in Section 2.2 of [AUTHSCHEME]

    +
    • +
  • +

    Token Key Encoding: Serialized as a DER-encoded SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID [RFC5756]

    +
    • +
  • +

    TokenChallenge Structure: As defined in Section 2.1 of [AUTHSCHEME]

    +
    • +
  • +

    Public Verifiability: Y

    +
    • +
  • +

    Public Metadata: N

    +
    • +
  • +

    Private Metadata: N

    +
    • +
  • +

    Nk: 256

    +
    • +
  • +

    Nid: 32

    +
    • +
  • +

    Reference: Section 6

    +
    • +
  • +

    Notes: The RSABSSA-SHA384-PSS-Deterministic and +RSABSSA-SHA384-PSSZERO-Deterministic variants are supported

    +
    • +
+
+
+
+
+
+
+

+8.3. Media Types +

+

The following entries should be added to the IANA "media types" +registry:

+
    +
  • +

    "application/private-token-issuer-directory"

    +
    • +
  • +

    "application/private-token-request"

    +
    • +
  • +

    "application/private-token-response"

    +
    • +
+

The templates for these entries are listed below and the +reference should be this RFC.

+
+
+

+8.3.1. "application/private-token-issuer-directory" media type +

+
+
Type name:
+
+

application

+
+
+
Subtype name:
+
+

private-token-issuer-directory

+
+
+
Required parameters:
+
+

N/A

+
+
+
Optional parameters:
+
+

N/A

+
+
+
Encoding considerations:
+
+

"binary"

+
+
+
Security considerations:
+
+

see Section 4

+
+
+
Interoperability considerations:
+
+

N/A

+
+
+
Published specification:
+
+

this specification

+
+
+
Applications that use this media type:
+
+

Services that implement the Privacy Pass issuer role, and client +applications that interact with the issuer for the purposes of +issuing or redeeming tokens.

+
+
+
Fragment identifier considerations:
+
+

N/A

+
+
+
Additional information:
+
+
+
Magic number(s):
+
N/A +
+
+
Deprecated alias names for this type:
+
N/A +
+
+
File extension(s):
+
N/A +
+
+
Macintosh file type code(s):
+
N/A +
+
+
+
+
+
Person and email address to contact for further information:
+
+

see Authors' Addresses section

+
+
+
Intended usage:
+
+

COMMON

+
+
+
Restrictions on usage:
+
+

N/A

+
+
+
Author:
+
+

see Authors' Addresses section

+
+
+
Change controller:
+
+

IETF

+
+
+
+
+
+
+
+

+8.3.2. "application/private-token-request" media type +

+
+
Type name:
+
+

application

+
+
+
Subtype name:
+
+

private-token-request

+
+
+
Required parameters:
+
+

N/A

+
+
+
Optional parameters:
+
+

N/A

+
+
+
Encoding considerations:
+
+

"binary"

+
+
+
Security considerations:
+
+

see Section 7

+
+
+
Interoperability considerations:
+
+

N/A

+
+
+
Published specification:
+
+

this specification

+
+
+
Applications that use this media type:
+
+

Applications that want to issue or facilitate issuance of Privacy Pass tokens, +including Privacy Pass issuer applications themselves.

+
+
+
Fragment identifier considerations:
+
+

N/A

+
+
+
Additional information:
+
+
+
Magic number(s):
+
N/A +
+
+
Deprecated alias names for this type:
+
N/A +
+
+
File extension(s):
+
N/A +
+
+
Macintosh file type code(s):
+
N/A +
+
+
+
+
+
Person and email address to contact for further information:
+
+

see Authors' Addresses section

+
+
+
Intended usage:
+
+

COMMON

+
+
+
Restrictions on usage:
+
+

N/A

+
+
+
Author:
+
+

see Authors' Addresses section

+
+
+
Change controller:
+
+

IETF

+
+
+
+
+
+
+
+

+8.3.3. "application/private-token-response" media type +

+
+
Type name:
+
+

application

+
+
+
Subtype name:
+
+

private-token-response

+
+
+
Required parameters:
+
+

N/A

+
+
+
Optional parameters:
+
+

N/A

+
+
+
Encoding considerations:
+
+

"binary"

+
+
+
Security considerations:
+
+

see Section 7

+
+
+
Interoperability considerations:
+
+

N/A

+
+
+
Published specification:
+
+

this specification

+
+
+
Applications that use this media type:
+
+

Applications that want to issue or facilitate issuance of Privacy Pass tokens, +including Privacy Pass issuer applications themselves.

+
+
+
Fragment identifier considerations:
+
+

N/A

+
+
+
Additional information:
+
+
+
Magic number(s):
+
N/A +
+
+
Deprecated alias names for this type:
+
N/A +
+
+
File extension(s):
+
N/A +
+
+
Macintosh file type code(s):
+
N/A +
+
+
+
+
+
Person and email address to contact for further information:
+
+

see Authors' Addresses section

+
+
+
Intended usage:
+
+

COMMON

+
+
+
Restrictions on usage:
+
+

N/A

+
+
+
Author:
+
+

see Authors' Addresses section

+
+
+
Change controller:
+
+

IETF

+
+
+
+
+
+
+
+
+
+
+

+9. References +

+
+
+

+9.1. Normative References +

+
+
[ARCHITECTURE]
+
+Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", Work in Progress, Internet-Draft, draft-ietf-privacypass-architecture-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-16>.
+
+
[AUTHSCHEME]
+
+Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass HTTP Authentication Scheme", Work in Progress, Internet-Draft, draft-ietf-privacypass-auth-scheme-14, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14>.
+
+
[BLINDRSA]
+
+Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind Signatures", Work in Progress, Internet-Draft, draft-irtf-cfrg-rsa-blind-signatures-14, , <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-rsa-blind-signatures-14>.
+
+
[HTTP]
+
+Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
+
+
[OPRF]
+
+Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Work in Progress, Internet-Draft, draft-irtf-cfrg-voprf-21, , <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC4648]
+
+Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/rfc/rfc4648>.
+
+
[RFC5756]
+
+Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, DOI 10.17487/RFC5756, , <https://www.rfc-editor.org/rfc/rfc5756>.
+
+
[RFC5861]
+
+Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, DOI 10.17487/RFC5861, , <https://www.rfc-editor.org/rfc/rfc5861>.
+
+
[RFC8017]
+
+Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, , <https://www.rfc-editor.org/rfc/rfc8017>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
[RFC8259]
+
+Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
+
+
[RFC9111]
+
+Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, , <https://www.rfc-editor.org/rfc/rfc9111>.
+
+
[TIMESTAMP]
+
+Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Defining Packet Timestamps", RFC 8877, DOI 10.17487/RFC8877, , <https://www.rfc-editor.org/rfc/rfc8877>.
+
+
[TLS13]
+
+Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
+
+
[WellKnownURIs]
+
+"Well-Known URIs", n.d., <https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml>.
+
+
+
+
+
+
+

+9.2. Informative References +

+
+
[CONSISTENCY]
+
+Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, "Key Consistency and Discovery", Work in Progress, Internet-Draft, draft-ietf-privacypass-key-consistency-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01>.
+
+
[DSS]
+
+Moody, D., "Digital Signature Standard (DSS)", National Institute of Standards and Technology, DOI 10.6028/nist.fips.186-5, , <https://doi.org/10.6028/nist.fips.186-5>.
+
+
[RFC5280]
+
+Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
+
+
+
+
+
+
+
+

+Appendix A. Acknowledgements +

+

The authors of this document would like to acknowledge the helpful +feedback and discussions from Benjamin Schwartz, Joseph Salowey, +and Tara Whalen.

+
+
+
+
+

+Appendix B. Test Vectors +

+

This section includes test vectors for the two basic issuance protocols +specified in this document. Appendix B.1 contains test vectors +for token issuance protocol 1 (0x0001), and Appendix B.2 contains +test vectors for token issuance protocol 2 (0x0002).

+
+
+

+B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) +

+

The test vector below lists the following values:

+
    +
  • +

    skS: The Issuer Private Key, serialized using SerializeScalar from +Section 2.1 of [OPRF] and represented as a hexadecimal string.

    +
    • +
  • +

    pkS: The Issuer Public Key, serialized according to the encoding in Section 8.2.1.

    +
    • +
  • +

    token_challenge: A randomly generated TokenChallenge structure, represented +as a hexadecimal string.

    +
    • +
  • +

    nonce: The 32-byte client nonce generated according to Section 5.1, +represented as a hexadecimal string.

    +
    • +
  • +

    blind: The blind used when computing the OPRF blinded message, serialized +using SerializeScalar from Section 2.1 of [OPRF] and represented as a +hexadecimal string.

    +
    • +
  • +

    token_request: The TokenRequest message constructed according to +Section 5.1, represented as a hexadecimal string.

    +
    • +
  • +

    token_response: The TokenResponse message constructed according to +Section 5.2, represented as a hexadecimal string.

    +
    • +
  • +

    token: The output Token from the protocol, represented as a hexadecimal +string.

    +
    • +
+
+
+// Test vector 1
+skS: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181
+14910bee3c919bed1bbffe3fc1b87d53240a
+pkS: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c
+21da1a46d42ca38f7beabdf05c074aee1455bf
+token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc
+daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696
+7696e2e6578616d706c65
+nonce:
+6aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05fafe73073b8
+blind: 8e7fd80970b8a00b0931b801a2e22d9903d83bd5597c6a4dc1496ed2b1
+7ef820445ef3bd223f3ab2c4f54c5d1c956909
+token_request: 0001f4030ab3e23181d1e213f24315f5775983c678ce22eff9
+427610832ab3900f2cd12d6829a07ec8a6813cf0b5b886f4cc4979
+token_response: 036bb3c5c397d88c3527cf9f08f1fe63687b867e85c930c49
+ee2c222408d4903722a19ff272ac97e3725b947c972784ebfe86eb9ea54336e43
+34ea9660212c0c85fbadfbf491a1ce2446fc3379337fccd45c1059b2bc760110e
+e1ec227d8e01c9f482c00c47ffa0dbe2fb58c32dde2b1dbe69fff920a528e68dd
+9b3c2483848e57c30542b8984fa6bfecd6d71d54d53eda
+token: 00016aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05f
+afe73073b8501370b494089dc462802af545e63809581ee6ef57890a12105c283
+68169514bf260d0792bf7f46c9866a6d37c3032d8714415f87f5f6903d7fb071e
+253be2f4e0a835d76528b8444f73789ee7dc90715b01c17902fd87375c00a7a9d
+3d92540437f470773be20f71e721da3af40edeb
+
+// Test vector 2
+skS: 39efed331527cc4ddff9722ab5cd35aeafe7c27520b0cfa2eedbdc298dc3
+b12bc8298afcc46558af1e2eeacc5307d865
+pkS: 038017e005904c6146b37109d6c2a72b95a183aaa9ed951b8d8fb1ed9033
+f68033284d175e7df89849475cd67a86bfbf4e
+token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269
+67696e2e6578616d706c65
+nonce:
+7617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3190c29d665
+blind: 6492ee50072fa18d035d69c4246362dffe2621afb95a10c033bb0109e0
+f705b0437c425553272e0aa5266ec379e7015e
+token_request: 000133033a5fe04a39da1bbfb68ccdeecd1917474dd525462e
+5a90a6ba53b42aaa1486fe443a2e1c7f3fd5ff028a1c7cf1aeac5d
+token_response: 023bf8cd624880d669c5cc6c88b056355c6e8e1bcbf3746cf
+b9ab9248a4c056f23a4876ef998a8b6b281d50f852c6fa868fc4fa135c79ccb5f
+bdf8bf3c926e10c7c12f934a887d86da4a4e5be70f5a169aa75720887bb690536
+92a8f11f9cda7a72f281e4e3568e848225367946c70db09e718e3cba16193987b
+c10bede3ef54c4d036c17cd4015bb113be60d7aa927e0d
+token: 00017617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3
+190c29d665c994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1
+34bd5a62a116477bc9e1a205cca95d0c92335ca7a3e71063b2ac020bdd231c660
+97f12333ef438d00801bca5ace0fab8eb483dc04cd62578b95b5652921cd2698c
+45ea74f6c8827b4e19f01140fa5bd039866f562
+
+// Test vector 3
+skS: 2b7709595b62b784f14946ae828f65e6caeba6eefe732c86e9ae50e818c0
+55b3d7ca3a5f2beecaa859a62ff7199d35cc
+pkS: 03a0de1bf3fd0a73384283b648884ba9fa5dee190f9d7ad4292c2fd49d8b
+4d64db674059df67f5bd7e626475c78934ae8d
+token_challenge: 0001000e6973737565722e6578616d706c65000017666f6f
+2e6578616d706c652c6261722e6578616d706c65
+nonce:
+87499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c28aa7d3a9df
+blind: 1f659584626ba15f44f3d887b2e5fe4c27315b185dfbfaea4253ebba30
+610c4d9b73c78714c142360e85a00942c0fcff
+token_request: 0001c8024610a9f3aac21090f3079d6809437a2b94b4403c7e
+645f849bc6c505dade154c258c8ecd4d2bdcf574daca65db671908
+token_response: 03c2ab925d03e7793b4a4df6eb505210139f620359e142449
+1b8143c06a3e5298b25b662c33256411be7277233e1a34570f7a4d142d931e4b5
+ff8829e27aaf7eb2cc7f9ab655477d71c01d5da5aef44dd076b5820b4710ef025
+a9e6c6b50a95af6105c5987c1b834d615008cf6370556ed00c6671e69776c09a9
+2b5ac84804750dd867c78817bdf69f1443002b18ae7a52
+token: 000187499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c2
+8aa7d3a9df1949fd455872478ba87e2e6c513c3261cddbe57220581245e4c9c91
+1dd1c0bb865785bff8f3cfe08cccbb3a7b8e41d23a172871be4828cc54582d87b
+c7cfc5c8bcedc1868ebc845b000c317ed75312274a42b10be6db23bd8a168fd2f
+021c23925d72c4d14cd7588c03845da0d41a326
+
+// Test vector 4
+skS: 22e237b7b983d77474e4495aff2fc1e10422b1d955192e0fbf2b7b618fba
+625fcb94b599da9113da49c495a48fbf7f7f
+pkS: 028cd68715caa20d19b2b20d017d6a0a42b9f2b0a47db65e5e763e23744f
+e14d74e374bbc93a2ec3970eb53c8aa765ee21
+token_challenge: 0001000e6973737565722e6578616d706c65000000
+nonce:
+02f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a89e820cd43
+blind: af91d1dbcf6b46baecde70eb305b8fe75629199cca19c7f9344b8607b9
+0def27bc53e0345ade32c9fd0a1efda056d1c0
+token_request: 0001a503632ebb003ed15b6de4557c047c7f81a58688143331
+2ad3ad7f9416f2dfc940d3f439ad1e8cd677d94ae7c05bc958d134
+token_response: 032018bc3f180d9650e27f72de76a90b47e336ae9cb058548
+d851c7046fa0875d96346c15cb39d8083cc6fb57216544c6a815c37d792769e12
+9c0513ce2034c3286cb212548f4aed1b0f71b28e219a71874a93e53ab2f473282
+71d1e9cbefc197a4f599a6825051fa1c6e55450042f04182b86c9cf12477a9f16
+849396c051fa27012e81a86e6c4a9204a063f1e1722dd7
+token: 000102f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a
+89e820cd43085cb06952044c7655b412ab7d484c97b97c48c79c568140b8d49a0
+2ca47a9cfb0a5cfb861290c4dbd8fd9b60ee9b1a1a54cf47c98531fe253f1ed6d
+875de5a58f42db12b540b0d11bc5d6b42e6d17c2b73e98631e54d40fd2901ebec
+4268668535b03cbf76f7f15a29d623a64cab0c4
+
+// Test vector 5
+skS: 46f3d4f562002b85ffcfdb4d06835fb9b2e24372861ecaa11357fd1f29f9
+ed26e44715549ccedeb39257f095110f0159
+pkS: 02fbe9da0b7cabe3ec51c36c8487b10909142b59af030c728a5e87bb3b30
+f54c06415d22e03d9212bd3d9a17d5520d4d0f
+token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc
+daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b30000
+nonce:
+9ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e84483c90e89
+blind: 76e0938e824b6cda6c163ff55d0298d539e222ed3984f4e31bbb654a8c
+59671d4e0a7e264ca758cd0f4b533e0f60c5aa
+token_request: 0001e10202bc92ac516c867f39399d71976018db52fcab5403
+f8534a65677ba9e1e7d9b1d01767d137884c86cf5fe698c2f5d8e9
+token_response: 0322ea3856a71533796393229b33d33c02cd714e40d5aa4e0
+71f056276f32f89c09947eca8ff119d940d9d57c2fcbd83d2da494ddeb37dc1f6
+78e5661a8e7bcc96b3477eb89d708b0ce10e0ea1b5ce0001f9332f743c0cc3d47
+48233fea6d3152fae7844821268eb96ba491f60b1a3a848849310a39e9ef59121
+669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080
+token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8
+4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8
+7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca
+1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c
+d24504fe4f6c52d24ac901471267d8b63b61e6b
+
+
+
+
+
+
+

+B.2. Issuance Protocol 2 - Blind RSA, 2048 +

+

The test vector below lists the following values:

+
    +
  • +

    skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for signing tokens, +represented as a hexadecimal string.

    +
    • +
  • +

    pkS: The Issuer Public Key, serialized according to the encoding in Section 8.2.2.

    +
    • +
  • +

    token_challenge: A randomly generated TokenChallenge structure, represented +as a hexadecimal string.

    +
    • +
  • +

    nonce: The 32-byte client nonce generated according to Section 6.1, +represented as a hexadecimal string.

    +
    • +
  • +

    blind: The blind used when computing the blind RSA blinded message, +represented as a hexadecimal string.

    +
    • +
  • +

    salt: The randomly generated 48-byte salt used when encoding the blinded +token request message, represented as a hexadecimal string.

    +
    • +
  • +

    token_request: The TokenRequest message constructed according to +Section 6.1, represented as a hexadecimal string.

    +
    • +
  • +

    token_request: The TokenResponse message constructed according to +Section 6.2, represented as a hexadecimal string.

    +
    • +
  • +

    token: The output Token from the protocol, represented as a hexadecimal +string.

    +
    • +
+
+
+// Test vector 1
+skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
+4945765149424144414e42676b71686b6947397730424151454641415343424b6
+3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
+7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
+57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
+35743561496b3172417643655844644e44503442325055707851436e6969396e6
+b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
+6558563835464f314a752b62397336356d586d34516a755139455961497138337
+1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
+355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
+76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
+72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
+475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
+742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
+b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
+316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
+57266366336444373686c6c784c57535638477342737663386f364750320a6359
+366f777042447763626168474b556b5030456b62395330584c4a5763475347356
+1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
+644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
+f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
+414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
+264556851483856437872793251564d515751696e57684174364d7154340a5342
+5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
+3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
+784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
+a652f376b337946786b68305146333162713630654c393047495369414f0a354b
+4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
+9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
+306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
+e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
+7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
+8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
+77524e3632496f397463392b41434c745542377674476179332b6752775974534
+33262356564386c4969656774546b6561306830754453527841745673330a6e35
+6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
+0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
+77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
+e735170315947763977644a724d6156774a6376497077563676315570660a5674
+4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
+9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
+5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
+97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
+7844733968355272627852614e6673542b7241554837783153594456565159564
+d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
+6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
+2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
+31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
+86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
+77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
+0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
+4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
+0524956415445204b45592d2d2d2d2d0a
+pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
+03040202a11a301806092a864886f70d010108300b0609608648016503040202a
+2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
+25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
+b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
+0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
+53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
+32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
+1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
+e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
+babd612d03cad02db134b7e225a5f0203010001
+token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e
+393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e88000e6f72696
+7696e2e6578616d706c65
+nonce:
+aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd1508d07827f05
+blind: 425421de54c7381864ce36473abfb988c454fe6c27de863de702a6a2ad
+ca153fa2de47bd8fcd62734caa8ce1f920b77d980ab58c32d16dde54873f28ca9
+68e8c125b8363514be68972f553655bcc7f80a284cc327e47e804a47333c5b3cd
+f773312cc7ad9fda748aed0baa7e19c5a2d1dafda718f086d7fc0a4bc02d488e0
+f20812daee335af7177b7a8369bd617066aed7a58f659f295c36b418827f67972
+5b81ca14ea16fb82df21ad76da1ac38dcf24bf6252f8510e2308608ac9197f6cb
+54fdcb19db17837302a2b87d659c5605f35f3709a130f0c3d50e172f0cae36cbc
+9467f9914895a215a9e32443bcafff795273ccf8965a7eaa8c0b2184763e3e5c
+salt: 3d980852fa570c064204feb8d107098db976ef8c2137e8641d234bbd88a
+986fdb306a7af220cfadede08f51e1ef61766
+token_request: 0002086a95be84b63cfed0993bb579194a72a95057e1548ac4
+63a9a5b33b011f2b2011d59487f01862f1d8e4d5ea42e73a660fbc3d010b944a5
+4da3a4e0942f8894c0884589b438cb902e9a34278970f33c16f351f7dae58d273
+c3ab66ef368da36f785e89e24d1d983d5c34311cd21f290f9e89e8646ab0d0a48
+988fcd46230de5e7603cd12cc95c7ec5002e5e26737aa7eb69c626476e6c8d465
+10ee404a3d7daf3a23b7c66735d363ca13676925c6ed0117f60d165ce1f8ba616
+d041b6384baf6da3e2f757cb18e879a4f8595c2dc895ddf1f4279c75768d108b5
+c47f95f94e81e2d8b9c8b74476924ab3b7c45243fc99ac5466e8a3680ad37fa15
+c96010b274094
+token_response: 675d84b751d9e593330ec4b6d7ab69c9a61517e98971f4b73
+6150508174b4335761464f237be2d72bbae4b94dffc6143413f6351f1aa4efde6
+c32d4d6d9392a008290d56d1222f9b77a1336213e01934f7d972f3bf9ea5a5786
+c321352f103b3667e605379a55f0fb925fbb09b8a9f85e7dd4b388a3b49d06fd7
+0ba28f6a780e3bc8f6421554fd6c38b63ef19f84ccfcf14709dd0b4d72213c1f0
+60893854eba0ea1a147e275da320db5e9849882d5f9179efa8a2d8d3b803f9d14
+45ef5c1f660be08883ce9b29a0a992fc035d2938cbb61c440044438dbb8b3ce71
+58a8f9827d230482f622d291406ab236b32b122627ae0fd36bd0d6b7607b8044a
+ce404d44
+token: 0002aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd150
+8d07827f055969f643b4cfda5196d4aa86aeb5368834f4f06de46950ed435b3b8
+1bd036d44ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
+71cd2708bc6a21b533d07294b5e900faf5537dd3eb33cee4e08c9670d1e5358fd
+184b0e00c637174f5206b14c7bb0e724ebf6b56271e5aa2ed94c051c4a433d302
+b23bc52460810d489fb050f9de5c868c6c1b06e3849fd087629f704cc724bc0d0
+984d5c339686fcdd75f9a9cdd25f37f855f6f4c584d84f716864f546b696d620c
+5bd41a811498de84ff9740ba3003ba2422d26b91eb745c084758974642a420782
+01543246ddb58030ea8e722376aa82484dca9610a8fb7e018e396165462e17a03
+e40ea7e128c090a911ecc708066cb201833010c1ebd4e910fc8e27a1be467f786
+71836a508257123a45e4e0ae2180a434bd1037713466347a8ebe46439d3da1970
+
+// Test vector 2
+skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
+4945765149424144414e42676b71686b6947397730424151454641415343424b6
+3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
+7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
+57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
+35743561496b3172417643655844644e44503442325055707851436e6969396e6
+b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
+6558563835464f314a752b62397336356d586d34516a755139455961497138337
+1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
+355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
+76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
+72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
+475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
+742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
+b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
+316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
+57266366336444373686c6c784c57535638477342737663386f364750320a6359
+366f777042447763626168474b556b5030456b62395330584c4a5763475347356
+1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
+644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
+f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
+414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
+264556851483856437872793251564d515751696e57684174364d7154340a5342
+5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
+3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
+784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
+a652f376b337946786b68305146333162713630654c393047495369414f0a354b
+4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
+9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
+306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
+e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
+7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
+8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
+77524e3632496f397463392b41434c745542377674476179332b6752775974534
+33262356564386c4969656774546b6561306830754453527841745673330a6e35
+6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
+0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
+77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
+e735170315947763977644a724d6156774a6376497077563676315570660a5674
+4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
+9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
+5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
+97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
+7844733968355272627852614e6673542b7241554837783153594456565159564
+d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
+6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
+2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
+31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
+86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
+77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
+0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
+4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
+0524956415445204b45592d2d2d2d2d0a
+pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
+03040202a11a301806092a864886f70d010108300b0609608648016503040202a
+2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
+25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
+b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
+0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
+53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
+32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
+1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
+e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
+babd612d03cad02db134b7e225a5f0203010001
+token_challenge: 0002000e6973737565722e6578616d706c6500000e6f7269
+67696e2e6578616d706c65
+nonce:
+98c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873d90e84488d
+blind: 7bb85f89c9b83a0e2b02938b3396f06f8f3df0018a91f1a2cc5416aaa5
+52994d063f634d50bea13bffe8d5e01431e646e2e384549cefd695ac3affff665
+a1ebf0113df2520006bd66e468d37a58266daa8a3a75692535e1fc46d0c1d6fb6
+f37c949808172e20c0b77a48570a1fcb474325bdd23cdbce52b5d6a9e39f7aec7
+3b09004eae8c8bfff2b4b533ea63bcf467a4cd95ccfb0cb4e43bc4992c1fd0be7
+a77a4475dbf8094cf25125ece901abbcea607a9050ad9f8ec3d0d66341f6eab40
+ee9c9c22c0b560b8377f8543d8878c7458885fd285c7556cc88fc6021617075b4
+2c83a86005169a6f13352e789b28fdbbe3d0288e1dd7c801497573893146aea3
+salt: b6b4378421ab0ea677ce3f4036fd0489dee458ad81ea519c3e8bde3fcd5
+ec1505d28e110d7b44dcac5e04ecedd54d11a
+token_request: 00020892d26a271c0104657ba10c0b5cb2827bb209d86e8002
+7f96bfb861e0f40cb897f0fc426498433141ce9bc8b4a95914fefe4e40bdd3802
+a121cb0b59a4ae7e03255275c4abf071d991c82ead402606c0ef912178b0a0f68
+d303e06a966079230592827b84979dbcb5f21ab8904e9908638ddf705c4f8af8a
+053c19a66090726b60c6b4063976e4c66eab33522dd3f9d64828441db4aa82d55
+adcc3d3920592884cd1e5a3f490d5c81f1306705dcc5c61d82373f1dbd7d2ae4b
+2fea0f7339f5d868415f59312766e3074ee4a7305f5f053da82673ee6747a727a
+26d8d10ea1b1a3491d26b0c38b962c02a774ac78932153aae9dcc98a9b1db1f53
+89644682f7727
+token_response: 113a5124c1aef6fc230d9fc42b789226f45ca941aad4da3f4
+8cf37c7744a8d7fd1dcfd71cd39d09e9324760180ea0bade3360efaf7322a1fa1
+5f41247be3857fde8c5c92ec6d67a7ee33be8fdadf8b27bb0db706117448e55bc
+e9927cb6bfb1f87f9edb054181a4558af0c0d3973d7033b9599e674c20cf08a7b
+bcf0da815a2edaab7c4fb80dee4ea2cc53576a9691e857da931c6c592d2c69dd2
+1afda8ea653dd90157adfe80e2375c08e75beb497df8b7b73192fbbd4e80359d9
+bbaecea14e0acebdda92596f71ec1d57e26b6497b3152976bc07a4409148cb843
+89eb207fb8e841106012408c6e19b4f964008b6a909aaab767a661a061c97da16
+43040455
+token: 000298c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873
+d90e84488d11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2
+b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
+71cd27083350a206c5e9b7c0898f97611ce0bb8d74d310bb194ab67e094e32ff6
+da90886924b1b9e7b569402c1101d896d2fc3a7371ef77f02310db1dc9f81c853
+5828c2d0e9d9051720d182cd54e1c2c3bf417da2fc7aa72bb70ccc834ef274a2e
+809c9821b3d395d6535423f7428b3f29175d6eb840b4b7685336e57e2b6afeaab
+c0c17ea4f557e8a9cc2f624e245c6ccd7cbdd6c32c97c5c6974e802f688e2d25f
+0aba4215f609f692244517d5d3407e0172273982c001c158f5fcbe1b5d2447c26
+a87e89f5a9e72b498b0c59ce749823d2cf253d3cf6cd4e64fa0e434d95e488789
+247a9ceed756ff4ff33a8d2402c0db381236d331092838b608a42002552092897
+
+// Test vector 3
+skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
+4945765149424144414e42676b71686b6947397730424151454641415343424b6
+3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
+7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
+57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
+35743561496b3172417643655844644e44503442325055707851436e6969396e6
+b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
+6558563835464f314a752b62397336356d586d34516a755139455961497138337
+1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
+355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
+76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
+72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
+475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
+742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
+b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
+316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
+57266366336444373686c6c784c57535638477342737663386f364750320a6359
+366f777042447763626168474b556b5030456b62395330584c4a5763475347356
+1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
+644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
+f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
+414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
+264556851483856437872793251564d515751696e57684174364d7154340a5342
+5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
+3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
+784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
+a652f376b337946786b68305146333162713630654c393047495369414f0a354b
+4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
+9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
+306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
+e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
+7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
+8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
+77524e3632496f397463392b41434c745542377674476179332b6752775974534
+33262356564386c4969656774546b6561306830754453527841745673330a6e35
+6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
+0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
+77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
+e735170315947763977644a724d6156774a6376497077563676315570660a5674
+4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
+9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
+5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
+97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
+7844733968355272627852614e6673542b7241554837783153594456565159564
+d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
+6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
+2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
+31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
+86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
+77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
+0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
+4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
+0524956415445204b45592d2d2d2d2d0a
+pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
+03040202a11a301806092a864886f70d010108300b0609608648016503040202a
+2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
+25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
+b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
+0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
+53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
+32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
+1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
+e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
+babd612d03cad02db134b7e225a5f0203010001
+token_challenge: 0002000e6973737565722e6578616d706c65000017666f6f
+2e6578616d706c652c6261722e6578616d706c65
+nonce:
+9e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af1592df0e71
+blind: c52cabc5e4e131e0f5860cc4c486c5ee8a5fa8ae59484446121f87b0d8
+ccd037f161a99ebcc57f79d05a2ffc852656ad2d0894fab8d1b0f998e6e678254
+ed5778da98b137371320314d06c24276e35435bccffa49d257687f270f9ce1792
+6a074737546d5415a4bb9e624a6302562b395856632efb6992f6593a4f95fb342
+002efebc3046ca96bbc26edb2f1a1454a24ce7b9a7ec8e44fb9e99c8144d409d8
+cd8a5903c0a3c0acbd9f82573ed1fc4a296e3eaf4867ade30110794678f422d36
+bd103ea4617d2472cf58da3381e52e5be60f4acbf685e280648cef21211a796ec
+d005ecbdaa1046c40950afca4c4e7dd4b8c19e504088489a15667b45895b6e92
+salt: c847b5d0fa9101a1e09954ac9f3eed6600af58936295ad2e54274e13e64
+0d59f732d07530c94c19c20668f03470c77ac
+token_request: 0002080f6bd84fba1822c577c8cd670f1136cca107f84ddd9d
+405d5ed22ad15da975538f031433bad4a2688999732927efe2928d4c132389a12
+2f40b639b083d6fcbbed7a55fb18db536d2dcbaefe6dc0a70730e6565b08a7dfd
+783913a59f37d798de0cfc262c9e90a7ee884a3ec355eacbd44e5f6779fea6a78
+5b05ac352fdd51a116cf2be1d8e38b0bfacd6a3d53a88c99f747cce908f86b335
+62691f540e3e88562092cd17cc2f78ce0fb53312a5f2dc918bdb1dc90d9d65091
+c7ba9080ccc1755cb5437989364dc92f0e8fea18f66d631451feb02a3d68af41d
+e1a3f9be925dda5c4ca0706fc4ca28b3317e939f6573442c6d03be17cd141fa82
+60d382d134c6b
+token_response: 2dd08ce89cf4f62bc236ab7b75266e13c57c750345e328e0b
+ea107537c4cbeea5bfc990716950440628ea2e37dbc5c9c6d84f9a965cbf0cbff
+fb89516b1fd19a90d69cc52a28890bbdcf782f56aefadad85b6e861a74170ce91
+0891c89e4293f37978dbd41cc8b5c68802de3d86d9f0326b9c22b809512245896
+6a6ddd1aeb3828d239c3b359efc9b375390eb19050d5656c2b084304d9bd8a816
+14f631bf82a7e4588413b44a0cb6d94e942fa134790b396cb71e3ed33b557b5bd
+0734e726fa79abdca8694703b81d0e289b749801d4383e0d4f825dcde0dd98c43
+d3ba81c028dd8833a4fc24961f60e118d4421dce5b611d53e9ca96156a52509bf
+a9afeb7e
+token: 00029e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af
+1592df0e710042eee45ac4dd5acb8f6e65c4d8dd47504f73f7463507ef96a4d72
+27d2774f3ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
+71cd270815b010bbc0d5f55e9c856d2e9ffaefba007d33c2d5452fbeb0b15919b
+973e0dc9180aaeb18242043758d9fb0ac9ac5e04da9ff74ec93644ae6cdb7068e
+a76ce2295b9b95e383ed3a9856e9f618dafdf4cec5d2b53ea4297c2f3990babca
+71e3ccd6c07a437daae7ed27b6b81178fb7ce5fa5dd63781cc64ac1e410f441c0
+34b0a5cc873a2ce875e8b38c92bab563635c4f8f4fa35d1f582ef19edf7da75aa
+11a503a82e32a12bd4da41e0ca7ec7f451caf586f5b910003fcbbb9ff5ffa2408
+c28d6807737d03da651ea9bfafcc2747a6830e19a1d160fcd5c25d2f79dad86a8
+b3de8e926e08ca1addced72977f7b56398ef59c26e725df0a976a08f2a936ca42
+
+// Test vector 4
+skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
+4945765149424144414e42676b71686b6947397730424151454641415343424b6
+3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
+7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
+57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
+35743561496b3172417643655844644e44503442325055707851436e6969396e6
+b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
+6558563835464f314a752b62397336356d586d34516a755139455961497138337
+1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
+355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
+76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
+72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
+475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
+742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
+b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
+316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
+57266366336444373686c6c784c57535638477342737663386f364750320a6359
+366f777042447763626168474b556b5030456b62395330584c4a5763475347356
+1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
+644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
+f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
+414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
+264556851483856437872793251564d515751696e57684174364d7154340a5342
+5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
+3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
+784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
+a652f376b337946786b68305146333162713630654c393047495369414f0a354b
+4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
+9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
+306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
+e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
+7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
+8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
+77524e3632496f397463392b41434c745542377674476179332b6752775974534
+33262356564386c4969656774546b6561306830754453527841745673330a6e35
+6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
+0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
+77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
+e735170315947763977644a724d6156774a6376497077563676315570660a5674
+4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
+9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
+5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
+97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
+7844733968355272627852614e6673542b7241554837783153594456565159564
+d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
+6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
+2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
+31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
+86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
+77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
+0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
+4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
+0524956415445204b45592d2d2d2d2d0a
+pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
+03040202a11a301806092a864886f70d010108300b0609608648016503040202a
+2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
+25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
+b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
+0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
+53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
+32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
+1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
+e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
+babd612d03cad02db134b7e225a5f0203010001
+token_challenge: 0002000e6973737565722e6578616d706c65000000
+nonce:
+494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c45340bfe8e6
+blind: 097cb17bcedecfe058dff5c4e517d1e36d7ab8f46252b1ac1933ba378c
+32625c0dbc69f5655c2003bf39e75810796cd63675b223cf3162c57108d56e058
+4cfce6cad829e74369ada38a095eb3012c912b31ccde7425f93464e353fb17552
+be3a8df2913daca61543a33ae45058f218c471dfbc12fb304158e29b6ed35bc07
+9e23f1e6173c5dec4545840bbe58e5ad37cbea0a10dca5d9df2781589d27c3410
+8477b52c0d32a1370c17f703941fbb1a007a6794e7de2758709c9bbf80f21eec7
+922b9bb491eb6aac8c1a14764e648e6be4fff0ae913797067aa0826f366c3103e
+103b05653c73b52d7f825a185dccfb806da700db9f53abb848554b7d4f7c28f3
+salt: 49912979f1bf528e5b8228ab1328df74319dce7bdaf45821ceb1100dcf0
+42a2dfe852fc9db59b64a5f6493c282504240
+token_request: 000208244840027ca8c620f8b14caded9a198ba388ccd8541e
+962f68a0071535d958d18494afd0bc11da4da8c8b33864f5a8f623b697cd56348
+594e11a75479048a72c0ed179b070506c09a7eb6ed3582f572df38cf60fcde11a
+52c5ce6d7b23435b60200ad9f66d21f40f323c9aa54307d0b966d4457c37542b6
+6bb183ddeafca914fc74831698b5d52f498ee3d165685f49a8d86e39fe6c4b7ec
+678f5250908d25e5b873c69b422368121aa4210cadd6fc640907d3cb9a7a3e827
+a0e742470f00c2f49dc6c0e8cc9470dbfd73df0ccbb96c10b02af0dd7dee719ec
+a11ff8e1b4929e59f3cf319de9bda29a6d968b43083b5d4242f3448d76ada08b8
+014f70b97e719
+token_response: c2746ff644cffb28a2c19395fa19dfb61fd135daa837844fb
+f9fbe06c253e64e69f53aefddc0fb4833b1b5e58f571134a34f245499c3e73419
+549c2c9111cf94f2f68fea3996d47f71e8d8d6fc5b1c074bf74fa59de4cbf32f5
+f08d45ea45492f0279c3b1a8d852698edbe1651eb8e09eb223a27386c0feb2f6a
+8260235edb36cf433da518100829b63166284b325d87fc941ea3bafe7b6761b70
+82e09397837f74b4f0fc838bce8af7242089dd5561f57735926bcbad219fc9fee
+85ae49a8e8951f63ca194b7ff018c06ee02267e7267bb996432dc76973819da80
+e3e86947b0a4b36d3a972dafaaa3db0e1044b325f02c679996d9bcd3ce51390d5
+4bc10b8c
+token: 0002494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c4
+5340bfe8e6b741ec1b6fd05f1e95f8982906aec1612896d9ca97d53eef94ad3c9
+fe023f7a4ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
+71cd2708a55c83dc04292b5d92add1a87b37e54f22f61c58840586f390c50b231
+824423378ddcf50e69dc817d45bfad06c7f2a0ac35d2acd7f26b0bc9954c192b0
+a0ef28a2a5650e390098dd3cb1166a7cb1716d3dd2d19dc5ca3b1ea6206359de0
+002d82bc4fa7e69fb07214b06addcbd2203d1e17f57fc580bcc5a13e0ac15cf94
+2182cc2b5d6eaa737a712704114e357e2ec2f10047463ded02a1a0766dc346dd7
+212b9711e03ac95eb258ac1164104dc9a0d3e738ae742ab5ed8c5139fc07145a7
+88b9f891741ee68f0a66782b7b84a9bb4cb4b3d1b26b67106f397b35b641d882d
+7b0185168946de898ef72349a44a47dbdd6d46e9ba9ba543d5701b65c63d645c2
+
+// Test vector 5
+skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
+4945765149424144414e42676b71686b6947397730424151454641415343424b6
+3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
+7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
+57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
+35743561496b3172417643655844644e44503442325055707851436e6969396e6
+b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
+6558563835464f314a752b62397336356d586d34516a755139455961497138337
+1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
+355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
+76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
+72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
+475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
+742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
+b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
+316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
+57266366336444373686c6c784c57535638477342737663386f364750320a6359
+366f777042447763626168474b556b5030456b62395330584c4a5763475347356
+1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
+644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
+f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
+414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
+264556851483856437872793251564d515751696e57684174364d7154340a5342
+5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
+3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
+784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
+a652f376b337946786b68305146333162713630654c393047495369414f0a354b
+4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
+9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
+306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
+e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
+7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
+8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
+77524e3632496f397463392b41434c745542377674476179332b6752775974534
+33262356564386c4969656774546b6561306830754453527841745673330a6e35
+6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
+0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
+77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
+e735170315947763977644a724d6156774a6376497077563676315570660a5674
+4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
+9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
+5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
+97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
+7844733968355272627852614e6673542b7241554837783153594456565159564
+d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
+6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
+2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
+31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
+86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
+77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
+0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
+4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
+0524956415445204b45592d2d2d2d2d0a
+pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
+03040202a11a301806092a864886f70d010108300b0609608648016503040202a
+2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
+25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
+b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
+0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
+53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
+32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
+1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
+e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
+babd612d03cad02db134b7e225a5f0203010001
+token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e
+393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e880000
+nonce:
+a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f63143cd43a3
+blind: ad7a32e1ac31b91daefd7042cc23d5621ab3e870d87297bbfe1ee8a518
+ffc5b84770d3b77775c485b2d219954834868842d2f11877ac4bceb5da88944cc
+a043a9afa52f9c9998a5dea7ab7c1f82662d0d327e29705a269ad221ae74a7c11
+72ff89c48997a9fda08886d3998bb538868396c0ace71d260cc71f768001939b2
+4d80d88979f0244a3dbc004eadfac81e138d430b9fa51c1aad21b957ff96b3123
+c91c2fff362a386f0f99a3f9fc906ca626fd9107648f87532b44c4fe3856ecae1
+f46d8ebf5d2f46e52034478e5e883015666574dd80bd5c036c4b55ebcc8b66068
+8d23944cc1932d075b559dcdc269fae3511761f71c113634e60d67accc8875fb
+salt: 35c04710ce866d879447b6230ce098a49e81be5c067881cce7bd5f92c1e
+5bd9b3c7d4d795cfad134fdfe916d735a624a
+token_request: 0002083d6495c72529bbc4f5c0b49e94e4561baec1ca638a93
+b2940ea9e37b838db7b1a91ec1f257d49b45c4f75119c2ab9eb5578541ad2b9ba
+c1bd627abc709097f503f83d98fed6dbeb615c3be9bf09cbf8ea25ea8026c1b8b
+a1c704ff516ed87c3d7d85342fd00111d8a80492d4b8fdbb092a282f74f13901e
+5edc1b3b02cfe24c950affe6130fbb57c1482d674db3c6944812ba081c2235a16
+d01eeec0932a8619d85732fc3e36179f0b50377bf9cb7a50ce3abeb3f31ed5f0f
+3deec7aae7290f5397cec61318357d652b029a0fda0f100a78e36c4ef56ba3779
+963e8745fdf4e347763c63d825836878e249833a0f4bd315392cc06ccca2c955e
+921efbc4f941d
+token_response: 8db727000018a98a2fe9fda8bbde5b8e9cedc31efbcaed695
+0eb1e0f8d9af9db632def52f74f07cdab304bbde40519080dd0388fb2b8900528
+b4791d2bca40aa2c2a6d1b92f010c1849bfb781cc813cc204855dd05e8a2dd31e
+a5220981b8ab6b008e153083dc8f594206440d66286fea9c21b56807be8655506
+ab7818bb9c8c69489dda56fe6390a5397268c8b5711f9d2df6f2584740cccf034
+5fd67f93f345426f33c078a0aceb90845df9eef74f6248d06c36d19e191da325b
+721ddc12ea78ed37b0c3b6170590536e3aee7eb0efc7d11a2c9d072a394f12ffa
+67ecf316c49efd8f31723b11fe46740636bd89ad4f7ef96bc38b2cb4916d9dc04
+ba1b2fc6
+token: 0002a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f6
+3143cd43a3bb8a8cf1c59e7a251358ed76fe0ccff61044bc79dd261f16020324d
+22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
+71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a
+9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26
+e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c
+c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81
+a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b
+a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273
+c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658
+5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23
+
+
+
+
+
+
+
+
+

+Authors' Addresses +

+
+
Sofía Celi
+
Brave Software
+
Lisbon
+
Portugal
+ +
+
+
Alex Davidson
+
Brave Software
+
Lisbon
+
Portugal
+ +
+
+
Steven Valdez
+
Google LLC
+ +
+
+
Christopher A. Wood
+
Cloudflare
+
101 Townsend St
+
+San Francisco,
+
United States of America
+ +
+
+
+ + + diff --git a/chris-wood-patch-7/draft-ietf-privacypass-protocol.txt b/chris-wood-patch-7/draft-ietf-privacypass-protocol.txt new file mode 100644 index 00000000..4163ab37 --- /dev/null +++ b/chris-wood-patch-7/draft-ietf-privacypass-protocol.txt @@ -0,0 +1,1868 @@ + + + + +Network Working Group S. Celi +Internet-Draft A. Davidson +Intended status: Standards Track Brave Software +Expires: 5 April 2024 S. Valdez + Google LLC + C. A. Wood + Cloudflare + 3 October 2023 + + + Privacy Pass Issuance Protocol + draft-ietf-privacypass-protocol-latest + +Abstract + + This document specifies two variants of the two-message issuance + protocol for Privacy Pass tokens: one that produces tokens that are + privately verifiable using the issuance private key, and another that + produces tokens that are publicly verifiable using the issuance + public key. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 5 April 2024. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Protocol Overview + 4. Configuration + 5. Issuance Protocol for Privately Verifiable Tokens + 5.1. Client-to-Issuer Request + 5.2. Issuer-to-Client Response + 5.3. Finalization + 5.4. Token Verification + 5.5. Issuer Configuration + 6. Issuance Protocol for Publicly Verifiable Tokens + 6.1. Client-to-Issuer Request + 6.2. Issuer-to-Client Response + 6.3. Finalization + 6.4. Token Verification + 6.5. Issuer Configuration + 7. Security considerations + 8. IANA considerations + 8.1. Well-Known 'private-token-issuer-directory' URI + 8.2. Token Type Registry Updates + 8.2.1. Token Type VOPRF (P-384, SHA-384) + 8.2.2. Token Type Blind RSA (2048-bit) + 8.3. Media Types + 8.3.1. "application/private-token-issuer-directory" media type + 8.3.2. "application/private-token-request" media type + 8.3.3. "application/private-token-response" media type + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. Acknowledgements + Appendix B. Test Vectors + B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) + B.2. Issuance Protocol 2 - Blind RSA, 2048 + Authors' Addresses + +1. Introduction + + The Privacy Pass protocol provides a privacy-preserving authorization + mechanism. In essence, the protocol allows clients to provide + cryptographic tokens that prove nothing other than that they have + been created by a given server in the past [ARCHITECTURE]. + + This document describes the issuance protocol for Privacy Pass built + on [HTTP]. It specifies two variants: one that is privately + verifiable using the issuance private key based on the oblivious + pseudorandom function from [OPRF], and one that is publicly + verifiable using the issuance public key based on the blind RSA + signature scheme [BLINDRSA]. + + This document does not cover the Privacy Pass architecture, including + choices that are necessary for deployment and application specific + choices for protecting client privacy. This information is covered + in [ARCHITECTURE]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses the terms Origin, Client, Issuer, and Token as + defined in Section 2 of [ARCHITECTURE]. Moreover, the following + additional terms are used throughout this document. + + * Issuer Public Key: The public key (from a private-public key pair) + used by the Issuer for issuing and verifying Tokens. + + * Issuer Private Key: The private key (from a private-public key + pair) used by the Issuer for issuing and verifying Tokens. + + Unless otherwise specified, this document encodes protocol messages + in TLS notation from Section 3 of [TLS13]. Moreover, all constants + are in network byte order. + +3. Protocol Overview + + The issuance protocols defined in this document embody the core of + Privacy Pass. Clients receive TokenChallenge inputs from the + redemption protocol ([AUTHSCHEME], Section 2.1) and use the issuance + protocols to produce corresponding Token values ([AUTHSCHEME], + Section 2.2). The issuance protocol describes how Clients and + Issuers interact to compute a token using a one-round protocol + consisting of a TokenRequest from the Client and TokenResponse from + the Issuer. This interaction is shown below. + + +--------+ +--------+ +----------+ +--------+ + | Origin | | Client | | Attester | | Issuer | + +---+----+ +---+----+ +----+-----+ +---+----+ + | | | | + |<----- Request ------+ | | + +-- TokenChallenge -->| | | + | |<== Attestation ==>| | + | | | | + | +--------- TokenRequest ------->| + | |<-------- TokenResponse -------+ + |<-- Request+Token ---+ | | + | | | | + + Figure 1: Issuance Overview + + The TokenChallenge inputs to the issuance protocols described in this + document can be interactive or non-interactive, and per-origin or + cross-origin. + + The issuance protocols defined in this document are compatible with + any deployment model defined in Section 4 of [ARCHITECTURE]. The + details of attestation are outside the scope of the issuance + protocol; see Section 4 of [ARCHITECTURE] for information about how + attestation can be implemented in each of the relevant deployment + models. + + This document describes two variants of the issuance protocol: one + that is privately verifiable (Section 5) using the issuance private + key based on the oblivious pseudorandom function from [OPRF], and one + that is publicly verifiable (Section 6) using the issuance public key + based on the blind RSA signature scheme [BLINDRSA]. + +4. Configuration + + Issuers MUST provide two parameters for configuration: + + 1. Issuer Request URL: A token request URL for generating access + tokens. For example, an Issuer URL might be + https://issuer.example.net/request. + + 2. Issuer Public Key values: A list of Issuer Public Keys for the + issuance protocol. + + The Issuer parameters can be obtained from an Issuer via a directory + object, which is a JSON object ([RFC8259], Section 4) whose values + are other JSON values ([RFC8259], Section 3) for the parameters. The + contents of this JSON object are defined in Table 1. + + +====================+======================================+ + | Field Name | Value | + +====================+======================================+ + | issuer-request-uri | Issuer Request URL value (as an | + | | absolute URL, or a URL relative to | + | | the directory object) as a percent- | + | | encoded URL string, represented as a | + | | JSON string ([RFC8259], Section 7) | + +--------------------+--------------------------------------+ + | token-keys | List of Issuer Public Key values, | + | | each represented as JSON objects | + | | ([RFC8259], Section 4) | + +--------------------+--------------------------------------+ + + Table 1: Issuer directory object description + + Each "token-keys" JSON object contains the fields and corresponding + raw values defined in Table 2. + + +============+====================================================+ + | Field Name | Value | + +============+====================================================+ + | token-type | Integer value of the Token Type, as defined in | + | | Section 8.2, represented as a JSON number | + | | ([RFC8259], Section 6) | + +------------+----------------------------------------------------+ + | token-key | The base64url-encoded [RFC4648] Public Key for use | + | | with the issuance protocol as determined by the | + | | token-type field, including padding, represented | + | | as a JSON string ([RFC8259], Section 7) | + +------------+----------------------------------------------------+ + + Table 2: Issuer 'token-keys' object description' + + Each "token-keys" JSON object may also contain the optional field + "not-before". The value of this field is the UNIX timestamp (number + of seconds since January 1, 1970, UTC -- see Section 4.2.1 of + [TIMESTAMP]) at which the key can be used. If this field is present, + Clients SHOULD NOT use a token key before this timestamp, as doing so + can lead to issuance failures. The purpose of this field is to + assist in scheduled key rotations. + + Beyond staging keys with the "not-before" value, Issuers MAY + advertise multiple "token-keys" for the same token-type to facilitate + key rotation. In this case, Issuers indicate preference for which + token key to use based on the order of keys in the list, with + preference given to keys earlier in the list. Clients SHOULD use the + first key in the "token-keys" list that either does not have a "not- + before" value or has a "not-before" value in the past, since the + first such key is the most likely to be valid in the given time + window. Origins can attempt to use any key in the "token-keys" list + to verify tokens, starting with the most preferred key in the list. + Trial verification like this can help deal with Client clock skew. + + Altogether, the Issuer's directory could look like the following + (with the "token-key" fields abbreviated): + + { + "issuer-request-uri": "https://issuer.example.net/request", + "token-keys": [ + { + "token-type": 2, + "token-key": "MI...AB", + "not-before": 1686913811, + }, + { + "token-type": 2, + "token-key": "MI...AQ", + } + ] + } + + Clients that use this directory resource before 1686913811 in UNIX + time would use the second key in the "token-keys" list, whereas + Clients that use this directory after 1686913811 in UNIX time would + use the first key in the "token-keys" list. + + A complete "token-key" value, encoded as it would be in the Issuer + directory, would look like the following (line breaks are inserted to + fit within the per-line character limits): + +$ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDAL \ + BglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr_DhZAPhJM7 \ + Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTvW6SKCh7ZPXEqCGR \ + sq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWbjf21iaVjXJ2VdwdS-8O- \ + 430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuID9OQm1nxfs1Z4PhWBzt93T2oz \ + Tnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99aA-muXRFN4ZUwORrF7cAcCUD_-56_6 \ + fh9s34FmqBGwIDAQAB \ + | sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \ + | openssl asn1parse -dump -inform DER + 0:d=0 hl=4 l= 338 cons: SEQUENCE + 4:d=1 hl=2 l= 61 cons: SEQUENCE + 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss + 17:d=2 hl=2 l= 48 cons: SEQUENCE + 19:d=3 hl=2 l= 13 cons: cont [ 0 ] + 21:d=4 hl=2 l= 11 cons: SEQUENCE + 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 + 34:d=3 hl=2 l= 26 cons: cont [ 1 ] + 36:d=4 hl=2 l= 24 cons: SEQUENCE + 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 + 49:d=5 hl=2 l= 11 cons: SEQUENCE + 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 + 62:d=3 hl=2 l= 3 cons: cont [ 2 ] + 64:d=4 hl=2 l= 1 prim: INTEGER :30 + 67:d=1 hl=4 l= 271 prim: BIT STRING + ... truncated public key bytes ... + + Issuer directory resources have the media type "application/private- + token-issuer-directory" and are located at the well-known location + /.well-known/private-token-issuer-directory; see Section 8.1 for the + registration information for this well-known URI. The reason that + this resource is located at a well-known URI is that Issuers are + defined by an origin name in TokenChallenge structures; see + Section 2.1 of [AUTHSCHEME]. + + The Issuer directory and Issuer resources SHOULD be available on the + same origin. If an Issuer wants to service multiple different Issuer + directories they MUST create unique subdomains for each so the + TokenChallenge defined in Section 2.1 of [AUTHSCHEME] can be + differentiated correctly. + + Issuers SHOULD use HTTP cache directives to permit caching of this + resource [RFC5861]. The cache lifetime depends on the Issuer's key + rotation schedule. Regular rotation of token keys is recommended to + minimize the risk of key compromise and any harmful effects that + happen due to key compromise. + + Issuers can control cache lifetime with the Cache-Control header, as + follows: + + Cache-Control: max-age=86400 + + Consumers of the Issuer directory resource SHOULD follow the usual + HTTP caching [RFC9111] semantics when processing this resource. Long + cache lifetimes may result in use of stale Issuer configuration + information, whereas short lifetimes may result in decreased + performance. When use of an Issuer configuration results in token + issuance failures, e.g., because the Issuer has invalidated its + directory resource before its expiration time and issuance requests + using this configuration are unsuccessful, the directory SHOULD be + fetched and revalidated. Issuance will continue to fail until the + Issuer configuration is updated. + +5. Issuance Protocol for Privately Verifiable Tokens + + The privately verifiable issuance protocol allows Clients to produce + Token values that verify using the Issuer Private Key. This protocol + is based on the oblivious pseudorandom function from [OPRF]. + + Issuers provide a Issuer Private and Public Key, denoted skI and pkI + respectively, used to produce tokens as input to the protocol. See + Section 5.5 for how these keys are generated. + + Clients provide the following as input to the issuance protocol: + + * Issuer Request URL: A URL identifying the location to which + issuance requests are sent. This can be a URL derived from the + "issuer-request-uri" value in the Issuer's directory resource, or + it can be another Client-configured URL. The value of this + parameter depends on the Client configuration and deployment + model. For example, in the 'Joint Origin and Issuer' deployment + model, the Issuer Request URL might correspond to the Client's + configured Attester, and the Attester is configured to relay + requests to the Issuer. + + * Issuer name: An identifier for the Issuer. This is typically a + host name that can be used to construct HTTP requests to the + Issuer. + + * Issuer Public Key: pkI, with a key identifier token_key_id + computed as described in Section 5.5. + + * Challenge value: challenge, an opaque byte string. For example, + this might be provided by the redemption protocol in [AUTHSCHEME]. + + Given this configuration and these inputs, the two messages exchanged + in this protocol are described below. This section uses notation + described in [OPRF], Section 4, including SerializeElement and + DeserializeElement, SerializeScalar and DeserializeScalar, and + DeriveKeyPair. + + The constants Ne and Ns are as defined in [OPRF], Section 4 for + OPRF(P-384, SHA-384). The constant Nk, which is also equal to Nh as + defined in [OPRF], Section 4, is defined by Section 8.2.1. + +5.1. Client-to-Issuer Request + + The Client first creates a context as follows: + + client_context = SetupVOPRFClient("P384-SHA384", pkI) + + Here, "P384-SHA384" is the identifier corresponding to the + OPRF(P-384, SHA-384) ciphersuite in [OPRF]. SetupVOPRFClient is + defined in [OPRF], Section 3.2. + + The Client then creates an issuance request message for a random + 32-byte value nonce with the input challenge and Issuer key + identifier as described below: + + nonce = random(32) + challenge_digest = SHA256(challenge) + token_input = concat(0x0001, // Token type field is 2 bytes long + nonce, + challenge_digest, + token_key_id) + blind, blinded_element = client_context.Blind(token_input) + + The Blind function is defined in [OPRF], Section 3.3.2. If the Blind + function fails, the Client aborts the protocol. The Client stores + the nonce and challenge_digest values locally for use when finalizing + the issuance protocol to produce a token (as described in + Section 5.3). + + The Client then creates a TokenRequest structured as follows: + + struct { + uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ + uint8_t truncated_token_key_id; + uint8_t blinded_msg[Ne]; + } TokenRequest; + + The structure fields are defined as follows: + + * "token_type" is a 2-octet integer, which matches the type in the + challenge. + + * "truncated_token_key_id" is the least significant byte of the + token_key_id (Section 5.5) in network byte order (in other words, + the last 8 bits of token_key_id). This value is truncated so that + Issuers cannot use token_key_id as a way of uniquely identifying + Clients; see Section 7 and referenced information for more + details. + + * "blinded_msg" is the Ne-octet blinded message defined above, + computed as SerializeElement(blinded_element). + + The values token_input and blinded_element are stored locally and + used later as described in Section 5.3. The Client then generates an + HTTP POST request to send to the Issuer Request URL, with the + TokenRequest as the content. The media type for this request is + "application/private-token-request". An example request for the + Issuer Request URL "https://issuer.example.net/request" is shown + below. + + POST /request HTTP/1.1 + Host: issuer.example.net + Accept: application/private-token-response + Content-Type: application/private-token-request + Content-Length: + + + +5.2. Issuer-to-Client Response + + Upon receipt of the request, the Issuer validates the following + conditions: + + * The TokenRequest contains a supported token_type. + + * The TokenRequest.truncated_token_key_id corresponds to the + truncated key ID of a Public Key owned by the Issuer. + + * The TokenRequest.blinded_msg is of the correct size. + + If any of these conditions is not met, the Issuer MUST return an HTTP + 422 (Unprocessable Content) error to the client. + + If these conditions are met, the Issuer then tries to deserialize + TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of + [OPRF], yielding blinded_element. If this fails, the Issuer MUST + return an HTTP 422 (Unprocessable Content) error to the client. + Otherwise, if the Issuer is willing to produce a token to the Client, + the Issuer completes the issuance flow by computing a blinded + response as follows: + + server_context = SetupVOPRFServer("P384-SHA384", skI) + evaluate_element, proof = + server_context.BlindEvaluate(skI, pkI, blinded_element) + + SetupVOPRFServer is defined in [OPRF], Section 3.2 and BlindEvaluate + is defined in [OPRF], Section 3.3.2. The Issuer then creates a + TokenResponse structured as follows: + + struct { + uint8_t evaluate_msg[Ne]; + uint8_t evaluate_proof[Ns+Ns]; + } TokenResponse; + + The structure fields are defined as follows: + + * "evaluate_msg" is the Ne-octet evaluated message, computed as + SerializeElement(evaluate_element). + + * "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a + pair of Scalar values, computed as + concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])). + + The Issuer generates an HTTP response with status code 200 whose + content consists of TokenResponse, with the content type set as + "application/private-token-response". + + HTTP/1.1 200 OK + Content-Type: application/private-token-response + Content-Length: + + + +5.3. Finalization + + Upon receipt, the Client handles the response and, if successful, + deserializes the content values TokenResponse.evaluate_msg and + TokenResponse.evaluate_proof, yielding evaluated_element and proof. + If deserialization of either value fails, the Client aborts the + protocol. Otherwise, the Client processes the response as follows: + + authenticator = client_context.Finalize(token_input, blind, + evaluated_element, + blinded_element, + proof) + + The Finalize function is defined in [OPRF], Section 3.3.2. If this + succeeds, the Client then constructs a Token as follows: + + struct { + uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ + uint8_t nonce[32]; + uint8_t challenge_digest[32]; + uint8_t token_key_id[32]; + uint8_t authenticator[Nk]; + } Token; + + The Token.nonce value is that which was created in Section 5.1. If + the Finalize function fails, the Client aborts the protocol. + +5.4. Token Verification + + Verifying a Token requires creating a VOPRF context using the Issuer + Private Key and Public Key, evaluating the token contents, and + comparing the result against the token authenticator value: + + server_context = SetupVOPRFServer("P384-SHA384", skI) + token_authenticator_input = + concat(Token.token_type, + Token.nonce, + Token.challenge_digest, + Token.token_key_id) + token_authenticator = + server_context.Evaluate(token_authenticator_input) + valid = (token_authenticator == Token.authenticator) + +5.5. Issuer Configuration + + Issuers are configured with Issuer Private and Public Keys, each + denoted skI and pkI, respectively, used to produce tokens. These + keys MUST NOT be reused in other protocols. A RECOMMENDED method for + generating keys is as follows: + + seed = random(Ns) + (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") + + The DeriveKeyPair function is defined in [OPRF], Section 3.3.1. The + key identifier for a public key pkI, denoted token_key_id, is + computed as follows: + + token_key_id = SHA256(SerializeElement(pkI)) + + Since Clients truncate token_key_id in each TokenRequest, Issuers + SHOULD ensure that the truncated form of new key IDs do not collide + with other truncated key IDs in rotation. Collisions can cause the + Issuer to use the wrong Issuer Private Key for issuance, which will + in turn cause the resulting tokens to be invalid. There is no known + security consequence of using the the wrong Issuer Private Key. A + possible exception to this constraint would be a colliding key that + is still in use but in the process of being rotated out, in which + case the collision cannot reasonably be avoided but it is expected to + be transient. + +6. Issuance Protocol for Publicly Verifiable Tokens + + This section describes a variant of the issuance protocol in + Section 5 for producing publicly verifiable tokens using the protocol + in [BLINDRSA]. In particular, this variant of the issuance protocol + works for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384- + PSSZERO-Deterministic blind RSA protocol variants described in + Section 5 of [BLINDRSA]. + + The publicly verifiable issuance protocol differs from the protocol + in Section 5 in that the output tokens are publicly verifiable by + anyone with the Issuer Public Key. This means any Origin can select a + given Issuer to produce tokens, as long as the Origin has the Issuer + public key, without explicit coordination or permission from the + Issuer. This is because the Issuer does not learn the Origin that + requested the token during the issuance protocol. + + Beyond this difference, the publicly verifiable issuance protocol + variant is nearly identical to the privately verifiable issuance + protocol variant. In particular, Issuers provide an Issuer Private + and Public Key, denoted skI and pkI, respectively, used to produce + tokens as input to the protocol. See Section 6.5 for how these keys + are generated. + + Clients provide the following as input to the issuance protocol: + + * Issuer Request URL: A URL identifying the location to which + issuance requests are sent. This can be a URL derived from the + "issuer-request-uri" value in the Issuer's directory resource, or + it can be another Client-configured URL. The value of this + parameter depends on the Client configuration and deployment + model. For example, in the 'Split Origin, Attester, Issuer' + deployment model, the Issuer Request URL might correspond to the + Client's configured Attester, and the Attester is configured to + relay requests to the Issuer. + + * Issuer name: An identifier for the Issuer. This is typically a + host name that can be used to construct HTTP requests to the + Issuer. + + * Issuer Public Key: pkI, with a key identifier token_key_id + computed as described in Section 6.5. + + * Challenge value: challenge, an opaque byte string. For example, + this might be provided by the redemption protocol in [AUTHSCHEME]. + + Given this configuration and these inputs, the two messages exchanged + in this protocol are described below. The constant Nk is defined by + Section 8.2.2. + +6.1. Client-to-Issuer Request + + The Client first creates an issuance request message for a random + 32-byte value nonce using the input challenge and Issuer key + identifier as follows: + + nonce = random(32) + challenge_digest = SHA256(challenge) + token_input = concat(0x0002, // Token type field is 2 bytes long + nonce, + challenge_digest, + token_key_id) + blinded_msg, blind_inv = + Blind(pkI, PrepareIdentity(token_input)) + + The PrepareIdentity and Blind functions are defined in Section 4.1 of + [BLINDRSA] and Section 4.2 of [BLINDRSA], respectively. The Client + stores the nonce and challenge_digest values locally for use when + finalizing the issuance protocol to produce a token (as described in + Section 6.3). + + The Client then creates a TokenRequest structured as follows: + + struct { + uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ + uint8_t truncated_token_key_id; + uint8_t blinded_msg[Nk]; + } TokenRequest; + + The structure fields are defined as follows: + + * "token_type" is a 2-octet integer, which matches the type in the + challenge. + + * "truncated_token_key_id" is the least significant byte of the + token_key_id (Section 6.5) in network byte order (in other words, + the last 8 bits of token_key_id). This value is truncated so that + Issuers cannot use token_key_id as a way of uniquely identifying + Clients; see Section 7 and referenced information for more + details. + + * "blinded_msg" is the Nk-octet request defined above. + + The Client then generates an HTTP POST request to send to the Issuer + Request URL, with the TokenRequest as the content. The media type + for this request is "application/private-token-request". An example + request for the Issuer Request URL "https://issuer.example.net/ + request" is shown below. + + POST /request HTTP/1.1 + Host: issuer.example.net + Accept: application/private-token-response + Content-Type: application/private-token-request + Content-Length: + + + +6.2. Issuer-to-Client Response + + Upon receipt of the request, the Issuer validates the following + conditions: + + * The TokenRequest contains a supported token_type. + + * The TokenRequest.truncated_token_key_id corresponds to the + truncated key ID of an Issuer Public Key. + + * The TokenRequest.blinded_msg is of the correct size. + + If any of these conditions is not met, the Issuer MUST return an HTTP + 422 (Unprocessable Content) error to the Client. Otherwise, if the + Issuer is willing to produce a token to the Client, the Issuer + completes the issuance flow by computing a blinded response as + follows: + + blind_sig = BlindSign(skI, TokenRequest.blinded_msg) + + The BlindSign function is defined in Section 4.3 of [BLINDRSA]. The + result is encoded and transmitted to the client in the following + TokenResponse structure: + + struct { + uint8_t blind_sig[Nk]; + } TokenResponse; + + The Issuer generates an HTTP response with status code 200 whose + content consists of TokenResponse, with the content type set as + "application/private-token-response". + + HTTP/1.1 200 OK + Content-Type: application/private-token-response + Content-Length: + + + +6.3. Finalization + + Upon receipt, the Client handles the response and, if successful, + processes the content as follows: + + authenticator = + Finalize(pkI, nonce, blind_sig, blind_inv) + + The Finalize function is defined in Section 4.4 of [BLINDRSA]. If + this succeeds, the Client then constructs a Token as described in + [AUTHSCHEME] as follows: + + struct { + uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ + uint8_t nonce[32]; + uint8_t challenge_digest[32]; + uint8_t token_key_id[32]; + uint8_t authenticator[Nk]; + } Token; + + The Token.nonce value is that which was sampled in Section 5.1. If + the Finalize function fails, the Client aborts the protocol. + +6.4. Token Verification + + Verifying a Token requires checking that Token.authenticator is a + valid signature over the remainder of the token input using the + Issuer Public Key. The function RSASSA-PSS-VERIFY is defined in + Section 8.1.2 of [RFC8017], using SHA-384 as the Hash function, MGF1 + with SHA-384 as the PSS mask generation function (MGF), and a 48-byte + salt length (sLen). + + token_authenticator_input = + concat(Token.token_type, + Token.nonce, + Token.challenge_digest, + Token.token_key_id) + valid = RSASSA-PSS-VERIFY(pkI, + token_authenticator_input, + Token.authenticator) + +6.5. Issuer Configuration + + Issuers are configured with Issuer Private and Public Keys, each + denoted skI and pkI, respectively, used to produce tokens. Each key + SHALL be generated securely, for example as specified in FIPS 186-5 + [DSS]. These keys MUST NOT be reused in other protocols. + + The key identifier for an Issuer Private and Public Key (skI, pkI), + denoted token_key_id, is computed as SHA256(encoded_key), where + encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) + object carrying pkI as a DER-encoded RSAPublicKey value [RFC5756] in + the subjectPublicKey field. Additionally, the SPKI object MUST use + the id-RSASSA-PSS object identifier in the algorithm field within the + SPKI object, the parameters field MUST contain a RSASSA-PSS-params + value, and MUST include the hashAlgorithm, maskGenAlgorithm, and + saltLength values. The saltLength MUST match the output size of the + hash function associated with the public key and token type. + + An example sequence of the SPKI object (in ASN.1 format, with the + actual public key bytes truncated) for a 2048-bit key is below: + + $ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER + 0:d=0 hl=4 l= 338 cons: SEQUENCE + 4:d=1 hl=2 l= 61 cons: SEQUENCE + 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss + 17:d=2 hl=2 l= 48 cons: SEQUENCE + 19:d=3 hl=2 l= 13 cons: cont [ 0 ] + 21:d=4 hl=2 l= 11 cons: SEQUENCE + 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 + 34:d=3 hl=2 l= 26 cons: cont [ 1 ] + 36:d=4 hl=2 l= 24 cons: SEQUENCE + 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 + 49:d=5 hl=2 l= 11 cons: SEQUENCE + 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 + 62:d=3 hl=2 l= 3 cons: cont [ 2 ] + 64:d=4 hl=2 l= 1 prim: INTEGER :30 + 67:d=1 hl=4 l= 271 prim: BIT STRING + ... truncated public key bytes ... + + Since Clients truncate token_key_id in each TokenRequest, Issuers + SHOULD ensure that the truncated form of new key IDs do not collide + with other truncated key IDs in rotation. Collisions can cause the + Issuer to use the wrong Issuer Private Key for issuance, which will + in turn cause the resulting tokens to be invalid. There is no known + security consequence of using the the wrong Issuer Private Key. A + possible exception to this constraint would be a colliding key that + is still in use but in the process of being rotated out, in which + case the collision cannot reasonably be avoided but it is expected to + be transient. + +7. Security considerations + + This document outlines how to instantiate the Issuance protocol based + on the VOPRF defined in [OPRF] and blind RSA protocol defined in + [BLINDRSA]. All security considerations described in the VOPRF and + blind RSA documents also apply in the Privacy Pass use-case. + Considerations related to broader privacy and security concerns in a + multi-Client and multi-Issuer setting are deferred to the + architecture document [ARCHITECTURE]. In particular, Section 4 and + Section 5 of [ARCHITECTURE] discuss relevant privacy considerations + influenced by the Privacy Pass deployment model, and Section 6 of + [ARCHITECTURE] discusses privacy considerations that apply regardless + of deployment model. Notable considerations include those pertaining + to Issuer Public Key rotation and consistency, where consistency is + as described in [CONSISTENCY], and Issuer selection. + +8. IANA considerations + + This section contains considerations for IANA. + +8.1. Well-Known 'private-token-issuer-directory' URI + + This document updates the "Well-Known URIs" Registry [WellKnownURIs] + with the following values. + + +===============+============+===========+===========+=============+ + | URI Suffix | Change | Reference | Status | Related | + | | Controller | | | information | + +===============+============+===========+===========+=============+ + | private- | IETF | [this | permanent | None | + | token-issuer- | | document] | | | + | directory | | | | | + +---------------+------------+-----------+-----------+-------------+ + + Table 3: 'private-token-issuer-directory' Well-Known URI + +8.2. Token Type Registry Updates + + This document updates the "Privacy Pass Token Type" Registry with the + following entries. + +8.2.1. Token Type VOPRF (P-384, SHA-384) + + * Value: 0x0001 + + * Name: VOPRF (P-384, SHA-384) + + * Token Structure: As defined in Section 2.2 of [AUTHSCHEME] + + * Token Key Encoding: Serialized using SerializeElement from + Section 2.1 of [OPRF] + + * TokenChallenge Structure: As defined in Section 2.1 of + [AUTHSCHEME] + + * Public Verifiability: N + + * Public Metadata: N + + * Private Metadata: N + + * Nk: 48 + + * Nid: 32 + + * Reference: Section 5 + + * Notes: None + +8.2.2. Token Type Blind RSA (2048-bit) + + * Value: 0x0002 + + * Name: Blind RSA (2048-bit) + + * Token Structure: As defined in Section 2.2 of [AUTHSCHEME] + + * Token Key Encoding: Serialized as a DER-encoded + SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID + [RFC5756] + + * TokenChallenge Structure: As defined in Section 2.1 of + [AUTHSCHEME] + + * Public Verifiability: Y + + * Public Metadata: N + + * Private Metadata: N + + * Nk: 256 + + * Nid: 32 + + * Reference: Section 6 + + * Notes: The RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384- + PSSZERO-Deterministic variants are supported + +8.3. Media Types + + The following entries should be added to the IANA "media types" + registry: + + * "application/private-token-issuer-directory" + + * "application/private-token-request" + + * "application/private-token-response" + + The templates for these entries are listed below and the reference + should be this RFC. + +8.3.1. "application/private-token-issuer-directory" media type + + Type name: application + Subtype name: private-token-issuer-directory + Required parameters: N/A + Optional parameters: N/A + Encoding considerations: "binary" + Security considerations: see Section 4 + Interoperability considerations: N/A + Published specification: this specification + Applications that use this media type: Services that implement the + Privacy Pass issuer role, and client applications that interact + with the issuer for the purposes of issuing or redeeming tokens. + Fragment identifier considerations: N/A + Additional information: Magic number(s): N/A + Deprecated alias names for this type: N/A + File extension(s): N/A + Macintosh file type code(s): N/A + Person and email address to contact for further information: see Aut + hors' Addresses section + Intended usage: COMMON + Restrictions on usage: N/A + Author: see Authors' Addresses section + Change controller: IETF + +8.3.2. "application/private-token-request" media type + + Type name: application + Subtype name: private-token-request + Required parameters: N/A + Optional parameters: N/A + Encoding considerations: "binary" + Security considerations: see Section 7 + Interoperability considerations: N/A + Published specification: this specification + Applications that use this media type: Applications that want to + issue or facilitate issuance of Privacy Pass tokens, including + Privacy Pass issuer applications themselves. + Fragment identifier considerations: N/A + Additional information: Magic number(s): N/A + Deprecated alias names for this type: N/A + File extension(s): N/A + Macintosh file type code(s): N/A + Person and email address to contact for further information: see Aut + hors' Addresses section + Intended usage: COMMON + Restrictions on usage: N/A + Author: see Authors' Addresses section + Change controller: IETF + +8.3.3. "application/private-token-response" media type + + Type name: application + Subtype name: private-token-response + Required parameters: N/A + Optional parameters: N/A + Encoding considerations: "binary" + Security considerations: see Section 7 + Interoperability considerations: N/A + Published specification: this specification + Applications that use this media type: Applications that want to + issue or facilitate issuance of Privacy Pass tokens, including + Privacy Pass issuer applications themselves. + Fragment identifier considerations: N/A + Additional information: Magic number(s): N/A + Deprecated alias names for this type: N/A + File extension(s): N/A + Macintosh file type code(s): N/A + Person and email address to contact for further information: see Aut + hors' Addresses section + Intended usage: COMMON + Restrictions on usage: N/A + Author: see Authors' Addresses section + Change controller: IETF + +9. References + +9.1. Normative References + + [ARCHITECTURE] + Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy + Pass Architecture", Work in Progress, Internet-Draft, + draft-ietf-privacypass-architecture-16, 25 September 2023, + . + + [AUTHSCHEME] + Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass + HTTP Authentication Scheme", Work in Progress, Internet- + Draft, draft-ietf-privacypass-auth-scheme-14, 25 September + 2023, . + + [BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind + Signatures", Work in Progress, Internet-Draft, draft-irtf- + cfrg-rsa-blind-signatures-14, 10 July 2023, + . + + [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + . + + [OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. + Wood, "Oblivious Pseudorandom Functions (OPRFs) using + Prime-Order Groups", Work in Progress, Internet-Draft, + draft-irtf-cfrg-voprf-21, 21 February 2023, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + . + + [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Updates for RSAES-OAEP and RSASSA-PSS Algorithm + Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, + . + + [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale + Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, + . + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + . + + [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Caching", STD 98, RFC 9111, + DOI 10.17487/RFC9111, June 2022, + . + + [TIMESTAMP] + Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for + Defining Packet Timestamps", RFC 8877, + DOI 10.17487/RFC8877, September 2020, + . + + [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [WellKnownURIs] + "Well-Known URIs", n.d., + . + +9.2. Informative References + + [CONSISTENCY] + Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, + "Key Consistency and Discovery", Work in Progress, + Internet-Draft, draft-ietf-privacypass-key-consistency-01, + 10 July 2023, . + + [DSS] Moody, D., "Digital Signature Standard (DSS)", National + Institute of Standards and Technology, + DOI 10.6028/nist.fips.186-5, 2023, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + +Appendix A. Acknowledgements + + The authors of this document would like to acknowledge the helpful + feedback and discussions from Benjamin Schwartz, Joseph Salowey, and + Tara Whalen. + +Appendix B. Test Vectors + + This section includes test vectors for the two basic issuance + protocols specified in this document. Appendix B.1 contains test + vectors for token issuance protocol 1 (0x0001), and Appendix B.2 + contains test vectors for token issuance protocol 2 (0x0002). + +B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) + + The test vector below lists the following values: + + * skS: The Issuer Private Key, serialized using SerializeScalar from + Section 2.1 of [OPRF] and represented as a hexadecimal string. + + * pkS: The Issuer Public Key, serialized according to the encoding + in Section 8.2.1. + + * token_challenge: A randomly generated TokenChallenge structure, + represented as a hexadecimal string. + + * nonce: The 32-byte client nonce generated according to + Section 5.1, represented as a hexadecimal string. + + * blind: The blind used when computing the OPRF blinded message, + serialized using SerializeScalar from Section 2.1 of [OPRF] and + represented as a hexadecimal string. + + * token_request: The TokenRequest message constructed according to + Section 5.1, represented as a hexadecimal string. + + * token_response: The TokenResponse message constructed according to + Section 5.2, represented as a hexadecimal string. + + * token: The output Token from the protocol, represented as a + hexadecimal string. + + // Test vector 1 + skS: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181 + 14910bee3c919bed1bbffe3fc1b87d53240a + pkS: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c + 21da1a46d42ca38f7beabdf05c074aee1455bf + token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc + daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696 + 7696e2e6578616d706c65 + nonce: + 6aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05fafe73073b8 + blind: 8e7fd80970b8a00b0931b801a2e22d9903d83bd5597c6a4dc1496ed2b1 + 7ef820445ef3bd223f3ab2c4f54c5d1c956909 + token_request: 0001f4030ab3e23181d1e213f24315f5775983c678ce22eff9 + 427610832ab3900f2cd12d6829a07ec8a6813cf0b5b886f4cc4979 + token_response: 036bb3c5c397d88c3527cf9f08f1fe63687b867e85c930c49 + ee2c222408d4903722a19ff272ac97e3725b947c972784ebfe86eb9ea54336e43 + 34ea9660212c0c85fbadfbf491a1ce2446fc3379337fccd45c1059b2bc760110e + e1ec227d8e01c9f482c00c47ffa0dbe2fb58c32dde2b1dbe69fff920a528e68dd + 9b3c2483848e57c30542b8984fa6bfecd6d71d54d53eda + token: 00016aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05f + afe73073b8501370b494089dc462802af545e63809581ee6ef57890a12105c283 + 68169514bf260d0792bf7f46c9866a6d37c3032d8714415f87f5f6903d7fb071e + 253be2f4e0a835d76528b8444f73789ee7dc90715b01c17902fd87375c00a7a9d + 3d92540437f470773be20f71e721da3af40edeb + + // Test vector 2 + skS: 39efed331527cc4ddff9722ab5cd35aeafe7c27520b0cfa2eedbdc298dc3 + b12bc8298afcc46558af1e2eeacc5307d865 + pkS: 038017e005904c6146b37109d6c2a72b95a183aaa9ed951b8d8fb1ed9033 + f68033284d175e7df89849475cd67a86bfbf4e + token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269 + 67696e2e6578616d706c65 + nonce: + 7617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3190c29d665 + blind: 6492ee50072fa18d035d69c4246362dffe2621afb95a10c033bb0109e0 + f705b0437c425553272e0aa5266ec379e7015e + token_request: 000133033a5fe04a39da1bbfb68ccdeecd1917474dd525462e + 5a90a6ba53b42aaa1486fe443a2e1c7f3fd5ff028a1c7cf1aeac5d + token_response: 023bf8cd624880d669c5cc6c88b056355c6e8e1bcbf3746cf + b9ab9248a4c056f23a4876ef998a8b6b281d50f852c6fa868fc4fa135c79ccb5f + bdf8bf3c926e10c7c12f934a887d86da4a4e5be70f5a169aa75720887bb690536 + 92a8f11f9cda7a72f281e4e3568e848225367946c70db09e718e3cba16193987b + c10bede3ef54c4d036c17cd4015bb113be60d7aa927e0d + token: 00017617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3 + 190c29d665c994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1 + 34bd5a62a116477bc9e1a205cca95d0c92335ca7a3e71063b2ac020bdd231c660 + 97f12333ef438d00801bca5ace0fab8eb483dc04cd62578b95b5652921cd2698c + 45ea74f6c8827b4e19f01140fa5bd039866f562 + + // Test vector 3 + skS: 2b7709595b62b784f14946ae828f65e6caeba6eefe732c86e9ae50e818c0 + 55b3d7ca3a5f2beecaa859a62ff7199d35cc + pkS: 03a0de1bf3fd0a73384283b648884ba9fa5dee190f9d7ad4292c2fd49d8b + 4d64db674059df67f5bd7e626475c78934ae8d + token_challenge: 0001000e6973737565722e6578616d706c65000017666f6f + 2e6578616d706c652c6261722e6578616d706c65 + nonce: + 87499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c28aa7d3a9df + blind: 1f659584626ba15f44f3d887b2e5fe4c27315b185dfbfaea4253ebba30 + 610c4d9b73c78714c142360e85a00942c0fcff + token_request: 0001c8024610a9f3aac21090f3079d6809437a2b94b4403c7e + 645f849bc6c505dade154c258c8ecd4d2bdcf574daca65db671908 + token_response: 03c2ab925d03e7793b4a4df6eb505210139f620359e142449 + 1b8143c06a3e5298b25b662c33256411be7277233e1a34570f7a4d142d931e4b5 + ff8829e27aaf7eb2cc7f9ab655477d71c01d5da5aef44dd076b5820b4710ef025 + a9e6c6b50a95af6105c5987c1b834d615008cf6370556ed00c6671e69776c09a9 + 2b5ac84804750dd867c78817bdf69f1443002b18ae7a52 + token: 000187499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c2 + 8aa7d3a9df1949fd455872478ba87e2e6c513c3261cddbe57220581245e4c9c91 + 1dd1c0bb865785bff8f3cfe08cccbb3a7b8e41d23a172871be4828cc54582d87b + c7cfc5c8bcedc1868ebc845b000c317ed75312274a42b10be6db23bd8a168fd2f + 021c23925d72c4d14cd7588c03845da0d41a326 + + // Test vector 4 + skS: 22e237b7b983d77474e4495aff2fc1e10422b1d955192e0fbf2b7b618fba + 625fcb94b599da9113da49c495a48fbf7f7f + pkS: 028cd68715caa20d19b2b20d017d6a0a42b9f2b0a47db65e5e763e23744f + e14d74e374bbc93a2ec3970eb53c8aa765ee21 + token_challenge: 0001000e6973737565722e6578616d706c65000000 + nonce: + 02f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a89e820cd43 + blind: af91d1dbcf6b46baecde70eb305b8fe75629199cca19c7f9344b8607b9 + 0def27bc53e0345ade32c9fd0a1efda056d1c0 + token_request: 0001a503632ebb003ed15b6de4557c047c7f81a58688143331 + 2ad3ad7f9416f2dfc940d3f439ad1e8cd677d94ae7c05bc958d134 + token_response: 032018bc3f180d9650e27f72de76a90b47e336ae9cb058548 + d851c7046fa0875d96346c15cb39d8083cc6fb57216544c6a815c37d792769e12 + 9c0513ce2034c3286cb212548f4aed1b0f71b28e219a71874a93e53ab2f473282 + 71d1e9cbefc197a4f599a6825051fa1c6e55450042f04182b86c9cf12477a9f16 + 849396c051fa27012e81a86e6c4a9204a063f1e1722dd7 + token: 000102f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a + 89e820cd43085cb06952044c7655b412ab7d484c97b97c48c79c568140b8d49a0 + 2ca47a9cfb0a5cfb861290c4dbd8fd9b60ee9b1a1a54cf47c98531fe253f1ed6d + 875de5a58f42db12b540b0d11bc5d6b42e6d17c2b73e98631e54d40fd2901ebec + 4268668535b03cbf76f7f15a29d623a64cab0c4 + + // Test vector 5 + skS: 46f3d4f562002b85ffcfdb4d06835fb9b2e24372861ecaa11357fd1f29f9 + ed26e44715549ccedeb39257f095110f0159 + pkS: 02fbe9da0b7cabe3ec51c36c8487b10909142b59af030c728a5e87bb3b30 + f54c06415d22e03d9212bd3d9a17d5520d4d0f + token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc + daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b30000 + nonce: + 9ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e84483c90e89 + blind: 76e0938e824b6cda6c163ff55d0298d539e222ed3984f4e31bbb654a8c + 59671d4e0a7e264ca758cd0f4b533e0f60c5aa + token_request: 0001e10202bc92ac516c867f39399d71976018db52fcab5403 + f8534a65677ba9e1e7d9b1d01767d137884c86cf5fe698c2f5d8e9 + token_response: 0322ea3856a71533796393229b33d33c02cd714e40d5aa4e0 + 71f056276f32f89c09947eca8ff119d940d9d57c2fcbd83d2da494ddeb37dc1f6 + 78e5661a8e7bcc96b3477eb89d708b0ce10e0ea1b5ce0001f9332f743c0cc3d47 + 48233fea6d3152fae7844821268eb96ba491f60b1a3a848849310a39e9ef59121 + 669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080 + token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8 + 4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8 + 7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca + 1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c + d24504fe4f6c52d24ac901471267d8b63b61e6b + +B.2. Issuance Protocol 2 - Blind RSA, 2048 + + The test vector below lists the following values: + + * skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for + signing tokens, represented as a hexadecimal string. + + * pkS: The Issuer Public Key, serialized according to the encoding + in Section 8.2.2. + + * token_challenge: A randomly generated TokenChallenge structure, + represented as a hexadecimal string. + + * nonce: The 32-byte client nonce generated according to + Section 6.1, represented as a hexadecimal string. + + * blind: The blind used when computing the blind RSA blinded + message, represented as a hexadecimal string. + + * salt: The randomly generated 48-byte salt used when encoding the + blinded token request message, represented as a hexadecimal + string. + + * token_request: The TokenRequest message constructed according to + Section 6.1, represented as a hexadecimal string. + + * token_request: The TokenResponse message constructed according to + Section 6.2, represented as a hexadecimal string. + + * token: The output Token from the protocol, represented as a + hexadecimal string. + + // Test vector 1 + skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e + 393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e88000e6f72696 + 7696e2e6578616d706c65 + nonce: + aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd1508d07827f05 + blind: 425421de54c7381864ce36473abfb988c454fe6c27de863de702a6a2ad + ca153fa2de47bd8fcd62734caa8ce1f920b77d980ab58c32d16dde54873f28ca9 + 68e8c125b8363514be68972f553655bcc7f80a284cc327e47e804a47333c5b3cd + f773312cc7ad9fda748aed0baa7e19c5a2d1dafda718f086d7fc0a4bc02d488e0 + f20812daee335af7177b7a8369bd617066aed7a58f659f295c36b418827f67972 + 5b81ca14ea16fb82df21ad76da1ac38dcf24bf6252f8510e2308608ac9197f6cb + 54fdcb19db17837302a2b87d659c5605f35f3709a130f0c3d50e172f0cae36cbc + 9467f9914895a215a9e32443bcafff795273ccf8965a7eaa8c0b2184763e3e5c + salt: 3d980852fa570c064204feb8d107098db976ef8c2137e8641d234bbd88a + 986fdb306a7af220cfadede08f51e1ef61766 + token_request: 0002086a95be84b63cfed0993bb579194a72a95057e1548ac4 + 63a9a5b33b011f2b2011d59487f01862f1d8e4d5ea42e73a660fbc3d010b944a5 + 4da3a4e0942f8894c0884589b438cb902e9a34278970f33c16f351f7dae58d273 + c3ab66ef368da36f785e89e24d1d983d5c34311cd21f290f9e89e8646ab0d0a48 + 988fcd46230de5e7603cd12cc95c7ec5002e5e26737aa7eb69c626476e6c8d465 + 10ee404a3d7daf3a23b7c66735d363ca13676925c6ed0117f60d165ce1f8ba616 + d041b6384baf6da3e2f757cb18e879a4f8595c2dc895ddf1f4279c75768d108b5 + c47f95f94e81e2d8b9c8b74476924ab3b7c45243fc99ac5466e8a3680ad37fa15 + c96010b274094 + token_response: 675d84b751d9e593330ec4b6d7ab69c9a61517e98971f4b73 + 6150508174b4335761464f237be2d72bbae4b94dffc6143413f6351f1aa4efde6 + c32d4d6d9392a008290d56d1222f9b77a1336213e01934f7d972f3bf9ea5a5786 + c321352f103b3667e605379a55f0fb925fbb09b8a9f85e7dd4b388a3b49d06fd7 + 0ba28f6a780e3bc8f6421554fd6c38b63ef19f84ccfcf14709dd0b4d72213c1f0 + 60893854eba0ea1a147e275da320db5e9849882d5f9179efa8a2d8d3b803f9d14 + 45ef5c1f660be08883ce9b29a0a992fc035d2938cbb61c440044438dbb8b3ce71 + 58a8f9827d230482f622d291406ab236b32b122627ae0fd36bd0d6b7607b8044a + ce404d44 + token: 0002aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd150 + 8d07827f055969f643b4cfda5196d4aa86aeb5368834f4f06de46950ed435b3b8 + 1bd036d44ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd2708bc6a21b533d07294b5e900faf5537dd3eb33cee4e08c9670d1e5358fd + 184b0e00c637174f5206b14c7bb0e724ebf6b56271e5aa2ed94c051c4a433d302 + b23bc52460810d489fb050f9de5c868c6c1b06e3849fd087629f704cc724bc0d0 + 984d5c339686fcdd75f9a9cdd25f37f855f6f4c584d84f716864f546b696d620c + 5bd41a811498de84ff9740ba3003ba2422d26b91eb745c084758974642a420782 + 01543246ddb58030ea8e722376aa82484dca9610a8fb7e018e396165462e17a03 + e40ea7e128c090a911ecc708066cb201833010c1ebd4e910fc8e27a1be467f786 + 71836a508257123a45e4e0ae2180a434bd1037713466347a8ebe46439d3da1970 + + // Test vector 2 + skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c6500000e6f7269 + 67696e2e6578616d706c65 + nonce: + 98c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873d90e84488d + blind: 7bb85f89c9b83a0e2b02938b3396f06f8f3df0018a91f1a2cc5416aaa5 + 52994d063f634d50bea13bffe8d5e01431e646e2e384549cefd695ac3affff665 + a1ebf0113df2520006bd66e468d37a58266daa8a3a75692535e1fc46d0c1d6fb6 + f37c949808172e20c0b77a48570a1fcb474325bdd23cdbce52b5d6a9e39f7aec7 + 3b09004eae8c8bfff2b4b533ea63bcf467a4cd95ccfb0cb4e43bc4992c1fd0be7 + a77a4475dbf8094cf25125ece901abbcea607a9050ad9f8ec3d0d66341f6eab40 + ee9c9c22c0b560b8377f8543d8878c7458885fd285c7556cc88fc6021617075b4 + 2c83a86005169a6f13352e789b28fdbbe3d0288e1dd7c801497573893146aea3 + salt: b6b4378421ab0ea677ce3f4036fd0489dee458ad81ea519c3e8bde3fcd5 + ec1505d28e110d7b44dcac5e04ecedd54d11a + token_request: 00020892d26a271c0104657ba10c0b5cb2827bb209d86e8002 + 7f96bfb861e0f40cb897f0fc426498433141ce9bc8b4a95914fefe4e40bdd3802 + a121cb0b59a4ae7e03255275c4abf071d991c82ead402606c0ef912178b0a0f68 + d303e06a966079230592827b84979dbcb5f21ab8904e9908638ddf705c4f8af8a + 053c19a66090726b60c6b4063976e4c66eab33522dd3f9d64828441db4aa82d55 + adcc3d3920592884cd1e5a3f490d5c81f1306705dcc5c61d82373f1dbd7d2ae4b + 2fea0f7339f5d868415f59312766e3074ee4a7305f5f053da82673ee6747a727a + 26d8d10ea1b1a3491d26b0c38b962c02a774ac78932153aae9dcc98a9b1db1f53 + 89644682f7727 + token_response: 113a5124c1aef6fc230d9fc42b789226f45ca941aad4da3f4 + 8cf37c7744a8d7fd1dcfd71cd39d09e9324760180ea0bade3360efaf7322a1fa1 + 5f41247be3857fde8c5c92ec6d67a7ee33be8fdadf8b27bb0db706117448e55bc + e9927cb6bfb1f87f9edb054181a4558af0c0d3973d7033b9599e674c20cf08a7b + bcf0da815a2edaab7c4fb80dee4ea2cc53576a9691e857da931c6c592d2c69dd2 + 1afda8ea653dd90157adfe80e2375c08e75beb497df8b7b73192fbbd4e80359d9 + bbaecea14e0acebdda92596f71ec1d57e26b6497b3152976bc07a4409148cb843 + 89eb207fb8e841106012408c6e19b4f964008b6a909aaab767a661a061c97da16 + 43040455 + token: 000298c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873 + d90e84488d11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2 + b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd27083350a206c5e9b7c0898f97611ce0bb8d74d310bb194ab67e094e32ff6 + da90886924b1b9e7b569402c1101d896d2fc3a7371ef77f02310db1dc9f81c853 + 5828c2d0e9d9051720d182cd54e1c2c3bf417da2fc7aa72bb70ccc834ef274a2e + 809c9821b3d395d6535423f7428b3f29175d6eb840b4b7685336e57e2b6afeaab + c0c17ea4f557e8a9cc2f624e245c6ccd7cbdd6c32c97c5c6974e802f688e2d25f + 0aba4215f609f692244517d5d3407e0172273982c001c158f5fcbe1b5d2447c26 + a87e89f5a9e72b498b0c59ce749823d2cf253d3cf6cd4e64fa0e434d95e488789 + 247a9ceed756ff4ff33a8d2402c0db381236d331092838b608a42002552092897 + + // Test vector 3 + skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65000017666f6f + 2e6578616d706c652c6261722e6578616d706c65 + nonce: + 9e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af1592df0e71 + blind: c52cabc5e4e131e0f5860cc4c486c5ee8a5fa8ae59484446121f87b0d8 + ccd037f161a99ebcc57f79d05a2ffc852656ad2d0894fab8d1b0f998e6e678254 + ed5778da98b137371320314d06c24276e35435bccffa49d257687f270f9ce1792 + 6a074737546d5415a4bb9e624a6302562b395856632efb6992f6593a4f95fb342 + 002efebc3046ca96bbc26edb2f1a1454a24ce7b9a7ec8e44fb9e99c8144d409d8 + cd8a5903c0a3c0acbd9f82573ed1fc4a296e3eaf4867ade30110794678f422d36 + bd103ea4617d2472cf58da3381e52e5be60f4acbf685e280648cef21211a796ec + d005ecbdaa1046c40950afca4c4e7dd4b8c19e504088489a15667b45895b6e92 + salt: c847b5d0fa9101a1e09954ac9f3eed6600af58936295ad2e54274e13e64 + 0d59f732d07530c94c19c20668f03470c77ac + token_request: 0002080f6bd84fba1822c577c8cd670f1136cca107f84ddd9d + 405d5ed22ad15da975538f031433bad4a2688999732927efe2928d4c132389a12 + 2f40b639b083d6fcbbed7a55fb18db536d2dcbaefe6dc0a70730e6565b08a7dfd + 783913a59f37d798de0cfc262c9e90a7ee884a3ec355eacbd44e5f6779fea6a78 + 5b05ac352fdd51a116cf2be1d8e38b0bfacd6a3d53a88c99f747cce908f86b335 + 62691f540e3e88562092cd17cc2f78ce0fb53312a5f2dc918bdb1dc90d9d65091 + c7ba9080ccc1755cb5437989364dc92f0e8fea18f66d631451feb02a3d68af41d + e1a3f9be925dda5c4ca0706fc4ca28b3317e939f6573442c6d03be17cd141fa82 + 60d382d134c6b + token_response: 2dd08ce89cf4f62bc236ab7b75266e13c57c750345e328e0b + ea107537c4cbeea5bfc990716950440628ea2e37dbc5c9c6d84f9a965cbf0cbff + fb89516b1fd19a90d69cc52a28890bbdcf782f56aefadad85b6e861a74170ce91 + 0891c89e4293f37978dbd41cc8b5c68802de3d86d9f0326b9c22b809512245896 + 6a6ddd1aeb3828d239c3b359efc9b375390eb19050d5656c2b084304d9bd8a816 + 14f631bf82a7e4588413b44a0cb6d94e942fa134790b396cb71e3ed33b557b5bd + 0734e726fa79abdca8694703b81d0e289b749801d4383e0d4f825dcde0dd98c43 + d3ba81c028dd8833a4fc24961f60e118d4421dce5b611d53e9ca96156a52509bf + a9afeb7e + token: 00029e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af + 1592df0e710042eee45ac4dd5acb8f6e65c4d8dd47504f73f7463507ef96a4d72 + 27d2774f3ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd270815b010bbc0d5f55e9c856d2e9ffaefba007d33c2d5452fbeb0b15919b + 973e0dc9180aaeb18242043758d9fb0ac9ac5e04da9ff74ec93644ae6cdb7068e + a76ce2295b9b95e383ed3a9856e9f618dafdf4cec5d2b53ea4297c2f3990babca + 71e3ccd6c07a437daae7ed27b6b81178fb7ce5fa5dd63781cc64ac1e410f441c0 + 34b0a5cc873a2ce875e8b38c92bab563635c4f8f4fa35d1f582ef19edf7da75aa + 11a503a82e32a12bd4da41e0ca7ec7f451caf586f5b910003fcbbb9ff5ffa2408 + c28d6807737d03da651ea9bfafcc2747a6830e19a1d160fcd5c25d2f79dad86a8 + b3de8e926e08ca1addced72977f7b56398ef59c26e725df0a976a08f2a936ca42 + + // Test vector 4 + skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65000000 + nonce: + 494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c45340bfe8e6 + blind: 097cb17bcedecfe058dff5c4e517d1e36d7ab8f46252b1ac1933ba378c + 32625c0dbc69f5655c2003bf39e75810796cd63675b223cf3162c57108d56e058 + 4cfce6cad829e74369ada38a095eb3012c912b31ccde7425f93464e353fb17552 + be3a8df2913daca61543a33ae45058f218c471dfbc12fb304158e29b6ed35bc07 + 9e23f1e6173c5dec4545840bbe58e5ad37cbea0a10dca5d9df2781589d27c3410 + 8477b52c0d32a1370c17f703941fbb1a007a6794e7de2758709c9bbf80f21eec7 + 922b9bb491eb6aac8c1a14764e648e6be4fff0ae913797067aa0826f366c3103e + 103b05653c73b52d7f825a185dccfb806da700db9f53abb848554b7d4f7c28f3 + salt: 49912979f1bf528e5b8228ab1328df74319dce7bdaf45821ceb1100dcf0 + 42a2dfe852fc9db59b64a5f6493c282504240 + token_request: 000208244840027ca8c620f8b14caded9a198ba388ccd8541e + 962f68a0071535d958d18494afd0bc11da4da8c8b33864f5a8f623b697cd56348 + 594e11a75479048a72c0ed179b070506c09a7eb6ed3582f572df38cf60fcde11a + 52c5ce6d7b23435b60200ad9f66d21f40f323c9aa54307d0b966d4457c37542b6 + 6bb183ddeafca914fc74831698b5d52f498ee3d165685f49a8d86e39fe6c4b7ec + 678f5250908d25e5b873c69b422368121aa4210cadd6fc640907d3cb9a7a3e827 + a0e742470f00c2f49dc6c0e8cc9470dbfd73df0ccbb96c10b02af0dd7dee719ec + a11ff8e1b4929e59f3cf319de9bda29a6d968b43083b5d4242f3448d76ada08b8 + 014f70b97e719 + token_response: c2746ff644cffb28a2c19395fa19dfb61fd135daa837844fb + f9fbe06c253e64e69f53aefddc0fb4833b1b5e58f571134a34f245499c3e73419 + 549c2c9111cf94f2f68fea3996d47f71e8d8d6fc5b1c074bf74fa59de4cbf32f5 + f08d45ea45492f0279c3b1a8d852698edbe1651eb8e09eb223a27386c0feb2f6a + 8260235edb36cf433da518100829b63166284b325d87fc941ea3bafe7b6761b70 + 82e09397837f74b4f0fc838bce8af7242089dd5561f57735926bcbad219fc9fee + 85ae49a8e8951f63ca194b7ff018c06ee02267e7267bb996432dc76973819da80 + e3e86947b0a4b36d3a972dafaaa3db0e1044b325f02c679996d9bcd3ce51390d5 + 4bc10b8c + token: 0002494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c4 + 5340bfe8e6b741ec1b6fd05f1e95f8982906aec1612896d9ca97d53eef94ad3c9 + fe023f7a4ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd2708a55c83dc04292b5d92add1a87b37e54f22f61c58840586f390c50b231 + 824423378ddcf50e69dc817d45bfad06c7f2a0ac35d2acd7f26b0bc9954c192b0 + a0ef28a2a5650e390098dd3cb1166a7cb1716d3dd2d19dc5ca3b1ea6206359de0 + 002d82bc4fa7e69fb07214b06addcbd2203d1e17f57fc580bcc5a13e0ac15cf94 + 2182cc2b5d6eaa737a712704114e357e2ec2f10047463ded02a1a0766dc346dd7 + 212b9711e03ac95eb258ac1164104dc9a0d3e738ae742ab5ed8c5139fc07145a7 + 88b9f891741ee68f0a66782b7b84a9bb4cb4b3d1b26b67106f397b35b641d882d + 7b0185168946de898ef72349a44a47dbdd6d46e9ba9ba543d5701b65c63d645c2 + + // Test vector 5 + skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e + 393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e880000 + nonce: + a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f63143cd43a3 + blind: ad7a32e1ac31b91daefd7042cc23d5621ab3e870d87297bbfe1ee8a518 + ffc5b84770d3b77775c485b2d219954834868842d2f11877ac4bceb5da88944cc + a043a9afa52f9c9998a5dea7ab7c1f82662d0d327e29705a269ad221ae74a7c11 + 72ff89c48997a9fda08886d3998bb538868396c0ace71d260cc71f768001939b2 + 4d80d88979f0244a3dbc004eadfac81e138d430b9fa51c1aad21b957ff96b3123 + c91c2fff362a386f0f99a3f9fc906ca626fd9107648f87532b44c4fe3856ecae1 + f46d8ebf5d2f46e52034478e5e883015666574dd80bd5c036c4b55ebcc8b66068 + 8d23944cc1932d075b559dcdc269fae3511761f71c113634e60d67accc8875fb + salt: 35c04710ce866d879447b6230ce098a49e81be5c067881cce7bd5f92c1e + 5bd9b3c7d4d795cfad134fdfe916d735a624a + token_request: 0002083d6495c72529bbc4f5c0b49e94e4561baec1ca638a93 + b2940ea9e37b838db7b1a91ec1f257d49b45c4f75119c2ab9eb5578541ad2b9ba + c1bd627abc709097f503f83d98fed6dbeb615c3be9bf09cbf8ea25ea8026c1b8b + a1c704ff516ed87c3d7d85342fd00111d8a80492d4b8fdbb092a282f74f13901e + 5edc1b3b02cfe24c950affe6130fbb57c1482d674db3c6944812ba081c2235a16 + d01eeec0932a8619d85732fc3e36179f0b50377bf9cb7a50ce3abeb3f31ed5f0f + 3deec7aae7290f5397cec61318357d652b029a0fda0f100a78e36c4ef56ba3779 + 963e8745fdf4e347763c63d825836878e249833a0f4bd315392cc06ccca2c955e + 921efbc4f941d + token_response: 8db727000018a98a2fe9fda8bbde5b8e9cedc31efbcaed695 + 0eb1e0f8d9af9db632def52f74f07cdab304bbde40519080dd0388fb2b8900528 + b4791d2bca40aa2c2a6d1b92f010c1849bfb781cc813cc204855dd05e8a2dd31e + a5220981b8ab6b008e153083dc8f594206440d66286fea9c21b56807be8655506 + ab7818bb9c8c69489dda56fe6390a5397268c8b5711f9d2df6f2584740cccf034 + 5fd67f93f345426f33c078a0aceb90845df9eef74f6248d06c36d19e191da325b + 721ddc12ea78ed37b0c3b6170590536e3aee7eb0efc7d11a2c9d072a394f12ffa + 67ecf316c49efd8f31723b11fe46740636bd89ad4f7ef96bc38b2cb4916d9dc04 + ba1b2fc6 + token: 0002a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f6 + 3143cd43a3bb8a8cf1c59e7a251358ed76fe0ccff61044bc79dd261f16020324d + 22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a + 9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26 + e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c + c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81 + a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b + a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273 + c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658 + 5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23 + +Authors' Addresses + + Sofía Celi + Brave Software + Lisbon + Portugal + Email: cherenkov@riseup.net + + + Alex Davidson + Brave Software + Lisbon + Portugal + Email: alex.davidson92@gmail.com + + + Steven Valdez + Google LLC + Email: svaldez@chromium.org + + + Christopher A. Wood + Cloudflare + 101 Townsend St + San Francisco, + United States of America + Email: caw@heapingbits.net diff --git a/chris-wood-patch-7/index.html b/chris-wood-patch-7/index.html new file mode 100644 index 00000000..d4ec315c --- /dev/null +++ b/chris-wood-patch-7/index.html @@ -0,0 +1,55 @@ + + + + ietf-wg-privacypass/base-drafts chris-wood-patch-7 preview + + + + +

Editor's drafts for chris-wood-patch-7 branch of ietf-wg-privacypass/base-drafts

+ + + + + + + + + + + + + + + + +
Privacy Pass Issuanceplain textsame as main
Privacy Pass Authenticationplain textsame as main
Privacy Pass Architectureplain textsame as main
+ + + diff --git a/index.html b/index.html index ff56ff64..80e9fec0 100644 --- a/index.html +++ b/index.html @@ -74,6 +74,24 @@

Preview for branch fix-auth-figures

diff with main +

Preview for branch chris-wood-patch-7

+ + + + + + + + + + + + + + + + +
Privacy Pass Issuanceplain textdiff with main
Privacy Pass Authenticationplain textsame as main
Privacy Pass Architectureplain textsame as main

Preview for branch draft-ietf-privacypass-architecture-16