Skip to content

Commit

Permalink
Script updating gh-pages from bfd536b. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Dec 19, 2023
1 parent 1034f60 commit f45abff
Show file tree
Hide file tree
Showing 8 changed files with 111 additions and 109 deletions.
44 changes: 22 additions & 22 deletions .../draft-ietf-privacypass-architecture.html → .../draft-ietf-privacypass-architecture.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,24 +16,24 @@
and recommendations for each deployment model that helps ensure the desired
security and privacy goals are fulfilled.
" name="description">
<meta content="xml2rfc 3.18.2" name="generator">
<meta content="xml2rfc 3.19.0" name="generator">
<meta content="Internet-Draft" name="keyword">
<meta content="draft-ietf-privacypass-architecture-latest" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.18.2
xml2rfc 3.19.0
Python 3.11.6
ConfigArgParse 1.5.3
ConfigArgParse 1.7
google-i18n-address 3.1.0
intervaltree 3.1.0
Jinja2 3.1.2
lxml 4.9.3
platformdirs 3.11.0
platformdirs 4.1.0
pycountry 22.3.5
PyYAML 6.0
PyYAML 6.0.1
requests 2.31.0
setuptools 67.7.2
setuptools 68.2.2
six 1.16.0
wcwidth 0.2.8
wcwidth 0.2.12
-->
<link href="draft-ietf-privacypass-architecture.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
Expand Down Expand Up @@ -1032,11 +1032,11 @@
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">Privacy Pass Architecture</td>
<td class="right">October 2023</td>
<td class="right">December 2023</td>
</tr></thead>
<tfoot><tr>
<td class="left">Davidson, et al.</td>
<td class="center">Expires 25 April 2024</td>
<td class="center">Expires 21 June 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1049,12 +1049,12 @@
<dd class="internet-draft">draft-ietf-privacypass-architecture-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-10-23" class="published">23 October 2023</time>
<time datetime="2023-12-19" class="published">19 December 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-04-25">25 April 2024</time></dd>
<dd class="expires"><time datetime="2024-06-21">21 June 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1101,7 +1101,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 25 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 21 June 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1679,8 +1679,8 @@ <h3 id="name-redemption-protocol">
<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span>, is an authorization protocol
wherein Clients present tokens to Origins for authorization. Normally,
redemption is preceded by a challenge, wherein the Origin challenges
Clients for a token with a TokenChallenge (<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.1" class="relref">Section 2.1</a></span>) and,
if possible, Clients present a valid Token (<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.2" class="relref">Section 2.2</a></span>)
Clients for a token with a TokenChallenge (<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.1" class="relref">Section 2.1</a></span>) and,
if possible, Clients present a valid Token (<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.2" class="relref">Section 2.2</a></span>)
in reaction to the challenge. This interaction is shown below.<a href="#section-3.4-1" class="pilcrow"></a></p>
<span id="name-challenge-and-redemption-pr"></span><div id="fig-redemption">
<figure id="figure-2">
Expand Down Expand Up @@ -1757,7 +1757,7 @@ <h3 id="name-redemption-protocol">
example, an empty redemption context always allows tokens to be issued and
redeemed non-interactively, whereas a fresh and random redemption context
means that the redeemed token must be issued only after the client receives
the challenge. See <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for more details.<a href="#section-3.4-6.3.1" class="pilcrow"></a></p>
the challenge. See <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for more details.<a href="#section-3.4-6.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.4-6.4">
<p id="section-3.4-6.4.1">Per-Origin or cross-Origin. Challenges can be constrained to the Origin for
Expand All @@ -1767,7 +1767,7 @@ <h3 id="name-redemption-protocol">
to as the cross-Origin set. Opting into this set is done by explicitly agreeing
on the contents of the set. Every Origin in a cross-Origin set, by opting in,
agrees to admit tokens for any other Origin in the set. See
<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for more information on how this set is created.<a href="#section-3.4-6.4.1" class="pilcrow"></a></p>
<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for more information on how this set is created.<a href="#section-3.4-6.4.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-3.4-7">Origins that admit cross-Origin tokens bear some risk of allowing tokens
Expand All @@ -1782,7 +1782,7 @@ <h3 id="name-redemption-protocol">
times for any such challenge. Note that Clients which redeem the
same token to multiple Origins do risk those Origins being able to link
Client activity together, which can disincentivize this behavior. See
<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for discussion.<a href="#section-3.4-7" class="pilcrow"></a></p>
<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for discussion.<a href="#section-3.4-7" class="pilcrow"></a></p>
<p id="section-3.4-8">How Clients respond to token challenges can have privacy implications.
For example, if an Origin allows the Client to choose an Issuer, then the choice
of Issuer can reveal information about the Client used to partition anonymity
Expand All @@ -1797,8 +1797,8 @@ <h3 id="name-issuance-protocol">
</h3>
<p id="section-3.5-1">The Privacy Pass issuance protocol, described in <span>[<a href="#ISSUANCE" class="cite xref">ISSUANCE</a>]</span>, is a two-message
protocol that takes as input a TokenChallenge from the redemption protocol
(<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.1" class="relref">Section 2.1</a></span>) and produces a Token
(<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.2" class="relref">Section 2.2</a></span>), as shown in <a href="#fig-overview" class="auto internal xref">Figure 1</a>.<a href="#section-3.5-1" class="pilcrow"></a></p>
(<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.1" class="relref">Section 2.1</a></span>) and produces a Token
(<span>[<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>], <a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.2" class="relref">Section 2.2</a></span>), as shown in <a href="#fig-overview" class="auto internal xref">Figure 1</a>.<a href="#section-3.5-1" class="pilcrow"></a></p>
<p id="section-3.5-2">The structure and semantics of the TokenRequest and TokenResponse messages
depend on the issuance protocol and token type being used; see <span>[<a href="#ISSUANCE" class="cite xref">ISSUANCE</a>]</span>
for more information.<a href="#section-3.5-2" class="pilcrow"></a></p>
Expand All @@ -1814,7 +1814,7 @@ <h3 id="name-issuance-protocol">
<p id="section-3.5-5">Clients initiate the issuance protocol using the token challenge, a randomly
generated nonce, and public key for the Issuer, all of which are the Client's
private input to the protocol and ultimately bound to an output Token;
see <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14#section-2.2" class="relref">Section 2.2</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for details. Future specifications
see <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15#section-2.2" class="relref">Section 2.2</a> of [<a href="#AUTHSCHEME" class="cite xref">AUTHSCHEME</a>]</span> for details. Future specifications
may change or extend the Client's input to the issuance protocol to produce
Tokens with a different structure.<a href="#section-3.5-5" class="pilcrow"></a></p>
<p id="section-3.5-6">Token properties vary based on the issuance protocol. Important properties
Expand Down Expand Up @@ -2615,7 +2615,7 @@ <h3 id="name-partitioning-by-issuance-me">
additional bits provides an exponential increase in tracking granularity
similarly to introducing more Issuers (though with more potential targeting).<a href="#section-6.1-1" class="pilcrow"></a></p>
<p id="section-6.1-2">For this reason, deployments should take the amount of metadata used by an Issuer
in creating redemption tokens must into account -- together with the bits
in creating redemption tokens into account -- together with the bits
of information that Issuers may learn about Clients otherwise. Since this
metadata may be useful for practical deployments of Privacy Pass, Issuers
must balance this against the reduction in Client privacy.<a href="#section-6.1-2" class="pilcrow"></a></p>
Expand Down Expand Up @@ -2757,7 +2757,7 @@ <h3 id="name-normative-references">
<dl class="references">
<dt id="AUTHSCHEME">[AUTHSCHEME]</dt>
<dd>
<span class="refAuthor">Pauly, T.</span>, <span class="refAuthor">Valdez, S.</span>, and <span class="refAuthor">C. A. Wood</span>, <span class="refTitle">"The Privacy Pass HTTP Authentication Scheme"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-privacypass-auth-scheme-14</span>, <time datetime="2023-09-25" class="refDate">25 September 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14">https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-14</a>&gt;</span>. </dd>
<span class="refAuthor">Pauly, T.</span>, <span class="refAuthor">Valdez, S.</span>, and <span class="refAuthor">C. A. Wood</span>, <span class="refTitle">"The Privacy Pass HTTP Authentication Scheme"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-privacypass-auth-scheme-15</span>, <time datetime="2023-10-23" class="refDate">23 October 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15">https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
<dd>
Expand Down
16 changes: 8 additions & 8 deletions ...5/draft-ietf-privacypass-architecture.txt → ...s/draft-ietf-privacypass-architecture.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@
Network Working Group A. Davidson
Internet-Draft LIP
Intended status: Informational J. Iyengar
Expires: 25 April 2024 Fastly
Expires: 21 June 2024 Fastly
C. A. Wood
Cloudflare
23 October 2023
19 December 2023


The Privacy Pass Architecture
Expand Down Expand Up @@ -39,7 +39,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 April 2024.
This Internet-Draft will expire on 21 June 2024.

Copyright Notice

Expand Down Expand Up @@ -1138,9 +1138,9 @@ Table of Contents
Issuers (though with more potential targeting).

For this reason, deployments should take the amount of metadata used
by an Issuer in creating redemption tokens must into account --
together with the bits of information that Issuers may learn about
Clients otherwise. Since this metadata may be useful for practical
by an Issuer in creating redemption tokens into account -- together
with the bits of information that Issuers may learn about Clients
otherwise. Since this metadata may be useful for practical
deployments of Privacy Pass, Issuers must balance this against the
reduction in Client privacy.

Expand Down Expand Up @@ -1269,9 +1269,9 @@ Table of Contents
[AUTHSCHEME]
Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
HTTP Authentication Scheme", Work in Progress, Internet-
Draft, draft-ietf-privacypass-auth-scheme-14, 25 September
Draft, draft-ietf-privacypass-auth-scheme-15, 23 October
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-auth-scheme-14>.
privacypass-auth-scheme-15>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
Expand Down
28 changes: 14 additions & 14 deletions ...5/draft-ietf-privacypass-auth-scheme.html → ...s/draft-ietf-privacypass-auth-scheme.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,26 +15,26 @@
to redeem Privacy Pass tokens with an origin. It can also be used by
origins to challenge clients to present Privacy Pass tokens.
" name="description">
<meta content="xml2rfc 3.18.2" name="generator">
<meta content="xml2rfc 3.19.0" name="generator">
<meta content="anonymous" name="keyword">
<meta content="authorization" name="keyword">
<meta content="crypto" name="keyword">
<meta content="draft-ietf-privacypass-auth-scheme-latest" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.18.2
xml2rfc 3.19.0
Python 3.11.6
ConfigArgParse 1.5.3
ConfigArgParse 1.7
google-i18n-address 3.1.0
intervaltree 3.1.0
Jinja2 3.1.2
lxml 4.9.3
platformdirs 3.11.0
platformdirs 4.1.0
pycountry 22.3.5
PyYAML 6.0
PyYAML 6.0.1
requests 2.31.0
setuptools 67.7.2
setuptools 68.2.2
six 1.16.0
wcwidth 0.2.8
wcwidth 0.2.12
-->
<link href="draft-ietf-privacypass-auth-scheme.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
Expand Down Expand Up @@ -1033,11 +1033,11 @@
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">Privacy Pass Authentication</td>
<td class="right">October 2023</td>
<td class="right">December 2023</td>
</tr></thead>
<tfoot><tr>
<td class="left">Pauly, et al.</td>
<td class="center">Expires 25 April 2024</td>
<td class="center">Expires 21 June 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1050,12 +1050,12 @@
<dd class="internet-draft">draft-ietf-privacypass-auth-scheme-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-10-23" class="published">23 October 2023</time>
<time datetime="2023-12-19" class="published">19 December 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Standards Track</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-04-25">25 April 2024</time></dd>
<dd class="expires"><time datetime="2024-06-21">21 June 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1101,7 +1101,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 25 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 21 June 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1915,7 +1915,7 @@ <h2 id="name-origin-behavior">
<h3 id="name-greasing">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-greasing" class="section-name selfRef">Greasing</a>
</h3>
<p id="section-4.1-1">In order to prevent clients becoming incompatible with new token challenges,
<p id="section-4.1-1">In order to prevent clients from becoming incompatible with new token challenges,
origins SHOULD include random token types, from the Reserved list of "greased"
types (defined in <a href="#token-types" class="auto internal xref">Section 6.2</a>), with some non-trivial probability.<a href="#section-4.1-1" class="pilcrow"></a></p>
<p id="section-4.1-2">Additionally, for deployments where tokens are not required (such as when tokens
Expand Down Expand Up @@ -2337,7 +2337,7 @@ <h3 id="name-informative-references">
<dl class="references">
<dt id="COOKIES">[COOKIES]</dt>
<dd>
<span class="refAuthor">Bingler, S.</span>, <span class="refAuthor">West, M.</span>, and <span class="refAuthor">J. Wilander</span>, <span class="refTitle">"Cookies: HTTP State Management Mechanism"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-rfc6265bis-12</span>, <time datetime="2023-05-10" class="refDate">10 May 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-12">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-12</a>&gt;</span>. </dd>
<span class="refAuthor">Bingler, S.</span>, <span class="refAuthor">West, M.</span>, and <span class="refAuthor">J. Wilander</span>, <span class="refTitle">"Cookies: HTTP State Management Mechanism"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-rfc6265bis-13</span>, <time datetime="2023-11-15" class="refDate">15 November 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-13">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ISSUANCE">[ISSUANCE]</dt>
<dd>
Expand Down
Loading

0 comments on commit f45abff

Please sign in to comment.