< 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/