rfc9577.original.xml | rfc9577.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | ||||
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 3.1. 2) --> | <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 3.1. 2) --> | |||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | ||||
-ietf-privacypass-auth-scheme-15" category="std" consensus="true" tocInclude="tr | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | |||
ue" sortRefs="true" symRefs="true" version="3"> | -ietf-privacypass-auth-scheme-15" number="9577" submissionType="IETF" category=" | |||
std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates=" | ||||
" obsoletes="" xml:lang="en" version="3"> | ||||
<!-- xml2rfc v2v3 conversion 3.12.10 --> | <!-- xml2rfc v2v3 conversion 3.12.10 --> | |||
<front> | <front> | |||
<title abbrev="Privacy Pass Authentication">The Privacy Pass HTTP Authentica tion Scheme</title> | <title abbrev="Privacy Pass Authentication">The Privacy Pass HTTP Authentica tion Scheme</title> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-auth-scheme- 15"/> | <seriesInfo name="RFC" value="9577"/> | |||
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> | <author initials="T." surname="Pauly" fullname="Tommy Pauly"> | |||
<organization>Apple Inc.</organization> | <organization>Apple Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>One Apple Park Way</street> | <street>One Apple Park Way</street> | |||
<city>Cupertino, California 95014</city> | <city>Cupertino</city> | |||
<country>United States of America</country> | <region>California</region> | |||
<code>95014</code> | ||||
<country>United States of America</country> | ||||
</postal> | </postal> | |||
<email>tpauly@apple.com</email> | <email>tpauly@apple.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="S." surname="Valdez" fullname="Steven Valdez"> | <author initials="S." surname="Valdez" fullname="Steven Valdez"> | |||
<organization>Google LLC</organization> | <organization>Google LLC</organization> | |||
<address> | <address> | |||
<email>svaldez@chromium.org</email> | <email>svaldez@chromium.org</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> | <author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> | |||
<organization>Cloudflare</organization> | <organization>Cloudflare</organization> | |||
<address> | <address> | |||
<email>caw@heapingbits.net</email> | <email>caw@heapingbits.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2023" month="October" day="23"/> | <date year="2024" month="May"/> | |||
<area>sec</area> | ||||
<workgroup>privacypass</workgroup> | ||||
<keyword>anonymous</keyword> | <keyword>anonymous</keyword> | |||
<keyword>authorization</keyword> | <keyword>authorization</keyword> | |||
<keyword>crypto</keyword> | <keyword>crypto</keyword> | |||
<abstract> | <abstract> | |||
<t>This document defines an HTTP authentication scheme for Privacy Pass, | <t>This document defines an HTTP authentication scheme for Privacy Pass, | |||
a privacy-preserving authentication mechanism used for authorization. | a privacy-preserving authentication mechanism used for authorization. | |||
The authentication scheme in this document can be used by clients | The authentication scheme specified in this document can be used by clients | |||
to redeem Privacy Pass tokens with an origin. It can also be used by | to redeem Privacy Pass tokens with an origin. It can also be used by | |||
origins to challenge clients to present Privacy Pass tokens.</t> | origins to challenge clients to present Privacy Pass tokens.</t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="introduction"> | <section anchor="introduction"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>Privacy Pass tokens are unlinkable authenticators that can be used to | <t>Privacy Pass tokens are unlinkable authenticators that can be used to | |||
anonymously authorize a client (see | anonymously authorize a client (see | |||
<xref target="ARCHITECTURE"/>). | <xref target="RFC9576"/>). | |||
Tokens are generated by token issuers, on the basis of authentication, | Tokens are generated by token issuers, on the basis of authentication, | |||
attestation, or some previous action such as solving a CAPTCHA. A client | attestation, or some previous action such as solving a CAPTCHA. A client | |||
possessing such a token is able to prove that it was able to get a token | possessing such a token is able to prove that it was able to get a token | |||
issued, without allowing the relying party redeeming the client's token | issued, without allowing the relying party redeeming the client's token | |||
(the origin) to link it with the issuance flow.</t> | (the origin) to link it with the issuance flow.</t> | |||
<t>Different types of authenticators, using different token issuance proto cols, | <t>Different types of authenticators, using different token issuance proto cols, | |||
can be used as Privacy Pass tokens.</t> | can be used as Privacy Pass tokens.</t> | |||
<t>This document defines a common HTTP authentication scheme | <t>This document defines a common HTTP authentication scheme | |||
(<xref section="11" sectionFormat="comma" target="RFC9110"/>), PrivateToken, tha t allows clients to redeem various | (<xref section="11" sectionFormat="comma" target="RFC9110"/>), PrivateToken, tha t allows clients to redeem various | |||
kinds of Privacy Pass tokens.</t> | kinds of Privacy Pass tokens.</t> | |||
<t>Clients and relying parties (origins) interact using this scheme to per form the | <t>Clients and relying parties (origins) interact using this scheme to per form the | |||
token challenge and token redemption flow. In particular, origins challenge | token challenge and token redemption flow. In particular, origins challenge | |||
clients for a token with an HTTP Authentication challenge (using the | clients for a token with an HTTP Authentication challenge (using the | |||
WWW-Authenticate response header field). Clients can then react to that | WWW-Authenticate response header field). Clients can then react to that | |||
challenge by issuing a new request with a corresponding token (using the Authori zation | challenge by issuing a new request with a corresponding token (using the Authori zation | |||
request header field). Clients generate tokens that match the origin's token | request header field). Clients generate tokens that match the origin's token | |||
challenge by running the token issuance protocol | challenge by running the token issuance protocol | |||
<xref target="ISSUANCE"/>. The act of presenting a token in an | <xref target="RFC9578"/>. The act of presenting a token in an | |||
Authorization request header field is referred to as token redemption. This | Authorization request header field is referred to as "token redemption". This | |||
interaction between client and origin is shown below.</t> | interaction between the client and origin is shown below.</t> | |||
<!-- [rfced] Please review each artwork element. Specifically, | ||||
should any of the artwork elements (e.g., the test-vector data in | ||||
Appendix A) be tagged as sourcecode? | ||||
Please see <https://www.rfc-editor.org/materials/sourcecode-types.txt>. | ||||
If the current list of preferred values for "type" does not contain | ||||
an applicable type, please let us know. Also, it is acceptable to | ||||
leave the "type" attribute not set. --> | ||||
<!-- [rfced] The SVG figures in this document have width or height | ||||
specified, which will make the artwork not scale. Please consider | ||||
whether scaling should be enabled. Scaling will allow the figures to | ||||
be resized when viewed on a mobile device; however, there may be | ||||
aesthetic trade-offs (e.g., a given image may appear too large on a | ||||
desktop screen, or different figures may scale differently based on | ||||
their relative sizes). Please review the HTML and PDF outputs, | ||||
noting that we will need you to update the edited copy of the XML and | ||||
specify the viewBox item where appropriate. | ||||
The warning: | ||||
Warning: Found SVG with width or height specified, which will make the | ||||
artwork not scale. Specify a viewBox only to let the artwork scale. --> | ||||
<figure anchor="fig-overview"> | <figure anchor="fig-overview"> | |||
<name>Challenge and redemption protocol flow</name> | <name>Challenge and Redemption Protocol Flow</name> | |||
<artset> | <artset> | |||
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="192" width="456" viewBox="0 0 456 192" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px" stroke-linecap="round"> | <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="192" width="456" viewBox="0 0 456 192" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px" stroke-linecap="round"> | |||
<path d="M 8,32 L 8,64" fill="none" stroke="black"/> | <path d="M 8,32 L 8,64" fill="none" stroke="black"/> | |||
<path d="M 40,64 L 40,176" fill="none" stroke="black"/> | <path d="M 40,64 L 40,176" fill="none" stroke="black"/> | |||
<path d="M 80,32 L 80,64" fill="none" stroke="black"/> | <path d="M 80,32 L 80,64" fill="none" stroke="black"/> | |||
<path d="M 328,32 L 328,64" fill="none" stroke="black"/> | <path d="M 328,32 L 328,64" fill="none" stroke="black"/> | |||
<path d="M 360,64 L 360,112" fill="none" stroke="black"/> | <path d="M 360,64 L 360,112" fill="none" stroke="black"/> | |||
<path d="M 360,144 L 360,176" fill="none" stroke="black"/> | <path d="M 360,144 L 360,176" fill="none" stroke="black"/> | |||
<path d="M 400,32 L 400,64" fill="none" stroke="black"/> | <path d="M 400,32 L 400,64" fill="none" stroke="black"/> | |||
<path d="M 8,32 L 80,32" fill="none" stroke="black"/> | <path d="M 8,32 L 80,32" fill="none" stroke="black"/> | |||
skipping to change at line 125 ¶ | skipping to change at line 156 ¶ | |||
+-- WWW-Authenticate: TokenChallenge -->| | +-- WWW-Authenticate: TokenChallenge -->| | |||
| | | | | | |||
| (Run issuance protocol) | | (Run issuance protocol) | |||
| | | | | | |||
|<------ Authorization: Token ----------+ | |<------ Authorization: Token ----------+ | |||
| | | | | | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
<t>In addition to working with different token issuance protocols, this sc heme | <t>In addition to working with different token issuance protocols, this sc heme | |||
optionally supports use of tokens that are associated with origin-chosen | optionally supports the use of tokens that are associated with origin-chosen | |||
contexts and specific origin names. Relying parties that request and redeem | contexts and specific origin names. Relying parties that request and redeem | |||
tokens can choose a specific kind of token, as appropriate for its use case. | tokens can choose a specific kind of token, as appropriate for its use case. | |||
These options allow for different deployment models to prevent double-spending, | These options allow for different deployment models to prevent double-spending, | |||
and allow for both interactive (online challenges) and non-interactive | and allow for both interactive (online challenges) and non-interactive | |||
(pre-fetched) tokens.</t> | (pre-fetched) tokens. | |||
<!-- [rfced] Section 1: Does "and allow for" refer to the options or | ||||
the deployment models? | ||||
Original: | ||||
These options allow for different | ||||
deployment models to prevent double-spending, and allow for both | ||||
interactive (online challenges) and non-interactive (pre-fetched) | ||||
tokens. | ||||
Perhaps (the options): | ||||
These options (1) allow for different | ||||
deployment models to prevent double-spending and (2) allow for both | ||||
interactive (online challenges) and non-interactive (pre-fetched) | ||||
tokens. | ||||
Or possibly (the deployment models): | ||||
These options allow for different | ||||
deployment models to (1) prevent double-spending and (2) allow for | ||||
both interactive (online challenges) and non-interactive | ||||
(pre-fetched) tokens. --> | ||||
</t> | ||||
<section anchor="terminology"> | <section anchor="terminology"> | |||
<name>Terminology</name> | <name>Terminology</name> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", | |||
"MAY", and "OPTIONAL" in this document are to be interpreted as | "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and | "<bcp14>SHOULD NOT</bcp14>", | |||
only when, they | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
appear in all capitals, as shown here.</t> | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document | |||
are to be interpreted as described in BCP 14 | ||||
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only | ||||
when, they appear in all capitals, as shown here.</t> | ||||
<t>Unless otherwise specified, this document encodes protocol messages i n TLS | <t>Unless otherwise specified, this document encodes protocol messages i n TLS | |||
notation from <xref target="TLS13"/>, Section 3.</t> | notation from | |||
<t>This document uses the terms "Client", "Origin", "Issuer", "Issuance | <xref target="RFC8446" sectionFormat="comma" section="3"/>.</t> | |||
Protocol", | <t>This document uses the terms "Client", "Origin", "Issuer", "issuance | |||
and "Token" as defined in <xref target="ARCHITECTURE"/>. It additionally | protocol", | |||
and "Token" as defined in <xref target="RFC9576"/>. It additionally | ||||
uses the following terms in more specific ways:</t> | uses the following terms in more specific ways:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Issuer key: Keying material that can be used with an issuance prot | <dt>Issuer key:</dt><dd>Keying material that can be used with an issua | |||
ocol | nce protocol | |||
to create a signed token.</li> | to create a signed token.</dd> | |||
<li>Token challenge: A request for tokens sent from an origin to a cli | <dt>Token challenge:</dt><dd>A request for tokens sent from an origin | |||
ent, using | to a client, using | |||
the "WWW-Authenticate" HTTP header field. This challenge identifies a specific | the "WWW-Authenticate" HTTP header field. This challenge identifies a specific | |||
token issuer and issuance protocol. Token challenges optionally include | token issuer and issuance protocol. Token challenges optionally include | |||
one or both of: a redemption context (see <xref target="context-construction"/>) | one or both of the following: a redemption context (see <xref target="context-co | |||
, and | nstruction"/>) and | |||
a list of associated origins. These optional values are then | a list of associated origins. These optional values can then | |||
be bound to the token that is issued.</li> | be bound to the token that is issued.</dd> | |||
<li>Token redemption: An action by which a client presents a token to | <dt>Token redemption:</dt><dd>An action by which a client presents a t | |||
an origin | oken to an origin | |||
in an HTTP request, using the "Authorization" HTTP header field.</li> | in an HTTP request, using the "Authorization" HTTP header field.</dd> | |||
</ul> | </dl> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="challenge-redemption"> | <section anchor="challenge-redemption"> | |||
<name>HTTP Authentication Scheme</name> | <name>HTTP Authentication Scheme</name> | |||
<t>Token redemption is performed using HTTP Authentication | <t>Token redemption is performed using HTTP Authentication | |||
(<xref section="11" sectionFormat="comma" target="RFC9110"/>), with the scheme " PrivateToken". Origins challenge | (<xref section="11" sectionFormat="comma" target="RFC9110"/>), with the scheme " PrivateToken". Origins challenge | |||
clients to present a token from a specific issuer (<xref target="challenge"/>). Once a | clients to present a token from a specific issuer (<xref target="challenge"/>). Once a | |||
client has received a token from that issuer, or already has a valid token | client has received a token from that issuer or already has a valid token | |||
available, it presents the token to the origin (<xref target="redemption"/>). Th e process of | available, it presents the token to the origin (<xref target="redemption"/>). Th e process of | |||
presenting a token as authentication to an origin is also referred to | presenting a token as authentication to an origin is also referred to | |||
as "spending" a token.</t> | as "spending" a token.</t> | |||
<t>In order to prevent linkability across different transactions, clients | <t>In order to prevent linkability across different transactions, clients | |||
will often present a particular "PrivateToken" only once. Origins can link multi ple | will often present a particular "PrivateToken" only once. Origins can link multi ple | |||
transactions to the same client if that client spends the same token value more | transactions to the same client if that client spends the same token value more | |||
than once. As such, origins ought to expect at most one unique token | than once. As such, origins ought to expect at most one unique token | |||
value, carried in one request, for each challenge.</t> | value, carried in one request, for each challenge.</t> | |||
<t>The rest of this section describes the token challenge and redemption i nteractions | <t>The rest of this section describes the token challenge and redemption i nteractions | |||
in more detail.</t> | in more detail.</t> | |||
<section anchor="challenge"> | <section anchor="challenge"> | |||
<name>Token Challenge</name> | <name>Token Challenge</name> | |||
<t>Origins send a token challenge to clients in an "WWW-Authenticate" he ader field | <t>Origins send a token challenge to clients in a "WWW-Authenticate" hea der field | |||
with the "PrivateToken" scheme. This authentication scheme has two mandatory par ameters: | with the "PrivateToken" scheme. This authentication scheme has two mandatory par ameters: | |||
one containing a token challenge and another containing the token-key used for | one containing a token challenge and another containing the token-key used for | |||
producing (and verifying) a corresponding token.</t> | producing (and verifying) a corresponding token.</t> | |||
<t>Origins that support the "PrivateToken" authentication scheme need to handle | <t>Origins that support the "PrivateToken" authentication scheme need to handle | |||
the following tasks in constructing the WWW-Authenticate header field:</t> | the following tasks in constructing the WWW-Authenticate header field:</t> | |||
<ol spacing="normal" type="1"><li>Select which issuer to use, and config ure the issuer name and token-key to | <ol spacing="normal" type="1"><li>Select which issuer to use, and config ure the issuer name and token-key to | |||
include in WWW-Authenticate token challenges. The issuer name is included in | include in WWW-Authenticate token challenges. The issuer name is included in | |||
the token challenge, and the issuer token-key is used to populate the | the token challenge, and the issuer token-key is used to populate the | |||
WWW-Authenticate header parameter.</li> | WWW-Authenticate header parameter.</li> | |||
<li>Determine a redemption context construction to include in the | <li>Determine a redemption context construction to include in the | |||
token challenge, as discussed in <xref target="context-construction"/>.</li> | token challenge, as discussed in <xref target="context-construction"/>.</li> | |||
<li>Select the origin information to include in the token challenge. T his can | <li>Select the origin information to include in the token challenge. T his can | |||
be empty to allow fully cross-origin tokens, a single origin name that | be empty to allow fully cross-origin tokens, a single origin name that | |||
matches the origin itself for per-origin tokens, or a list of origin names | matches the origin itself for per-origin tokens, or a list of origin names | |||
containing the origin itself. See <xref section="3.4" sectionFormat="of" target= "ARCHITECTURE"/> for more | containing the origin itself. See <xref section="3.4" sectionFormat="of" target= "RFC9576"/> for more | |||
information about the difference between cross-origin and per-origin tokens.</li > | information about the difference between cross-origin and per-origin tokens.</li > | |||
</ol> | </ol> | |||
<t>Once these decisions are made, origins construct the WWW-Authenticate header | <t>Once these decisions are made, origins construct the WWW-Authenticate header | |||
by first constructing the token challenge as described in <xref target="challeng e-structure"/>. | by first constructing the token challenge as described in <xref target="challeng e-structure"/>. | |||
Origins send challenges as described in <xref target="send-challenge"/>, and cli ents process | Origins send challenges as described in <xref target="send-challenge"/>, and cli ents process | |||
them as described in <xref target="process-challenge"/> and <xref target="cachin g"/>.</t> | them as described in Sections <xref target="process-challenge" format="coun ter"/> and <xref target="caching" format="counter"/>.</t> | |||
<section anchor="challenge-structure"> | <section anchor="challenge-structure"> | |||
<name>Token Challenge Structure</name> | <name>Token Challenge Structure</name> | |||
<t>This document defines the default challenge structure that can be u sed across | <t>This document defines the default challenge structure that can be u sed across | |||
token types, although future token types MAY extend or modify the structure | token types, although future token types <bcp14>MAY</bcp14> extend or modify the structure | |||
of the challenge; see <xref target="token-types"/> for the registry information | of the challenge; see <xref target="token-types"/> for the registry information | |||
which establishes and defines the relationship between "token_type" and the | that establishes and defines the relationship between "token_type" and the | |||
contents of the TokenChallenge message.</t> | contents of the TokenChallenge message.</t> | |||
<t>All token challenges MUST begin with a 2-octet integer that defines the | <t>All token challenges <bcp14>MUST</bcp14> begin with a 2-octet integ er that defines the | |||
token type, in network byte order. This type indicates the issuance protocol | token type, in network byte order. This type indicates the issuance protocol | |||
used to generate the token and determines the structure and semantics of the res t of | used to generate the token and determines the structure and semantics of the res t of | |||
the structure. Values are registered in an IANA registry, <xref target="token-ty pes"/>. Client MUST | the structure. Values are registered in an IANA registry; see <xref target="toke n-types"/>. Clients <bcp14>MUST</bcp14> | |||
ignore challenges with token types they do not support.</t> | ignore challenges with token types they do not support.</t> | |||
<t>Even when a given token type uses the default challenge structure, | <t>Even when a given token type uses the default challenge structure, | |||
the requirements on the presence or interpretation of the fields can differ | the requirements on the presence or interpretation of the fields can differ | |||
across token types. For example, some token types might require that "origin_inf o" | across token types. For example, some token types might require that "origin_inf o" | |||
is non-empty, while others allow it to be empty.</t> | is non-empty, while others allow it to be empty.</t> | |||
<t>The default TokenChallenge message has the following structure:</t> | <t>The default TokenChallenge message has the following structure:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type; | uint16_t token_type; | |||
opaque issuer_name<1..2^16-1>; | opaque issuer_name<1..2^16-1>; | |||
opaque redemption_context<0..32>; | opaque redemption_context<0..32>; | |||
opaque origin_info<0..2^16-1>; | opaque origin_info<0..2^16-1>; | |||
} TokenChallenge; | } TokenChallenge; | |||
]]></artwork> | ]]></artwork> | |||
<t>The structure fields are defined as follows:</t> | <t>The structure fields are defined as follows:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>"token_type" is a 2-octet integer, in network byte order, as des cribed | <li>"token_type" is a 2-octet integer, in network byte order, as des cribed | |||
above.</li> | above.</li> | |||
<li>"issuer_name" is an ASCII string that identifies the issuer usin | <li>"issuer_name" is an ASCII string that identifies the issuer, usi | |||
g the format of a | ng the format of a | |||
server name defined in <xref target="server-name"/>. This name identifies the is | server name as defined in <xref target="server-name"/>. This name identifies the | |||
suer that is allowed to | issuer that is allowed to | |||
issue tokens that can be redeemed by this origin. The field that stores this str ing in the challenge | issue tokens that can be redeemed by this origin. The field that stores this str ing in the challenge | |||
is prefixed with a 2-octet integer indicating the length, in network byte order. </li> | is prefixed with a 2-octet integer indicating the length, in network byte order. </li> | |||
<li>"redemption_context" is a field that is either 0 or 32 bytes, pr efixed with a single | <li>"redemption_context" is a field that is either 0 or 32 bytes, pr efixed with a single | |||
octet indicating the length (either 0 or 32). If value is non-empty, it is a 32- byte value | octet indicating the length (either 0 or 32). If the value is non-empty, it is a 32-byte value | |||
generated by the origin that allows the origin to require that clients fetch tok ens | generated by the origin that allows the origin to require that clients fetch tok ens | |||
bound to a specific context, as opposed to reusing tokens that were fetched for other | bound to a specific context, as opposed to reusing tokens that were fetched for other | |||
contexts. See <xref target="context-construction"/> for example contexts that mi ght be useful in | contexts. See <xref target="context-construction"/> for example contexts that mi ght be useful in | |||
practice. Challenges with redemption_context values of invalid lengths MUST be i | practice. Challenges with redemption_context values of invalid lengths <bcp14>MU | |||
gnored.</li> | ST</bcp14> be ignored.</li> | |||
<li>"origin_info" is an ASCII string that is either empty, or contai | <li>"origin_info" is an ASCII string that either is empty or contain | |||
ns one or more | s one or more | |||
origin names that allow a token to be scoped to a specific set of origins. Each | origin names that allow a token to be scoped to a specific set of origins. Each | |||
origin name uses the format of a server name defined in <xref target="server-nam e"/>. The string | origin name uses the format of a server name as defined in <xref target="server- name"/>. The string | |||
is prefixed with a 2-octet integer indicating the length, in network byte order. | is prefixed with a 2-octet integer indicating the length, in network byte order. | |||
If empty, any non-origin-specific token can be redeemed. If the string contains | If empty, any non-origin-specific token can be redeemed. If the string contains | |||
multiple origin names, they are delimited with commas "," without any whitespace | multiple origin names, they are delimited with commas (",") without any whitespa | |||
. | ce. | |||
If this field is not empty, the Origin MUST include its own name as one of the | If this field is not empty, the Origin <bcp14>MUST</bcp14> include its own name | |||
as one of the | ||||
names in the list.</li> | names in the list.</li> | |||
</ul> | </ul> | |||
<t>If "origin_info" contains multiple origin names, this means the cha llenge is valid | <t>If "origin_info" contains multiple origin names, this means the cha llenge is valid | |||
for any of the origins in the list, including the origin which issued the challe nge | for any of the origins in the list, including the origin that issued the challen ge | |||
(which must always be present in the list if it is non-empty; see <xref target=" process-challenge"/>). | (which must always be present in the list if it is non-empty; see <xref target=" process-challenge"/>). | |||
This can be useful in settings where clients pre-fetch and cache tokens for a pa rticular | This can be useful in settings where clients pre-fetch and cache tokens for a pa rticular | |||
challenge -- including the "origin_info" field -- and then later redeem these to kens | challenge -- including the "origin_info" field -- and then later redeem these to kens | |||
with one of the origins in the list. See <xref target="caching"/> for more discu ssion about | with one of the origins in the list. See <xref target="caching"/> for more discu ssion about | |||
token caching.</t> | token caching.</t> | |||
<section anchor="server-name"> | <section anchor="server-name"> | |||
<name>Server Name Encoding</name> | <name>Server Name Encoding</name> | |||
<t>Server names contained in a token challenge are ASCII strings tha t contain a hostname | <t>Server names contained in a token challenge are ASCII strings tha t contain a hostname | |||
and optional port, where the port is implied to be "443" if missing. The names u se the | and optional port, where the port is implied to be "443" if missing. The names u se the | |||
format of the authority portion of a URI as defined in <xref section="3.2" secti | format of the authority portion of a URI as defined in <xref section="3.2" secti | |||
onFormat="of" target="URI"/>. | onFormat="of" target="RFC3986"/>. | |||
The names MUST NOT include a "userinfo" portion of an authority. For example, a | The names <bcp14>MUST NOT</bcp14> include a "userinfo" portion of an authority. | |||
valid | For example, a valid | |||
server name might be "issuer.example.com" or "issuer.example.com:8443", | server name might be "issuer.example.com" or "issuer.example.com:8443", | |||
but not "issuer@example.com".</t> | but not "issuer@example.com".</t> | |||
</section> | </section> | |||
<section anchor="context-construction"> | <section anchor="context-construction"> | |||
<name>Redemption Context Construction</name> | <name>Redemption Context Construction</name> | |||
<t>The TokenChallenge redemption context allows the origin to determ ine the | <t>The TokenChallenge redemption context allows the origin to determ ine the | |||
context in which a given token can be redeemed. This value can be a unique | context in which a given token can be redeemed. This value can be a unique | |||
per-request nonce, constructed from 32 freshly generated random bytes. It | per-request nonce, constructed from 32 freshly generated random bytes. It | |||
can also represent state or properties of the client session. Some example | can also represent state or properties of the client session. Some example | |||
properties and methods for constructing the corresponding context are below. | properties and methods for constructing the corresponding context are below. | |||
This list is not exhaustive.</t> | This list is not exhaustive.</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Context bound to a given time window: Construct redemption con | <dt>Context bound to a given time window:</dt><dd>Construct the re | |||
text as | demption context as | |||
F(current time window), where F is a pseudorandom function.</li> | F(current time window), where F is a pseudorandom function.</dd> | |||
<li>Context bound to a client network: Construct redemption contex | <dt>Context bound to a client network:</dt><dd>Construct the redem | |||
t as | ption context as | |||
F(client ASN), where F is a pseudorandom function.</li> | F(client ASN), where F is a pseudorandom function.</dd> | |||
<li>Context bound to a given time window and client network: Const | <dt>Context bound to a given time window and client network:</dt>< | |||
ruct redemption | dd>Construct the redemption | |||
context as F(current time window, client ASN), where F is a pseudorandom functio | context as F(current time window, client ASN), where F is a pseudorandom functio | |||
n.</li> | n.</dd> | |||
</ul> | ||||
<t>Preventing double spending on tokens requires the origin to keep | <!-- [rfced] Section 2.1.1.2: Is the "ASN" in "client ASN" an | |||
state | abbreviation? If yes, should it be defined for readers (perhaps | |||
"Autonomous System Number")? | ||||
Original: | ||||
* Context bound to a client network: Construct redemption context as | ||||
F(client ASN), where F is a pseudorandom function. | ||||
* Context bound to a given time window and client network: Construct | ||||
redemption context as F(current time window, client ASN), where F | ||||
is a pseudorandom function. --> | ||||
</dl> | ||||
<t>Preventing double-spending on tokens requires the origin to keep | ||||
state | ||||
associated with the redemption context. An empty redemption context is not | associated with the redemption context. An empty redemption context is not | |||
bound to any property of the client request, so state to prevent double spending | bound to any property of the client request, so state to prevent double-spending | |||
needs to be stored and shared across all origin servers that can accept tokens u ntil | needs to be stored and shared across all origin servers that can accept tokens u ntil | |||
token-key expiration or rotation. For a non-empty redemption context, the | token-key expiration or rotation. For a non-empty redemption context, the | |||
double spend state only needs to be stored across the set of origin servers that will | double-spend state only needs to be stored across the set of origin servers that will | |||
accept tokens with that redemption context.</t> | accept tokens with that redemption context.</t> | |||
<t>Origins that share redemption contexts, i.e., by using the same r edemption | <t>Origins that share redemption contexts, i.e., by using the same r edemption | |||
context, choosing the same issuer, and providing the same origin_info field in | context, choosing the same issuer, and providing the same origin_info field in | |||
the TokenChallenge, must necessarily share state required to enforce double | the TokenChallenge, must necessarily share state required to enforce | |||
spend prevention. Origins should consider the operational complexity of this | double-spend prevention. Origins should consider the operational complexity of t | |||
his | ||||
shared state before choosing to share redemption contexts. Failure to | shared state before choosing to share redemption contexts. Failure to | |||
successfully synchronize this state and use it for double spend prevention can | successfully synchronize this state and use it for double-spend prevention can | |||
allow Clients to redeem tokens to one Origin that were issued after an | allow Clients to redeem tokens to one Origin that were issued after an | |||
interaction with another Origin that shares the context.</t> | interaction with another Origin that shares the context.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="send-challenge"> | <section anchor="send-challenge"> | |||
<name>Sending Token Challenges</name> | <name>Sending Token Challenges</name> | |||
<t>When used in an authentication challenge, the "PrivateToken" scheme uses the | <t>When used in an authentication challenge, the "PrivateToken" scheme uses the | |||
following parameters:</t> | following parameters:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>"challenge", which contains a base64url-encoded <xref target="RF | <li>"challenge", which contains a base64url TokenChallenge value, en | |||
C4648"/> TokenChallenge | coded per <xref target="RFC4648"/>. This document follows the default padding be | |||
value. This document follows the default padding behavior described in | havior described in | |||
<xref section="3.2" sectionFormat="of" target="RFC4648"/>, so the base64url valu | <xref section="3.2" sectionFormat="of" target="RFC4648"/>, so the base64url valu | |||
e MUST include padding. | e <bcp14>MUST</bcp14> include padding. | |||
As an Authentication Parameter (<tt>auth-param</tt> from <xref section="11.2" se | As an authentication parameter (<tt>auth-param</tt> from <xref section="11.2" se | |||
ctionFormat="comma" target="RFC9110"/>), | ctionFormat="comma" target="RFC9110"/>), | |||
the value can be either a token or a quoted-string, and might be required to | the value can be either a token or a quoted-string and might be required to | |||
be a quoted-string if the base64url string includes "=" characters. This | be a quoted-string if the base64url string includes "=" characters. This | |||
parameter is required for all challenges.</li> | parameter is required for all challenges.</li> | |||
<li>"token-key", which contains a base64url encoding of the public k ey for | <li>"token-key", which contains a base64url encoding of the public k ey for | |||
use with the issuance protocol indicated by the challenge. See <xref target="ISS UANCE"/> | use with the issuance protocol indicated by the challenge. See <xref target="RFC 9578"/> | |||
for more information about how this public key is used by the issuance protocols | for more information about how this public key is used by the issuance protocols | |||
in that specification. The encoding of | described in that specification. The encoding of | |||
the public key is determined by the token type; see <xref target="token-types"/> . | the public key is determined by the token type; see <xref target="token-types"/> . | |||
As with "challenge", the base64url value MUST include padding. As an | As with "challenge", the base64url value <bcp14>MUST</bcp14> include padding. As | |||
Authentication Parameter (<tt>auth-param</tt> from <xref section="11.2" sectionF | an | |||
ormat="comma" target="RFC9110"/>), the | authentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionF | |||
value can be either a token or a quoted-string, and might be required to be a | ormat="comma" target="RFC9110"/>), the | |||
value can be either a token or a quoted-string and might be required to be a | ||||
quoted-string if the base64url string includes "=" characters. This parameter | quoted-string if the base64url string includes "=" characters. This parameter | |||
MAY be omitted in deployments where clients are able to retrieve the issuer key | <bcp14>MAY</bcp14> be omitted in deployments where clients are able to retrieve the issuer key | |||
using an out-of-band mechanism.</li> | using an out-of-band mechanism.</li> | |||
<li>"max-age", an optional parameter that consists of the number of seconds for | <li>"max-age", which is an optional parameter that consists of the n umber of seconds for | |||
which the challenge will be accepted by the origin.</li> | which the challenge will be accepted by the origin.</li> | |||
</ul> | </ul> | |||
<t>The header field MAY also include the standard "realm" parameter, i | <t>The header field <bcp14>MAY</bcp14> also include the standard "real | |||
f desired. | m" parameter, if desired. | |||
Issuance protocols MAY define other parameters, some of which might be required. | Issuance protocols <bcp14>MAY</bcp14> define other parameters, some of which mig | |||
Clients MUST ignore parameters in challenges that are not defined for the issuan | ht be required. | |||
ce | Clients <bcp14>MUST</bcp14> ignore parameters in challenges that are not defined | |||
for the issuance | ||||
protocol corresponding to the token type in the challenge.</t> | protocol corresponding to the token type in the challenge.</t> | |||
<t>As an example, the WWW-Authenticate header field could look like th is:</t> | <t>As an example, the WWW-Authenticate header field could look like th is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
WWW-Authenticate: | WWW-Authenticate: | |||
PrivateToken challenge="abc...", token-key="123..." | PrivateToken challenge="abc...", token-key="123..." | |||
]]></artwork> | ]]></artwork> | |||
<section anchor="sending-multiple-token-challenges"> | <section anchor="sending-multiple-token-challenges"> | |||
<name>Sending Multiple Token Challenges</name> | <name>Sending Multiple Token Challenges</name> | |||
<t>It is possible for the WWW-Authenticate header field to include m ultiple | <t>It is possible for the WWW-Authenticate header field to include m ultiple | |||
challenges (<xref section="11.6.1" sectionFormat="comma" target="RFC9110"/>). Th is allows the origin to indicate | challenges (<xref section="11.6.1" sectionFormat="comma" target="RFC9110"/>). Th is allows the origin to indicate | |||
support for different token types, issuers, or to include multiple redemption | support for different token types, issuers, or to include multiple redemption | |||
contexts. For example, the WWW-Authenticate header field could look like this:</ | contexts. For example, the WWW-Authenticate header field could look like this: | |||
t> | ||||
<!-- [rfced] Section 2.1.2.1: This sentence does not parse. If | ||||
neither suggestion below is correct, please provide clarifying text. | ||||
Original: | ||||
This allows the | ||||
origin to indicate support for different token types, issuers, or to | ||||
include multiple redemption contexts. | ||||
Suggestion #1 (support for different token types or different | ||||
issuers): | ||||
This allows the | ||||
origin to indicate support for different token types or different | ||||
issuers, or to include multiple redemption contexts. | ||||
Suggestion #2 (support for different token types or for issuers in | ||||
general): | ||||
This allows the | ||||
origin to indicate support for different token types or for issuers, | ||||
or to include multiple redemption contexts. --> | ||||
</t> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
WWW-Authenticate: | WWW-Authenticate: | |||
PrivateToken challenge="abc...", token-key="123...", | PrivateToken challenge="abc...", token-key="123...", | |||
PrivateToken challenge="def...", token-key="234..." | PrivateToken challenge="def...", token-key="234..." | |||
]]></artwork> | ]]></artwork> | |||
<t>Origins should only include challenges for different types of iss uance | <t>Origins should only include challenges for different types of iss uance | |||
protocols with functionally equivalent properties. For instance, both issuance | protocols with functionally equivalent properties. For instance, both issuance | |||
protocols in <xref target="ISSUANCE"/> have the same functional properties, albe it with | protocols in <xref target="RFC9578"/> have the same functional properties, albei t with | |||
different mechanisms for verifying the resulting tokens during redemption. | different mechanisms for verifying the resulting tokens during redemption. | |||
Since clients are free to choose which challenge they want to consume when | Since clients are free to choose which challenge they want to consume when | |||
presented with options, mixing multiple challenges with different functional | presented with options, mixing multiple challenges with different functional | |||
properties for one use case is nonsensical. If the origin has a preference | properties for one use case is nonsensical. If the origin has a preference | |||
for one challenge over another (for example, if one uses a token type | for one challenge over another (for example, if one uses a token type | |||
that is faster to verify), it can sort it to be first in the list | that is faster to verify), it can sort it to be first in the list | |||
of challenges as a hint to the client.</t> | of challenges as a hint to the client.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="process-challenge"> | <section anchor="process-challenge"> | |||
skipping to change at line 365 ¶ | skipping to change at line 459 ¶ | |||
before taking any action, such as fetching a new token or redeeming a token | before taking any action, such as fetching a new token or redeeming a token | |||
in a new request. Validation requirements are as follows:</t> | in a new request. Validation requirements are as follows:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The token_type is recognized and supported by the client;</li> | <li>The token_type is recognized and supported by the client;</li> | |||
<li>The TokenChallenge structure is well-formed; and</li> | <li>The TokenChallenge structure is well-formed; and</li> | |||
<li>If the origin_info field is non-empty, the name of the origin th at issued the | <li>If the origin_info field is non-empty, the name of the origin th at issued the | |||
authentication challenge is included in the list of origin names. Comparison | authentication challenge is included in the list of origin names. Comparison | |||
of the origin name that issued the authentication challenge against elements | of the origin name that issued the authentication challenge against elements | |||
in the origin_info list is done via case-insensitive equality checks.</li> | in the origin_info list is done via case-insensitive equality checks.</li> | |||
</ul> | </ul> | |||
<t>If validation fails, the client MUST NOT fetch or redeem a token ba | <t>If validation fails, the client <bcp14>MUST NOT</bcp14> fetch or re | |||
sed on the | deem a token based on the | |||
challenge. Clients MAY have further restrictions and requirements around | challenge. Clients <bcp14>MAY</bcp14> have further restrictions and requirements | |||
around | ||||
validating when a challenge is considered acceptable or valid. For example, | validating when a challenge is considered acceptable or valid. For example, | |||
clients can choose to ignore challenges that list origin names for which the | clients can choose to ignore challenges that list origin names for which the | |||
current connection is not authoritative (according to the TLS certificate).</t> | current connection is not authoritative (according to the TLS certificate).</t> | |||
<t>Caching and pre-fetching of tokens is discussed in <xref target="ca ching"/>.</t> | <t>Caching and pre-fetching of tokens are discussed in <xref target="c aching"/>.</t> | |||
</section> | </section> | |||
<section anchor="caching"> | <section anchor="caching"> | |||
<name>Token Caching</name> | <name>Token Caching</name> | |||
<t>Clients can generate multiple tokens from a single TokenChallenge, and cache | <t>Clients can generate multiple tokens from a single TokenChallenge a nd cache | |||
them for future use. This improves privacy by separating the time of token | them for future use. This improves privacy by separating the time of token | |||
issuance from the time of token redemption, and also allows clients to avoid | issuance from the time of token redemption, and also allows clients to avoid | |||
any overhead of receiving new tokens via the issuance protocol.</t> | the overhead of receiving new tokens via the issuance protocol.</t> | |||
<t>Cached tokens can only be redeemed when they match all of the field s in the | <t>Cached tokens can only be redeemed when they match all of the field s in the | |||
TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. | TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. | |||
Clients ought to store cached tokens based on all of these fields, to | Clients ought to store cached tokens based on all of these fields, to | |||
avoid trying to redeem a token that does not match. Note that each token | avoid trying to redeem a token that does not match. Note that each token | |||
has a unique client nonce, which is sent in token redemption (<xref target="rede mption"/>).</t> | has a unique client nonce, which is sent in token redemption (<xref target="rede mption"/>).</t> | |||
<t>If a client fetches a batch of multiple tokens for future use that are bound | <t>If a client fetches a batch of multiple tokens for future use that are bound | |||
to a specific redemption context (the redemption_context in the TokenChallenge | to a specific redemption context (the redemption_context in the TokenChallenge | |||
was not empty), clients SHOULD discard these tokens upon flushing state such as | was not empty), clients <bcp14>SHOULD</bcp14> discard these tokens upon flushing | |||
HTTP cookies <xref target="COOKIES"/>, or if there is a network | state such as | |||
HTTP cookies <xref target="I-D.ietf-httpbis-rfc6265bis"/>, or if there is a netw | ||||
ork | ||||
change and the client does not have any origin-specific state like HTTP cookies. | change and the client does not have any origin-specific state like HTTP cookies. | |||
Using these tokens in a context that otherwise would not be linkable to the | Using these tokens in a context that otherwise would not be linkable to the | |||
original context could allow the origin to recognize a client.</t> | original context could allow the origin to recognize a client.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="redemption"> | <section anchor="redemption"> | |||
<name>Token Redemption</name> | <name>Token Redemption</name> | |||
<t>The output of the issuance protocol is a token that corresponds to th e origin's | <t>The output of the issuance protocol is a token that corresponds to th e origin's | |||
challenge (see <xref target="challenge"/>).</t> | challenge (see <xref target="challenge"/>).</t> | |||
<section anchor="token-structure"> | <section anchor="token-structure"> | |||
<name>Token Structure</name> | <name>Token Structure</name> | |||
<t>A token is a structure that begins with a two-octet field that indi cates a token | <t>A token is a structure that begins with a two-octet field that indi cates a token | |||
type, which MUST match the token_type in the TokenChallenge structure. This valu | type, which <bcp14>MUST</bcp14> match the token_type in the TokenChallenge struc | |||
e | ture. This value | |||
determines the structure and semantics of the rest of token structure.</t> | determines the structure and semantics of the rest of the token structure.</t> | |||
<t>This document defines the default token structure that can be used across | <t>This document defines the default token structure that can be used across | |||
token types, although future token types MAY extend or modify the structure | token types, although future token types <bcp14>MAY</bcp14> extend or modify the | |||
of the token; see <xref target="token-types"/> for the registry information whic | structure | |||
h | of the token; see <xref target="token-types"/> for the registry information that | |||
establishes and defines the relationship between "token_type" and the contents | establishes and defines the relationship between "token_type" and the contents | |||
of the Token structure.</t> | of the Token structure.</t> | |||
<t>The default Token message has the following structure:</t> | <t>The default Token message has the following structure:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type; | uint16_t token_type; | |||
uint8_t nonce[32]; | uint8_t nonce[32]; | |||
uint8_t challenge_digest[32]; | uint8_t challenge_digest[32]; | |||
uint8_t token_key_id[Nid]; | uint8_t token_key_id[Nid]; | |||
uint8_t authenticator[Nk]; | uint8_t authenticator[Nk]; | |||
skipping to change at line 439 ¶ | skipping to change at line 533 ¶ | |||
issuance protocol.</li> | issuance protocol.</li> | |||
<li>"authenticator" is a Nk-octet authenticator that is cryptographi cally bound | <li>"authenticator" is a Nk-octet authenticator that is cryptographi cally bound | |||
to the preceding fields in the token; see <xref target="verification"/> for more information | to the preceding fields in the token; see <xref target="verification"/> for more information | |||
about how this field is used in verifying a token. The token_type and correspond ing | about how this field is used in verifying a token. The token_type and correspond ing | |||
issuance protocol determine the value of the authenticator field and how it is c omputed. | issuance protocol determine the value of the authenticator field and how it is c omputed. | |||
The value of constant Nk depends on token_type, as defined in <xref target="toke n-types"/>.</li> | The value of constant Nk depends on token_type, as defined in <xref target="toke n-types"/>.</li> | |||
</ul> | </ul> | |||
<t>The authenticator value in the Token structure is computed over the token_type, | <t>The authenticator value in the Token structure is computed over the token_type, | |||
nonce, challenge_digest, and token_key_id fields. A token is considered a valid | nonce, challenge_digest, and token_key_id fields. A token is considered a valid | |||
if token verification using succeeds; see <xref target="verification"/> for deta ils about | if token verification using succeeds; see <xref target="verification"/> for deta ils about | |||
verifying the token and its authenticator value.</t> | verifying the token and its authenticator value. | |||
<!-- [rfced] Section 2.2.1: This sentence does not parse. If the | ||||
suggested text is not correct, please provide clarifying text. | ||||
Original: | ||||
A | ||||
token is considered a valid if token verification using succeeds; see | ||||
Section 2.2.3 for details about verifying the token and its | ||||
authenticator value. | ||||
Suggested: | ||||
A | ||||
token is considered valid if token verification succeeds; see | ||||
Section 2.2.3 for details about verifying the token and its | ||||
authenticator value. --> | ||||
</t> | ||||
</section> | </section> | |||
<section anchor="sending-tokens"> | <section anchor="sending-tokens"> | |||
<name>Sending Tokens</name> | <name>Sending Tokens</name> | |||
<t>When used for client authorization, the "PrivateToken" authenticati on | <t>When used for client authorization, the "PrivateToken" authenticati on | |||
scheme defines one parameter, "token", which contains the base64url-encoded | scheme defines one parameter, "token", which contains the base64url-encoded | |||
Token struct. As with the challenge parameters (<xref target="challenge"/>), the | Token structure. As with the challenge parameters (<xref target="challenge"/>), | |||
base64url | the base64url | |||
value MUST include padding. As an Authentication Parameter (<tt>auth-param</tt> | value <bcp14>MUST</bcp14> include padding. As an authentication parameter (<tt>a | |||
from | uth-param</tt> from | |||
<xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or a | <xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or a | |||
quoted-string, and might be required to be a quoted-string if the base64url | quoted-string and might be required to be a quoted-string if the base64url | |||
string includes "=" characters. All unknown or unsupported parameters to | string includes "=" characters. All unknown or unsupported parameters to | |||
"PrivateToken" authentication credentials MUST be ignored.</t> | "PrivateToken" authentication credentials <bcp14>MUST</bcp14> be ignored.</t> | |||
<t>Clients present this Token structure to origins in a new HTTP reque st using | <t>Clients present this Token structure to origins in a new HTTP reque st using | |||
the Authorization header field as follows:</t> | the Authorization header field as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Authorization: PrivateToken token="abc..." | Authorization: PrivateToken token="abc..." | |||
]]></artwork> | ]]></artwork> | |||
<t>For context-bound tokens, origins store or reconstruct the contexts of previous | <t>For context-bound tokens, origins store or reconstruct the contexts of previous | |||
TokenChallenge structures in order to validate the token. A TokenChallenge can | TokenChallenge structures in order to validate the token. A TokenChallenge can | |||
be bound to a specific TLS session with a client, but origins can also accept | be bound to a specific TLS session with a client, but origins can also accept | |||
tokens for valid challenges in new sessions. Origins SHOULD implement some form | tokens for valid challenges in new sessions. Origins <bcp14>SHOULD</bcp14> imple ment some form | |||
of double-spend prevention that prevents a token with the same nonce from being | of double-spend prevention that prevents a token with the same nonce from being | |||
redeemed twice. Double-spend prevention ensures that clients cannot replay token s | redeemed twice. Double-spend prevention ensures that clients cannot replay token s | |||
for previous challenges. See <xref target="replay-attacks"/> for more informatio n about replay | for previous challenges. See <xref target="replay-attacks"/> for more informatio n about replay | |||
attacks. For context-bound tokens, this double-spend prevention can require no s tate | attacks. For context-bound tokens, this double-spend prevention can require no s tate | |||
or minimal state, since the context can be used to verify token uniqueness.</t> | or minimal state, since the context can be used to verify token uniqueness.</t> | |||
</section> | </section> | |||
<section anchor="verification"> | <section anchor="verification"> | |||
<name>Token Verification</name> | <name>Token Verification</name> | |||
<t>A token consists of some input cryptographically bound to an authen ticator | <t>A token consists of some input cryptographically bound to an authen ticator | |||
value, such as a digital signature. Verifying a token consists of checking that | value, such as a digital signature. Verifying a token consists of checking that | |||
the authenticator value is correct.</t> | the authenticator value is correct.</t> | |||
<t>The authenticator value is as computed when running and finalizing the issuance | <t>The authenticator value is as computed when running and finalizing the issuance | |||
protocol corresponding to the token type with the following value as the input:< /t> | protocol corresponding to the token type with the following values as the input: </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type; | uint16_t token_type; | |||
uint8_t nonce[32]; | uint8_t nonce[32]; | |||
uint8_t challenge_digest[32]; | uint8_t challenge_digest[32]; | |||
uint8_t token_key_id[Nid]; | uint8_t token_key_id[Nid]; | |||
} AuthenticatorInput; | } AuthenticatorInput; | |||
]]></artwork> | ]]></artwork> | |||
<t>The value of these fields are as described in <xref target="redempt | <t>The values of these fields are as described in <xref target="token- | |||
ion"/>. The cryptographic | structure"/>. The cryptographic | |||
verification check depends on the token type; see <xref section="5.4" sectionFor | verification check depends on the token type; see | |||
mat="of" target="ISSUANCE"/> | Sections <xref target="RFC9578" section="5.4" sectionFormat="bare"/> and <x | |||
and <xref section="6.4" sectionFormat="of" target="ISSUANCE"/> for verification | ref target="RFC9578" section="6.4" sectionFormat="bare"/> of <xref target="RFC95 | |||
instructions for the issuance | 78"/> for verification instructions for the issuance | |||
protocols described in <xref target="ISSUANCE"/>. As such, the security properti | protocols described in that specification. As such, the security properties of t | |||
es of the | he | |||
token, e.g., the probability that one can forge an authenticator value without | token, e.g., the probability that one can forge an authenticator value without | |||
invoking the issuance protocol, depend on the cryptographic algorithm used by | invoking the issuance protocol, depend on the cryptographic algorithm used by | |||
the issuance protocol as determined by the token type.</t> | the issuance protocol as determined by the token type. | |||
<!-- [rfced] Section 2.2.3: Because the cited information is in | ||||
Section 2.2.1 and this text is also part of Section 2.2, we updated | ||||
this sentence as follows. If this is incorrect, please provide | ||||
clarifying text. | ||||
Original: | ||||
The value of these fields are as described in Section 2.2. | ||||
Currently (also fixed the subject-verb disagreement): | ||||
The values of these fields are as described in Section 2.2.1. --> | ||||
</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="client-behavior"> | <section anchor="client-behavior"> | |||
<name>Client Behavior</name> | <name>Client Behavior</name> | |||
<t>When a client receives one or more token challenges in response to a re quest, | <t>When a client receives one or more token challenges in response to a re quest, | |||
the client has a set of choices to make:</t> | the client has a set of choices to make:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Whether or not to redeem a token via a new request to the origin.</l i> | <li>Whether or not to redeem a token via a new request to the origin.</l i> | |||
<li>Whether to redeem a previously issued and cached token, or redeem a token freshly issued from the issuance protocol.</li> | <li>Whether to redeem a previously issued and cached token or redeem a t oken freshly issued from the issuance protocol.</li> | |||
<li>If multiple challenges were sent, which challenge to use for redeemi ng a | <li>If multiple challenges were sent, which challenge to use for redeemi ng a | |||
token on a subsequent request.</li> | token on a subsequent request.</li> | |||
</ul> | </ul> | |||
<t>The approach to these choices depends on the use case of the applicatio n, as | <t>The approach to these choices depends on the use case of the applicatio n, as | |||
well as the deployment model (see <xref section="4" sectionFormat="of" target="A RCHITECTURE"/> for discussion | well as the deployment model (see <xref section="4" sectionFormat="of" target="R FC9576"/> for discussion | |||
of the different deployment models).</t> | of the different deployment models).</t> | |||
<section anchor="choosing-to-redeem-tokens"> | <section anchor="choosing-to-redeem-tokens"> | |||
<name>Choosing to Redeem Tokens</name> | <name>Choosing to Redeem Tokens</name> | |||
<t>Some applications of tokens might require clients to always present a token | <t>Some applications of tokens might require clients to always present a token | |||
as authentication in order to successfully make requests. For example, a restric ted | as authentication in order to successfully make requests. For example, a restric ted | |||
service that wants to only allow access to valid users, but do so without learni | service that wants to only allow access to valid users but wants to do so withou | |||
ng | t learning | |||
specific user credential information, could use tokens that are based on attesti | specific user credential information could use tokens that are based on attestin | |||
ng user | g user | |||
credentials. In these kinds of use cases, clients will need to always redeem a | credentials. In these kinds of use cases, clients will need to always redeem a | |||
token in order to successfully make a request.</t> | token in order to successfully make a request.</t> | |||
<t>Many other use cases for Privacy Pass tokens involve open services th at must work | <t>Many other use cases for Privacy Pass tokens involve open services th at must work | |||
with any client, including those that either cannot redeem tokens, or can only s ometimes redeem | with any client, including those that either cannot redeem tokens or can only so metimes redeem | |||
tokens. For example, a service can use tokens as a way to reduce the incidence o f | tokens. For example, a service can use tokens as a way to reduce the incidence o f | |||
presenting CAPTCHAs to users. In such use cases, services will regularly encount er | presenting CAPTCHAs to users. In such use cases, services will regularly encount er | |||
clients that cannot redeem a token or choose not to. In order to mitigate the ri sk | clients that cannot redeem a token or choose not to. In order to mitigate the ri sk | |||
of these services relying on always receiving tokens, clients that are capable o f | of these services relying on always receiving tokens, clients that are capable o f | |||
redeeming tokens can ignore token challenges (and instead behave as if they were a client | redeeming tokens can ignore token challenges (and instead behave as if they were a client | |||
that either doesn't support redeeming tokens or is unable to generate a new toke n, by not | that either doesn't support redeeming tokens or is unable to generate a new toke n, by not | |||
sending a new request that contains a token to redeem) with some | sending a new request that contains a token to redeem) with some | |||
non-trivial probability. See <xref section="5.1" sectionFormat="of" target="ARCH | non-trivial probability. See <xref section="5.1" sectionFormat="of" target="RFC9 | |||
ITECTURE"/> for further considerations | 576"/> for further considerations | |||
on avoiding discriminatory behavior across clients when using Privacy Pass token | regarding avoiding discriminatory behavior across clients when using Privacy Pas | |||
s.</t> | s tokens.</t> | |||
<t>Clients might also choose to not redeem tokens in subsequent requests when the | <t>Clients might also choose to not redeem tokens in subsequent requests when the | |||
token challenges indicate erroneous or malicious behavior on the part of the | token challenges indicate erroneous or malicious behavior on the part of the | |||
challenging origin. For example, if a client's ability to generate tokens via an | challenging origin. For example, if a client's ability to generate tokens via an | |||
attester and issuer is limited to a certain rate, a malicious origin could send | Attester and issuer is limited to a certain rate, a malicious origin could send | |||
an excessive number of token challenges with unique redemption contexts | an excessive number of token challenges with unique redemption contexts | |||
in order to cause the client to exhaust its ability to generate new tokens, or | in order to (1) cause the client to exhaust its ability to generate new tok | |||
to overwhelm issuance servers. The limits here will vary based on the specific | ens or (2) overwhelm issuance servers. Based on the specific deployment, th | |||
deployment, but clients SHOULD have some implementation-specific policy | e limits here will vary, but clients <bcp14>SHOULD</bcp14> have some implementat | |||
to minimize the number of tokens that can be retrieved by origins.</t> | ion-specific policy to minimize the number of tokens that can be retrieved by or | |||
igins.</t> | ||||
</section> | </section> | |||
<section anchor="choosing-between-multiple-challenges"> | <section anchor="choosing-between-multiple-challenges"> | |||
<name>Choosing Between Multiple Challenges</name> | <name>Choosing between Multiple Challenges</name> | |||
<t>A single response from an origin can include multiple token challenge s. | <t>A single response from an origin can include multiple token challenge s. | |||
For example, a set of challenges could include different token types | For example, a set of challenges could include different token types | |||
and issuers, to allow clients to choose a preferred issuer or type.</t> | and issuers, to allow clients to choose a preferred issuer or type.</t> | |||
<t>If clients choose to respond, clients should satisfy exactly one of | <t>If clients choose to respond, clients should satisfy exactly one of | |||
the challenges presented. The choice of which challenge to use for redeeming | the challenges presented. The choice of which challenge to use for redeeming | |||
tokens is up to client policy. This can involve which token types are | tokens is up to client policy. This can involve which token types are | |||
supported or preferred, which issuers are supported or preferred, or whether | supported or preferred, which issuers are supported or preferred, or whether | |||
or not the client is able to use cached tokens based on the redemption context | or not the client is able to use cached tokens based on the redemption context | |||
or origin information in the challenge. See <xref target="caching"/> for more di scussion | or origin information in the challenge. See <xref target="caching"/> for more di scussion | |||
on token caching. Regardless of how the choice is made, it SHOULD be done in a | on token caching. Regardless of how the choice is made, it <bcp14>SHOULD</bcp14> be done in a | |||
consistent manner to ensure that the choice does not reveal information about th e | consistent manner to ensure that the choice does not reveal information about th e | |||
specific client; see <xref section="6.2" sectionFormat="of" target="ARCHITECTURE "/> for more details on the privacy | specific client; see <xref section="6.2" sectionFormat="of" target="RFC9576"/> f or more details on the privacy | |||
implications of issuance consistency.</t> | implications of issuance consistency.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="origin-behavior"> | <section anchor="origin-behavior"> | |||
<name>Origin Behavior</name> | <name>Origin Behavior</name> | |||
<t>Origins choose what token challenges to send to clients, which will var y | <t>Origins choose what token challenges to send to clients; these token ch allenges will vary, | |||
depending on the use case and deployment model. The origin chooses | depending on the use case and deployment model. The origin chooses | |||
which token types, issuers, redemption contexts, and origin info to include | which token types, issuers, redemption contexts, and origin information to inclu | |||
in challenges. If an origin sends multiple challenges, each challenge SHOULD | de | |||
in challenges. If an origin sends multiple challenges, each challenge <bcp14>SHO | ||||
ULD</bcp14> | ||||
be equivalent in terms of acceptability for token redemption, since clients | be equivalent in terms of acceptability for token redemption, since clients | |||
are free to choose to generate tokens based on any of the challenges.</t> | are free to choose to generate tokens based on any of the challenges.</t> | |||
<t>Origins ought to consider the time involved in token issuance. Particul arly, | <t>Origins ought to consider the time involved in token issuance. Particul arly, | |||
a challenge that includes a unique redemption context will prevent a client | a challenge that includes a unique redemption context will prevent a client | |||
from using cached tokens, and thus can add more delay before the client | from using cached tokens and thus can add more delay before the client | |||
is able to redeem a token.</t> | is able to redeem a token.</t> | |||
<t>Origins SHOULD minimize the number of challenges sent to a particular c lient | <t>Origins <bcp14>SHOULD</bcp14> minimize the number of challenges sent to a particular client | |||
context (referred to as the "redemption context" in | context (referred to as the "redemption context" in | |||
<xref section="3.3" sectionFormat="of" target="ARCHITECTURE"/>), to avoid overwh elming clients and issuers | <xref section="3.3" sectionFormat="of" target="RFC9576"/>), to avoid overwhelmin g clients and issuers | |||
with token requests that might cause clients to hit rate limits.</t> | with token requests that might cause clients to hit rate limits.</t> | |||
<section anchor="greasing"> | <section anchor="greasing"> | |||
<name>Greasing</name> | <name>Greasing</name> | |||
<t>In order to prevent clients becoming incompatible with new token chal | <t>In order to prevent clients from becoming incompatible with new token | |||
lenges, | challenges, | |||
origins SHOULD include random token types, from the Reserved list of "greased" | origins <bcp14>SHOULD</bcp14> include random token types, from the Reserved list | |||
of "greased" | ||||
types (defined in <xref target="token-types"/>), with some non-trivial probabili ty.</t> | types (defined in <xref target="token-types"/>), with some non-trivial probabili ty.</t> | |||
<t>Additionally, for deployments where tokens are not required (such as when tokens | <t>Additionally, for deployments where tokens are not required (such as when tokens | |||
are used as a way to avoiding showing CAPTCHAs), origins SHOULD randomly | are used as a way to avoid showing CAPTCHAs), origins <bcp14>SHOULD</bcp14> rand omly | |||
choose to not challenge clients for tokens with some non-trivial probability. | choose to not challenge clients for tokens with some non-trivial probability. | |||
This helps origins ensure that their behavior for handling clients that cannot | This helps origins ensure that their behavior for handling clients that cannot | |||
redeem tokens is maintained and exercised consistently.</t> | redeem tokens is maintained and exercised consistently.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sec-considerations"> | <section anchor="sec-considerations"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t>This section contains security considerations for the PrivateToken auth entication | <t>This section contains security considerations for the PrivateToken auth entication | |||
scheme described in this document.</t> | scheme described in this document.</t> | |||
<section anchor="randomness-requirements"> | <section anchor="randomness-requirements"> | |||
<name>Randomness Requirements</name> | <name>Randomness Requirements</name> | |||
<t>All random values in the challenge and token MUST be | <t>All random values in the challenge and token <bcp14>MUST</bcp14> be | |||
generated using a cryptographically secure source of randomness (<xref target="R | generated using a cryptographically secure source of randomness <xref target="RF | |||
FC4086"/>).</t> | C4086"/>.</t> | |||
</section> | </section> | |||
<section anchor="replay-attacks"> | <section anchor="replay-attacks"> | |||
<name>Replay Attacks</name> | <name>Replay Attacks</name> | |||
<t>Applications SHOULD constrain tokens to a single origin unless the us e case can | <t>Applications <bcp14>SHOULD</bcp14> constrain tokens to a single origi n unless the use case can | |||
accommodate replay attacks. Replaying tokens is not necessarily a security | accommodate replay attacks. Replaying tokens is not necessarily a security | |||
or privacy problem. As an example, it is reasonable for clients to replay tokens | or privacy problem. As an example, it is reasonable for clients to replay tokens | |||
in contexts where token redemption does not induce side effects and in which | in contexts where token redemption does not induce side effects and in which | |||
client requests are already linkable. One possible setting where this applies | client requests are already linkable. One possible setting where this applies | |||
is where tokens are sent as part of 0-RTT data.</t> | is where tokens are sent as part of 0-RTT data.</t> | |||
<t>If successful token redemption produces side effects, origins SHOULD | <t>If successful token redemption produces side effects, origins <bcp14> | |||
implement an | SHOULD</bcp14> implement an | |||
anti-replay mechanism to mitigate the harm of such replays. See <xref section="8 | anti-replay mechanism to mitigate the harm of such replays. See <xref section="8 | |||
" sectionFormat="comma" target="TLS13"/> | " sectionFormat="comma" target="RFC8446"/> | |||
and <xref section="9.2" sectionFormat="comma" target="RFC9001"/> for details abo ut anti-replay mechanisms, as well as | and <xref section="9.2" sectionFormat="comma" target="RFC9001"/> for details abo ut anti-replay mechanisms, as well as | |||
<xref section="3" sectionFormat="comma" target="RFC8470"/> for discussion about safety considerations for 0-RTT | <xref section="3" sectionFormat="comma" target="RFC8470"/> for discussion about safety considerations for 0-RTT | |||
HTTP data.</t> | HTTP data.</t> | |||
</section> | </section> | |||
<section anchor="reflection-attacks"> | <section anchor="reflection-attacks"> | |||
<name>Reflection Attacks</name> | <name>Reflection Attacks</name> | |||
<t>The security properties of token challenges vary depending on whether the | <t>The security properties of token challenges vary, depending on whethe r the | |||
challenge contains a redemption context or not, as well as whether the | challenge contains a redemption context or not, as well as whether the | |||
challenge is per-origin or not. For example, cross-origin tokens with empty | challenge is a per-origin challenge or not. For example, cross-origin tokens wit h empty | |||
contexts can be reflected from one party by another, as shown below.</t> | contexts can be reflected from one party by another, as shown below.</t> | |||
<!-- [rfced] Figure 2: | ||||
a) As the title of Section 5.3 is "Reflection Attacks" as opposed to | ||||
Section 5.2 ("Replay Attacks"), should the title of Figure 2 be | ||||
"Reflection Attack Example" instead of "Replay Attack Example"? | ||||
Original: | ||||
Figure 2: Replay attack example | ||||
Currently: | ||||
Figure 2: Replay Attack Example | ||||
Possibly: | ||||
Figure 2: Reflection Attack Example | ||||
b) In the HTML and PDF output files, we see an ASCII arrow after | ||||
"(reflect challenge)" as opposed to the SVG-style arrow used in other | ||||
parts of the figure. Should the ASCII arrow be updated to use the | ||||
same style? If yes, please provide the updated SVG. --> | ||||
<figure anchor="fig-replay"> | <figure anchor="fig-replay"> | |||
<name>Replay attack example</name> | <name>Replay Attack Example</name> | |||
<artset> | <artset> | |||
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="176" width="472" viewBox="0 0 472 176" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> | <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="176" width="472" viewBox="0 0 472 176" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> | |||
<path d="M 8,32 L 8,64" fill="none" stroke="black"/> | <path d="M 8,32 L 8,64" fill="none" stroke="black"/> | |||
<path d="M 40,64 L 40,160" fill="none" stroke="black"/> | <path d="M 40,64 L 40,160" fill="none" stroke="black"/> | |||
<path d="M 80,32 L 80,64" fill="none" stroke="black"/> | <path d="M 80,32 L 80,64" fill="none" stroke="black"/> | |||
<path d="M 176,32 L 176,64" fill="none" stroke="black"/> | <path d="M 176,32 L 176,64" fill="none" stroke="black"/> | |||
<path d="M 216,64 L 216,160" fill="none" stroke="black"/> | <path d="M 216,64 L 216,160" fill="none" stroke="black"/> | |||
<path d="M 264,32 L 264,64" fill="none" stroke="black"/> | <path d="M 264,32 L 264,64" fill="none" stroke="black"/> | |||
<path d="M 392,32 L 392,64" fill="none" stroke="black"/> | <path d="M 392,32 L 392,64" fill="none" stroke="black"/> | |||
<path d="M 424,64 L 424,144" fill="none" stroke="black"/> | <path d="M 424,64 L 424,144" fill="none" stroke="black"/> | |||
skipping to change at line 667 ¶ | skipping to change at line 809 ¶ | |||
| |<-------- Token ---------+ | | |<-------- Token ---------+ | |||
|<-- (reflect token) -+ | | |<-- (reflect token) -+ | | |||
| | | | | | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="token-exhaustion-attacks"> | <section anchor="token-exhaustion-attacks"> | |||
<name>Token Exhaustion Attacks</name> | <name>Token Exhaustion Attacks</name> | |||
<t>When a Client holds cross-origin tokens with empty contexts, it | <t>When a Client holds cross-origin tokens with empty contexts, it | |||
is possible for any Origin in the cross-origin set to deplete that Client | is possible for any Origin in the cross-origin set to deplete that Client's | |||
set of tokens. To prevent this from happening, tokens can be scoped to single | set of tokens. To prevent this from happening, tokens can be scoped to single | |||
Origins (with non-empty origin_info) such that they can only be redeemed for | Origins (with non-empty origin_info) such that they can only be redeemed for | |||
a single Origin. Alternatively, if tokens are cross-Origin, Clients can use | a single Origin. Alternatively, if tokens are cross-Origin tokens, Clients can u se | |||
alternate methods to prevent many tokens from being redeemed at once. For | alternate methods to prevent many tokens from being redeemed at once. For | |||
example, if the Origin requests an excess of tokens, the Client could choose to | example, if the Origin requests an excess of tokens, the Client could choose to | |||
not present any tokens for verification if a redemption had already | not present any tokens for verification if a redemption had already | |||
occurred in a given time window.</t> | occurred in a given time window.</t> | |||
<t>Token challenges that include non-empty origin_info bind tokens to on e or more | <t>Token challenges that include non-empty origin_info bind tokens to on e or more | |||
specific origins. As described in <xref target="challenge"/>, clients only accep t such | specific origins. As described in <xref target="challenge"/>, clients only accep t such | |||
challenges from origin names listed in the origin_info string. Even if multiple | challenges from origin names listed in the origin_info string. Even if multiple | |||
origins are listed, a token can only be redeemed for an origin if the challenge | origins are listed, a token can only be redeemed for an origin if the challenge | |||
has a match for the origin_info. For example, if "a.example.com" issues | has a match for the origin_info. For example, if "a.example.com" issues | |||
a challenge with an origin_info string of "a.example.com,b.example.com", a | a challenge with an origin_info string of "a.example.com,b.example.com", a | |||
client could redeem a token fetched for this challenge if and only if | client could redeem a token fetched for this challenge if and only if | |||
"b.example.com" also included an origin_info string of | "b.example.com" also included an origin_info string of | |||
"a.example.com,b.example.com". On the other hand, if "b.example.com" had an | "a.example.com,b.example.com". On the other hand, if "b.example.com" had an | |||
origin_info string of "b.example.com" or "b.example.com,a.example.com" or | origin_info string of "b.example.com", "b.example.com,a.example.com", or | |||
"a.example.com,b.example.com,c.example.com", the string would not match and the | "a.example.com,b.example.com,c.example.com", the string would not match, and the | |||
client would need to use a different token.</t> | client would need to use a different token. | |||
<!-- [rfced] Section 5.4: Apologies if we're missing something | ||||
obvious, but it appears to us that this sentence conflicts with | ||||
item 3. in Section 2.1 ("Select the origin information to include in | ||||
the token challenge. This can be empty ..."). Please confirm that | ||||
this sentence and the citation will be clear to readers. | ||||
Original (the previous sentence is included for context): | ||||
Token challenges that include non-empty origin_info bind tokens to | ||||
one or more specific origins. As described in Section 2.1, clients | ||||
only accept such challenges from origin names listed in the | ||||
origin_info string. --> | ||||
</t> | ||||
</section> | </section> | |||
<section anchor="timing-correlation-attacks"> | <section anchor="timing-correlation-attacks"> | |||
<name>Timing Correlation Attacks</name> | <name>Timing Correlation Attacks</name> | |||
<t>Context-bound token challenges require clients to obtain matching tok ens when | <t>Context-bound token challenges require clients to obtain matching tok ens when | |||
challenged, rather than presenting a token that was obtained from a different | challenged, rather than presenting a token that was obtained from a different | |||
context in the past. This can make it more likely that issuance and redemption | context in the past. This can make it more likely that issuance and redemption | |||
events will occur at approximately the same time. For example, if a client is | events will occur at approximately the same time. For example, if a client is | |||
challenged for a token with a unique context at time T1 and then subsequently | challenged for a token with a unique context at time T1 and then subsequently | |||
obtains a token at time T2, a colluding issuer and origin can link this to the | obtains a token at time T2, a colluding issuer and origin can link this to the | |||
same client if T2 is unique to the client. This linkability is less feasible as | same client if T2 is unique to the client. This linkability is less feasible as | |||
the number of issuance events at time T2 increases. Depending on the "max-age" | the number of issuance events at time T2 increases. Depending on the "max-age" | |||
token challenge parameter, clients MAY try to add delay to the time between | token challenge parameter, clients <bcp14>MAY</bcp14> try to add delay to the ti me between | |||
being challenged and redeeming a token to make this sort of linkability more | being challenged and redeeming a token to make this sort of linkability more | |||
difficult. For more discussion on correlation risks between token issuance and | difficult. For more discussion on correlation risks between token issuance and | |||
redemption, see <xref section="6.3" sectionFormat="of" target="ARCHITECTURE"/>.< /t> | redemption, see <xref section="6.3" sectionFormat="of" target="RFC9576"/>.</t> | |||
</section> | </section> | |||
<section anchor="cross-context-linkability-attacks"> | <section anchor="cross-context-linkability-attacks"> | |||
<name>Cross-Context Linkability Attacks</name> | <name>Cross-Context Linkability Attacks</name> | |||
<t>As discussed in <xref target="challenge"/>, clients SHOULD discard an | <t>As discussed in <xref target="challenge"/>, clients <bcp14>SHOULD</bc | |||
y context-bound tokens | p14> discard any context-bound tokens | |||
upon flushing cookies or changing networks, to prevent an origin using the | upon flushing cookies or changing networks, to prevent an origin from using the | |||
redemption context state as a cookie to recognize clients.</t> | redemption context state as a cookie to recognize clients.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="iana"> | <section anchor="iana"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<section anchor="authentication-scheme"> | <section anchor="authentication-scheme"> | |||
<name>Authentication Scheme</name> | <name>Authentication Scheme</name> | |||
<t>This document registers the "PrivateToken" authentication scheme in t | <t>IANA has registered the "PrivateToken" authentication scheme in the | |||
he | "HTTP Authentication Schemes" subregistry of the "Hypertext Transfer Protocol (H | |||
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined | TTP) Authentication Scheme Registry" as defined | |||
in <xref section="16.4" sectionFormat="comma" target="RFC9110"/>.</t> | in <xref section="16.4" sectionFormat="comma" target="RFC9110"/>.</t> | |||
<dl> | <dl> | |||
<dt>Authentication Scheme Name:</dt> | <dt>Authentication Scheme Name:</dt> | |||
<dd> | <dd>PrivateToken</dd> | |||
<t>PrivateToken</t> | <dt>Reference:</dt> | |||
</dd> | <dd>RFC 9577, <xref target="challenge-redemption"/></dd> | |||
<dt>Pointer to specification text:</dt> | ||||
<dd> | ||||
<t><xref target="challenge-redemption"/> of this document</t> | ||||
</dd> | ||||
</dl> | </dl> | |||
</section> | </section> | |||
<section anchor="token-types"> | <section anchor="token-types"> | |||
<name>Token Type Registry</name> | <name>Privacy Pass Token Type Registry</name> | |||
<t>IANA is requested to create a new "Privacy Pass Token Type" registry | <t>IANA has created a new "Privacy Pass Token Type" registry in a new | |||
in a new | "Privacy Pass" page to list identifiers for issuance protocols | |||
"Privacy Pass Parameters" page to list identifiers for issuance protocols | ||||
defined for use with the Privacy Pass token authentication scheme. These | defined for use with the Privacy Pass token authentication scheme. These | |||
identifiers are two-byte values, so the maximum possible value is | identifiers are two-byte values, so the maximum possible value is | |||
0xFFFF = 65535.</t> | 0xFFFF = 65535. | |||
<!-- [rfced] We have included some specific questions about the IANA text in | ||||
the document. In addition to responding to those questions, please | ||||
review all of the IANA-related updates carefully and let us know if any | ||||
further updates are needed. | ||||
a) Section 6.2: FYI - We updated "Privacy Pass Parameters" to "Privacy Pass" | ||||
to match the title on the IANA page: <https://www.iana.org/assignments/privacy-p | ||||
ass>. | ||||
IANA notes, 'Whenever possible, we're trying to leave the words "Parameters" and | ||||
"Registry" out of titles, except where doing so causes confusion.' | ||||
b) Section 6.2: Because the "Privacy Pass Token Type" registry contains | ||||
multiple entries, we suggest changing the registry name from "Privacy Pass | ||||
Token Type" to "Privacy Pass Token Types" (plural "Types"). If you agree, we | ||||
will ask IANA to to update the registry at | ||||
<https://www.iana.org/assignments/privacy-pass/> accordingly. | ||||
Original: | ||||
6.2. Token Type Registry | ||||
IANA is requested to create a new "Privacy Pass Token Type" registry | ||||
in a new "Privacy Pass Parameters" page to list identifiers for | ||||
issuance protocols defined for use with the Privacy Pass token | ||||
authentication scheme. | ||||
Perhaps: | ||||
6.2. Privacy Pass Token Types Registry | ||||
IANA has created a new "Privacy Pass Token Types" registry in a new | ||||
"Privacy Pass" page to list identifiers for issuance protocols | ||||
defined for use with the Privacy Pass token authentication scheme. | ||||
c) Sections 6.2 and 6.2.1: The "Privacy Pass Token Type" registry | ||||
(https://www.iana.org/assignments/privacy-pass) includes a "Change Controller" | ||||
column, but "Change Controller" is not included in the lists in these | ||||
sections. Should it be included? If so, we'll place it after "Nid" and before | ||||
"Reference" to correspond with the order in the registry. We will also need | ||||
you to provide an appropriate description to include for Section 6.2. | ||||
d) Sections 6.2 and 6.2.1: Section 6.2 uses "Public Verifiability" while | ||||
Section 6.2.1 and the "Privacy Pass Token Type" registry | ||||
(https://www.iana.org/assignments/privacy-pass) use "Publicly Verifiable". | ||||
Which phrasing is preferred? | ||||
If needed, we will ask IANA to update the registry. We will also update | ||||
Sections 8.2.1 and 8.2.2 of RFC-to-be 9578 if needed. | ||||
Section 6.2: | ||||
Public Verifiability | ||||
Section 6.2.1: | ||||
Publicly Verifiable | ||||
Registry: | ||||
Publicly Verifiable | ||||
e) Section 6.2: Please confirm that "Section 2.2" is correct here. We do not | ||||
see "token-key" in Section 2.2, but we do see it defined in Section 2.1. We | ||||
see "token_key_id" in Section 2.2. | ||||
Original: | ||||
Token Key Encoding: The encoding of the "token-key" parameter in | ||||
Section 2.2 | ||||
--> | ||||
</t> | ||||
<t>New registrations need to list the following attributes:</t> | <t>New registrations need to list the following attributes:</t> | |||
<dl spacing="compact"> | <dl spacing="compact"> | |||
<dt>Value:</dt> | <dt>Value:</dt> | |||
<dd> | <dd> | |||
<t>The two-byte identifier for the algorithm</t> | The two-byte identifier for the algorithm.</dd> | |||
</dd> | ||||
<dt>Name:</dt> | <dt>Name:</dt> | |||
<dd> | <dd>Name of the issuance protocol.</dd> | |||
<t>Name of the issuance protocol</t> | ||||
</dd> | ||||
<dt>Token Structure:</dt> | <dt>Token Structure:</dt> | |||
<dd> | <dd>The contents of the Token structure; see <xref target="redemption" | |||
<t>The contents of the Token structure in <xref target="redemption"/ | />.</dd> | |||
></t> | ||||
</dd> | ||||
<dt>Token Key Encoding:</dt> | <dt>Token Key Encoding:</dt> | |||
<dd> | <dd>The encoding of the "token-key" parameter; see <xref target="redem | |||
<t>The encoding of the "token-key" parameter in <xref target="redemp | ption"/>.</dd> | |||
tion"/></t> | ||||
</dd> | ||||
<dt>TokenChallenge Structure:</dt> | <dt>TokenChallenge Structure:</dt> | |||
<dd> | <dd>The contents of the TokenChallenge structure; see <xref target="ch | |||
<t>The contents of the TokenChallenge structure in <xref target="cha | allenge"/>.</dd> | |||
llenge"/></t> | ||||
</dd> | ||||
<dt>Public Verifiability:</dt> | <dt>Public Verifiability:</dt> | |||
<dd> | <dd>A Y/N value indicating if the output tokens have the | |||
<t>A Y/N value indicating if the output tokens have the | public verifiability property; see <xref section="3.5" sectionFormat="of" target | |||
public verifiability property; see <xref section="3.5" sectionFormat="of" target | ="RFC9576"/> | |||
="ARCHITECTURE"/> | for more details about this property.</dd> | |||
for more details about this property.</t> | ||||
</dd> | ||||
<dt>Public Metadata:</dt> | <dt>Public Metadata:</dt> | |||
<dd> | <dd>A Y/N value indicating if the output tokens can contain | |||
<t>A Y/N value indicating if the output tokens can contain | public metadata; see <xref section="3.5" sectionFormat="of" target="RFC9576"/> | |||
public metadata; see <xref section="3.5" sectionFormat="of" target="ARCHITECTURE | for more details about this property.</dd> | |||
"/> | ||||
for more details about this property.</t> | ||||
</dd> | ||||
<dt>Private Metadata:</dt> | <dt>Private Metadata:</dt> | |||
<dd> | <dd>A Y/N value indicating if the output tokens can contain | |||
<t>A Y/N value indicating if the output tokens can contain | private metadata; see <xref section="3.5" sectionFormat="of" target="RFC9576"/> | |||
private metadata; see <xref section="3.5" sectionFormat="of" target="ARCHITECTUR | for more details about this property.</dd> | |||
E"/> | ||||
for more details about this property.</t> | ||||
</dd> | ||||
<dt>Nk:</dt> | <dt>Nk:</dt> | |||
<dd> | <dd>The length in bytes of an output authenticator.</dd> | |||
<t>The length in bytes of an output authenticator</t> | ||||
</dd> | ||||
<dt>Nid:</dt> | <dt>Nid:</dt> | |||
<dd> | <dd>The length of the token key identifier.</dd> | |||
<t>The length of the token key identifier</t> | ||||
</dd> | ||||
<dt>Reference:</dt> | <dt>Reference:</dt> | |||
<dd> | <dd>Where this algorithm is defined.</dd> | |||
<t>Where this algorithm is defined</t> | ||||
</dd> | ||||
<dt>Notes:</dt> | <dt>Notes:</dt> | |||
<dd> | <dd>Any notes associated with the entry.</dd> | |||
<t>Any notes associated with the entry</t> | ||||
</dd> | ||||
</dl> | </dl> | |||
<t>New entries in this registry are subject to the Specification Require d | <t>New entries in this registry are subject to the Specification Require d | |||
registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126"/ >). Designated experts need to | registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126"/ >). Designated experts need to | |||
ensure that the token type is defined to be used for both token issuance and | ensure that the token type is defined to be used for both token issuance and | |||
redemption. Additionally, the experts can reject registrations on the basis | redemption. Additionally, the experts can reject registrations on the basis | |||
that they do not meet the security and privacy requirements for issuance | that they do not meet the security and privacy requirements for issuance | |||
protocols defined in <xref section="3.2" sectionFormat="of" target="ARCHITECTURE | protocols defined in <xref section="3.2" sectionFormat="of" target="RFC9576"/>.< | |||
"/>.</t> | /t> | |||
<t><xref target="ISSUANCE"/> defines entries for this registry.</t> | <t><xref target="RFC9578"/> defines entries for this registry.</t> | |||
<section anchor="reserved-values"> | <section anchor="reserved-values"> | |||
<name>Reserved Values</name> | <name>Reserved Values</name> | |||
<t>This document defines several Reserved values, which can be used by clients | <t>This document defines several Reserved values, which can be used by clients | |||
and servers to send "greased" values in token challenges and redemptions to | and servers to send "greased" values in token challenges and redemptions to | |||
ensure that implementations remain able to handle unknown token types | ensure that implementations remain able to handle unknown token types | |||
gracefully (this technique is inspired by <xref target="RFC8701"/>). Implementat ions SHOULD | gracefully (this technique is inspired by <xref target="RFC8701"/>). Implementat ions <bcp14>SHOULD</bcp14> | |||
select reserved values at random when including them in greased messages. | select reserved values at random when including them in greased messages. | |||
Servers can include these in TokenChallenge structures, either as the only | Servers can include these in TokenChallenge structures, either as the only | |||
challenge when no real token type is desired, or as one challenge in a list of | challenge when no real token type is desired or as one challenge in a list of | |||
challenges that include real values. Clients can include these in Token | challenges that include real values. Clients can include these in Token | |||
structures when they are not able to present a real token. The | structures when they are not able to present a real token. The | |||
contents of the Token structure SHOULD be filled with random bytes when | contents of the Token structure <bcp14>SHOULD</bcp14> be filled with random byte s when | |||
using greased values.</t> | using greased values.</t> | |||
<t>The initial contents for this registry consists of multiple reserve d values, | <t>The initial contents of this registry consist of multiple reserved values, | |||
with the following attributes, which are repeated for each registration:</t> | with the following attributes, which are repeated for each registration:</t> | |||
<dl spacing="compact"> | <dl spacing="compact"> | |||
<dt>Value:</dt> | <dt>Value:</dt> | |||
<dd> | <dd>0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, | |||
<t>0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, | 0x7F3F, | |||
0x7F3F, | 0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057</dd> | |||
0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057</t> | ||||
</dd> | ||||
<dt>Name:</dt> | <dt>Name:</dt> | |||
<dd> | <dd>RESERVED</dd> | |||
<t>RESERVED</t> | ||||
</dd> | ||||
<dt>Token Structure:</dt> | <dt>Token Structure:</dt> | |||
<dd> | <dd>Random bytes</dd> | |||
<t>Random bytes</t> | ||||
</dd> | ||||
<dt>Token Key Encoding:</dt> | <dt>Token Key Encoding:</dt> | |||
<dd> | <dd>Random bytes</dd> | |||
<t>Random bytes</t> | ||||
</dd> | ||||
<dt>TokenChallenge Structure:</dt> | <dt>TokenChallenge Structure:</dt> | |||
<dd> | <dd>Random bytes</dd> | |||
<t>Random bytes</t> | ||||
</dd> | ||||
<dt>Publicly Verifiable:</dt> | <dt>Publicly Verifiable:</dt> | |||
<dd> | <dd>N/A</dd> | |||
<t>N/A</t> | ||||
</dd> | ||||
<dt>Public Metadata:</dt> | <dt>Public Metadata:</dt> | |||
<dd> | <dd>N/A</dd> | |||
<t>N/A</t> | ||||
</dd> | ||||
<dt>Private Metadata:</dt> | <dt>Private Metadata:</dt> | |||
<dd> | <dd>N/A</dd> | |||
<t>N/A</t> | ||||
</dd> | ||||
<dt>Nk:</dt> | <dt>Nk:</dt> | |||
<dd> | <dd>N/A</dd> | |||
<t>N/A</t> | ||||
</dd> | ||||
<dt>Nid:</dt> | <dt>Nid:</dt> | |||
<dd> | <dd>N/A</dd> | |||
<t>N/A</t> | ||||
</dd> | ||||
<dt>Reference:</dt> | <dt>Reference:</dt> | |||
<dd> | <dd>RFC 9577</dd> | |||
<t>This document</t> | ||||
</dd> | ||||
<dt>Notes:</dt> | <dt>Notes:</dt> | |||
<dd> | <dd>None</dd> | |||
<t>None</t> | ||||
</dd> | ||||
</dl> | </dl> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<displayreference target="RFC9576" to="ARCHITECTURE"/> | ||||
<displayreference target="RFC8446" to="TLS13"/> | ||||
<displayreference target="RFC3986" to="URI"/> | ||||
<displayreference target="RFC9578" to="ISSUANCE"/> | ||||
<displayreference target="I-D.ietf-httpbis-rfc6265bis" to="COOKIES"/> | ||||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<reference anchor="ARCHITECTURE"> | ||||
<front> | ||||
<title>The Privacy Pass Architecture</title> | ||||
<author fullname="Alex Davidson" initials="A." surname="Davidson"> | ||||
<organization>LIP</organization> | ||||
</author> | ||||
<author fullname="Jana Iyengar" initials="J." surname="Iyengar"> | ||||
<organization>Fastly</organization> | ||||
</author> | ||||
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo | ||||
d"> | ||||
<organization>Cloudflare</organization> | ||||
</author> | ||||
<date day="25" month="September" year="2023"/> | ||||
<abstract> | ||||
<t> This document specifies the Privacy Pass architecture and | ||||
requirements for its constituent protocols used for authorization | ||||
based on privacy-preserving authentication mechanisms. It describes | ||||
the conceptual model of Privacy Pass and its protocols, its security | ||||
and privacy goals, practical deployment models, and recommendations | ||||
for each deployment model that helps ensure the desired security and | ||||
privacy goals are fulfilled. | ||||
</t> | <!-- draft-ietf-privacypass-architecture (RFC 9576) --> | |||
</abstract> | <reference anchor="RFC9576" target="https://www.rfc-editor.org/info/rfc9576"> | |||
</front> | <front> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-archit | <title>The Privacy Pass Architecture</title> | |||
ecture-16"/> | <author initials='A' surname='Davidson' fullname='Alex Davidson'> | |||
</reference> | <organization /> | |||
<reference anchor="RFC9110"> | </author> | |||
<front> | <author initials='J' surname='Iyengar' fullname='Jana Iyengar'> | |||
<title>HTTP Semantics</title> | <organization /> | |||
<author fullname="R. Fielding" initials="R." role="editor" surname=" | </author> | |||
Fielding"/> | <author initials='C. A.' surname='Wood' fullname='Christopher A. Wood'> | |||
<author fullname="M. Nottingham" initials="M." role="editor" surname | <organization /> | |||
="Nottingham"/> | </author> | |||
<author fullname="J. Reschke" initials="J." role="editor" surname="R | <date year='2024' month='May'/> | |||
eschke"/> | </front> | |||
<date month="June" year="2022"/> | <seriesInfo name="RFC" value="9576"/> | |||
<abstract> | <seriesInfo name="DOI" value="10.17487/RFC9576"/> | |||
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati | </reference> | |||
on-level protocol for distributed, collaborative, hypertext information systems. | ||||
This document describes the overall architecture of HTTP, establishes common te | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml" | |||
rminology, and defines aspects of the protocol that are shared by all versions. | /> | |||
In this definition are core protocol elements, extensibility mechanisms, and the | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" | |||
"http" and "https" Uniform Resource Identifier (URI) schemes.</t> | /> | |||
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7 | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" | |||
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> | /> | |||
</abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml" | |||
</front> | /> | |||
<seriesInfo name="STD" value="97"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml" | |||
<seriesInfo name="RFC" value="9110"/> | /> | |||
<seriesInfo name="DOI" value="10.17487/RFC9110"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml" | |||
</reference> | /> | |||
<reference anchor="RFC2119"> | ||||
<front> | ||||
<title>Key words for use in RFCs to Indicate Requirement Levels</tit | ||||
le> | ||||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | ||||
<date month="March" year="1997"/> | ||||
<abstract> | ||||
<t>In many standards track documents several words are used to sig | ||||
nify the requirements in the specification. These words are often capitalized. T | ||||
his document defines these words as they should be interpreted in IETF documents | ||||
. This document specifies an Internet Best Current Practices for the Internet Co | ||||
mmunity, and requests discussion and suggestions for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="2119"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | ||||
</reference> | ||||
<reference anchor="RFC8174"> | ||||
<front> | ||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti | ||||
tle> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<date month="May" year="2017"/> | ||||
<abstract> | ||||
<t>RFC 2119 specifies common key words that may be used in protoco | ||||
l specifications. This document aims to reduce the ambiguity by clarifying that | ||||
only UPPERCASE usage of the key words have the defined special meanings.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="8174"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/> | ||||
</reference> | ||||
<reference anchor="TLS13"> | ||||
<front> | ||||
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl | ||||
e> | ||||
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/> | ||||
<date month="August" year="2018"/> | ||||
<abstract> | ||||
<t>This document specifies version 1.3 of the Transport Layer Secu | ||||
rity (TLS) protocol. TLS allows client/server applications to communicate over t | ||||
he Internet in a way that is designed to prevent eavesdropping, tampering, and m | ||||
essage forgery.</t> | ||||
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50 | ||||
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im | ||||
plementations.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8446"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8446"/> | ||||
</reference> | ||||
<reference anchor="URI"> | ||||
<front> | ||||
<title>Uniform Resource Identifier (URI): Generic Syntax</title> | ||||
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee | ||||
"/> | ||||
<author fullname="R. Fielding" initials="R." surname="Fielding"/> | ||||
<author fullname="L. Masinter" initials="L." surname="Masinter"/> | ||||
<date month="January" year="2005"/> | ||||
<abstract> | ||||
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch | ||||
aracters that identifies an abstract or physical resource. This specification de | ||||
fines the generic URI syntax and a process for resolving URI references that mig | ||||
ht be in relative form, along with guidelines and security considerations for th | ||||
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers | ||||
et of all valid URIs, allowing an implementation to parse the common components | ||||
of a URI reference without knowing the scheme-specific requirements of every pos | ||||
sible identifier. This specification does not define a generative grammar for UR | ||||
Is; that task is performed by the individual specifications of each URI scheme. | ||||
[STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="66"/> | ||||
<seriesInfo name="RFC" value="3986"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC3986"/> | ||||
</reference> | ||||
<reference anchor="RFC4648"> | ||||
<front> | ||||
<title>The Base16, Base32, and Base64 Data Encodings</title> | ||||
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> | ||||
<date month="October" year="2006"/> | ||||
<abstract> | ||||
<t>This document describes the commonly used base 64, base 32, and | ||||
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da | ||||
ta, use of padding in encoded data, use of non-alphabet characters in encoded da | ||||
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA | ||||
CK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="4648"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4648"/> | ||||
</reference> | ||||
<reference anchor="SHS" target="https://doi.org/10.6028/nist.fips.180-4" > | <reference anchor="SHS" target="https://doi.org/10.6028/nist.fips.180-4" > | |||
<front> | <front> | |||
<title>Secure Hash Standard</title> | <title>Secure Hash Standard (SHS)</title> | |||
<author fullname="Quynh H. Dang" surname="Dang"/> | ||||
<author> | <author> | |||
<organization>National Institute of Standards and Technology</orga nization> | <organization>National Institute of Standards and Technology</orga nization> | |||
</author> | </author> | |||
<date month="July" year="2015"/> | <date month="August" year="2015"/> | |||
</front> | ||||
<seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/> | ||||
</reference> | ||||
<reference anchor="RFC8126"> | ||||
<front> | ||||
<title>Guidelines for Writing an IANA Considerations Section in RFCs | ||||
</title> | ||||
<author fullname="M. Cotton" initials="M." surname="Cotton"/> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<author fullname="T. Narten" initials="T." surname="Narten"/> | ||||
<date month="June" year="2017"/> | ||||
<abstract> | ||||
<t>Many protocols make use of points of extensibility that use con | ||||
stants to identify various protocol parameters. To ensure that the values in the | ||||
se fields do not have conflicting uses and to promote interoperability, their al | ||||
locations are often coordinated by a central record keeper. For IETF protocols, | ||||
that role is filled by the Internet Assigned Numbers Authority (IANA).</t> | ||||
<t>To make assignments in a given registry prudently, guidance des | ||||
cribing the conditions under which new values should be assigned, as well as whe | ||||
n and how modifications to existing values can be made, is needed. This document | ||||
defines a framework for the documentation of these guidelines by specification | ||||
authors, in order to assure that the provided guidance for the IANA Consideratio | ||||
ns is clear and addresses the various issues that are likely in the operation of | ||||
a registry.</t> | ||||
<t>This is the third edition of this document; it obsoletes RFC 52 | ||||
26.</t> | ||||
</abstract> | ||||
</front> | </front> | |||
<seriesInfo name="BCP" value="26"/> | <seriesInfo name="NIST FIPS Publication" value="180-4"/> | |||
<seriesInfo name="RFC" value="8126"/> | <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC8126"/> | ||||
</reference> | </reference> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" | ||||
/> | ||||
</references> | </references> | |||
<references> | <references> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<reference anchor="ISSUANCE"> | ||||
<front> | ||||
<title>Privacy Pass Issuance Protocol</title> | ||||
<author fullname="Sofia Celi" initials="S." surname="Celi"> | ||||
<organization>Brave Software</organization> | ||||
</author> | ||||
<author fullname="Alex Davidson" initials="A." surname="Davidson"> | ||||
<organization>Brave Software</organization> | ||||
</author> | ||||
<author fullname="Steven Valdez" initials="S." surname="Valdez"> | ||||
<organization>Google LLC</organization> | ||||
</author> | ||||
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo | ||||
d"> | ||||
<organization>Cloudflare</organization> | ||||
</author> | ||||
<date day="3" month="October" year="2023"/> | ||||
<abstract> | ||||
<t> This document specifies two variants of the two-message issu | ||||
ance | ||||
protocol for Privacy Pass tokens: one that produces tokens that are | ||||
privately verifiable using the issuance private key, and another that | ||||
produces tokens that are publicly verifiable using the issuance | ||||
public key. | ||||
</t> | <!-- draft-ietf-privacypass-protocol (RFC 9578) --> | |||
</abstract> | <reference anchor="RFC9578" target="https://www.rfc-editor.org/info/rfc9578"> | |||
</front> | <front> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-protoc | <title>Privacy Pass Issuance Protocol</title> | |||
ol-16"/> | <author initials="S." surname="Celi" fullname="Sofia Celi"> | |||
</reference> | <organization>Brave Software</organization> | |||
<reference anchor="COOKIES"> | </author> | |||
<front> | <author initials="A." surname="Davidson" fullname="Alex Davidson"> | |||
<title>Cookies: HTTP State Management Mechanism</title> | <organization>Brave Software</organization> | |||
<author fullname="Steven Bingler" initials="S." surname="Bingler"> | </author> | |||
<organization>Google LLC</organization> | <author initials="S." surname="Valdez" fullname="Steven Valdez"> | |||
</author> | <organization>Google LLC</organization> | |||
<author fullname="Mike West" initials="M." surname="West"> | </author> | |||
<organization>Google LLC</organization> | <author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> | |||
</author> | <organization>Cloudflare</organization> | |||
<author fullname="John Wilander" initials="J." surname="Wilander"> | </author> | |||
<organization>Apple, Inc</organization> | <date month="May" year="2024"/> | |||
</author> | </front> | |||
<date day="10" month="May" year="2023"/> | <seriesInfo name="RFC" value="9578"/> | |||
<abstract> | <seriesInfo name="DOI" value="10.17487/RFC9578"/> | |||
<t> This document defines the HTTP Cookie and Set-Cookie header | </reference> | |||
fields. | ||||
These header fields can be used by HTTP servers to store state | <!-- draft-ietf-httpbis-rfc6265bis (I-D Exists) | |||
(called cookies) at HTTP user agents, letting the servers maintain a | "Long way" to include editor designations --> | |||
stateful session over the mostly stateless HTTP protocol. Although | <reference anchor="I-D.ietf-httpbis-rfc6265bis"> | |||
cookies have many historical infelicities that degrade their security | <front> | |||
and privacy, the Cookie and Set-Cookie header fields are widely used | <title>Cookies: HTTP State Management Mechanism</title> | |||
on the Internet. This document obsoletes RFC 6265. | <author fullname="Steven Bingler" initials="S." surname="Bingler" role="edit | |||
or"> | ||||
<organization>Google LLC</organization> | ||||
</author> | ||||
<author fullname="Mike West" initials="M." surname="West" role="editor"> | ||||
<organization>Google LLC</organization> | ||||
</author> | ||||
<author fullname="John Wilander" initials="J." surname="Wilander" role="edit | ||||
or"> | ||||
<organization>Apple, Inc</organization> | ||||
</author> | ||||
<date day="15" month="November" year="2023"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-rfc6265bis-13"/> | ||||
</reference> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml" | ||||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml" | ||||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8470.xml" | ||||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml" | ||||
/> | ||||
</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-rfc6265bis | ||||
-12"/> | ||||
</reference> | ||||
<reference anchor="RFC4086"> | ||||
<front> | ||||
<title>Randomness Requirements for Security</title> | ||||
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 | ||||
rd"/> | ||||
<author fullname="J. Schiller" initials="J." surname="Schiller"/> | ||||
<author fullname="S. Crocker" initials="S." surname="Crocker"/> | ||||
<date month="June" year="2005"/> | ||||
<abstract> | ||||
<t>Security systems are built on strong cryptographic algorithms t | ||||
hat foil pattern analysis attempts. However, the security of these systems is de | ||||
pendent on generating secret quantities for passwords, cryptographic keys, and s | ||||
imilar quantities. The use of pseudo-random processes to generate secret quantit | ||||
ies can result in pseudo-security. A sophisticated attacker may find it easier t | ||||
o reproduce the environment that produced the secret quantities and to search th | ||||
e resulting small set of possibilities than to locate the quantities in the whol | ||||
e of the potential number space.</t> | ||||
<t>Choosing random quantities to foil a resourceful and motivated | ||||
adversary is surprisingly difficult. This document points out many pitfalls in u | ||||
sing poor entropy sources or traditional pseudo-random number generation techniq | ||||
ues for generating such quantities. It recommends the use of truly random hardwa | ||||
re techniques and shows that the existing hardware on many systems can be used f | ||||
or this purpose. It provides suggestions to ameliorate the problem when a hardwa | ||||
re solution is not available, and it gives examples of how large such quantities | ||||
need to be for some applications. This document specifies an Internet Best Curr | ||||
ent Practices for the Internet Community, and requests discussion and suggestion | ||||
s for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="106"/> | ||||
<seriesInfo name="RFC" value="4086"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4086"/> | ||||
</reference> | ||||
<reference anchor="RFC9001"> | ||||
<front> | ||||
<title>Using TLS to Secure QUIC</title> | ||||
<author fullname="M. Thomson" initials="M." role="editor" surname="T | ||||
homson"/> | ||||
<author fullname="S. Turner" initials="S." role="editor" surname="Tu | ||||
rner"/> | ||||
<date month="May" year="2021"/> | ||||
<abstract> | ||||
<t>This document describes how Transport Layer Security (TLS) is u | ||||
sed to secure QUIC.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9001"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9001"/> | ||||
</reference> | ||||
<reference anchor="RFC8470"> | ||||
<front> | ||||
<title>Using Early Data in HTTP</title> | ||||
<author fullname="M. Thomson" initials="M." surname="Thomson"/> | ||||
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ | ||||
> | ||||
<author fullname="W. Tarreau" initials="W." surname="Tarreau"/> | ||||
<date month="September" year="2018"/> | ||||
<abstract> | ||||
<t>Using TLS early data creates an exposure to the possibility of | ||||
a replay attack. This document defines mechanisms that allow clients to communic | ||||
ate with servers about HTTP requests that are sent in early data. Techniques are | ||||
described that use these mechanisms to mitigate the risk of replay.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8470"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8470"/> | ||||
</reference> | ||||
<reference anchor="RFC8701"> | ||||
<front> | ||||
<title>Applying Generate Random Extensions And Sustain Extensibility | ||||
(GREASE) to TLS Extensibility</title> | ||||
<author fullname="D. Benjamin" initials="D." surname="Benjamin"/> | ||||
<date month="January" year="2020"/> | ||||
<abstract> | ||||
<t>This document describes GREASE (Generate Random Extensions And | ||||
Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS | ||||
ecosystem. It reserves a set of TLS protocol values that may be advertised to e | ||||
nsure peers correctly handle unknown values.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8701"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8701"/> | ||||
</reference> | ||||
</references> | </references> | |||
</references> | </references> | |||
<section anchor="test-vectors"> | <section anchor="test-vectors"> | |||
<name>Test Vectors</name> | <name>Test Vectors</name> | |||
<t>This section includes test vectors for the HTTP authentication scheme s pecified | <t>This section includes test vectors for the HTTP authentication scheme s pecified | |||
in this document. It consists of the following types of test vectors:</t> | in this document. It consists of the following types of test vectors:</t> | |||
<ol spacing="normal" type="1"><li>Test vectors for the challenge and redem ption protocols. Implementations can | <ol spacing="normal" type="1"><li>Test vectors for the challenge and redem ption protocols. Implementations can | |||
use these test vectors for verifying code that builds and encodes | use these test vectors for verifying code that builds and encodes | |||
TokenChallenge structures, as well as code that produces a well-formed Token | TokenChallenge structures, as well as code that produces a well-formed Token | |||
bound to a TokenChallenge.</li> | bound to a TokenChallenge.</li> | |||
<li>Test vectors for the HTTP headers used for authentication. Implement ations | <li>Test vectors for the HTTP headers used for authentication. Implement ations | |||
can use these test vectors for validating whether they parse HTTP | can use these test vectors for validating whether they parse HTTP | |||
authentication headers correctly to produce TokenChallenge structures and the | authentication headers correctly to produce TokenChallenge structures and the | |||
other associated parameters, such as the token-key and max-age values.</li> | other associated parameters, such as the token-key and max-age values.</li> | |||
</ol> | </ol> | |||
<section anchor="challenge-and-redemption-structure-test-vectors"> | <section anchor="challenge-and-redemption-structure-test-vectors"> | |||
<name>Challenge and Redemption Structure Test Vectors</name> | <name>Challenge and Redemption Structure Test Vectors</name> | |||
<t>This section includes test vectors for the challenge and redemption | <t>This section includes test vectors for the challenge and redemption | |||
functionalities described in <xref target="challenge"/> and <xref target="redemp tion"/>. Each test vector | functionalities described in Sections <xref target="challenge" format="coun ter"/> and <xref target="redemption" format="counter"/>. Each test vector | |||
lists the following values:</t> | lists the following values:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>token_type: The type of token issuance protocol, a value from | <dt>token_type:</dt><dd>The type of token issuance protocol -- a value | |||
from | ||||
<xref target="token-types"/>. For these test vectors, token_type is 0x0002, corr esponding | <xref target="token-types"/>. For these test vectors, token_type is 0x0002, corr esponding | |||
to the issuance protocol in <xref target="ISSUANCE"/>.</li> | to the issuance protocol in <xref target="RFC9578"/>. | |||
<li>issuer_name: The name of the issuer in the TokenChallenge structur | ||||
e, | <!-- [rfced] Appendix A.1: Because two issuance protocols are | |||
represented as a hexadecimal string.</li> | defined in [ISSUANCE] and we see "both issuance protocols in | |||
<li>redemption_context: The redemption context in the TokenChallenge s | [ISSUANCE]" in Section 2.1.2.1, may we clarify this text by updating | |||
tructure, | as suggested below? | |||
represented as a hexadecimal string.</li> | ||||
<li>origin_info: The origin info in the TokenChallenge structure, repr | Original (the previous phrase is included for context): | |||
esented as | * token_type: The type of token issuance protocol, a value from | |||
a hexadecimal string.</li> | Section 6.2. For these test vectors, token_type is 0x0002, | |||
<li>nonce: The nonce in the Token structure, represented as a hexadeci | corresponding to the issuance protocol in [ISSUANCE]. | |||
mal string.</li> | ||||
<li>token_key: The public token-key, encoded based on the correspondin | Suggested: | |||
g token | token_type: The type of token issuance protocol - a value from | |||
type, represented as a hexadecimal string.</li> | Section 6.2. For these test vectors, token_type is 0x0002, | |||
<li>token_authenticator_input: The values in the Token structure used | corresponding to token issuance protocol 2; see Appendix B of | |||
to compute | [ISSUANCE]. --> | |||
the Token authenticator value, represented as a hexadecimal string.</li> | ||||
</ul> | </dd> | |||
<dt>issuer_name:</dt><dd> The name of the issuer in the TokenChallenge | ||||
structure, | ||||
represented as a hexadecimal string.</dd> | ||||
<dt>redemption_context:</dt><dd>The redemption context in the TokenCha | ||||
llenge structure, | ||||
represented as a hexadecimal string.</dd> | ||||
<dt>origin_info:</dt><dd> The origin information in the TokenChallenge | ||||
structure, represented as | ||||
a hexadecimal string.</dd> | ||||
<dt>nonce:</dt><dd>The nonce in the Token structure, represented as a | ||||
hexadecimal string.</dd> | ||||
<!-- [rfced] Appendix A.1: Is "token_key" here correct? "token_key_id" is used | ||||
in the test vectors in this section. We do not see "token_key" elsewhere | ||||
in the document (though we do see "token-key"). | ||||
Original: | ||||
* token_key: The public token-key, encoded based on the | ||||
corresponding token type, represented as a hexadecimal string. | ||||
--> | ||||
<dt>token_key:</dt><dd>The public token-key, encoded based on the corre | ||||
sponding token | ||||
type, represented as a hexadecimal string.</dd> | ||||
<dt>token_authenticator_input:</dt><dd>The values in the Token structu | ||||
re used to compute | ||||
the Token authenticator value, represented as a hexadecimal string.</dd> | ||||
</dl> | ||||
<t>Test vectors are provided for each of the following TokenChallenge | <t>Test vectors are provided for each of the following TokenChallenge | |||
configurations:</t> | configurations:</t> | |||
<ol spacing="normal" type="1"><li>TokenChallenge with a single origin an | <ol spacing="normal" type="1"><li>TokenChallenge with a single origin an | |||
d non-empty redemption context</li> | d non-empty redemption context.</li> | |||
<li>TokenChallenge with a single origin and empty redemption context</ | <li>TokenChallenge with a single origin and empty redemption context.< | |||
li> | /li> | |||
<li>TokenChallenge with an empty origin and redemption context</li> | <li>TokenChallenge with an empty origin and redemption context.</li> | |||
<li>TokenChallenge with an empty origin and non-empty redemption conte | <li>TokenChallenge with an empty origin and non-empty redemption conte | |||
xt</li> | xt.</li> | |||
<li>TokenChallenge with a multiple origins and non-empty redemption co | <li>TokenChallenge with multiple origins and non-empty redemption cont | |||
ntext</li> | ext.</li> | |||
<li>TokenChallenge for greasing</li> | <li>TokenChallenge for greasing.</li> | |||
<!-- [rfced] Appendix A.1: We changed "a multiple origins" to | ||||
"multiple origins" here. Should "and non-empty redemption context" | ||||
be "and a non-empty redemption context" (as appears to be the case | ||||
for the "// Test vector 5" entry), or should it be "and non-empty | ||||
redemption contexts"? | ||||
Original: | ||||
5. TokenChallenge with a multiple origins and non-empty redemption | ||||
context | ||||
Currently: | ||||
5. TokenChallenge with multiple origins and non-empty redemption | ||||
context. --> | ||||
</ol> | </ol> | |||
<t>These test vectors are below.</t> | <t>These test vectors are below.</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
// Test vector 1: | // Test vector 1: | |||
// token_type(0002), issuer_name(issuer.example), | // token_type(0002), issuer_name(issuer.example), | |||
// origin_info(origin.example), redemption_context(non-empty) | // origin_info(origin.example), redemption_context(non-empty) | |||
token_type: 0002 | token_type: 0002 | |||
issuer_name: 6973737565722e6578616d706c65 | issuer_name: 6973737565722e6578616d706c65 | |||
redemption_context: | redemption_context: | |||
476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb | 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb | |||
skipping to change at line 1276 ¶ | skipping to change at line 1339 ¶ | |||
f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834 | f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834 | |||
2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d | 2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d | |||
b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d | b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d | |||
6cf7b522a5badd63b9cb | 6cf7b522a5badd63b9cb | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
<section anchor="http-header-test-vectors"> | <section anchor="http-header-test-vectors"> | |||
<name>HTTP Header Test Vectors</name> | <name>HTTP Header Test Vectors</name> | |||
<t>This section includes test vectors the contents of the HTTP authentic ation | <t>This section includes test vectors the contents of the HTTP authentic ation | |||
headers. Each test vector consists of one or more challenges that comprise | headers. Each test vector consists of one or more challenges that comprise | |||
a WWW-Authenticate header, as defined in {(choosing-between-multiple-challenges} | a WWW-Authenticate header; see | |||
}. | <xref target="choosing-between-multiple-challenges"/>. | |||
For each challenge, the token-type, token-key, max-age, and token-challenge | For each challenge, the token-type, token-key, max-age, and token-challenge | |||
parameters are listed. Each challenge also includes an unknown (not specified) | parameters are listed. Each challenge also includes an unknown (unspecified) | |||
parameter that implementations are meant to ignore.</t> | parameter that implementations are meant to ignore. | |||
<!-- [rfced] Appendix A.2: This sentence does not parse. If the | ||||
suggested text is not correct, please clarify. | ||||
Original: | ||||
This section includes test vectors the contents of the HTTP | ||||
authentication headers. | ||||
Suggested (per item 2. in Appendix A): | ||||
This section includes test vectors for the HTTP authentication | ||||
headers. --> | ||||
</t> | ||||
<t>The parameters for each challenge are indexed by their position | <t>The parameters for each challenge are indexed by their position | |||
in the WWW-Authentication challenge list. For example, token-key-0 denotes | in the WWW-Authentication challenge list. For example, token-key-0 denotes | |||
the token-key parameter for the first challenge in the list, whereas | the token-key parameter for the first challenge in the list, whereas | |||
token-key-1 denotes the token-key for the second challenge in the list.</t> | token-key-1 denotes the token-key for the second challenge in the list.</t> | |||
<t>The resulting wire-encoded WWW-Authentication header based on this | <t>The resulting wire-encoded WWW-Authentication header based on this | |||
list of challenges is then listed at the end. Line folding is only | list of challenges is then listed at the end. Line folding is only | |||
used to fit the document formatting constraints and not supported | used to fit the document-formatting constraints and is not supported | |||
in actual requests.</t> | in actual requests.</t> | |||
<t>The last challenge on this list includes Basic authentication, a grea se | <t>The last challenge in this list includes Basic authentication, a grea se | |||
challenge, and a valid challenge for token type <tt>0x0001</tt>. Correct client | challenge, and a valid challenge for token type <tt>0x0001</tt>. Correct client | |||
implementations will ignore the Basic and grease challenges.</t> | implementations will ignore the Basic and grease challenges.</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
token-type-0: 0x0002 | token-type-0: 0x0002 | |||
token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 | token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 | |||
8016503040202a11a301806092a864886f70d010108300b060960864801650304020 | 8016503040202a11a301806092a864886f70d010108300b060960864801650304020 | |||
2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 | 2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 | |||
5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 | 5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 | |||
ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f | ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f | |||
67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b | 67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b | |||
skipping to change at line 1388 ¶ | skipping to change at line 1465 ¶ | |||
ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2 | ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2 | |||
GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=", | GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=", | |||
PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6 | PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6 | |||
a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z | a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z | |||
gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC | gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC | |||
hallengeAttribute="ignore-me", max-age="10" | hallengeAttribute="ignore-me", max-age="10" | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
</section> | </section> | |||
</back> | </back> | |||
<!-- ##markdown-source: | ||||
H4sIAAAAAAAAA+196XbbSJbm/3gKtPJH26dIFgBuoKvdXbS8Kb1bcjoz6/S4 | ||||
AkBARIokaAKULDvdp19j/s3PeY55lH6SuUtEIACCsrPGNV19ulynUhIJxHrj | ||||
3u+u0e/3RZVXS3XHO1so7+U2v5TJtfdSlqX3+OzspTffVQu1rvJEVnmx9k6T | ||||
hVopIeN4qy7vNJ9vPirSIlnLFTScbmVW9XNVZf0NP7+Bx/sSHu+X1F4/GAt4 | ||||
S50X2+s7XlmlAtoeCpFvtne8arsrq9D3Z34oLtT1VbFN7wiv78l1sb5eFbuS | ||||
/oDGim3+kbuGD5Lt9aYqhCgruU7fyWWxhpFcq1Js8jven6oi6Xllsa22Kivh | ||||
t+sV/vKvQnA72L7w4F++LmFhBjC/3fKaPuEpnRWr1bXzabE9v+PNN5ul8k7W | ||||
yYA+K6FxVd3xXqyV/uql3F54byW/kuQVzPV4t1HbKl8XPe9YLvOs2K5z6c3G | ||||
fjDip4rdusJFebPOK5V6pxUsU+kVmTdfqS0sNT2lVjJfwkptcEB/lNjZIClW | ||||
jVmcDrwf5DJVH51pnFbqUq3dz2kij4riHIb79Omx23p5SY/9MVlsi1W+Ww3g | ||||
2UYPxwNvPvDeFkXqdHG82OZlVWwWatv4ljo6Xha7NFvKrXI7SuTVHxdKbvL1 | ||||
eZxX5WCtKiH6fdjkGNZUJvDX2SIvPSCw3QoIzktVlq9hVeSaaVY2aZZpzIO1 | ||||
bdBrT0hP0yPQpSrV9hJ6bL+8UslCrvNy5e1KWH9spEFrA4HnprvHfO1VjYEm | ||||
MMJYcUvxtZcsc/i0FFXhbVWq1Kp5nqriQq1L7yqvFjg16PI8Xw+8E25HLsvC | ||||
aUzw1/iWByNeLtX6XJke8EOaIoyho4sBL+8qT9OlEuI7oOFqW6S7hCbz6bvc | ||||
+fOzEF2DhC30dutlvr6Q8bKxHsUWHlrI5uThZNrju7y2Kwov6iF7t0qlxKdP | ||||
/zB/ffz45OzB8dmb1w/unvTvD/b5yDZZwNlIqt1Wff58GzakHtK5WqutrHi5 | ||||
aaheXpY7tYVDX+DuKC+WZU4HqrmHQB0VnLSK/4DFB3YBWwqreJnDoD3Ji1Pu | ||||
EticEr5cMvV4x/OXZ8ePgdTneipiU5SlKkv8mh+3I/FosWhzikvFy5RX3pWs | ||||
vzlXlXlB0NDTHlFEsYPPl8viCpvFeWzV8hp/38htda3pyXzHA/lHvVviFn7G | ||||
9HIb+8Bto36R0vA77EiuEzgz0AFQx/08y9QWt6W63qj2ahW4mjuaX1o/aBeb | ||||
GoIJAs8tlnDqXDqAiXbT44EDDvxwtSpuOubiFhDN64fHsyDwe96p4m0KAqCM | ||||
HvdVKSKQHi83rWHpHhR9FC/lFjdaXOTrlGbcPdBj/SJImcYW5DDcW/pM3gZO | ||||
UCnkXHqZiCtoJoG7r7bAV1a49ILXrT7B2C5/huNabWg6tC1wSrmnZAcctOcZ | ||||
BmDfFWZSxLR0K4abdAn3utdbZpxKvH37tu88h4RWbop1qTzg0Slw9SxXy/T2 | ||||
wDMrgfuLj8ODOGOYHy60qBuHo4h0wcdlra7gwfc7OGp6bLDHW+4jpTHQsOsB | ||||
0aBrUW/ePTAYwwAMn6I9X8kqYULnNbMHozHG7W69Nn0eoGZgUP9ycnr6Zv78 | ||||
+ABzMk9+/jwggIUrArSkmTEvgW4cWPpaNCbndU0O2QaAFQVrhJSBR6hNH9hV | ||||
XgpDdNhSrKorhYTF3BWpiueOzZWL4gof4cP+b//2b56U5eW5+F1f//udd+O/ | ||||
+jnxq/eCm/315ld+1Tvk/Uq9/O4re+HnBLfwdf9+Ffplr03JCONg4Y7tpvf7 | ||||
//zrX9D2jU/fer3rIJzbf0k3/8SL3DwAehJev19vwm9rG/ZbfLrjfZfl532Q | ||||
QoCC4EiSTnD36LjBhxwOZCZCrOgIQAEwI5mmOX0JVAko/QKpm470V0gFlyWK | ||||
gvqAnq9BYG42ANNLFBd4cNxjjAIezliR5CThqSsm6n6yKEo8zwUcgQ+aO5cb | ||||
leRZnhjCR3xaDrzXLaZNTZuDZ2atVkL3jNwNWofm4eTaJlFI2OH18EwCCN8W | ||||
wAmQ9yD/zfUcElkqwow4H5pnyTKInqpXKlWbZXFN0m9VpGppMNwlfVnsAB70 | ||||
oXvikYBVoPu6lbiAlbCnH4DFrQKhmaoZPIgkfAUgWN95TtyCDvqZAu6o0tu1 | ||||
jPvuO+9MbQFNFMvi/FoQ4gVNDDcZROPRszenZ0c9/uk9f0G/v37w6s3J6wf3 | ||||
8ffTx/OnT+0vQj9x+vjFm6f369/qN49fPHv24Pl9fhk+9RofiaNn85/gGxz/ | ||||
0YuXZycvns+fHu1jbaSOihAyzRBmVhHgEKkqk20ewx/wzr3jl//nfwUjj0FD | ||||
GASzz5/1H1EwHcEfVwvaUdzfNRAk/wlM5FrAFiu5Jca9XMLGbvJKIilLw1FB | ||||
54G9FuLNegn4z4NdUdurHDZe0w1iueag1TqBzS7r4wUkWkrYL+zl7OmpWBeM | ||||
SL0MlDAcKHwYDO/icEejyefPNeQZ7qEoIL+SpRlsJuwbc2BcZObZ+NsJoWPz | ||||
Gx3Sl3osR0xmR8RvjnCWDMtoHT99coE6SjtQUwxDwJMsbO9ZYWErjQPeXhVb | ||||
VR+mK3ld3gGVxOPBIKnd8Z4oOqUgukHtlct9lcIAm30hjRoRYJGKTmx+vlYa | ||||
UaHao7mnPRigxdvDj0dJn3rSnGjJrSJGslfLUw1/BU7vqC1mjhhruTKcBbSD | ||||
t/IUn85ywrhmIYSrsBAF7s1t0B5/6TnMM18ny10K/HSNSIfZQpHdgS4cTq55 | ||||
JClcsI36zz78BGVb63yInaF/UJiXoMwT/K/5rsadhG8sU4MdupTLnWI1DBdD | ||||
wEbFxY7grIOpWOcpeZapsyX1EGFP1kbfivEE5qREaSijoVRpgRTui9kkQaiK | ||||
N0Bva8+roeRRQ5R2bRRqw4ftYKAb25Xv1wMGcdieA05Rw3xYMh5BR7s3ai9W | ||||
PdOaw5GrzhwNNPLqUgAc9d+sEhNzfeg0lUH/9nVUpr0XSG5St+QtJILPRIGw | ||||
SJtN6X3ERkhblks4cuk1vSGRFnJ96oS8lPkS1dse6px2+xySKBxsjiNyVhaH | ||||
hOIHDkBCPDUTHVga+2zul0sUpHij9cSB0QJeOTLy9Mg0NCBcA1JObV3xy2aO | ||||
fJmDoi2TLaj3LsTZynXJ1AqywJh4rnIQEUVWqbWzE7X21tpLFjUFLL2zqzB+ | ||||
UtRXu2WVb5agKjo9mUUrAdSYk5FnmkvynzS7sn6Kl4pOKTFg4F64RNTpvCRT | ||||
Ra1UFrvzBely6gNQDAweYQmygjXafXI4WXp3qT2Yt9xucxYN+Ig9e8hTQS1c | ||||
1EQ6YDyxVcxYGAdqwjei2qWO5BAkddQd1H1YqKSqAmrTGIberyGtc3jhxJp1 | ||||
hr2pSbvuDIWIPk3MUzr4vMs5hD2tra3lw6slQLfdEM9MdVWAsFunaF65RkqB | ||||
LYP5gWDE9UQuLfO1S/PNdZFrQhvug3YJ+4jdjDUTjg+a9vCBW/giKAB5hqL2 | ||||
drcmPqhXiohLA/SumXZPbq1YbwViQ2tjCxHI8oIWuBY/euR7Zgh3sQEtBANg | ||||
l0skTZYPmp9BRzBTxm/QJug4O5ZH5gHUAmojCy0NcAMtOXEkex23lpsFX6M5 | ||||
FGfcAB4A0UG7PCBnGHXveWlMpN6m2ABzqFS3HUYvgCWNAS3Cffx1hWC/U8q7 | ||||
Yh27cCbaYX0iLJvmZbIrS4PzugHCwN0Bh3vnaxR5sru79qoYWCQJLODQr4lx | ||||
s2KzQ0hD3LZvERiCsx7BujV6LBzNjo1OZOnR7MOMqCrVMiNGBAK53RRZygzI | ||||
cRVF0TpJjdZw5gieauw9IhdNAxJTl8Ro3UWRMVpysUUjQkDeWmuNO1ukmL0R | ||||
43HENyrCXikI85JVSqDyFdCHYxY0+3XTcRKAr7J8W1b7B3CPy5ReQ5NygEOf | ||||
3yR7/KDJWB2gut8APtF34Ic+tprtapGPx2nV8bL+2n2fXodxgbyBWRCRftch | ||||
B07NaBtwrp7DIWs0bZrKJMhjZ13se/sqCmMFfcjIkg4zXKIt/3wB9M0v1V96 | ||||
oOiCvK0UGevQDACcmeW36UOQxHQU+z94DOOZn1AzmvLYR3AOpL29do+lYH6J | ||||
ro4YCH+h2FriTnKrlvRoucg3ljaPqIt32MWR4WZscMHN0uNqGdi0Ngv7MAc4 | ||||
1GakHhkQYoXUrU3BYb9IKlWRbD9HNolL6gzNWcseksEaBldsL0BNqBTjNs1T | ||||
8Al4ICViL5tODqsoGr5bG40t3fOSaNZaNjeBrUsKpDWcJTt1DWhE41HywRqt | ||||
iHdDbZmCgU5O5s/ndo967V00Rm1aJgF6LOIbZ/UYcDjkg0YKoFoPoIAR07Dy | ||||
D9Dji1YMWN7z/FKtnXdqE8ENdN0TPL33u3yrVrzbzM4Z2SakbFqjC7M5vSgk | ||||
rRnLMrsTGj874x54DxEkfpCrDeoI5HZzp7XKEYrq/pkijpjJvUOyPhKw3WjY | ||||
IvnRQziAkgHRkLG05ZW2DNEjGoCaGXeTLGOyBlaxC3KHbOZCc9dPZH7dwfyD | ||||
yTtt8aRT8gf2e28kgmUW++9QtPxTMBiE/yOY9IN/bjxSS+93Wub+kz8YDMPm | ||||
U87M8Wvb0OfWRP5AY6SZ1oSrt0MSUGZbjiz1FNkE0zjlCFjbR/LAses1OLQA | ||||
KXepSLk/cmbOLa69+enxyQkOi2UNKpK1PcQBSbXiztyLDBECHfcGeTUsUvxF | ||||
H79g9wsSBuGzztaNJYJohJVC+qZhc9bsnG3C2q2M7Rrn/Jkhco2OAb1TL6jU | ||||
8Pw09KmVdLQMgCaaf7BGrD22pxmXmT2+Vy0OMTxa5X3i0dvnDA7+VjlpCT6e | ||||
2GFIrYBMag+H0ZUwY+oYi3er2RJo6SeZ1i2bxzHnNYZn+jRmekY0/fQ1vHJd | ||||
tO7HRfP8W0enIsce7ZewxibHyqHXgqizAI6oGf5WadJydvpK4QFhWzgJUGIh | ||||
1qVgIF83HGY9l1mYZ70Q7Hwk9sWQADAtKggbUltR7z5usfP9bTRmNSD9fM1m | ||||
Fd4CKz49Fg1sS2twxsPHzVKC3qXCao6lp62HhFxdROxsjmt7i9E+VWxUe+lL | ||||
5WBqWL4HgMrc9jzHQGwPt/f1h1vpGX378wSUrJdFrq+JlrWXyc5NI5kmb6Aj | ||||
UNlx2QUVxoDT0C/Yp6BZ8TJf5dalhSEPaJ3qHdWBH2syg8Jh3UggG3Gi7SbW | ||||
QYwiX48ZR6B9skQgVgVDuX2l117qbaYBC95ezahQGUI7WNaiJUsfB6cD41gp | ||||
uS6b/A6HR3QrKCwBZqKxgVFUnH57erQtpcvR8NMWM73F36126LxboicBt8SY | ||||
3Jym0TrGvMgyJ4OdOzQJjCrSqmnj6CJVIxmViKi2ytFVtB+NNRggdStGOBij | ||||
Nv05QQf9fmu+zRXn3cU4OEbbaw+NA1sTsMIqoGZ+7Ay1W9q1uJaDGfXIKqhG | ||||
5bf6qbEL8JOsRn0Hr9PZfI4E9AAdVzjsT9+5J1OI0/oAl4ZmNODdVymha5c5 | ||||
GZnLb8ELi6KssCVyRFlHAwLbnt4AgqFoj0IbDHDfnPkQ7NnRaDQ8wl1f5RSL | ||||
xTyDx4WOWST8mvNUOqgP1q26phY1ipXem9cne86vWvEP8aF/gGfQJzecRRNU | ||||
O+uejI/UHkPpHUHvW95ht5913X8LEWtzegP4WKmi8dVAP41hoEfIvjs+vxPh | ||||
kvREDBwFGYZ+5I/uq2avX9empGMtiI5dUxJozl2CkAFnC1J3mKU6RbzVt2rV | ||||
8gOdYeMBctWXPeZL55URiP5Oaku1QCuKcfKt0eDdq80dKOzRnwFoKAOusVhe | ||||
O0GEW6A7+I5gEno4hQ3E3CrDYzBkkAQm+v8VxxQYLV0b4hUdLTh/qNro1RbO | ||||
40jdKwWbnzK72LPFNO2ydhG3ygTx0OSZzWlh8GEhgSfmGoWbPXQwkl7MHIYE | ||||
6k1aXN2pd7hzy0pQQx7eSnZbdnvUL942h/EhQ71NqXZpodcu260TjpvtHIVe | ||||
Ii2Gv3II/M789Pn/S89783eMTzePR3jOiLqXxDiCfsMgxUv2NlFYJcV7eMY/ | ||||
Rfo2SxMNg9tH50KpDVOiaEfIsPLeXssB+ljZ4tqx0ExEDqIGqa3p9bpF3NbT | ||||
A4eCj8Je3Iqdh0BfQGlAI6pKKdtSFnJrzWUUXKFnxhzPUcVkkqhNZRZjB6u1 | ||||
FLUpXX3Y5FttfwAxqUMnmJvKWu53zJhgk3CHa841Oua6hq3NGAj3XKDbHDJ6 | ||||
AUVzzHpPZBeB7/laFmw2aj8HaCsfqEEPladaRyYnn0OldmoUvtR4yvhtycS8 | ||||
LS7ztPG1g0IMxGSvRpOx9xh2rRWiJ7nNMXyLRsxLp0mVCEih/TFRmiAEr7Cm | ||||
EtoiazQGvLsk102ZkxcWyXyjeFdB9oOMAub5ITd0mJdCUw93GquMzWRmysXh | ||||
VQTCkPmSjbCi3CU4DfY6lNdrzHpYY4S61uUpnGSdEnTIOVakQS71ZMifwWrS | ||||
8V6UsdE4CwJrLxytl/RPjXFlVlEESCOkUwe8sJ/PfZMmqFG3JSQGbMw+Wgbw | ||||
kkBbw/QuxFvEl7vS2iblgVDh3mEfp9XoRG00cx2ZqJ7ado56WqxbvUJiaL6a | ||||
jHbbZZ/jolIdmTWajKLPbQMXe5613Le2em3Latg0NxiXBGOJ1UJe5rhxjidB | ||||
7IM52yMxtYpzBnhgGmA0FCvd/EDMWdtuLtxLswDerT9TBhStyJ9tPFdH8Mcg | ||||
xPAPOnANPKNVdoOjiam93xXA6fuMn/lAW2joHEBBcKjxMIcLuHOzBiuaF2ig | ||||
d49w35H+YP90kLHdUI5L1j2QkoNBcbWXtLYmIm++cbs5DI4EHY9pAwcLoyyB | ||||
p6PLGs/cfq6CjZkzZn5rTHIcjKzymJjtz5+F1Xn2nXILOLF02p3ujXdWt7wf | ||||
ySrsKdTGAWkispU7LdGaFtKsgbu29drq3enWIQqjdWgco68mUI8IVHwrAqWT | ||||
/q0IlPC6+AYEWnMcge40aLZY5VXFfK0Osm0r8BRbrFNwtgr6UZeNsAHYM8Gi | ||||
FmNmdlW/yPox43adL8YEv5If+pK2BZ+zGqtdY6PgloDVrZ6w3q1i+A7+KhV8 | ||||
x1qA9tM1bSkUVoRLRZiibT7Vno1G9gAuAmkshhrYQoWRJtsU7cZyCQqjHWAP | ||||
Vx3WNieD4skeuVN7rAqzgdTh8Np3A9PQRpn2Pg9s9gzTJ7u06gYoEKSWUjbo | ||||
GxUao34b16Y5icKygXbwSutI7Rni0StJHNsq2l+MO8H0TPjvsiguQNu6YHCg | ||||
3UF72QagJrhSsu747pGMk8FggGfX8Me7R0E4xM/YbfOdK76fGYNbW44LcUJY | ||||
HRPOciReszg3T8KJy7CxZc6yHwhJHEwGgQ7HM06TthZiGLEwQULNEPeGH7xO | ||||
y9t2DagDyLYdhX8Lu9W74TWg2L3XwuGo3uQW5iVVw6yDsx+tRTQJeXsHQMsG | ||||
o1FSRDAePGDRHDdr7A28jtBzJckWwukD+82RpasWnR6gJ1UrCXU/TtMY3xAr | ||||
nVoo6lFbLsnTsUFnxnOOu177Y9Id8XknwUmc5siGXG6dbRVH6XFyhkYXdfwe | ||||
WtevJJEdMdwdKucYl6wNNzaDZKNDN1f5B4o4NxTYdrXXs6mn7lpxyGe0Vjbr | ||||
Q9uaoa8SSGxp3QP6vHCg7IZiUtGJLsz79RwwO8ci/luZS/zApXVfTiA0kIYw | ||||
/p1MlhXHw/Fi3yZXHArqksylxiXO0T+OmRhDTJpRO9Jb5OvKcFTeA61hvGTT | ||||
+QElY9+wLsSbDeW5JSrfaJePG31mrApk8LSRGy17Yh0No7W9Sl6wZL7WYeM9 | ||||
m6dLRvk689ACkzpf1ibbrpvZiRS6gYMwiXk2+oHzkBpu8zMjat6xqKGo6eIc | ||||
FUht4mCO6GBUmugf9LuHZogtXanlss+B5H+gqPx+k5IaenrD91ppM3TTKeDV | ||||
odscxOMdVPZakY21M6UVLDfwjkEvl9u8JOtYszsbned6cA72KM9RO6g8teTV | ||||
Fp7p2J2tMXWmeAguc0kHrp/zYaMUKNgwSQHboJomFyV7tC7rHc1A9WcnnKE5 | ||||
a6pnR44lEnu+EIimOvZFODqGBTUAjYhHZrstHVkMCdrmOmCbo5cbZITmNWHG | ||||
hMlzHKXTWH5jCSGbE4I+QqnIQ/G9pki08f9O0hrK1r3QIdoN3kjXwYscxqJO | ||||
YcyaMIK1RgHauGwcFZKTzWBcxdYFXWdPT70EuSKpQ+o2pk1LfQzZVNK357LO | ||||
8cv3Q0+7A/l0U5++M9/XWdk4cRvNZTm58cTpFAiOHW3bsqzjjgMOcS10iB4w | ||||
WY168hUl7pemjgQe5lIhgK3DJvNVnbgo6sR6zplofe+IOB4AIfX9FHV5WeSp | ||||
IN8pcHPEONgEJ2Zgx5a1lXQYOjVVvQkmGYrXijCHG99CJEiyk5OmyRjbiOXS | ||||
kcPN5bvjcD+D7Sjkp9cR0tBz0pHpONd6gU07IDMr74cdsD1/9aBKM6we5XTg | ||||
MnnV9lrTYuv8cjBhoZiIaX4D73lRae5EaQq8bSybdZ6DcQmw48j4oj3rYG5n | ||||
/uwlsBDrsaKNQ0zY/kF8Jtsn1Abt1XoQ2eNFM8yiK7OrafJ/53jS9qWpwOIT | ||||
Nnzgts1g8XSWJh5J1BRdb7O321BRgl254MA4PG1a4grKckoAcyMm+vTpX45f | ||||
vHhy8uC0TpdfVNUmzsv+Nksm4WQMv6KlDREpbSkLPWlcMMhobV2EmlnbbSSG | ||||
SyejFaPBoyLc7w5pIN4YW3g9H5L9ZplouevczSsC59hVrDxb8IQ5nY5nIbu0 | ||||
ibfHp9n62w5g0oDAkoKbpeL4Wz9918wsw1Z21WZn/dQdFrCySeS1KmwThUzl | ||||
Ayf8wGQANsIeHEZr46RBUfZMbiLSXjPimQJ4TdkazGPRwTdu5JkNxDVoixkF | ||||
HyYSvHWNBhdHdVGsG11bO33FXxStq6dVt/g1sd+tdzw3UPCvHPdNb/32mG9e | ||||
aPFNYr49E/NtxnTWsYSt8NpvHlWLX0TvNFP+0zD81+bHlqTfpTngnWr/CW4Q | ||||
dPJ3efqn53na+rpR7eZPzy/+1QbY/s3E1dLUj2xwJTemzbFuthjzmv5eUAO9 | ||||
P2g6ZfRyfbFV3ELYyoUJILNssA2qTh/P++F4cqv5ufWI66+pOxthIwj7/cPp | ||||
49O791+cDAJ/MPHD6PfPT07PBg9PXp4Ogsjvjyg+HkVDYzxGMycIUWBMBbqd | ||||
WYGmdEfTI3N1E1RKPbe1ROJAdTme+izeKnOdgmPPgucqzXoVdR+xIqflDpfe | ||||
mhCWIGm1gVczDtJkSA5pBtH0Jzg0xESr9whI19CRCXLeWlagUxmaGcfwOnsn | ||||
eFeLdiihIWDXJ/HOrkXDyCq6QCaMs3F6zEAv9DgbXxq9UJfvO9/KzQKNJYhK | ||||
DdipONMgUaRiNFBokx+SoUNP041uc5NfWp4eO2vj+awtUyYluK3bf8UqNCOZ | ||||
3IVuVUrT/WOTC85TII2PqYXDyOzLFBSE9qznF+jHoNxeExeicXc7Sq3lPWpX | ||||
rmMlctcUs03bg6VcMkU16aEnTCxVi/B79anRxKp3DWukWRzhKrY6wC038tjd | ||||
SR3hQP55lZY3bDbn/pY6hLFpY6yzejAOtmMRulzmpesWp8AsXU3JrSLQ6RBv | ||||
nTntHzfyFo+643Hhc73vIW04v4xLXLi7RC496xmtkZ3jUmkl+LfcheKL7sLf | ||||
4s8WX3IXftGfLX6Lu/AL/mzxJXch5qTt1hdrjIqGznfr2kjnLCDolTfnOScI | ||||
1+FPuewKyT+uI4RJYyS20z5pGA5SB+yyEHJrWDjlRpoFwxrujgbkQJTSKhzV | ||||
cFTQmlvfBoOahzoNAMM6TezXhU6T1a4KUsvJNNbML7U5D1zsjGomtmwE9Xxp | ||||
lrbKgrH11ucU+UTrXZ0j3JXjgdYmHWJpK8rpKi0Y6WrzYU3oJpvRTH2nzJjS | ||||
XPsYQbEr02pZhydppRgjjcmKxx5PFC+Iht0yTW5AEAk5/XetqdXlPdBASryU | ||||
zUSxws22JpnqilJF7h9oHCax2xqbnmMARI11qzZLeW1ixCkF2tSzdPPZOUiC | ||||
H+7LqpLJRXlAgOpQCX5W6GfZCtlNObreUffYcU8MBlvr+EGBvQIaW8klf9Dz | ||||
WnjrQ7u2qJbael3ZbAN8tmxosz+4MuXTdw35USu4rmue9jZfo+Z9AJ5wbGRT | ||||
nJiKGMYDIQH1nWOlKKpFJHVWaBtmNDomk7VJ1hH7qMHmWREOSaqbRDshayvG | ||||
ybxnCh0ic80QtucfjZj87V51S8W1Ssc9a02P1u8/Xbf77IqxYnuCg3I0OReh | ||||
lQ11bj/v3LXtMThsEIdoYBfayQZc6wzzMbJyzHUEnHAlzmg330/a39feVNNj | ||||
Xkfjl4eDJfZmVTfpFIMh5qSSHedEtMPbmYP2PDU4H/Q0Si9iUyeHrWhrFvYw | ||||
DjLhdZKoTnICte+yuGgTosXUPb2KZhEbiw6M/RwdEouVLY/cbSiTN4ddUfkn | ||||
nXV9z0QLfvpOq9AmftBES8o6BpoqJDVS59rJLiRUbClVkmAmdFo4dk22POuQ | ||||
4mRRAOsnE95KXigyJEDPhJqgG+Tw+1ZudAA0y6w2LIADpw33ZSMYltc2CNU4 | ||||
RDQz73W4xEzKhH7Fejk6FEPyWnY619ESUJK83nPiUzUXImPHYQuHXSNG3INy | ||||
F5c40ToW3bBDrMjINn19rs16ts6jddgbFW2zWZqq0GjRRgesYWftMo3GiGpO | ||||
6KE6IHWGlTGb3VD6kc2w3rETxPya192oJZRJ4oyzdPxozXx514vE+XGtymBi | ||||
v3iWi84acdFIhWaV2+E40ro7Facq5Yk2jWIUhg55xtrfnEBKrVr4h3uAwUAI | ||||
2FI03djUx6WSW5RWwuI9fNQB3S466Wn7+6427dfOE+s9ojrfuK7YknDgO5VY | ||||
ZlKxVaANcdS1vTgIz5Q10otqzoWp4XfjCkqHUp+R74KOo+1qr3R97ae4LJaX | ||||
FBHPmQbMHijNeEcWp+2F0HHi1xYFuzmGhfEnaeXLAkUnOp3TgY13kMxoObqH | ||||
G4VR93bfbDm+6Kw/8bMrAqHYwE4DORgTGqywdkSjopuupl7qo7/lPSEs5eyE | ||||
nTptxVadY2Ilhjut6f4E3FVD9to270zS0Te1j5wZKfVkd22VV/m50Uq2eXkh | ||||
LDywvZv63+SS1GRgXLJmKRsDkeTT3LALPxNO0fbaJau99Xvig6p1oXRH7y+J | ||||
IkInrPVeMxc1Ekm4W4yusvU/1pW79notKJZ7t65L0GsHumMNpVwTzAkqtYGk | ||||
JWKcvM1GZUbu7DbDRCQlNBr1gU1c5hw4ZgBDu6TSeBAcYKUmusIYkJgBCtwE | ||||
9P9S/lSO4AbmyNXUbOC/ztqxB5mNO/jGzcXemaWS9liHVeydG8oP3pNGpfWp | ||||
t6ttldYv5qntFrAD6mUIH4AjJqSk2YGbgitya7yA1o9HBKirUTSOZF47nf/j | ||||
3/8nmsU0Miv2qqQTZljrGxCc2qMc5W+y0zlhDzAgJuduSTOTzmC1q5M5MJKJ | ||||
oNhaig+7dIOc95aBiEN72zvydITLTROpk3cNYqIahZTsyKa9jlnW4RHI2tCm | ||||
jOZM2JblqkYqOnGLIT1NuaSCvsxjLiXSkRMAVFdtrcU3y6+WA50OKquSxmpA | ||||
FFt7qjcFLOG1IKYDei8nHe0tWLsgCceoE4g1NRaaqOGeduLZ8OFGbJ7JkOpr | ||||
X1/fQLM6Wq8kvViHy1jo2qqKSyyrHbzb3uGB2BMWVcNlUmqyMS11Bg2Lmiwp | ||||
3kNDCQfh2ELdG1vqU5MxKkIM8AGFWiuJPctaxa3ZtY7JLWGrygwzC2VSUYlO | ||||
ZZI5nLHbiFKtDxLMrOPgb8azxhCFLHjj2bKTmirqEnlW+OsILcd/jPfp1LZL | ||||
tvLw9HuN6ois0h56koK/SDEQRrmoT5lzdwnL4c7AnGbgiTnA2FxHecC9ePyv | ||||
qU8gjMvDFicAaHwutylX3M60a8duAtakoLJ4eWUOpOtsE9rsQtgbUALzGDap | ||||
8Xlz2rIxJ2jAagLPuqxfjVN1hGdLxZ9wktmBUoHWh2ErbJFYElTawIH6lmvZ | ||||
8SfXpLzqvEBHedVxMY7yWtcN1pHTstrnyQhcFVu49JkwtGT5oWA9yiQou5oU | ||||
Rxc01Ro+HIZtUN+l2CNmJzOgM/HVvckCI0Hr3AHRyB6hcOuaTZWk8HWon71W | ||||
eVpNJVSQsg6eR1ql4uUYsazDMFnO2KLhjVi+0g1XFx3h6h1CuFZQ6hopjXw6 | ||||
s282SK6RJUuBhZpHpHVgmqEUvNPMlCBZXuNdWG6sPMXoaDeJPCyKee9NdrdF | ||||
myQSGEc1GIOperrT1vc0NUSOVmkTvG2ZjHCYTBOrO5PXh/iApHQIuNTgoFF2 | ||||
WXdkI+XaF6ugJ29/2kftPNHh/hG+zRKJIhAtuqAVcS4M0qQtnNJ9FiU6xaIY | ||||
4zhybQHca8vhbIhLWNA/2ipJbqHOmtXm7VglxUq7wTBGu6JEIRpAHergHAd7 | ||||
r5hxdWiJrKNGGifVmnte021qsIwmOPzoHAen0iPBEurWYb+0KXROEOmQcgBA | ||||
xLlboKfdve1kPqNy6pQx6y+8ZWzxjMTZhiK39Z1UVkO1GgRe6ODqo7drH5he | ||||
GF6Q5fV//Pv/Fk2lYP86Nudmga+YK0l8IJ9NaftsSaR8W6sG2DbVVnaJzVF7 | ||||
RUtHQYGYm7I8SJTqg9omOa5ELQyXLE1OjfH3uKFrUf540m8qYKZsqqnlbbVB | ||||
a0FuPm+N0w235CHHuWOsbtygwUfhNe0FunyAFOsQey47qilX11Frow4nwkc7 | ||||
b53idDrjs8P9Q5NCXL/bMtTb1kO49enTv2AOuY/FgLQt7zV74ubsMIOBubY7 | ||||
TVHsUZW21q/2czZKHe/4apGGsKV6AwndlJZy4QXqyzrnuG9H4ddh/G7hBmm3 | ||||
SRAqZG0YyRJUFhMKUKuWFae4yLJgq0EdHKGLHbh+x7yW3+5BdeWLhVagEaOJ | ||||
COnEU6ADJIZzmhjGZtkR7aTRdw+Y6NwB3cFpsyJ1zS5bMSov2XQK8CPvYB1s | ||||
HC2tsu33X5+debCykrWH2p63Pw8uro7Sx5nAHuuo3ce4c0Dtfb1g9eWTbQvU | ||||
Qm5X5JNETsZPW8ctXQlTB1xE1m2EVDjz/aD+boaxGPvBMl7nIPhqG239Ftxc | ||||
NJo6sR3DPeu2bq+Umeo+8bSaHCSul5ROR7bUTdoTcnaD86kNVkk7b6DRK+Pi | ||||
cFN1XAtVB7hhrced9IFm+G4PU5ibX2sZXzrqljPrpzD7+qIqq87TAhgXig4Q | ||||
qijBRCcAOvcMfeXNbb9z7ghr3QL2pRvcftX7AFNvXyz2pZvc+IODvX7xRrfD | ||||
F5nVN7u1gkPwHrcvvNX9PbZ1S699TU+3vZvvhTMXs5mB1Hex/c5e3FY3S5sP | ||||
TR6+7e7GvhrXtRm+ype1vXb5vCE9vJvNxjw80FXA3HOlXZd6ExcF1We+kVrd | ||||
skME0hv55qitvDAKmXbNOq2hpYdqu8HYTKYN9y20Ecj4E85q8MqxmXgSFnjp | ||||
1ppiwRwbeaPmqK5WaxSEW4xtbbEnJ8/oNrNPg6Kuu1OgsPaCFbsvtGV1vgT9 | ||||
b00Jb4g/88yVGDxhfrTXuBcTZLSQ+lVla7w5MH2Fy2dCkWzwTz0YcqKj9gbc | ||||
RbimXVxovey1LDT21npZ2TGvN5ttbBas4uVitTfQGcdeTEHWZJgLmRqZK4qE | ||||
8gR1hce9omoDczVSO/vQ6BWdG+XFuQ0h8nStJFOStnWtX0ng5NDNBJhZZHAJ | ||||
ex+5GBfSgVvzgLmumwuJmkyd9OqOjcMKBx4VVs9rn7bVnJAk+PVeHd5zgNLc | ||||
W4paKr/OQuPEGAOW3ay5PXP/kWyWgSR1s2yo+s3Lpd0JkdrWaKAXN5rr1ddC | ||||
JTp6vhkL4NROrlrXnWX1hXp5Jo6aDTfqk6QHRyduHB1iPl4hEtioEfGatPoi | ||||
2l2LA/OP9+toNj7qyfYDN46ql7RWsFrY8sB1XpnOtDRXKvAS66+1l3lHVu2W | ||||
VVznj+Wk3h9jnBan8NS8/ng/JM89iB0xAkVM3h0akqMxUOEE+yasLEA6m1PR | ||||
cSGX9vuXuj2Da5wpuPU92bWFKffW2E1+8rxiexEm8S2vTa6Atnw2b4MSOriS | ||||
791CnoSsk0JAPuR4ieDyuo61RP502FkGXThT7bhM2SaGmiKQuvTjWVBX6q39 | ||||
gEvgkXHTL2pfCKnkQbHU7nnn5j/Hu0KXgNGB0kmHrTu/zkJ23+pLuRyDml5P | ||||
9/oy/BMFRIa2I7q5nS5YcUxodoFNuKodLB5RMuuUeO1Qy/RrKx/t3WjtRLob | ||||
QsOEN0xRQwU3TbU90MQWYmfaKSVYGjq7UV/Q2iA3DpDiVaL6FjARd9okOZD2 | ||||
0A6osXq78jFpAvUhQp9/aTPhmsZUKsPQsPe2bPwdBkLtnSOoYMqRPnWGWJsG | ||||
9vPgu8RZKz+XAj46InBFM1fXJOZS8IPOntJZZ+xTs8ZdK5fqq8E7dCZdGJGv | ||||
asemvUaqqx4sGZPotpM9Q1Iu15Iha+eNi+18THOHSvnlrAtTlVAnrB89vkYV | ||||
Egd9hhfpARuyV516t1AhvX3g0sfXOqPyqJWhtp/qMBmMaKO728HC2XdEMw5f | ||||
iJcFFXkkJOumfHk4VHzcvWjJDT61qVtmcRzgf4ahuWbcsMquxVUI2gldvk+V | ||||
2rVvr0xFs/BRIx6ibvPITS/lZ0XzWZsfUmJVMfZ5crUOm5/GCLOjlJ5b46tR | ||||
828/OqN7r/WdpMLti+4jvSqc2ydKW9cReFa+2q1qhcYETQv/w0P45931JuPx | ||||
cAxb+pyiXWjumnaNbKbZNSOgQSUDNLqrFGZi0A1AuJFo0bAj6UjXs0Gs0Jsm | ||||
ledO9Zb9+4s0tD6tU2i5k85bmdzErnYcs2npCehEprK7aaxdm9Gp6ejUtTvU | ||||
ZMetWzeOsrMGTosHwpnhQooc0q8ZKDY79376/XOb1GbvfNDIWmfRa0hjqlmB | ||||
8q3rMl66zdl6x20H7nAw3mfu0MieC9e4hOl+Cm5rYIf+DB5C+9dvHTVVdmEr | ||||
Vj3wlW7sWw+V+dS3Gqtu7a802OcXhq70DTX5muu26+L6emjNVA3xPE9br7mJ | ||||
9lyp0x5UIV6bYl340lvHnGzDz+sEWmi8IAaA1xlT7BxV09ovzg3Nb6/RxIOX | ||||
e8Bi3j0iR11SoSmH+A4+kRvfBfFtzYM5nCP+he1M1NppQ4ZobwiClZp16dAS | ||||
U+gvCsJJLcNGA3JaAMDjdBWV0hWw28oyPNEOj3CyQZz8YU7Ss6mTVGTuRhQF | ||||
inzDx0dro7vmRCGaZ5MJa/QZA5otRW3Y0begrZSqmlkMXH+IpUmjGpMrkhpp | ||||
EodvfdjDd41qeSbZ02yeVYvN7uFN8XzVgnae8lVxhypQlIDLtnJZP25kWSON | ||||
3BSrtaEHVPxClyTXIR3WOev6xNq6YVO9Ktv73oxlw0mt6MoO7b7ny15tdqUb | ||||
xHW+lYniYOhbrNWoZMHKC1UbKzfks4U5aI/D1Oe6kyetLnWgRsl3kG6by4Jq | ||||
i3b8kdO3cc/KCmesF8GUpgCMeqrXyQ1p44hfePxgLmPP5rHqcphr0Pgcgwv2 | ||||
vkZMLJd7J4XKrPIlpGWr9h/BK+1OF4eMZ9QoT3jQsDt2D184GZh1oSfjLjd7 | ||||
V+cH1GMmYNV926MjqOsAqwzUcMPj3Es02JDAGoXZAD1+9vjk65yC+m1Xe8em | ||||
kSnnlAttngrRkZdWozJzaLgw/EYRm7NXVbscxsVv/gcf/vXwZzif488gGIb4 | ||||
M3wwm+DP4fH9If4cjab0czyf0M/JfX5u+nD4EEuG+h+i+/4UP5kFk3v4cz6Z | ||||
j/DnvQdz+vt4+JDevD8f0ZsPZiP6/qE/ntbw8PWD0wevf3hwvxMJvnbW/RDA | ||||
63jmAGJrPskoBo6wgWBLhqu/n3ciHP68A07QFyy6+VeWx/R7Q9ieNRUdK1qf | ||||
w6k5JDvRQRODTo3K5xlGqf8AjKLYlq1ABRv4hMHPAALpGQvKyVPZrVhqdY31 | ||||
wWZUgneyX+XZufXa1HB1e+Q7rc+6xtAMVmi6m1lO7XNHDArQkdL433azdXUE | ||||
rCrAXCXe5ZT2iDEhVGzghgzuhpe0bsL6v6VbtlJzHyd5u9nuQIQHZk6rz0nu | ||||
ZY0lmtuxN3dhU1AOzL1RcdH4d+nS9ZK7FK0NNyPQ+bbLa+aTNNfDksGadAst | ||||
Hyz2a9TM1rFJFknRVSZU+IAtajWDpOhulxScqmH1pcZ/MakfIjNR17vNyQV/ | ||||
2Nuib2Bu5sg+oCS8ukexzDngbS9pmGsl1QnBWmdGeWnd/h2ZoVIrJFSDwtu/ | ||||
R/chT7BFCz2nIxTHxN7DXqu4i2eAdde9AwhRDOSrC9xpfLmBDe+bhxEf9t3C | ||||
iHfsdWSufs+a9E3aMIoPe/mUiV5bqA8S7wLnnHlyT0Fv+yUAudOuC3++WaeO | ||||
Y+WOG/BLnpYvddPqBCvTHuiGksP1GlLlhO4aNu0WD7bHpAAnj9vUirU9jz3P | ||||
3EjSiHVvJ8cjl/P07dS/qeOGWvqOc+brIk3lgdnZ+gc6vx/7tk91pFp/5aBE | ||||
gxUjRuI7glyMtCfTmnuKUDHLz3daTdOyrbntjctmDZkg/7jpoiaSFF/ZzsE2 | ||||
hgfaMDdiOW10vD36+rdvnMn40ExaF2yWX25qstcUbtS5DRA+2xeEzuVxFGLy | ||||
+9+7EtgL7uAnnsMibyF3vN0o7nqrecfg7R6/47CAWzozzT7RwZRu2andFi7r | ||||
x/5Eg2NOZtMh/G88GU/DUMF/o0kwSaf+JJmMRQe3E6PpRCZhMhuOs9E4UrM4 | ||||
TKcyG4apTLI4DcM0nfjhUGXjKJrKaTTLAhkr3x+p6SyOx3EsGtxskk3DyWwy | ||||
hf+rve6ZIQnlB7NpFERhMprM1Fj54SSdTMbQuQqiyXgCr4yycDhWo0BlUxUO | ||||
p5GaZCE8FkUylrGwjOgdQuFEwlSzaBaFcpbIcBTJoT+eQEtDGPxsmMhgBGOa | ||||
BGGQpioew8eJP82CbBokaTj1I3EDe8H1/fJwxc3jjVSQjsdBpJIonE1G4Xg8 | ||||
DicqS6NslsZRFPpjKaI0TYdZFgdpHM6iLEmGMh1OklE4jOCvr5ihuHGKbdIN | ||||
/z+S7l+HbP9OdV+guiBQwTiZBXKahDL1QxnD+xM44nCap8MUKC0S4TBWMvIz | ||||
P0pH43A8CrI4jCdhPIZ5xd+e6obfiOr+s+jsvyspxVP4IgniSZb64yxQszGN | ||||
duZPJHwMA4tmYpLC2GfTdDxUKpuNgHslswy6GmZTOfr2pDT6q5LSfxFp+9+W | ||||
HqNxBouR+BNY4dhXkYriFD4gbpaMMjnyRTScgrhVyMZwMcMkAn44ioKpkkH0 | ||||
7elx/I3oMSsK83UvlnuP/telVQ+ETwab2Oo4xPr2QceA/puStgzldDqOJpMY | ||||
eKufzaLZaDQL/CTKRtE0jNJIhmI6HMezYDydTmAL4izygcf6CmldDtW3J+1J | ||||
J2n7QNpWyb7F/ot3ZPneo0P/C6vmj6MRYOB0GKgwmqhoOkriUZj6IEfSsT+a | ||||
BFKJqT8EMRTIMAimUazg+1kyGiY+pg+N4Y3xJI3Gk8zPwjjNkjAAfD0bpuMk | ||||
DMcKVmKoRAStwvqryXCGexT50RREUxz445GUwBcyf5YmsK4z6at0ks38TAFd | ||||
w6L6UZIGSikxGqXjWMEeBEOVylkWwoam8SSAExICkE+nwyyagFD0R6lK/SD0 | ||||
YY9mALHiNICJjEczgZ0r+Nafjoe+BJpIh1M/A9VgGk+A+qPxNBjHaTQFbUCF | ||||
o+FoMh0HsEfDUMIT00BJMfLjWI1lMAyRniI19IfJZBQBFxzCHEbjIQwgzhIY | ||||
JqgZfhTEWTjNAN/NYHeBPFUoRtFQAVUAhc5GcaoywMwgr4eZnM1COYFxDcNZ | ||||
mITj1AeFBChMRhM59VM/9kMAilk2FvEM/oRGswlgytgHoQ+jyWBWo2wog9ls | ||||
BNOMk3Q4llEEWxGCHjNNE0DnwBuiMAyHIhuPYtiY4UyGsMFDWMqpSuKxVDMF | ||||
2lI6RqoFZJEFsBHjAHqLwiiYwZZHACmiaDgS4Ww8U3CM5Ay4PjAWCbNIAgkv | ||||
x3Kk0nA2zUZJ5iMVjaDTeDqTQZBNprhGKaxlKmLYIAVaVwTwBEDv2A/iOIlm | ||||
4xiIx48jfwrAZgygJoiDCJieglMUZ7CAs1TJBJYkFZMkm8bjMJTjWAIvHMaz | ||||
JDZXE7JV/jGXnv3N1uaqI/Snw8kitM1933zccKy4FffaXlK0im1zzMA4dE/g | ||||
XsnsW19VFuWzrmfSKBzQcyz4bAF0rIfalO9Uxq7bE06x4Tp1QM/bsck7QfKU | ||||
6mGc67fQeWt9UbdF67LRtqceu1gpfTEeF5vSvldnHNne9Oi9fJ2qD7ZwYr7F | ||||
wDmK2BDaQNla57xxtRdOrH2Ho1mivg/7QDEyoukIqWdj3BR8Y13DU14tuHV9 | ||||
r4As60vh+4FpuOVhMc3xlavd7emFqS8ovMq3yl5O3TFZXY/ZMRLnpTBJ8W7h | ||||
p5LDxHWWiQ6kUWvY9qdYNj4rljoinOMJjKE3y/lJ575rrEBSsSNPpw9XxmJY | ||||
1bVe6Ho7kGdyWdfv48ktZWM19aB1zKYht3uyxCqbjcmi34V9+MI5BHSLVbui | ||||
slMlg7wtfyZfS/DnAactJJWtANEiVgrnNxXRYLB6HNAH99wskIH8qT6AfV+7 | ||||
7EOHGuCzIXBcEF8hSIMUBBpIhgikTDTJUBIE8D9AFSDBfJARPkgGeGLiwxMi | ||||
8gPgpEN/BMIiBI4LjwVRZwNR40X3PRHKEH6F/uGRIY4D5I7PI4IuQ/oZ+H4S | ||||
AzBIESiBPjqOgwTA1xCYeZbIOBQAkUDGqMlI4iRGagSSRgL4jxE1pCCooiQI | ||||
Z7OhzIIwDoJghjaQeDQNYpUMA/h1ksyEBP6fgqj3AS5JkJ4zfwhroiYpiOAw | ||||
HEHnfgi4QY2T4XSU+glIpyCNsjFIqrEP3YGYzcRkCm1ncgJSCN6C/n3URaBf | ||||
mU0BUcdjwMujLJmBzAuGs3A6iaaz6XiaKJDmMVkKZ7HIJomKZ7MZQOtoBJgC | ||||
4MkIkRFIn2w4lTKGzsfTISDB8QxQDQg9gFPJFIHJJAKNJ0gmiQDoMPGnaQSw | ||||
aQwCDXBplkKbkzQBBAbI0QfYAAgfZDeMfDicpsEUDZJyBmgiAhgDww7FLBgG | ||||
02AEKD8DmJmNAVzOpv4McMAkieOZkiPAb3DEwwnIVR8wkRrNpiM/8QPYRRX4 | ||||
gGYnwp9MZtEwDQM1zqIh4BO020XhMIG5JylsEYBjIK5QwnqDiEfbVQCyHOAr | ||||
oJg0DoajeCoUgDs5BiEPxBHgWRFahCAFBxp11jKEaB0oHf6vbtKFQh/RRzSE | ||||
FUhnQNH+OA2zIaxNNgpmsI8xIAtAloBmAMFMAEZEoOvEowTG7YPqGQ+RtKGL | ||||
2iYp9o2S+5frHrwjdz4/md9fLT8mwx+WST5eqkcPq+TRh+XJiSj655Nns9X8 | ||||
Xvr043F/dm89ke/Onv/4aP5wFJani3jnf3z+6uXm6Yv78/n4Mlkt1/LtaPfz | ||||
j4tF/OO98udXd+/i7bz25N89enZycu/NL/PZvfOL94uL/NHsyr83f1VcPXsy | ||||
f/5sXj46fnv86HT+cDm/enU8f/9APrt3/uj49P0jcXoSD++/enDv+P786b3z | ||||
5fni4vzez6+ePZifP8nnVyf3ns1fHM9fRXPs4Pj8Cfz+YH79YVvJ8P0Ps/jx | ||||
i/nZ5pl496Rc7t6Uu5+fnFw9f/FqebyebF9F97MXxdXp6mz74cmHBz8fPz+F | ||||
kz+9//hNVa6q9fNwc2/xJJ9u5sEJ4JG3ufj+ubx6erVeXg3PXn3sz9NfgifJ | ||||
m/lmVFz+PD5+uSmeBMX21dX1vcnlo8ukUsF4fBatnjw7u1jLx8sge/H6rDoV | ||||
8SUoMy92Py/Huwcn04uXrx89yp9cPp+8v/oYJB9nwXJyeXF29vjxs6oqip8e | ||||
P7qejs+zn65evNndW/44W/0cJ28fiOmT4/5i0o+CUfExe60+hJN18eTp5U+P | ||||
84uzhx9ev8je5dkPbx/9eBwfv72ert+/9j++91dnx/c+vrtY+vfnj6/uL8Tx | ||||
63vnP2/OZyfqx9HLq8XuaXESLcYf37x8Mbu6f1oETza7bbB4+urlE/84/PD8 | ||||
aZZ/L3+8Ork/fzW/d9Rj/CNqp9fcxHfdPWKR0V/hRez64Nw9Cvwj8Xf58Hf5 | ||||
8Hf58J8rH5wjGOgjGLiA/Y6n4jjIVDqE5gJ/OAkSIFA/AcKABqFZIN4J6Kxq | ||||
BorvNJ3OwgnaRSIpxqDqx+kItkYmfgZEl8DRC0czOZmAngu6LHwN1ArUbVYr | ||||
6FytgFYr+JtYrb9L079L079RadrrpkRBpPjgACl+JSWKG0nRpcTJ9HHf/3j+ | ||||
YR4+nv/y6kOQbuTb5HS5u6dWQj6cqdM4uyo2Z/1tcLKeXL08314XP12sVvLl | ||||
i+XlpByefW8mf2Du4jdACb8JJaIxiMthMg38OJqFapokEuT2WAErAAk4CoE9 | ||||
qekUpMoU8AII1TCMklk8EyBRpuEszqJROvbHU2D+2PYQJE2UAYaYJEmWAesD | ||||
8ZOB0AF2AmI7VLNoDDwH2E2WxUqCnAl8EEQpYAXgL+F4DCI2lVGARvsJ8Mxo | ||||
IkFgT0ajLBgHwKtAyoDs8kGkAzvNJulMzqSYjWdZPB5GKojHcThEADED6BDO | ||||
MHojjNGWG6bjeBiO4kCBUI4UCDYQof4kjCYJNHhAEvkySYZxOJ7OgD8OJyCL | ||||
0zSCZZmBIJyNZBzLaDqdpkOQ6JGKxHSaJVEEIArAVAjTGQJcGssEZOAwHY8T | ||||
f5qMRypTkyEsG4pd5YP0VfjWJIizYCbjKBJ+hlbRbJxOwunYor6/y6G/WA6x | ||||
NQazRFZ3dVLRIZ5ALOG4FFfT739cJj+F734e/lSero5fvHk/ff84nT3/Wb1Y | ||||
DN+dLE7y02KR/PLswdvye/nyhx/n2cOzy/EvySZ5Nz2/93E8fPdIPHr3SO5O | ||||
7l/fr2bpT+s3x0c9hx0s3g5/+fDheHSxy54VcqzK00eXr8r3L9Lxg2Hx+uTi | ||||
pLiOV/E9cb16t3j+5mH26tl8fv84/uXKf/TxZX+Rvn08npTBs2enk5/eri4f | ||||
3X93+f7eYr46S8ofv89/OHswe38vWP2w+b6Qi1A8ev3y4Wv57qfTj+/n34+r | ||||
dwBJV5u3WXX2y6KKT/yX84vNxebVL+fboTqp3n78/unji59+mp4+/vH80ZNH | ||||
V+UIperh9fp6Fip+uzTfZ6Gik4f+RhYqfos2hga7/wtsdj5LksQAAA== | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the | ||||
online Style Guide at | ||||
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, | ||||
and let us know if any changes are needed. | ||||
For example, please consider whether the following should be updated: | ||||
whitespace --> | ||||
<!-- [rfced] Please let us know if any changes are needed for the | ||||
following: | ||||
a) The following term was used inconsistently in this document. | ||||
We chose to use the latter form. Please let us know any objections. | ||||
Issuance Protocol (1 instance in text) / | ||||
issuance protocol (27 instances in text) (per the rest of | ||||
Cluster 450) | ||||
b) The following terms appear to be used inconsistently in this | ||||
document. Please let us know which form is preferred. | ||||
Reserved value / reserved value | ||||
the token key / the token-key (e.g., "the token-key used", | ||||
"the token key identifier", "the token-key parameter") | ||||
(We also see "token_key: The public token-key", which reads a bit | ||||
oddly.) | ||||
token structure / Token structure | ||||
WWW-Authenticate / WWW-Authentication (header / response header) | ||||
(We also see "WWW-Authentication challenge list". | ||||
Also, it appears that RFC 7616 is the only published RFC to date | ||||
that uses "WWW-Authentication header field".) | ||||
c) Quoting of some items is applied inconsistently in this document. | ||||
Please let us know which form is preferred. | ||||
"PrivateToken" / PrivateToken (mostly quoted, but not quoted where | ||||
first used) | ||||
PrivateToken authentication scheme / | ||||
"PrivateToken" authentication scheme | ||||
"token_type" / token_type (e.g., 'the token_type', 'relationship | ||||
between "token_type" and') | ||||
Please compare with usage for "issuer_name", "redemption_context", | ||||
and "origin_info". | ||||
"WWW-Authenticate" header field / WWW-Authenticate header field | ||||
(One option might be to quote the field name only when first used | ||||
(Section 1), as was done for the "origin_info" field.) | ||||
d) Please let us know how/if the following should be made consistent: | ||||
2-octet / two-octet | ||||
(We also see "two-byte" in Section 6.2.) | ||||
Spacing (or not) after the comma for this item: | ||||
",token-key=" / ", token-key=" | ||||
e) We see "HTTP authentication headers" but "HTTP Authentication | ||||
challenge", "HTTP Authentication ([RFC9110], Section 11)", and | ||||
"HTTP authentication scheme". Should capitalization of | ||||
"Authentication"/"authentication" be made consistent among these | ||||
expressions, or all they all distinct from each other? --> | ||||
</rfc> | </rfc> | |||
End of changes. 145 change blocks. | ||||
1010 lines changed or deleted | 744 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |