diff options
Diffstat (limited to 'doc/rfc/rfc9578.txt')
| -rw-r--r-- | doc/rfc/rfc9578.txt | 1903 |
1 files changed, 1903 insertions, 0 deletions
diff --git a/doc/rfc/rfc9578.txt b/doc/rfc/rfc9578.txt new file mode 100644 index 0000000..9879c6b --- /dev/null +++ b/doc/rfc/rfc9578.txt @@ -0,0 +1,1903 @@ + + + + +Internet Engineering Task Force (IETF) S. Celi +Request for Comments: 9578 Brave Software +Category: Standards Track A. Davidson +ISSN: 2070-1721 NOVA LINCS, Universidade NOVA de Lisboa + S. Valdez + Google LLC + C. A. Wood + Cloudflare + June 2024 + + + Privacy Pass Issuance Protocols + +Abstract + + This document specifies two variants of the two-message issuance + protocol for Privacy Pass tokens: one that produces tokens that are + privately verifiable using the Issuer Private Key and one that + produces tokens that are publicly verifiable using the Issuer Public + Key. Instances of "issuance protocol" and "issuance protocols" in + the text of this document are used interchangeably to refer to the + two variants of the Privacy Pass issuance protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9578. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Protocol Overview + 4. Configuration + 5. Issuance Protocol for Privately Verifiable Tokens + 5.1. Client-to-Issuer Request + 5.2. Issuer-to-Client Response + 5.3. Finalization + 5.4. Token Verification + 5.5. Issuer Configuration + 6. Issuance Protocol for Publicly Verifiable Tokens + 6.1. Client-to-Issuer Request + 6.2. Issuer-to-Client Response + 6.3. Finalization + 6.4. Token Verification + 6.5. Issuer Configuration + 7. Security Considerations + 8. IANA Considerations + 8.1. Well-Known "private-token-issuer-directory" URI + 8.2. Privacy Pass Token Types + 8.2.1. Token Type VOPRF(P-384, SHA-384) + 8.2.2. Token Type Blind RSA (2048-bit) + 8.3. Media Types + 8.3.1. "application/private-token-issuer-directory" Media Type + 8.3.2. "application/private-token-request" Media Type + 8.3.3. "application/private-token-response" Media Type + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. Test Vectors + A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) + A.2. Issuance Protocol 2 - Blind RSA (2048-bit) + Acknowledgements + Authors' Addresses + +1. Introduction + + The Privacy Pass protocol provides a privacy-preserving authorization + mechanism. In essence, the protocol allows Clients to provide + cryptographic tokens that prove nothing other than that they have + been created by a given server in the past [ARCHITECTURE]. + + This document describes two issuance protocols for Privacy Pass, each + of which is built on [HTTP]. It specifies two variants: one that is + privately verifiable using the Issuer Private Key based on the + Oblivious Pseudorandom Function (OPRF) as defined in [OPRF] and one + that is publicly verifiable using the Issuer Public Key based on the + blind RSA signature scheme [BLINDRSA]. Instances of "issuance + protocol" and "issuance protocols" in the text of this document are + used interchangeably to refer to the two variants of the Privacy Pass + issuance protocol. + + This document does not cover the Privacy Pass architecture, which + includes (1) choices that are necessary for deployment and (2) + application-specific choices for protecting Client privacy. This + information is covered in [ARCHITECTURE]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses the terms "Origin", "Client", "Issuer", and + "Token" as defined in Section 2 of [ARCHITECTURE]. Moreover, the + following additional terms are used throughout this document. + + Issuer Public Key: The public key (from a private-public key pair) + used by the Issuer for issuing and verifying tokens. + + Issuer Private Key: The private key (from a private-public key pair) + used by the Issuer for issuing and verifying tokens. + + Unless otherwise specified, this document encodes protocol messages + in TLS notation ([TLS13], Section 3). Moreover, all constants are in + network byte order. + +3. Protocol Overview + + The issuance protocols defined in this document embody the core of + Privacy Pass. Clients receive TokenChallenge inputs from the + redemption protocol ([AUTHSCHEME], Section 2.1) and use the issuance + protocols to produce corresponding token values ([AUTHSCHEME], + Section 2.2). The issuance protocol describes how Clients and + Issuers interact to compute a token using a one-round protocol + consisting of a TokenRequest from the Client and a TokenResponse from + the Issuer. This interaction is shown below. + + +--------+ +--------+ +----------+ +--------+ + | Origin | | Client | | Attester | | Issuer | + +---+----+ +---+----+ +----+-----+ +---+----+ + | | | | + |<----- Request ------+ | | + +-- TokenChallenge -->| | | + | |<== Attestation ==>| | + | | | | + | +--------- TokenRequest ------->| + | |<-------- TokenResponse -------+ + |<-- Request+Token ---+ | | + | | | | + + Figure 1: Issuance Overview + + The TokenChallenge inputs to the issuance protocols described in this + document can be interactive or non-interactive and can be per Origin + or across Origins. + + The issuance protocols defined in this document are compatible with + any deployment model defined in Section 4 of [ARCHITECTURE]. The + details of attestation are outside the scope of the issuance + protocol; see Section 4 of [ARCHITECTURE] for information about how + attestation can be implemented in each of the relevant deployment + models. + + This document describes two variants of the issuance protocol: one + that is privately verifiable (Section 5) using the Issuer Private Key + based on the OPRF [OPRF] and one that is publicly verifiable + (Section 6) using the Issuer Public Key based on the blind RSA + signature scheme [BLINDRSA]. + +4. Configuration + + Issuers MUST provide two parameters for configuration: + + Issuer Request URL: A token request URL for generating access + tokens. For example, an Issuer Request URL might be + <https://issuer.example.net/request>. + + Issuer Public Key values: A list of Issuer Public Keys for the + issuance protocol. + + The Issuer parameters can be obtained from an Issuer via a directory + object, which is a JSON object ([RFC8259], Section 4) whose values + are other JSON values ([RFC8259], Section 3) for the parameters. The + contents of this JSON object are defined in Table 1. + + +====================+======================================+ + | Field Name | Value | + +====================+======================================+ + | issuer-request-uri | Issuer Request URL value (as an | + | | absolute URL or as a URL relative to | + | | the directory object) as a percent- | + | | encoded URL string, represented as a | + | | JSON string ([RFC8259], Section 7) | + +--------------------+--------------------------------------+ + | token-keys | List of Issuer Public Key values, | + | | each represented as JSON objects | + | | ([RFC8259], Section 4) | + +--------------------+--------------------------------------+ + + Table 1: Issuer Directory Object Description + + Each "token-keys" JSON object contains the fields and corresponding + raw values defined in Table 2. + + +============+=====================================================+ + | Field Name | Value | + +============+=====================================================+ + | token-type | Integer value of the token type, as defined in | + | | Section 8.2, represented as a JSON number | + | | ([RFC8259], Section 6) | + +------------+-----------------------------------------------------+ + | token-key | The base64url public key, encoded per [RFC4648], | + | | for use with the issuance protocol as determined by | + | | the token-type field, including padding, | + | | represented as a JSON string ([RFC8259], Section 7) | + +------------+-----------------------------------------------------+ + + Table 2: Issuer "token-keys" Object Description + + Each "token-keys" JSON object may also contain the optional field + "not-before". The value of this field is the UNIX timestamp (number + of seconds since January 1, 1970, UTC -- see Section 4.2.1 of + [TIMESTAMP]) at which the key can be used. If this field is present, + Clients SHOULD NOT use a token key before this timestamp, as doing so + can lead to issuance failures. The purpose of this field is to + assist in scheduled key rotations. + + Beyond staging keys with the "not-before" value, Issuers MAY + advertise multiple "token-keys" for the same token-type to facilitate + key rotation. In this case, Issuers indicate their preference for + which token key to use based on the order of keys in the list, with + preference given to keys earlier in the list. Clients SHOULD use the + first key in the "token-keys" list that either does not have a "not- + before" value or has a "not-before" value in the past, since the + first such key is the most likely to be valid in the given time + window. Origins can attempt to use any key in the "token-keys" list + to verify tokens, starting with the most preferred key in the list. + Trial verifications like this can help deal with Client clock skew. + + Altogether, the Issuer's directory could look like the following + (with the "token-key" fields abbreviated): + + { + "issuer-request-uri": "https://issuer.example.net/request", + "token-keys": [ + { + "token-type": 2, + "token-key": "MI...AB", + "not-before": 1686913811, + }, + { + "token-type": 2, + "token-key": "MI...AQ", + } + ] + } + + Clients that use this directory resource before 1686913811 in UNIX + time would use the second key in the "token-keys" list, whereas + Clients that use this directory after 1686913811 in UNIX time would + use the first key in the "token-keys" list. + + A complete "token-key" value, encoded as it would be in the Issuer + directory, would look like the following (line breaks are inserted to + fit within the per-line character limits): + +$ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQE \ + BCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr \ + _DhZAPhJM7Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTv \ + W6SKCh7ZPXEqCGRsq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWb \ + jf21iaVjXJ2VdwdS-8O-430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuI \ + D9OQm1nxfs1Z4PhWBzt93T2ozTnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99 \ + aA-muXRFN4ZUwORrF7cAcCUD_-56_6fh9s34FmqBGwIDAQAB \ + | sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \ + | openssl asn1parse -dump -inform DER + 0:d=0 hl=4 l= 338 cons: SEQUENCE + 4:d=1 hl=2 l= 61 cons: SEQUENCE + 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss + 17:d=2 hl=2 l= 48 cons: SEQUENCE + 19:d=3 hl=2 l= 13 cons: cont [ 0 ] + 21:d=4 hl=2 l= 11 cons: SEQUENCE + 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 + 34:d=3 hl=2 l= 26 cons: cont [ 1 ] + 36:d=4 hl=2 l= 24 cons: SEQUENCE + 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 + 49:d=5 hl=2 l= 11 cons: SEQUENCE + 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 + 62:d=3 hl=2 l= 3 cons: cont [ 2 ] + 64:d=4 hl=2 l= 1 prim: INTEGER :30 + 67:d=1 hl=4 l= 271 prim: BIT STRING + ... truncated public key bytes ... + + Issuer directory resources have the media type "application/private- + token-issuer-directory" and are located at the well-known location + /.well-known/private-token-issuer-directory; see Section 8.1 for the + registration information for this well-known URI. This resource is + located at a well-known URI because Issuers are defined by an Origin + name in TokenChallenge structures; see Section 2.1 of [AUTHSCHEME]. + + The Issuer directory and Issuer resources SHOULD be available on the + same Origin. If an Issuer wants to service multiple different Issuer + directories, they MUST create unique subdomains for each directory so + the TokenChallenge defined in Section 2.1 of [AUTHSCHEME] can be + differentiated correctly. + + Issuers SHOULD use HTTP cache directives to permit caching of this + resource [RFC5861]. The cache lifetime depends on the Issuer's key + rotation schedule. Regular rotation of token keys is recommended to + minimize the risk of key compromise and any harmful effects that + happen due to key compromise. + + Issuers can control the cache lifetime with the Cache-Control header, + as follows: + + Cache-Control: max-age=86400 + + Consumers of the Issuer directory resource SHOULD follow the usual + HTTP caching semantics [RFC9111] when processing this resource. Long + cache lifetimes may result in the use of stale Issuer configuration + information, whereas short lifetimes may result in decreased + performance. When the use of an Issuer configuration results in + token issuance failures, e.g., because the Issuer has invalidated its + directory resource before its expiration time and issuance requests + using this configuration are unsuccessful, the directory SHOULD be + fetched and revalidated. Issuance will continue to fail until the + Issuer configuration is updated. + +5. Issuance Protocol for Privately Verifiable Tokens + + The privately verifiable issuance protocol allows Clients to produce + token values that verify using the Issuer Private Key. This protocol + is based on the OPRF [OPRF]. + + Issuers provide an Issuer Private Key and Public Key, denoted skI and + pkI, respectively, used to produce tokens as input to the protocol. + See Section 5.5 for information about how these keys are generated. + + Clients provide the following as input to the issuance protocol: + + Issuer Request URL: A URL identifying the location to which issuance + requests are sent. This can be a URL derived from the "issuer- + request-uri" value in the Issuer's directory resource, or it can + be another Client-configured URL. The value of this parameter + depends on the Client configuration and deployment model. For + example, in the "Joint Origin and Issuer" deployment model + ([ARCHITECTURE], Section 4.3), the Issuer Request URL might + correspond to the Client's configured Attester, and the Attester + is configured to relay requests to the Issuer. + + Issuer name: An identifier for the Issuer. This is typically a + hostname that can be used to construct HTTP requests to the + Issuer. + + Issuer Public Key: pkI, with a key identifier token_key_id computed + as described in Section 5.5. + + Challenge value: challenge -- an opaque byte string. For example, + this might be provided by the redemption protocol described in + [AUTHSCHEME]. + + Given this configuration and these inputs, the two messages exchanged + in this protocol are described below. This section uses notation + described in [OPRF], Section 4, including SerializeElement and + DeserializeElement, SerializeScalar and DeserializeScalar, and + DeriveKeyPair. + + The constants Ne and Ns are as defined in Section 4.4 ("OPRF(P-384, + SHA-384)") of [OPRF]. For this protocol, the constant Nk, which is + also equal to Nh as defined in Section 4.4 of [OPRF], is defined by + Section 8.2.1. + +5.1. Client-to-Issuer Request + + The Client first creates a context as follows: + + client_context = SetupVOPRFClient("P384-SHA384", pkI) + + Here, "P384-SHA384" is the identifier corresponding to the + OPRF(P-384, SHA-384) ciphersuite defined in [OPRF]. SetupVOPRFClient + is defined in [OPRF], Section 3.2. + + The Client then creates an issuance request message for a random + 32-byte nonce with the input challenge and Issuer key identifier as + described below: + + nonce = random(32) + challenge_digest = SHA256(challenge) + token_input = concat(0x0001, // token-type field is 2 bytes long + nonce, + challenge_digest, + token_key_id) + blind, blinded_element = client_context.Blind(token_input) + + The Blind function is discussed in Sections 3.3.1 and 3.3.2 of + [OPRF]. If the Blind function fails, the Client aborts the protocol. + The Client stores the nonce and challenge_digest values locally for + use when finalizing the issuance protocol to produce a token (as + described in Section 5.3). + + The Client then creates a TokenRequest structured as follows: + + struct { + uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ + uint8_t truncated_token_key_id; + uint8_t blinded_msg[Ne]; + } TokenRequest; + + The structure fields are defined as follows: + + * "token_type" is a 2-octet integer, which matches the type in the + challenge. + + * "truncated_token_key_id" is the least significant byte of the + token_key_id (Section 5.5) in network byte order (in other words, + the last 8 bits of token_key_id). This value is truncated so that + Issuers cannot use token_key_id as a way of uniquely identifying + Clients; see referenced information from Section 7 for more + details. + + * "blinded_msg" is the Ne-octet blinded message defined above, + computed as SerializeElement(blinded_element). + + The values token_input and blinded_element are stored locally for use + when finalizing the issuance protocol to produce a token (as + described in Section 5.3). The Client then generates an HTTP POST + request to send to the Issuer Request URL, with the TokenRequest as + the content. The media type for this request is "application/ + private-token-request". An example request for the Issuer Request + URL "https://issuer.example.net/request" is shown below. + + POST /request HTTP/1.1 + Host: issuer.example.net + Accept: application/private-token-response + Content-Type: application/private-token-request + Content-Length: <Length of TokenRequest> + + <Bytes containing the TokenRequest> + +5.2. Issuer-to-Client Response + + Upon receipt of the request, the Issuer validates the following + conditions: + + * The TokenRequest contains a supported token_type. + + * The TokenRequest.truncated_token_key_id corresponds to the + truncated key ID of a public key owned by the Issuer. + + * The TokenRequest.blinded_msg is of the correct size. + + If any of these conditions are not met, the Issuer MUST return an + HTTP 422 (Unprocessable Content) error to the Client. + + If these conditions are met, the Issuer then tries to deserialize + TokenRequest.blinded_msg using DeserializeElement ([OPRF], + Section 2.1), yielding blinded_element. If this fails, the Issuer + MUST return an HTTP 422 (Unprocessable Content) error to the Client. + Otherwise, if the Issuer is willing to produce a token to the Client, + the Issuer completes the issuance flow by computing a blinded + response as follows: + + server_context = SetupVOPRFServer("P384-SHA384", skI) + evaluate_element, proof = + server_context.BlindEvaluate(skI, pkI, blinded_element) + + SetupVOPRFServer is defined in [OPRF], Section 3.2, and BlindEvaluate + is defined in [OPRF], Section 3.3.2. The Issuer then creates a + TokenResponse structured as follows: + + struct { + uint8_t evaluate_msg[Ne]; + uint8_t evaluate_proof[Ns+Ns]; + } TokenResponse; + + The structure fields are defined as follows: + + * "evaluate_msg" is the Ne-octet evaluated message, computed as + SerializeElement(evaluate_element). + + * "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a + pair of Scalar values, computed as + concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])). + + The Issuer generates an HTTP response with status code 200 whose + content consists of TokenResponse, with the content type set as + "application/private-token-response". + + HTTP/1.1 200 OK + Content-Type: application/private-token-response + Content-Length: <Length of TokenResponse> + + <Bytes containing the TokenResponse> + +5.3. Finalization + + Upon receipt, the Client handles the response and, if successful, + deserializes the content values TokenResponse.evaluate_msg and + TokenResponse.evaluate_proof, yielding evaluated_element and proof. + If deserialization of either value fails, the Client aborts the + protocol. Otherwise, the Client processes the response as follows: + + authenticator = client_context.Finalize(token_input, blind, + evaluated_element, + blinded_element, + proof) + + The Finalize function is defined in [OPRF], Section 3.3.2. If this + succeeds, the Client then constructs a token as follows: + + struct { + uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ + uint8_t nonce[32]; + uint8_t challenge_digest[32]; + uint8_t token_key_id[32]; + uint8_t authenticator[Nk]; + } Token; + + The Token.nonce value is the value that was created according to + Section 5.4. If the Finalize function fails, the Client aborts the + protocol. + +5.4. Token Verification + + Verifying a token requires creating a Verifiable Oblivious + Pseudorandom Function (VOPRF) context using the Issuer Private Key + and Public Key, evaluating the token contents, and comparing the + result against the token authenticator value: + + server_context = SetupVOPRFServer("P384-SHA384", skI) + token_authenticator_input = + concat(Token.token_type, + Token.nonce, + Token.challenge_digest, + Token.token_key_id) + token_authenticator = + server_context.Evaluate(token_authenticator_input) + valid = (token_authenticator == Token.authenticator) + +5.5. Issuer Configuration + + Issuers are configured with Issuer Private Keys and Public Keys, each + denoted skI and pkI, respectively, used to produce tokens. These + keys MUST NOT be reused in other protocols. A RECOMMENDED method for + generating keys is as follows: + + seed = random(Ns) + (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") + + The DeriveKeyPair function is defined in [OPRF], Section 3.2.1. The + key identifier for a public key pkI, denoted token_key_id, is + computed as follows: + + token_key_id = SHA256(SerializeElement(pkI)) + + Since Clients truncate token_key_id in each TokenRequest, Issuers + SHOULD ensure that the truncated forms of new key IDs do not collide + with other truncated key IDs in rotation. Collisions can cause the + Issuer to use the wrong Issuer Private Key for issuance, which will + in turn cause the resulting tokens to be invalid. There is no known + security consequence of using the wrong Issuer Private Key. A + possible exception to this constraint would be a colliding key that + is still in use but is in the process of being rotated out, in which + case the collision cannot reasonably be avoided; however, this + situation is expected to be transient. + +6. Issuance Protocol for Publicly Verifiable Tokens + + This section describes a variant of the issuance protocol discussed + in Section 5 for producing publicly verifiable tokens using the + protocol defined in [BLINDRSA]. In particular, this variant of the + issuance protocol works for the RSABSSA-SHA384-PSS-Deterministic and + RSABSSA-SHA384-PSSZERO-Deterministic blind RSA protocol variants + described in Section 5 of [BLINDRSA]. + + The publicly verifiable issuance protocol differs from the protocol + defined in Section 5 in that the output tokens are publicly + verifiable by anyone with the Issuer Public Key. This means any + Origin can select a given Issuer to produce tokens, as long as the + Origin has the Issuer Public Key, without explicit coordination or + permission from the Issuer. This is because the Issuer does not + learn the Origin that requested the token during the issuance + protocol. + + Beyond this difference, the publicly verifiable issuance protocol + variant is nearly identical to the privately verifiable issuance + protocol variant. In particular, Issuers provide an Issuer Private + Key and Public Key, denoted skI and pkI, respectively, used to + produce tokens as input to the protocol. See Section 6.5 for + information about how these keys are generated. + + Clients provide the following as input to the issuance protocol: + + Issuer Request URL: A URL identifying the location to which issuance + requests are sent. This can be a URL derived from the "issuer- + request-uri" value in the Issuer's directory resource, or it can + be another Client-configured URL. The value of this parameter + depends on the Client configuration and deployment model. For + example, in the "Split Origin, Attester, Issuer" deployment model + ([ARCHITECTURE], Section 4.4), the Issuer Request URL might + correspond to the Client's configured Attester, and the Attester + is configured to relay requests to the Issuer. + + Issuer name: An identifier for the Issuer. This is typically a + hostname that can be used to construct HTTP requests to the + Issuer. + + Issuer Public Key: pkI, with a key identifier token_key_id computed + as described in Section 6.5. + + Challenge value: challenge -- an opaque byte string. For example, + this might be provided by the redemption protocol described in + [AUTHSCHEME]. + + Given this configuration and these inputs, the two messages exchanged + in this protocol are described below. For this protocol, the + constant Nk is defined by Section 8.2.2. + +6.1. Client-to-Issuer Request + + The Client first creates an issuance request message for a random + 32-byte nonce using the input challenge and Issuer key identifier as + follows: + + nonce = random(32) + challenge_digest = SHA256(challenge) + token_input = concat(0x0002, // token-type field is 2 bytes long + nonce, + challenge_digest, + token_key_id) + blinded_msg, blind_inv = + Blind(pkI, PrepareIdentity(token_input)) + + The PrepareIdentity and Blind functions are defined in Sections 4.1 + and 4.2 of [BLINDRSA], respectively. The Client stores the nonce and + challenge_digest values locally for use when finalizing the issuance + protocol to produce a token (as described in Section 6.3). + + The Client then creates a TokenRequest structured as follows: + + struct { + uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ + uint8_t truncated_token_key_id; + uint8_t blinded_msg[Nk]; + } TokenRequest; + + The structure fields are defined as follows: + + * "token_type" is a 2-octet integer, which matches the type in the + challenge. + + * "truncated_token_key_id" is the least significant byte of the + token_key_id (Section 6.5) in network byte order (in other words, + the last 8 bits of token_key_id). This value is truncated so that + Issuers cannot use token_key_id as a way of uniquely identifying + Clients; see referenced information from Section 7 for more + details. + + * "blinded_msg" is the Nk-octet request defined above. + + The Client then generates an HTTP POST request to send to the Issuer + Request URL, with the TokenRequest as the content. The media type + for this request is "application/private-token-request". An example + request for the Issuer Request URL "https://issuer.example.net/ + request" is shown below. + + POST /request HTTP/1.1 + Host: issuer.example.net + Accept: application/private-token-response + Content-Type: application/private-token-request + Content-Length: <Length of TokenRequest> + + <Bytes containing the TokenRequest> + +6.2. Issuer-to-Client Response + + Upon receipt of the request, the Issuer validates the following + conditions: + + * The TokenRequest contains a supported token_type. + + * The TokenRequest.truncated_token_key_id corresponds to the + truncated key ID of an Issuer Public Key. + + * The TokenRequest.blinded_msg is of the correct size. + + If any of these conditions are not met, the Issuer MUST return an + HTTP 422 (Unprocessable Content) error to the Client. Otherwise, if + the Issuer is willing to produce a token to the Client, the Issuer + completes the issuance flow by computing a blinded response as + follows: + + blind_sig = BlindSign(skI, TokenRequest.blinded_msg) + + The BlindSign function is defined in Section 4.3 of [BLINDRSA]. The + result is encoded and transmitted to the Client in the following + TokenResponse structure: + + struct { + uint8_t blind_sig[Nk]; + } TokenResponse; + + The Issuer generates an HTTP response with status code 200 whose + content consists of TokenResponse, with the content type set as + "application/private-token-response". + + HTTP/1.1 200 OK + Content-Type: application/private-token-response + Content-Length: <Length of TokenResponse> + + <Bytes containing the TokenResponse> + +6.3. Finalization + + Upon receipt, the Client handles the response and, if successful, + processes the content as follows: + + authenticator = + Finalize(pkI, PrepareIdentity(token_input), blind_sig, blind_inv) + + The Finalize function is defined in Section 4.4 of [BLINDRSA]. If + this succeeds, the Client then constructs a token as described in + [AUTHSCHEME] as follows: + + struct { + uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ + uint8_t nonce[32]; + uint8_t challenge_digest[32]; + uint8_t token_key_id[32]; + uint8_t authenticator[Nk]; + } Token; + + The Token.nonce value is the value that was sampled according to + Section 6.1. If the Finalize function fails, the Client aborts the + protocol. + +6.4. Token Verification + + Verifying a token requires checking that Token.authenticator is a + valid signature over the remainder of the token input using the + Issuer Public Key. The function RSASSA-PSS-VERIFY is defined in + Section 8.1.2 of [RFC8017], using SHA-384 as the hash function, MGF1 + with SHA-384 as the Probabilistic Signature Scheme (PSS) mask + generation function (MGF), and a 48-byte salt length (sLen). + + token_authenticator_input = + concat(Token.token_type, + Token.nonce, + Token.challenge_digest, + Token.token_key_id) + valid = RSASSA-PSS-VERIFY(pkI, + token_authenticator_input, + Token.authenticator) + +6.5. Issuer Configuration + + Issuers are configured with Issuer Private Keys and Public Keys, each + denoted skI and pkI, respectively, used to produce tokens. Each key + SHALL be generated securely -- for example, as specified in FIPS + 186-5 [DSS]. These keys MUST NOT be reused in other protocols. + + The key identifier for an Issuer Private Key and Public Key (skI, + pkI), denoted token_key_id, is computed as SHA256(encoded_key), where + encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object + [RFC5280] carrying pkI as a DER-encoded RSAPublicKey value [RFC5756] + in the subjectPublicKey field. Additionally, (1) the SPKI object + MUST use the id-RSASSA-PSS object identifier in the algorithm field + within the SPKI object and (2) the parameters field MUST contain an + RSASSA-PSS-params value and MUST include the hashAlgorithm, + maskGenAlgorithm, and saltLength values. The saltLength MUST match + the output size of the hash function associated with the public key + and token type. + + An example sequence of the SPKI object (in ASN.1 format, with the + actual public key bytes truncated) for a 2048-bit key is shown below: + + $ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER + 0:d=0 hl=4 l= 338 cons: SEQUENCE + 4:d=1 hl=2 l= 61 cons: SEQUENCE + 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss + 17:d=2 hl=2 l= 48 cons: SEQUENCE + 19:d=3 hl=2 l= 13 cons: cont [ 0 ] + 21:d=4 hl=2 l= 11 cons: SEQUENCE + 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 + 34:d=3 hl=2 l= 26 cons: cont [ 1 ] + 36:d=4 hl=2 l= 24 cons: SEQUENCE + 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 + 49:d=5 hl=2 l= 11 cons: SEQUENCE + 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 + 62:d=3 hl=2 l= 3 cons: cont [ 2 ] + 64:d=4 hl=2 l= 1 prim: INTEGER :30 + 67:d=1 hl=4 l= 271 prim: BIT STRING + ... truncated public key bytes ... + + Since Clients truncate token_key_id in each TokenRequest, Issuers + SHOULD ensure that the truncated forms of new key IDs do not collide + with other truncated key IDs in rotation. Collisions can cause the + Issuer to use the wrong Issuer Private Key for issuance, which will + in turn cause the resulting tokens to be invalid. There is no known + security consequence of using the wrong Issuer Private Key. A + possible exception to this constraint would be a colliding key that + is still in use but is in the process of being rotated out, in which + case the collision cannot reasonably be avoided; however, this + situation is expected to be transient. + +7. Security Considerations + + This document outlines how to instantiate the issuance protocol based + on the VOPRF defined in [OPRF] and the blind RSA protocol defined in + [BLINDRSA]. All security considerations described in the VOPRF and + blind RSA documents also apply in the Privacy Pass use case. + Considerations related to broader privacy and security concerns in a + multi-Client and multi-Issuer setting are covered in the architecture + document [ARCHITECTURE]. In particular, Sections 4 and 5 of + [ARCHITECTURE] discuss relevant privacy considerations influenced by + the Privacy Pass deployment models, and Section 6 of [ARCHITECTURE] + discusses privacy considerations that apply regardless of deployment + model. Notable considerations include those pertaining to Issuer + Public Key rotation and consistency -- where consistency is as + described in [CONSISTENCY] -- and Issuer selection. + +8. IANA Considerations + +8.1. Well-Known "private-token-issuer-directory" URI + + IANA has updated the "Well-Known URIs" registry [WellKnownURIs] with + the following values. + + +===============+============+===========+===========+=============+ + | URI Suffix | Change | Reference | Status | Related | + | | Controller | | | Information | + +===============+============+===========+===========+=============+ + | private- | IETF | RFC 9578 | permanent | None | + | token-issuer- | | | | | + | directory | | | | | + +---------------+------------+-----------+-----------+-------------+ + + Table 3: "private-token-issuer-directory" Well-Known URI + +8.2. Privacy Pass Token Types + + IANA has updated the "Privacy Pass Token Types" registry + [PrivPassTokenTypes] with the entries below. + +8.2.1. Token Type VOPRF(P-384, SHA-384) + + Value: 0x0001 + Name: VOPRF(P-384, SHA-384) + Token Structure: As defined in Section 2.2 of [AUTHSCHEME]. + Token Key Encoding: Serialized using SerializeElement (Section 2.1 + of [OPRF]). + TokenChallenge Structure: As defined in Section 2.1 of [AUTHSCHEME]. + Publicly Verifiable: N + Public Metadata: N + Private Metadata: N + Nk: 48 + Nid: 32 + Change controller: IETF + Reference: RFC 9578, Section 5 + Notes: None + +8.2.2. Token Type Blind RSA (2048-bit) + + Value: 0x0002 + Name: Blind RSA (2048-bit) + Token Structure: As defined in Section 2.2 of [AUTHSCHEME]. + Token Key Encoding: Serialized as a DER-encoded SubjectPublicKeyInfo + (SPKI) object using the RSASSA-PSS OID [RFC5756]. + TokenChallenge Structure: As defined in Section 2.1 of [AUTHSCHEME]. + Publicly Verifiable: Y + Public Metadata: N + Private Metadata: N + Nk: 256 + Nid: 32 + Change controller: IETF + Reference: RFC 9578, Section 6 + Notes: The RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384- + PSSZERO-Deterministic variants are supported. + +8.3. Media Types + + IANA has added the following entries to the "Media Types" registry + [MediaTypes]: + + * "application/private-token-issuer-directory" + + * "application/private-token-request" + + * "application/private-token-response" + + The templates for these entries are listed below. The reference is + this RFC. + +8.3.1. "application/private-token-issuer-directory" Media Type + + Type name: application + + Subtype name: private-token-issuer-directory + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: binary + + Security considerations: See Section 7 of RFC 9578. + + Interoperability considerations: N/A + + Published specification: RFC 9578 + + Applications that use this media type: Services that implement the + Privacy Pass Issuer role, and Client applications that interact + with the Issuer for the purposes of issuing or redeeming tokens. + + Fragment identifier considerations: N/A + + Additional information: + + Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): N/A + + Person & email address to contact for further information: See the + Authors' Addresses section of RFC 9578. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See the Authors' Addresses section of RFC 9578. + + Change controller: IETF + +8.3.2. "application/private-token-request" Media Type + + Type name: application + + Subtype name: private-token-request + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: binary + + Security considerations: See Section 7 of RFC 9578. + + Interoperability considerations: N/A + + Published specification: RFC 9578 + + Applications that use this media type: Applications that want to + issue or facilitate issuance of Privacy Pass tokens, including + Privacy Pass Issuer applications themselves. + + Fragment identifier considerations: N/A + + Additional information: + + Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): N/A + + Person & email address to contact for further information: See the + Authors' Addresses section of RFC 9578. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See the Authors' Addresses section of RFC 9578. + + Change controller: IETF + +8.3.3. "application/private-token-response" Media Type + + Type name: application + + Subtype name: private-token-response + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: binary + + Security considerations: See Section 7 of RFC 9578. + + Interoperability considerations: N/A + + Published specification: RFC 9578 + + Applications that use this media type: Applications that want to + issue or facilitate issuance of Privacy Pass tokens, including + Privacy Pass Issuer applications themselves. + + Fragment identifier considerations: N/A + + Additional information: + + Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): N/A + + Person & email address to contact for further information: See the + Authors' Addresses section of RFC 9578. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See the Authors' Addresses section of RFC 9578. + + Change controller: IETF + +9. References + +9.1. Normative References + + [ARCHITECTURE] + Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy + Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June + 2024, <https://www.rfc-editor.org/info/rfc9576>. + + [AUTHSCHEME] + Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass + HTTP Authentication Scheme", RFC 9577, + DOI 10.17487/RFC9577, June 2024, + <https://www.rfc-editor.org/info/rfc9577>. + + [BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind + Signatures", RFC 9474, DOI 10.17487/RFC9474, October 2023, + <https://www.rfc-editor.org/info/rfc9474>. + + [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + <https://www.rfc-editor.org/info/rfc9110>. + + [MediaTypes] + IANA, "Media Types", + <https://www.iana.org/assignments/media-types/>. + + [OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. + Wood, "Oblivious Pseudorandom Functions (OPRFs) Using + Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497, + December 2023, <https://www.rfc-editor.org/info/rfc9497>. + + [PrivPassTokenTypes] + IANA, "Privacy Pass Token Types", + <https://www.iana.org/assignments/privacy-pass/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + <https://www.rfc-editor.org/info/rfc4648>. + + [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Updates for RSAES-OAEP and RSASSA-PSS Algorithm + Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, + <https://www.rfc-editor.org/info/rfc5756>. + + [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale + Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, + <https://www.rfc-editor.org/info/rfc5861>. + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + <https://www.rfc-editor.org/info/rfc8017>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Caching", STD 98, RFC 9111, + DOI 10.17487/RFC9111, June 2022, + <https://www.rfc-editor.org/info/rfc9111>. + + [TIMESTAMP] + Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for + Defining Packet Timestamps", RFC 8877, + DOI 10.17487/RFC8877, September 2020, + <https://www.rfc-editor.org/info/rfc8877>. + + [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [WellKnownURIs] + IANA, "Well-Known URIs", + <https://www.iana.org/assignments/well-known-uris/>. + +9.2. Informative References + + [CONSISTENCY] + Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, + "Key Consistency and Discovery", Work in Progress, + Internet-Draft, draft-ietf-privacypass-key-consistency-01, + 10 July 2023, <https://datatracker.ietf.org/doc/html/ + draft-ietf-privacypass-key-consistency-01>. + + [DSS] National Institute of Standards and Technology, "Digital + Signature Standard (DSS)", NIST FIPS Publication 186-5, + DOI 10.6028/NIST.FIPS.186-5, February 2023, + <https://doi.org/10.6028/nist.fips.186-5>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + +Appendix A. Test Vectors + + This section includes test vectors for the two basic issuance + protocols specified in this document. Appendix A.1 contains test + vectors for token issuance protocol 1 (0x0001), and Appendix A.2 + contains test vectors for token issuance protocol 2 (0x0002). + +A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) + + The test vectors below list the following values: + + skI: The Issuer Private Key, serialized using SerializeScalar + ([OPRF], Section 2.1) and represented as a hexadecimal string. + + pkI: The Issuer Public Key, serialized according to the encoding in + Section 8.2.1. + + token_challenge: A randomly generated TokenChallenge structure, + represented as a hexadecimal string. + + nonce: The 32-byte Client nonce generated according to Section 5.1, + represented as a hexadecimal string. + + blind: The blind used when computing the OPRF blinded message, + serialized using SerializeScalar ([OPRF], Section 2.1) and + represented as a hexadecimal string. + + token_request: The TokenRequest message constructed according to + Section 5.1, represented as a hexadecimal string. + + token_response: The TokenResponse message constructed according to + Section 5.2, represented as a hexadecimal string. + + token: The output token from the protocol, represented as a + hexadecimal string. + + // Test vector 1 + skI: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181 + 14910bee3c919bed1bbffe3fc1b87d53240a + pkI: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c + 21da1a46d42ca38f7beabdf05c074aee1455bf + token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc + daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696 + 7696e2e6578616d706c65 + nonce: + 6aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05fafe73073b8 + blind: 8e7fd80970b8a00b0931b801a2e22d9903d83bd5597c6a4dc1496ed2b1 + 7ef820445ef3bd223f3ab2c4f54c5d1c956909 + token_request: 0001f4030ab3e23181d1e213f24315f5775983c678ce22eff9 + 427610832ab3900f2cd12d6829a07ec8a6813cf0b5b886f4cc4979 + token_response: 036bb3c5c397d88c3527cf9f08f1fe63687b867e85c930c49 + ee2c222408d4903722a19ff272ac97e3725b947c972784ebfe86eb9ea54336e43 + 34ea9660212c0c85fbadfbf491a1ce2446fc3379337fccd45c1059b2bc760110e + e1ec227d8e01c9f482c00c47ffa0dbe2fb58c32dde2b1dbe69fff920a528e68dd + 9b3c2483848e57c30542b8984fa6bfecd6d71d54d53eda + token: 00016aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05f + afe73073b8501370b494089dc462802af545e63809581ee6ef57890a12105c283 + 68169514bf260d0792bf7f46c9866a6d37c3032d8714415f87f5f6903d7fb071e + 253be2f4e0a835d76528b8444f73789ee7dc90715b01c17902fd87375c00a7a9d + 3d92540437f470773be20f71e721da3af40edeb + + // Test vector 2 + skI: 39efed331527cc4ddff9722ab5cd35aeafe7c27520b0cfa2eedbdc298dc3 + b12bc8298afcc46558af1e2eeacc5307d865 + pkI: 038017e005904c6146b37109d6c2a72b95a183aaa9ed951b8d8fb1ed9033 + f68033284d175e7df89849475cd67a86bfbf4e + token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269 + 67696e2e6578616d706c65 + nonce: + 7617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3190c29d665 + blind: 6492ee50072fa18d035d69c4246362dffe2621afb95a10c033bb0109e0 + f705b0437c425553272e0aa5266ec379e7015e + token_request: 000133033a5fe04a39da1bbfb68ccdeecd1917474dd525462e + 5a90a6ba53b42aaa1486fe443a2e1c7f3fd5ff028a1c7cf1aeac5d + token_response: 023bf8cd624880d669c5cc6c88b056355c6e8e1bcbf3746cf + b9ab9248a4c056f23a4876ef998a8b6b281d50f852c6fa868fc4fa135c79ccb5f + bdf8bf3c926e10c7c12f934a887d86da4a4e5be70f5a169aa75720887bb690536 + 92a8f11f9cda7a72f281e4e3568e848225367946c70db09e718e3cba16193987b + c10bede3ef54c4d036c17cd4015bb113be60d7aa927e0d + token: 00017617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3 + 190c29d665c994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1 + 34bd5a62a116477bc9e1a205cca95d0c92335ca7a3e71063b2ac020bdd231c660 + 97f12333ef438d00801bca5ace0fab8eb483dc04cd62578b95b5652921cd2698c + 45ea74f6c8827b4e19f01140fa5bd039866f562 + + // Test vector 3 + skI: 2b7709595b62b784f14946ae828f65e6caeba6eefe732c86e9ae50e818c0 + 55b3d7ca3a5f2beecaa859a62ff7199d35cc + pkI: 03a0de1bf3fd0a73384283b648884ba9fa5dee190f9d7ad4292c2fd49d8b + 4d64db674059df67f5bd7e626475c78934ae8d + token_challenge: 0001000e6973737565722e6578616d706c65000017666f6f + 2e6578616d706c652c6261722e6578616d706c65 + nonce: + 87499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c28aa7d3a9df + blind: 1f659584626ba15f44f3d887b2e5fe4c27315b185dfbfaea4253ebba30 + 610c4d9b73c78714c142360e85a00942c0fcff + token_request: 0001c8024610a9f3aac21090f3079d6809437a2b94b4403c7e + 645f849bc6c505dade154c258c8ecd4d2bdcf574daca65db671908 + token_response: 03c2ab925d03e7793b4a4df6eb505210139f620359e142449 + 1b8143c06a3e5298b25b662c33256411be7277233e1a34570f7a4d142d931e4b5 + ff8829e27aaf7eb2cc7f9ab655477d71c01d5da5aef44dd076b5820b4710ef025 + a9e6c6b50a95af6105c5987c1b834d615008cf6370556ed00c6671e69776c09a9 + 2b5ac84804750dd867c78817bdf69f1443002b18ae7a52 + token: 000187499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c2 + 8aa7d3a9df1949fd455872478ba87e2e6c513c3261cddbe57220581245e4c9c91 + 1dd1c0bb865785bff8f3cfe08cccbb3a7b8e41d23a172871be4828cc54582d87b + c7cfc5c8bcedc1868ebc845b000c317ed75312274a42b10be6db23bd8a168fd2f + 021c23925d72c4d14cd7588c03845da0d41a326 + + // Test vector 4 + skI: 22e237b7b983d77474e4495aff2fc1e10422b1d955192e0fbf2b7b618fba + 625fcb94b599da9113da49c495a48fbf7f7f + pkI: 028cd68715caa20d19b2b20d017d6a0a42b9f2b0a47db65e5e763e23744f + e14d74e374bbc93a2ec3970eb53c8aa765ee21 + token_challenge: 0001000e6973737565722e6578616d706c65000000 + nonce: + 02f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a89e820cd43 + blind: af91d1dbcf6b46baecde70eb305b8fe75629199cca19c7f9344b8607b9 + 0def27bc53e0345ade32c9fd0a1efda056d1c0 + token_request: 0001a503632ebb003ed15b6de4557c047c7f81a58688143331 + 2ad3ad7f9416f2dfc940d3f439ad1e8cd677d94ae7c05bc958d134 + token_response: 032018bc3f180d9650e27f72de76a90b47e336ae9cb058548 + d851c7046fa0875d96346c15cb39d8083cc6fb57216544c6a815c37d792769e12 + 9c0513ce2034c3286cb212548f4aed1b0f71b28e219a71874a93e53ab2f473282 + 71d1e9cbefc197a4f599a6825051fa1c6e55450042f04182b86c9cf12477a9f16 + 849396c051fa27012e81a86e6c4a9204a063f1e1722dd7 + token: 000102f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a + 89e820cd43085cb06952044c7655b412ab7d484c97b97c48c79c568140b8d49a0 + 2ca47a9cfb0a5cfb861290c4dbd8fd9b60ee9b1a1a54cf47c98531fe253f1ed6d + 875de5a58f42db12b540b0d11bc5d6b42e6d17c2b73e98631e54d40fd2901ebec + 4268668535b03cbf76f7f15a29d623a64cab0c4 + + // Test vector 5 + skI: 46f3d4f562002b85ffcfdb4d06835fb9b2e24372861ecaa11357fd1f29f9 + ed26e44715549ccedeb39257f095110f0159 + pkI: 02fbe9da0b7cabe3ec51c36c8487b10909142b59af030c728a5e87bb3b30 + f54c06415d22e03d9212bd3d9a17d5520d4d0f + token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc + daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b30000 + nonce: + 9ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e84483c90e89 + blind: 76e0938e824b6cda6c163ff55d0298d539e222ed3984f4e31bbb654a8c + 59671d4e0a7e264ca758cd0f4b533e0f60c5aa + token_request: 0001e10202bc92ac516c867f39399d71976018db52fcab5403 + f8534a65677ba9e1e7d9b1d01767d137884c86cf5fe698c2f5d8e9 + token_response: 0322ea3856a71533796393229b33d33c02cd714e40d5aa4e0 + 71f056276f32f89c09947eca8ff119d940d9d57c2fcbd83d2da494ddeb37dc1f6 + 78e5661a8e7bcc96b3477eb89d708b0ce10e0ea1b5ce0001f9332f743c0cc3d47 + 48233fea6d3152fae7844821268eb96ba491f60b1a3a848849310a39e9ef59121 + 669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080 + token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8 + 4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8 + 7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca + 1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c + d24504fe4f6c52d24ac901471267d8b63b61e6b + +A.2. Issuance Protocol 2 - Blind RSA (2048-bit) + + The test vectors below list the following values: + + skI: The PEM-encoded PKCS #8 RSA Issuer Private Key used for signing + tokens, represented as a hexadecimal string. + + pkI: The Issuer Public Key, serialized according to the encoding in + Section 8.2.2. + + token_challenge: A randomly generated TokenChallenge structure, + represented as a hexadecimal string. + + nonce: The 32-byte Client nonce generated according to Section 6.1, + represented as a hexadecimal string. + + blind: The blind used when computing the blind RSA blinded message, + represented as a hexadecimal string. + + salt: The randomly generated 48-byte salt used when encoding the + blinded TokenRequest message, represented as a hexadecimal string. + + token_request: The TokenRequest message constructed according to + Section 6.1, represented as a hexadecimal string. + + token_response: The TokenResponse message constructed according to + Section 6.2, represented as a hexadecimal string. + + token: The output token from the protocol, represented as a + hexadecimal string. + + // Test vector 1 + skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e + 393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e88000e6f72696 + 7696e2e6578616d706c65 + nonce: + aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd1508d07827f05 + blind: 425421de54c7381864ce36473abfb988c454fe6c27de863de702a6a2ad + ca153fa2de47bd8fcd62734caa8ce1f920b77d980ab58c32d16dde54873f28ca9 + 68e8c125b8363514be68972f553655bcc7f80a284cc327e47e804a47333c5b3cd + f773312cc7ad9fda748aed0baa7e19c5a2d1dafda718f086d7fc0a4bc02d488e0 + f20812daee335af7177b7a8369bd617066aed7a58f659f295c36b418827f67972 + 5b81ca14ea16fb82df21ad76da1ac38dcf24bf6252f8510e2308608ac9197f6cb + 54fdcb19db17837302a2b87d659c5605f35f3709a130f0c3d50e172f0cae36cbc + 9467f9914895a215a9e32443bcafff795273ccf8965a7eaa8c0b2184763e3e5c + salt: 3d980852fa570c064204feb8d107098db976ef8c2137e8641d234bbd88a + 986fdb306a7af220cfadede08f51e1ef61766 + token_request: 0002086a95be84b63cfed0993bb579194a72a95057e1548ac4 + 63a9a5b33b011f2b2011d59487f01862f1d8e4d5ea42e73a660fbc3d010b944a5 + 4da3a4e0942f8894c0884589b438cb902e9a34278970f33c16f351f7dae58d273 + c3ab66ef368da36f785e89e24d1d983d5c34311cd21f290f9e89e8646ab0d0a48 + 988fcd46230de5e7603cd12cc95c7ec5002e5e26737aa7eb69c626476e6c8d465 + 10ee404a3d7daf3a23b7c66735d363ca13676925c6ed0117f60d165ce1f8ba616 + d041b6384baf6da3e2f757cb18e879a4f8595c2dc895ddf1f4279c75768d108b5 + c47f95f94e81e2d8b9c8b74476924ab3b7c45243fc99ac5466e8a3680ad37fa15 + c96010b274094 + token_response: 675d84b751d9e593330ec4b6d7ab69c9a61517e98971f4b73 + 6150508174b4335761464f237be2d72bbae4b94dffc6143413f6351f1aa4efde6 + c32d4d6d9392a008290d56d1222f9b77a1336213e01934f7d972f3bf9ea5a5786 + c321352f103b3667e605379a55f0fb925fbb09b8a9f85e7dd4b388a3b49d06fd7 + 0ba28f6a780e3bc8f6421554fd6c38b63ef19f84ccfcf14709dd0b4d72213c1f0 + 60893854eba0ea1a147e275da320db5e9849882d5f9179efa8a2d8d3b803f9d14 + 45ef5c1f660be08883ce9b29a0a992fc035d2938cbb61c440044438dbb8b3ce71 + 58a8f9827d230482f622d291406ab236b32b122627ae0fd36bd0d6b7607b8044a + ce404d44 + token: 0002aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd150 + 8d07827f055969f643b4cfda5196d4aa86aeb5368834f4f06de46950ed435b3b8 + 1bd036d44ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd2708bc6a21b533d07294b5e900faf5537dd3eb33cee4e08c9670d1e5358fd + 184b0e00c637174f5206b14c7bb0e724ebf6b56271e5aa2ed94c051c4a433d302 + b23bc52460810d489fb050f9de5c868c6c1b06e3849fd087629f704cc724bc0d0 + 984d5c339686fcdd75f9a9cdd25f37f855f6f4c584d84f716864f546b696d620c + 5bd41a811498de84ff9740ba3003ba2422d26b91eb745c084758974642a420782 + 01543246ddb58030ea8e722376aa82484dca9610a8fb7e018e396165462e17a03 + e40ea7e128c090a911ecc708066cb201833010c1ebd4e910fc8e27a1be467f786 + 71836a508257123a45e4e0ae2180a434bd1037713466347a8ebe46439d3da1970 + + // Test vector 2 + skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c6500000e6f7269 + 67696e2e6578616d706c65 + nonce: + 98c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873d90e84488d + blind: 7bb85f89c9b83a0e2b02938b3396f06f8f3df0018a91f1a2cc5416aaa5 + 52994d063f634d50bea13bffe8d5e01431e646e2e384549cefd695ac3affff665 + a1ebf0113df2520006bd66e468d37a58266daa8a3a75692535e1fc46d0c1d6fb6 + f37c949808172e20c0b77a48570a1fcb474325bdd23cdbce52b5d6a9e39f7aec7 + 3b09004eae8c8bfff2b4b533ea63bcf467a4cd95ccfb0cb4e43bc4992c1fd0be7 + a77a4475dbf8094cf25125ece901abbcea607a9050ad9f8ec3d0d66341f6eab40 + ee9c9c22c0b560b8377f8543d8878c7458885fd285c7556cc88fc6021617075b4 + 2c83a86005169a6f13352e789b28fdbbe3d0288e1dd7c801497573893146aea3 + salt: b6b4378421ab0ea677ce3f4036fd0489dee458ad81ea519c3e8bde3fcd5 + ec1505d28e110d7b44dcac5e04ecedd54d11a + token_request: 00020892d26a271c0104657ba10c0b5cb2827bb209d86e8002 + 7f96bfb861e0f40cb897f0fc426498433141ce9bc8b4a95914fefe4e40bdd3802 + a121cb0b59a4ae7e03255275c4abf071d991c82ead402606c0ef912178b0a0f68 + d303e06a966079230592827b84979dbcb5f21ab8904e9908638ddf705c4f8af8a + 053c19a66090726b60c6b4063976e4c66eab33522dd3f9d64828441db4aa82d55 + adcc3d3920592884cd1e5a3f490d5c81f1306705dcc5c61d82373f1dbd7d2ae4b + 2fea0f7339f5d868415f59312766e3074ee4a7305f5f053da82673ee6747a727a + 26d8d10ea1b1a3491d26b0c38b962c02a774ac78932153aae9dcc98a9b1db1f53 + 89644682f7727 + token_response: 113a5124c1aef6fc230d9fc42b789226f45ca941aad4da3f4 + 8cf37c7744a8d7fd1dcfd71cd39d09e9324760180ea0bade3360efaf7322a1fa1 + 5f41247be3857fde8c5c92ec6d67a7ee33be8fdadf8b27bb0db706117448e55bc + e9927cb6bfb1f87f9edb054181a4558af0c0d3973d7033b9599e674c20cf08a7b + bcf0da815a2edaab7c4fb80dee4ea2cc53576a9691e857da931c6c592d2c69dd2 + 1afda8ea653dd90157adfe80e2375c08e75beb497df8b7b73192fbbd4e80359d9 + bbaecea14e0acebdda92596f71ec1d57e26b6497b3152976bc07a4409148cb843 + 89eb207fb8e841106012408c6e19b4f964008b6a909aaab767a661a061c97da16 + 43040455 + token: 000298c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873 + d90e84488d11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2 + b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd27083350a206c5e9b7c0898f97611ce0bb8d74d310bb194ab67e094e32ff6 + da90886924b1b9e7b569402c1101d896d2fc3a7371ef77f02310db1dc9f81c853 + 5828c2d0e9d9051720d182cd54e1c2c3bf417da2fc7aa72bb70ccc834ef274a2e + 809c9821b3d395d6535423f7428b3f29175d6eb840b4b7685336e57e2b6afeaab + c0c17ea4f557e8a9cc2f624e245c6ccd7cbdd6c32c97c5c6974e802f688e2d25f + 0aba4215f609f692244517d5d3407e0172273982c001c158f5fcbe1b5d2447c26 + a87e89f5a9e72b498b0c59ce749823d2cf253d3cf6cd4e64fa0e434d95e488789 + 247a9ceed756ff4ff33a8d2402c0db381236d331092838b608a42002552092897 + + // Test vector 3 + skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65000017666f6f + 2e6578616d706c652c6261722e6578616d706c65 + nonce: + 9e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af1592df0e71 + blind: c52cabc5e4e131e0f5860cc4c486c5ee8a5fa8ae59484446121f87b0d8 + ccd037f161a99ebcc57f79d05a2ffc852656ad2d0894fab8d1b0f998e6e678254 + ed5778da98b137371320314d06c24276e35435bccffa49d257687f270f9ce1792 + 6a074737546d5415a4bb9e624a6302562b395856632efb6992f6593a4f95fb342 + 002efebc3046ca96bbc26edb2f1a1454a24ce7b9a7ec8e44fb9e99c8144d409d8 + cd8a5903c0a3c0acbd9f82573ed1fc4a296e3eaf4867ade30110794678f422d36 + bd103ea4617d2472cf58da3381e52e5be60f4acbf685e280648cef21211a796ec + d005ecbdaa1046c40950afca4c4e7dd4b8c19e504088489a15667b45895b6e92 + salt: c847b5d0fa9101a1e09954ac9f3eed6600af58936295ad2e54274e13e64 + 0d59f732d07530c94c19c20668f03470c77ac + token_request: 0002080f6bd84fba1822c577c8cd670f1136cca107f84ddd9d + 405d5ed22ad15da975538f031433bad4a2688999732927efe2928d4c132389a12 + 2f40b639b083d6fcbbed7a55fb18db536d2dcbaefe6dc0a70730e6565b08a7dfd + 783913a59f37d798de0cfc262c9e90a7ee884a3ec355eacbd44e5f6779fea6a78 + 5b05ac352fdd51a116cf2be1d8e38b0bfacd6a3d53a88c99f747cce908f86b335 + 62691f540e3e88562092cd17cc2f78ce0fb53312a5f2dc918bdb1dc90d9d65091 + c7ba9080ccc1755cb5437989364dc92f0e8fea18f66d631451feb02a3d68af41d + e1a3f9be925dda5c4ca0706fc4ca28b3317e939f6573442c6d03be17cd141fa82 + 60d382d134c6b + token_response: 2dd08ce89cf4f62bc236ab7b75266e13c57c750345e328e0b + ea107537c4cbeea5bfc990716950440628ea2e37dbc5c9c6d84f9a965cbf0cbff + fb89516b1fd19a90d69cc52a28890bbdcf782f56aefadad85b6e861a74170ce91 + 0891c89e4293f37978dbd41cc8b5c68802de3d86d9f0326b9c22b809512245896 + 6a6ddd1aeb3828d239c3b359efc9b375390eb19050d5656c2b084304d9bd8a816 + 14f631bf82a7e4588413b44a0cb6d94e942fa134790b396cb71e3ed33b557b5bd + 0734e726fa79abdca8694703b81d0e289b749801d4383e0d4f825dcde0dd98c43 + d3ba81c028dd8833a4fc24961f60e118d4421dce5b611d53e9ca96156a52509bf + a9afeb7e + token: 00029e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af + 1592df0e710042eee45ac4dd5acb8f6e65c4d8dd47504f73f7463507ef96a4d72 + 27d2774f3ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd270815b010bbc0d5f55e9c856d2e9ffaefba007d33c2d5452fbeb0b15919b + 973e0dc9180aaeb18242043758d9fb0ac9ac5e04da9ff74ec93644ae6cdb7068e + a76ce2295b9b95e383ed3a9856e9f618dafdf4cec5d2b53ea4297c2f3990babca + 71e3ccd6c07a437daae7ed27b6b81178fb7ce5fa5dd63781cc64ac1e410f441c0 + 34b0a5cc873a2ce875e8b38c92bab563635c4f8f4fa35d1f582ef19edf7da75aa + 11a503a82e32a12bd4da41e0ca7ec7f451caf586f5b910003fcbbb9ff5ffa2408 + c28d6807737d03da651ea9bfafcc2747a6830e19a1d160fcd5c25d2f79dad86a8 + b3de8e926e08ca1addced72977f7b56398ef59c26e725df0a976a08f2a936ca42 + + // Test vector 4 + skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65000000 + nonce: + 494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c45340bfe8e6 + blind: 097cb17bcedecfe058dff5c4e517d1e36d7ab8f46252b1ac1933ba378c + 32625c0dbc69f5655c2003bf39e75810796cd63675b223cf3162c57108d56e058 + 4cfce6cad829e74369ada38a095eb3012c912b31ccde7425f93464e353fb17552 + be3a8df2913daca61543a33ae45058f218c471dfbc12fb304158e29b6ed35bc07 + 9e23f1e6173c5dec4545840bbe58e5ad37cbea0a10dca5d9df2781589d27c3410 + 8477b52c0d32a1370c17f703941fbb1a007a6794e7de2758709c9bbf80f21eec7 + 922b9bb491eb6aac8c1a14764e648e6be4fff0ae913797067aa0826f366c3103e + 103b05653c73b52d7f825a185dccfb806da700db9f53abb848554b7d4f7c28f3 + salt: 49912979f1bf528e5b8228ab1328df74319dce7bdaf45821ceb1100dcf0 + 42a2dfe852fc9db59b64a5f6493c282504240 + token_request: 000208244840027ca8c620f8b14caded9a198ba388ccd8541e + 962f68a0071535d958d18494afd0bc11da4da8c8b33864f5a8f623b697cd56348 + 594e11a75479048a72c0ed179b070506c09a7eb6ed3582f572df38cf60fcde11a + 52c5ce6d7b23435b60200ad9f66d21f40f323c9aa54307d0b966d4457c37542b6 + 6bb183ddeafca914fc74831698b5d52f498ee3d165685f49a8d86e39fe6c4b7ec + 678f5250908d25e5b873c69b422368121aa4210cadd6fc640907d3cb9a7a3e827 + a0e742470f00c2f49dc6c0e8cc9470dbfd73df0ccbb96c10b02af0dd7dee719ec + a11ff8e1b4929e59f3cf319de9bda29a6d968b43083b5d4242f3448d76ada08b8 + 014f70b97e719 + token_response: c2746ff644cffb28a2c19395fa19dfb61fd135daa837844fb + f9fbe06c253e64e69f53aefddc0fb4833b1b5e58f571134a34f245499c3e73419 + 549c2c9111cf94f2f68fea3996d47f71e8d8d6fc5b1c074bf74fa59de4cbf32f5 + f08d45ea45492f0279c3b1a8d852698edbe1651eb8e09eb223a27386c0feb2f6a + 8260235edb36cf433da518100829b63166284b325d87fc941ea3bafe7b6761b70 + 82e09397837f74b4f0fc838bce8af7242089dd5561f57735926bcbad219fc9fee + 85ae49a8e8951f63ca194b7ff018c06ee02267e7267bb996432dc76973819da80 + e3e86947b0a4b36d3a972dafaaa3db0e1044b325f02c679996d9bcd3ce51390d5 + 4bc10b8c + token: 0002494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c4 + 5340bfe8e6b741ec1b6fd05f1e95f8982906aec1612896d9ca97d53eef94ad3c9 + fe023f7a4ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd2708a55c83dc04292b5d92add1a87b37e54f22f61c58840586f390c50b231 + 824423378ddcf50e69dc817d45bfad06c7f2a0ac35d2acd7f26b0bc9954c192b0 + a0ef28a2a5650e390098dd3cb1166a7cb1716d3dd2d19dc5ca3b1ea6206359de0 + 002d82bc4fa7e69fb07214b06addcbd2203d1e17f57fc580bcc5a13e0ac15cf94 + 2182cc2b5d6eaa737a712704114e357e2ec2f10047463ded02a1a0766dc346dd7 + 212b9711e03ac95eb258ac1164104dc9a0d3e738ae742ab5ed8c5139fc07145a7 + 88b9f891741ee68f0a66782b7b84a9bb4cb4b3d1b26b67106f397b35b641d882d + 7b0185168946de898ef72349a44a47dbdd6d46e9ba9ba543d5701b65c63d645c2 + + // Test vector 5 + skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 + 4945765149424144414e42676b71686b6947397730424151454641415343424b6 + 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b + 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 + 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a + 35743561496b3172417643655844644e44503442325055707851436e6969396e6 + b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f + 6558563835464f314a752b62397336356d586d34516a755139455961497138337 + 1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41 + 355334475666325a6c74785954736f4c364872377a58696a4e394637486271656 + 76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f + 72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473 + 475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530 + 742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6 + b562b434c6679665351322b7266486e7266724665502f566344787275690a3270 + 316153584a596962653645532b4d622f4d4655646c485067414c7731785134576 + 57266366336444373686c6c784c57535638477342737663386f364750320a6359 + 366f777042447763626168474b556b5030456b62395330584c4a5763475347356 + 1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230 + 644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422 + f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a + 414261577538364d435a342f5131334c762b426566627174493973715a5a776a7 + 264556851483856437872793251564d515751696e57684174364d7154340a5342 + 5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367 + 3587a76374b53514b42675144766377735055557641395a325a583958350a6d49 + 784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7 + a652f376b337946786b68305146333162713630654c393047495369414f0a354b + 4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733 + 9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732 + 306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6 + e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932 + 7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4 + 8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675 + 77524e3632496f397463392b41434c745542377674476179332b6752775974534 + 33262356564386c4969656774546b6561306830754453527841745673330a6e35 + 6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385 + 0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533 + 77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6 + e735170315947763977644a724d6156774a6376497077563676315570660a5674 + 4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573 + 9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567 + 5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3 + 97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941 + 7844733968355272627852614e6673542b7241554837783153594456565159564 + d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c + 6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726 + 2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30 + 31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787 + 86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363 + 77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5 + 0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b + 4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205 + 0524956415445204b45592d2d2d2d2d0a + pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165 + 03040202a11a301806092a864886f70d010108300b0609608648016503040202a + 2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab + 25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4 + b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50 + 0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4 + 53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7 + 32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b + 1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f + e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9 + babd612d03cad02db134b7e225a5f0203010001 + token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e + 393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e880000 + nonce: + a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f63143cd43a3 + blind: ad7a32e1ac31b91daefd7042cc23d5621ab3e870d87297bbfe1ee8a518 + ffc5b84770d3b77775c485b2d219954834868842d2f11877ac4bceb5da88944cc + a043a9afa52f9c9998a5dea7ab7c1f82662d0d327e29705a269ad221ae74a7c11 + 72ff89c48997a9fda08886d3998bb538868396c0ace71d260cc71f768001939b2 + 4d80d88979f0244a3dbc004eadfac81e138d430b9fa51c1aad21b957ff96b3123 + c91c2fff362a386f0f99a3f9fc906ca626fd9107648f87532b44c4fe3856ecae1 + f46d8ebf5d2f46e52034478e5e883015666574dd80bd5c036c4b55ebcc8b66068 + 8d23944cc1932d075b559dcdc269fae3511761f71c113634e60d67accc8875fb + salt: 35c04710ce866d879447b6230ce098a49e81be5c067881cce7bd5f92c1e + 5bd9b3c7d4d795cfad134fdfe916d735a624a + token_request: 0002083d6495c72529bbc4f5c0b49e94e4561baec1ca638a93 + b2940ea9e37b838db7b1a91ec1f257d49b45c4f75119c2ab9eb5578541ad2b9ba + c1bd627abc709097f503f83d98fed6dbeb615c3be9bf09cbf8ea25ea8026c1b8b + a1c704ff516ed87c3d7d85342fd00111d8a80492d4b8fdbb092a282f74f13901e + 5edc1b3b02cfe24c950affe6130fbb57c1482d674db3c6944812ba081c2235a16 + d01eeec0932a8619d85732fc3e36179f0b50377bf9cb7a50ce3abeb3f31ed5f0f + 3deec7aae7290f5397cec61318357d652b029a0fda0f100a78e36c4ef56ba3779 + 963e8745fdf4e347763c63d825836878e249833a0f4bd315392cc06ccca2c955e + 921efbc4f941d + token_response: 8db727000018a98a2fe9fda8bbde5b8e9cedc31efbcaed695 + 0eb1e0f8d9af9db632def52f74f07cdab304bbde40519080dd0388fb2b8900528 + b4791d2bca40aa2c2a6d1b92f010c1849bfb781cc813cc204855dd05e8a2dd31e + a5220981b8ab6b008e153083dc8f594206440d66286fea9c21b56807be8655506 + ab7818bb9c8c69489dda56fe6390a5397268c8b5711f9d2df6f2584740cccf034 + 5fd67f93f345426f33c078a0aceb90845df9eef74f6248d06c36d19e191da325b + 721ddc12ea78ed37b0c3b6170590536e3aee7eb0efc7d11a2c9d072a394f12ffa + 67ecf316c49efd8f31723b11fe46740636bd89ad4f7ef96bc38b2cb4916d9dc04 + ba1b2fc6 + token: 0002a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f6 + 3143cd43a3bb8a8cf1c59e7a251358ed76fe0ccff61044bc79dd261f16020324d + 22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f + 71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a + 9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26 + e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c + c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81 + a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b + a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273 + c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658 + 5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23 + +Acknowledgements + + The authors of this document would like to acknowledge the helpful + feedback and discussions from Benjamin Schwartz, Joseph Salowey, and + Tara Whalen. + +Authors' Addresses + + Sofía Celi + Brave Software + Lisbon + Portugal + Email: cherenkov@riseup.net + + + Alex Davidson + NOVA LINCS, Universidade NOVA de Lisboa + Largo da Torre + Caparica + Portugal + Email: alex.davidson92@gmail.com + + + Steven Valdez + Google LLC + Email: svaldez@chromium.org + + + Christopher A. Wood + Cloudflare + 101 Townsend St + San Francisco, CA 94107 + United States of America + Email: caw@heapingbits.net |