Skip to content

Commit

Permalink
Script updating gh-pages from f938600. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Sep 21, 2023
1 parent 1ca4f05 commit 43296d1
Show file tree
Hide file tree
Showing 3 changed files with 69 additions and 52 deletions.
49 changes: 29 additions & 20 deletions draft-ietf-privacypass-protocol.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1498,7 +1498,8 @@ <h2 id="name-configuration">
Issuers indicate 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. Origins can attempt
"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 verification like this can help deal with Client
clock skew.<a href="#section-4-8" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1550,8 +1551,10 @@ <h2 id="name-configuration">
result in use of stale Issuer configuration information, whereas short
lifetimes may result in decreased performance. When 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.<a href="#section-4-17" class="pilcrow"></a></p>
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.<a href="#section-4-17" class="pilcrow"></a></p>
</section>
</div>
<div id="private-flow">
Expand All @@ -1562,9 +1565,9 @@ <h2 id="name-issuance-protocol-for-priva">
<p id="section-5-1">The privately verifiable issuance protocol allows Clients to produce Token
values that verify using the Issuer Private Key. This protocol is based
on the oblivious pseudorandom function from <span>[<a href="#OPRF" class="cite xref">OPRF</a>]</span>.<a href="#section-5-1" class="pilcrow"></a></p>
<p id="section-5-2">Issuers provide a Private and Public Key, denoted <code>skI</code> and <code>pkI</code> respectively,
<p id="section-5-2">Issuers provide a Issuer Private and Public Key, denoted <code>skI</code> and <code>pkI</code> respectively,
used to produce tokens as input to the protocol. See <a href="#issuer-configuration" class="auto internal xref">Section 5.5</a>
for how this key pair is generated.<a href="#section-5-2" class="pilcrow"></a></p>
for how these keys are generated.<a href="#section-5-2" class="pilcrow"></a></p>
<p id="section-5-3">Clients provide the following as input to the issuance protocol:<a href="#section-5-3" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-5-4.1">Issuer Request URL: A URL identifying the location to which issuance requests
Expand Down Expand Up @@ -1796,9 +1799,9 @@ <h3 id="name-token-verification">
<h3 id="name-issuer-configuration">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-issuer-configuration" class="section-name selfRef">Issuer Configuration</a>
</h3>
<p id="section-5.5-1">Issuers are configured with Private and Public Key pairs, each denoted <code>skI</code>
<p id="section-5.5-1">Issuers are configured with Issuer Private and Public Keys, each denoted <code>skI</code>
and <code>pkI</code>, respectively, used to produce tokens. These keys MUST NOT be reused
in other protocols. A RECOMMENDED method for generating key pairs is as
in other protocols. A RECOMMENDED method for generating keys is as
follows:<a href="#section-5.5-1" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-5.5-2">
<pre>
Expand All @@ -1816,7 +1819,10 @@ <h3 id="name-issuer-configuration">
</div>
<p id="section-5.5-5">Since Clients truncate <code>token_key_id</code> in each <code>TokenRequest</code>, Issuers SHOULD
ensure that the truncated form of new key IDs do not collide with other
truncated key IDs in rotation.<a href="#section-5.5-5" class="pilcrow"></a></p>
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 the wrong Issuer Private Key.<a href="#section-5.5-5" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand All @@ -1839,9 +1845,9 @@ <h2 id="name-issuance-protocol-for-publi">
does not learn the Origin that requested the token during the issuance protocol.<a href="#section-6-2" class="pilcrow"></a></p>
<p id="section-6-3">Beyond this difference, the publicly verifiable issuance protocol variant is
nearly identical to the privately verifiable issuance protocol variant. In
particular, Issuers provide a Private and Public Key, denoted skI and pkI,
particular, Issuers provide an Issuer Private and Public Key, denoted skI and pkI,
respectively, used to produce tokens as input to the protocol. See
<a href="#public-issuer-configuration" class="auto internal xref">Section 6.5</a> for how this key pair is generated.<a href="#section-6-3" class="pilcrow"></a></p>
<a href="#public-issuer-configuration" class="auto internal xref">Section 6.5</a> for how these keys are generated.<a href="#section-6-3" class="pilcrow"></a></p>
<p id="section-6-4">Clients provide the following as input to the issuance protocol:<a href="#section-6-4" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-6-5.1">Issuer Request URL: A URL identifying the location to which issuance requests
Expand Down Expand Up @@ -2037,12 +2043,12 @@ <h3 id="name-token-verification-2">
<h3 id="name-issuer-configuration-2">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-issuer-configuration-2" class="section-name selfRef">Issuer Configuration</a>
</h3>
<p id="section-6.5-1">Issuers are configured with Private and Public Key pairs, each denoted skI and
pkI, respectively, used to produce tokens. Each key pair SHALL be generated
<p id="section-6.5-1">Issuers are configured with Issuer Private 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 <span>[<a href="#DSS" class="cite xref">DSS</a>]</span>.
These key pairs MUST NOT be reused in other protocols.<a href="#section-6.5-1" class="pilcrow"></a></p>
<p id="section-6.5-2">The key identifier for a keypair (skI, pkI), denoted <code>token_key_id</code>, is
computed as SHA256(encoded_key), where encoded_key is a DER-encoded
These keys MUST NOT be reused in other protocols.<a href="#section-6.5-1" class="pilcrow"></a></p>
<p id="section-6.5-2">The key identifier for an Issuer Private and Public Key (skI, pkI), denoted <code>token_key_id</code>,
is computed as SHA256(encoded_key), where encoded_key is a DER-encoded
SubjectPublicKeyInfo (SPKI) object carrying pkI. The SPKI object MUST use the
RSASSA-PSS OID <span>[<a href="#RFC5756" class="cite xref">RFC5756</a>]</span>, which specifies the hash algorithm and salt size.
The salt size MUST match the output size of the hash function associated with
Expand Down Expand Up @@ -2072,7 +2078,10 @@ <h3 id="name-issuer-configuration-2">
</div>
<p id="section-6.5-5">Since Clients truncate <code>token_key_id</code> in each <code>TokenRequest</code>, Issuers SHOULD
ensure that the truncated form of new key IDs do not collide with other
truncated key IDs in rotation.<a href="#section-6.5-5" class="pilcrow"></a></p>
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 the wrong Issuer Private Key.<a href="#section-6.5-5" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -2253,7 +2262,7 @@ <h4 id="name-application-private-token-i">
<dd class="break"></dd>
<dt id="section-8.3.1-1.7">Optional parameters:</dt>
<dd style="margin-left: 1.5em" id="section-8.3.1-1.8">
<p id="section-8.3.1-1.8.1">None<a href="#section-8.3.1-1.8.1" class="pilcrow"></a></p>
<p id="section-8.3.1-1.8.1">N/A<a href="#section-8.3.1-1.8.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-8.3.1-1.9">Encoding considerations:</dt>
Expand Down Expand Up @@ -2361,7 +2370,7 @@ <h4 id="name-application-private-token-r">
<dd class="break"></dd>
<dt id="section-8.3.2-1.7">Optional parameters:</dt>
<dd style="margin-left: 1.5em" id="section-8.3.2-1.8">
<p id="section-8.3.2-1.8.1">None<a href="#section-8.3.2-1.8.1" class="pilcrow"></a></p>
<p id="section-8.3.2-1.8.1">N/A<a href="#section-8.3.2-1.8.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-8.3.2-1.9">Encoding considerations:</dt>
Expand Down Expand Up @@ -2468,7 +2477,7 @@ <h4 id="name-application-private-token-re">
<dd class="break"></dd>
<dt id="section-8.3.3-1.7">Optional parameters:</dt>
<dd style="margin-left: 1.5em" id="section-8.3.3-1.8">
<p id="section-8.3.3-1.8.1">None<a href="#section-8.3.3-1.8.1" class="pilcrow"></a></p>
<p id="section-8.3.3-1.8.1">N/A<a href="#section-8.3.3-1.8.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-8.3.3-1.9">Encoding considerations:</dt>
Expand Down Expand Up @@ -2669,7 +2678,7 @@ <h3 id="name-issuance-protocol-1-voprfp-">
</h3>
<p id="appendix-B.1-1">The test vector below lists the following values:<a href="#appendix-B.1-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="appendix-B.1-2.1">skS: The Issuer private Key, serialized using SerializeScalar from
<li class="normal" id="appendix-B.1-2.1">skS: The Issuer Private Key, serialized using SerializeScalar from
<span><a href="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21#section-2.1" class="relref">Section 2.1</a> of [<a href="#OPRF" class="cite xref">OPRF</a>]</span> and represented as a hexadecimal string.<a href="#appendix-B.1-2.1" class="pilcrow"></a>
</li>
<li class="normal" id="appendix-B.1-2.2">pkS: The Issuer Public Key, serialized according to the encoding in <a href="#private-token-type" class="auto internal xref">Section 8.2.1</a>.<a href="#appendix-B.1-2.2" class="pilcrow"></a>
Expand Down
70 changes: 39 additions & 31 deletions draft-ietf-privacypass-protocol.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -245,10 +245,11 @@ Table of Contents
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. 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 verification
like this can help deal with Client clock skew.
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 verification like this can help deal with Client clock skew.

