idnits 2.17.00 (12 Aug 2021) /tmp/idnits47541/draft-privacypass-rate-limit-tokens-02.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: ---------------------------------------------------------------------------- No issues found here. 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 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (2 May 2022) is 12 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Npk' is mentioned on line 645, but not defined == Missing Reference: 'Nk' is mentioned on line 882, but not defined -- Looks like a reference, but probably isn't: '32' on line 880 == Missing Reference: 'Nsig' is mentioned on line 666, but not defined == Missing Reference: 'Nid' is mentioned on line 881, but not defined == Outdated reference: A later version (-02) exists of draft-dew-cfrg-signature-key-blinding-01 -- Duplicate reference: draft-ietf-privacypass-protocol, mentioned in 'BASIC-ISSUANCE', was also mentioned in 'ISSUANCE'. Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hendrickson 3 Internet-Draft Google LLC 4 Intended status: Informational J. Iyengar 5 Expires: 3 November 2022 Fastly 6 T. Pauly 7 Apple Inc. 8 S. Valdez 9 Google LLC 10 C. A. Wood 11 Cloudflare 12 2 May 2022 14 Rate-Limited Token Issuance Protocol 15 draft-privacypass-rate-limit-tokens-02 17 Abstract 19 This document specifies a variant of the Privacy Pass issuance 20 protocol that allows for tokens to be rate-limited on a per-origin 21 basis. This enables origins to use tokens for use cases that need to 22 restrict access from anonymous clients. 24 Discussion Venues 26 This note is to be removed before publishing as an RFC. 28 Source for this draft and an issue tracker can be found at 29 https://github.com/tfpauly/privacy-proxy. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 3 November 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Properties and Requirements . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Token Challenge Requirements . . . . . . . . . . . . . . . . 9 70 5. Issuance Protocol . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. State Requirements . . . . . . . . . . . . . . . . . . . 10 72 5.1.1. Client State . . . . . . . . . . . . . . . . . . . . 11 73 5.1.2. Attester State . . . . . . . . . . . . . . . . . . . 12 74 5.1.3. Issuer State . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Issuance HTTP Headers . . . . . . . . . . . . . . . . . . 13 76 5.3. Client-to-Attester Request . . . . . . . . . . . . . . . 14 77 5.4. Attester-to-Issuer Request . . . . . . . . . . . . . . . 17 78 5.5. Issuer-to-Attester Response . . . . . . . . . . . . . . . 18 79 5.6. Attester-to-Client Response . . . . . . . . . . . . . . . 19 80 6. Encrypting Origin Token Requests and Responses . . . . . . . 20 81 6.1. Client to Issuer Encapsulation . . . . . . . . . . . . . 20 82 6.2. Issuer to Client Encapsulation . . . . . . . . . . . . . 22 83 7. Anonymous Issuer Origin ID Computation . . . . . . . . . . . 23 84 7.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25 85 7.1.1. Request Key . . . . . . . . . . . . . . . . . . . . . 25 86 7.1.2. Request Signature . . . . . . . . . . . . . . . . . . 25 87 7.2. Attester Behavior (Client Request Validation) . . . . . . 26 88 7.3. Issuer Behavior . . . . . . . . . . . . . . . . . . . . . 26 89 7.4. Attester Behavior (Index Computation) . . . . . . . . . . 27 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 91 8.1. Channel Security . . . . . . . . . . . . . . . . . . . . 28 92 8.2. Token Request Unlinkability and Unforgeability . . . . . 28 93 8.3. Information Disclosure . . . . . . . . . . . . . . . . . 29 94 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 95 9.1. Client Token State and Origin Tracking . . . . . . . . . 30 96 9.2. Origin Verification . . . . . . . . . . . . . . . . . . . 30 97 9.3. Client Identification with Unique Keys . . . . . . . . . 30 98 9.4. Origin Identification . . . . . . . . . . . . . . . . . . 31 99 9.5. Collusion Among Different Entities . . . . . . . . . . . 31 100 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 32 101 10.1. Token Key Management . . . . . . . . . . . . . . . . . . 32 102 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 103 11.1. Token Type . . . . . . . . . . . . . . . . . . . . . . . 32 104 11.1.1. ECDSA-based Token Type . . . . . . . . . . . . . . . 33 105 11.1.2. Ed25519-based Token Type . . . . . . . . . . . . . . 34 106 11.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 35 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 109 12.2. Informative References . . . . . . . . . . . . . . . . . 37 110 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 111 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 38 112 B.1. Origin Name Encryption Test Vector . . . . . . . . . . . 38 113 B.2. Anonymous Origin ID Test Vector . . . . . . . . . . . . . 39 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 116 1. Introduction 118 This document specifies a variant of the Privacy Pass issuance 119 protocol (as defined in [ARCH]) that allows for tokens to be rate- 120 limited on a per-origin basis. This enables origins to use tokens 121 for use cases that need to restrict access from anonymous clients. 123 The base Privacy Pass issuance protocol [ISSUANCE] defines stateless 124 anonymous tokens, which can either be publicly verifiable or not. 126 This variant build upon the publicly verifiable issuance protocol 127 that uses RSA Blind Signatures [BLINDSIG], and allows tokens to be 128 rate-limited on a per-origin basis. This means that a client will 129 only be able to receive a limited number of tokens associated with a 130 given origin server within a fixed period of time. 132 This issuance protocol registers the Rate-Limited Blind RSA token 133 type (Section 11.1), to be used with the PrivateToken HTTP 134 authentication scheme defined in [AUTHSCHEME]. 136 1.1. Motivation 138 A client that wishes to keep its IP address private can hide its IP 139 address using a proxy service or a VPN. However, doing so severely 140 limits the client's ability to access services and content, since 141 servers might not be able to enforce their policies without a stable 142 and unique client identifier. 144 Privacy Pass tokens in general allow clients to provide anonymous 145 attestation of various properties. The tokens generated by the base 146 issuance protocol ([ISSUANCE]) can be used to verify that a client 147 meets a particular bar for attestation, but cannot be used by a 148 redeeming server to rate-limit specific clients. 150 There are several use cases for rate-limiting anonymous clients that 151 are common on the Internet. These routinely use client IP address 152 tracking, among other characteristics, to implement rate-limiting. 154 One example of this use case is rate-limiting website accesses to a 155 client to help prevent fraud. Operations that are sensitive to 156 fraud, such as account creation on a website or logging into an 157 account, often employ rate-limiting as a defense-in-depth strategy. 158 Additional verification can be required by these pages when a client 159 exceeds a set rate-limit. 161 Another example of this use case is a metered paywall, where an 162 origin limits the number of page requests from each unique user over 163 a period of time before the user is required to pay for access. The 164 origin typically resets this state periodically, say, once per month. 165 For example, an origin may serve ten (major content) requests in a 166 month before a paywall is enacted. Origins may want to differentiate 167 quick refreshes from distinct accesses. 169 For some applications, the basic issuance protocol from 170 [BASIC-ISSUANCE] could be used to implement rate limits. In 171 particular, the 'Joint Attester and Issuer' model from [ARCH] could 172 be used to restrict the number of tokens issued to individual clients 173 over a time window. However, in this deployment model, the Attester 174 and Issuer would learn all origins used by a participating client. 175 In some cases this might be a significant portion of browsing 176 history. The issuance protocol defined in this document employs the 177 'Split Origin, Attester, Issuer' model to combat this, where the 178 issuer would know all per-origin policies, and the attester would 179 mantain per-client state without knowing all origins a client visits. 181 1.2. Properties and Requirements 183 For rate-limited token issuance, the Attester, Issuer, and Origin as 184 defined in [ARCH] each have partial knowledge of the Client's 185 identity and actions, and each entity only knows enough to serve its 186 function (see Section 2 for more about the pieces of information): 188 * The Attester knows the Client's identity and learns the Client's 189 public key (Client Key), the Issuer being targeted (Issuer Name), 190 the period of time for which the Issuer's policy is valid (Issuer 191 Policy Window), the number of tokens the Issuer is willing to 192 issue within the current policy window, and the number of tokens 193 issued to a given Client for the claimed Origin in the policy 194 window. The Attester does not know the identity of the Origin the 195 Client is trying to access (Origin Name), but knows a Client- 196 anonymized identifier for it (Anonymous Origin ID). 198 * The Issuer knows the Origin's secret (Issuer Origin Secret) and 199 policy about client access, and learns the Origin's identity 200 (Origin Name) during issuance. The Issuer does not learn the 201 Client's identity or information about the Client's access 202 pattern. 204 * The Origin knows the Issuer to which it will delegate an incoming 205 Client (Issuer Name), and can verify that any tokens presented by 206 the Client were signed by the Issuer. The Origin does not learn 207 which Attester was used by a Client for issuance. 209 Since an Issuer enforces policies on behalf of Origins, a Client is 210 required to reveal the Origin's identity to the delegated Issuer. It 211 is a requirement of this protocol that the Attester not learn the 212 Origin's identity so that, despite knowing the Client's identity, an 213 Attester cannot track and concentrate information about Client 214 activity. 216 An Issuer expects an Attester to verify its Clients' identities 217 correctly, but an Issuer cannot confirm an Attester's efficacy or the 218 Attester-Client relationship directly without learning the Client's 219 identity. Similarly, an Origin does not know the Attester's 220 identity, but ultimately relies on the Attester to correctly verify 221 or authenticate a Client for the Origin's policies to be correctly 222 enforced. An Issuer therefore chooses to issue tokens to only known 223 and reputable Attesters; the Issuer can employ its own methods to 224 determine the reputation of a Attester. 226 An Attester is expected to employ a stable Client identifier, such as 227 an IP address, a device identifier, or an account at the Attester, 228 that can serve as a reasonable proxy for a user with some creation 229 and maintenance cost on the user. 231 For the Issuance protocol, a Client is expected to create and 232 maintain stable and explicit secrets for time periods that are on the 233 scale of Issuer policy windows. Changing these secrets arbitrarily 234 during a policy window can result in token issuance failure for the 235 rest of the policy window; see Section 5.1.1 for more details. A 236 Client can use a service offered by its Attester or a third-party to 237 store these secrets, but it is a requirement of this protocol that 238 the Attester not be able to learn these secrets. 240 The privacy guarantees of this issuance protocol, specifically those 241 around separating the identity of the Client from the names of the 242 Origins that it accesses, are based on the expectation that there is 243 not collusion between the entities that know about Client identity 244 and those that know about Origin identity. Clients choose and share 245 information with Attesters, and Origins choose and share policy with 246 Issuers; however, the Attester is generally expected to not be 247 colluding with Issuers or Origins. If this occurs, it can become 248 possible for an Attester to learn or infer which Origins a Client is 249 accessing, or for an Origin to learn or infer the Client identity. 250 For further discussion, see Section 9.5. 252 2. Terminology 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in 257 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 258 capitals, as shown here. 260 Unless otherwise specified, this document encodes protocol messages 261 in TLS notation from [TLS13], Section 3. 263 This draft includes pseudocode that uses the functions and 264 conventions defined in [HPKE]. 266 Encoding an integer to a sequence of bytes in network byte order is 267 described using the function "encode(n, v)", where "n" is the number 268 of bytes and "v" is the integer value. The function "len()" returns 269 the length of a sequence of bytes. 271 The following terms are defined in [ARCH] and are used throughout 272 this document: 274 * Client: An entity that provides authorization tokens to services 275 across the Internet, in return for authorization. 277 * Issuer: An entity that produces Privacy Pass tokens to clients. 279 * Attester: An entity that can attest to properties about the 280 client, including previous patterns of access. 282 * Origin: The server from which the client can redeem tokens. 284 * Issuance Protocol: The protocol exchange that involves the client, 285 attester, and issuer, used to generate tokens. 287 The following terms are defined in [AUTHSCHEME], which defines the 288 interactions between clients and origins: 290 * Issuer Name: The name that identifies the Issuer, which is an 291 entity that can generate tokens for a Client using one or more 292 issuance protocols. 294 * Token Key: Keying material that can be used with an issuance 295 protocol to create a signed token. 297 * Origin Name: The name that identifies the Origin, as included in a 298 TokenChallenge. 300 Additionally, this document defines several terms that are unique to 301 the rate-limited issuance protocol: 303 * Issuer Policy Window: The period over which an Issuer will track 304 access policy, defined in terms of seconds and represented as a 305 uint64. The state that the Attester keeps for a Client is 306 specific to a policy window. The effective policy window for a 307 specific Client starts when the Client first sends a request 308 associated with an Issuer. 310 * Issuer Encapsulation Key: The public key used to encrypt values 311 such as Origin Name in requests from Clients to the Issuer, so 312 that Attesters cannot learn the Origin Name value. Each Issuer 313 Encapsulation Key is used across all requests on the Issuer, for 314 different Origins. 316 * Anonymous Origin ID: An identifier that is generated by the Client 317 and marked on requests to the Attester, which represents a 318 specific Origin anonymously. The Client generates a stable 319 Anonymous Origin ID for each Origin Name, to allow the Attester to 320 count token access without learning the Origin Name. 322 * Client Key: A public key chosen by the Client and shared only with 323 the Attester; see Section 8.2 for more details about this 324 restriction. 326 * Client Secret: The secret key used by the Client during token 327 issuance, whose public key (Client Key) is shared with the 328 Attester. 330 * Issuer Origin Secret: A per-origin secret key used by the Issuer 331 during token issuance, whose public key is not shared with anyone. 333 * Anonymous Issuer Origin ID: An identifier that is generated by 334 Issuer based on an Issuer Origin Secret that is per-Client and 335 per-Origin. See Section 5.6 for details of derivation. 337 3. Configuration 339 Issuers MUST provide three parameters for configuration: 341 1. Issuer Policy Window: a uint64 of seconds as defined in 342 Section 2. 344 2. Issuer Request URI: a token request URL for generating access 345 tokens. For example, an Issuer URL might be 346 https://issuer.example.net/token-request. This parameter uses 347 resource media type "text/plain". 349 3. Issuer Encapsulation Key: a EncapsulationKey structure as defined 350 below to use when encapsulating information, such as the origin 351 name, to the Issuer in issuance requests. This parameter uses 352 resource media type "application/issuer-encap-key". The Npk 353 parameter corresponding to the HpkeKdfId can be found in [HPKE]. 355 opaque HpkePublicKey[Npk]; // defined in RFC9180 356 uint16 HpkeKemId; // defined in RFC9180 357 uint16 HpkeKdfId; // defined in RFC9180 358 uint16 HpkeAeadId; // defined in RFC9180 360 struct { 361 uint8 key_id; 362 HpkeKemId kem_id; 363 HpkePublicKey public_key; 364 HpkeKdfId kdf_id; 365 HpkeAeadId aead_id; 366 } EncapsulationKey; 368 The Issuer parameters can be obtained from an Issuer via a directory 369 object, which is a JSON object whose field names and values are raw 370 values and URLs for the parameters. 372 +======================+=======================================+ 373 | Field Name | Value | 374 +======================+=======================================+ 375 | issuer-policy-window | Issuer Policy Window as a JSON number | 376 +----------------------+---------------------------------------+ 377 | issuer-request-uri | Issuer Request URI resource URL as a | 378 | | JSON string | 379 +----------------------+---------------------------------------+ 380 | issuer-encap-key-uri | Issuer Encapsulation Key URI resource | 381 | | URL as a JSON string | 382 +----------------------+---------------------------------------+ 384 Table 1 386 As an example, the Issuer's JSON directory could look like: 388 { 389 "issuer-token-window": 86400, 390 "issuer-request-uri": "https://issuer.example.net/token-request" 391 "issuer-encap-key-uri": "https://issuer.example.net/encap-key", 392 } 394 Issuer directory resources have the media type "application/json" and 395 are located at the well-known location /.well-known/token-issuer- 396 directory. 398 4. Token Challenge Requirements 400 Clients receive challenges for tokens, as described in [AUTHSCHEME]. 402 For the rate-limited token issuance protocol described in this 403 document, the name of the origin is sent in an encrypted message from 404 the Client to the Issuer. If the TokenChallenge.origin_info field 405 contains a single origin name, that origin name is used. If the 406 origin_info field contains multiple origin names, the client selects 407 the single origin name that presented the challenge. If the 408 origin_info field is empty, the encrypted message is the empty string 409 "". 411 The HTTP authentication challenge also SHOULD contain the following 412 additional attribute: 414 * "issuer-encap-key", which contains a base64url encoding of a 415 EncapsulationKey as defined in Section 3 to use when encrypting 416 the Origin Name in issuance requests. 418 5. Issuance Protocol 420 This section describes the Issuance protocol for a Client to request 421 and receive a token from an Issuer. Token issuance involves a 422 Client, Attester, and Issuer, with the following steps: 424 1. The Client sends a token request containing a token request, 425 encrypted origin name, and one-time-use public key and signature 426 to the Attester 428 2. The Attester validates the request contents, specifically 429 checking the request signature, and proxies the request to the 430 Issuer 432 3. The Issuer validates the request against the signature, and 433 processes its contents, and produces a token response sent back 434 to the Attester 436 4. The Attester verifies the response and proxies the response to 437 the Client 439 The Issuance protocol is designed such that Client, Attester, and 440 Issuer learn only what is necessary for completing the protocol; see 441 Section 8.3 for more details. 443 The Issuance protocol has a number of underlying cryptographic 444 dependencies for operation: 446 * RSA Blind Signatures [BLINDSIG], for issuing and constructing 447 Tokens. This support is the same as used in the base publicly 448 verifiable token issuance protocol [ISSUANCE] 450 * [HPKE], for encrypting the origin server name in transit between 451 Client and Issuer across the Attester. 453 * Signatures with key blinding, as described in [KEYBLINDING], for 454 verifying correctness of Client requests. 456 Clients and Issuers are required to implement all of these 457 dependencies, whereas Attesters are required to implement signature 458 with key blinding support. 460 5.1. State Requirements 462 The Issuance protocol requires each participating endpoint to 463 maintain some necessary state, as described in this section. 465 5.1.1. Client State 467 A Client is required to have the following information, derived from 468 a given TokenChallenge: 470 * Origin Name, a hostname referring to the Origin [RFC6454]. This 471 is the name of the Origin that issued the token challenge. One or 472 more names can be listed in the TokenChallenge.origin_info field. 473 Rate-limited token issuance relies on the client selecting a 474 single origin name from this list if multiple are present. 476 * Token Key, a blind signature public key corresponding to the 477 Issuer identified by the TokenChallenge.issuer_name. 479 * Issuer Encapsulation Key, a public key used to encrypt request 480 information corresponding to the Issuer identified by 481 TokenChallenge.issuer_name. 483 Clients maintain a stable Client Key that they use for all 484 communication with a specific Attester. Client Key is a public key, 485 where the corresponding private key Client Secret is known only to 486 the client. 488 If the client loses this (Client Key, Client Secret), they may 489 generate a new tuple. The Attester will enforce if a client is 490 allowed to use this new Client Key. See Section 5.1.2 for details on 491 this enforcement. 493 Clients also need to be able to generate an Anonymous Origin ID value 494 that corresponds to the Origin Name, to send in requests to the 495 Attester. 497 Anonymous Origin ID MUST be a stable and unpredictable 32-byte value 498 computed by the Client. Clients MUST NOT change this value across 499 token requests for the same Origin Name. Doing so will result in 500 token issuance failure (specifically, when an Attester rejects a 501 request upon detecting two Anonymous Origin ID values that map to the 502 same Origin). 504 One possible mechanism for implementing this identifier is for the 505 Client to store a mapping between the Origin Name and a randomly 506 generated Anonymous Origin ID for future requests. Alternatively, 507 the Client can compute a PRF keyed by a per-client secret (Client 508 Secret) over the Origin Name, e.g., Anonymous Origin ID = 509 HKDF(secret=Client Secret, salt="", info=Origin Name). 511 5.1.2. Attester State 513 An Attester is required to maintain state for every authenticated 514 Client. The mechanism of identifying a Client is specific to each 515 Attester, and is not defined in this document. As examples, the 516 Attester could use device-specific certificates or account 517 authentication to identify a Client. 519 Attesters must enforce that Clients don't change their Client Key 520 frequently, to ensure Clients can't regularly evade the per-client 521 policy as seen by the issuer. Attesters MUST NOT allow Clients to 522 change their Client Key more than once within a policy window, or in 523 the subsequent policy window after a previous Client Key change. 524 Alternative schemes where the Attester stores the encrypted (Client 525 Key, Client Secret) tuple on behalf of the client are possible but 526 not described here. 528 Attesters are expected to know the Issuer Policy Window for any 529 Issuer Name to which they allow access. This information can be 530 retrieved using the URIs defined in Section 3. 532 For each Client-Issuer pair, an Attester maintains a policy window 533 start and end time for each Issuer from which a Client requests a 534 token. 536 For each tuple of (Client Key, Anonymous Origin ID, policy window), 537 the Attester maintains the following state: 539 * A counter of successful tokens issued 541 * Whether or not a previous request was rejected by the Issuer 543 * The last received Anonymous Issuer Origin ID value for this 544 Anonymous Origin ID, if any 546 5.1.3. Issuer State 548 Issuers maintain a stable Issuer Origin Secret that they use in 549 calculating values returned to the Attester for each origin. If this 550 value changes, it will open up a possibility for Clients to request 551 extra tokens for an Origin without being limited, within a policy 552 window. See Section 10.1 for details about generating and rotating 553 the Issuer Origin Secret. 555 Issuers are expected to have the private key that corresponds to 556 Issuer Encapsulation Key, which allows them to decrypt the Origin 557 Name values in requests. 559 Issuers also need to know the set of valid Token Key public keys and 560 corresponding private key, for each Origin Name that is served by the 561 Issuer. Origins SHOULD update their view of the Token Key regularly 562 to ensure that Client requests do not fail after Token Key rotation. 564 5.2. Issuance HTTP Headers 566 The Issuance protocol defines four new HTTP headers that are used in 567 requests and responses between Clients, Attesters, and Issuers (see 568 Section 11.2). 570 The "Sec-Token-Origin" is an Item Structured Header [RFC8941]. Its 571 value MUST be a Byte Sequence. This header is sent both on Client- 572 to-Attester requests (Section 5.3) and on Issuer-to-Attester 573 responses (Section 5.5). Its ABNF is: 575 Sec-Token-Origin = sf-binary 577 The "Sec-Token-Client" is an Item Structured Header [RFC8941]. Its 578 value MUST be a Byte Sequence. This header is sent on Client-to- 579 Attester requests (Section 5.3), and contains the bytes of Client 580 Key. Its ABNF is: 582 Sec-Token-Client = sf-binary 584 The "Sec-Token-Request-Blind" is an Item Structured Header [RFC8941]. 585 Its value MUST be a Byte Sequence. This header is sent on Client-to- 586 Attester requests (Section 5.3), and contains a per-request nonce 587 value. Its ABNF is: 589 Sec-Token-Request-Blind = sf-binary 591 The "Sec-Token-Request-Key" is an Item Structured Header [RFC8941]. 592 Its value MUST be a Byte Sequence. This header is sent on Client-to- 593 Attester requests (Section 5.3), and contains a per-request public 594 key. Its ABNF is: 596 Sec-Token-Request-Key = sf-binary 598 The "Sec-Token-Limit" is an Item Structured Header [RFC8941]. Its 599 value MUST be an Integer. This header is sent on Issuer-to-Attester 600 responses (Section 5.5), and contains the number of times a Client 601 can retrieve a token for the requested Origin within a policy window, 602 as set by the Issuer. Its ABNF is: 604 Sec-Token-Limit = sf-integer 606 5.3. Client-to-Attester Request 608 The Client and Attester MUST use a secure and Attester-authenticated 609 HTTPS connection. They MAY use mutual authentication or mechanisms 610 such as TLS certificate pinning, to mitigate the risk of channel 611 compromise; see Section 8 for additional about this channel. 613 Requests to the Attester need to indicate the Issuer Name to which 614 issuance requests will be forwarded. Attesters SHOULD provide 615 Clients with a URI template that contains one variable that contains 616 the Issuer Name, "issuer", using Level 3 URI template encoding as 617 defined in Section 1.2 of [RFC6570]. 619 An example of an Attester URI templates is shown below: 621 https://attester.net/token-request{?issuer} 623 Attesters and Clients MAY agree on other mechanisms to specify the 624 Issuer Name in requests. 626 The Client first creates an issuance request message for a random 627 value nonce using the input TokenChallenge challenge and the Issuer 628 key identifier key_id as follows: 630 nonce = random(32) 631 context = SHA256(challenge) 632 token_input = concat(0x0003, nonce, context, key_id) 633 blinded_msg, blind_inv = rsabssa_blind(pkI, token_input) 635 The Client then uses Client Key to generate its one-time-use request 636 public key request_key and blind request_blind as described in 637 Section 7.1. 639 The Client then constructs a InnerTokenRequest value, denoted 640 origin_token_request, combining blinded_msg, request_key, and the 641 origin name as follows: 643 struct { 644 uint8_t blinded_msg[Nk]; 645 uint8_t request_key[Npk]; 646 uint8_t padded_origin_name<0..2^16-1>; 647 } InnerTokenRequest; 649 This structure is initialized and then encrypted using Issuer 650 Encryption Key, producing encrypted_token_request, as described in 651 Section 6. 653 Finally, the Client uses Client Secret to produce request_signature 654 as described in Section 7.1.2. 656 The Client then constructs a TokenRequest structure. This 657 TokenRequest structure is based on the publicly verifiable token 658 issuance path in [ISSUANCE], adding fields for the encrypted origin 659 name and request signature. 661 struct { 662 uint16_t token_type = 0x0003; 663 uint8_t token_key_id; 664 uint8_t issuer_encap_key_id[32]; 665 uint8_t encrypted_token_request<1..2^16-1>; 666 uint8_t request_signature[Nsig]; 667 } TokenRequest; 669 The structure fields are defined as follows: 671 * "token_type" is a 2-octet integer, which matches the type in the 672 challenge. 674 * "token_key_id" is the least significant byte of the Token Key key 675 ID, which is generated as SHA256(public_key), where public_key is 676 a DER-encoded SubjectPublicKeyInfo object carrying Token Key. 678 * "issuer_encap_key_id" is a collision-resistant hash that 679 identifies the Issuer Encryption Key, generated as 680 SHA256(EncapsulationKey). 682 * "encrypted_token_request" is an encrypted structure that contains 683 an InnerTokenRequest value, calculated as described in Section 6. 685 * "request_signature" is computed as described in Section 7.1.2. 687 The Client then generates an HTTP POST request to send through the 688 Attester to the Issuer, with the TokenRequest as the body. The media 689 type for this request is "message/token-request". The Client 690 includes the "Sec-Token-Origin" header, whose value is Anonymous 691 Origin ID; the "Sec-Token-Client" header, whose value is Client Key; 692 the "Sec-Token-Request-Blind" header, whose value is request_blind; 693 and the "Sec-Token-Request-Key" header, whose value is request_key. 694 The Client sends this request to the Attester's proxy URI. An 695 example request is shown below, where the Issuer Name is "issuer.net" 696 and the Attester URI template is "https://attester.net/token- 697 request{?issuer}" 698 :method = POST 699 :scheme = https 700 :authority = attester.net 701 :path = /token-request?issuer=issuer.net 702 accept = message/token-response 703 cache-control = no-cache, no-store 704 content-type = message/token-request 705 content-length = 706 sec-token-origin = Anonymous Origin ID 707 sec-token-client = Client Key 708 sec-token-request-blind = request_blind 709 sec-token-request-key = request_key 711 713 If the Attester detects a token_type in the TokenRequest that it does 714 not recognize or support, it MUST reject the request with an HTTP 400 715 error. 717 The Attester also checks to validate that the issuer_encap_key_id in 718 the client's TokenRequest matches a known Issuer Encapsulation Key 719 public key for the Issuer. For example, the Attester can fetch this 720 key using the API defined in Section 3. This check is done to help 721 ensure that the Client has not been given a unique key that could 722 allow the Issuer to fingerprint or target the Client. If the key 723 does not match, the Attester rejects the request with an HTTP 400 724 error. Note that this can lead to failures in the event of Issuer 725 Issuer Encapsulation Key rotation; see Section 9 for considerations. 727 The Attester finally validates the Client's stable mapping request as 728 described in Section 7.2. If this fails, the Attester MUST return an 729 HTTP 400 error to the Client. 731 If the Attester accepts the request, it will look up the state stored 732 for this Client. It will look up the count of previously generate 733 tokens for this Client using the same Anonymous Origin ID. See 734 Section 5.1.2 for more details. 736 If the Attester has stored state that a previous request for this 737 Anonymous Origin ID was rejected by the Issuer in the current policy 738 window, it SHOULD reject the request without forwarding it to the 739 Issuer. 741 If the Attester detects this Client has changed their Client Key more 742 frequently than allowed as described in Section 5.1.2, it SHOULD 743 reject the request without forwarding it to the Issuer. 745 5.4. Attester-to-Issuer Request 747 Assuming all checks in Section 5.3 succeed, the Attester generates an 748 HTTP POST request to send to the Issuer with the Client's 749 TokenRequest as the body. The Attester MUST NOT add information that 750 will uniquely identify a Client, or associate the request with a 751 small set of possible Clients. Extensions to this protocol MAY allow 752 Attesters to add information that can be used to separate large 753 populations, such as providing information about the country or 754 region to which a Client belongs. An example request is shown below. 756 :method = POST 757 :scheme = https 758 :authority = issuer.net 759 :path = /token-request 760 accept = message/token-response 761 cache-control = no-cache, no-store 762 content-type = message/token-request 763 content-length = 765 767 The Attester and the Issuer MUST use a secure and Issuer- 768 authenticated HTTPS connection. Also, Issuers MUST authenticate 769 Attesters, either via mutual TLS or another form of application-layer 770 authentication. They MAY additionally use mechanisms such as TLS 771 certificate pinning, to mitigate the risk of channel compromise; see 772 Section 8 for additional about this channel. 774 Upon receipt of the forwarded request, the Issuer validates the 775 following conditions: 777 * The TokenRequest contains a supported token_type 779 * The TokenRequest.token_key_id and TokenRequest.issuer_encap_key_id 780 correspond to known Token Keys and Issuer Encapsulation Keys held 781 by the Issuer. 783 * The TokenRequest.encrypted_token_request can be decrypted using 784 the Issuer's private key (the private key associated with Issuer 785 Encapsulation Key), and contains a valid InnerTokenRequest whose 786 unpadded origin name matches an Origin Name that is served by the 787 Issuer. The Origin name associated with the InnerTokenRequest 788 value might be the empty string "", as described in Section 6, in 789 which case the Issuer applies a cross-origin policy if supported. 790 If a cross-origin policy is not supported, this condition is not 791 met. 793 If any of these conditions is not met, the Issuer MUST return an HTTP 794 400 error to the Attester, which will forward the error to the 795 client. 797 The Issuer determines the correct Issuer Key by using the decrypted 798 Origin Name value and TokenRequest.token_key_id. If there is no 799 Token Key whose truncated key ID matches TokenRequest.token_key_id, 800 the Issuer MUST return an HTTP 401 error to Attester, which will 801 forward the error to the client. The Attester learns that the 802 client's view of the Origin key was invalid in the process. 804 5.5. Issuer-to-Attester Response 806 If the Issuer is willing to give a token to the Client, the Issuer 807 decrypts TokenRequest.encrypted_token_request to discover a 808 InnerTokenRequest value. If this fails, the Issuer rejects the 809 request with a 400 error. Otherwise, the Issuer validates and 810 processes the token request with Issuer Origin Secret corresponding 811 to the designated Origin as described in Section 7.3. If this fails, 812 the Issuer rejects the request with a 400 error. Otherwise, the 813 output is index_key. 815 The Issuer completes the issuance flow by computing a blinded 816 response as follows: 818 blind_sig = rsabssa_blind_sign(skP, InnerTokenRequest.blinded_msg) 820 skP is the private key corresponding to Token Key, known only to the 821 Issuer. The Issuer then encrypts blind_sig to the Client as 822 described in Section 6.2, yielding encrypted_token_response. 824 The Issuer generates an HTTP response with status code 200 whose body 825 consists of blind_sig, with the content type set as "message/token- 826 response", the index_key set in the "Sec-Token-Origin" header, and 827 the limit of tokens allowed for a Client for the Origin within a 828 policy window set in the "Sec-Token-Limit" header. This limit SHOULD 829 NOT be unique to a specific Origin, such that the Attester could use 830 the value to infer which Origin the Client is accessing (see 831 Section 9). 833 :status = 200 834 content-type = message/token-response 835 content-length = 836 sec-token-origin = index_key 837 sec-token-limit = Token limit 839 841 5.6. Attester-to-Client Response 843 Upon receipt of a successful response from the Issuer, the Attester 844 extracts the "Sec-Token-Origin" header, and uses the value to 845 determine Anonymous Issuer Origin ID as described in Section 7.4. 847 If the "Sec-Token-Origin" is missing, or if the same Anonymous Issuer 848 Origin ID was previously received in a response for a different 849 Anonymous Origin ID within the same policy window, the Attester MUST 850 drop the token and respond to the client with an HTTP 400 status. If 851 there is not an error, the Anonymous Issuer Origin ID is stored 852 alongside the state for the Anonymous Origin ID. 854 The Attester also extracts the "Sec-Token-Limit" header, and compares 855 the limit against the previous count of accesses for this Client for 856 the Anonymous Origin ID. If the count is greater than or equal to 857 the limit, the Attester drops the token and responds to the client 858 with an HTTP 429 (Too Many Requests) error. 860 For all other cases, the Attester forwards all HTTP responses 861 unmodified to the Client as the response to the original request for 862 this issuance. 864 When the Attester detects successful token issuance, it MUST 865 increment the counter in its state for the number of tokens issued to 866 the Client for the Anonymous Origin ID. 868 Upon receipt, the Client decrypts the blind_sig from 869 encrypted_token_response as described in Section 6.2. If successful, 870 the Client then processes the response as follows: 872 authenticator = rsabssa_finalize(pkI, token_input, blind_sig, blind_inv) 874 If this succeeds, the Client then constructs a token as described in 875 [AUTHSCHEME] as follows: 877 struct { 878 uint16_t token_type = 0x0003 879 uint8_t nonce[32]; 880 uint8_t context[32]; 881 uint8_t token_key_id[Nid]; 882 uint8_t authenticator[Nk] 883 } Token; 885 6. Encrypting Origin Token Requests and Responses 887 Clients encapsulate token request information to the Issuer using the 888 Issuer Encapsulation Key. Issuers decrypt the token request using 889 their corresponding private key. This process yields the decrypted 890 token request as well as a shared encryption context between Client 891 and Issuer. Issuers encapsulate their token response to the Client 892 using an ephemeral key derived from this shared encryption context. 893 This process ensures that the Attester learns neither the token 894 request or response information. 896 Client to Issuer encapsulation is described in Section 6.1, and 897 Issuer to Client encapsulation is described in Section 6.2. 899 6.1. Client to Issuer Encapsulation 901 Given a EncapsulationKey (Issuer Encapsulation Key), Clients produce 902 encrypted_token_request using the following values: 904 * the one octet key identifier from the Name Key, keyID, with the 905 corresponding KEM identified by kemID, the public key from the 906 configuration, pkI, and; 908 * a selected combination of KDF, identified by kdfID, and AEAD, 909 identified by aeadID. 911 Beyond the key configuration inputs, Clients also require the 912 following inputs defined in Section 5.3: token_key_id, blinded_msg, 913 request_key, origin_name, and issuer_encap_key_id. 915 Together, these are used to encapsulate an InnerTokenRequest and 916 produce an encrypted token request (encrypted_token_request). 918 origin_name contains the name of the origin that initiated the 919 challenge, as taken from the TokenChallenge.origin_info field. If 920 the TokenChallenge.origin_info field is empty, origin_name is set to 921 the empty string "". 923 The process for generating encrypted_token_request from blinded_msg, 924 request_key, and origin_name values is as follows: 926 1. Compute an [HPKE] context using pkI, yielding context and 927 encapsulation key enc. 929 2. Construct associated data, aad, by concatenating the values of 930 keyID, kemID, kdfID, aeadID, and all other values of the 931 TokenRequest structure. 933 3. Pad origin_name with N zero bytes, where N = 31 - ((L - 1) % 32) 934 and L is the length of origin_name. If L is 0, N = 32. Denote 935 this padding process as the function pad. 937 4. Encrypt (seal) the padded origin_name with aad as associated data 938 using context, yielding ciphertext ct. 940 5. Concatenate the values of aad, enc, and ct, yielding 941 encrypted_token_request. 943 Note that enc is of fixed-length, so there is no ambiguity in parsing 944 this structure. 946 In pseudocode, this procedure is as follows: 948 enc, context = SetupBaseS(pkI, "InnerTokenRequest") 949 aad = concat(encode(1, keyID), 950 encode(2, kemID), 951 encode(2, kdfID), 952 encode(2, aeadID), 953 encode(2, token_type), 954 encode(1, token_key_id), 955 encode(32, issuer_encap_key_id)) 956 padded_origin_name = pad(origin_name) 957 input = concat(encode(Nk, blinded_msg), 958 encode(49, request_key), 959 encode(len(padded_origin_name), padded_origin_name)) 960 ct = context.Seal(aad, input) 961 encrypted_token_request = concat(enc, ct) 963 Issuers reverse this procedure to recover the InnerTokenRequest value 964 by computing the AAD as described above and decrypting 965 encrypted_token_request with their private key skI (the private key 966 corresponding to pkI). The origin_name value is recovered from 967 InnerTokenRequest.padded_origin_name by stripping off padding bytes. 968 In pseudocode, this procedure is as follows: 970 enc, ct = parse(encrypted_token_request) 971 aad = concat(encode(1, keyID), 972 encode(2, kemID), 973 encode(2, kdfID), 974 encode(2, aeadID), 975 encode(2, token_type), 976 encode(1, token_key_id), 977 encode(32, issuer_encap_key_id)) 978 context = SetupBaseR(enc, skI, "TokenRequest") 979 origin_token_request, error = context.Open(aad, ct) 980 The InnerTokenRequest.blinded_msg and InnerTokenRequest.request_key 981 values, along with the unpadded origin_name value, are used by the 982 Issuer as described in Section 5.4. 984 6.2. Issuer to Client Encapsulation 986 Given an HPKE context context computed in Section 6.1, Issuers 987 encapsulate their token response blind_sig, yielding an encrypted 988 token response encrypted_token_response, to the Client as follows: 990 1. Export a secret secret from context, using the string 991 "OriginTokenResponse" as context. The length of this secret is 992 max(Nn, Nk), where Nn and Nk are the length of AEAD key and nonce 993 associated with context. 995 2. Generate a random value of length max(Nn, Nk) bytes, called 996 response_nonce. 998 3. Extract a pseudorandom key prk using the Extract function 999 provided by the KDF algorithm associated with context. The ikm 1000 input to this function is secret; the salt input is the 1001 concatenation of enc (from enc_request) and response_nonce 1003 4. Use the Expand function provided by the same KDF to extract an 1004 AEAD key key, of length Nk - the length of the keys used by the 1005 AEAD associated with context. Generating key uses a label of 1006 "key". 1008 5. Use the same Expand function to extract a nonce nonce of length 1009 Nn - the length of the nonce used by the AEAD. Generating nonce 1010 uses a label of "nonce". 1012 6. Encrypt blind_sig, passing the AEAD function Seal the values of 1013 key, nonce, empty aad, and a pt input of request, which yields 1014 ct. 1016 7. Concatenate response_nonce and ct, yielding an Encapsulated 1017 Response enc_response. Note that response_nonce is of fixed- 1018 length, so there is no ambiguity in parsing either response_nonce 1019 or ct. 1021 In pseudocode, this procedure is as follows: 1023 secret = context.Export("OriginTokenResponse", Nk) 1024 response_nonce = random(max(Nn, Nk)) 1025 salt = concat(enc, response_nonce) 1026 prk = Extract(salt, secret) 1027 aead_key = Expand(prk, "key", Nk) 1028 aead_nonce = Expand(prk, "nonce", Nn) 1029 ct = Seal(aead_key, aead_nonce, "", blind_sig) 1030 encrypted_token_response = concat(response_nonce, ct) 1032 Clients decrypt encrypted_token_response by reversing this process. 1033 That is, they first parse enc_response into response_nonce and ct. 1034 They then follow the same process to derive values for aead_key and 1035 aead_nonce. 1037 The client uses these values to decrypt ct using the Open function 1038 provided by the AEAD. Decrypting might produce an error, as follows: 1040 blind_sig, error = Open(aead_key, aead_nonce, "", ct) 1042 7. Anonymous Issuer Origin ID Computation 1044 This section describes the Client, Attester, and Issuer behavior in 1045 computing Anonymous Issuer Origin ID, the stable mapping based on 1046 client identity and origin name. At a high level, this functionality 1047 computes y = F(x, k), where x is a per-Client secret and k is a per- 1048 Origin secret, subject to the following constraints: 1050 * The Attester only learns y if the Client in possession of x 1051 engages with the protocol; 1053 * The Attester prevents a Client with private input x from running 1054 the protocol for input x' that is not equal to x; 1056 * The Issuer does not learn x, nor does it learn when two requests 1057 correspond to the same private value x; and 1059 * Neither the Client nor Attester learn k. 1061 The interaction between Client, Attester, and Issuer in computing 1062 this functionality is shown below. 1064 Client Attester Issuer 1065 (request, signature) 1066 ----------------------> 1067 (request, signature) 1068 ----------------------> 1069 (response) 1070 <---------------------- 1072 The protocol for computing this functionality is divided into 1073 sections for each of the participants. Section 7.1 describes Client 1074 behavior for initiating the computation with its per-Client secret, 1075 Section 7.2 describes Attester behavior for verifying Client 1076 requests, Section 7.3 describes Issuer behavior for computing the 1077 mapping with its per-Origin secret, and Section 7.4 describes the 1078 final Attester step for computing the client-origin index. 1080 The index computation is based on a signature scheme with key 1081 blinding and unblinding support, denoted BKS, as described in 1082 [KEYBLINDING]. Such a scheme has the following functions: 1084 * BKS-KeyGen(): Generate a random private and public key pair (sk, 1085 pk). 1087 * BKS-BlindKeyGen(): Generate a random blinding key bk. 1089 * BKS-BlindPublicKey(pk, bk): Produce a blinded public key based on 1090 the input public key pk and blind key bk according to 1091 [KEYBLINDING], Section 6.1. 1093 * BKS-Verify(pk, msg, sig): Verify signature sig over input message 1094 msg against the public key pk, producing a boolean value 1095 indicating success. 1097 * BKS-BlindKeySign(sk_sign, sk_blind, msg): Sign input message msg 1098 with signing key sk_sign and blind key sk_blind according to 1099 [KEYBLINDING], Section 6.2, and produce a signature of size Nsig 1100 bytes. 1102 * BKS-SerializePrivatekey(sk): Serialize a private key to a byte 1103 string of length Nsk. 1105 * BKS-DeserializePrivatekey(buf): Attempt to deserialize a private 1106 key from an Nsk-byte string buf. This function can fail if buf 1107 does not represent a valid private key. 1109 * BKS-SerializePublicKey(pk): Serialize a public key to a byte 1110 string of length Npk. 1112 * BKS-DeserializePublicKey(buf): Attempt to deserialize a public key 1113 of length Npk. This function can fail if buf does not represent a 1114 valid public key. 1116 Additionally, each BKS scheme has a corresponding hash function, 1117 denoted Hash. The implementation of each of these functions depends 1118 on the issuance protocol token type. See Section 11.1 for more 1119 details. 1121 7.1. Client Behavior 1123 This section describes the Client behavior for generating an one- 1124 time-use request key and signature. Clients provide their Client 1125 Secret as input to the request key generation step, and the rest of 1126 the token request inputs to the signature generation step. 1128 7.1.1. Request Key 1130 Clients produce request_key by masking Client Key and Client Secret 1131 with a randomly chosen blind. Let pk_sign and sk_sign denote Client 1132 Key and Client Secret, respectively. This process is done as 1133 follows: 1135 1. Generate a random blind key, sk_blind. 1137 2. Blind pk_sign with sk_blind to compute a blinded public key, 1138 request_key. 1140 3. Output the blinded public key. 1142 In pseudocode, this is as follows: 1144 sk_blind = BKS-BlindKeyGen() 1145 blinded_key = BKS-BlindPublicKey(pk_sign, sk_blind) 1146 request_key = BKS-SerializePublicKey(blinded_key) 1147 request_blind = BKS-SerializePrivatekey(sk_blind) 1149 7.1.2. Request Signature 1151 Clients produce signature of their request based on the following 1152 inputs defined in Section 5.3: token_key_id, blinded_msg, 1153 request_key, issuer_encap_key_id, encrypted_token_request. This 1154 process requires the blind value sk_blind produced during the 1155 Section 7.1.1 process. As above, let pk and sk denote Client Key and 1156 Client Secret, respectively. Given these values, this signature 1157 process works as follows: 1159 1. Concatenate all signature inputs to yield a message to sign. 1161 2. Compute a signature with the blind sk_blind over the input 1162 message using Client Secret, sk_sign as the signing key. 1164 3. Output the signature. 1166 In pseudocode, this is as follows: 1168 context = concat(token_type, 1169 token_key_id, 1170 issuer_encap_key_id, 1171 encrypted_token_request) 1172 request_signature = BKS-BlindKeySign(sk_sign, sk_blind, context) 1174 7.2. Attester Behavior (Client Request Validation) 1176 Given a TokenRequest request containing request_key, 1177 request_signature, and request_blind, as well as Client Key pk_blind, 1178 Attesters verify the signature as follows: 1180 1. Check that request_key is a valid public key. If this fails, 1181 abort. 1183 2. Check that request_blind is a valid private key. If this fails, 1184 abort. 1186 3. Blind the Client Key pk_sign by blind sk_blind, yielding a 1187 blinded key. If this does not match request_key, abort. 1189 4. Verify request_signature over the contents of the request, 1190 excluding the signature itself, using request_key. If signature 1191 verification fails, abort. 1193 In pseudocode, this is as follows: 1195 blind_key = BKS-DeserializePublicKey(request_key) 1196 sk_blind = BKS-DeserializePrivatekey(request_blind) 1197 pk_blind = BKS-BlindPublicKey(pk_sign, sk_blind) 1198 if pk_blind != blind_key: 1199 raise InvalidParameterError 1201 context = parse(request[..len(request)-Nsig]) // this matches context computed during signing 1202 valid = BKS-Verify(blind_key, context, request_signature) 1203 if not valid: 1204 raise InvalidSignatureError 1206 7.3. Issuer Behavior 1208 Given an Issuer Origin Secret (denoted sk_origin) and a TokenRequest, 1209 from which request_key and request_signature are parsed, Issuers 1210 verify the request signature and compute a response as follows: 1212 1. Check that request_key is a valid public key. If this fails, 1213 abort. 1215 2. Verify request_signature over the contents of the request, 1216 excluding the signature itself, using request_key. If signature 1217 verification fails, abort. 1219 3. Blind request_key by Issuer Origin Secret, sk_origin, yielding an 1220 index key. 1222 4. Output the index key. 1224 In pseudocode, this is as follows: 1226 blind_key = BKS-DeserializePublicKey(request_key) 1227 context = parse(request[..len(request)-Nsig]) // this matches context computed during signing 1228 valid = BKS-Verify(blind_key, context, request_signature) 1229 if not valid: 1230 raise InvalidSignatureError 1232 evaluated_key = BKS-BlindPublicKey(request_key, sk_origin) 1233 index_key = BKS-SerializePublicKey(evaluated_key) 1235 7.4. Attester Behavior (Index Computation) 1237 Given an Issuer response index_key, Client blind sk_blind, and Client 1238 Key (denoted pk_sign), Attesters complete the Anonymous Issuer Origin 1239 ID computation as follows: 1241 1. Check that index_key is a valid public key. If this fails, 1242 abort. 1244 2. Unblind the index_key using the Client blind sk_blind, yielding 1245 the index result. 1247 3. Run HKDF [RFC5869] with the hash function corresponding to the 1248 BKS scheme, using the index result as the secret, Client Key 1249 pk_sign as the salt, and ASCII string "anon_issuer_origin_id" as 1250 the info string, yielding Anonymous Issuer Origin ID. 1252 In pseudocode, this is as follows: 1254 evaluated_key = BKS-DeserializePublicKey(index_key) 1255 unblinded_key = BKS-UnblindPublicKey(evaluated_key, sk_blind) 1257 index_result = BKS-SerializePublicKey(unblinded_key) 1258 pk_encoded = BKS-SerializePublicKey(pk_sign) 1260 anon_issuer_origin_id = HKDF-Hash(secret=index_result, 1261 salt=pk_encoded, info="anon_issuer_origin_id") 1263 8. Security Considerations 1265 This section describes security considerations relevant to the use of 1266 this protocol. 1268 8.1. Channel Security 1270 An attacker that can act as an intermediate between Attester and 1271 Issuer communication can influence or disrupt the ability for the 1272 Issuer to correctly rate-limit token issuance. All communication 1273 channels use server-authenticated HTTPS. Some connections, e.g., 1274 between an Attester and an Issuer, require mutual authentication 1275 between both endpoints. Where appropriate, endpoints MAY use further 1276 enhancements such as TLS certificate pinning to mitigate the risk of 1277 channel compromise. 1279 8.2. Token Request Unlinkability and Unforgeability 1281 Client token requests are constructed such that an Issuer cannot 1282 distinguish between any two token requests from the same Client and 1283 two requests from different Clients. We refer to this property as 1284 issuance unlinkability. This property is achieved by the way the 1285 tokens are constructed. In particular, TokenRequest.request_key and 1286 TokenRequest.request_signature are the only value in a TokenRequest 1287 that is derived from per-Client information, i.e., the Client Secret. 1289 TokenRequest.request_key is computed using a freshly generated blind 1290 for each token request. As a result, the value of 1291 TokenRequest.request_key in one token request is statistically 1292 independent from Client Key. Similarly, 1293 TokenRequest.request_signature is computed using the same freshly 1294 generated blind as TokenRequest.request_key for each token request, 1295 and the resulting signature is therefore independent from signatures 1296 produced using Client Secret. More details about this unlinkability 1297 property can be found in [KEYBLINDING]. 1299 This unlinkability property is only intended for requests observed by 1300 the Issuer. In contrast, the Attester is required to link requests 1301 from the same Client together for the purposes of enforcing rate 1302 limits. This Attester does this by observing the Client Key. 1303 Importantly, the Client Key is not sent to the Issuer during the 1304 issuance flow, as doing this would allow the Issuer to trivially link 1305 two requests to the same Client. 1307 The token request signature is also required to be unforgeable. 1308 Informally, unforgeability means that no entity can produce a valid 1309 (message, signature) pair for any blinding key without access to the 1310 private signing key. Importantly, the means the Attester cannot 1311 forge signatures on behalf of a given Client in an attempt to learn 1312 the origin name. 1314 8.3. Information Disclosure 1316 The protocol in this document is designed such that information 1317 pertaining to issuance of a token is limited to parties that need it 1318 for completing the protocol. In particular, honest-but-curious 1319 Attesters learn only the Anonymous Issuer Origin ID as described in 1320 Section 7, any per-Client information necessary for attestation, and 1321 the target Issuer for a given token request. The Attester does not 1322 directly learn the origin name associated with a given token request, 1323 though it does learn the distribution of tokens across Client 1324 interactions. This auxiliary information could be used to infer the 1325 Origin for a given token. For example, if an Issuer has only two 1326 configured Origins, each with a different token request pattern, then 1327 the distribution of Client tokens might reveal the Origin associated 1328 with a given token. 1330 Malicious or otherwise compromised Attesters can choose to not follow 1331 the protocol described in this specification, allowing, for example, 1332 Clients to bypass rate limits imposed by Origins. Moreover, 1333 malicious Attesters could reveal the per-request blind 1334 (request_blind) to Issuers, breaking the unlinkability property 1335 described in Section 8.2. 1337 Honest-but-curious Issuers only learn the Attester that vouches for a 1338 particular Client's token request and the origin name associated with 1339 a token request. Issuers do not learn the Anonymous Issuer Origin ID 1340 or any per-Client information used when creating a token request. 1342 Conversely, malicious Issuers that do not follow the protocol can 1343 choose to not validate the token request signature, thereby allowing 1344 others to forge token requests in an attempt to learn the origin 1345 name. Malicious Issuers can also rotate token signing keys or Issuer 1346 Origin Secret values frequently in an attempt to bypass Attester- 1347 enforced rate limits. Both of these are detectable by the Attester, 1348 though. Issuers can also lie about per-origin rate limits without 1349 detection, e.g., by increasing the limit to a value well beyond any 1350 configured limit by an Origin, or return different limits for 1351 different origins to the Attester. 1353 Clients learn the output token. They do not learn the Anonymous 1354 Issuer Origin ID, though the security of the protocol does not depend 1355 on keeping this value secret from Clients. Moreover, even malicious 1356 Clients cannot tamper with per-Client state stored on the Attester 1357 for other Clients, as doing so requires knowledge of their unique 1358 Client Secret. 1360 9. Privacy Considerations 1362 This section describes privacy considerations relevant to use of this 1363 protocol. 1365 9.1. Client Token State and Origin Tracking 1367 Origins SHOULD only generate token challenges based on client action, 1368 such as when a user loads a website. Clients SHOULD ignore token 1369 challenges if an Origin tries to force the client to present tokens 1370 multiple times without any new client-initiated action. Failure to 1371 do so can allow malicious origins to track clients across contexts. 1372 Specifically, an origin can abuse per-user token limits for tracking 1373 by assigning each new client a random token count and observing 1374 whether or not the client can successfully redeem that many tokens in 1375 a given context. If any token redemption fails, then the origin 1376 learns information about how many tokens that client had previously 1377 been issued. 1379 By rejecting repeated or duplicative challenges within a single 1380 context, the origin only learns a single bit of information: whether 1381 or not the client had any token quota left in the given policy 1382 window. 1384 9.2. Origin Verification 1386 Rate-limited tokens are defined in terms of a Client authenticating 1387 to an Origin, where the "origin" is used as defined in [RFC6454]. In 1388 order to limit cross-origin correlation, Clients MUST verify that the 1389 name of the origin that is providing the HTTP authentication 1390 challenge is present in the TokenChallenge.origin_info list 1391 ([AUTHSCHEME]), where the matching logic is defined for same-origin 1392 policies in [RFC6454]. Clients MAY further limit which 1393 authentication challenges they are willing to respond to, for example 1394 by only accepting challenges when the origin is a web site to which 1395 the user navigated. 1397 9.3. Client Identification with Unique Keys 1399 Client activity could be linked if an Origin and Issuer collude to 1400 have unique keys targeted at specific Clients or sets of Clients. 1402 To mitigate the risk of a targeted Issuer Encapsulation Key, the 1403 Attester can observe and validate the token_key_id presented by the 1404 Client to the Issuer. As described in Section 5, Attesters MUST 1405 validate that the token_key_id in the Client's TokenRequest matches a 1406 known public key for the Issuer. The Attester needs to support key 1407 rotation, but ought to disallow very rapid key changes, which could 1408 indicate that an Origin is colluding with an Issuer to try to rotate 1409 the key for each new Client in order to link the client activity. 1411 9.4. Origin Identification 1413 As stated in Section 1.2, the design of this protocol is such that 1414 Attesters cannot learn the identity of origins that Clients are 1415 accessing. The Origin Name itself is encrypted in the request 1416 between the Client and the Issuer, so the Attester cannot directly 1417 learn the value. However, in order to prevent the Attester from 1418 inferring the value, additional constraints need to be added: 1420 * Each Issuer SHOULD serve tokens to a large number of Origins. A 1421 one-to-one relationship between Origin and Issuer would allow an 1422 Attester to infer which Origin is accessed simply by observing the 1423 Issuer identity. 1425 * Issuers SHOULD NOT return rate-limit values that are specific to 1426 Origins, such that an Attester can infer which Origin is accessed 1427 by observing the rate limit. This can be mitigated by having many 1428 Origins share the same rate-limit value. 1430 Some deployments MAY choose to relax these requirements, such as in 1431 cases where the origins being accessed are ubiquitous or do not 1432 correspond to user-specific behavior. 1434 9.5. Collusion Among Different Entities 1436 Collusion among the different entities in the Privacy Pass 1437 architecture can result in exposure of a client's per-origin access 1438 patterns. 1440 For this issuance protocol, Issuers and Attesters should be run by 1441 mutually distinct organizations to limit information sharing. A 1442 single entity running an Issuer and Attester for a single token 1443 issuance flow can view the origins being accessed by a given client. 1444 Running the Issuer and Attester in this 'single Issuer/Attester' 1445 fashion reduces the privacy promises of no one entity being able to 1446 learn Client browsing patterns. This may be desirable for a 1447 redemption flow that is limited to specific Issuers and Attesters, 1448 but should be avoided where hiding origin names from the Attester is 1449 desirable. 1451 If a Attester and Origin are able to collude, they can correlate a 1452 client's identity and origin access patterns through timestamp 1453 correlation. The timing of a request to an Origin and subsequent 1454 token issuance to a Attester can reveal the Client identity (as known 1455 to the Attester) to the Origin, especially if repeated over multiple 1456 accesses. 1458 10. Deployment Considerations 1460 10.1. Token Key Management 1462 Issuers SHOULD generate a new (Token Key, Issuer Origin Secret) 1463 regularly, and SHOULD maintain old and new secrets to allow for 1464 graceful updates. The RECOMMENDED rotation interval is two times the 1465 length of the policy window for that information. During generation, 1466 issuers must ensure the token_key_id (the 8-bit prefix of 1467 SHA256(Token Key)) is different from all other token_key_id values 1468 for that origin currently in rotation. One way to ensure this 1469 uniqueness is via rejection sampling, where a new key is generated 1470 until its token_key_id is unique among all currently in rotation for 1471 the origin. 1473 11. IANA considerations 1475 11.1. Token Type 1477 This document updates the "Token Type" Registry ([AUTHSCHEME]) with 1478 the following value: 1480 +======+=============+==========+========+========+===+===+=========+ 1481 |Value |Name |Publicly |Public |Private |Nk |Nid|Reference| 1482 | | |Verifiable|Metadata|Metadata| | | | 1483 +======+=============+==========+========+========+===+===+=========+ 1484 |0x0003|Rate-Limited |Y |N |N |512|32 |This | 1485 | |Blind | | | | | |document | 1486 | |RSA(SHA-384, | | | | | | | 1487 | |2048-bit) | | | | | | | 1488 | |with | | | | | | | 1489 | |ECDSA(P-384, | | | | | | | 1490 | |SHA-384) | | | | | | | 1491 +------+-------------+----------+--------+--------+---+---+---------+ 1492 |0x0004|Rate-Limited |Y |N |N |512|32 |This | 1493 | |Blind | | | | | |document | 1494 | |RSA(SHA-384, | | | | | | | 1495 | |2048-bit) | | | | | | | 1496 | |with | | | | | | | 1497 | |Ed25519(SHA- | | | | | | | 1498 | |512) | | | | | | | 1499 +------+-------------+----------+--------+--------+---+---+---------+ 1501 Table 2: Token Types 1503 The details of the signature scheme with key blinding and unblinding 1504 functions for each token type above are described in the following 1505 sections. 1507 11.1.1. ECDSA-based Token Type 1509 This section describes the implementation details of the signature 1510 scheme with key blinding and unblinding functions introduced in 1511 Section 7 using [ECDSA] with P-384 as the underlying elliptic curve 1512 and SHA-384 as the corresponding hash function. 1514 * BKS-KeyGen(): Generate a random ECDSA private and public key pair 1515 (sk, pk). 1517 * BKS-BlindKeyGen(): Generate a random ECDSA private key bk. 1519 * BKS-BlindPublicKey(pk, bk): Produce a blinded public key based on 1520 the input public key pk and blind bk according to [KEYBLINDING], 1521 Section 6.1. 1523 * BKS-Verify(pk, msg, sig): Verify the DER-encoded [X690] BKS-Sig- 1524 Value signature sig over input message msg against the ECDSA 1525 public key pk, producing a boolean value indicating success. 1527 * BKS-BlindKeySign(sk_sign, sk_blind, msg): Sign input message msg 1528 with signing key sk_sign and blind sk_blind according to 1529 [KEYBLINDING], Section 6.2, and serializes the resulting signature 1530 pair (r, s) in "raw" form, i.e., as the concatenation of two 1531 48-byte, big endian scalars, yielding an Nsig=96 byte signature. 1533 * BKS-SerializePrivatekey(sk): Serialize an ECDSA private key using 1534 the Field-Element-to-Octet-String conversion according to [SECG]. 1536 * BKS-DeserializePrivatekey(buf): Attempt to deserialize an ECDSA 1537 private key from a 48-byte string buf using Octet-String-to-Field- 1538 Element from [SECG]. This function can fail if buf does not 1539 represent a valid private key. 1541 * BKS-SerializePublicKey(pk): Serialize an ECDSA public key using 1542 the compressed Elliptic-Curve-Point-to-Octet-String method 1543 according to [SECG]. 1545 * BKS-DeserializePublicKey(buf): Attempt to deserialize a public key 1546 using the compressed Octet-String-to-Elliptic-Curve-Point method 1547 according to [SECG], and then performs partial public-key 1548 validation as defined in section 5.6.2.3.4 of [KEYAGREEMENT]. 1549 This validation includes checking that the coordinates are in the 1550 correct range, that the point is on the curve, and that the point 1551 is not the point at infinity. 1553 11.1.2. Ed25519-based Token Type 1555 This section describes the implementation details of the signature 1556 scheme with key blinding and unblinding functions introduced in 1557 Section 7 using Ed25519 as described in [RFC8032]. 1559 * BKS-KeyGen(): Generate a random Ed25519 private and public key 1560 pair (sk, pk), where sk is randomly generated 32 bytes (See 1561 [RFC4086] for information about randomness generation) and pk is 1562 computed according to [RFC8032], Section 5.1.5. 1564 * BKS-BlindKeyGen(): Generate and output 32 random bytes. 1566 * BKS-BlindPublicKey(pk, bk): Produce a blinded public key based on 1567 the input public key pk and blind bk according to [KEYBLINDING], 1568 Section 5.1. 1570 * BKS-Verify(pk, msg, sig): Verify the signature sig over input 1571 message msg against the Ed25519 public key pk, as defined in 1572 [RFC8032], Section 5.1.7, producing a boolean value indicating 1573 success. 1575 * BKS-BlindKeySign(sk_sign, sk_blind, msg): Sign input message msg 1576 with signing key sk_sign and blind sk_blind according to 1577 [KEYBLINDING], Section 5.2, yielding an Nsig=64 byte signature. 1579 * BKS-SerializePrivatekey(sk): Identity function which outputs sk as 1580 an Nsk=32 byte buffer. 1582 * BKS-DeserializePrivatekey(buf): Identity function which outputs 1583 buf interpreted as sk. 1585 * BKS-SerializePublicKey(pk): Identity function which outputs pk as 1586 an Npk=32 byte buffer. 1588 * BKS-DeserializePublicKey(buf): Identity function which outputs buf 1589 interpreted as pk. 1591 11.2. HTTP Headers 1593 This document registers four new headers for use on the token 1594 issuance path in the "Permanent Message Header Field Names" 1595 . 1597 +-------------------------+----------+--------+---------------+ 1598 | Header Field Name | Protocol | Status | Reference | 1599 +-------------------------+----------+--------+---------------+ 1600 | Sec-Token-Origin | http | std | This document | 1601 +-------------------------+----------+--------+---------------+ 1602 | Sec-Token-Client | http | std | This document | 1603 +-------------------------+----------+--------+---------------+ 1604 | Sec-Token-Request-Blind | http | std | This document | 1605 +-------------------------+----------+--------+---------------+ 1606 | Sec-Token-Request-Key | http | std | This document | 1607 +-------------------------+----------+--------+---------------+ 1608 | Sec-Token-Limit | http | std | This document | 1609 +-------------------------+----------+--------+---------------+ 1611 Figure 1: Registered HTTP Header 1613 12. References 1615 12.1. Normative References 1617 [ARCH] Davidson, A., Iyengar, J., and C. A. Wood, "Privacy Pass 1618 Architectural Framework", Work in Progress, Internet- 1619 Draft, draft-ietf-privacypass-architecture-03, 7 March 1620 2022, . 1623 [AUTHSCHEME] 1624 Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass 1625 HTTP Authentication Scheme", Work in Progress, Internet- 1626 Draft, draft-ietf-privacypass-auth-scheme-02, 4 April 1627 2022, . 1630 [BLINDSIG] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind 1631 Signatures", Work in Progress, Internet-Draft, draft-irtf- 1632 cfrg-rsa-blind-signatures-03, 2 February 2022, 1633 . 1636 [ECDSA] American National Standards Institute, "Public Key 1637 Cryptography for the Financial Services Industry - The 1638 Elliptic Curve Digital Signature Algorithm (ECDSA)", 1639 ANSI ANS X9.62-2005, November 2005. 1641 [HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 1642 Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, 1643 February 2022, . 1645 [ISSUANCE] Celi, S., Davidson, A., Faz-Hernandez, A., Valdez, S., and 1646 C. A. Wood, "Privacy Pass Issuance Protocol", Work in 1647 Progress, Internet-Draft, draft-ietf-privacypass-protocol- 1648 04, 5 April 2022, . 1651 [KEYAGREEMENT] 1652 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1653 Davis, "Recommendation for pair-wise key-establishment 1654 schemes using discrete logarithm cryptography", National 1655 Institute of Standards and Technology report, 1656 DOI 10.6028/nist.sp.800-56ar3, April 2018, 1657 . 1659 [KEYBLINDING] 1660 Denis, F., Eaton, E., and C. A. Wood, "Key Blinding for 1661 Signature Schemes", Work in Progress, Internet-Draft, 1662 draft-dew-cfrg-signature-key-blinding-01, 7 March 2022, 1663 . 1666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1667 Requirement Levels", BCP 14, RFC 2119, 1668 DOI 10.17487/RFC2119, March 1997, 1669 . 1671 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1672 Key Derivation Function (HKDF)", RFC 5869, 1673 DOI 10.17487/RFC5869, May 2010, 1674 . 1676 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1677 DOI 10.17487/RFC6454, December 2011, 1678 . 1680 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1681 and D. Orchard, "URI Template", RFC 6570, 1682 DOI 10.17487/RFC6570, March 2012, 1683 . 1685 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1686 Signature Algorithm (EdDSA)", RFC 8032, 1687 DOI 10.17487/RFC8032, January 2017, 1688 . 1690 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1691 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1692 May 2017, . 1694 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 1695 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 1696 . 1698 [SECG] "Elliptic Curve Cryptography, Standards for Efficient 1699 Cryptography Group, ver. 2", 2009, 1700 . 1702 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1703 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1704 . 1706 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 1707 Specification of Basic Encoding Rules (BER), Canonical 1708 Encoding Rules (CER) and Distinguished Encoding Rules 1709 (DER)", ISO/IEC 8824-1:2021 , February 2021. 1711 12.2. Informative References 1713 [BASIC-ISSUANCE] 1714 Celi, S., Davidson, A., Faz-Hernandez, A., Valdez, S., and 1715 C. A. Wood, "Privacy Pass Issuance Protocol", Work in 1716 Progress, Internet-Draft, draft-ietf-privacypass-protocol- 1717 04, 5 April 2022, . 1720 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1721 "Randomness Requirements for Security", BCP 106, RFC 4086, 1722 DOI 10.17487/RFC4086, June 2005, 1723 . 1725 Appendix A. Acknowledgements 1727 The authors of this document would like to acknowledge feedback from 1728 contributors to the Privacy Pass working group for their help in 1729 improving this document. The authors also thank Frank Denis and 1730 David Schinazi for their contributions. 1732 Appendix B. Test Vectors 1734 This section includes test vectors for Origin Name encryption in 1735 Section 6 and Anonymous Origin ID computation in Section 7. Test 1736 vectors for the token request and response protocol can be found in 1737 [ISSUANCE]. 1739 B.1. Origin Name Encryption Test Vector 1741 The test vector below for the procedure in Section 6 lists the 1742 following values: 1744 * origin_name: The Origin Name to encrypt, represented as a 1745 hexadecimal string. 1747 * kem_id, kdf_id, aead_id: The HPKE algorithms comprising the 1748 ciphersuite DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM. 1750 * issuer_encap_key_seed: The seed used to derive the private key 1751 corresponding to Issuer Encapsulation Key via the DeriveKeyPair 1752 function as defined in Section 7.1.3. of [HPKE], represented as a 1753 hexadecimal string. 1755 * issuer_encap_key: The public Issuer Encapsulation Key, represented 1756 as a hexadecimal string. 1758 * token_type: The type of the protocol specified in this document. 1760 * token_key_id: The ID of Token Key computed as in Section 5.3, a 1761 single octet. 1763 * blinded_msg: A random blinded_msg value, represented as a 1764 hexadecimal string. 1766 * request_key: A random request_key value, represented as a 1767 hexadecimal string. 1769 * issuer_encap_key_id: The Issuer Encapsulation Key ID computed as 1770 in Section 5.3, represented as a hexadecimal string. 1772 * encrypted_token_request: The encrypted InnerTokenRequest, 1773 represented as a hexadecimal string. 1775 origin_name: 746573742e6578616d706c65 1776 kem_id: 32 1777 kdf_id: 1 1778 aead_id: 1 1779 issuer_encap_key_seed: 1780 d2653816496f400baec656f213f1345092f4406af4f2a63e164956c4c3d240ca 1781 issuer_encap_key: 010020d7b6a2c10e75c4239feb9897e8d23f3f3c377d78e7903611 1782 53167736a24a9c5400010001 1783 token_type: 3 1784 token_key_id: 125 1785 blinded_msg: 89da551a48270b053e53c9eb741badf89e43cb7e66366bb936e11fb2aa0 1786 d30866986a790378bb9fc6a7cf5c32b7b7584d448ffa4ced3be650e354b3136428a52ec0 1787 b27c4103c5855c2b9b4f521ad0713c800d7e6925b6c62e1a6f58b31d13335f468cf509b7 1788 46a16e79b23862d277d0880706c3fb84b127d94faf8d6d2f3e124e681994441b19be084e 1789 c5c159bcd0abab433bbc308d90ea2cabdf4216e1b07155be66a048d686e383ca1e517ab8 1790 0025bb4849d98beb8c3d05d045c1167cb74f4451d8f85695babb604418385464f21f9a81 1791 5fb850ed83fd16a966130427e5637816501f7a79c0010e06adeba55781ceb50f56eae152 1792 ebd06f3cef80dc7ab121d 1793 request_key: 0161d905e4e37f515cb61f863b60e5896aa9e4a17dbe238e752a144c64a 1794 5412e244f0b1f75e010831e185cac023d33cb20 1795 issuer_encap_key_id: 1796 dd2c6de3091f1873643233d229a7a0e9defe0f9fe43f6a7c42ae3a6b16f77837 1797 encrypted_token_request: 82ef7c068506bcabc27d068a51c7ead2cbaf600b76a15e4 1798 d9df99a0da676da5a073fcc8f5ac77b25064d7379037b4e1b186977cface31eceb611978 1799 c73c9aef38c9a0e8ae846881624fa6d454523a0a91d22b02b022891d0469deebd66a912a 1800 a1ab3391b203e92e0a681f0a10c2a2d59b668daf1e5219ed16227d707fa0e8e29188bd58 1801 7ab38b3584564ce9b6538ba82e301cfed4231a2fa4f64a67285a1b9bf648e25f3eb1644c 1802 88d43552bdea6e4bfcbaef0de3ac245e0432be6b019494927fde0743b775f9efe8ca5fef 1803 afbf2048890d54618d408a6001fc8fb276f6828c46f4fe1381e9775eec72ee47593df738 1804 95d18952440d33756d78caea4bd8218950d35afa6c46c535211eda39da277260cb8dab7c 1805 00c6840a745e8150a6ee4893e72b6a51382f877f8c05a15e891a2bde07049760f0f09879 1806 78d78b97e47ecaf90a44996d724dd3720e308abbbf04f672bc5a4db573291986be191b06 1807 03ff521accb6fa081c151c758f3092a89fc6ef591934ff4bc860896c57f83a31b237dd1b 1808 803516c 1810 B.2. Anonymous Origin ID Test Vector 1812 The test vector below for the procedure in Section 7 lists the 1813 following values: 1815 * sk_client: Client Secret, serialized and represented as a 1816 hexadecimal string. 1818 * pk_client: Client Key, serialized and represented as a hexadecimal 1819 string. 1821 * sk_origin: Origin Secret, serialized and represented as a 1822 hexadecimal string. 1824 * request_blind: The request_blind value computed in Section 7.1.1, 1825 represented as a hexadecimal string. 1827 * index_key: The index_key value computed in Section 7.3, 1828 represented as a hexadecimal string. 1830 * anon_issuer_origin_id: The anon_issuer_origin_id value computed in 1831 Section 7.4, represented as a hexadecimal string. 1833 sk_sign: f6e6a0c9de38663ca539ff2e6a04e4fca11dc569794dc405e2d17439d6ce4f6 1834 7abb2b81a1852e0db993b6a0452eb60d6 1835 pk_sign: 032db7483c710673e6999a5fb2a2c6eac1d891f89bbf58d985ff168d182ad51 1836 605c4369280efabb7692f661162e683f03c 1837 sk_origin: 85de5fbbd787da5093da0adb240eba0cc6ea90d72032fc4b6925dd7d0ab1d 1838 a1e5ae0be27fe9f59e9ec7e1f1b15b28696 1839 request_blind: 0698a149fb9d16bcb0a856062f74f9191e82b35e91224a57abce60f5b 1840 79f03a669c6b5e093d57e647865f9fd4305b5a9 1841 request_key: 0287b0ce6b957111263d8c6126af96d400bd5a9d0b0f62ade15ab789446 1842 06c209470ced7086d3c418dd32bf9245fd42678 1843 index_key: 03188bec3dc02d2382b5251b6b4fd729d0472bbddf008c5e93b7c12270d9f 1844 57dde111c861c13be53822a1cebb604946066 1845 anon_issuer_origin_id: 9b0f980e5c1142fddb4401e5cd2107a87d22b73753b0d5dc9 1846 3f9a8f5ed2ee7db78163c6a93cc41ae8158d562381c51ee 1848 Authors' Addresses 1850 Scott Hendrickson 1851 Google LLC 1852 Email: scott@shendrickson.com 1854 Jana Iyengar 1855 Fastly 1856 Email: jri@fastly.com 1858 Tommy Pauly 1859 Apple Inc. 1860 One Apple Park Way 1861 Cupertino, California 95014, 1862 United States of America 1863 Email: tpauly@apple.com 1864 Steven Valdez 1865 Google LLC 1866 Email: svaldez@chromium.org 1868 Christopher A. Wood 1869 Cloudflare 1870 Email: caw@heapingbits.net