rfc9474.original.xml   rfc9474.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.36 (Ruby 3.2. 2) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.36 (Ruby 3.2. 2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-irtf-cfrg-rsa-blind-signatures-14" category="info" tocInclude="true" sortRefs=" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
true" symRefs="true" version="3"> -irtf-cfrg-rsa-blind-signatures-14" number="9474" submissionType="IRTF" category
="info" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" update
s="" obsoletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 --> <!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="RSA Blind Signatures">RSA Blind Signatures</title> <title abbrev="RSA Blind Signatures">RSA Blind Signatures</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-rsa-blind-signature s-14"/> <seriesInfo name="RFC" value="9474"/>
<author initials="F." surname="Denis" fullname="Frank Denis"> <author initials="F." surname="Denis" fullname="Frank Denis">
<organization>Fastly Inc.</organization> <organization>Fastly Inc.</organization>
<address> <address>
<email>fd@00f.net</email> <email>fd@00f.net</email>
</address> </address>
</author> </author>
<author initials="F." surname="Jacobs" fullname="Frederic Jacobs"> <author initials="F." surname="Jacobs" fullname="Frederic Jacobs">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<email>frederic.jacobs@apple.com</email> <email>frederic.jacobs@apple.com</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2023" month="July" day="10"/> <date year="2023" month="October"/>
<keyword>Internet-Draft</keyword> <workgroup>Crypto Forum</workgroup>
<keyword>RSABSSA</keyword>
<keyword>RSA</keyword>
<keyword>blind signature</keyword>
<abstract> <abstract>
<?line 139?>
<t>This document specifies an RSA-based blind signature protocol. RSA blind sign atures were first <t>This document specifies an RSA-based blind signature protocol. RSA blind sign atures were first
introduced by Chaum for untraceable payments. A signature that is output from th is introduced by Chaum for untraceable payments. A signature that is output from th is
protocol can be verified as an RSA-PSS signature.</t> protocol can be verified as an RSA-PSS signature.</t>
<t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t> <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/chris-wood/draft-wood-cfrg-blind-signatures"/
>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 147?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Originally introduced in the context of digital cash systems by Chaum <t>Originally introduced in the context of digital cash systems by Chaum
for untraceable payments <xref target="Chaum83"/>, RSA blind signatures turned o ut to have for untraceable payments <xref target="Chaum83"/>, RSA blind signatures turned o ut to have
a wide range of applications ranging from privacy-preserving digital payments to a wide range of applications ranging from privacy-preserving digital payments to
authentication mechanisms <xref target="GoogleVPN"/> <xref target="ApplePrivateR elay"/> <xref target="PrettyGoodPhonePrivacy"/>.</t> authentication mechanisms <xref target="GoogleVPN"/> <xref target="ApplePrivateR elay"/> <xref target="PrettyGoodPhonePrivacy"/>.</t>
<t>Recently, interest in blind signatures has grown to address operational shortcomings from applications <t>Recently, interest in blind signatures has grown to address operational shortcomings from applications
that use Verifiable Oblivious Pseudorandom Functions (VOPRFs) <xref target="VOPR that use Verifiable Oblivious Pseudorandom Functions (VOPRFs) <xref target="I-D.
F"/>, such irtf-cfrg-voprf"/>, such
as Privacy Pass <xref target="PRIVACY-PASS"/>. Specifically, VOPRFs are not nece as Privacy Pass <xref target="I-D.ietf-privacypass-protocol"/>. Specifically, VO
ssarily PRFs are not necessarily
publicly verifiable, meaning that a verifier needs access to the VOPRF private k ey to verify publicly verifiable, meaning that a verifier needs access to the VOPRF private k ey to verify
that the output of a VOPRF protocol is valid for a given input. This limitation complicates that the output of a VOPRF protocol is valid for a given input. This limitation complicates
deployments where it is not desirable to distribute private keys to entities per forming verification. deployments where it is not desirable to distribute private keys to entities per forming verification.
Additionally, if the private key is kept in a Hardware Security Module, the numb er of operations Additionally, if the private key is kept in a Hardware Security Module, the numb er of operations
on the key is doubled compared to a scheme where only the public key is required for verification.</t> on the key is doubled compared to a scheme where only the public key is required for verification.</t>
<t>In contrast, digital signatures provide a primitive that is publicly ve rifiable and does not <t>In contrast, digital signatures provide a primitive that is publicly ve rifiable and does not
require access to the private key for verification. Moreover, <xref target="JKK1 4"/> shows that one can realize require access to the private key for verification. Moreover, <xref target="JKK1 4"/> shows that one can realize
a VOPRF in the Random Oracle Model by hashing a signature-message pair, where th e signature is a VOPRF in the random oracle model by hashing a (message, signature) pair, where the signature is
computed using a deterministic blind signature protocol.</t> computed using a deterministic blind signature protocol.</t>
<t>This document specifies a protocol for computing RSA blind signatures u <t>This document specifies (1) a protocol for computing RSA blind signatur
sing RSA-PSS encoding, es using RSA-PSS encoding
and a family of variants for this protocol, denoted RSABSSA (RSA Blind Signature and (2)&nbsp;a family of variants (<xref target="rsabssa"/>) for this protocol,
with Appendix). denoted RSABSSA (RSA Blind Signature with Appendix).
In order to facilitate deployment, it is defined in such a way that the resultin g (unblinded) In order to facilitate deployment, it is defined in such a way that the resultin g (unblinded)
signature can be verified with a standard RSA-PSS library.</t> signature can be verified with a standard RSA-PSS library.</t>
<t>This document represents the consensus of the Crypto Forum Research Gro up (CFRG). It is <t>This document represents the consensus of the Crypto Forum Research Gro up (CFRG). It is
not an IETF product and is not a standard.</t> not an IETF product and is not a standard.</t>
</section> </section>
<section anchor="requirements-notation"> <section anchor="requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</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. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<?line -6?> are to be interpreted as described in BCP&nbsp;14
</t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="notation"> <section anchor="notation">
<name>Notation</name> <name>Notation</name>
<t>The following terms are used throughout this document to describe the p <t>The following terms, which describe different protocol operations, are
rotocol operations used throughout this document:</t>
in this document:</t> <dl spacing="normal">
<ul spacing="normal"> <dt>bytes_to_int and int_to_bytes:</dt><dd>Convert a byte string to and
<li>bytes_to_int and int_to_bytes: Convert a byte string to and from a n from a non-negative integer. &nbsp;bytes_to_int and int_to_bytes are implemented
on-negative integer. as OS2IP and I2OSP -- as described in
bytes_to_int and int_to_bytes are implemented as OS2IP and I2OSP as described in <xref target="RFC8017"/> -- respectively. Note that these functions operate on b
<xref target="RFC8017"/>, respectively. Note that these functions operate on byt yte strings
e strings in big-endian byte order.</dd>
in big-endian byte order.</li> <dt>random_integer_uniform(M, N):</dt><dd>Generate a random, uniformly d
<li>random_integer_uniform(M, N): Generate a random, uniformly distribut istributed integer R
ed integer R between M inclusive and N exclusive, i.e., M &lt;= R &lt; N.</dd>
between M inclusive and N exclusive, i.e., M &lt;= R &lt; N.</li> <dt>bit_len(n):</dt><dd>Compute the minimum number of bits needed to rep
<li>bit_len(n): Compute the minimum number of bits needed to represent t resent the positive integer n.</dd>
he positive integer n.</li> <dt>inverse_mod(x, n):</dt><dd>Compute the multiplicative inverse of x m
<li>inverse_mod(x, n): Compute the multiplicative inverse of x mod n or od n or fail if x and n are not co-prime.</dd>
fail if x and n are not co-prime.</li> <dt>is_coprime(x, n):</dt><dd>Return true if x and n are co-prime, and f
<li>is_coprime(x, n): Return true if x and n are co-prime, and false oth alse otherwise.</dd>
erwise.</li> <dt>len(s):</dt><dd>The length of a byte string, in bytes.</dd>
<li>len(s): The length of a byte string, in bytes.</li> <dt>random(n):</dt><dd>Generate n random bytes using a cryptographically
<li>random(n): Generate n random bytes using a cryptographically-secure secure random number generator.</dd>
random number generator.</li> <dt>concat(x0, ..., xN):</dt><dd>Concatenation of byte strings. For exam
<li>concat(x0, ..., xN): Concatenation of byte strings. For example, ple,
concat(0x01, 0x0203, 0x040506) = 0x010203040506.</li> concat(0x01, 0x0203, 0x040506) = 0x010203040506.</dd>
<li>slice(x, i, j): Return bytes in the byte string <tt>x</tt> starting <dt>slice(x, i, j):</dt><dd>Return bytes in the byte string <tt>x</tt> s
from offset <tt>i</tt> and ending at tarting from offset <tt>i</tt> and ending at
offset <tt>j</tt>, inclusive. For example, slice(0x010203040506, 1, 5) = 0x02030 offset <tt>j</tt>, inclusive. For example, slice(0x010203040506, 1, 5) = 0x02030
40506.</li> 40506.</dd>
</ul> </dl>
</section> </section>
<section anchor="core-protocol"> <section anchor="core-protocol">
<name>Blind Signature Protocol</name> <name>Blind Signature Protocol</name>
<t>The RSA Blind Signature Protocol is a two-party protocol between a clie nt and server <t>The RSA Blind Signature Protocol is a two-party protocol between a clie nt and server
where they interact to compute <tt>sig = Sign(sk, input_msg)</tt>, where <tt>inp ut_msg = Prepare(msg)</tt> where they interact to compute <tt>sig = Sign(sk, input_msg)</tt>, where <tt>inp ut_msg = Prepare(msg)</tt>
is a prepared version of the private message <tt>msg</tt> provided by the client , and <tt>sk</tt> is the is a prepared version of the private message <tt>msg</tt> provided by the client , and <tt>sk</tt> is the
private signing key provided by the server. See <xref target="cert-oid"/> for de tails on how <tt>sk</tt> is generated private signing key provided by the server. See <xref target="cert-oid"/> for de tails on how <tt>sk</tt> is generated
and used in this protocol. Upon completion of this protocol, the server learns n othing, and used in this protocol. Upon completion of this protocol, the server learns n othing,
whereas the client learns <tt>sig</tt>. In particular, this means the server lea rns nothing of <tt>msg</tt> whereas the client learns <tt>sig</tt>. In particular, this means the server lea rns nothing of <tt>msg</tt>
or <tt>input_msg</tt> and the client learns nothing of <tt>sk</tt>.</t> or <tt>input_msg</tt> and the client learns nothing of <tt>sk</tt>.</t>
<t>The protocol consists of four functions -- Prepare, Blind, BlindSign, a nd Finalize -- and requires <t>The protocol consists of four functions -- Prepare, Blind, BlindSign, a nd Finalize -- and requires
one round of interaction between client and server. Let <tt>msg</tt> be the clie nt's private input one round of interaction between client and server. Let <tt>msg</tt> be the clie nt's private input
message, and <tt>(sk, pk)</tt> be the server's private and public key pair.</t> message, and let <tt>(sk, pk)</tt> be the server's private and public key pair.< /t>
<t>The protocol begins by the client preparing the message to be signed by computing:</t> <t>The protocol begins by the client preparing the message to be signed by computing:</t>
<artwork><![CDATA[ <artwork><![CDATA[
input_msg = Prepare(msg) input_msg = Prepare(msg)
]]></artwork> ]]></artwork>
<t>The client then initiates the blind signature protocol by computing:</t > <t>The client then initiates the blind signature protocol by computing:</t >
<artwork><![CDATA[ <artwork><![CDATA[
blinded_msg, inv = Blind(pk, input_msg) blinded_msg, inv = Blind(pk, input_msg)
]]></artwork> ]]></artwork>
<t>The client then sends <tt>blinded_msg</tt> to the server, which then pr ocesses the message <t>The client then sends <tt>blinded_msg</tt> to the server, which then pr ocesses the message
by computing:</t> by computing:</t>
skipping to change at line 143 skipping to change at line 143
]]></artwork> ]]></artwork>
<t>The server then sends <tt>blind_sig</tt> to the client, which then fina lizes the protocol by computing:</t> <t>The server then sends <tt>blind_sig</tt> to the client, which then fina lizes the protocol by computing:</t>
<artwork><![CDATA[ <artwork><![CDATA[
sig = Finalize(pk, input_msg, blind_sig, inv) sig = Finalize(pk, input_msg, blind_sig, inv)
]]></artwork> ]]></artwork>
<t>The output of the protocol is <tt>input_msg</tt> and <tt>sig</tt>. Upon completion, correctness requires that <t>The output of the protocol is <tt>input_msg</tt> and <tt>sig</tt>. Upon completion, correctness requires that
clients can verify signature <tt>sig</tt> over the prepared message <tt>input_ms g</tt> using the server clients can verify signature <tt>sig</tt> over the prepared message <tt>input_ms g</tt> using the server
public key <tt>pk</tt> by invoking the RSASSA-PSS-VERIFY routine defined in public key <tt>pk</tt> by invoking the RSASSA-PSS-VERIFY routine defined in
<xref section="8.1.2" sectionFormat="of" target="RFC8017"/>. The Finalize functi on performs this check before returning the signature. <xref section="8.1.2" sectionFormat="of" target="RFC8017"/>. The Finalize functi on performs this check before returning the signature.
See <xref target="verification"/> for more details about verifying signatures pr oduced through this protocol.</t> See <xref target="verification"/> for more details about verifying signatures pr oduced through this protocol.</t>
<t>In pictures, the protocol runs as follows:</t> <t>Shown graphically, the protocol runs as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Client(pk, msg) Server(sk, pk) Client(pk, msg) Server(sk, pk)
----------------------------------------------------- -----------------------------------------------------
input_msg = Prepare(msg) input_msg = Prepare(msg)
blinded_msg, inv = Blind(pk, input_msg) blinded_msg, inv = Blind(pk, input_msg)
blinded_msg blinded_msg
----------> ---------->
blind_sig = BlindSign(sk, blinded_msg) blind_sig = BlindSign(sk, blinded_msg)
skipping to change at line 166 skipping to change at line 166
<---------- <----------
sig = Finalize(pk, input_msg, blind_sig, inv) sig = Finalize(pk, input_msg, blind_sig, inv)
]]></artwork> ]]></artwork>
<t>In the remainder of this section, we specify the Prepare, Blind, BlindS ign, and Finalize <t>In the remainder of this section, we specify the Prepare, Blind, BlindS ign, and Finalize
functions that are used in this protocol.</t> functions that are used in this protocol.</t>
<section anchor="randomization"> <section anchor="randomization">
<name>Prepare</name> <name>Prepare</name>
<t>Message preparation, denoted by the Prepare function, is the process by which the message <t>Message preparation, denoted by the Prepare function, is the process by which the message
to be signed and verified is prepared for input to the blind signing protocol. to be signed and verified is prepared for input to the blind signing protocol.
There are two types of preparation functions: an identity preparation function, There are two types of preparation functions: an identity preparation function
and a randomized preparation function. The identity preparation function returns and a randomized preparation function. The identity preparation function returns
the input message without transformation, i.e., <tt>msg = PrepareIdentity(msg)</ tt>.</t> the input message without transformation, i.e., <tt>msg = PrepareIdentity(msg)</ tt>.</t>
<t>The randomized preparation function augments the input message with f resh randomness. <t>The randomized preparation function augments the input message with f resh randomness.
We denote this process by the function <tt>PrepareRandomize(msg)</tt>, which tak es as input a message We denote this process by the function <tt>PrepareRandomize(msg)</tt>, which tak es as input a message
<tt>msg</tt> and produces a randomized message <tt>input_msg</tt>. Its implement ation is shown below.</t> <tt>msg</tt> and produces a randomized message <tt>input_msg</tt>. Its implement ation is shown below.</t>
<artwork><![CDATA[ <sourcecode name="" type="pseudocode"><![CDATA[
PrepareRandomize(msg) PrepareRandomize(msg)
Inputs: Inputs:
- msg, message to be signed, a byte string - msg, message to be signed, a byte string
Outputs: Outputs:
- input_msg, a byte string that is 32 bytes longer than msg - input_msg, a byte string that is 32 bytes longer than msg
Steps: Steps:
1. msg_prefix = random(32) 1. msg_prefix = random(32)
2. input_msg = concat(msg_prefix, msg) 2. input_msg = concat(msg_prefix, msg)
3. output input_msg 3. output input_msg
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="blind"> <section anchor="blind">
<name>Blind</name> <name>Blind</name>
<t>The Blind function encodes an input message and blinds it with the se rver's public <t>The Blind function encodes an input message and blinds it with the se rver's public
key. It outputs the blinded message to be sent to the server, encoded as a byte string, key. It outputs the blinded message to be sent to the server, encoded as a byte string,
and the corresponding inverse, an integer. RSAVP1 and EMSA-PSS-ENCODE are as def ined in and the corresponding inverse, an integer. RSAVP1 and EMSA-PSS-ENCODE are as def ined in
Sections <xref target="RFC8017" section="5.2.2" sectionFormat="bare"/> and <xref Sections&nbsp;<xref target="RFC8017" section="5.2.2" sectionFormat="bare"/> and
target="RFC8017" section="9.1.1" sectionFormat="bare"/> of <xref target="RFC801 <xref target="RFC8017" section="9.1.1" sectionFormat="bare"/> of <xref target="R
7"/>, respectively.</t> FC8017"/>, respectively.</t>
<t>If this function fails with an "blinding error" error, implementation <t>If this function fails with a "blinding error" error, implementations
s SHOULD retry <bcp14>SHOULD</bcp14> try
the function again. The probability of one or more such errors in sequence is ne gligible. the function again. The probability of one or more such errors in sequence is ne gligible.
This function can also fail with an "invalid input" error, which indicates that one of This function can also fail with an "invalid input" error, which indicates that one of
the inputs (likely the public key) was invalid. Implementations SHOULD update th e public the inputs (likely the public key) was invalid. Implementations <bcp14>SHOULD</b cp14> update the public
key before calling this function again. See <xref target="errors"/> for more inf ormation about key before calling this function again. See <xref target="errors"/> for more inf ormation about
dealing with such errors.</t> dealing with such errors.</t>
<t>Note that this function invokes RSAVP1, which is defined to throw an optional error <t>Note that this function invokes RSAVP1, which is defined to throw an optional error
for invalid inputs. However, this error cannot occur based on how RSAVP1 is invo ked, for invalid inputs. However, this error cannot occur based on how RSAVP1 is invo ked,
so this error is not included in the list of errors for Blind.</t> so this error is not included in the list of errors for Blind.</t>
<artwork><![CDATA[ <sourcecode name="" type="pseudocode"><![CDATA[
Blind(pk, msg) Blind(pk, msg)
Parameters: Parameters:
- modulus_len, the length in bytes of the RSA modulus n - modulus_len, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message - Hash, the hash function used to hash the message
- MGF, the mask generation function - MGF, the mask generation function
- salt_len, the length in bytes of the salt (denoted sLen in RFC8017) - salt_len, the length in bytes of the salt (denoted sLen
in RFC 8017)
Inputs: Inputs:
- pk, server public key (n, e) - pk, server public key (n, e)
- msg, message to be signed, a byte string - msg, message to be signed, a byte string
Outputs: Outputs:
- blinded_msg, a byte string of length modulus_len - blinded_msg, a byte string of length modulus_len
- inv, an integer used to unblind the signature in Finalize - inv, an integer used to unblind the signature in Finalize
Errors: Errors:
- "message too long": Raised when the input message is too long (raised by EMSA- - "message too long": Raised when the input message is too long
PSS-ENCODE). (raised by EMSA-PSS-ENCODE)
- "encoding error": Raised when the input message fails encoding (raised by EMSA - "encoding error": Raised when the input message fails encoding
-PSS-ENCODE). (raised by EMSA-PSS-ENCODE)
- "blinding error": Raised when the inverse of r cannot be found. - "blinding error": Raised when the inverse of r cannot be found
- "invalid input": Raised when the message is not co-prime with n. - "invalid input": Raised when the message is not co-prime with n
"invalid input": Raised when the message is not co-prime with <span class="inse rt">n</span>
Steps: Steps:
1. encoded_msg = EMSA-PSS-ENCODE(msg, bit_len(n)) 1. encoded_msg = EMSA-PSS-ENCODE(msg, bit_len(n))
with Hash, MGF, and salt_len as defined in the parameters with Hash, MGF, and salt_len as defined in the parameters
2. If EMSA-PSS-ENCODE raises an error, raise the error and stop 2. If EMSA-PSS-ENCODE raises an error, re-raise the error and stop
3. m = bytes_to_int(encoded_msg) 3. m = bytes_to_int(encoded_msg)
4. c = is_coprime(m, n) 4. c = is_coprime(m, n)
5. If c is false, raise an "invalid input" error 5. If c is false, raise an "invalid input" error and stop
and stop
6. r = random_integer_uniform(1, n) 6. r = random_integer_uniform(1, n)
7. inv = inverse_mod(r, n) 7. inv = inverse_mod(r, n)
8. If inverse_mod fails, raise an "blinding error" error 8. If inverse_mod fails, raise a "blinding error" error and stop
and stop
9. x = RSAVP1(pk, r) 9. x = RSAVP1(pk, r)
10. z = (m * x) mod n 10. z = (m * x) mod n
11. blinded_msg = int_to_bytes(z, modulus_len) 11. blinded_msg = int_to_bytes(z, modulus_len)
12. output blinded_msg, inv 12. output blinded_msg, inv
]]></artwork> ]]></sourcecode>
<t>The blinding factor r MUST be randomly chosen from a uniform distribu <t>The blinding factor r <bcp14>MUST</bcp14> be randomly chosen from a u
tion. niform distribution.
This is typically done via rejection sampling.</t> This is typically done via rejection sampling.</t>
</section> </section>
<section anchor="blindsign"> <section anchor="blindsign">
<name>BlindSign</name> <name>BlindSign</name>
<t>BlindSign performs the RSA private key operation on the client's <t>BlindSign performs the RSA private key operation on the client's
blinded message input and returns the output encoded as a byte string. blinded message input and returns the output encoded as a byte string.
RSASP1 is as defined in <xref section="5.2.1" sectionFormat="of" target="RFC8017 "/>.</t> RSASP1 is as defined in <xref section="5.2.1" sectionFormat="of" target="RFC8017 "/>.</t>
<artwork><![CDATA[ <sourcecode name="" type="pseudocode"><![CDATA[
BlindSign(sk, blinded_msg) BlindSign(sk, blinded_msg)
Parameters: Parameters:
- modulus_len, the length in bytes of the RSA modulus n - modulus_len, the length in bytes of the RSA modulus n
Inputs: Inputs:
- sk, server private key - sk, server private key
- blinded_msg, encoded and blinded message to be signed, a - blinded_msg, encoded and blinded message to be signed, a
byte string byte string
Outputs: Outputs:
- blind_sig, a byte string of length modulus_len - blind_sig, a byte string of length modulus_len
Errors: Errors:
- "signing failure": Raised when the signing operation fails - "signing failure": Raised when the signing operation fails
- "message representative out of range": Raised when the message representative - "message representative out of range": Raised when the
to sign is not an integer between 0 and n - 1 (raised by RSASP1) message representative to sign is not an integer between 0
and n - 1 (raised by RSASP1)
Steps: Steps:
1. m = bytes_to_int(blinded_msg) 1. m = bytes_to_int(blinded_msg)
2. s = RSASP1(sk, m) 2. s = RSASP1(sk, m)
3. m' = RSAVP1(pk, s) 3. m' = RSAVP1(pk, s)
4. If m != m', raise "signing failure" and stop 4. If m != m', raise a "signing failure" error and stop
5. blind_sig = int_to_bytes(s, modulus_len) 5. blind_sig = int_to_bytes(s, modulus_len)
6. output blind_sig 6. output blind_sig
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="finalize"> <section anchor="finalize">
<name>Finalize</name> <name>Finalize</name>
<t>Finalize validates the server's response, unblinds the message <t>Finalize validates the server's response, unblinds the message
to produce a signature, verifies it for correctness, and outputs the signature to produce a signature, verifies it for correctness, and outputs the signature
upon success. Note that this function will internally hash the input message upon success. Note that this function will internally hash the input message
as is done in Blind.</t> as is done in Blind.</t>
<artwork><![CDATA[ <sourcecode name="" type="pseudocode"><![CDATA[
Finalize(pk, msg, blind_sig, inv) Finalize(pk, msg, blind_sig, inv)
Parameters: Parameters:
- modulus_len, the length in bytes of the RSA modulus n - modulus_len, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message - Hash, the hash function used to hash the message
- MGF, the mask generation function - MGF, the mask generation function
- salt_len, the length in bytes of the salt (denoted sLen in RFC8017) - salt_len, the length in bytes of the salt (denoted sLen
in RFC 8017)
Inputs: Inputs:
- pk, server public key (n, e) - pk, server public key (n, e)
- msg, message to be signed, a byte string - msg, message to be signed, a byte string
- blind_sig, signed and blinded element, a byte string of - blind_sig, signed and blinded element, a byte string of
length modulus_len length modulus_len
- inv, inverse of the blind, an integer - inv, inverse of the blind, an integer
Outputs: Outputs:
- sig, a byte string of length modulus_len - sig, a byte string of length modulus_len
Errors: Errors:
- "invalid signature": Raised when the signature is invalid - "invalid signature": Raised when the signature is invalid
- "unexpected input size": Raised when a byte string input doesn't - "unexpected input size": Raised when a byte string input doesn't
have the expected length. have the expected length
Steps: Steps:
1. If len(blind_sig) != modulus_len, raise "unexpected input size" and stop 1. If len(blind_sig) != modulus_len, raise an "unexpected input size"
error and stop
2. z = bytes_to_int(blind_sig) 2. z = bytes_to_int(blind_sig)
3. s = (z * inv) mod n 3. s = (z * inv) mod n
4. sig = int_to_bytes(s, modulus_len) 4. sig = int_to_bytes(s, modulus_len)
5. result = RSASSA-PSS-VERIFY(pk, msg, sig) with 5. result = RSASSA-PSS-VERIFY(pk, msg, sig) with
Hash, MGF, and salt_len as defined in the parameters Hash, MGF, and salt_len as defined in the parameters
6. If result = "valid signature", output sig, else 6. If result = "valid signature", output sig, else
raise "invalid signature" and stop raise an "invalid signature" error and stop
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="verification"> <section anchor="verification">
<name>Verification</name> <name>Verification</name>
<t>As described in <xref target="core-protocol"/>, the output of the pro tocol is the prepared <t>As described in <xref target="core-protocol"/>, the output of the pro tocol is the prepared
message <tt>input_msg</tt> and the signature <tt>sig</tt>. The message that appl ications message <tt>input_msg</tt> and the signature <tt>sig</tt>. The message that appl ications
consume is <tt>msg</tt>, from which <tt>input_msg</tt> is derived. Clients verif y the consume is <tt>msg</tt>, from which <tt>input_msg</tt> is derived. Clients verif y the
<tt>msg</tt> signature using the server's public key <tt>pk</tt> by invoking the <tt>msg</tt> signature using the server's public key <tt>pk</tt> by invoking the
RSASSA-PSS-VERIFY routine defined in <xref section="8.1.2" sectionFormat="of" ta rget="RFC8017"/> RSASSA-PSS-VERIFY routine defined in <xref section="8.1.2" sectionFormat="of" ta rget="RFC8017"/>
with <tt>(n, e)</tt> as <tt>pk</tt>, M as <tt>input_msg</tt>, and <tt>S</tt> as <tt>sig</tt>.</t> with <tt>(n, e)</tt> as <tt>pk</tt>, M as <tt>input_msg</tt>, and <tt>S</tt> as <tt>sig</tt>.</t>
<t>Verification and the message that applications consume therefore depe nds on <t>Verification and the message that applications consume therefore depe nd on
which preparation function is used. In particular, if the PrepareIdentity which preparation function is used. In particular, if the PrepareIdentity
function is used, then the application message is <tt>input_msg</tt>. function is used, then the application message is <tt>input_msg</tt>.
In contrast, if the PrepareRandomize function is used, then the application In contrast, if the PrepareRandomize function is used, then the application
message is <tt>slice(input_msg, 32, len(input_msg))</tt>, i.e., the prepared mes sage message is <tt>slice(input_msg, 32, len(input_msg))</tt>, i.e., the prepared mes sage
with the random prefix removed.</t> with the message randomizer prefix removed.</t>
</section> </section>
</section> </section>
<section anchor="rsabssa"> <section anchor="rsabssa">
<name>RSABSSA Variants</name> <name>RSABSSA Variants</name>
<t>In this section we define different named variants of RSABSSA. Each var <t>In this section, we define different named variants of RSABSSA. Each va
iant specifies riant specifies
RSASSA-PSS parameters as defined in <xref section="9.1.1" sectionFormat="of" tar EMSA-PSS options Hash, MGF, and sLen as defined in <xref section="9.1.1" section
get="RFC8017"/> and Format="of" target="RFC8017"/>, as well as
the type of message preparation function applied (as described in <xref target=" randomization"/>). the type of message preparation function applied (as described in <xref target=" randomization"/>).
Each variant uses the MGF1 Mask Generation Function defined in <xref section="B. 2.1." sectionFormat="of" target="RFC8017"/>. Each variant uses the mask generation function 1 (MGF1) defined in <xref section ="B.2.1." sectionFormat="of" target="RFC8017"/>.
Future specifications can introduce other variants as desired. The named variant s are as follows:</t> Future specifications can introduce other variants as desired. The named variant s are as follows:</t>
<ol spacing="normal" type="1"><li>RSABSSA-SHA384-PSS-Randomized: This name <dl spacing="normal"><dt>RSABSSA-SHA384-PSS-Randomized:</dt><dd>This named
d variant uses SHA-384 as the hash function, variant uses SHA-384 as the EMSA-PSS Hash option,
MGF1 with SHA-384 as the PSS mask generation function, a 48-byte salt length, an MGF1 with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS sLen option
d uses (48-byte salt length); it also uses
the randomized preparation function (PrepareRandomize).</li> the randomized preparation function (PrepareRandomize).</dd>
<li>RSABSSA-SHA384-PSSZERO-Randomized: This named variant uses SHA-384 a <dt>RSABSSA-SHA384-PSSZERO-Randomized:</dt><dd>This named variant uses S
s the hash function, HA-384 as the EMSA-PSS Hash option,
MGF1 with SHA-384 as the PSS mask generation function, an empty PSS salt, and us MGF1 with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS sLen option
es (0-byte salt length); it also uses
the randomized preparation function (PrepareRandomize).</li> the randomized preparation function (PrepareRandomize).</dd>
<li>RSABSSA-SHA384-PSS-Deterministic: This named variant uses SHA-384 as <dt>RSABSSA-SHA384-PSS-Deterministic:</dt><dd>This named variant uses SH
the hash function, A-384 as the EMSA-PSS Hash option,
MGF1 with SHA-384 as the PSS mask generation function, 48-byte salt length, and MGF1 with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS sLen option
uses (48-byte salt length); it also uses
the identity preparation function (PrepareIdentity).</li> the identity preparation function (PrepareIdentity).</dd>
<li>RSABSSA-SHA384-PSSZERO-Deterministic: This named variant uses SHA-38 <dt>RSABSSA-SHA384-PSSZERO-Deterministic:</dt><dd>This named variant use
4 as the hash function, s SHA-384 as the EMSA-PSS Hash option,
MGF1 with SHA-384 as the PSS mask generation function, an empty PSS salt, and us MGF1 with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS sLen option
es (0-byte salt length); it also uses
the identity preparation function (PrepareIdentity). This is the only variant th at the identity preparation function (PrepareIdentity). This is the only variant th at
produces deterministic signatures over the client's input message <tt>msg</tt>.< produces deterministic signatures over the client's input message <tt>msg</tt>.<
/li> /dd>
</ol> </dl>
<t>The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or RSABSSA-S <t>The <bcp14>RECOMMENDED</bcp14> variants are RSABSSA-SHA384-PSS-Randomiz
HA384-PSSZERO-Randomized.</t> ed or RSABSSA-SHA384-PSSZERO-Randomized.</t>
<t>Not all named variants can be used interchangeably. In particular, appl ications that provide <t>Not all named variants can be used interchangeably. In particular, appl ications that provide
high-entropy input messages can safely use named variants without randomized mes sage preparation, high-entropy input messages can safely use named variants without randomized mes sage preparation,
as the additional message randomization does not offer security advantages. See <xref target="Lys22"/> and as the additional message randomization does not offer security advantages. See <xref target="Lys22"/> and
<xref target="message-entropy"/> for more information. For all other application s, the variants that use the <xref target="message-entropy"/> for more information. For all other application s, the variants that use the
randomized preparation function protect clients from malicious signers. A randomized preparation function protect clients from malicious signers. A
verifier that accepts randomized messages needs to remove the random component f rom the signed verifier that accepts randomized messages needs to remove the random component f rom the signed
part of messages before processing.</t> part of messages before processing.</t>
<t>Applications that require deterministic signatures can use the RSABSSA- SHA384-PSSZERO-Deterministic <t>Applications that require deterministic signatures can use the RSABSSA- SHA384-PSSZERO-Deterministic
variant, but only if their input messages have high entropy. Applications that u se variant, but only if their input messages have high entropy. Applications that u se
RSABSSA-SHA384-PSSZERO-Deterministic SHOULD carefully analyze the security impli cations, RSABSSA-SHA384-PSSZERO-Deterministic <bcp14>SHOULD</bcp14> carefully analyze the security implications,
taking into account the possibility of adversarially generated signer keys as de scribed in taking into account the possibility of adversarially generated signer keys as de scribed in
<xref target="message-entropy"/>. When it is not clear whether an application re quires deterministic or <xref target="message-entropy"/>. When it is not clear whether an application re quires deterministic or
randomized signatures, applications SHOULD use one of the variants with randomiz ed message preparation.</t> randomized signatures, applications <bcp14>SHOULD</bcp14> use one of the variant s with randomized message preparation.</t>
</section> </section>
<section anchor="implementation-and-usage-considerations"> <section anchor="implementation-and-usage-considerations">
<name>Implementation and Usage Considerations</name> <name>Implementation and Usage Considerations</name>
<t>This section documents considerations for interfaces to implementations of the protocol <t>This section documents considerations for interfaces to implementations of the protocol defined
in this document. This includes error handling and API considerations.</t> in this document. This includes error handling and API considerations.</t>
<section anchor="errors"> <section anchor="errors">
<name>Errors</name> <name>Errors</name>
<t>The high-level functions specified in <xref target="core-protocol"/> are all fallible. The explicit errors <t>The high-level functions specified in <xref target="core-protocol"/> are all fallible. The explicit errors
generated throughout this specification, along with the conditions that lead to each error, generated throughout this specification, along with the conditions that lead to each error,
are listed in the definitions for Blind, BlindSign, and Finalize. are listed in the definitions for Blind, BlindSign, and Finalize.
These errors are meant as a guide for implementors. They are not an exhaustive l ist of all These errors are meant as a guide for implementors. They are not an exhaustive l ist of all
the errors an implementation might emit. For example, implementations might run out of memory.</t> the errors an implementation might emit. For example, implementations might run out of memory.</t>
<t>Moreover, implementations can handle errors as needed or desired. Whe re applicable, this document <t>Moreover, implementations can handle errors as needed or desired. Whe re applicable, this document
provides guidance for how to deal with explicit errors that are generated in the protocol. For provides guidance for how to deal with explicit errors that are generated in the protocol. For
example, "blinding error" is generated in Blind when the client produces a prime example, a "blinding error" error is generated in Blind when the client produces
factor of a prime factor of
the server's public key. <xref target="blind"/> indicates that implementations S the server's public key. <xref target="blind"/> indicates that implementations <
HOULD bcp14>SHOULD</bcp14>
retry the Blind function when this error occurs, but an implementation could als o handle this retry the Blind function when this error occurs, but an implementation could als o handle this
exceptional event differently, e.g., by informing the server that the key has be en factored.</t> exceptional event differently, e.g., by informing the server that the key has be en factored.</t>
</section> </section>
<section anchor="cert-oid"> <section anchor="cert-oid">
<name>Signing Key Generation and Usage</name> <name>Signing Key Generation and Usage</name>
<t>The RECOMMENDED method for generating the server signing key pair is as specified in FIPS 186-4 <t>The <bcp14>RECOMMENDED</bcp14> method for generating the server signi ng key pair is as specified in FIPS 186-5
<xref target="DSS"/>.</t> <xref target="DSS"/>.</t>
<t>A server signing key MUST NOT be reused for any other protocol beyond <t>A server signing key <bcp14>MUST NOT</bcp14> be reused for any other
RSABSSA. Moreover, a protocol beyond RSABSSA. Moreover, a
server signing key MUST NOT be reused for different RSABSSA encoding options. Th server signing key <bcp14>MUST NOT</bcp14> be reused for different RSABSSA encod
at is, ing options. That is,
if a server supports two different encoding options, then it MUST have a distinc if a server supports two different encoding options, then it <bcp14>MUST</bcp14>
t key have a distinct key
pair for each option.</t> pair for each option.</t>
<t>If the server public key is carried in an X.509 certificate, it MUST <t>If the server public key is carried in an X.509 certificate, it <bcp1
use the RSASSA-PSS 4>MUST</bcp14> use the id-RSASSA-PSS
OID <xref target="RFC5756"/>. It MUST NOT use the rsaEncryption OID <xref target OID <xref target="RFC5756"/>. It <bcp14>MUST NOT</bcp14> use the rsaEncryption O
="RFC5280"/>.</t> ID <xref target="RFC5280"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-considerations"> <section anchor="sec-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Lysyanskaya proved one-more-forgery polynomial security of RSABSSA vari ants in the random <t>Lysyanskaya proved one-more-forgery polynomial security of RSABSSA vari ants in the random
oracle model under the one-more-RSA assumption in <xref target="Lys22"/>. This m eans the adversary oracle model under the one-more-RSA assumption; see <xref target="Lys22"/>. This means the adversary
cannot output n+1 valid message and signature tuples, where all messages are dis tinct, after cannot output n+1 valid message and signature tuples, where all messages are dis tinct, after
interacting with the server (signer) as a client only n times, for some n which is polynomial interacting with the server (signer) as a client only n times, for some n that i s polynomial
in the protocol's security parameter. in the protocol's security parameter.
Lysyanskaya also proved that the RSABSSA variants which use the PrepareRandomize Lysyanskaya also proved that the RSABSSA variants, which use the PrepareRandomiz
function e function,
achieve blindness in <xref target="Lys22"/>. Blindness means that the malicious achieve blindness (see version B of the protocol and related proofs in <xref tar
signer learns nothing get="Lys22"/>). Blindness means that the malicious signer learns nothing
about the client input and output after the protocol execution. However, additio nal assumptions on the message about the client input and output after the protocol execution. However, additio nal assumptions on the message
inputs are required for blindness to hold for RSABSSA variants that use the Prep areIdentity inputs are required for blindness to hold for RSABSSA variants that use the Prep areIdentity
function; see <xref target="message-entropy"/> for more discussion on those resu lts.</t> function; see <xref target="message-entropy"/> for more discussion on those resu lts.</t>
<section anchor="timing-side-channels-and-fault-attacks"> <section anchor="timing-side-channels-and-fault-attacks">
<name>Timing Side Channels and Fault Attacks</name> <name>Timing Side Channels and Fault Attacks</name>
<t>BlindSign is functionally a remote procedure call for applying the RS A private <t>BlindSign is functionally a remote procedure call for applying the RS A private
key operation. As such, side channel resistance is paramount to protect the priv key operation. As such, side-channel resistance is paramount to protect the priv
ate key ate key
from exposure <xref target="RemoteTimingAttacks"/>. Implementations SHOULD imple from exposure <xref target="RemoteTimingAttacks"/>. Implementations <bcp14>SHOUL
ment some form of D</bcp14> implement some form of
side channel attack mitigation, such as RSA blinding as described in Section 10 side-channel attack mitigation, such as RSA blinding as described in Section 10
of of
<xref target="TimingAttacks"/>. Failure to apply such mitigations can <xref target="TimingAttacks"/>. Failure to apply such mitigations can
lead to side channel attacks that leak the private signing key.</t> lead to side-channel attacks that leak the private signing key.</t>
<t>Moreover, we assume that the server does not initiate the protocol an d therefore has <t>Moreover, we assume that the server does not initiate the protocol an d therefore has
no knowledge of when the Prepare and Blind operations take place. If this were n ot the no knowledge of when the Prepare and Blind operations take place. If this were n ot the
case, additional side-channel mitigations might be required to prevent timing si de case, additional side-channel mitigations might be required to prevent timing si de
channels through Prepare and Blind.</t> channels through Prepare and Blind.</t>
<t>Beyond timing side channels, <xref target="FAULTS"/> describes the im portance <t>Beyond timing side channels, <xref target="FAULTS"/> describes the im portance
of implementation safeguards that protect against fault attacks that can also le ak the of implementation safeguards that protect against fault attacks that can also le ak the
private signing key. These safeguards require that implementations check that th e result private signing key. These safeguards require that implementations check that th e result
of the private key operation when signing is correct, i.e., given s = RSASP1(sk, m), of the private key operation when signing is correct, i.e., given s = RSASP1(sk, m),
verify that m = RSAVP1(pk, s), as is required by BlindSign. Applying this (or eq uivalent) verify that m = RSAVP1(pk, s), as is required by BlindSign. Applying this (or an equivalent)
safeguard is necessary to mitigate fault attacks, even for implementations that are not safeguard is necessary to mitigate fault attacks, even for implementations that are not
based on the Chinese remainder theorem.</t> based on the Chinese remainder theorem.</t>
</section> </section>
<section anchor="message-robustness"> <section anchor="message-robustness">
<name>Message Robustness</name> <name>Message Robustness</name>
<t>An essential property of blind signature protocols is that the signer learns nothing of the message <t>An essential property of blind signature protocols is that the signer learns nothing of the message
being signed. In some circumstances, this may raise concerns of arbitrary signin g oracles. Applications being signed. In some circumstances, this may raise concerns regarding arbitrary signing oracles. Applications
using blind signature protocols should take precautions to ensure that such orac les do not cause using blind signature protocols should take precautions to ensure that such orac les do not cause
cross-protocol attacks. Ensuring that the signing key used for RSABSSA is distin ct from other protocols cross-protocol attacks. Ensuring that the signing key used for RSABSSA is distin ct from other protocols
prevents such cross-protocol attacks.</t> prevents such cross-protocol attacks.</t>
<t>An alternative solution to this problem of message blindness is to gi ve signers proof that the <t>An alternative solution to this problem of message blindness is to gi ve signers proof that the
message being signed is well-structured. Depending on the application, zero know message being signed is well structured. Depending on the application,
ledge proofs zero-knowledge proofs
could be useful for this purpose. Defining such a proof is out of scope for this could be useful for this purpose. Defining such proofs is out of scope for this
document.</t> document.</t>
<t>Verifiers should check that, in addition to signature validity, the s igned message is <t>Verifiers should check that, in addition to signature validity, the s igned message is
well-structured for the relevant application. For example, if an application of this protocol well structured for the relevant application. For example, if an application of this protocol
requires messages to be structures of a particular form, then verifiers should c heck that requires messages to be structures of a particular form, then verifiers should c heck that
messages adhere to this form.</t> messages adhere to this form.</t>
</section> </section>
<section anchor="message-entropy"> <section anchor="message-entropy">
<name>Message Entropy</name> <name>Message Entropy</name>
<t>As discussed in <xref target="Lys22"/>, a malicious signer can constr uct an invalid public key and use <t>As discussed in <xref target="Lys22"/>, a malicious signer can constr uct an invalid public key and use
it to learn information about low-entropy input messages. Note that some invalid public it to learn information about low-entropy input messages. Note that some invalid public
keys may not yield valid signatures when run with the protocol, e.g., because th e signature keys may not yield valid signatures when run with the protocol, e.g., because th e signature
fails to verify. However, if an attacker can coerce the client to use these inva lid public fails to verify. However, if an attacker can coerce the client to use these inva lid public
keys with low-entropy inputs, they can learn information about the client inputs before keys with low-entropy inputs, they can learn information about the client inputs before
the protocol completes.</t> the protocol completes.</t>
<t>A client that uses this protocol might be vulnerable to attack from a malicious signer <t>A client that uses this protocol might be vulnerable to attack from a malicious signer
unless it is able to ensure that either:</t> unless it is able to ensure that one of the following conditions is satisfied:</
<ol spacing="normal" type="1"><li>The client has proof that the signer's t>
public key is honestly generated. <xref target="GRSB19"/> presents <ol spacing="normal" type="(%d)"><li>The client has proof that the signe
r's public key is honestly generated. <xref target="GRSB19"/> presents
some (non-interactive) honest-verifier zero-knowledge proofs of various statem ents about the some (non-interactive) honest-verifier zero-knowledge proofs of various statem ents about the
public key.</li> public key.</li>
<li>The input message has a value that the signer is unable to guess. That is, the client has <li>The input message has a value that the signer is unable to guess. That is, the client has
added a high-entropy component that was not available to the signer prior to t hem choosing added a high-entropy component that was not available to the signer prior to t hem choosing
their signing key.</li> their signing key.</li>
</ol> </ol>
<t>The named variants that use the PrepareRandomize function -- RSABSSA- SHA384-PSS-Randomized and <t>The named variants that use the PrepareRandomize function -- RSABSSA- SHA384-PSS-Randomized and
RSABSSA-SHA384-PSSZERO-Randomized -- explicitly inject fresh entropy alongside e ach message RSABSSA-SHA384-PSSZERO-Randomized -- explicitly inject fresh entropy alongside e ach message
to satisfy condition (2). As such, these variants are safe for all application u se cases.</t> to satisfy condition (2). As such, these variants are safe for all application u se cases. In contrast, the named variants that use the PrepareIdentity function do not inject fresh entropy and therefore could be a problem with low-entropy in puts.</t>
<t>Note that these variants effectively mean that the resulting signatur e is always randomized. <t>Note that these variants effectively mean that the resulting signatur e is always randomized.
As such, this interface is not suitable for applications that require determinis tic signatures.</t> As such, this interface is not suitable for applications that require determinis tic signatures.</t>
</section> </section>
<section anchor="randomness-generation"> <section anchor="randomness-generation">
<name>Randomness Generation</name> <name>Randomness Generation</name>
<t>All random values in the protocol, including the salt, message random <t>All random values in the protocol, including the salt, message random
izer prefix, and random blind izer prefix (msg_prefix; see <xref target="test-vectors"/>), and random blind
value in <tt>Blind</tt>, MUST be generated from a cryptographically secure rando value in <tt>Blind</tt>, <bcp14>MUST</bcp14> be generated from a cryptographical
m number generator <xref target="RFC4086"/>. ly secure random number generator <xref target="RFC4086"/>.
If these values are not generated randomly, or are otherwise constructed malicio If these values are not generated randomly or are otherwise constructed maliciou
usly, it might be sly, it might be
possible for them to encode information that is not present in the signed messag e. For example, possible for them to encode information that is not present in the signed messag e. For example,
the PSS salt might be maliciously constructed to encode the local IP address of the client. As a result, the PSS salt might be maliciously constructed to encode the local IP address of the client. As a result,
implementations SHOULD NOT allow clients to provide these values directly.</t> implementations <bcp14>SHOULD NOT</bcp14> allow clients to provide these values directly.</t>
<t>Note that malicious implementations could also encode client informat ion in the message being signed, <t>Note that malicious implementations could also encode client informat ion in the message being signed,
but since clients can verify the resulting message signature using the public ke y this can be detected.</t> but since clients can verify the resulting message signature using the public ke y, this can be detected.</t>
</section> </section>
<section anchor="key-substitution-attacks"> <section anchor="key-substitution-attacks">
<name>Key Substitution Attacks</name> <name>Key Substitution Attacks</name>
<t>RSA is well known to permit key substitution attacks, wherein an atta cker generates a key pair <t>RSA is well known for permitting key substitution attacks, wherein an attacker generates a key pair
(skA, pkA) that verifies some known (message, signature) pair produced under a d ifferent (sk, pk) (skA, pkA) that verifies some known (message, signature) pair produced under a d ifferent (sk, pk)
key pair <xref target="WM99"/>. This means it may be possible for an attacker to use a (message, signature) pair key pair <xref target="WM99"/>. This means it may be possible for an attacker to use a (message, signature) pair
from one context in another. Entities that verify signatures must take care to e nsure a from one context in another. Entities that verify signatures must take care to e nsure that a
(message, signature) pair verifies with a valid public key from the expected iss uer.</t> (message, signature) pair verifies with a valid public key from the expected iss uer.</t>
</section> </section>
<section anchor="alternative-rsa-encoding-functions"> <section anchor="alternative-rsa-encoding-functions">
<name>Alternative RSA Encoding Functions</name> <name>Alternative RSA Encoding Functions</name>
<t>This document document uses PSS encoding as specified in <xref target ="RFC8017"/> for a number of <t>This document uses PSS encoding as specified in <xref target="RFC8017 "/> for a number of
reasons. First, it is recommended in recent standards, including TLS 1.3 <xref t arget="RFC8446"/>, reasons. First, it is recommended in recent standards, including TLS 1.3 <xref t arget="RFC8446"/>,
X.509v3 <xref target="RFC4055"/>, and even PKCS#1 itself. According to <xref tar X.509 <xref target="RFC4055"/>, and even PKCS #1 itself. According to <xref targ
get="RFC8017"/>, "Although no et="RFC8017"/>,
attacks are known against RSASSA-PKCS#1 v1.5, in the interest of increased robus "Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of inc
tness, reased robustness, RSASSA-PSS is <bcp14>REQUIRED</bcp14> in new applications." W
RSA-PSS <xref target="RFC8017"/> is recommended for eventual adoption in new app hile RSA-PSS is
lications." While RSA-PSS is more complex than RSASSA-PKCS1-v1_5 encoding, ubiquity of RSA-PSS support influe
more complex than RSASSA-PKCS#1 v1.5 encoding, ubiquity of RSA-PSS support influ nced
enced the design decision in this document, despite PKCS #1 v1.5 having equivalent sec
the design decision in this draft, despite PKCS#1 v1.5 having equivalent securit urity
y
properties for digital signatures <xref target="JKM18"/>.</t> properties for digital signatures <xref target="JKM18"/>.</t>
<t>Full Domain Hash (FDH) <xref target="RSA-FDH"/> encoding is also poss <t>Full Domain Hash (FDH) encoding <xref target="RSA-FDH"/> is also poss
ible, and this variant has ible. This variant provides
equivalent security to PSS <xref target="KK18"/>. However, FDH is security equivalent to that of PSS <xref target="KK18"/>. However, FDH is
less standard and not used widely in related technologies. Moreover, FDH is less standard and is not used widely in related technologies. Moreover, FDH is
deterministic, whereas PSS supports deterministic and probabilistic encodings.</ t> deterministic, whereas PSS supports deterministic and probabilistic encodings.</ t>
</section> </section>
<section anchor="post-quantum-readiness"> <section anchor="post-quantum-readiness">
<name>Post-Quantum Readiness</name> <name>Post-Quantum Readiness</name>
<t>The blind signature protocol specified in this document is not post-q uantum ready since it <t>The blind signature protocol specified in this document is not post-q uantum ready, since it
is based on RSA. Shor's polynomial-time factorization algorithm readily applies. </t> is based on RSA. Shor's polynomial-time factorization algorithm readily applies. </t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no IANA requests.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.irtf-cfrg-voprf" to="VOPRF"/>
<displayreference target="I-D.ietf-privacypass-protocol" to="PRIVACY-PASS"/>
<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.21
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 19.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 74.xml"/>
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<abstract> 17.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
nify the requirements in the specification. These words are often capitalized. T 56.xml"/>
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="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="GoogleVPN" target="https://one.google.com/about/vpn/h owitworks"> <reference anchor="GoogleVPN" target="https://one.google.com/about/vpn/h owitworks">
<front> <front>
<title>VPN by Google One White Paper</title> <title>VPN by Google One, explained</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="ApplePrivateRelay" target="https://www.apple.com/iclo ud/docs/iCloud_Private_Relay_Overview_Dec2021.pdf"> <reference anchor="ApplePrivateRelay" target="https://www.apple.com/iclo ud/docs/iCloud_Private_Relay_Overview_Dec2021.pdf">
<front> <front>
<title>iCloud Private Relay Overview</title> <title>iCloud Private Relay Overview</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="December" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="PrettyGoodPhonePrivacy" target="https://www.usenix.or g/conference/usenixsecurity21/presentation/schmitt"> <reference anchor="PrettyGoodPhonePrivacy" target="https://www.usenix.or g/conference/usenixsecurity21/presentation/schmitt">
<front> <front>
<title>Pretty Good Phone Privacy</title> <title>Pretty Good Phone Privacy</title>
<author initials="P." surname="Schmitt"> <author initials="P." surname="Schmitt">
<organization/> <organization/>
</author> </author>
<author initials="B." surname="Raghavan"> <author initials="B." surname="Raghavan">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="August" year="2021"/>
</front> </front>
<refcontent>Proceedings of the 30th USENIX Security Symposium</refcon tent>
</reference> </reference>
<reference anchor="WM99">
<reference anchor="WM99" target="https://link.springer.com/chapter/10.10
07/3-540-49162-7_12">
<front> <front>
<title>Unknown key-share attacks on the station-to-station (STS) pro tocol</title> <title>Unknown Key-Share Attacks on the Station-to-Station (STS) Pro tocol</title>
<author initials="S." surname="Blake-Wilson"> <author initials="S." surname="Blake-Wilson">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Menezes"> <author initials="A." surname="Menezes">
<organization/> <organization/>
</author> </author>
<date year="1999" month="October"/> <date year="1999" month="October"/>
</front> </front>
<refcontent>International Workshop on Public Key Cryptography</refcont <refcontent>International Workshop on Public Key Cryptography, PKC 199
ent> 9, pp. 154-170</refcontent>
</reference> <seriesInfo name="DOI" value="10.1007/3-540-49162-7_12"/>
<reference anchor="KLRX20" target="https://eprint.iacr.org/2020/1071">
<front>
<title>On Pairing-Free Blind Signature Schemes in the Algebraic Grou
p Model</title>
<author initials="J." surname="Kastner">
<organization/>
</author>
<author initials="J." surname="Loss">
<organization/>
</author>
<author initials="M." surname="Rosenberg">
<organization/>
</author>
<author initials="J." surname="Xu">
<organization/>
</author>
<date year="2020" month="September"/>
</front>
</reference> </reference>
<reference anchor="JKK14" target="https://eprint.iacr.org/2014/650"> <reference anchor="JKK14" target="https://eprint.iacr.org/2014/650">
<front> <front>
<title>Round-Optimal Password-Protected Secret Sharing and T-PAKE in the Password-Only model</title> <title>Round-Optimal Password-Protected Secret Sharing and T-PAKE in the Password-Only Model</title>
<author initials="S." surname="Jarecki"> <author initials="S." surname="Jarecki">
<organization>UC Irvine, CA, USA</organization> <organization>UC Irvine, CA, USA</organization>
</author> </author>
<author initials="A." surname="Kiayias"> <author initials="A." surname="Kiayias">
<organization>University of Athens, Greece</organization> <organization>University of Athens, Greece</organization>
</author> </author>
<author initials="H." surname="Krawczyk"> <author initials="H." surname="Krawczyk">
<organization>IBM Research, NY, USA</organization> <organization>IBM Research, NY, USA</organization>
</author> </author>
<date year="2014" month="August"/> <date year="2014" month="August"/>
skipping to change at line 659 skipping to change at line 602
</author> </author>
<author initials="A." surname="Kiayias"> <author initials="A." surname="Kiayias">
<organization>University of Athens, Greece</organization> <organization>University of Athens, Greece</organization>
</author> </author>
<author initials="H." surname="Krawczyk"> <author initials="H." surname="Krawczyk">
<organization>IBM Research, NY, USA</organization> <organization>IBM Research, NY, USA</organization>
</author> </author>
<date year="2014" month="August"/> <date year="2014" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="Lys22" target="https://eprint.iacr.org/2022/895"> <reference anchor="Lys22" target="https://eprint.iacr.org/2022/895">
<front> <front>
<title>Security Analysis of RSA-BSSA</title> <title>Security Analysis of RSA-BSSA</title>
<author initials="A." surname="Lysyanskaya"> <author initials="A." surname="Lysyanskaya">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="March" year="2023"/>
</front>
</reference>
<reference anchor="BLS-Proposal" target="https://mailarchive.ietf.org/ar
ch/msg/privacy-pass/BDOOhSLwB3uUJcfBiss6nUF5sUA/">
<front>
<title>[Privacy-pass] External verifiability: a concrete proposal</t
itle>
<author initials="W." surname="Ladd">
<organization/>
</author>
<date year="2020" month="July"/>
</front>
</reference>
<reference anchor="PolytimeROS" target="https://eprint.iacr.org/2020/945
">
<front>
<title>On the (in)security of ROS</title>
<author initials="F." surname="Benhamouda">
<organization/>
</author>
<author initials="T." surname="Lepoint">
<organization/>
</author>
<author initials="J." surname="Loss">
<organization/>
</author>
<author initials="M." surname="Orru">
<organization/>
</author>
<author initials="M." surname="Raykova">
<organization/>
</author>
<date year="2020" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="RSA-FDH" target="https://cseweb.ucsd.edu/~mihir/paper
s/ro.pdf"> <reference anchor="RSA-FDH" target="https://dl.acm.org/doi/abs/10.1145/1
68588.168596">
<front> <front>
<title>Random Oracles are Practical: A Paradigm for Designing Effici ent Protocols</title> <title>Random oracles are practical: a paradigm for designing effic ient protocols</title>
<author initials="M." surname="Bellare"> <author initials="M." surname="Bellare">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Rogaway"> <author initials="P." surname="Rogaway">
<organization/> <organization/>
</author> </author>
<date year="1995" month="October"/> <date year="1993" month="December"/>
</front> </front>
<refcontent>CCS '93: Proceedings of the 1st ACM conference on Computer
and communications security, pp. 62-73</refcontent>
<seriesInfo name="DOI" value="10.1145/168588.168596"/>
</reference> </reference>
<reference anchor="Chaum83" target="http://sceweb.sce.uhcl.edu/yang/teac hing/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF"> <reference anchor="Chaum83" target="https://sceweb.sce.uhcl.edu/yang/tea ching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF">
<front> <front>
<title>Blind Signatures for Untraceable Payments</title> <title>Blind Signatures for Untraceable Payments</title>
<author initials="D." surname="Chaum"> <author initials="D." surname="Chaum">
<organization>University of California, Santa Barbara, USA</organi zation> <organization>University of California, Santa Barbara, USA</organi zation>
</author> </author>
<date year="1983"/> <date year="1998"/>
</front> </front>
<refcontent>Springer-Verlag</refcontent>
</reference> </reference>
<reference anchor="RemoteTimingAttacks" target="https://crypto.stanford.
edu/~dabo/papers/ssl-timing.pdf"> <reference anchor="RemoteTimingAttacks" target="https://www.usenix.org/l
egacy/events/sec03/tech/brumley/brumley.pdf">
<front> <front>
<title>Remote Timing Attacks are Practical</title> <title>Remote Timing Attacks are Practical</title>
<author initials="D." surname="Boneh">
<organization>Stanford University</organization>
</author>
<author initials="D." surname="Brumley"> <author initials="D." surname="Brumley">
<organization>Stanford University</organization> <organization>Stanford University</organization>
</author> </author>
<date year="2003" month="May"/> <author initials="D." surname="Boneh">
</front> <organization>Stanford University</organization>
<refcontent>12th Usenix Security Symposium</refcontent>
</reference>
<reference anchor="TZ22" target="https://eprint.iacr.org/2022/047">
<front>
<title>Short Pairing-Free Blind Signatures with Exponential Security
</title>
<author initials="S." surname="Tessaro">
<organization>University of Washington</organization>
</author>
<author initials="C." surname="Zhu">
<organization>University of Washington</organization>
</author>
<date year="2022" month="January"/>
</front>
</reference>
<reference anchor="UProve" target="https://www.microsoft.com/en-us/resea
rch/project/u-prove/">
<front>
<title>U-Prove</title>
<author initials="" surname="Microsoft">
<organization>Microsoft</organization>
</author> </author>
<date year="2012" month="February"/> <date year="2003" month="August"/>
</front> </front>
<refcontent>Proceedings of the 12th USENIX Security Symposium</refcont ent>
</reference> </reference>
<reference anchor="GRSB19" target="https://eprint.iacr.org/2018/057.pdf" > <reference anchor="GRSB19" target="https://eprint.iacr.org/2018/057.pdf" >
<front> <front>
<title>Efficient Noninteractive Certification of RSA Moduli and Beyo nd</title> <title>Efficient Noninteractive Certification of RSA Moduli and Beyo nd</title>
<author initials="S." surname="Goldberg"> <author initials="S." surname="Goldberg">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Reyzin"> <author initials="L." surname="Reyzin">
<organization/> <organization/>
</author> </author>
<author initials="O." surname="Sagga"> <author initials="O." surname="Sagga">
<organization/> <organization/>
</author> </author>
<author initials="F." surname="Baldimtsi"> <author initials="F." surname="Baldimtsi">
<organization/> <organization/>
</author> </author>
<date year="2019" month="October"/> <date year="2019" month="October"/>
</front> </front>
</reference> </reference>
<reference anchor="VOPRF">
<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> <!-- draft-irtf-cfrg-voprf (RFC-EDITOR since 9/22/2023) -->
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-voprf-21"/>
</reference>
<reference anchor="PRIVACY-PASS">
<front>
<title>Privacy Pass Issuance Protocol</title>
<author fullname="Sofia Celi" initials="S." surname="Celi">
<organization>Brave Software</organization>
</author>
<author fullname="Alex Davidson" initials="A." surname="Davidson">
<organization>Brave Software</organization>
</author>
<author fullname="Steven Valdez" initials="S." surname="Valdez">
<organization>Google LLC</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="26" month="June" year="2023"/>
<abstract>
<t> This document specifies two variants of the two-message issu
ance
protocol for Privacy Pass tokens: one that produces tokens that are
privately verifiable using the issuance private key, and another that
produces tokens that are publicly verifiable using the issuance
public key.
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-cf
</abstract> rg-voprf.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-protoc <!-- draft-ietf-privacypass-protocol (Submitted to IESG for Pub) -->
ol-11"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pr
</reference> ivacypass-protocol.xml"/>
<reference anchor="DSS">
<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> <author>
<organization/> <organization/>
</author> </author>
<date month="July" year="2013"/> <date month="February" year="2023"/>
</front>
<seriesInfo name="National Institute of Standards and Technology" valu
e="report"/>
<seriesInfo name="DOI" value="10.6028/nist.fips.186-4"/>
</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"/> <refcontent>National Institute of Standards and Technology report</ref
<seriesInfo name="DOI" value="10.17487/RFC5280"/> content>
<seriesInfo name="DOI" value="10.6028/nist.fips.186-5"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"
/>
<reference anchor="TimingAttacks"> <reference anchor="TimingAttacks">
<front> <front>
<title>Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS , and Other Systems</title> <title>Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS , and Other Systems</title>
<author fullname="Paul C. Kocher" initials="P." surname="Kocher"> <author fullname="Paul C. Kocher" initials="P. C." surname="Kocher">
<organization/> <organization/>
</author> </author>
<date year="1996"/> <date year="1996"/>
</front> </front>
<seriesInfo name="Advances in Cryptology - CRYPTO '96" value="pp. 104- 113"/> <refcontent>Advances in Cryptology - CRYPTO '96, pp. 104-113</refconte nt>
<seriesInfo name="DOI" value="10.1007/3-540-68697-5_9"/> <seriesInfo name="DOI" value="10.1007/3-540-68697-5_9"/>
</reference> </reference>
<reference anchor="FAULTS"> <reference anchor="FAULTS">
<front> <front>
<title>On the Importance of Checking Cryptographic Protocols for Fau lts</title> <title>On the Importance of Checking Cryptographic Protocols for Fau lts</title>
<author fullname="Dan Boneh" initials="D." surname="Boneh"> <author fullname="Dan Boneh" initials="D." surname="Boneh">
<organization/> <organization/>
</author> </author>
<author fullname="Richard A. DeMillo" initials="R." surname="DeMillo "> <author fullname="Richard A. DeMillo" initials="R. A." surname="DeMi llo">
<organization/> <organization/>
</author> </author>
<author fullname="Richard J. Lipton" initials="R." surname="Lipton"> <author fullname="Richard J. Lipton" initials="R. J." surname="Lipto n">
<organization/> <organization/>
</author> </author>
<date year="1997"/> <date year="1997"/>
</front> </front>
<seriesInfo name="Advances in Cryptology - EUROCRYPT '97" value="pp. 3 7-51"/> <refcontent>Advances in Cryptology - EUROCRYPT '97, pp. 37-51</refcont ent>
<seriesInfo name="DOI" value="10.1007/3-540-69053-0_4"/> <seriesInfo name="DOI" value="10.1007/3-540-69053-0_4"/>
</reference> </reference>
<reference anchor="RFC4086">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<title>Randomness Requirements for Security</title> 86.xml"/>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
rd"/> 46.xml"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<author fullname="S. Crocker" initials="S." surname="Crocker"/> 55.xml"/>
<date month="June" year="2005"/>
<abstract> <reference anchor="JKM18" target="https://eprint.iacr.org/2018/855">
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC8446">
<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="RFC4055">
<front>
<title>Additional Algorithms and Identifiers for RSA Cryptography fo
r use in the Internet X.509 Public Key Infrastructure Certificate and Certificat
e Revocation List (CRL) Profile</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="June" year="2005"/>
<abstract>
<t>This document supplements RFC 3279. It describes the convention
s for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algori
thm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OA
EP) key transport algorithm and additional one-way hash functions with the Publi
c-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the In
ternet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identi
fiers, and parameter formats are specified. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4055"/>
<seriesInfo name="DOI" value="10.17487/RFC4055"/>
</reference>
<reference anchor="JKM18">
<front> <front>
<title>On the Security of the PKCS#1 v1.5 Signature Scheme</title> <title>On the Security of the PKCS#1 v1.5 Signature Scheme</title>
<author fullname="Tibor Jager" initials="T." surname="Jager"> <author fullname="Tibor Jager" initials="T." surname="Jager">
<organization>Paderborn Uninversity, Paderborn, Germany</organizat ion> <organization>Paderborn Uninversity, Paderborn, Germany</organizat ion>
</author> </author>
<author fullname="Saqib A. Kakvi" initials="S." surname="Kakvi"> <author fullname="Saqib A. Kakvi" initials="S. A." surname="Kakvi">
<organization>Paderborn University, Paderborn, Germany</organizati on> <organization>Paderborn University, Paderborn, Germany</organizati on>
</author> </author>
<author fullname="Alexander May" initials="A." surname="May"> <author fullname="Alexander May" initials="A." surname="May">
<organization>Ruhr-University Bochum, Bochum, Germany</organizatio n> <organization>Ruhr-University Bochum, Bochum, Germany</organizatio n>
</author> </author>
<date month="October" year="2018"/> <date month="September" year="2018"/>
</front> </front>
<seriesInfo name="Proceedings of the 2018 ACM SIGSAC Conference on Com puter and Communications" value="Security"/> <refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 1195-1208</refcontent>
<seriesInfo name="DOI" value="10.1145/3243734.3243798"/> <seriesInfo name="DOI" value="10.1145/3243734.3243798"/>
</reference> </reference>
<reference anchor="KK18"> <reference anchor="KK18">
<front> <front>
<title>Optimal Security Proofs for Full Domain Hash, Revisited</titl e> <title>Optimal Security Proofs for Full Domain Hash, Revisited</titl e>
<author fullname="Saqib A. Kakvi" initials="S." surname="Kakvi"> <author fullname="Saqib A. Kakvi" initials="S. A." surname="Kakvi">
<organization/> <organization/>
</author> </author>
<author fullname="Eike Kiltz" initials="E." surname="Kiltz"> <author fullname="Eike Kiltz" initials="E." surname="Kiltz">
<organization/> <organization/>
</author> </author>
<date month="April" year="2017"/> <date month="April" year="2017"/>
</front> </front>
<seriesInfo name="Journal of Cryptology" value="vol. 31, no. 1, pp. 27 6-306"/> <refcontent>Journal of Cryptology, vol. 31, no. 1, pp. 276-306</refcon tent>
<seriesInfo name="DOI" value="10.1007/s00145-017-9257-9"/> <seriesInfo name="DOI" value="10.1007/s00145-017-9257-9"/>
</reference> </reference>
</references> </references>
</references> </references>
<?line 655?>
<section anchor="test-vectors"> <section anchor="test-vectors">
<name>Test Vectors</name> <name>Test Vectors</name>
<t>This section includes test vectors for the blind signature protocol def ined in <xref target="core-protocol"/>. <t>This section includes test vectors for the blind signature protocol def ined in <xref target="core-protocol"/>.
The following parameters are specified for each test vector:</t> The following parameters are specified for each test vector:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>p, q, n, e, d: RSA private and public key (sk and pk) parameters, ea <dt>p, q, n, e, d:</dt><dd>RSA private and public key (sk and pk) parame
ch encoded as a hexadecimal string.</li> ters, each encoded as a hexadecimal string.</dd>
<li>msg: Input messsage being signed, encoded as a hexadecimal string. T <dt>msg:</dt><dd>Input message being signed, encoded as a hexadecimal st
he hash is computed using SHA-384.</li> ring. The hash is computed using SHA-384.</dd>
<li>msg_prefix: Message randomizer prefix, encoded as a hexadecimal stri <dt>msg_prefix:</dt><dd>Message randomizer prefix, encoded as a hexadeci
ng. This is only present for variants mal string. This is only present for variants
that use the randomization preparation function.</li> that use the randomization preparation function.</dd>
<li>prepared_msg: The message actually signed. If the variant does not u <dt>prepared_msg:</dt><dd>The message actually signed. If the variant do
se the randomization preparation es not use the randomization preparation
function, this is equal to msg.</li> function, this is equal to msg.</dd>
<li>salt: Randomly-generated salt used when computing the signature. The <dt>salt:</dt><dd>Randomly generated salt used when computing the signat
length is either 48 or 0 bytes.</li> ure. The length is either 48 or 0 bytes.</dd>
<li>encoded_msg: EMSA-PSS encoded message. The mask generation function <dt>encoded_msg:</dt><dd>EMSA-PSS encoded message. The mask generation f
is MGF1 with SHA-384.</li> unction is MGF1 with SHA-384.</dd>
<li>inv: The message blinding inverse, encoded as a hexadecimal string.< <dt>inv:</dt><dd>The message blinding inverse, encoded as a hexadecimal
/li> string.</dd>
<li>blinded_msg, blind_sig: The protocol values exchanged during the com <dt>blinded_msg, blind_sig:</dt><dd>The protocol values exchanged during
putation, the computation,
encoded as hexadecimal strings.</li> encoded as hexadecimal strings.</dd>
<li>sig: The output message signature.</li> <dt>sig:</dt><dd>The output message signature.</dd>
</ul> </dl>
<section anchor="rsabssa-sha384-pss-randomized-test-vector"> <section anchor="rsabssa-sha384-pss-randomized-test-vector">
<name>RSABSSA-SHA384-PSS-Randomized Test Vector</name> <name>RSABSSA-SHA384-PSS-Randomized Test Vector</name>
<artwork><![CDATA[
<sourcecode name="" type="test-vectors"><![CDATA[
p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305
59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca
7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e
41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10
8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048
b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632
2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401
7e32ebca06308a12ecc290c7cd1156dcccfb2311 7e32ebca06308a12ecc290c7cd1156dcccfb2311
q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8
06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945
skipping to change at line 1130 skipping to change at line 921
1e2cfee2d8bef511412e93c859a13726d87c57d1bc4c2e68ab121562f839c3a3d233 1e2cfee2d8bef511412e93c859a13726d87c57d1bc4c2e68ab121562f839c3a3d233
e87ed63c69b7e57525367753fbebcc2a9805a2802659f5888b2c69115bf865559f10 e87ed63c69b7e57525367753fbebcc2a9805a2802659f5888b2c69115bf865559f10
d906c09d048a0d71bfee4b33857393ec2b69e451433496d02c9a7910abb954317720 d906c09d048a0d71bfee4b33857393ec2b69e451433496d02c9a7910abb954317720
bbde9e69108eafc3e90bad3d5ca4066d7b1e49013fa04e948104a1dd82b12509ecb1 bbde9e69108eafc3e90bad3d5ca4066d7b1e49013fa04e948104a1dd82b12509ecb1
46e948c54bd8bfb5e6d18127cd1f7a93c3cf9f2d869d5a78878c03fe808a0d799e91 46e948c54bd8bfb5e6d18127cd1f7a93c3cf9f2d869d5a78878c03fe808a0d799e91
0be6f26d18db61c485b303631d3568368fc41986d08a95ea6ac0592240c19d7b2241 0be6f26d18db61c485b303631d3568368fc41986d08a95ea6ac0592240c19d7b2241
6b9c82ae6241e211dd5610d0baaa9823158f9c32b66318f5529491b7eeadcaa71898 6b9c82ae6241e211dd5610d0baaa9823158f9c32b66318f5529491b7eeadcaa71898
a63bac9d95f4aa548d5e97568d744fc429104e32edd9c87519892a198a30d333d427 a63bac9d95f4aa548d5e97568d744fc429104e32edd9c87519892a198a30d333d427
739ffb9607b092e910ae37771abf2adb9f63bc058bf58062ad456cb934679795bbdf 739ffb9607b092e910ae37771abf2adb9f63bc058bf58062ad456cb934679795bbdf
cdfad5e0f2 cdfad5e0f2
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="rsabssa-sha384-psszero-randomized-test-vector"> <section anchor="rsabssa-sha384-psszero-randomized-test-vector">
<name>RSABSSA-SHA384-PSSZERO-Randomized Test Vector</name> <name>RSABSSA-SHA384-PSSZERO-Randomized Test Vector</name>
<artwork><![CDATA[ <sourcecode name="" type="test-vectors"><![CDATA[
p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305
59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca
7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e
41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10
8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048
b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632
2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401
7e32ebca06308a12ecc290c7cd1156dcccfb2311 7e32ebca06308a12ecc290c7cd1156dcccfb2311
q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8
06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945
skipping to change at line 1272 skipping to change at line 1063
e7b8016ca9ad11b835756df862c465c420535e25faa48bf341f7ee8192be47fa8757 e7b8016ca9ad11b835756df862c465c420535e25faa48bf341f7ee8192be47fa8757
91f32f56d5e631d237060688f052426dee5b0b2b74ca5f830e82a453379eedb541fa 91f32f56d5e631d237060688f052426dee5b0b2b74ca5f830e82a453379eedb541fa
4fcdaa19dae6509401e3cdd4c40f5c9243db3f6d7115c4e8cd6db8290723ab01d9d0 4fcdaa19dae6509401e3cdd4c40f5c9243db3f6d7115c4e8cd6db8290723ab01d9d0
d7e355a97a01547800e43f11736668c3f8908848d759c33a67a2f506abc3f6871cbe d7e355a97a01547800e43f11736668c3f8908848d759c33a67a2f506abc3f6871cbe
625b1bc71eb06d785a59501396712c581a60d6ccc450d2f4eb4cf08ae0dbfa45c286 625b1bc71eb06d785a59501396712c581a60d6ccc450d2f4eb4cf08ae0dbfa45c286
0425be90cc4cd4c989495bbd2963e19c59ae5d90d1ca884e80d654b5f2cd6a80c358 0425be90cc4cd4c989495bbd2963e19c59ae5d90d1ca884e80d654b5f2cd6a80c358
8b514ee91c802736f594c340397b316a97e9c70b0609955b6c3ee06f4760d9377f07 8b514ee91c802736f594c340397b316a97e9c70b0609955b6c3ee06f4760d9377f07
97a0411a244db395bb8b711ef79fbcb5589226174029be79a72dcd6f4ca566b7b1b9 97a0411a244db395bb8b711ef79fbcb5589226174029be79a72dcd6f4ca566b7b1b9
a27e43b5c02a9a579d60bdda183398d66d76e0e8eceb1af2f27633589d043bcdc041 a27e43b5c02a9a579d60bdda183398d66d76e0e8eceb1af2f27633589d043bcdc041
683b31f7f1 683b31f7f1
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="rsabssa-sha384-pss-deterministic-test-vector"> <section anchor="rsabssa-sha384-pss-deterministic-test-vector">
<name>RSABSSA-SHA384-PSS-Deterministic Test Vector</name> <name>RSABSSA-SHA384-PSS-Deterministic Test Vector</name>
<artwork><![CDATA[ <sourcecode name="" type="test-vectors"><![CDATA[
p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305
59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca
7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e
41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10
8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048
b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632
2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401
7e32ebca06308a12ecc290c7cd1156dcccfb2311 7e32ebca06308a12ecc290c7cd1156dcccfb2311
q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8
06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945
skipping to change at line 1413 skipping to change at line 1204
7d9286f5c1d193f1454c9f868a57816bf5ff76c838a2eeb616a3fc9976f65d4371de 7d9286f5c1d193f1454c9f868a57816bf5ff76c838a2eeb616a3fc9976f65d4371de
ecfbab29362caebdff69c635fe5a2113da4d4d8c24f0b16a0584fa05e80e607c5d9a ecfbab29362caebdff69c635fe5a2113da4d4d8c24f0b16a0584fa05e80e607c5d9a
2f765f1f069f8d4da21f27c2a3b5c984b4ab24899bef46c6d9323df4862fe51ce300 2f765f1f069f8d4da21f27c2a3b5c984b4ab24899bef46c6d9323df4862fe51ce300
fca40fb539c3bb7fe2dcc9409e425f2d3b95e70e9c49c5feb6ecc9d43442c33d5000 fca40fb539c3bb7fe2dcc9409e425f2d3b95e70e9c49c5feb6ecc9d43442c33d5000
3ee936845892fb8be475647da9a080f5bc7f8a716590b3745c2209fe05b17992830c 3ee936845892fb8be475647da9a080f5bc7f8a716590b3745c2209fe05b17992830c
e15f32c7b22cde755c8a2fe50bd814a0434130b807dc1b7218d4e85342d70695a5d7 e15f32c7b22cde755c8a2fe50bd814a0434130b807dc1b7218d4e85342d70695a5d7
f29306f25623ad1e8aa08ef71b54b8ee447b5f64e73d09bdd6c3b7ca224058d7c67c f29306f25623ad1e8aa08ef71b54b8ee447b5f64e73d09bdd6c3b7ca224058d7c67c
c7551e9241688ada12d859cb7646fbd3ed8b34312f3b49d69802f0eaa11bc4211c2f c7551e9241688ada12d859cb7646fbd3ed8b34312f3b49d69802f0eaa11bc4211c2f
7a29cd5c01ed01a39001c5856fab36228f5ee2f2e1110811872fe7c865c42ed59029 7a29cd5c01ed01a39001c5856fab36228f5ee2f2e1110811872fe7c865c42ed59029
c706195d52 c706195d52
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="rsabssa-sha384-psszero-deterministic-test-vector"> <section anchor="rsabssa-sha384-psszero-deterministic-test-vector">
<name>RSABSSA-SHA384-PSSZERO-Deterministic Test Vector</name> <name>RSABSSA-SHA384-PSSZERO-Deterministic Test Vector</name>
<artwork><![CDATA[ <sourcecode name="" type="test-vectors"><![CDATA[
p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305
59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca
7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e
41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10
8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048
b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632
2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401
7e32ebca06308a12ecc290c7cd1156dcccfb2311 7e32ebca06308a12ecc290c7cd1156dcccfb2311
q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8
06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945
skipping to change at line 1553 skipping to change at line 1344
a0d5b0bae3ab085b658692579a376740ff6ce69e89b06f360520b864e33d82d029c8 a0d5b0bae3ab085b658692579a376740ff6ce69e89b06f360520b864e33d82d029c8
08248a19e18e31f0ecd16fac5cd4870f8d3ebc1c32c718124152dc905672ab0b7af4 08248a19e18e31f0ecd16fac5cd4870f8d3ebc1c32c718124152dc905672ab0b7af4
8bf7d1ac1ff7b9c742549c91275ab105458ae37621757add83482bbcf779e777bbd6 8bf7d1ac1ff7b9c742549c91275ab105458ae37621757add83482bbcf779e777bbd6
1126e93686635d4766aedf5103cf7978f3856ccac9e28d21a850dbb03c811128616d 1126e93686635d4766aedf5103cf7978f3856ccac9e28d21a850dbb03c811128616d
315d717be1c2b6254f8509acae862042c034530329ce15ca2e2f6b1f5fd59272746e 315d717be1c2b6254f8509acae862042c034530329ce15ca2e2f6b1f5fd59272746e
3918c748c0eb810bf76884fa10fcf749326bbfaa5ba285a0186a22e4f628dbf178d3 3918c748c0eb810bf76884fa10fcf749326bbfaa5ba285a0186a22e4f628dbf178d3
bb5dc7e165ca73f6a55ecc14c4f5a26c4693ce5da032264cbec319b12ddb9787d0ef bb5dc7e165ca73f6a55ecc14c4f5a26c4693ce5da032264cbec319b12ddb9787d0ef
a4fcf1e5ccee35ad85ecd453182df9ed735893f830b570faae8be0f6fe2e571a4e0d a4fcf1e5ccee35ad85ecd453182df9ed735893f830b570faae8be0f6fe2e571a4e0d
927cba4debd368d3b4fca33ec6251897a137cf75474a32ac8256df5e5ffa518b88b4 927cba4debd368d3b4fca33ec6251897a137cf75474a32ac8256df5e5ffa518b88b4
3fb6f63a24 3fb6f63a24
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>We would like to thank Bjoern Tackmann who provided an editorial and se curity review of this document.</t> <t>We would like to thank <contact fullname="Bjoern Tackmann"/>, who provi ded an editorial and security review of this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y963YcyZWl+d+fwjv1o8gZAPT7hVNqNfNCicoL2USmVFVd
vZLm5uZAFIEIVFzIhHKpnmWeZZ5svm1+CY8AwExpZrqn10JWiQQDHu52OWef
vY8dMz89PQ22i+2Vex6+PX8Rfn61WLbh+eJiaba7tdsEpmnW7sMDv2xXdmmu
+Wq7Nt32dLHedqe2W1+crjfmtNHVp5vp6tM4C1qzdc8Dy58Xq/Xt83Cx7FZB
sLhZPw+3691mm0RRHSXBe3f7cbVun4evllu3Xrrt6Zd6QBBstmbZ/miuVkse
eksLbhbPw/+2XdmTcLNab9eu2/DT7bV++O9BYHbby9X6eRCehjxq8zx8eRZ+
6ZaLTRDyX9/0l2uzfD/7dLW+4EOz2V7d8nh75j9012Zx9Tzs2v8SRd0ZDTq4
5R+NXTWH93StWy/s/Df+vi9ubq7c3dsOl5/9m7/8vxhddWZX1/unfHEWvjgL
/7xatbPHfHG5Xmy2q5tLtz74rX/UF1erXdtdmbWbP8qaj//l0pmbxfKiWWw3
viuBZmF9bbaLD0xOGP5+tbq4cn96891z/83BOj7jg7C5HX4bvl668M+Xi60L
35gbt/6sv9SsL9z2eXi53d5snj97xjSdXfjr1Ztnplntts8+3CyfXa4+LrZM
8XuNjR+UN+vFB8zirbsyt4fPXfiehMMFob8ifP3BrT8s3Mf7n/vx48ezaRCf
Laxu8Axj3Tzrb/bjcLMf/c1+HG/245fOJlESn920Hfd9s3bb7S39bd9c0hP/
HXvUuP4aDQot1FXhcNnDDdttsLWfzpikZ3a17NzaLa171n+6cXa3Xmxvk/jZ
DS7jlltmZbV8trGX14vt1t9zMmr/32lvH2/OwvPZNdPnn5+Fb83Fpflglvzi
z9/W9WH7f1i+X64+LkM87nRzibGEZrs19v0mXC3D7aULN30LTrer0+HH8Mn5
9+dPw5v1Cr9bXfUdxeHozJYGj07rrzVXWCWzfLm60Q3f7AAFG37tbsMv1rc3
29XF2txc3vo7eGgIX9vtqnHrkzCu6/rh7p6fAUbmvTv98+Jqs1oe/hJX+NYt
3V+cjOvrb97+UxIddvo1LTGLNT5wiqe6Y1zTSLprt+FufgheXF24Zm1o+O/X
q91N+O2qdVf3z6+74a7bs4Wxaz/BWFP0LI7KeNbFc3ezdde+k/r1w53841n4
NTi0dOs7n3+z2mwOP/yWiV5hMNz34s7l/7Tjoz9+/XWcHQxE+Nnb1Q6Mfn2z
XVwzVW/MZiPcPX3D3Dq7dQyKs1h4eI5pMFwh6Bt+f/rmxddfjYMzfef1EsC8
/luGJs6eFXk0G5kXuwtigIaFUPGpuf8jhmrfL4bPB8D74YvwFW68dCfhFy9O
wh/OX9wxi68X5nZhNkffW4J76w1eF6668AWdWhJEfo9hWHd4hz9wh7X5aP9y
+/7wFq8+/xZc2jiztpcn4Xf/PD79m9tNkhza3vng4eELnON2s9jooQTX08/P
z1/8aqNKnlV1/vAQ0VUefWuWm/fm1vC7z78516TerDbm6rA9/23Aq9MbJvK/
h1/95H33KmRIFt3CNIsrGvs8NCHuLVNwcnx/n/sbqzCjYWBMzxZu2/kW64Nn
15sLQG3/sGeff/n69eX5Nx8/T3c//NF2ny82m2L5w8t888OLZzOr+OPu6vaX
XOXPdNi0in5vVle3WLN7+/r8jtPLXp8slk9HlPVD//r8b3DlOsv/xpZBDz53
y0tzTdgxh7/6nka7mxVP+XX+/Xq93t11enP7fvVBd5YRvfzyD4e9fovHrq75
qrFXIJoA/g0/bxcWQwhf4L5r0y4urkMYACRIbE1+/lXXLewCNA/fDDC/uX+U
7MZ9dM3Zzm7aM9funv3H9eJysX52I06webZeDaH0Pnj/hP1+q0G7mrjLPMq9
XV2Yj0Yh44tLs7uu0oP+HjNU360fllu67ExzJbi6vaZbmzudoS8b6/vCX2e7
S3vl+4MPXTzbOoNB84Pd2EWepNmfXTP68UtzdQVexc98c+6Q3rM3X76c9T+u
q/Thbn951nfqU/j0hbla0KnlwpyE5wZ+EH5u1g2zOGLOW3cNeH+/uKbBL/pY
fmQS/oKwvyIcLjm0jAfm2ofsM3FwWjDMdwupG6d7s7k63frbHk37t8b7SZTe
4Qpxsr0Mf/DcJ5yg8fz2GoRZDAPx0FB9Dtu6PByq86FpszG7+7X17vrK3f6a
L37/L3fQm5ZsP0keNiHM9hIcvaF5y+0CKB379Tege5SVc5wxy51Z91CTfDIw
fu82G7NefcqA/mw2suXtMWtCYfzL5e5Xf/MHgKGXC9Po/HDqP3uQ+F4v7Hq1
WXVbz8rd8nQHQgxRk8iw+jcox7Pd6Y1uMg8AL2Ffu/UwAPEnBuDb8QGHvZh/
/Pu355/Hhxx4j3XfrQA/4p+84IMLv3DrLTHQ9qy3D9Mif7urhSdCn7vb1bL9
tWSnehbl5UNwyO8/zXZ/v7pq71K7b8BDd/uXxdFUvkYMmIuLo3CjSGSu2sX1
drMIgtPT09A0GyEjCvD7S4gIAmkncAw3N87SccWLpQ8rjdnABT22hRO2TQrg
zA/M0W/xA5RN2C3Wmy0Cc7tm3KxucttjnEfm3QyZbwZkRujOnrG9NNtQJGm3
vdltUcoEsy2NDcaHo2iXYeMGvsIDzNTqN+fn+zudHXeSn426QLO2mlyRg16U
hC9XYMRE6AbW/+SLl29//3Skva/efv/yrB/F60XbXrkg+I2ET38/7CUIXq8X
FwuoFLR41v/h+x4Af/IPJvwutkYd2VyGm9sN4mAzDVPw0DCFP/88BMC//vXk
/gngzyVPZOhCOoUGdIEBnVoXrolqTs+WSB4MfOM/VUjwgzwxNXmoaPXF1NCp
CduVz7AI5gYnuXb20iwXm2u1b8oj/PWv/OuOyvef3q+x//pXxvYt/Hu5FcPy
Tuk2Ww3enV5eMuEXa2lYOgkH5DPMhXg0CtCNMBvEoQubvm/zXgfewlDf4Z8G
xqvkBk/5sFjtNuGbjdu1q3XPol7ulrYfqid/ev3m7cvNU3rwO//jb1+dfnm2
z399WN2sO03MZmcvA1o4dMzLJX3pzdtXf3rxxT8jpc7P++/ClU+HQRc7Ph0N
nLEIz3uHtDKmk7B/to/Yy9U2XDJOQv3F1W1w4wU2Fvdh6swJk2I8qfM9NaOn
rPmia7mN1dc1eLJLf+9+8uEI7xHq/MJ/47YfKV00OKPsZ/rC4I141QcYSuvd
24QX4OiSaeNygpP87wp+MOQRmJN+HpRJdDdXq8GsPl4KORbeRdXBFlq69vNC
W9oFmLVodl6ITK307ZcdboVaTL4SWupz39l+rs+CF2276K3Cm1Xv9PPO8sT3
yHMZmgn/YNbtR43yREw8+DOi+tpyJw2vQZiMbRMMSZPhVu2K6cAD1VHu03oL
DTc+uzD0ciXV7FvRp0aGb67dv+8W+oaG8bAPwaulR4+1kVQefXLmEIqfcnKh
mwZboWyE0Xvsw4eyduX8WAfDg4+sYj5Ed1rEqKwdIZsw9vPPPsmAZ+N0Hzf9
Y5UUE0ivHYbxF2FQbzMDEh4olD63IvS77MmGxmvs2um17PxCGLjgYf0A+hzV
FC4IDBrsnVIXu03//RbRKmPAcBjgB4PYJ4Lg3rzV+f4Buve9qNs/dow/bmlX
LR+cBBpmE3bmGj+V1XzAY43MXfdUSJuewqw65oIucBelBcIn92Tfe54Jqrpl
u/jp6ZnsAgaLSTJpnbES7pqzvWedDD7Vum6x7EOR4IlWIajCybvpxO7K9+/J
bum759qnwX7EjgOub4cJfWoej5m6frVoRNruDOzaDanNzRgJ+cdmt/n1Qfgs
fKWOBAIHGvPqq+9fTpFcwzzgxr5NZ4rOb3vT7jHmu1UPQmpcb9dKYm3Cz779
4fz7z076v8PvXvuf3371X3949farL/Xz+R9efPPN9EMwXHH+h9c/fPPl/qf9
N794/e23X333Zf9lPg0PPgo++/bFP/Mbtfqz12++f/X6uxfffNa7xnzMhEKM
CcPuY+GNEjGiOuDmxgKH/Wx+/sWb/+v/jDPc8D+9fflFEse1j7H6RxWXckt8
Ztk/zQNP/08G/TYgJjLQHviuxEVuBCubE9Ep+fIylLedBf/4OwzChafF7/5z
oEE9HMdudXW1+uhjDS7Xh6idqOP2kum7uPRU5KBjQvShCwPSDJ42A9Xj0XgO
7wIiCBs/blc/LpbDpC+3+qf/HDWzWmKgsgF9ECpmqFUrf2lPArCR5enSXfh1
Dz+uF26tdZlP3tr3aUHg8obU883X58mrN/7KV8nr8zf6aD4v3HKYhCguRQow
f8BFj726PdMQusn74CHdxDL6MVCQmPdCuQsRocXFqVzfDL/0vn/GyPRk5ceh
Qz/ulsoXXD/59iT87unz8Pdu2d/UDBeehMMV2MM+uLbjgIRvNSJu+9ERyL/l
U3sFwn3ow8Z3oftp+DfgcubOTrjkH38bvg3/MfxObWkW2x+v3PLJ8qmmxAOz
n2bB8TXuvQ+iWo3yjKQPkxNI9Fax2izmsxQudfOFpnjjfrxetU9+OgnvPEMo
NhA9/1V/tZ71k/LUoeASoFxciQj85PuznEiVXYmMXTv/nM2PduX/NT7mrRO3
1pKlO/7y+MXeyzp8iEfSnPXHxcbfTcOx4R7yF36+ADw9kZrN8ImfX1nbfj79
EE6Ttxw+7a+aQp3dL6r0ZPHUpzrdePUw3Bf9bVbeXJTXNdsnP0Un4dkZE/jT
d34c9aFbTtJ3bn9nwmZm3sgLTjCP4RbRT1F8EvJnEqX+7yzKo+Jp+Fv9HOvT
/hM9dcO8+OFcnIT/th/RvjsDM5h77ruf3gnN19tJoKy6buO24bvFOz/ScgWN
gUT++Kt/e3eyN9jDVg8NOGzYSUj786HBs+aCc8fBd0yLhj//xkJ/9my9B8L7
4vWbGUc24fYjhkJ/bveQN3oZ83jl8xHql8SXWwcT2bkNxxSF3GQgO+E7wjPN
1sOebN6f9Iz7x+vNxdN3I1F6N33GhcguMdIn/opgkMKuJ6k+49PP+pz7jeTr
Hd95N5JMr+d9FPct7o3+3eb9O3WSz4Px22NiWZH2+Lt9F1E5zgGUFtg+XS1a
opWYEewNF/XLkYSh6d6DCbvW8yofY8YwsU9L/HAzqgy3nXp0QLT2j8cXzXrp
icOl52t+1Mxm1rvxEg32OzjIMtQELuzuyqxP+jtLam0evqta4McvoGf7Cekt
+O6D5t+i32e9be0zH8QIANsTp261W88ix+npOMUnvR0Of8lA+kl6qdQEdFyX
6t8D8ZeEAS60LKjbTukwhaDBPO8Yp5YxtoNdDGG8v+YfNpP1+L4Ggw0NZuIt
9eb90+lb/e1m39JlM2Ek3n88CI27WCw3h2Y42HKvefeW2xMoWWJvexORh1D8
x3/8R/CQg/hf+qcOt1fKgx4RkqRde6x6QFbc95yBU+tJ8tQPPM5PzpObA8+9
/7HERGjqu9k93o0qrR8++fsCwuyvphnScUMjh4EIHmrTjz2KTJbiJ2j2pFmT
BvO+0yTdYmrQCAqzBnWD2W0O2d49LerbMprp4dgMrdLD/AjOGrbPTRw8AN88
9rfBjY9A4oSf12vY2VL6d/QKz8+Cvj8br4D6nMhsxv3twtUwKns4nXBz9vg+
Xu/nLJgZ+bsbEK4RzH9YvR8vI56c97Lq9E9fvX318p/lolsx8b2YC37++dz1
rlqdxWeJxmDPOs884Zi8foSKMVey6fHLXjr7Hi/hIwlBxeSppftMag/U8yTA
ANbX+tqI2L7aZxgn3eQwRdFnQwddcATcPsdxs7D+4pPDiVzv8HazGaTGZjCW
MAy/8JPj7USmGt7737kf7hF4+Nrp3/OfJ+APYEUY/lr3Du5v4sENHrxm35j/
fM+NfqU3P3j3/Q0evOQfZ8PBRX+Ht75aDumGa6M2rafwvOmtGNxwQxamB/df
GdGCfRjsM56jCL1DECB2vxnvCpHrSfLiL71FB8G3Y7rJX2H6No2pmeagTZM/
nQzEZ0ReXTfB3wTAB5FIbZ+SKb55A3LIo/wgjni6DzLyp303vvcEz+cIPnLl
7Y3znGDW7j01eK6MCexLudLbey8ZU1XjcNCS+y7rAeWTdxoQRDn2gQFMaKik
kc8G8JTNUH3oR8+LyHcHjvVqeEbPVgcC8AutC83u4nrKMd19tmouN5fDXQT1
Z8Gf3TC5k5WME6hbTDd+N7Tq7diAJxPN9tNs3jsPUP0zzTTn76bAM6Df5nCM
74kTynNt9smGvoeLMSHTOADwrMe/e9skF+NWYORp6N3wPiJ0cig9g+C1D6D+
SzMPPsqjDOnkNBkU29VqeeEDH8Yl2ArOt+6Ge8Rn+uePzFC3+IkZHbRsmjwN
krMDEB005P7qHsaD9GwM6dPVPXz8ZhRlP//G+8WgvPrPptny+dd+IfPQCDQR
/nsbZUW9SRxSUB+RVYnss419G2ZcbzZjw3AO6aw5E+uf3q9JHgj8YCL8Ihsb
KIhXr0OO4qRvbp+QUuz/05vYN/irbwcS8NV3X7z+8ivv8mZzLwfYhPlZAgnQ
12roQHxIB46SUJjKAL7TyHU+iPfJ3WX4me+02ujW69X6s/6vkyPj3IRD+hPH
X98GB35jLoD5HjRwgGaoLPPrJ0tlr3ry4BPS/t4+DbCBf6k81qd03cXV4mLR
XLmzPqM83Vp8zFxtVn02Z2oyo+mXovzETy3u3VSdsQN7H9YoVt0epzbhk6vF
e3dnbeZp+NG7tr8xhnF/73c3Wt6ffVVmNLIq5WV6H5p3YRidnln1/Z9zqqlC
W5eKVwWtVlO4je/tbNSYynlCcf4MzyjpcW9Q00js7cdb7xqVzeitboblU3/b
oI9Fs/HcnIV/WH103sz9Y/x1mgqlz1bWokf7soFBuQ9mvNgM7WhPgs1q/tUh
a+8TNu1+pfwKiSsrGYxCDfE+PiDfnlr1kKeCtmut+PSwpwW73UY5yJ5HDhm3
Mb826gTla4ZrwyXf+4PZXPZf0DrUfgj7ZPaq/3Qe0U/Db3//sv/Gtdm8H/MT
85CkrJe52v5iW3RR+GTkGZtvvNYMB889AHX1ehBiMwHxhNu7p38v5h+w10PU
p31Dk2fD2udh54g1DdKwenS8RLfcM7XgKz+peu5n+4aufDj57Hn41ix0K61S
3BPGRbSGa8Mn6/5SgvURRj5VtvGzcRluQK9funWPfdOXfunuR9h4392n3PPk
Io2WS3ay49NjqLp7g1mf59np3vu1KLyPt0PMGcLqUXuf9HR8yspLr/Q36S3e
G7HP7AyWehheekibPEwxnLhxHJX8aPmQO0Cu/8B/t/d0/4Dt6kbB/ZpGzhdc
nsza/zTIzkLLBbMM/LUy8EHuH2w1Hj7FPj7jIdhXN6enFmfMwm8fWieJ/QPK
s0G6zRcZ1v5XlX/27PPeXOZNuDdYHrShPgvFh3pQ9PC1fhrE0Vn4Fz59ch3+
b+FPT/tViiBmUmde6du0X4968peTuTtyk2RiTMdKdJ8lmRrYGbtlRtahX+9s
Rl5N4LOX2k4wrpUNo7NfIfK1CD4Myw9vb/r1hrBVJP2wgNm6fxuSERtl3FUT
uudsEm1BMP04T0L0WDwvOJhWAsctKWNyMTgmYgPl9tlMLzzm1SoPcbGzQMmV
PjIdGvs+nyIqdUSg5uHnAXX9/0YomqH9Zob2++E5huypmyO/vUtUxxgwLHU+
GAV6wf5rYsAcx0d5KqcA7+8Bs/GK/cR6B5oHgWn5r1+7W/UZPV+29gl0PPwW
3aPDethUELCPUWMyOxqW7k7DeA7zvUk8PdAxx0B1MNk43ab3Z77nbeHaa5fr
fzj08o3HNPDjOvxPv+W3I2rcGbY9VORnB/mcA+ffHDl/cej7PoMzqqV91J2y
gB4opxz2pH16RSJUHUL4YfqYUR0k7Lw652RMYnhB1RfKTInUoeZgJqKm7wU7
JWBhsFLbh6vhc/L6cXF11S9H9CWVEwM7iNwqtfOVAktPNOZE8SA3dW9W6pE7
/h3c8QArZhmtEXtcL5Du4gju+TCbnBGmSXHPOeYBWP1dMDWyhMkOHwCqsa5s
VD/67m7pfrrp98f11rfBro6+f9ie/jJV2S3/QSvUKsbtCdF4o765B0zule/E
k2l8n3rImFvlgB33t2ePIElPK+6il7+rYErY9eQvsA45wsA7wKlfgTigU18w
NqDfwSrF3td880U0xYL+Lq5Z+AGZnvXZ8fSdjMjnzcFBCvWoYYTuzvZ+dEZ8
/NNsPSMIXhzW8Ghh+mCd/68nc3Jxz3LTfBEouG8RyNyRRsOK1PfzNUufwZ7X
K2vVd3ftTdKnFE96itaL+fn9vbCHKLj2bFgc2YyrVlqZ7/OR+4cfr0lNObAH
V6WCX7MqFX5yVSrw2uNdDzvvZAB6kKqIzMGC3bBifN5f4ocpCOYTNo3mgwMX
jgOnYpw+FdO6G790yXz3w3dvJnmx8dB9Z8F/KB8+SlIHx9876Rc+demsOXNF
N8/4Hlb3Hj5iyu7eadv9zwjmz+jrXWYZ3TQ58fCyX5FSErvPv9+3gBlMOdKh
mGhI6q7d9Uo25kssh3rVP421rT//Zr0xDd//67Des1/e0epObyaIis5vg9/6
cw3afWlsv+dGtzwLvzJM0PCbfXHuzAZnYPEgkb8nEyrL8Yk/rZvoV1OV8b3L
Chpe7vrE3MGHw+Wjvz49Cw6avBtX4cG9OPxWgf73+0A/bi24v9mfS3+cHQuQ
lzvvuJtxc8Bg5n2UHAiaLz3bD2jfalWW9zBzNN5DPnm/thqfjRNwev6HF2mV
eWefDLF93hf1H9ym7ymXn3J9OFTQHFChk8CPgTeoo+s0jw+RIAX5rDrt46qI
Th8ze2zQQ4O9dT68MPTk2JuYqPv7+S9fvX39P7Gvy9Bd32xv/WXq7v9n/Tz9
cl4h/z+4m788oZ9eYnxyhL+fns3/mT39pQn9W/sZTtmXy2EfydgHX6wyrTIe
7n+YVWFMtSpTtdZhFvRdH5H6gsZ91fohXHwSHrSs84t+1a9Y+LLzIzgadhoM
i/f0QpvLLrQP7vZOND4I9T74D2WGweXi4vLUCRFvbg972D9hYzot9GgL2NHz
x0Xqe1Zp5zUBwTD9ZtpdtM9IzGPCtMtGBaoM/XQMgWk/aCc3DRpXgPzBEUNs
+vnn4W5jJx5YGOoLXDWMPejPR6QP6VPHpj1vYnG/BCQ3/WEg4Vj95OnmNXTa
+h1yXvOttW0zmHaW9eQLRX+z3dwzepth65mv8xZ7mNMKlWL5rdPjZs9ReQaa
7lmA3owrasNKfZ9ifHHHDsYtTQ/6gYxgGIxfhRvBMI4nYSPqL8/ridpifWxf
XufJAMNh7s7Cuw3k2cGvee64vGjxu26nJIjRGSJ/GYsnB2taXM/mPdia970A
1d4Ha1e7fUn9ZrFfg8UEmUT1S/edqmuH2e232B1va7jHMM/CP/vayGnvnlUp
qxRxb5LLAw48VdcdTs1qPbfJ/UQdOfm42Ko0wXJKFRw47y94ruesh2u4HpJ/
8Bd+ofLadtqF0ie7R/I67kXpZcX+sqFoh+50RuDLqB8vkR9pxTvbW0Zg79dB
x9VRkK+9Go/gefHm1dFz++R6n9/oEdvD3pX74K5mdcEjb75f0vb8DwDptEat
hXZPEt1PGnXmtF+CDfbWcbyt54CKMl1+bW7SDVZVDjO7xzR8QkynawxLRYFa
oBXffQrAE+LFfnA/Xfzli6E2blwt1u1Uk73t0/4XO22M9FM0ToqWzNXL22nr
h+L0T5dmt/Gp53H5mREJphWsvp7k0HCuGW+G6HqxPdppcDz//YXr3XJMa1+D
gX6f3H4j5fF3BFHeAvYNmHbL+CL5gdP/ua8E692k6beqzkwrGGLixo+EUWGF
BkPL834jlhmqJ45mfF9Ht5/6MUEzFdvT52Dq850VsHnJ/pSZ3WfaprrtqTKq
X98clqeG0ox7EhNnWHFf/vPX45qO+0tTAl+a4h96VCo0NGaqR/A1DJse5O9O
N0h61fZVJ8PE+GMJ3E8KekPlxAf1aRK32nLszi6Q1z6PMu5Q3ncsnLZgKuOi
fe2Nlij6MegV9m/8Fg99TWeozfTjHrZ+/s20g+IudUMeX676ysKRox424WCf
hlmsh1WxA9x4+erNeRhXxWlGCPjdl+fnv/3y9auzODoroqR69t2r8+/PdMmZ
v8SvlL247/bjDku/6ug8yfObxpe3A4GZ1fjroI19KmDvJyb49TfeZxnGNMW0
wN8Xu3gg8IVtJ8FCW7LGe+9ublZr0aaPq9ldjr89JGHwGt8AH/qNXzAFyrd+
rc6PqNriIa//3lh75e5Jx6si26zXw7hjhP90lkd1aKeDSdzJ9LwZgxkSIsHr
V18OOw/zMi8UnV9t96MzfoGw/9XS7xyTIfXf+Z2+k1SRn73f7DfAH8ZEbI14
eHoYibC62dljnoX7IiB3KsJ6Su8vHA54s7q6XRKatXd9fhzXMDVTGB9wpg/k
warfJe6PmQt3vmq4Vz/D3bUWYzab3fXNUPG059JDWN3v0Bkpz20wFi31udzl
/x4PZxjMawVnR5LsAILNuK1K4XKie4LIccIxzg4aEExbaOahcJjqJz29etpH
pwEEPaGk1+AfT5G1bFbX2vI31Wvtxy44guF/2OxHc0qHnR1MiIesYVYmwLkz
7P2zRhN5MAEZ6GAscK5fofFbJg7H/PPp83HghyceC4ijPU9Bv3tgFhv2i/vD
PPnhPUy7u5/ofK+FpuK0mSrbW8Z0vOWY3Byq/ozf9jA7e2HfL63cra76T+8M
11xQPZgR/j+YG4m7T8g5jMfuNpup2GG1GffjDwxvOLXrXDzmCwLP0mmnhQiQ
0brIcJrXvLZitojqub3xmms7yKZ2N5Qk9tgLcbid7TkZCw2CgzoMNMzGlxxq
WYd22L4dauhCO+77ck1vfr3cWE0asp+tffGCl3iwjdVG7fj553sOL/OwdX+d
5RSSew/xBSpQhYNG9ceZhjoH42Kgpf2hB5v98Q2eVh/lc8fUaxzpliDiQaPG
iBdHUfksPc2z6LSoiro8zX+s1eCX/Sq+33CuMe2fuW+EZ3TBSIDvafCeIr8/
GLRZnDsgjB9db937neQjxkxJh3HD2qHLDOsmw4oIpCNYrkKdCXvl2v6MoImk
jXsd/NlXnjvtN+n7uvfw5grR49fpPI/yJ0Dp0UozWOMLm/feqF6fjr2eD01P
kJuZJ3oL6ulUf76c/3JgRwcYtxHdaSFj1J/SNf/eONQbHVjyu5cvfvjm+/P7
JrSO8vQ0+lHnJoymMWwnuBYfkKEH2iN5SAyVTrrYmXW7T0N50/cVvmiJzjvq
wSxP9cvjdN+3bdarlI2b33/MbNxLd/utXEenegSru2fe7Mtw/EyPjxT36As4
xlWh/jCfO2UuJ8G0qsizro/rXfwREvMjbWC/Ezr16ZDbqR76ibgR1xF/6cnT
YOpsXwDeH3TkzyQaDMYdjueJJ92HCm+eahk0XjBVJmswviDguM18JxKf4g3X
PeSO24DerprdxlezQGjRiJvNcL6fDkR1656/PLQPdEjUjq55X8gbEwPTLk03
7pobFh89yNnFGi3Xw+xm3HVsboeFbu2icOs+yWDWzWKrE1j2BVf9KaCHOaig
X/h9uOGbSy91egfHHsxuGFCduLSZDmnzCDc8AdDpsz9GuS2dvrc/z2qcqrPw
K3172k4yrwyTWU68fQy20rEjme5PADhQCToSzkNEH5vCB57q585cDSdUw1w2
qyvfob76vd/4g3K+ni8FztiN7/eF/2Kf+NT1fub6PkyLrvPpCz0YXl2dbrbr
nd/W2Oog+pvh0ILVnaXbk/Avbj3HYf8QLf5rKvqceLe7mp0dtFsTRJ3uqnSJ
ntwf7dO3rj9BT13aWIx1/70p6TQup6tHw4zvEcQfSDFC91hV19uJZ8qwnJNZ
pna2uB0cdXt4spztyn3wiZl9r48TJ91xwvB4A38wZRAnCj7UKo0P7D1htlLg
WcIg1T483ONgz+nb/uiFwTr09UNc+GpYWvj5N8fErq8i6SndmHIbmLHWMu9Q
YMUBiSnf+L7aqRciM0k4LBkFC8+rPILc3R0SXq0+PrDkMa+w84By+IzAZ3oF
KPLf24W7asOj0plNHyeUwJr0zP5EhSHD4bzrTzbRV/r1ZfXTgXIzkj5MtffR
aSDc2s5PE/BbCvp7bu5vtm/Ona73wvzW3/Sh8TrWGePaQnDAlYZd4s6jyH5X
vpkW92emuWcxH3ZXyrQM59cNfHQoqz42gWC3vPIw059POXxnDrNuIdTrl+a/
37da2aJDIBrueFjGw011zKJ/ucWUj1MOrT8XFaYzns2lPb0yjyc6JWl2KurT
4Qan02KPkOr0GKnGE85813QOWZ8sn0ab28+SeGNnDtcfL70qZpp37rhXvvBl
OY7Pxc6Xjo7Jm/lsXvrT3oEulSWGB0uB+4Umf3Nt7PLp3w86wXy48+yJUKbV
evjsWtXxK8VNFRn7hZ9DYn5PbcV9EvGeip7T019YUtWS4C+uqeo2YxLXnz+q
Yvxhz+vYf5+d93zYZ6Nm1b0bXGPT3e4T9uGT5OlM9fUeeLAMLKLWS0ik5Byy
1WNR/+ONaQd3cF03bkX0eYJj2npwfID3jKuP5na+tHgWzFrnV0+GJZhxIWqz
W2z9rI46929bJOwh/+20XXiWewUL6POweumtdXOcHR+OIWqnZKtf/T9eJPZG
1m999XsYhhOexD2C3gu47TvPnVUiN2zY2KfVB0y5cwhU+OlDoIZ0XxZVShEO
yUg/O74r47LI/jnjFpETLT3o19P5VvvoJRIwYps/a3M7AWLQLz1ejSwEb/IY
p30LB9A87jLW08fTwBb7ytw9zzg6kGosxfAlJRMMz5pz0Mz9s/W9qxVDFuo0
t/Ek2W4GJ94HzGCUJ8EDm1+VXDWqoJqWzPsMiD+V82Bs24X0ld9/u/eNfUy4
I+n2aw5Dk6eYtR+1xeGeiDkNPQkaXx+rDM09Z5kc+tt4g/sqRGcRpT82pC/U
kPNoTHtn0QrF+a7BkbY9wZ6SU297Ni9qGPavn9EAye98mhxfnX1rUnY+39qn
wSeiMBqlZmVcsgjQpS90vseLp/2ATvsSfEDrH/hkOopo6t/TfsFjOpukTy+b
WcZ/OjdkWh35+We9UucouSxbN9rvGx5Y+rzdA5UxD7ejT435s1OHo6J9172r
SToNR93uO3g7Z2jXKNVesdnh6MiBQ5jg4Z5P4zSc6HmHe04FGfty881mpwSz
5vvFTFRphr8a10emY5OPTwKdfvD0aX5c6p01p/kBisPZwtPZgYHO6fLLNy91
2vh4zCmutbrm9sNe4rU/Tno6EnQzx+TvvzkP47N0QMIqy0DCk8AvtnxIJ3zM
c8/bddickgxvvv7i/DcxD9u4qw5ksHa1bodTJocbDVvtP2NoLn2CarkKzOyF
C70tjpmhceWmv++H+Cw/Gb15OgHbn8ll1WEB8ZSROAnGU1cPBupoFPzKkyTy
TsnwdjUtkizdx4OYePaZ3u115aazXBFyPj/dM+CfQn/Qw9327o+7DXfNgog6
Ler0h7H3C2mCqyu/rb8vvG39a0f4yy42E4LJTvTON524srnx7xmbPefS+BPJ
96miadkjGLIxi+HlH/cckMzk/PHrb+NqyvnFWf4sTbK0TLMz/3dd+YWvlzsA
6suVskJ+z0L45OWXf9CZ38OrVhjhyWA9KdHKyuDyJ0Nm1R+I3ZfliYve02LZ
Sz9zv/v661mrlIncRBGNO2U2T+sk5w9BzaSaaIJmxiuG6fhdv59tte3zJzrt
3fM/6e2+ZMPZy+XqanWxkBbcJ5CHex3wnwFzTe+b0zLoIUcaTjTpD3Twn4xj
MpCmNyvUwn/dMQL+PF/TLvoc2veXnzg27cD5D4+MHRmBbvvvw21pZHs7RLbF
VgcaThm+t1ox1ns7/mG+cKb3lIzlBWN5nrm64B/by/52Oqa5r/be9HVCL757
cX9N0NSya3/2y3LVXytKictuhtcENHi97vO93PhPTg8+LiqaSn62uuZDf82U
MXlwrA5Kxo9Kes6OzuWd18jva8dHbJAOmD3bH7R7cxL++0moDRq44vOD3blH
x/MRHvuP3j+dPedkqO+Zb7+9hKvJ3fXSsXEXrt9zppfHjRLwLn35xZt4Eemr
dX32+uAg8KFWd3jQvw6nzDyf0jj3sPBf8bi+Atcv2Y4U1R+QPigbLw9nuu+w
HvTeY5U05MPWi3/90Q/J9zM6h8Huek4/5oUPyt72qz2/+ESatq9N3g4dwWTp
ntLrGz8lotDPB9lzdXs6qwsUt95Nu932Z6IfZHzO5qfc6vY+eRFmlZRDtD/i
dhjoob/jeQLT+E80//tPbJHU/e9UZg/HBB+O4bTmNx238yuMc9jP+K+zA83+
Vdvnno8n2vS+OBB791NfqtyG7W46h7IfpKFmOJw/9O4j/bBMtx9WvO9Q8kGV
fjJfMMMbv9XtJvxt6OIua0uTZlWUuKS0ZVonJrXOpIlJCn7MWpsWddy0Vdml
XRpHrS3zgvhYVXUa5UFe2ziJujbK4iius66pTNSaPG/aqKniJCldlaVda01R
cGdXRS43eZvFWRwXLU9NO2uCsq1sGjljjMtLl2UmruLCNU1u8yYqosLmaZFk
hS27OK6rvC3TuKiyOI+aIrW1SU1buyCLmyizUZM39KOJq8rwRFtlRV00ZZaY
KmpT20aRaao67pIsL7MsbU3bucYUbdGaLo6CqoiSxiVFW0ZlTOtsUcYRLc6S
okorV9DrtlSfyqxJ6iTLrOtMl8WVS6u4SRmKrAoa7k0bs7hO4jSiiUXkXNlE
bRVXSRQXeVVknevqNE9ofpHmNkmSOKrzwuWpqVo+SoIkq9Ous3nVVhndr1yS
MSZRWbm8sU3eJl1bVMYVxnY0r6sLep0ltMzUbdolZZlFcVC6NHGNNTQiqkyc
OGuTOrKlbeM4L1prbdckaRwH/66Dt4ooNrU1jrli1qs0r5KyydO6beq2K/i/
3LiypNMMbFlFtk3TzERRYZo0T20VRAXD1BQaORvljHCRR1USt2mdZXmbmiav
Y9fGkSnTtO7ivK3SzsVpV5i0pR1Ro5fqJbYwdUNPjMH+isrWZdR2qTVtw2jW
XRVlpq2SJG3zIo6qtmtdGjWmbNOidHXDzQ0tsVnXNoYxqtvWFUURd5h2R+cz
rLdukyipu6Qqo85GCc1IcoYx4VmmM3HtrIYzaI0pa8Y8ifm0jWrXFEnnaDi/
jpuybG1V1k1ZYwpZjXG5pk1cLVOJcpwlbyOTBrbusrwra2PLpMT0YpPHtama
OqnyOk3auklcbhnKrHR5LRdLsGZrUsYqzl3ZMsBBZbDgqMAmcStXubjCJB0u
mVeYO45auKpKqg5bKVLDkOL9zHhmkjotTFs2zHhQY840GMOx/AJbrpM6xkzb
pi1rxrWxCXNe5cESWzDOZm1RmxZ3Z17qSEbBM0vcMW2KzgEWxuA6bVR19CKz
jYuTPLI5Rqx3lhk62Mq0U/rvmBhsKm5skYAPKQyIgdOvYm6VABiNM1WX0tKs
abqS4U8blwaMYZLqPqUrbJw6l3FVnecOl+TztEw07HGHXWCvLktdRNeZq7wy
dVYDH2kalGVn07xxRca0M0YYFxObxHoOVoMjciN8HoBwUce3u6jBP5wDfECU
CJQwQQKo1IlwLE8SU2YlWNaWGYBoYkfXHV4GlEZVUUQmygGWTnfMI0ClMEVc
OlsERZXnZVpGsm2DVeVFFgGG1nSMRubSuuzAsi6uMFwMzGqg6tgUaVrE4IDL
6G5QpECbc3GW8ixGJOaWeRuDuKXFlHPgvOZnzWZhu64tYywSB8oS/p+HAtRp
wNe51hZxmmN8WdZmADZDBnxhzrTS2KQETVvsCxiKUuwNx29iRifDN8vK5kGW
2DYDyTvrii5OaqFb1xQtCEUE6XStHCJidLJWw5nUdd20tsAN4yxzVZsnAaAE
CoLTFszNMbaC2GNtJHy3mLtJ0xwQwKwLxqOKmbMkaRhXy0xWSQrQVvhHlkWM
fU3saGvcLkqiGoSwBW5AIGis5YlpnCdx3jG3DT4SN9w/jzsaoRk2ga06ADCq
CEZtljBPlolIwYPY0c845S/j0F/8YeIMvLAZppM3VWrjunOAoe2CNrZtkdSt
SSyxqHYAe5PW8lhhVleWTZOWTCV9bNKC+BXlBESDHyeRaxkYAlQQ4WtNG5el
LarEYDula2KwMHUdc8yUVxh6S/fxmKLpCMeNIRRUWcf/x7hM0xGEiBhFbPER
WtER4QAPgI4IYtu2jVvmLc8BPlt0xLGkwGrKOIlr8JD+NGmTJnWQVQ1tbfPA
6Sh8hCgxpdWPbYY8xgfAb5Ab3+zwbaCSHmEbGRaLsxGEIwyFzhUOLG/jwghz
yzIOKn5JHI27iHlIuhqjaAnzCaiFurWYT1KYLMc+DeADlpTAd9oIvAhSKc+L
2wAUKYFT62wZE/GxdQfMY3bEhCbKO5pGOI4TSwfx1g70SIoa+UzUr+gZCN4F
jabRn/3vmo4QyLwAYFYhteKWPLJMwUoGmH5U1vVupv42bdGVVQbaBAlhvcHQ
6ornVUWX0HYbtQnPU4dT7kAoMobIqbkz4HXiAEeTRCYDvEDIMsCqE1NHReLA
jILw34idVAQX16RRC+5VYH6ONZeGQWeOQFFMHJ5RF3nGzUthDNEqQ4PD4TKe
WsadUyC28LQG6lTXMtnM2dg0uCh8hGjbAGFYlHC0goMRg/WYvOJ3fEbMx0G6
FvJX0RKYCtQOR80qzArYgw4ZED2DXjG4WcFMEC6CWjiegm9tnuWYQdEqvDGm
HTBU0HhIDZ6kQAefxGagj2BH0VkQx8YOB6QldYUrKGpYyCKTRhhN26oDr2sA
MLaEeyIsjILAjIc0MQAURSBzjuHiM0lmAzy87jpYYoXXFwlQCRLhOUxyDhaA
5hBLJgHm2hTQI2YrKwvGoomzKoWwpHEWaACqpjEdVt41bSM/t9CSGgJgAE4Y
bpQyrpGpsH4wiBAptIQ7MR1JDWdtA1CkiWoYKzHNQP4s+NQ2ZZ7x3SSOYQ6O
lkEQYH54IqgF2QXTc6aX+SqYgBSzzxO5KFOFk2CsCf3DnZqkTWpoNrQZbkGr
HUAMzQRySyIJNBQyV7aE5KwJgGlgHZOBAjA0IstFQXt86IJdYTKpEBN8h90j
C0BLOCwBVkS0o6OdA2PKkmgXB/1pZMIj4AQvgRYmCAvif+KIpzW0NaHNmA7W
liZqU2synsZjK1tFUUKMxZhgQBU3tjmOBz6mOHoJgQVmWqhnGxwcIUuEgBcQ
UkCtNpdLFhgWA0LYh/K6GlMhWLU0BbhDyiS4UFIG3Ajq46omGOX1cJra33XD
AIkz3vDvHoDAj8CvGACvtsHfPFYYTHPIVVVW+C1syjCZ4sFNm0YAQgTtjhzP
wM1lKVh8lEYRTpVBjYj7kijC9LbDRAs4Ot0k1sKFmy44PDwQTRTFuHAhElwW
YGRHLKBhRQrnL1v4SUHnO4gvsS+HMCId6sAQuKD9gKSDrOMBdVrinnhyDYS6
ktt2dQc+Vq4knhjuQHDOOryHnnUAUF4FRpGIFkOAcbu8E+eKEki3S1pGB9um
wVELQ6m9AquN7BgYQezAzGNctQiqDKGV0+7IwdMzBBgEpbIWsZU3mZyR7qBc
rPQKMETLIzkX8TruiiaDQNcBUAAouhpaVHIHxrPOpOq60kFJIK3ABvSOaUMH
A3ngZtvCtTN67QgvEtToOt0jNRGPNRDIgqCOs8XoN8YIcHQWutzahtDalmgS
S3/hxZq8riSAxrkJXI1V1eAbUQbiVKF1QL40beDBDWGDjyv0kMYRqgRHwgyI
rUYypiOK0Mc0gApBVQhCWQsPQgjZsnW1cQgJWFGK4cHQDR2FNjVqHTwdNmRA
NG5UtRG3DUq0FXqPwFyCoNAX/g3E2ZIx5ttpAvrAtGDGMkxpQi6DQ8GlGBM4
na3bgKCaorVFW+Mkw3iBHFAGdsODUdbMKW4R1VXpZV3UwXXAW2g8PkFLcaco
aKHc6E3oUNLEMEqTtNCbLsa00GtCOPhP7DVhY6OmzRuEM0TMxJBTApKkWFAA
AUA2zAjvjAjhBRQTCpqKKEd5I02cOQAdJYSD15A3GBi2DGIXOZEXthJApsV/
M8Y/chB3KdcqV3gwHSGmLjrGpsAyoM0YLdycqMZteR5RzaWMFJFPYhcnKq2U
XkOAL1NYOc8C/gFe4QQCMNNned7l0EJ4Q04Qh+nhA1nZNQGezwOgVcxzUQD0
ZdsQZuoyF4plsCS4IqMG10oLIANZFFcohTSPFThQGBJQMETMA/fVI3AJG/Qn
YlawdHiueHgGu+QHJqMlisHpENEVJs1TQEMMkphY5pEIlEuRuHDTIGpdXjbw
zRLPg57gIhLlkEhCji1yZCa/hDdAAIyRCcDrihxOg0qhow1wHGANMcjSMtgl
WqIDViUymX3YhksBbKYaD2USkDUMGVy9aCIkCdjbaiowYuIz8wtKOehSkcNR
iqTNuozBiWQ8ER/GNBcChfruImWigDBCv/IfVePKrgvQMWCZa6AQLT7cee0B
xSyh5yVsrk6KHGSPEo/0LcQRgWhiSRN6SYMBIgmzzBBHikYqsskzHh6DmdKN
aIoOphoDG9CINodlQjFbtEKNNSIzIBtRHoHv4p4MqB8/AkeNazDfEQPCFRAD
AAFLQ9XUcNmsMOiTzibYe4xhRCjQjjHJHS0yaV0YlA5sJ7IZ3fVAkqELkNSZ
clegDsPawEwgxgnXNwlT1sJnrJQMWgOymqNiE+hgjUPETB//M+jlmK67jIHE
KiOGJrOiYVUHnUpkpVBl2wTAPwxOw4YZ5Iw9UcTmYvkNfJbuox0yi+AtuhQe
3raImkogYhDnMD6FjwAgLyvu2BIIO8P85fD0nEBJRGhlE2h1vClyrq0dpLCp
GgaM4IgpRbXiXU08My4rYuUJUOvYCxLCap5aafY4j7IGF4AaYOoALXwqQ2jK
NZyEVotVpTaAUXdi1UrCEO8B35qYZMA1LoiJB1ghXovNZ4RkAm7m4CMVJBtp
DiIwxDAvwLxLlK/CxgiocA8jVOYrhcgvTCMV4Y2aGm3iIkCgAsYLVF/cGSU9
qzxAe3Z4YMlzoRDcBYgCoAjQzIAWjvGoOK2iDmEE124leUrUJ6AYw6SyCn1C
FMHaGZy4m7/OSCkkUeBIGg7tW2ZwB8a469CMNcy5hHCYOssjo2xf1+ItOdDI
bEOHlWRpaHksEd21jJxxDGepjBkBra5xBEJW3sIXClyy64hJKFZCL15oCowX
ok+IZN6yiPjRcDvBbBTlACW2ghUnzDjoLE/EECPlMhhO3AvogXF39AyU6tDZ
ZV3g+iV+R2iNpBo6ES4FHNeARxGSgAHM0aH0BDUBXXG4fdkVQacsDNqciGph
UGClMBe/Y267AhYJVUCyol+lsYDxCpPPChQ7zwFsk64oAwiRMkkV3BwPVezH
Emvoj0E7MQiRT0IzFESXLC6sEgBGZAn2bkqJVtgLwR3qBmYSj4FnJheFWIG4
DA2OYDOMH0lksF3lI1HDucliKAYDBxy1CsYBkqKqHDGlJK5b8ZQ0tZXEbC1t
zbCD8QkMsUjgnyWSDlxOQOrC1XhMXEQ5Y9LlaoNBtQPTGaGqwpmIG40XFEx3
VTLPHV+CyiFjI/gW9pii65CwWEjTBBVAUxGoiewER2QgMIiWAt6IXy1eV+B6
tVXiIJYY4t+KkZEYIcxLkaGAjDmmrE4qzLTy4cJC5homp0uUcanzriJyW0wP
wQ9pwyQRh8rrwPMjpD+6pW6TtFK6qpNKtgliCaRjpBm+WtlYYBWvq0zKLSDN
NiGGyqEtvEIGUca5kLKirURNZt0UAHVCl4vMJrnWCiBbBD1aAFYVylzCXTC4
EvoP1MTIT0wlqHAA1+YRvFQaNXeE78SioXl8h4pABQPjBHGJRThhh63VxAIr
1MEWYApVQNMd17TK0EB2u1Q8yBU8g6HA8Gm3BUGaJiGg0JoUAwPivK5HK9PM
Ng2YfCnzpHMljYdktwcvFksl2Wtn5HR4E1wOha/FJTGMpINgM2pZq7wcRD3x
K0lMRhoIdCTwhWCuaOCcDdjXmZgRT0S9a4aqoMlJynS3uQQu5BBpHOM8ykCb
LCD+O/UIB88tAlyJYrFDVDKIHOEEPAZZkSEGrZYmlKcGlK0B+7DUxFZ1IB2k
roGPIDC80+SmIlhrqQFEBDmYFNshFV2BPkFjCdKIaDm+ziBqlSOAqOSNlhWI
5jkaOy2h51UJ6JVwMpgF7F/RXQwN7pjI/IsKDgPNxQYdDegCpa8Txhh1pZwb
PpLY3AIfSYmYslYWn9BaZYy6KhPYpuJiEQgqV2Ui0iCFxDeAGSETBLXQbuRn
K2ojMhvl0PS4qWGMULU4ItKiZ1G6iYtwZrAtt2kdSAC0Ji4KqF9LYCcqoYwh
M2oDCJXC6HNUi8VDjRYU6xILbxBjtKFUcj+zgUM05QSxCg5TlFpfQ82B5rXF
HcBwWprDO6o0S/PSEe19+plY5kwlOgyO2ADMTVuXGFAUVYe+wo6Idvo3ER5W
BW7lnXJNKH7kB3dHCmB7LXJDcYNRCJhAFFTn198M9s5sw9MxTQAplSIXl0Ja
WGWklPklYiXiJBhOKuMBTwNlNzDlnFAWM3S2QATQB2MRKik8xCobSGQiSFlU
OdNDTIT2IwuIasibCrNvpcWI9ZmUmaWZKQq7cbQrwuVysBcZCI8TP3eFuB9Q
0MCgE6PRB1joTgELzPkMhlKlOcSmghvDV5V5xcOdeG5MlINdwbXhFBA36cga
GlBnmDWWEhDXDCEAMgLzw78Yd/hMqRUUVGdZtWUMcakcuELPgDMGtJYOx9Nq
ohGqpwpQQzWeCmn1CwrF8Io/cNrxIPQhbBvzbqX7DHSO0CWZqqRyilBOYuhL
qWXMRnw119JAGQdC3twIuIiuDHFH+1B18EDG0UhESh6KMDZavFEyOAMi0YBQ
1ATazT8CJk/KCw9qYvQoIqjIopaBdxZSVUGWU5//xEPFnnAFlLlUkyWelW2C
wacB/N1BqBEyMbwZjWcILy0GWWIJjLqtLYwrUoyAUMFJ6xo9TT8BSwF0bZAC
sg7lSTsiMuBSdFroSUFXBfVMnDNpxNYQDLJcDIiAhW4TFyaSF12mRT8tGCJF
jcSnVnUIdA6ql0rzE+PBkIIAlFcMB+K/keXCaNHxcGh+yxjnQexQHs4lggO6
jAxMiOZKMhqlp4AJrioFroQr7mdQ8fiotKpCFv1DRTJjrtVaeI23McMJxotZ
YuR4iU1MXTGRsE5UUt3JwppEFsMkoJZxjFrL822tlEGtFBLaB3ijWRkKpGJs
wFabNFoDysF6Boo4IYZcYtd4b52jmsoyiYKmoad4p9LZ8kVXR9CbVBoM1lC0
xDKwC7rRGXh+nTFTmUFW4KFa4kTZNnGQFfoNIIu6bDqZThsTpbSy3hH4UguT
gFu1FWoQdgKoEyUBDaKFWl7XuFuA+xEm9M22KSC7Ve45bBq3SsSlRYXyAuvp
iPwNWmAsc5OgtrER2slPMdEMloOiLvgHSiFu/cI4XmCg1hUOg6BiGhgaLR12
EHfoacwkYPcEcnC/rgKlzg0YD+HBnHKibO5qcBN/BpFgy4xWpmIC4gxwktOq
OgEWiNp4B7hOsAlEfMAsALeJ6kR4YlxalqWWGhIYAyoLChTlDFgOt+GjDG5F
UCRK11q1bIhmIvs8POqS6TzmX97k8lja8lja8lja8lja8lja8lja8lja8lja
8lja8lja8lja8lja8r9uaQukoSByAAyOx+Di/IDdi9DA8IBPVHAsc+2Iel3b
FqBmEhSScxDz9m5py99xwwAfH2/4P6q05ajwJAXaxM+0GJrmkNpEpR3MHrQW
gow81QJArPVDpg/WX2JmRM0KrGujjtY3DfZOGCxNWQoouppoAqdsoKWI2Ax+
K6qBzdedrRCtcVYSTIou4Dql14BVSBs0DrpNyDMwch7OGJSVygBKLaJrxVe5
a61ERp2kCOMVxZYwA5eHEIC8+CbaDorukGG4F1HepSkiEPLdgu4m71xREthS
4i19hrBlrRY8o6BVUie2SlYVikfweMad/iGxgJk6AzIkm5ktHoagbHg6vuH1
kIG1FRhyHSFy8FB8KIVJlxVBs0xymAD0RwiutBdeBstFjkR5CnZiMincoYWu
Zcy+CRjGOoqQd7D7qlU7LI9vYK9InS5KKoBPCwipryCBGWMCjh472qZhbIFS
vKGSyaGIE7hNhm4GCnL4B9KMJ5UwOBgnIbSUBClFeJlxQKtFcdmISTZa5M6s
6jMsttgwylWl1UBIEE4PMSwxGUhtAqlVxryrATPCQKP1zMrZBsZXNEHtaoKU
QdPRYUSI0wqLyD2jUkutEa0JUQwaUR8xVDlAk4AAUlZYHHIkB28iAk+EPRm/
uo6AItYXSoVaYhJ8vksI23DwGI5Q9UIGZoje17DCluBJhJScGyvmVGUMx8w0
mB1EgniN0iFmxr7qDFun5xmTZWIYJJiWihrXeZfXge30MBAa/OwgxNyuhufk
bd5mDESkUU0sISrJa6hQAgO1/NFoVmijzKYNiAGdK9HrWrICSKMGkzat1i6V
pEfRQH+c0kxalCwj6HECkDh9wcgw4OEBwOtUwwHkWl9Jh25PJYV8OphZaVRL
k7Q+H2EUHgjEKJmy6TqEEHaYuECaGMWYaMhVMvNYePJYePJYePJYePILhSeZ
5IDST3XZ1IXWEZxGmKEgimN6LsXxIQvMJs4gTII1FgHkFvMSIrf4HIw0sQau
jKhpwd+W8SIw51o4B19zyyBgw8jNUgsiTaYQlgUCIhh/V5RSoTAV7hIT/mkd
8gcDws06JAW8BjuzWkEvE1gwPen0V85/kHqlFJD6WrgjdmmVsYozpqzTyg3j
TkTFeWgsYgtCDXRrBb5CUJS4oEhToHVL/s4R0wwf0SDCS+DekCatVjGrSFIU
OyNRJKAgMQtrrAhDcHvbKf9cBsgDW3dtB2Gm18wlTlI6hGwlXY5mY1atlgro
MlBItCM2puggXAREBIojE7gIwKzaXBRCMadWUU1sLGCU5wXWRiiyiKuE2c8I
4ZFVjWfODYkzbYJCbRowG16UxVJtWqQq5ZAFmMEAoUGtU7EDaA4ZwGQTLTQ0
FdERIQ92OYJsVaqih9CvKhOcWhW5Kk2GK9QtICLGkDXKGiHOHCYvqmlUTEBT
fUYGTpVoub3Q4GSpn7SG4OlbhCwGprERIDTPIdu4QOugKCge+JcGHmKVSlhy
ryDT1KrgGvxvoa0xsbCKsJuiURE6jJRQn5SVBwQL3mOsyBwiWSIqrhpaG2AO
dQWcu1wUjgbnaa1Fl1rlIzChWslnzRIhH8JAKMdr8xJHNUgxCCeiMDBQNyCh
UOKVaGos9tbCH5rEySGUtOggmEhvEKtTEKwKoUVtLfYcEf+7NMDhUuVVIzFl
KAYUrOGJjSy/VX7flSn0IOs6ZtaUNuKaRvxGNU9ENaJ1ir5X0NFyk18U4euJ
Q/UyKBaKj8NFODRmrkqKtFAxMbgrVpvipdhh4vIiADeYPNVCQ307lcEeFJ5A
FXDLDACIM0+EBBSq6Gjgm6W1MDZCmDIuGeANgcKGBfJMmBYHYgQByGtB9ET5
HeXvkTk0Ia3quEU9NxkTwZMBg1jl4spUt6pGR4igTJ18Dk8uE7CQ8NdYlwgr
VVFhYuUMlMjVOnCFmzQOBpdxj5QYRisIL13g5TQkUCVxCCgFX4fdQ8tLiL9J
0DzgZ15x05Z4CCtKsbmk4TMtTKi6AHeKmJG0FNFukBBKqDQ5cAvXK5U9QRYB
ljQ2xyhjA9Wj7RgJAEMwzOGbZRlABqNcew7yWOm8ppZsJJoQtEoxOJAgU8JG
oomZyjqlQ/D3piH6FrhfVNkAgg+v4tuOmF6CBAb3haphV44WZTGagjjopM2x
V2W9jKq2RUyI/gygFtzjRMSW6A1FwIkYFiJr1mhRjVEoXAKYChhjGH7K7VWY
lBDKWyQQrKCOszaghYWyVHVfNRcR5AzkBv+Q/ID8NiIBVaoF2QTmVBL0Enwf
uNPKFZANYrZJGYsxMAjwrMJC3Ktay9Ui/ngf1AkPkcOnTptLCiCuzqE1TYq8
MRhY1ASMXMY0V1qbaruSYG7zJJcUyWKvj+RDKv7D91siIzy+AIWgEGmNUUGg
rAu6Er8hQEISIinujmlrM637AitW+ydUka+0E0DsOqUdm06ZNthWzqg4y8DC
oZRfLcCdpAYuc5SdcQWYi0Vyd/llpsQvcJow0RhVrAwj4kKVc5qUSssz8vRG
cxarxBBCheGAknHMgDqTqAYdqlBUrdLBOU8reHococS7rmQmM1hurgWRoo6d
smmNkLEF/XEeLTQouYl34ZFEClXmW0QpPE0lhl1qfYozQu9Vko2YQQVymWYq
PAFwUul6gJNxS8HwtIJ6wNTKCvxLfRYiqpNWK7JJpEK1RhYB7dbKKsyu5JfQ
KHxApWASLVCxVLo0UbUmJpND2Ai9rXOq1seNIO5SUVhxawICMK3PkNNIyAj4
Vsmh6TAO8A4YAI461fTj+IniJcwHpotPZWhZpQAwhQAyBOBGcQ5eV7nWB1Pr
Sz2J2EpQQmlaXEJlCWCKzeFqCBLicdalpXIlNCaokRNwBwMlbpTD78oarZyD
u0XpKqgp3h+r9ijHeOvSNkR1oC/X1g/oOVo1Qh6lWZGprLIFxizzXlnmoUML
WiUSkPaiJHImX37pIlXRVASULMNB6BpqN0AOwgYx41rNVkAvwSGkoLJAOYIg
UhEkAcoYPAinUdYAZV6DJoyVqcq81Jjg7nxP5ZBaQtBCn1ICWsdFfiJcVSCo
sQchK2h5pRw36FjjUKqh7Qyh1mrzS90ykzk+hY5LbQskZ6p/q5kBoR5aNoYj
ZQ7liXqsEuKjZC/aAI4RtFCnPIdaIB3zDNONXIbboSKLoqgsE1RHxHMltWrl
aIjTflhNw+/wuRibDtDu2L5MuIkKZVAxtjxCKhcAD/QMwaOsiPKdiDTstlGd
Z2Vc5N07xyFRwBl3cTWYmCm6KQ/myy8ShJWTFKqNQ+LgSsCx0mXcUqoQToQ8
ABoRIQEiAmrr6hiWl9CHDoJqBVyE6RRoq1VVhz5kuOtahWdWBeGqS6KF8Bmk
LLNTatkuhnrgrakaoXrY2GF0WodAHKMjiphQkxAEyhp20dKGTpMFWYIONMij
pGQkG6gv+G20B62IlIWMq1RZI9X0iO5B/oAXpWMSfJwuqJAobSzooToa6DTU
FWL+icKTo/fwPdadPNadPNadPNadPNadPNadPNadPNadPNadPNadPNadPNad
/C9ad3KnauTveXowPf7/v+eZQKiwEwKbpengTpxBk3x9CbeHszntnyDMaXVT
hK2TPcL9uTXYp0hcmrIjKhlPSLRnBuNOcshL0hZxW2TiPxBXdAvoCzRVQmQQ
Og6UAqu6TpTVMzoMiwAWx6nWIgvtRkXOdnKXmHAZa7tmp7XNGCUHiyEwa30d
itIoP1BGWj6OoGDaztEIWiwxHHVdc0/+B10AnHBWzyIho4Qp4Yqpg1a78+Bs
lYSAVF6jTX8VKF/CC6BXIukOe/cLKXiz0rylMlBlhDxzzFAdEFdFsEDDRvv3
Ihy9iJXlB8RQN2W/E5bgkICgKME8hm+2ff6SAVRCwgWIjA4DEwCj5y3cSltX
Oy3QMhp0oXBx67RED/AIobRWyKTh313ul1ezKEiVBu9aMK3Ihd4lVDdR2iwq
cseExSLpEfdRGIi1rusKpQ9g6uApnLsrfR1GAnzEtY49IcrSM+3WBjLiWOve
qnDAjRtEWKEKH62xdVq3VG5NHLBBrSqr0qk+yGqJFvzrCO7ihyV0XvigNRGa
ATSLZjXMaqKNebiIg/jESh8EROUcIGK+y1qqHo+gyYU2pYHoToTS55SF4bW2
9orKQVu0sU8zW7VNBthHFYZcI29rZQuIGsgM6FGMPGu0Vm60aVsBlCHMuHeq
5KeYL6Qtlb0BsU2BhOiyuoXq4f4wHmXJeC6eqF15MHkdOUN4iKW2cGxVTjVw
AG1VgotGFrqvko9E2asyZtZL7ygZ1qo6J5/UxWIaWu/AiYowisjNlSzExOFA
0M82wF9ApLIhnKG7GXZsxJWYdqHtfTbTMURKHWnArNYFo7rMcVIZCEwKHyOe
ZxGgFuexbBhykDyWlTyWlTyWlTyWlfxCWUmMOTEEqoiNHXFZdaiAGdK8KkU7
wUciAcS24pFKq+Y6myGoSpX91RJhCkodUcwwwoZIV1ubY//gg61S4nkeGQFI
h4/BfaSmoDCgJ1GJDhLacvCK+KT4DF62HUoezh5JBkaqXsV5a48/ufWnOlVE
ZcQw3LzQSivt4OFYYlSi9dM6Vbkk3KBUTap2l4Ogqgys4xZpVcHAACGrHa8I
oDyHkujNfUZnrNHFLoMmMStNif7RRvNc1cRpUqpAxiptYbEGgBdAT2v0PeoJ
bdvUJiCqxFbbtNNI2R+pshjIQf3CW5JCq10q+9QRFRGsR8UwlYWdpNAjy4wm
WmHSUk+sKku+qUgNnigN65g9zIPw0VidLWNV8RoDY52WTgn0CfeBb5UJOi+Q
BVrttpVO7yTYTKq8KRCgFXj8r0bV9Yd7VCqL0K74Qidl6HSuQuu8VeCA6Axp
kenQGWYNhZU5Hail5DOe2ekkGbREo7gbg/Wlq4nEkQ49i7AGaFIdKB9DM3PY
CE5sGqhsC1nAoCTa61QqjHCqDHqUe9bHBAueYdlcREDLugCY1rkXtVaKURJa
reO6jDACjBSoDWi7kV3i3OKWxA1uW+sYkLyqUllhFWQ6wA/vaIpIu5OLCIfG
UuNGlMFojzby1yoRRUy0NrZajNXJYRbcJfCCskVQ6VC2EtaX6SiJiA8xT3A6
LpFqhepdVJKj4/Zqh2khmE0NtgFuBhMBV9B8QUsIjVTvjMvqXBrsOc/RHmAw
VJjmNQQzgC1XmTJxy6hqIZOsh2jIr3CoQEVFaeniSCU9hc5naZDkOu+lVDoa
3seQpX7Del34wh76XFtiAyQkVxY7jQLiPZyNkcBHtIs/Sw7PM8EwebI4T6MT
+IgZxNIUO3MOIogNRZ2oGA8u+Bcshv4Sl4NWh6DUETK7JGyhjRCCeVfieTQR
qphBfFP6qQUZowkRC+w6vzHeu1aEjm5ViwR7xnWJG8g1QECVVNgNIyK6qPQ7
zhBJByfKMMYFbNfRfZxTWbcK4ttmrlR9B4CWK3mb6OwlnfGRFaCx1dEnWibB
2SFTeK7W6wndWVmJjqrKK8gagDiWRihVeqDj50odPQNvrnTSRx0VbQQCWonc
SMukUAPTiACUuDjMrkuDxLrcZ+sc3BbPwgoyVcmZRgcBNc4VljDM46IiaXQy
BGMsPxKOQD+s9wR8B/ZaxNAcrcprNbpT+ghOFFe1cUbHOuk4D7C00UFUnT/P
CEvOiEVpVtdVFKDi66RVYRF+Jy4vXoqZxFBpncxQW+OrAS26p9VpHSVyCiWM
ictyK+wYOYyKS7Ia/0Ag+VUMcIVRiLBnuEwlORupKs2IKZSZ6vK7ooDs1UBv
DFvvKni8UpSR+FCjlAbqkKlLOuYUxZcLrEpmREcRoEV1Rk4j4IoxIEId/MO5
JHA1kV+x0UJWyrRAHdKYKrX8iZu2cDxoWVro4AoVz+skFtHeUpsaQOe2TdtA
3gu84TNJjstVsu2oo1mZSCbRzLUN0hT0t1oHyXV2FP6bglKpmKbfp2KAjhQn
cXSPwMHoEzFAD/iCkh+lai2gs6rC10KN6AzxW8fQwOgckgzCHcSoJhVyqMhQ
R4g5pSrwCQJULjmRi6srg9GpXIsggIJ2PWqmKARL9HMB0AkVUA4Mopj4mhKg
V2e7pCmiLKuMDs7AjDrlg0rGL9UZHfCIgtbGKtDKA5WMgak0DBZNsBzKSgot
hABRKuonymAmzJmkj+or0XCMIT10SE+Vf+HtsnYta8GNqyZAcdbGH9ShUynl
k7F4Z1061GiCwcK+lVmAy+tcWoXfSIebNky9ddoXgTxnMFNCvOI899OxaMxz
VUBFdGYGQRyegARkXC0hJk94RiY1YyKtjsE4bGuDOK9VyFPmTDPgqfJ9nTQa
aZOHKQuJIGbZgN5tViltGLsE084zeGlGQ3QOlMqrkAg+dWqV+Fdo0oFNRGOV
nUGYiyZTbZiK8/iVMtWJ0pcMAgFQLhYHWu1zqT8zLY39CVCuZXRsExc2AUnr
OopU2Ef8clGiV2ahAFKdZKbCIC7FcQMd1wtm0WnwMO1ibSWpuwo0y5H5Sv93
Kp4iHhpiXMNEQwq4d1mgm1DyCHgXMMBYi1YDJfybVqBMDNeZUlAslCaBiNbb
BFJI64widsefWq/XQbPaKAERKgsl1SNIfKVjyZIYRuz3ZEDdIOSIJ3gpFMZ1
eDKhGgUo5qVlU6Xp0wiU0rklnVaVFXqAeyCL8AVtg80hlFKCu9O+KASPpX2Q
FH5PP4hilriWR5GSJ46uQBZU2YhYcFrVzYiQSBwYM+G77AjgcUH8bdJSaRu4
EYxJer6WLkfjYzxIFquDSWwLLKFb+touJKvOoOGRRLMG5tNaTxnoM8Q9VWaE
IVAZQxl0orQQD+KxjjtDJ9ACRD3WqQ04CN2yyTudGQWKKu+o8+7QLToWJdem
G5AxsDw8drUW+CspidhvkrFNiYoFoVMdqapkbNKlyD4cpYoSpdjhZw0kGC6T
dAGMstbZVpFOQ4vRKZEOQSb+dbB3UFKHcCnuOlRZpKrqUmWFAKZKkxw6CFEa
aP0tRt7nv3ieyWNpyWNpyWNpyWNpyWNpyWNpyWNpyWNpyWNpyWNpyWNpyWNp
yWNpyf+D0pKjwo84h2nUTQ3pibXep22vMMis8jvGnPYoAbKRLIQxbXUkBSAT
xHoNDIanFJYO2ADyDOSG4SDewE2YdEShqi20ccnpBAut0zWAtHamGqWxAx1h
TazCFoh/zBaaKdZGPdH/Am7ut2/5JfiqquJc5/c2MWEEnhJBqSKAkJBFm1A1
bYaRRPBGvV6lUFDEonTWKuJD8jTTngngPHLQXQDDaDXZFPA1a5tA1MASXVv8
WUfL8//obB2xjyTSKh5ALtkm0NH+FOCmJCJpi6tOxID5RV2gFQgiWaYwCFKh
BKDuOog7q2qtaaBGaF+lc16VR4ZaqDpE0lOBUseNd/IObokKSp0WRBCSSrQS
7nQaiI6yyOkVQ0JgyLVNo4O+SeEqopZiY373adl1cLO61oGtTAFw0tTKE7jI
JihioLHrxOBqA/BG0sb+1e6wWNPpgO2saTNQFOarlmmuylTHllSNdqjpFF4d
fB4DN3rlE6OLwicgIQ9gUog0r1+ZxizQ+nSkuKeNsFmhU2GQQpmNtU0wg8b7
k9WVlTEVgjoVZYUilwgxUArmgYQPtEAb66UAykYqW97Bo3SAL6FAggXKoJPj
I2CmRlT4zHeBnm65lYO2FUkTBY3Kc5AznYsirYa0gI+ynkpgYMjEiEj7bmwh
RUtjlUeG4tW6sWpGmFDtetIuNThXV2m1SrtpTaZyEm0jzJD8VUSExjQTHXpf
NriAVAJcrdaCS9lIGneoYSYwquWeRmNT4t6SZcxAlhF/rd9z1/oCHyel2+BF
LYJWW2stmq0IMq3zQie0BMsTwAMlpZRzdapXANW6OIOfxX451yFr9L6ptNG7
vJRcV8VWADAIVwwIDmrzu8fCj8fCj8fCj8fCj08Xfvh32UWIgzxn3hrgLlLj
VJ2qbbS1TtJWjr1k0GsFDPoQNQHAyKzrdCpLhO0qbUk0VSyQMnrJG75TZzC+
mFbSxwQvjiDKTqd3JDp2KY2TIHJVqbPXxXRyDN0RuFETOfHQ6FSAHMIDmuu4
JB3lFWt5JEf85gBCXanMtOhwo0oHicF7oRL4r1UfXJmUsd5ewGASgEr/Hr+4
zrW+qrfh5UoRY45gBTe3AQQ9Uy5EnVYaU0UAaDvtPIedlDk3luzRSnyl07+Q
Gv7M/TIG/+Kq0esdgqIBKghaPAxvbSOdZmW1XEQwRcIgNl2qI7zEWkun81VS
5RJrvZkhEgJCnQNXaUlVAhtOXzR6DQxIoMpAYA5nEI5By1ymQliid9QoAmgx
NpfwBwkN8q3Gt1udItchHpXUspIw3CpX+YUW+wud0a/a107qFwQu9Gq2EhMl
giBYkkCKjqhJwyCtkLUKkiD6HmdiVJUS7wk3bf2bB3PQPMbxaF4OU0q1/tfA
GehoJCfRmi7BQe8mosm2QlJgzNCuTOuVUFq9v0Jvikj8GywgvToEJU6gIk3g
a32Vt/Vrp6hN1USqNCTVERfEFTlZplpgoC4WR0z09kalT9HmddIgBwMX+aPn
TdkBNXrLiDZGo36QR5UOcBFfcKpCgvZp/RdnthHWjJDUexHw0zQNWpCDiMBY
W6RVkhJKUdGEmcwZX4lb5/Q9r0ElIkqSgacIQQyQ4AbSljW/CoyqRTE7lfYg
+hA/tVRSnStHlWWlXtsDbmG42pjONEdSnkWk+oUiUd47Up4pLbWfX98RZ3CF
1sX1rpEkIsRpxbosNChYBKOCEomtNAkA1SmnrZNAAq0YI0AzvYYQ5ECkHhV+
8HW9dQaBZ9GfJRwmz/Xqv8SU2qcsCQZAInTwWeIxFoRjFkFTapUjwoLgk4Xq
pwodpNOWev2FTtMjtOlwwVJHmUiOSM03EcK41DE/VY5vQXxrvWYBRlxEKk3D
an0FcOyrYpQ8J/qmHRqyykFUhr8Ej43SlUwpvogfBplOJICGYGWVjohUUl1n
TnQtMj6VDEp01CA+nUTafA/1TnSQg94IqbeMRPh4ULcRTBo1lGipWGfBpInO
pcFBMKVMah0iGalIJ1Ys5yGq7Y1kFqk6jewIiH1GYFhCN5FXEh3+hSh6FafK
pdoc8NdxIXWrYJfAJpIExV6rkXqVTKnXQDbWSKhqWVg59li71KsYitX5M0KM
1qh1MhOaBKyjixiRTUEgFaSUqlfPAq37IwZpQqRXf2b0ugM2YZXETLg0/icr
inT0hSsUzowKyDGyVFmODD4SBTiV6tewuEKvJbO5P78RRI50UBJ3BKVVUaWk
pd7CABNQIVlbY8w6kEj53UAd0Ws4kFFoBy2q0uUMWahiFKUOy0ovoKxiSDTU
Wa8R1RuHkiZpBcg60TAKdLpU3kV6k2qU6s2o8N0G72s8NGY6RqlWpVrV6n9W
79TI9Fow7oEOpLU8K0gJ/DrnyZZQR5RRqjRHo3p8R9hxWufj5waOANnUe0oJ
7aqX0qYOtJlTs4NC54o24jrKM2aENQYAZGoE11pEFjMxyMsuz1U9XkV6exXs
0cbKFiVFhcVi41YUGVOTjIdPaH0mLnUYlXhrWoE9kV4oBJCC94QvZkkn1Jiq
TPXyLLhl7LRDompw1VpLqco5QoDABJvS7VzvVyJIuUr8ssnhtyqFwoxxEWJH
p9o9vaNFrma7XDVuSIzhlKEMyqvkoWiuDjrKMzRYrTNwar3w1Wh5OElVMOL0
jh0VcxgIWJTo9WdBF1lZHo6BF+vMArQQhBg9raRnrMOYaHSZqvwKiaitGzon
IbNem8dQEZzJ6q1Lrd6KpvOREECAJG4cd45GWe00sQqfWoETmEL2OuxPh2HG
oo4AuEsDnQaBdo60nlKaRryVCaz0hi465bSaoOMaUDN6CUlpmyyCpWh130G3
HYaYgg0MnpPq4SJUpF4/JPci/Fmj9SXlSrTEKRqS5Up7MaAqhgDvDMoUet0F
RosLDpSBr9Li/o00eRMbvVcXwqxiJoG7ZEUN9QR8wDMjB4MPAXQQlQCZ4UOa
05kcFbyEEFKrVI9IAdvE6gqr1zZVRCfCs44QRekVQBRToTem1lo3RSRWCpxa
RlbylLYXel0f5F1rlJXWFm1sVQihV8JkOtuLYJ5rHwxPLw2ipELytrGkQ1c2
eltuIhv31V4GhFQOVu9OgZ+WdLdtqzTDfBmXUm/K0sJEq7Ou/Gv1Cr2mFXwv
4WWu1TuJ9Ba7uqyg1LleoAf3TnR2qla4oA38GqDWuUqMWJAqaRnjtbHenqO3
zXEVw2YcsjfKCMkpxosKqi3mirpzeqHX/93SFeQ0DAPBu1+x6gMQpVVjKnGA
NyBxdu01dePYyHEaIdS/dwY45uIoye56JjuepUoRGzvFvsgRAxxpOfKX6Wdp
njccLOUuW3Z+yBk52w9wne1PIFdiIx7roWTMBhSuAS/NYMsHeFLEgXcD+8zI
QRB+nvii2tPvDyg/qDMIGXxx9jD9DjQepBMVZQBDfVTECRXCWzZpwc8BqS0V
THgACoLjM22PiVRp83LicS+UG/4+iGxsKr2sEEE8ZoJQ/jV0C3i7gJVYFNhG
kTFAG5yHtfuz+KL10pMDzqQtDa1yIoWlHElHAz7wflq97v+FH/Lqx1LXrOFz
0tJn83Msy3TSpuFlE12edXMz5kNlrUsOktOo0qv0syujvF2qtiLvzo+TK0XW
c5WvVq8JPEVcEQ2p15ZcxkWQWf3SUv+Wptekq9SIZdIsofqF934wd+BH2ofu
/wAA
</rfc> </rfc>
 End of changes. 132 change blocks. 
1139 lines changed or deleted 325 lines changed or added

This html diff was produced by rfcdiff 1.48.