Network Working Group S. Celi Internet-Draft A. Davidson Intended status: Informational Brave Software Expires: 3 August 2023 A. Faz-Hernandez Cloudflare S. Valdez Google LLC C. A. Wood Cloudflare 30 January 2023 Privacy Pass Issuance Protocol draft-ietf-privacypass-protocol-08 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 3 August 2023. 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. Celi, et al. Expires 3 August 2023 [Page 1] Internet-Draft Privacy Pass Issuance January 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Issuance Protocol for Privately Verifiable Tokens . . . . . . 6 5.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 7 5.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 9 5.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Token Verification . . . . . . . . . . . . . . . . . . . 10 5.5. Issuer Configuration . . . . . . . . . . . . . . . . . . 11 6. Issuance Protocol for Publicly Verifiable Tokens . . . . . . 11 6.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 12 6.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 13 6.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Token Verification . . . . . . . . . . . . . . . . . . . 15 6.5. Issuer Configuration . . . . . . . . . . . . . . . . . . 15 7. Security considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. Well-Known 'token-issuer-directory' URI . . . . . . . . . 16 8.2. Token Type Registry Updates . . . . . . . . . . . . . . . 16 8.2.1. Token Type VOPRF (P-384, SHA-384) . . . . . . . . . . 16 8.2.2. Token Type Blind RSA (2048-bit) . . . . . . . . . . . 17 8.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 17 8.3.1. "application/token-issuer-directory" media type . . . 17 8.3.2. "application/private-token-request" media type . . . 18 8.3.3. "application/private-token-response" media type . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 21 B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) . . . . . . . 21 B.2. Issuance Protocol 2 - Blind RSA, 2048 . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Celi, et al. Expires 3 August 2023 [Page 2] Internet-Draft Privacy Pass Issuance January 2023 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. The following terms are used throughout this document. * Client: An entity that runs the Issuance protocol with an Issuer to produce Tokens that can be later used for redemption (see Section 2.2 of [AUTHSCHEME]). * Issuer: A service that provides Tokens to Clients. * 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. This document additionally uses the terms "Origin" and "Token" as defined in [ARCHITECTURE]. Unless otherwise specified, this document encodes protocol messages in TLS notation from Section 3 of [TLS13]. Moreover, all constants are in network byte order. Celi, et al. Expires 3 August 2023 [Page 3] Internet-Draft Privacy Pass Issuance January 2023 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 +-------------------------------------. TokenChallenge ---> Attest -------> | | TokenRequest ------------------> | | (evaluate)| Token <------+ <------------------- TokenResponse | `------------------------------------' 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. Celi, et al. Expires 3 August 2023 [Page 4] Internet-Draft Privacy Pass Issuance January 2023 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 or relative URL) 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 encoding of the Public Key for use | | | with the issuance protocol, including padding, | | | represented as a JSON string ([RFC8259], Section 7) | +------------+-----------------------------------------------------+ Table 2: Issuer 'token-keys' object description' 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 directory could look like: Celi, et al. Expires 3 August 2023 [Page 5] Internet-Draft Privacy Pass Issuance January 2023 { "issuer-request-uri": "https://issuer.example.net/request", "token-keys": [ { "token-type": 2, "token-key": "MI...AB", }, { "token-type": 2, "token-key": "MI...AQ", } ] } Issuer directory resources have the media type "application/token- issuer-directory" and are located at the well-known location /.well- known/token-issuer-directory; see Section 8.1 for the registration information for this well-known URI. Issuers SHOULD use HTTP caching 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. 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 configuration information is too stale, the directory SHOULD be fetched and revalidated. 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 Private and Public Key, denoted skI and pkI respectively, used to produce tokens as input to the protocol. See Section 5.5 for how this key pair is generated. Clients provide the following as input to the issuance protocol: Celi, et al. Expires 3 August 2023 [Page 6] Internet-Draft Privacy Pass Issuance January 2023 * Issuer Request URI: A URI to which token request messages 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 URI might be 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 is defined by Section 8.2.1. 5.1. Client-to-Issuer Request The Client first creates a context as follows: client_context = SetupVOPRFClient(0x0004, pkI) Here, 0x0004 is the two-octet 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 value nonce with the input challenge and Issuer key identifier as described below: Celi, et al. Expires 3 August 2023 [Page 7] Internet-Draft Privacy Pass Issuance January 2023 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). * "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 URI, with the TokenRequest as the content. The media type for this request is "application/private-token-request". An example request is shown below. Celi, et al. Expires 3 August 2023 [Page 8] Internet-Draft Privacy Pass Issuance January 2023 :method = POST :scheme = https :authority = issuer.example.net :path = /request accept = application/private-token-response cache-control = no-cache, no-store 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 400 error to the client. The Issuer then tries to deseralize TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of [OPRF], 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 to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: server_context = SetupVOPRFServer(0x0004, skI, pkI) evaluate_element, proof = server_context.Evaluate(skI, blinded_element) SetupVOPRFServer is in [OPRF], Section 3.2 and Evaluate 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). Celi, et al. Expires 3 August 2023 [Page 9] Internet-Draft Privacy Pass Issuance January 2023 * "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". :status = 200 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 sampled 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: Celi, et al. Expires 3 August 2023 [Page 10] Internet-Draft Privacy Pass Issuance January 2023 server_context = SetupVOPRFServer(0x0004, skI, pkI) 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 Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens. These keys MUST NOT be reused in other protocols. A RECOMMENDED method for generating key pairs is as follows: seed = random(Ns) (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") 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. 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. Celi, et al. Expires 3 August 2023 [Page 11] Internet-Draft Privacy Pass Issuance January 2023 Beyond this difference, 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 Section 6.5 for how this key pair is generated. Clients provide the following as input to the issuance protocol: * Issuer Request URI: A URI to which token request messages 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 URI might be 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 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)) Celi, et al. Expires 3 August 2023 [Page 12] Internet-Draft Privacy Pass Issuance January 2023 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). * "blinded_msg" is the Nk-octet request defined above. The Client then generates an HTTP POST request to send to the Issuer Request URI, with the TokenRequest as the content. The media type for this request is "application/private-token-request". An example request is shown below: :method = POST :scheme = https :authority = issuer.example.net :path = /request accept = application/private-token-response cache-control = no-cache, no-store 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. Celi, et al. Expires 3 August 2023 [Page 13] Internet-Draft Privacy Pass Issuance January 2023 * 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 400 error to the Client, which will forward the 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: 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". :status = 200 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: Celi, et al. Expires 3 August 2023 [Page 14] Internet-Draft Privacy Pass Issuance January 2023 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 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 [DSS]. These key pairs MUST NOT be reused in other protocols. The key identifier for a keypair (skI, pkI), denoted token_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 [RFC5756], 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. 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. Celi, et al. Expires 3 August 2023 [Page 15] Internet-Draft Privacy Pass Issuance January 2023 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, the privacy considerations in Section 4 and Section 5 of [ARCHITECTURE], particularly those pertaining to Issuer Public Key rotation and consistency (where consistency is as described in [CONSISTENCY]) and Issuer selection, are relevant for implementations of the protocols in this document. 8. IANA considerations This section contains considerations for IANA. 8.1. Well-Known '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| +======================+==========+=========+=========+===========+ |token-issuer-directory|IETF |[this |permanent|None | | | |document]| | | +----------------------+----------+---------+---------+-----------+ Table 3: 'token-issuer-directory' Well-Known URI 8.2. Token Type Registry Updates This document updates the "Token Type" Registry from [AUTHSCHEME], Section 5.2 with the following entries. 8.2.1. Token Type VOPRF (P-384, SHA-384) * Value: 0x0001 * Name: VOPRF (P-384, SHA-384) * Publicly Verifiable: N * Public Metadata: N Celi, et al. Expires 3 August 2023 [Page 16] Internet-Draft Privacy Pass Issuance January 2023 * 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) * Publicly Verifiable: 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 This specification defines the following protocol messages, along with their corresponding media types: * Token issuer directory: "application/token-issuer-directory" * TokenRequest: "application/private-token-request" * TokenResponse: "application/private-token-response" The definition for each media type is in the following subsections. 8.3.1. "application/token-issuer-directory" media type Type name: application Subtype name: token-issuer-directory Celi, et al. Expires 3 August 2023 [Page 17] Internet-Draft Privacy Pass Issuance January 2023 Required parameters: N/A Optional parameters: None Encoding considerations: "binary" Security considerations: see Section 4 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 Aut hors' Addresses section Intended usage: COMMON Restrictions on usage: N/A Author: see Authors' Addresses section Change controller: IESG 8.3.2. "application/private-token-request" media type Type name: application Subtype name: private-token-request Required parameters: N/A Optional parameters: None Encoding considerations: "binary" Security considerations: see Section 7 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 Aut hors' Addresses section Intended usage: COMMON Restrictions on usage: N/A Author: see Authors' Addresses section Change controller: IESG 8.3.3. "application/private-token-response" media type Type name: application Subtype name: private-token-response Required parameters: N/A Optional parameters: None Celi, et al. Expires 3 August 2023 [Page 18] Internet-Draft Privacy Pass Issuance January 2023 Encoding considerations: "binary" Security considerations: see Section 7 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 Aut hors' Addresses section Intended usage: COMMON Restrictions on usage: N/A Author: see Authors' Addresses section Change controller: IESG 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-07, 8 December 2022, . [BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind Signatures", Work in Progress, Internet-Draft, draft-irtf- cfrg-rsa-blind-signatures-07, 8 December 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-19, 24 January 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Celi, et al. Expires 3 August 2023 [Page 19] Internet-Draft Privacy Pass Issuance January 2023 [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, . [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 [ARCHITECTURE] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", Work in Progress, Internet-Draft, draft-ietf-privacypass-architecture-09, 8 December 2022, . [CONSISTENCY] "*** BROKEN REFERENCE ***". Celi, et al. Expires 3 August 2023 [Page 20] Internet-Draft Privacy Pass Issuance January 2023 [DSS] Laboratory, I. T. and National Institute of Standards and Technology, "Digital Signature Standard (DSS)", DOI 10.6028/nist.fips.186-4, July 2013, . [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . Appendix A. 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. 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 using SerializeElement from Section 2.1 of [OPRF] and represented as a hexadecimal string. * 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. Celi, et al. Expires 3 August 2023 [Page 21] Internet-Draft Privacy Pass Issuance January 2023 * token: The output Token from the protocol, represented as a hexadecimal string. skS: 08f572b675c83bf83c8037e503816119409a21d26e097414678eb44c625f cddd9b2e4eb16dbccc975c5ae745ffa3f4fa pkS: 0371b63695ddf79655f770ced74c17938d60c9cb9d8b9537614072b001ff c6085e80f310cdb4475487736f0f9d1406c7c9 token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269 67696e2e6578616d706c65 nonce: 1a177bae66ea3341c367c160c635aa52daef9f105bb1240d06a063ae12e9798a blind: 1e46366a7b619aea7d7e24d2b853f5ddc64524eb5a78f4e3af108f0291 9827cbdea2f8d753869ab9229aeb7fe9988763 token_request: 00017f023d788d4089a5f76f908ce26d18bb3b8ee826223b8a 1df70a052e092aaf235c44c6f1e57f81d17d31632d090d260dc531 token_response: 03c1854b0cb631ceff11079299fdc5c8d9f94c6d7d6dbc862 b259916a4dba69e39ac38817fafaa6e48842c610d41bf0bb6fa3ae6e3025acf22 38c0ef02e0b628437944cdbd0207c86bd9c3025fcacbd0e520576c7ad9bb9cc18 46687168e7c5226bdfd0c89be908d5d90eb60e5533045358e3063b6d3a24cc2f5 5891cded1a7642ef945bcec888e92e15d5ecdb431fdc6d token: 00011a177bae66ea3341c367c160c635aa52daef9f105bb1240d06a063 ae12e9798ac994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1 34bd5a62a7f13956db7526669425e8eb1128273c17972b5f16a9bc835a9c9f357 72a2add9f5e1bb3ab71770ada81faf1af0fbdfa476fc92a3ff25fac14639b7fe3 4365118ae2ff55a2399e1580bec9aa759659317 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 DER-encoded SubjectPublicKeyInfo object carrying the Issuer Public Key, as described in Section 6.5, represented as a hexadecimal string. * 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. Celi, et al. Expires 3 August 2023 [Page 22] Internet-Draft Privacy Pass Issuance January 2023 * 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. 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 Celi, et al. Expires 3 August 2023 [Page 23] Internet-Draft Privacy Pass Issuance January 2023 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 e735170315947763977644a724d6156774a6376497077563676315570660a5674 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 7844733968355272627852614e6673542b7241554837783153594456565159564 d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 0524956415445204b45592d2d2d2d2d0a pkS: 30820156304106092a864886f70d01010a3034a00f300d06096086480165 030402020500a11c301a06092a864886f70d010108300d0609608648016503040 2020500a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce01 3a4cfcab25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b47 1bec31d4b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d 8f529c500a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a31392768 79757ce453b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597ab e44d31c732db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78 a337d17b1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead2 64c2073fe49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700 d2a352a9babd612d03cad02db134b7e225a5f0203010001 token_challenge: d0bea78c3b452a4ccd4484e4c6f1e73d3c494be58a5a81c7c97f12fe5f9bb03c nonce: 23b29061bc9d3cf3637e067c47abe5122d355e9d681a3fc249fd4d4dd4ae7d61 blind: 1206c0f56241aac4716329f2eb1423dea369eaf05ce759c3ca6426c415 b44f90d4466ba4f57993b0ed753a156aa067a04d5eb9cd27ab930fdedf46a3c5f d46fed554849fd03df605602b33ed5e70d6266a74dd067563cab0d0f5fae416df b862b32a1254d60c5add16bbc6382273c75599f50abbe1b0ae9e63a1384a50738 5e492de216fdb9477ab0a4a6843d8068fd533b3014ca2aa127045bc99bb40311c ed536f28896bcd222b9bc1ba10ade0fa6b1e355af27f00bb189d37142c2976ebb 9c52da0372c3c1b75d030ab736a2889372e55dcd5970fce79cdddd10abf37dd60 ad2e1168081aab519041346cef7b4f4a8052d1c67cf83cf36d7bfac2111a3e00 salt: 0660138f93e216110f176800079b11f2da8ef31ab539ecee16a6c012085 79a61f043c7c8253f830ad38b06b8aa4314aa token_request: 0002f84040a643a8297d0c6f77c51fe71ab33ba77d1113345f 12d1c6224376b0ae8f332e8df4557c06f9c014ed859dbe5f87cd7811cbf3de6fa 9c680447b28d30cd379776c86dc16d7bfe96336321374d15cd728321fcfd939ea ef01ebcfe52a72ec0131fcecd447818339a6acde3e3d9034d50e2d88c2360a506 df1fb33f95d9bb84d5af1870f00576c9b47cf949f1f5bd57b7b334fefa3cf301a Celi, et al. Expires 3 August 2023 [Page 24] Internet-Draft Privacy Pass Issuance January 2023 52e08c449d198ec8e391b39de3d4d6a121b5288a4ec90df722b43cb13c50d58ce 52d78916ac4bb4d3597c7c816edd2997383fb59b0e565c36b9c19b63deea7538a c9e5d60e3e28b03b651edb6b3e0c647b327b153f61176ee6d2e1f3708ba946ecd 447610b2c8347 token_response: 67393299cc66da3b450f1c73836a918e543392ce11ccca9a8 a26eb2d9b8aa3f31825d7b89e7f0dd07bdc2770a39d1d0cda6bf597e4585468d4 bc608268b7786cb86be017913d284be7d040069c667dbb2ce49fe87b5e936e5b6 8f66f34d7828f281ea2a5a913cdf97b4b5e60153f9f2fcfebe4099c3bbc2f9d0c bd63197bf30a451c93f7677665c46112a2296b5e359589cb66c13d2bb6a49b985 89bb3580225bad2014fc433c1801328c1f064fee894cb037613dccc33af197d71 119b572f9fc32dcd614de2008ebfaafad393ff4f95b9d91662ae4a7952f13e958 7aa87810f586b03a14b096ea949da8d4e1d56de7a31a5bd93e921f3652a4d63ab d70f2d6d token: 000223b29061bc9d3cf3637e067c47abe5122d355e9d681a3fc249fd4d 4dd4ae7d61a982f3054cb8cd7dd827eb06f6c7bbd05b1f65a8e6e2968895c0ed1 642be52faf861220ad4241ee0e33eb4a486a32f05af05ee33fcfdd1104c665eb8 27c2062154c68677136693e8301583932d67445e8d073eb2dc2593583b0111e36 92129fa6bfa50f556d284e885ea8113a4500619d1559a00739774c4bb9b32adb5 43ee67a0db240ae44e6e84a5bedbe44d3db69b4859e6a36c5a51fa7da5deb13fe 38b3a04335c7e3b4ca495692d4efdec8272f9a718c4dd86a661161b9f26729fe4 87b35d2ccb0729adcfaec1393c64186002641177853e3af7f64f2384c81f3765c d572d618771a2b845647b4a4a167d51df8b49abe412310a6f1cdcdaea1efe6deb 97ca9cba9b5d90798b2399effeae0ff66a6a67b2f69961b4b34db5f5c79d5e48c 67ace06ba2836197fdb98bb6d276d1df03a006f9f8b06e09c7db7f473fb4736cc Authors' Addresses Sofía Celi Brave Software Lisbon Portugal Email: cherenkov@riseup.net Alex Davidson Brave Software Lisbon Portugal Email: alex.davidson92@gmail.com Armando Faz-Hernandez Cloudflare 101 Townsend St San Francisco, United States of America Email: armfazh@cloudflare.com Celi, et al. Expires 3 August 2023 [Page 25] Internet-Draft Privacy Pass Issuance January 2023 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 Celi, et al. Expires 3 August 2023 [Page 26]