Privacy Pass Issuance Protocols
Extracted elements (27)
Origins can attempt trial verification against multiple keys from the token-keys list (starting with the most preferred) to handle Client clock skew when the not-before field is in use.
Publicly verifiable tokens (Blind RSA) allow any Origin to verify tokens using only the Issuer Public Key without explicit Issuer coordination, because the Issuer never learns which Origin requested the token during issuance.
The truncated_token_key_id uses only the least-significant byte of the full SHA256 key identifier to prevent Issuers from embedding a unique per-Client identifier in the key ID field, which would undermine unlinkability.
The Blind RSA issuance protocol is defined only for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic variants of RFC 9474 Section 5; other blind RSA variants are not supported.
Blind RSA Issuer keys SHALL be generated securely (e.g., per FIPS 186-5) and MUST NOT be reused in other protocols. The key identifier is token_key_id = SHA256(DER-encoded SPKI of pkI).
For Blind RSA, the SPKI object MUST use the id-RSASSA-PSS OID; the parameters field MUST contain RSASSA-PSS-params and MUST include hashAlgorithm, maskGenAlgorithm, and saltLength, where saltLength MUST match the hash output size.
If a token-keys entry includes a not-before field, Clients SHOULD NOT use that key before the specified UNIX timestamp, as doing so can lead to issuance failures. Clients SHOULD use the first key in token-keys that either lacks a not-before value or has a not-before value in the past.
If any of the following conditions fail—supported token_type, recognized truncated_token_key_id, correctly sized blinded_msg, or successful deserialization of blinded_msg—the Issuer MUST return HTTP 422 (Unprocessable Content). This applies to both VOPRF and Blind RSA protocols.
Issuers MUST provide two configuration parameters: an Issuer Request URL and a list of Issuer Public Key values.
Issuers SHOULD ensure truncated forms (least-significant byte) of new VOPRF key IDs do not collide with other truncated key IDs in rotation; collisions cause the Issuer to use the wrong private key, producing invalid tokens.
Issuers SHOULD use HTTP cache directives (e.g., Cache-Control: max-age=86400) on the directory resource. When issuance fails due to stale configuration, the directory SHOULD be fetched and revalidated.
VOPRF Issuer keys MUST NOT be reused in other protocols. The RECOMMENDED generation method is seed=random(Ns); (skI, pkI)=DeriveKeyPair(seed, "PrivacyPass"). The key identifier is token_key_id = SHA256(SerializeElement(pkI)).
Blind RSA token verification uses RSASSA-PSS-VERIFY with SHA-384, MGF1-SHA-384, and 48-byte salt length to verify Token.authenticator against token_type || nonce || challenge_digest || token_key_id using the Issuer Public Key pkI.
The Issuer directory is a JSON object at /.well-known/private-token-issuer-directory (media type application/private-token-issuer-directory) containing issuer-request-uri and a token-keys list; each token-keys entry has token-type (integer), token-key (base64url-encoded public key), and optional not-before (UNIX timestamp).
The Privacy Pass issuance protocol is a one-round, two-message HTTP-based protocol: the Client sends a TokenRequest and the Issuer returns a TokenResponse. Two variants are defined—privately verifiable (OPRF-based) and publicly verifiable (blind RSA-based).
VOPRF token verification requires the Issuer Private Key: create a VOPRF server context, compute Evaluate(token_type || nonce || challenge_digest || token_key_id) using skI, and compare the result against Token.authenticator.
IANA has registered three media types: application/private-token-issuer-directory, application/private-token-request, and application/private-token-response, all used in Privacy Pass HTTP issuance exchanges.
IANA has registered token type 0x0001 (VOPRF(P-384, SHA-384)) in the Privacy Pass Token Types registry: not publicly verifiable, no public or private metadata, Nk=48, Nid=32, key encoded via SerializeElement.
IANA has registered token type 0x0002 (Blind RSA, 2048-bit) in the Privacy Pass Token Types registry: publicly verifiable, Nk=256, Nid=32, key encoded as DER-encoded SPKI with RSASSA-PSS OID; supports RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic.
IANA has registered well-known URI suffix 'private-token-issuer-directory' (permanent, change controller: IETF) for locating the Privacy Pass Issuer directory resource.
All security properties established by VOPRF (RFC 9497) and blind RSA (RFC 9474) carry over to the Privacy Pass use case. Notable cross-cutting concerns include Issuer Public Key rotation, key consistency (as described in the key-consistency draft), and Issuer selection.
Privacy and security concerns in multi-Client, multi-Issuer settings are addressed in the architecture document RFC 9576: deployment-model-dependent considerations in Sections 4–5 and deployment-model-independent considerations in Section 6.
The Blind RSA TokenRequest (type 0x0002) contains: token_type (2 octets = 0x0002), truncated_token_key_id (1 octet, least-significant byte of SHA256(DER-encoded SPKI)), and blinded_msg (Nk=256 octets, the blind RSA blinded message from Blind(pkI, PrepareIdentity(token_input))).
The Blind RSA TokenResponse contains a single field: blind_sig (Nk=256 octets), the blind RSA signature computed by BlindSign(skI, TokenRequest.blinded_msg).
The Token structure (both protocols) contains: token_type (2 octets), nonce (32 octets, random), challenge_digest (32 octets, SHA256 of challenge), token_key_id (32 octets), and authenticator (Nk octets; Nk=48 for VOPRF, 256 for Blind RSA).
The VOPRF TokenRequest (type 0x0001) contains: token_type (2 octets = 0x0001), truncated_token_key_id (1 octet, least-significant byte of SHA256(SerializeElement(pkI))), and blinded_msg (Ne octets, the serialized blinded OPRF element).
The VOPRF TokenResponse contains: evaluate_msg (Ne octets, serialized evaluated OPRF element) and evaluate_proof (Ns+Ns octets, two serialized VOPRF proof scalars concatenated). For OPRF(P-384, SHA-384), Ne=49 and Ns=48.