| < draft-ietf-privacypass-protocol-03.txt | draft-ietf-privacypass-protocol-04.txt > | |||
|---|---|---|---|---|
| Network Working Group S. Celi | Network Working Group S. Celi | |||
| Internet-Draft Cloudflare | Internet-Draft Cloudflare | |||
| Intended status: Informational A. Davidson | Intended status: Informational A. Davidson | |||
| Expires: 8 September 2022 Brave Software | Expires: 7 October 2022 Brave Software | |||
| A. Faz-Hernandez | A. Faz-Hernandez | |||
| Cloudflare | Cloudflare | |||
| S. Valdez | S. Valdez | |||
| Google LLC | Google LLC | |||
| C. A. Wood | C. A. Wood | |||
| Cloudflare | Cloudflare | |||
| 7 March 2022 | 5 April 2022 | |||
| Privacy Pass Issuance Protocol | Privacy Pass Issuance Protocol | |||
| draft-ietf-privacypass-protocol-03 | draft-ietf-privacypass-protocol-04 | |||
| Abstract | Abstract | |||
| This document specifies two variants of the the two-message issuance | This document specifies two variants of the the two-message issuance | |||
| protocol for Privacy Pass tokens: one that produces tokens that are | protocol for Privacy Pass tokens: one that produces tokens that are | |||
| privately verifiable, and another that produces tokens that are | privately verifiable, and another that produces tokens that are | |||
| publicly verifiable. The privately verifiable issuance protocol | publicly verifiable. The privately verifiable issuance protocol | |||
| optionally supports public metadata during the issuance flow. | optionally supports public metadata during the issuance flow. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 8 September 2022. | This Internet-Draft will expire on 7 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 40 ¶ | skipping to change at page 2, line 40 ¶ | |||
| 6.4. Issuer Configuration . . . . . . . . . . . . . . . . . . 11 | 6.4. Issuer Configuration . . . . . . . . . . . . . . . . . . 11 | |||
| 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 | 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 | |||
| 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 | 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 8.1. Token Type . . . . . . . . . . . . . . . . . . . . . . . 12 | 8.1. Token Type . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 12 | 8.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8.2.1. "message/token-request" media type . . . . . . . . . 12 | 8.2.1. "message/token-request" media type . . . . . . . . . 12 | |||
| 8.2.2. "message/token-response" media type . . . . . . . . . 13 | 8.2.2. "message/token-response" media type . . . . . . . . . 13 | |||
| 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 | 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 | |||
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 | |||
| Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 15 | Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 15 | |||
| B.1. Issuance Protocol 1 (POPRF) . . . . . . . . . . . . . . . 15 | B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) . . . . . . . 15 | |||
| B.2. Issuance Protocol 2 (Blind RSA) . . . . . . . . . . . . . 16 | B.2. Issuance Protocol 2 - Blind RSA, 4096 . . . . . . . . . . 16 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 1. Introduction | 1. Introduction | |||
| The Privacy Pass protocol provides a privacy-preserving authorization | The Privacy Pass protocol provides a privacy-preserving authorization | |||
| mechanism. In essence, the protocol allows clients to provide | mechanism. In essence, the protocol allows clients to provide | |||
| cryptographic tokens that prove nothing other than that they have | cryptographic tokens that prove nothing other than that they have | |||
| been created by a given server in the past | been created by a given server in the past | |||
| [I-D.ietf-privacypass-architecture]. | [I-D.ietf-privacypass-architecture]. | |||
| This document describes the issuance protocol for Privacy Pass. It | This document describes the issuance protocol for Privacy Pass. It | |||
| skipping to change at page 4, line 38 ¶ | skipping to change at page 4, line 38 ¶ | |||
| interactive or non-interactive, and per-origin or cross-origin. | interactive or non-interactive, and per-origin or cross-origin. | |||
| 5. Issuance Protocol for Privately Verifiable Tokens with Public | 5. Issuance Protocol for Privately Verifiable Tokens with Public | |||
| Metadata | Metadata | |||
| The Privacy Pass issuance protocol is a two message protocol that | The Privacy Pass issuance protocol is a two message protocol that | |||
| takes as input a challenge from the redemption protocol and produces | takes as input a challenge from the redemption protocol and produces | |||
| a token, as shown in the figure below. | a token, as shown in the figure below. | |||
| Origin Client Issuer | Origin Client Issuer | |||
| (pkI, info) (skI, pkI, info) | (pkI) (skI, pkI) | |||
| +------------------------------------\ | +------------------------------------\ | |||
| Challenge ----> TokenRequest -------------> | | Challenge ----> TokenRequest -------------> | | |||
| | (evaluate) | | | (evaluate) | | |||
| Token <----+ <--------------- TokenResponse | | Token <----+ <--------------- TokenResponse | | |||
| \------------------------------------/ | \------------------------------------/ | |||
| Issuers provide a Private and Public Key, denoted skI and pkI, | Issuers provide a Private and Public Key, denoted skI and pkI, | |||
| respectively, used to produce tokens as input to the protocol. See | respectively, used to produce tokens as input to the protocol. See | |||
| Section 5.4 for how this key pair is generated. | Section 5.4 for how this key pair is generated. | |||
| skipping to change at page 5, line 12 ¶ | skipping to change at page 5, line 12 ¶ | |||
| * Issuer name, identifying the Issuer. This is typically a host | * Issuer name, identifying the Issuer. This is typically a host | |||
| name that can be used to construct HTTP requests to the Issuer. | name that can be used to construct HTTP requests to the Issuer. | |||
| * Issuer Public Key pkI, with a key identifier key_id computed as | * Issuer Public Key pkI, with a key identifier key_id computed as | |||
| described in Section 5.4. | described in Section 5.4. | |||
| * Challenge value challenge, an opaque byte string. For example, | * Challenge value challenge, an opaque byte string. For example, | |||
| this might be provided by the redemption protocol in | this might be provided by the redemption protocol in | |||
| [HTTP-Authentication]. | [HTTP-Authentication]. | |||
| Both Client and Issuer also share a common public string called info. | ||||
| Given this configuration and these inputs, the two messages exchanged | Given this configuration and these inputs, the two messages exchanged | |||
| in this protocol are described below. This section uses notation | in this protocol are described below. This section uses notation | |||
| described in [OPRF], Section 4, including SerializeElement and | described in [OPRF], Section 4, including SerializeElement and | |||
| DeserializeElement, SerializeScalar and DeserializeScalar, and | DeserializeElement, SerializeScalar and DeserializeScalar, and | |||
| DeriveKeyPair. | DeriveKeyPair. | |||
| 5.1. Client-to-Issuer Request | 5.1. Client-to-Issuer Request | |||
| The Client first creates a context as follows: | The Client first creates a context as follows: | |||
| client_context = SetupPOPRFClient(0x0004, pkI) | client_context = SetupVOPRFClient(0x0004, pkI) | |||
| Here, 0x0004 is the two-octet identifier corresponding to the | Here, 0x0004 is the two-octet identifier corresponding to the | |||
| OPRF(P-384, SHA-384) ciphersuite in [OPRF]. SetupPOPRFClient is | OPRF(P-384, SHA-384) ciphersuite in [OPRF]. SetupVOPRFClient is | |||
| defined in [OPRF], Section 3.2. | defined in [OPRF], Section 3.2. | |||
| The Client then creates an issuance request message for a random | The Client then creates an issuance request message for a random | |||
| value nonce using the input challenge and Issuer key identifier as | value nonce using the input challenge and Issuer key identifier as | |||
| follows: | follows: | |||
| nonce = random(32) | nonce = random(32) | |||
| context = SHA256(challenge) | context = SHA256(challenge) | |||
| token_input = concat(0x0001, nonce, context, key_id) | token_input = concat(0x0001, nonce, context, key_id) | |||
| blind, blinded_msg, tweaked_key = client_context.Blind(nonce, info) | blind, blinded_element = client_context.Blind(token_input) | |||
| The Blind function is defined in [OPRF], Section 3.3.3. If the Blind | The Blind function is defined in [OPRF], Section 3.3.2. If the Blind | |||
| function fails, the Client aborts the protocol. Otherwise, the | function fails, the Client aborts the protocol. Otherwise, the | |||
| Client then creates a TokenRequest structured as follows: | Client then creates a TokenRequest structured as follows: | |||
| struct { | struct { | |||
| uint16_t token_type = 0x0001; | uint16_t token_type = 0x0001; | |||
| uint8_t token_key_id; | uint8_t token_key_id; | |||
| uint8_t blinded_request[Ne]; | uint8_t blinded_msg[Ne]; | |||
| } TokenRequest; | } TokenRequest; | |||
| The structure fields are defined as follows: | The structure fields are defined as follows: | |||
| * "token_type" is a 2-octet integer, which matches the type in the | * "token_type" is a 2-octet integer, which matches the type in the | |||
| challenge. | challenge. | |||
| * "token_key_id" is the least significant byte of the key_id. | * "token_key_id" is the least significant byte of the key_id. | |||
| * "blinded_request" is the Ne-octet blinded message defined above, | * "blinded_msg" is the Ne-octet blinded message defined above, | |||
| computed as SerializeElement(blinded_msg). Ne is as defined in | computed as SerializeElement(blinded_element). Ne is as defined | |||
| [OPRF], Section 4. | in [OPRF], Section 4. | |||
| The value tweaked_key is stored locally and used later as described | The values token_input and blinded_element are stored locally and | |||
| in Section 5.3. The Client then generates an HTTP POST request to | used later as described in Section 5.3. The Client then generates an | |||
| send to the Issuer, with the TokenRequest as the body. The media | HTTP POST request to send to the Issuer, with the TokenRequest as the | |||
| type for this request is "message/token-request". An example request | body. The media type for this request is "message/token-request". | |||
| is shown below. | An example request is shown below. | |||
| :method = POST | :method = POST | |||
| :scheme = https | :scheme = https | |||
| :authority = issuer.example.net | :authority = issuer.example.net | |||
| :path = /example-token-request | :path = /example-token-request | |||
| accept = message/token-response | accept = message/token-response | |||
| cache-control = no-cache, no-store | cache-control = no-cache, no-store | |||
| content-type = message/token-request | content-type = message/token-request | |||
| content-length = <Length of TokenRequest> | content-length = <Length of TokenRequest> | |||
| <Bytes containing the TokenRequest> | <Bytes containing the TokenRequest> | |||
| Upon receipt of the request, the Issuer validates the following | Upon receipt of the request, the Issuer validates the following | |||
| conditions: | conditions: | |||
| * The TokenRequest contains a supported token_type. | * The TokenRequest contains a supported token_type. | |||
| * The TokenRequest.token_key_id corresponds to a key ID of a Public | * The TokenRequest.token_key_id corresponds to a key ID of a Public | |||
| Key owned by the issuer. | Key owned by the issuer. | |||
| * The TokenRequest.blinded_msg is of the correct size. | * The TokenRequest.blinded_request is of the correct size. | |||
| If any of these conditions is not met, the Issuer MUST return an HTTP | If any of these conditions is not met, the Issuer MUST return an HTTP | |||
| 400 error to the Client, which will forward the error to the client. | 400 error to the client. | |||
| 5.2. Issuer-to-Client Response | 5.2. Issuer-to-Client Response | |||
| If the Issuer is willing to produce a token token to the Client, the | Upon receipt of a TokenRequest, the Issuer tries to deseralize | |||
| Issuer completes the issuance flow by computing a blinded response as | TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of | |||
| follows: | [OPRF], yielding blinded_element. If this fails, the Issuer MUST | |||
| return an HTTP 400 error to the client. Otherwise, if the Issuer is | ||||
| server_context = SetupPOPRFServer(0x0004, skI, pkI) | willing to produce a token token to the Client, the Issuer completes | |||
| evaluate_msg, proof = server_context.Evaluate(skI, | the issuance flow by computing a blinded response as follows: | |||
| TokenRequest.blinded_message, info) | ||||
| SetupPOPRFServer is in [OPRF], Section 3.2 and Evaluate is defined in | server_context = SetupVOPRFServer(0x0004, skI, pkI) | |||
| [OPRF], Section 3.3.3. The Issuer then creates a TokenResponse | evaluate_element, proof = server_context.Evaluate(skI, blinded_element) | |||
| SetupVOPRFServer is in [OPRF], Section 3.2 and Evaluate is defined in | ||||
| [OPRF], Section 3.3.2. The Issuer then creates a TokenResponse | ||||
| structured as follows: | structured as follows: | |||
| struct { | struct { | |||
| uint8_t evaluate_response[Nk]; | uint8_t evaluate_msg[Nk]; | |||
| uint8_t evaluate_proof[Ns+Ns]; | uint8_t evaluate_proof[Ns+Ns]; | |||
| } TokenResponse; | } TokenResponse; | |||
| The structure fields are defined as follows: | The structure fields are defined as follows: | |||
| * "evaluate_response" is the Ne-octet evaluated messaged, computed | * "evaluate_msg" is the Ne-octet evaluated messaged, computed as | |||
| as SerializeElement(evaluated_msg). | SerializeElement(evaluate_element). | |||
| * "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a | * "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a | |||
| pair of Scalar values, computed as | pair of Scalar values, computed as | |||
| concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])), | concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])), | |||
| where Ns is as defined in [OPRF], Section 4. | where Ns is as defined in [OPRF], Section 4. | |||
| The Issuer generates an HTTP response with status code 200 whose body | The Issuer generates an HTTP response with status code 200 whose body | |||
| consists of TokenResponse, with the content type set as "message/ | consists of TokenResponse, with the content type set as "message/ | |||
| token-response". | token-response". | |||
| :status = 200 | :status = 200 | |||
| content-type = message/token-response | content-type = message/token-response | |||
| content-length = <Length of TokenResponse> | content-length = <Length of TokenResponse> | |||
| <Bytes containing the TokenResponse> | <Bytes containing the TokenResponse> | |||
| 5.3. Finalization | 5.3. Finalization | |||
| Upon receipt, the Client handles the response and, if successful, | Upon receipt, the Client handles the response and, if successful, | |||
| deserializes the body values TokenResponse.evaluate_response and | deserializes the body values TokenResponse.evaluate_response and | |||
| TokenResponse.evaluate_proof. If deserialization of any value fails, | TokenResponse.evaluate_proof, yielding evaluated_element and proof. | |||
| the Client aborts the protocol. Otherwise, when deserialization | If deserialization of either value fails, the Client aborts the | |||
| yields evaluated_msg and proof, the Client processes the response as | protocol. Otherwise, the Client processes the response as follows: | |||
| follows: | ||||
| authenticator = client_context.Finalize(context, blind, pkI, | authenticator = client_context.Finalize(token_input, blind, evaluated_element, blinded_element, proof) | |||
| evaluated_msg, blinded_msg, info, tweaked_key) | ||||
| The Finalize function is defined in [OPRF], Section 3.3.3. If this | The Finalize function is defined in [OPRF], Section 3.3.2. If this | |||
| succeeds, the Client then constructs a Token as follows: | succeeds, the Client then constructs a Token as follows: | |||
| struct { | struct { | |||
| uint16_t token_type = 0x0001 | uint16_t token_type = 0x0001 | |||
| uint8_t nonce[32]; | uint8_t nonce[32]; | |||
| uint8_t context[32]; | uint8_t challenge_digest[32]; | |||
| uint8_t key_id[32]; | uint8_t token_key_id[32]; | |||
| uint8_t authenticator[Nk]; | uint8_t authenticator[Nk]; | |||
| } Token; | } Token; | |||
| Otherwise, the Client aborts the protocol. | Otherwise, the Client aborts the protocol. | |||
| 5.4. Issuer Configuration | 5.4. Issuer Configuration | |||
| Issuers are configured with Private and Public Key pairs, each | Issuers are configured with Private and Public Key pairs, each | |||
| denoted skI and pkI, respectively, used to produce tokens. Each key | denoted skI and pkI, respectively, used to produce tokens. Each key | |||
| pair MUST be generated as follows: | pair MUST be generated as follows: | |||
| skipping to change at page 11, line 25 ¶ | skipping to change at page 11, line 25 ¶ | |||
| authenticator = rsabssa_finalize(pkI, nonce, blind_sig, blind_inv) | authenticator = rsabssa_finalize(pkI, nonce, blind_sig, blind_inv) | |||
| The rsabssa_finalize function is defined in [BLINDRSA], | The rsabssa_finalize function is defined in [BLINDRSA], | |||
| Section 5.1.3.. If this succeeds, the Client then constructs a Token | Section 5.1.3.. If this succeeds, the Client then constructs a Token | |||
| as described in [HTTP-Authentication] as follows: | as described in [HTTP-Authentication] as follows: | |||
| struct { | struct { | |||
| uint16_t token_type = 0x0002 | uint16_t token_type = 0x0002 | |||
| uint8_t nonce[32]; | uint8_t nonce[32]; | |||
| uint8_t context[32]; | uint8_t challenge_digest[32]; | |||
| uint8_t key_id[32]; | uint8_t token_key_id[32]; | |||
| uint8_t authenticator[Nk]; | uint8_t authenticator[Nk]; | |||
| } Token; | } Token; | |||
| Otherwise, the Client aborts the protocol. | Otherwise, the Client aborts the protocol. | |||
| 6.4. Issuer Configuration | 6.4. Issuer Configuration | |||
| Issuers are configured with Private and Public Key pairs, each | Issuers are configured with Private and Public Key pairs, each | |||
| denoted skI and pkI, respectively, used to produce tokens. Each key | denoted skI and pkI, respectively, used to produce tokens. Each key | |||
| pair MUST be generated as as a valid 4096-bit RSA private key | pair MUST be generated as as a valid 4096-bit RSA private key | |||
| skipping to change at page 12, line 9 ¶ | skipping to change at page 12, line 9 ¶ | |||
| related to broader privacy and security concerns in a multi-Client | related to broader privacy and security concerns in a multi-Client | |||
| and multi-Issuer setting are deferred to the Architecture document | and multi-Issuer setting are deferred to the Architecture document | |||
| [I-D.ietf-privacypass-architecture]. | [I-D.ietf-privacypass-architecture]. | |||
| 8. IANA considerations | 8. IANA considerations | |||
| 8.1. Token Type | 8.1. Token Type | |||
| This document updates the "Token Type" Registry with the following | This document updates the "Token Type" Registry with the following | |||
| values. | values. | |||
| +======+=============+============+========+========+===+===========+ | +======+==============+============+========+========+===+==========+ | |||
| |Value | Name | Publicly |Public |Private |Nk | Reference | | |Value | Name | Publicly |Public |Private |Nk |Reference | | |||
| | | | Verifiable |Metadata|Metadata| | | | | | | Verifiable |Metadata|Metadata| | | | |||
| +======+=============+============+========+========+===+===========+ | +======+==============+============+========+========+===+==========+ | |||
| |0x0001| OPRF(P-384, | N |Y |N |48 | Section 5 | | |0x0001| VOPRF(P-384, | N |N |N |48 |Section 5 | | |||
| | | SHA-384) | | | | | | | | | SHA-384) | | | | | | | |||
| +------+-------------+------------+--------+--------+---+-----------+ | +------+--------------+------------+--------+--------+---+----------+ | |||
| |0x0002| Blind RSA, | Y |N |N |512| Section 6 | | |0x0002| Blind RSA, | Y |N |N |512|Section 6 | | |||
| | | 4096 | | | | | | | | | 4096 | | | | | | | |||
| +------+-------------+------------+--------+--------+---+-----------+ | +------+--------------+------------+--------+--------+---+----------+ | |||
| Table 2: Token Types | Table 2: Token Types | |||
| 8.2. Media Types | 8.2. Media Types | |||
| This specification defines the following protocol messages, along | This specification defines the following protocol messages, along | |||
| with their corresponding media types: | with their corresponding media types: | |||
| * TokenRequest: "message/token-request" | * TokenRequest: "message/token-request" | |||
| skipping to change at page 15, line 27 ¶ | skipping to change at page 15, line 27 ¶ | |||
| feedback and discussions from Benjamin Schwartz, Joseph Salowey, | feedback and discussions from Benjamin Schwartz, Joseph Salowey, | |||
| Sofia Celi, and Tara Whalen. | Sofia Celi, and Tara Whalen. | |||
| Appendix B. Test Vectors | Appendix B. Test Vectors | |||
| This section includes test vectors for the two basic issuance | This section includes test vectors for the two basic issuance | |||
| protocols specified in this document. Appendix B.1 contains test | protocols specified in this document. Appendix B.1 contains test | |||
| vectors for token issuance protocol 1 (0x0001), and Appendix B.2 | vectors for token issuance protocol 1 (0x0001), and Appendix B.2 | |||
| contains test vectors for token issuance protocol 2 (0x0002). | contains test vectors for token issuance protocol 2 (0x0002). | |||
| B.1. Issuance Protocol 1 (POPRF) | B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384) | |||
| The test vector below lists the following values: | The test vector below lists the following values: | |||
| * skS: The encoded OPRF private key, serialized using | * skS: The encoded OPRF private key, serialized using | |||
| SerializeScalar from Section 2.1 of [OPRF] and represented as a | SerializeScalar from Section 2.1 of [OPRF] and represented as a | |||
| hexadecimal string. | hexadecimal string. | |||
| * pkS: The encoded OPRF public key, serialized using | * pkS: The encoded OPRF public key, serialized using | |||
| SerializeElement from Section 2.1 of [OPRF] and represented as a | SerializeElement from Section 2.1 of [OPRF] and represented as a | |||
| hexadecimal string. | hexadecimal string. | |||
| skipping to change at page 16, line 11 ¶ | skipping to change at page 16, line 11 ¶ | |||
| * token_request: The TokenRequest message constructed according to | * token_request: The TokenRequest message constructed according to | |||
| Section 5.1, represented as a hexadecimal string. | Section 5.1, represented as a hexadecimal string. | |||
| * token_request: The TokenResponse message constructed according to | * token_request: The TokenResponse message constructed according to | |||
| Section 5.2, represented as a hexadecimal string. | Section 5.2, represented as a hexadecimal string. | |||
| * token: The output Token from the protocol, represented as a | * token: The output Token from the protocol, represented as a | |||
| hexadecimal string. | hexadecimal string. | |||
| The info parameter used when computing the token is the ASCII string | skS: 0177781aeced893dccdf80713d318a801e2a0498240fdcf650304bbbfd0f8d3b5c0 | |||
| "Privacy Pass". | cf6cfee457aaa983ec02ff283b7a9 | |||
| pkS: 022c63f79ac59c0ba3d204245f676a2133bd6120c90d67afa05cd6f8614294b7366 | ||||
| skS: accb1467936ba0c06500acc592633dd19c7d8cd752fc3975f6fd3123b993a703a84 | c252c6458300551b79a4911c2590a36 | |||
| f0a7d88949bd41ec9c655459c9b47 | ||||
| pkS: 03fa7bb43a5223538e3bfd06e817af754d6a950a86eb88a134dacbb3f5c4cff47e4 | ||||
| a8a8f4cea5eb2cf162a913a985167f8 | ||||
| challenge: | challenge: | |||
| f7e31518291770916d2164b7ec4a7a32698588fdaef0428812069b54dbc70bca | a5d46383359ef34e3c4a7b8d1b3165778bffc9b70c9e6a60dd14143e4c9c9fbd | |||
| nonce: ae576e03963659fe07badeccb21967ad5d893e09a1ad71635367d87fb932ca39 | nonce: 5d4799f8338ddc50a6685f83b8ecd264b2f157015229d12b3384c0f199efe7b8 | |||
| blind: 4a13636159a6769241dcb439d7e2ff604ce971d217edb20f1f8ad7b28faf841e5 | blind: 0322fec505230992256296063d989b59cc03e83184eb6187076d264137622d202 | |||
| 1688a95e722554d2ea796f40c010c4c | 48e4e525bdc007b80d1560e0a6f49d9 | |||
| token_request: 000178036e06b416f09c58bd9ca0a6c5d60391e0d993fc2ffdea33963 | token_request: 00011a02861fd50d14be873611cff0131d2c872c79d0260c6763498a2 | |||
| f3c7d6c421a8c36d9b1d2f1164fd94a4be70651d1745e01 | a3f14ca926009c0f247653406e1d52b68d61b7ed2bac9ea | |||
| token_response: 036544d94b1e2b3518bcbf6a80e85779f516406c5b41d1c2d35e6f22 | token_response: 038e3625b6a769668a99680e46cf9479f5dc1e86d57164ab3b4a569d | |||
| dc7d61708736f0768a3bc7313f42e06be5674db27cc2af138521a9dc979ea2ca4636bec9 | dfc486bf1485d4916a5194fdc0518d3e8444968421ba36e8144aa7902705ff0f3cf40586 | |||
| 0d21258aba98e4f322ec4a443bf8976fe5529dd92dd60c2e6f3c9030fcdb2621bf0e25c5 | 3d69451a2a7ba210cc45760c2f1a6045134d877b39e8bcbbf920e5de4a3372557debf211 | |||
| 0d9deb319df250a9ec40ec121e1852f2365007ca0b330cb9edbff46daa89087fc3d8cf2f | 765cd969976860bc039f9082d6a3e03f8e891246240173d2cf3d69a4613b0f8415979029 | |||
| d33979c2a6d8f64fed | 22e74c7a1f2e4639e4 | |||
| token: 0001ae576e03963659fe07badeccb21967ad5d893e09a1ad71635367d87fb932c | token: 00015d4799f8338ddc50a6685f83b8ecd264b2f157015229d12b3384c0f199efe | |||
| a39ebecc2a0a1a2beef6f8457a256501ff3d943f9a18a507f21069bd960542420b178d37 | 7b8742cdfb0ed756ea680868ef109a280a393e001d2fa56b1be46ecb31fa25e76731a5b1 | |||
| 692bdb29cedf2e6c44adc55d7b8909584e5a9096005aeb5b8913a69c681e7a5d48fd687f | d698ea7ab843b8e8a71ed9b2fffa70457a43a8fc687939424b29a7554b40fde130ab7a82 | |||
| fb181512ba16d6472489b363ad84047b4e1701d50f30fa03516eae4ca715698f37c68d16 | 2715909cb73f99a45b640ca1c85180ba9ca1a40bab8b664406a34bcbc63b5e2e5c455cea | |||
| 0c7ffb0dbd4 | 00001a968f7 | |||
| B.2. Issuance Protocol 2 (Blind RSA) | B.2. Issuance Protocol 2 - Blind RSA, 4096 | |||
| The test vector below lists the following values: | The test vector below lists the following values: | |||
| * skS: The PEM-encoded PKCS#8 RSA private key used for signing | * skS: The PEM-encoded PKCS#8 RSA private key used for signing | |||
| tokens, represented as a hexadecimal string. | tokens, represented as a hexadecimal string. | |||
| * pkS: The DER-encoded SubjectPublicKeyInfo object carrying the | * pkS: The DER-encoded SubjectPublicKeyInfo object carrying the | |||
| public key corresponding to skS, as described in Section 6.4, | public key corresponding to skS, as described in Section 6.4, | |||
| represented as a hexadecimal string. | represented as a hexadecimal string. | |||
| skipping to change at page 21, line 4 ¶ | skipping to change at page 20, line 49 ¶ | |||
| d0dc9a0f596a9f76502ebadc0b248985f9bb66d9d99a5aca08527aa11d555b26489299ba | d0dc9a0f596a9f76502ebadc0b248985f9bb66d9d99a5aca08527aa11d555b26489299ba | |||
| 5b400157a9fd47b6b4fa74315eade2b22624b29d53eb84126f64b98ea5ba45914d1fa14b | 5b400157a9fd47b6b4fa74315eade2b22624b29d53eb84126f64b98ea5ba45914d1fa14b | |||
| 1525e2327856565054a1db9b0d778871fa6ed4d0d4c26641bf3f4faa33efaa0f5b8cec80 | 1525e2327856565054a1db9b0d778871fa6ed4d0d4c26641bf3f4faa33efaa0f5b8cec80 | |||
| 8d52ed3f1378273d5b7b0b0b812bfc128ef5e4924a60aebd124659d31661e9ec89f8bcb9 | 8d52ed3f1378273d5b7b0b0b812bfc128ef5e4924a60aebd124659d31661e9ec89f8bcb9 | |||
| a51bab6a5711187639c24fdd31f14abf7d80827df91f31bfe7c4916ec4d1927ca138c5ba | a51bab6a5711187639c24fdd31f14abf7d80827df91f31bfe7c4916ec4d1927ca138c5ba | |||
| 9a595a9e83b5055148d19ad005c523eda76ea94006ce6315e20ed0d637fb1211b541e9ea | 9a595a9e83b5055148d19ad005c523eda76ea94006ce6315e20ed0d637fb1211b541e9ea | |||
| 12c9b641d48fd2cc5f0c7f479672a4e2bf7469267c8526d734df41f2c30fb62c2aea4033 | 12c9b641d48fd2cc5f0c7f479672a4e2bf7469267c8526d734df41f2c30fb62c2aea4033 | |||
| 214df44a53353dc683cf72dee7b1ba39ef668478958935a0e8c9a880ae85712c401d7f09 | 214df44a53353dc683cf72dee7b1ba39ef668478958935a0e8c9a880ae85712c401d7f09 | |||
| b66fbad05cfd69d615b229bce8818c6a6472e07a8793456f19f4f4015c507ab5c1357881 | b66fbad05cfd69d615b229bce8818c6a6472e07a8793456f19f4f4015c507ab5c1357881 | |||
| 68b | 68b | |||
| Authors' Addresses | ||||
| Authors' Addresses | ||||
| Sofía Celi | Sofía Celi | |||
| Cloudflare | Cloudflare | |||
| Lisbon | Lisbon | |||
| Portugal | Portugal | |||
| Email: sceli@cloudflare.com | Email: sceli@cloudflare.com | |||
| Alex Davidson | Alex Davidson | |||
| Brave Software | Brave Software | |||
| Lisbon | Lisbon | |||
| Portugal | Portugal | |||
| End of changes. 32 change blocks. | ||||
| 84 lines changed or deleted | 78 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||