Altogether, the Issuer's directory could look like:

Expand Down Expand Up @@ -305,17 +306,18 @@ Table of Contents
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.
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 oblivious pseudorandom function from [OPRF].

Issuers provide a Private and Public Key, denoted skI and pkI
Issuers provide a Issuer Private and Public Key, denoted skI and pkI
respectively, used to produce tokens as input to the protocol. See
Section 5.5 for how this key pair is generated.
Section 5.5 for how these keys are generated.

Clients provide the following as input to the issuance protocol:

Expand Down Expand Up @@ -516,10 +518,10 @@ Table of Contents

5.5. Issuer Configuration

Issuers are configured with Private and Public Key pairs, each
Issuers are configured with Issuer Private 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 key pairs is as follows:
generating keys is as follows:

seed = random(Ns)
(skI, pkI) = DeriveKeyPair(seed, "PrivacyPass")
Expand All @@ -532,7 +534,10 @@ Table of Contents

Since Clients truncate token_key_id in each TokenRequest, Issuers
SHOULD ensure that the truncated form of new key IDs do not collide
with other truncated key IDs in rotation.
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 the wrong Issuer Private Key.

6. Issuance Protocol for Publicly Verifiable Tokens

Expand All @@ -553,10 +558,10 @@ Table of Contents

Beyond this difference, the publicly verifiable issuance protocol
variant is nearly identical to the privately verifiable issuance
protocol variant. In particular, Issuers provide a Private and
Public Key, denoted skI and pkI, respectively, used to produce tokens
as input to the protocol. See Section 6.5 for how this key pair is
generated.
protocol variant. In particular, Issuers provide an Issuer Private
and Public Key, denoted skI and pkI, respectively, used to produce
tokens as input to the protocol. See Section 6.5 for how these keys
are generated.

Clients provide the following as input to the issuance protocol:

Expand Down Expand Up @@ -722,19 +727,19 @@ Table of Contents

6.5. Issuer Configuration

Issuers are configured with Private and Public Key pairs, each
Issuers are configured with Issuer Private and Public Keys, each
denoted skI and pkI, respectively, used to produce tokens. Each key
pair SHALL be generated securely, for example as specified in FIPS
186-5 [DSS]. These key pairs MUST NOT be reused in other protocols.

The key identifier for a keypair (skI, pkI), denoted token_key_id, is
computed as SHA256(encoded_key), where encoded_key is a DER-encoded
SubjectPublicKeyInfo (SPKI) object carrying pkI. The SPKI object
MUST use the RSASSA-PSS OID [RFC5756], which specifies the hash
algorithm and salt size. The salt size MUST match the output size of
the hash function associated with the public key and token type. The
parameters field for the digest used in the mask generation function
and the digest being signed MUST be omitted.
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 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
carrying pkI. The SPKI object MUST use the RSASSA-PSS OID [RFC5756],
which specifies the hash algorithm and salt size. The salt size MUST
match the output size of the hash function associated with the public
key and token type. The parameters field for the digest used in the
mask generation function and the digest being signed MUST be omitted.

An example sequence of the SPKI object (in ASN.1 format) for a
2048-bit key is below:
Expand All @@ -758,7 +763,10 @@ Table of Contents

Since Clients truncate token_key_id in each TokenRequest, Issuers
SHOULD ensure that the truncated form of new key IDs do not collide
with other truncated key IDs in rotation.
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 the wrong Issuer Private Key.

7. Security considerations

Expand Down Expand Up @@ -878,7 +886,7 @@ Table of Contents
Type name: application
Subtype name: private-token-issuer-directory
Required parameters: N/A
Optional parameters: None
Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 4
Interoperability considerations: N/A
Expand All @@ -903,7 +911,7 @@ Table of Contents
Type name: application
Subtype name: private-token-request
Required parameters: N/A
Optional parameters: None
Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 7
Interoperability considerations: N/A
Expand All @@ -928,7 +936,7 @@ Table of Contents
Type name: application
Subtype name: private-token-response
Required parameters: N/A
Optional parameters: None
Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 7
Interoperability considerations: N/A
Expand Down Expand Up @@ -1063,7 +1071,7 @@ B.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384)

The test vector below lists the following values:

* skS: The Issuer private Key, serialized using SerializeScalar from
* skS: The Issuer Private Key, serialized using SerializeScalar from
Section 2.1 of [OPRF] and represented as a hexadecimal string.

* pkS: The Issuer Public Key, serialized according to the encoding
Expand Down
2 changes: 1 addition & 1 deletion index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -625,7 +625,7 @@ <h2>Preview for branch <a href="caw/lars-protocol">caw/lars-protocol</a></h2>
<tr>
<td><a href="caw/lars-protocol/draft-ietf-privacypass-protocol.html" class="html draft-ietf-privacypass-protocol" title="Privacy Pass Issuance Protocol (HTML)">Privacy Pass Issuance</a></td>
<td><a href="caw/lars-protocol/draft-ietf-privacypass-protocol.txt" class="txt draft-ietf-privacypass-protocol" title="Privacy Pass Issuance Protocol (Text)">plain text</a></td>
<td>same as main</td>
<td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ietf-wg-privacypass.github.io/base-drafts/draft-ietf-privacypass-protocol.txt&amp;url_2=https://ietf-wg-privacypass.github.io/base-drafts/caw/lars-protocol/draft-ietf-privacypass-protocol.txt" class="diff draft-ietf-privacypass-protocol">diff with main</a></td>
</tr>
<tr>
<td><a href="caw/lars-protocol/draft-ietf-privacypass-auth-scheme.html" class="html draft-ietf-privacypass-auth-scheme" title="The Privacy Pass HTTP Authentication Scheme (HTML)">Privacy Pass Authentication</a></td>
Expand Down

0 comments on commit 43296d1

Please sign in to comment.