idnits 2.17.00 (12 Aug 2021) /tmp/idnits43820/draft-ietf-privacypass-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (5 April 2022) is 39 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Ne' is mentioned on line 230, but not defined == Missing Reference: 'Nk' is mentioned on line 483, but not defined -- Looks like a reference, but probably isn't: '0' on line 301 -- Looks like a reference, but probably isn't: '1' on line 301 -- Looks like a reference, but probably isn't: '32' on line 482 == Missing Reference: 'TODO' is mentioned on line 493, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Celi 3 Internet-Draft Cloudflare 4 Intended status: Informational A. Davidson 5 Expires: 7 October 2022 Brave Software 6 A. Faz-Hernandez 7 Cloudflare 8 S. Valdez 9 Google LLC 10 C. A. Wood 11 Cloudflare 12 5 April 2022 14 Privacy Pass Issuance Protocol 15 draft-ietf-privacypass-protocol-04 17 Abstract 19 This document specifies two variants of the the two-message issuance 20 protocol for Privacy Pass tokens: one that produces tokens that are 21 privately verifiable, and another that produces tokens that are 22 publicly verifiable. The privately verifiable issuance protocol 23 optionally supports public metadata during the issuance flow. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 7 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Token Challenge Requirements . . . . . . . . . . . . . . . . 4 62 5. Issuance Protocol for Privately Verifiable Tokens with Public 63 Metadata . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 5 65 5.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 6 66 5.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 7 67 5.4. Issuer Configuration . . . . . . . . . . . . . . . . . . 8 68 6. Issuance Protocol for Publicly Verifiable Tokens . . . . . . 8 69 6.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 9 70 6.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 10 71 6.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 11 72 6.4. Issuer Configuration . . . . . . . . . . . . . . . . . . 11 73 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Token Type . . . . . . . . . . . . . . . . . . . . . . . 12 76 8.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.2.1. "message/token-request" media type . . . . . . . . . 12 78 8.2.2. "message/token-response" media type . . . . . . . . . 13 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 81 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 15 82 B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) . . . . . . . 15 83 B.2. Issuance Protocol 2 - Blind RSA, 4096 . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 The Privacy Pass protocol provides a privacy-preserving authorization 89 mechanism. In essence, the protocol allows clients to provide 90 cryptographic tokens that prove nothing other than that they have 91 been created by a given server in the past 92 [I-D.ietf-privacypass-architecture]. 94 This document describes the issuance protocol for Privacy Pass. It 95 specifies two variants: one that is privately verifiable based on the 96 oblivious pseudorandom function from [OPRF], and one that is publicly 97 verifiable based on the blind RSA signature scheme [BLINDRSA]. 99 This document DOES NOT cover the architectural framework required for 100 running and maintaining the Privacy Pass protocol in the Internet 101 setting. In addition, it DOES NOT cover the choices that are 102 necessary for ensuring that client privacy leaks do not occur. Both 103 of these considerations are covered in 104 [I-D.ietf-privacypass-architecture]. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 The following terms are used throughout this document. 116 * Client: An entity that provides authorization tokens to services 117 across the Internet, in return for authorization. 119 * Issuer: A service produces Privacy Pass tokens to clients. 121 * Private Key: The secret key used by the Issuer for issuing tokens. 123 * Public Key: The public key used by the Issuer for issuing and 124 verifying tokens. 126 We assume that all protocol messages are encoded into raw byte format 127 before being sent across the wire. 129 3. Configuration 131 Issuers MUST provide one parameter for configuration: 133 1. Issuer Request URI: a token request URL for generating access 134 tokens. For example, an Issuer URL might be 135 https://issuer.example.net/example-token-request. This parameter 136 uses resource media type "text/plain". 138 The Issuer parameters can be obtained from an Issuer via a directory 139 object, which is a JSON object whose field names and values are raw 140 values and URLs for the parameters. 142 +====================+=============================+ 143 | Field Name | Value | 144 +====================+=============================+ 145 | issuer-request-uri | Issuer Request URI resource | 146 | | URL as a JSON string | 147 +--------------------+-----------------------------+ 149 Table 1 151 As an example, the Issuer's JSON directory could look like: 153 { 154 "issuer-request-uri": "https://issuer.example.net/example-token-request" 155 } 157 Issuer directory resources have the media type "application/json" and 158 are located at the well-known location /.well-known/token-issuer- 159 directory. 161 4. Token Challenge Requirements 163 Clients receive challenges for tokens, as described in [AUTHSCHEME]. 164 The basic token issuance protocols described in this document can be 165 interactive or non-interactive, and per-origin or cross-origin. 167 5. Issuance Protocol for Privately Verifiable Tokens with Public 168 Metadata 170 The Privacy Pass issuance protocol is a two message protocol that 171 takes as input a challenge from the redemption protocol and produces 172 a token, as shown in the figure below. 174 Origin Client Issuer 175 (pkI) (skI, pkI) 176 +------------------------------------\ 177 Challenge ----> TokenRequest -------------> | 178 | (evaluate) | 179 Token <----+ <--------------- TokenResponse | 180 \------------------------------------/ 182 Issuers provide a Private and Public Key, denoted skI and pkI, 183 respectively, used to produce tokens as input to the protocol. See 184 Section 5.4 for how this key pair is generated. 186 Clients provide the following as input to the issuance protocol: 188 * Issuer name, identifying the Issuer. This is typically a host 189 name that can be used to construct HTTP requests to the Issuer. 191 * Issuer Public Key pkI, with a key identifier key_id computed as 192 described in Section 5.4. 194 * Challenge value challenge, an opaque byte string. For example, 195 this might be provided by the redemption protocol in 196 [HTTP-Authentication]. 198 Given this configuration and these inputs, the two messages exchanged 199 in this protocol are described below. This section uses notation 200 described in [OPRF], Section 4, including SerializeElement and 201 DeserializeElement, SerializeScalar and DeserializeScalar, and 202 DeriveKeyPair. 204 5.1. Client-to-Issuer Request 206 The Client first creates a context as follows: 208 client_context = SetupVOPRFClient(0x0004, pkI) 210 Here, 0x0004 is the two-octet identifier corresponding to the 211 OPRF(P-384, SHA-384) ciphersuite in [OPRF]. SetupVOPRFClient is 212 defined in [OPRF], Section 3.2. 214 The Client then creates an issuance request message for a random 215 value nonce using the input challenge and Issuer key identifier as 216 follows: 218 nonce = random(32) 219 context = SHA256(challenge) 220 token_input = concat(0x0001, nonce, context, key_id) 221 blind, blinded_element = client_context.Blind(token_input) 223 The Blind function is defined in [OPRF], Section 3.3.2. If the Blind 224 function fails, the Client aborts the protocol. Otherwise, the 225 Client then creates a TokenRequest structured as follows: 227 struct { 228 uint16_t token_type = 0x0001; 229 uint8_t token_key_id; 230 uint8_t blinded_msg[Ne]; 231 } TokenRequest; 233 The structure fields are defined as follows: 235 * "token_type" is a 2-octet integer, which matches the type in the 236 challenge. 238 * "token_key_id" is the least significant byte of the key_id. 240 * "blinded_msg" is the Ne-octet blinded message defined above, 241 computed as SerializeElement(blinded_element). Ne is as defined 242 in [OPRF], Section 4. 244 The values token_input and blinded_element are stored locally and 245 used later as described in Section 5.3. The Client then generates an 246 HTTP POST request to send to the Issuer, with the TokenRequest as the 247 body. The media type for this request is "message/token-request". 248 An example request is shown below. 250 :method = POST 251 :scheme = https 252 :authority = issuer.example.net 253 :path = /example-token-request 254 accept = message/token-response 255 cache-control = no-cache, no-store 256 content-type = message/token-request 257 content-length = 259 261 Upon receipt of the request, the Issuer validates the following 262 conditions: 264 * The TokenRequest contains a supported token_type. 266 * The TokenRequest.token_key_id corresponds to a key ID of a Public 267 Key owned by the issuer. 269 * The TokenRequest.blinded_request is of the correct size. 271 If any of these conditions is not met, the Issuer MUST return an HTTP 272 400 error to the client. 274 5.2. Issuer-to-Client Response 276 Upon receipt of a TokenRequest, the Issuer tries to deseralize 277 TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of 278 [OPRF], yielding blinded_element. If this fails, the Issuer MUST 279 return an HTTP 400 error to the client. Otherwise, if the Issuer is 280 willing to produce a token token to the Client, the Issuer completes 281 the issuance flow by computing a blinded response as follows: 283 server_context = SetupVOPRFServer(0x0004, skI, pkI) 284 evaluate_element, proof = server_context.Evaluate(skI, blinded_element) 285 SetupVOPRFServer is in [OPRF], Section 3.2 and Evaluate is defined in 286 [OPRF], Section 3.3.2. The Issuer then creates a TokenResponse 287 structured as follows: 289 struct { 290 uint8_t evaluate_msg[Nk]; 291 uint8_t evaluate_proof[Ns+Ns]; 292 } TokenResponse; 294 The structure fields are defined as follows: 296 * "evaluate_msg" is the Ne-octet evaluated messaged, computed as 297 SerializeElement(evaluate_element). 299 * "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a 300 pair of Scalar values, computed as 301 concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])), 302 where Ns is as defined in [OPRF], Section 4. 304 The Issuer generates an HTTP response with status code 200 whose body 305 consists of TokenResponse, with the content type set as "message/ 306 token-response". 308 :status = 200 309 content-type = message/token-response 310 content-length = 312 314 5.3. Finalization 316 Upon receipt, the Client handles the response and, if successful, 317 deserializes the body values TokenResponse.evaluate_response and 318 TokenResponse.evaluate_proof, yielding evaluated_element and proof. 319 If deserialization of either value fails, the Client aborts the 320 protocol. Otherwise, the Client processes the response as follows: 322 authenticator = client_context.Finalize(token_input, blind, evaluated_element, blinded_element, proof) 324 The Finalize function is defined in [OPRF], Section 3.3.2. If this 325 succeeds, the Client then constructs a Token as follows: 327 struct { 328 uint16_t token_type = 0x0001 329 uint8_t nonce[32]; 330 uint8_t challenge_digest[32]; 331 uint8_t token_key_id[32]; 332 uint8_t authenticator[Nk]; 333 } Token; 335 Otherwise, the Client aborts the protocol. 337 5.4. Issuer Configuration 339 Issuers are configured with Private and Public Key pairs, each 340 denoted skI and pkI, respectively, used to produce tokens. Each key 341 pair MUST be generated as follows: 343 seed = random(Ns) 344 (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") 346 The key identifier for this specific key pair, denoted key_id, is 347 computed as follows: 349 key_id = SHA256(0x0001 || SerializeElement(pkI)) 351 6. Issuance Protocol for Publicly Verifiable Tokens 353 This section describes a variant of the issuance protocol in 354 Section 5 for producing publicly verifiable tokens. It differs from 355 the previous variant in two important ways: 357 1. The output tokens are publicly verifiable by anyone with the 358 Issuer public key; and 360 2. The issuance protocol does not admit public or private metadata 361 to bind additional context to tokens. 363 Otherwise, this variant is nearly identical. In particular, Issuers 364 provide a Private and Public Key, denoted skI and pkI, respectively, 365 used to produce tokens as input to the protocol. See Section 6.4 for 366 how this key pair is generated. 368 Clients provide the following as input to the issuance protocol: 370 * Issuer name, identifying the Issuer. This is typically a host 371 name that can be used to construct HTTP requests to the Issuer. 373 * Issuer Public Key pkI, with a key identifier key_id computed as 374 described in Section 6.4. 376 * Challenge value challenge, an opaque byte string. For example, 377 this might be provided by the redemption protocol in 378 [HTTP-Authentication]. 380 Given this configuration and these inputs, the two messages exchanged 381 in this protocol are described below. 383 6.1. Client-to-Issuer Request 385 The Client first creates an issuance request message for a random 386 value nonce using the input challenge and Issuer key identifier as 387 follows: 389 nonce = random(32) 390 context = SHA256(challenge) 391 token_input = concat(0x0002, nonce, context, key_id) 392 blinded_msg, blind_inv = rsabssa_blind(pkI, token_input) 394 The rsabssa_blind function is defined in [BLINDRSA], Section 5.1.1.. 395 The Client then creates a TokenRequest structured as follows: 397 struct { 398 uint16_t token_type = 0x0002 399 uint8_t token_key_id; 400 uint8_t blinded_msg[Nk]; 401 } TokenRequest; 403 The structure fields are defined as follows: 405 * "token_type" is a 2-octet integer, which matches the type in the 406 challenge. 408 * "token_key_id" is the least significant byte of the key_id. 410 * "blinded_msg" is the Nk-octet request defined above. 412 The Client then generates an HTTP POST request to send to the Issuer, 413 with the TokenRequest as the body. The media type for this request 414 is "message/token-request". An example request is shown below, where 415 Nk = 512. 417 :method = POST 418 :scheme = https 419 :authority = issuer.example.net 420 :path = /example-token-request 421 accept = message/token-response 422 cache-control = no-cache, no-store 423 content-type = message/token-request 424 content-length = 426 428 Upon receipt of the request, the Issuer validates the following 429 conditions: 431 * The TokenRequest contains a supported token_type. 433 * The TokenRequest.token_key_id corresponds to a key ID of a Public 434 Key owned by the issuer. 436 * The TokenRequest.blinded_msg is of the correct size. 438 If any of these conditions is not met, the Issuer MUST return an HTTP 439 400 error to the Client, which will forward the error to the client. 441 6.2. Issuer-to-Client Response 443 If the Issuer is willing to produce a token token to the Client, the 444 Issuer completes the issuance flow by computing a blinded response as 445 follows: 447 blind_sig = rsabssa_blind_sign(skI, TokenRequest.blinded_rmsg) 449 This is encoded and transmitted to the client in the following 450 TokenResponse structure: 452 struct { 453 uint8_t blind_sig[Nk]; 454 } TokenResponse; 456 The rsabssa_blind_sign function is defined in [BLINDRSA], 457 Section 5.1.2.. The Issuer generates an HTTP response with status 458 code 200 whose body consists of TokenResponse, with the content type 459 set as "message/token-response". 461 :status = 200 462 content-type = message/token-response 463 content-length = 465 467 6.3. Finalization 469 Upon receipt, the Client handles the response and, if successful, 470 processes the body as follows: 472 authenticator = rsabssa_finalize(pkI, nonce, blind_sig, blind_inv) 474 The rsabssa_finalize function is defined in [BLINDRSA], 475 Section 5.1.3.. If this succeeds, the Client then constructs a Token 476 as described in [HTTP-Authentication] as follows: 478 struct { 479 uint16_t token_type = 0x0002 480 uint8_t nonce[32]; 481 uint8_t challenge_digest[32]; 482 uint8_t token_key_id[32]; 483 uint8_t authenticator[Nk]; 484 } Token; 486 Otherwise, the Client aborts the protocol. 488 6.4. Issuer Configuration 490 Issuers are configured with Private and Public Key pairs, each 491 denoted skI and pkI, respectively, used to produce tokens. Each key 492 pair MUST be generated as as a valid 4096-bit RSA private key 493 according to [TODO]. The key identifier for a keypair (skI, pkI), 494 denoted key_id, is computed as SHA256(encoded_key), where encoded_key 495 is a DER-encoded SubjectPublicKeyInfo object carrying pkI. 497 7. Security considerations 499 This document outlines how to instantiate the Issuance protocol based 500 on the VOPRF defined in [OPRF] and blind RSA protocol defnied in 501 [BLINDRSA]. All security considerations described in the VOPRF 502 document also apply in the Privacy Pass use-case. Considerations 503 related to broader privacy and security concerns in a multi-Client 504 and multi-Issuer setting are deferred to the Architecture document 505 [I-D.ietf-privacypass-architecture]. 507 8. IANA considerations 508 8.1. Token Type 510 This document updates the "Token Type" Registry with the following 511 values. 513 +======+==============+============+========+========+===+==========+ 514 |Value | Name | Publicly |Public |Private |Nk |Reference | 515 | | | Verifiable |Metadata|Metadata| | | 516 +======+==============+============+========+========+===+==========+ 517 |0x0001| VOPRF(P-384, | N |N |N |48 |Section 5 | 518 | | SHA-384) | | | | | | 519 +------+--------------+------------+--------+--------+---+----------+ 520 |0x0002| Blind RSA, | Y |N |N |512|Section 6 | 521 | | 4096 | | | | | | 522 +------+--------------+------------+--------+--------+---+----------+ 524 Table 2: Token Types 526 8.2. Media Types 528 This specification defines the following protocol messages, along 529 with their corresponding media types: 531 * TokenRequest: "message/token-request" 533 * TokenResponse: "message/token-response" 535 The definition for each media type is in the following subsections. 537 8.2.1. "message/token-request" media type 539 Type name: message 541 Subtype name: token-request 543 Required parameters: N/A 545 Optional parameters: None 547 Encoding considerations: only "8bit" or "binary" is permitted 549 Security considerations: see Section 7 551 Interoperability considerations: N/A 553 Published specification: this specification 555 Applications that use this media type: N/A 556 Fragment identifier considerations: N/A 558 Additional information: Magic number(s): N/A 560 Deprecated alias names for this type: N/A 562 File extension(s): N/A 564 Macintosh file type code(s): N/A 566 Person and email address to contact for further information: see Aut 567 hors' Addresses section 569 Intended usage: COMMON 571 Restrictions on usage: N/A 573 Author: see Authors' Addresses section 575 Change controller: IESG 577 8.2.2. "message/token-response" media type 579 Type name: message 581 Subtype name: access-token-response 583 Required parameters: N/A 585 Optional parameters: None 587 Encoding considerations: only "8bit" or "binary" is permitted 589 Security considerations: see Section 7 591 Interoperability considerations: N/A 593 Published specification: this specification 595 Applications that use this media type: N/A 597 Fragment identifier considerations: N/A 599 Additional information: Magic number(s): N/A 601 Deprecated alias names for this type: N/A 603 File extension(s): N/A 604 Macintosh file type code(s): N/A 606 Person and email address to contact for further information: see Aut 607 hors' Addresses section 609 Intended usage: COMMON 611 Restrictions on usage: N/A 613 Author: see Authors' Addresses section 615 Change controller: IESG 617 9. Normative References 619 [AUTHSCHEME] 620 Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass 621 HTTP Authentication Scheme", Work in Progress, Internet- 622 Draft, draft-pauly-privacypass-auth-scheme-00, 31 January 623 2022, . 626 [BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind 627 Signatures", Work in Progress, Internet-Draft, draft-irtf- 628 cfrg-rsa-blind-signatures-03, 2 February 2022, 629 . 632 [HTTP-Authentication] 633 "The Privacy Pass HTTP Authentication Scheme", n.d., 634 . 637 [I-D.ietf-privacypass-architecture] 638 Davidson, A., Iyengar, J., and C. A. Wood, "Privacy Pass 639 Architectural Framework", Work in Progress, Internet- 640 Draft, draft-ietf-privacypass-architecture-03, 7 March 641 2022, . 644 [OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. 645 Wood, "Oblivious Pseudorandom Functions (OPRFs) using 646 Prime-Order Groups", Work in Progress, Internet-Draft, 647 draft-irtf-cfrg-voprf-09, 8 February 2022, 648 . 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, 653 DOI 10.17487/RFC2119, March 1997, 654 . 656 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 657 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 658 May 2017, . 660 Appendix A. Acknowledgements 662 The authors of this document would like to acknowledge the helpful 663 feedback and discussions from Benjamin Schwartz, Joseph Salowey, 664 Sofia Celi, and Tara Whalen. 666 Appendix B. Test Vectors 668 This section includes test vectors for the two basic issuance 669 protocols specified in this document. Appendix B.1 contains test 670 vectors for token issuance protocol 1 (0x0001), and Appendix B.2 671 contains test vectors for token issuance protocol 2 (0x0002). 673 B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) 675 The test vector below lists the following values: 677 * skS: The encoded OPRF private key, serialized using 678 SerializeScalar from Section 2.1 of [OPRF] and represented as a 679 hexadecimal string. 681 * pkS: The encoded OPRF public key, serialized using 682 SerializeElement from Section 2.1 of [OPRF] and represented as a 683 hexadecimal string. 685 * challenge: A random challenge, represented as a hexadecimal 686 string. 688 * nonce: The 32-byte client nonce generated according to 689 Section 5.1, represented as a hexadecimal string. 691 * blind: The blind used when computing the OPRF blinded message, 692 serialized using SerializeScalar from Section 2.1 of [OPRF] and 693 represented as a hexadecimal string. 695 * token_request: The TokenRequest message constructed according to 696 Section 5.1, represented as a hexadecimal string. 698 * token_request: The TokenResponse message constructed according to 699 Section 5.2, represented as a hexadecimal string. 701 * token: The output Token from the protocol, represented as a 702 hexadecimal string. 704 skS: 0177781aeced893dccdf80713d318a801e2a0498240fdcf650304bbbfd0f8d3b5c0 705 cf6cfee457aaa983ec02ff283b7a9 706 pkS: 022c63f79ac59c0ba3d204245f676a2133bd6120c90d67afa05cd6f8614294b7366 707 c252c6458300551b79a4911c2590a36 708 challenge: 709 a5d46383359ef34e3c4a7b8d1b3165778bffc9b70c9e6a60dd14143e4c9c9fbd 710 nonce: 5d4799f8338ddc50a6685f83b8ecd264b2f157015229d12b3384c0f199efe7b8 711 blind: 0322fec505230992256296063d989b59cc03e83184eb6187076d264137622d202 712 48e4e525bdc007b80d1560e0a6f49d9 713 token_request: 00011a02861fd50d14be873611cff0131d2c872c79d0260c6763498a2 714 a3f14ca926009c0f247653406e1d52b68d61b7ed2bac9ea 715 token_response: 038e3625b6a769668a99680e46cf9479f5dc1e86d57164ab3b4a569d 716 dfc486bf1485d4916a5194fdc0518d3e8444968421ba36e8144aa7902705ff0f3cf40586 717 3d69451a2a7ba210cc45760c2f1a6045134d877b39e8bcbbf920e5de4a3372557debf211 718 765cd969976860bc039f9082d6a3e03f8e891246240173d2cf3d69a4613b0f8415979029 719 22e74c7a1f2e4639e4 720 token: 00015d4799f8338ddc50a6685f83b8ecd264b2f157015229d12b3384c0f199efe 721 7b8742cdfb0ed756ea680868ef109a280a393e001d2fa56b1be46ecb31fa25e76731a5b1 722 d698ea7ab843b8e8a71ed9b2fffa70457a43a8fc687939424b29a7554b40fde130ab7a82 723 2715909cb73f99a45b640ca1c85180ba9ca1a40bab8b664406a34bcbc63b5e2e5c455cea 724 00001a968f7 726 B.2. Issuance Protocol 2 - Blind RSA, 4096 728 The test vector below lists the following values: 730 * skS: The PEM-encoded PKCS#8 RSA private key used for signing 731 tokens, represented as a hexadecimal string. 733 * pkS: The DER-encoded SubjectPublicKeyInfo object carrying the 734 public key corresponding to skS, as described in Section 6.4, 735 represented as a hexadecimal string. 737 * challenge: A random challenge, represented as a hexadecimal 738 string. 740 * nonce: The 32-byte client nonce generated according to 741 Section 6.1, represented as a hexadecimal string. 743 * blind: The blind used when computing the blind RSA blinded 744 message, represented as a hexadecimal string. 746 * salt: The randomly generated 48-byte salt used when encoding the 747 blinded token request message, represented as a hexadecimal 748 string. 750 * token_request: The TokenRequest message constructed according to 751 Section 6.1, represented as a hexadecimal string. 753 * token_request: The TokenResponse message constructed according to 754 Section 6.2, represented as a hexadecimal string. 756 * token: The output Token from the protocol, represented as a 757 hexadecimal string. 759 skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49494a517 760 749424144414e42676b71686b69473977304241514546414153434353307767676b70416 761 74541416f4943415144584d4d364c5073637a6130696b0a39596c315a4e683868324a796 762 d504962704c383035354d52516f6463446c4c4672764d694c57666f59535241506b4e744 763 1546272324162654e334d454a2f67550a392f424958717a704d4256484852546c627a676 764 b364c7866766b54505a2b4a427832517177364f5555714b442f34426f5464765761536d6 765 a63644165555037760a4836376e396a383836307463367375546e67616c574d4b6d764d2 766 f5a6237644262543763345647386577706c6776444f6d616641353956354f78505545704 767 9510a586c454f4771414f43436c316f54686d33363836436c48413352374c5a4d78567a4 768 742386f594537583548396a70793532786a2f3242724a6861625033567a430a6f4c696c3 769 54f6e36487158785363466d4956573742787956495979756d75537659544e52757652777 770 3566c3775595446366f4d6d2b59722f5a506372594c7a510a4e666135634f747533532b6 771 649594456716f6f58375541415671382f716c4945747a794a744f7261616756393039327 772 0324f474c4f6d306a52384543666963520a3868363332572f76554d7739724c4c317a4d4 773 e7554424f4b74316c546c307265644a677668626b66515a5a55303541336a69366c71754 774 d2f47307250553030470a3369385253732f64694e625843505453746b616f45537350345 775 946496d526269756c786a544e2b626c5859744868494261556774306e2b566b544a77554 776 86e380a5367447534664e547142776567517265494e427732446b6e63576e676b5644416 777 867577635383669727351644c345843723376765856647a51375134586978730a465a6b6 778 d7763676d665142444f3469363078536c336337316954595362783359326e74584b4e6f5 779 a4c31537a424f595051496a6c734749454250677157546e5a0a64655a7852464f6c4d384 780 679794b6d30746471586271594b57716b663777494441514142416f4943414364314d707 781 044773645424467763558654168777252710a32726c717042492f6a6a50304e6e7057755 782 a302b6e787a53624a4361784d2f4f61436844676e654e586e573259655144524e7242505 783 84d5331344e646f4e554e0a56516c36497166445567637169636741696e7542622f4a687 784 a6c4d74466d5350466d2b667650726a4d2b6c4831544f384863354253633274414a52574 785 36468770a794a7663446349656d74646378437877754b6746485251704a5071356368526 786 56431535077766f50494c7831686959356c2f5175423478717a764149483873530a34673 787 949705a2f766169443558573541335847734a4f2b696a78717250706756655236474e4f5 788 33763515551716a44446967665a626a5864354a322b734d79460a4c435a6e514d6771577 789 03731756437366a4f4a445571563537454154534e6b56472f52633279537a554b4d6e354 790 c335a314a796d6d31694f584a5136535744760a6f5375426b435652436645635a746b546 791 f436c76646f5456666b63414a394e51343839686b3050754e466f593675315671614c5a4 792 a7764657a3931764f5966300a4b676f665a4a6e774976547733754b786f7559685033334 793 43644574a4f31763265487658767a4c744f4a54477054446f726f4c7a2f475459316b682 794 f484d50510a416c4f333758772f526b527752684b4d6f39545555347766642b2b5348325 795 4346e6730584875355254764d5339496b4266724455337a75557675434b7270356b0a377 796 942364473763433517932364f6367367151584a563650676b6c5770696164445778326f4 797 73935746578436f3346563434764a6d49327a706d5748514257630a48395331336b6d7a3 798 06873506274576a537535494c443061694f5630764d4c61353841685a767a32774562763 799 750546a494d48364d77446736326d6450744d6b0a534969517548644a38326a69316e757 800 8646f5678416f4942415144773431456757476e437644496239727a73704b6e61486a654 801 3574650385737664a6b446c4c0a61786c724a6f574e614d654c33306b646873576569765 802 7616730436f457656556631543455374936735a33705054675653685079374b6f4c645a4 803 86f757a5a390a4d774679716d694652726e574135467138544b756f4354647a3836542f5 804 37859753330625a476c6d6a4c432f6664453279556141486f6f5177375a2f34646b6d0a4 805 1693031696a36484d654e39486e5a425737656c436c4173443242436d4b5279655554793 806 7754b472b6b3732704630336e45694f7a42615565354d6c7a7436620a3867586b63715a5 807 735495478454b41726b6d486a77454379765178346a7867324573326a7653654e3041554 808 b624a63534a736e7a35434a65667a697561676f650a36482b3947676f62386e496a78546 809 34e784c7a58316a676e5236772f41302f6e657837714e6b57357773485a46644c58416f4 810 9424151446b734d6e75503452460a7558474a6e34316559696c43716b694e4e6b4a53753 811 9637456556b7772364570744230506d34556e3770535238684866767a5a43782f6b65766 812 b33553336546e0a67556c72416a4b72474a6a77437231457a7252726e417153466f61395 813 04851395a69697264626336726f474932576f63795a585859664b784a56646a4f754c440 814 a793947564d72575133665a3571696d7a6a394b4163304852455765784b6875514259465 815 554542f44323169584b4b65497568647834796b795435323857714b310a66786f4c72584 816 e6d5936726b77787778763334556779685a54564a75454879506e51422f54743242377a2 817 b342f763033665a46347361635646337738514a306c0a692b466879555a34326b63674a3 818 52b654c6d5558726b6d5a5959314a534332417a722f336449516a4b554655515935326a3 819 65775667338392f576a72516669470a31732b6c51385a7a6d4a4370416f49424151432b3 820 84c43686e764e574e4b37546b365431507943546b466758726351457950374a657453766 821 6316c4b6f654a430a304d6337692b58387a5a4e6674473478353941636163716c43376c6 822 96a5a55394351564f6d415159652f754d4679524371524c62453271426d79694f70357a7 823 00a3538487562693261513034564e554f44767644555256346468364148556e52706f534 824 f49356b59723079646137746f7070376a4662565165324b4c56535a742b0a746f4448384 825 a6c7a2f5374345774427033465a4538354747573748586a70746f756f6855344c777a464 826 7492f4c6d37486935783733357038716a385a6366642f0a384f756632626e6354382f674 827 938676b35633034307451794b483177534d4e4e6d5a496c54535943635653725369346b4 828 5567677684955354d726e75507647380a6256556b48584d694b7377316d63777739704d4 829 6373634716f6d464337586f66594d30664d6a6c4a416f494241465079565632676354534 830 b2b784e7976786b4c0a58577638522f2b57454569416256395674445572387a503079736 831 f6b34333869412b57432f32367271515a676b36446d61486d673073367356622f7a495a6 832 84f0a7769307a4e41446a41375751705179314f6961533333522b594b56333435656c345 833 35454386a433543736a79536e306559504b71396679376636614e343770570a304267664 834 4346d37584b454d4c66664a744d2b437a6e56536f41504c433449677257646e5a4141376 835 c306d57416c52576832645275664a3377703751763943770a2b315659446178785235334 836 e2b327930686e4b696d4b613745696970555952567834566f444a6c6d2f5a525a5769545 837 335796253375279514f563645334e71560a2f592f6647366563446a33674732497a50674 838 c4e664f3651646b556d7679364e4155386c645638754962707045446749497042684f684 839 a394865486a664343490a75326b4367674542414d68686e6f69312b78454a365339636e5 840 a327977527737433057544962662b54557230436e374f344a4d76637843544b484d62773 841 76a680a574c6247392f314732595966354c5673326b572f34472b2f446d586b6d4b68715 842 4746d6f324e50463666504b73694d64477877354149677039557a50543168550a2f6c777 843 26a75474d322f2b77434b70316d3645374e4d4d5659684b5841534f673473652b3676586 844 455356a56436f634343576162657a6c5835513262796c51480a2b2b624f6d4661504d535 845 5683761616d6657357573614553627366612f45506932446d3545574f456339567577525 846 671526143527552534632507043627279410a6b376e6b6b6746474b5a523777353053465 847 5366f7a776667627a2b7a33637256315535766d3076346c63794b6d524b6c4b575a51554 848 9624b782f5070583737640a395057536e3569594343704c432f316245372f566f4c70467 849 7757631656a773d0a2d2d2d2d2d454e442050524956415445204b45592d2d2d2d2d0a 850 pkS: 30820252303d06092a864886f70d01010a3030a00d300b060960864801650304020 851 2a11a301806092a864886f70d010108300b0609608648016503040202a20302013003820 852 20f003082020a0282020100d730ce8b3ec7336b48a4f5897564d87c87627298f21ba4bf3 853 4e7931142875c0e52c5aef3222d67e86124403e436d0136ebd806de37730427f814f7f04 854 85eace93015471d14e56f3824e8bc5fbe44cf67e241c7642ac3a39452a283ff80684ddbd 855 66929a371d01e50feef1faee7f63f3ceb4b5ceacb939e06a558c2a6bccfd96fb7416d3ed 856 ce151bc7b0a6582f0ce99a7c0e7d5793b13d41292105e510e1aa00e082975a13866dfaf3 857 a0a51c0dd1ecb64cc55cc607ca1813b5f91fd8e9cb9db18ffd81ac985a6cfdd5cc2a0b8a 858 5e4e9fa1ea5f149c1662155bb071c95218cae9ae4af613351baf470b1597bb984c5ea832 859 6f98aff64f72b60bcd035f6b970eb6edd2f9f2180d5aa8a17ed400056af3faa5204b73c8 860 9b4eada6a057dd3dda9d8e18b3a6d2347c1027e2711f21eb7d96fef50cc3dacb2f5ccc36 861 e4c138ab75953974ade74982f85b91f419654d390378e2ea5aae33f1b4acf534d06de2f1 862 14acfdd88d6d708f4d2b646a8112b0fe181489916e2ba5c634cdf9b95762d1e120169482 863 dd27f959132705079fc4a00eee1f353a81c1e810ade20d070d839277169e09150c08605a 864 fe7cea2aec41d2f85c2af7bef5d577343b4385e2c6c159926c1c8267d00433b88bad314a 865 5ddcef58936126f1dd8da7b5728da192f54b304e60f4088e5b0620404f82a5939d975e67 866 14453a533c172c8a9b4b5da976ea60a5aa91fef0203010001 867 challenge: 868 83ce743dcdadd5fc4aeb0357977bb8426635c390a15b88947f0b1c62e4a87c22 869 nonce: 7e0da97bfdc4365a5f40e69262f78b81bcd2f92daf885358d9831874e3dd9d22 870 blind: cd6d03e332386d0166eb76b8e78522510e5cbdcf49aaac83191ea948a7719e914 871 0ccb6701f7301b7d445ede7adbc5e582b35edd9ac45bc4b8f794e150b2e3e407b7b7624b 872 6f90b33845bc255174cee0c570aa781c203dce8563afe9f48e2b49c773bba1031987fb48 873 d981d131876f53e264ec0609a3ea628cf2042005ed3071aeb6657472c7e7df947915b8cd 874 333e3f5078e456e65e5edef8f892c4f21d25a18dcd80628ed6c7d55b0b9433bc67760be0 875 8a4eacbdb16a4be4c5b8cab26b478fa6a36ea3c3dd1ffb420bf69feef52aab4892c9e60a 876 df18347b4e8256b5a0e8cbf55fc97ac62af2e7349ba98ca7462cb6a41d70b0217814a06e 877 1b257289c3b345be652b87d5820b06a80500880b40b8772140bf431f11497114b20fee7e 878 5ffc1af5cf874cc293a0c8df65d52814bcd55ae6d3701f73d140ca82c6528627129ea389 879 f3cbd6058f4f80b7df3818f36dd3489259b6b95df4511930ff02b5cbe643fea44306e7c4 880 e3d9b02f1b0559aa238b8882a6e8791bfbfd366ef4fe433fd42e5c5db208c9fcebc74def 881 11663ce5f793c7013116995b3fef392a8633b08179a9c8309fb69359fd8486a7a8febb42 882 4d0726c2516b11e8b19a55fa54e9be606de6811059976473de8f9adb25af7e2862932bed 883 c7764b4dc50bfc9d724a4aba356a7677b5aceef21876e56b4f1b65adef0fbf8bf1636815 884 be01b372727e79aa6c47f41 885 salt: d13a47fa6466a37203e51ac34f7319831b3f04202ff74c98ab18e78088b7ac3014 886 06189783503227153871405c6a1da0 887 token_request: 0002013a370077e8259098e741dcaac8184838b7c995cd82966419064 888 90205bf28e6745396dd9ec1761c4676e9fec3272588194c48bc60fc77c3fff19219a6b65 889 96523044d07d9d9e4dd88f2db9d9c369597363a12a65d244d69a1b743b365f8f5bdbf8d6 890 52f2d2e249f417e9fd7da7db2626d6499d7d3856d8f9277385dfd776ffa4ffa74d7a7b17 891 01d87f40e525bb258a7f5b4d6c134b3b242ef46d93b32f106c84c396b1fc2772796b2473 892 64c48c364537708f3a8a87fb870a299ac08107a5dd3f467733d76c2359e346ee3ebcff68 893 c3c7e10f0f01a2b9bbbdb26ffea14f81f036a71c47725b5c9f81e0320b85abfd77d5eb1c 894 ccfdd8eb0cf2735ea297e2a07c82dfee9b0a4d21baa81a2cfb2a72983107555035386c33 895 973d48f04257dd8298116d2c93298810cb6b82ad033f5b16f9f7a65d8f74b7bdcae000db 896 1411b40f46cb373cb69c8ab58552f98904b78229b63838ab40e833fab4ec47acf00a00db 897 3290c9c74ed982c64ddbcae16fd73976ffe7da7b3b1a8e0190e95b7ce7900295f3c8c94f 898 2d3d85cd1825fe27073aad63fa4c530907402dc4e3a748edb300f05ce7ac5b8c1d9aeb2f 899 d6002b05dee582aeaefa4f503f13bae1a51be9420e3cdcb685169bdc5ae2ebca7713ec16 900 666b55b097e56e5719d1b0324ecaca613af76b9f367775a90dba5e7fdd21a8da73bd80b1 901 31e6531117ef709ad8c7b2b3182255235acea 902 token_response: 061780e09bc9b851fe81e7022ee2d55b043198bcb1aa33f761d213a9 903 8d831abaef5417d30904a7c9d7ec531278cd9655c4b7d72f3a4e66e26565b73e5f1b9271 904 b541f28556543d2473c363e104a11c6ba1a1d8f99b32d3cd8f74ae07b465afdaabd21977 905 d6f114ea9484cd592f461e5dc4a97b86fe1463b1c69171cf734f49c240760dc2555d7cc8 906 9d7f882d3e1b99388bc3b561d418a7fc5770ccc66e3dd41f4a74e8267492f48e8b6aabce 907 592c8dc83826b1f4528f2497902a0ce4baacd4216623274057592e77091102452de115bb 908 d0c98ee22b14fe30fb371277ab17bc948b62b8adb56b67e44dce74860647718c8f4bd10e 909 7b022ad35e2996dd49fb4a6c765689931fc11b56b06cca921fb1205e8b230254054a48da 910 38ed7a5e20f7aa80b55f1de9f5a6c9589f4f2c3b6ed2c53ad2a6a64abb8fba67aef86e6f 911 f77647aa05ce96527e2d1199b7553a3b900ec510f5b765211c14d0fc6cbe82f28be4d8ac 912 8110f13d7aee3741fc68f4abf3ca33444f790a72ef4ddec72c1d92938ee5d303f914ff12 913 8d9a73e867d9aa5d327934d4b2b299d7ffa32350d72d35103c027ac76c5417823e6790ee 914 174b9761e086bfa445f1725b20cff6a94d51abdfcfe46ff7c0f69685fd38639bdbd3917f 915 424949027b5a322fc217364748e544257d11f0cdcab9aa1d3282f6ac2811dfc8db5b2f99 916 c1ba00c366057748cabe6975fc73ed60 917 token: 00027e0da97bfdc4365a5f40e69262f78b81bcd2f92daf885358d9831874e3dd9 918 d22895c9d3ff72e71d22cdbc11706d350ab772b0820be9f33a02e003652cb00a31501000 919 000000000000000000000000000000000000000000000000000000000004c9e19f2a624e 920 e7d44ac35846749b29b1d3a784f13ea1005a2c87b9d3f939f795877d5fded823f45fd399 921 dc0b8730cb46c66102740c679338b7093c47e8f586e48a8b042cb0ea2b901f6981e797c4 922 a614f52f02ffe3ae7f83fa4f9a243e8b59621975abffb94f82b3fadfb4cb305cc1c1b677 923 42a673204e5a0aa0c25423c604430597d0332e30dddab8855de42bcf49668410df38bb3b 924 fa4370df28ec59316bc1c6f3c9afc8ccfdb93f4ca60365683988f649201e1c6d6bb73d14 925 d0dc9a0f596a9f76502ebadc0b248985f9bb66d9d99a5aca08527aa11d555b26489299ba 926 5b400157a9fd47b6b4fa74315eade2b22624b29d53eb84126f64b98ea5ba45914d1fa14b 927 1525e2327856565054a1db9b0d778871fa6ed4d0d4c26641bf3f4faa33efaa0f5b8cec80 928 8d52ed3f1378273d5b7b0b0b812bfc128ef5e4924a60aebd124659d31661e9ec89f8bcb9 929 a51bab6a5711187639c24fdd31f14abf7d80827df91f31bfe7c4916ec4d1927ca138c5ba 930 9a595a9e83b5055148d19ad005c523eda76ea94006ce6315e20ed0d637fb1211b541e9ea 931 12c9b641d48fd2cc5f0c7f479672a4e2bf7469267c8526d734df41f2c30fb62c2aea4033 932 214df44a53353dc683cf72dee7b1ba39ef668478958935a0e8c9a880ae85712c401d7f09 933 b66fbad05cfd69d615b229bce8818c6a6472e07a8793456f19f4f4015c507ab5c1357881 934 68b 936 Authors' Addresses 937 SofĂ­a Celi 938 Cloudflare 939 Lisbon 940 Portugal 941 Email: sceli@cloudflare.com 943 Alex Davidson 944 Brave Software 945 Lisbon 946 Portugal 947 Email: alex.davidson92@gmail.com 949 Armando Faz-Hernandez 950 Cloudflare 951 101 Townsend St 952 San Francisco, 953 United States of America 954 Email: armfazh@cloudflare.com 956 Steven Valdez 957 Google LLC 958 Email: svaldez@chromium.org 960 Christopher A. Wood 961 Cloudflare 962 101 Townsend St 963 San Francisco, 964 United States of America 965 Email: caw@heapingbits.net