<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 2.6.10) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-cms-sha3-hash-04" number="9688" obsoletes="" updates="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.21.0 -->version="3" xml:lang="en"> <front> <title abbrev="Using SHA3 with the CMS">Use of the SHA3One-wayOne-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-cms-sha3-hash-04"/>name="RFC" value="9688"/> <author initials="R." surname="Housley" fullname="Russ Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal> <city>Herndon</city> <region>VA</region> <country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <date year="2024"month="May" day="16"/> <area>Security</area> <keyword>Internet-Draft</keyword>month="November"/> <area>SEC</area> <workgroup>lamps</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 119?><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 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or as part of akey derivation function.</t>Key Derivation Function (KDF).</t> </abstract> </front> <middle><?line 127?><section anchor="intro"> <name>Introduction</name> <t>The Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. This 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"/> with the CMS. In addition, this specification describes the use of these four one-way hash functions with the RSASSA PKCS#1 version 1.5 signature algorithm <xref target="RFC8017"/> and the Elliptic Curve Digital Signature Algorithm (ECDSA) <xref target="DSS"/> with the CMS signed-data content type.</t> <t>This document should not be confused withRFC 8702<xref target="RFC8702"/>, which defines conventions for using thetheSHAKE family of SHA3-based extensible output functions with the CMS.</t> <section anchor="asn1"> <name>ASN.1</name> <!-- [rfced] May we rephrase the following sentence to avoid repetition of "using"? Original: CMS values are generated using ASN.1 [X.680], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690]. Perhaps: CMS values are generated using ASN.1 [X.680], utilizing the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690]. Or: CMS values are generated using ASN.1 [X.680], which utilizes the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690]. --> <t>CMS values are generated using ASN.1 <xref target="X.680"/>, using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X.690"/>.</t> </section> <section anchor="terminology"> <name>Terminology</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.<?line -6?></t> </section> </section> <section anchor="sha3oids"> <name>Message Digest Algorithms</name> <t>One-way hash functions are also referred to as message digest algorithms. This section specifies the conventions employed by CMS implementations that support SHA3-224, SHA3-256, SHA3-384, and SHA3-512 <xref target="SHA3"/>.</t> <!-- [rfced] We have two questions regarding the sentence below. a) We note that "SignedData digestAlgorithms field" is the only field name where "digestAlgorithm" is plural. Should this term be updated to use the singular form? b) Would removing "field" after each field name improve the flow of the sentence? Original: Digest algorithm identifiers are located in the SignedData digestAlgorithms field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, and the AuthenticatedData digestAlgorithm field. Perhaps: Digest algorithm identifiers are located in the SignedData digestAlgorithm, SignerInfo digestAlgorithm, DigestedData digestAlgorithm, and AuthenticatedData digestAlgorithm fields. --> <t>Digest algorithm identifiers are located in the SignedData digestAlgorithms field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, and the AuthenticatedData digestAlgorithm field.</t> <t>Digest values are located in the DigestedData digest field and the Message Digest authenticated attribute. In addition, digest values are input to signature algorithms.</t> <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 these four one-way hash functions are as follows:</t> <!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. --> <sourcecode type="asn.1"><![CDATA[ hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 } id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 } id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 } id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 } ]]></sourcecode> <t>When using the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 algorithm identifiers, the parameters fieldMUST<bcp14>MUST</bcp14> beabsent;absent, not NULL but absent.</t> </section> <section anchor="signature-algorithms"> <name>Signature Algorithms</name> <t>This section specifies the conventions employed by CMS implementations that support the four SHA3 one-way hash functions with the RSASSA PKCS#1 version 1.5 signature algorithm <xref target="RFC8017"/> and theElliptic Curve Digital Signature Algorithm (ECDSA)ECDSA <xref target="DSS"/> with the CMS signed-data content type.</t> <t>Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. Also, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.</t> <t>Signature values are located in the SignerInfo signature field of SignedData. Also, signature values are located in the SignerInfo signature field of countersignature attributes.</t> <section anchor="rsassa-pkcs1-v15-with-sha3"> <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 used in conjunction with one of the SHA3 one-way hash functions, the object identifiers are:</t> <sourcecode type="asn.1"><![CDATA[ OID ::= OBJECT IDENTIFIER sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } id-rsassa-pkcs1-v1-5-with-sha3-224 OID ::= { sigAlgs 13 } id-rsassa-pkcs1-v1-5-with-sha3-256 OID ::= { sigAlgs 14 } id-rsassa-pkcs1-v1-5-with-sha3-384 OID ::= { sigAlgs 15 } id-rsassa-pkcs1-v1-5-with-sha3-512 OID ::= { sigAlgs 16 } ]]></sourcecode> <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 here for convenience:</t> <sourcecode type="asn.1"><![CDATA[ rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } ]]></sourcecode> <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-384, and id-rsassa-pkcs1-v1-5-with-sha3-512 algorithmidentifier isidentifiers are used, the AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> contain NULL.</t> <t>When the rsaEncryption algorithm identifier is used, the RSA public key, which is composed of a modulus and a public exponent,MUST<bcp14>MUST</bcp14> be encoded using the RSAPublicKey type as specified in <xref target="RFC3279"/>. The output of this encoding is carried in the certificate subject public key. The definition of RSAPublicKey is repeated here for convenience:</t> <sourcecode type="asn.1"><![CDATA[ RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e ]]></sourcecode> <t>When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a singlevalue, and thatvalue. That value is used directly as the signature value.</t> </section> <section anchor="ecdsa-with-sha3"> <name>ECDSA with SHA3</name> <t>TheElliptic Curve Digital Signature Algorithm (ECDSA)ECDSA is defined in <xref target="DSS"/>. When the ECDSA is used in conjunction with one of the SHA3 one-way hash functions, the object identifiers are:</t> <sourcecode type="asn.1"><![CDATA[ sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } id-ecdsa-with-sha3-224 OBJECT IDENTIFIER ::= { sigAlgs 9 } id-ecdsa-with-sha3-256 OBJECT IDENTIFIER ::= { sigAlgs 10 } id-ecdsa-with-sha3-384 OBJECT IDENTIFIER ::= { sigAlgs 11 } id-ecdsa-with-sha3-512 OBJECT IDENTIFIER ::= { sigAlgs 12 } ]]></sourcecode><t>When<!-- [rfced] May we rephrase the following sentences in Sections 2 and 3.2 to match other similar sentences in the document? Original: 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 but absent. ... When using the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256,id-ecdsa-with-sha3-384,id- ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers, the parameters field MUST be absent; not NULL but absent. Perhaps: When the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 algorithm identifier is used, the parameters field MUST be absent, not NULL but absent. ... When the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, id- ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers are used, the parameters field MUST be absent, not NULL but absent. --> <t>When using the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, id-ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers, the parameters field <bcp14>MUST</bcp14> be absent, not NULL but absent.</t> <t>The conventions for ECDSA public keysisare as specified in <xref target="RFC5480"/>. The ECParameters associated with the ECDSA public key in the signers certificateSHALL<bcp14>SHALL</bcp14> apply to the verification of the signature.</t> <t>When signing, the ECDSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, theyMUST<bcp14>MUST</bcp14> be ASN.1 encoded using the ECDSA-Sig-Value defined in <xreftarget="RFC3279"/> andtarget="RFC3279"/>, which is repeated here for convenience:</t> <sourcecode type="asn.1"><![CDATA[ ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } ]]></sourcecode> </section> </section> <section anchor="message-authentication-codes-using-hmac-and-sha3"> <name>Message Authentication CodesusingUsing HMAC and SHA3</name> <t>This section specifies the conventions employed by CMS implementations that support theHMACHashed Message Authentication Code (HMAC) <xref target="RFC2104"/> with SHA3 message authentication code (MAC).</t> <t>MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm 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 one-way hash functions, the object identifiers are:</t> <sourcecode type="asn.1"><![CDATA[ hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 } id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 } id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 } id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 } ]]></sourcecode> <t>When the id-hmacWithSHA3-224, id-hmacWithSHA3-256, id-hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithmidentifier isidentifiers are used, the parameters fieldMUST<bcp14>MUST</bcp14> beabsent;absent, not NULL but absent.</t> </section> <section anchor="key-derivation-functions"> <name>Key Derivation Functions</name> <t>The CMS KEMRecipientInfo structure <xreftarget="I-D.ietf-lamps-cms-kemri"/>target="RFC9629"/> is one place where algorithm identifiers for key-derivation functions are needed.</t> <section anchor="hkdf-with-sha3"> <name>HKDF with SHA3</name> <t>This section assigns four algorithm identifiers that can be employed by CMS implementations that support the HMAC-based Extract-and-Expand Key Derivation 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 one-way hash functions, the object identifiers are:</t> <sourcecode type="asn.1"><![CDATA[ id-alg OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 } id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-algTBD132 } id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-algTBD233 } id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-algTBD334 } id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-algTBD435 } ]]></sourcecode> <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 an algorithm identifier, the parameters fieldMUST<bcp14>MUST</bcp14> beabsent;absent, not NULL but absent.</t> </section> <section anchor="kmac128-kdf-and-kmac256-kdf"> <name>KMAC128-KDF and KMAC256-KDF</name> <t>This section specifies the conventions employed by CMS implementations that employ eithertheKMAC128 or KMAC256 asa key derivation functionKDFs as 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 and KMAC256 asa key derivation functionKDFs are definedas:</t> <ul empty="true"> <li> <t>KMAC128-KDFas follows:</t> <t indent="3">KMAC128-KDF is KMAC128(K, X, L, S).</t></li> </ul> <ul empty="true"> <li> <t>KMAC256-KDF<t indent="3">KMAC256-KDF is KMAC256(K, X, L, S).</t></li> </ul><t>The parameters to the KMAC128 and KMAC256 functions are:</t><ul empty="true"> <li><dl> <dt>K</dt> <dd><t>the<t>The input key-derivation key. The length of KMUST<bcp14>MUST</bcp14> be less than2^2040.</t>2<sup>2040</sup>.</t> </dd></dl> </li> </ul> <ul empty="true"> <li> <dl><dt>X</dt> <dd><t>the<t>The context, which contains the ASN.1 DER encoding of CMSORIforKEMOtherInfo when the KDF is used with <xreftarget="I-D.ietf-lamps-cms-kemri"/>.</t>target="RFC9629"/>.</t> </dd></dl> </li> </ul> <ul empty="true"> <li> <dl><dt>L</dt> <dd><t>the<t>The outputlength,length in bits. LMUST<bcp14>MUST</bcp14> be greater than or equal to0,0 andL MUST<bcp14>MUST</bcp14> be less than2^2040.</t>2<sup>2040</sup>.</t> </dd></dl> </li> </ul> <ul empty="true"> <li> <dl><dt>S</dt> <dd><t>the<t>The optional customization label, such as "KDF" (0x4B4446). The length of SMUST<bcp14>MUST</bcp14> be less than2^2040.</t>2<sup>2040</sup>.</t> </dd> </dl></li> </ul><t>The K parameter is known to all authorized parties; it is often the output 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 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 the KDF algorithm identifier.</t> <t>When KMAC128-KDF or KMAC256-KDF is used, the object identifiers are:</t> <sourcecode type="asn.1"><![CDATA[ hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 } id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 } ]]></sourcecode> <t>Whentheid-kmac128 or id-kmac256 is used as part of an algorithm identifier, the parameters fieldMUST<bcp14>MUST</bcp14> be absent when there is no customization labelS.(S). If any value is provided for S, then the parameters fieldMUST<bcp14>MUST</bcp14> be present and contain the value of S, encoded as Customization.</t> <sourcecode type="asn.1"><![CDATA[ Customization ::= OCTET STRING ]]></sourcecode> </section> <section anchor="kdf2-and-kdf3-with-sha3"> <name>KDF2 and KDF3 with SHA3</name> <t>This section specifies the conventions employed by CMS implementations that employ either the KDF2 or KDF3 functions defined in <xref target="ANS-X9.44"/>. The CMS KEMRecipientInfo structure <xreftarget="I-D.ietf-lamps-cms-kemri"/>target="RFC9629"/> is one place where algorithm identifiers for key-derivation functions are needed.</t> <t>The key-derivation function algorithm identifier is an object identifier and optionalparameters.parameter. When KDF2 and KDF3 are used, they are identified by the id-kdf-kdf2 and id-kdf-kdf3 object identifiers, respectively. The key-derivation function algorithm identifier parameters carry a message digest algorithm identifier, which indicates the hash function that is being employed. To support SHA3, the key-derivation function algorithm identifier parameters contain an algorithm identifier from <xref target="sha3oids"/>.</t> <sourcecode type="asn.1"><![CDATA[ x9-44 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-44(44) } x9-44-components OBJECT IDENTIFIER ::= { x9-44 components(1) } id-kdf-kdf2 OBJECT IDENTIFIER ::= { x9-44-components kdf2(1) } id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) } ]]></sourcecode> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>Implementations must protect the signer's private key. Compromise of the signer's private key permits masquerade.</t> <t>Implementations must protect the key-derivation key. Compromise of the key-derivation key permits others to derive the derived keying material, which would result in loss of confidentiality, integrity, or authentication, depending on the use of the derived keying material.</t> <t>When more than two parties share the same message-authentication key, data origin authentication is not assured. Any party that knows the message-authentication key can compute a validMAC, thereforeMAC; therefore, the content could originate from any one of the parties.</t><t>Implementations<!-- [rfced] Should "k value" use the uppercase form "K value" per the 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 k value when generating an ECDSA signature. In addition, the generation of public/private key pairs relies on a random numbers. The use of inadequatepseudo-randompseudorandom number generators (PRNGs) to generate cryptographic values can result in little or no security. Instead ofbrute forcebrute-force searching the whole key space, an attacker may find it much easier to reproduce the PRNG environment that produced thekeys,keys and then search the resulting small set of possibilities. The generation of quality random numbers is difficult.RFC 4086<xref target="RFC4086"/> offers important guidance in this area, and Appendix 3 of FIPSPubPUB 186-4 <xref target="DSS"/> provides some PRNG techniques.</t> <t>Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should bemodularmodular, allowing new algorithms to be readily inserted. That is, implementers should be prepared to regularly update the set of algorithms in their implementations.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>IANAis asked to assignhas assigned one object identifier for the ASN.1 module in <xref target="asn1mod"/> in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)" registry <xref target="IANA-MOD"/>:</t> <sourcecode type="asn1"><![CDATA[ id-mod-sha3-oids-2023 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) mod(0)TBD078 } ]]></sourcecode> <t>IANAis asked to assignhas assigned four object identifiers for the HKDF using SHA3 algorithm identifiers in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry <xref target="IANA-ALG"/>:</t> <sourcecode type="asn1"><![CDATA[ id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-algTBD132 } id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-algTBD233 } id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-algTBD334 } id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-algTBD435 } ]]></sourcecode> </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> <back> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <!-- [rfced] Please review the following reference. The most current version of [ANS-X9.44] was reaffirmed in 2017. We have updated this reference to use the most current reaffirmation date and series number (ANSI X9.44-2007 (R2017). Please let us know if you have any objections. Additionally, the correct series name and number for [ANS-X9.44] is "ANSI X9.44-2007". May we update the citation tag to [ANSI-X9.44-2007] to match this series identifier? Current: [ANS-X9.44] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry - Key Establishment Using Integer Factorization Cryptography", ANSI X9.44-2007 (R2017), 2017, <https://webstore.ansi.org/standards/ascx9/ ansix9442007r2017>. --> <referenceanchor="ANS-X9.44">anchor="ANS-X9.44" target="https://webstore.ansi.org/standards/ascx9/ansix9442007r2017"> <front> <title>Public Key Cryptography for the Financial Services Industry -- Key Establishment Using Integer Factorization Cryptography</title> <author> <organization>American National Standards Institute</organization> </author> <dateyear="2007"/>year="2017"/> </front> <seriesInfoname="American National Standard" value="X9.44"/>name="ANSI" value="X9.44-2007 (R2017)"/> </reference> <reference anchor="NIST.SP.800-108r1-upd1" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf"> <front> <title>Recommendation forkey derivation using pseudorandom functions</title> <author>Key Derivation Using Pseudorandom Functions</title> <author fullname="Lily Chen"> <organization>National Institute of Standards and Technology</organization> </author> <date year="2024" month="February" day="02"/> </front> <seriesInfo name="NIST SP" value="800-108r1-upd1"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/> </reference> <reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf"> <front> <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash</title><author><author fullname="John Kelsey"> <organization>National Institute of Standards and Technology</organization> </author><date year="2016" month="December"/> </front> <seriesInfo name="NIST Special Publication" value="800-185"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/> </reference> <reference anchor="RFC2104"> <front> <title>HMAC: Keyed-Hashing for Message Authentication</title> <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/><authorfullname="M. Bellare" initials="M." surname="Bellare"/> <author fullname="R. Canetti" initials="R." surname="Canetti"/> <date month="February" year="1997"/> <abstract> <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t> </abstract> </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 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key 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 arbitrary 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</title> <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 Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 modulefullname="Shu-jen Chang"> <organization>National Institute of"Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure CertificateStandards andCertificate 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"/>Technology</organization> </author> <authorfullname="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 building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its usefullname="Ray Perlner"> <organization>National Institute ofcryptographic hash functions. This document is not an InternetStandardsTrack specification; it is published for informational purposes.</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.509 (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 format,andmany 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 changes to any of the formats; 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="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"/>Technology</organization> </author> <datemonth="November" year="2016"/> <abstract> <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t> <t>This document represents a republication of PKCS #1 v2.2 from RSA 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>year="2016" month="December"/> </front> <seriesInfoname="RFC" value="8017"/>name="NIST SP" value="800-185"/> <seriesInfo name="DOI"value="10.17487/RFC8017"/>value="10.6028/NIST.SP.800-185"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/> <reference anchor="SHA3" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf"> <front> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title> <author> <organization>National Institute of Standards and Technology</organization> </author> <date year="2015" month="August"/> </front> <seriesInfoname="FIPS PUB"name="NIST FIPS" value="202"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/> </reference> <reference anchor="DSS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf"> <front> <title>Digital Signature Standard (DSS)</title> <author> <organization>National Institute of Standards and Technology</organization> </author> <date year="2023" month="February" day="03"/> </front> <seriesInfo name="FIPS PUB" value="186-5"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/> </reference> <reference anchor="X.680"target="https://www.itu.int/rec/T-REC-X.680">target="https://www.itu.int/rec/T-REC-X.680-202102-I/en"> <front> <title>Information technology--- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/> </reference> <reference anchor="X.690"target="https://www.itu.int/rec/T-REC-X.680">target="https://www.itu.int/rec/T-REC-X.690-202102-I/en"> <front> <title>Information technology--- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ISO/IEC" value="8825-1:2021"/> </reference><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title> <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 protocol 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IANA-ALG" target="https://www.iana.org/assignments/smi-numbers/"> <front> <title>SMI Security forforS/MIME Algorithms (1.2.840.113549.1.9.16.3)</title> <author> <organization>IANA</organization> </author><date>n.d.</date></front> </reference> <reference anchor="IANA-MOD" target="https://www.iana.org/assignments/smi-numbers/"> <front> <title>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)</title> <author> <organization>IANA</organization> </author><date>n.d.</date> </front> </reference> <reference anchor="I-D.ietf-lamps-cms-kemri"> <front> <title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic 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 transport 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> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-kemri-08"/> </reference> <reference anchor="RFC4086"> <front> <title>Randomness Requirements for Security</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <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 that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole 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 using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware 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 Current Practices for the Internet Community, and requests discussion and suggestions 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) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital 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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8702.xml"/> </references> </references><?line 522?><sectionnumbered="false"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 using the SHA3 family of hash functions <xref target="SHA3"/>. This module imports types from other ASN.1 modules that are defined in <xref target="RFC5912"/>.</t> <sourcecode type="asn.1" markers="true"><![CDATA[ SHA3-OIDs-2023 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)id-mod-sha3-oids-2023(TBD0)id-mod-sha3-oids-2023(78) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, KEY-DERIVATION, MAC-ALGORITHM FROM AlgorithmInformation-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } mda-sha1, pk-rsa, pk-ec, ECDSA-Sig-Value FROM PKIXAlgs-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms2008-02(56) } mda-sha224, mda-sha256, mda-sha384, mda-sha512 FROM PKIX1-PSS-OAEP-Algorithms-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs-02(54) } ; -- -- Alias -- OID ::= OBJECT IDENTIFIER -- -- Object Identifier Arcs -- nistAlgorithm OID ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) 4 } hashAlgs OID ::= { nistAlgorithm 2 } sigAlgs OID ::= { nistAlgorithm 3 } x9-44 OID ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-44(44) } x9-44-components OID ::= { x9-44 components(1) } id-alg OID ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 } -- -- Message Digest Algorithms -- id-sha3-224 OID ::= { hashAlgs 7 } id-sha3-256 OID ::= { hashAlgs 8 } id-sha3-384 OID ::= { hashAlgs 9 } id-sha3-512 OID ::= { hashAlgs 10 } mda-sha3-224 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-224 PARAMS ARE absent } mda-sha3-256 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-256 PARAMS ARE absent } mda-sha3-384 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-384 PARAMS ARE absent } mda-sha3-512 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-512 PARAMS ARE absent } HashAlgorithm ::= AlgorithmIdentifier{ DIGEST-ALGORITHM, { HashAlgorithms } } HashAlgorithms DIGEST-ALGORITHM ::= { mda-sha3-224 | mda-sha3-256 | mda-sha3-384 | mda-sha3-512, ... } -- -- Signature Algorithms -- id-rsassa-pkcs1-v1-5-with-sha3-224 OID ::= { sigAlgs 13 } id-rsassa-pkcs1-v1-5-with-sha3-256 OID ::= { sigAlgs 14 } id-rsassa-pkcs1-v1-5-with-sha3-384 OID ::= { sigAlgs 15 } id-rsassa-pkcs1-v1-5-with-sha3-512 OID ::= { sigAlgs 16 } id-ecdsa-with-sha3-224 OID ::= { sigAlgs 9 } id-ecdsa-with-sha3-256 OID ::= { sigAlgs 10 } id-ecdsa-with-sha3-384 OID ::= { sigAlgs 11 } id-ecdsa-with-sha3-512 OID ::= { sigAlgs 12 } sa-rsaWithSHA3-224 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-224 PARAMS TYPE NULL ARE required HASHES { mda-sha3-224 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-224 } } sa-rsaWithSHA3-256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-256 PARAMS TYPE NULL ARE required HASHES { mda-sha3-256 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-256 } } sa-rsaWithSHA3-384 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-384 PARAMS TYPE NULL ARE required HASHES { mda-sha3-384 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-384 } } sa-rsaWithSHA3-512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-512 PARAMS TYPE NULL ARE required HASHES { mda-sha3-512 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-512 } } sa-ecdsaWithSHA3-224 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-224 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-224 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-224 } } sa-ecdsaWithSHA3-256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-256 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-256 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-256 } } sa-ecdsaWithSHA3-384 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-384 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-384 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-384 } } sa-ecdsaWithSHA3-512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-512 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-512 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-512 } } SignatureAlg ::= AlgorithmIdentifier{ SIGNATURE-ALGORITHM, { SignatureAlgs } } SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-rsaWithSHA3-224 | sa-rsaWithSHA3-256 | sa-rsaWithSHA3-384 | sa-rsaWithSHA3-512 | sa-ecdsaWithSHA3-224 | sa-ecdsaWithSHA3-256 | sa-ecdsaWithSHA3-384 | sa-ecdsaWithSHA3-512, ... } -- -- Message Authentication Codes -- id-hmacWithSHA3-224 OID ::= { hashAlgs 13 } id-hmacWithSHA3-256 OID ::= { hashAlgs 14 } id-hmacWithSHA3-384 OID ::= { hashAlgs 15 } id-hmacWithSHA3-512 OID ::= { hashAlgs 16 } maca-hmacWithSHA3-224 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-224 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-224 } } maca-hmacWithSHA3-256 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-256 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-256 } } maca-hmacWithSHA3-384 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-384 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-384 } } maca-hmacWithSHA3-512 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-512 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-512 } } MACAlgorithm ::= AlgorithmIdentifier{ MAC-ALGORITHM, { MACAlgorithms } } MACAlgorithms MAC-ALGORITHM ::= { maca-hmacWithSHA3-224 | maca-hmacWithSHA3-256 | maca-hmacWithSHA3-384 | maca-hmacWithSHA3-512, ... } -- -- Key Derivation Algorithms -- id-alg-hkdf-with-sha3-224 OID ::= { id-algTBD132 } id-alg-hkdf-with-sha3-256 OID ::= { id-algTBD233 } id-alg-hkdf-with-sha3-384 OID ::= { id-algTBD334 } id-alg-hkdf-with-sha3-512 OID ::= { id-algTBD435 } id-kmac128 OID ::= { hashAlgs 21 } id-kmac256 OID ::= { hashAlgs 22 } id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } kda-hkdf-with-sha3-224 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-224 PARAMS ARE absent -- No S/MIME caps defined -- } kda-hkdf-with-sha3-256 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-256 PARAMS ARE absent -- No S/MIME caps defined -- } kda-hkdf-with-sha3-384 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-384 PARAMS ARE absent -- No S/MIME caps defined -- } kda-hkdf-with-sha3-512 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-512 PARAMS ARE absent -- No S/MIME caps defined -- } kda-kmac128 KEY-DERIVATION ::= { IDENTIFIER id-kmac128 PARAMS TYPE Customization ARE optional -- PARAMS are absent when Customization is ''H -- -- No S/MIME caps defined -- } kda-kmac256 KEY-DERIVATION ::= { IDENTIFIER id-kmac256 PARAMS TYPE Customization ARE optional -- PARAMS are absent when Customization is ''H -- -- No S/MIME caps defined -- } kda-kdf2 KEY-DERIVATION ::= { IDENTIFIER id-kdf-kdf2 PARAMS TYPE KDF2-HashFunction ARE required -- No S/MIME caps defined -- } kda-kdf3 KEY-DERIVATION ::= { IDENTIFIER id-kdf-kdf3 PARAMS TYPE KDF3-HashFunction ARE required -- No S/MIME caps defined -- } Customization ::= OCTET STRING KDF2-HashFunction ::= AlgorithmIdentifier { DIGEST-ALGORITHM, { KDF2-HashFunctions } } KDF2-HashFunctions DIGEST-ALGORITHM ::= { X9-HashFunctions, ... } KDF3-HashFunction ::= AlgorithmIdentifier { DIGEST-ALGORITHM, { KDF3-HashFunctions } } KDF3-HashFunctions DIGEST-ALGORITHM ::= { X9-HashFunctions, ... } X9-HashFunctions DIGEST-ALGORITHM ::= { mda-sha1 | mda-sha224 | mda-sha256 | mda-sha384 | mda-sha512 | mda-sha3-224 | mda-sha3-256 | mda-sha3-384 | mda-sha3-512, ... } KeyDerivationFunction ::= AlgorithmIdentifier{ KEY-DERIVATION, { KeyDevAlgs } } KeyDevAlgs KEY-DERIVATION ::= { kda-hkdf-with-sha3-224 | kda-hkdf-with-sha3-256 | kda-hkdf-with-sha3-384 | kda-hkdf-with-sha3-512 | kda-kmac128 | kda-kmac256 | kda-kdf2 | kda-kdf3, ... } END ]]></sourcecode> </section></back><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> <!--##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=[rfced] We note that "RSASSA PKCS#1 version 1.5 signature algorithm" appears inconsistently throughout the document. Please review and let us know how you would like to update for consistency. RSASSA PKCS#1 version 1.5 signature algorithm RSASSA PKCS#1 v1.5 RSASSA PKCS#1 v1.5 signature algorithm --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!-- [rfced] FYI - We have added expansions for the following abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Hashed Message Authentication Code (HMAC) --> </back> </rfc>