]> Brave Software

Lisbon Portugal cherenkov@riseup.net

Brave Software

Lisbon Portugal alex.davidson92@gmail.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 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.

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 built on . It specifies two variants: one that is privately verifiable using the issuance private key based on the oblivious pseudorandom function from , and one that is publicly verifiable using the issuance public key based on the blind RSA signature scheme . 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 .

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. This document uses the terms Origin, Client, Issuer, and Token as defined in . 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 . Moreover, all constants are in network byte order.

Protocol Overview The issuance protocols defined in this document embody the core of Privacy Pass. Clients receive TokenChallenge inputs from the redemption protocol () and use the issuance protocols to produce corresponding Token values (). 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.

Issuance Overview | | | | |<== Attestation ==>| | | | | | | +--------- TokenRequest ------->| | |<-------- TokenResponse -------+ |<-- Request+Token ---+ | | | | | | ]]>

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 . The details of attestation are outside the scope of the issuance protocol; see 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 () using the issuance private key based on the oblivious pseudorandom function from , and one that is publicly verifiable () using the issuance public key based on the blind RSA signature scheme .

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 () whose values are other JSON values () for the parameters. The contents of this JSON object are defined in . Issuer directory object description

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 ()
token-keys	List of Issuer Public Key values, each represented as JSON objects ()

Each "token-keys" JSON object contains the fields and corresponding raw values defined in . Issuer 'token-keys' object description'

Field Name	Value
token-type	Integer value of the Token Type, as defined in , represented as a JSON number ()
token-key	The base64url-encoded Public Key for use with the issuance protocol as determined by the token-type field, including padding, represented as a JSON string ()

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 ) 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): 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): 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 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 . 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 can be differentiated correctly. Issuers SHOULD use HTTP cache directives to permit caching of this resource . 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: Consumers of the Issuer directory resource SHOULD follow the usual HTTP caching 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.

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 . Issuers provide a Issuer Private and Public Key, denoted skI and pkI respectively, used to produce tokens as input to the protocol. See 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 .
• 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. The constants Ne and Ns are as defined in for OPRF(P-384, SHA-384). The constant Nk, which is also equal to Nh as defined in , is defined by .

Client-to-Issuer Request The Client first creates a context as follows: Here, "P384-SHA384" is the 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 32-byte value nonce with the input challenge and Issuer key identifier as described below: The Blind function is defined in . 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 ). 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.
• "truncated_token_key_id" is the least significant byte of the token_key_id () 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 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 . 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. ]]>

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 , 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: SetupVOPRFServer is defined in and BlindEvaluate 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 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". ]]>

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: The Finalize function is defined in . If this succeeds, the Client then constructs a Token as follows: The Token.nonce value is that which was created in . If the Finalize function fails, the Client aborts the protocol.

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:

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: The DeriveKeyPair function is defined in . The key identifier for a public key pkI, denoted token_key_id, is computed as follows: 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.

Issuance Protocol for Publicly Verifiable Tokens This section describes a variant of the issuance protocol in for producing publicly verifiable tokens using the protocol in . 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 . The publicly verifiable issuance protocol differs from the protocol in 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 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 .
• 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. The constant Nk is defined by .

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: The PrepareIdentity and Blind functions are defined in and , 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 ). 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.
• "truncated_token_key_id" is the least significant byte of the token_key_id () 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 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. ]]>

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: The BlindSign function is defined in . The result is encoded and transmitted to the client in the following TokenResponse structure: 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". ]]>

Finalization Upon receipt, the Client handles the response and, if successful, processes the content as follows: The Finalize function is defined in . If this succeeds, the Client then constructs a Token as described in as follows: The Token.nonce value is that which was sampled in . If the Finalize function fails, the Client aborts the protocol.

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 , 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).

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 . 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 (SPKI) object carrying pkI as a DER-encoded RSAPublicKey value in the 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: 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.

Security considerations This document outlines how to instantiate the Issuance protocol based on the VOPRF defined in and blind RSA protocol defined in . 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 . In particular, Section and Section of discuss relevant privacy considerations influenced by the Privacy Pass deployment model, and 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 , and Issuer selection.

IANA considerations This section contains considerations for IANA.

Well-Known 'private-token-issuer-directory' URI This document updates the "Well-Known URIs" Registry with the following values. 'private-token-issuer-directory' Well-Known URI

URI Suffix	Change Controller	Reference	Status	Related information
private-token-issuer-directory	IETF	[this document]	permanent	None

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

Token Type VOPRF (P-384, SHA-384)

• Value: 0x0001
• Name: VOPRF (P-384, SHA-384)
• Token Structure: As defined in
• Token Key Encoding: Serialized using SerializeElement from
• TokenChallenge Structure: As defined in
• Public Verifiability: N
• Public Metadata: N
• Private Metadata: N
• Nk: 48
• Nid: 32
• Reference:
• Notes: None

Token Type Blind RSA (2048-bit)

• Value: 0x0002
• Name: Blind RSA (2048-bit)
• Token Structure: As defined in
• Token Key Encoding: Serialized as a DER-encoded SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID
• TokenChallenge Structure: As defined in
• Public Verifiability: Y
• Public Metadata: N
• Private Metadata: N
• Nk: 256
• Nid: 32
• Reference:
• Notes: The RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic variants are supported

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.

"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

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

"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

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

"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

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

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 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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 private 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 private 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. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Fastly Inc. Apple Inc. Cloudflare This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. Apple Inc. Google LLC Cloudflare 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. This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. 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 National Institute of Standards and Technology National Institute of Standards and Technology <jats:p /> This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Brave Software The Tor Project Mozilla Cloudflare This document describes the consistency requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It presents definitions for consistency and then surveys mechanisms for providing consistency in varying threat models. In concludes with discussion of open problems in this area.

Acknowledgements The authors of this document would like to acknowledge the helpful feedback and discussions from Benjamin Schwartz, Joseph Salowey, 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 Issuer Private Key, serialized using SerializeScalar from and represented as a hexadecimal string.
• pkS: The Issuer Public Key, serialized according to the encoding in .
• token_challenge: A randomly generated TokenChallenge structure, 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_response: 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, 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 .
• token_challenge: A randomly generated TokenChallenge structure, 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.