From b99cf49cc721d8638365858cebc75676c025fe46 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 16 Nov 2023 19:00:45 +0000 Subject: [PATCH] Script updating gh-pages from 26e0aa4. [ci skip] --- .../draft-ietf-privacypass-architecture.html | 2884 ------------- .../draft-ietf-privacypass-architecture.txt | 1379 ------- .../draft-ietf-privacypass-auth-scheme.html | 2670 ------------ .../draft-ietf-privacypass-auth-scheme.txt | 1205 ------ .../draft-ietf-privacypass-protocol.html | 3569 ----------------- .../draft-ietf-privacypass-protocol.txt | 1868 --------- chris-wood-patch-8/index.html | 55 - draft-ietf-privacypass-architecture.html | 10 +- draft-ietf-privacypass-architecture.txt | 12 +- draft-ietf-privacypass-auth-scheme.html | 10 +- draft-ietf-privacypass-auth-scheme.txt | 10 +- draft-ietf-privacypass-protocol.html | 8 +- draft-ietf-privacypass-protocol.txt | 6 +- index.html | 18 - 14 files changed, 28 insertions(+), 13676 deletions(-) delete mode 100644 chris-wood-patch-8/draft-ietf-privacypass-architecture.html delete mode 100644 chris-wood-patch-8/draft-ietf-privacypass-architecture.txt delete mode 100644 chris-wood-patch-8/draft-ietf-privacypass-auth-scheme.html delete mode 100644 chris-wood-patch-8/draft-ietf-privacypass-auth-scheme.txt delete mode 100644 chris-wood-patch-8/draft-ietf-privacypass-protocol.html delete mode 100644 chris-wood-patch-8/draft-ietf-privacypass-protocol.txt delete mode 100644 chris-wood-patch-8/index.html diff --git a/chris-wood-patch-8/draft-ietf-privacypass-architecture.html b/chris-wood-patch-8/draft-ietf-privacypass-architecture.html deleted file mode 100644 index fd02d9d9..00000000 --- a/chris-wood-patch-8/draft-ietf-privacypass-architecture.html +++ /dev/null @@ -1,2884 +0,0 @@ - - - - - - -The Privacy Pass Architecture - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftPrivacy Pass ArchitectureOctober 2023
Davidson, et al.Expires 15 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 15 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-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-protocol-16>.
-
-
[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-8/draft-ietf-privacypass-architecture.txt b/chris-wood-patch-8/draft-ietf-privacypass-architecture.txt deleted file mode 100644 index 13e3d435..00000000 --- a/chris-wood-patch-8/draft-ietf-privacypass-architecture.txt +++ /dev/null @@ -1,1379 +0,0 @@ - - - - -Network Working Group A. Davidson -Internet-Draft LIP -Intended status: Informational J. Iyengar -Expires: 15 April 2024 Fastly - C. A. Wood - Cloudflare - 13 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 15 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-16, 3 - October 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-8/draft-ietf-privacypass-auth-scheme.html b/chris-wood-patch-8/draft-ietf-privacypass-auth-scheme.html deleted file mode 100644 index 1b34dc19..00000000 --- a/chris-wood-patch-8/draft-ietf-privacypass-auth-scheme.html +++ /dev/null @@ -1,2670 +0,0 @@ - - - - - - -The Privacy Pass HTTP Authentication Scheme - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftPrivacy Pass AuthenticationOctober 2023
Pauly, et al.Expires 15 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 15 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-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-protocol-16>.
-
-
[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 supported -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-8/draft-ietf-privacypass-auth-scheme.txt b/chris-wood-patch-8/draft-ietf-privacypass-auth-scheme.txt deleted file mode 100644 index 8d53df8c..00000000 --- a/chris-wood-patch-8/draft-ietf-privacypass-auth-scheme.txt +++ /dev/null @@ -1,1205 +0,0 @@ - - - - -Network Working Group T. Pauly -Internet-Draft Apple Inc. -Intended status: Standards Track S. Valdez -Expires: 15 April 2024 Google LLC - C. A. Wood - Cloudflare - 13 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 15 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-16, 3 - October 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 supported 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-8/draft-ietf-privacypass-protocol.html b/chris-wood-patch-8/draft-ietf-privacypass-protocol.html deleted file mode 100644 index 945a52d8..00000000 --- a/chris-wood-patch-8/draft-ietf-privacypass-protocol.html +++ /dev/null @@ -1,3569 +0,0 @@ - - - - - - -Privacy Pass Issuance Protocol - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftPrivacy Pass IssuanceOctober 2023
Celi, et al.Expires 15 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 15 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-8/draft-ietf-privacypass-protocol.txt b/chris-wood-patch-8/draft-ietf-privacypass-protocol.txt deleted file mode 100644 index 613ede1f..00000000 --- a/chris-wood-patch-8/draft-ietf-privacypass-protocol.txt +++ /dev/null @@ -1,1868 +0,0 @@ - - - - -Network Working Group S. Celi -Internet-Draft A. Davidson -Intended status: Standards Track Brave Software -Expires: 15 April 2024 S. Valdez - Google LLC - C. A. Wood - Cloudflare - 13 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 15 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-8/index.html b/chris-wood-patch-8/index.html deleted file mode 100644 index 0c349cea..00000000 --- a/chris-wood-patch-8/index.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - ietf-wg-privacypass/base-drafts chris-wood-patch-8 preview - - - - -

Editor's drafts for chris-wood-patch-8 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/draft-ietf-privacypass-architecture.html b/draft-ietf-privacypass-architecture.html index 9b4f01f4..acfc20cf 100644 --- a/draft-ietf-privacypass-architecture.html +++ b/draft-ietf-privacypass-architecture.html @@ -1036,7 +1036,7 @@ Davidson, et al. -Expires 5 May 2024 +Expires 19 May 2024 [Page] @@ -1049,12 +1049,12 @@
draft-ietf-privacypass-architecture-latest
Published:
- +
Intended Status:
Informational
Expires:
-
+
Authors:
@@ -1101,7 +1101,7 @@

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 May 2024.

+ This Internet-Draft will expire on 19 May 2024.