rfc9688.original.xml   rfc9688.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 2.6.1 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
0) --> -ietf-lamps-cms-sha3-hash-04" number="9688" obsoletes="" updates="" category="st
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft d" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symR
-ietf-lamps-cms-sha3-hash-04" category="std" consensus="true" submissionType="IE efs="true" version="3" xml:lang="en">
TF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title abbrev="Using SHA3 with the CMS">Use of the SHA3 One-way Hash Functio <title abbrev="Using SHA3 with the CMS">Use of the SHA3 One-Way Hash Functio
ns in the Cryptographic Message Syntax (CMS)</title> ns in the Cryptographic Message Syntax (CMS)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-sha3-hash-04"/ <seriesInfo name="RFC" value="9688"/>
>
<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>
<city>Herndon</city> <city>Herndon</city>
<region>VA</region> <region>VA</region>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2024" month="May" day="16"/> <date year="2024" month="November"/>
<area>Security</area>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 119?>
<area>SEC</area>
<workgroup>lamps</workgroup>
<keyword>example</keyword>
<abstract>
<t>This document describes the conventions for using the one-way hash functions <t>This document describes the conventions for using the one-way hash functions
in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3
family can be used as a message digest algorithm, as part of a signature family can be used as a message digest algorithm, as part of a signature
algorithm, as part of a message authentication code, or part of a key algorithm, as part of a message authentication code, or as part of a Key
derivation function.</t> Derivation Function (KDF).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 127?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>The Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> is used to digitally sign, <t>The Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> is used to digitally sign,
digest, authenticate, or encrypt arbitrary message contents. This digest, authenticate, or encrypt arbitrary message contents. This
specification describes the use of the four one-way hash functions in the specification describes the use of the four one-way hash functions in the
SHA3 family (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) <xref target="SHA3"/> w ith the SHA3 family (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) <xref target="SHA3"/> w ith the
CMS. In addition, this specification describes the use of these four CMS. In addition, this specification describes the use of these four
one-way hash functions with the RSASSA PKCS#1 version 1.5 signature one-way hash functions with the RSASSA PKCS#1 version 1.5 signature
algorithm <xref target="RFC8017"/> and the Elliptic Curve Digital Signature Algo rithm algorithm <xref target="RFC8017"/> and the Elliptic Curve Digital Signature Algo rithm
(ECDSA) <xref target="DSS"/> with the CMS signed-data content type.</t> (ECDSA) <xref target="DSS"/> with the CMS signed-data content type.</t>
<t>This document should not be confused with RFC 8702 <xref target="RFC870 <t>This document should not be confused with <xref target="RFC8702"/>, whi
2"/>, which defines ch defines
conventions for using the the SHAKE family of SHA3-based extensible output conventions for using the SHAKE family of SHA3-based extensible output
functions with the CMS.</t> functions with the CMS.</t>
<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"/>, using th e Basic <t>CMS values are generated with ASN.1 <xref target="X.680"/>, using 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="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and ",
only when, they "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
appear in all capitals, as shown here. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<?line -6?> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sha3oids"> <section anchor="sha3oids">
<name>Message Digest Algorithms</name> <name>Message Digest Algorithms</name>
<t>One-way hash functions are also referred to as message digest algorithm s. <t>One-way hash functions are also referred to as message digest algorithm s.
This section specifies the conventions employed by CMS implementations This section specifies the conventions employed by CMS implementations
that support SHA3-224, SHA3-256, SHA3-384, and SHA3-512 <xref target="SHA3"/>.</ t> that support SHA3-224, SHA3-256, SHA3-384, and SHA3-512 <xref target="SHA3"/>.</ t>
<t>Digest algorithm identifiers are located in the SignedData digestAlgori thms <t>Digest algorithm identifiers are located in the SignedData digestAlgorithms
field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm
field, and the AuthenticatedData digestAlgorithm field.</t> field, and the AuthenticatedData digestAlgorithm field.</t> <t>Digest values
<t>Digest values are located in the DigestedData digest field and the Mess are located in the DigestedData digest field and the Message Digest
age authenticated attribute. In addition, digest values are input to signature
Digest authenticated attribute. In addition, digest values are input to algorithms.</t>
signature algorithms.</t>
<t>SHA3-224, SHA3-256, SHA3-384, and SHA3-512 produce output values with <t>SHA3-224, SHA3-256, SHA3-384, and SHA3-512 produce output values with
224, 256, 384, and 512 bits, respectively. The object identifiers for 224, 256, 384, and 512 bits, respectively. The object identifiers for
these four one-way hash functions are as follows:</t> these four one-way hash functions are as follows:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }
id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 } id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 }
id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 } id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 }
id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 } id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 }
id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 } id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 }
]]></sourcecode> ]]></sourcecode>
<t>When using the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 <t>When using the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512
algorithm identifiers, the parameters field MUST be absent; not NULL algorithm identifiers, the parameters field <bcp14>MUST</bcp14> be absent, not N ULL
but absent.</t> but absent.</t>
</section> </section>
<section anchor="signature-algorithms"> <section anchor="signature-algorithms">
<name>Signature Algorithms</name> <name>Signature Algorithms</name>
<t>This section specifies the conventions employed by CMS implementations <t>This section specifies the conventions employed by CMS implementations
that support the four SHA3 one-way hash functions with the RSASSA PKCS#1 that support the four SHA3 one-way hash functions with the RSASSA PKCS#1 v1.5 si
version 1.5 signature algorithm <xref target="RFC8017"/> and the Elliptic Curve gnature algorithm <xref target="RFC8017"/> and the ECDSA <xref target="DSS"/> wi
Digital th the CMS signed-data content type.</t>
Signature Algorithm (ECDSA) <xref target="DSS"/> with the CMS signed-data conten
t type.</t>
<t>Signature algorithm identifiers are located in the SignerInfo <t>Signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData. Also, signature algorithm signatureAlgorithm field of SignedData. Also, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field identifiers are located in the SignerInfo signatureAlgorithm field
of countersignature attributes.</t> of countersignature attributes.</t>
<t>Signature values are located in the SignerInfo signature field of <t>Signature values are located in the SignerInfo signature field of
SignedData. Also, signature values are located in the SignerInfo SignedData. Also, signature values are located in the SignerInfo
signature field of countersignature attributes.</t> signature field of countersignature attributes.</t>
<section anchor="rsassa-pkcs1-v15-with-sha3"> <section anchor="rsassa-pkcs1-v15-with-sha3">
<name>RSASSA PKCS#1 v1.5 with SHA3</name> <name>RSASSA PKCS#1 v1.5 with SHA3</name>
<t>The RSASSA PKCS#1 v1.5 is defined in <xref target="RFC8017"/>. When RSASSA PKCS#1 v1.5 is <t>The RSASSA PKCS#1 v1.5 is defined in <xref target="RFC8017"/>. When RSASSA PKCS#1 v1.5 is
skipping to change at line 143 skipping to change at line 144
<t>The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys <t>The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys
in certificates is specified in <xref target="RFC3279"/>, and it is repeated her e for in certificates is specified in <xref target="RFC3279"/>, and it is repeated her e for
convenience:</t> convenience:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
]]></sourcecode> ]]></sourcecode>
<t>When the rsaEncryption, id-rsassa-pkcs1-v1-5-with-sha3-224, <t>When the rsaEncryption, id-rsassa-pkcs1-v1-5-with-sha3-224,
id-rsassa-pkcs1-v1-5-with-sha3-256, id-rsassa-pkcs1-v1-5-with-sha3-256,
id-rsassa-pkcs1-v1-5-with-sha3-384, and id-rsassa-pkcs1-v1-5-with-sha3-384, and
id-rsassa-pkcs1-v1-5-with-sha3-512 algorithm identifier is used, id-rsassa-pkcs1-v1-5-with-sha3-512 algorithm identifiers are used,
AlgorithmIdentifier parameters field MUST contain NULL.</t> the AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> contain NULL.</t>
<t>When the rsaEncryption algorithm identifier is used, the RSA public k ey, <t>When the rsaEncryption algorithm identifier is used, the RSA public k ey,
which is composed of a modulus and a public exponent, MUST be encoded which is composed of a modulus and a public exponent, <bcp14>MUST</bcp14> be enc oded
using the RSAPublicKey type as specified in <xref target="RFC3279"/>. The outpu t of using the RSAPublicKey type as specified in <xref target="RFC3279"/>. The outpu t of
this encoding is carried in the certificate subject public key. The this encoding is carried in the certificate subject public key. The
definition of RSAPublicKey is repeated here for convenience:</t> definition of RSAPublicKey is repeated here for convenience:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
RSAPublicKey ::= SEQUENCE { RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n modulus INTEGER, -- n
publicExponent INTEGER } -- e publicExponent INTEGER } -- e
]]></sourcecode> ]]></sourcecode>
<t>When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a <t>When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a
single value, and that value is used directly as the signature value.</t> single value. That value is used directly as the signature value.</t>
</section> </section>
<section anchor="ecdsa-with-sha3"> <section anchor="ecdsa-with-sha3">
<name>ECDSA with SHA3</name> <name>ECDSA with SHA3</name>
<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in <t>The ECDSA is defined in
<xref target="DSS"/>. When ECDSA is used in conjunction with one of the SHA3 <xref target="DSS"/>. When the ECDSA is used in conjunction with one of the SHA
3
one-way hash functions, the object identifiers are:</t> one-way hash functions, the object identifiers are:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 }
id-ecdsa-with-sha3-224 OBJECT IDENTIFIER ::= { sigAlgs 9 } id-ecdsa-with-sha3-224 OBJECT IDENTIFIER ::= { sigAlgs 9 }
id-ecdsa-with-sha3-256 OBJECT IDENTIFIER ::= { sigAlgs 10 } id-ecdsa-with-sha3-256 OBJECT IDENTIFIER ::= { sigAlgs 10 }
id-ecdsa-with-sha3-384 OBJECT IDENTIFIER ::= { sigAlgs 11 } id-ecdsa-with-sha3-384 OBJECT IDENTIFIER ::= { sigAlgs 11 }
id-ecdsa-with-sha3-512 OBJECT IDENTIFIER ::= { sigAlgs 12 } id-ecdsa-with-sha3-512 OBJECT IDENTIFIER ::= { sigAlgs 12 }
]]></sourcecode> ]]></sourcecode>
<t>When using the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, <t> When the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 algorithm
id-ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers, identifier is used, the parameters field <bcp14>MUST</bcp14> be absent, not NULL
the parameters field MUST be absent; not NULL but absent.</t> but absent.</t>
<t>The conventions for ECDSA public keys is as specified in <xref target <t> When the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, id-
="RFC5480"/>. The ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers are
ECParameters associated with the ECDSA public key in the signers used, the parameters field <bcp14>MUST</bcp14> be absent, not NULL but absent.</
certificate SHALL apply to the verification of the signature.</t> t>
<t>When signing, the ECDSA algorithm generates two values. These values <t>The conventions for
are commonly referred to as r and s. To easily transfer these two ECDSA public keys are as specified in <xref target="RFC5480"/>. The
values as one signature, they MUST be ASN.1 encoded using the ECParameters associated with the ECDSA public key in the signers certificate
ECDSA-Sig-Value defined in <xref target="RFC3279"/> and repeated here for <bcp14>SHALL</bcp14> apply to the verification of the signature.</t> <t>When
convenience:</t> signing, the ECDSA algorithm generates two values. These values are commonly
<sourcecode type="asn.1"><![CDATA[ referred to as r and s. To easily transfer these two values as one signature,
ECDSA-Sig-Value ::= SEQUENCE { they <bcp14>MUST</bcp14> be ASN.1 encoded using the ECDSA-Sig-Value defined in
r INTEGER, <xref target="RFC3279"/>, which is repeated here for convenience:</t>
s INTEGER } <sourcecode type="asn.1"><![CDATA[ ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s
]]></sourcecode> INTEGER } ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="message-authentication-codes-using-hmac-and-sha3"> <section anchor="message-authentication-codes-using-hmac-and-sha3">
<name>Message Authentication Codes using HMAC and SHA3</name> <name>Message Authentication Codes Using HMAC and SHA3</name>
<t>This section specifies the conventions employed by CMS implementations <t>This section specifies the conventions employed by CMS implementations
that support the HMAC <xref target="RFC2104"/> with SHA3 message authentication code (MAC).</t> that support the Hashed Message Authentication Code (HMAC) <xref target="RFC2104 "/> with SHA3 message authentication code (MAC).</t>
<t>MAC algorithm identifiers are located in the AuthenticatedData <t>MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field.</t> macAlgorithm field.</t>
<t>MAC values are located in the AuthenticatedData mac field.</t> <t>MAC values are located in the AuthenticatedData mac field.</t>
<t>When HMAC is used in conjunction with one of the SHA3 <t>When HMAC is used in conjunction with one of the SHA3
one-way hash functions, the object identifiers are:</t> one-way hash functions, the object identifiers are:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }
id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 } id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 }
id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 } id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 }
id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 } id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 }
id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 } id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 }
]]></sourcecode> ]]></sourcecode>
<t>When the id-hmacWithSHA3-224, id-hmacWithSHA3-256, <t>When the id-hmacWithSHA3-224, id-hmacWithSHA3-256,
id-hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithm id-hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithm
identifier is used, the parameters field MUST be absent; identifiers are used, the parameters field <bcp14>MUST</bcp14> be absent,
not NULL but absent.</t> not NULL but absent.</t>
</section> </section>
<section anchor="key-derivation-functions"> <section anchor="key-derivation-functions">
<name>Key Derivation Functions</name> <name>Key Derivation Functions</name>
<t>The CMS KEMRecipientInfo structure <xref target="I-D.ietf-lamps-cms-kem ri"/> is one place where <t>The CMS KEMRecipientInfo structure <xref target="RFC9629"/> is one plac e where
algorithm identifiers for key-derivation functions are needed.</t> algorithm identifiers for key-derivation functions are needed.</t>
<section anchor="hkdf-with-sha3"> <section anchor="hkdf-with-sha3">
<name>HKDF with SHA3</name> <name>HKDF with SHA3</name>
<t>This section assigns four algorithm identifiers that can be employed by CMS <t>This section assigns four algorithm identifiers that can be employed by CMS
implementations that support the HMAC-based Extract-and-Expand Key Derivation implementations that support the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) <xref target="RFC5869"/> with the SHA3 family of hash functions. </t> Function (HKDF) <xref target="RFC5869"/> with the SHA3 family of hash functions. </t>
<t>When HKDF is used in conjunction with one of the SHA3 <t>When HKDF is used in conjunction with one of the SHA3
one-way hash functions, the object identifiers are:</t> one-way hash functions, the object identifiers are:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-alg OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 }
id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg TBD1 } id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg 32 }
id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg TBD2 } id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg 33 }
id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg TBD3 } id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg 34 }
id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg TBD4 } id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg 35 }
]]></sourcecode> ]]></sourcecode>
<t>When id-alg-hkdf-with-sha3-224, id-alg-hkdf-with-sha3-256, <t>When id-alg-hkdf-with-sha3-224, id-alg-hkdf-with-sha3-256,
id-alg-hkdf-with-sha3-384, or id-alg-hkdf-with-sha3-512 is used in id-alg-hkdf-with-sha3-384, or id-alg-hkdf-with-sha3-512 is used in
an algorithm identifier, the parameters field MUST be absent; an algorithm identifier, the parameters field <bcp14>MUST</bcp14> be absent,
not NULL but absent.</t> not NULL but absent.</t>
</section> </section>
<section anchor="kmac128-kdf-and-kmac256-kdf"> <section anchor="kmac128-kdf-and-kmac256-kdf">
<name>KMAC128-KDF and KMAC256-KDF</name> <name>KMAC128-KDF and KMAC256-KDF</name>
<t>This section specifies the conventions employed by CMS implementation s <t>This section specifies the conventions employed by CMS implementation s
that employ either the KMAC128 or KMAC256 as a key derivation function as that employ either KMAC128 or KMAC256 as KDFs as
defined in Section 4.4 of <xref target="NIST.SP.800-108r1-upd1"/>.</t> defined in Section 4.4 of <xref target="NIST.SP.800-108r1-upd1"/>.</t>
<t>KMAC128 and KMAC256 are specified in <xref target="NIST.SP.800-185"/> . The use of KMAC128 <t>KMAC128 and KMAC256 are specified in <xref target="NIST.SP.800-185"/> . The use of KMAC128
and KMAC256 as a key derivation function are defined as:</t> and KMAC256 as KDFs are defined as follows:</t>
<ul empty="true"> <t indent="3">KMAC128-KDF is KMAC128(K, X, L, S).</t>
<li> <t indent="3">KMAC256-KDF is KMAC256(K, X, L, S).</t>
<t>KMAC128-KDF is KMAC128(K, X, L, S).</t>
</li>
</ul>
<ul empty="true">
<li>
<t>KMAC256-KDF is KMAC256(K, X, L, S).</t>
</li>
</ul>
<t>The parameters to the KMAC128 and KMAC256 functions are:</t> <t>The parameters to the KMAC128 and KMAC256 functions are:</t>
<ul empty="true"> <dl>
<li>
<dl>
<dt>K</dt> <dt>K</dt>
<dd> <dd>
<t>the input key-derivation key. The length of K MUST be less t han 2^2040.</t> <t>The input key-derivation key. The length of K <bcp14>MUST</b cp14> be less than 2<sup>2040</sup>.</t>
</dd> </dd>
</dl>
</li>
</ul>
<ul empty="true">
<li>
<dl>
<dt>X</dt> <dt>X</dt>
<dd> <dd>
<t>the context, which contains the ASN.1 DER encoding of CMSORIf orKEMOtherInfo when the KDF is used with <xref target="I-D.ietf-lamps-cms-kemri" />.</t> <t>The context, which contains the ASN.1 DER encoding of CMSORIf orKEMOtherInfo when the KDF is used with <xref target="RFC9629"/>.</t>
</dd> </dd>
</dl>
</li>
</ul>
<ul empty="true">
<li>
<dl>
<dt>L</dt> <dt>L</dt>
<dd> <dd>
<t>the output length, in bits. L MUST be greater than or equal to 0, and L MUST be less than 2^2040.</t> <t>The output length in bits. L <bcp14>MUST</bcp14> be greater than or equal to 0 and <bcp14>MUST</bcp14> be less than 2<sup>2040</sup>.</t>
</dd> </dd>
</dl>
</li>
</ul>
<ul empty="true">
<li>
<dl>
<dt>S</dt> <dt>S</dt>
<dd> <dd>
<t>the optional customization label, such as "KDF" (0x4B4446). The length of S MUST be less than 2^2040.</t> <t>The optional customization label, such as "KDF" (0x4B4446). The length of S <bcp14>MUST</bcp14> be less than 2<sup>2040</sup>.</t>
</dd> </dd>
</dl> </dl>
</li>
</ul>
<t>The K parameter is known to all authorized parties; it is often the o utput <t>The K parameter is known to all authorized parties; it is often the o utput
of a KEM Decap() operation. The X parameter is assembled from data that of a KEM Decap() operation. The X parameter is assembled from data that
is transmitted by the originator. The L parameter is determined by the is transmitted by the originator. The L parameter is determined by the
size of the output keying material. The S parameter is optional, and if size of the output keying material. The S parameter is optional, and if
it is provided by the originator, it is passed in the parameters field of it is provided by the originator, it is passed in the parameters field of
the KDF algorithm identifier.</t> the KDF algorithm identifier.</t>
<t>When KMAC128-KDF or KMAC256-KDF is used, the object identifiers are:< /t> <t>When KMAC128-KDF or KMAC256-KDF is used, the object identifiers are:< /t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }
id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 } id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 }
id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 } id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 }
]]></sourcecode> ]]></sourcecode>
<t>When the id-kmac128 or id-kmac256 is used as part of an algorithm ide <t>When id-kmac128 or id-kmac256 is used as part of an algorithm identif
ntifier, the ier, the
parameters field MUST be absent when there is no customization label S. If any parameters field <bcp14>MUST</bcp14> be absent when there is no customization la
value is provided for S, then the parameters field MUST be present and bel (S). If any
value is provided for S, then the parameters field <bcp14>MUST</bcp14> be presen
t and
contain the value of S, encoded as Customization.</t> contain the value of S, encoded as Customization.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
Customization ::= OCTET STRING Customization ::= OCTET STRING
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="kdf2-and-kdf3-with-sha3"> <section anchor="kdf2-and-kdf3-with-sha3">
<name>KDF2 and KDF3 with SHA3</name> <name>KDF2 and KDF3 with SHA3</name>
<t>This section specifies the conventions employed by CMS implementation s <t>This section specifies the conventions employed by CMS implementation s
that employ either the KDF2 or KDF3 functions defined in <xref target="ANS-X9.44 that employ either the KDF2 or KDF3 functions defined in <xref target="ANS-X9.44
"/>. -2007"/>.
The CMS KEMRecipientInfo structure <xref target="I-D.ietf-lamps-cms-kemri"/> is The CMS KEMRecipientInfo structure <xref target="RFC9629"/> is one
one
place where algorithm identifiers for key-derivation functions are needed.</t> place where algorithm identifiers for key-derivation functions are needed.</t>
<t>The key-derivation function algorithm identifier is an object identif ier <t>The key-derivation function algorithm identifier is an object identif ier
and optional parameters. When KDF2 and KDF3 are used, they are identified by and optional parameters. When KDF2 and KDF3 are used, they are identified by
the id-kdf-kdf2 and id-kdf-kdf3 object identifiers, respectively. The the id-kdf-kdf2 and id-kdf-kdf3 object identifiers, respectively. The
key-derivation function algorithm identifier parameters carry a message key-derivation function algorithm identifier parameters carry a message
digest algorithm identifier, which indicates the hash function that digest algorithm identifier, which indicates the hash function that
is being employed. To support SHA3, the key-derivation function is being employed. To support SHA3, the key-derivation function
algorithm identifier parameters contain an algorithm identifier from algorithm identifier parameters contain an algorithm identifier from
<xref target="sha3oids"/>.</t> <xref target="sha3oids"/>.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
skipping to change at line 364 skipping to change at line 334
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Implementations must protect the signer's private key. Compromise of t he <t>Implementations must protect the signer's private key. Compromise of t he
signer's private key permits masquerade.</t> signer's private key permits masquerade.</t>
<t>Implementations must protect the key-derivation key. Compromise of the <t>Implementations must protect the key-derivation key. Compromise of the
key-derivation key permits others to derive the derived keying material, key-derivation key permits others to derive the derived keying material,
which would result in loss of confidentiality, integrity, or authentication, which would result in loss of confidentiality, integrity, or authentication,
depending on the use of the derived keying material.</t> depending on the use of the derived keying material.</t>
<t>When more than two parties share the same message-authentication key, <t>When more than two parties share the same message-authentication key,
data origin authentication is not assured. Any party that knows the data origin authentication is not assured. Any party that knows the
message-authentication key can compute a valid MAC, therefore the content message-authentication key can compute a valid MAC; therefore, the content
could originate from any one of the parties.</t> could originate from any one of the parties.</t>
<t>Implementations must randomly generate message-authentication keys and <!-- [rfced] Should "k value" use the uppercase form "K value" per the
one-time values, such as the k value when generating a ECDSA signature. parameters to the KMAC functions defined in Section 5.2?
Original:
Implementations must randomly generate message-authentication keys
and one-time values, such as the k value when generating a ECDSA signature.
Perhaps:
Implementations must randomly generate message-authentication keys and
one-time values, such as the K value when generating an ECDSA signature.
-->
<t> Implementations must randomly generate message-authentication keys
and one-time values, such as the a per-message secret number (called the
k value) when generating a ECDSA signature.
In addition, the generation of public/private key pairs relies on a In addition, the generation of public/private key pairs relies on a
random numbers. The use of inadequate pseudo-random number generators random numbers. The use of inadequate pseudorandom number generators
(PRNGs) to generate cryptographic values can result in little or no (PRNGs) to generate cryptographic values can result in little or no
security. Instead of brute force searching the whole key space, an security. Instead of brute-force searching the whole key space, an
attacker may find it much easier to reproduce the PRNG environment that attacker may find it much easier to reproduce the PRNG environment that
produced the keys, and then search the resulting small set of produced the keys and then search the resulting small set of
possibilities. The generation of quality random numbers is possibilities. The generation of quality random numbers is
difficult. RFC 4086 <xref target="RFC4086"/> offers important guidance in this difficult. <xref target="RFC4086"/> offers important guidance in this area,
area, and Appendix 3 of FIPS PUB 186-4 <xref target="DSS"/> provides some PRNG techniq
and Appendix 3 of FIPS Pub 186-4 <xref target="DSS"/> provides some PRNG techniq ues.</t>
ues.</t>
<t>Implementers should be aware that cryptographic algorithms become weake r <t>Implementers should be aware that cryptographic algorithms become weake r
with time. As new cryptanalysis techniques are developed and computing with time. As new cryptanalysis techniques are developed and computing
performance improves, the work factor to break a particular cryptographic performance improves, the work factor to break a particular cryptographic
algorithm will reduce. Therefore, cryptographic algorithm algorithm will reduce. Therefore, cryptographic algorithm
implementations should be modular allowing new algorithms to be readily implementations should be modular, allowing new algorithms to be readily
inserted. That is, implementers should be prepared to regularly update inserted. That is, implementers should be prepared to regularly update
the set of algorithms in their implementations.</t> the set of algorithms in their implementations.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is asked to assign one object identifier for the ASN.1 module in < xref target="asn1mod"/> <t>IANA has assigned one object identifier for the ASN.1 module in <xref t arget="asn1mod"/>
in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)" in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)"
registry <xref target="IANA-MOD"/>:</t> registry <xref target="IANA-MOD"/>:</t>
<sourcecode type="asn1"><![CDATA[ <sourcecode type="asn1"><![CDATA[
id-mod-sha3-oids-2023 OBJECT IDENTIFIER ::= { id-mod-sha3-oids-2023 OBJECT IDENTIFIER ::= {
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) mod(0) TBD0 } pkcs-9(9) smime(16) mod(0) 78 }
]]></sourcecode> ]]></sourcecode>
<t>IANA is asked to assign four object identifiers for the HKDF using SHA3 algorithm <t>IANA has assigned four object identifiers for the HKDF using SHA3 algor ithm
identifiers in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) " identifiers in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) "
registry <xref target="IANA-ALG"/>:</t> registry <xref target="IANA-ALG"/>:</t>
<sourcecode type="asn1"><![CDATA[ <sourcecode type="asn1"><![CDATA[
id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg TBD1 } id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg 32 }
id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg TBD2 } id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg 33 }
id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg TBD3 } id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg 34 }
id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg TBD4 } id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg 35 }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name>
<t>Thanks to
Daniel Van Geest and
Sean Turner
for their careful review and thoughtful comments.</t>
<t>Thanks to Sara Kerman, Quynh Dang, and David Cooper
for getting the object identifiers assigned for KMAC128 and KMAC256.</t>
</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="ANS-X9.44"> <reference anchor="ANS-X9.44-2007" target="https://webstore.ansi.org/sta ndards/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="2017"/>
</front> </front>
<seriesInfo name="American National Standard" value="X9.44"/> <seriesInfo name="ANSI" value="X9.44-2007 (R2017)"/>
</reference> </reference>
<reference anchor="NIST.SP.800-108r1-upd1" target="https://nvlpubs.nist. gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf"> <reference anchor="NIST.SP.800-108r1-upd1" target="https://nvlpubs.nist. gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf">
<front> <front>
<title>Recommendation for key derivation using pseudorandom function <title>Recommendation for Key Derivation Using Pseudorandom Function
s</title> s</title>
<author> <author fullname="Lily Chen">
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date year="2024" month="February" day="02"/> <date year="2024" month="February" day="02"/>
</front> </front>
<seriesInfo name="NIST SP" value="800-108r1-upd1"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/>
</reference> </reference>
<reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nis tpubs/SpecialPublications/NIST.SP.800-185.pdf"> <reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nis tpubs/SpecialPublications/NIST.SP.800-185.pdf">
<front> <front>
<title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and Parallel Hash</title> <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and Parallel Hash</title>
<author> <author fullname="John Kelsey">
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<author fullname="Shu-jen Chang">
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<author fullname="Ray Perlner">
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date year="2016" month="December"/> <date year="2016" month="December"/>
</front> </front>
<seriesInfo name="NIST Special Publication" value="800-185"/> <seriesInfo name="NIST SP" value="800-185"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/>
</reference> </reference>
<reference anchor="RFC2104">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>HMAC: Keyed-Hashing for Message Authentication</title> 104.xml"/>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="M. Bellare" initials="M." surname="Bellare"/> 279.xml"/>
<author fullname="R. Canetti" initials="R." surname="Canetti"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<date month="February" year="1997"/> 652.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<t>This document describes HMAC, a mechanism for message authentic 480.xml"/>
ation using cryptographic hash functions. HMAC can be used with any iterative cr <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
yptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared 869.xml"/>
key. The cryptographic strength of HMAC depends on the properties of the underl <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
ying hash function. This memo provides information for the Internet community. T 912.xml"/>
his memo does not specify an Internet standard of any kind</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 017.xml"/>
</front>
<seriesInfo name="RFC" value="2104"/>
<seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<reference anchor="RFC3279">
<front>
<title>Algorithms and Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="L. Bassham" initials="L." surname="Bassham"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="April" year="2002"/>
<abstract>
<t>This document specifies algorithm identifiers and ASN.1 encodin
g formats for digital signatures and subject public keys used in the Internet X.
509 Public Key Infrastructure (PKI). Digital signatures are used to sign certifi
cates and certificate revocation list (CRLs). Certificates include the public ke
y of the named subject. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3279"/>
<seriesInfo name="DOI" value="10.17487/RFC3279"/>
</reference>
<reference anchor="RFC5652">
<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="RFC5480">
<front>
<title>Elliptic Curve Cryptography Subject Public Key Information</t
itle>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="D. Brown" initials="D." surname="Brown"/>
<author fullname="K. Yiu" initials="K." surname="Yiu"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="T. Polk" initials="T." surname="Polk"/>
<date month="March" year="2009"/>
<abstract>
<t>This document specifies the syntax and semantics for the Subjec
t Public Key Information field in certificates that support Elliptic Curve Crypt
ography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Al
gorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certif
icate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5480"/>
<seriesInfo name="DOI" value="10.17487/RFC5480"/>
</reference>
<reference anchor="RFC5869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
/title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2010"/>
<abstract>
<t>This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
g block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is co
nservative in its use of cryptographic hash functions. This document is not an I
nternet Standards Track specification; it is published for informational purpose
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC5912">
<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="RFC8017">
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="November" year="2016"/>
<abstract>
<t>This document provides recommendations for the implementation o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference>
<reference anchor="SHA3" target="http://nvlpubs.nist.gov/nistpubs/FIPS/N IST.FIPS.202.pdf"> <reference anchor="SHA3" target="http://nvlpubs.nist.gov/nistpubs/FIPS/N IST.FIPS.202.pdf">
<front> <front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</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="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="202"/> <seriesInfo name="NIST FIPS" value="202"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
</reference> </reference>
<reference anchor="DSS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/N IST.FIPS.186-5.pdf"> <reference anchor="DSS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/N IST.FIPS.186-5.pdf">
<front> <front>
<title>Digital Signature Standard (DSS)</title> <title>Digital Signature Standard (DSS)</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="2023" month="February" day="03"/> <date year="2023" month="February" day="03"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="186-5"/> <seriesInfo name="FIPS PUB" value="186-5"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
</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-20
2102-I/en">
<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-20
2102-I/en">
<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="RFC2119">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 19.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 74.xml"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IANA-ALG" target="https://www.iana.org/assignments/sm i-numbers/"> <reference anchor="IANA-ALG" target="https://www.iana.org/assignments/sm i-numbers/">
<front> <front>
<title>SMI Security for for S/MIME Algorithms (1.2.840.113549.1.9.16 .3)</title> <title>SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)< /title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA-MOD" target="https://www.iana.org/assignments/sm i-numbers/"> <reference anchor="IANA-MOD" target="https://www.iana.org/assignments/sm i-numbers/">
<front> <front>
<title>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9 .16.0)</title> <title>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9 .16.0)</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-lamps-cms-kemri">
<front>
<title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cry
ptographic Message Syntax (CMS)</title>
<author fullname="Russ Housley" initials="R." surname="Housley">
<organization>Vigil Security, LLC</organization>
</author>
<author fullname="John Gray" initials="J." surname="Gray">
<organization>Entrust</organization>
</author>
<author fullname="Tomofumi Okubo" initials="T." surname="Okubo">
<organization>DigiCert, Inc.</organization>
</author>
<date day="6" month="February" year="2024"/>
<abstract>
<t> The Cryptographic Message Syntax (CMS) supports key transpor
t and key
agreement algorithms. In recent years, cryptographers have been
specifying Key Encapsulation Mechanism (KEM) algorithms, including
quantum-secure KEM algorithms. This document defines conventions for
the use of KEM algorithms by the originator and recipients to encrypt
and decrypt CMS content. This document updates RFC 5652.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</abstract> 629.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-kemri-08 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
"/> 86.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
<reference anchor="RFC4086"> 02.xml"/>
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC8702">
<front>
<title>Use of the SHAKE One-Way Hash Functions in the Cryptographic
Message Syntax (CMS)</title>
<author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/
>
<author fullname="Q. Dang" initials="Q." surname="Dang"/>
<date month="January" year="2020"/>
<abstract>
<t>This document updates the "Cryptographic Message Syntax (CMS) A
lgorithms" (RFC 3370) and describes the conventions for using the SHAKE family o
f hash functions in the Cryptographic Message Syntax as one-way hash functions w
ith the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digit
al Signature Algorithm (ECDSA). The conventions for the associated signer public
keys in CMS are also described.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8702"/>
<seriesInfo name="DOI" value="10.17487/RFC8702"/>
</reference>
</references> </references>
</references> </references>
<?line 522?>
<section numbered="false" anchor="asn1mod"> <section numbered="true" anchor="asn1mod">
<name>Appendix. ASN.1 Module</name> <name>ASN.1 Module </name>
<t>This section contains the ASN.1 module for the algorithm identifiers us <t>This section contains the ASN.1 module for the algorithm identifiers us
ing SHA3 ing the SHA3
family of hash functions <xref target="SHA3"/>. This module imports types from other ASN.1 family of hash functions <xref target="SHA3"/>. This module imports types from other ASN.1
modules that are defined in <xref target="RFC5912"/>.</t> modules that are defined in <xref target="RFC5912"/>.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[ <sourcecode type="asn.1" markers="true"><![CDATA[
SHA3-OIDs-2023 SHA3-OIDs-2023
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-sha3-oids-2023(TBD0) } smime(16) modules(0) id-mod-sha3-oids-2023(78) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,
KEY-DERIVATION, MAC-ALGORITHM KEY-DERIVATION, MAC-ALGORITHM
skipping to change at line 950 skipping to change at line 774
maca-hmacWithSHA3-224 | maca-hmacWithSHA3-224 |
maca-hmacWithSHA3-256 | maca-hmacWithSHA3-256 |
maca-hmacWithSHA3-384 | maca-hmacWithSHA3-384 |
maca-hmacWithSHA3-512, maca-hmacWithSHA3-512,
... } ... }
-- --
-- Key Derivation Algorithms -- Key Derivation Algorithms
-- --
id-alg-hkdf-with-sha3-224 OID ::= { id-alg TBD1 } id-alg-hkdf-with-sha3-224 OID ::= { id-alg 32 }
id-alg-hkdf-with-sha3-256 OID ::= { id-alg TBD2 } id-alg-hkdf-with-sha3-256 OID ::= { id-alg 33 }
id-alg-hkdf-with-sha3-384 OID ::= { id-alg TBD3 } id-alg-hkdf-with-sha3-384 OID ::= { id-alg 34 }
id-alg-hkdf-with-sha3-512 OID ::= { id-alg TBD4 } id-alg-hkdf-with-sha3-512 OID ::= { id-alg 35 }
id-kmac128 OID ::= { hashAlgs 21 } id-kmac128 OID ::= { hashAlgs 21 }
id-kmac256 OID ::= { hashAlgs 22 } id-kmac256 OID ::= { hashAlgs 22 }
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
kda-hkdf-with-sha3-224 KEY-DERIVATION ::= { kda-hkdf-with-sha3-224 KEY-DERIVATION ::= {
skipping to change at line 1053 skipping to change at line 877
kda-hkdf-with-sha3-512 | kda-hkdf-with-sha3-512 |
kda-kmac128 | kda-kmac128 |
kda-kmac256 | kda-kmac256 |
kda-kdf2 | kda-kdf2 |
kda-kdf3, kda-kdf3,
... } ... }
END END
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Daniel Van Geest"/> and <contact
fullname="Sean Turner"/> for their careful review and thoughtful
comments.</t>
<t>Thanks to <contact fullname="Sara Kerman"/>, <contact fullname="Quynh
Dang"/>, and <contact fullname="David Cooper"/> for getting the object
identifiers assigned for KMAC128 and KMAC256.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIADRZRmYAA+1d6XLjSHL+X09RVv8QFUFQvKSWNJ5dUyS7xdW5IjXbExtr
B0QUJaxAgIMCpeZqtM/iZ/GTObMOnAWQUqvH47A7pqNJoI7MrMwvj6riWJZF
eGT7zn/YXuCzIxqFS0bcRSg+8ajdbB4228QJpr49h9dOaM8iy2XRzPLs+YJb
0zm3+L3dse5tfm81u2RqR0eURw5ZuEeE0iiYHtHtFePb8IUHYRSyGU89Wc3T
DyI38mCW7RvOaDCj0T2j45Neh176zHqyV/QEJqGflv40cgOfU9cXTfrhahEF
d6G9uHen9Jxxbt9Bx5Uf2V9prX8+3tkm9u1tyB7F0K5/J0d9cqN7OcD5eJvw
5e3c5RwGnqwWQMRoOPlE7JDZR3RrzKbL0I1WW+ThCd74EQt9FlkDlAZx7Aia
t5vtrtXcs1r7hNjL6D4Ij4hFpdSul5zTk2DJPbYCpoPw7oj+5N65HtUD1+nZ
WR9eaTKzb+HFFP45oicwrxP48D1kd0ApNOzhy2DpRyG8v/HdiDl0HAFJHCXY
m7PQndrQhs1t1zui95KKf3vECTibNqbBnBDXnwXh3I7cR4aLNupd9Kze2Wf8
DDQpbqj4I4jHBuK7WrCt8fkoppbCWOLvePd8dD6kPe8ugOf3c05rrUa7cdBt
Nlqtzl73sNFqwN/9RmdnS45mh3cM1Oc+ihb8aHf36emp4dq+3YBJd21Ymzt/
zvyI7/K5a/nL+S0L+a6m9/xy8A30KlrPA2fpMTpyYBp35rKwjOTmt5JsDRo5
M3pg81DYzPWnfrd5sK8+HnxstvEj8dNL1LsYW18OG91uKc9q6X16YaO12B6q
he/YocNBgzlIYhmxtFD+oHpfLW89sKNTtkpblhQTWssn17f9qYsDsvDRnTIc
zwGwCFcU4EQOgr2HgCwwFL9HCVBpeGg7dyDWT/Y0Aq34h6AtM48YQNtU86P4
yoEVxlFLNYvl3B1RIRdodzEaTxrjq8ZBs2m1mgdhy1ounNaRcd38R2+xvOUN
3+VR4y543MUP+GR3vGDIrJSKmIzvmkduLJxZRsuuGVgXMO9ILlGADyAXB0h/
lI+WQigLzpZOEAL9wZzONLxtFVbWkisbsxwvI5p6srrwL52w6b0feMFdVp6I
UW34r0SqyBdVDNMUx0c0y2lJ98Hl6Ii2mo39ZvugREb5ZTnYe/f1ONgrLATA
vdWhA5Q7wGPsQI7oFN6cDuv09LzXr9PJcuEx4WNQhFd2aHse8/DB91iL1r7V
euNCHOytlbhoAvDRbjW7Ckk67Y+H6uPe/l5bf+weNPXHg/24wWFLNzhotj7i
R/SZxcWqXKtPo6uxJAs/NUD/8kuzLZcmMd4rFs6XkWDWOrY5LFe8IMOvEdrS
rcesyyVMECUruf091mfPah6UrM8W8kOvbo63QLuArS0KLwbj8WuVOSeg1sG+
VdDe7QH46ggRDpyJHS1DFtNPazDnzvdgvt0RQNHZhH9B9VZaI7cyKpmwho2+
NPalwpU4z2jZcP1oN2TT3Yl1PexbooPJUY101AJAGsVsJD6odws+CfyMDgUv
AqlXGE7SWm980WjtaIaErc2UlaGUbm0OTtBXXcokPJrcWJOs4Frl8Cpa06xX
OKIJf9BifLk7GvbBzA8AqltHOJ6U2eFvJDOUCmX+NHDQM4UQDQFMFqRzLKQz
1M2usRmtHQ+vd+pqoL7tBz708Aqt+tBKqN4ArACeLyFCADPPNxtAs+8s9kOT
2Pe02IllWRCQSx0iZHLvcgqJ0FJEMw7j09C9BUIxJJoG/iNGjJiUoJeXbh3f
BCpzwfQoce1EZS4iDZnZc9dbpbKRtelMg9KJ6k1UbwyFbhlMDJK0wbLpXPVz
3DvGI2rrILyOrxd2GOEy2pRrTCFlLfRAuAzIo1ICWCxWh9VItYTYhqRiG81t
Q0py7jqOxwj5gDFgCHG2eEmfP7j49QUFvAnv9PlZ+a+XFworIjiOAuQTQRJE
gSzVieS7niZb0gu6jZNQO7x1YWkhaNUcwipGGKsL8bqc8IzWZ1d8mWSos2AZ
lqyzylBJep1r+MVqt7t1Kj/t7atPnQN4hoYhvu212sgsfgZOtXYQkEEDzZja
juPiJHV4DHLYjFguySUl5MY6eD3ujcc9enXaH39o0UdIWnDUVmPPpDBySTBM
AEKRfhxh6HnuAsRO+8vwkdGiD4vTQlIb9gfjHjIL3izFK+blYj7mWGC1tl4g
GkGC3shbJIfU1nMQsdEQoOlMqIYYDMijmEcpSuHTy0udPoGO3YOoZq7POCm3
YWWpp0O9hOhEcYluRXzCMCzhLoQlNBBhCTEIFJcNdP+DBFiCy0gfbW8JK2SD
MO6Yz0Ibc3c5rYTh52eB40hrQo2AXmKC3lj264FVDn0IQ0uqJhB1uSoMEIaI
ecpTgEHC1vnNeLJVl//Si0vx+Xr455vR9XCAn0EUZ2fxB6JajE8ub84Gyaek
Z//y/Hx4MZCd4SnNPCJb572ft6QdbF1eTUaXF72zLWlI6eVGqYHZw1K7WI5Z
hCwS0Ee06jvY57h/9V//2eoCu/8iYuHWIeiX/HLQ+thFZQN0kLMFPqKw+ApC
XBF7sWB2iKMArADALlCBuUBH0LUnn96zENTwX//ogf5Qa/+PfyCIbhq0BhJ4
U9WP5w9YKQtchwPaXZotENmCWQIashkLQ4ltMGMZnPOGNAPOJJwqGDD4JTZf
eMEKBrxdCcNy4TtDUcocikT3NhjRcrEIAM83x6gYokCRBjniqBvXUSRnXjAV
Sq7dn7DtAZq25CsRFoFOnlNPmoUYueSb0VQrObl5OD2aNpBeyikYO8iBE5ZS
pprjwTCt7BxPphQilk56bmpHESgrROZ5UHcKE7s+pjxRQGIIzqgBecWaLYT/
1XilJ0GwImIA0Tfuhj3AV4Lqhwz1C2tQ3koFIcHt3+FJZqUBPUnia8pco9B0
bOx5wRM/IuSf//wnPPAborqAjWE1OL08/tOwP6GjwfBiMvo0Gl7To6Mf6TP9
ewB2b7k8sCD6taIaOEtVBq219ndUXAewWTvoNncwarR9VW2qtXYoJGG1VhM+
THkQ1jo7FDOyePVr3R3apmCkMILryPo2yKWUlpjYj/lOe/vrOx3kOoHc13c6
zHXCNVrbqdWEXiBmQv4CKpjyKSkm6/EXLrQgRZUIn1ITEqOhS2uEqNCeAySj
OghrEN4D0BoCamj6g/DTFzfgL0D51UN0RaYAgZPvgnFx7Cais1dFRMQYEdG3
RETEwDB9a0Q0NpCyCQYLcE1wJQeDIt6JoRrsvgcOqm7im2w8GS2bjMBkwpBR
wvEEGiV5hslyVDZNFDNDKpnZZFBSHHQN0RBj5WJqVB2xriKNE0GXoQWGPCJA
FVSk1AooF0Zs7ENE6Otilub/XemynAzUPLOzZlZ7YcPEAO0glTxSX44GAmcK
6CPwCcTxPwrjnQQnQ26DI7YWD1Pesh5b1p6FEkmhu2LkOSa6tWlvhPli7+5m
vQXeF3vvbdZbAH+x975GetQrExiIHMegPHwpV30hd4EgDxDViikLI5legm0k
6WZKLbG6jJkKwp0bYZuQQQCN9oOBsogKJFa7kIIX1Ah4HMrMXFToStQFFAXX
fc5wI826DZwVaExeS2Aoh7s1uWG3Q1Fs2An/tVr4qZVxg2gLmdnrG2hLnazX
ibVtdIS1rh2usXENVf2jTmKdT+1cml0wegwb1gx9b6NMAtWzaX+Y0pE6kck0
NJkG80WA8COrR7ihupSlZlt3YF8XgDt+VI+jAlFwZA5JQhIYX+574E4iujeR
d5VonY5FZTgLCC9yxbiKiVTZYegmUJ5SZ4PGy+GIAF5XlzwzBJm0m1Zod6Yz
qvIYEujhRX9In5X2akGNLibDz8PrOrUs6qt3krKhkppuQl+wDUtpMvoe4Lde
DFiUbRvCA115gCUiKHxPeUCdLNkqPYhrbY4bgrQgVbZl/JXznNLXifgl7942
LwnFAVDG/REVDmnXJyfRdG3g7UrKXlJem3m735E/Y1MHACPnw0rI0mQfVnSv
yFVit9Is71+VtsT9W+X9qzKYuH+7PIExiKNewqcAZgP9ynmZaTMnO+RVyQ7N
JDsTw86B1OmU80X9NiIf7ttq5CPD/lVCAziSYOoKbIoTh/y4GghFMhFykgZE
Ucej9mIBRh4FohnkO5n9n4zhN0zwIyc04Uz0FKggWxLPdcyNp63QfcxFJS5X
AAvF2oguAWU2xzpsFNo+h1aqsg0DEx29c2H7MYmypBevS2qXKy65RkKMQLQF
gGT9JDAvH3pLbyMoeVVwkx/X6AGAxRj99SNOE7SXip8UGHvZDZk+8MIVLyfn
vX5c8fl+2bOYRggGTxnoPFXkFRW7RrQG3XZAaQSRm+aphZIdmdvTYr0OxyzP
4Ip1Pxgk7iuUWPD02/qU30WtiypYvgeJ/AVe6GriBlWllE/K9t6k+pXOkjK9
NyqDpbOkTO/N6mH7hUTAIIG6iTHhQvL0xv6jQIqpQpKNp9f5EGL2IR/ESbtB
susaH4lRG6pgx6fD82uw+QVAUyRLIlG4nIqI6/m57CCi3F1FZV949pThxkhm
zy9X8EWfYhk2f6UZ+owB0MrQ8OR08CkbGabASZ6Y5LIuZ55MoJDa7s4hFskh
FjUiltq2G34VG/sWLJkFoTWuXFaURIuS1pBmvfN8sH+Yrsilt3YBFrIoEIMK
8vzbggpoIcjv+yXShzV4wufunCEGpeNSmNa6f3BmG4amitDJ8aBVPUYFmiRj
tCvHqMKUZIxqXqqQJRmjm0GWUqnUy5kVCGPmQRfiS6hLFI3Y5lT+2yDngzgu
2WofWKjWwnDgO5CM39832pCNKAP6ZZinp0YJqFnleZfcwVptM3JHOI7ixoqs
bqOL9vb8bD6lKnYz9UwpBgWY5ULx3KlLDMknyZkLNQjJDFJJb5iEnTZui/2B
pKUNolVfa6d1+qVOz+p0jMGUbKYWQTeDr7lmk+y6q/DexGoGwSUd5Ej6SLER
mQP8uGxCPebfIaQB87FGeRAOIhr7tP3v7Wa3KQj+osYTmxhfI30gQ1WopMbI
SH0AFhZXc2Bg0JfL6xG4HXBtl6gawq09aSeeRlsBr1VuTpBypkhRFSTJQh0X
GDc+gbGzmJW7EOP+UHKD54l+WdoeCrIp3f9ZNdNjPdNCnc2cLnkUzPVJeM++
ZV4dfBYIAvRkC1jZorXm1+5xt9vd3ymIeFw1GzY9TZYbZfLg48kFTKk8T52s
c/8BYsJTXGClP6jSbTCLlCzVkRZRzANpg3+c2osaRJkLTOfweJck6Ut2HnDk
4Fo8GHkWBnMqNqvQogm8E2nb3I0iafxiltC9cyFVC0I13Fl2OAc/zIVRyB6E
A9naZapVAxVE/Zjj8ri2p0/JZUfSclex2oxIhhdh8Og6JoLqSiQLZCnOJArY
KYqOUvVMiKsjgbQtJxBmpTT2f23m8ABBL4LI2rC7nXL02GmjPKHdNsXqek7p
D/Vg2vbT5xgrHCFZ4whjYAlFFdQPTDZLxbE8nGhF4oJprFXiipGYrER99IyL
kIkpcVdAl+pFAUYMiQZfj+sWwF4/TUgjpx2Zl3KPrj8ZTuh4cj26+KzKCR9Q
ZdsS+QefOqWR+fs7cpwWTQBnTZxNpuQS33JCmH6fdIak0pmSDGPzdEadlDO1
LN1CQa+RN24RHsQeIVEOXenOLhGSECPFSp4N0kPhKhBtHBAZwt+2zkrV944B
XExHe8irOEtpNO61rJKTwyR/Zi1jf2rfyHfU3iLSnsl6YrdxyxDdtbbJQmD6
vJoEzhKijZlrhmhlbCVAIdwYeX6OT/C95K3t66HVrcguZL6VrJOVAdtOjMXR
dP+g1up0MkANg0uE/noY397A/EvMWesCEEtAFd8tsQOHO0XlfkESmzRE2hJM
1npT2Ts9DbY2DdF51RAddE9xmTO+ntkHswO5hQpOyCiX5M8B5hBpI9TppKa9
jfCLasBUbNqHyWAR3fgwNDE1pAsMNICguc1/WcKsDta3185pjIaLMxabxfMF
iIwiIhcN5LFjR11Zy4U2erv1SRx5BtNdehEiphdwLs+i+DOparYnbhfjGdk7
edEYwC1blK1DgrRgvoyt/fzp9hIKdDwzD/AcLkadWNZXUSQFKwklAxzsSwOB
lSsGi31jERnKaCtfLBa+NsJQErAdDb7nr8QUK1nYwVhWAAYpn0BUilDN8PKT
jW7UBWeLl/2EP58Fik51kAp8LkpUR39MRq/g09MVGsVlmVrIe5zeKt7yqOBf
bIyLak/kzvU+SBL+C81Svl8EIWpIXAlbbbGktmFytwLiY+Vq00bu/uxmlN12
Q9zK9nDVENqJuoWqriqrGFrpA4jEwXQHOssrq1amtZ4uCDmpXV1ffOY7qM6x
GKaZyx2qSo/rk1JgyArwHH0IK0+4QgBxNJZHzBZnCm5DXEpYOPDinNnh9F5v
Aj7dB55kiy/Ax2OET+wosqcPQNvcXkGoJc+mzFG8uIeEoQgetdbnYXEUJBxC
rEc3DMTVbel/VAtHGzuPDxP7igp5ikJwggTxOWZYnInjCAuwS/fWBe5cveuV
WxtMIhHssuLHo1yOO5u5Uxi1IW5jUrwaLkuR+AnimmA2E03n6AltIPhu6Tq2
P2XxoXn8FYO6iDF6C2HpX2kHJ5WX+Ja3FC/ndePThipqBTMO5koe4qqY+8sy
q/U4rbp2gcHykzR6LM9mVjo5pQzNpjjmE7NhTYgsooLio22DsbMn2dOGKGjF
MVOMp1V1EYhOIPGUZ6ulVYOsCUCouNUmeEbIfWSqVvoUhA90Ju6ai9sCIIgH
PIeCFgwytcMsqako4cmF5QPYgUWXCybBol7GW6H2nAhGHO2wsZ7tBU+oG8ho
SijyGgOQ5rjeirg+Z2EkAxyUpQusuGaJQ7IAnMgt0pDd4SQAO8sFXooTQaBU
v/RcMp1ww3yULrYS8GcSiu4WH4qM/kFvxiLkSEDMB5LxjwTIus1c/pyCiOUh
UGrB95cXfflt8x9hKP3hCPwVBvwlDPHbA3/VPwPxtyRN1qVwmFjWRzF2s/B6
a1lkouIwY318TWFcn9YxlMdh/hr0mxwP4iPYZXKVZ+aNp+rlFgbWCpbJr5iY
D9+uk/FmP8oRyxYSK/WbIC8vRen+f8U/XfH/QHtTDE085twJC+Pk+UghOnN+
3PKDLXHb0fYf0PbJANIA5tGfwBF+ZiJRgpBgzODrZBmCjyBq5cFoIbNisyXi
0qOLGCI8ULC8u4/wqbzfGvFGanQ6hhSHnjJExzr983Ll31OY8E66r4ENQA8W
j8U8Mc0di6L46qqhBMXl4XOhSYaisbrqeQsuV8hBeZuGvlesLPv5gwYDs2RS
ZQdDMViBirYHcw6fGAgp25xLbi7J+54xWglHysWhQy4DQBGbq6t7spXaW0xX
6+ODOYetdjE9FFvBl6OBRB8JFSXbcBvvv8WnRNI4g8Qh1hhRr4YIpPO0wfDT
6GKEN+zGdHR+dTbqjyZ00vs8Rt3GBsfDz6ML0XT45eryejKmvbOzH8QDaI8P
8KOkwnAC9fmlTgejz8PxBIHj8no0OTmv0/Ho80VvcnM9TD2UQ5wOf7YGw+vR
Tz2kqY5hetJGNvl0fXmemiq5zG7hL1VRPBD5V7UEf9PS2SD5pg7gM4jPVb/s
lIA5SlfBZ20PF2oKluXyOcdviwf3a+2jFjUIPemkpG+bSG22a3sHehHo3LFx
kVp1GA5PAYt/2bSePzREYv6vTkdfsCZazvM3svwWjhXD2KCVsM2BxAPB8H6e
YbH7qT/jTSP1Wexvqs976gdSYrZb1tV4bF32hldW4sF+v3IIxYluG9cKZYB1
Ggr2g43lLy4AzT3Ptbl6suY+RabfpYTn1IHvXjhND5Qp1qfuCLzznoA+v5Ps
RcQzZSnQjjo+QlvSrpMuZqVarV/KuHammXiXElpMQGXRTBy2yNNqxvX4vN8r
j1dklr/0mnFKAzJ3F2Paqm8rFpsZ7ycWmxlvJBabxUeItbkL6vJuIhOLp6Ou
FEv67VXvuncOrul6qPdr8hMAX6+fYG9/4wlQIq+eADptPAHK8tUTaPCsmOBE
rooyPBzQ5MaLTjzxc/k/z9kxOQCeYSpu5iZhJ6McvxafwooWn+IyFJ+CGGJ6
G41GwZCMF04zNvR/7uJY1QWDQo91VwqKU6y7RFDsse7aQLFH7GxsFELmQKsh
AK2ypTWrnzOxyc9XQ3lmCo0tZL8sXUhtdKOT3vhkOAY6M/r9Eo9xcwxBuAVx
MLaR4WDydoyJu9XvXcHLmMQBPf6Zps1xA319KZENrNZ7yqYAoK+Wzd7+N8vm
NaLB6cyiQbV8R9EUof+1okGCfkPRiOnMokH7e0fRFJ3Wa0WzJ2z/NxONmC4R
jYCnb4EbA+jqhj/1zm6GxrSQGlz8WzGHTTeBnBL3UC6J14OLwZu8uyQqEebt
ksgiSVYSb8ASg5d8b0lUA8qbJZEDjqwk3gAdBu//3pKoxo83SyKNE+PUb1+U
R93lhTLTn+fMqDLuLm2cJ4KvXwdDIPVr2bt0dG7wpGXvUETpd0UsrXibm7No
c+VvixmCEpEx4TZdu8vmC8UrVIY0uPLSlKF95TUpQ/vKi1GG9jruh7Z2kYNM
KbbKQPM91xrgaIzWNRxYeO9ucn0z3Mi6CgS+lJMPAn0j+RUlgPckP+UtiuTj
+r6N/KoCwzuSn4b4Ivmobm8jv6p88Y7kp3EZRtmgGpJhpxSRnzOjceMcvEo0
ZkP8teJ1pihiVKSK1+vKJLlrhmW1krKt4KQy+prNX0OvDbZ7Db022OA19Eph
bny4vQidpuPsxnYp0pMjltnq8oaHKis7qWOU2OkBghrDamQ32qos0ryca+0S
9OUi0EcNpvYiOdYNb8pJA8F9G2kbAPbbSEO9+ibSNgHjt5GGyvtNpG0CtBuS
pq1kc3pUD1POn72+gDTpE/IpqlQH8WOSqcsa2b4up9vbJ8mPnL+Gndcpperx
O2UHAecVvCiMMjGDFxIsLOnHd6RNxZnN6eq8nq5OCV2dd6Frzd0ZbFKUQUnI
QF+1g4J/nouDJxGE4VXl3tCXw2xrPbfy8nLEzvfkpFPOSf7VN3KSb7Fm10yf
vShsG5m2nYybToYtp0wa+303sqj4Hy0lYVlm/czRa+6QTfXq6SXEOR7jskI8
rXxUZbklAcivVe/TIilxxVXvM+JPO6XCw8JMAiDzTzoGoQ8vBuKs3/MR5cEy
nDK8kGfN7fCBhfzHbfyf6G2/kP8GlEDSHl1vAAA=
</rfc> </rfc>
 End of changes. 92 change blocks. 
589 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.48.