rfc9690.original.xml | rfc9690.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | ||||
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.11 (Ruby 3.2. | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | |||
4) --> | -ietf-lamps-rfc5990bis-10" number="9690" category="std" consensus="true" submiss | |||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | ionType="IETF" updates="" obsoletes="5990" tocInclude="true" sortRefs="true" sym | |||
-ietf-lamps-rfc5990bis-10" category="std" consensus="true" submissionType="IETF" | Refs="true" version="3" xml:lang="en"> | |||
obsoletes="5990" tocInclude="true" sortRefs="true" symRefs="true" version="3"> | ||||
<!-- xml2rfc v2v3 conversion 3.21.0 --> | ||||
<front> | <front> | |||
<title abbrev="RSA-KEM with CMS KEMRecipientInfo">Use of the RSA-KEM Algorit hm in the Cryptographic Message Syntax (CMS)</title> | <title abbrev="RSA-KEM with CMS KEMRecipientInfo">Use of the RSA-KEM Algorit hm in the Cryptographic Message Syntax (CMS)</title> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc5990bis-10"/> | <seriesInfo name="RFC" value="9690"/> | |||
<author initials="R." surname="Housley" fullname="Russ Housley"> | <author initials="R." surname="Housley" fullname="Russ Housley"> | |||
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> | <organization abbrev="Vigil Security">Vigil Security, LLC</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>516 Dranesville Road</street> | <street>516 Dranesville Road</street> | |||
<city>Herndon, VA</city> | <city>Herndon</city> | |||
<region>VA</region> | ||||
<code>20170</code> | <code>20170</code> | |||
<country>US</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>housley@vigilsec.com</email> | <email>housley@vigilsec.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="S." surname="Turner" fullname="Sean Turner"> | <author initials="S." surname="Turner" fullname="Sean Turner"> | |||
<organization>sn3rd</organization> | <organization>sn3rd</organization> | |||
<address> | <address> | |||
<email>sean@sn3rd.com</email> | <email>sean@sn3rd.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2024" month="June" day="05"/> | <date year="2025" month="January"/> | |||
<area>Security</area> | ||||
<workgroup>Limited Additional Mechanisms for PKIX and SMIME</workgroup> | <area>SEC</area> | |||
<workgroup>lamps</workgroup> | ||||
<keyword>Key Encapsulation Mechanism (KEM)</keyword> | <keyword>Key Encapsulation Mechanism (KEM)</keyword> | |||
<keyword>KEMRecipientInfo</keyword> | <keyword>KEMRecipientInfo</keyword> | |||
<abstract> | <abstract> | |||
<?line 138?> | ||||
<t>The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass | <t>The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass | |||
(store-and-forward) cryptographic mechanism for an originator to securely | (store-and-forward) cryptographic mechanism for an originator to securely | |||
send keying material to a recipient using the recipient's RSA public key. | send keying material to a recipient using the recipient's RSA public key. | |||
The RSA-KEM Algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. | The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. | |||
This document specifies the conventions for using the RSA-KEM Algorithm as a | This document specifies the conventions for using the RSA-KEM algorithm as a | |||
standalone KEM algorithm and the conventions for using the RSA-KEM Algorithm | standalone KEM algorithm and the conventions for using the RSA-KEM algorithm | |||
with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as | with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as | |||
specified in RFC XXXX. This document obsoletes RFC 5990.</t> | specified in RFC 9629. This document obsoletes RFC 5990.</t> | |||
<t>RFC EDITOR: Please replace XXXX with the RFC number assigned to draft-i | ||||
etf-lamps-cms-kemri.</t> | ||||
</abstract> | </abstract> | |||
<note removeInRFC="true"> | ||||
<name>About This Document</name> | ||||
<t> | ||||
Status information for this document may be found at <eref target="https | ||||
://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5990bis/"/>. | ||||
</t> | ||||
<t> | ||||
Discussion of this document takes place on the | ||||
Limited Additional Mechanisms for PKIX and SMIME Working Group mailing l | ||||
ist (<eref target="mailto:spasm@ietf.org"/>), | ||||
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro | ||||
wse/spasm/"/>. | ||||
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/" | ||||
/>. | ||||
</t> | ||||
</note> | ||||
</front> | </front> | |||
<middle> | <middle> | |||
<?line 151?> | ||||
<section anchor="introduction"> | <section anchor="introduction"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass | <t>The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass | |||
(store-and-forward) cryptographic mechanism for an originator to securely | (store-and-forward) cryptographic mechanism for an originator to securely | |||
send keying material to a recipient using the recipient's RSA public key. | send keying material to a recipient using the recipient's RSA public key. | |||
The RSA-KEM Algorithm is specified in Clause 11.5 of <xref target="ISO18033-2"/> | The RSA-KEM algorithm is specified in Clause 11.5 of <xref target="ISO18033-2"/> | |||
.</t> | .</t> | |||
<t>The RSA-KEM Algorithm takes a different approach than other RSA key | <t>The RSA-KEM algorithm takes a different approach than other RSA key | |||
transport mechanisms <xref target="RFC8017"/>, with the goal of providing higher | transport mechanisms <xref target="RFC8017"/> with the goal of providing higher | |||
security assurance while also satisfying the KEM interface. The | security assurance while also satisfying the KEM interface. The | |||
RSA-KEM Algorithm encrypts a random integer with the recipient's | RSA-KEM algorithm encrypts a random integer with the recipient's | |||
RSA public key, and derives a shared secret from the random integer. The | RSA public key and derives a shared secret from the random integer. The | |||
originator and recipient can derive a symmetric key from the shared | originator and recipient can derive a symmetric key from the shared | |||
secret. For example, a key-encryption key can be derived from the shared | secret. For example, a key-encryption key (KEK) can be derived from the shared | |||
secret to wrap a content-encryption key.</t> | secret to wrap a content-encryption key (CEK).</t> | |||
<t>In the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> usin g | <t>In the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> usin g | |||
KEMRecipientInfo <xref target="I-D.ietf-lamps-cms-kemri"/>, the shared secret va | KEMRecipientInfo <xref target="RFC9629"/>, the shared-secret value | |||
lue | is input to a key derivation function (KDF) to compute a key-encryption key and | |||
is input to a key-derivation function to compute a key-encryption key, and | ||||
wrap a symmetric content-encryption key with the key-encryption key. In | wrap a symmetric content-encryption key with the key-encryption key. In | |||
this way, the originator and the recipient end up with the same | this way, the originator and the recipient end up with the same | |||
content-encryption key.</t> | content-encryption key.</t> | |||
<t>For completeness, a specification of the RSA-KEM Algorithm is given in | <t>For completeness, a specification of the RSA-KEM algorithm is given in | |||
Appendix A of this document; ASN.1 syntax is given in Appendix B.</t> | <xref target="app-alg" format="default"/> of this document. ASN.1 syntax is give | |||
n in <xref target="app-asn1" format="default"/>.</t> | ||||
<section anchor="rsa-kem-algorithm-rationale"> | <section anchor="rsa-kem-algorithm-rationale"> | |||
<name>RSA-KEM Algorithm Rationale</name> | <name>RSA-KEM Algorithm Rationale</name> | |||
<t>The RSA-KEM Algorithm provides higher security assurance than other | <t>The RSA-KEM algorithm provides higher security assurance than other | |||
variants of the RSA cryptosystem for two reasons. First, the input to the | variants of the RSA cryptosystem for two reasons. First, the input to | |||
underlying RSA operation is a string-encoded random integer between 0 and n-1, | the underlying RSA operation is a string-encoded random integer | |||
where n is the RSA modulus, so it does not have any structure that could be | between 0 and n-1, where n is the RSA modulus, so it does not have any | |||
exploited by an adversary. Second, the input is independent of the keying | structure that could be exploited by an adversary. Second, the input | |||
material so the result of the RSA decryption operation is not directly | is independent of the keying material, so the result of the RSA | |||
available to an adversary. As a result, the RSA-KEM Algorithm enjoys a | decryption operation is not directly available to an adversary. As a | |||
"tight" security proof in the random oracle model. (In other padding | result, the RSA-KEM algorithm enjoys a "tight" security proof in the | |||
schemes, such as PKCS #1 v1.5 <xref target="RFC8017"/>, the input has structure | random oracle model. (In other padding schemes, such as PKCS #1 v1.5 | |||
and/or | <xref target="RFC8017"/>, the input has structure and depends on the | |||
depends on the keying material, and the provable security assurances are not | keying material. Additionally, the provable security assurances are | |||
as strong.)</t> | not as strong.)</t> | |||
<t>The approach is also architecturally convenient because the | <t>The approach is also architecturally convenient because the | |||
public-key operations are separate from the symmetric operations on the | public-key operations are separate from the symmetric operations on the | |||
keying material. Another benefit is that the length of the keying material | keying material. Another benefit is that the length of the keying material | |||
is determined by the symmetric algorithms, not the size of the RSA modulus.</t> | is determined by the symmetric algorithms, not the size of the RSA modulus.</t> | |||
</section> | </section> | |||
<section anchor="rsa-kem-algorithm-summary"> | <section anchor="rsa-kem-algorithm-summary"> | |||
<name>RSA-KEM Algorithm Summary</name> | <name>RSA-KEM Algorithm Summary</name> | |||
<t>All KEM algorithms provide three functions: KeyGen(), Encapsulate(), | <t>All KEM algorithms provide three functions: KeyGen(), Encapsulate(), | |||
and Decapsulate().</t> | and Decapsulate().</t> | |||
<t>The following summarizes these three functions for RSA-KEM:</t> | <t>The following summarizes these three functions for RSA-KEM:</t> | |||
<t>KeyGen() -> (pk, sk):</t> | ||||
<ul empty="true"> | <dl spacing="normal" newline="true"> | |||
<li> | <dt>KeyGen() -> (pk, sk):</dt> | |||
<t>Generate the public key (pk) and a private key (sk) as described | <dd><t>Generate the public key (pk) and a private key (sk) as | |||
in <xref section="3" sectionFormat="of" target="RFC8017"/>.</t> | described in <xref section="3" sectionFormat="of" | |||
</li> | target="RFC8017"/>.</t></dd> | |||
</ul> | <dt>Encapsulate(pk) -> (ct, SS):</dt> | |||
<t>Encapsulate(pk) -> (ct, SS):</t> | <dd> | |||
<ul empty="true"> | <t>Given the recipient's public key (pk), produce a ciphertext | |||
<li> | (ct) to be passed to the recipient and a shared secret (SS) for | |||
<t>Given the recipient's public key (pk), produce a ciphertext (ct) | use by the originator as follows:</t> | |||
to be | <ol type="1" spacing="normal"> | |||
passed to the recipient and a shared secret (SS) for use by the originator, | <li>Generate a random integer z between 0 and n-1.</li> | |||
as follows:</t> | <li><t>Encrypt the integer z with the recipient's RSA public key t | |||
</li> | o obtain the ciphertext:</t> | |||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>1. Generate a random integer z between 0 and n-1.</t> | ||||
</li> | ||||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>2. Encrypt the integer z with the recipient's RSA public key to o | ||||
btain the ciphertext:</t> | ||||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
ct = z^e mod n | ct = z^e mod n]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | <li><t>Derive a shared secret from the integer z using a Key | |||
<li> | Derivation Function (KDF):</t> | |||
<t>3. Derive a shared secret from the integer z using a Key Derivati | ||||
on Function (KDF):</t> | ||||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
SS = KDF(Z, ssLen) | SS = KDF(Z, ssLen)]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | <li><t>The ciphertext and the shared secret are returned by the | |||
<li> | function. The originator sends the ciphertext to the | |||
<t>4. The ciphertext and the shared secret are returned by the funct | recipient.</t> | |||
ion. The | </li> | |||
originator sends the ciphertext to the recipient.</t> | </ol> | |||
</li> | </dd> | |||
</ul> | <dt>Decapsulate(sk, ct) -> SS:</dt> | |||
<t>Decapsulate(sk, ct) -> SS:</t> | <dd><t>Given the private key (sk) and the ciphertext (ct), produce | |||
<ul empty="true"> | the shared secret (SS) for the recipient as follows:</t> | |||
<li> | <ol type="1" spacing="normal"> | |||
<t>Given the private key (sk) and the ciphertext (ct), produce the | <li><t>Decrypt the ciphertext with the recipient's RSA private | |||
shared secret (SS) for the recipient as follows:</t> | key to obtain the random integer z:</t> | |||
</li> | ||||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>1. Decrypt the ciphertext with the recipient's RSA private key | ||||
to obtain the random integer z:</t> | ||||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
z = ct^d mod n | z = ct^d mod n]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | <li><t>Derive a shared secret from the integer z:</t> | |||
<li> | ||||
<t>2. Derive a shared secret from the integer z:</t> | ||||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
SS = KDF(Z, ssLen) | SS = KDF(Z, ssLen)]]></artwork> | |||
]]></artwork> | </li> | |||
<t>3. The shared secret is returned by the function.</t> | <li><t>The shared secret is returned by the function.</t></li> | |||
</ol> | ||||
</dd> | ||||
</dl> | ||||
</section> | </section> | |||
<section anchor="cms-kemrecipientinfo-processing-summary"> | <section anchor="cms-kemrecipientinfo-processing-summary"> | |||
<name>CMS KEMRecipientInfo Processing Summary</name> | <name>CMS KEMRecipientInfo Processing Summary</name> | |||
<t>To support the RSA-KEM algorithm, the CMS originator <bcp14>MUST</bcp | <t>To support the RSA-KEM algorithm, the CMS originator | |||
14> implement | <bcp14>MUST</bcp14> implement Encapsulate().</t> | |||
Encapsulate().</t> | <t>Given a content-encryption key CEK, the RSA-KEM algorithm | |||
<t>Given a content-encryption key CEK, the RSA-KEM Algorithm processing | processing by the originator to produce the values that are carried in | |||
by the | the CMS KEMRecipientInfo can be summarized as follows:</t> | |||
originator to produce the values that are carried in the CMS KEMRecipientInfo | ||||
can be summarized as:</t> | <ol type="1" spacing="normal"> | |||
<ul empty="true"> | ||||
<li> | <li> | |||
<t>1. Obtain the shared secret using the Encapsulate() function of | <t>Obtain the shared secret using the Encapsulate() function of | |||
the | the RSA-KEM algorithm and the recipient's RSA public key:</t> | |||
RSA-KEM algorithm and the recipient's RSA public key:</t> | ||||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
(ct, SS) = Encapsulate(pk) | (ct, SS) = Encapsulate(pk)]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | ||||
<li> | <li> | |||
<t>2. Derive a key-encryption key KEK from the shared secret:</t> | <t>Derive a key-encryption key KEK from the shared secret:</t> | |||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
KEK = KDF(SS, kekLength, otherInfo) | KEK = KDF(SS, kekLength, otherInfo)]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | ||||
<li> | <li> | |||
<t>3. Wrap the CEK with the KEK to obtain wrapped keying material W | <t>Wrap the CEK with the KEK to obtain wrapped keying material WK:</ | |||
K:</t> | t> | |||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
WK = WRAP(KEK, CEK) | WK = WRAP(KEK, CEK) | |||
]]></artwork> | ]]></artwork> | |||
<ul empty="true"> | </li> | |||
<li> | <li> | |||
<t>4. The originator sends the ciphertext and WK to the recipient in | <t>The originator sends the ciphertext and WK to the recipient in | |||
the CMS | the CMS KEMRecipientInfo structure.</t> | |||
KEMRecipientInfo structure.</t> | ||||
</li> | </li> | |||
</ul> | </ol> | |||
<t>To support the RSA-KEM algorithm, the CMS recipient <bcp14>MUST</bcp1 | ||||
4> implement | <t>To support the RSA-KEM algorithm, the CMS recipient | |||
Decapsulate().</t> | <bcp14>MUST</bcp14> implement Decapsulate().</t> | |||
<t>The RSA-KEM algorithm recipient processing of the values obtained fro | <t>The RSA-KEM algorithm recipient processing of the values obtained | |||
m the | from the KEMRecipientInfo structure is summarized as follows:</t> | |||
KEMRecipientInfo structure can be summarized as:</t> | ||||
<ul empty="true"> | <ol type="1" spacing="normal"> | |||
<li> | <li> | |||
<t>1. Obtain the shared secret using the Decapsulate() function of | <t>Obtain the shared secret using the Decapsulate() function of | |||
the | the RSA-KEM algorithm and the recipient's RSA private key:</t> | |||
RSA-KEM algorithm and the recipient's RSA private key:</t> | ||||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
SS = Decapsulate(sk, ct) | SS = Decapsulate(sk, ct)]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | ||||
<li> | <li> | |||
<t>2. Derive a key-encryption key KEK from the shared secret:</t> | <t>Derive a key-encryption key KEK from the shared secret:</t> | |||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
KEK = KDF(SS, kekLength, otherInfo) | KEK = KDF(SS, kekLength, otherInfo)]]></artwork> | |||
]]></artwork> | </li> | |||
<ul empty="true"> | ||||
<li> | <li> | |||
<t>3. Unwrap the WK with the KEK to obtain content-encryption key C | <t>Unwrap the WK with the KEK to obtain the content-encryption key C | |||
EK:</t> | EK:</t> | |||
</li> | ||||
</ul> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
CEK = UNWRAP(KEK, WK) | CEK = UNWRAP(KEK, WK)]]></artwork> | |||
]]></artwork> | </li> | |||
</ol> | ||||
<t>Note that the KDF used to process the KEMRecipientInfo structure <bcp 14>MAY</bcp14> be | <t>Note that the KDF used to process the KEMRecipientInfo structure <bcp 14>MAY</bcp14> be | |||
different from the KDF used to derive the shared secret in the RSA-KEM | different from the KDF used to derive the shared secret in the RSA-KEM | |||
algorithm.</t> | algorithm.</t> | |||
</section> | </section> | |||
<section anchor="conventions-and-definitions"> | <section anchor="conventions-and-definitions"> | |||
<name>Conventions and Definitions</name> | <name>Conventions and Definitions</name> | |||
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp | <t> | |||
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | |||
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO | IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> | |||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i | RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
nterpreted as | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
described in BCPÂ 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and | be interpreted as | |||
only when, they | described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | |||
appear in all capitals, as shown here.</t> | when, and only when, they appear in all capitals, as shown here. | |||
<?line -18?> | </t> | |||
</section> | ||||
</section> | ||||
<section anchor="asn1"> | <section anchor="asn1"> | |||
<name>ASN.1</name> | <name>ASN.1</name> | |||
<t>CMS values are generated using ASN.1 <xref target="X.680"/>, which us es the Basic | <t>CMS values are generated using ASN.1 <xref target="X.680"/>, which us es the Basic | |||
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X. 690"/>.</t> | Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X. 690"/>.</t> | |||
</section> | </section> | |||
<section anchor="changes-since-rfc-5990"> | <section anchor="changes-since-rfc-5990"> | |||
<name>Changes Since RFC 5990</name> | <name>Changes Since RFC 5990</name> | |||
<t>RFC 5990 <xref target="RFC5990"/> specified the conventions for using the RSA-KEM Algorithm | <t>RFC 5990 <xref target="RFC5990"/> specified the conventions for using the RSA-KEM algorithm | |||
in CMS as a key transport algorithm. That is, it used KeyTransRecipientInfo <xr ef target="RFC5652"/> | in CMS as a key transport algorithm. That is, it used KeyTransRecipientInfo <xr ef target="RFC5652"/> | |||
for each recipient. Since the publication of RFC 5990, a new KEMRecipientInfo | for each recipient. Since the publication of RFC 5990, a new KEMRecipientInfo | |||
structure <xref target="I-D.ietf-lamps-cms-kemri"/> has been defined to support KEM | structure <xref target="RFC9629"/> has been defined to support KEM | |||
algorithms. When the id-rsa-kem algorithm identifier appears in the | algorithms. When the id-rsa-kem algorithm identifier appears in the | |||
SubjectPublicKeyInfo field of a certificate, the complex parameter structure | SubjectPublicKeyInfo field of a certificate, the complex parameter structure | |||
defined in RFC 5990 can be omitted; however, the parameters are allowed for | defined in RFC 5990 can be omitted; however, the parameters are allowed for | |||
backward compatibility. Also, to avoid visual confusion with id-kem-rsa, | backward compatibility. Also, to avoid visual confusion with id-kem-rsa, | |||
id-rsa-kem-spki is introduced as an alias for id-rsa-kem.</t> | id-rsa-kem-spki is introduced as an alias for id-rsa-kem.</t> | |||
<t>RFC 5990 used EK as the EncryptedKey, which is the concatenation of | <t>RFC 5990 used EK as the EncryptedKey, which is the concatenation of | |||
the ciphertext C and the wrapped key WK, EK = (C || WK). The use of EK was | the ciphertext C and the wrapped key WK, EK = (C || WK). The use of EK was | |||
necessary to align with the KeyTransRecipientInfo structure. In this | necessary to align with the KeyTransRecipientInfo structure. In this | |||
document, the ciphertext and the wrapped key are sent in separate fields of | document, the ciphertext and the wrapped key are sent in separate fields of | |||
the KEMRecipientInfo structure. In particular, the ciphertext is carried in | the KEMRecipientInfo structure. In particular, the ciphertext is carried in | |||
the kemct field, and wrapped key is carried in the encryptedKey | the kemct field, and the wrapped key is carried in the encryptedKey | |||
field. See <xref target="app-alg"/> for details about the computation of the ci phertext.</t> | field. See <xref target="app-alg"/> for details about the computation of the ci phertext.</t> | |||
<t>RFC 5990 included support for Camellia and Triple-DES block ciphers; | <t>RFC 5990 included support for Camellia and Triple-DES block ciphers; | |||
discussion of these block ciphers is removed from this document, but | discussion of these block ciphers does not appear in this document, but | |||
the algorithm identifiers remain in the ASN.1 Module <xref target="app-asn1-modu | the algorithm identifiers remain in the ASN.1 module (see <xref target="app-asn1 | |||
le"/>.</t> | -module"/>).</t> | |||
<t>RFC 5990 included support for SHA-1 hash function; discussion of this | <t>RFC 5990 included support for SHA-1 hash function; discussion of this | |||
hash function is removed from this document, but the algorithm identifier | hash function does not appear this document, but the algorithm identifier | |||
remains in the ASN.1 module <xref target="app-asn1-module"/>.</t> | remains in the ASN.1 module (see <xref target="app-asn1-module"/>).</t> | |||
<t>RFC 5990 required support for the KDF3 key-derivation function <xref | <t>RFC 5990 required support for the KDF3 key derivation function | |||
target="ANS-X9.44"/>; | <xref target="ANS-X9.44"/>; this document continues to require | |||
this document continues to require support for the KDF3 key-derivation function, | support for the KDF3 key derivation function, but it requires support | |||
but it requires support for SHA-256 <xref target="SHS"/> as the hash function.</ | for SHA-256 <xref target="SHS"/> as the hash function.</t> | |||
t> | ||||
<t>RFC 5990 recommended support for alternatives to KDF3 and AES-Wrap-12 8; | <t>RFC 5990 recommended support for alternatives to KDF3 and AES-Wrap-12 8; | |||
this document simply states that other key-derivation functions and other | this document simply states that other key derivation functions and other | |||
key-encryption algorithms <bcp14>MAY</bcp14> be supported.</t> | key-encryption algorithms <bcp14>MAY</bcp14> be supported.</t> | |||
<t>RFC 5990 supported the future definition of additional KEM algorithms that | <t>RFC 5990 supported the future definition of additional KEM algorithms that | |||
use RSA; this document supports only one, and it is identified by the | use RSA; this document supports only one, and it is identified by the | |||
id-kem-rsa object identifier.</t> | id-kem-rsa object identifier.</t> | |||
<t>RFC 5990 included an ASN.1 module; this document provides an alternat ive | <t>RFC 5990 included an ASN.1 module; this document provides an alternat ive | |||
ASN.1 module that follows the conventions established in <xref target="RFC5911"/ >, | ASN.1 module that follows the conventions established in <xref target="RFC5911"/ >, | |||
<xref target="RFC5912"/>, and <xref target="RFC6268"/>. The new ASN.1 module <x ref target="app-asn1-module"/> | <xref target="RFC5912"/>, and <xref target="RFC6268"/>. The new ASN.1 module (< xref target="app-asn1-module"/>) | |||
produces the same bits-on-the-wire as the one in RFC 5990.</t> | produces the same bits-on-the-wire as the one in RFC 5990.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="use-of-the-rsa-kem-algorithm-in-cms"> | <section anchor="use-of-the-rsa-kem-algorithm-in-cms"> | |||
<name>Use of the RSA-KEM Algorithm in CMS</name> | <name>Use of the RSA-KEM Algorithm in CMS</name> | |||
<t>The RSA-KEM Algorithm <bcp14>MAY</bcp14> be employed for one or more re cipients in the | <t>The RSA-KEM algorithm <bcp14>MAY</bcp14> be employed for one or more re cipients in the | |||
CMS enveloped-data content type <xref target="RFC5652"/>, the CMS authenticated- data | CMS enveloped-data content type <xref target="RFC5652"/>, the CMS authenticated- data | |||
content type <xref target="RFC5652"/>, or the CMS authenticated-enveloped-data | content type <xref target="RFC5652"/>, or the CMS authenticated-enveloped-data | |||
content type <xref target="RFC5083"/>. In each case, the KEMRecipientInfo | content type <xref target="RFC5083"/>. In each case, the KEMRecipientInfo | |||
<xref target="I-D.ietf-lamps-cms-kemri"/> is used with the RSA-KEM Algorithm | <xref target="RFC9629"/> is used with the RSA-KEM algorithm | |||
to securely transfer the content-encryption key from the originator to | to securely transfer the content-encryption key from the originator to | |||
the recipient.</t> | the recipient.</t> | |||
<section anchor="mandatory-to-implement"> | <section anchor="mandatory-to-implement"> | |||
<name>Mandatory To Implement</name> | <name>Mandatory To Implement</name> | |||
<t>A CMS implementation that supports the RSA-KEM Algorithm <bcp14>MUST< /bcp14> support at | <t>A CMS implementation that supports the RSA-KEM algorithm <bcp14>MUST< /bcp14> support at | |||
least the following underlying components:</t> | least the following underlying components:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>For the key-derivation function, an implementation <bcp14>MUST</b cp14> support | <t>For the key derivation function, an implementation <bcp14>MUST</b cp14> support | |||
KDF3 <xref target="ANS-X9.44"/> with SHA-256 <xref target="SHS"/>.</t> | KDF3 <xref target="ANS-X9.44"/> with SHA-256 <xref target="SHS"/>.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>For key-wrapping, an implementation <bcp14>MUST</bcp14> support t he | <t>For key-wrapping, an implementation <bcp14>MUST</bcp14> support t he | |||
AES-Wrap-128 <xref target="RFC3394"/> key-encryption algorithm.</t> | AES-Wrap-128 <xref target="RFC3394"/> key-encryption algorithm.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>An implementation <bcp14>MAY</bcp14> also support other key-derivatio | <t>An implementation <bcp14>MAY</bcp14> also support other key derivatio | |||
n functions and | n functions and | |||
other key-encryption algorithms as well.</t> | other key-encryption algorithms.</t> | |||
</section> | </section> | |||
<section anchor="recipientinfo-conventions"> | <section anchor="recipientinfo-conventions"> | |||
<name>RecipientInfo Conventions</name> | <name>RecipientInfo Conventions</name> | |||
<t>When the RSA-KEM Algorithm is employed for a recipient, the | <t>When the RSA-KEM algorithm is employed for a recipient, the | |||
RecipientInfo alternative for that recipient <bcp14>MUST</bcp14> be | RecipientInfo alternative for that recipient <bcp14>MUST</bcp14> be | |||
OtherRecipientInfo using the KEMRecipientInfo structure | OtherRecipientInfo using the KEMRecipientInfo structure | |||
<xref target="I-D.ietf-lamps-cms-kemri"/>. The fields of the | <xref target="RFC9629"/>. The fields of the | |||
KEMRecipientInfo <bcp14>MUST</bcp14> have the following values:</t> | KEMRecipientInfo <bcp14>MUST</bcp14> have the following values:</t> | |||
<ul empty="true"> | ||||
<li> | <ul spacing="normal"> | |||
<t>version is the syntax version number; it <bcp14>MUST</bcp14> be 0 | <li>version is the syntax version number; it <bcp14>MUST</bcp14> be | |||
.</t> | 0.</li> | |||
</li> | ||||
</ul> | <li>rid identifies the recipient's certificate or public key.</li> | |||
<ul empty="true"> | ||||
<li> | <li>kem identifies the KEM algorithm; it <bcp14>MUST</bcp14> contain | |||
<t>rid identifies the recipient's certificate or public key.</t> | id-kem-rsa.</li> | |||
</li> | ||||
</ul> | <li>kemct is the ciphertext produced for this recipient; | |||
<ul empty="true"> | it contains C from steps 1 and 2 of Originator's Operations in | |||
<li> | <xref target="app-alg"/>.</li> | |||
<t>kem identifies the KEM algorithm; it <bcp14>MUST</bcp14> contain | ||||
id-kem-rsa.</t> | <li>kdf identifies the key derivation function (KDF). | |||
</li> | Note that the KDF used for CMS RecipientInfo process | |||
</ul> | <bcp14>MAY</bcp14> be different than the KDF used within the | |||
<ul empty="true"> | RSA-KEM algorithm.</li> | |||
<li> | ||||
<t>kemct is the ciphertext produced for this recipient; it contains | <li>kekLength is the size of the key-encryption key in octets.</li> | |||
C from steps 1 and 2 of Originator's Operations in <xref target="app-alg"/>.</t> | ||||
</li> | <li>ukm is an optional random input to the key derivation function.< | |||
</ul> | /li> | |||
<ul empty="true"> | ||||
<li> | <li>wrap identifies a key-encryption algorithm used to | |||
<t>kdf identifies the key-derivation function (KDF). Note that the | encrypt the keying material.</li> | |||
KDF used for CMS RecipientInfo process <bcp14>MAY</bcp14> be different than the | ||||
KDF | <li>encryptedKey is the result of encrypting the keying material wit | |||
used within the RSA-KEM Algorithm.</t> | h the | |||
</li> | ||||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>kekLength is the size of the key-encryption key in octets.</t> | ||||
</li> | ||||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>ukm is an optional random input to the key-derivation function.</ | ||||
t> | ||||
</li> | ||||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>wrap identifies a key-encryption algorithm used to encrypt the | ||||
keying material.</t> | ||||
</li> | ||||
</ul> | ||||
<ul empty="true"> | ||||
<li> | ||||
<t>encryptedKey is the result of encrypting the keying material with | ||||
the | ||||
key-encryption key. When used with the CMS enveloped-data content | key-encryption key. When used with the CMS enveloped-data content | |||
type <xref target="RFC5652"/>, the keying material is a content-encryption key. When | type <xref target="RFC5652"/>, the keying material is a content-encryption key. When | |||
used with the CMS authenticated-data content type <xref target="RFC5652"/>, the | used with the CMS authenticated-data content type <xref target="RFC5652"/>, the | |||
keying material is a message-authentication key. When used with the | keying material is a message-authentication key. When used with the | |||
CMS authenticated-enveloped-data content type <xref target="RFC5083"/>, the | CMS authenticated-enveloped-data content type <xref target="RFC5083"/>, the | |||
keying material is a content-authenticated-encryption key.</t> | keying material is a content-authenticated-encryption key (CAEK).</li> | |||
</li> | </ul> | |||
</ul> | <t>NOTE: For backward compatibility, implementations <bcp14>MAY</bcp14> also sup | |||
<t>NOTE: For backward compatibility, implementations <bcp14>MAY</bcp14> | port | |||
also support | the RSA-KEM Key Transport algorithm, identified by id-rsa-kem-spki, which uses | |||
RSA-KEM Key Transport Algorithm, identified by id-rsa-kem-spki, which uses | ||||
KeyTransRecipientInfo as specified in <xref target="RFC5990"/>.</t> | KeyTransRecipientInfo as specified in <xref target="RFC5990"/>.</t> | |||
</section> | </section> | |||
<section anchor="certificate-conventions"> | <section anchor="certificate-conventions"> | |||
<name>Certificate Conventions</name> | <name>Certificate Conventions</name> | |||
<t>The conventions specified in this section augment RFC 5280 <xref targ et="RFC5280"/>.</t> | <t>The conventions specified in this section augment RFC 5280 <xref targ et="RFC5280"/>.</t> | |||
<t>A recipient who employs the RSA-KEM Algorithm <bcp14>MAY</bcp14> iden tify the public key | <t>A recipient who employs the RSA-KEM algorithm <bcp14>MAY</bcp14> iden tify the public key | |||
in a certificate by the same AlgorithmIdentifier as for the | in a certificate by the same AlgorithmIdentifier as for the | |||
PKCS #1 v1.5 algorithm, that is, using the rsaEncryption object | PKCS #1 v1.5 algorithm, that is, using the rsaEncryption object | |||
identifier <xref target="RFC8017"/>. The fact that the recipient will accept RS A-KEM | identifier <xref target="RFC8017"/>. The fact that the recipient will accept RS A-KEM | |||
with this public key is not indicated by the use of this object | with this public key is not indicated by the use of this object | |||
identifier. The willingness to accept the RSA-KEM Algorithm <bcp14>MAY</bcp14> be | identifier. The willingness to accept the RSA-KEM algorithm <bcp14>MAY</bcp14> be | |||
signaled by the use of the SMIMECapabilities Attribute as specified in | signaled by the use of the SMIMECapabilities Attribute as specified in | |||
<xref section="2.5.2." sectionFormat="of" target="RFC8551"/> or the SMIMECapabil ities certificate | <xref section="2.5.2" sectionFormat="of" target="RFC8551"/> or the SMIMECapabili ties certificate | |||
extension as specified in <xref target="RFC4262"/>.</t> | extension as specified in <xref target="RFC4262"/>.</t> | |||
<t>If the recipient wishes only to employ the RSA-KEM Algorithm with a g iven | <t>If the recipient wishes only to employ the RSA-KEM algorithm with a g iven | |||
public key, the recipient <bcp14>MUST</bcp14> identify the public key in the cer tificate | public key, the recipient <bcp14>MUST</bcp14> identify the public key in the cer tificate | |||
using the id-rsa-kem-spki object identifier; see <xref target="app-asn1"/>. The use | using the id-rsa-kem-spki object identifier; see <xref target="app-asn1"/>. The use | |||
of the id-rsa-kem-spki object identifier allows certificates that were | of the id-rsa-kem-spki object identifier allows certificates that were | |||
issued to be compatible with RSA-KEM Key Transport to also be used with | issued to be compatible with RSA-KEM Key Transport to also be used with | |||
this specification. When the id-rsa-kem-spki object identifier appears | this specification. When the id-rsa-kem-spki object identifier appears | |||
in the SubjectPublicKeyInfo algorithm field of the certificate, the | in the SubjectPublicKeyInfo algorithm field of the certificate, the | |||
parameters field from AlgorithmIdentifier <bcp14>SHOULD</bcp14> be absent. That is, the | parameters field from AlgorithmIdentifier <bcp14>SHOULD</bcp14> be absent. That is, the | |||
AlgorithmIdentifier <bcp14>SHOULD</bcp14> be a SEQUENCE of one component, the | AlgorithmIdentifier <bcp14>SHOULD</bcp14> be a SEQUENCE of one component, the | |||
id-rsa-kem-spki object identifier. With absent parameters, the KDF3 | id-rsa-kem-spki object identifier. With absent parameters, the KDF3 | |||
key-derivation function <xref target="ANS-X9.44"/> with SHA-256 <xref target="SH S"/> are used to | key derivation function <xref target="ANS-X9.44"/> with SHA-256 <xref target="SH S"/> are used to | |||
derive the shared secret.</t> | derive the shared secret.</t> | |||
<t>When the AlgorithmIdentifier parameters are present, the | <t>When the AlgorithmIdentifier parameters are present, the | |||
GenericHybridParameters <bcp14>MUST</bcp14> be used. Within the kem element, th e algorithm | GenericHybridParameters <bcp14>MUST</bcp14> be used. Within the kem element, th e algorithm | |||
identifier <bcp14>MUST</bcp14> be set to id-kem-rsa, and RsaKemParameters <bcp14 >MUST</bcp14> be included. | identifier <bcp14>MUST</bcp14> be set to id-kem-rsa, and RsaKemParameters <bcp14 >MUST</bcp14> be included. | |||
As described in <xref target="smimecap"/>, the GenericHybridParameters constrain the values | As described in <xref target="smimecap"/>, the GenericHybridParameters constrain the values | |||
that can be used with the RSA public key for the kdf, kekLength, and wrap | that can be used with the RSA public key for the kdf, kekLength, and wrap | |||
fields of the KEMRecipientInfo structure.</t> | fields of the KEMRecipientInfo structure.</t> | |||
<t>Regardless of the AlgorithmIdentifier used, the RSA public key <bcp14 >MUST</bcp14> be | <t>Regardless of the AlgorithmIdentifier used, the RSA public key <bcp14 >MUST</bcp14> be | |||
carried in the subjectPublicKey BIT STRING within the SubjectPublicKeyInfo | carried in the subjectPublicKey BIT STRING within the SubjectPublicKeyInfo | |||
field of the certificate using the RSAPublicKey type defined in <xref target="RF C8017"/>.</t> | field of the certificate using the RSAPublicKey type defined in <xref target="RF C8017"/>.</t> | |||
<t>The intended application for the public key <bcp14>MAY</bcp14> be ind icated in the key usage | <t>The intended application for the public key <bcp14>MAY</bcp14> be ind icated in the key usage | |||
certificate extension as specified in <xref section="4.2.1.3" sectionFormat="of" target="RFC5280"/>. If the | certificate extension as specified in <xref section="4.2.1.3" sectionFormat="of" target="RFC5280"/>. If the | |||
keyUsage extension is present in a certificate that conveys an RSA public key | keyUsage extension is present in a certificate that conveys an RSA public key | |||
with the id-rsa-kem-spki object identifier as discussed above, then the key | with the id-rsa-kem-spki object identifier as discussed above, then the key | |||
usage extension <bcp14>MUST</bcp14> contain only the following value:</t> | usage extension <bcp14>MUST</bcp14> contain only the following value:</t> | |||
<ul empty="true"> | <t indent="3">keyEncipherment</t> | |||
<li> | ||||
<t>keyEncipherment</t> | ||||
</li> | ||||
</ul> | ||||
<t>Other keyUsage extension values <bcp14>MUST NOT</bcp14> be | <t>Other keyUsage extension values <bcp14>MUST NOT</bcp14> be | |||
present. That is, a public key intended to be employed only with the | present. That is, a public key intended to be employed only with the | |||
RSA-KEM Algorithm <bcp14>MUST NOT</bcp14> also be employed for data encryption o r | RSA-KEM algorithm <bcp14>MUST NOT</bcp14> also be employed for data encryption o r | |||
for digital signatures. Good cryptographic practice employs a given RSA | for digital signatures. Good cryptographic practice employs a given RSA | |||
key pair in only one scheme. This practice avoids the risk that vulnerability | key pair in only one scheme. This practice avoids the risk that vulnerability | |||
in one scheme may compromise the security of the other, and may be essential | in one scheme may compromise the security of the other and may be essential | |||
to maintain provable security.</t> | to maintain provable security.</t> | |||
</section> | </section> | |||
<section anchor="smimecap"> | <section anchor="smimecap"> | |||
<name>SMIMECapabilities Attribute Conventions</name> | <name>SMIMECapabilities Attribute Conventions</name> | |||
<t><xref section="2.5.2" sectionFormat="of" target="RFC8551"/> defines t he SMIMECapabilities attribute to | <t><xref section="2.5.2" sectionFormat="of" target="RFC8551"/> defines t he SMIMECapabilities attribute to | |||
announce a partial list of algorithms that an S/MIME implementation can | announce a partial list of algorithms that an S/MIME implementation can | |||
support. When constructing a CMS signed-data content type <xref target="RFC5652 "/>, | support. When constructing a CMS signed-data content type <xref target="RFC5652 "/>, | |||
a compliant implementation <bcp14>MAY</bcp14> include the SMIMECapabilities attr ibute | a compliant implementation <bcp14>MAY</bcp14> include the SMIMECapabilities attr ibute | |||
that announces support for the RSA-KEM Algorithm.</t> | that announces support for the RSA-KEM algorithm.</t> | |||
<t>The SMIMECapability SEQUENCE representing the RSA-KEM Algorithm <bcp1 | <t>The SMIMECapability SEQUENCE representing the RSA-KEM algorithm <bcp1 | |||
4>MUST</bcp14> | 4>MUST</bcp14> | |||
include the id-rsa-kem-spki object identifier in the capabilityID field; | include the id-rsa-kem-spki object identifier in the capabilityID field; | |||
see <xref target="app-asn1"/> for the object identifier value, and see <xref tar get="app-example"/> | see <xref target="app-asn1"/> for the object identifier value and <xref target=" app-example"/> | |||
for examples. When the id-rsa-kem-spki object identifier appears in the | for examples. When the id-rsa-kem-spki object identifier appears in the | |||
capabilityID field and the parameters are present, then the parameters | capabilityID field and the parameters are present, then the parameters | |||
field <bcp14>MUST</bcp14> use the GenericHybridParameters type.</t> | field <bcp14>MUST</bcp14> use the GenericHybridParameters type.</t> | |||
<artwork><![CDATA[ | ||||
<sourcecode type="asn.1"> | ||||
GenericHybridParameters ::= SEQUENCE { | GenericHybridParameters ::= SEQUENCE { | |||
kem KeyEncapsulationMechanism, | kem KeyEncapsulationMechanism, | |||
dem DataEncapsulationMechanism } | dem DataEncapsulationMechanism }</sourcecode> | |||
]]></artwork> | ||||
<t>The fields of the GenericHybridParameters type have the following mea nings:</t> | <t>The fields of the GenericHybridParameters type have the following mea nings:</t> | |||
<ul empty="true"> | <ul> | |||
<li> | <li> | |||
<t>kem is an AlgorithmIdentifer. The algorithm field <bcp14>MUST</b cp14> be set to id-kem-rsa, | <t>kem is an AlgorithmIdentifer. The algorithm field <bcp14>MUST</b cp14> be set to id-kem-rsa, | |||
and the parameters field <bcp14>MUST</bcp14> be RsaKemParameters, which is a SEQ UENCE of an | and the parameters field <bcp14>MUST</bcp14> be RsaKemParameters, which is a SEQ UENCE of an | |||
AlgorithmIdentifier that identifies the supported key-derivation function | AlgorithmIdentifier that identifies the supported key derivation function | |||
and a positive INTEGER that identifies the length of the key-encryption | and a positive INTEGER that identifies the length of the key-encryption | |||
key in octets.</t> | key in octets.</t> | |||
</li> | </li> | |||
</ul> | ||||
<ul empty="true"> | ||||
<li> | <li> | |||
<t>dem is an AlgorithmIdentifier. The algorithm field <bcp14>MUST</ bcp14> be present, and it | <t>dem is an AlgorithmIdentifier. The algorithm field <bcp14>MUST</ bcp14> be present, and it | |||
identifies the key-encryption algorithm. The parameters are optional. If the | identifies the key-encryption algorithm. The parameters are optional. If the | |||
GenericHybridParameters are present, then the provided dem value <bcp14>MUST</bc p14> be | GenericHybridParameters are present, then the provided dem value <bcp14>MUST</bc p14> be | |||
used in the wrap field of KEMRecipientInfo.</t> | used in the wrap field of KEMRecipientInfo.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>If the GenericHybridParameters are present, then the provided kem val ue <bcp14>MUST</bcp14> | <t>If the GenericHybridParameters are present, then the provided kem val ue <bcp14>MUST</bcp14> | |||
be used as the key-derivation function in the kdf field of KEMRecipientInfo, | be used as the key derivation function in the kdf field of KEMRecipientInfo | |||
and the provided key length <bcp14>MUST</bcp14> be used in the kekLength of KEMR ecipientInfo.</t> | and the provided key length <bcp14>MUST</bcp14> be used in the kekLength of KEMR ecipientInfo.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="security-considerations"> | <section anchor="security-considerations"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t>The RSA-KEM Algorithm should be considered as a replacement for the key transport portion of the | <t>The RSA-KEM algorithm should be considered as a replacement for the key transport portion of the | |||
widely implemented PKCS #1 v1.5 <xref target="RFC8017"/> for new applications | widely implemented PKCS #1 v1.5 <xref target="RFC8017"/> for new applications | |||
that use CMS to avoid potential vulnerabilities to chosen-ciphertext | that use CMS to avoid potential vulnerabilities to chosen-ciphertext | |||
attacks and gain a tighter security proof; however, the RSA-KEM Algorithm | attacks and gain a tighter security proof. However, the RSA-KEM algorithm | |||
has the disadvantage of slightly longer encrypted keying material. With | has the disadvantage of slightly longer encrypted keying material. With | |||
PKCS #1 v1.5, the originator encrypts the key-encryption key directly with | PKCS #1 v1.5, the originator encrypts the key-encryption key directly with | |||
the recipient's RSA public key. With the RSA-KEM, the key-encryption key | the recipient's RSA public key. With the RSA-KEM, the key-encryption key | |||
is encrypted separately.</t> | is encrypted separately.</t> | |||
<t>The security of the RSA-KEM Algorithm can be shown to be tightly relate | <t> The security of the RSA-KEM algorithm can be shown to be tightly related | |||
d | to the difficulty of either solving the RSA problem or breaking the underlying | |||
to the difficulty of either solving the RSA problem, or breaking the | symmetric key-encryption algorithm if the underlying key derivation function | |||
underlying symmetric key-encryption algorithm, if the underlying | is modeled as a random oracle, assuming that the symmetric key-encryption | |||
key-derivation function is modeled as a random oracle, and assuming that | algorithm satisfies the properties of a data encapsulation mechanism <xref | |||
the symmetric key-encryption algorithm satisfies the properties of a | target="SHOUP"/>. While in practice a random-oracle result does not provide | |||
data encapsulation mechanism <xref target="SHOUP"/>. While in practice a random | an actual security proof for any particular key derivation function, the | |||
-oracle | result does provide assurance that the general construction is reasonable; a | |||
result does not provide an actual security proof for any particular | key derivation function would need to be particularly weak to lead to an | |||
key-derivation function, the result does provide assurance that the general | attack that is not possible in the random-oracle model.</t> | |||
construction is reasonable; a key-derivation function would need to be | ||||
particularly weak to lead to an attack that is not possible in the | ||||
random-oracle model.</t> | ||||
<t>The RSA key size and the underlying components need to be selected | <t>The RSA key size and the underlying components need to be selected | |||
consistent with the desired security level. Several security levels | consistent with the desired security level. Several security levels | |||
have been identified in the NIST SP 800-57 Part 1 <xref target="NISTSP800-57pt1r 5"/>. For example, one way | have been identified in the NIST SP 800-57 Part 1 <xref target="NISTSP800-57pt1r 5"/>. For example, one way | |||
to achieve 128-bit security, the RSA key size would be at least 3072 bits, | to achieve 128-bit security, the RSA key size would be at least 3072 bits, | |||
the key-derivation function would be SHA-256, and the symmetric | the key derivation function would be SHA-256, and the symmetric | |||
key-encryption algorithm would be AES Key Wrap with a 128-bit key.</t> | key-encryption algorithm would be AES Key Wrap with a 128-bit key.</t> | |||
<t>Implementations <bcp14>MUST</bcp14> protect the RSA private key, the ke y-encryption key, | <t>Implementations <bcp14>MUST</bcp14> protect the RSA private key, the ke y-encryption key, | |||
the content-encryption key, message-authentication key, and the | the content-encryption key, message-authentication key, and the | |||
content-authenticated-encryption key. Disclosure of the RSA private key | content-authenticated-encryption key. Disclosure of the RSA private key | |||
could result in the compromise of all messages protected with that key. | could result in the compromise of all messages protected with that key. | |||
Disclosure of the key-encryption key, the content-encryption key, or the | Disclosure of the key-encryption key, the content-encryption key, or the | |||
content-authenticated-encryption key could result in compromise of the | content-authenticated-encryption key could result in compromise of the | |||
associated encrypted content. Disclosure of the key-encryption key, the | associated encrypted content. Disclosure of the key-encryption key, the | |||
message-authentication key, or the content-authenticated-encryption key | message-authentication key, or the content-authenticated-encryption key | |||
could allow modification of the associated authenticated content.</t> | could allow modification of the associated authenticated content.</t> | |||
<t>Additional considerations related to key management may be found in | <t>Additional considerations related to key management may be found in | |||
<xref target="NISTSP800-57pt1r5"/>.</t> | <xref target="NISTSP800-57pt1r5"/>.</t> | |||
<t>The security of the RSA-KEM Algorithm depends on a quality random numbe r | <t>The security of the RSA-KEM algorithm depends on a quality random numbe r | |||
generator. For further discussion on random number generation, | generator. For further discussion on random number generation, | |||
see <xref target="RFC4086"/>.</t> | see <xref target="RFC4086"/>.</t> | |||
<t>The RSA-KEM Algorithm does not use an explicit padding scheme; instead, | <t>The RSA-KEM algorithm does not use an explicit padding scheme. Instead, | |||
an encoded random value (z) between zero and the RSA modulus minus one (n-1) | an encoded random value (z) between zero and the RSA modulus minus one (n-1) | |||
is directly encrypted with the recipient's RSA public key. The | is directly encrypted with the recipient's RSA public key. The | |||
IntegerToString(z, nLen) encoding produces a string that is the full length of | IntegerToString(z, nLen) encoding produces a string that is the full length of | |||
the RSA modulus. In addition, the random value is passed through a key-derivati | the RSA modulus. In addition, the random value is passed through a | |||
on | KDF to reduce possible harm from a poorly implemented random number | |||
function (KDF) to reduce possible harm from a poorly implemented random number | ||||
source or a maliciously chosen random value (z). Implementations <bcp14>MUST NO T</bcp14> | source or a maliciously chosen random value (z). Implementations <bcp14>MUST NO T</bcp14> | |||
use z directly for any purpose.</t> | use z directly for any purpose.</t> | |||
<t>As long as a fresh random integer z is chosen as part of each invocatio n | <t>As long as a fresh random integer z is chosen as part of each invocatio n | |||
of the Encapsulate() function, RSA-KEM does not degrade as the number of | of the Encapsulate() function, RSA-KEM does not degrade as the number of | |||
ciphertexts increases. Since RSA encryption provides a bijective map, | ciphertexts increases. Since RSA encryption provides a bijective map, | |||
a collision in the KDF is the only way that RSA-KEM can produce more than | a collision in the KDF is the only way that RSA-KEM can produce more than | |||
one ciphertext that encapsulates the same shared secret.</t> | one ciphertext that encapsulates the same shared secret.</t> | |||
<t>The RSA-KEM Algorithm provides a fixed-length ciphertext. The recipien t <bcp14>MUST</bcp14> | <t>The RSA-KEM algorithm provides a fixed-length ciphertext. The recipien t <bcp14>MUST</bcp14> | |||
check that the received byte string is the expected length and the length | check that the received byte string is the expected length and the length | |||
corresponds to an integer in the expected range prior to attempting decryption | corresponds to an integer in the expected range prior to attempting decryption | |||
with their RSA private key as described in Steps 1 and 2 of <xref target="app-al g-decap"/>.</t> | with their RSA private key as described in Steps 1 and 2 of <xref target="app-al g-decap"/>.</t> | |||
<t>Implementations <bcp14>SHOULD NOT</bcp14> reveal information about inte rmediate | <t>Implementations <bcp14>SHOULD NOT</bcp14> reveal information about inte rmediate | |||
values or calculations, whether by timing or other "side channels", | values or calculations, whether by timing or other "side channels"; | |||
otherwise an opponent may be able to determine information about | otherwise, an opponent may be able to determine information about | |||
the keying data and/or the recipient's private key. Although not all | the keying data and/or the recipient's private key. Although not all | |||
intermediate information may be useful to an opponent, it is | intermediate information may be useful to an opponent, it is | |||
preferable to conceal as much information as is practical, unless | preferable to conceal as much information as is practical, unless | |||
analysis specifically indicates that the information would not be | analysis specifically indicates that the information would not be | |||
useful to an opponent.</t> | useful to an opponent.</t> | |||
<t>Generally, good cryptographic practice employs a given RSA key pair | <t>Generally, good cryptographic practice employs a given RSA key pair | |||
in only one scheme. This practice avoids the risk that vulnerability | in only one scheme. This practice avoids the risk that vulnerability | |||
in one scheme may compromise the security of the other, and may be | in one scheme may compromise the security of the other, and may be | |||
essential to maintain provable security. RSA public keys have often | essential to maintain provable security. RSA public keys have often | |||
been employed for multiple purposes such as key transport and digital | been employed for multiple purposes such as key transport and digital | |||
signature without any known bad interactions; however, such combined use | signature without any known bad interactions; however, such combined use | |||
of an RSA key pair is <bcp14>NOT RECOMMENDED</bcp14> in the future (unless the d ifferent | of an RSA key pair is <bcp14>NOT RECOMMENDED</bcp14> in the future (unless the d ifferent | |||
schemes are specifically designed to be used together).</t> | schemes are specifically designed to be used together).</t> | |||
<t>Accordingly, an RSA key pair used for the RSA-KEM Algorithm <bcp14>SHOU LD NOT</bcp14> | <t>Accordingly, an RSA key pair used for the RSA-KEM algorithm <bcp14>SHOU LD NOT</bcp14> | |||
also be used for digital signatures. Indeed, the Accredited Standards | also be used for digital signatures. Indeed, the Accredited Standards | |||
Committee X9 (ASC X9) requires such a separation between key pairs used | Committee X9 (ASC X9) requires such a separation between key pairs used | |||
for key establishment and key pairs used for digital signature | for key establishment and key pairs used for digital signature | |||
<xref target="ANS-X9.44"/>. Continuing this principle of key separation, a key pair | <xref target="ANS-X9.44"/>. Continuing this principle of key separation, a key pair | |||
used for the RSA-KEM Algorithm <bcp14>SHOULD NOT</bcp14> be used with other key | used for the RSA-KEM algorithm <bcp14>SHOULD NOT</bcp14> be used with other key | |||
establishment schemes, or for data encryption, or with more | establishment schemes, or for data encryption, or with more | |||
than one set of underlying algorithm components.</t> | than one set of underlying algorithm components.</t> | |||
<t>It is acceptable to use the same RSA key pair for RSA-KEM Key Transport | <t>It is acceptable to use the same RSA key pair for RSA-KEM Key Transport | |||
as specified in <xref target="RFC5990"/> and this specification. This is accept able | as specified in <xref target="RFC5990"/> and this specification. This is accept able | |||
because the operations involving the RSA public key and the RSA private | because the operations involving the RSA public key and the RSA private | |||
key are identical in the two specifications.</t> | key are identical in the two specifications.</t> | |||
<t>Parties can gain assurance that implementations are correct through | <t>Parties can gain assurance that implementations are correct through | |||
formal implementation validation, such as the NIST Cryptographic | formal implementation validation, such as the NIST Cryptographic | |||
Module Validation Program (CMVP) <xref target="CMVP"/>.</t> | Module Validation Program (CMVP) <xref target="CMVP"/>.</t> | |||
</section> | </section> | |||
<section anchor="iana-considerations"> | <section anchor="iana-considerations"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<t>For the ASN.1 Module in <xref target="app-asn1-module"/>, IANA is reque sted to assign an | <t>For the ASN.1 Module in <xref target="app-asn1-module"/>, IANA has assi gned an | |||
object identifier (OID) for the module identifier. The OID for the module | object identifier (OID) for the module identifier. The OID for the module | |||
should be allocated in the "SMI Security for S/MIME Module Identifier" | has been allocated in the "SMI Security for S/MIME Module Identifier" | |||
registry (1.2.840.113549.1.9.16.0), and the Description for the new OID | registry (1.2.840.113549.1.9.16.0), and the Description for the new OID | |||
should be set to "id-mod-cms-rsa-kem-2023".</t> | has been set to "id-mod-cms-rsa-kem-2023".</t> | |||
<t>IANA is requested to update the id-alg-rsa-kem entry in the SMI Security for | <t>IANA has updated the id-alg-rsa-kem entry in the "SMI Security for S/MIME Alg | |||
S/MIME Algorithms (1.2.840.113549.1.9.16.3) repository to refer to this document | orithms (1.2.840.113549.1.9.16.3)" repository to refer to this document. In add | |||
. In addition, IANA is requested to add the following note to the registry:</t> | ition, IANA has added the following note to the registry:</t> | |||
<t>Value 14, "id-alg-rsa-kem," is also referred to as "id-rsa-kem-spki."</t> | <t>Value 14, "id-alg-rsa-kem," is also referred to as "id-rsa-kem-spki."</t> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references anchor="sec-normative-references"> | <references anchor="sec-normative-references"> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<reference anchor="I-D.ietf-lamps-cms-kemri" target="https://datatracker | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.96 | |||
.ietf.org/doc/html/draft-ietf-lamps-cms-kemri-08" xml:base="https://bib.ietf.org | 29.xml"/> | |||
/public/rfc/bibxml3/reference.I-D.ietf-lamps-cms-kemri.xml"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.33 | |||
<title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cry | 94.xml"/> | |||
ptographic Message Syntax (CMS)</title> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50 | |||
<author fullname="Russ Housley" initials="R." surname="Housley"> | 83.xml"/> | |||
<organization>Vigil Security, LLC</organization> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52 | |||
</author> | 80.xml"/> | |||
<author fullname="John Gray" initials="J." surname="Gray"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56 | |||
<organization>Entrust</organization> | 52.xml"/> | |||
</author> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59 | |||
<author fullname="Tomofumi Okubo" initials="T." surname="Okubo"> | 11.xml"/> | |||
<organization>DigiCert, Inc.</organization> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59 | |||
</author> | 12.xml"/> | |||
<date day="6" month="February" year="2024"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62 | |||
<abstract> | 68.xml"/> | |||
<t>The Cryptographic Message Syntax (CMS) supports key transport a | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80 | |||
nd key agreement algorithms. In recent years, cryptographers have been specifyin | 17.xml"/> | |||
g Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM alg | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85 | |||
orithms. This document defines conventions for the use of KEM algorithms by the | 51.xml"/> | |||
originator and recipients to encrypt and decrypt CMS content. This document upda | ||||
tes RFC 5652.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-kemri-08 | ||||
"/> | ||||
</reference> | ||||
<reference anchor="RFC3394" target="https://www.rfc-editor.org/info/rfc3 | ||||
394" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"> | ||||
<front> | ||||
<title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<author fullname="R. Housley" initials="R." surname="Housley"/> | ||||
<date month="September" year="2002"/> | ||||
</front> | ||||
<seriesInfo name="RFC" value="3394"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC3394"/> | ||||
</reference> | ||||
<reference anchor="RFC5083" target="https://www.rfc-editor.org/info/rfc5 | ||||
083" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml"> | ||||
<front> | ||||
<title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Da | ||||
ta Content Type</title> | ||||
<author fullname="R. Housley" initials="R." surname="Housley"/> | ||||
<date month="November" year="2007"/> | ||||
<abstract> | ||||
<t>This document describes an additional content type for the Cryp | ||||
tographic Message Syntax (CMS). The authenticated-enveloped-data content type is | ||||
intended for use with authenticated encryption modes. All of the various key ma | ||||
nagement techniques that are supported in the CMS enveloped-data content type ar | ||||
e also supported by the CMS authenticated-enveloped-data content type. [STANDARD | ||||
S-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5083"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5083"/> | ||||
</reference> | ||||
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5 | ||||
280" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"> | ||||
<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> | ||||
<seriesInfo name="RFC" value="5280"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5280"/> | ||||
</reference> | ||||
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5 | ||||
652" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"> | ||||
<front> | ||||
<title>Cryptographic Message Syntax (CMS)</title> | ||||
<author fullname="R. Housley" initials="R." surname="Housley"/> | ||||
<date month="September" year="2009"/> | ||||
<abstract> | ||||
<t>This document describes the Cryptographic Message Syntax (CMS). | ||||
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra | ||||
ry message content. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="70"/> | ||||
<seriesInfo name="RFC" value="5652"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5652"/> | ||||
</reference> | ||||
<reference anchor="RFC5911" target="https://www.rfc-editor.org/info/rfc5 | ||||
911" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"> | ||||
<front> | ||||
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and | ||||
S/MIME</title> | ||||
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<date month="June" year="2010"/> | ||||
<abstract> | ||||
<t>The Cryptographic Message Syntax (CMS) format, and many associa | ||||
ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the | ||||
1988 version of ASN.1. This document updates those ASN.1 modules to conform to | ||||
the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the f | ||||
ormats; this is simply a change to the syntax. This document is not an Internet | ||||
Standards Track specification; it is published for informational purposes.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5911"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5911"/> | ||||
</reference> | ||||
<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5 | ||||
912" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"> | ||||
<front> | ||||
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.5 | ||||
09 (PKIX)</title> | ||||
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<date month="June" year="2010"/> | ||||
<abstract> | ||||
<t>The Public Key Infrastructure using X.509 (PKIX) certificate fo | ||||
rmat, and many associated formats, are expressed using ASN.1. The current ASN.1 | ||||
modules conform to the 1988 version of ASN.1. This document updates those ASN.1 | ||||
modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire c | ||||
hanges to any of the formats; this is simply a change to the syntax. This docume | ||||
nt is not an Internet Standards Track specification; it is published for informa | ||||
tional purposes.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5912"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5912"/> | ||||
</reference> | ||||
<reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6 | ||||
268" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"> | ||||
<front> | ||||
<title>Additional New ASN.1 Modules for the Cryptographic Message Sy | ||||
ntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<author fullname="S. Turner" initials="S." surname="Turner"/> | ||||
<date month="July" year="2011"/> | ||||
<abstract> | ||||
<t>The Cryptographic Message Syntax (CMS) format, and many associa | ||||
ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the | ||||
1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to co | ||||
nform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative | ||||
version. There are no bits- on-the-wire changes to any of the formats; this is s | ||||
imply a change to the syntax. This document is not an Internet Standards Track s | ||||
pecification; it is published for informational purposes.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6268"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6268"/> | ||||
</reference> | ||||
<reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8 | ||||
017" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"> | ||||
<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="RFC8551" target="https://www.rfc-editor.org/info/rfc8 | ||||
551" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"> | ||||
<front> | ||||
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version | ||||
4.0 Message Specification</title> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<author fullname="B. Ramsdell" initials="B." surname="Ramsdell"/> | ||||
<author fullname="S. Turner" initials="S." surname="Turner"/> | ||||
<date month="April" year="2019"/> | ||||
<abstract> | ||||
<t>This document defines Secure/Multipurpose Internet Mail Extensi | ||||
ons (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive s | ||||
ecure MIME data. Digital signatures provide authentication, message integrity, a | ||||
nd non-repudiation with proof of origin. Encryption provides data confidentialit | ||||
y. Compression can be used to reduce data size. This document obsoletes RFC 5751 | ||||
.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8551"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8551"/> | ||||
</reference> | ||||
<reference anchor="SHS"> | <reference anchor="SHS"> | |||
<front> | <front> | |||
<title>Secure Hash Standard</title> | <title>Secure Hash Standard</title> | |||
<author> | <author> | |||
<organization>National Institute of Standards and Technology</orga nization> | <organization>National Institute of Standards and Technology</orga nization> | |||
</author> | </author> | |||
<date year="2015" month="July"/> | <date year="2015" month="July"/> | |||
</front> | </front> | |||
<seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/> | <seriesInfo name="NIST FIPS PUB" value="180-4"/> | |||
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> | ||||
</reference> | </reference> | |||
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> | <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> | |||
<front> | <front> | |||
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> | <title>Information technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title> | |||
<author> | <author> | |||
<organization>ITU-T</organization> | <organization>ITU-T</organization> | |||
</author> | </author> | |||
<date year="2021" month="February"/> | <date year="2021" month="February"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.680"/> | <seriesInfo name="ITU-T Recommendation" value="X.680"/> | |||
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> | <seriesInfo name="ISO/IEC" value="8824-1:2021"/> | |||
</reference> | </reference> | |||
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.680"> | ||||
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690"> | ||||
<front> | <front> | |||
<title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> | <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> | |||
<author> | <author> | |||
<organization>ITU-T</organization> | <organization>ITU-T</organization> | |||
</author> | </author> | |||
<date year="2021" month="February"/> | <date year="2021" month="February"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.690"/> | <seriesInfo name="ITU-T Recommendation" value="X.690"/> | |||
<seriesInfo name="ISO/IEC" value="8825-1:2021"/> | <seriesInfo name="ISO/IEC" value="8825-1:2021"/> | |||
</reference> | </reference> | |||
<reference anchor="ANS-X9.44"> | ||||
<reference anchor="ANS-X9.44" target="https://webstore.ansi.org/standard | ||||
s/ascx9/ansix9442007r2017"> | ||||
<front> | <front> | |||
<title>Public Key Cryptography for the Financial Services Industry - - Key Establishment Using Integer Factorization Cryptography</title> | <title>Public Key Cryptography for the Financial Services Industry - - Key Establishment Using Integer Factorization Cryptography</title> | |||
<author> | <author> | |||
<organization>American National Standards Institute</organization> | <organization>American National Standards Institute</organization> | |||
</author> | </author> | |||
<date year="2007"/> | <date year="2007"/> | |||
</front> | </front> | |||
<seriesInfo name="American National Standard" value="X9.44"/> | <seriesInfo name="ANSI" value="X9.44-2007 (R2017)"/> | |||
</reference> | </reference> | |||
<reference anchor="ISO18033-2" target="https://www.iso.org/standard/3797 1.html"> | <reference anchor="ISO18033-2" target="https://www.iso.org/standard/3797 1.html"> | |||
<front> | <front> | |||
<title>Information technology -- Security techniques -- Encryption a lgorithms -- Part 2: Asymmetric ciphers</title> | <title>Information technology -- Security techniques -- Encryption a lgorithms -- Part 2: Asymmetric ciphers</title> | |||
<author> | <author> | |||
<organization>ISO/IEC JTC 1/SC 27</organization> | <organization>ISO/IEC</organization> | |||
</author> | </author> | |||
<date year="2006"/> | <date year="2006"/> | |||
</front> | </front> | |||
<seriesInfo name="ISO/IEC" value="18033-2:2006"/> | <seriesInfo name="ISO/IEC" value="18033-2:2006"/> | |||
</reference> | </reference> | |||
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 | ||||
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21 | |||
<front> | 19.xml"/> | |||
<title>Key words for use in RFCs to Indicate Requirement Levels</tit | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
le> | 74.xml"/> | |||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | ||||
<date month="March" year="1997"/> | ||||
<abstract> | ||||
<t>In many standards track documents several words are used to sig | ||||
nify the requirements in the specification. These words are often capitalized. T | ||||
his document defines these words as they should be interpreted in IETF documents | ||||
. This document specifies an Internet Best Current Practices for the Internet Co | ||||
mmunity, and requests discussion and suggestions for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="2119"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | ||||
</reference> | ||||
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 | ||||
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> | ||||
<front> | ||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti | ||||
tle> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<date month="May" year="2017"/> | ||||
<abstract> | ||||
<t>RFC 2119 specifies common key words that may be used in protoco | ||||
l specifications. This document aims to reduce the ambiguity by clarifying that | ||||
only UPPERCASE usage of the key words have the defined special meanings.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="8174"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/> | ||||
</reference> | ||||
</references> | </references> | |||
<references anchor="sec-informative-references"> | <references anchor="sec-informative-references"> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4 | ||||
086" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40 | |||
<front> | 86.xml"/> | |||
<title>Randomness Requirements for Security</title> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42 | |||
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 | 62.xml"/> | |||
rd"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59 | |||
<author fullname="J. Schiller" initials="J." surname="Schiller"/> | 90.xml"/> | |||
<author fullname="S. Crocker" initials="S." surname="Crocker"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.61 | |||
<date month="June" year="2005"/> | 94.xml"/> | |||
<abstract> | ||||
<t>Security systems are built on strong cryptographic algorithms t | ||||
hat foil pattern analysis attempts. However, the security of these systems is de | ||||
pendent on generating secret quantities for passwords, cryptographic keys, and s | ||||
imilar quantities. The use of pseudo-random processes to generate secret quantit | ||||
ies can result in pseudo-security. A sophisticated attacker may find it easier t | ||||
o reproduce the environment that produced the secret quantities and to search th | ||||
e resulting small set of possibilities than to locate the quantities in the whol | ||||
e of the potential number space.</t> | ||||
<t>Choosing random quantities to foil a resourceful and motivated | ||||
adversary is surprisingly difficult. This document points out many pitfalls in u | ||||
sing poor entropy sources or traditional pseudo-random number generation techniq | ||||
ues for generating such quantities. It recommends the use of truly random hardwa | ||||
re techniques and shows that the existing hardware on many systems can be used f | ||||
or this purpose. It provides suggestions to ameliorate the problem when a hardwa | ||||
re solution is not available, and it gives examples of how large such quantities | ||||
need to be for some applications. This document specifies an Internet Best Curr | ||||
ent Practices for the Internet Community, and requests discussion and suggestion | ||||
s for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="106"/> | ||||
<seriesInfo name="RFC" value="4086"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4086"/> | ||||
</reference> | ||||
<reference anchor="RFC4262" target="https://www.rfc-editor.org/info/rfc4 | ||||
262" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4262.xml"> | ||||
<front> | ||||
<title>X.509 Certificate Extension for Secure/Multipurpose Internet | ||||
Mail Extensions (S/MIME) Capabilities</title> | ||||
<author fullname="S. Santesson" initials="S." surname="Santesson"/> | ||||
<date month="December" year="2005"/> | ||||
<abstract> | ||||
<t>This document defines a certificate extension for inclusion of | ||||
Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 publ | ||||
ic key certificates, as defined by RFC 3280. This certificate extension provides | ||||
an optional method to indicate the cryptographic capabilities of an entity as a | ||||
complement to the S/MIME Capabilities signed attribute in S/MIME messages accor | ||||
ding to RFC 3851. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="4262"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4262"/> | ||||
</reference> | ||||
<reference anchor="RFC5990" target="https://www.rfc-editor.org/info/rfc5 | ||||
990" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5990.xml"> | ||||
<front> | ||||
<title>Use of the RSA-KEM Key Transport Algorithm in the Cryptograph | ||||
ic Message Syntax (CMS)</title> | ||||
<author fullname="J. Randall" initials="J." surname="Randall"/> | ||||
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> | ||||
<author fullname="J. Brainard" initials="J." surname="Brainard"/> | ||||
<author fullname="S. Turner" initials="S." surname="Turner"/> | ||||
<date month="September" year="2010"/> | ||||
<abstract> | ||||
<t>The RSA-KEM Key Transport Algorithm is a one-pass (store-and-fo | ||||
rward) mechanism for transporting keying data to a recipient using the recipient | ||||
's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This docume | ||||
nt specifies the conventions for using the RSA-KEM Key Transport Algorithm with | ||||
the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expe | ||||
cted forthcoming change to American National Standard (ANS) X9.44.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5990"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5990"/> | ||||
</reference> | ||||
<reference anchor="RFC6194" target="https://www.rfc-editor.org/info/rfc6 | ||||
194" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"> | ||||
<front> | ||||
<title>Security Considerations for the SHA-0 and SHA-1 Message-Diges | ||||
t Algorithms</title> | ||||
<author fullname="T. Polk" initials="T." surname="Polk"/> | ||||
<author fullname="L. Chen" initials="L." surname="Chen"/> | ||||
<author fullname="S. Turner" initials="S." surname="Turner"/> | ||||
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> | ||||
<date month="March" year="2011"/> | ||||
<abstract> | ||||
<t>This document includes security considerations for the SHA-0 an | ||||
d SHA-1 message digest algorithm. This document is not an Internet Standards Tra | ||||
ck specification; it is published for informational purposes.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6194"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6194"/> | ||||
</reference> | ||||
<reference anchor="NISTSP800-57pt1r5"> | <reference anchor="NISTSP800-57pt1r5"> | |||
<front> | <front> | |||
<title>Recommendation for Key Management:Part 1 - General</title> | <title>Recommendation for Key Management: Part 1 - General</title> | |||
<author> | <author fullname="Elaine Barker"> | |||
<organization>National Institute of Standards and Technology</orga nization> | <organization>National Institute of Standards and Technology</orga nization> | |||
</author> | </author> | |||
<date year="2020" month="May"/> | <date year="2020" month="May"/> | |||
</front> | </front> | |||
<seriesInfo name="NIST SP" value="800-57, Part 1, Revision 5"/> | ||||
<seriesInfo name="DOI" value="10.6028/nist.sp.800-57pt1r5"/> | <seriesInfo name="DOI" value="10.6028/nist.sp.800-57pt1r5"/> | |||
</reference> | </reference> | |||
<reference anchor="CMVP" target="https://csrc.nist.gov/projects/cryptogr aphic-module-validation-program"> | <reference anchor="CMVP" target="https://csrc.nist.gov/projects/cryptogr aphic-module-validation-program"> | |||
<front> | <front> | |||
<title>Cryptographic Module Validation Program</title> | <title>Cryptographic Module Validation Program</title> | |||
<author> | <author> | |||
<organization>National Institute of Standards and Technology</orga nization> | <organization>National Institute of Standards and Technology</orga nization> | |||
</author> | </author> | |||
<date year="2016"/> | <date year="2016"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="SHOUP" target="https://eprint.iacr.org/2001/112"> | <reference anchor="SHOUP" target="https://eprint.iacr.org/2001/112"> | |||
<front> | <front> | |||
<title>A Proposal for an ISO Standard for Public Key Encryption</tit le> | <title>A Proposal for an ISO Standard for Public Key Encryption</tit le> | |||
<author initials="V." surname="Shoup" fullname="Victor Shoup"> | <author initials="V." surname="Shoup" fullname="Victor Shoup"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2001"/> | <date year="2001"/> | |||
</front> | </front> | |||
<seriesInfo name="Cryptology ePrint Archive" value="Paper 2001/112"/> | <seriesInfo name="Cryptology ePrint Archive" value="Paper 2001/112"/> | |||
</reference> | </reference> | |||
</references> | </references> | |||
</references> | </references> | |||
<?line 665?> | ||||
<section anchor="app-alg"> | <section anchor="app-alg"> | |||
<name>RSA-KEM Algorithm</name> | <name>RSA-KEM Algorithm</name> | |||
<t>The RSA-KEM Algorithm is a one-pass (store-and-forward) cryptographic | <t>The RSA-KEM algorithm is a one-pass (store-and-forward) cryptographic | |||
mechanism for an originator to securely send keying material to a recipient | mechanism for an originator to securely send keying material to a recipient | |||
using the recipient's RSA public key.</t> | using the recipient's RSA public key.</t> | |||
<t>With the RSA-KEM Algorithm, an originator encrypts a random integer (z) with | <t>With the RSA-KEM algorithm, an originator encrypts a random integer (z) with | |||
the recipient's RSA public key to produce a ciphertext (ct), and the originator | the recipient's RSA public key to produce a ciphertext (ct), and the originator | |||
derives a shared secret (SS) from the random integer (z). The originator then | derives a shared secret (SS) from the random integer (z). The originator then | |||
sends the ciphertext (ct) to the recipient. The recipient decrypts the | sends the ciphertext (ct) to the recipient. The recipient decrypts the | |||
ciphertext (ct) using their private key to recover the random integer (z), | ciphertext (ct) using their private key to recover the random integer (z), | |||
and the recipient derives a shared secret (SS) from the random integer(z). In | and the recipient derives a shared secret (SS) from the random integer (z). In | |||
this way, originator and recipient obtain the same shared secret (SS).</t> | this way, the originator and recipient obtain the same shared secret (SS).</t> | |||
<t>The RSA-KEM Algorithm depends on a key-derivation function (KDF), which | <t>The RSA-KEM algorithm depends on a key derivation function (KDF), which | |||
is | is | |||
used to derive the shared secret (SS). Many key-derivation functions support | used to derive the shared secret (SS). Many key derivation functions support | |||
the inclusion of other information in addition to the shared secret (SS) in | the inclusion of other information in addition to the shared secret (SS) in | |||
the input to the function; however, no other information is included as an | the input to the function; however, no other information is included as an | |||
input to the KDF by the RSA-KEM Algorithm.</t> | input to the KDF by the RSA-KEM algorithm.</t> | |||
<section anchor="app-alg-encap"> | <section anchor="app-alg-encap"> | |||
<name>Originator's Operations: RSA-KEM Encapsulate()</name> | <name>Originator's Operations: RSA-KEM Encapsulate()</name> | |||
<t>Let (n,e) be the recipient's RSA public key; see <xref target="RFC801 7"/> for details.</t> | <t>Let (n,e) be the recipient's RSA public key; see <xref target="RFC801 7"/> for details.</t> | |||
<t>Let nLen denote the length in bytes of the modulus n, i.e., the least | <t>Let nLen denote the length in bytes of the modulus n, i.e., the least | |||
integer such that 2^(8*nLen) > n.</t> | integer such that 2<sup>(8*nLen)</sup> > n.</t> | |||
<t>The originator performs the following operations:</t> | <t>The originator performs the following operations:</t> | |||
<ol spacing="normal" type="1"><li> | <ol spacing="normal" type="1"><li> | |||
<t>Generate a random integer z between 0 and n-1 (see note), and | <t>Generate a random integer z between 0 and n-1 (see NOTE below), a | |||
convert z to a byte string Z of length nLen, most significant byte | nd | |||
first: </t> | convert z to a byte string Z of length nLen, most significant byte | |||
first: </t> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
z = RandomInteger (0, n-1) | z = RandomInteger (0, n-1) | |||
Z = IntegerToString (z, nLen) | Z = IntegerToString (z, nLen)]]></artwork> | |||
]]></artwork> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Encrypt the random integer z using the recipient's RSA public key | <t>Encrypt the random integer z using the recipient's RSA public | |||
(n,e), and convert the resulting integer c to a ciphertext C, a | key (n,e) and convert the resulting integer c to a ciphertext C, | |||
byte string of length nLen: </t> | a byte string of length nLen: </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
c = z^e mod n | c = z^e mod n | |||
ct = IntegerToString (c, nLen) | ct = IntegerToString (c, nLen)]]></artwork> | |||
]]></artwork> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Derive a symmetric shared secret SS of length ssLen bytes (which <bcp14>MUST</bcp14> be the length of the key-encryption key) from the | <t>Derive a symmetric shared secret SS of length ssLen bytes (which <bcp14>MUST</bcp14> be the length of the key-encryption key) from the | |||
byte string Z using the underlying key-derivation function: </t> | byte string Z using the underlying key derivation function: </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
SS = KDF (Z, ssLen) | SS = KDF (Z, ssLen)]]></artwork> | |||
]]></artwork> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Output the shared secret SS and the ciphertext ct. Send the | <t>Output the shared secret SS and the ciphertext ct. Send the | |||
ciphertext ct to the recipient.</t> | ciphertext ct to the recipient.</t> | |||
</li> | </li> | |||
</ol> | </ol> | |||
<t>NOTE: The random integer z <bcp14>MUST</bcp14> be generated independe ntly at random | <t>NOTE: The random integer z <bcp14>MUST</bcp14> be generated independe ntly at random | |||
for different encryption operations, whether for the same or different | for different encryption operations, whether for the same or different | |||
recipients.</t> | recipients.</t> | |||
</section> | </section> | |||
skipping to change at line 981 ¶ | skipping to change at line 711 ¶ | |||
<t>Let ct be the ciphertext received from the originator.</t> | <t>Let ct be the ciphertext received from the originator.</t> | |||
<t>Let nLen denote the length in bytes of the modulus n.</t> | <t>Let nLen denote the length in bytes of the modulus n.</t> | |||
<t>The recipient performs the following operations:</t> | <t>The recipient performs the following operations:</t> | |||
<ol spacing="normal" type="1"><li> | <ol spacing="normal" type="1"><li> | |||
<t>If the length of the encrypted keying material is less than nLen | <t>If the length of the encrypted keying material is less than nLen | |||
bytes, output "decryption error", and stop.</t> | bytes, output "decryption error", and stop.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Convert the ciphertext ct to an integer c, most significant byte | <t>Convert the ciphertext ct to an integer c, most significant byte | |||
first (see NOTE below): </t> | first (see NOTE below): </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
c = StringToInteger (ct) | c = StringToInteger (ct)]]></artwork> | |||
]]></artwork> | ||||
<t> | <t>If the integer c is not between 0 and n-1, output "decryption | |||
If the integer c is not between 0 and n-1, output "decryption | error", and stop.</t> | |||
error", and stop.</t> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Decrypt the integer c using the recipient's private key | <t>Decrypt the integer c using the recipient's private key (n,d) | |||
(n,d) to recover an integer z (see NOTE below): </t> | to recover an integer z (see NOTE below): </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
z = c^d mod n | z = c^d mod n]]></artwork> | |||
]]></artwork> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Convert the integer z to a byte string Z of length nLen, most | <t>Convert the integer z to a byte string Z of length nLen, most | |||
significant byte first (see NOTE below): </t> | significant byte first (see NOTE below): </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Z = IntegerToString (z, nLen) | Z = IntegerToString (z, nLen)]]></artwork> | |||
]]></artwork> | ||||
</li> | </li> | |||
<li> | <li> | |||
<t>Derive a shared secret SS of length ssLen bytes from the byte | <t>Derive a shared secret SS of length ssLen bytes from the byte | |||
string Z using the key-derivation function (see NOTE below): </t> | string Z using the key derivation function (see NOTE below): </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
SS = KDF (Z, ssLen) | SS = KDF (Z, ssLen) | |||
]]></artwork> | ]]></artwork> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Output the shared secret SS.</t> | <t>Output the shared secret SS.</t> | |||
</li> | </li> | |||
</ol> | </ol> | |||
<t>NOTE: Implementations <bcp14>SHOULD NOT</bcp14> reveal information ab out the | <t>NOTE: Implementations <bcp14>SHOULD NOT</bcp14> reveal information ab out the | |||
integer z, the string Z, or about the calculation of the | integer z, the string Z, or about the calculation of the | |||
skipping to change at line 1027 ¶ | skipping to change at line 755 ¶ | |||
The observable behavior of the implementation <bcp14>SHOULD</bcp14> be the same at | The observable behavior of the implementation <bcp14>SHOULD</bcp14> be the same at | |||
these steps for all ciphertexts C that are in range. For example, | these steps for all ciphertexts C that are in range. For example, | |||
IntegerToString conversion should take the same amount of time | IntegerToString conversion should take the same amount of time | |||
regardless of the actual value of the integer z. The integer z, the | regardless of the actual value of the integer z. The integer z, the | |||
string Z, and other intermediate results <bcp14>MUST</bcp14> be securely deleted | string Z, and other intermediate results <bcp14>MUST</bcp14> be securely deleted | |||
when they are no longer needed.</t> | when they are no longer needed.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="app-asn1"> | <section anchor="app-asn1"> | |||
<name>ASN.1 Syntax</name> | <name>ASN.1 Syntax</name> | |||
<t>The ASN.1 syntax for identifying the RSA-KEM Algorithm | <t>The ASN.1 syntax for identifying the RSA-KEM algorithm | |||
is an extension of the syntax for the "generic hybrid cipher" in | is an extension of the syntax for the "generic hybrid cipher" in | |||
ANS X9.44 <xref target="ANS-X9.44"/>.</t> | ANS X9.44 <xref target="ANS-X9.44"/>.</t> | |||
<t>The ASN.1 Module is unchanged from RFC 5990. The id-rsa-kem-spki | <t>The ASN.1 Module is unchanged from RFC 5990. The id-rsa-kem-spki | |||
object identifier is used in a backward compatible manner | object identifier is used in a backward compatible manner | |||
in certificates <xref target="RFC5280"/> and SMIMECapabilities <xref target="RFC 8551"/>. | in certificates <xref target="RFC5280"/> and SMIMECapabilities <xref target="RFC 8551"/>. | |||
Of course, the use of the id-kem-rsa object identifier in the | Of course, the use of the id-kem-rsa object identifier in the | |||
new KEMRecipientInfo structure <xref target="I-D.ietf-lamps-cms-kemri"/> | new KEMRecipientInfo structure <xref target="RFC9629"/> | |||
was not yet defined at the time that RFC 5990 was written.</t> | was not yet defined at the time that RFC 5990 was written.</t> | |||
<section anchor="app-asn1-intro"> | <section anchor="app-asn1-intro"> | |||
<name>Underlying Components</name> | <name>Underlying Components</name> | |||
<t>Implementations that conform to this specification <bcp14>MUST</bcp14 > support | <t>Implementations that conform to this specification <bcp14>MUST</bcp14 > support | |||
the KDF3 <xref target="ANS-X9.44"/> key-derivation function using SHA-256 <xref | the KDF3 <xref target="ANS-X9.44"/> key derivation function using SHA-256 <xref | |||
target="SHS"/>.</t> | target="SHS"/>.</t> | |||
<t>KDF2 <xref target="ANS-X9.44"/> and KDF3 are both key-derivation func | <t>KDF2 <xref target="ANS-X9.44"/> and KDF3 are both key derivation func | |||
tions based on | tions based on | |||
a hash function. The only difference between KDF2 and KDF3 is the order | a hash function. The only difference between KDF2 and KDF3 is the order | |||
of the components to be hashed.</t> | of the components to be hashed.</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
KDF2 calculates T as: T = T || Hash (Z || D || otherInfo) | KDF2 calculates T as: T = T || Hash (Z || D || otherInfo) | |||
KDF3 calculates T as: T = T || Hash (D || Z || otherInfo) | KDF3 calculates T as: T = T || Hash (D || Z || otherInfo)]]></artwork> | |||
]]></artwork> | ||||
<t>The object identifier for KDF3 is:</t> | <t>The object identifier for KDF3 is:</t> | |||
<artwork><![CDATA[ | <sourcecode type="asn.1"> | |||
id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) } | id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) }</sourcecode> | |||
]]></artwork> | ||||
<t>The KDF3 parameters identify the underlying hash function. For | <t>The KDF3 parameters identify the underlying hash function. For | |||
alignment with the ANS X9.44, the hash function <bcp14>MUST</bcp14> be an ASC X9 -approved | alignment with ANS X9.44, the hash function <bcp14>MUST</bcp14> be an ASC X9-app roved | |||
hash function. While the SHA-1 hash algorithm is included in the | hash function. While the SHA-1 hash algorithm is included in the | |||
ASN.1 definitions, SHA-1 <bcp14>MUST NOT</bcp14> be used. SHA-1 is considered | ASN.1 definitions, SHA-1 <bcp14>MUST NOT</bcp14> be used. SHA-1 is considered | |||
to be obsolete; see <xref target="RFC6194"/>. SHA-1 remains in the ASN.1 module for | to be obsolete; see <xref target="RFC6194"/>. SHA-1 remains in the ASN.1 module for | |||
compatibility with RFC 5990. In addition, other hash functions <bcp14>MAY</bcp1 4> be | compatibility with RFC 5990. In addition, other hash functions <bcp14>MAY</bcp1 4> be | |||
used with CMS.</t> | used with CMS.</t> | |||
<artwork><![CDATA[ | <sourcecode type="asn.1"> | |||
kda-kdf3 KEY-DERIVATION ::= { | kda-kdf3 KEY-DERIVATION ::= { | |||
IDENTIFIER id-kdf-kdf3 | IDENTIFIER id-kdf-kdf3 | |||
PARAMS TYPE KDF3-HashFunction ARE required | PARAMS TYPE KDF3-HashFunction ARE required | |||
-- No S/MIME caps defined -- } | -- No S/MIME caps defined -- } | |||
KDF3-HashFunction ::= | KDF3-HashFunction ::= | |||
AlgorithmIdentifier { DIGEST-ALGORITHM, {KDF3-HashFunctions} } | AlgorithmIdentifier { DIGEST-ALGORITHM, {KDF3-HashFunctions} } | |||
KDF3-HashFunctions DIGEST-ALGORITHM ::= { X9-HashFunctions, ... } | KDF3-HashFunctions DIGEST-ALGORITHM ::= { X9-HashFunctions, ... } | |||
X9-HashFunctions DIGEST-ALGORITHM ::= { | X9-HashFunctions DIGEST-ALGORITHM ::= { | |||
mda-sha1 | mda-sha224 | mda-sha256 | mda-sha384 | | mda-sha1 | mda-sha224 | mda-sha256 | mda-sha384 | | |||
mda-sha512, ... } | mda-sha512, ... }</sourcecode> | |||
]]></artwork> | ||||
<t>Implementations that conform to this specification <bcp14>MUST</bcp14 > support | <t>Implementations that conform to this specification <bcp14>MUST</bcp14 > support | |||
the AES Key Wrap <xref target="RFC3394"/> key-encryption algorithm with a 128-bi t | the AES Key Wrap <xref target="RFC3394"/> key-encryption algorithm with a 128-bi t | |||
key. There are three object identifiers for the AES Key Wrap, one for | key. There are three object identifiers for the AES Key Wrap, one for | |||
each permitted size of the key-encryption key. There are three object | each permitted size of the key-encryption key. There are three object | |||
identifiers imported from <xref target="RFC5912"/>, and none of these algorithm | identifiers imported from <xref target="RFC5912"/>, and none of these algorithm | |||
identifiers have associated parameters:</t> | identifiers have associated parameters:</t> | |||
<artwork><![CDATA[ | <sourcecode type="asn.1"> | |||
kwa-aes128-wrap KEY-WRAP ::= { | kwa-aes128-wrap KEY-WRAP ::= { | |||
IDENTIFIER id-aes128-wrap | IDENTIFIER id-aes128-wrap | |||
PARAMS ARE absent | PARAMS ARE absent | |||
SMIME-CAPS { IDENTIFIED BY id-aes128-wrap } } | SMIME-CAPS { IDENTIFIED BY id-aes128-wrap } } | |||
kwa-aes192-wrap KEY-WRAP ::= { | kwa-aes192-wrap KEY-WRAP ::= { | |||
IDENTIFIER id-aes192-wrap | IDENTIFIER id-aes192-wrap | |||
PARAMS ARE absent | PARAMS ARE absent | |||
SMIME-CAPS { IDENTIFIED BY id-aes192-wrap } } | SMIME-CAPS { IDENTIFIED BY id-aes192-wrap } } | |||
kwa-aes256-wrap KEY-WRAP ::= { | kwa-aes256-wrap KEY-WRAP ::= { | |||
IDENTIFIER id-aes256-wrap | IDENTIFIER id-aes256-wrap | |||
PARAMS ARE absent | PARAMS ARE absent | |||
SMIME-CAPS { IDENTIFIED BY id-aes256-wrap } } | SMIME-CAPS { IDENTIFIED BY id-aes256-wrap } }</sourcecode> | |||
]]></artwork> | ||||
</section> | </section> | |||
<section anchor="app-asn1-module"> | <section anchor="app-asn1-module"> | |||
<name>ASN.1 Module</name> | <name>ASN.1 Module</name> | |||
<t>RFC EDITOR: Please replace TBD2 with the value assigned by IANA | ||||
during the publication of <xref target="I-D.ietf-lamps-cms-kemri"/>.</t> | ||||
<sourcecode type="asn.1" markers="true"><![CDATA[ | <sourcecode type="asn.1" markers="true"><![CDATA[ | |||
CMS-RSA-KEM-2023 | CMS-RSA-KEM-2023 | |||
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | |||
pkcs-9(9) smime(16) modules(0) id-mod-cms-rsa-kem-2023(TBD1) } | pkcs-9(9) smime(16) modules(0) id-mod-cms-rsa-kem-2023(79) } | |||
DEFINITIONS EXPLICIT TAGS ::= BEGIN | DEFINITIONS EXPLICIT TAGS ::= BEGIN | |||
-- EXPORTS ALL | -- EXPORTS ALL | |||
IMPORTS | IMPORTS | |||
KEM-ALGORITHM | KEM-ALGORITHM | |||
FROM KEMAlgorithmInformation-2023 -- [I-D.ietf-lamps-cms-kemri] | FROM KEMAlgorithmInformation-2023 -- [I-D.ietf-lamps-cms-kemri] | |||
{ iso(1) identified-organization(3) dod(6) internet(1) | { iso(1) identified-organization(3) dod(6) internet(1) | |||
security(5) mechanisms(5) pkix(7) id-mod(0) | security(5) mechanisms(5) pkix(7) id-mod(0) | |||
id-mod-kemAlgorithmInformation-2023(TBD2) } | id-mod-kemAlgorithmInformation-2023(109) } | |||
AlgorithmIdentifier{}, PUBLIC-KEY, DIGEST-ALGORITHM, | AlgorithmIdentifier{}, PUBLIC-KEY, DIGEST-ALGORITHM, | |||
KEY-DERIVATION, KEY-WRAP, SMIME-CAPS | KEY-DERIVATION, KEY-WRAP, SMIME-CAPS | |||
FROM AlgorithmInformation-2009 -- [RFC5912] | FROM AlgorithmInformation-2009 -- [RFC5912] | |||
{ iso(1) identified-organization(3) dod(6) internet(1) | { iso(1) identified-organization(3) dod(6) internet(1) | |||
security(5) mechanisms(5) pkix(7) id-mod(0) | security(5) mechanisms(5) pkix(7) id-mod(0) | |||
id-mod-algorithmInformation-02(58) } | id-mod-algorithmInformation-02(58) } | |||
kwa-aes128-wrap, kwa-aes192-wrap, kwa-aes256-wrap | kwa-aes128-wrap, kwa-aes192-wrap, kwa-aes256-wrap | |||
FROM CMSAesRsaesOaep-2009 -- [RFC5911] | FROM CMSAesRsaesOaep-2009 -- [RFC5911] | |||
skipping to change at line 1315 ¶ | skipping to change at line 1042 ¶ | |||
SMimeCapsSet SMIME-CAPS ::= { | SMimeCapsSet SMIME-CAPS ::= { | |||
kema-kem-rsa.&smimeCaps | | kema-kem-rsa.&smimeCaps | | |||
kwa-aes128-wrap | | kwa-aes128-wrap | | |||
kwa-aes192-wrap | | kwa-aes192-wrap | | |||
kwa-aes256-wrap | | kwa-aes256-wrap | | |||
kwa-camellia128-wrap.&smimeCaps | | kwa-camellia128-wrap.&smimeCaps | | |||
kwa-camellia192-wrap.&smimeCaps | | kwa-camellia192-wrap.&smimeCaps | | |||
kwa-camellia256-wrap.&smimeCaps, | kwa-camellia256-wrap.&smimeCaps, | |||
... } | ... } | |||
END | END]]></sourcecode> | |||
]]></sourcecode> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="app-example"> | <section anchor="app-example"> | |||
<name>SMIMECapabilities Examples</name> | <name>SMIMECapabilities Examples</name> | |||
<t>To indicate support for the RSA-KEM algorithm coupled with the KDF3 | <t>To indicate support for the RSA-KEM algorithm coupled with the KDF3 | |||
key-derivation function with SHA-256 and the AES Key Wrap symmetric | key derivation function with SHA-256 and the AES Key Wrap symmetric | |||
key-encryption algorithm 128-bit key-encryption key, the | key-encryption algorithm 128-bit key-encryption key, the | |||
SMIMECapabilities will include the following entry:</t> | SMIMECapabilities will include the following entry:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
SEQUENCE { | SEQUENCE { | |||
id-rsa-kem-spki, -- RSA-KEM Algorithm | id-rsa-kem-spki, -- RSA-KEM Algorithm | |||
SEQUENCE { -- GenericHybridParameters | SEQUENCE { -- GenericHybridParameters | |||
SEQUENCE { -- key encapsulation mechanism | SEQUENCE { -- key encapsulation mechanism | |||
id-kem-rsa, -- RSA-KEM | id-kem-rsa, -- RSA-KEM | |||
SEQUENCE { -- RsaKemParameters | SEQUENCE { -- RsaKemParameters | |||
SEQUENCE { -- key derivation function | SEQUENCE { -- key derivation function | |||
id-kdf-kdf3, -- KDF3 | id-kdf-kdf3, -- KDF3 | |||
SEQUENCE { -- KDF3-HashFunction | SEQUENCE { -- KDF3-HashFunction | |||
id-sha256 -- SHA-256; no parameters (preferred) | id-sha256 -- SHA-256; no parameters (preferred) | |||
}, | }, | |||
16 -- KEK length in bytes | 16 -- KEK length in bytes | |||
}, | }, | |||
SEQUENCE { -- data encapsulation mechanism | SEQUENCE { -- data encapsulation mechanism | |||
id-aes128-Wrap -- AES-128 Wrap; no parameters | id-aes128-Wrap -- AES-128 Wrap; no parameters | |||
} | } | |||
} | } | |||
} | }]]></artwork> | |||
]]></artwork> | ||||
<t>This SMIMECapability value has the following DER encoding (in hexadecim al):</t> | <t>This SMIMECapability value has the following DER encoding (in hexadecim al):</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
30 47 | 30 47 | |||
06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem-spki | 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem-spki | |||
30 38 | 30 38 | |||
30 29 | 30 29 | |||
06 07 28 81 8c 71 02 02 04 -- id-kem-rsa | 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa | |||
30 1e | 30 1e | |||
30 19 | 30 19 | |||
06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 | |||
30 0b | 30 0b | |||
06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 | 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 | |||
02 01 10 -- 16 bytes | 02 01 10 -- 16 bytes | |||
30 0b | 30 0b | |||
06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap | 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap]]></artwork> | |||
]]></artwork> | ||||
<t>To indicate support for the RSA-KEM algorithm coupled with the KDF3 | <t>To indicate support for the RSA-KEM algorithm coupled with the KDF3 | |||
key-derivation function with SHA-384 and the AES Key Wrap symmetric | key derivation function with SHA-384 and the AES Key Wrap symmetric | |||
key-encryption algorithm 192-bit key-encryption key, the | key-encryption algorithm 192-bit key-encryption key, the | |||
SMIMECapabilities will include the following SMIMECapability value | SMIMECapabilities will include the following SMIMECapability value | |||
(in hexadecimal):</t> | (in hexadecimal):</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | |||
38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | |||
06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | |||
60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 | 60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 | |||
60 86 48 01 65 03 04 01 19 | 60 86 48 01 65 03 04 01 19]]></artwork> | |||
]]></artwork> | ||||
<t>To indicate support for the RSA-KEM algorithm coupled with the KDF3 | <t>To indicate support for the RSA-KEM algorithm coupled with the KDF3 | |||
key-derivation function with SHA-512 and the AES Key Wrap symmetric | key derivation function with SHA-512 and the AES Key Wrap symmetric | |||
key-encryption algorithm 256-bit key-encryption key, the | key-encryption algorithm 256-bit key-encryption key, the | |||
SMIMECapabilities will include the following SMIMECapability value | SMIMECapabilities will include the following SMIMECapability value | |||
(in hexadecimal):</t> | (in hexadecimal):</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | |||
38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | |||
06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | |||
60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 | 60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 | |||
60 86 48 01 65 03 04 01 2d | 60 86 48 01 65 03 04 01 2d]]></artwork> | |||
]]></artwork> | ||||
</section> | </section> | |||
<section anchor="rsa-kem-cms-enveloped-data-example"> | <section anchor="rsa-kem-cms-enveloped-data-example"> | |||
<name>RSA-KEM CMS Enveloped-Data Example</name> | <name>RSA-KEM CMS Enveloped-Data Example</name> | |||
<t>This example shows the establishment of an AES-128 content-encryption | <t>This example shows the establishment of an AES-128 content-encryption | |||
key using:</t> | key using:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>RSA-KEM with a 3072-bit key and KDF3 with SHA-256;</t> | <t>RSA-KEM with a 3072-bit key and KDF3 with SHA-256;</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>KEMRecipientInfo key derivation using KDF3 with SHA-256; and</t> | <t>KEMRecipientInfo key derivation using KDF3 with SHA-256; and</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>KEMRecipientInfo key wrap using AES-128-KEYWRAP.</t> | <t>KEMRecipientInfo Key Wrap using AES-128-KEYWRAP.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>In real-world use, the originator would encrypt the content-encryption | <t>In real-world use, the originator would encrypt the content-encryption | |||
key in a manner that would allow decryption with their own private key | key in a manner that would allow decryption with their own private key | |||
as well as the recipient's private key. This is omitted in an attempt | as well as the recipient's private key. This is omitted in an attempt | |||
to simplify the example.</t> | to simplify the example.</t> | |||
<section anchor="originator-rsa-kem-encapsulate-processing"> | <section anchor="originator-rsa-kem-encapsulate-processing"> | |||
<name>Originator RSA-KEM Encapsulate() Processing</name> | <name>Originator RSA-KEM Encapsulate() Processing</name> | |||
<t>Alice obtains Bob's public key:</t> | <t>Alice obtains Bob's public key:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
-----BEGIN PUBLIC KEY----- | -----BEGIN PUBLIC KEY----- | |||
MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ | MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ | |||
AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH | AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH | |||
Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq | Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq | |||
vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx | vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx | |||
2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v | 2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v | |||
SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a | SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a | |||
uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy | uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy | |||
FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS | FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS | |||
whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= | whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= | |||
-----END PUBLIC KEY----- | -----END PUBLIC KEY-----]]></artwork> | |||
]]></artwork> | ||||
<t>Bob's RSA public key has the following key identifier:</t> | <t>Bob's RSA public key has the following key identifier:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
9eeb67c9b95a74d44d2f16396680e801b5cba49c | 9eeb67c9b95a74d44d2f16396680e801b5cba49c]]></artwork> | |||
]]></artwork> | ||||
<t>Alice randomly generates integer z between 0 and n-1:</t> | <t>Alice randomly generates integer z between 0 and n-1:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
9c126102a5c1c0354672a3c2f19fc9ddea988f815e1da812c7bd4f8eb082bdd1 | 9c126102a5c1c0354672a3c2f19fc9ddea988f815e1da812c7bd4f8eb082bdd1 | |||
4f85a7f7c2f1af11d5333e0d6bcb375bf855f208da72ba27e6fb0655f2825aa6 | 4f85a7f7c2f1af11d5333e0d6bcb375bf855f208da72ba27e6fb0655f2825aa6 | |||
2b93b1f9bbd3491fed58f0380fa0de36430e3a144d569600bd362609be5b9481 | 2b93b1f9bbd3491fed58f0380fa0de36430e3a144d569600bd362609be5b9481 | |||
0875990b614e406fa6dff500043cbca95968faba61f795096a7fb3687a51078c | 0875990b614e406fa6dff500043cbca95968faba61f795096a7fb3687a51078c | |||
4ca2cb663366b0bea0cd9cccac72a25f3f4ed03deb68b4453bba44b943f4367b | 4ca2cb663366b0bea0cd9cccac72a25f3f4ed03deb68b4453bba44b943f4367b | |||
67d6cd10c8ace53f545aac50968fc3c6ecc80f3224b64e37038504e2d2c0e2b2 | 67d6cd10c8ace53f545aac50968fc3c6ecc80f3224b64e37038504e2d2c0e2b2 | |||
9d45e46c62826d96331360e4c17ea3ef89a9efc5fac99eda830e81450b6534dc | 9d45e46c62826d96331360e4c17ea3ef89a9efc5fac99eda830e81450b6534dc | |||
0bdf042b8f3b706649c631fe51fc2445cc8d447203ec2f41f79cdfea16de1ce6 | 0bdf042b8f3b706649c631fe51fc2445cc8d447203ec2f41f79cdfea16de1ce6 | |||
abdfdc1e2ef2e5d5d8a65e645f397240ef5a26f5e4ff715de782e30ecf477293 | abdfdc1e2ef2e5d5d8a65e645f397240ef5a26f5e4ff715de782e30ecf477293 | |||
e89e13171405909a8e04dd31d21d0c57935fc1ceea8e1033e31e1bc8c56da0f3 | e89e13171405909a8e04dd31d21d0c57935fc1ceea8e1033e31e1bc8c56da0f3 | |||
d79510f3f380ff58e5a61d361f2f18e99fbae5663172e8cd1f21deaddc5bbbea | d79510f3f380ff58e5a61d361f2f18e99fbae5663172e8cd1f21deaddc5bbbea | |||
060d55f1842b93d1a9c888d0bf85d0af9947fe51acf940c7e7577eb79cabecb3 | 060d55f1842b93d1a9c888d0bf85d0af9947fe51acf940c7e7577eb79cabecb3]]></artwork> | |||
]]></artwork> | ||||
<t>Alice encrypts integer z using the Bob's RSA public key, the result i | <t>Alice encrypts integer z using the Bob's RSA public key. The result i | |||
s | s | |||
called ct:</t> | called ct:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
c071fc273af8e7bdb152e06bf73310361074154a43abcf3c93c13499d2065344 | c071fc273af8e7bdb152e06bf73310361074154a43abcf3c93c13499d2065344 | |||
3eed9ef5d3c0685e4aa76a6854815bb97691ff9f8dac15eea7d74f452bf350a6 | 3eed9ef5d3c0685e4aa76a6854815bb97691ff9f8dac15eea7d74f452bf350a6 | |||
46163d68288e978cbf7a73089ee52712f9a4f49e06ace7bbc85ab14d4e336c97 | 46163d68288e978cbf7a73089ee52712f9a4f49e06ace7bbc85ab14d4e336c97 | |||
c5728a2654138c7b26e8835c6b0a9fbed26495c4eadf745a2933be283f6a88b1 | c5728a2654138c7b26e8835c6b0a9fbed26495c4eadf745a2933be283f6a88b1 | |||
6695fc06666873cfb6d36718ef3376cefc100c3941f3c494944078325807a559 | 6695fc06666873cfb6d36718ef3376cefc100c3941f3c494944078325807a559 | |||
186b95ccabf3714cfaf79f83bd30537fdd9aed5a4cdcbd8bd0486faed73e9d48 | 186b95ccabf3714cfaf79f83bd30537fdd9aed5a4cdcbd8bd0486faed73e9d48 | |||
6b3087d6c806546b6e2671575c98461e441f65542bd95de26d0f53a64e7848d7 | 6b3087d6c806546b6e2671575c98461e441f65542bd95de26d0f53a64e7848d7 | |||
31d9608d053e8d345546602d86236ffe3704c98ad59144f3089e5e6d527b5497 | 31d9608d053e8d345546602d86236ffe3704c98ad59144f3089e5e6d527b5497 | |||
ba103c79d62e80d0235410b06f71a7d9bd1c38000f910d6312ea2f20a3557535 | ba103c79d62e80d0235410b06f71a7d9bd1c38000f910d6312ea2f20a3557535 | |||
ad01b3093fb5f7ee507080d0f77d48c9c3b3796f6b7dd3786085fb895123f04c | ad01b3093fb5f7ee507080d0f77d48c9c3b3796f6b7dd3786085fb895123f04c | |||
a1f1c1be22c747a8dface32370fb0d570783e27dbb7e74fca94ee39676fde3d8 | a1f1c1be22c747a8dface32370fb0d570783e27dbb7e74fca94ee39676fde3d8 | |||
a9553d878224736e37e191dab953c7e228c07ad5ca3122421c14debd072a9ab6 | a9553d878224736e37e191dab953c7e228c07ad5ca3122421c14debd072a9ab6]]></artwork> | |||
]]></artwork> | ||||
<t>Alice derives the shared secret (SS) using KDF3 with SHA-256:</t> | <t>Alice derives the shared secret (SS) using KDF3 with SHA-256:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
3cf82ec41b54ed4d37402bbd8f805a52 | 3cf82ec41b54ed4d37402bbd8f805a52]]></artwork> | |||
]]></artwork> | ||||
</section> | </section> | |||
<section anchor="originator-cms-processing"> | <section anchor="originator-cms-processing"> | |||
<name>Originator CMS Processing</name> | <name>Originator CMS Processing</name> | |||
<t>Alice encodes the CMSORIforKEMOtherInfo structure with the algorithm | <t>Alice encodes the CMSORIforKEMOtherInfo structure with the algorithm | |||
identifier for AES-128-KEYWRAP and a key length of 16 octets. | identifier for AES-128-KEYWRAP and a key length of 16 octets. | |||
The DER encoding of CMSORIforKEMOtherInfo produces 18 octets:</t> | The DER encoding of CMSORIforKEMOtherInfo produces 18 octets:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
3010300b0609608648016503040105020110 | 3010300b0609608648016503040105020110]]></artwork> | |||
]]></artwork> | ||||
<t>The CMSORIforKEMOtherInfo structure contains:</t> | <t>The CMSORIforKEMOtherInfo structure contains:</t> | |||
<ul empty="true"> | ||||
<li> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
0 16: SEQUENCE { | 0 16: SEQUENCE { | |||
2 11: SEQUENCE { | 2 11: SEQUENCE { | |||
4 9: OBJECT IDENTIFIER aes128-wrap (2 16 840 1 101 3 4 1 5) | 4 9: OBJECT IDENTIFIER aes128-wrap (2 16 840 1 101 3 4 1 5) | |||
: } | : } | |||
15 1: INTEGER 16 | 15 1: INTEGER 16 | |||
: } | : }]]></artwork> | |||
]]></artwork> | ||||
</li> | ||||
</ul> | ||||
<t>Alice derives the key-encryption key from shared secret produced | <t>Alice derives the key-encryption key from shared secret produced | |||
by RSA-KEM Encapsulate() and the CMSORIforKEMOtherInfo structure | by RSA-KEM Encapsulate() and the CMSORIforKEMOtherInfo structure | |||
with KDF3 and SHA-256, the KEK is:</t> | with KDF3 and SHA-256. The KEK is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
e6dc9d62ff2b469bef604c617b018718 | e6dc9d62ff2b469bef604c617b018718]]></artwork> | |||
]]></artwork> | ||||
<t>Alice randomly generates a 128-bit content-encryption key:</t> | <t>Alice randomly generates a 128-bit content-encryption key:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
77f2a84640304be7bd42670a84a1258b | 77f2a84640304be7bd42670a84a1258b]]></artwork> | |||
]]></artwork> | ||||
<t>Alice uses AES-128-KEYWRAP to encrypt the 128-bit content-encryption | <t>Alice uses AES-128-KEYWRAP to encrypt the 128-bit content-encryption | |||
key with the derived key-encryption key:</t> | key with the derived key-encryption key:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
28782e5d3d794a7616b863fbcfc719b78f12de08cf286e09 | 28782e5d3d794a7616b863fbcfc719b78f12de08cf286e09]]></artwork> | |||
]]></artwork> | ||||
<t>Alice encrypts the padded content using AES-128-CBC with the | <t>Alice encrypts the padded content using AES-128-CBC with the | |||
content-encryption key. The 16-octet IV used is:</t> | content-encryption key. The 16-octet IV used is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
480ccafebabefacedbaddecaf8887781 | 480ccafebabefacedbaddecaf8887781]]></artwork> | |||
]]></artwork> | ||||
<t>The padded content plaintext is:</t> | <t>The padded content plaintext is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
48656c6c6f2c20776f726c6421030303 | 48656c6c6f2c20776f726c6421030303]]></artwork> | |||
]]></artwork> | ||||
<t>The resulting ciphertext is:</t> | <t>The resulting ciphertext is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
c6ca65db7bdd76b0f37e2fab6264b66d | c6ca65db7bdd76b0f37e2fab6264b66d]]></artwork> | |||
]]></artwork> | ||||
<t>Alice encodes the EnvelopedData (using KEMRecipientInfo) and | <t>Alice encodes the EnvelopedData (using KEMRecipientInfo) and | |||
ContentInfo, and then sends the result to Bob. The Base64-encoded | ContentInfo, and then sends the result to Bob. The Base64-encoded | |||
result is:</t> | result is:</t> | |||
<ul empty="true"> | ||||
<li> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
MIICXAYJKoZIhvcNAQcDoIICTTCCAkkCAQMxggIEpIICAAYLKoZIhvcNAQkQDQMw | MIICXAYJKoZIhvcNAQcDoIICTTCCAkkCAQMxggIEpIICAAYLKoZIhvcNAQkQDQMw | |||
ggHvAgEAgBSe62fJuVp01E0vFjlmgOgBtcuknDAJBgcogYxxAgIEBIIBgMBx/Cc6 | ggHvAgEAgBSe62fJuVp01E0vFjlmgOgBtcuknDAJBgcogYxxAgIEBIIBgMBx/Cc6 | |||
+Oe9sVLga/czEDYQdBVKQ6vPPJPBNJnSBlNEPu2e9dPAaF5Kp2poVIFbuXaR/5+N | +Oe9sVLga/czEDYQdBVKQ6vPPJPBNJnSBlNEPu2e9dPAaF5Kp2poVIFbuXaR/5+N | |||
rBXup9dPRSvzUKZGFj1oKI6XjL96cwie5ScS+aT0ngas57vIWrFNTjNsl8VyiiZU | rBXup9dPRSvzUKZGFj1oKI6XjL96cwie5ScS+aT0ngas57vIWrFNTjNsl8VyiiZU | |||
E4x7JuiDXGsKn77SZJXE6t90Wikzvig/aoixZpX8BmZoc8+202cY7zN2zvwQDDlB | E4x7JuiDXGsKn77SZJXE6t90Wikzvig/aoixZpX8BmZoc8+202cY7zN2zvwQDDlB | |||
88SUlEB4MlgHpVkYa5XMq/NxTPr3n4O9MFN/3ZrtWkzcvYvQSG+u1z6dSGswh9bI | 88SUlEB4MlgHpVkYa5XMq/NxTPr3n4O9MFN/3ZrtWkzcvYvQSG+u1z6dSGswh9bI | |||
BlRrbiZxV1yYRh5EH2VUK9ld4m0PU6ZOeEjXMdlgjQU+jTRVRmAthiNv/jcEyYrV | BlRrbiZxV1yYRh5EH2VUK9ld4m0PU6ZOeEjXMdlgjQU+jTRVRmAthiNv/jcEyYrV | |||
kUTzCJ5ebVJ7VJe6EDx51i6A0CNUELBvcafZvRw4AA+RDWMS6i8go1V1Na0Bswk/ | kUTzCJ5ebVJ7VJe6EDx51i6A0CNUELBvcafZvRw4AA+RDWMS6i8go1V1Na0Bswk/ | |||
tffuUHCA0Pd9SMnDs3lva33TeGCF+4lRI/BMofHBviLHR6jfrOMjcPsNVweD4n27 | tffuUHCA0Pd9SMnDs3lva33TeGCF+4lRI/BMofHBviLHR6jfrOMjcPsNVweD4n27 | |||
fnT8qU7jlnb949ipVT2HgiRzbjfhkdq5U8fiKMB61coxIkIcFN69ByqatjAbBgor | fnT8qU7jlnb949ipVT2HgiRzbjfhkdq5U8fiKMB61coxIkIcFN69ByqatjAbBgor | |||
gQUQhkgJLAECMA0GCWCGSAFlAwQCAQUAAgEQMAsGCWCGSAFlAwQBBQQYKHguXT15 | gQUQhkgJLAECMA0GCWCGSAFlAwQCAQUAAgEQMAsGCWCGSAFlAwQBBQQYKHguXT15 | |||
SnYWuGP7z8cZt48S3gjPKG4JMDwGCSqGSIb3DQEHATAdBglghkgBZQMEAQIEEEgM | SnYWuGP7z8cZt48S3gjPKG4JMDwGCSqGSIb3DQEHATAdBglghkgBZQMEAQIEEEgM | |||
yv66vvrO263eyviId4GAEMbKZdt73Xaw834vq2Jktm0= | yv66vvrO263eyviId4GAEMbKZdt73Xaw834vq2Jktm0=]]></artwork> | |||
]]></artwork> | ||||
</li> | ||||
</ul> | ||||
<t>This result decodes to:</t> | <t>This result decodes to:</t> | |||
<ul empty="true"> | ||||
<li> | ||||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
0 604: SEQUENCE { | 0 604: SEQUENCE { | |||
4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) | 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) | |||
15 589: [0] { | 15 589: [0] { | |||
19 585: SEQUENCE { | 19 585: SEQUENCE { | |||
23 1: INTEGER 3 | 23 1: INTEGER 3 | |||
26 516: SET { | 26 516: SET { | |||
30 512: [4] { | 30 512: [4] { | |||
34 11: OBJECT IDENTIFIER | 34 11: OBJECT IDENTIFIER | |||
: KEMRecipientInfo (1 2 840 113549 1 9 16 13 3) | : KEMRecipientInfo (1 2 840 113549 1 9 16 13 3) | |||
skipping to change at line 1610 ¶ | skipping to change at line 1337 ¶ | |||
559 29: SEQUENCE { | 559 29: SEQUENCE { | |||
561 9: OBJECT IDENTIFIER | 561 9: OBJECT IDENTIFIER | |||
: aes128-CBC (2 16 840 1 101 3 4 1 2) | : aes128-CBC (2 16 840 1 101 3 4 1 2) | |||
572 16: OCTET STRING | 572 16: OCTET STRING | |||
: 48 0C CA FE BA BE FA CE DB AD DE CA F8 88 77 81 | : 48 0C CA FE BA BE FA CE DB AD DE CA F8 88 77 81 | |||
: } | : } | |||
590 16: [0] C6 CA 65 DB 7B DD 76 B0 F3 7E 2F AB 62 64 B6 6D | 590 16: [0] C6 CA 65 DB 7B DD 76 B0 F3 7E 2F AB 62 64 B6 6D | |||
: } | : } | |||
: } | : } | |||
: } | : } | |||
: } | : }]]></artwork> | |||
]]></artwork> | ||||
</li> | ||||
</ul> | ||||
</section> | </section> | |||
<section anchor="recipient-rsa-kem-decapsulate-processing"> | <section anchor="recipient-rsa-kem-decapsulate-processing"> | |||
<name>Recipient RSA-KEM Decapsulate() Processing</name> | <name>Recipient RSA-KEM Decapsulate() Processing</name> | |||
<t>Bob's private key:</t> | <t>Bob's private key:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
-----BEGIN PRIVATE KEY----- | -----BEGIN PRIVATE KEY----- | |||
MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx | MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx | |||
WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su | WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su | |||
sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro | sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro | |||
ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q | ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q | |||
khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b | khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b | |||
JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW | JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW | |||
MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn | MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn | |||
XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd | XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd | |||
skipping to change at line 1657 ¶ | skipping to change at line 1383 ¶ | |||
B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 | B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 | |||
gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr | gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr | |||
ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI | ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI | |||
x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T | x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T | |||
UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ | UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ | |||
SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz | SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz | |||
AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x | AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x | |||
2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 | 2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 | |||
sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f | sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f | |||
hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== | hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== | |||
-----END PRIVATE KEY----- | -----END PRIVATE KEY-----]]></artwork> | |||
]]></artwork> | ||||
<t>Bob checks that the length of the ciphertext is less than nLen bytes. </t> | <t>Bob checks that the length of the ciphertext is less than nLen bytes. </t> | |||
<t>Bob checks that the ciphertext is greater than zero and is less | <t>Bob checks that the ciphertext is greater than zero and is less | |||
than his RSA modulus.</t> | than his RSA modulus.</t> | |||
<t>Bob decrypts the ciphertext with his RSA private key to obtain | <t>Bob decrypts the ciphertext with his RSA private key to obtain | |||
the integer z:</t> | the integer z:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
9c126102a5c1c0354672a3c2f19fc9ddea988f815e1da812c7bd4f8eb082bdd1 | 9c126102a5c1c0354672a3c2f19fc9ddea988f815e1da812c7bd4f8eb082bdd1 | |||
4f85a7f7c2f1af11d5333e0d6bcb375bf855f208da72ba27e6fb0655f2825aa6 | 4f85a7f7c2f1af11d5333e0d6bcb375bf855f208da72ba27e6fb0655f2825aa6 | |||
2b93b1f9bbd3491fed58f0380fa0de36430e3a144d569600bd362609be5b9481 | 2b93b1f9bbd3491fed58f0380fa0de36430e3a144d569600bd362609be5b9481 | |||
0875990b614e406fa6dff500043cbca95968faba61f795096a7fb3687a51078c | 0875990b614e406fa6dff500043cbca95968faba61f795096a7fb3687a51078c | |||
4ca2cb663366b0bea0cd9cccac72a25f3f4ed03deb68b4453bba44b943f4367b | 4ca2cb663366b0bea0cd9cccac72a25f3f4ed03deb68b4453bba44b943f4367b | |||
67d6cd10c8ace53f545aac50968fc3c6ecc80f3224b64e37038504e2d2c0e2b2 | 67d6cd10c8ace53f545aac50968fc3c6ecc80f3224b64e37038504e2d2c0e2b2 | |||
9d45e46c62826d96331360e4c17ea3ef89a9efc5fac99eda830e81450b6534dc | 9d45e46c62826d96331360e4c17ea3ef89a9efc5fac99eda830e81450b6534dc | |||
0bdf042b8f3b706649c631fe51fc2445cc8d447203ec2f41f79cdfea16de1ce6 | 0bdf042b8f3b706649c631fe51fc2445cc8d447203ec2f41f79cdfea16de1ce6 | |||
abdfdc1e2ef2e5d5d8a65e645f397240ef5a26f5e4ff715de782e30ecf477293 | abdfdc1e2ef2e5d5d8a65e645f397240ef5a26f5e4ff715de782e30ecf477293 | |||
e89e13171405909a8e04dd31d21d0c57935fc1ceea8e1033e31e1bc8c56da0f3 | e89e13171405909a8e04dd31d21d0c57935fc1ceea8e1033e31e1bc8c56da0f3 | |||
d79510f3f380ff58e5a61d361f2f18e99fbae5663172e8cd1f21deaddc5bbbea | d79510f3f380ff58e5a61d361f2f18e99fbae5663172e8cd1f21deaddc5bbbea | |||
060d55f1842b93d1a9c888d0bf85d0af9947fe51acf940c7e7577eb79cabecb3 | 060d55f1842b93d1a9c888d0bf85d0af9947fe51acf940c7e7577eb79cabecb3]]></artwork> | |||
]]></artwork> | ||||
<t>Bob checks that the integer z is greater than zero and is less | <t>Bob checks that the integer z is greater than zero and is less | |||
than his RSA modulus.</t> | than his RSA modulus.</t> | |||
<t>Bob derives the shared secret (SS) using KDF3 with SHA-256:</t> | <t>Bob derives the shared secret (SS) using KDF3 with SHA-256:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
3cf82ec41b54ed4d37402bbd8f805a52 | 3cf82ec41b54ed4d37402bbd8f805a52]]></artwork> | |||
]]></artwork> | ||||
</section> | </section> | |||
<section anchor="recipient-cms-processing"> | <section anchor="recipient-cms-processing"> | |||
<name>Recipient CMS Processing</name> | <name>Recipient CMS Processing</name> | |||
<t>Bob encodes the CMSORIforKEMOtherInfo structure with the algorithm | <t>Bob encodes the CMSORIforKEMOtherInfo structure with the algorithm | |||
identifier for AES-128-KEYWRAP and a key length of 16 octets. | identifier for AES-128-KEYWRAP and a key length of 16 octets. | |||
The DER encoding of CMSORIforKEMOtherInfo is not repeated here.</t> | The DER encoding of CMSORIforKEMOtherInfo is not repeated here.</t> | |||
<t>Bob derives the key-encryption key from shared secret and the | <t>Bob derives the key-encryption key from shared secret and the | |||
CMSORIforKEMOtherInfo structure with KDF3 and SHA-256, the KEK is:</t> | CMSORIforKEMOtherInfo structure with KDF3 and SHA-256, the KEK is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
e6dc9d62ff2b469bef604c617b018718 | e6dc9d62ff2b469bef604c617b018718]]></artwork> | |||
]]></artwork> | ||||
<t>Bob uses AES-KEY-WRAP to decrypt the content-encryption key | <t>Bob uses AES-KEY-WRAP to decrypt the content-encryption key | |||
with the key-encryption key; the content-encryption key is:</t> | with the key-encryption key. The content-encryption key is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
77f2a84640304be7bd42670a84a1258b | 77f2a84640304be7bd42670a84a1258b]]></artwork> | |||
]]></artwork> | ||||
<t>Bob decrypts the content using AES-128-CBC with the content- | <t>Bob decrypts the content using AES-128-CBC with the content- | |||
encryption key. The 16-octet IV used is:</t> | encryption key. The 16-octet IV used is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
480ccafebabefacedbaddecaf8887781 | 480ccafebabefacedbaddecaf8887781]]></artwork> | |||
]]></artwork> | ||||
<t>The received ciphertext content is:</t> | <t>The received ciphertext content is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
c6ca65db7bdd76b0f37e2fab6264b66d | c6ca65db7bdd76b0f37e2fab6264b66d]]></artwork> | |||
]]></artwork> | ||||
<t>The resulting padded plaintext content is:</t> | <t>The resulting padded plaintext content is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
48656c6c6f2c20776f726c6421030303 | 48656c6c6f2c20776f726c6421030303]]></artwork> | |||
]]></artwork> | ||||
<t>After stripping the AES-CBC padding, the plaintext content is:</t> | <t>After stripping the AES-CBC padding, the plaintext content is:</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Hello, world! | Hello, world!]]></artwork> | |||
]]></artwork> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section numbered="false" anchor="acknowledgements"> | <section numbered="false" anchor="acknowledgements"> | |||
<name>Acknowledgements</name> | <name>Acknowledgements</name> | |||
<t>We thank James Randall, Burt Kaliski, and John Brainard as the | <t>We thank <contact fullname="James Randall"/>, <contact fullname="Burt | |||
original authors of <xref target="RFC5990"/>; this document is based on their wo | Kaliski"/>, and <contact fullname="John Brainard"/> as the original | |||
rk.</t> | authors of <xref target="RFC5990"/>; this document is based on their | |||
work.</t> | ||||
<t>We thank the members of the ASC X9F1 working group for their | <t>We thank the members of the ASC X9F1 working group for their | |||
contributions to drafts of ANS X9.44, which led to <xref target="RFC5990"/>.</t> | contributions to drafts of ANS X9.44, which led to <xref | |||
<t>We thank Blake Ramsdell, Jim Schaad, Magnus Nystrom, Bob Griffin, | target="RFC5990"/>.</t> | |||
and John Linn for helping bring <xref target="RFC5990"/> to fruition.</t> | <t>We thank <contact fullname="Blake Ramsdell"/>, <contact fullname="Jim | |||
<t>We thank | Schaad"/>, <contact fullname="Magnus Nystrom"/>, <contact fullname="Bob | |||
Burt Kaliski, | Griffin"/>, and <contact fullname="John Linn"/> for helping bring <xref | |||
Alex Railean, | target="RFC5990"/> to fruition.</t> | |||
Joe Mandel, | <t>We thank <contact fullname="Burt Kaliski"/>, <contact fullname="Alex | |||
Mike Ounsworth, | Railean"/>, <contact fullname="Joe Mandel"/>, <contact fullname="Mike | |||
Peter Campbell, | Ounsworth"/>, <contact fullname="Peter Campbell"/>, <contact | |||
Daniel Van Geest, and David Ireland | fullname="Daniel Van Geest"/>, and <contact fullname="David Ireland"/> | |||
for careful review and thoughtful comments that greatly improved this document.< | for careful review and thoughtful comments that greatly improved this | |||
/t> | document.</t> | |||
</section> | </section> | |||
</back> | </back> | |||
<!-- ##markdown-source: | ||||
H4sIAAAAAAAAA+29aXPrypEg+h2/AnMc8SzNESXsBM8de5qrRG2USGrt6Y7A | ||||
UiAhkQAFkJSo49O/ZX7L+2Uvs6qwk5Ku7Xb4Rfh6uSKWqsysrNwrUavVhKW/ | ||||
nJEf4k1MxNATl1MiDkfN2ln3QmzOJmHkL6dz0Q/ojXa0WSzDSWQtpr4jXpA4 | ||||
tiZEHG2CpfUm7rUvRvuCZdsRWf9Ix3iF90W4I8KPIXH8hU+CZT/wQsGxlgTG | ||||
3/wQ46UruKETWHOAw40sb1nzydKrzaz5Iq5FnqM3GpLtxzXJFOKVPffj2A+D | ||||
5WYBj/e7454Q2nE4I0sS/xDxUcFfRD/EZbSKl4okNSRFcGGuH4ITBjEJ4lVM | ||||
bxJh4f8QRHEZOj/EP25I/Ef4EYfRMiJenLuymecvWBGxfojfRsRZAWk234TX | ||||
MHqeROFqAVfP/bm/JK7YdF1/CSBaMyCSM7UCP57HohdG4tVZ/160AlccXfQv | ||||
ut+EZ7KBAVyAoyaekY3YDRxrEa9mFr6evSzuAfn26UNlMq5JsCKIx18PBNCA | ||||
0vLbHeDiBxPxGIfC63PLn8H1eGHF83/DNTkMownesCJnCjemy+Ui/nF0hM/h | ||||
JX9NDpPHjvDCkR2FrzE5oiMcfRMEa7WchhHiC6OIIlvz4SqOxZNwFc/Ihl6G | ||||
13+It/7En4kJpQ/E8/M2vZmwWPE+vRXD4pElcIFsiJ3ICki89mcz4OjQcukD | ||||
Djz5QzwhUeCGwYF422RXQxegUCS5LvHfq2CJnHkzor8Jo8OUQfhva5w4Js6h | ||||
E86LiIyIFYjjVRSQiF71A2Cc0WH+EqAGS/FOFxhYP1AjNz9HDCP8G71KRxeC | ||||
MJrDs2u6xP1a5zC3M5x5XHsm84iy8bDXVtWGxv/UJVNN/lRMKfnT0JXkz4Ys | ||||
Z38mVw3FMPmfJlAj+VPX6bOjk9EPtgLJIorpYl1anNf6QQwSZbWk0mS0BDaz | ||||
Ijem7DYGNgzCWThhi8UFD9tLRDyx4mn6wjf6BN22uC56TaqzBSaRT2IfGD+Z | ||||
/dtlfzT+BsP0+lcjUTalmvZtx6OdQf+HKEuHhqSYR7Adloeev4gP6TvwyP2h | ||||
wSgFoFnRBPko4e/X19dDQOrQD5ZHEXGOxrVht12jL+RR+TOfCDcmXTbYw8sU | ||||
abFW4/ebNjCq5SwT0XkZLtnDg4CIe83R5aG8nwA9WsB293yHPQA0ta0YhG/A | ||||
X6msR42tR398UxsXiKjINZCE2ylDnxZBsITzOYEFYMyZ4QdPjAZH/W77h2ia | ||||
ilaTf+B4jGaNfxDNkCoiCWCvooiKVjMU9xXqtCh1usljQ3xM3Gt1h/sHfKC2 | ||||
FYQBvDGrPNWGpyijdoA34PrKj6cgSMuPdeCx/2ayN7aRXc/I3rwc1e4bh5q2 | ||||
cz825zCbA9Io3ZjZXky36LZ1uFrZM6AgKqOcut9QxYE2QM8PrMDxcUASrX2H | ||||
4HguqNoot1hUlcVLC4aKp4DaEswLpGA/AJ1PIrEHzA+mBZOChXkKtNu56Xdj | ||||
B+RDugiUdLCzVbWmfMCfcUhVVczfPlLrjbp8OF3OZ38Njya6iN30X1ZAnPQm | ||||
sBHiie9aiWGVu31lRUtRgYUDg2NOloAeKKvFlETxLl5LmEM8HbdF+WjUFpV6 | ||||
kXzGLr5LuCohEH1W8BP0mLYBya9JppH8qRiZ7mgkGsWQmcpBITy6MiWpptcX | ||||
SznS/zsURXGjUI5ERruwAjBDkct+UCLKQKBjAvrWmhXViCLVJP0zNUIlCoDH | ||||
9gGbieEl8tGHZO2jASrqX1c08eIwRxx4rH1xe7WdL504cg7pS5NwfbSIwifi | ||||
LOMjJ2971+ahC8KotrZmPqNGDR6Em/P/BrKXrH46s3ibzixesZlLKtugBsPg | ||||
ZgeWZBGBYjj0LSeiOxA4UD6SZWUL/My0uvVRZIgjMMIW/Aa1rm4Pc9c4yE2E | ||||
aRHGgC4yCcgJ4PgUWWYDZ2Iu25jF3SPvWF1GD7rzyRViITaZ6fsDOGQB0i3F | ||||
RajVamCuMmUvCGPmW31s6HPHaT/vfcHyiGFAamBEx8JeDHQgNcClBoi8AkL7 | ||||
YoE5xHk6GscexpmA2Eb6LUPACO2t2UYAZ8gVwQNByQzbHhAFgsEDlhglLoa4 | ||||
onIbBX967Y8xxWLBKAjvHyaYlb3GWIyZfgYtCi5ke2atwMuU5UMdmW+rFMKx | ||||
4D1wB1dUbyQDxBQG8ODA30GSMU8mg646uwVUE5hgnwHx0HPKBC/l9985okB9 | ||||
2a/5wXycsrcGQAkFkoAIFe/hn0NRLOKdurT0EZS4h4KAf3Y7/fFgCKw2I1aM | ||||
q7KYWQ6hg4gpgPhgsJrbwIzAMv4kgNlgYSu+depBHDJenfuuOyOC8AfU1BHs | ||||
dIdui39xbpFzf/7MjItfvw6FHaMsrWeCBHB9zyMRwmQtQExbDi4SIgfARRQi | ||||
AEUAIRHEixBUzDxz13/+5K7Yr18H2fJOQkAX4IDB1j41Taf+BMYS4sQAAXKv | ||||
YDxgjNepD+LamsVAPliy2NskZEFgQXqRyAMGogxIhCoShElHxAMGdMM5fQeN | ||||
uBScHH2FIn0P6D5zYX3WlBLx1IqAogBmRJaiF8FodIDCwIcUktzK4xjZuqLZ | ||||
x0bEAVNjCWbLBmTzCGweQK0Ho5A3YPkZAZDw2RrJzDF8FUe1CR/Y3TESstgr | ||||
sCoMAXJjCdCUhgFW6H81VMbWFl3yX78YswoVcQGMtsPlR37I4EsoCvbAigjA | ||||
vX6wWC3ZjkBkKVrcaloFDjNgQ0BivkBLYBtF6NIJHNucTboV74wXqgMdot0s | ||||
LFG6vVobBnVpcQtMJOLeXi2yIWPQ/8JOeuPSIh4oLAMgM65vXPYKd0Q1Y3EC | ||||
qx0AtYTmYgHz+m9gO9Dnc7L4N+57xmzxcm+J6VstgOQPf9gyx5DbXWSXkGB7 | ||||
GHYH28Lili2cCQthbYGoC2A3ZkhxERpv4iVhcnP5GgI5rRh0GvK+H8VLRvaU | ||||
K+CHsAqAK2ZUGuAoIVgujF5UaIPNAndq1N8G/iptfZssXwmQQKLLF9TkA+EV | ||||
wCMifTsBjBqpK1gRkD3+EugJWAbhUpxauHeDDU4CGgaDP4DiEsNuMxfGFsjb | ||||
YhbSIKa9QS1guWvwg6wIeQl8rDBw8/hQdncJrgTVnF7CiLilUu0Qh5zNQHUt | ||||
8+RzScpRBRogpK4PbLkEhWOtMcJpgyTFPVWEqEllIx33YAenkeAp3KA98m0J | ||||
q7z8lq0yLD/AwuPrnMohmIswE5CPzGD8vX6iKhaWi9JeiJ0p+DtI2BXoEjB0 | ||||
rs7aI/EPsrhGBVXQGRmZpvBcRnCY6SiMBEY2YKcgR7RUpR6kuxO5lKJfZU9A | ||||
Cxc+XApsgjCYHO4zbk/VHbIUaiAaIwbnGECwZrMNt77orreJQ3UssiZTIDUU | ||||
LOmSsGlisrDgN8kJ6FQ05R5l6AgldHCtAkZJG2SF5y8ZtwLr4UgzEkxA5BT4 | ||||
J30XhaoLIiaa+wHjy+LkmUt/QDmH3vXf8zmVZD/sEhWj1XwOHCUIzdmsaK3G | ||||
iZSAoSJCUhkO7g9YZODr7u0f5OwyAj8FGsciuUvcTPHC2Sx8RdRiOh/ASHds | ||||
XBmcyhIO5g9BSGYSa38W9xbPwHzP+3D5z9zXXhLGKKnux4dYOM0C8FH9EHY5 | ||||
xstIzdiJfBuUK3D/z5+wr+nOU5FiKQMD0Hm8cESc3oGdNhrx6akwLtt5JTgO | ||||
kIJgzqKuY2GVJXlb4kD7uKNB5qCFyqzkojZiCBTV7B7Mzb0FkrBCptIOcCMw | ||||
MscIoSD/n8OMSBUz6r0qTQ/xLQXe4q4p38XJ89sMr5Jhi3iE9tLigiVDGQD6 | ||||
r//6L+7Jis5S/JP4/p9U1ogBvQMzqzBzJ7WwtptsGTTMzraob9DJ7IxeYmfs | ||||
nXV6+8VpRyOYFi7vve8nc2r/h5p9+cVJZE8RApQC8G9MqKTbMGFZbsTmrIuY | ||||
SrciCSprDOTO75QYeBv5AhhtNCqxWJWREz+yyFQZv6Ec2sE9JUarMk2HZMuf | ||||
m2D3+mfQCUUGKPNccT3eYTmc5X+6RTZQfg8bfLLAKl/e4jAgU3cuJRWS2xLH | ||||
GNsBrUO5LhWZY/BuVgvqPeU1cCpBmSLE4XLMcXEzGos+mo5o5hUEDUpLtuq7 | ||||
TH2x3T3bpe4XGYQMLaHox+Z4g5nsXAshbztWFHGvMwF5S+qcOiupAAcJlTGN | ||||
OMiWvUjuzCMuoJq5BExXCRXqVY30isAprn8ioIELSuJ7K3Nt8cfOumdlJ4yj | ||||
UZwJn2OsBtPlBZh4h64LJSE8km4ZfD7bGujeLEg1lHB3VpzlDie5Gzav9s5w | ||||
1WHEiuD6TOggCe/OqvolW+eq+5eaa4e/h8OzsUsMvs0cqK519nqOjbkVw5mV | ||||
US/nJn8Auvg3M2sB7L+FWTPpuEVabdEA/zhevQleE26928msu+VQcZo2nebm | ||||
MuPXu4RdL8MlyQxegAQtGJeLJFzrJDC0azEvmg9oLGURrRTv/GA8PFNdVL7S | ||||
fM2EdM24tM/FYpn56vkBrWGJGbPSSEOI6YpvyNrfDti/xcsB/XvYvb7pD7sd | ||||
/Ht00jw/T/8Q+BOYkDjvZH9lb7YHFxfdyw57Ga6KhUvCN0D8G3OHvg2uxv3B | ||||
ZfP8G0MnH7VFAU7NSRZYWwDOlN+F1NjFd1rtq//3/8oaGL3/AwxdRZYbv37x | ||||
H6Zc1+AHONMBmy0MwE1iP4Fy4IiCvLIiHAUcKNhbC38JntUBWg/xNHwNRHTD | ||||
gZz/89+RMv/xQ/xftrOQtT/zC4hw4WJCs8JFSrPqlcrLjIhbLm2ZJqVm4XqJ | ||||
0kV4mw+F3wndcxf/1/+egRwSa7L5v/8sUB6ioRpBQDnIhRWuyYRb3y4XKyyg | ||||
8/MnrUagodWpD24q8C/bAbSKQNhWRZBKl89rBNj4DYl6McjeUyuYwM2Rj0Gd | ||||
JKzPovr4Fw8INvCNXPj592YpMFwN2GP6g3kCaVw5225oJ1tofx1gYIZuWzDf | ||||
x/hkOQCZxigFnJigN58ZziJHJvP80pBbghXG4wLyWjViMqHyUZSThi1s9I5c | ||||
lAZMviSKsCBDMNZ1N+V2uu/WotjCQXKKwcf4EBI1Etk2irlAEkYrG7OsLCkI | ||||
lKC4w4MzF1EBExCUOAsokgO+IKhV30SMRswxLJDJSCEBlKd36NJyJRjO/SVw | ||||
4W8ibFWyJhEbLB2EMauFTgChaUrBtpxnTJTQCYG2tj/zlzToNIvDAxqMWoe+ | ||||
K679eAV2C/CJt6K5aapDgApAAaTEgZBRpBYvnn0WNWM5HiqiaFRr5luMwbKn | ||||
D3MMShkFtIsVJ1YkKiLinmG4mG0hP03UIbGChB2EkjXUTvdRzgQDPXUgUuW1 | ||||
1xb/8hdUW8yjo342LAQaciBMA4KqCux+iv/MnwQ5lbmVjTNDCoPRVGgLidA+ | ||||
2GaplSFjsSdmrmUxKGSQOMHuA+uNTgovLX0HDIyoMiMQLTP7BRZ9moNvTidg | ||||
eiAPTOFxOhbJrYRA36KRUtxa8FoNtgDsJFxXl4ApMYPFtsPVMuXk1bIQKc8g | ||||
yy8+bPTZCmPBye7D8drAuDPgGlY/EPmwKWqd7ki0Z6HznBSw/Ab2QuysaNUu | ||||
nwPjJvlHmCs4D3O5l5xePRDt1ZLSZdtmpm+igcSJwYQ7r1PgBIgDmddMUGn8 | ||||
MVKg7GoyCp5pam3+JpZRAA4qPPEFDMRdGAgMgbiIwfxLGETkZeVHJQy4Qabu | ||||
TP78/JmWkP369ZtQtGLQ0PQD6pWGyfi/a/gDAbEFzcJfjivkVXQDY34nI+BL | ||||
Lk0K1CxiyMt+SkhaMxCZAS1XopBSiJAPm91RDb2/mqyYZdxidIcw82AtE6+b | ||||
RYR3oMIsUZZ8KZn+ufAsM4sT6IibBz+9yOMbVOW5qWlLFUxWql2K+yKAAko/ | ||||
0PO/lYxNPnDMbMQwIExSsKh2ylxJZEXIlAE4FKjtcgy4dUuAQsgzYnn6NHFF | ||||
FUe6FEKBeSmBeVirYsmQpEKQCTJu/sgyGGRC8kNB6wzRohewPhnYnykFtCo+ | ||||
2ykCD7XEaSZRtP1lXAuDGlyovSJnc/7DGpGcykab7dNDEei178jrcZYgwG7h | ||||
hmlzOgX8ax5GOe80NULQaiNAnVkIgr7mWss09ETr8/O2WObsY6kU0hO1LXtJ | ||||
2P0S37rV94rTbhtBMlVKeFBk1AZ0rJibQhXD7kNzDjiIWhFZqUrFgM0VejDj | ||||
FVzNhHe2OcCpC1oIsgnlEC9Y4BdYDAS3N+I4FPtpXERoUpKkgRJe4Imsm+6x | ||||
7SxAXapEJsFOxZocJuazNEsuz4q6FngA1hw89hqtSuCppq1SFHdWCaj8hODv | ||||
U5FXkOWMsCURe5jMhjNRSwKg+Wx4ypNiQZgyXsBjBjDRLmkIkzWrA8NuYDUo | ||||
fPDPha6QPbJd6MK+fQXjg6fTCqZXLpIgCKlTsLUCoLBBc/VDByy6VKzeysQc | ||||
14PWshxus4kwQMCLb2YO224z8cONw2VeanJuj7pRCGh6vciDzBWmuQzMW3Nz | ||||
hYpEVtSQXGVFY7+hEuHYiCgJ/yxG4GSk+iKuxNdyDhJKmXyFFbyMbljp5YKe | ||||
y+bDLU5NuVRZJQM4y9S3yAznReK/sNWgJhgHio7Jh4uFNpMS8ZIsYlGmCkVB | ||||
Kg5SkQFIDLIEMlVHqenMYHC9MhK7rCua8oIVK4TbhDRCRg1nEDjFtUsicFxx | ||||
ZCE2Wv7BTS4hFZ7+Dp7m9Ho+Z9nsZJlzqegtEUwYLHSWZBnTt1fPrHIPCyK4 | ||||
WZLmj7ICkl3Y0yFoODNHrUrcNDODk6AhyXKdlcQ9Dpn3cRK0smqOZGi+y8oB | ||||
/UTdlG04Vp9EJURRLe1WxsJ2ZVyekVbR7KhaYjMK1Rmr2vxjE6BMKDbrnFWb | ||||
1XKjfYSr8Jk9sA0Gag98AEOCeXncUvXW5WDc/UFV0/ZIx0FJkcQVTZImAJAt | ||||
xmmsq5nlRYqmcCkOkg/9CduDB1apGDQXpuOBvZzwK2ieccngLQxDxVXMqx6s | ||||
1YQa1dT6VMwkFqiYbJJmTsu8TkOutHZaJUAijvQmF5qjaWE/KIaz0koWNI3T | ||||
Ifq5SFmcuHxCocqokHjiscRcyW1s5c67MH9DyMXfcjVKiWbD83BpaiKHrj+b | ||||
iZbjEBANSd6Ac65fKPPgJVt+4DJmSzBbJTa8H1cB4ZPjJAB6QDMgYTLdbuqC | ||||
kseqamu2ZRrCjtW2rYVFeRjFX3O5jHyblloWuUDICl+UQ/1QOUyqX3Qd3KDE | ||||
YK8OmFtBARQhCaj23sqpeHCHMlHfq5AWXC/uPi4TptqBNSW5xSofhXyBb3FI | ||||
lnHczntJdCMPe8Yx5fhkxUf9DTZL3sdLOQcoL3DKfzoIC64W6MejAK+gbAU/ | ||||
jldMG9kkFUQzwrDfLmhoCDKmL6RSlcUcClWo24PTO6Fk4WmBU2xreDrToGmg | ||||
ukRdJp5z0WX2ILWEtm11nrsBTCw7ZuH9NE2AI33yjjjqXt90L9tdBAVd3dTd | ||||
OUgCEB+jjTSibEZnz4XFD9KIk/ClgNZWJ4jGcLmxIezKUB7m3IVt6JZC9Qsw | ||||
QFL8aImX75xsbDCWr7IHE0Ma5+Yo+km55VwkTLsdFIODeVmZvB+zAvRcUJ/a | ||||
scPYOiPzLfMlgZxDoZmrtmNyIZ77c0x4J9bLLtixZQL44Bxe5kYIrFiXZTQq | ||||
znx+wyexQjCdDzKbNAtoCwV35qMIugCe2ASsgxlKaP74tvVBcA62gZL4ZqXA | ||||
eVzaWWKrPxZH42H/8jhvZW/bgMKubVfMzmVDU+splxzK60BmK2DSmIY5Yf+n | ||||
ubSEiHlkmIuQqbqUnzYwOZh+Qh6cj/RDonw0UD3yYVJ7ye0OUWQqAzfdDT2/ | ||||
kA2Fupcxv1gxKXgxN9g9G+pFFJciO0b1BTkYJ3F3JIodrplMS7EVViWwCk4k | ||||
U2xVR/gHc5E2YKFQV5IFgQZJuKGMKs8jJ+lzWizKUM8LSKuo6fhCMk2SxhhY | ||||
Nj+xu3fEk3CORKUUohPUFs+Z0GFEc7IuuLBLrHBHiwR3C2ZCj8PQLR2uWuAp | ||||
RN8hqfXI1TmuDy4xCDefVhYk8WSR1ZknZ9PS92nKkTtgfvzM1nu9mmGOnZnt | ||||
Ah0lGQBcgw1VBqB4/JhL3aSOnO8fGuxhkgGfRtRjJDGWXgMRMT1C17RSiM5M | ||||
8I9MrnxZyc8/pJJPKNteRdOLbdR4h/1lpaODMrGCIFwFtLaYJvlgLWZ+TN3S | ||||
Uigfd8PoCEcrB8hAnArco0lMBSZ78Qgera9FL40d5fvEMRQslp7GgyLb4nBc | ||||
L3yGmcABZrjFlQTQtsjDuDLkJrMKIsK3ze4zm8j/Qh6+z0VEYlSmE/Y7zM75 | ||||
TSjbiyno1VHoHmfsl73FT4wlpQ/s144yg08suSTGXwUzO2Kx27QISg9w1UOl | ||||
BT8zsVODI3scJvVhux768eNP2Tr9pIVkaJugqVs47pme9mTNNFx8pgPMuP0h | ||||
8RerOqsELj8Edlv8ck5gwGAS/0ijiVSxlC2A1J8r28a7TShhC/mL75Ttq1yl | ||||
Q9HkhR28zSRh3nExcJjlBHfYswI/NxHGPo029y/H3ePucOtglXMruTCLUI3u | ||||
uTvJ539Kv5QpWaJR2BIP3ZoSYKOWODwJLmZ2xi622LEfWALSpRjRDZxaedQq | ||||
5ZKBhiJTW61sY2Z+8V85+XNhciExia2PI8SJweZ6u0HL8WY22SZZ7rxXkdl/ | ||||
Sdh3O6Z/yDqUgFKMYUge796VxIyn/EgeVUb4PK8VSs6d06CVl+WxctVm+H+5 | ||||
Ot1XeBvMilQfwUC7Tq3RATG7mzODudeB0g4VYVr4tAiXzEooGCA+qwhwpiEs | ||||
Wy1LGAig3SznmSX1Jxa1XOmJvPzBS3okr1SiVc1STvkKg31quWtQtWg0Aq7x | ||||
DMcDTGdhgCcj0rB1OULMXcFCVK1yOjY9fb0jcJ8cUEzCDh8edufudQ6fgx3j | ||||
4mm3DPCk4Gm24Sq+bLxVGScp+qYlqcwIXnK6RARrrF2BZxEwz4FlUWw04lMr | ||||
PA5n65yVgEsCNt+cZrDtiFjP/Gb+EGvhKPhWMXQg+gze7K2d8QQgAD1/mfJ7 | ||||
/mgmk394AnLOALFYddLnIPAz+InABLwW6DgRqhktIbHwcw0WspYIGMcY3FxR | ||||
x+yOnuqn9nBilHMQawxEgadG0kO3yQlCrNYAnxr9heIZVNZxYZOrU9tFnCTo | ||||
l02QDp4/s8wCqKz0diZk1mxSK4UHlNGU/+2DQ+qvVP4EJHGlhAw6ZHrgBLw+ | ||||
I5abHMylGzwJSTPMwzimUTxugxXoxE/ZZi0ucFfRbFkifLfm73MgAR1nsAeB | ||||
o6mMjJcstMo3mktin4eXGLFnIFRmtDpvjXQp3cCiMlD3tOA1l7fg8h17FImj | ||||
q1I/op8/K92XkEcKPQ/QGXu16Kkwy5n6MJUoK2bN9pcpAFnYJCXBayL9gZis | ||||
tEGV6gqtoDkQPlJv6Ys8BpcdJE63yM5qquzlZndEg630JA8PQCdQ82YL5eQQ | ||||
KkVgRjxinBMe6bmPXfKOYbM9W3fwQT4txUv4Ur5LxKpxZxbGWAKWOxicP7fH | ||||
DsHzzZU4N5nvTH3KWQJSnCCbBeEsTpvqTNt6PHyENs/6fAUzsQx1EWIcBkRD | ||||
6Pg0WpVpFj72VsLsAFf4aDXCYqHQRyBzQtN8AAqBSr+IHMCFcVKgBSHXYtUp | ||||
2FOJkkMJgeSZpy3KkuiGB141TwBt271f1bO58/uW+AJSHZ/muorVcgj87EMY | ||||
8T4o3iqiOjZf0BoU30nOS9BSTuYP82ZwH3S7STUN2mggibGJg+/4y6RrAQ8G | ||||
/YZtu5YgsNG8FUv9JZghvfe+n56JfidRmAqP3CF6ETTvKqZybS+oyfv0fH5i | ||||
DGUM9oWj0vzQMG9NOA5HtPPF3vuBGIAxvZ+1nExLCZPuGKmWoc7qCrZl6ooJ | ||||
JXBZ5VxS58kVaB5njK/xE+jTKFxNphWlKBTLS1htLj1Gmiq4qRXNWXoHXccw | ||||
KtnbRb6Iw1Xk0GodC5gSlwrb22640VxZEcRgm7S9HIxpgep7Rv7UklhFABpG | ||||
H5oxNYeZKeWBmJhWT8FjVTub2oqpEULtQdo9IliHbG8meb7t51cPUq5MedEl | ||||
k8hy0xpPzt6wPplPgLEZB60RGtrhh3Ng5XLiIit1Bd2HER50yefWgoXaZjPW | ||||
DtBPq3QSnmDhXmvDGCUBDm3j5AQwLQXFAh+BJsxyZ9TxjcwSzBewlhNW27dj | ||||
DmbPfwPxx3kzV9zPvPJi8laATZrYT3zfENoRyd6AguJ8z9GDHc5UDx862abs | ||||
JwjYCFYaDCY35sZZstjJqYXk/QgPRqEWZMejwYYjc1bLkzVnSdMGflTWmYVu | ||||
Ejj4qFzmldZywX6iWa8ttkN2cg2QXhMsZMm1+2QHJuipvjlxUS0IyWHYCFZ0 | ||||
5nB7nYaHCBWwWBjgUwcBS3/ppW+oI0Q06AOw9b4dsBrHV59JzHDBrMtERyT9 | ||||
ZtK+I1WIEiuM0gqdB9bXpSLyctSih4eWUypjcIuABhTyeBUm4ZDABgf5xlcx | ||||
AfOAlZpjMsRDx5sBiyd/kHiwJvMV3bw5kGMxyyNge5lVgAk9UATWbBPnU+bY | ||||
HCZJb+VatOQH465BuOQBnyqAeIafeR8zsA0mvy8jIiYZEeGfJSMipBkR8eOM | ||||
iFjScDELqYYemC0CdS0KaaU52Gx4cCeR13HaVqh0fBBbubFck5DmmqiGxa2B | ||||
Av85QHfftly2USxWzJsLpdCBAW+b5kB54YZVpDeySOlYaCIw+OGJPcY2afiA | ||||
lkkmTZHYUa08H6ELlnRAtNMSgAndpHgMvumApEINP6P2fBGYtGBzu/2VCQ2h | ||||
UAWyMy/XB28ySVHDxCDIaZ+rtBGr0A7n9JAgEe8b2Au8Df/ezx+kwaVJQjK4 | ||||
DxJLKQGZFdjTlAVeIoU2zBbrm5h7cDuoQqGeAuBuszNBzOqhrO9j9nRGzXXq | ||||
MKYQ8Q57bPN8mX7FYoK09lsowp92vkJDtpoSpdfpAKhYBdY4LWBxf4Az58pn | ||||
7mbm1KNSoPYcq/9KJFqSYaHKt8AcuQZJxaog4YOaQa4mtxQIUZlSmF7IdcXK | ||||
97dCi6gUIcuSz3lrmct9ITnDyGIKDlVu9CHsFVeAA6mAgQVaZQbkY1HSYlyn | ||||
XJNJ+5agtqdeNzVfBSqoZ+X8Y9awOGtelkY2Cj0ThZ2NhrF94u0VHq/Gf7Mi | ||||
TLHfvGxWgtrJAYvCicCstDt/UOiAjUADU9i3mztvrHsqpnaqqb29Qb+TNfLh | ||||
Z5Dy1UxoXQ0wz1d4RMiC6uh8Fgo4vo0u+lmMnh6WY9liDnuWqPkmRGTi067r | ||||
e/Khcmhq0qEsq7rWOJQP4X/GobSfRV061DpaFOpJMMAO0OXA4dmxb76LZKGn | ||||
D5LspiIp6jfeJBYrdZHk1d388w9Jyfwuq7TQEFb8tCGs8MWGsOIXGsIKX2sI | ||||
K5Rj5PlS4iIAu1ujogf7hYh8vhdQpS9ZtnrZlMKuVqqsp9T2fqrcexsXMwsY | ||||
0RC2dqpJmqIVYK84C9wyj1mMqPR2SmoQknlDnfqsTrjmB7qqcGY5r/xMvx9n | ||||
7rDm+47ubCiba5NV9a/oLLtjHvnwy4enQbKssfBplxQ6pYin1Ta7T0gl5e/M | ||||
LHZmq+RoMlOdeUvZzyIPybpuoSQ/eV444pEdf05NuCDcNkOcOzaK2TWhMAy6 | ||||
xPaOymJWv7PjHE72Hamix58Kmhp1kUHcnCMawQHZp6mmD3ddUkhczDfyk/GH | ||||
bCgM/cClIORtDbmHC5REPzitY0iCUaDN/ENyeMCfteKlkDA11XJUayr/uWf+ | ||||
TxZT+rMYcJ7KcSVgjRTl4aS09iFT+z8EQf6dnQRBxBLanJMweYJlG7QyD+z5 | ||||
dyYg8479IyLGcUVIDwDDeEnNQmogYJ/ODftuiIdtZQEi+DPXe4i2khtSsJJv | ||||
fexJByKN0KXPPMIzpXCbmMbbkgEFpdj+sILrV8Q5Dka5ggnTBPMsfUWjGXxI | ||||
h9Ej36UCXsMh8iQqEqhKAKfQUTG7vNyGtFNGWs233EuzicXdOhrlgIhj5FTG | ||||
lGk3rhLIjzla5UzgHaKlilLSzU/cezxgE2YAa4fiYLVc8OYGFUC3tEd0aNsY | ||||
wvMmSJr8vW3NGdkhofE2JkiqILIGP7lWwGAX4PlM+g6vlEzO1OWrKNP9lYVu | ||||
EhuJ6oP8i0J2bLt07nSH3Co2L8vklksKcsvdLbcy9fmh4GI9F3if4JzKZUK6 | ||||
0FmGyzhnmcyZW4E03rflVPVfKRu5pMv1lfuaoON1OcXypp3lFKiDeFQArDSE | ||||
MdkG6C0yFv2W6/VMoiiMeEsvMEMXh1TitHMSosKXuQim85lkZIIXOReIDAju | ||||
b5cUTBCMw1RYYtu5ZG+JSWFUTkTxnHa1AfcWHHGALWiqxcai2djbJWo+OcnE | ||||
qbufN+RyVHn/Ata012jaajQnRvKkzwb8oorCgcpr8eWF+Jo+0nd2Q/1UIKes | ||||
sUUg77QaPwX7I7FsfCiWU5n618TAUWqn68M/QsDRouGXXGuhLCyeZIHJG4u1 | ||||
+KllirF6UUkz0enxdH5HTZO6yH85QiUPaL8n4M6+9xHaMYlYzNQmU2uNaYfk | ||||
AFkxXJGdbkq1ASv1iQk/S84a0czEfD6pLabdXP2AJTdK36AoZxvzmHN/HD8e | ||||
kpt1jp+kpFD6cyzuKR+G4TU9LF0XFqXGO3feiqsmZKuWtrgpJDi4iRTnqme5 | ||||
t411UVjw8sqrITe8BXxS84bFMVTN8H58yXcvuPrDYmymEwofVmB9x9jRwQ/a | ||||
28UsuZyczuC45saggZQJq+YUp7Scky/PN/qlh8sR+0Zc8czYYR6iJFQUg73k | ||||
0LZ9XCGm3WE4RYv131uCREm/E1pqWDnjjPVHyJo0yVA4k5g7/5t9qrVQqM/s | ||||
AHpY4VAYeFiCESU9WXKHUT9q+5NURG3rzyd+rT+f8GoxjbQhy/RwE8/WIKvy | ||||
1GfSXAiffo0wvs07PN9k9mg7q67KGKVGm9T9qqbrkkNGKJ6Y0ViOqBabpXA/ | ||||
tNwuZZf4ZQK62kcFhlBKQ+DysN5TQCsb9tFup922YnoKSLBK7a54eAbTTImt | ||||
6ZBUy9NJ02mS5HIEUyQJ8VxlGsty4PB0C3KNQYdIBDJwzxi78ML1MeiQMTbb | ||||
o59f3XvEPzv4f1QeICMwx43O/Pn79NXH0vvpIYAqA9Jv+DGksia2yLKuh/9T | ||||
xUHrtNsei/1O93Lc7/W7Q3pW4af41qhpWi2HNj69p+znzxzQgXNF54VzyTlH | ||||
qLwUIKkF2lZwXijlSwUH22PF7m+JjKRNszBnU6MfvwBLWigPz2o3cYhcozkr | ||||
HyJNYyl8fzKhlPUMA4uWvZo7k5YcL2U3/DhXsS0wlkg+KZZzI/DzjTS9w976 | ||||
qA0ddqMstGbgh6IzgVgocGHqpIB60tok1/eifTHKWPTZtdian3Ufap3usH/b | ||||
xIavbMGTL1dmfJDjkuQTms1h82Ikjh+uunTta8iT6XcImsNu2iyPv1CriZdh | ||||
EmJHPy2VYHDnV8r3xXEAnOQrpFtOe/wUO/3j7mhca54fD4b98cnFgfizMkj8 | ||||
a9fwceV9zvDAUYXnDsTDw0M+SvnejjE42HOgM1iEsviX5E9F0XI/QN6lP1QT | ||||
7hTf02UlmZvutL+HYC5Uen6lyVSpHFRI67jQy42ST5lU5E3ay6IwIyuPRQan | ||||
5UYLLLZY0sL3D7vm7JxQyE8IFiU76UPth0pbu4D2hEt6Ym47/82z97lyxEyk | ||||
ZTIT7IqaRWKkBz3wgnsIG4AXVr60fXLPJw/wLYR7hZ3CT3uk4x6ptZtXI+DF | ||||
dJiO2HoojSQmrJ1A1FB+H0T8+b8DRMnMJYiAwX8XRMnzfztE6cy/ks2TdKxO | ||||
25X+oZyZ/PCrj+NWR8kUFDP+0w8+gjuEOU3BXUWJOV3q0fxhwzHKWjBacChj | ||||
h6AaN8VpKhAx/glKJtyT98U5waK6mh26G1TAq3jP1KR9bAHjxv4eS0rui4tn | ||||
J4anGa3wR62xB5fpcdw92djneibeg1d3JCD3AF15ny9mp9vrX/ZRQYzE7v3V | ||||
eb/dH4vj5vGIrmare9y/xHQl3hsMx7Bc5+cgqy7oDxwAUUnlI4WqNxxc4OVM | ||||
rGe+L52fKox/30Wy/0jYICVMVsBfC6OJFfDvXe+p+6IbunvGPnO3ArJMCYP/ | ||||
JHU8e/p+7lOQ+AtcjLe9ekIfoFT2EicZQLITfCSfwsm3RXX9BIl0ddMCQsIy | ||||
PxxU9RglWl4zH6Q76CDH+xktd0AiNRghuSRM6PY3ku2voRonmrUNTknZ001O | ||||
rZJwPSjLtoOyaMloADunSeJhDDcHFllU0Jcr6H9pO6Uo8G31yY4qY4xMCxAh | ||||
kmoeSbXTHd0V4c+n4/lnLJk3n65u/M+DFEbW8evLFLE6RwxuO7xNdbaC+Yvp | ||||
KuYubllJfifra5XjbzyTmBBANfT635EAv2tRE/D3FJVjn1h7BzAYaxqTb0qS | ||||
oXd11r8HhKqL+U+wQfEBOdumMYBo0g1qFJEEO/YgZ8Ye5KzYg5z5WkRarl2N | ||||
RrVBs3tV+4Cl/2mogApx8WzhSiEFNKCA+JtAVd0NL4LdLEjMP7yb+4AKViKh | ||||
aqx61Igmbf0vCJer2ezKwtwMPnp5g0oT7vJPdSdf6sbvOAqCHyc/k6FT2sS8 | ||||
nJEqc/bYHv3/fVrZrzBHHUemhV+5b/fgwECSZVZjkQ3+FAJFazBFzV+uaksc | ||||
xMGwaLShO4PvKSRbYUEAnkm43pMl+MOJwwhXqDDFnpZAk5zFpWBQ6SNXkfvy | ||||
Vi6IMXlPTmZh0Uc6Bw1jVKf4gLeWjmHuyUBJlsrP0H9rMDjeGmkxKUoOOsOe | ||||
xlCsRE2ymRkk2a0M3GoMNtfK6+9FnpKUA45AZGUNYSh32UimzK4LO1sHVDtb | ||||
fKGxxed9LYSdAyTxge3BgYLViZGBnLnJggKFK8XnOZ0BASuN6f6F/eR0SIMC | ||||
+YvbBqG5xYKjU4hji8Vgyi7ioguUdHGg76TmI3pATN8AhOwPCsovfOzm7KLy | ||||
asF3+mjSciAoca8KHPIrpUFCpy/RgD9cRr/SYe2fG+9cxD+/ORNhzQMZGevW | ||||
Uj0E+xWngTe5SKxgvm07bbKvfqZBMtxg1csH/AXepKLwz1l6+ReK3pRyGW3T | ||||
VfuQcfHBkoXzVVZmB1ki4jYTtx5VQqWWIsnBZwXeNApUqwn47bXhGGGt3Yya | ||||
x0ChUpexX1x0bKHYJ2Kj6HdhRLEsN/JXtoZQkwCrgkKDx1pTgZGRH59N2s3s | ||||
yYeHF837fUH4QBp+CjnzEH92KrKuU5J15XDMfaM2SoqgAMA73rl+xE960MBk | ||||
YpbXqg+kyH0yTnXicjTtL5Vo1l8q0aS/JC8mTtTXpv8y+T5GgtLzA1rsQLLs | ||||
GHG8yq5RhlzZP0qR3D33lzH8AHwm0LcBXMWrKB7KL+SEezGC93H0rjJvFaLd | ||||
gc4dEOUinX8LRIUw57Y1+jJEeaf3b4CoEOZEC/Js+6ehY6arWBJHKduipeSe | ||||
wg3SVIjtyhJtTREpZZ2O+dCP80OfJYeqI3zI59vTQsqWtFD18u/OCRUyqB+S | ||||
ledMhU+Tb7szb78v7fYFsm5PuP2t2ba/Q6oNIKRp7hwD/47U21+Vd6sm3ain | ||||
v3BpFj7JZuX25Sj5PDfLzMqyIIwuwK1qA6nxXu7RTBPkLOXD/4d6Yfh4JvUL | ||||
unBbcid/saoRy8Jz6xxlefbhQ8kcuYeocclJ1L3s0PzKzx8ia3OAXSZqcyt6 | ||||
BlvvT39cRivyx1+0H1qlrKbL2zzyVEzSA5J+gDk5kbyzF2b+VOFqMcs3oPiw | ||||
e3WhX3VSM11Iin6hb06uNc7WxilVXGlv/Xy7zawYl2BcgacXiwZ/5QMKu//Z | ||||
GjxANZIO+PHLH7tCH48Cr9Pjr9ubaRUSJ2k77S/8k6GUDfEldOibJXdKyN// | ||||
aBSOzLZGkaUnc7L5U3xQMyNXli5/gg5/qyD2ykMwQLhQwzc4b/+GRYK5ipy9 | ||||
1OXaLw/x66BwRTY+x6V7Vq5FLwyRjvghgjDQR13YCozDxSLdoKUx8LNZ+MUs | ||||
vFfCmg9BQwK/hLReCbzKcutcltBNOg1mmxP0c9aWZs/Hjz6/WS54o3Nrts83 | ||||
rSqJWh2mkAxRskXFEk1D1Ez8f68uSq4oyaLUEGVJlFRRIgXYq041DKaaDG74 | ||||
U2mkVMDR6yLgacqi6Yh1GFSh/9W20LUYYUlGk0l+lfBCo8QLOIklKjZOIukI | ||||
M8MF4FccioiSDF8sCMoNKtlVHsVxG6KRDieLhk7JoVEUZD4oY+Mtr9NnAJpd | ||||
/8DrwLZ5RiwB8hEAFNUi8XLsxpnmH6GS0BT5q1US6PK/m0raujuEHexPaa3V | ||||
v8r+qoRvmIy7P+JqyrApl36FM+mas6WGN3Zym5Lwk/mlN2QE4B/HBGB//tVM | ||||
gLbav5jgS0ygciZQpC8ygeLyOqJ0qTET3U0/34Vhu8Sk5UqGW7S0Nyvv41Ro | ||||
scE6siT6q9ockPaSoOXR9COWyby8IA8bRCarnZUs5+3b34Ratdi8ZN2w6uvq | ||||
q/QI647XqcvBXuTAYyAWwx7Y1yPAhqOz2msYzWjjmUqnXdZOKPcRul2o00p+ | ||||
VrXPah1fc40EcwfMcv2qsCtO/hgV/3Jl0vxid6OmpCMI/248nTtI+mPRD6Xi | ||||
gZWkpJmvbPlE9Y4z1Ffse4PYBFdozrCLETsIH4ut0P5j/tNaWZVhDf+htVU8 | ||||
Lk/DBfgP3r3o91vhU/OyNXl+mT77x41XqdW87vaazUG7+WA28b4/OYO/u001 | ||||
dO5kzXkLnKtTre4F3afWI/XyN15bmb1Yi3O1O9ae1rdGuz45JrfR8Prt7qrz | ||||
Ovvu9B5araFCntQn9UgiTme++n6/uvWV77F+eoJjnBHybn33l95qGr+rG9+b | ||||
kO6CnJnj76NVfDINFOnosnU+fTizp+qz33Tak2vdcBedqLPuOOcvLzjGeqQ+ | ||||
TY5uB98HV8GjHXrhyWBA1kvz+igKrekpka9m/c21tnLvWub7I3k/1ebn5549 | ||||
aDYebq2H+zccQ2menDyeknWoBvNhMJuc3ofGvCtJ3SPj5Xn61Dk5G124M+Xu | ||||
2JgPGuN259FpvDyoTvO0c2P0I2lNXaWT+svNzDxaX8rqRrsZ9J4Dc3qhPc8f | ||||
Dfv0xX5c6pf208nyQVtdS7cXd+pw0x29T6OBpMyjhdqgltbq/DI4Ubv37r11 | ||||
Ky+f6/qJ+tKuv59a5Pju4nRz7Q266oPXPR6eBab3trKf/LpsdMwb4jTfmu89 | ||||
WiTSOzfm8qk/2NzqltP0B4u3S1l7GT48uifB/eCi0Xk57h8vQvIg36w62kUo | ||||
6WE8eBncLFqnJ82GR6vCXqejx+P67aX3fT25vBufXz6MHs77knbmX7irWbC+ | ||||
Mdz4+/XV+/ezs2VzctFqNrt/SrkOXPoKz1HRx7i11FijajPTrZtGjjKWbhBi | ||||
G3WnYTd0q665muYqnmyoDcMwJWJKsq07tqU1HDYZ2yjsSPFskx47jj86g5+b | ||||
y5EVQ5YUS3dkR1J1zagrlurAhA3PabgusRqm6ZmyTmTXMmXFqduu5pnElkzF | ||||
dl0Zx4DfAKhXx7csT5ZdXVVVIrmG7dhqXbfhtu4pkuladcW2lDoxPFsy8Jqp | ||||
6JZF7VjFbqi27DVs21W1huwRVzc9STUlz5JcohqaKhHVkoEWutEwJAkeMxRD | ||||
athEtxuaSeGQzDrW/duGrBFNMjzLcD1PlyRJUx3bsRp6wzA9y7YM2as3dKlh | ||||
ANC2aph1S5eluulQXBxLcWzDUFXDsCWbWJLjNhzHsRygi6J7qqcRV1JdWCHT | ||||
1jRdtWEpNAABbqhGnVrSRt01HFeWHNNyiK56ugZYOjih6TmqYxDHAbxURdFs | ||||
QyNqHdDUJY0oruJIRLFpYLjhajrRDMcAGhluA+CRVUMimiPXiaUSz2xYDeI5 | ||||
umc5jQaBpQH6mLKmA/a6qrkUFyCSJ2mKbXqqXZcMA1jGUIG0uuw5CsAOYABz | ||||
1RVJJbB0GlLFcT1iyYZLZIfQdbFgDNeRiUI8heiu7pqWoRNDA0o06oomEU+3 | ||||
FMMDWD2vLusuqZsKAVgcT6vXlQZ1e4jZILIq12VN0htSwzKJpLmuKruK7EqO | ||||
Xm+ougfcRwjckSVgHVUmsu2YDohAS2KukwsrJsPfHrKEp5tEh2UEHpA9YDqT | ||||
NBqebREd1k2uK8QE6nswOLFc19FtG5aR0sOQXOA62dSQ21zZajimaboSMqgr | ||||
WV6jAWIfqGM5XkOTnDqp6/U6sYEqlk2AlfP7LW20s637w7b9X+hQ7scCNoLD | ||||
zr3LbC86Uh1Xpq5asMFgn9myrhDJsL06rL4EuEp1TdY1S1Mt2/FUp6E6MmyW | ||||
hqtIuOgajqES4gJj6K7qSIYJy2JZdcOCv2CPACUadQM2l9fwYDM6sKmJVXfr | ||||
mqfpiu2pusT2omaAtHENUzGBsLAvAACrrkqwikRX6rLiNSx4pQGgAX/XbVgp | ||||
3bJlEFQEdo3TqFNc9LpiAmfomqyaIDQUg5imqjuwqSxYK+IqwI66o8ESeXXY | ||||
H8Aqqk0UU/UMyzRtup8NowGMAYwLgq+uOp5twILXYbU9Va0bDrC/LEmO2gDO | ||||
VR2tAf/RYBurim5KsKV16rPLpgFiFPYv4AcM6HgWcLlnqiA/JF2te67bsEDW | ||||
WJrjOrZr2q6kmSA5iFtXCexBGmEwbEAe97QJdNYM2yAKgKHXdadhAq2IBgCA | ||||
OAOuchuwA2C/Sp6uWrC366ZmupQewO0gtoDZdJWYIOLgccOQFNc0FNXwPJQC | ||||
GgxnuXoDhJxHqQ37zAWC27rGaGpbwAVOveEawOKSKykgrmUJRCnsPFjHhu3K | ||||
DmwPSfIaMkhfVVaIpYDgtVQdgFV1up9d0B+q1FA9W/fqsKBSXcKxvHodsHUa | ||||
jgoiu2F4hl2HLVo3AWbds03YfIoKwoTKFUv2ZEeG1QJtoNUt0wUhRFQFUAC5 | ||||
7up1XASi1F3bhi2keSB5NUJAfdUND0S5S2kK0liHP0FaKFpdNQB/IjdAxcBi | ||||
AYowtAm7AajhWICGoikwoQZC1wVb3mpYtpHfi0k3ph1dhHZY7tm+A9YCoeVo | ||||
oFhBuGuAtiYpoIhA70m6pSvpuYicAYs+TdVcZb2jGSTwxGDYB7cX7NxBcvIw | ||||
d4Q1dXe3fmER3eWSz8C+8JD/4Ar4RbKRfkgHzxcWwnBwezsQadto8OzZ2zli | ||||
SMBkEnKVhAxraGBwGDpc0uCGLimSLEvZecbPkEy+do5fSeIzSBg5/VEs2VHg | ||||
mvxDLF7EeF0DD3RWy0PzyZ89BYlgauD6gqMriyq8KIt6Gr3FETCyKWPsCidJ | ||||
KklkI//Ir10cteUTJ+zD7QVOSz77LtibHc5NEqv4hGSsqTA7vIuHrJOvFdDA | ||||
SPescCoV5IOD0sDzFFszwBbyDNiihly3JdkEQfmJgZh9umB7v/1sonrdUyyQ | ||||
dRrygY26SQMRKMElSwZxa+cnws9WV1i3+DH1D+al/mzuUxUR7fxSXYMMNgWF | ||||
CJgmKpgIGig72bBNA8Sb4zl1uWHXTU9WXCKZDpibBpEaW7U4PYkE1kLWS7/k | ||||
t7db7ewriTu/oY5bQjZqdE+J/Vt+zj63YrCbQBd5xAaLAqWma+OkcAUMkXod | ||||
zNh0Z5WgWcywuS42fikOZ+hgIzqGpziKVAcBW1fgF4hLWCj4TzZc1lsq10Mm | ||||
PxSMApada8PaunXQ0qAuiQLWMljZYKYabolsqZhLAzs0rrPHhW0pGkK5X2gz | ||||
XOiHpJLtEIhZwz9uHAGvgAHFqdmyYrA2a7wpv5DaT6lAAQ++fd98OD0LH/vT | ||||
tXPZvHY6IVwbj9vt5vNzu3l98TaZ9LsLuNZsPpxnzz1fd64vXoXJ5GTdnHSb | ||||
k9aIwFY6Xd0uJLkrrXtPs/lkMGktndVz0GmetiZOOHl4e2vCYK1+vwXe4NtR | ||||
2zGE7wPSiG/PJ9aR897tPFy7rduza2N9dXV61bo8DUat2WX3aqWAOXHVtHr6 | ||||
2UJZhLf9nr26t4ZH+vdLIWrdrxZwdzhav9+cPR73nuTwrG/cP503DOfVJ/rI | ||||
GX23xlIwsWK9vu7fRb3L8dNlPDNvN77/eCN0tbf66crv3B/HZ0G9Pno8ve8a | ||||
y4Z05z+/r/3JkRX6b4+Le7M1fwwd87siKc5D/f1SeV+/Xnc6s5ZgmqObWbel | ||||
XcwmJ4vb5wdLv794Obp8G19FaqANGhe9yyP1MVrePb8764f19ej4+0p+N9zR | ||||
cfw6bdh9oTUbRrb/+HYrbx6GU717otzenDVmrjaXrm6MxwHpPt1fuLPJ0/XN | ||||
96fx8HY4by6n/uX66Mnpbh6iW+H5ZvzePtWJfXtavz0lRrfzpsu+0ZTalzfd | ||||
89YatsjjeviqNZvfh527i5Hhm5NQvpUvLakVvz4fCUvPW92ctJvSldsYXQSd | ||||
WJ2tLVUdk+N277s2G/aPWhehd9Ja++cnQ+PJiwYXT85VfHn7SjpaoNQFLxib | ||||
Lzf1p1kA3lzDX9yOlZOJP3y3n7zps/ui35ief3bRMmQnfOs/953epdFobV6s | ||||
5VPTboEGFybXN9fT58npebPbvmhKx+279vGo2Zs1X6+BC2+awGTXF804f73V | ||||
ur5+ODuZrO7Hsi6Mgoe71fFV/d10HpeaOVInT1dnx9rpRef1uD16OR71bbVz | ||||
3T1pjptuazKbwGStx+uLbvO63+12JxfCZm0Y63U0UAyVbNZ+39WOm90L++zR | ||||
XdbVe+vVVLX1i3L6vJxLf8rl+JLPJhG+q8OCtgaV8mO7Yq7qZVIUBjIodqqY | ||||
aYU9aOW6iIcEQBPrJg7w79J/4IByA37rqITz0+DhRqqvM40NnqBiiDqaD/Th | ||||
MT6nSnBFoVfEf9fogKrG7Qlxm/VQMAxEsRq6rcLdQBNDVin0Wl0Ez4W/nAdY | ||||
l1OAczBLcAPAUaTkBiBdhqDRFbst0aiL7YbYAmI0xbomdjRR64hKD6dWG+AM | ||||
iaYkdjHcXn69pYvtltjUxEZbEOtGYjaV4aubqMmTO1tW75nM0WcF9CV2rAbI | ||||
oIjafnk+ak6ZsJamllwatMfd5CvV5cfbEmYqem1RgVeaYs8Uu3Wx1RFbYKUp | ||||
Yhc4rCX24JaKeQrVKL8OF4EawDNaU9RUsdkS2z1RbYsNVWzLuNSNhthRMC2h | ||||
g+mnlV9XgbYdpHBPFzsqAmOYot7F0Zp10WjSnxomSvQWEL/8OpCzAcD3xEZP | ||||
NDtis42QdLv4bgcYoSdquqgA/KqoS2KzArxm0OXr4CyYt+mKjbpotsVWT6zD | ||||
KquiZNLV15E4/BhY7vVeA5e1p+EzgCDMjqQDCpjIJEBA4BCti6QzgCD1CuV1 | ||||
sQ6c3KS7RkMGhqnrLfwJjGQCzG0kvtRE7Frd8utAVQOmBu7SxG5T7PRwIWBe | ||||
pYEztrqIkdpDGpomAFN+HTgW3oV1B8jhb6AA4Atr1zJwIYDbwfvo9nAoIHK7 | ||||
Mju8iGmwNjK/JiOFAYwG/S9sTWBmVQGxgQmxJsiTysLB4IAaAt9GnoHXgQm1 | ||||
tthrIrPhaqrIhCg94FavgjvwTBM5B/CFtzptfNhsiR0JU15GDwxDZADgrgYs | ||||
gVnBvYUjwx7pGLhYEqU/XDS6SHyARK8j8Rsm5ZAK7hosVg+zavAWcFcHZEJH | ||||
7MJydESphwA3DVx3IAIA06msuyrjK5ig62D6D4CEP2Cn6DpOB9eVDubuQMIC | ||||
Ir3K7GodU3kgi4BzOjryP8DTS3gV9g6AATsXGAnAq3Jdq0k3MnBaA9FXuii4 | ||||
gG4wHTKhJLYknBeIgJuosnBAZ7mNOU9JQmRhdgm2DwgHBZkQ5KECG01FXOqA | ||||
ml5+vdnBJGRLxVwnMCfIRlhu2LCwPesShwSu1HHVAMfKllHxXYAcIIT1gseA | ||||
V4HOSEwYqiWaDRT0gEsPOKFdmR0YVUa5hLtDEdt1VBdNE/cObl4VXwQwYBxA | ||||
Sq+QDpgZ2BIWGuaFbV7v4o6DjdBs4HLD6w0DN0uvg393KlwHjwFZQNoA45kg | ||||
uzXcccBysKBdGSnZaVL9oiJg3Yq0ge2MspoueruJXAQoaAouhwz6qItLg/nn | ||||
Jm6NliFosAAgt7boGq1eR8G9W9dUVQqt9N1D911GTcA8+gbdCaKyL2hAd7iT | ||||
Pp+frIGKt5EN9YXZ0HunlY3bogdwaV/QJQUXJHuFnjytDvRrm3bUabFRxRaQ | ||||
DbhTz9kmeTR0PN2bQ+MLWPzuMEgCHmwh4I6vKG/gCeB+2MMggICxYGOA4qxT | ||||
rdYycVv2qD4GfgIrrlVhaLOH+xZYB2QHPAajATtKlV1XpWL5AgANogu24Y8y | ||||
2TQzI1vVpnF3GaK4xDpQXOGv5oc08gz16TrwVcAIwfZFAPbV6woLe31GcKyn | ||||
aOPu63VRkIIYAYUFUHVaKNmAkG1qQYHChS1mVnQukKkhZTOhgd028B3QJTAE | ||||
iGxQbLB8IIJRI3ZRnoJ2NKimB8VsdCp0L/wu/iz8ytrHpNb0jpbD+bgpT+xn | ||||
JQbbM/u0+L9bTu0f681+q9ncnb7/KHWPY3wlff9R6h7H+Er6/qPUPY2GfyF9 | ||||
/1HqHsf4Svr+o9Q9jvGV9P1HqXu6Ll9I33+UuscxvpK+/yh1T0sMtqfv25PJ | ||||
cXPc855HzzdPT6ftp/N151mzRs5i9GZ8H1rPnjKN3JFK+ePp9WW6ufGa95Px | ||||
mNxcX7di+eR2edKevF27319m9w+BevSyMsfk8fb1WLu8el9u/KNHfdOSXwfH | ||||
p91bGlB/Ni+PNsvVzFic9nqBsdDM2wtJtm/ccfR8cWrfd4fEmBxFkeG2rgnp | ||||
L9vW4Kx+qY/6pyfq4GVKs8FvD6uWvjzRopdV2304ny/l+vjNbFu3LzeNl6sH | ||||
dT1wr7uD1/7T08Wtubq+GZrRyWjQOHsePZnNY1rref7SeHZWV4v15NRRwpeL | ||||
oXNJrkbK3e3UfLvqPS+H5+dD631yfmWOxifN5dPYGM1OlZv355sXr3NyfIZj | ||||
vBy1wvu3VmdlnMu3nVc36I/0k/vlua51Z879XRwONmc988ifzafDm/7N3fCx | ||||
N5+N5PDZ7Lf1/uQex7hxzxvR6e1jbzw83zRf5067ux5eyFZst6LppruJp6PB | ||||
6lIPTk59AO70++voxH8iZzP5hZzPFhfPOMZJ5PYfWi/a5Xv96P1+7l8vpovm | ||||
5vvmmljB9MocaAOjbZL68PXMXbwRTYtX2qPpdSdNfXP9Jq2omjI3Q7k7PT7b | ||||
uPe6PW2dD/X2XL69qEdjpdUMT1rNq6PvRJ88nl96R932stt6fCL+qXQbgxgY | ||||
hDd0z02tm+ur5vdG662x2Czj8Gyuh9fTVv26Y70111FgHvVu7hSr+Wzdx9ZT | ||||
o/f96EWVmg+j62X3zfIbpziG556dheGzGvrzS/NoczmMz+ZT7+l48GROXe37 | ||||
8dO99BJejFrt7q07/m43n56ijfk6uY5ehmT1GFAZFN7fmLo7t9Wn9Vpa9Z33 | ||||
/tl63Cebp/uubnlP1/3T8/lj7z5uzaVG69is9y2927s5m20aRmtwcUp57Oj6 | ||||
rvu+eni477wMet779fK5Sbz7y96dIp+9ayevyvVZ6/W6Q/zjqTZ7ax+Pn7rt | ||||
9XHds1YXx7PVd0qPzsh92Fyc+J6xNOZvep2MZKP7tB5Es/uz/vJh2t+835ln | ||||
r1LkHbVHLeXJ9Cfy8fPF+XgwiY77p6yKQ1WUUJd6g0gPB/PHqxUhQ20x2DSv | ||||
JG9ybXY68rl62lo8GOaReTF9sGP/HeT592akPV1IXoO64HeK3dPvn9Tpd+96 | ||||
3Ll4fjNuo3b72pj7w3nr5v3k++NVrAdHs4fBe/MhevHPBlZg+Scbbf40XM9i | ||||
Wl40f3o03vX2sRn3Ry/O+fXRs3o98/XF4OFoLUVu62ny2rw7umlPnG7z5fj2 | ||||
4fjpzL1vv686a6/RXdzSQMR8Mb5rGZv+reI8W1eD4Gj56OutSTzvXr2uHx8e | ||||
l9L6wl4p5tVbPR4tnl9uVq0zGyT/wtmYq7bap+VWqwd/3Jxe+CcjLXrrt+7V | ||||
1sP9aNXpKMOOtj6Wv99fSFPj6XZ4cn8ylYLBvXvrTYK5P7k6flefbimPtcxw | ||||
MT166pgD5aH9rD20x53B/VXXN4dPq/jtPQq/v07Xw+H352NpEh8fO2ej28v2 | ||||
1ZPsXfZH3SWhuExO+259IM9vms130nkKjm6t0dHV/XW47l6Eszi+ujoLGpeh | ||||
Y5/ZC7p/ToPeyekqmCnK3dEsinCMxWJ+FfTfn/qq9HDrPAya+nr2cn62Obaa | ||||
ceA9vFzJdzeXE+92+qI8DePo5K3hBCfX/cbJStOUqzWlx9t3B1SO9NA71fxF | ||||
VyXD4XDevPG1yfRBv5t0vsvTV9N72dzc1bv1mX5uj+zj7s3t/TJ6vtGPDW1M | ||||
ZdCwIZ93Nxc9c3DVHLv+7dFZR7u6e3ieWC/Dubq87a7at812Z3z9/HIZDwa+ | ||||
+nB17cyVuvRqTN68a7oug+7m6Nmdtnvk7bTXNFeP6/nUaC8UJ3Le3zYtfzY8 | ||||
2rTfXs4Gg8uXWc8d4P7p2afPOjm5ejp9xzGaDytydnHdHV0dP7Sj1/7L2+Tx | ||||
uP1mvZDbZnSyPosxDP467Rund2Hv4fYZpulJF5vp6jns2kcKK+l7aelj0+xM | ||||
1K798jT2zyfqy1t0d6oM3pY3obloXSl95dWeKZeD13fHjmYP0/fuo2mfbt4e | ||||
V7pP91z80D9vm2A3Xb+/Gk8j7Xox1zby3cm7SY66szvjduPNZ0+PD82617i7 | ||||
CJauR65vX9q375fj9VlgeFQWTozj0eJ0/L7Qzm/VcDXxG8H16u7+sae89oP4 | ||||
/vn8YRH7F/a50XtXteFrOD1dPjT/VCqnKxt6ST2dSD8Cm/vuZvEbDIWkVumj | ||||
C+y4w+H2YYovTiKC325g76bfeeYjsm/3YcA8/xVlNmz+01P5MWnKMHml9Nkp | ||||
VtsqFNqi/6sw71+Fef8qzPvrCvO2be/Ct7z/ht39Dyowyjzncn0RgvH/k+oi | ||||
3osmIgtCewNjK5othPxaXQ0vExC+hO/fs2oGwU1LWdJuFfQbeR+dx6CHKVLi | ||||
V3H87YP3ClB+reSmqns+rV5JJxf+O8tX0o825T9ZxGH7/WUnxQoWXhqTlcRs | ||||
G/hrpTFNDwUCfnaEtnZJDpNRguE0cI0x0ceTnZDZLDwQ6VGe/5Ecf2o6+PHp | ||||
GXEntBd5LPz8EaywER1x//TNs2Yx+fZLEO7o9yiCZ/HUwp44+KE6azY7EFur | ||||
aCmeWTM/xgPtyNSn4TQQWxHAgd/rYKcJBH5caCZaq+U0jGLWQzn9su9vrNe5 | ||||
GzqrOQM6/eADPwgEMD8f5sBAZFm/vPRDLuzrAT2ZPotUmkThapGc6PMjWg8V | ||||
+faKd1uHPRJZ3pK+n/tCAfva5Ix9aTIHY3721gy/MTO05rFLkAqn/lwcOVPL | ||||
cg/EC2sSrGLxcgPLFc4PsEhIPI58z/MD9o1OSqBzP2AflJ2SGV1Sm7aazn/t | ||||
GKb3ohVtQpmbWyhQXGjOyBsA4s+IBcOfhgQ/fglAHQgXPoA4WAUxkGM5PRCu | ||||
8Ag1Nn1a2BRmLHXqWIFPZuItqJRjQuIl/dabA4INu2FGZO2TVy7a8MvES7zq | ||||
hPM5+1oGKi+qq/CL83P2yYbiOh4K/x/15nZmJ90AAA== | ||||
<!-- [rfced] We note that the following terms appear inconsistently | ||||
throughout the document. If there are no objections, we will use the | ||||
form on the right. | ||||
PKCS #1 v1.5 vs. PKCS #1 v1.5 algorithm | ||||
RSA-KEM vs. RSA-KEM algorithm vs. RSA-KEM Algorithm | ||||
--> | ||||
</rfc> | </rfc> | |||
End of changes. 192 change blocks. | ||||
1274 lines changed or deleted | 473 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |