RFC 9578: Privacy Pass Issuance Protocols
- S. Celi,
- A. Davidson,
- S. Valdez,
- C. A. Wood
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 Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2024 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://
1. Introduction
The Privacy Pass protocol provides a privacy
This document describes two issuance protocols for Privacy Pass, each of which is built on [HTTP]. It specifies two variants: one that is privately verifiable using the Issuer Private Key based on the Oblivious Pseudorandom Function (OPRF) as defined in [OPRF] and one that is publicly verifiable using the Issuer Public Key based on the blind RSA signature scheme [BLINDRSA]. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol.¶
This document does not cover the Privacy Pass architecture, which
includes (1) choices that are necessary for deployment and (2) application
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terms "Origin", "Client", "Issuer", and "Token" as defined in Section 2 of [ARCHITECTURE]. Moreover, the following additional terms are used throughout this document.¶
- Issuer Public Key:
- The public key (from a private-public key pair) used by the Issuer for issuing and verifying tokens.¶
- Issuer Private Key:
- The private key (from a private-public key pair) used by the Issuer for issuing and verifying tokens.¶
Unless otherwise specified, this document encodes protocol messages in TLS notation ([TLS13], Section 3). Moreover, all constants are in network byte order.¶
3. Protocol Overview
The issuance protocols defined in this document embody the core of Privacy Pass. Clients receive TokenChallenge inputs from the redemption protocol ([AUTHSCHEME], Section 2.1) and use the issuance protocols to produce corresponding token values ([AUTHSCHEME], Section 2.2). The issuance protocol describes how Clients and Issuers interact to compute a token using a one-round protocol consisting of a TokenRequest from the Client and a TokenResponse from the Issuer. This interaction is shown below.¶
The TokenChallenge inputs to the issuance protocols described in this document can be interactive or non-interactive and can be per Origin or across Origins.¶
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 Issuer Private Key based on the OPRF [OPRF] and one that is publicly verifiable (Section 6) using the Issuer Public Key based on the blind RSA signature scheme [BLINDRSA].¶
4. Configuration
Issuers MUST provide two parameters for configuration:¶
- Issuer Request URL:
- A token request URL for generating access tokens.
For example, an Issuer Request URL might be
<https://
issuer .example .net /request> . ¶ - 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.¶
Each "token-keys" JSON object contains the fields and corresponding raw values defined in Table 2.¶
Each "token-keys" JSON object may also contain the optional field "not-before". The value of this field is the UNIX timestamp (number of seconds since January 1, 1970, UTC -- see Section 4.2.1 of [TIMESTAMP]) at which the key can be used. If this field is present, Clients SHOULD NOT use a token key before this timestamp, as doing so can lead to issuance failures. The purpose of this field is to assist in scheduled key rotations.¶
Beyond staging keys with the "not-before" value, Issuers MAY advertise multiple "token-keys" for the same token-type to facilitate key rotation. In this case, Issuers indicate their 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 verifications 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
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 directory so the TokenChallenge defined in Section 2.1 of [AUTHSCHEME] can be differentiated correctly.¶
Issuers SHOULD use HTTP cache directives to permit caching of this resource [RFC5861]. The cache lifetime depends on the Issuer's key rotation schedule. Regular rotation of token keys is recommended to minimize the risk of key compromise and any harmful effects that happen due to key compromise.¶
Issuers can control the cache lifetime with the Cache-Control header, as follows:¶
Consumers of the Issuer directory resource SHOULD follow the usual HTTP caching semantics [RFC9111] when processing this resource. Long cache lifetimes may result in the use of stale Issuer configuration information, whereas short lifetimes may result in decreased performance. When the use of an Issuer configuration results in token issuance failures, e.g., because the Issuer has invalidated its directory resource before its expiration time and issuance requests using this configuration are unsuccessful, the directory SHOULD be fetched and revalidated. Issuance will continue to fail until the Issuer configuration is updated.¶
5. Issuance Protocol for Privately Verifiable Tokens
The privately verifiable issuance protocol allows Clients to produce token values that verify using the Issuer Private Key. This protocol is based on the OPRF [OPRF].¶
Issuers provide an Issuer Private Key and Public Key, denoted skI and pkI, respectively,
used to produce tokens as input to the protocol. See Section 5.5
for information about 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 ([ARCHITECTURE], Section 4.3), 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 hostname that can be used to construct HTTP requests to the Issuer.¶
- Issuer Public Key:
-
pkI, with a key identifiertoken_key_idcomputed as described in Section 5.5.¶ - Challenge value:
-
challenge-- an opaque byte string. For example, this might be provided by the redemption protocol described 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 Serialize
The constants Ne and Ns are as defined in
Section 4.4 ("OPRF(P-384, SHA-384)") of [OPRF]. For this protocol, the constant Nk, which is also equal to Nh as defined
in Section 4.4 of [OPRF], is defined by Section 8.2.1.¶
5.1. 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 defined in [OPRF]. Setup
The Client then creates an issuance request message for a random 32-byte nonce
with the input challenge and Issuer key identifier as described below:¶
The Blind function is discussed in
Sections 3.3.1 and 3.3.2 of [OPRF].
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:¶
The structure fields are defined as follows:¶
The values token_input and blinded_element are stored locally for use
when finalizing the issuance protocol to produce a token (as described in Section 5.3). The Client then generates an HTTP
POST request to send to the Issuer Request URL, with the TokenRequest as the
content. The media type for this request is
"application
5.2. Issuer-to-Client Response
Upon receipt of the request, the Issuer validates the following conditions:¶
If any of these conditions are 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
Tokenblinded_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 [OPRF], Section 3.2, and BlindEvaluate is defined in [OPRF], Section 3.3.2. The Issuer then creates a TokenResponse structured as follows:¶
The structure fields are defined as follows:¶
The Issuer generates an HTTP response with status code 200 whose content
consists of TokenResponse, with the content type set as
"application
5.3. Finalization
Upon receipt, the Client handles the response and, if successful, deserializes
the content values Tokenevaluated 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 [OPRF], Section 3.3.2. If this succeeds, the Client then constructs a token as follows:¶
The Token.nonce value is the value that was created according to Section 5.4. If the Finalize function fails, the Client aborts the protocol.¶
5.4. Token Verification
Verifying a token requires creating a Verifiable Oblivious Pseudorandom Function (VOPRF) context using the Issuer Private Key and Public Key, evaluating the token contents, and comparing the result against the token authenticator value:¶
5.5. Issuer Configuration
Issuers are configured with Issuer Private Keys 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 [OPRF], Section 3.2.1.
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 forms 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 wrong Issuer Private Key. A possible exception to this constraint
would be a colliding key that is still in use but is in the process of being
rotated out, in which case the collision cannot reasonably be avoided; however, this situation is expected to be transient.¶
6. Issuance Protocol for Publicly Verifiable Tokens
This section describes a variant of the issuance protocol discussed in Section 5
for producing publicly verifiable tokens using the protocol defined in [BLINDRSA].
In particular, this variant of the issuance protocol works for the
RSABSSA
The publicly verifiable issuance protocol differs from the protocol defined in Section 5 in that the output tokens are publicly verifiable by anyone with the Issuer Public Key. This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer Public Key, without explicit coordination or permission from the Issuer. This is because the Issuer does not learn the Origin that requested the token during the issuance protocol.¶
Beyond this difference, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance protocol variant. In particular, Issuers provide an Issuer Private Key and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol. See Section 6.5 for information about 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 ([ARCHITECTURE], Section 4.4), 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 hostname that can be used to construct HTTP requests to the Issuer.¶
- Issuer Public Key:
-
pkI, with a key identifiertoken_key_idcomputed as described in Section 6.5.¶ - Challenge value:
-
challenge-- an opaque byte string. For example, this might be provided by the redemption protocol described in [AUTHSCHEME].¶
Given this configuration and these inputs, the two messages exchanged in
this protocol are described below. For this protocol, the constant Nk is defined by
Section 8.2.2.¶
6.1. Client-to-Issuer Request
The Client first creates an issuance request message for a random 32-byte
nonce using the input challenge and Issuer key identifier as follows:¶
The PrepareIdentity and Blind functions are defined in
Sections 4.1 and 4.2 of [BLINDRSA], respectively.
The Client stores the nonce and challenge
The Client then creates a TokenRequest structured as follows:¶
The structure fields are defined as follows:¶
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
6.2. Issuer-to-Client Response
Upon receipt of the request, the Issuer validates the following conditions:¶
If any of these conditions are 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 Section 4.3 of [BLINDRSA]. 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
6.3. Finalization
Upon receipt, the Client handles the response and, if successful, processes the content as follows:¶
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:¶
The Token.nonce value is the value that was sampled according to Section 6.1. If the Finalize function fails, the Client aborts the protocol.¶
6.4. Token Verification
Verifying a token requires checking that TokenRSASSA is defined in Section 8.1.2 of [RFC8017],
using SHA-384 as the hash function, MGF1 with SHA-384 as the Probabilistic Signature Scheme (PSS) mask
generation function (MGF), and a 48-byte salt length (sLen).¶
6.5. Issuer Configuration
Issuers are configured with Issuer Private Keys and Public Keys, each denoted skI and pkI, respectively, used to produce tokens. Each key SHALL be generated securely -- for example, as specified in FIPS 186-5 [DSS]. These keys MUST NOT be reused in other protocols.¶
The key identifier for an Issuer Private Key and Public Key (skI, pkI),
denoted token_key_id, is computed as SHA256
An example sequence of the SPKI object (in ASN.1 format, with the actual public key bytes truncated) for a 2048-bit key is shown below:¶
Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD
ensure that the truncated forms 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 wrong Issuer Private Key. A possible exception to this constraint
would be a colliding key that is still in use but is in the process of being
rotated out, in which case the collision cannot reasonably be avoided; however, this
situation is expected to be transient.¶
7. Security Considerations
This document outlines how to instantiate the issuance protocol based on the VOPRF defined in [OPRF] and the 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 covered in the architecture document [ARCHITECTURE]. In particular, Sections 4 and 5 of [ARCHITECTURE] discuss relevant privacy considerations influenced by the Privacy Pass deployment models, and Section 6 of [ARCHITECTURE] discusses privacy considerations that apply regardless of deployment model. Notable considerations include those pertaining to Issuer Public Key rotation and consistency -- where consistency is as described in [CONSISTENCY] -- and Issuer selection.¶
8. IANA Considerations
8.1. Well-Known "private-token-issuer-directory" URI
IANA has updated the "Well-Known URIs" registry [WellKnownURIs] with the following values.¶
8.2. Privacy Pass Token Types
IANA has updated the "Privacy Pass Token Types" registry [Priv
8.2.1. Token Type VOPRF(P-384, SHA-384)
- Value:
- 0x0001¶
- Name:
- VOPRF(P-384, SHA-384)¶
- Token Structure:
- As defined in Section 2.2 of [AUTHSCHEME].¶
- Token Key Encoding:
- Serialized using Serialize
Element (Section 2.1 of [OPRF]).¶ - TokenChallenge Structure:
- As defined in Section 2.1 of [AUTHSCHEME].¶
- Publicly Verifiable:
- N¶
- Public Metadata:
- N¶
- Private Metadata:
- N¶
- Nk:
- 48¶
- Nid:
- 32¶
- Change controller:
- IETF¶
- Reference:
- RFC 9578, Section 5¶
- Notes:
- None¶
8.2.2. Token Type Blind RSA (2048-bit)
- Value:
- 0x0002¶
- Name:
- Blind RSA (2048-bit)¶
- Token Structure:
- As defined in Section 2.2 of [AUTHSCHEME].¶
- Token Key Encoding:
- Serialized as a DER-encoded Subject
Public Key Info (SPKI) object using the RSASSA-PSS OID [RFC5756].¶ - TokenChallenge Structure:
- As defined in Section 2.1 of [AUTHSCHEME].¶
- Publicly Verifiable:
- Y¶
- Public Metadata:
- N¶
- Private Metadata:
- N¶
- Nk:
- 256¶
- Nid:
- 32¶
- Change controller:
- IETF¶
- Reference:
- RFC 9578, Section 6¶
- Notes:
- The RSABSSA
-SHA384 -PSS -Deterministic and RSABSSA -SHA384 -PSSZERO -Deterministic variants are supported.¶
8.3. Media Types
IANA has added the following entries to the "Media Types" registry [MediaTypes]:¶
The templates for these entries are listed below. The reference is this RFC.¶
8.3.1. "application/private-token-issuer-directory" Media Type
- Type name:
-
application¶
- Subtype name:
-
private
-token -issuer -directory ¶ - Required parameters:
-
N/A¶
- Optional parameters:
-
N/A¶
- Encoding considerations:
-
binary¶
- Security considerations:
- Interoperability considerations:
-
N/A¶
- Published specification:
-
RFC 9578¶
- 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:
-
- Person & email address to contact for further information:
-
See the Authors' Addresses section of RFC 9578.¶
- Intended usage:
-
COMMON¶
- Restrictions on usage:
-
N/A¶
- Author:
-
See the Authors' Addresses section of RFC 9578.¶
- Change controller:
-
IETF¶
8.3.2. "application/private-token-request" Media Type
- Type name:
-
application¶
- Subtype name:
-
private
-token -request ¶ - Required parameters:
-
N/A¶
- Optional parameters:
-
N/A¶
- Encoding considerations:
-
binary¶
- Security considerations:
- Interoperability considerations:
-
N/A¶
- Published specification:
-
RFC 9578¶
- 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:
-
- Person & email address to contact for further information:
-
See the Authors' Addresses section of RFC 9578.¶
- Intended usage:
-
COMMON¶
- Restrictions on usage:
-
N/A¶
- Author:
-
See the Authors' Addresses section of RFC 9578.¶
- Change controller:
-
IETF¶
8.3.3. "application/private-token-response" Media Type
- Type name:
-
application¶
- Subtype name:
-
private
-token -response ¶ - Required parameters:
-
N/A¶
- Optional parameters:
-
N/A¶
- Encoding considerations:
-
binary¶
- Security considerations:
- Interoperability considerations:
-
N/A¶
- Published specification:
-
RFC 9578¶
- 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:
-
- Person & email address to contact for further information:
-
See the Authors' Addresses section of RFC 9578.¶
- Intended usage:
-
COMMON¶
- Restrictions on usage:
-
N/A¶
- Author:
-
See the Authors' Addresses section of RFC 9578.¶
- Change controller:
-
IETF¶
9. References
9.1. Normative References
- [ARCHITECTURE]
-
Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10
.17487 , , <https:///RFC9576 www >..rfc -editor .org /info /rfc9576 - [AUTHSCHEME]
-
Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass HTTP Authentication Scheme", RFC 9577, DOI 10
.17487 , , <https:///RFC9577 www >..rfc -editor .org /info /rfc9577 - [BLINDRSA]
-
Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind Signatures", RFC 9474, DOI 10
.17487 , , <https:///RFC9474 www >..rfc -editor .org /info /rfc9474 - [HTTP]
-
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10
.17487 , , <https:///RFC9110 www >..rfc -editor .org /info /rfc9110 - [MediaTypes]
-
IANA, "Media Types", <https://
www >..iana .org /assignments /media -types / - [OPRF]
-
Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", RFC 9497, DOI 10
.17487 , , <https:///RFC9497 www >..rfc -editor .org /info /rfc9497 - [Priv
Pass Token Types] -
IANA, "Privacy Pass Token Types", <https://
www >..iana .org /assignments /privacy -pass / - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC4648]
-
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10
.17487 , , <https:///RFC4648 www >..rfc -editor .org /info /rfc4648 - [RFC5756]
-
Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, DOI 10
.17487 , , <https:///RFC5756 www >..rfc -editor .org /info /rfc5756 - [RFC5861]
-
Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, DOI 10
.17487 , , <https:///RFC5861 www >..rfc -editor .org /info /rfc5861 - [RFC8017]
-
Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10
.17487 , , <https:///RFC8017 www >..rfc -editor .org /info /rfc8017 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8259]
-
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10
.17487 , , <https:///RFC8259 www >..rfc -editor .org /info /rfc8259 - [RFC9111]
-
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10
.17487 , , <https:///RFC9111 www >..rfc -editor .org /info /rfc9111 - [TIMESTAMP]
-
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Defining Packet Timestamps", RFC 8877, DOI 10
.17487 , , <https:///RFC8877 www >..rfc -editor .org /info /rfc8877 - [TLS13]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [WellKnownURIs]
-
IANA, "Well-Known URIs", <https://
www >..iana .org /assignments /well -known -uris /
9.2. Informative References
- [CONSISTENCY]
-
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, "Key Consistency and Discovery", Work in Progress, Internet-Draft, draft
-ietf , , <https://-privacypass -key -consistency -01 datatracker >..ietf .org /doc /html /draft -ietf -privacypass -key -consistency -01 - [DSS]
-
National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-5, DOI 10
.6028 , , <https:///NIST .FIPS .186 -5 doi >..org /10 .6028 /nist .fips .186 -5 - [RFC5280]
-
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10
.17487 , , <https:///RFC5280 www >..rfc -editor .org /info /rfc5280
Appendix A. Test Vectors
This section includes test vectors for the two basic issuance protocols specified in this document. Appendix A.1 contains test vectors for token issuance protocol 1 (0x0001), and Appendix A.2 contains test vectors for token issuance protocol 2 (0x0002).¶
A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384)
The test vectors below list the following values:¶
- skI:
- The Issuer Private Key, serialized using SerializeScalar ([OPRF], Section 2.1) and represented as a hexadecimal string.¶
- pkI:
- The Issuer Public Key, serialized according to the encoding in Section 8.2.1.¶
- token_challenge:
- A randomly generated TokenChallenge structure, represented as a hexadecimal string.¶
- nonce:
- The 32-byte Client nonce generated according to Section 5.1, represented as a hexadecimal string.¶
- blind:
- The blind used when computing the OPRF blinded message, serialized using SerializeScalar ([OPRF], Section 2.1) and represented as a hexadecimal string.¶
- token_request:
- The TokenRequest message constructed according to Section 5.1, represented as a hexadecimal string.¶
- token_response:
- The TokenResponse message constructed according to Section 5.2, represented as a hexadecimal string.¶
- token:
- The output token from the protocol, represented as a hexadecimal string.¶
A.2. Issuance Protocol 2 - Blind RSA (2048-bit)
The test vectors below list the following values:¶
- skI:
- The PEM-encoded PKCS #8 RSA Issuer Private Key used for signing tokens, represented as a hexadecimal string.¶
- pkI:
- The Issuer Public Key, serialized according to the encoding in Section 8.2.2.¶
- token_challenge:
- A randomly generated TokenChallenge structure, represented as a hexadecimal string.¶
- nonce:
- The 32-byte Client nonce generated according to Section 6.1, represented as a hexadecimal string.¶
- blind:
- The blind used when computing the blind RSA blinded message, represented as a hexadecimal string.¶
- salt:
- The randomly generated 48-byte salt used when encoding the blinded TokenRequest message, represented as a hexadecimal string.¶
- token_request:
- The TokenRequest message constructed according to Section 6.1, represented as a hexadecimal string.¶
- token_response:
- 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.¶
Acknowledgements
The authors of this document would like to acknowledge the helpful feedback and discussions from Benjamin Schwartz, Joseph Salowey, and Tara Whalen.¶