rfc9578.original.xml | rfc9578.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-protocol-16" category="std" consensus="true" tocInclude="true" | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | |||
sortRefs="true" symRefs="true" version="3"> | -ietf-privacypass-protocol-16" number="9578" submissionType="IETF" category="std | |||
" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" o | ||||
bsoletes="" xml:lang="en" version="3"> | ||||
<!-- xml2rfc v2v3 conversion 3.12.10 --> | <!-- xml2rfc v2v3 conversion 3.12.10 --> | |||
<front> | <front> | |||
<title abbrev="Privacy Pass Issuance">Privacy Pass Issuance Protocol</title> | <title abbrev="Privacy Pass Issuance">Privacy Pass Issuance Protocol</title> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-protocol-16" /> | <seriesInfo name="RFC" value="9578"/> | |||
<author initials="S." surname="Celi" fullname="Sofía Celi"> | <author initials="S." surname="Celi" fullname="Sofía Celi"> | |||
<organization>Brave Software</organization> | <organization>Brave Software</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<city>Lisbon</city> | <city>Lisbon</city> | |||
<country>Portugal</country> | <country>Portugal</country> | |||
</postal> | </postal> | |||
<email>cherenkov@riseup.net</email> | <email>cherenkov@riseup.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
skipping to change at line 47 ¶ | skipping to change at line 50 ¶ | |||
<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> | |||
<postal> | <postal> | |||
<street>101 Townsend St</street> | <street>101 Townsend St</street> | |||
<city>San Francisco</city> | <city>San Francisco</city> | |||
<region>CA</region> | ||||
<code>94107</code> | ||||
<country>United States of America</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>caw@heapingbits.net</email> | <email>caw@heapingbits.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2023" month="October" day="03"/> | <date year="2024" month="May"/> | |||
<keyword>Internet-Draft</keyword> | <area>sec</area> | |||
<workgroup>privacypass</workgroup> | ||||
<!-- [rfced] Please insert any keywords (beyond those that appear in the | ||||
title) for use on <https://www.rfc-editor.org/search>. --> | ||||
<!-- [rfced] Regarding "issuance protocol" vs. "issuance protocols" | ||||
as used in this document: It appears that this could be confusing to | ||||
some readers. For example, we see | ||||
* "Privacy Pass Issuance Protocol" (the document title) | ||||
* "This document specifies two variants of the two-message issuance | ||||
protocol for Privacy Pass tokens" | ||||
* "This document describes the issuance protocol for Privacy Pass | ||||
built on [HTTP]. It specifies two variants" | ||||
* "The issuance protocols defined in this document" | ||||
* "a variant of the issuance protocol in Section 5" (from Section 6) | ||||
* (in draft-ietf-privacypass-auth-scheme, where it refers to this | ||||
document) "the issuance protocols in that specification". | ||||
* the two basic issuance protocols specified in this document | ||||
Side note regarding the fifth bullet: The current wording seems to | ||||
indicate that the protocol discussed in Section 6 is a subset of | ||||
the protocol discussed in Section 5, rather than a separate variant | ||||
as indicated elsewhere in this document; it also seems to conflict | ||||
with the text of the two paragraphs that follow it. | ||||
Please review, and let us know your decision, noting that this will | ||||
also affect the language used in companion documents | ||||
draft-ietf-privacypass-architecture-16 and | ||||
draft-ietf-privacypass-auth-scheme. | ||||
One option would be to add a brief explanatory sentence in the | ||||
Abstract (a new second sentence) and Introduction (new last sentence | ||||
of Paragraph 2), such as the following: | ||||
Instances of "issuance protocol" and "issuance protocols" in the | ||||
text of this document are used interchangeably to refer to the two | ||||
variants of the Privacy Pass issuance protocol. --> | ||||
<abstract> | <abstract> | |||
<t>This document specifies two variants of the two-message issuance protoc ol | <t>This document specifies two variants of the two-message issuance protoc ol | |||
for Privacy Pass tokens: one that produces tokens that are privately | for Privacy Pass tokens: one that produces tokens that are privately | |||
verifiable using the issuance private key, and another that produces tokens | verifiable using the issuance private key and one that produces tokens | |||
that are publicly verifiable using the issuance public key.</t> | that are publicly verifiable using the issuance public key. | |||
<!-- [rfced] Abstract and subsequent: Please confirm that the | ||||
following terms are all distinct from each other: | ||||
issuance public key (3 instances) and | ||||
Issuer Public Key (approx. 19 instances) | ||||
issuance private key (3 instances) and | ||||
Issuer Private Key (approx. 14 instances) --> | ||||
</t> | ||||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="introduction"> | <section anchor="introduction"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>The Privacy Pass protocol provides a privacy-preserving authorization | <t>The Privacy Pass protocol provides a privacy-preserving authorization | |||
mechanism. In essence, the protocol allows clients to provide cryptographic | mechanism. In essence, the protocol allows clients to provide cryptographic | |||
tokens that prove nothing other than that they have been created by a given | tokens that prove nothing other than that they have been created by a given | |||
server in the past <xref target="ARCHITECTURE"/>.</t> | server in the past <xref target="RFC9576"/>.</t> | |||
<t>This document describes the issuance protocol for Privacy Pass built on | <t>This document describes the issuance protocol for Privacy Pass built on | |||
<xref target="HTTP"/>. It specifies two variants: one that is privately verifiab | <xref target="RFC9110"/>. It specifies two variants: one that is privately verif | |||
le | iable | |||
using the issuance private key based on the oblivious pseudorandom function from | using the issuance private key based on the Oblivious Pseudorandom Function (OPR | |||
<xref target="OPRF"/>, and one that is publicly verifiable using the | F) as defined in <xref target="RFC9497"/> and one that is publicly verifiable us | |||
ing the | ||||
issuance public key based on the blind RSA signature scheme | issuance public key based on the blind RSA signature scheme | |||
<xref target="BLINDRSA"/>.</t> | <xref target="RFC9474"/>. | |||
<!-- [rfced] Section 1: We had trouble following this sentence. | ||||
Does it mean that either the issuance protocol or Privacy Pass is | ||||
based on RFC 9110? If so, which one? | ||||
Original: | ||||
This document describes the issuance protocol for Privacy Pass built | ||||
on [HTTP]. --> | ||||
</t> | ||||
<t>This document does not cover the Privacy Pass architecture, including | <t>This document does not cover the Privacy Pass architecture, including | |||
choices that are necessary for deployment and application specific choices | choices that are necessary for deployment and application-specific choices | |||
for protecting client privacy. This information is covered in <xref target="ARCH | for protecting client privacy. This information is covered in <xref target="RFC9 | |||
ITECTURE"/>.</t> | 576"/>. | |||
<!-- [rfced] Section 1: "choices that are necessary for deployment and | ||||
application specific choices" is difficult to parse. If the | ||||
suggested text is not correct, please clarify. | ||||
Original: | ||||
This document does not cover the Privacy Pass architecture, including | ||||
choices that are necessary for deployment and application specific | ||||
choices for protecting client privacy. | ||||
Suggested: | ||||
This document does not cover the Privacy Pass architecture, which | ||||
includes (1) choices that are necessary for deployment and | ||||
(2) application-specific choices related to protecting client | ||||
privacy. --> | ||||
</t> | ||||
</section> | </section> | |||
<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 | |||
<t>This document uses the terms Origin, Client, Issuer, and Token as defin | are to be interpreted as described in BCP 14 | |||
ed in | <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only | |||
<xref section="2" sectionFormat="of" target="ARCHITECTURE"/>. Moreover, the foll | when, they appear in all capitals, as shown here.</t> | |||
owing additional terms are | <t>This document uses the terms "Origin", "Client", "Issuer", and "Token" | |||
as defined in | ||||
<xref section="2" sectionFormat="of" target="RFC9576"/>. Moreover, the following | ||||
additional terms are | ||||
used throughout this document.</t> | used throughout this document.</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Issuer Public Key: The public key (from a private-public key pair) u | <dt>Issuer Public Key:</dt><dd>The public key (from a private-public key | |||
sed by | pair) used by | |||
the Issuer for issuing and verifying Tokens.</li> | the Issuer for issuing and verifying Tokens.</dd> | |||
<li>Issuer Private Key: The private key (from a private-public key pair) | <dt>Issuer Private Key:</dt><dd>The private key (from a private-public k | |||
used by | ey pair) used by | |||
the Issuer for issuing and verifying Tokens.</li> | the Issuer for issuing and verifying Tokens.</dd> | |||
</ul> | </dl> | |||
<t>Unless otherwise specified, this document encodes protocol messages in TLS | <t>Unless otherwise specified, this document encodes protocol messages in TLS | |||
notation from <xref section="3" sectionFormat="of" target="TLS13"/>. Moreover, a ll constants are in | notation (<xref section="3" sectionFormat="comma" target="RFC8446"/>). Moreover, all constants are in | |||
network byte order.</t> | network byte order.</t> | |||
</section> | </section> | |||
<section anchor="protocol-overview"> | <section anchor="protocol-overview"> | |||
<name>Protocol Overview</name> | <name>Protocol Overview</name> | |||
<t>The issuance protocols defined in this document embody the core of Priv acy Pass. | <t>The issuance protocols defined in this document embody the core of Priv acy Pass. | |||
Clients receive TokenChallenge inputs from the redemption protocol | Clients receive TokenChallenge inputs from the redemption protocol | |||
(<xref section="2.1" sectionFormat="comma" target="AUTHSCHEME"/>) and use the is | (<xref section="2.1" sectionFormat="comma" target="RFC9577"/>) and use the issua | |||
suance protocols to produce | nce protocols to produce | |||
corresponding Token values (<xref section="2.2" sectionFormat="comma" target="AU | corresponding Token values (<xref section="2.2" sectionFormat="comma" target="RF | |||
THSCHEME"/>). The issuance protocol | C9577"/>). The issuance protocol | |||
describes how Clients and Issuers interact to compute a token using a one-round | describes how Clients and Issuers interact to compute a token using a one-round | |||
protocol consisting of a TokenRequest from the Client and TokenResponse from | protocol consisting of a TokenRequest from the Client and a TokenResponse from | |||
the Issuer. This interaction is shown below.</t> | the Issuer. This interaction is shown below.</t> | |||
<!-- [rfced] Please review each artwork element. Specifically, | ||||
should any of the artwork elements (e.g., the first two artwork | ||||
items in Section 4, the HTTP POST requests in Sections 5.1 and 6.1, | ||||
or the test-vector data in the original Appendix B) 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 figure in this document has width or height | ||||
specified, which will make the artwork not scale. Please consider | ||||
whether scaling should be enabled. Scaling will allow the figure to | ||||
be resized when viewed on a mobile device; however, there may be | ||||
aesthetic trade-offs (e.g., the image may appear too large on a | ||||
desktop screen, or it may scale differently based on its relative | ||||
size). 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-issuance"> | <figure anchor="fig-issuance"> | |||
<name>Issuance Overview</name> | <name>Issuance Overview</name> | |||
<artset> | <artset> | |||
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="224" width="520" viewBox="0 0 520 224" 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="224" width="520" viewBox="0 0 520 224" 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,208" fill="none" stroke="black"/> | <path d="M 40,64 L 40,208" 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 184,32 L 184,64" fill="none" stroke="black"/> | <path d="M 184,32 L 184,64" fill="none" stroke="black"/> | |||
<path d="M 216,64 L 216,208" fill="none" stroke="black"/> | <path d="M 216,64 L 216,208" fill="none" stroke="black"/> | |||
<path d="M 256,32 L 256,64" fill="none" stroke="black"/> | <path d="M 256,32 L 256,64" fill="none" stroke="black"/> | |||
skipping to change at line 184 ¶ | skipping to change at line 294 ¶ | |||
| |<== Attestation ==>| | | | |<== Attestation ==>| | | |||
| | | | | | | | | | |||
| +--------- TokenRequest ------->| | | +--------- TokenRequest ------->| | |||
| |<-------- TokenResponse -------+ | | |<-------- TokenResponse -------+ | |||
|<-- Request+Token ---+ | | | |<-- Request+Token ---+ | | | |||
| | | | | | | | | | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
<t>The TokenChallenge inputs to the issuance protocols described in this | <t>The TokenChallenge inputs to the issuance protocols described in this | |||
document can be interactive or non-interactive, and per-origin or cross-origin.< /t> | document can be interactive or non-interactive and can be per origin or across o rigins.</t> | |||
<t>The issuance protocols defined in this document are compatible with any | <t>The issuance protocols defined in this document are compatible with any | |||
deployment model defined in <xref section="4" sectionFormat="of" target="ARCHITE CTURE"/>. The details of | deployment model defined in <xref section="4" sectionFormat="of" target="RFC9576 "/>. The details of | |||
attestation are outside the scope of the issuance protocol; see | attestation are outside the scope of the issuance protocol; see | |||
<xref section="4" sectionFormat="of" target="ARCHITECTURE"/> for information abo ut how attestation can | <xref section="4" sectionFormat="of" target="RFC9576"/> for information about ho w attestation can | |||
be implemented in each of the relevant deployment models.</t> | be implemented in each of the relevant deployment models.</t> | |||
<t>This document describes two variants of the issuance protocol: one that is | <t>This document describes two variants of the issuance protocol: one that is | |||
privately verifiable (<xref target="private-flow"/>) using the issuance private key based on | privately verifiable (<xref target="private-flow"/>) using the issuance private key based on | |||
the oblivious pseudorandom function from <xref target="OPRF"/>, and one | the OPRF <xref target="RFC9497"/> and one | |||
that is publicly verifiable (<xref target="public-flow"/>) using the issuance pu blic key | that is publicly verifiable (<xref target="public-flow"/>) using the issuance pu blic key | |||
based on the blind RSA signature scheme | based on the blind RSA signature scheme | |||
<xref target="BLINDRSA"/>.</t> | <xref target="RFC9474"/>.</t> | |||
</section> | </section> | |||
<section anchor="setup"> | <section anchor="setup"> | |||
<name>Configuration</name> | <name>Configuration</name> | |||
<t>Issuers MUST provide two parameters for configuration:</t> | <t>Issuers <bcp14>MUST</bcp14> provide two parameters for configuration:</ | |||
<ol spacing="normal" type="1"><li>Issuer Request URL: A token request URL | t> | |||
for generating access tokens. | <dl spacing="normal"><dt>Issuer Request URL:</dt><dd>A token request URL f | |||
For example, an Issuer URL might be | or generating access tokens. | |||
https://issuer.example.net/request.</li> | For example, an Issuer Request URL might be | |||
<li>Issuer Public Key values: A list of Issuer Public Keys for the issua | <https://issuer.example.net/request>.</dd> | |||
nce | <dt>Issuer Public Key values:</dt><dd>A list of Issuer Public Keys for t | |||
protocol.</li> | he issuance | |||
</ol> | protocol.</dd> | |||
</dl> | ||||
<t>The Issuer parameters can be obtained from an Issuer via a directory ob ject, | <t>The Issuer parameters can be obtained from an Issuer via a directory ob ject, | |||
which is a JSON object (<xref section="4" sectionFormat="comma" target="RFC8259" />) whose values are other JSON | which is a JSON object (<xref section="4" sectionFormat="comma" target="RFC8259" />) whose values are other JSON | |||
values (<xref section="3" sectionFormat="comma" target="RFC8259"/>) for the para meters. The contents of this JSON | values (<xref section="3" sectionFormat="comma" target="RFC8259"/>) for the para meters. The contents of this JSON | |||
object are defined in <xref target="directory-values"/>.</t> | object are defined in <xref target="directory-values"/>.</t> | |||
<table anchor="directory-values"> | <table anchor="directory-values"> | |||
<name>Issuer directory object description</name> | <name>Issuer Directory Object Description</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Field Name</th> | <th align="left">Field Name</th> | |||
<th align="left">Value</th> | <th align="left">Value</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">issuer-request-uri</td> | <td align="left">issuer-request-uri</td> | |||
<td align="left">Issuer Request URL value (as an absolute URL, or a URL relative to the directory object) as a percent-encoded URL string, represent ed as a JSON string (<xref section="7" sectionFormat="comma" target="RFC8259"/>) </td> | <td align="left">Issuer Request URL value (as an absolute URL or as a URL relative to the directory object) as a percent-encoded URL string, represe nted as a JSON string (<xref section="7" sectionFormat="comma" target="RFC8259"/ >)</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">token-keys</td> | <td align="left">token-keys</td> | |||
<td align="left">List of Issuer Public Key values, each represented as JSON objects (<xref section="4" sectionFormat="comma" target="RFC8259"/>)</td > | <td align="left">List of Issuer Public Key values, each represented as JSON objects (<xref section="4" sectionFormat="comma" target="RFC8259"/>)</td > | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>Each "token-keys" JSON object contains the fields and corresponding raw values | <t>Each "token-keys" JSON object contains the fields and corresponding raw values | |||
defined in <xref target="tokenkeys-values"/>.</t> | defined in <xref target="tokenkeys-values"/>.</t> | |||
<table anchor="tokenkeys-values"> | <table anchor="tokenkeys-values"> | |||
<name>Issuer 'token-keys' object description'</name> | <name>Issuer "token-keys" Object Description</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Field Name</th> | <th align="left">Field Name</th> | |||
<th align="left">Value</th> | <th align="left">Value</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">token-type</td> | <td align="left">token-type</td> | |||
<td align="left">Integer value of the Token Type, as defined in <xre f target="token-type"/>, represented as a JSON number (<xref section="6" section Format="comma" target="RFC8259"/>)</td> | <td align="left">Integer value of the token type, as defined in <xre f target="token-type"/>, represented as a JSON number (<xref section="6" section Format="comma" target="RFC8259"/>)</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">token-key</td> | <td align="left">token-key</td> | |||
<td align="left">The base64url-encoded <xref target="RFC4648"/> Publ ic Key for use with the issuance protocol as determined by the token-type field, including padding, represented as a JSON string (<xref section="7" sectionForma t="comma" target="RFC8259"/>)</td> | <td align="left">The base64url public key, encoded per <xref target= "RFC4648"/>, for use with the issuance protocol as determined by the token-type field, including padding, represented as a JSON string (<xref section="7" sectio nFormat="comma" target="RFC8259"/>)</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
<t>Each "token-keys" JSON object may also contain the optional field "not- before". | <t>Each "token-keys" JSON object may also contain the optional field "not- before". | |||
The value of this field is the UNIX timestamp (number of seconds since | The value of this field is the UNIX timestamp (number of seconds since | |||
January 1, 1970, UTC -- see <xref section="4.2.1" sectionFormat="of" target="TIM | January 1, 1970, UTC -- see <xref section="4.2.1" sectionFormat="of" target="RFC | |||
ESTAMP"/>) at which | 8877"/>) at which | |||
the key can be used. If this field is present, Clients SHOULD NOT use a token | the key can be used. If this field is present, Clients <bcp14>SHOULD NOT</bcp14> | |||
use a token | ||||
key before this timestamp, as doing so can lead to issuance failures. The | key before this timestamp, as doing so can lead to issuance failures. The | |||
purpose of this field is to assist in scheduled key rotations.</t> | purpose of this field is to assist in scheduled key rotations. | |||
<t>Beyond staging keys with the "not-before" value, Issuers MAY advertise | ||||
multiple | <!-- [rfced] Section 4: We found this sentence confusing, because | |||
Section 4.2.1 of [TIMESTAMP] says "number of seconds since the epoch" | ||||
and "The epoch is 1 January 1900 at 00:00 UTC." "1970" is not | ||||
mentioned until Section 4.3 of [TIMESTAMP], where it says "The PTP | ||||
[IEEE1588] epoch is 1 January 1970 00:00:00 TAI." | ||||
Will this sentence and section-number citation be clear to readers? | ||||
Original: | ||||
The value of this field is the UNIX timestamp (number | ||||
of seconds since January 1, 1970, UTC - see Section 4.2.1 of | ||||
[TIMESTAMP]) at which the key can be used. --> | ||||
</t> | ||||
<t>Beyond staging keys with the "not-before" value, Issuers <bcp14>MAY</bc | ||||
p14> advertise multiple | ||||
"token-keys" for the same token-type to facilitate key rotation. In this case, | "token-keys" for the same token-type to facilitate key rotation. In this case, | |||
Issuers indicate preference for which token key to use based on the order of | Issuers indicate their preference for which token key to use based on the order of | |||
keys in the list, with preference given to keys earlier in the list. Clients | keys in the list, with preference given to keys earlier in the list. Clients | |||
SHOULD use the first key in the "token-keys" list that either does not have a | <bcp14>SHOULD</bcp14> use the first key in the "token-keys" list that either doe s not have a | |||
"not-before" value or has a "not-before" value in the past, since the first such key is the | "not-before" value or has a "not-before" value in the past, since the first such key is the | |||
most likely to be valid in the given time window. Origins can attempt | most likely to be valid in the given time window. Origins can attempt | |||
to use any key in the "token-keys" list to verify tokens, starting with the most | to use any key in the "token-keys" list to verify tokens, starting with the most | |||
preferred key in the list. Trial verification like this can help deal with Clien t | preferred key in the list. Trial verifications like this can help deal with Clie nt | |||
clock skew.</t> | clock skew.</t> | |||
<t>Altogether, the Issuer's directory could look like the following (with the | <t>Altogether, the Issuer's directory could look like the following (with the | |||
"token-key" fields abbreviated):</t> | "token-key" fields abbreviated):</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
{ | { | |||
"issuer-request-uri": "https://issuer.example.net/request", | "issuer-request-uri": "https://issuer.example.net/request", | |||
"token-keys": [ | "token-keys": [ | |||
{ | { | |||
"token-type": 2, | "token-type": 2, | |||
"token-key": "MI...AB", | "token-key": "MI...AB", | |||
skipping to change at line 290 ¶ | skipping to change at line 415 ¶ | |||
} | } | |||
] | ] | |||
} | } | |||
]]></artwork> | ]]></artwork> | |||
<t>Clients that use this directory resource before 1686913811 in UNIX time would use the | <t>Clients that use this directory resource before 1686913811 in UNIX time would use the | |||
second key in the "token-keys" list, whereas Clients that use this directory aft er | second key in the "token-keys" list, whereas Clients that use this directory aft er | |||
1686913811 in UNIX time would use the first key in the "token-keys" list.</t> | 1686913811 in UNIX time would use the first key in the "token-keys" list.</t> | |||
<t>A complete "token-key" value, encoded as it would be in the Issuer dire ctory, | <t>A complete "token-key" value, encoded as it would be in the Issuer dire ctory, | |||
would look like the following (line breaks are inserted to fit within the per-li ne | would look like the following (line breaks are inserted to fit within the per-li ne | |||
character limits):</t> | character limits):</t> | |||
<!-- [rfced] Section 4: The six lines beginning with "$ echo" were | ||||
still too long for the text output; we received six instances of | ||||
"Warning: Too long line found ... 5 characters longer than 72 | ||||
characters". Because we see the "line breaks are inserted to fit" | ||||
note just prior to the data, we adjusted the line lengths. Please | ||||
review the latest output files carefully; if the line breaks should | ||||
be placed differently, please let us know where they should be | ||||
placed. --> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
$ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDAL \ | $ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQE \ | |||
BglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr_DhZAPhJM7 \ | BCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr \ | |||
Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTvW6SKCh7ZPXEqCGR \ | _DhZAPhJM7Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTv \ | |||
sq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWbjf21iaVjXJ2VdwdS-8O- \ | W6SKCh7ZPXEqCGRsq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWb \ | |||
430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuID9OQm1nxfs1Z4PhWBzt93T2oz \ | jf21iaVjXJ2VdwdS-8O-430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuI \ | |||
Tnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99aA-muXRFN4ZUwORrF7cAcCUD_-56_6 \ | D9OQm1nxfs1Z4PhWBzt93T2ozTnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99 \ | |||
fh9s34FmqBGwIDAQAB \ | aA-muXRFN4ZUwORrF7cAcCUD_-56_6fh9s34FmqBGwIDAQAB \ | |||
| sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \ | | sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \ | |||
| openssl asn1parse -dump -inform DER | | openssl asn1parse -dump -inform DER | |||
0:d=0 hl=4 l= 338 cons: SEQUENCE | 0:d=0 hl=4 l= 338 cons: SEQUENCE | |||
4:d=1 hl=2 l= 61 cons: SEQUENCE | 4:d=1 hl=2 l= 61 cons: SEQUENCE | |||
6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss | 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss | |||
17:d=2 hl=2 l= 48 cons: SEQUENCE | 17:d=2 hl=2 l= 48 cons: SEQUENCE | |||
19:d=3 hl=2 l= 13 cons: cont [ 0 ] | 19:d=3 hl=2 l= 13 cons: cont [ 0 ] | |||
21:d=4 hl=2 l= 11 cons: SEQUENCE | 21:d=4 hl=2 l= 11 cons: SEQUENCE | |||
23:d=5 hl=2 l= 9 prim: OBJECT :sha384 | 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 | |||
34:d=3 hl=2 l= 26 cons: cont [ 1 ] | 34:d=3 hl=2 l= 26 cons: cont [ 1 ] | |||
skipping to change at line 320 ¶ | skipping to change at line 455 ¶ | |||
49:d=5 hl=2 l= 11 cons: SEQUENCE | 49:d=5 hl=2 l= 11 cons: SEQUENCE | |||
51:d=6 hl=2 l= 9 prim: OBJECT :sha384 | 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 | |||
62:d=3 hl=2 l= 3 cons: cont [ 2 ] | 62:d=3 hl=2 l= 3 cons: cont [ 2 ] | |||
64:d=4 hl=2 l= 1 prim: INTEGER :30 | 64:d=4 hl=2 l= 1 prim: INTEGER :30 | |||
67:d=1 hl=4 l= 271 prim: BIT STRING | 67:d=1 hl=4 l= 271 prim: BIT STRING | |||
... truncated public key bytes ... | ... truncated public key bytes ... | |||
]]></artwork> | ]]></artwork> | |||
<t>Issuer directory resources have the media type | <t>Issuer directory resources have the media type | |||
"application/private-token-issuer-directory" and are located at the well-known l ocation | "application/private-token-issuer-directory" and are located at the well-known l ocation | |||
/.well-known/private-token-issuer-directory; see <xref target="wkuri-reg"/> for the registration | /.well-known/private-token-issuer-directory; see <xref target="wkuri-reg"/> for the registration | |||
information for this well-known URI. The reason that this resource is located | information for this well-known URI. This resource is located | |||
at a well-known URI is that Issuers are defined by an origin name in TokenChalle | at a well-known URI because Issuers are defined by an origin name in TokenChalle | |||
nge | nge | |||
structures; see <xref section="2.1" sectionFormat="of" target="AUTHSCHEME"/>.</t | structures; see <xref section="2.1" sectionFormat="of" target="RFC9577"/>.</t> | |||
> | <t>The Issuer directory and Issuer resources <bcp14>SHOULD</bcp14> be avai | |||
<t>The Issuer directory and Issuer resources SHOULD be available on the sa | lable on the same origin. If | |||
me origin. If | an Issuer wants to service multiple different Issuer directories, they <bcp14>MU | |||
an Issuer wants to service multiple different Issuer directories they MUST creat | ST</bcp14> create | |||
e | unique subdomains for each directory so the TokenChallenge defined in | |||
unique subdomains for each so the TokenChallenge defined in | <xref section="2.1" sectionFormat="of" target="RFC9577"/> can be | |||
<xref section="2.1" sectionFormat="of" target="AUTHSCHEME"/> can be | ||||
differentiated correctly.</t> | differentiated correctly.</t> | |||
<t>Issuers SHOULD use HTTP cache directives to permit caching of this reso urce | <t>Issuers <bcp14>SHOULD</bcp14> use HTTP cache directives to permit cachi ng of this resource | |||
<xref target="RFC5861"/>. The cache lifetime depends on the Issuer's key rotatio n schedule. | <xref target="RFC5861"/>. The cache lifetime depends on the Issuer's key rotatio n schedule. | |||
Regular rotation of token keys is recommended to minimize the risk of key | Regular rotation of token keys is recommended to minimize the risk of key | |||
compromise and any harmful effects that happen due to key compromise.</t> | compromise and any harmful effects that happen due to key compromise.</t> | |||
<t>Issuers can control cache lifetime with the Cache-Control header, as fo llows:</t> | <t>Issuers can control the cache lifetime with the Cache-Control header, a s follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Cache-Control: max-age=86400 | Cache-Control: max-age=86400 | |||
]]></artwork> | ]]></artwork> | |||
<t>Consumers of the Issuer directory resource SHOULD follow the usual HTTP | <t>Consumers of the Issuer directory resource <bcp14>SHOULD</bcp14> follow | |||
caching | the usual HTTP caching semantics | |||
<xref target="RFC9111"/> semantics when processing this resource. Long cache lif | <xref target="RFC9111"/> when processing this resource. Long cache lifetimes may | |||
etimes may | result in the use of stale Issuer configuration information, whereas short | |||
result in use of stale Issuer configuration information, whereas short | lifetimes may result in decreased performance. When the use of an Issuer | |||
lifetimes may result in decreased performance. When use of an Issuer | ||||
configuration results in token issuance failures, e.g., because the | configuration results in token issuance failures, e.g., because the | |||
Issuer has invalidated its directory resource before its expiration | Issuer has invalidated its directory resource before its expiration | |||
time and issuance requests using this configuration are unsuccessful, | time and issuance requests using this configuration are unsuccessful, | |||
the directory SHOULD be fetched and revalidated. Issuance will continue | the directory <bcp14>SHOULD</bcp14> be fetched and revalidated. Issuance will co ntinue | |||
to fail until the Issuer configuration is updated.</t> | to fail until the Issuer configuration is updated.</t> | |||
</section> | </section> | |||
<section anchor="private-flow"> | <section anchor="private-flow"> | |||
<name>Issuance Protocol for Privately Verifiable Tokens</name> | <name>Issuance Protocol for Privately Verifiable Tokens</name> | |||
<t>The privately verifiable issuance protocol allows Clients to produce To ken | <t>The privately verifiable issuance protocol allows Clients to produce To ken | |||
values that verify using the Issuer Private Key. This protocol is based | values that verify using the Issuer Private Key. This protocol is based | |||
on the oblivious pseudorandom function from <xref target="OPRF"/>.</t> | on the OPRF <xref target="RFC9497"/>.</t> | |||
<t>Issuers provide a Issuer Private and Public Key, denoted <tt>skI</tt> a | <t>Issuers provide an Issuer Private Key and Public Key, denoted <tt>skI</ | |||
nd <tt>pkI</tt> respectively, | tt> and <tt>pkI</tt>, respectively, | |||
used to produce tokens as input to the protocol. See <xref target="issuer-config uration"/> | used to produce tokens as input to the protocol. See <xref target="issuer-config uration"/> | |||
for how these keys are generated.</t> | for information about how these keys are generated.</t> | |||
<t>Clients provide the following as input to the issuance protocol:</t> | <t>Clients provide the following as input to the issuance protocol:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Issuer Request URL: A URL identifying the location to which issuance | <dt>Issuer Request URL:</dt><dd>A URL identifying the location to which | |||
requests | issuance requests | |||
are sent. This can be a URL derived from the "issuer-request-uri" value in the | are sent. This can be a URL derived from the "issuer-request-uri" value in the | |||
Issuer's directory resource, or it can be another Client-configured URL. The val ue | Issuer's directory resource, or it can be another Client-configured URL. The val ue | |||
of this parameter depends on the Client configuration and deployment model. | of this parameter depends on the Client configuration and deployment model. | |||
For example, in the 'Joint Origin and Issuer' deployment model, the Issuer | For example, in the "Joint Origin and Issuer" deployment model (<xref target="RF C9576" sectionFormat="comma" section="4.3"/>), the Issuer | |||
Request URL might correspond to the Client's configured Attester, and the | Request URL might correspond to the Client's configured Attester, and the | |||
Attester is configured to relay requests to the Issuer.</li> | Attester is configured to relay requests to the Issuer.</dd> | |||
<li>Issuer name: An identifier for the Issuer. This is typically a host | <dt>Issuer name:</dt><dd>An identifier for the Issuer. This is typically | |||
name that | a hostname that | |||
can be used to construct HTTP requests to the Issuer.</li> | can be used to construct HTTP requests to the Issuer.</dd> | |||
<li>Issuer Public Key: <tt>pkI</tt>, with a key identifier <tt>token_key | <dt>Issuer Public Key:</dt><dd><tt>pkI</tt>, with a key identifier <tt>t | |||
_id</tt> computed as | oken_key_id</tt> computed as | |||
described in <xref target="issuer-configuration"/>.</li> | described in <xref target="issuer-configuration"/>.</dd> | |||
<li>Challenge value: <tt>challenge</tt>, an opaque byte string. For exam | <dt>Challenge value:</dt><dd><tt>challenge</tt> -- an opaque byte string | |||
ple, this might | . For example, this might | |||
be provided by the redemption protocol in <xref target="AUTHSCHEME"/>.</li> | be provided by the redemption protocol described in <xref target="RFC9577"/>.</d | |||
</ul> | d> | |||
</dl> | ||||
<t>Given this configuration and these inputs, the two messages exchanged i n | <t>Given this configuration and these inputs, the two messages exchanged i n | |||
this protocol are described below. This section uses notation described in | this protocol are described below. This section uses notation described in | |||
<xref section="4" sectionFormat="comma" target="OPRF"/>, including SerializeElem ent and DeserializeElement, | <xref section="4" sectionFormat="comma" target="RFC9497"/>, including SerializeE lement and DeserializeElement, | |||
SerializeScalar and DeserializeScalar, and DeriveKeyPair.</t> | SerializeScalar and DeserializeScalar, and DeriveKeyPair.</t> | |||
<t>The constants <tt>Ne</tt> and <tt>Ns</tt> are as defined in <xref secti | <t>The constants <tt>Ne</tt> and <tt>Ns</tt> are as defined in <xref secti | |||
on="4" sectionFormat="comma" target="OPRF"/> for | on="4" sectionFormat="comma" target="RFC9497"/> for | |||
OPRF(P-384, SHA-384). The constant <tt>Nk</tt>, which is also equal to <tt>Nh</t | OPRF(P-384, SHA-384). For this protocol, the constant <tt>Nk</tt>, which is also | |||
t> as defined | equal to <tt>Nh</tt> as defined | |||
in <xref section="4" sectionFormat="comma" target="OPRF"/>, is defined by <xref | in <xref section="4" sectionFormat="comma" target="RFC9497"/>, is defined by <xr | |||
target="private-token-type"/>.</t> | ef target="private-token-type"/>. | |||
<!-- Lynne: If authors agree to the suggested update below, make a | ||||
link for the title of Section 4.4 of [OPRF] --> | ||||
<!-- [rfced] Section 5: We found the second sentence here | ||||
confusing, because Section 4 of [OPRF] shows three different values | ||||
for Nh: 64 (Sections 4.1, 4.2, and 4.5), 32 (Section 4.3), and | ||||
48 (Section 4.4). If the suggested text is not correct, please | ||||
provide clarifying text. (For ease of the reader, we suggest | ||||
specifying Section 4.4 in both sentences.) | ||||
Original: | ||||
The constants Ne and Ns are as defined in [OPRF], Section 4 for | ||||
OPRF(P-384, SHA-384). The constant Nk, which is also equal to Nh as | ||||
defined in [OPRF], Section 4, is defined by Section 8.2.1. | ||||
Suggested (because Section 8.2.1 says "Nk: 48" and Section 4.4 of | ||||
[OPRF] says "Nh = 48"): | ||||
The constants Ne and Ns are as defined in [OPRF], Section 4.4 | ||||
("OPRF(P-384, SHA-384)"). For this protocol, the constant Nk, | ||||
which is also equal to Nh as defined in [OPRF], Section 4.4, is | ||||
defined by Section 8.2.1. --> | ||||
</t> | ||||
<section anchor="private-request"> | <section anchor="private-request"> | |||
<name>Client-to-Issuer Request</name> | <name>Client-to-Issuer Request</name> | |||
<t>The Client first creates a context as follows:</t> | <t>The Client first creates a context as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
client_context = SetupVOPRFClient("P384-SHA384", pkI) | client_context = SetupVOPRFClient("P384-SHA384", pkI) | |||
]]></artwork> | ]]></artwork> | |||
<t>Here, "P384-SHA384" is the identifier corresponding to the | <t>Here, "P384-SHA384" is the identifier corresponding to the | |||
OPRF(P-384, SHA-384) ciphersuite in <xref target="OPRF"/>. SetupVOPRFClient | OPRF(P-384, SHA-384) ciphersuite defined in <xref target="RFC9497"/>. SetupVOPRF | |||
is defined in <xref section="3.2" sectionFormat="comma" target="OPRF"/>.</t> | Client | |||
is defined in <xref section="3.2" sectionFormat="comma" target="RFC9497"/>.</t> | ||||
<t>The Client then creates an issuance request message for a random 32-b yte value <tt>nonce</tt> | <t>The Client then creates an issuance request message for a random 32-b yte value <tt>nonce</tt> | |||
with the input challenge and Issuer key identifier as described below:</t> | with the input challenge and Issuer key identifier as described below: | |||
<!-- [rfced] Sections 5.1 and 6.1: "a random 32-byte value nonce" | ||||
reads oddly, as it seems to indicate "a (random) value nonce of | ||||
32 bytes". May we update as suggested? | ||||
Original: | ||||
The Client then creates an issuance request message for a random | ||||
32-byte value nonce with the input challenge and Issuer key | ||||
identifier as described below: | ||||
... | ||||
The Client first creates an issuance request message for a random | ||||
32-byte value nonce using the input challenge and Issuer key | ||||
identifier as follows: | ||||
Suggested: | ||||
The Client then creates an issuance request message for a random | ||||
nonce having a 32-byte value, along with the input challenge and | ||||
Issuer key identifier, as follows: | ||||
... | ||||
The Client first creates an issuance request message for a random | ||||
nonce having a 32-byte value, also using the input challenge and | ||||
Issuer key identifier, as follows: --> | ||||
</t> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
nonce = random(32) | nonce = random(32) | |||
challenge_digest = SHA256(challenge) | challenge_digest = SHA256(challenge) | |||
token_input = concat(0x0001, // Token type field is 2 bytes long | token_input = concat(0x0001, // Token type field is 2 bytes long | |||
nonce, | nonce, | |||
challenge_digest, | challenge_digest, | |||
token_key_id) | token_key_id) | |||
blind, blinded_element = client_context.Blind(token_input) | blind, blinded_element = client_context.Blind(token_input) | |||
]]></artwork> | ]]></artwork> | |||
<t>The Blind function is defined in <xref section="3.3.2" sectionFormat= "comma" target="OPRF"/>. | <t>The Blind function is defined in <xref section="3.3.2" sectionFormat= "comma" target="RFC9497"/>. | |||
If the Blind function fails, the Client aborts the protocol. | If the Blind function fails, the Client aborts the protocol. | |||
The Client stores the <tt>nonce</tt> and <tt>challenge_digest</tt> values locall y | The Client stores the <tt>nonce</tt> and <tt>challenge_digest</tt> values locall y | |||
for use when finalizing the issuance protocol to produce a token | for use when finalizing the issuance protocol to produce a token | |||
(as described in <xref target="private-finalize"/>).</t> | (as described in <xref target="private-finalize"/>). | |||
<!-- [rfced] Section 5.1: We found this sentence confusing, because | ||||
in Section 3.3.2 of [OPRF] we see "The VOPRF protocol begins with the | ||||
client blinding its input, using the same Blind function as in | ||||
Section 3.3.1". Should "Section 3.3.2" be "Sections 3.3.1 and 3.3.2" | ||||
instead? | ||||
Original: | ||||
The Blind function is defined in [OPRF], Section 3.3.2. | ||||
Possibly: | ||||
The Blind function is discussed in Sections 3.3.1 and 3.3.2 of | ||||
[OPRF]. --> | ||||
</t> | ||||
<t>The Client then creates a TokenRequest structured as follows:</t> | <t>The Client then creates a TokenRequest structured as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ | uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ | |||
uint8_t truncated_token_key_id; | uint8_t truncated_token_key_id; | |||
uint8_t blinded_msg[Ne]; | uint8_t blinded_msg[Ne]; | |||
} TokenRequest; | } TokenRequest; | |||
]]></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, which matches the type in the c hallenge.</li> | <li>"token_type" is a 2-octet integer, which matches the type in the c hallenge.</li> | |||
<li>"truncated_token_key_id" is the least significant byte of the <tt> token_key_id</tt> | <li>"truncated_token_key_id" is the least significant byte of the <tt> token_key_id</tt> | |||
(<xref target="issuer-configuration"/>) in network byte order (in other words, t he last 8 | (<xref target="issuer-configuration"/>) in network byte order (in other words, t he last 8 | |||
bits of <tt>token_key_id</tt>). This value is truncated so that Issuers cannot u se | bits of <tt>token_key_id</tt>). This value is truncated so that Issuers cannot u se | |||
<tt>token_key_id</tt> as a way of uniquely identifying Clients; see <xref target ="security"/> | <tt>token_key_id</tt> as a way of uniquely identifying Clients; see <xref target ="security"/> | |||
and referenced information for more details.</li> | and referenced information for more details.</li> | |||
<li>"blinded_msg" is the Ne-octet blinded message defined above, compu ted as | <li>"blinded_msg" is the Ne-octet blinded message defined above, compu ted as | |||
<tt>SerializeElement(blinded_element)</tt>.</li> | <tt>SerializeElement(blinded_element)</tt>.</li> | |||
<!-- [rfced] Sections 5.1 and 6.1: Does "referenced information" | ||||
refer to citations in these two sections, Section 7, or all three | ||||
sections? | ||||
Also, we do not see any mention of "truncat(ed)", "token_key_id", | ||||
"unique(ly)", or "ident(ifying)" in Section 7. | ||||
Will the intended meaning of this text be clear to readers? | ||||
Original: | ||||
This value is truncated so that | ||||
Issuers cannot use token_key_id as a way of uniquely identifying | ||||
Clients; see Section 7 and referenced information for more | ||||
details. | ||||
... | ||||
This value is truncated so that | ||||
Issuers cannot use token_key_id as a way of uniquely identifying | ||||
Clients; see Section 7 and referenced information for more | ||||
details. --> | ||||
</ul> | </ul> | |||
<t>The values <tt>token_input</tt> and <tt>blinded_element</tt> are stor ed locally and used | <t>The values <tt>token_input</tt> and <tt>blinded_element</tt> are stor ed locally and used | |||
later as described in <xref target="private-finalize"/>. The Client then generat es an HTTP | later, as described in <xref target="private-finalize"/>. The Client then genera tes an HTTP | |||
POST request to send to the Issuer Request URL, with the TokenRequest as the | POST request to send to the Issuer Request URL, with the TokenRequest as the | |||
content. The media type for this request is | content. The media type for this request is | |||
"application/private-token-request". An example request for the Issuer Request U RL | "application/private-token-request". An example request for the Issuer Request U RL | |||
"https://issuer.example.net/request" is shown below.</t> | "https://issuer.example.net/request" is shown below. | |||
<!-- [rfced] Section 5.1: We found this sentence confusing. Would | ||||
it help to clarify as suggested, along the lines of text earlier in | ||||
this section and in Section 6.1? | ||||
Original: | ||||
The values token_input and blinded_element are stored locally and | ||||
used later as described in Section 5.3. | ||||
Suggested: | ||||
The values token_input and blinded_element are stored locally for | ||||
use when finalizing the issuance protocol to produce a token (as | ||||
described in Section 5.3). --> | ||||
</t> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
POST /request HTTP/1.1 | POST /request HTTP/1.1 | |||
Host: issuer.example.net | Host: issuer.example.net | |||
Accept: application/private-token-response | Accept: application/private-token-response | |||
Content-Type: application/private-token-request | Content-Type: application/private-token-request | |||
Content-Length: <Length of TokenRequest> | Content-Length: <Length of TokenRequest> | |||
<Bytes containing the TokenRequest> | <Bytes containing the TokenRequest> | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
<section anchor="private-response"> | <section anchor="private-response"> | |||
<name>Issuer-to-Client Response</name> | <name>Issuer-to-Client Response</name> | |||
<t>Upon receipt of the request, the Issuer validates the following condi tions:</t> | <t>Upon receipt of the request, the Issuer validates the following condi tions:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The TokenRequest contains a supported token_type.</li> | <li>The TokenRequest contains a supported token_type.</li> | |||
<li>The TokenRequest.truncated_token_key_id corresponds to the truncat ed key ID | <li>The TokenRequest.truncated_token_key_id corresponds to the truncat ed key ID | |||
of a Public Key owned by the Issuer.</li> | of a public key owned by the Issuer.</li> | |||
<li>The TokenRequest.blinded_msg is of the correct size.</li> | <li>The TokenRequest.blinded_msg is of the correct size.</li> | |||
</ul> | </ul> | |||
<t>If any of these conditions is not met, the Issuer MUST return an HTTP 422 | <t>If any of these conditions are not met, the Issuer <bcp14>MUST</bcp14 > return an HTTP 422 | |||
(Unprocessable Content) error to the client.</t> | (Unprocessable Content) error to the client.</t> | |||
<t>If these conditions are met, the Issuer then tries to deserialize | <t>If these conditions are met, the Issuer then tries to deserialize | |||
TokenRequest.blinded_msg using DeserializeElement from | TokenRequest.blinded_msg using DeserializeElement | |||
<xref section="2.1" sectionFormat="of" target="OPRF"/>, yielding <tt>blinded_ele | (<xref section="2.1" sectionFormat="comma" target="RFC9497"/>), yielding <tt>bli | |||
ment</tt>. If this fails, the | nded_element</tt>. If this fails, the | |||
Issuer MUST return an HTTP 422 (Unprocessable Content) error to the | Issuer <bcp14>MUST</bcp14> return an HTTP 422 (Unprocessable Content) error to t | |||
he | ||||
client. Otherwise, if the Issuer is willing to produce a token to the Client, | client. Otherwise, if the Issuer is willing to produce a token to the Client, | |||
the Issuer completes the issuance flow by computing a blinded response as | the Issuer completes the issuance flow by computing a blinded response as | |||
follows:</t> | follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
server_context = SetupVOPRFServer("P384-SHA384", skI) | server_context = SetupVOPRFServer("P384-SHA384", skI) | |||
evaluate_element, proof = | evaluate_element, proof = | |||
server_context.BlindEvaluate(skI, pkI, blinded_element) | server_context.BlindEvaluate(skI, pkI, blinded_element) | |||
]]></artwork> | ]]></artwork> | |||
<t>SetupVOPRFServer is defined in <xref section="3.2" sectionFormat="com | <t>SetupVOPRFServer is defined in <xref section="3.2" sectionFormat="com | |||
ma" target="OPRF"/> and BlindEvaluate is | ma" target="RFC9497"/>, and BlindEvaluate is | |||
defined in <xref section="3.3.2" sectionFormat="comma" target="OPRF"/>. The Issu | defined in <xref section="3.3.2" sectionFormat="comma" target="RFC9497"/>. The I | |||
er then creates a TokenResponse | ssuer then creates a TokenResponse | |||
structured as follows:</t> | structured as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint8_t evaluate_msg[Ne]; | uint8_t evaluate_msg[Ne]; | |||
uint8_t evaluate_proof[Ns+Ns]; | uint8_t evaluate_proof[Ns+Ns]; | |||
} TokenResponse; | } TokenResponse; | |||
]]></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>"evaluate_msg" is the Ne-octet evaluated message, computed as | <li>"evaluate_msg" is the Ne-octet evaluated message, computed as | |||
skipping to change at line 501 ¶ | skipping to change at line 736 ¶ | |||
the content values TokenResponse.evaluate_msg and TokenResponse.evaluate_proof, | the content values TokenResponse.evaluate_msg and TokenResponse.evaluate_proof, | |||
yielding <tt>evaluated_element</tt> and <tt>proof</tt>. If deserialization of ei ther value | yielding <tt>evaluated_element</tt> and <tt>proof</tt>. If deserialization of ei ther value | |||
fails, the Client aborts the protocol. Otherwise, the Client processes the | fails, the Client aborts the protocol. Otherwise, the Client processes the | |||
response as follows:</t> | response as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
authenticator = client_context.Finalize(token_input, blind, | authenticator = client_context.Finalize(token_input, blind, | |||
evaluated_element, | evaluated_element, | |||
blinded_element, | blinded_element, | |||
proof) | proof) | |||
]]></artwork> | ]]></artwork> | |||
<t>The Finalize function is defined in <xref section="3.3.2" sectionForm at="comma" target="OPRF"/>. If this | <t>The Finalize function is defined in <xref section="3.3.2" sectionForm at="comma" target="RFC9497"/>. If this | |||
succeeds, the Client then constructs a Token as follows:</t> | succeeds, the Client then constructs a Token as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ | uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */ | |||
uint8_t nonce[32]; | uint8_t nonce[32]; | |||
uint8_t challenge_digest[32]; | uint8_t challenge_digest[32]; | |||
uint8_t token_key_id[32]; | uint8_t token_key_id[32]; | |||
uint8_t authenticator[Nk]; | uint8_t authenticator[Nk]; | |||
} Token; | } Token; | |||
]]></artwork> | ]]></artwork> | |||
<t>The Token.nonce value is that which was created in <xref target="priv | <t>The Token.nonce value is the value that was created according to <xre | |||
ate-request"/>. | f target="private-request"/>. | |||
If the Finalize function fails, the Client aborts the protocol.</t> | If the Finalize function fails, the Client aborts the protocol. | |||
<!-- [rfced] Section 5.3: Please confirm that "Section 5.1" and not | ||||
"Section 5.4" is correct here. We ask because we do not see | ||||
"Token.nonce" mentioned in Section 5.1. | ||||
Original: | ||||
The Token.nonce value is that which was created in Section 5.1. If | ||||
the Finalize function fails, the Client aborts the protocol. | ||||
Possibly: | ||||
The Token.nonce value is the value that was created according to | ||||
Section 5.4. --> | ||||
</t> | ||||
</section> | </section> | |||
<section anchor="token-verification"> | <section anchor="token-verification"> | |||
<name>Token Verification</name> | <name>Token Verification</name> | |||
<t>Verifying a Token requires creating a VOPRF context using the Issuer Private | <t>Verifying a Token requires creating a Verifiable Oblivious Pseudorand om Function (VOPRF) context using the Issuer Private | |||
Key and Public Key, evaluating the token contents, and comparing the result | Key and Public Key, evaluating the token contents, and comparing the result | |||
against the token authenticator value:</t> | against the token authenticator value:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
server_context = SetupVOPRFServer("P384-SHA384", skI) | server_context = SetupVOPRFServer("P384-SHA384", skI) | |||
token_authenticator_input = | token_authenticator_input = | |||
concat(Token.token_type, | concat(Token.token_type, | |||
Token.nonce, | Token.nonce, | |||
Token.challenge_digest, | Token.challenge_digest, | |||
Token.token_key_id) | Token.token_key_id) | |||
token_authenticator = | token_authenticator = | |||
server_context.Evaluate(token_authenticator_input) | server_context.Evaluate(token_authenticator_input) | |||
valid = (token_authenticator == Token.authenticator) | valid = (token_authenticator == Token.authenticator) | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
<section anchor="issuer-configuration"> | <section anchor="issuer-configuration"> | |||
<name>Issuer Configuration</name> | <name>Issuer Configuration</name> | |||
<t>Issuers are configured with Issuer Private and Public Keys, each deno | <t>Issuers are configured with Issuer Private Keys and Public Keys, each | |||
ted <tt>skI</tt> | denoted <tt>skI</tt> | |||
and <tt>pkI</tt>, respectively, used to produce tokens. These keys MUST NOT be r | and <tt>pkI</tt>, respectively, used to produce tokens. These keys <bcp14>MUST N | |||
eused | OT</bcp14> be reused | |||
in other protocols. A RECOMMENDED method for generating keys is as | in other protocols. A <bcp14>RECOMMENDED</bcp14> method for generating keys is a | |||
s | ||||
follows:</t> | follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
seed = random(Ns) | seed = random(Ns) | |||
(skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") | (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass") | |||
]]></artwork> | ]]></artwork> | |||
<t>The DeriveKeyPair function is defined in <xref section="3.3.1" sectio nFormat="comma" target="OPRF"/>. | <t>The DeriveKeyPair function is defined in <xref section="3.2.1" sectio nFormat="comma" target="RFC9497"/>. | |||
The key identifier for a public key <tt>pkI</tt>, denoted <tt>token_key_id</tt>, is computed | The key identifier for a public key <tt>pkI</tt>, denoted <tt>token_key_id</tt>, is computed | |||
as follows:</t> | as follows: | |||
<!-- [rfced] Section 5.5: Because (1) DeriveKeyPair is not mentioned | ||||
in Section 3.3.1 of [OPRF] and (2) Section 3.2 of [OPRF] contains the | ||||
text "the deterministic key generation function DeriveKeyPair, as | ||||
described in Section 3.2.1", we changed "3.3.1" to "3.2.1" in this | ||||
sentence accordingly. If this is incorrect, please clarify the text. | ||||
Original: | ||||
The DeriveKeyPair function is defined in [OPRF], Section 3.3.1. | ||||
Currently: | ||||
The DeriveKeyPair function is defined in [OPRF], Section 3.2.1. --> | ||||
</t> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
token_key_id = SHA256(SerializeElement(pkI)) | token_key_id = SHA256(SerializeElement(pkI)) | |||
]]></artwork> | ]]></artwork> | |||
<t>Since Clients truncate <tt>token_key_id</tt> in each <tt>TokenRequest | <t>Since Clients truncate <tt>token_key_id</tt> in each <tt>TokenRequest | |||
</tt>, Issuers SHOULD | </tt>, Issuers <bcp14>SHOULD</bcp14> | |||
ensure that the truncated form of new key IDs do not collide with other | ensure that the truncated forms of new key IDs do not collide with other | |||
truncated key IDs in rotation. Collisions can cause the Issuer to use | truncated key IDs in rotation. Collisions can cause the Issuer to use | |||
the wrong Issuer Private Key for issuance, which will in turn cause the | the wrong Issuer Private Key for issuance, which will in turn cause the | |||
resulting tokens to be invalid. There is no known security consequence of | resulting tokens to be invalid. There is no known security consequence of | |||
using the the wrong Issuer Private Key. A possible exception to this constraint | using the wrong Issuer Private Key. A possible exception to this constrain | |||
would be a colliding key that is still in use but in the process of being | t | |||
rotated out, in which case the collision cannot reasonably be avoided but it | would be a colliding key that is still in use but is in the process of being | |||
is expected to be transient.</t> | rotated out, in which case the collision cannot reasonably be avoided; however, | |||
this situation is expected to be transient.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="public-flow"> | <section anchor="public-flow"> | |||
<name>Issuance Protocol for Publicly Verifiable Tokens</name> | <name>Issuance Protocol for Publicly Verifiable Tokens</name> | |||
<t>This section describes a variant of the issuance protocol in <xref targ | <t>This section describes a variant of the issuance protocol discussed in | |||
et="private-flow"/> | <xref target="private-flow"/> | |||
for producing publicly verifiable tokens using the protocol in <xref target="BLI | for producing publicly verifiable tokens using the protocol defined in <xref tar | |||
NDRSA"/>. | get="RFC9474"/>. | |||
In particular, this variant of the issuance protocol works for the | In particular, this variant of the issuance protocol works for the | |||
RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic | RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic | |||
blind RSA protocol variants described in <xref section="5" sectionFormat="of" ta | blind RSA protocol variants described in <xref section="5" sectionFormat="of" ta | |||
rget="BLINDRSA"/>.</t> | rget="RFC9474"/>.</t> | |||
<t>The publicly verifiable issuance protocol differs from the protocol in | <t>The publicly verifiable issuance protocol differs from the protocol def | |||
ined in | ||||
<xref target="private-flow"/> in that the output tokens are publicly verifiable by anyone | <xref target="private-flow"/> in that the output tokens are publicly verifiable by anyone | |||
with the Issuer Public Key. This means any Origin can select a given Issuer to | with the Issuer Public Key. This means any Origin can select a given Issue | |||
produce tokens, as long as the Origin has the Issuer public key, without | r to | |||
produce tokens, as long as the Origin has the Issuer Public Key, without | ||||
explicit coordination or permission from the Issuer. This is because the Issuer | explicit coordination or permission from the Issuer. This is because the Issuer | |||
does not learn the Origin that requested the token during the issuance protocol. </t> | does not learn the Origin that requested the token during the issuance protocol. </t> | |||
<t>Beyond this difference, the publicly verifiable issuance protocol varia nt is | <t>Beyond this difference, the publicly verifiable issuance protocol varia nt is | |||
nearly identical to the privately verifiable issuance protocol variant. In | nearly identical to the privately verifiable issuance protocol variant. In | |||
particular, Issuers provide an Issuer Private and Public Key, denoted skI and pk I, | particular, Issuers provide an Issuer Private Key and Public Key, denoted skI an d pkI, | |||
respectively, used to produce tokens as input to the protocol. See | respectively, used to produce tokens as input to the protocol. See | |||
<xref target="public-issuer-configuration"/> for how these keys are generated.</ t> | <xref target="public-issuer-configuration"/> for information about how these key s are generated.</t> | |||
<t>Clients provide the following as input to the issuance protocol:</t> | <t>Clients provide the following as input to the issuance protocol:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Issuer Request URL: A URL identifying the location to which issuance | <dt>Issuer Request URL:</dt><dd>A URL identifying the location to which | |||
requests | issuance requests | |||
are sent. This can be a URL derived from the "issuer-request-uri" value in the | are sent. This can be a URL derived from the "issuer-request-uri" value in the | |||
Issuer's directory resource, or it can be another Client-configured URL. The val ue | Issuer's directory resource, or it can be another Client-configured URL. The val ue | |||
of this parameter depends on the Client configuration and deployment model. | of this parameter depends on the Client configuration and deployment model. | |||
For example, in the 'Split Origin, Attester, Issuer' deployment model, the | For example, in the "Split Origin, Attester, Issuer" deployment model (<xref tar get="RFC9576" sectionFormat="comma" section="4.4"/>), the | |||
Issuer Request URL might correspond to the Client's configured Attester, | Issuer Request URL might correspond to the Client's configured Attester, | |||
and the Attester is configured to relay requests to the Issuer.</li> | and the Attester is configured to relay requests to the Issuer.</dd> | |||
<li>Issuer name: An identifier for the Issuer. This is typically a host | <dt>Issuer name:</dt><dd>An identifier for the Issuer. This is typically | |||
name that | a hostname that | |||
can be used to construct HTTP requests to the Issuer.</li> | can be used to construct HTTP requests to the Issuer.</dd> | |||
<li>Issuer Public Key: <tt>pkI</tt>, with a key identifier <tt>token_key | <dt>Issuer Public Key:</dt><dd><tt>pkI</tt>, with a key identifier <tt>t | |||
_id</tt> computed as | oken_key_id</tt> computed as | |||
described in <xref target="public-issuer-configuration"/>.</li> | described in <xref target="public-issuer-configuration"/>.</dd> | |||
<li>Challenge value: <tt>challenge</tt>, an opaque byte string. For exam | <dt>Challenge value:</dt><dd><tt>challenge</tt> -- an opaque byte string | |||
ple, this might | . For example, this might | |||
be provided by the redemption protocol in <xref target="AUTHSCHEME"/>.</li> | be provided by the redemption protocol described in <xref target="RFC9577"/>.</d | |||
</ul> | d> | |||
</dl> | ||||
<t>Given this configuration and these inputs, the two messages exchanged i n | <t>Given this configuration and these inputs, the two messages exchanged i n | |||
this protocol are described below. The constant <tt>Nk</tt> is defined by | this protocol are described below. For this protocol, the constant <tt>Nk</tt> i s defined by | |||
<xref target="public-token-type"/>.</t> | <xref target="public-token-type"/>.</t> | |||
<section anchor="public-request"> | <section anchor="public-request"> | |||
<name>Client-to-Issuer Request</name> | <name>Client-to-Issuer Request</name> | |||
<t>The Client first creates an issuance request message for a random 32- byte value | <t>The Client first creates an issuance request message for a random 32- byte value | |||
<tt>nonce</tt> using the input challenge and Issuer key identifier as follows:</ t> | <tt>nonce</tt> using the input challenge and Issuer key identifier as follows:</ t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
nonce = random(32) | nonce = random(32) | |||
challenge_digest = SHA256(challenge) | challenge_digest = SHA256(challenge) | |||
token_input = concat(0x0002, // Token type field is 2 bytes long | token_input = concat(0x0002, // Token type field is 2 bytes long | |||
nonce, | nonce, | |||
challenge_digest, | challenge_digest, | |||
token_key_id) | token_key_id) | |||
blinded_msg, blind_inv = | blinded_msg, blind_inv = | |||
Blind(pkI, PrepareIdentity(token_input)) | Blind(pkI, PrepareIdentity(token_input)) | |||
]]></artwork> | ]]></artwork> | |||
<t>The PrepareIdentity and Blind functions are defined in | <t>The PrepareIdentity and Blind functions are defined in | |||
<xref section="4.1" sectionFormat="of" target="BLINDRSA"/> and <xref section="4. 2" sectionFormat="of" target="BLINDRSA"/>, respectively. | Sections <xref target="RFC9474" section="4.1" sectionFormat="bare"/> and <x ref target="RFC9474" section="4.2" sectionFormat="bare"/> of <xref target="RFC94 74"/>, respectively. | |||
The Client stores the nonce and challenge_digest values locally for use | The Client stores the nonce and challenge_digest values locally for use | |||
when finalizing the issuance protocol to produce a token (as described | when finalizing the issuance protocol to produce a token (as described | |||
in <xref target="public-finalize"/>).</t> | in <xref target="public-finalize"/>).</t> | |||
<t>The Client then creates a TokenRequest structured as follows:</t> | <t>The Client then creates a TokenRequest structured as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ | uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ | |||
uint8_t truncated_token_key_id; | uint8_t truncated_token_key_id; | |||
uint8_t blinded_msg[Nk]; | uint8_t blinded_msg[Nk]; | |||
} TokenRequest; | } TokenRequest; | |||
skipping to change at line 656 ¶ | skipping to change at line 918 ¶ | |||
</section> | </section> | |||
<section anchor="public-response"> | <section anchor="public-response"> | |||
<name>Issuer-to-Client Response</name> | <name>Issuer-to-Client Response</name> | |||
<t>Upon receipt of the request, the Issuer validates the following condi tions:</t> | <t>Upon receipt of the request, the Issuer validates the following condi tions:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The TokenRequest contains a supported token_type.</li> | <li>The TokenRequest contains a supported token_type.</li> | |||
<li>The TokenRequest.truncated_token_key_id corresponds to the truncat ed key | <li>The TokenRequest.truncated_token_key_id corresponds to the truncat ed key | |||
ID of an Issuer Public Key.</li> | ID of an Issuer Public Key.</li> | |||
<li>The TokenRequest.blinded_msg is of the correct size.</li> | <li>The TokenRequest.blinded_msg is of the correct size.</li> | |||
</ul> | </ul> | |||
<t>If any of these conditions is not met, the Issuer MUST return an HTTP 422 | <t>If any of these conditions are not met, the Issuer <bcp14>MUST</bcp14 > return an HTTP 422 | |||
(Unprocessable Content) error to the Client. Otherwise, if the | (Unprocessable Content) error to the Client. Otherwise, if the | |||
Issuer is willing to produce a token to the Client, the Issuer | Issuer is willing to produce a token to the Client, the Issuer | |||
completes the issuance flow by computing a blinded response as follows:</t> | completes the issuance flow by computing a blinded response as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
blind_sig = BlindSign(skI, TokenRequest.blinded_msg) | blind_sig = BlindSign(skI, TokenRequest.blinded_msg) | |||
]]></artwork> | ]]></artwork> | |||
<t>The BlindSign function is defined in <xref section="4.3" sectionForma t="of" target="BLINDRSA"/>. | <t>The BlindSign function is defined in <xref section="4.3" sectionForma t="of" target="RFC9474"/>. | |||
The result is encoded and transmitted to the client in the following | The result is encoded and transmitted to the client in the following | |||
TokenResponse structure:</t> | TokenResponse structure:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint8_t blind_sig[Nk]; | uint8_t blind_sig[Nk]; | |||
} TokenResponse; | } TokenResponse; | |||
]]></artwork> | ]]></artwork> | |||
<t>The Issuer generates an HTTP response with status code 200 whose cont ent | <t>The Issuer generates an HTTP response with status code 200 whose cont ent | |||
consists of TokenResponse, with the content type set as | consists of TokenResponse, with the content type set as | |||
"application/private-token-response".</t> | "application/private-token-response".</t> | |||
skipping to change at line 690 ¶ | skipping to change at line 952 ¶ | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
<section anchor="public-finalize"> | <section anchor="public-finalize"> | |||
<name>Finalization</name> | <name>Finalization</name> | |||
<t>Upon receipt, the Client handles the response and, if successful, pro cesses the | <t>Upon receipt, the Client handles the response and, if successful, pro cesses the | |||
content as follows:</t> | content as follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
authenticator = | authenticator = | |||
Finalize(pkI, nonce, blind_sig, blind_inv) | Finalize(pkI, nonce, blind_sig, blind_inv) | |||
]]></artwork> | ]]></artwork> | |||
<t>The Finalize function is defined in <xref section="4.4" sectionFormat | <t>The Finalize function is defined in <xref section="4.4" sectionFormat | |||
="of" target="BLINDRSA"/>. If this | ="of" target="RFC9474"/>. If this | |||
succeeds, the Client then constructs a Token as described in <xref target="AUTHS | succeeds, the Client then constructs a Token as described in <xref target="RFC95 | |||
CHEME"/> as | 77"/> as | |||
follows:</t> | follows:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
struct { | struct { | |||
uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ | uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */ | |||
uint8_t nonce[32]; | uint8_t nonce[32]; | |||
uint8_t challenge_digest[32]; | uint8_t challenge_digest[32]; | |||
uint8_t token_key_id[32]; | uint8_t token_key_id[32]; | |||
uint8_t authenticator[Nk]; | uint8_t authenticator[Nk]; | |||
} Token; | } Token; | |||
]]></artwork> | ]]></artwork> | |||
<t>The Token.nonce value is that which was sampled in <xref target="priv | <t>The Token.nonce value is the value that was sampled according to <xre | |||
ate-request"/>. | f target="private-request"/>. | |||
If the Finalize function fails, the Client aborts the protocol.</t> | If the Finalize function fails, the Client aborts the protocol. | |||
<!-- [rfced] Section 6.3: Should "Section 5.1" be "Section 6.4" | ||||
here? We ask because we do not see "Token.nonce" mentioned in | ||||
Section 5.1 (we have a similar question regarding Section 5.3), and | ||||
it appears that a subsection of Section 6 should be cited here | ||||
(noting that we don't see "Token.nonce" mentioned in Section 6.1 | ||||
either). | ||||
Original: | ||||
The Token.nonce value is that which was sampled in Section 5.1. If | ||||
the Finalize function fails, the Client aborts the protocol. | ||||
Possibly: | ||||
The Token.nonce value is the value that was sampled according to | ||||
Section 6.4. --> | ||||
</t> | ||||
</section> | </section> | |||
<section anchor="token-verification-1"> | <section anchor="token-verification-1"> | |||
<name>Token Verification</name> | <name>Token Verification</name> | |||
<t>Verifying a Token requires checking that Token.authenticator is a val id | <t>Verifying a Token requires checking that Token.authenticator is a val id | |||
signature over the remainder of the token input using the Issuer Public Key. | signature over the remainder of the token input using the Issuer Public | |||
The function <tt>RSASSA-PSS-VERIFY</tt> is defined in <xref section="8.1.2" sect | Key. The function <tt>RSASSA-PSS-VERIFY</tt> is defined in <xref section=" | |||
ionFormat="of" target="RFC8017"/>, | 8.1.2" sectionFormat="of" target="RFC8017"/>, | |||
using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask | using SHA-384 as the hash function, MGF1 with SHA-384 as the Probabilistic Signa | |||
ture Scheme (PSS) mask | ||||
generation function (MGF), and a 48-byte salt length (sLen).</t> | generation function (MGF), and a 48-byte salt length (sLen).</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
token_authenticator_input = | token_authenticator_input = | |||
concat(Token.token_type, | concat(Token.token_type, | |||
Token.nonce, | Token.nonce, | |||
Token.challenge_digest, | Token.challenge_digest, | |||
Token.token_key_id) | Token.token_key_id) | |||
valid = RSASSA-PSS-VERIFY(pkI, | valid = RSASSA-PSS-VERIFY(pkI, | |||
token_authenticator_input, | token_authenticator_input, | |||
Token.authenticator) | Token.authenticator) | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
<section anchor="public-issuer-configuration"> | <section anchor="public-issuer-configuration"> | |||
<name>Issuer Configuration</name> | <name>Issuer Configuration</name> | |||
<t>Issuers are configured with Issuer Private and Public Keys, each deno | <t>Issuers are configured with Issuer Private Keys and Public Keys, each | |||
ted skI and | denoted skI and | |||
pkI, respectively, used to produce tokens. Each key SHALL be generated | pkI, respectively, used to produce tokens. Each key <bcp14>SHALL</bcp14> be gene | |||
securely, for example as specified in FIPS 186-5 <xref target="DSS"/>. | rated | |||
These keys MUST NOT be reused in other protocols.</t> | securely -- for example, as specified in FIPS 186-5 <xref target="DSS"/>. | |||
<t>The key identifier for an Issuer Private and Public Key (skI, pkI), | These keys <bcp14>MUST NOT</bcp14> be reused in other protocols.</t> | |||
<t>The key identifier for an Issuer Private Key and Public Key (skI, pkI | ||||
), | ||||
denoted <tt>token_key_id</tt>, is computed as SHA256(encoded_key), where encoded _key | denoted <tt>token_key_id</tt>, is computed as SHA256(encoded_key), where encoded _key | |||
is a DER-encoded SubjectPublicKeyInfo <xref target="RFC5280"/> (SPKI) object car | is a DER-encoded SubjectPublicKeyInfo (SPKI) object <xref target="RFC5280"/> | |||
rying pkI | carrying pkI | |||
as a DER-encoded RSAPublicKey value <xref target="RFC5756"/> in the subjectPubli cKey | as a DER-encoded RSAPublicKey value <xref target="RFC5756"/> in the subjectPubli cKey | |||
field. Additionally, the SPKI object MUST use the id-RSASSA-PSS object | field. Additionally, the SPKI object <bcp14>MUST</bcp14> use the id-RSASSA-PSS o bject | |||
identifier in the algorithm field within the SPKI object, the parameters field | identifier in the algorithm field within the SPKI object, the parameters field | |||
MUST contain a RSASSA-PSS-params value, and MUST include the hashAlgorithm, | <bcp14>MUST</bcp14> contain an RSASSA-PSS-params value, and <bcp14>MUST</bcp14> | |||
maskGenAlgorithm, and saltLength values. The saltLength MUST match the output | include the hashAlgorithm, | |||
size of the hash function associated with the public key and token type.</t> | maskGenAlgorithm, and saltLength values. The saltLength <bcp14>MUST</bcp14> matc | |||
h the output | ||||
size of the hash function associated with the public key and token type. | ||||
<!-- [rfced] Section 6.5: | ||||
a) We do not see any mention of "RSAPublicKey" in RFC 5756. Will | ||||
this citation be clear to readers? | ||||
Original: | ||||
The key identifier for an Issuer Private and Public Key (skI, pkI), | ||||
denoted token_key_id, is computed as SHA256(encoded_key), where | ||||
encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) | ||||
object carrying pkI as a DER-encoded RSAPublicKey value [RFC5756] in | ||||
the subjectPublicKey field. | ||||
b) This sentence does not parse. If the suggested text is not | ||||
correct, please clarify what the "and MUST" refers to. | ||||
Original: | ||||
Additionally, the SPKI object MUST use | ||||
the id-RSASSA-PSS object identifier in the algorithm field within the | ||||
SPKI object, the parameters field MUST contain a RSASSA-PSS-params | ||||
value, and MUST include the hashAlgorithm, maskGenAlgorithm, and | ||||
saltLength values. | ||||
Suggested (fixing the run-on sentence and guessing that "and MUST" | ||||
applies to the parameters field): | ||||
Additionally, (1) the SPKI object MUST use the id-RSASSA-PSS object | ||||
identifier in the algorithm field within the SPKI object and | ||||
(2) the parameters field MUST contain an RSASSA-PSS-params value and | ||||
MUST include the hashAlgorithm, maskGenAlgorithm, and saltLength | ||||
values. --> | ||||
</t> | ||||
<t>An example sequence of the SPKI object (in ASN.1 format, with the act ual public key | <t>An example sequence of the SPKI object (in ASN.1 format, with the act ual public key | |||
bytes truncated) for a 2048-bit key is below:</t> | bytes truncated) for a 2048-bit key is shown below:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER | $ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER | |||
0:d=0 hl=4 l= 338 cons: SEQUENCE | 0:d=0 hl=4 l= 338 cons: SEQUENCE | |||
4:d=1 hl=2 l= 61 cons: SEQUENCE | 4:d=1 hl=2 l= 61 cons: SEQUENCE | |||
6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss | 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss | |||
17:d=2 hl=2 l= 48 cons: SEQUENCE | 17:d=2 hl=2 l= 48 cons: SEQUENCE | |||
19:d=3 hl=2 l= 13 cons: cont [ 0 ] | 19:d=3 hl=2 l= 13 cons: cont [ 0 ] | |||
21:d=4 hl=2 l= 11 cons: SEQUENCE | 21:d=4 hl=2 l= 11 cons: SEQUENCE | |||
23:d=5 hl=2 l= 9 prim: OBJECT :sha384 | 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 | |||
34:d=3 hl=2 l= 26 cons: cont [ 1 ] | 34:d=3 hl=2 l= 26 cons: cont [ 1 ] | |||
36:d=4 hl=2 l= 24 cons: SEQUENCE | 36:d=4 hl=2 l= 24 cons: SEQUENCE | |||
38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 | 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 | |||
49:d=5 hl=2 l= 11 cons: SEQUENCE | 49:d=5 hl=2 l= 11 cons: SEQUENCE | |||
51:d=6 hl=2 l= 9 prim: OBJECT :sha384 | 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 | |||
62:d=3 hl=2 l= 3 cons: cont [ 2 ] | 62:d=3 hl=2 l= 3 cons: cont [ 2 ] | |||
64:d=4 hl=2 l= 1 prim: INTEGER :30 | 64:d=4 hl=2 l= 1 prim: INTEGER :30 | |||
67:d=1 hl=4 l= 271 prim: BIT STRING | 67:d=1 hl=4 l= 271 prim: BIT STRING | |||
... truncated public key bytes ... | ... truncated public key bytes ... | |||
]]></artwork> | ]]></artwork> | |||
<t>Since Clients truncate <tt>token_key_id</tt> in each <tt>TokenRequest | <t>Since Clients truncate <tt>token_key_id</tt> in each <tt>TokenRequest | |||
</tt>, Issuers SHOULD | </tt>, Issuers <bcp14>SHOULD</bcp14> | |||
ensure that the truncated form of new key IDs do not collide with other | ensure that the truncated forms of new key IDs do not collide with other | |||
truncated key IDs in rotation. Collisions can cause the Issuer to use | truncated key IDs in rotation. Collisions can cause the Issuer to use | |||
the wrong Issuer Private Key for issuance, which will in turn cause the | the wrong Issuer Private Key for issuance, which will in turn cause the | |||
resulting tokens to be invalid. There is no known security consequence of | resulting tokens to be invalid. There is no known security consequence of | |||
using the the wrong Issuer Private Key. A possible exception to this constraint | using the wrong Issuer Private Key. A possible exception to this constrain | |||
would be a colliding key that is still in use but in the process of being | t | |||
rotated out, in which case the collision cannot reasonably be avoided but it | would be a colliding key that is still in use but is in the process of being | |||
is expected to be transient.</t> | rotated out, in which case the collision cannot reasonably be avoided; however, | |||
this | ||||
situation is expected to be transient.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="security"> | <section anchor="security"> | |||
<name>Security considerations</name> | <name>Security Considerations</name> | |||
<t>This document outlines how to instantiate the Issuance protocol | <t>This document outlines how to instantiate the issuance protocol | |||
based on the VOPRF defined in <xref target="OPRF"/> and blind RSA protocol defin | based on the VOPRF defined in <xref target="RFC9497"/> and the blind RSA protoco | |||
ed in | l defined in | |||
<xref target="BLINDRSA"/>. All security considerations described in the VOPRF an | <xref target="RFC9474"/>. All security considerations described in the VOPRF and | |||
d blind RSA | blind RSA | |||
documents also apply in the Privacy Pass use-case. Considerations related to | documents also apply in the Privacy Pass use case. Considerations related to | |||
broader privacy and security concerns in a multi-Client and multi-Issuer | broader privacy and security concerns in a multi-Client and multi-Issuer | |||
setting are deferred to the architecture document <xref target="ARCHITECTURE"/>. | setting are covered in the architecture document <xref target="RFC9576"/>. In | |||
In | particular, Sections <xref target="RFC9576" section="4" sectionFormat="bare | |||
particular, Section <xref target="ARCHITECTURE" section="4" sectionFormat="bare" | "/> and <xref target="RFC9576" section="5" sectionFormat="bare"/> of <xref targe | |||
/> and Section <xref target="ARCHITECTURE" section="5" sectionFormat="bare"/> of | t="RFC9576"/> discuss | |||
<xref target="ARCHITECTURE"/> discuss | ||||
relevant privacy considerations influenced by the Privacy Pass deployment | relevant privacy considerations influenced by the Privacy Pass deployment | |||
model, and <xref section="6" sectionFormat="of" target="ARCHITECTURE"/> discusse s privacy considerations that | models, and <xref section="6" sectionFormat="of" target="RFC9576"/> discusses pr ivacy considerations that | |||
apply regardless of deployment model. Notable considerations include those perta ining to | apply regardless of deployment model. Notable considerations include those perta ining to | |||
Issuer Public Key rotation and consistency, where consistency is as described | Issuer Public Key rotation and consistency -- where consistency is as described | |||
in <xref target="CONSISTENCY"/>, and Issuer selection.</t> | in <xref target="I-D.ietf-privacypass-key-consistency"/> -- and Issuer selection | |||
.</t> | ||||
</section> | </section> | |||
<section anchor="iana-considerations"> | <section anchor="iana-considerations"> | |||
<name>IANA considerations</name> | <name>IANA Considerations</name> | |||
<t>This section contains considerations for IANA.</t> | ||||
<!-- [rfced] Sections 8.1, 8.2, and 8.3: A citation is used for the | ||||
"Well-Known URIs" registry (Section 8.1), but no citation is used for the | ||||
"Privacy Pass Token Type" registry (Section 8.2) or the "Media Types" | ||||
registry (Section 8.3). Is this intentional, or would you like to add | ||||
citations for the registries in Sections 8.2 and 8.3? Note that | ||||
[WellKnownURIs] is listed as a normative reference; if the other | ||||
registries are cited, let us know if they should be listed as informative | ||||
or normative. | ||||
Current: | ||||
IANA has updated the "Well-Known URIs" registry [WellKnownURIs] with | ||||
the following values. | ||||
... | ||||
[WellKnownURIs] | ||||
IANA, "Well-Known URIs", | ||||
<https://www.iana.org/assignments/well-known-uris/>. | ||||
--> | ||||
<!-- [rfced] Sections 8.2.1 and 8.2.2: The "Privacy Pass Token Type" registry | ||||
includes a "Change Controller" column, but "Change Controller" is not | ||||
included in these sections. May we add it to both sections? If so, we'll | ||||
place it after "Nid" and before "Reference" to correspond with the order | ||||
in the registry. | ||||
Link to registry: https://www.iana.org/assignments/privacy-pass | ||||
--> | ||||
<section anchor="wkuri-reg"> | <section anchor="wkuri-reg"> | |||
<name>Well-Known 'private-token-issuer-directory' URI</name> | <name>Well-Known "private-token-issuer-directory" URI</name> | |||
<t>This document updates the "Well-Known URIs" Registry <xref target="We | <t>IANA has updated the "Well-Known URIs" registry <xref target="WellKno | |||
llKnownURIs"/> with the | wnURIs"/> with the following values.</t> | |||
following values.</t> | ||||
<table anchor="wellknownuri-values"> | <table anchor="wellknownuri-values"> | |||
<name>'private-token-issuer-directory' Well-Known URI</name> | <name>"private-token-issuer-directory" Well-Known URI</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">URI Suffix</th> | <th align="left">URI Suffix</th> | |||
<th align="left">Change Controller</th> | <th align="left">Change Controller</th> | |||
<th align="left">Reference</th> | <th align="left">Reference</th> | |||
<th align="left">Status</th> | <th align="left">Status</th> | |||
<th align="left">Related information</th> | <th align="left">Related Information</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">private-token-issuer-directory</td> | <td align="left">private-token-issuer-directory</td> | |||
<td align="left">IETF</td> | <td align="left">IETF</td> | |||
<td align="left">[this document]</td> | <td align="left">RFC 9578</td> | |||
<td align="left">permanent</td> | <td align="left">permanent</td> | |||
<td align="left">None</td> | <td align="left">None</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
</section> | </section> | |||
<section anchor="token-type"> | <section anchor="token-type"> | |||
<name>Token Type Registry Updates</name> | <name>Privacy Pass Token Types</name> | |||
<t>This document updates the "Privacy Pass Token Type" Registry with the | ||||
following entries.</t> | <!-- Lynne: If the authors of draft-ietf-privacypass-auth-scheme agree to | |||
change the registry name to "Privacy Pass Token Types", pluralize it here | ||||
as well. Also update "Public Verifiability" to "Publicly Verifiable" if | ||||
authors of draft-ietf-privacypass-auth-scheme choose that. --> | ||||
<t>IANA has updated the "Privacy Pass Token Type" registry with the | ||||
entries below.</t> | ||||
<section anchor="private-token-type"> | <section anchor="private-token-type"> | |||
<name>Token Type VOPRF (P-384, SHA-384)</name> | <name>Token Type VOPRF(P-384, SHA-384)</name> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Value: 0x0001</li> | <dt>Value:</dt><dd>0x0001</dd> | |||
<li>Name: VOPRF (P-384, SHA-384)</li> | <dt>Name:</dt><dd>VOPRF(P-384, SHA-384)</dd> | |||
<li>Token Structure: As defined in <xref section="2.2" sectionFormat | <dt>Token Structure:</dt><dd>As defined in <xref target="RFC9577" se | |||
="of" target="AUTHSCHEME"/></li> | ctionFormat="of" section="2.2"/>.</dd> | |||
<li>Token Key Encoding: Serialized using SerializeElement from <xref | <dt>Token Key Encoding:</dt><dd>Serialized using SerializeElement (< | |||
section="2.1" sectionFormat="of" target="OPRF"/></li> | xref target="RFC9497" sectionFormat="of" section="2.1"/>).</dd> | |||
<li>TokenChallenge Structure: As defined in <xref section="2.1" sect | <dt>TokenChallenge Structure:</dt><dd>As defined in <xref target="RF | |||
ionFormat="of" target="AUTHSCHEME"/></li> | C9577" sectionFormat="of" section="2.1"/>.</dd> | |||
<li>Public Verifiability: N</li> | <dt>Public Verifiability:</dt><dd>N</dd> | |||
<li>Public Metadata: N</li> | <dt>Public Metadata:</dt><dd>N</dd> | |||
<li>Private Metadata: N</li> | <dt>Private Metadata:</dt><dd>N</dd> | |||
<li>Nk: 48</li> | <dt>Nk:</dt><dd>48</dd> | |||
<li>Nid: 32</li> | <dt>Nid:</dt><dd>32</dd> | |||
<li>Reference: <xref target="private-flow"/></li> | <dt>Reference:</dt><dd>RFC 9578, <xref target="private-flow"/></dd> | |||
<li>Notes: None</li> | <dt>Notes:</dt><dd>None</dd> | |||
</ul> | </dl> | |||
</section> | </section> | |||
<section anchor="public-token-type"> | <section anchor="public-token-type"> | |||
<name>Token Type Blind RSA (2048-bit)</name> | <name>Token Type Blind RSA (2048-bit)</name> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Value: 0x0002</li> | <dt>Value:</dt><dd>0x0002</dd> | |||
<li>Name: Blind RSA (2048-bit)</li> | <dt>Name:</dt><dd>Blind RSA (2048-bit)</dd> | |||
<li>Token Structure: As defined in <xref section="2.2" sectionFormat | <dt>Token Structure:</dt><dd>As defined in <xref target="RFC9577" se | |||
="of" target="AUTHSCHEME"/></li> | ctionFormat="of" section="2.2"/>.</dd> | |||
<li>Token Key Encoding: Serialized as a DER-encoded SubjectPublicKey | <dt>Token Key Encoding:</dt><dd>Serialized as a DER-encoded SubjectP | |||
Info (SPKI) object using the RSASSA-PSS OID <xref target="RFC5756"/></li> | ublicKeyInfo (SPKI) object using the RSASSA-PSS OID <xref target="RFC5756"/>.</d | |||
<li>TokenChallenge Structure: As defined in <xref section="2.1" sect | d> | |||
ionFormat="of" target="AUTHSCHEME"/></li> | <dt>TokenChallenge Structure:</dt><dd>As defined in <xref target="RF | |||
<li>Public Verifiability: Y</li> | C9577" sectionFormat="of" section="2.1"/>.</dd> | |||
<li>Public Metadata: N</li> | <dt>Public Verifiability:</dt><dd>Y</dd> | |||
<li>Private Metadata: N</li> | <dt>Public Metadata:</dt><dd>N</dd> | |||
<li>Nk: 256</li> | <dt>Private Metadata:</dt><dd>N</dd> | |||
<li>Nid: 32</li> | <dt>Nk:</dt><dd>256</dd> | |||
<li>Reference: <xref target="public-flow"/></li> | <dt>Nid:</dt><dd>32</dd> | |||
<li>Notes: The RSABSSA-SHA384-PSS-Deterministic and | <dt>Reference:</dt><dd>RFC 9578, <xref target="public-flow"/></dd> | |||
RSABSSA-SHA384-PSSZERO-Deterministic variants are supported</li> | <dt>Notes:</dt><dd>The RSABSSA-SHA384-PSS-Deterministic and | |||
</ul> | RSABSSA-SHA384-PSSZERO-Deterministic variants are supported.</dd> | |||
</dl> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="media-types"> | <section anchor="media-types"> | |||
<name>Media Types</name> | <name>Media Types</name> | |||
<t>The following entries should be added to the IANA "media types" | <!-- [rfced] Sections 8.3.1-8.3.3: FYI - We reordered the following to match | |||
the order in Section 5.6 of RFC 6838. | ||||
Original: | ||||
Magic number(s): N/A | ||||
Deprecated alias names for this type: N/A | ||||
Updated: | ||||
Deprecated alias names for this type: N/A | ||||
Magic number(s): N/A | ||||
--> | ||||
<t>IANA has added the following entries to the "Media Types" | ||||
registry:</t> | registry:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>"application/private-token-issuer-directory"</li> | <li>"application/private-token-issuer-directory"</li> | |||
<li>"application/private-token-request"</li> | <li>"application/private-token-request"</li> | |||
<li>"application/private-token-response"</li> | <li>"application/private-token-response"</li> | |||
</ul> | </ul> | |||
<t>The templates for these entries are listed below and the | <t>The templates for these entries are listed below. The reference | |||
reference should be this RFC.</t> | is this RFC.</t> | |||
<section anchor="applicationprivate-token-issuer-directory-media-type"> | <section anchor="applicationprivate-token-issuer-directory-media-type"> | |||
<name>"application/private-token-issuer-directory" media type</name> | <name>"application/private-token-issuer-directory" Media Type</name> | |||
<dl spacing="compact"> | <dl spacing="normal"> | |||
<dt>Type name:</dt> | <dt>Type name:</dt> | |||
<dd> | <dd> | |||
<t>application</t> | <t>application</t> | |||
</dd> | </dd> | |||
<dt>Subtype name:</dt> | <dt>Subtype name:</dt> | |||
<dd> | <dd> | |||
<t>private-token-issuer-directory</t> | <t>private-token-issuer-directory</t> | |||
</dd> | </dd> | |||
<dt>Required parameters:</dt> | <dt>Required parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Optional parameters:</dt> | <dt>Optional parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Encoding considerations:</dt> | <dt>Encoding considerations:</dt> | |||
<dd> | <dd> | |||
<t>"binary"</t> | <t>binary</t> | |||
</dd> | </dd> | |||
<dt>Security considerations:</dt> | <dt>Security considerations:</dt> | |||
<dd> | <dd> | |||
<t>see <xref target="setup"/></t> | <t>See <xref target="security"/> of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Interoperability considerations:</dt> | <dt>Interoperability considerations:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Published specification:</dt> | <dt>Published specification:</dt> | |||
<dd> | <dd> | |||
<t>this specification</t> | <t>RFC 9578</t> | |||
</dd> | </dd> | |||
<dt>Applications that use this media type:</dt> | <dt>Applications that use this media type:</dt> | |||
<dd> | <dd> | |||
<t>Services that implement the Privacy Pass issuer role, and clien t | <t>Services that implement the Privacy Pass issuer role, and clien t | |||
applications that interact with the issuer for the purposes of | applications that interact with the issuer for the purposes of | |||
issuing or redeeming tokens.</t> | issuing or redeeming tokens.</t> | |||
</dd> | </dd> | |||
<dt>Fragment identifier considerations:</dt> | <dt>Fragment identifier considerations:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Additional information:</dt> | <dt>Additional information:</dt> | |||
<dd> | <dd><t><br/></t> | |||
<dl spacing="compact"> | <dl spacing="compact"> | |||
<dt>Magic number(s):</dt> | ||||
<dd>N/A</dd> | ||||
<dt>Deprecated alias names for this type:</dt> | <dt>Deprecated alias names for this type:</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
<dt>Magic number(s):</dt> | ||||
<dd><t>N/A</t></dd> | ||||
<dt>File extension(s):</dt> | <dt>File extension(s):</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
<dt>Macintosh file type code(s):</dt> | <dt>Macintosh file type code(s):</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
</dl> | </dl> | |||
</dd> | </dd> | |||
<dt>Person and email address to contact for further information:</dt > | <dt>Person & email address to contact for further information:</ dt> | |||
<dd> | <dd> | |||
<t>see Authors' Addresses section</t> | <t>See the Authors' Addresses section of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Intended usage:</dt> | <dt>Intended usage:</dt> | |||
<dd> | <dd> | |||
<t>COMMON</t> | <t>COMMON</t> | |||
</dd> | </dd> | |||
<dt>Restrictions on usage:</dt> | <dt>Restrictions on usage:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Author:</dt> | <dt>Author:</dt> | |||
<dd> | <dd> | |||
<t>see Authors' Addresses section</t> | <t>See the Authors' Addresses section of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Change controller:</dt> | <dt>Change controller:</dt> | |||
<dd> | <dd> | |||
<t>IETF</t> | <t>IETF</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<!-- [rfced] Section 8.3.1: Per Sections 8.3.2 and 8.3.3, we changed | ||||
"Section 4" to "Section 7" here. If this is incorrect in this case, | ||||
please clarify how Section 4 is relevant.. | ||||
Original: | ||||
Security considerations: see Section 4 | ||||
Currently: | ||||
Security considerations: See Section 7 of RFC 9578 --> | ||||
</section> | </section> | |||
<section anchor="applicationprivate-token-request-media-type"> | <section anchor="applicationprivate-token-request-media-type"> | |||
<name>"application/private-token-request" media type</name> | <name>"application/private-token-request" Media Type</name> | |||
<dl spacing="compact"> | <dl spacing="normal"> | |||
<dt>Type name:</dt> | <dt>Type name:</dt> | |||
<dd> | <dd> | |||
<t>application</t> | <t>application</t> | |||
</dd> | </dd> | |||
<dt>Subtype name:</dt> | <dt>Subtype name:</dt> | |||
<dd> | <dd> | |||
<t>private-token-request</t> | <t>private-token-request</t> | |||
</dd> | </dd> | |||
<dt>Required parameters:</dt> | <dt>Required parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Optional parameters:</dt> | <dt>Optional parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Encoding considerations:</dt> | <dt>Encoding considerations:</dt> | |||
<dd> | <dd> | |||
<t>"binary"</t> | <t>binary</t> | |||
</dd> | </dd> | |||
<dt>Security considerations:</dt> | <dt>Security considerations:</dt> | |||
<dd> | <dd> | |||
<t>see <xref target="security"/></t> | <t>See <xref target="security"/> of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Interoperability considerations:</dt> | <dt>Interoperability considerations:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Published specification:</dt> | <dt>Published specification:</dt> | |||
<dd> | <dd> | |||
<t>this specification</t> | <t>RFC 9578</t> | |||
</dd> | </dd> | |||
<dt>Applications that use this media type:</dt> | <dt>Applications that use this media type:</dt> | |||
<dd> | <dd> | |||
<t>Applications that want to issue or facilitate issuance of Priva cy Pass tokens, | <t>Applications that want to issue or facilitate issuance of Priva cy Pass tokens, | |||
including Privacy Pass issuer applications themselves.</t> | including Privacy Pass issuer applications themselves.</t> | |||
</dd> | </dd> | |||
<dt>Fragment identifier considerations:</dt> | <dt>Fragment identifier considerations:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Additional information:</dt> | <dt>Additional information:</dt> | |||
<dd> | <dd><t><br/></t> | |||
<dl spacing="compact"> | <dl spacing="compact"> | |||
<dt>Magic number(s):</dt> | ||||
<dd>N/A</dd> | ||||
<dt>Deprecated alias names for this type:</dt> | <dt>Deprecated alias names for this type:</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
<dt>Magic number(s):</dt> | ||||
<dd><t>N/A</t></dd> | ||||
<dt>File extension(s):</dt> | <dt>File extension(s):</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
<dt>Macintosh file type code(s):</dt> | <dt>Macintosh file type code(s):</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
</dl> | </dl> | |||
</dd> | </dd> | |||
<dt>Person and email address to contact for further information:</dt > | <dt>Person & email address to contact for further information:</ dt> | |||
<dd> | <dd> | |||
<t>see Authors' Addresses section</t> | <t>See the Authors' Addresses section of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Intended usage:</dt> | <dt>Intended usage:</dt> | |||
<dd> | <dd> | |||
<t>COMMON</t> | <t>COMMON</t> | |||
</dd> | </dd> | |||
<dt>Restrictions on usage:</dt> | <dt>Restrictions on usage:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Author:</dt> | <dt>Author:</dt> | |||
<dd> | <dd> | |||
<t>see Authors' Addresses section</t> | <t>See the Authors' Addresses section of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Change controller:</dt> | <dt>Change controller:</dt> | |||
<dd> | <dd> | |||
<t>IETF</t> | <t>IETF</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
</section> | </section> | |||
<section anchor="applicationprivate-token-response-media-type"> | <section anchor="applicationprivate-token-response-media-type"> | |||
<name>"application/private-token-response" media type</name> | <name>"application/private-token-response" Media Type</name> | |||
<dl spacing="compact"> | <dl spacing="normal"> | |||
<dt>Type name:</dt> | <dt>Type name:</dt> | |||
<dd> | <dd> | |||
<t>application</t> | <t>application</t> | |||
</dd> | </dd> | |||
<dt>Subtype name:</dt> | <dt>Subtype name:</dt> | |||
<dd> | <dd> | |||
<t>private-token-response</t> | <t>private-token-response</t> | |||
</dd> | </dd> | |||
<dt>Required parameters:</dt> | <dt>Required parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Optional parameters:</dt> | <dt>Optional parameters:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Encoding considerations:</dt> | <dt>Encoding considerations:</dt> | |||
<dd> | <dd> | |||
<t>"binary"</t> | <t>binary</t> | |||
</dd> | </dd> | |||
<dt>Security considerations:</dt> | <dt>Security considerations:</dt> | |||
<dd> | <dd> | |||
<t>see <xref target="security"/></t> | <t>See <xref target="security"/> of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Interoperability considerations:</dt> | <dt>Interoperability considerations:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Published specification:</dt> | <dt>Published specification:</dt> | |||
<dd> | <dd> | |||
<t>this specification</t> | <t>RFC 9578</t> | |||
</dd> | </dd> | |||
<dt>Applications that use this media type:</dt> | <dt>Applications that use this media type:</dt> | |||
<dd> | <dd> | |||
<t>Applications that want to issue or facilitate issuance of Priva cy Pass tokens, | <t>Applications that want to issue or facilitate issuance of Priva cy Pass tokens, | |||
including Privacy Pass issuer applications themselves.</t> | including Privacy Pass issuer applications themselves.</t> | |||
</dd> | </dd> | |||
<dt>Fragment identifier considerations:</dt> | <dt>Fragment identifier considerations:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Additional information:</dt> | <dt>Additional information:</dt> | |||
<dd> | <dd><t><br/></t> | |||
<dl spacing="compact"> | <dl spacing="compact"> | |||
<dt>Magic number(s):</dt> | ||||
<dd>N/A</dd> | ||||
<dt>Deprecated alias names for this type:</dt> | <dt>Deprecated alias names for this type:</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
<dt>Magic number(s):</dt> | ||||
<dd><t>N/A</t></dd> | ||||
<dt>File extension(s):</dt> | <dt>File extension(s):</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
<dt>Macintosh file type code(s):</dt> | <dt>Macintosh file type code(s):</dt> | |||
<dd>N/A</dd> | <dd><t>N/A</t></dd> | |||
</dl> | </dl> | |||
</dd> | </dd> | |||
<dt>Person and email address to contact for further information:</dt > | <dt>Person & email address to contact for further information:</ dt> | |||
<dd> | <dd> | |||
<t>see Authors' Addresses section</t> | <t>See the Authors' Addresses section of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Intended usage:</dt> | <dt>Intended usage:</dt> | |||
<dd> | <dd> | |||
<t>COMMON</t> | <t>COMMON</t> | |||
</dd> | </dd> | |||
<dt>Restrictions on usage:</dt> | <dt>Restrictions on usage:</dt> | |||
<dd> | <dd> | |||
<t>N/A</t> | <t>N/A</t> | |||
</dd> | </dd> | |||
<dt>Author:</dt> | <dt>Author:</dt> | |||
<dd> | <dd> | |||
<t>see Authors' Addresses section</t> | <t>See the Authors' Addresses section of RFC 9578.</t> | |||
</dd> | </dd> | |||
<dt>Change controller:</dt> | <dt>Change controller:</dt> | |||
<dd> | <dd> | |||
<t>IETF</t> | <t>IETF</t> | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<displayreference target="RFC9576" to="ARCHITECTURE"/> | ||||
<displayreference target="RFC9110" to="HTTP"/> | ||||
<displayreference target="RFC9497" to="OPRF"/> | ||||
<displayreference target="RFC9474" to="BLINDRSA"/> | ||||
<displayreference target="RFC8446" to="TLS13"/> | ||||
<displayreference target="RFC8877" to="TIMESTAMP"/> | ||||
<displayreference target="RFC9577" to="AUTHSCHEME"/> | ||||
<displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTENCY" | ||||
/> | ||||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<reference anchor="RFC2119"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" | |||
<title>Key words for use in RFCs to Indicate Requirement Levels</tit | /> | |||
le> | ||||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | <reference anchor="WellKnownURIs" target="https://www.iana.org/assignmen | |||
<date month="March" year="1997"/> | ts/well-known-uris/"> | |||
<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="WellKnownURIs" target="https://www.iana.org/assignmen | ||||
ts/well-known-uris/well-known-uris.xhtml"> | ||||
<front> | <front> | |||
<title>Well-Known URIs</title> | <title>Well-Known URIs</title> | |||
<author> | <author> | |||
<organization/> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date>n.d.</date> | <date></date> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<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="HTTP"> | </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 | ||||
rminology, and defines aspects of the protocol that are shared by all versions. | ||||
In this definition are core protocol elements, extensibility mechanisms, and the | ||||
"http" and "https" Uniform Resource Identifier (URI) schemes.</t> | ||||
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7 | ||||
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="97"/> | ||||
<seriesInfo name="RFC" value="9110"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9110"/> | ||||
</reference> | ||||
<reference anchor="OPRF"> | ||||
<front> | ||||
<title>Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Gr | ||||
oups</title> | ||||
<author fullname="Alex Davidson" initials="A." surname="Davidson"> | ||||
<organization>Brave Software</organization> | ||||
</author> | ||||
<author fullname="Armando Faz-Hernandez" initials="A." surname="Faz- | ||||
Hernandez"> | ||||
<organization>Cloudflare, Inc.</organization> | ||||
</author> | ||||
<author fullname="Nick Sullivan" initials="N." surname="Sullivan"> | ||||
<organization>Cloudflare, Inc.</organization> | ||||
</author> | ||||
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo | ||||
d"> | ||||
<organization>Cloudflare, Inc.</organization> | ||||
</author> | ||||
<date day="21" month="February" year="2023"/> | ||||
<abstract> | ||||
<t> An Oblivious Pseudorandom Function (OPRF) is a two-party pro | ||||
tocol | ||||
between client and server for computing the output of a Pseudorandom | ||||
Function (PRF). The server provides the PRF private key, and the | ||||
client provides the PRF input. At the end of the protocol, the | ||||
client learns the PRF output without learning anything about the PRF | ||||
private key, and the server learns neither the PRF input nor output. | ||||
An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. | ||||
A VOPRF ensures clients can verify that the server used a specific | ||||
private key during the execution of the protocol. A VOPRF can also | ||||
be partially-oblivious, called a POPRF. A POPRF allows clients and | ||||
servers to provide public input to the PRF computation. This | ||||
document specifies an OPRF, VOPRF, and POPRF instantiated within | ||||
standard prime-order groups, including elliptic curves. This | ||||
document is a product of the Crypto Forum Research Group (CFRG) in | ||||
the IRTF. | ||||
</t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml" | |||
</abstract> | /> | |||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-voprf-21"/> | ||||
</reference> | ||||
<reference anchor="BLINDRSA"> | ||||
<front> | ||||
<title>RSA Blind Signatures</title> | ||||
<author fullname="Frank Denis" initials="F." surname="Denis"> | ||||
<organization>Fastly Inc.</organization> | ||||
</author> | ||||
<author fullname="Frederic Jacobs" initials="F." surname="Jacobs"> | ||||
<organization>Apple Inc.</organization> | ||||
</author> | ||||
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo | ||||
d"> | ||||
<organization>Cloudflare</organization> | ||||
</author> | ||||
<date day="10" month="July" year="2023"/> | ||||
<abstract> | ||||
<t> This document specifies an RSA-based blind signature protoco | ||||
l. RSA | ||||
blind signatures were first introduced by Chaum for untraceable | ||||
payments. A signature that is output from this protocol can be | ||||
verified as an RSA-PSS signature. | ||||
This document is a product of the Crypto Forum Research Group (CFRG) | <!-- draft-irtf-cfrg-voprf (RFC 9497; published) --> | |||
in the IRTF. | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9497.xml" | |||
/> | ||||
Discussion Venues | <!-- draft-irtf-cfrg-rsa-blind-signatures (RFC 9474; published) --> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9474.xml" | ||||
/> | ||||
This note is to be removed before publishing as an RFC. | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" | |||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml" | ||||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml" | ||||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml" | ||||
/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8877.xml" | ||||
/> | ||||
Source for this draft and an issue tracker can be found at | <!-- draft-ietf-privacypass-auth-scheme (RFC 9577) --> | |||
https://github.com/chris-wood/draft-wood-cfrg-blind-signatures. | <reference anchor="RFC9577" target="https://www.rfc-editor.org/info/rfc9577"> | |||
<front> | ||||
<title>The Privacy Pass HTTP Authentication Scheme</title> | ||||
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> | ||||
<organization>Apple Inc.</organization> | ||||
</author> | ||||
<author initials="S." surname="Valdez" fullname="Steven Valdez"> | ||||
<organization>Google LLC</organization> | ||||
</author> | ||||
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> | ||||
<organization>Cloudflare</organization> | ||||
</author> | ||||
<date month="May" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9577"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9577"/> | ||||
</reference> | ||||
</t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5861.xml" | |||
</abstract> | /> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml" | |||
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-rsa-blind-sig | /> | |||
natures-14"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml" | |||
</reference> | /> | |||
<reference anchor="RFC8174"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5756.xml" | |||
<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="RFC8259"> | ||||
<front> | ||||
<title>The JavaScript Object Notation (JSON) Data Interchange Format | ||||
</title> | ||||
<author fullname="T. Bray" initials="T." role="editor" surname="Bray | ||||
"/> | ||||
<date month="December" year="2017"/> | ||||
<abstract> | ||||
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, | ||||
language-independent data interchange format. It was derived from the ECMAScrip | ||||
t Programming Language Standard. JSON defines a small set of formatting rules fo | ||||
r the portable representation of structured data.</t> | ||||
<t>This document removes inconsistencies with other specifications | ||||
of JSON, repairs specification errors, and offers experience-based interoperabi | ||||
lity guidance.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="90"/> | ||||
<seriesInfo name="RFC" value="8259"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8259"/> | ||||
</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="TIMESTAMP"> | ||||
<front> | ||||
<title>Guidelines for Defining Packet Timestamps</title> | ||||
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/> | ||||
<author fullname="J. Fabini" initials="J." surname="Fabini"/> | ||||
<author fullname="A. Morton" initials="A." surname="Morton"/> | ||||
<date month="September" year="2020"/> | ||||
<abstract> | ||||
<t>Various network protocols make use of binary-encoded timestamps | ||||
that are incorporated in the protocol packet format, referred to as "packet tim | ||||
estamps" for short. This document specifies guidelines for defining packet times | ||||
tamp formats in networking protocols at various layers. It also presents three r | ||||
ecommended timestamp formats. The target audience of this document includes netw | ||||
ork protocol designers. It is expected that a new network protocol that requires | ||||
a packet timestamp will, in most cases, use one of the recommended timestamp fo | ||||
rmats. If none of the recommended formats fits the protocol requirements, the ne | ||||
w protocol specification should specify the format of the packet timestamp accor | ||||
ding to the guidelines in this document.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8877"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8877"/> | ||||
</reference> | ||||
<reference anchor="AUTHSCHEME"> | ||||
<front> | ||||
<title>The Privacy Pass HTTP Authentication Scheme</title> | ||||
<author fullname="Tommy Pauly" initials="T." surname="Pauly"> | ||||
<organization>Apple Inc.</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="25" month="September" year="2023"/> | ||||
<abstract> | ||||
<t> This document defines an HTTP authentication scheme for Priv | ||||
acy Pass, | ||||
a privacy-preserving authentication mechanism used for authorization. | ||||
The authentication scheme in this document can be used by clients to | ||||
redeem Privacy Pass tokens with an origin. It can also be used by | ||||
origins to challenge clients to present Privacy Pass tokens. | ||||
</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-auth-s | ||||
cheme-14"/> | ||||
</reference> | ||||
<reference anchor="RFC5861"> | ||||
<front> | ||||
<title>HTTP Cache-Control Extensions for Stale Content</title> | ||||
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ | ||||
> | ||||
<date month="May" year="2010"/> | ||||
<abstract> | ||||
<t>This document defines two independent HTTP Cache-Control extens | ||||
ions that allow control over the use of stale responses by caches. This document | ||||
is not an Internet Standards Track specification; it is published for informati | ||||
onal purposes.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5861"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5861"/> | ||||
</reference> | ||||
<reference anchor="RFC9111"> | ||||
<front> | ||||
<title>HTTP Caching</title> | ||||
<author fullname="R. Fielding" initials="R." role="editor" surname=" | ||||
Fielding"/> | ||||
<author fullname="M. Nottingham" initials="M." role="editor" surname | ||||
="Nottingham"/> | ||||
<author fullname="J. Reschke" initials="J." role="editor" surname="R | ||||
eschke"/> | ||||
<date month="June" year="2022"/> | ||||
<abstract> | ||||
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati | ||||
on-level protocol for distributed, collaborative, hypertext information systems. | ||||
This document defines HTTP caches and the associated header fields that control | ||||
cache behavior or indicate cacheable response messages.</t> | ||||
<t>This document obsoletes RFC 7234.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="98"/> | ||||
<seriesInfo name="RFC" value="9111"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9111"/> | ||||
</reference> | ||||
<reference anchor="RFC8017"> | ||||
<front> | ||||
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title> | ||||
<author fullname="K. Moriarty" initials="K." role="editor" surname=" | ||||
Moriarty"/> | ||||
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> | ||||
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/> | ||||
<author fullname="A. Rusch" initials="A." surname="Rusch"/> | ||||
<date month="November" year="2016"/> | ||||
<abstract> | ||||
<t>This document provides recommendations for the implementation o | ||||
f public-key cryptography based on the RSA algorithm, covering cryptographic pri | ||||
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f | ||||
or representing keys and for identifying the schemes.</t> | ||||
<t>This document represents a republication of PKCS #1 v2.2 from R | ||||
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing | ||||
this RFC, change control is transferred to the IETF.</t> | ||||
<t>This document also obsoletes RFC 3447.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8017"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8017"/> | ||||
</reference> | ||||
<reference anchor="RFC5756"> | ||||
<front> | ||||
<title>Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters</t | ||||
itle> | ||||
<author fullname="S. Turner" initials="S." surname="Turner"/> | ||||
<author fullname="D. Brown" initials="D." surname="Brown"/> | ||||
<author fullname="K. Yiu" initials="K." surname="Yiu"/> | ||||
<author fullname="R. Housley" initials="R." surname="Housley"/> | ||||
<author fullname="T. Polk" initials="T." surname="Polk"/> | ||||
<date month="January" year="2010"/> | ||||
<abstract> | ||||
<t>This document updates RFC 4055. It updates the conventions for | ||||
using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-O | ||||
AEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PK | ||||
I). Specifically, it updates the conventions for algorithm parameters in an X.50 | ||||
9 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5756"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5756"/> | ||||
</reference> | ||||
</references> | </references> | |||
<references> | <references> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<reference anchor="DSS" target="https://doi.org/10.6028/nist.fips.186-5" > | <reference anchor="DSS" target="https://doi.org/10.6028/nist.fips.186-5" > | |||
<front> | <front> | |||
<title>Digital Signature Standard (DSS)</title> | <title>Digital Signature Standard (DSS)</title> | |||
<author fullname="Dustin Moody" surname="Moody"> | ||||
<organization>National Institute of Standards and Technology</orga | ||||
nization> | ||||
</author> | ||||
<author> | <author> | |||
<organization>National Institute of Standards and Technology</orga nization> | <organization>National Institute of Standards and Technology</orga nization> | |||
</author> | </author> | |||
<date year="2023"/> | <date month="February" year="2023"/> | |||
<abstract> | ||||
<t><jats:p /></t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="DOI" value="10.6028/nist.fips.186-5"/> | ||||
</reference> | ||||
<reference anchor="RFC5280"> | ||||
<front> | ||||
<title>Internet X.509 Public Key Infrastructure Certificate and Cert | ||||
ificate Revocation List (CRL) Profile</title> | ||||
<author fullname="D. Cooper" initials="D." surname="Cooper"/> | ||||
<author fullname="S. Santesson" initials="S." surname="Santesson"/> | ||||
<author fullname="S. Farrell" initials="S." surname="Farrell"/> | ||||
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/> | ||||
<author fullname="R. Housley" initials="R." surname="Housley"/> | ||||
<author fullname="W. Polk" initials="W." surname="Polk"/> | ||||
<date month="May" year="2008"/> | ||||
<abstract> | ||||
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif | ||||
icate revocation list (CRL) for use in the Internet. An overview of this approac | ||||
h and model is provided as an introduction. The X.509 v3 certificate format is d | ||||
escribed in detail, with additional information regarding the format and semanti | ||||
cs of Internet name forms. Standard certificate extensions are described and two | ||||
Internet-specific extensions are defined. A set of required certificate extensi | ||||
ons is specified. The X.509 v2 CRL format is described in detail along with stan | ||||
dard and Internet-specific extensions. An algorithm for X.509 certification path | ||||
validation is described. An ASN.1 module and examples are provided in the appen | ||||
dices. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | </front> | |||
<seriesInfo name="RFC" value="5280"/> | <seriesInfo name="NIST FIPS Publication" value="186-5"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC5280"/> | <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/> | |||
</reference> | </reference> | |||
<reference anchor="CONSISTENCY"> | ||||
<front> | ||||
<title>Key Consistency and Discovery</title> | ||||
<author fullname="Alex Davidson" initials="A." surname="Davidson"> | ||||
<organization>Brave Software</organization> | ||||
</author> | ||||
<author fullname="Matthew Finkel" initials="M." surname="Finkel"> | ||||
<organization>The Tor Project</organization> | ||||
</author> | ||||
<author fullname="Martin Thomson" initials="M." surname="Thomson"> | ||||
<organization>Mozilla</organization> | ||||
</author> | ||||
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo | ||||
d"> | ||||
<organization>Cloudflare</organization> | ||||
</author> | ||||
<date day="10" month="July" year="2023"/> | ||||
<abstract> | ||||
<t> This document describes the consistency requirements of prot | ||||
ocols | ||||
such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user | ||||
privacy. It presents definitions for consistency and then surveys | ||||
mechanisms for providing consistency in varying threat models. In | ||||
concludes with discussion of open problems in this area. | ||||
</t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml" | |||
</abstract> | /> | |||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-co | <!-- draft-ietf-privacypass-key-consistency (Expired) --> | |||
nsistency-01"/> | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pr | |||
</reference> | ivacypass-key-consistency.xml"/> | |||
</references> | </references> | |||
</references> | </references> | |||
<section anchor="acknowledgements"> | ||||
<name>Acknowledgements</name> | ||||
<t>The authors of this document would like to acknowledge the helpful | ||||
feedback and discussions from Benjamin Schwartz, Joseph Salowey, | ||||
and Tara Whalen.</t> | ||||
</section> | ||||
<section anchor="test-vectors"> | <section anchor="test-vectors"> | |||
<name>Test Vectors</name> | <name>Test Vectors</name> | |||
<t>This section includes test vectors for the two basic issuance protocols | <t>This section includes test vectors for the two basic issuance protocols | |||
specified in this document. <xref target="test-vectors-poprf"/> contains test ve ctors | specified in this document. <xref target="test-vectors-poprf"/> contains test ve ctors | |||
for token issuance protocol 1 (0x0001), and <xref target="test-vectors-rsa"/> co ntains | for token issuance protocol 1 (0x0001), and <xref target="test-vectors-rsa"/> co ntains | |||
test vectors for token issuance protocol 2 (0x0002).</t> | test vectors for token issuance protocol 2 (0x0002).</t> | |||
<section anchor="test-vectors-poprf"> | <section anchor="test-vectors-poprf"> | |||
<name>Issuance Protocol 1 - VOPRF(P-384, SHA-384)</name> | <name>Issuance Protocol 1 - VOPRF(P-384, SHA-384)</name> | |||
<t>The test vector below lists the following values:</t> | <t>The test vectors below list the following values:</t> | |||
<ul spacing="normal"> | ||||
<li>skS: The Issuer Private Key, serialized using SerializeScalar from | <!-- [rfced] Original Appendices B.1 and B.2: | |||
<xref section="2.1" sectionFormat="of" target="OPRF"/> and represented as a hexa | ||||
decimal string.</li> | a) As these sections each list five test vectors that use the | |||
<li>pkS: The Issuer Public Key, serialized according to the encoding i | parameters in question, we changed "The test vector below lists" to | |||
n <xref target="private-token-type"/>.</li> | "The test vectors below list" per this text in Appendix B: | |||
<li>token_challenge: A randomly generated TokenChallenge structure, re | "Appendix B.1 contains test vectors for token issuance protocol 1 | |||
presented | (0x0001), and Appendix B.2 contains test vectors for token issuance | |||
as a hexadecimal string.</li> | protocol 2 (0x0002)". If this is incorrect, please clarify the use | |||
<li>nonce: The 32-byte client nonce generated according to <xref targe | of the singular "vector". | |||
t="private-request"/>, | ||||
represented as a hexadecimal string.</li> | Original: | |||
<li>blind: The blind used when computing the OPRF blinded message, ser | The test vector below lists the following values: | |||
ialized | ... | |||
using SerializeScalar from <xref section="2.1" sectionFormat="of" target="OPRF"/ | The test vector below lists the following values: | |||
> and represented as a | ||||
hexadecimal string.</li> | Currently: | |||
<li>token_request: The TokenRequest message constructed according to | The test vectors below list the following values: | |||
<xref target="private-request"/>, represented as a hexadecimal string.</li> | ... | |||
<li>token_response: The TokenResponse message constructed according to | The test vectors below list the following values: | |||
<xref target="private-response"/>, represented as a hexadecimal string.</li> | ||||
<li>token: The output Token from the protocol, represented as a hexade | b) In Sections 5 and 6, we see "skI" and "pkI" used to indicate the | |||
cimal | Issuer Private Key and Public Key, respectively. However, the | |||
string.</li> | appendices appear to use "skS" and "pkS" in place of "skI" and "pkI". | |||
</ul> | Please confirm that the use of the different strings to represent | |||
what appear to be the same things is as intended. | ||||
Also, we see that RFC 9497 uses "skS" and "pkS" but not "skI" or | ||||
"pkI". RFC 9497 has the following text: "skS is the server's | ||||
private key" and "the server's public key, pkS". | ||||
Original ("a Issuer" has been fixed): | ||||
Issuers provide a Issuer Private and Public Key, denoted skI and pkI | ||||
respectively, used to produce tokens as input to the protocol. | ||||
... | ||||
In particular, Issuers provide an Issuer Private | ||||
and Public Key, denoted skI and pkI, respectively, used to produce | ||||
tokens as input to the protocol. | ||||
... | ||||
Issuers are configured with Issuer Private and Public Keys, each | ||||
denoted skI and pkI, respectively, used to produce tokens. | ||||
... | ||||
* skS: The Issuer Private Key, serialized using SerializeScalar from | ||||
Section 2.1 of [OPRF] and represented as a hexadecimal string. | ||||
* pkS: The Issuer Public Key, serialized according to the encoding | ||||
in Section 8.2.1. | ||||
... | ||||
* skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for | ||||
signing tokens, represented as a hexadecimal string. | ||||
* pkS: The Issuer Public Key, serialized according to the encoding | ||||
in Section 8.2.2. --> | ||||
<dl spacing="normal"> | ||||
<dt>skS:</dt><dd>The Issuer Private Key, serialized using SerializeSca | ||||
lar | ||||
(<xref section="2.1" sectionFormat="comma" target="RFC9497"/>) and represented a | ||||
s a hexadecimal string.</dd> | ||||
<dt>pkS:</dt><dd>The Issuer Public Key, serialized according to the en | ||||
coding in <xref target="private-token-type"/>.</dd> | ||||
<dt>token_challenge:</dt><dd>A randomly generated TokenChallenge struc | ||||
ture, represented | ||||
as a hexadecimal string.</dd> | ||||
<dt>nonce:</dt><dd>The 32-byte client nonce generated according to <xr | ||||
ef target="private-request"/>, | ||||
represented as a hexadecimal string.</dd> | ||||
<dt>blind:</dt><dd>The blind used when computing the OPRF blinded mess | ||||
age, serialized | ||||
using SerializeScalar (<xref section="2.1" sectionFormat="comma" target="RFC9497 | ||||
"/>) and represented as a | ||||
hexadecimal string.</dd> | ||||
<dt>token_request:</dt><dd>The TokenRequest message constructed accord | ||||
ing to | ||||
<xref target="private-request"/>, represented as a hexadecimal string.</dd> | ||||
<dt>token_response:</dt><dd>The TokenResponse message constructed acco | ||||
rding to | ||||
<xref target="private-response"/>, represented as a hexadecimal string.</dd> | ||||
<dt>token:</dt><dd>The output Token from the protocol, represented as | ||||
a hexadecimal | ||||
string.</dd> | ||||
</dl> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
// Test vector 1 | // Test vector 1 | |||
skS: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181 | skS: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181 | |||
14910bee3c919bed1bbffe3fc1b87d53240a | 14910bee3c919bed1bbffe3fc1b87d53240a | |||
pkS: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c | pkS: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c | |||
21da1a46d42ca38f7beabdf05c074aee1455bf | 21da1a46d42ca38f7beabdf05c074aee1455bf | |||
token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc | token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc | |||
daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696 | daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696 | |||
7696e2e6578616d706c65 | 7696e2e6578616d706c65 | |||
nonce: | nonce: | |||
skipping to change at line 1623 ¶ | skipping to change at line 1787 ¶ | |||
669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080 | 669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080 | |||
token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8 | token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8 | |||
4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8 | 4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8 | |||
7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca | 7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca | |||
1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c | 1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c | |||
d24504fe4f6c52d24ac901471267d8b63b61e6b | d24504fe4f6c52d24ac901471267d8b63b61e6b | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
<section anchor="test-vectors-rsa"> | <section anchor="test-vectors-rsa"> | |||
<name>Issuance Protocol 2 - Blind RSA, 2048</name> | <name>Issuance Protocol 2 - Blind RSA, 2048</name> | |||
<t>The test vector below lists the following values:</t> | <t>The test vectors below list the following values:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for signin | <dt>skS:</dt><dd>The PEM-encoded PKCS #8 RSA Issuer Private Key used f | |||
g tokens, | or signing tokens, | |||
represented as a hexadecimal string.</li> | represented as a hexadecimal string.</dd> | |||
<li>pkS: The Issuer Public Key, serialized according to the encoding i | <dt>pkS:</dt><dd>The Issuer Public Key, serialized according to the en | |||
n <xref target="public-token-type"/>.</li> | coding in <xref target="public-token-type"/>.</dd> | |||
<li>token_challenge: A randomly generated TokenChallenge structure, re | <dt>token_challenge:</dt><dd>A randomly generated TokenChallenge struc | |||
presented | ture, represented | |||
as a hexadecimal string.</li> | as a hexadecimal string.</dd> | |||
<li>nonce: The 32-byte client nonce generated according to <xref targe | <dt>nonce:</dt><dd>The 32-byte client nonce generated according to <xr | |||
t="public-request"/>, | ef target="public-request"/>, | |||
represented as a hexadecimal string.</li> | represented as a hexadecimal string.</dd> | |||
<li>blind: The blind used when computing the blind RSA blinded message | <dt>blind:</dt><dd>The blind used when computing the blind RSA blinded | |||
, | message, | |||
represented as a hexadecimal string.</li> | represented as a hexadecimal string.</dd> | |||
<li>salt: The randomly generated 48-byte salt used when encoding the b | <dt>salt:</dt><dd>The randomly generated 48-byte salt used when encodi | |||
linded | ng the blinded | |||
token request message, represented as a hexadecimal string.</li> | token request message, represented as a hexadecimal string.</dd> | |||
<li>token_request: The TokenRequest message constructed according to | <dt>token_request:</dt><dd>The TokenRequest message constructed accord | |||
<xref target="public-request"/>, represented as a hexadecimal string.</li> | ing to | |||
<li>token_request: The TokenResponse message constructed according to | <xref target="public-request"/>, represented as a hexadecimal string.</dd> | |||
<xref target="public-response"/>, represented as a hexadecimal string.</li> | <dt>token_response:</dt><dd>The TokenResponse message constructed acco | |||
<li>token: The output Token from the protocol, represented as a hexade | rding to | |||
cimal | <xref target="public-response"/>, represented as a hexadecimal string.</dd> | |||
string.</li> | <dt>token:</dt><dd>The output Token from the protocol, represented as | |||
</ul> | a hexadecimal | |||
string.</dd> | ||||
<!-- [rfced] Original Appendix B.2: | ||||
a) Should "PEM" be defined for readers? If yes, does it stand for | ||||
"Privacy-Enhanced Mail"? | ||||
Also, for ease of the reader, should an RFC or other document that | ||||
explains PKCS #8 be cited here? If yes, please specify. | ||||
Original: | ||||
* skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for | ||||
signing tokens, represented as a hexadecimal string. | ||||
Possibly: | ||||
skS: The PEM-encoded PKCS #8 RSA Issuer Private Key used for | ||||
signing tokens, represented as a hexadecimal string. ("PEM" | ||||
stands for "Privacy-Enhanced Mail". PKCS #8 is discussed in | ||||
[RFC5958].) | ||||
b) Should "blinded token request message" be "blinded TokenRequest | ||||
message" here? We see "Token request: A message used by Clients to | ||||
request a token from an Issuer, often denoted TokenRequest" in | ||||
Section 2 of draft-ietf-privacypass-architecture, but readers might | ||||
not be aware of that text when reading this document. | ||||
Original: | ||||
* salt: The randomly generated 48-byte salt used when encoding the | ||||
blinded token request message, represented as a hexadecimal | ||||
string. | ||||
c) We changed the second "token_request:" item to "token_response:" | ||||
here, as it refers to the TokenResponse message. If this is | ||||
incorrect, please provide clarifying text. | ||||
Original: | ||||
* token_request: The TokenRequest message constructed according to | ||||
Section 6.1, represented as a hexadecimal string. | ||||
* token_request: The TokenResponse message constructed according to | ||||
Section 6.2, represented as a hexadecimal string. | ||||
Currently: | ||||
token_request: The TokenRequest message constructed according to | ||||
Section 6.1, represented as a hexadecimal string. | ||||
token_response: The TokenResponse message constructed according to | ||||
Section 6.2, represented as a hexadecimal string. --> | ||||
</dl> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
// Test vector 1 | // Test vector 1 | |||
skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 | skS: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49 | |||
4945765149424144414e42676b71686b6947397730424151454641415343424b6 | 4945765149424144414e42676b71686b6947397730424151454641415343424b6 | |||
3776767536a41674541416f49424151444c4775317261705831736334420a4f6b | 3776767536a41674541416f49424151444c4775317261705831736334420a4f6b | |||
7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 | 7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764 | |||
57245526b49314c527876734d6453327961326333616b4745714c756b440a556a | 57245526b49314c527876734d6453327961326333616b4745714c756b440a556a | |||
35743561496b3172417643655844644e44503442325055707851436e6969396e6 | 35743561496b3172417643655844644e44503442325055707851436e6969396e6 | |||
b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f | b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f | |||
6558563835464f314a752b62397336356d586d34516a755139455961497138337 | 6558563835464f314a752b62397336356d586d34516a755139455961497138337 | |||
skipping to change at line 2191 ¶ | skipping to change at line 2403 ¶ | |||
9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26 | 9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26 | |||
e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c | e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c | |||
c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81 | c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81 | |||
a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b | a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b | |||
a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273 | a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273 | |||
c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658 | c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658 | |||
5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23 | 5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23 | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="acknowledgements" numbered="false"> | ||||
<name>Acknowledgements</name> | ||||
<t>The authors of this document would like to acknowledge the helpful | ||||
feedback and discussions from <contact fullname="Benjamin Schwartz"/>, <contact | ||||
fullname="Joseph Salowey"/>, and <contact fullname="Tara Whalen"/>.</t> | ||||
</section> | ||||
</back> | </back> | |||
<!-- ##markdown-source: | ||||
H4sIAAAAAAAAA+y963Ycx7Wl+z+foprqMUxuA1DeL7Tl3iRFSbTEi0lK3rbb | ||||
Q4qMiCTKBFBwVYEUZaufpV/gvMQ5L3a+GZlZlVUAKUqyu727QVskUJUZGZe1 | ||||
5prrEpGHh4fRer4+8bdnN54s56+MfTN7Ylar2YPV6sKcWT97slysF3ZxciMy | ||||
bbv0r27Prrwucgt7Zk5pxy1Ntz6c+3V3eN5fec6F/Ny3c5iUkTNrfzuy/P1i | ||||
sXxze7Zauyiany9vz9bLi9U6jeMmTqOX/s3rxdLdnj04W/vlmV8ffqymo2i1 | ||||
Nmfua3OyOONxb/wqOp/fnv2J1g9mq8VyvfTdip/enOqHP0eRuVgfL5a3o9lh | ||||
NOPP/Gx1e/bsaHbPn8zDB323ny26/+//MdtPF8sXt2d3l+aV11fr12bpw+d2 | ||||
vqbHX8xX7eKs/2BxcbbWKJ7w7IsX5iR86k/N/OT2zB77pT97uXj178v5yl+c | ||||
HzGMnY7cOZp9bF7N3Wpore/MnRP/7e7n/5juGNo9ckO7TfrvL/TxkV2c7k/O | ||||
V+bE+e+m07P2r/zZ9PPQo08XixcnfvbFF/emj1m9Cpf9uz1eLk7nF6dHXLvz | ||||
hHtHGvjvFws3ecS9Y+ZovThnyna+DQ+6d7K4cN3JOOwVq+zXt2dJnMyeL16f | ||||
rfyZo4+TKXlmzmafLBHN+coudmfmy7P52utyBHA1W3SzO6d+ObdmZ+HM638/ | ||||
9uZ8fvaina9XYd2is8Xy1KznrxDe2ezpJ/fSJGn04+/9ycnnZ3Tjy6cPVrdD | ||||
M4NS6ZvD8NVM3/VfmeUL9f14vT5f3f7ww9evXx/NzZnRLH2IqsxfnJ36s/Xq | ||||
w9e6+aVuPrxgavZ/P/r2eH16EkWHh4cz0zIjxtLH58fz1QxlvFAbs9W5t/Nu | ||||
zjDXrxezV2bJg9ZhzOtjr88OT/1qZV742XxU+FFRo26x3NX19eKl1+qhd9xu | ||||
1rrUXVg/ftN/yBLNguKv/cmb6BUz281Ni5BcrJjM8NzJs8J1M1T9YIZS899i | ||||
rfW/qvlo2/xFezK3J29mP9B6uEyNH/WzdDp37sRH0QeClND4eo7aMGd+d6Tj | ||||
HOgHlIUumNkAZgCZX/nlKz2tR5b5dyY0c+rtsTmbr06PaH7GtHo6cRC6tGnP | ||||
nJwsXq9m9mSuFWZg4xNmdvnmfL14sTTnx3MbTSdUV/iZJkbP3MzPWf8tv76Z | ||||
HQsXWo+C2qU3Eu72DV1+gaieReott8zP+q6Y1Xr2t7/9lztP73324Pn9e8+/ | ||||
fHr/oweHHx9dQmyztMcoil1fLP333x/tixazYpfzVstzfIX4zC6JT3sxP1kj | ||||
PBFP/+z58ycfoUFNksS0PXvwNlGdSNt8tZWrycpH75arWWtWzMeiH/0CiXg1 | ||||
X1zQFHDsFgCEW5zOuouzIAqzDsBS/x4/efpJPytLZsV2yxeHrxbny+7773s5 | ||||
3enUu6QxukIad7vEpzT49NmdmTTfaLZnK+zGqVdH7n7x4NHHfLnXmeXKHIYb | ||||
Dzc3ra5aowXTieSAfa+C1OzJ+XSJD5AQe3Lh6HhkjxfzoHijxp15K5xYvgnL | ||||
6vz5yeJNeEJQ2vNzRhaUYFxFOxuaCCgimeAhmpJe8kdlOpqF/s7Puh5ZaYBf | ||||
Q2eZICT2b3+bymkY4Qez5355Oj9bnCxevOl1V3MqqrCa3Xj45bPnNw76f2eP | ||||
Hoefn97/3ZcPnt7/WD8/++zOF19sfoiGK5599vjLLz7e/rS9897jhw/vP/q4 | ||||
v5lPZzsfRTce3vnDjV4kbjx+8vzB40d3vrjRq9p0HTSF6HqLiIrLACHSUbOK | ||||
RiUKg71778n/+z+TXNo5GJfvvx9+qZMq55fXx/5sFEAErv9VCBCxBt4EJQdi | ||||
sF7n87U5gQaZ1Wx1LPMjIsLs7QnIxWrQX3p1upo9Xs5fzGnyXlilg8Du/LJ/ | ||||
4nNBktpzvpufhR4joM98rzhpsKO7azV7uFh6rWUPgt1C4Bdw07m57jInw3Nl | ||||
1i+kE2sYw8WL48XFencGBeBDb2ZPekX63GPKtfoTxbop/R2xeu0PJ1+dm/ny | ||||
1iw8pH2DHVaPhgYlolLT0DVGGvT4jX4LY14dTZ49AMv24ROk+Wc9Pfry7ATt | ||||
66H/NTxyg5XuYE/QMDkLmasNCg/mXTo2e/7FMyjM2myQbrZdv0zr91+4IsmE | ||||
y3Wel7srGMRqcSbuvQ4LpvWHFaF3LxkTU4AC+mVQ0NFnmD1+JUvpX/dqeslG | ||||
TGVpfyCn7cK9CfNk6YN6N0Wuo+jeYEKXIBNmrp+se8d005+JzpydX/BtGKUa | ||||
AU/86XkY6obg3ARdvnz+2bN7n91/eP9gthHlo+T772+FtWDBrrZuo+kWP4no | ||||
IPB7vjhzm1XDfp1cMOtvfUTKI45mV85KtLWsaO5sHKj604vMqkcR6J56AXtn | ||||
qB65C6RhMD1GJuoQZTpz0UYYtH5Q7EAjOi4JXX3q/0pP19up6h+41fmnYWzM | ||||
RDCOW8ndgHfflwG8e7RpPaqOLPyP//E/ZsasXr2Ifnk4/PnlbPLnik83H+nD | ||||
7ffR3wd0mv192sDfx+7+ffLRnTXEnl7x499HNft76MEvr+zBL6/owS8nPeg/ | ||||
iPrGr/pz1afTz/7e3/vr0OZsnPEr5uOt99KFfRE/PPzNez736j7/+qOPhpnq | ||||
EeGjj37z3vf+jOdu13dX/oYPf/PuPu/fO4jmRkrGq8ZJ/mWvju89zz91vAh6 | ||||
9Lfbsw+6+YvDjUYHJ/CjG5tYygiHN77vAfFqzEKn34I5O2xBeBlt8NKasw29 | ||||
kDK+Eh5D/c4OJx/1hvzcLw8XvSpxiV0u4Pr970c/HqdlCIRAiJB47+v5+piH | ||||
vIkmFPEUi3QybWFrdfKrWIO64PwaN1yOamQmIqqnwQ1Wcpg0R7j25370Zi91 | ||||
+1ezlffRO5/WW98J/TStuIdwd/pcZjfS7J6en3iNqR+HN/Z4fPjSn/hXJrhF | ||||
uwNfvctxusInvzSKHQ8ousoDkpUZOUcH7sp6vadTFL2vUzR7P6coepdTpG6G | ||||
j9/Zyw1piv6JbtIHs3uLM3T1Ytkv8N8+WPn1xTl6OZrY4ECMzrkW6twszSm8 | ||||
ne8kNHZ6/+0oSo5GSzMC2pdPv7g9uzNY5eX2w3D7C3/mda9MtZVvNQQ5joRC | ||||
n3CB/9ZI2jSzY8O693T+4niNpuuyMYA0783xcIdCVR8OjzuK0qPLtHkgJ+rc | ||||
CXRAknfpmn6Q05XRE0eZHIBiuGsyMwMMLVrUV9reM+LNCF7NDbTDzSFt6wXO | ||||
5KL9Cz8dRK+P56jSXGGW3z57/Gj4XAITnJ+0aLbcKZfgvD5egPoDyQqoEMIi | ||||
ujnaUq9L92a6dxzYtts95rCia7/RRDoTWhu6omfsQNhmEIf984JY/X32ydyf | ||||
uNkjGt4xFV/pmitNyzv//D36++3Dq/685eMf/kOLs15eDgcZUSwx9PGy+PYT | ||||
PLtpxD4VY1yciGnyzYFMhwnXgHwhJjrarf3VvSWf0cjqWGb3sPdQXLh1tV6i | ||||
AAc0EYJqZ71TPApB/+2V61hpHTWUoDSHLyWv0+n+4m1iPYjMQY/de8+diN7V | ||||
4pP3j5Wd31/+qa3nifuTMIB+cEBk/e/r8Te2vb+xI/eSRPSn98w7SVRP/3cd | ||||
jaV5PQwn2pHM0KoafYdk/uMk8mdJYj8B6zfnfZ+U6HkhmAh9GwxiT+Cec83B | ||||
bvRhHGq4XzboajE6uzhtafOq9SwviVEvPkIDGZ8yv1iebCS2B6O8zGt4w0Sk | ||||
hCdyFAP3uToWGvq9DmGrPjYbQi7bwYc1ngTgwCbnfpZqSEb3BWFPRn+xFb9f | ||||
XCGmv/hhOT01b2bmZLUYBbYPsZ4PoZ0wqNmNs8X6sPVMkr9xFKzGZHUB2f6q | ||||
eS/rXz568B/08lTE6/R8dnNYO65deZ6BGkAYMEW/NWcXCkYmB7OkqeKD2ZfP | ||||
78Hxxfem7PIIV76Pazx4eP/Z8zsPQ8y5rqswSRCVYHcCB9LaD8ZLURqs5n7/ | ||||
hnU42Djk21BhWP7B/44CvQrj7RvYDKcX34UWTlPGw068cYLNjcB0kF5xlGCQ | ||||
ovOL5bnM3OWpWsyUJwLjmHORIHdxgnzoycshviPaede/Yc4QFvNCDw0ouRHS | ||||
6br0S3KwCS88vPOHmXEwt7WCTacXJ+s5xCLakYPRiq4EKBNRpm+dsfOT+Xrk | ||||
mmOXQlokDMSiWwfRNpjhFD2WuvhO6VJNBK33pKCnT2qHljXPu/F8xZzkJYTB | ||||
DRIoUnPQj3TSZEiGqJFwqTdLlnE5veVoXNloWNkx+tPNl0y1ujBcvTMRgUIF | ||||
2uvngYRsgu4hK2OiyzMt43kctPmK7yZ5moNe3CedWF0wJaEnQWGi0wUfnsxf | ||||
yiHoA8w0MndjI8OYkUCmA1L/+mgIovRMTS7O6fk6GmYWv+0HRrkYopMDWT2Q | ||||
bC0Did3IlXoU9dO+HGRyZ46f4+6cDF7BkDNQ/0fBUKD65Bwc4qLQZr8mkT1Z | ||||
2Jez1UuvqNKdk/XihddkH0wiqb9YTcyuXVygKyeLxcux+WkA+ubY3YlM39hY | ||||
2lDnMFca7dbtEMKKZn8LwYEbl5nTjduzGz/Mw28c9PdPZvT27E9Rb1L/Fo3G | ||||
9cZWj/g+Pdj/Qr3keQ8fHB0d3bl7Y/L9RIxuz5KyLpskq5NkvOL7g5/3rN9t | ||||
nvV9+PfPET9oYjZh2KAAvcLMp+sAmC0uYH4jJG77JrHY4P3sdVivQeOiHu3f | ||||
KYwHyn4sPVr0Q10wHZY3eq8Hv4eqS/xCxOMEgz6drBFER7pAz+brofl2o9b7 | ||||
/BDf592SivfK5DHQl2PUfQUu+2A3Oj1grrxwDxmIpi6P7LFRxIfnnMxP5+vV | ||||
KMb/debt8WL28MGDu1/+5U5z98XLvx6/nH/avI7v3vnd4vXDz+88enhn9em9 | ||||
39/79NmdT07uvP7dvTt/vW8e3n3x6b1nf/302YM2+/h39+/e+/jOF7P/Hs3u | ||||
vjh5cfzyxd0//u7h/TsvPp/fef3g7sM7j+/d+V19R8+49+Jzfr5/5/Tzzz69 | ||||
8/CNX/x2nZz/JTurvn2+/uudJ8uvPz7+450nx799WKm1J7a+/+hpevc798fX | ||||
T54//6T6/JPPT1fF6/Xh6RdxYtbxs3uH1t29ePCX8vd/+Lx+/Oq7+M4bc/fi | ||||
1fNXvy+ffX7vuPrjk/+4/9d7nz5Va6u/Fg/is/Xx0/vr5R9efrpIkmzx8Ksn | ||||
X51nqzf5V589efGdqz933z3/4tPvHi//Mv/y8erZJ79v/9Klydx89Zf/+G36 | ||||
lXvtnh3Wjw/VWp7Fr19e2D/85VP/+Lev5/Xy999+/ceX9rO1eRU/K6vfff3s | ||||
5P63v/Un5dmbp9+dX1w8+Lh5/LvT5OzbbpX8MX9y/Pu7362b7Hm6+E6tPT9z | ||||
Jnv88uST4iw+f/AfH5ften363L988Prr+j++Tb94OF/Ff+l+m/zui6Yxdw5P | ||||
L/7j6SeP8j9++frx0+Unlb1j73358deHRfl1qda642aV5Z+c/vXup68ffHzn | ||||
d3fu6tO/z2QlVx8efvjLD19sfvv6w//+3z8Mvy/Owe/VyUBzZ4euv2n82KzO | ||||
EvxjRVbdBUzssI+RzT6+/zQAQHzbfRTPZscnH+Wzk49mWVaH5MLt2bP7v/vy | ||||
/qN798NVOVcl4apUV83K5KqrSq5KJ1fNGoWqTm/PHt/97f17z6fex+3lCuJj | ||||
nqxCJU1S7d2ZX9WLpOGqbHJVkg1XibXO/jSLBWezWZpwXT697qrephlXFe/Z | ||||
29Wxyepct2X5XifScrcTSd+JrNzrRJpf0Yms/hGdOH3RJbopb/ZuunJ8hWah | ||||
/NHjK9O98c32Jjntx1fme+Nj4H3zDx49v//p/afT5rM43FJtpCjIWlqNt9x9 | ||||
8Hz27PnTB48+1XXYKZUPntlQ/zKttnijMi++7i3WJQ99NFGrnrAFEuPdHD6P | ||||
bYxuTKobPhyjrD3qD2xg09KNvhoCkIashF709TmzbeFW/42qhT482n76A+3+ | ||||
avBrgKDlHPLxYohb93HnF3OVfoU2p4Hs/gIM4eThXz590Ie6ZDcXmwKi+Wpr | ||||
pvl56Hyk0o+9u3vayRcjd5+GxVRypJRCyCyopC/knHdSHBFdvQjVJqtf7Tlr | ||||
g6u2zZYO5SyXTeYkEzpZu4GzY2nNK7yoEHAenITgogwZDvy6aBuPfG2GKqxQ | ||||
0WW3vg5P64LjsN5//LwvmHjTB4j7cqvo4mwOz4Odt25xGiI3mv4QY1ottlGM | ||||
barn6hqKwVvdzsFbCrMu1seHfewbSei91mjT4UBc+1CRXZ+o9G1crIlbo/or | ||||
7rSbeB2OQp/TVpBiHb4a0sQ78hH1QZCiLpMxVdO3cjLvfOBTzmNCYNGLs11q | ||||
PvUENz7rUfTUv7g4McvtV3ri6PKtZuHRsK1T2uw5z+n8DE7zXa+ny/nqpe5Q | ||||
tkCcTOWmwZFxwZmBBp12Fyczz9TYkSEeq1TmbOYu/OAMzrZ3TiZL0yrsWipv | ||||
vjvEja9zT58f3huuOsabD5USq4G/rUbvYffC27NT8+2heeE/qss8jgceDVhe | ||||
nOrBQ9jrrTA1LmP/jHDtxeoCd2mzpqrg6tepSRLWCek+RdDndhUqhhSWUsah | ||||
T71MFvdo9sVCJVo7o10pyhNxCZohhb7oAxI4fiebTu7kQqbptC1JXx0vluto | ||||
p9HZtlHnpUjiKMhfuPtM3fn9sd88cKO00e7T+kZ63z/IzaVgCpT86MXRAUpi | ||||
zehgDB2XEz4/Cy5z0Bq48jt8F33rvz2fD2gbZEGitnni4O2tNnmtUMw27a3w | ||||
8oKVDikfRPMg2g2Zb1GMiZKShAfgjo5dPNpW5r+e9yU5+N8XPgpxl/kJra/5 | ||||
eyJBe4tD5877lkId7H6Z/7ZsMyQZv9pm7/pqpNnfPthJNfYQfWVW8oowaF/9 | ||||
em+n+lUlNH3jY+YmqOkQaNhmCC9XYA0FKJvm+TkEh6IfUez57rzmBA/GVKDZ | ||||
74gWaBsNPkCWccZZuG9WLx98E7795lw/KXLfA+0JXl9f7badgKHgN8jj+cV6 | ||||
TKZsEm6zZ8FaDtRgZ02//z4UWR73YLDyPXJK0oYkY1jrcdI3Kc3diry9517O | ||||
Qk8K8PYSnMrk0CJy15ethVjPQHPU3pjc21MSYFF9VEx1WMgh/tqnlYBSpspt | ||||
y5KuCr7shMxo8IpA0KjEIWM13xRKjIXm/bRsJrRPTPWGLbRNo6MN3OQL923c | ||||
UIG0p+ks/H4tgJK7O7ndwXH/xW8Xc64Z6pu29OYXl1qYxru0B2GSq+szw9sU | ||||
0biUfe9+sUUixjgWSPV5+37uNkVT851LaUUZvjdbcBvaHYrAtmIxbF05G4Vh | ||||
PhQ3Xq4YW4law6lPTlSlfqwYZuCLUnx6MonD9wVuZz1t7C3cD/ZjWh8aVG+I | ||||
BZs+rrPt3DdB6b7m06/n7puxkC7U5c52a23epnh66pbUBYHhmXb85JuQvV+c | ||||
G5HDUCPZJ26OdqUgSFdYPp7b+lFFN4miK2oXh9roXbL8aR/tvcLq9Iu8GkuM | ||||
eilSUcOmPNR/q80LL3pKut6B1Z7jj7PRV/b1C7kaiGuoIt5Ulk5nDh4idN1J | ||||
oU7zXM+8wsHQuft9YU3o6sfaYLHz8UG0ufAZYgNf3Luu//Rg+FjIwfI/MfPl | ||||
4ENsK1e/eeQHVH60+iaMbT+peKnDkuJIn958coi/y3ef3dEPtzZ1A6FtWnwp | ||||
WdvUMigzhrCqynnBl8ffTB4VXf2oA904cai2hT3TVKdM9wcjdK0Xh3u4vDXR | ||||
g64MVnrAqT7G2XsuykGEuodv15d5a1+r//X4/Ud0dH1x/pU63Td188YTpuGQ | ||||
6eCfGwczlO1WT2c/89pQsPP1mOObKOBuPrvX5ysnembn2ha2upiv/XaR5IHs | ||||
dymav3M1MxXeHu1Mx/p4s20mlDnsG6pRRwKWmdlAIrL0MCh0b4C+OVtwxzfR | ||||
NgUcjOkGCKYu6x4ImdW+cg2zH5pk0vsH3szSW9Gmva/d/IW69pFmKC3Km5tv | ||||
bvVbh77uO/CRFhdLfDP+No7j5GD24YdDPn2bdta6pEOQ5AT+H82u+hN6c3D1 | ||||
d/vdestlU7S9FYWyrIO+rMu7r/2g/x/NdqXu6K4uuDkZ1CBhWsHw3ZbP/dDS | ||||
D4v/oHew9m4WeR6AcSyAbnFZVrs0bCo4K/jFsHtiWP8eV/an45uxTkmkCJMX | ||||
bQoGJHn0Vwh2RbXeAL8TkjimmG+a1b592pDyvjmv8vJ3iPlu6e0mKuMug8Bg | ||||
epU4uoCkJOXX62Elgwh9NOtF61ezD/8tFGnMvrpSgf/tw6GBWvePYbqvpzLx | ||||
q8kVo1icrl786ZH/86+i73d6/KutDGz6vknfTUJSO6M5HLI1oeM3+mqz9HBh | ||||
134d6mZfiA/16I33ivM17IzRoAaitlnao765K8exQboTr712qjwMuU4Wod8n | ||||
0cvfLvtg7DffxjJu6fGXt1rMbqqCN7DYsPmpF94TPbMWkZj3pWy7z7k1mO6B | ||||
OK8mIdMQqZrE9uixsthIKq3tcaWQvH4NK+QBffDr5M2OEzC4G2OUD6YAX1+/ | ||||
+V75w96lHfLybrYftTxdLDcFwP08T6RhM7mP/LB0w5cbmN6sfbtQxfMuq/tm | ||||
n3Dc3AOgW98MajPo7DcT5Bn0e++OnkQEMHCjio+bR1x0Ytb7IP8Wfe3JxFRb | ||||
R/ctmCVx3+jJ42fPN3YphC23PP+yc3awjVTtqLvpaweGesf+uduI9zZyPD5o | ||||
vnpXFHxMcR+J+g+cdnPrLv+fdi56n7T5lRtK+lkYrwkT82FylESf4Ufcnl1u | ||||
LbpjrT/nq3eNod9HoDCc5uRQSPbuG8LDN9d/ASisj2/Pft3/ILWYTvlvoujX | ||||
d4OFHSqlRrjfvSiA2gcfDLMlZjeIw2afw5Ta9R/B7b48D3Ew6+fn6209emhz | ||||
6i/OxiDSas/5V6497MfrUfL5vrxsyhHNbHVxfr4Y0s8jlB5dcc/R1dA4YXwb | ||||
/20LQGJGDz7uPW4zrbBDALbe0Nbfu/TQCU5IcoapGELhAPF3IcDbhdhw/+XK | ||||
T0ave4R4OPk78xYi/UuI5vJs1MRZnqbRzS/PhlBqiHcNsnBr5pdLiX0/vJ7O | ||||
9M+99EAhx/7Tguqv+zzDQrAxIlb01rH2QbLLbtO4nXkvwdBz54PZGxlM3XkJ | ||||
0iblbxtaFL17NmbvMxuDS3E0e7wetjLi8OzEu5Wwmp+cDP7AHvHZDWkcTPai | ||||
bSoy9najK0YpwemtQL8xbjQYowbJMuxxnrBj/krH51n4at/xWcnxUZD2AkEe | ||||
Z/FA3We6P0Kid1vsSe394fqb3B18p0tseKC6+0//QaILzQ0WaOcxgvH3oMez | ||||
53uieIkzDlD5nqRxQ+k207PhdFd9GabsT49Wv3y0mrK+/pk/lfZNH32ZQIzf | ||||
bijED5OG/aUOrGH6oDCMzaNuhvHcGp630VLXC8g0ZBA2CquecTYbAh1jwfpe | ||||
lwa/bi8scrOfvvjPtw5mV3+V/PnWhuIMq3yJZmw1I/AHbYK6kOVyfpbG8bD3 | ||||
YmAP0bCndDUxef3NE/YxXNvTi5UXA3k3o+hbuDHY+9HCh6c//vxHGOk9q/52 | ||||
K91f+ENmerxqtNOf9ORt3EJ0idPtmuYd5/IY/TwZ0GoLRPKIwcNJfmhqAFbR | ||||
dDIHgrrTtaOppF/ewXu0K58H0dYCbJRgQmtD6kIX9vZg25NNpnaoeO0j5e/n | ||||
QU+hf3LpYDr6GYkm0LyHLMp9y8tgwbEql6IFw4r4acBggNW3RCWu+HNpLt7/ | ||||
1j0Af/8bwzxPQhvjQH5sdGM03FGQIe92F6QH9DGevsH0/zVef4iR/ClL/zx1 | ||||
9PeDJfvfT9nj/nc7svCnRy+3BmNiKMLvR30wbev0Ho/F/zixq82hOTue2Rg7 | ||||
3UaMLq/JewaNhBX9RH81qXuOoq82Rz2MC6GHzhVVCl3qvwlTu4nSvi0hGoko | ||||
7+ciB0ke7+hJ1LjP7WDYU3R6bpbjFX02PTIvxPfXk5t29a7PdPwcstSv606r | ||||
Y8xSGaDeuvVrt5W7iTpNlvXSp++IR05bHCORV3TlKs62oWtv7fqtqC++/2h2 | ||||
1TWzjz4aHr/z8a09r293Y+o2/9xvtN6k5YJtfWcmetzktpOPjjb56IPdhPTs | ||||
6oR0oINjSnk8U0c5qqUP4Y1NBGqzVfxodmd6Ro7cm+OF29/zOhb3XEG9vdsG | ||||
vSFN0YYe3+LzndzOTV18sDm4UOeC3JhA6M61PwZHVdq0OVdoL5lpppWFw0Ru | ||||
ZngnRnbQJ1J71hZdQtgdt3gTx7/ENDXu0Q0Ie0E2xROD27wfmRv3pX8z9Ra/ | ||||
2e7t6StMItb2YunHCsCpFx7qfLHtZ/714JFr19JwihSemRtoYVj3aN97D4U4 | ||||
2x0/93THKvi6oaBqLMDZeBhh50ngNa+XKj66XOWxOSDHhOPUBtRW7YuCsvJC | ||||
t2U9PXz1zmN/gNpw6FJQzCDMS9+7+bO+qHEMTAarqMnSHMO/tzD7rr5J2M8X | ||||
q1U4+8B/qzDTUPQwZmFVm4m5ijb7AMwwi4MWzMYN86v1MKSwx+livdkH1BMj | ||||
rUjrVdkVJlc7oMRsuKifEG2pGrj2MONj/Lav9cQnf9MXRy761LKeELJl/luh | ||||
QK/8rQTBQOj7kMVb64PGzf1XlgdNtvgPRx+MeeLtyQdmPPfgrcce7IVJw4EB | ||||
42FiAFTYJHnFGQPDum+Xb7e98ZyAYNXPVNIBDF+E1PG6D4v/QK8Ug9/sjY9o | ||||
6e6zZ3cG23b45Nmzw4+HfZ46Z8cGSL580R/vP328e2G0Pd5g86jNyRB7oeMR | ||||
qgr1cjqgvhTrikm5PIy+WnRyPtJkmqL9ae9FcQAKxK6vE+rrld5yGmOoBX6j | ||||
AyE2TuCl6owhE3HqjRo6ezPWvwgoVhBo7bofdrBt0CLaNU+h2FJJyyGmPTZx | ||||
PPw6HlCwgezeKWUMEWLPZyoIWiyWaOPg0yz7CtjValMgdlX5yqSUcCzG2ez6 | ||||
O/FmeTbtTJi6gU2GI85GTuUulm9N+223bw67mbohXzIcKPleqzxKM+7AmTY8 | ||||
jtbM9iUJ6/ev3Bta0hbOaKo0l6rjzt5NSrbGEqven0aDdY/eh4q8uzYu2pwt | ||||
cnUObXZdIrf+T10i9wx1XW8OKNwWsL2zUm4z3p9fKTfkLXXddaXcuyrl3qmG | ||||
/zcXzO1Viu1Wem3x68cVevX3vE+d10+qbIrGypbJSU0/prRp1+f5x5c0pf9y | ||||
JU19Sm6IOdLnVyGW0FcxhRzPk6UHJv2DME/rNzulTRPvde+ybT5n48mu9g4l | ||||
mp501if6tuQw3L5zMsbu97vRgLeVOfXrF6JG+8u2W+I0nokS/dQSp9lOiVM0 | ||||
BZb/TRVO6TbWeXfD1W+mcV4ftvP1zytwevl/TYHTO43Dj6lzorm+0un/+Dqn | ||||
l8MKjqC9U990hQZcTue9f9VQ9INVQ2P0+AerhhRa+MdUDUVT7nZdNfTTqoZG | ||||
nvB/YtGQWP7HO3sEp1GG/yyFQvfeVhozFt78mNKYqfr8vNKYPWPZ0xogH7sY | ||||
7OAz0L8P0b9thvcLtnXH28PxW4qS7ce3nm8SVLprc86KwExBy9P5eghjrjd1 | ||||
V6Nd28jtWEQ1jG9jXK/mAhtLrRHv2elLJSnX5RT/4HKKPb73j6im2C0zGCfy | ||||
h6oMFJMYCwsCh+9dh61oTOj+j8rhb4U93xP2n5zH3/PGpx7vFdm2fzz1/dfN | ||||
8q+Cbf/XyvIfe/uy1wq6ekV2uCfxwQZH23OPNy9zWeptVWf9EXiTwHLvKV+u | ||||
FJgYRU3aZoDfsKDKUCh/8dX9pw8++cM3bxXV+ijpncdwMm+cVDiPQ7ZsKPsY | ||||
meJnZnW8ecbB7OGnnyQ9hu1dx1PxR1YvozE/vJiYh5vcdmt4N9RMAheCQuZE | ||||
cfYAOjdXoM+to2lS9V+iqmAsBbg0tQFB3lEX9NYxvOumH11YsMXXK32xf2Dd | ||||
wRDojwJwvl/NQTh1VMGk8JIeRfg2YfooeFjh7m4bEgyvuRnfiSJ5/eTBk2ez | ||||
pC4PC0T3v3387NlHHz9+cJTER2Wc1h8+evDs+ZEuOQqXDNzi7WUOsyvKHKK3 | ||||
Vgj8QApkti1oOIjeo3RAYxtCYgPl0WW3hqM1ZpPPogAWH99/ujmy9tlFOKi1 | ||||
fzjPfoALqgnRES5pHWMSbj578vmDW5uDh81yGZCK3kVmvzVEedPSgLJDW1VR | ||||
jmnCcArOzkOjELfA0du89Uerpyv17PHRYdY371txh1u9Ga6IJvM8PMmcvFjg | ||||
bR+fDmG/yVl4k6aHjNnk+HZdHPXn9wwH15qpnoZLV+N5flq9cG2/a7nv4DHY | ||||
dmd8+kEk+PrUn20/CXcJpgZq1IfHeqd58nFoN8RiJrnVSP7HCOjHUxDVqa8L | ||||
2x/ws2GDk3qUQIU3sVCdVLj1rSfFDZfmXgGWO88eQQn7CMWEaxrYsTnZOZU/ | ||||
MLqNA3ZriB6PdGA8nXS6lfW/Ilh6wdvL+VEbXuDy7bdudricHZ5fHzl3feTc | ||||
//lHzl1Xbl1Xbv2vrtx6Np0ebuyJ3Sq86WSIUe+/mIZ+6fjY/rVjOpa8z1bK | ||||
3mxWfvdNZTtncfd1ypdqK4fk0xUFTjupq6nve4f5XL2l/3vvQBofu/OIzWuR | ||||
hkM4FNPYnOi78wJMluxQCyB533lMeKtFmNqoXS50sNv4zsretE96Z/3yLCiP | ||||
6Y8PHMOvuq7/YAjErfy6j7P1CZz+gOwhXDV9E+d2RS69/nK//mb6ciM9b6c2 | ||||
bO9VR26+sheYsc2risYB7c0wdvfkok9ZDPn0nSnbFlpEQ6HFbm6xfPuj/ept | ||||
zwz1DP0yLf0Ls3Qng+Zcqg+ZPUKLpLSXej2yM4XTzv1yE3BaRJf83+1xg30J | ||||
fIi5MeQ3I6uefNSXKe8nI//bvcePnuFGYMT+cPUpjUDE4aSZ8SVJQ1/6Ajch | ||||
bSizvPPozt6A9konN+H0vWELYnV3H36YvG76F+8+U/QX4TjPv32wPVP00qtB | ||||
z7dh/xt777G+MXvanzuqE2p23n6tl5SOZ6tvkwUD/dVrSPTYZxddN/82vLwv | ||||
1FDMhpMRT5gYPny6ObP/7+El3Rer8OHJsEdjm0XbfxnJle8imX64+fnqt5bo | ||||
VSDvnja9pOT+80/4508770H7M5+ocNCc+fAuwkd6Z1f/Fg6doBosliZ690Uc | ||||
P7hGu9OuF3JsYkwhHLdZhS+HxfrbB5PykXeu6I5Ob5ucrOwV60gr2pgchG2n | ||||
Iz0IX9r/s90Tt9Otf+vfPnN72EXE749CRdTVrfB1/6Rnm2D97M5bolNpH5ua | ||||
Rj03t0vv78uVZSS3t9sj3RAou3QU1d4bUnc2T4+NbmuZ3qtzl464pZ0BlcZS | ||||
ar05483t2aPtNw/92rBwZvhw4DC7nz56eRtXRD/M3e1ZlvLTRotuX66j/jeh | ||||
qN4AJjm9tJhXBnk38aJ3rGS6Wcmrmvinr+OlgMWV4Y/diMeWLU4CDo8ffDy8 | ||||
7aePbPzTV/sPP36106J8x3JPX7O3Xe3n/TB/sGRdJwu+R9H6tkI9VKmOWd4A | ||||
Ug9DZYDEadVHyi6BiFL0I7N2bsuEgi28sa0sWN2IhkOu3/Q1Lj/iQO53Xz7W | ||||
C/zQVUP6rB+H3phyEmB0qFJY+c2IwtHf81DlHcIfm9MVt2+h2Q462A9EbADT | ||||
H3XO+OR88iiobKgojaKd9B1+50W73vn23e1GodJiLla6jZaF+x59eCeKHo8v | ||||
drrqy1Eh9/hJuOBGOz8zWo3oLU5JuGosoNFrGBV/1mtLF9jUQUmuuiU8OejN | ||||
Skflju+eH1/JeLuf452Po+jOdob23xmyndZw97P+UPDhqs3LPy9T4n4iIZUn | ||||
Q7ywTz6rBOjSwzavbt55XdikAHh469OqPwVAX4aDuJehqtWfbl1kvc39k6V5 | ||||
Efq0c6re1RO1jb9OSVT4/tcOh+vcaFfNRzfCjlC7vvEbHv9rt/7NQ/MCXe9f | ||||
xXVzdev2rz/kw1879xta5Wc3XvexXlU2nHt/MgeMJXarbWFQmNe33fzJPPjh | ||||
UGV5wO96zEN1c71QWFT3BAEX3L/1ng/dyW8QE8R14PtKmp0IdJb9ezd7cm37 | ||||
uqPuYhki/ftTJPG8c4F3sVz9QqHsZZ9GHvh5L6+hduJCJbXhFm2CfPxIWqUq | ||||
5qFmMxyXOV7Rr0to9b0eMtBlu6HL4S4xUlHNSyv4/Q9Cy6Zk6h+DKGOB078E | ||||
kGwq8f4VsOTylXr3wPjyt/BGsMlr0zZFOnuvvR+3PQkYNmeoXgVFe7jjT/E3 | ||||
XwXifo0Y14jx8xBjoEP/MMgYqoquMeMaM64x4z8nZhweHs5aY18qlnnHKtp1 | ||||
4t2LwJYH98/0z9vsFNwEpYbX34U33y1mZntzn/72J+fdxUnUee/0gH7PYB9N | ||||
7uOfCtLc9Wd/MTDj2TN7/Nos198dzH4LhT4/nj0zuGH+zUE49+I50DH7PT68 | ||||
76Ouz1Wn/FXwffbDrUM0mXULm1v6azYUXRvBWrNCXi/tZVlFO3UoO2M90huL | ||||
tS9zaO/wvH/LxDa4O31a2Ow+1HNd2jGTzIYjnW+N4fedhpcrM2k2ujyItzSb | ||||
Ds2mt442lUO72/+T2eFbzvr52wdXjG30mTfPHxzjk1DjultRPryVXj7+6uWz | ||||
29OD6CaJu4Pp+Wl7kbvhyLRw6uHsbaG7YVvG3muVj/23xrFwp+DWsOeQfpzv | ||||
92OykXnSDWNt2EM+nmHeF+Xo951aw92dfYdDpdemrkwbhfudcSdvtgVP+5Gn | ||||
TcXyzruh5Wq+fRihoK0fyLi7byiP7ismtw/bGckVVZKyIu85dyEb1z+0T8yF | ||||
SqrXfeXqWHKuyQpB371TfKfTq1rQt67zj1plWrq6r/1KDKO8fXkzw7hRclNy | ||||
uzdVQdouT9b7TtX4+J4J7Tx/qGX+kR0Ydnn8yB70Dx4OeOhjrZfOh3h3izo1 | ||||
aWgzVD5ob+ZE95MoKHbWtLGLc5dVWZoXTVrXnS3A97pp2zi1qTF56uOyipsu | ||||
jRNX2iKp6ypx/JNESd4kcet9Zpukab1L2rbrfNbZpK0rV9BibKKgt3Hq8qLt | ||||
ijTN08I6l6Zp5bKOv3iqa1xRZnFc12mTFmlSpS7LfV7nZZM2sY3SxJnE5KXL | ||||
U2uyuqtab1rXxYWNq9x4n+QFbUeXVFiYzH++bCqGVxVlUaWp5++6TEpXxaUt | ||||
izQunC9qU6SdjZzxHd0zWVcWeV4zLz7O465NmjT3dVrmxnaW/zMLhvEwC3Xa | ||||
ZuERXZWWTRlV/OX3n9Hvtb0dlZrM1OZJWzQu83lukqx0Ls8a1zENuc+KuvK+ | ||||
6DJ6XDW1dTYuOtP5KourrK2jQY1rX3WujpsqbmsTx23cZEx4nJjUp6lrmjhz | ||||
dda6omgqW5rcWdap9C5tk6jyXZ3GeV74jivSNOsy09Klrsht4RLbFGUTN9Ge | ||||
DmoiuzzOYtNmPs1Yepf4NGH98iwpuqKqiqbObFnVlh74rmuiPK3KJK6zlFua | ||||
OO5S65LUlaywiStva1PWSWa7uC3aui673Nq8qbYPHrUvzsq2zWxhs6ZydW2z | ||||
Iq1s13Rx3SWdL7Oyrtq6rHxd2CaLaSPyHqlFzOLa5cwEK26SpkPSUmObyvNB | ||||
0TZ5xc9pVee+7Xxd+rbxpsizrPR5FiF7pinLOE1SG9u66FrjurZD1k3C+PK8 | ||||
7GyWVQ3/IQ3IgU3iomnT1lZlnCSxj3zirQS89jFT2uU1DdG5qutM7Fqfdm3B | ||||
UFLnPGvCByUd7Jo0RgprX9bORQ2DTvMaY177orJZXOQpOlnnnSnpsnXIFuKX | ||||
o2TemWiADK3TTxOyaCtlRZxkSFbeMIWNs3mZ1nFqEJCC+UbqijrxvvSset3E | ||||
JkkZvE3rLGJBy6ZI8rZLSyClatK2q7q8tE1dlqYEYRgGgwY98hypqauu6EoJ | ||||
a9W1cZX4KC0yTQ5KZ+qscBXaWbd1nucd2ls33lfONlxZtExrUjVxihpIsZld | ||||
U5nGRZkDQPI4Z2XyKq4qtRd3tF0JQzKDEHvn22gfDNMRDH3nXYZMI2U2d45V | ||||
kQC1QFZWGK9JsmkFaLSx7VA3gNLZtKmdzaI2QQKQ79ogFXlZACodWuI9tqFg | ||||
al0NEvRgmKlW38dITZzbMsnLNquSuAFdU1OlbVOYpM6MMY13zGhbuxoM4uc4 | ||||
y6KurPknrXOXVAUz0kkqEGi6WFamRjoQVf/TwDCOt1gWle/EMrS7YriYiM61 | ||||
rFWu1roqT+rWtW2Ovtc1iAHY+KJg2jxY7bIEOE8ZJ+0MWFbmDVPEk6u0Y9Qu | ||||
ZuHLxuZpjnKnLIBPyzQxXZiU2DJ07BJz5eOoq2IkgbXm6qLA2lRYKoMOlaW3 | ||||
6Kev4qTwV2FZhiBmhm7FuUEvjOxWW9Yos0e1kiZhOKx+gSyVqY8Kg6CXrUE8 | ||||
cwyiSXIQC83KkIDEVl3WuaLr4rQGH0CnBEEBTC9jWZq1HfpWoth1zCQ04Bq2 | ||||
pK7bGPtXFLb0tU9a23ZZhd50UduYFtNTmxwdLbs0M3ldoXoNQla3ZZsCxEXc | ||||
1UVqy461x3YDEElW2KqxtkWtMZM1zdkmLT3TV9kk7ZosN9hw5NGZ3OS+aJmp | ||||
juktG2MqxAJDXLUtqllkZdSkBqxNusY6dIxV4qFeKFLWHnRKUdqyauhuBbSx | ||||
LlVSwwdaWkuarKGhyIojOJ95GZmcFS5RXnCT1WnbJEFHwYsKaU/RCTfFsp8m | ||||
ZNFWymzTAB4O3bCArgxmkjlMuW9LX6JV4JszpizqIgGDIDNp4TqfYAIwn6bE | ||||
dCRlXtGHxmNdATprmsLFTGfGJDMfGeONy6zFuMSgAsQmSyy2I2qqLuEiBp1n | ||||
SHWMxrfWFMb6uDMtHQDcQd5c4oCCId4tKgn/SaxD+2obgbemyjvJR1q1uceK | ||||
YV2gI6ZomUShaleU6SUsy3osS9sK0lbQbsmPGA5IQF4aaEwNu/GlNb41pffC | ||||
feax9I1BDX2d1DaO4FPAMkQIJUkheNaYumiYkA4wbbArzMSIZZg0hFZKAAhn | ||||
WCyMQVsi4nXemobeolSsCHNdQZoYIUuBaXZ1G+WuzF1bVjlI6LoSg9C6ypcQ | ||||
LeAMxEdQfe1+OpYhQExS2UWXWJ/lIcnlm0Z0q6u8aTCgGTJRO2xW5i1UoUmd | ||||
6GEsm4BowLkQww6MRlMwDDXq4zLsUDeiW8JUYzBBEeADm4cpg5uhFCkG2OfY | ||||
EmxNm9SFCAawAZBlvm1NFkewJ5SlaauMmcBkQuLSrGSBCihfAxOOO9t1V6Gb | ||||
FCbndiYfI2Ix0Mw+BgiNwHyDlwYTk7c5mmMrH5U5tjhvWrFayDDuQ4KepjCU | ||||
GjDMoY3OYuxzZyyaouViNesrmBrGC7RCPVAK2FELtrCovqVV+pBkTVemwDuq | ||||
BLrD1Ji/JM9sXKJFSH7dwszKMoVbpUWZM71Y7apCidC9LC/AqIoWudnBd33e | ||||
FlHXyWXwKeDRVR4eCxgDmdhelBaCZPFYGBGWm5l3cJIS4oWa5iitB7CLCBPL | ||||
utNF9Np0pbgMVLaSA5MhnQliVNuuhBAVBRQaFlcyfgleVdq4MU2Utig1QBgj | ||||
s7EDVCvWqwa3GHuD0uX4B7C82vgK0zRFt58mZNFWypImb1AlmEaV5mCIgdgh | ||||
0bhoGeyyBEngllKNGM4G90PgGjy1KHEw/biFOCP8eE5djYXAGGIALWzbQKl9 | ||||
ngBlBhVB9lp8sZQvoYC1+BuQjpnDeNWt9XgXGB4PTOPgMSybQW1cVWQJDBgR | ||||
YOzAf+larJ/DQmKkXNpFsGubZhKXCrLKqlrugeCD5jiEYErOoqflJXTLB3TD | ||||
1cmqtmrxO1wlc4091hJ2+HEJpg4ODLVuigLfDciFlHJxmUCkTATidlYqUABl | ||||
psEEYQjhHNyfcwGstepGt1X2milgQcB/qAE0n39BFleaWKPDL275oUIxCg8h | ||||
K+UhVSg6XkCOycLjyFsMiMiCvJgYhcisFpHrcaJ+BlOLR7iCCMd0r4SZ4vUV | ||||
JoVUYR2RfIBC7Ca3reSrgxUDCbV8lczAqFEGVDwb4cp0DZ6da5H4FlJq0H+v | ||||
DuN+tDWGAnODow+1wKWSqmV5jhDFrEKEEcDHamG6PkZZQRGsSiObkPiO9SxK | ||||
ydxVcGUKGEGWAnsxyOHAw9J5hLrCOqJLXc0VSJiwAmYepQbhx2Vo8gRG5DqL | ||||
n+IyrGxjcEq1XKh+g+Hg/oJ5L2qXZPkVcJWigUxDl6BgDTMKjEB8GXAJ3QMi | ||||
PO6g8Y2FnNVFXkcOkgDJwfszcV0V3JPBepAMHFy8cfxfSFjLWiUKHuB413yX | ||||
AUPwmhLQS6OGHqGauCRZjoLWJauSwDHrju66pJWnAqdDKBpTCR5MAzLKQde6 | ||||
pXUaVXK86ZJHyBvQsEOC8aRTsCGB+EEggT6EI0cgYEm4jLhfMFLgAf+oS8oI | ||||
pM+a0obrUwhyisWHOYIaPC2FD8NmcFtkG52rpnD104Qs2kpZjJPexviICkDg | ||||
K0My8gSbUbm8BpmQIph8LeoKt4TotPLgTRylFvUyDAM9K/gbNVBYCOYAg8NC | ||||
YhR90+Kc48LbTq59DfrgOBQaCZ5ypOXyBWLUYTzkp+EjtmgzlAxvA1IPPkFJ | ||||
gYjMw6uwLnjWMC3HcxLfeshYWsK3aBeMg912FU5SlzAJGFVwssytwSXML8FV | ||||
0cMVQgPvFF2TMajxFsRo4cIlji7EFD6QYpgRiURcC0Qqqs4lXdp0TeQhhKAb | ||||
IFSAUlYOrICz6qB3SRLDCotmhKuu9UBa3MLdWhg3psBCtzFPVSsa0GA9QT3T | ||||
xRnOAISl8KL6GRoeiZ3H2N3CgTaxPGkmyvEvVoAFB/Xo7//WKNsG7xo8Rths | ||||
GuyJolm4zSxO2cJDcbrBgBhHymedyWoac0h+hrMC5bYNDKoZ8Q5fKm4y/Jg0 | ||||
b0s8AdQZ6e8KOIyc+iKDWzAWlynwApIj5KA83pONigYe4BSqwOZq+bFelvnB | ||||
qEBY4q6M6b25Cu8wTilCgA+Bl5iwOPDeDKWEH6PTJaiEr8M8GUkp/j5Cl0O8 | ||||
gDXoNKMC3bBs4rYVyAbXyGkChtZ5uQ1pV7jaXxVIYyBMR1ECLYXCVyUPTdOm | ||||
zTKXwcJSDHCCFY1xfHAKY7CmA7XBri5LuxrswpfCw8IbxB1snGC3caA0XUUR | ||||
MwgMRhSWhXRWkIKujKraF2UJvHgMg23KNgOGfFsz0hif1zITPvZAR4FXpBBj | ||||
A/XDvaM31qIvVQTvyLLOK3qUMCeAulYRwRTjoEGeyIPw6vBUEHKBG7yXZWtw | ||||
NpsE61rKqS1ggeATCifjC7/qmrgyMGXcHK40eNZgBj7aFO9+mpBFWykD8jAt | ||||
gK9oVIX8AGSJ9/J1Ww/Dkch7aB22R8TWiZ00bR1VvkLtuwzWbACzREQUlULl | ||||
Wxh0algHwN0CZG1cs2w8FyaqVYo1j9ZA8CDB0GagEfZRGRTPwsfx0XFSigxV | ||||
9LYyXW2NiBziyvJi6/FysaSKq0cKy8c5Lgr+J3ifopNAIRiUInU1jcOlfNnu | ||||
HGuwm5xMZ4fbyvODsCV5Py2pzOjPTUo+uf9wU2L+5PN7zz6oQ6X7FRsgQ8pL | ||||
CddwRt6mcvNHZNH+QRnIq44W/U+RgNw93/Sfkn/c7kzcT0K+/8O0p79/1hUT | ||||
uHNsybYXmyXadCJM43pzRMwk8/ijU4k/L5O5P+s//+k/Ko+5d1jdv2gaE4ga | ||||
/pcryYFnDdzGijzg1YnUCL9jLEBRNNtr8dugmBEXF9BRBcjSHI89lx0E6Mq2 | ||||
wl0t2xLDh+dWZbG+57oip0l+yvIsF3WIsgprDDPGY8AtqbggkXvSN1ioSYvp | ||||
g5VWCjvhUPATTg/+U0of8LaiCitSJVVTVFlRKLmEoSk7NZfFWZHzIc+BcuBZ | ||||
0hJcpM5KvuXpOK3Q0TyCdjG6FDqLEcxB7aqmSzIeOfY+xeAnONT4UNAy3BuG | ||||
zFXQNQWCTAEviCCdPKhUtrBVV3M4Rp4pk5EzYHnYuGp0OZO/UVRxhUfE9/CO | ||||
Uk6FLyOeneK+wVXgpxDCPPxpoJ9JBh1kEukbHDE4HJi9BhrVKThZZDEkuuwi | ||||
Pa0oGZ3muGMgECuaxEBX9JzewQZhA9BCiAzefdZoSdVnPQJeE6njdBTCJM+S | ||||
MRU8HdYLuWQuaIM+MAQ6DfNSkkG+iHLLmaL8THikFWCczE2JY1pACzGiddEg | ||||
V5lSlVnJgHDyKzmmDbd4ekG7eQ1dwvtTGrhjtaGIsEU92SkGyDLAYdJWOYdC | ||||
cUGDB2kqsbs0rARTmteshYIHTGBWBPHMYSZ0P1OQmt+TUrLXIWImCHrKdDtF | ||||
meRK0OEKZxGelUXqP75sRQO4D77Q9DCHQbjbkhWnqy5TFyULCD0CmPIIW0om | ||||
WZCIxllQRfb1TMTaBf2Q/Ou+XswhEvymkK1BClgVCA1SlNVMdtRCIFu6o6hZ | ||||
U5YMAhnEzUppkF7pX1aLLxgi3lGpWacXlbLQBpmNI1pMNPYcN5O5TmmDiYTE | ||||
QeYgQx194m5Ex2qe6JN6VCG9zJaChqX0gob5PzcyTywhdJlBwZuRjUzChkah | ||||
yDgvuqqG8CoArQgBK4Rvxc1dVVXSfq6UyKBC3MTSFoodggvSVgQIuUG5UXbD | ||||
k1mFQiuBPCSKHuYaRF0gOEqsVXWGzEi4FKNmhnzQ30QDhGbiPkl3K+gsDccR | ||||
fa/xqPibQaRS6pzeSmYEPXmPFfwHuEAEofZoCc0VCDuzqYMvGVVAAPw+eROl | ||||
pJ7xcbHcS61Sy4o28uE0TaWkC/eEYZY4OXVlIuaWkSvbL/Rh5uk+89Yx0wmC | ||||
RYOsihovpQe00khrcTdMYSqJYpRq7UoJci1XhMdotdHHIuE3x98VM8DsMH01 | ||||
8JPrMTRA59ALnhWxYDkDEC1VOgqgoZO4R5K3IqTzWHthmA/Ap1WyrITWRGpf | ||||
VpHy3zB5heUkj7m6XAmjtfo0mAncmDhEngU1AgDwuuG/grWQvaj0LK2CZxXA | ||||
KXCAEXNPXKHu/I/5EJKXeIyFIglgp/J7cr1KfNkqosPMOwZGjhgNyMjUiE6S | ||||
C6ATTR9AhWcA2DSIF/YMsWik+OgFD4nyEJIX+mntQ4YnkXJJNnPQm9GXCg/x | ||||
U4X3XPNsZRckWLFEPYuaTHlnJJb/sxp0WCLTIiX4HyiUJL03eXIbzQAvrXCD | ||||
taiyNKKDAHeZBhvJEwotb8Zzavoh2JMJYHJBL9m0ajvVhRKP4IPvVz8PwQJm | ||||
RBor+xDTaEj6M6iYC2UnvHrLbYkC4XmFTHKn7GbMIjHxzK+gpcglXl0a5qQI | ||||
lU2q6shYG6baykVFvEG1UqTA5VFdaaGwlJmgE/Sj28Arai1ppMOVhgmK8m2K | ||||
oDNriHyqe5AHxhOhEMiCgpigJbpXaRUxhCyXtIK28jQwBMlYosIRLBr3qGyG | ||||
b7M8yrRwzK9UAnTKBXXy+CVdLT8lAd4lXsGIVEE3CvVZdtNnRQRXCQZeFjFw | ||||
mTDXGB2spCQUWTDCcz6qil7BMAmKFvJ7xQJHgjExFpkVBFz9Ytlk+JX/qKSr | ||||
IETK9KYYPwaB3QqNZ729yJgHLkYa+UyMgGVUAkdSqHlBLjFtZc10ykYEsye7 | ||||
UcoYtCoXkTygkZVmvglI24QmTZWGXIwmBMTio0bFHSC3DHgikS5ZC77PI9VT | ||||
0KZDiSxTByZxaSLuEHIETppQ6l9wGggWGTKyoIiXzBB2E44CcNeaaNplJhiE | ||||
EaSXNpj5OFPkV1JrA8erglH0NCecpBMR6yhYi7Wolcgbl9EXGU30gHngU4mV | ||||
JlDuv/icdCcQHIMK0gfEOhg+5kIYI0hBmNEB+oSVqEQ2lIyXvspkCD87TISR | ||||
XsBhFChh1I3UVgtGT1g44SIim6maSPyO9YUUMA96VMODZFGYfBqLnKwQt6gI | ||||
AuEJhpcnBhDz9EhMslRzuQgbBheJNLJlFVhN721UyjrTzUocIwYoANygf7Ao | ||||
PShwKwUoCiBWwIdx0tSyJlr6tIyQNkmflnyY60SjZxGBtNCYZVGrYNk75kil | ||||
O0FFilhYnYk/sDgG+BR/1+0Q40wmsZMS0310NCAFkCfgz7LA8oQjYhJ1FUHx | ||||
5DykKnNDnWWjWXGYvnIkqJHol1BpVCgZTNCB6fSyWWUW8EEkIxOUIpy9qc9V | ||||
5JEyejHbSkQ11yJWSljTMFKKfMumWelm3TOWShTIyhLmEgv9jnnF8Hal6Dry | ||||
Ano4iDPX5SLz4ENuUuyF103MLFSYJzBxpTJ1dJ+hJFkRVqXU/Ge4RRN3qhDv | ||||
x5WKftCX6mPQWVynccKAYxoqY5WPqBgAsVDaLFZ4ToWEcczqxK2uKGNdEbOy | ||||
AYMUHTVJwmVJfWUD9eUbN/dFKT/yfC5RWYii43HfIx6Zhn+TOLZtYrxDJU1T | ||||
dEWbWM8d6LiCrlGoD2xTbLvRIOQKForymlaBSddlprZJ2jSZ6ZjLJFE2HLuZ | ||||
K0/KlGJRgJ3GuMY6Zxq0OFWhWIMXl2a+VB4iFZy1yqc0Ximi3MVKvyauRiQb | ||||
/KJIhMuwphVtd0rw4OWJSMe2TjzPNcpUVW2Bpc4729QGu6Q0E1YcNLcebzBr | ||||
ZaO6poUq+bZpgLW2xg61TdzhziX0wkBBjPIWiHaWdbJGpmW1AU8LT0odVt0k | ||||
dYKotCrSqVxtY5DKC4I6R5ulsyCltyZuPdjTtdbRccTZJVUbJU4R6zqt29bR | ||||
77QRLwLOfNV1ddNhsBOAvGlZSR7QeCOy5o1TPD2Nq6yLPEifxzZOWEafqECn | ||||
BOqV800TX3R11iECPuUZmWXsyjJZj6DELoUmpaaJWtNiOhDPzBoXK/sjnutT | ||||
sboulrQk4diTq9Ia6Q+nNWpfGWsbrotkEhllXSdKvzQedK/bQgmFpKtx63Df | ||||
69qUXQf1R6phD8xN/d7FwwYrGCeNS7qmSJT7r5RCV0kmiOHrVvLtbIIEmkQZ | ||||
6dQ5LEbt8NLTqos3BXdIc54miCHgQX/RIOuF7Jlpu7apawAu7/DO08r5usyU | ||||
AE6xU6lxkTWYiY6WgVzl3lS7JEg0aIRPVMDaKveqsfb1rQxCD8KT6dLashqq | ||||
GUN5iraWqYOk+LIG6DuZxaJoVb/B3SlAx+0Vj/E1VlKGLFOs3roIRwyQV6UH | ||||
GtY5OE2NKsct0+MTdIfeJc7oi6SWcLiqs0Bga1WBXtcqG2TVEAjjPZiLIgGC | ||||
bWXoUCNJEZWgQbn2qt3p0gYNBekTVWFJISt8kBadMJhSg01q69R1aWIcUGoS | ||||
Y7Pa2S7NFaqH48NFYw+M1GCVUZU8bdg2YoodINQgjpW8cqY4Vck8T7RFGRdd | ||||
xv9RDQOQdbHNMANKyfKjYbFsayN5DV3T4Ejho6TYgMZnQvzWmq7rIPOsjLWo | ||||
GZYE7GKF4jZNMEJl5jNQJ+qjpJmWq1ZqBQut9F+qqH9buyTm8bVrG9Ub1jaF | ||||
lSMOoSoklzrXJmrAZNdi6XEtujRVRazzzoNYReITD+HDo7oiA8b8C3hBDMii | ||||
Ck9cDJq2Lfw8aUT2jGpdKpUhMWd5VGamMax+1sZJ0qn+IkmcCDlijfymHcAJ | ||||
oytUPgWBhIPEAFEmYwGSQzqjXLW/mOMGZ7WusX1xDb+rGxC1tgBi6hs5shWy | ||||
GOOEWJYV6ewqhKSoHTMZ2Uz66/Gha9pSzKrwdeMB8sQJjhASaJ5q95S0jbtG | ||||
3zJfpdH2CjwiZksKk8uZd6FOBERyEmQErPKAPr0oPJxdmFz5tmxsiKooUlYr | ||||
yBEhST6Xi+voGGYILK9sYHMObbKq8wZBUpWRMvYESYvRwEKqWbcGRIlcnCet | ||||
4h2t6ZDWzKedzEWboJZVg4+gIJcFRhAqB8bg8ACqlZxxBAI0i1TEjs2E2wjQ | ||||
Xd02tm6DX9NAblr1CHKQZxilxthCXAd7UKLU+GEd+BFZzDYLA/FhOS6lKWHI | ||||
Tm4GEIdtbOTfeIuYKGfGjDQMA/LrG1aK3rWsjGq0wLlE3qVIlMqpcf+yqqV/ | ||||
uJ6t8Tli4LpOldYZJLET9GBDkYjO+TISUmGQXYMJhZfUrJ9TuUoK52tANCYW | ||||
7ppkWGh8ZqRCiJW1nfYMGGG1WkgU20viTHy8wlYqhmuwkogiS9K1GLm2Ng0z | ||||
7CsnNxsNytq8gSN1rooAMNVlYvZjjw7zIyBdCCagacq3eRC/Ey52tsOljxsH | ||||
6Mk34ckW8xgBMA2cOPetUU4VeMLKMZsG98zBFFQlDoY5Fg8X1HcGguFql7V1 | ||||
nHWYlVwFp12hxG2JNUdDamxp02rDhmmaFBhF0NJGGtOWic3zOFY8DYxoa6DZ | ||||
V0lU1Kbumlq7eiBktUgp1BCQAiNaLF4L1WZasRrGxx1S27oYJlSphAigz01k | ||||
JeE46JNEbPrTLF+0NX2KHDKhTLfFMBRJI8YOqzTKBmOUWdS8i1V1VII8XnGt | ||||
VtttEtXZKrhqWWblwGugyRoVZOM+lmBPpv02Uj3FpKAZidLfkO7UxhXqE1VC | ||||
BCW7LRY0UWkAnUpVeea1KcbI8CEOmQfdLNqtGrwGj9XBbjIskIuA7DZWVhdH | ||||
KZEvncZlK88EiZIb4TE0irJW3GEgmk7oVrA8JldiP04jFd7h9OQISBJjA5uu | ||||
RWFYcqxAXdaQuwQ27UEFlWsxp2kDg0LSaB2z6WKgKxfAyZkswTBXIUNG9DaV | ||||
lUKkC7ksYoLobhdyJtpQpMQJ3hGGAYuper46SZBBaEWufRV5rDpXNIYJlZiU | ||||
bZN4hSBBZzngCqPkKZiuZYxiBQEZhEOWkVhEHOqVKpbKSspNdPALFb3WHfQu | ||||
VhG6/MhQwJ/gFWdwSW7CqsBE4iZW2Z9njDE+huqwuCMTF7T0weUeptnZWpWl | ||||
qn7E1ErNoRSZPPY6LapExfiFVsx47CoQr5pxAKCqFCJS8Jce6l7tvMmgBojt | ||||
2/adXGevrrNX19mr6+zVdfbqOnt1nb26zl5dZ6+us1fX2avr7NV19uo6e3Wd | ||||
vbrOXv1zslc/4rSHBqHBoHZdVhv58nna8F/dxl3KddomkNVN2tVxnjQIZaqz | ||||
S6rMaRsEnL92mw03rTY/1Y1lNTMT+xQ5guy3gvoOolJ3meu0NdY0itCm2nOq | ||||
E01MESFbjTZMKXwrstx6k2Q6bqh2BdKHmULmNQJtIM0bJlLEy9hM+ZBOJ06Y | ||||
xLfaQs8j0kKzUzK5WNOyhmXBkrHkzhgEQHawkQfrk85ijWObuLLDwCNxFjZQ | ||||
K9yc+pSlVXgYCwKf41LFJbAK4RQA61qLsLWFK5WaabrKeIkl4hJjCY2vbU3v | ||||
5VCHHUOYktZ2getY1xRWu91o0CujkzdNapPOMWbIt56I0XFtp93clrEkaeEt | ||||
OpqYlocaRB3NRetd09VeiRAn3zTpSqFAHKHOtrFpSu+LMm5lQrsaQNfG9FqE | ||||
r65ZJJfWBW59UVqrzIWOw1HwpyraPEotq1eXcSx3x5Qdpgu9quqmTevOoW08 | ||||
M61rnzhXWSAubwJLE50vjTfZkHxqsUHiZSkdj+l3he5nOmeoZKx53Tjv6YyR | ||||
9ilqazNft07HS7ki8lZMmk76JIkBk1wBQIskoM/e6WQcQPjq5JNgvzRp2B4e | ||||
ywi24WSRtrB0P0VE07hxKGatlyhUXaMjVbQxD+RhSeqm6mLEAjVvamgEFlph | ||||
clYzB48byLtHH3yuwyCymhZ0RI5tY227065UD7ESpyngZIhjlYBEia1TkAMj | ||||
AEAAUp22LlUhst2VdYStyUCtcCgRTBPy14SO1joyCTlrCyUg6RmDb8DcMqud | ||||
0+koNu9qw/+xfplNGmXGGlgtpiOGXuaxeAoKgA+PZGgNU/rcNbiewB6cxbWK | ||||
k2u7Z2SctmQB0+Hh2HKFqA2rpWQJuK5NSJDVgssKSKwD04BAWnAVaIaHHqWd | ||||
ZzhiddqiJge5CB4ewI8PEMMiveJJMZ929NfxYLie96V2MInF4n875aG0Y0wn | ||||
AjSJgsax8iPwBYv9FMMO50akMEJjfENvMC/aL9cmOHtRDU9C39NOnvel5BPQ | ||||
gJzBjLGv0BirVF2jpYZhNWkqv8oa6KlhqZzGHtVWkMBjc1M77dh0ttO5A0yU | ||||
wzyKZocdffQ5brUnWic4dNi/TMdSdSaJCogfF6EytbZ8AguFbVJvFYbEbHMH | ||||
tqlzRue4SDZjJw6dKD5Re6XMI5Y8rWwrKU10qFLjXRsDm3Vi8nAIEbLtFMoA | ||||
02kNGW00p1YJ27g2WDqAJ3barqz8ASa1Qm507IASEgGDlVZD+prE00logc44 | ||||
sYE+2bIB7aJEGffai2Y7UB86SYdRIG2FVzzfAxu+RVw1jKqtsgRr0SrQXutE | ||||
CIel025zr6R6bLD4Ih9pCK8maLortMmylefUaiMgUttabZrLtaO1Rilzra1H | ||||
cyt6jtFJZGsTnQJmS59grFDjPI5rkaa4MRok86vNiUympV8mKaNcPIw5myaf | ||||
fprli7amL0l8wpJqK18qGy6LXiq2E0tDkEupCsashuzBxHTmUNK1aaRjW4q6 | ||||
qdufnXzKFPpRbwtwqmI1mrpjBhMRR+yxUyQm4Scl3/HslSb3WYrNjMQA4a5N | ||||
mrcJDAfKBvWOsUWJ6B78Ke2wrwqSQVuAxZR2NCKL4QHTULhCB0fAX1BFTBJW | ||||
M3aJ9izCyxObWgw4vN9BFq2y3mmLcFsMDry10+kRqY8wcuhwmrRCH6ypQmgp | ||||
dE+LkHWwMkxh6ZGAGEuqDZo6xU3ywlKDOFBii/2GAOPJ8zFoYG3wNzxeDGIM | ||||
57OIG/5EihwIvCBtiCXXYMF0FkcHoW2N8rEd+In3kSpEr03RLstjJZvgVlXW | ||||
hFPeEuwSRBgy4BOMv2KuFldQR3OINMIFKoWltf21gKRU/JjCB2XGGaCF7joF | ||||
5jrIUQ7PaQqfyyw3OJPaA+91tEbZdTkCiQmmfZaDOc/qJMXfwhzhctTKGKPa | ||||
uXaba+c2HzXVWw8Kuk4+XSefrpNP18mn6+TTdfLpOvl0nXy6Tj5dJ5+uk0/X | ||||
yafr5NN18uk6+XSdfPqnJZ9+8vG8ja9Yg5YZFMNljUUWvEKCvi06kEOF5514 | ||||
c4Jr5RQjYoYT6VwXq1B9SEcBaIitVRkv8+vjDh4XWwtS1YqW+ZqBmtoIkOQ7 | ||||
KMbW1VUbuzqylnmpOkDBNA2PxiHqqsZBqNKus7IXcFbpdo2YGW2oaWOd2+3B | ||||
pqrGMETegYo1cl4zseL6kAGRT0aa6u0JPsQuaLnrAGGnqEBdddjGrrEeKpRG | ||||
pYnBQBE4wA5wwf4hCqAXpiFO5T+Ke8s3TH3Xlirix3dGW7WFo5VLoE0nHb0H | ||||
A0rVT7etRfIdLE0bCKCMWGpftY3RKxsQ7472mwZNEv1TliSyjklCQy3gxH+2 | ||||
VdKJvuokzw7Ln0KYMvROxkwBcL0goeftnaq+MxxdVU0jwCy4g0CmqJT22Ggv | ||||
HfpSSHu6nIY7jKpPwbW8RlBT1iLBXpfeRi6OC8+TjVE+x9IxUAdAkoULmy1A | ||||
HeACnKvrvG4MIlNWrTYAFW3pmcg+HWWxM23h4s6gLIzfx01T6OCzLvNAXold | ||||
pGsNxhjfxtE1VkmCA9xFsSsaRfUdRBOowUYkDYqIO9rFYtw41sZenY6KITiq | ||||
m2/BizRFjiobTjGNuwRPRmetxlUHl3KucVEeF67wDgBySYHsiBXpEToctTVY | ||||
UzyKWoiVpTpOvQM5UiDWIlyZRp5GUPG4LfXaF6Cg7ARP2u2GQISDB7GbqbOt | ||||
4VYQCjAFTNBkdLhVssB1Dn6UNcqUMC863bR2HhhEblKLcAjuPdNsMhC9KLwk | ||||
AtgqAOSq0Ul+wHNEW8rM4sg5HFcdsm51zLj2cWV1G7edYQJM5goMRm0bZjav | ||||
rDKcdSf6Is6elk0CW44RrrrWuZqN3jBSKbart5DEnbKq2I+iYzhNODBecWmd | ||||
WQj4NElkdZwis2+tBR4K24pVNFrenOswML6mu0ndldAU5rdIUBTMJJNWI86J | ||||
i3QsNUbC6xBjZwpgA33E4dEPCk7rIORGp16jDfAAW4IYDLKin3kCrqDAWPI6 | ||||
1fm0EO5L6ajUgR7W143tYHIpqglzUvYkvOEgyRAVq1hLXvgsrX3cRl6yolOi | ||||
c9t6b4pW27Dg8NrWkud4hrXHoLJqrbJMdAixa1B7Rt9h2bsu6lqUIinbpHMJ | ||||
38R6FwMoyXjqJm51Ejjg1QFtvjPOuFoKBEDjH+F7sEJJBOAltm4w/U2GgDRA | ||||
nDZ/WFu3hUU4MSQ+07sHmk4sv1UmutVrRRJsO+pVRvIqnINmQFQRXhwmm7U6 | ||||
N5zRtJmCg7FvE2W4nUi3TZFMpW5cowOm66SMEjHfpAWIkEbls+G3Lc4QY+S5 | ||||
udc+QMOswxFa+bNtlSBHDhXCjWmL1kVIfa4YWwfEYAatEZWFiLd14mJQqGkV | ||||
uYd34HRmPoY2AnrOogqoaW3zLHLoI/Yf5uRcjbcE6lo5uTqv0ifoWq5tuBaA | ||||
K7WdMfNN2MBSKBaAgLZdZBqDyFV+Jx31kyxftDV9OhvYK69u9H4T/m6RcPSb | ||||
3+ioYnd620onPxwfFBKkFwhVwAbgLIc0+9npqPD6FmQJQgiDLBg3+gucNtg5 | ||||
zBT0ttKBpCkmrdB5tuAB3U+aFtdOUy1tjg3SAVxqu6pi4k6bmkDqvgIAXOwY | ||||
gbdS5tz40oakae0j6L7eUATuN21TKBPgdZQ6HeDxDEI7hzsmlOmVx6UdpY1O | ||||
OM1QI+iQNZEkBdtfhvQjmmSU0mdcbYlo4Ml1LRxSK+FAjQoBsDrPNvF5Iu6o | ||||
I7AhUTrHGNKVmRT1rgoPWABzKU+QY56FvD06Dw/DiBZ1qs1/3mk/aqVDZZNw | ||||
ZjYAgt5ry5uy0TnmyspMVx1QZWWpcD3bRhQtE8q3zEnBFCsnGlmksqz1gpwK | ||||
UHJ4qHDjRueaAqDKtytk4kGAxCWYX+sKi3inYjgofWnqqM2cr71eKwJGmcQ4 | ||||
RBk5wVXslCbMYDpd0YhNVHqnRoypgq7UHVKDUWNe33qy+3U66joddZ2Ouk5H | ||||
XaejrtNR1+mo63TUdTrqOh11nY66Tkddp6Ou01HX6ajrdNQ/by/U5v1Cgjbj | ||||
86SzlUf+VMDMFCmn4BR+53NIXKy36Di9ULWq9T5GmdlYr5OW99znl+JGh2tV | ||||
ekuel1wUteu6wsqFY17hGTrWqgYjUjzjxNikURQf82wjWZxClb22ZH5ZJeYx | ||||
zlrgwGPSlEMprXzgqmhTpqwT1bQidLXDQeFJkZRAr/l0ekWi+DeSrFfVxE2h | ||||
N7olqW2QegREL3lDM/Q6t1Ivds26VhHxNGq9SoxVY52Flz+KvSMSzAz4Wndp | ||||
UuNTJA5ZYRJoEkCpkY229E6Jq7iKGp/qHVxQpcwWzEGuVwgySy1GFvXRO6H1 | ||||
KhyTxM4avQe+w7jRSuPSyuLgxpE8OuRfWxjAkqxSLTdigf1OupY5i2O8VXTH | ||||
V07HXcFJtLlMe6Pon9eWqwYuySe5ThcqjbHovGKUMng5a4WadB1c3DNKdA7H | ||||
0xhgRq6jcDXOfKRjvWJZOVtJF12lYK/RWzu1TQtoc0aC2rJQmWnRzVoxngrw | ||||
1vt2unG7U94w4Shvl7SdXvRdtHWa1gY5TpllVihpnLJtznR60SJYBibRru3i | ||||
KAd6tKNCL4ZqXFswyXCwDv6U8QhgDTNy1dv1UoYiT5OfKgvclWnc1To/Skf1 | ||||
NSZpauSt1puPa8ykjxrZH71UXi+JYkH09jy9Xtpo95lNEgfZN9q6Ju9aTLTG | ||||
XGUtqoVqyDuLZC2VmSsUXc9rGB9IA4gADni0cXhrpo63k4wolQD8dZnesakw | ||||
o+6MWO0CyQUV00wZ0FLqq81sZanj9fIYPzezeq1Trtdqx22joE+u16RXokMl | ||||
FLpNQBbnlQXUliyoO8wIuGnRX9h/U3uf6XA8mBG/IeWAT9bo3EthCoSnEoIX | ||||
sSxCWmipkOBSWz/wPOsk1elxaRIzjcqhlbn2VbnMKlNqMkAMxzCWVuHddAIQ | ||||
HuKstnYx1UokuLZzlfY66o2bqHISK7fUxc4hx75KGvqA6QRdfaJQnA7D64Ka | ||||
N843iEjaKLxf1jIlNVKpgA5ul96nhn/uEOG2jmKGXjE/lVq8lF9SpLfskCGQ | ||||
omuRxFQAhB1FLFDqUjkgZMCYWg5D3rVR13StV366UNJTr61H4H3nnI07vdA4 | ||||
axMsmfY/VAnobLI8vHK+0dY9GBd90M5MAU+S2K6Rb1cqy5bJ/uSVNvuwEppR | ||||
mfIYNxO16EzBmHO9FRtxifpdMl6+jbJ0OqCQx2oFC7032bvWJwpnt7WPtSMo | ||||
zQwkHdIVd/wG6Y1Q7hgXjSuz0nY6Js0U2MZw8l8L/y3LFP8ISuvqSq+XxE6D | ||||
yh2aiZOSQNtpQe+Na3R0ZydfWBsCtenC+lr2PNcmQ+dkFQPVhFyVrW0xh0lD | ||||
g533EW64l9x5pdu6cHojVAVrGuv9y6X3cYrTp7BahXzAaLHhVk54VrM4po4j | ||||
JT4VztbLR1tt/TDwbKDDGJO5VjY2D4NgiiwAqRluMOpYVTmWsSuivJXY1Xaa | ||||
X/ppli/amj7cUu3YarWFs+j0frOQK4I9GT7GfmvbkFJdlXJesJocK2CbCOuo | ||||
XT3m55+1Z7CV/bu100b7b6GdyibWVZtVeDsd/L9MrJKCsXIkzAU8DahJIkGl | ||||
XIra6Y3HIgwOlgaOF21nVJdRdSnGyuocRAM/6rT9sLWqEkBz0jaW0ndSJJwg | ||||
7qdpnaEqXEiQKhPIgEK1DpYtsNdLEFvEC1RWeNL5WBUZGOxW73GvpGCgZprk | ||||
kGRlWFqXwnOcXs+JYKEldazKE6OzKY1eRcp0Rqk2WNmw89gbbc7CzWNe8iSR | ||||
cdcbgq1OqlQoSsf7aksaZlSBcyxuqZd+6sWPDRrs48xYsYW0qGkebxyhciAv | ||||
xhh91iuNsUtoPGxSQtWxEgmuI55WjTGsm0TC4FUDofCK4mUYR9OEV4UinC5p | ||||
tatPb1BXrKUV1udw5zp1EXKNgU1KBAymXSudVGEOGpPn4WW7Ts5aCRTSnAyB | ||||
wy9F6grcHkUL7eX8UnGdX7rOL13nl67zS9f5pev80nV+6Tq/dJ1fus4vXeeX | ||||
rvNL1/ml6/zSdX7pOr/0r/+mqE2CyiTG1C2E2epEOlM7nbOVKRiTd4o8pmnl | ||||
kNZS2QMV91ZtGasknkE75XDGBJVxmI/U67VFSdskTsFcsT5r08zBkhLTZixX | ||||
7GqV9rZt55OwKyqpo05BWvlDqGcLcOtAs7poUwU5GxkL8LxGjFzaJUmt7S95 | ||||
i3gVzugNPLm1kYlzvdmngw12jUVGaNh52CeTwkRg7FkMp/dA8WxtrFIGK6VP | ||||
HuPOJZiuVOLBc5FZo7dB6a0lgDlNtVgQfq7F33SiVKXDwmJrq6RD+GO9yqVp | ||||
0yh3NYOrlZWJgUGFTm04n891RhqEAWHC4rahl4nVyV8pE1UgliHykWaRbRJL | ||||
N/CZECSwR7u8tC8EZWPlxVyQ/yTGLtVdXQV3FNPQ6byvEnXwSQSGu9q3nQqs | ||||
c8xBGgfn1hcsOkInLi0GT09bV1iso5U7qT1nNZIC8YjCJgnNKaMKW5D4vnHW | ||||
WaasM5C+JIFOdoiLthQBVGWs48V00hJd6trxZVC0DjjF1tclXQIx8krOKh/E | ||||
LE6OFIJcXIQbosp25aqKTmcTer3ho2n//9LOJMluHAaie52GgwbyOByPUWfv | ||||
99gLhzt6ZW8roiSRBDITxAeQxzdRQfVxFBTus+deVR8weoXS/j9B5YWdQ5AS | ||||
kNa9+eQNnZdBi8iMaGOwyEbm0iqGm6pzPOrKXy8On/lA6OqV804Pb6+QDY8g | ||||
drAAq4EVxiEmtzi6Xnu7RuzOLWt9gCihfhtOAB9mLRukn311iHLkvgDEUEff | ||||
Fs08NuhKjkopHe/jX+9NNPsutmk4kEmNkfbEsGK0CiXcMN7dTztEmSnZdO7e | ||||
Xr27W2vyqAyyA+fIw1OwtpfqfTsIaxD2puk9SjftRCwPgWDdmBriv51RTnji | ||||
GoEDh/Vi5QNQDXtkoouoNXvb8H0dz+peb42VQeyed45rOpboytP0qPULDqx6 | ||||
kFFjIYlzRAc6iez05mxBr/K6GJ5x9Ni99vOao/7qhbpdajlrJlY+Mtzr10Lw | ||||
mCGYwsqqlS/QSJ8KR0wF48HsWmLJz7oq4Lw98mpB1X8TVJ4u4jj82xBUmls6 | ||||
uSRhRm7VwTbm8wRJuqIKVreMs0xgpUJKeAPfe3Y+fGM2k9T+900AbfHXBO1L | ||||
2T3ZPBHZUi7Y2b6CPBFtymcmxCEeDwM7G6ZgX7ufso4SMygZzPXyFHzVuUN8 | ||||
zAWcJdwFSwHIewD4WblWPorxTQpIUDtyJsACQx7OBbIWA158vRl4r+YbWGUd | ||||
xcM3l4TqxTy8d3yO3jUFa5KNVaaJDEzn/sJiNusNL47E8XCcNqrMXDZ6BLo9 | ||||
rfVY9/3MXddyW3DLYmoDARnrinKALUyB1jhN8SzPncjYPov93EhXgmoCybbW | ||||
t3pYG5+PtmqtjjZq4BBiZ+92vd86P0sgRoVVyvaeOKOCtvN07D1p2SOIjrNa | ||||
ZtTt45iGefp3VtM3MHIkgB7vb8Og/oj5rl/U1zmXMnYcz6mlIkR4WKCTpIKl | ||||
tu/Jm6GWJ3wRdzT5jBqfF7Ieh0bW/3WCKkFXeATrfQz8Pz4TqctuupUpE3yb | ||||
SOYrrEBKIEwvZZmLuSrAGPl2K7Qmz3zEMqiS/39afVtGmyMgHVpI0LCzJVH+ | ||||
AuBZOPJYhEmrpnsD2HaGzA7VmqisUIb1nXDJKkSNFl01CARDMbGK2VZFlImz | ||||
b1zjbeY0xgGpczlvW0fWFIYquHG2CLZtg9g94QLnkaGHgJC5HYsXL/wYmRCe | ||||
3W5At0JDaWGqXnMvZ7wVALWZGHst+ZvTCImgC1MAVDkRABi+SEVKY585HguY | ||||
2EE8XzdMN6hO6FTDbBsPCv5cAOmfUvEXK/XM8/ts1vj2LiSgTZ1D6Ni/FR13 | ||||
uRNLJAgYu8Aig1Brvtv5bXgw/AY4lks9IrqXAYPyOh5NHND56+uUqMwS0THs | ||||
QK521gyYw7dPFG57141y+Pn5uf4Be1fRwvQ5AQA= | ||||
<!-- [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. | ||||
Note that our script did not flag any words in particular, but this | ||||
should still be reviewed as a best practice. --> | ||||
<!-- [rfced] Please let us know if any changes are needed for the | ||||
following: | ||||
a) The following terms were used inconsistently in this document. | ||||
We chose to use the latter forms. Please let us know any objections. | ||||
Issuance protocol (1 instance) / issuance protocol (25 instances) | ||||
(also per the rest of Cluster 450) | ||||
Issuer URL (1 instance) / Issuer Request URL | ||||
Token Type / token type (per Section 6.5 and the rest of | ||||
Cluster 450) | ||||
VOPRF (P-384, SHA-384) / VOPRF(P-384, SHA-384) (spacing) | ||||
b) The following terms appear to be used inconsistently in this | ||||
document. Please let us know which form is preferred. | ||||
Blind RSA (2048-bit) / Blind RSA, 2048 | ||||
token-type field (Table 2) / Token type field (comments in | ||||
Sections 5.1 and 6.1) | ||||
c) Is "SubjectPublicKeyInfo" correct in these sentences, or whould it be | ||||
updated to "Subject Public Key Info"? We see both forms in RFC 5280 (but not | ||||
"SPKI"). In recent RFCs, SPKI has been expanded as "Subject Public Key Info". | ||||
Original: | ||||
...where encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) | ||||
object carrying pkI as a DER-encoded RSAPublicKey value [RFC5756] in | ||||
the subjectPublicKey field. | ||||
... | ||||
* Token Key Encoding: Serialized as a DER-encoded | ||||
SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID | ||||
[RFC5756] | ||||
--> | --> | |||
</rfc> | </rfc> | |||
End of changes. 162 change blocks. | ||||
1353 lines changed or deleted | 1020 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |