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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?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&nbsp;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 &lt;https://issuer.example.net/request&gt;.</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 &quot;token-keys&quot; 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. &nbsp;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. &nbsp;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. &nbsp;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&nbsp;<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. &nbsp;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. &nbsp;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&nbsp;<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 &quot;private-token-issuer-directory&quot; 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>&quot;private-token-issuer-directory&quot; 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 &amp; 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 &amp; 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 &amp; 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>&lt;jats:p /&gt;</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.