rfc9578.original   rfc9578.txt 
Network Working Group S. Celi Internet Engineering Task Force (IETF) S. Celi
Internet-Draft A. Davidson Request for Comments: 9578 Brave Software
Intended status: Standards Track Brave Software Category: Standards Track A. Davidson
Expires: 5 April 2024 S. Valdez ISSN: 2070-1721 NOVA LINCS, Universidade NOVA de Lisboa
S. Valdez
Google LLC Google LLC
C. A. Wood C. A. Wood
Cloudflare Cloudflare
3 October 2023 June 2024
Privacy Pass Issuance Protocol Privacy Pass Issuance Protocols
draft-ietf-privacypass-protocol-16
Abstract Abstract
This document specifies two variants of the two-message issuance This document specifies two variants of the two-message issuance
protocol for Privacy Pass tokens: one that produces tokens that are protocol for Privacy Pass tokens: one that produces tokens that are
privately verifiable using the issuance private key, and another that privately verifiable using the Issuer Private Key and one that
produces tokens that are publicly verifiable using the issuance produces tokens that are publicly verifiable using the Issuer Public
public key. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 5 April 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9578.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview
4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Configuration
5. Issuance Protocol for Privately Verifiable Tokens . . . . . . 8 5. Issuance Protocol for Privately Verifiable Tokens
5.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 9 5.1. Client-to-Issuer Request
5.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 10 5.2. Issuer-to-Client Response
5.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Finalization
5.4. Token Verification . . . . . . . . . . . . . . . . . . . 12 5.4. Token Verification
5.5. Issuer Configuration . . . . . . . . . . . . . . . . . . 12 5.5. Issuer Configuration
6. Issuance Protocol for Publicly Verifiable Tokens . . . . . . 13 6. Issuance Protocol for Publicly Verifiable Tokens
6.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 14 6.1. Client-to-Issuer Request
6.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 15 6.2. Issuer-to-Client Response
6.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Finalization
6.4. Token Verification . . . . . . . . . . . . . . . . . . . 16 6.4. Token Verification
6.5. Issuer Configuration . . . . . . . . . . . . . . . . . . 17 6.5. Issuer Configuration
7. Security considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations
8.1. Well-Known 'private-token-issuer-directory' URI . . . . . 18 8.1. Well-Known "private-token-issuer-directory" URI
8.2. Token Type Registry Updates . . . . . . . . . . . . . . . 19 8.2. Privacy Pass Token Types
8.2.1. Token Type VOPRF (P-384, SHA-384) . . . . . . . . . . 19 8.2.1. Token Type VOPRF(P-384, SHA-384)
8.2.2. Token Type Blind RSA (2048-bit) . . . . . . . . . . . 19 8.2.2. Token Type Blind RSA (2048-bit)
8.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 20 8.3. Media Types
8.3.1. "application/private-token-issuer-directory" media 8.3.1. "application/private-token-issuer-directory" Media Type
type . . . . . . . . . . . . . . . . . . . . . . . . 20 8.3.2. "application/private-token-request" Media Type
8.3.2. "application/private-token-request" media type . . . 21 8.3.3. "application/private-token-response" Media Type
8.3.3. "application/private-token-response" media type . . . 21 9. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Test Vectors
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384)
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 24 A.2. Issuance Protocol 2 - Blind RSA (2048-bit)
B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) . . . . . . . 24 Acknowledgements
B.2. Issuance Protocol 2 - Blind RSA, 2048 . . . . . . . . . . 27 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The Privacy Pass protocol provides a privacy-preserving authorization The Privacy Pass protocol provides a privacy-preserving authorization
mechanism. In essence, the protocol allows clients to provide mechanism. In essence, the protocol allows Clients to provide
cryptographic tokens that prove nothing other than that they have cryptographic tokens that prove nothing other than that they have
been created by a given server in the past [ARCHITECTURE]. been created by a given server in the past [ARCHITECTURE].
This document describes the issuance protocol for Privacy Pass built This document describes two issuance protocols for Privacy Pass, each
on [HTTP]. It specifies two variants: one that is privately of which is built on [HTTP]. It specifies two variants: one that is
verifiable using the issuance private key based on the oblivious privately verifiable using the Issuer Private Key based on the
pseudorandom function from [OPRF], and one that is publicly Oblivious Pseudorandom Function (OPRF) as defined in [OPRF] and one
verifiable using the issuance public key based on the blind RSA that is publicly verifiable using the Issuer Public Key based on the
signature scheme [BLINDRSA]. 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, including This document does not cover the Privacy Pass architecture, which
choices that are necessary for deployment and application specific includes (1) choices that are necessary for deployment and (2)
choices for protecting client privacy. This information is covered application-specific choices for protecting Client privacy. This
in [ARCHITECTURE]. information is covered in [ARCHITECTURE].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terms Origin, Client, Issuer, and Token as This document uses the terms "Origin", "Client", "Issuer", and
defined in Section 2 of [ARCHITECTURE]. Moreover, the following "Token" as defined in Section 2 of [ARCHITECTURE]. Moreover, the
additional terms are used throughout this document. following additional terms are used throughout this document.
* Issuer Public Key: The public key (from a private-public key pair) Issuer Public Key: The public key (from a private-public key pair)
used by the Issuer for issuing and verifying Tokens. used by the Issuer for issuing and verifying tokens.
* Issuer Private Key: The private key (from a private-public key Issuer Private Key: The private key (from a private-public key pair)
pair) used by the Issuer for issuing and verifying Tokens. used by the Issuer for issuing and verifying tokens.
Unless otherwise specified, this document encodes protocol messages Unless otherwise specified, this document encodes protocol messages
in TLS notation from Section 3 of [TLS13]. Moreover, all constants in TLS notation ([TLS13], Section 3). Moreover, all constants are in
are in network byte order. network byte order.
3. Protocol Overview 3. Protocol Overview
The issuance protocols defined in this document embody the core of The issuance protocols defined in this document embody the core of
Privacy Pass. Clients receive TokenChallenge inputs from the Privacy Pass. Clients receive TokenChallenge inputs from the
redemption protocol ([AUTHSCHEME], Section 2.1) and use the issuance redemption protocol ([AUTHSCHEME], Section 2.1) and use the issuance
protocols to produce corresponding Token values ([AUTHSCHEME], protocols to produce corresponding token values ([AUTHSCHEME],
Section 2.2). The issuance protocol describes how Clients and Section 2.2). The issuance protocol describes how Clients and
Issuers interact to compute a token using a one-round protocol Issuers interact to compute a token using a one-round protocol
consisting of a TokenRequest from the Client and TokenResponse from consisting of a TokenRequest from the Client and a TokenResponse from
the Issuer. This interaction is shown below. the Issuer. This interaction is shown below.
+--------+ +--------+ +----------+ +--------+ +--------+ +--------+ +----------+ +--------+
| Origin | | Client | | Attester | | Issuer | | Origin | | Client | | Attester | | Issuer |
+---+----+ +---+----+ +----+-----+ +---+----+ +---+----+ +---+----+ +----+-----+ +---+----+
| | | | | | | |
|<----- Request ------+ | | |<----- Request ------+ | |
+-- TokenChallenge -->| | | +-- TokenChallenge -->| | |
| |<== Attestation ==>| | | |<== Attestation ==>| |
| | | | | | | |
| +--------- TokenRequest ------->| | +--------- TokenRequest ------->|
| |<-------- TokenResponse -------+ | |<-------- TokenResponse -------+
|<-- Request+Token ---+ | | |<-- Request+Token ---+ | |
| | | | | | | |
Figure 1: Issuance Overview Figure 1: Issuance Overview
The TokenChallenge inputs to the issuance protocols described in this The TokenChallenge inputs to the issuance protocols described in this
document can be interactive or non-interactive, and per-origin or document can be interactive or non-interactive and can be per Origin
cross-origin. or across Origins.
The issuance protocols defined in this document are compatible with The issuance protocols defined in this document are compatible with
any deployment model defined in Section 4 of [ARCHITECTURE]. The any deployment model defined in Section 4 of [ARCHITECTURE]. The
details of attestation are outside the scope of the issuance details of attestation are outside the scope of the issuance
protocol; see Section 4 of [ARCHITECTURE] for information about how protocol; see Section 4 of [ARCHITECTURE] for information about how
attestation can be implemented in each of the relevant deployment attestation can be implemented in each of the relevant deployment
models. models.
This document describes two variants of the issuance protocol: one This document describes two variants of the issuance protocol: one
that is privately verifiable (Section 5) using the issuance private that is privately verifiable (Section 5) using the Issuer Private Key
key based on the oblivious pseudorandom function from [OPRF], and one based on the OPRF [OPRF] and one that is publicly verifiable
that is publicly verifiable (Section 6) using the issuance public key (Section 6) using the Issuer Public Key based on the blind RSA
based on the blind RSA signature scheme [BLINDRSA]. signature scheme [BLINDRSA].
4. Configuration 4. Configuration
Issuers MUST provide two parameters for configuration: Issuers MUST provide two parameters for configuration:
1. Issuer Request URL: A token request URL for generating access Issuer Request URL: A token request URL for generating access
tokens. For example, an Issuer URL might be tokens. For example, an Issuer Request URL might be
https://issuer.example.net/request. <https://issuer.example.net/request>.
2. Issuer Public Key values: A list of Issuer Public Keys for the Issuer Public Key values: A list of Issuer Public Keys for the
issuance protocol. issuance protocol.
The Issuer parameters can be obtained from an Issuer via a directory The Issuer parameters can be obtained from an Issuer via a directory
object, which is a JSON object ([RFC8259], Section 4) whose values object, which is a JSON object ([RFC8259], Section 4) whose values
are other JSON values ([RFC8259], Section 3) for the parameters. The are other JSON values ([RFC8259], Section 3) for the parameters. The
contents of this JSON object are defined in Table 1. contents of this JSON object are defined in Table 1.
+====================+======================================+ +====================+======================================+
| Field Name | Value | | Field Name | Value |
+====================+======================================+ +====================+======================================+
| issuer-request-uri | Issuer Request URL value (as an | | issuer-request-uri | Issuer Request URL value (as an |
| | absolute URL, or a URL relative to | | | absolute URL or as a URL relative to |
| | the directory object) as a percent- | | | the directory object) as a percent- |
| | encoded URL string, represented as a | | | encoded URL string, represented as a |
| | JSON string ([RFC8259], Section 7) | | | JSON string ([RFC8259], Section 7) |
+--------------------+--------------------------------------+ +--------------------+--------------------------------------+
| token-keys | List of Issuer Public Key values, | | token-keys | List of Issuer Public Key values, |
| | each represented as JSON objects | | | each represented as JSON objects |
| | ([RFC8259], Section 4) | | | ([RFC8259], Section 4) |
+--------------------+--------------------------------------+ +--------------------+--------------------------------------+
Table 1: Issuer directory object description Table 1: Issuer Directory Object Description
Each "token-keys" JSON object contains the fields and corresponding Each "token-keys" JSON object contains the fields and corresponding
raw values defined in Table 2. raw values defined in Table 2.
+============+====================================================+ +============+=====================================================+
| Field Name | Value | | Field Name | Value |
+============+====================================================+ +============+=====================================================+
| token-type | Integer value of the Token Type, as defined in | | token-type | Integer value of the token type, as defined in |
| | Section 8.2, represented as a JSON number | | | Section 8.2, represented as a JSON number |
| | ([RFC8259], Section 6) | | | ([RFC8259], Section 6) |
+------------+----------------------------------------------------+ +------------+-----------------------------------------------------+
| token-key | The base64url-encoded [RFC4648] Public Key for use | | token-key | The base64url public key, encoded per [RFC4648], |
| | with the issuance protocol as determined by the | | | for use with the issuance protocol as determined by |
| | token-type field, including padding, represented | | | the token-type field, including padding, |
| | as a JSON string ([RFC8259], Section 7) | | | represented as a JSON string ([RFC8259], Section 7) |
+------------+----------------------------------------------------+ +------------+-----------------------------------------------------+
Table 2: Issuer 'token-keys' object description' Table 2: Issuer "token-keys" Object Description
Each "token-keys" JSON object may also contain the optional field Each "token-keys" JSON object may also contain the optional field
"not-before". The value of this field is the UNIX timestamp (number "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 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, [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 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 can lead to issuance failures. The purpose of this field is to
assist in scheduled key rotations. assist in scheduled key rotations.
Beyond staging keys with the "not-before" value, Issuers MAY Beyond staging keys with the "not-before" value, Issuers MAY
advertise multiple "token-keys" for the same token-type to facilitate advertise multiple "token-keys" for the same token-type to facilitate
key rotation. In this case, Issuers indicate preference for which key rotation. In this case, Issuers indicate their preference for
token key to use based on the order of keys in the list, with 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 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- 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 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 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 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. to verify tokens, starting with the most preferred key in the list.
Trial verification like this can help deal with Client clock skew. Trial verifications like this can help deal with Client clock skew.
Altogether, the Issuer's directory could look like the following Altogether, the Issuer's directory could look like the following
(with the "token-key" fields abbreviated): (with the "token-key" fields abbreviated):
{ {
"issuer-request-uri": "https://issuer.example.net/request", "issuer-request-uri": "https://issuer.example.net/request",
"token-keys": [ "token-keys": [
{ {
"token-type": 2, "token-type": 2,
"token-key": "MI...AB", "token-key": "MI...AB",
skipping to change at page 7, line 5 skipping to change at line 274
Clients that use this directory resource before 1686913811 in UNIX Clients that use this directory resource before 1686913811 in UNIX
time would use the second key in the "token-keys" list, whereas time would use the second key in the "token-keys" list, whereas
Clients that use this directory after 1686913811 in UNIX time would Clients that use this directory after 1686913811 in UNIX time would
use the first key in the "token-keys" list. use the first key in the "token-keys" list.
A complete "token-key" value, encoded as it would be in the Issuer A complete "token-key" value, encoded as it would be in the Issuer
directory, would look like the following (line breaks are inserted to directory, would look like the following (line breaks are inserted to
fit within the per-line character limits): fit within the per-line character limits):
$ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDAL \ $ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQE \
BglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr_DhZAPhJM7 \ BCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr \
Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTvW6SKCh7ZPXEqCGR \ _DhZAPhJM7Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTv \
sq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWbjf21iaVjXJ2VdwdS-8O- \ W6SKCh7ZPXEqCGRsq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWb \
430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuID9OQm1nxfs1Z4PhWBzt93T2oz \ jf21iaVjXJ2VdwdS-8O-430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuI \
Tnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99aA-muXRFN4ZUwORrF7cAcCUD_-56_6 \ D9OQm1nxfs1Z4PhWBzt93T2ozTnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99 \
fh9s34FmqBGwIDAQAB \ aA-muXRFN4ZUwORrF7cAcCUD_-56_6fh9s34FmqBGwIDAQAB \
| sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \ | sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \
| openssl asn1parse -dump -inform DER | openssl asn1parse -dump -inform DER
0:d=0 hl=4 l= 338 cons: SEQUENCE 0:d=0 hl=4 l= 338 cons: SEQUENCE
4:d=1 hl=2 l= 61 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss
17:d=2 hl=2 l= 48 cons: SEQUENCE 17:d=2 hl=2 l= 48 cons: SEQUENCE
19:d=3 hl=2 l= 13 cons: cont [ 0 ] 19:d=3 hl=2 l= 13 cons: cont [ 0 ]
21:d=4 hl=2 l= 11 cons: SEQUENCE 21:d=4 hl=2 l= 11 cons: SEQUENCE
23:d=5 hl=2 l= 9 prim: OBJECT :sha384 23:d=5 hl=2 l= 9 prim: OBJECT :sha384
34:d=3 hl=2 l= 26 cons: cont [ 1 ] 34:d=3 hl=2 l= 26 cons: cont [ 1 ]
skipping to change at page 7, line 34 skipping to change at line 303
49:d=5 hl=2 l= 11 cons: SEQUENCE 49:d=5 hl=2 l= 11 cons: SEQUENCE
51:d=6 hl=2 l= 9 prim: OBJECT :sha384 51:d=6 hl=2 l= 9 prim: OBJECT :sha384
62:d=3 hl=2 l= 3 cons: cont [ 2 ] 62:d=3 hl=2 l= 3 cons: cont [ 2 ]
64:d=4 hl=2 l= 1 prim: INTEGER :30 64:d=4 hl=2 l= 1 prim: INTEGER :30
67:d=1 hl=4 l= 271 prim: BIT STRING 67:d=1 hl=4 l= 271 prim: BIT STRING
... truncated public key bytes ... ... truncated public key bytes ...
Issuer directory resources have the media type "application/private- Issuer directory resources have the media type "application/private-
token-issuer-directory" and are located at the well-known location token-issuer-directory" and are located at the well-known location
/.well-known/private-token-issuer-directory; see Section 8.1 for the /.well-known/private-token-issuer-directory; see Section 8.1 for the
registration information for this well-known URI. The reason that registration information for this well-known URI. This resource is
this resource is located at a well-known URI is that Issuers are located at a well-known URI because Issuers are defined by an Origin
defined by an origin name in TokenChallenge structures; see name in TokenChallenge structures; see Section 2.1 of [AUTHSCHEME].
Section 2.1 of [AUTHSCHEME].
The Issuer directory and Issuer resources SHOULD be available on the The Issuer directory and Issuer resources SHOULD be available on the
same origin. If an Issuer wants to service multiple different Issuer same Origin. If an Issuer wants to service multiple different Issuer
directories they MUST create unique subdomains for each so the directories, they MUST create unique subdomains for each directory so
TokenChallenge defined in Section 2.1 of [AUTHSCHEME] can be the TokenChallenge defined in Section 2.1 of [AUTHSCHEME] can be
differentiated correctly. differentiated correctly.
Issuers SHOULD use HTTP cache directives to permit caching of this Issuers SHOULD use HTTP cache directives to permit caching of this
resource [RFC5861]. The cache lifetime depends on the Issuer's key resource [RFC5861]. The cache lifetime depends on the Issuer's key
rotation schedule. Regular rotation of token keys is recommended to rotation schedule. Regular rotation of token keys is recommended to
minimize the risk of key compromise and any harmful effects that minimize the risk of key compromise and any harmful effects that
happen due to key compromise. happen due to key compromise.
Issuers can control cache lifetime with the Cache-Control header, as Issuers can control the cache lifetime with the Cache-Control header,
follows: as follows:
Cache-Control: max-age=86400 Cache-Control: max-age=86400
Consumers of the Issuer directory resource SHOULD follow the usual Consumers of the Issuer directory resource SHOULD follow the usual
HTTP caching [RFC9111] semantics when processing this resource. Long HTTP caching semantics [RFC9111] when processing this resource. Long
cache lifetimes may result in use of stale Issuer configuration cache lifetimes may result in the use of stale Issuer configuration
information, whereas short lifetimes may result in decreased information, whereas short lifetimes may result in decreased
performance. When use of an Issuer configuration results in token performance. When the use of an Issuer configuration results in
issuance failures, e.g., because the Issuer has invalidated its token issuance failures, e.g., because the Issuer has invalidated its
directory resource before its expiration time and issuance requests directory resource before its expiration time and issuance requests
using this configuration are unsuccessful, the directory SHOULD be using this configuration are unsuccessful, the directory SHOULD be
fetched and revalidated. Issuance will continue to fail until the fetched and revalidated. Issuance will continue to fail until the
Issuer configuration is updated. Issuer configuration is updated.
5. Issuance Protocol for Privately Verifiable Tokens 5. Issuance Protocol for Privately Verifiable Tokens
The privately verifiable issuance protocol allows Clients to produce The privately verifiable issuance protocol allows Clients to produce
Token values that verify using the Issuer Private Key. This protocol token values that verify using the Issuer Private Key. This protocol
is based on the oblivious pseudorandom function from [OPRF]. is based on the OPRF [OPRF].
Issuers provide a Issuer Private and Public Key, denoted skI and pkI Issuers provide an Issuer Private Key and Public Key, denoted skI and
respectively, used to produce tokens as input to the protocol. See pkI, respectively, used to produce tokens as input to the protocol.
Section 5.5 for how these keys are generated. See Section 5.5 for information about how these keys are generated.
Clients provide the following as input to the issuance protocol: Clients provide the following as input to the issuance protocol:
* Issuer Request URL: A URL identifying the location to which Issuer Request URL: A URL identifying the location to which issuance
issuance requests are sent. This can be a URL derived from the requests are sent. This can be a URL derived from the "issuer-
"issuer-request-uri" value in the Issuer's directory resource, or request-uri" value in the Issuer's directory resource, or it can
it can be another Client-configured URL. The value of this be another Client-configured URL. The value of this parameter
parameter depends on the Client configuration and deployment depends on the Client configuration and deployment model. For
model. For example, in the 'Joint Origin and Issuer' deployment example, in the "Joint Origin and Issuer" deployment model
model, the Issuer Request URL might correspond to the Client's ([ARCHITECTURE], Section 4.3), the Issuer Request URL might
configured Attester, and the Attester is configured to relay correspond to the Client's configured Attester, and the Attester
requests to the Issuer. is configured to relay requests to the Issuer.
* Issuer name: An identifier for the Issuer. This is typically a Issuer name: An identifier for the Issuer. This is typically a
host name that can be used to construct HTTP requests to the hostname that can be used to construct HTTP requests to the
Issuer. Issuer.
* Issuer Public Key: pkI, with a key identifier token_key_id Issuer Public Key: pkI, with a key identifier token_key_id computed
computed as described in Section 5.5. as described in Section 5.5.
* Challenge value: challenge, an opaque byte string. For example, Challenge value: challenge -- an opaque byte string. For example,
this might be provided by the redemption protocol in [AUTHSCHEME]. this might be provided by the redemption protocol described in
[AUTHSCHEME].
Given this configuration and these inputs, the two messages exchanged Given this configuration and these inputs, the two messages exchanged
in this protocol are described below. This section uses notation in this protocol are described below. This section uses notation
described in [OPRF], Section 4, including SerializeElement and described in [OPRF], Section 4, including SerializeElement and
DeserializeElement, SerializeScalar and DeserializeScalar, and DeserializeElement, SerializeScalar and DeserializeScalar, and
DeriveKeyPair. DeriveKeyPair.
The constants Ne and Ns are as defined in [OPRF], Section 4 for The constants Ne and Ns are as defined in Section 4.4 ("OPRF(P-384,
OPRF(P-384, SHA-384). The constant Nk, which is also equal to Nh as SHA-384)") of [OPRF]. For this protocol, the constant Nk, which is
defined in [OPRF], Section 4, is defined by Section 8.2.1. 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 5.1. Client-to-Issuer Request
The Client first creates a context as follows: The Client first creates a context as follows:
client_context = SetupVOPRFClient("P384-SHA384", pkI) client_context = SetupVOPRFClient("P384-SHA384", pkI)
Here, "P384-SHA384" is the identifier corresponding to the Here, "P384-SHA384" is the identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in [OPRF]. SetupVOPRFClient is OPRF(P-384, SHA-384) ciphersuite defined in [OPRF]. SetupVOPRFClient
defined in [OPRF], Section 3.2. is defined in [OPRF], Section 3.2.
The Client then creates an issuance request message for a random The Client then creates an issuance request message for a random
32-byte value nonce with the input challenge and Issuer key 32-byte nonce with the input challenge and Issuer key identifier as
identifier as described below: described below:
nonce = random(32) nonce = random(32)
challenge_digest = SHA256(challenge) challenge_digest = SHA256(challenge)
token_input = concat(0x0001, // Token type field is 2 bytes long token_input = concat(0x0001, // token-type field is 2 bytes long
nonce, nonce,
challenge_digest, challenge_digest,
token_key_id) token_key_id)
blind, blinded_element = client_context.Blind(token_input) blind, blinded_element = client_context.Blind(token_input)
The Blind function is defined in [OPRF], Section 3.3.2. If the Blind The Blind function is discussed in Sections 3.3.1 and 3.3.2 of
function fails, the Client aborts the protocol. The Client stores [OPRF]. If the Blind function fails, the Client aborts the protocol.
the nonce and challenge_digest values locally for use when finalizing The Client stores the nonce and challenge_digest values locally for
the issuance protocol to produce a token (as described in use when finalizing the issuance protocol to produce a token (as
Section 5.3). described in Section 5.3).
The Client then creates a TokenRequest structured as follows: The Client then creates a TokenRequest structured as follows:
struct { struct {
uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */
uint8_t truncated_token_key_id; uint8_t truncated_token_key_id;
uint8_t blinded_msg[Ne]; uint8_t blinded_msg[Ne];
} TokenRequest; } TokenRequest;
The structure fields are defined as follows: The structure fields are defined as follows:
* "token_type" is a 2-octet integer, which matches the type in the * "token_type" is a 2-octet integer, which matches the type in the
challenge. challenge.
* "truncated_token_key_id" is the least significant byte of the * "truncated_token_key_id" is the least significant byte of the
token_key_id (Section 5.5) in network byte order (in other words, token_key_id (Section 5.5) in network byte order (in other words,
the last 8 bits of token_key_id). This value is truncated so that 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 Issuers cannot use token_key_id as a way of uniquely identifying
Clients; see Section 7 and referenced information for more Clients; see referenced information from Section 7 for more
details. details.
* "blinded_msg" is the Ne-octet blinded message defined above, * "blinded_msg" is the Ne-octet blinded message defined above,
computed as SerializeElement(blinded_element). computed as SerializeElement(blinded_element).
The values token_input and blinded_element are stored locally and The values token_input and blinded_element are stored locally for use
used later as described in Section 5.3. The Client then generates an when finalizing the issuance protocol to produce a token (as
HTTP POST request to send to the Issuer Request URL, with the described in Section 5.3). The Client then generates an HTTP POST
TokenRequest as the content. The media type for this request is request to send to the Issuer Request URL, with the TokenRequest as
"application/private-token-request". An example request for the the content. The media type for this request is "application/
Issuer Request URL "https://issuer.example.net/request" is shown private-token-request". An example request for the Issuer Request
below. URL "https://issuer.example.net/request" is shown below.
POST /request HTTP/1.1 POST /request HTTP/1.1
Host: issuer.example.net Host: issuer.example.net
Accept: application/private-token-response Accept: application/private-token-response
Content-Type: application/private-token-request Content-Type: application/private-token-request
Content-Length: <Length of TokenRequest> Content-Length: <Length of TokenRequest>
<Bytes containing the TokenRequest> <Bytes containing the TokenRequest>
5.2. Issuer-to-Client Response 5.2. Issuer-to-Client Response
Upon receipt of the request, the Issuer validates the following Upon receipt of the request, the Issuer validates the following
conditions: conditions:
* The TokenRequest contains a supported token_type. * The TokenRequest contains a supported token_type.
* The TokenRequest.truncated_token_key_id corresponds to the * The TokenRequest.truncated_token_key_id corresponds to the
truncated key ID of a Public Key owned by the Issuer. truncated key ID of a public key owned by the Issuer.
* The TokenRequest.blinded_msg is of the correct size. * The TokenRequest.blinded_msg is of the correct size.
If any of these conditions is not met, the Issuer MUST return an HTTP If any of these conditions are not met, the Issuer MUST return an
422 (Unprocessable Content) error to the client. HTTP 422 (Unprocessable Content) error to the Client.
If these conditions are met, the Issuer then tries to deserialize If these conditions are met, the Issuer then tries to deserialize
TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of TokenRequest.blinded_msg using DeserializeElement ([OPRF],
[OPRF], yielding blinded_element. If this fails, the Issuer MUST Section 2.1), yielding blinded_element. If this fails, the Issuer
return an HTTP 422 (Unprocessable Content) error to the client. MUST return an HTTP 422 (Unprocessable Content) error to the Client.
Otherwise, if the Issuer is willing to produce a token 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 the Issuer completes the issuance flow by computing a blinded
response as follows: response as follows:
server_context = SetupVOPRFServer("P384-SHA384", skI) server_context = SetupVOPRFServer("P384-SHA384", skI)
evaluate_element, proof = evaluate_element, proof =
server_context.BlindEvaluate(skI, pkI, blinded_element) server_context.BlindEvaluate(skI, pkI, blinded_element)
SetupVOPRFServer is defined in [OPRF], Section 3.2 and BlindEvaluate SetupVOPRFServer is defined in [OPRF], Section 3.2, and BlindEvaluate
is defined in [OPRF], Section 3.3.2. The Issuer then creates a is defined in [OPRF], Section 3.3.2. The Issuer then creates a
TokenResponse structured as follows: TokenResponse structured as follows:
struct { struct {
uint8_t evaluate_msg[Ne]; uint8_t evaluate_msg[Ne];
uint8_t evaluate_proof[Ns+Ns]; uint8_t evaluate_proof[Ns+Ns];
} TokenResponse; } TokenResponse;
The structure fields are defined as follows: The structure fields are defined as follows:
skipping to change at page 12, line 6 skipping to change at line 515
TokenResponse.evaluate_proof, yielding evaluated_element and proof. TokenResponse.evaluate_proof, yielding evaluated_element and proof.
If deserialization of either value fails, the Client aborts the If deserialization of either value fails, the Client aborts the
protocol. Otherwise, the Client processes the response as follows: protocol. Otherwise, the Client processes the response as follows:
authenticator = client_context.Finalize(token_input, blind, authenticator = client_context.Finalize(token_input, blind,
evaluated_element, evaluated_element,
blinded_element, blinded_element,
proof) proof)
The Finalize function is defined in [OPRF], Section 3.3.2. If this The Finalize function is defined in [OPRF], Section 3.3.2. If this
succeeds, the Client then constructs a Token as follows: succeeds, the Client then constructs a token as follows:
struct { struct {
uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */
uint8_t nonce[32]; uint8_t nonce[32];
uint8_t challenge_digest[32]; uint8_t challenge_digest[32];
uint8_t token_key_id[32]; uint8_t token_key_id[32];
uint8_t authenticator[Nk]; uint8_t authenticator[Nk];
} Token; } Token;
The Token.nonce value is that which was created in Section 5.1. If The Token.nonce value is the value that was created according to
the Finalize function fails, the Client aborts the protocol. Section 5.4. If the Finalize function fails, the Client aborts the
protocol.
5.4. Token Verification 5.4. Token Verification
Verifying a Token requires creating a VOPRF context using the Issuer Verifying a token requires creating a Verifiable Oblivious
Private Key and Public Key, evaluating the token contents, and Pseudorandom Function (VOPRF) context using the Issuer Private Key
comparing the result against the token authenticator value: and Public Key, evaluating the token contents, and comparing the
result against the token authenticator value:
server_context = SetupVOPRFServer("P384-SHA384", skI) server_context = SetupVOPRFServer("P384-SHA384", skI)
token_authenticator_input = token_authenticator_input =
concat(Token.token_type, concat(Token.token_type,
Token.nonce, Token.nonce,
Token.challenge_digest, Token.challenge_digest,
Token.token_key_id) Token.token_key_id)
token_authenticator = token_authenticator =
server_context.Evaluate(token_authenticator_input) server_context.Evaluate(token_authenticator_input)
valid = (token_authenticator == Token.authenticator) valid = (token_authenticator == Token.authenticator)
5.5. Issuer Configuration 5.5. Issuer Configuration
Issuers are configured with Issuer Private and Public Keys, each Issuers are configured with Issuer Private Keys and Public Keys, each
denoted skI and pkI, respectively, used to produce tokens. These denoted skI and pkI, respectively, used to produce tokens. These
keys MUST NOT be reused in other protocols. A RECOMMENDED method for keys MUST NOT be reused in other protocols. A RECOMMENDED method for
generating keys is as follows: generating keys is as follows:
seed = random(Ns) seed = random(Ns)
(skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass")
The DeriveKeyPair function is defined in [OPRF], Section 3.3.1. The The DeriveKeyPair function is defined in [OPRF], Section 3.2.1. The
key identifier for a public key pkI, denoted token_key_id, is key identifier for a public key pkI, denoted token_key_id, is
computed as follows: computed as follows:
token_key_id = SHA256(SerializeElement(pkI)) token_key_id = SHA256(SerializeElement(pkI))
Since Clients truncate token_key_id in each TokenRequest, Issuers Since Clients truncate token_key_id in each TokenRequest, Issuers
SHOULD ensure that the truncated form of new key IDs do not collide SHOULD ensure that the truncated forms of new key IDs do not collide
with other truncated key IDs in rotation. Collisions can cause the with other truncated key IDs in rotation. Collisions can cause the
Issuer to use the wrong Issuer Private Key for issuance, which will 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 in turn cause the resulting tokens to be invalid. There is no known
security consequence of using the the wrong Issuer Private Key. A security consequence of using the wrong Issuer Private Key. A
possible exception to this constraint would be a colliding key that possible exception to this constraint would be a colliding key that
is still in use but in the process of being rotated out, in which is still in use but is in the process of being rotated out, in which
case the collision cannot reasonably be avoided but it is expected to case the collision cannot reasonably be avoided; however, this
be transient. situation is expected to be transient.
6. Issuance Protocol for Publicly Verifiable Tokens 6. Issuance Protocol for Publicly Verifiable Tokens
This section describes a variant of the issuance protocol in This section describes a variant of the issuance protocol discussed
Section 5 for producing publicly verifiable tokens using the protocol in Section 5 for producing publicly verifiable tokens using the
in [BLINDRSA]. In particular, this variant of the issuance protocol protocol defined in [BLINDRSA]. In particular, this variant of the
works for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384- issuance protocol works for the RSABSSA-SHA384-PSS-Deterministic and
PSSZERO-Deterministic blind RSA protocol variants described in RSABSSA-SHA384-PSSZERO-Deterministic blind RSA protocol variants
Section 5 of [BLINDRSA]. described in Section 5 of [BLINDRSA].
The publicly verifiable issuance protocol differs from the protocol The publicly verifiable issuance protocol differs from the protocol
in Section 5 in that the output tokens are publicly verifiable by defined in Section 5 in that the output tokens are publicly
anyone with the Issuer Public Key. This means any Origin can select a verifiable by anyone with the Issuer Public Key. This means any
given Issuer to produce tokens, as long as the Origin has the Issuer Origin can select a given Issuer to produce tokens, as long as the
public key, without explicit coordination or permission from the Origin has the Issuer Public Key, without explicit coordination or
Issuer. This is because the Issuer does not learn the Origin that permission from the Issuer. This is because the Issuer does not
requested the token during the issuance protocol. learn the Origin that requested the token during the issuance
protocol.
Beyond this difference, the publicly verifiable issuance protocol Beyond this difference, the publicly verifiable issuance protocol
variant is nearly identical to the privately verifiable issuance variant is nearly identical to the privately verifiable issuance
protocol variant. In particular, Issuers provide an Issuer Private protocol variant. In particular, Issuers provide an Issuer Private
and Public Key, denoted skI and pkI, respectively, used to produce Key and Public Key, denoted skI and pkI, respectively, used to
tokens as input to the protocol. See Section 6.5 for how these keys produce tokens as input to the protocol. See Section 6.5 for
are generated. information about how these keys are generated.
Clients provide the following as input to the issuance protocol: Clients provide the following as input to the issuance protocol:
* Issuer Request URL: A URL identifying the location to which Issuer Request URL: A URL identifying the location to which issuance
issuance requests are sent. This can be a URL derived from the requests are sent. This can be a URL derived from the "issuer-
"issuer-request-uri" value in the Issuer's directory resource, or request-uri" value in the Issuer's directory resource, or it can
it can be another Client-configured URL. The value of this be another Client-configured URL. The value of this parameter
parameter depends on the Client configuration and deployment depends on the Client configuration and deployment model. For
model. For example, in the 'Split Origin, Attester, Issuer' example, in the "Split Origin, Attester, Issuer" deployment model
deployment model, the Issuer Request URL might correspond to the ([ARCHITECTURE], Section 4.4), the Issuer Request URL might
Client's configured Attester, and the Attester is configured to correspond to the Client's configured Attester, and the Attester
relay requests to the Issuer. is configured to relay requests to the Issuer.
* Issuer name: An identifier for the Issuer. This is typically a Issuer name: An identifier for the Issuer. This is typically a
host name that can be used to construct HTTP requests to the hostname that can be used to construct HTTP requests to the
Issuer. Issuer.
* Issuer Public Key: pkI, with a key identifier token_key_id Issuer Public Key: pkI, with a key identifier token_key_id computed
computed as described in Section 6.5. as described in Section 6.5.
* Challenge value: challenge, an opaque byte string. For example, Challenge value: challenge -- an opaque byte string. For example,
this might be provided by the redemption protocol in [AUTHSCHEME]. this might be provided by the redemption protocol described in
[AUTHSCHEME].
Given this configuration and these inputs, the two messages exchanged Given this configuration and these inputs, the two messages exchanged
in this protocol are described below. The constant Nk is defined by in this protocol are described below. For this protocol, the
Section 8.2.2. constant Nk is defined by Section 8.2.2.
6.1. Client-to-Issuer Request 6.1. Client-to-Issuer Request
The Client first creates an issuance request message for a random The Client first creates an issuance request message for a random
32-byte value nonce using the input challenge and Issuer key 32-byte nonce using the input challenge and Issuer key identifier as
identifier as follows: follows:
nonce = random(32) nonce = random(32)
challenge_digest = SHA256(challenge) challenge_digest = SHA256(challenge)
token_input = concat(0x0002, // Token type field is 2 bytes long token_input = concat(0x0002, // token-type field is 2 bytes long
nonce, nonce,
challenge_digest, challenge_digest,
token_key_id) token_key_id)
blinded_msg, blind_inv = blinded_msg, blind_inv =
Blind(pkI, PrepareIdentity(token_input)) Blind(pkI, PrepareIdentity(token_input))
The PrepareIdentity and Blind functions are defined in Section 4.1 of The PrepareIdentity and Blind functions are defined in Sections 4.1
[BLINDRSA] and Section 4.2 of [BLINDRSA], respectively. The Client and 4.2 of [BLINDRSA], respectively. The Client stores the nonce and
stores the nonce and challenge_digest values locally for use when challenge_digest values locally for use when finalizing the issuance
finalizing the issuance protocol to produce a token (as described in protocol to produce a token (as described in Section 6.3).
Section 6.3).
The Client then creates a TokenRequest structured as follows: The Client then creates a TokenRequest structured as follows:
struct { struct {
uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */
uint8_t truncated_token_key_id; uint8_t truncated_token_key_id;
uint8_t blinded_msg[Nk]; uint8_t blinded_msg[Nk];
} TokenRequest; } TokenRequest;
The structure fields are defined as follows: The structure fields are defined as follows:
* "token_type" is a 2-octet integer, which matches the type in the * "token_type" is a 2-octet integer, which matches the type in the
challenge. challenge.
* "truncated_token_key_id" is the least significant byte of the * "truncated_token_key_id" is the least significant byte of the
token_key_id (Section 6.5) in network byte order (in other words, token_key_id (Section 6.5) in network byte order (in other words,
the last 8 bits of token_key_id). This value is truncated so that 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 Issuers cannot use token_key_id as a way of uniquely identifying
Clients; see Section 7 and referenced information for more Clients; see referenced information from Section 7 for more
details. details.
* "blinded_msg" is the Nk-octet request defined above. * "blinded_msg" is the Nk-octet request defined above.
The Client then generates an HTTP POST request to send to the Issuer The Client then generates an HTTP POST request to send to the Issuer
Request URL, with the TokenRequest as the content. The media type Request URL, with the TokenRequest as the content. The media type
for this request is "application/private-token-request". An example for this request is "application/private-token-request". An example
request for the Issuer Request URL "https://issuer.example.net/ request for the Issuer Request URL "https://issuer.example.net/
request" is shown below. request" is shown below.
skipping to change at page 15, line 40 skipping to change at line 693
Upon receipt of the request, the Issuer validates the following Upon receipt of the request, the Issuer validates the following
conditions: conditions:
* The TokenRequest contains a supported token_type. * The TokenRequest contains a supported token_type.
* The TokenRequest.truncated_token_key_id corresponds to the * The TokenRequest.truncated_token_key_id corresponds to the
truncated key ID of an Issuer Public Key. truncated key ID of an Issuer Public Key.
* The TokenRequest.blinded_msg is of the correct size. * The TokenRequest.blinded_msg is of the correct size.
If any of these conditions is not met, the Issuer MUST return an HTTP If any of these conditions are not met, the Issuer MUST return an
422 (Unprocessable Content) error to the Client. Otherwise, if the HTTP 422 (Unprocessable Content) error to the Client. Otherwise, if
Issuer is willing to produce a token to the Client, the Issuer the Issuer is willing to produce a token to the Client, the Issuer
completes the issuance flow by computing a blinded response as completes the issuance flow by computing a blinded response as
follows: follows:
blind_sig = BlindSign(skI, TokenRequest.blinded_msg) blind_sig = BlindSign(skI, TokenRequest.blinded_msg)
The BlindSign function is defined in Section 4.3 of [BLINDRSA]. The The BlindSign function is defined in Section 4.3 of [BLINDRSA]. The
result is encoded and transmitted to the client in the following result is encoded and transmitted to the Client in the following
TokenResponse structure: TokenResponse structure:
struct { struct {
uint8_t blind_sig[Nk]; uint8_t blind_sig[Nk];
} TokenResponse; } TokenResponse;
The Issuer generates an HTTP response with status code 200 whose The Issuer generates an HTTP response with status code 200 whose
content consists of TokenResponse, with the content type set as content consists of TokenResponse, with the content type set as
"application/private-token-response". "application/private-token-response".
skipping to change at page 16, line 25 skipping to change at line 725
Content-Length: <Length of TokenResponse> Content-Length: <Length of TokenResponse>
<Bytes containing the TokenResponse> <Bytes containing the TokenResponse>
6.3. Finalization 6.3. Finalization
Upon receipt, the Client handles the response and, if successful, Upon receipt, the Client handles the response and, if successful,
processes the content as follows: processes the content as follows:
authenticator = authenticator =
Finalize(pkI, nonce, blind_sig, blind_inv) Finalize(pkI, PrepareIdentity(token_input), blind_sig, blind_inv)
The Finalize function is defined in Section 4.4 of [BLINDRSA]. If The Finalize function is defined in Section 4.4 of [BLINDRSA]. If
this succeeds, the Client then constructs a Token as described in this succeeds, the Client then constructs a token as described in
[AUTHSCHEME] as follows: [AUTHSCHEME] as follows:
struct { struct {
uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */
uint8_t nonce[32]; uint8_t nonce[32];
uint8_t challenge_digest[32]; uint8_t challenge_digest[32];
uint8_t token_key_id[32]; uint8_t token_key_id[32];
uint8_t authenticator[Nk]; uint8_t authenticator[Nk];
} Token; } Token;
The Token.nonce value is that which was sampled in Section 5.1. If The Token.nonce value is the value that was sampled according to
the Finalize function fails, the Client aborts the protocol. Section 6.1. If the Finalize function fails, the Client aborts the
protocol.
6.4. Token Verification 6.4. Token Verification
Verifying a Token requires checking that Token.authenticator is a Verifying a token requires checking that Token.authenticator is a
valid signature over the remainder of the token input using the valid signature over the remainder of the token input using the
Issuer Public Key. The function RSASSA-PSS-VERIFY is defined in 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 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 with SHA-384 as the Probabilistic Signature Scheme (PSS) mask
salt length (sLen). generation function (MGF), and a 48-byte salt length (sLen).
token_authenticator_input = token_authenticator_input =
concat(Token.token_type, concat(Token.token_type,
Token.nonce, Token.nonce,
Token.challenge_digest, Token.challenge_digest,
Token.token_key_id) Token.token_key_id)
valid = RSASSA-PSS-VERIFY(pkI, valid = RSASSA-PSS-VERIFY(pkI,
token_authenticator_input, token_authenticator_input,
Token.authenticator) Token.authenticator)
6.5. Issuer Configuration 6.5. Issuer Configuration
Issuers are configured with Issuer Private and Public Keys, each Issuers are configured with Issuer Private Keys and Public Keys, each
denoted skI and pkI, respectively, used to produce tokens. Each key denoted skI and pkI, respectively, used to produce tokens. Each key
SHALL be generated securely, for example as specified in FIPS 186-5 SHALL be generated securely -- for example, as specified in FIPS
[DSS]. These keys MUST NOT be reused in other protocols. 186-5 [DSS]. These keys MUST NOT be reused in other protocols.
The key identifier for an Issuer Private and Public Key (skI, pkI), The key identifier for an Issuer Private Key and Public Key (skI,
denoted token_key_id, is computed as SHA256(encoded_key), where pkI), denoted token_key_id, is computed as SHA256(encoded_key), where
encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object
object carrying pkI as a DER-encoded RSAPublicKey value [RFC5756] in [RFC5280] carrying pkI as a DER-encoded RSAPublicKey value [RFC5756]
the subjectPublicKey field. Additionally, the SPKI object MUST use in the subjectPublicKey field. Additionally, (1) the SPKI object
the id-RSASSA-PSS object identifier in the algorithm field within the MUST use the id-RSASSA-PSS object identifier in the algorithm field
SPKI object, the parameters field MUST contain a RSASSA-PSS-params within the SPKI object and (2) the parameters field MUST contain an
value, and MUST include the hashAlgorithm, maskGenAlgorithm, and RSASSA-PSS-params value and MUST include the hashAlgorithm,
saltLength values. The saltLength MUST match the output size of the maskGenAlgorithm, and saltLength values. The saltLength MUST match
hash function associated with the public key and token type. 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 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: actual public key bytes truncated) for a 2048-bit key is shown below:
$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER $ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER
0:d=0 hl=4 l= 338 cons: SEQUENCE 0:d=0 hl=4 l= 338 cons: SEQUENCE
4:d=1 hl=2 l= 61 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss
17:d=2 hl=2 l= 48 cons: SEQUENCE 17:d=2 hl=2 l= 48 cons: SEQUENCE
19:d=3 hl=2 l= 13 cons: cont [ 0 ] 19:d=3 hl=2 l= 13 cons: cont [ 0 ]
21:d=4 hl=2 l= 11 cons: SEQUENCE 21:d=4 hl=2 l= 11 cons: SEQUENCE
23:d=5 hl=2 l= 9 prim: OBJECT :sha384 23:d=5 hl=2 l= 9 prim: OBJECT :sha384
34:d=3 hl=2 l= 26 cons: cont [ 1 ] 34:d=3 hl=2 l= 26 cons: cont [ 1 ]
36:d=4 hl=2 l= 24 cons: SEQUENCE 36:d=4 hl=2 l= 24 cons: SEQUENCE
38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1
49:d=5 hl=2 l= 11 cons: SEQUENCE 49:d=5 hl=2 l= 11 cons: SEQUENCE
51:d=6 hl=2 l= 9 prim: OBJECT :sha384 51:d=6 hl=2 l= 9 prim: OBJECT :sha384
62:d=3 hl=2 l= 3 cons: cont [ 2 ] 62:d=3 hl=2 l= 3 cons: cont [ 2 ]
64:d=4 hl=2 l= 1 prim: INTEGER :30 64:d=4 hl=2 l= 1 prim: INTEGER :30
67:d=1 hl=4 l= 271 prim: BIT STRING 67:d=1 hl=4 l= 271 prim: BIT STRING
... truncated public key bytes ... ... truncated public key bytes ...
Since Clients truncate token_key_id in each TokenRequest, Issuers Since Clients truncate token_key_id in each TokenRequest, Issuers
SHOULD ensure that the truncated form of new key IDs do not collide SHOULD ensure that the truncated forms of new key IDs do not collide
with other truncated key IDs in rotation. Collisions can cause the with other truncated key IDs in rotation. Collisions can cause the
Issuer to use the wrong Issuer Private Key for issuance, which will 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 in turn cause the resulting tokens to be invalid. There is no known
security consequence of using the the wrong Issuer Private Key. A security consequence of using the wrong Issuer Private Key. A
possible exception to this constraint would be a colliding key that possible exception to this constraint would be a colliding key that
is still in use but in the process of being rotated out, in which is still in use but is in the process of being rotated out, in which
case the collision cannot reasonably be avoided but it is expected to case the collision cannot reasonably be avoided; however, this
be transient. situation is expected to be transient.
7. Security considerations 7. Security Considerations
This document outlines how to instantiate the Issuance protocol based This document outlines how to instantiate the issuance protocol based
on the VOPRF defined in [OPRF] and blind RSA protocol defined in on the VOPRF defined in [OPRF] and the blind RSA protocol defined in
[BLINDRSA]. All security considerations described in the VOPRF and [BLINDRSA]. All security considerations described in the VOPRF and
blind RSA documents also apply in the Privacy Pass use-case. blind RSA documents also apply in the Privacy Pass use case.
Considerations related to broader privacy and security concerns in a Considerations related to broader privacy and security concerns in a
multi-Client and multi-Issuer setting are deferred to the multi-Client and multi-Issuer setting are covered in the architecture
architecture document [ARCHITECTURE]. In particular, Section 4 and document [ARCHITECTURE]. In particular, Sections 4 and 5 of
Section 5 of [ARCHITECTURE] discuss relevant privacy considerations [ARCHITECTURE] discuss relevant privacy considerations influenced by
influenced by the Privacy Pass deployment model, and Section 6 of the Privacy Pass deployment models, and Section 6 of [ARCHITECTURE]
[ARCHITECTURE] discusses privacy considerations that apply regardless discusses privacy considerations that apply regardless of deployment
of deployment model. Notable considerations include those pertaining model. Notable considerations include those pertaining to Issuer
to Issuer Public Key rotation and consistency, where consistency is Public Key rotation and consistency -- where consistency is as
as described in [CONSISTENCY], and Issuer selection. described in [CONSISTENCY] -- and Issuer selection.
8. IANA considerations
This section contains considerations for IANA. 8. IANA Considerations
8.1. Well-Known 'private-token-issuer-directory' URI 8.1. Well-Known "private-token-issuer-directory" URI
This document updates the "Well-Known URIs" Registry [WellKnownURIs] IANA has updated the "Well-Known URIs" registry [WellKnownURIs] with
with the following values. the following values.
+===============+============+===========+===========+=============+ +===============+============+===========+===========+=============+
| URI Suffix | Change | Reference | Status | Related | | URI Suffix | Change | Reference | Status | Related |
| | Controller | | | information | | | Controller | | | Information |
+===============+============+===========+===========+=============+ +===============+============+===========+===========+=============+
| private- | IETF | [this | permanent | None | | private- | IETF | RFC 9578 | permanent | None |
| token-issuer- | | document] | | | | token-issuer- | | | | |
| directory | | | | | | directory | | | | |
+---------------+------------+-----------+-----------+-------------+ +---------------+------------+-----------+-----------+-------------+
Table 3: 'private-token-issuer-directory' Well-Known URI Table 3: "private-token-issuer-directory" Well-Known URI
8.2. Token Type Registry Updates
This document updates the "Privacy Pass Token Type" Registry with the
following entries.
8.2.1. Token Type VOPRF (P-384, SHA-384) 8.2. Privacy Pass Token Types
* Value: 0x0001 IANA has updated the "Privacy Pass Token Types" registry
[PrivPassTokenTypes] with the entries below.
* Name: VOPRF (P-384, SHA-384) 8.2.1. Token Type VOPRF(P-384, SHA-384)
* Token Structure: As defined in Section 2.2 of [AUTHSCHEME] Value: 0x0001
Name: VOPRF(P-384, SHA-384)
Token Structure: As defined in Section 2.2 of [AUTHSCHEME].
Token Key Encoding: Serialized using SerializeElement (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
* Token Key Encoding: Serialized using SerializeElement from 8.2.2. Token Type Blind RSA (2048-bit)
Section 2.1 of [OPRF]
* TokenChallenge Structure: As defined in Section 2.1 of Value: 0x0002
[AUTHSCHEME] Name: Blind RSA (2048-bit)
Token Structure: As defined in Section 2.2 of [AUTHSCHEME].
Token Key Encoding: Serialized as a DER-encoded SubjectPublicKeyInfo
(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.
* Public Verifiability: N 8.3. Media Types
* Public Metadata: N IANA has added the following entries to the "Media Types" registry
[MediaTypes]:
* Private Metadata: N * "application/private-token-issuer-directory"
* Nk: 48 * "application/private-token-request"
* Nid: 32 * "application/private-token-response"
* Reference: Section 5 The templates for these entries are listed below. The reference is
this RFC.
* Notes: None 8.3.1. "application/private-token-issuer-directory" Media Type
8.2.2. Token Type Blind RSA (2048-bit) Type name: application
* Value: 0x0002 Subtype name: private-token-issuer-directory
* Name: Blind RSA (2048-bit) Required parameters: N/A
* Token Structure: As defined in Section 2.2 of [AUTHSCHEME] Optional parameters: N/A
* Token Key Encoding: Serialized as a DER-encoded Encoding considerations: binary
SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID
[RFC5756]
* TokenChallenge Structure: As defined in Section 2.1 of Security considerations: See Section 7 of RFC 9578.
[AUTHSCHEME]
* Public Verifiability: Y Interoperability considerations: N/A
* Public Metadata: N Published specification: RFC 9578
* Private Metadata: N 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.
* Nk: 256 Fragment identifier considerations: N/A
* Nid: 32 Additional information:
* Reference: Section 6 Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
* Notes: The RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384- Person & email address to contact for further information: See the
PSSZERO-Deterministic variants are supported Authors' Addresses section of RFC 9578.
8.3. Media Types Intended usage: COMMON
The following entries should be added to the IANA "media types" Restrictions on usage: N/A
registry:
* "application/private-token-issuer-directory" Author: See the Authors' Addresses section of RFC 9578.
* "application/private-token-request" Change controller: IETF
* "application/private-token-response" 8.3.2. "application/private-token-request" Media Type
The templates for these entries are listed below and the reference Type name: application
should be this RFC.
8.3.1. "application/private-token-issuer-directory" media type Subtype name: private-token-request
Type name: application
Subtype name: private-token-issuer-directory
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 4
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 Aut
hors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IETF
8.3.2. "application/private-token-request" media type Encoding considerations: binary
Security considerations: See Section 7 of RFC 9578.
Type name: application
Subtype name: private-token-request
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 7
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: this specification
Published specification: RFC 9578
Applications that use this media type: Applications that want to Applications that use this media type: Applications that want to
issue or facilitate issuance of Privacy Pass tokens, including issue or facilitate issuance of Privacy Pass tokens, including
Privacy Pass issuer applications themselves. Privacy Pass Issuer applications themselves.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Magic number(s): N/A
Deprecated alias names for this type: N/A Additional information:
File extension(s): N/A
Macintosh file type code(s): N/A Deprecated alias names for this type: N/A
Person and email address to contact for further information: see Aut Magic number(s): N/A
hors' Addresses section File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the
Authors' Addresses section of RFC 9578.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: see Authors' Addresses section
Author: See the Authors' Addresses section of RFC 9578.
Change controller: IETF Change controller: IETF
8.3.3. "application/private-token-response" media type 8.3.3. "application/private-token-response" Media Type
Type name: application Type name: application
Subtype name: private-token-response Subtype name: private-token-response
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 7 Encoding considerations: binary
Security considerations: See Section 7 of RFC 9578.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: this specification
Published specification: RFC 9578
Applications that use this media type: Applications that want to Applications that use this media type: Applications that want to
issue or facilitate issuance of Privacy Pass tokens, including issue or facilitate issuance of Privacy Pass tokens, including
Privacy Pass issuer applications themselves. Privacy Pass Issuer applications themselves.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Magic number(s): N/A
Deprecated alias names for this type: N/A Additional information:
File extension(s): N/A
Macintosh file type code(s): N/A Deprecated alias names for this type: N/A
Person and email address to contact for further information: see Aut Magic number(s): N/A
hors' Addresses section File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the
Authors' Addresses section of RFC 9578.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: see Authors' Addresses section
Author: See the Authors' Addresses section of RFC 9578.
Change controller: IETF Change controller: IETF
9. References 9. References
9.1. Normative References 9.1. Normative References
[ARCHITECTURE] [ARCHITECTURE]
Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", Work in Progress, Internet-Draft, Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
draft-ietf-privacypass-architecture-16, 25 September 2023, 2024, <https://www.rfc-editor.org/info/rfc9576>.
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-architecture-16>.
[AUTHSCHEME] [AUTHSCHEME]
Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
HTTP Authentication Scheme", Work in Progress, Internet- HTTP Authentication Scheme", RFC 9577,
Draft, draft-ietf-privacypass-auth-scheme-14, 25 September DOI 10.17487/RFC9577, June 2024,
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- <https://www.rfc-editor.org/info/rfc9577>.
privacypass-auth-scheme-14>.
[BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind [BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind
Signatures", Work in Progress, Internet-Draft, draft-irtf- Signatures", RFC 9474, DOI 10.17487/RFC9474, October 2023,
cfrg-rsa-blind-signatures-14, 10 July 2023, <https://www.rfc-editor.org/info/rfc9474>.
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
rsa-blind-signatures-14>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://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. [OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) using Wood, "Oblivious Pseudorandom Functions (OPRFs) Using
Prime-Order Groups", Work in Progress, Internet-Draft, Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,
draft-irtf-cfrg-voprf-21, 21 February 2023, December 2023, <https://www.rfc-editor.org/info/rfc9497>.
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
voprf-21>. [PrivPassTokenTypes]
IANA, "Privacy Pass Token Types",
<https://www.iana.org/assignments/privacy-pass/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Updates for RSAES-OAEP and RSASSA-PSS Algorithm "Updates for RSAES-OAEP and RSASSA-PSS Algorithm
Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
<https://www.rfc-editor.org/rfc/rfc5756>. <https://www.rfc-editor.org/info/rfc5756>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/rfc/rfc5861>. <https://www.rfc-editor.org/info/rfc5861>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111, Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022, DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>. <https://www.rfc-editor.org/info/rfc9111>.
[TIMESTAMP] [TIMESTAMP]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877, Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020, DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/rfc/rfc8877>. <https://www.rfc-editor.org/info/rfc8877>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[WellKnownURIs] [WellKnownURIs]
"Well-Known URIs", n.d., IANA, "Well-Known URIs",
<https://www.iana.org/assignments/well-known-uris/well- <https://www.iana.org/assignments/well-known-uris/>.
known-uris.xhtml>.
9.2. Informative References 9.2. Informative References
[CONSISTENCY] [CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress, "Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-01, Internet-Draft, draft-ietf-privacypass-key-consistency-01,
10 July 2023, <https://datatracker.ietf.org/doc/html/ 10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-01>. draft-ietf-privacypass-key-consistency-01>.
[DSS] Moody, D. and National Institute of Standards and [DSS] National Institute of Standards and Technology, "Digital
Technology, "Digital Signature Standard (DSS)", Signature Standard (DSS)", NIST FIPS Publication 186-5,
DOI 10.6028/nist.fips.186-5, 2023, DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://doi.org/10.6028/nist.fips.186-5>. <https://doi.org/10.6028/nist.fips.186-5>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
Appendix A. Acknowledgements
The authors of this document would like to acknowledge the helpful
feedback and discussions from Benjamin Schwartz, Joseph Salowey, and
Tara Whalen.
Appendix B. Test Vectors Appendix A. Test Vectors
This section includes test vectors for the two basic issuance This section includes test vectors for the two basic issuance
protocols specified in this document. Appendix B.1 contains test protocols specified in this document. Appendix A.1 contains test
vectors for token issuance protocol 1 (0x0001), and Appendix B.2 vectors for token issuance protocol 1 (0x0001), and Appendix A.2
contains test vectors for token issuance protocol 2 (0x0002). contains test vectors for token issuance protocol 2 (0x0002).
B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384)
The test vector below lists the following values: The test vectors below list the following values:
* skS: The Issuer Private Key, serialized using SerializeScalar from skI: The Issuer Private Key, serialized using SerializeScalar
Section 2.1 of [OPRF] and represented as a hexadecimal string. ([OPRF], Section 2.1) and represented as a hexadecimal string.
* pkS: The Issuer Public Key, serialized according to the encoding pkI: The Issuer Public Key, serialized according to the encoding in
in Section 8.2.1. Section 8.2.1.
* token_challenge: A randomly generated TokenChallenge structure, token_challenge: A randomly generated TokenChallenge structure,
represented as a hexadecimal string. represented as a hexadecimal string.
* nonce: The 32-byte client nonce generated according to nonce: The 32-byte Client nonce generated according to Section 5.1,
Section 5.1, represented as a hexadecimal string. represented as a hexadecimal string.
* blind: The blind used when computing the OPRF blinded message, blind: The blind used when computing the OPRF blinded message,
serialized using SerializeScalar from Section 2.1 of [OPRF] and serialized using SerializeScalar ([OPRF], Section 2.1) and
represented as a hexadecimal string. represented as a hexadecimal string.
* token_request: The TokenRequest message constructed according to token_request: The TokenRequest message constructed according to
Section 5.1, represented as a hexadecimal string. Section 5.1, represented as a hexadecimal string.
* token_response: The TokenResponse message constructed according to token_response: The TokenResponse message constructed according to
Section 5.2, represented as a hexadecimal string. Section 5.2, represented as a hexadecimal string.
* token: The output Token from the protocol, represented as a token: The output token from the protocol, represented as a
hexadecimal string. hexadecimal string.
// Test vector 1 // Test vector 1
skS: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181 skI: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181
14910bee3c919bed1bbffe3fc1b87d53240a 14910bee3c919bed1bbffe3fc1b87d53240a
pkS: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c pkI: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c
21da1a46d42ca38f7beabdf05c074aee1455bf 21da1a46d42ca38f7beabdf05c074aee1455bf
token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc
daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696 daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696
7696e2e6578616d706c65 7696e2e6578616d706c65
nonce: nonce:
6aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05fafe73073b8 6aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05fafe73073b8
blind: 8e7fd80970b8a00b0931b801a2e22d9903d83bd5597c6a4dc1496ed2b1 blind: 8e7fd80970b8a00b0931b801a2e22d9903d83bd5597c6a4dc1496ed2b1
7ef820445ef3bd223f3ab2c4f54c5d1c956909 7ef820445ef3bd223f3ab2c4f54c5d1c956909
token_request: 0001f4030ab3e23181d1e213f24315f5775983c678ce22eff9 token_request: 0001f4030ab3e23181d1e213f24315f5775983c678ce22eff9
427610832ab3900f2cd12d6829a07ec8a6813cf0b5b886f4cc4979 427610832ab3900f2cd12d6829a07ec8a6813cf0b5b886f4cc4979
skipping to change at page 25, line 44 skipping to change at line 1196
34ea9660212c0c85fbadfbf491a1ce2446fc3379337fccd45c1059b2bc760110e 34ea9660212c0c85fbadfbf491a1ce2446fc3379337fccd45c1059b2bc760110e
e1ec227d8e01c9f482c00c47ffa0dbe2fb58c32dde2b1dbe69fff920a528e68dd e1ec227d8e01c9f482c00c47ffa0dbe2fb58c32dde2b1dbe69fff920a528e68dd
9b3c2483848e57c30542b8984fa6bfecd6d71d54d53eda 9b3c2483848e57c30542b8984fa6bfecd6d71d54d53eda
token: 00016aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05f token: 00016aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05f
afe73073b8501370b494089dc462802af545e63809581ee6ef57890a12105c283 afe73073b8501370b494089dc462802af545e63809581ee6ef57890a12105c283
68169514bf260d0792bf7f46c9866a6d37c3032d8714415f87f5f6903d7fb071e 68169514bf260d0792bf7f46c9866a6d37c3032d8714415f87f5f6903d7fb071e
253be2f4e0a835d76528b8444f73789ee7dc90715b01c17902fd87375c00a7a9d 253be2f4e0a835d76528b8444f73789ee7dc90715b01c17902fd87375c00a7a9d
3d92540437f470773be20f71e721da3af40edeb 3d92540437f470773be20f71e721da3af40edeb
// Test vector 2 // Test vector 2
skS: 39efed331527cc4ddff9722ab5cd35aeafe7c27520b0cfa2eedbdc298dc3 skI: 39efed331527cc4ddff9722ab5cd35aeafe7c27520b0cfa2eedbdc298dc3
b12bc8298afcc46558af1e2eeacc5307d865 b12bc8298afcc46558af1e2eeacc5307d865
pkS: 038017e005904c6146b37109d6c2a72b95a183aaa9ed951b8d8fb1ed9033 pkI: 038017e005904c6146b37109d6c2a72b95a183aaa9ed951b8d8fb1ed9033
f68033284d175e7df89849475cd67a86bfbf4e f68033284d175e7df89849475cd67a86bfbf4e
token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269 token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269
67696e2e6578616d706c65 67696e2e6578616d706c65
nonce: nonce:
7617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3190c29d665 7617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3190c29d665
blind: 6492ee50072fa18d035d69c4246362dffe2621afb95a10c033bb0109e0 blind: 6492ee50072fa18d035d69c4246362dffe2621afb95a10c033bb0109e0
f705b0437c425553272e0aa5266ec379e7015e f705b0437c425553272e0aa5266ec379e7015e
token_request: 000133033a5fe04a39da1bbfb68ccdeecd1917474dd525462e token_request: 000133033a5fe04a39da1bbfb68ccdeecd1917474dd525462e
5a90a6ba53b42aaa1486fe443a2e1c7f3fd5ff028a1c7cf1aeac5d 5a90a6ba53b42aaa1486fe443a2e1c7f3fd5ff028a1c7cf1aeac5d
token_response: 023bf8cd624880d669c5cc6c88b056355c6e8e1bcbf3746cf token_response: 023bf8cd624880d669c5cc6c88b056355c6e8e1bcbf3746cf
skipping to change at page 26, line 19 skipping to change at line 1220
bdf8bf3c926e10c7c12f934a887d86da4a4e5be70f5a169aa75720887bb690536 bdf8bf3c926e10c7c12f934a887d86da4a4e5be70f5a169aa75720887bb690536
92a8f11f9cda7a72f281e4e3568e848225367946c70db09e718e3cba16193987b 92a8f11f9cda7a72f281e4e3568e848225367946c70db09e718e3cba16193987b
c10bede3ef54c4d036c17cd4015bb113be60d7aa927e0d c10bede3ef54c4d036c17cd4015bb113be60d7aa927e0d
token: 00017617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3 token: 00017617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3
190c29d665c994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1 190c29d665c994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1
34bd5a62a116477bc9e1a205cca95d0c92335ca7a3e71063b2ac020bdd231c660 34bd5a62a116477bc9e1a205cca95d0c92335ca7a3e71063b2ac020bdd231c660
97f12333ef438d00801bca5ace0fab8eb483dc04cd62578b95b5652921cd2698c 97f12333ef438d00801bca5ace0fab8eb483dc04cd62578b95b5652921cd2698c
45ea74f6c8827b4e19f01140fa5bd039866f562 45ea74f6c8827b4e19f01140fa5bd039866f562
// Test vector 3 // Test vector 3
skS: 2b7709595b62b784f14946ae828f65e6caeba6eefe732c86e9ae50e818c0 skI: 2b7709595b62b784f14946ae828f65e6caeba6eefe732c86e9ae50e818c0
55b3d7ca3a5f2beecaa859a62ff7199d35cc 55b3d7ca3a5f2beecaa859a62ff7199d35cc
pkS: 03a0de1bf3fd0a73384283b648884ba9fa5dee190f9d7ad4292c2fd49d8b pkI: 03a0de1bf3fd0a73384283b648884ba9fa5dee190f9d7ad4292c2fd49d8b
4d64db674059df67f5bd7e626475c78934ae8d 4d64db674059df67f5bd7e626475c78934ae8d
token_challenge: 0001000e6973737565722e6578616d706c65000017666f6f token_challenge: 0001000e6973737565722e6578616d706c65000017666f6f
2e6578616d706c652c6261722e6578616d706c65 2e6578616d706c652c6261722e6578616d706c65
nonce: nonce:
87499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c28aa7d3a9df 87499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c28aa7d3a9df
blind: 1f659584626ba15f44f3d887b2e5fe4c27315b185dfbfaea4253ebba30 blind: 1f659584626ba15f44f3d887b2e5fe4c27315b185dfbfaea4253ebba30
610c4d9b73c78714c142360e85a00942c0fcff 610c4d9b73c78714c142360e85a00942c0fcff
token_request: 0001c8024610a9f3aac21090f3079d6809437a2b94b4403c7e token_request: 0001c8024610a9f3aac21090f3079d6809437a2b94b4403c7e
645f849bc6c505dade154c258c8ecd4d2bdcf574daca65db671908 645f849bc6c505dade154c258c8ecd4d2bdcf574daca65db671908
token_response: 03c2ab925d03e7793b4a4df6eb505210139f620359e142449 token_response: 03c2ab925d03e7793b4a4df6eb505210139f620359e142449
skipping to change at page 26, line 43 skipping to change at line 1244
ff8829e27aaf7eb2cc7f9ab655477d71c01d5da5aef44dd076b5820b4710ef025 ff8829e27aaf7eb2cc7f9ab655477d71c01d5da5aef44dd076b5820b4710ef025
a9e6c6b50a95af6105c5987c1b834d615008cf6370556ed00c6671e69776c09a9 a9e6c6b50a95af6105c5987c1b834d615008cf6370556ed00c6671e69776c09a9
2b5ac84804750dd867c78817bdf69f1443002b18ae7a52 2b5ac84804750dd867c78817bdf69f1443002b18ae7a52
token: 000187499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c2 token: 000187499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c2
8aa7d3a9df1949fd455872478ba87e2e6c513c3261cddbe57220581245e4c9c91 8aa7d3a9df1949fd455872478ba87e2e6c513c3261cddbe57220581245e4c9c91
1dd1c0bb865785bff8f3cfe08cccbb3a7b8e41d23a172871be4828cc54582d87b 1dd1c0bb865785bff8f3cfe08cccbb3a7b8e41d23a172871be4828cc54582d87b
c7cfc5c8bcedc1868ebc845b000c317ed75312274a42b10be6db23bd8a168fd2f c7cfc5c8bcedc1868ebc845b000c317ed75312274a42b10be6db23bd8a168fd2f
021c23925d72c4d14cd7588c03845da0d41a326 021c23925d72c4d14cd7588c03845da0d41a326
// Test vector 4 // Test vector 4
skS: 22e237b7b983d77474e4495aff2fc1e10422b1d955192e0fbf2b7b618fba skI: 22e237b7b983d77474e4495aff2fc1e10422b1d955192e0fbf2b7b618fba
625fcb94b599da9113da49c495a48fbf7f7f 625fcb94b599da9113da49c495a48fbf7f7f
pkS: 028cd68715caa20d19b2b20d017d6a0a42b9f2b0a47db65e5e763e23744f pkI: 028cd68715caa20d19b2b20d017d6a0a42b9f2b0a47db65e5e763e23744f
e14d74e374bbc93a2ec3970eb53c8aa765ee21 e14d74e374bbc93a2ec3970eb53c8aa765ee21
token_challenge: 0001000e6973737565722e6578616d706c65000000 token_challenge: 0001000e6973737565722e6578616d706c65000000
nonce: nonce:
02f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a89e820cd43 02f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a89e820cd43
blind: af91d1dbcf6b46baecde70eb305b8fe75629199cca19c7f9344b8607b9 blind: af91d1dbcf6b46baecde70eb305b8fe75629199cca19c7f9344b8607b9
0def27bc53e0345ade32c9fd0a1efda056d1c0 0def27bc53e0345ade32c9fd0a1efda056d1c0
token_request: 0001a503632ebb003ed15b6de4557c047c7f81a58688143331 token_request: 0001a503632ebb003ed15b6de4557c047c7f81a58688143331
2ad3ad7f9416f2dfc940d3f439ad1e8cd677d94ae7c05bc958d134 2ad3ad7f9416f2dfc940d3f439ad1e8cd677d94ae7c05bc958d134
token_response: 032018bc3f180d9650e27f72de76a90b47e336ae9cb058548 token_response: 032018bc3f180d9650e27f72de76a90b47e336ae9cb058548
d851c7046fa0875d96346c15cb39d8083cc6fb57216544c6a815c37d792769e12 d851c7046fa0875d96346c15cb39d8083cc6fb57216544c6a815c37d792769e12
9c0513ce2034c3286cb212548f4aed1b0f71b28e219a71874a93e53ab2f473282 9c0513ce2034c3286cb212548f4aed1b0f71b28e219a71874a93e53ab2f473282
71d1e9cbefc197a4f599a6825051fa1c6e55450042f04182b86c9cf12477a9f16 71d1e9cbefc197a4f599a6825051fa1c6e55450042f04182b86c9cf12477a9f16
849396c051fa27012e81a86e6c4a9204a063f1e1722dd7 849396c051fa27012e81a86e6c4a9204a063f1e1722dd7
token: 000102f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a token: 000102f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a
89e820cd43085cb06952044c7655b412ab7d484c97b97c48c79c568140b8d49a0 89e820cd43085cb06952044c7655b412ab7d484c97b97c48c79c568140b8d49a0
2ca47a9cfb0a5cfb861290c4dbd8fd9b60ee9b1a1a54cf47c98531fe253f1ed6d 2ca47a9cfb0a5cfb861290c4dbd8fd9b60ee9b1a1a54cf47c98531fe253f1ed6d
875de5a58f42db12b540b0d11bc5d6b42e6d17c2b73e98631e54d40fd2901ebec 875de5a58f42db12b540b0d11bc5d6b42e6d17c2b73e98631e54d40fd2901ebec
4268668535b03cbf76f7f15a29d623a64cab0c4 4268668535b03cbf76f7f15a29d623a64cab0c4
// Test vector 5 // Test vector 5
skS: 46f3d4f562002b85ffcfdb4d06835fb9b2e24372861ecaa11357fd1f29f9 skI: 46f3d4f562002b85ffcfdb4d06835fb9b2e24372861ecaa11357fd1f29f9
ed26e44715549ccedeb39257f095110f0159 ed26e44715549ccedeb39257f095110f0159
pkS: 02fbe9da0b7cabe3ec51c36c8487b10909142b59af030c728a5e87bb3b30 pkI: 02fbe9da0b7cabe3ec51c36c8487b10909142b59af030c728a5e87bb3b30
f54c06415d22e03d9212bd3d9a17d5520d4d0f f54c06415d22e03d9212bd3d9a17d5520d4d0f
token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc
daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b30000 daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b30000
nonce: nonce:
9ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e84483c90e89 9ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e84483c90e89
blind: 76e0938e824b6cda6c163ff55d0298d539e222ed3984f4e31bbb654a8c blind: 76e0938e824b6cda6c163ff55d0298d539e222ed3984f4e31bbb654a8c
59671d4e0a7e264ca758cd0f4b533e0f60c5aa 59671d4e0a7e264ca758cd0f4b533e0f60c5aa
token_request: 0001e10202bc92ac516c867f39399d71976018db52fcab5403 token_request: 0001e10202bc92ac516c867f39399d71976018db52fcab5403
f8534a65677ba9e1e7d9b1d01767d137884c86cf5fe698c2f5d8e9 f8534a65677ba9e1e7d9b1d01767d137884c86cf5fe698c2f5d8e9
token_response: 0322ea3856a71533796393229b33d33c02cd714e40d5aa4e0 token_response: 0322ea3856a71533796393229b33d33c02cd714e40d5aa4e0
71f056276f32f89c09947eca8ff119d940d9d57c2fcbd83d2da494ddeb37dc1f6 71f056276f32f89c09947eca8ff119d940d9d57c2fcbd83d2da494ddeb37dc1f6
78e5661a8e7bcc96b3477eb89d708b0ce10e0ea1b5ce0001f9332f743c0cc3d47 78e5661a8e7bcc96b3477eb89d708b0ce10e0ea1b5ce0001f9332f743c0cc3d47
48233fea6d3152fae7844821268eb96ba491f60b1a3a848849310a39e9ef59121 48233fea6d3152fae7844821268eb96ba491f60b1a3a848849310a39e9ef59121
669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080 669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080
token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8 token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8
4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8 4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8
7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca 7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca
1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c 1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c
d24504fe4f6c52d24ac901471267d8b63b61e6b d24504fe4f6c52d24ac901471267d8b63b61e6b
B.2. Issuance Protocol 2 - Blind RSA, 2048 A.2. Issuance Protocol 2 - Blind RSA (2048-bit)
The test vector below lists the following values: The test vectors below list the following values:
* skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for skI: The PEM-encoded PKCS #8 RSA Issuer Private Key used for signing
signing tokens, represented as a hexadecimal string. tokens, represented as a hexadecimal string.
* pkS: The Issuer Public Key, serialized according to the encoding pkI: The Issuer Public Key, serialized according to the encoding in
in Section 8.2.2. Section 8.2.2.
* token_challenge: A randomly generated TokenChallenge structure, token_challenge: A randomly generated TokenChallenge structure,
represented as a hexadecimal string. represented as a hexadecimal string.
* nonce: The 32-byte client nonce generated according to nonce: The 32-byte Client nonce generated according to Section 6.1,
Section 6.1, represented as a hexadecimal string. represented as a hexadecimal string.
* blind: The blind used when computing the blind RSA blinded blind: The blind used when computing the blind RSA blinded message,
message, represented as a hexadecimal string. represented as a hexadecimal string.
* salt: The randomly generated 48-byte salt used when encoding the salt: The randomly generated 48-byte salt used when encoding the
blinded token request message, represented as a hexadecimal blinded TokenRequest message, represented as a hexadecimal string.
string.
* token_request: The TokenRequest message constructed according to token_request: The TokenRequest message constructed according to
Section 6.1, represented as a hexadecimal string. Section 6.1, represented as a hexadecimal string.
* token_request: The TokenResponse message constructed according to token_response: The TokenResponse message constructed according to
Section 6.2, represented as a hexadecimal string. Section 6.2, represented as a hexadecimal string.
* token: The output Token from the protocol, represented as a token: The output token from the protocol, represented as a
hexadecimal string. hexadecimal string.
// Test vector 1 // Test vector 1
skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
4945765149424144414e42676b71686b6947397730424151454641415343424b6 4945765149424144414e42676b71686b6947397730424151454641415343424b6
3776767536a41674541416f49424151444c4775317261705831736334420a4f6b 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
57245526b49314c527876734d6453327961326333616b4745714c756b440a556a 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
35743561496b3172417643655844644e44503442325055707851436e6969396e6 35743561496b3172417643655844644e44503442325055707851436e6969396e6
b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
6558563835464f314a752b62397336356d586d34516a755139455961497138337 6558563835464f314a752b62397336356d586d34516a755139455961497138337
1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
skipping to change at page 29, line 32 skipping to change at line 1375
7844733968355272627852614e6673542b7241554837783153594456565159564 7844733968355272627852614e6673542b7241554837783153594456565159564
d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
0524956415445204b45592d2d2d2d2d0a 0524956415445204b45592d2d2d2d2d0a
pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
03040202a11a301806092a864886f70d010108300b0609608648016503040202a 03040202a11a301806092a864886f70d010108300b0609608648016503040202a
2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
babd612d03cad02db134b7e225a5f0203010001 babd612d03cad02db134b7e225a5f0203010001
skipping to change at page 30, line 41 skipping to change at line 1432
71cd2708bc6a21b533d07294b5e900faf5537dd3eb33cee4e08c9670d1e5358fd 71cd2708bc6a21b533d07294b5e900faf5537dd3eb33cee4e08c9670d1e5358fd
184b0e00c637174f5206b14c7bb0e724ebf6b56271e5aa2ed94c051c4a433d302 184b0e00c637174f5206b14c7bb0e724ebf6b56271e5aa2ed94c051c4a433d302
b23bc52460810d489fb050f9de5c868c6c1b06e3849fd087629f704cc724bc0d0 b23bc52460810d489fb050f9de5c868c6c1b06e3849fd087629f704cc724bc0d0
984d5c339686fcdd75f9a9cdd25f37f855f6f4c584d84f716864f546b696d620c 984d5c339686fcdd75f9a9cdd25f37f855f6f4c584d84f716864f546b696d620c
5bd41a811498de84ff9740ba3003ba2422d26b91eb745c084758974642a420782 5bd41a811498de84ff9740ba3003ba2422d26b91eb745c084758974642a420782
01543246ddb58030ea8e722376aa82484dca9610a8fb7e018e396165462e17a03 01543246ddb58030ea8e722376aa82484dca9610a8fb7e018e396165462e17a03
e40ea7e128c090a911ecc708066cb201833010c1ebd4e910fc8e27a1be467f786 e40ea7e128c090a911ecc708066cb201833010c1ebd4e910fc8e27a1be467f786
71836a508257123a45e4e0ae2180a434bd1037713466347a8ebe46439d3da1970 71836a508257123a45e4e0ae2180a434bd1037713466347a8ebe46439d3da1970
// Test vector 2 // Test vector 2
skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
4945765149424144414e42676b71686b6947397730424151454641415343424b6 4945765149424144414e42676b71686b6947397730424151454641415343424b6
3776767536a41674541416f49424151444c4775317261705831736334420a4f6b 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
57245526b49314c527876734d6453327961326333616b4745714c756b440a556a 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
35743561496b3172417643655844644e44503442325055707851436e6969396e6 35743561496b3172417643655844644e44503442325055707851436e6969396e6
b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
6558563835464f314a752b62397336356d586d34516a755139455961497138337 6558563835464f314a752b62397336356d586d34516a755139455961497138337
1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
skipping to change at page 31, line 46 skipping to change at line 1485
7844733968355272627852614e6673542b7241554837783153594456565159564 7844733968355272627852614e6673542b7241554837783153594456565159564
d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
0524956415445204b45592d2d2d2d2d0a 0524956415445204b45592d2d2d2d2d0a
pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
03040202a11a301806092a864886f70d010108300b0609608648016503040202a 03040202a11a301806092a864886f70d010108300b0609608648016503040202a
2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
babd612d03cad02db134b7e225a5f0203010001 babd612d03cad02db134b7e225a5f0203010001
skipping to change at page 33, line 4 skipping to change at line 1539
d90e84488d11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2 d90e84488d11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2
b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
71cd27083350a206c5e9b7c0898f97611ce0bb8d74d310bb194ab67e094e32ff6 71cd27083350a206c5e9b7c0898f97611ce0bb8d74d310bb194ab67e094e32ff6
da90886924b1b9e7b569402c1101d896d2fc3a7371ef77f02310db1dc9f81c853 da90886924b1b9e7b569402c1101d896d2fc3a7371ef77f02310db1dc9f81c853
5828c2d0e9d9051720d182cd54e1c2c3bf417da2fc7aa72bb70ccc834ef274a2e 5828c2d0e9d9051720d182cd54e1c2c3bf417da2fc7aa72bb70ccc834ef274a2e
809c9821b3d395d6535423f7428b3f29175d6eb840b4b7685336e57e2b6afeaab 809c9821b3d395d6535423f7428b3f29175d6eb840b4b7685336e57e2b6afeaab
c0c17ea4f557e8a9cc2f624e245c6ccd7cbdd6c32c97c5c6974e802f688e2d25f c0c17ea4f557e8a9cc2f624e245c6ccd7cbdd6c32c97c5c6974e802f688e2d25f
0aba4215f609f692244517d5d3407e0172273982c001c158f5fcbe1b5d2447c26 0aba4215f609f692244517d5d3407e0172273982c001c158f5fcbe1b5d2447c26
a87e89f5a9e72b498b0c59ce749823d2cf253d3cf6cd4e64fa0e434d95e488789 a87e89f5a9e72b498b0c59ce749823d2cf253d3cf6cd4e64fa0e434d95e488789
247a9ceed756ff4ff33a8d2402c0db381236d331092838b608a42002552092897 247a9ceed756ff4ff33a8d2402c0db381236d331092838b608a42002552092897
// Test vector 3 // Test vector 3
skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
4945765149424144414e42676b71686b6947397730424151454641415343424b6 4945765149424144414e42676b71686b6947397730424151454641415343424b6
3776767536a41674541416f49424151444c4775317261705831736334420a4f6b 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
57245526b49314c527876734d6453327961326333616b4745714c756b440a556a 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
35743561496b3172417643655844644e44503442325055707851436e6969396e6 35743561496b3172417643655844644e44503442325055707851436e6969396e6
b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
6558563835464f314a752b62397336356d586d34516a755139455961497138337 6558563835464f314a752b62397336356d586d34516a755139455961497138337
1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
skipping to change at page 34, line 10 skipping to change at line 1594
7844733968355272627852614e6673542b7241554837783153594456565159564 7844733968355272627852614e6673542b7241554837783153594456565159564
d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
0524956415445204b45592d2d2d2d2d0a 0524956415445204b45592d2d2d2d2d0a
pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
03040202a11a301806092a864886f70d010108300b0609608648016503040202a 03040202a11a301806092a864886f70d010108300b0609608648016503040202a
2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
babd612d03cad02db134b7e225a5f0203010001 babd612d03cad02db134b7e225a5f0203010001
skipping to change at page 35, line 18 skipping to change at line 1650
71cd270815b010bbc0d5f55e9c856d2e9ffaefba007d33c2d5452fbeb0b15919b 71cd270815b010bbc0d5f55e9c856d2e9ffaefba007d33c2d5452fbeb0b15919b
973e0dc9180aaeb18242043758d9fb0ac9ac5e04da9ff74ec93644ae6cdb7068e 973e0dc9180aaeb18242043758d9fb0ac9ac5e04da9ff74ec93644ae6cdb7068e
a76ce2295b9b95e383ed3a9856e9f618dafdf4cec5d2b53ea4297c2f3990babca a76ce2295b9b95e383ed3a9856e9f618dafdf4cec5d2b53ea4297c2f3990babca
71e3ccd6c07a437daae7ed27b6b81178fb7ce5fa5dd63781cc64ac1e410f441c0 71e3ccd6c07a437daae7ed27b6b81178fb7ce5fa5dd63781cc64ac1e410f441c0
34b0a5cc873a2ce875e8b38c92bab563635c4f8f4fa35d1f582ef19edf7da75aa 34b0a5cc873a2ce875e8b38c92bab563635c4f8f4fa35d1f582ef19edf7da75aa
11a503a82e32a12bd4da41e0ca7ec7f451caf586f5b910003fcbbb9ff5ffa2408 11a503a82e32a12bd4da41e0ca7ec7f451caf586f5b910003fcbbb9ff5ffa2408
c28d6807737d03da651ea9bfafcc2747a6830e19a1d160fcd5c25d2f79dad86a8 c28d6807737d03da651ea9bfafcc2747a6830e19a1d160fcd5c25d2f79dad86a8
b3de8e926e08ca1addced72977f7b56398ef59c26e725df0a976a08f2a936ca42 b3de8e926e08ca1addced72977f7b56398ef59c26e725df0a976a08f2a936ca42
// Test vector 4 // Test vector 4
skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
4945765149424144414e42676b71686b6947397730424151454641415343424b6 4945765149424144414e42676b71686b6947397730424151454641415343424b6
3776767536a41674541416f49424151444c4775317261705831736334420a4f6b 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
57245526b49314c527876734d6453327961326333616b4745714c756b440a556a 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
35743561496b3172417643655844644e44503442325055707851436e6969396e6 35743561496b3172417643655844644e44503442325055707851436e6969396e6
b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
6558563835464f314a752b62397336356d586d34516a755139455961497138337 6558563835464f314a752b62397336356d586d34516a755139455961497138337
1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
skipping to change at page 36, line 23 skipping to change at line 1703
7844733968355272627852614e6673542b7241554837783153594456565159564 7844733968355272627852614e6673542b7241554837783153594456565159564
d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
0524956415445204b45592d2d2d2d2d0a 0524956415445204b45592d2d2d2d2d0a
pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
03040202a11a301806092a864886f70d010108300b0609608648016503040202a 03040202a11a301806092a864886f70d010108300b0609608648016503040202a
2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
babd612d03cad02db134b7e225a5f0203010001 babd612d03cad02db134b7e225a5f0203010001
skipping to change at page 37, line 30 skipping to change at line 1758
71cd2708a55c83dc04292b5d92add1a87b37e54f22f61c58840586f390c50b231 71cd2708a55c83dc04292b5d92add1a87b37e54f22f61c58840586f390c50b231
824423378ddcf50e69dc817d45bfad06c7f2a0ac35d2acd7f26b0bc9954c192b0 824423378ddcf50e69dc817d45bfad06c7f2a0ac35d2acd7f26b0bc9954c192b0
a0ef28a2a5650e390098dd3cb1166a7cb1716d3dd2d19dc5ca3b1ea6206359de0 a0ef28a2a5650e390098dd3cb1166a7cb1716d3dd2d19dc5ca3b1ea6206359de0
002d82bc4fa7e69fb07214b06addcbd2203d1e17f57fc580bcc5a13e0ac15cf94 002d82bc4fa7e69fb07214b06addcbd2203d1e17f57fc580bcc5a13e0ac15cf94
2182cc2b5d6eaa737a712704114e357e2ec2f10047463ded02a1a0766dc346dd7 2182cc2b5d6eaa737a712704114e357e2ec2f10047463ded02a1a0766dc346dd7
212b9711e03ac95eb258ac1164104dc9a0d3e738ae742ab5ed8c5139fc07145a7 212b9711e03ac95eb258ac1164104dc9a0d3e738ae742ab5ed8c5139fc07145a7
88b9f891741ee68f0a66782b7b84a9bb4cb4b3d1b26b67106f397b35b641d882d 88b9f891741ee68f0a66782b7b84a9bb4cb4b3d1b26b67106f397b35b641d882d
7b0185168946de898ef72349a44a47dbdd6d46e9ba9ba543d5701b65c63d645c2 7b0185168946de898ef72349a44a47dbdd6d46e9ba9ba543d5701b65c63d645c2
// Test vector 5 // Test vector 5
skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
4945765149424144414e42676b71686b6947397730424151454641415343424b6 4945765149424144414e42676b71686b6947397730424151454641415343424b6
3776767536a41674541416f49424151444c4775317261705831736334420a4f6b 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
57245526b49314c527876734d6453327961326333616b4745714c756b440a556a 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
35743561496b3172417643655844644e44503442325055707851436e6969396e6 35743561496b3172417643655844644e44503442325055707851436e6969396e6
b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
6558563835464f314a752b62397336356d586d34516a755139455961497138337 6558563835464f314a752b62397336356d586d34516a755139455961497138337
1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
skipping to change at page 38, line 35 skipping to change at line 1811
7844733968355272627852614e6673542b7241554837783153594456565159564 7844733968355272627852614e6673542b7241554837783153594456565159564
d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
0524956415445204b45592d2d2d2d2d0a 0524956415445204b45592d2d2d2d2d0a
pkS: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
03040202a11a301806092a864886f70d010108300b0609608648016503040202a 03040202a11a301806092a864886f70d010108300b0609608648016503040202a
2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
babd612d03cad02db134b7e225a5f0203010001 babd612d03cad02db134b7e225a5f0203010001
skipping to change at page 39, line 42 skipping to change at line 1866
22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f 22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a 71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a
9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26 9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26
e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c
c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81 c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81
a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b
a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273 a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273
c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658 c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658
5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23 5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23
Acknowledgements
The authors of this document would like to acknowledge the helpful
feedback and discussions from Benjamin Schwartz, Joseph Salowey, and
Tara Whalen.
Authors' Addresses Authors' Addresses
Sofía Celi Sofía Celi
Brave Software Brave Software
Lisbon Lisbon
Portugal Portugal
Email: cherenkov@riseup.net Email: cherenkov@riseup.net
Alex Davidson Alex Davidson
Brave Software NOVA LINCS, Universidade NOVA de Lisboa
Lisbon Largo da Torre
Caparica
Portugal Portugal
Email: alex.davidson92@gmail.com Email: alex.davidson92@gmail.com
Steven Valdez Steven Valdez
Google LLC Google LLC
Email: svaldez@chromium.org Email: svaldez@chromium.org
Christopher A. Wood Christopher A. Wood
Cloudflare Cloudflare
101 Townsend St 101 Townsend St
San Francisco, San Francisco, CA 94107
United States of America United States of America
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 216 change blocks. 
485 lines changed or deleted 521 lines changed or added

This html diff was produced by rfcdiff 1.48.