]> Cloudflare

Lisbon Portugal sceli@cloudflare.com

Brave Software

Lisbon Portugal alex.davidson92@gmail.com

Cloudflare

101 Townsend St San Francisco United States of America armfazh@cloudflare.com

Google LLC

svaldez@chromium.org

Cloudflare

101 Townsend St San Francisco United States of America caw@heapingbits.net

Internet-Draft This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable, and another that produces tokens that are publicly verifiable. The privately verifiable issuance protocol optionally supports public metadata during the issuance flow.

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 . This document describes the issuance protocol for Privacy Pass. It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from , and one that is publicly verifiable based on the blind RSA signature scheme . This document DOES NOT cover the architectural framework required for running and maintaining the Privacy Pass protocol in the Internet setting. In addition, it DOES NOT cover the choices that are necessary for ensuring that client privacy leaks do not occur. Both of these considerations are covered in .

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 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document.

• Client: An entity that provides authorization tokens to services across the Internet, in return for authorization.
• Issuer: A service produces Privacy Pass tokens to clients.
• Private Key: The secret key used by the Issuer for issuing tokens.
• Public Key: The public key used by the Issuer for issuing and verifying tokens.

We assume that all protocol messages are encoded into raw byte format before being sent across the wire.

Configuration Issuers MUST provide two parameters for configuration:

1. Issuer Request URI: a token request URL for generating access tokens. For example, an Issuer URL might be https://issuer.example.net/example-token-request. This parameter uses resource media type "text/plain".
2. Issuer Public Key values: an Issuer Public Key for an issuance protocol.

The Issuer parameters can be obtained from an Issuer via a directory object, which is a JSON object whose values are other JSON objects and URLs for the parameters.

Field Name	Value
issuer-request-uri	Issuer Request URI resource URL as a JSON string
token-keys	List of Issuer Public Key values, each as JSON objects

Each "token-keys" JSON object contains the following fields and corresponding raw values.

Field Name	Value
token-type	Integer value of the Token Type, as defined in , as a JSON number
token-key	The base64url encoding of the public key for use with the issuance protocol, including padding, as a JSON string

Issuers MAY advertise multiple token-keys for the same token-type to support 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. Altogether, the Issuer's JSON directory could look like: Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-directory.

Token Challenge Requirements Clients receive challenges for tokens, as described in . The basic token issuance protocols described in this document can be interactive or non-interactive, and per-origin or cross-origin.

Issuance Protocol for Privately Verifiable Tokens The Privacy Pass issuance protocol is a two message protocol that takes as input a challenge from the redemption protocol and produces a token, as shown in the figure below. TokenRequest -------------> | | (evaluate) | Token <----+ <--------------- TokenResponse | \------------------------------------/ ]]> Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol. See for how this key pair is generated. Clients provide the following as input to the issuance protocol:

• Issuer name, identifying 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 key_id computed as described in .
• Challenge value challenge, an opaque byte string. For example, this might be provided by the redemption protocol in .

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

Client-to-Issuer Request The Client first creates a context as follows: Here, 0x0004 is the two-octet identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite in . SetupVOPRFClient is defined in . The Client then creates an issuance request message for a random value nonce using the input challenge and Issuer key identifier as follows: The Blind function is defined in . If the Blind function fails, the Client aborts the protocol. Otherwise, the Client then creates a TokenRequest structured as follows: The structure fields are defined as follows:

• "token_type" is a 2-octet integer, which matches the type in the challenge.
• "token_key_id" is the least significant byte of the key_id in network byte order (in other words, the last 8 bits of key_id).
• "blinded_msg" is the Ne-octet blinded message defined above, computed as SerializeElement(blinded_element). Ne is as defined in .

The values token_input and blinded_element are stored locally and used later as described in . The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body. The media type for this request is "message/token-request". An example request is shown below. ]]> Upon receipt of the request, the Issuer validates the following conditions:

• The TokenRequest contains a supported token_type.
• The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer.
• The TokenRequest.blinded_request is of the correct size.

If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the client.

Issuer-to-Client Response Upon receipt of a TokenRequest, the Issuer tries to deseralize TokenRequest.blinded_msg using DeserializeElement from , yielding blinded_element. If this fails, the Issuer MUST return an HTTP 400 error to the client. Otherwise, if the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: SetupVOPRFServer is in and Evaluate is defined in . The Issuer then creates a TokenResponse structured as follows: The structure fields are defined as follows:

• "evaluate_msg" is the Ne-octet evaluated messaged, 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])), where Ns is as defined in .

The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "message/token-response". ]]>

Finalization Upon receipt, the Client handles the response and, if successful, deserializes the body values TokenResponse.evaluate_response 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: The Finalize function is defined in . If this succeeds, the Client then constructs a Token as follows: Otherwise, the Client aborts the protocol.

Issuer Configuration Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens. Each key pair MUST be generated as follows: The key identifier for this specific key pair, denoted key_id, is computed as follows:

Issuance Protocol for Publicly Verifiable Tokens This section describes a variant of the issuance protocol in for producing publicly verifiable tokens. It differs from the previous variant in two important ways:

1. The output tokens are publicly verifiable by anyone with the Issuer public key.
2. The issuance protocol does not admit public or private metadata to bind additional context to tokens.

The first property means that 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 these differences, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance protocol variant. In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol. See for how this key pair is generated. Clients provide the following as input to the issuance protocol:

• Issuer name, identifying 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 key_id computed as described in .
• Challenge value challenge, an opaque byte string. For example, this might be provided by the redemption protocol in .

Given this configuration and these inputs, the two messages exchanged in this protocol are described below.

Client-to-Issuer Request The Client first creates an issuance request message for a random value nonce using the input challenge and Issuer key identifier as follows: The rsabssa_blind function is defined in . The Client then creates a TokenRequest structured as follows: The structure fields are defined as follows:

• "token_type" is a 2-octet integer, which matches the type in the challenge.
• "token_key_id" is the least significant byte of the key_id in network byte order (in other words, the last 8 bits of key_id).
• "blinded_msg" is the Nk-octet request defined above.

The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body. The media type for this request is "message/token-request". An example request is shown below, where Nk = 512. ]]> Upon receipt of the request, the Issuer validates the following conditions:

• The TokenRequest contains a supported token_type.
• The TokenRequest.token_key_id corresponds to a 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 400 error to the Client, which will forward the error to the client.

Issuer-to-Client Response If the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: This is encoded and transmitted to the client in the following TokenResponse structure: The rsabssa_blind_sign function is defined in . The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "message/token-response". ]]>

Finalization Upon receipt, the Client handles the response and, if successful, processes the body as follows: The rsabssa_finalize function is defined in . If this succeeds, the Client then constructs a Token as described in as follows: Otherwise, the Client aborts the protocol.

Issuer Configuration Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens. Each key pair SHALL be generated as as specified in FIPS 186-4 . The key identifier for a keypair (skI, pkI), denoted key_id, is computed as SHA256(encoded_key), where encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object carrying pkI. The SPKI object MUST use the RSASSA-PSS OID , which specifies the hash algorithm and salt size. The salt size MUST match the output size of the hash function associated with the public key and token type.

Security considerations This document outlines how to instantiate the Issuance protocol based on the VOPRF defined in and blind RSA protocol defnied in . All security considerations described in the VOPRF document 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 .

IANA considerations

Token Type This document updates the "Token Type" Registry with the following values. Token Types

Value	Name	Publicly Verifiable	Public Metadata	Private Metadata	Nk	Reference
0x0001	VOPRF (P-384, SHA-384)	N	N	N	48
0x0002	Blind RSA (SHA-384, 2048-bit)	Y	N	N	256

Media Types This specification defines the following protocol messages, along with their corresponding media types:

• TokenRequest: "message/token-request"
• TokenResponse: "message/token-response"

The definition for each media type is in the following subsections.

"message/token-request" media type

Type name:

message

Subtype name:

token-request

Required parameters:

N/A

Optional parameters:

None

Encoding considerations:

only "8bit" or "binary" is permitted

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

N/A

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:

IESG

"message/token-response" media type

Type name:

message

Subtype name:

access-token-response

Required parameters:

N/A

Optional parameters:

None

Encoding considerations:

only "8bit" or "binary" is permitted

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

N/A

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:

IESG

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. n.d. LIP Fastly Cloudflare This document specifies the architectural framework for constructing secure and anonymity-preserving instantiations of the Privacy Pass protocol. It provides recommendations on how the protocol ecosystem should be constructed to ensure the privacy of clients, and the security of all participating entities. Brave Software Cloudflare, Inc. Cloudflare, Inc. Cloudflare, Inc. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF secret key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF secret key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially-oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. Fastly Inc. Apple Inc. Cloudflare This document specifies the RSA-based blind signature protocol with appendix (RSA-BSSA). RSA blind signatures were first introduced by Chaum for untraceable payments [Chaum83]. It extends RSA-PSS encoding specified in [RFC8017] to enable blind signature support. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-wood-cfrg-blind-signatures. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Apple Inc. Google LLC Cloudflare This document defines an HTTP authentication scheme that 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 an acceptable Privacy Pass token. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK] Informative References

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

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

Issuance Protocol 1 - VOPRF(P-384, SHA-384) The test vector below lists the following values:

• skS: The encoded OPRF private key, serialized using SerializeScalar from and represented as a hexadecimal string.
• pkS: The encoded OPRF public key, serialized using SerializeElement from and represented as a hexadecimal string.
• challenge: A random challenge digest, represented as a hexadecimal string.
• nonce: The 32-byte client nonce generated according to , represented as a hexadecimal string.
• blind: The blind used when computing the OPRF blinded message, serialized using SerializeScalar from and represented as a hexadecimal string.
• token_request: The TokenRequest message constructed according to , represented as a hexadecimal string.
• token_request: The TokenResponse message constructed according to , represented as a hexadecimal string.
• token: The output Token from the protocol, represented as a hexadecimal string.

Issuance Protocol 2 - Blind RSA, 4096 The test vector below lists the following values:

• skS: The PEM-encoded PKCS#8 RSA private key used for signing tokens, represented as a hexadecimal string.
• pkS: The DER-encoded SubjectPublicKeyInfo object carrying the public key corresponding to skS, as described in , represented as a hexadecimal string.
• challenge: A random challenge digest, represented as a hexadecimal string.
• nonce: The 32-byte client nonce generated according to , 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 , represented as a hexadecimal string.
• token_request: The TokenResponse message constructed according to , represented as a hexadecimal string.
• token: The output Token from the protocol, represented as a hexadecimal string.