<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2104 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"> <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml"> <!ENTITY RFC3370 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml"> <!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml"> <!-- <!ENTITY RFC4086 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"> --> <!ENTITY RFC5480 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"> <!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"> <!ENTITY RFC5753 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"> <!ENTITY RFC5911 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"> <!ENTITY RFC6268 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"> <!ENTITY RFC6979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> <!ENTITY RFC8017 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"> <!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY I-D.ietf-lamps-pkix-shake SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lamps-pkix-shake.xml"> <!ENTITY I-D.draft-housley-lamps-cms-sha3-hash SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-housley-lamps-cms-sha3-hash-00.xml"> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions -->"rfc2629-xhtml.ent"> <rfc number="8702" xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-lamps-cms-shakes-18" ipr="trust200902"updates="3370"> <!-- category values: std, bcp, info, exp, and historic ipr="full3978" (probably old) ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->updates="3370" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- ***** FRONT MATTER ***** --> <front> <title abbrev="SHAKEs in CMS">Use of the SHAKEOne-wayOne-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title> <seriesInfo name="RFC" value="8702" /> <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis"> <organization>Cisco Systems</organization><address><email>pkampana@cisco.com</email></address><address> <email>pkampana@cisco.com</email> </address> </author> <author fullname="Quynh Dang" initials="Q." surname="Dang"> <organization>NIST</organization><address><postal><street>100<address> <postal> <street>100 Bureau Drive</street><street>Gaithersburg, MD 20899</street><city>Gaithersburg</city> <region>MD</region> <code>20899</code> <country>United States of America</country> </postal> <email>quynh.Dang@nist.gov</email> </address> </author> <dateyear="2019"/>month="January" year="2020"/> <area>General</area> <workgroup>LAMPS WG</workgroup> <keyword>SHAKEs in CMS</keyword> <keyword>SHAKE</keyword> <keyword>CMS with SHAKEs</keyword> <abstract> <t>This document updates the“Cryptographic"Cryptographic Message SyntaxAlgorithms” (RFC3370)(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 ProbabilisticsignatureSignature Scheme (RSASSA-PSS) andECDSA signature algorithms.Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are alsodescribed. </t>described.</t> </abstract> </front> <middle> <sectiontitle="Change Log"> <t>[ EDNOTE: Remove this section before publication. ]</t> <t><list style="symbols"> <t>draft-ietf-lamps-cms-shake-18: <list> <t>Minor ASN.1 changes.</t> </list></t> <t>draft-ietf-lamps-cms-shake-17: <list> <t>Minor updates for EDNOTE accuracy.</t> </list></t> <t>draft-ietf-lamps-cms-shake-16: <list> <t>Minor nits.</t> <t>Using bytes instead of bits for consistency.</t> </list></t> <t>draft-ietf-lamps-cms-shake-15: <list> <t>Minor editorial nits.</t> </list></t> <t>draft-ietf-lamps-cms-shake-14: <list> <t>Fixing error with incorrect preimage resistance bits for SHA128 and SHA256.</t> </list></t> <t>draft-ietf-lamps-cms-shake-13: <list> <t>Addressing comments from Dan M.'s secdir review.</t> <t>Addressing comment from Scott B.'s opsdir review about references in the abstract.</t> </list></t> <t>draft-ietf-lamps-cms-shake-12: <list> <t>Nits identified by Roman, Barry L. in ballot position review.</t> </list></t> <t>draft-ietf-lamps-cms-shake-11: <list> <t>Minor nits.</t> <t>Nits identified by Roman in AD Review.</t> </list></t> <t>draft-ietf-lamps-cms-shake-10: <list> <t>Updated IANA considerations section to request for OID assignments. </t> </list></t> <t>draft-ietf-lamps-cms-shake-09: <list> <t>Fixed minor text nit.</t> <t>Updates in Sec Considerations section.</t> </list></t> <t>draft-ietf-lamps-cms-shake-08: <list> <t>id-shake128-len and id-shake256-len were replaced with id-sha128 with 32 bytes output length and id-shake256 with 64 bytes output length.</t> <t>Fixed a discrepancy between section 3 and 4.4 about the KMAC OIDs that have parameters as optional. </t> </list></t> <t>draft-ietf-lamps-cms-shake-07: <list> <t>Small nit from Russ while in WGLC.</t> </list></t> <t>draft-ietf-lamps-cms-shake-06: <list> <t>Incorporated Eric's suggestion from WGLC.</t> </list></t> <t>draft-ietf-lamps-cms-shake-05: <list> <t>Added informative references.</t> <t>Updated ASN.1 so it compiles.</t> <t>Updated IANA considerations.</t> </list></t> <t>draft-ietf-lamps-cms-shake-04: <list> <t>Added RFC8174 reference and text. </t> <t>Explicitly explained why RSASSA-PSS-params are omitted in section 4.2.1.</t> <t>Simplified Public Keys section by removing redundant info from RFCs.</t> </list></t> <t>draft-ietf-lamps-cms-shake-03: <list> <t>Removed paragraph suggesting KMAC to be used in generating k in Deterministic ECDSA. That should be RFC6979-bis. </t> <t>Removed paragraph from Security Considerations that talks about randomness of k because we are using deterministic ECDSA.</t> <t>Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's feedback.</t> <t>Text fixes.</t> </list></t> <t>draft-ietf-lamps-cms-shake-02: <list> <t>Updates based on suggestions and clarifications by Jim. </t> <t>Started ASN.1 module.</t> </list></t> <t>draft-ietf-lamps-cms-shake-01: <list> <t>Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in CMS.</t> <t>Added new OIDs for RSASSA-PSS that hardcodes hash, salt and MGF, according the WG consensus.</t> <t>Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage.</t> <t>Removed the no longer used SHAKE OIDs from section 3.1.</t> </list></t> <t>draft-ietf-lamps-cms-shake-00: <list> <t>Various updates to title and section names.</t> <t>Content changes filling in text and references.</t> </list></t> <t>draft-dang-lamps-cms-shakes-hash-00: <list> <t>Initial version</t> </list></t> </list></t> </section> <section title="Introduction" anchor="intro"> <t>The "Cryptographicanchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t>"Cryptographic Message Syntax (CMS)" <xreftarget="RFC5652"/> istarget="RFC5652" format="default"/> describes syntax used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. "Cryptographic Message Syntax (CMS) Algorithms" <xreftarget="RFC3370"/>target="RFC3370" format="default"/> defines the use of common cryptographic algorithms with CMS. This specification updatesRFC3370RFC 3370 and describes the use of the SHAKE128 and SHAKE256 specified in <xreftarget="SHA3"/>target="SHA3" format="default"/> as new hash functions in CMS. In addition, it describes the use of these functions with theRSASSA-PSSRSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm <xreftarget="RFC8017"/>target="RFC8017" format="default"/> and the Elliptic Curve Digital Signature Algorithm (ECDSA) <xreftarget="X9.62"/>target="X9.62" format="default"/> with the CMS signed-data content type.</t> <t>In the SHA-3 family, two extendable-output functions (SHAKEs), SHAKE128 and SHAKE256, are defined. Four other hash functioninstances, SHA3-224,instances (SHA3-224, SHA3-256, SHA3-384, andSHA3-512,SHA3-512) are also defined but are out of scope for this document. A SHAKE is avariable lengthvariable-length hash function defined as SHAKE(M, d) where the output is ad-bits-longd-bit-long digest of message M. The corresponding collision and second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and min(d,128) bits, respectively(Appendix(see Appendix A.1 of <xreftarget="SHA3"/>).target="SHA3" format="default"/>). And the corresponding collision and second-preimage-resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, respectively. In thisspecificationspecification, we use d=256 (for SHAKE128) and d=512 (for SHAKE256).</t> <t>A SHAKE can be used in CMS as the message digest function (to hash the message to be signed) in RSASSA-PSS and ECDSA, as the message authenticationcodecode, and as the mask generation function (MGF) in RSASSA-PSS. This specification describes the identifiers for SHAKEs to be used in CMS and theirmeaning.meanings. </t><!-- <section title="ASN.1" anchor="section-1.1"> <t>CMS values are generated using ASN.1 <xref target="ASN1-B"/>, using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="ASN1-E"/>.</t> </section> --><section anchor="terminology"title="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <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 shownhere.</t>here. </t> </section> <!-- Terminology --> </section> <sectiontitle="Identifiers" anchor="oids"> <!-- <figure><artwork><![CDATA[ id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm HashAlgorithm, maskGenAlgorithm MaskGenAlgorithm, saltLength INTEGER, trailerField INTEGER } ]]></artwork></figure> --> <!-- Commention out the below OIDs as they are no longer pertinent for the below public keys and sigs --> <!-- The mask generation function used in RSASSA-PSS is defined in <xref target="RFC8017"/>, but we include it here as well for convenience: <t><figure><artwork><![CDATA[ id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }]]></artwork></figure></t> <t>The parameters field associated with id-mgf1 MUST have a hashAlgorithm value that identifies the hash used with MGF1. To use SHAKE as this hash, this parameter MUST be id-shake128-len or id- shake256-len as specified in <xref target="mdmgf" /> above. </t> -->anchor="oids" numbered="true" toc="default"> <name>Identifiers</name> <t>This section identifies eight new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS.</t> <t>Two object identifiers for SHAKE128 and SHAKE256 hash functions are defined in <xreftarget="shake-nist-oids"/>target="shake-nist-oids" format="default"/>, and we include them here for convenience.</t><t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 12 }]]></artwork></figure></t>]]></sourcecode> <t>In this specification, when using the id-shake128 or id-shake256 algorithm identifiers, the parametersMUST<bcp14>MUST</bcp14> be absent. That is, the identifierSHALL be a SEQUENCE of one component, the OID. <!-- present, and they MUST employ the ShakeOutputLen --> <!-- "MUST employ syntax borrowed from RFC4055 --> <!-- syntax that contains an encoded positive integer value<bcp14>SHALL</bcp14> be a SEQUENCE of32 or 64 respectively.--></t> <t><xref target="I-D.ietf-lamps-pkix-shake"/> [ EDNOTE: Update reference withone component, theRFC when it is published. ]OID. </t> <t><xref target="RFC8692" format="default"/> defines two identifiers for RSASSA-PSS signatures usingSHAKEsSHAKEs, which we include here for convenience. </t><t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 }]]></artwork></figure></t>]]></sourcecode> <t>The same RSASSA-PSS algorithm identifiers can be used for identifying public keys and signatures.</t> <t><xreftarget="I-D.ietf-lamps-pkix-shake"/> [ EDNOTE: Update reference with the RFC when it is published. ]target="RFC8692" format="default"/> also defines two algorithm identifiers of ECDSA signatures usingSHAKEsSHAKEs, which we include here for convenience. </t><t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 }]]></artwork></figure></t>]]></sourcecode> <t>The parameters for the four RSASSA-PSS and ECDSA identifiersMUST<bcp14>MUST</bcp14> be absent. That is, each identifierSHALL<bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID.</t><!-- <figure><artwork><![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-shake128 ::= { sigAlgs x } id-ecdsa-with-shake256 ::= { sigAlgs y } Note: x and y will be specified by NIST. ]]></artwork> </figure> --> <t>Two object identifiers for KMACs using SHAKE128 and SHAKE256 as defined in by<t> In <xref target="shake-nist-oids" format="default"/>, the National Institute of Standards and Technology (NIST)in <xref target="shake-nist-oids"/>defines two object identifiers for Keccak message authentication codes (KMACs) using SHAKE128 and SHAKE256, and we include them here for convenience.</t><t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 19 } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 20 }]]></artwork></figure></t>]]></sourcecode> <t>The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 areOPTIONAL.</t> <!-- <figure><artwork><![CDATA[ hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { x } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { y } Note: x and y will be specified by NIST. ]]></artwork></figure> --> <t><xref target="md"/>,<bcp14>OPTIONAL</bcp14>.</t> <t>Sections <xreftarget="rsa-sigs"/>,target="md" format="counter"/>, <xreftarget="ecdsa-sigs"/>target="rsa-sigs" format="counter"/>, <xref target="ecdsa-sigs" format="counter"/>, and <xreftarget="kmac"/>target="kmac" format="counter"/> specify the required output length for each use of SHAKE128 or SHAKE256 in message digests, RSASSA-PSS,ECDSAECDSA, and KMAC.</t> </section> <sectiontitle="Usenumbered="true" toc="default"> <name>Use inCMS">CMS</name> <section anchor="md"title="Message Digests">numbered="true" toc="default"> <name>Message Digests</name> <t>The id-shake128 and id-shake256 OIDs(<xref target="oids"/>)(see <xref target="oids" format="default"/>) can be used as the digest algorithm identifiers located in the SignedData, SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm fields in CMS <xreftarget="RFC5652"/>.target="RFC5652" format="default"/>. The OID encodingMUST<bcp14>MUST</bcp14> omit the parameters field and the output length of SHAKE128 or SHAKE256 as the message digestMUST<bcp14>MUST</bcp14> be 32 or 64 bytes, respectively.</t> <t>The digest values are located in the DigestedData field and the Message Digest authenticated attribute included in the signedAttributes of the SignedDatasignerInfo.signerInfos. In addition, digest values are input to signature algorithms. The digest algorithmMUST<bcp14>MUST</bcp14> be the same as the message hash algorithms used in signatures.</t> </section> <sectiontitle="Signatures" anchor="sigs">anchor="sigs" numbered="true" toc="default"> <name>Signatures</name> <t>In CMS, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field ofSignedDatasigned-data content type and countersignature attribute. Signature values are located in the SignerInfo signature field ofSignedDatasigned-data content type and countersignature attribute.</t> <t>Conforming implementations that process RSASSA-PSS and ECDSA with SHAKE signatures when processing CMS dataMUST<bcp14>MUST</bcp14> recognize the corresponding OIDs specified in <xreftarget="oids"/>.</t>target="oids" format="default"/>.</t> <t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus or ECDSA curve orderSHOULD<bcp14>SHOULD</bcp14> be chosen in line with the SHAKE output length. Refer to <xreftarget="sec_cons"/>target="sec_cons" format="default"/> for more details.</t> <sectiontitle="RSASSA-PSS Signatures" anchor="rsa-sigs">anchor="rsa-sigs" numbered="true" toc="default"> <name>RSASSA-PSS Signatures</name> <t>The RSASSA-PSS algorithm is defined in <xreftarget="RFC8017"/>.target="RFC8017" format="default"/>. When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256specified(specified in <xreftarget="oids"/>target="oids" format="default"/>) is used, the encodingMUST<bcp14>MUST</bcp14> omit the parameters field. That is, the AlgorithmIdentifierSHALL<bcp14>SHALL</bcp14> be a SEQUENCE of onecomponent,component: id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xreftarget="RFC4055"/>target="RFC4055" format="default"/> defines RSASSA-PSS-params that are used to define the algorithms and inputs to the algorithm. This specification does not use parameters because the hash, mask generation algorithm,trailertrailer, and salt are embedded in the OID definition.</t> <t>The hash algorithm used to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSSMUST<bcp14>MUST</bcp14> be the same: both SHAKE128 or both SHAKE256. The output length of the hash algorithmwhichthat hashes the messageSHALL<bcp14>SHALL</bcp14> be 32 (for SHAKE128) or 64 bytes (for SHAKE256). </t> <t>The mask generation function takes an octet string of variable length and a desired output length as input, and outputs an octet string of the desired length. In RSASSA-PSS with SHAKEs, the SHAKEsMUST<bcp14>MUST</bcp14> be used natively as theMGF function,MGF, instead of the MGF1 algorithm that uses the hash function in multipleiterationsiterations, as specified inSection B.2.1 of [RFC8017].<xref target="RFC8017" sectionFormat="of" section="B.2.1"/>. In other words, the MGF is defined as the SHAKE128 or SHAKE256 with input being the mgfSeed forid-RSASSA-PSS- SHAKE128id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed isthe seed from which mask is generated,an octet string used as the seed to generate the mask <xreftarget="RFC8017"/>.target="RFC8017" format="default"/>. As explained in Step 9 ofsection 9.1.1 of<xreftarget="RFC8017"/>,target="RFC8017" sectionFormat="of" section="9.1.1"/>, the output length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and64-bytes64 bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively.ThusThus, when SHAKE is used as the MGF, the SHAKE output length maskLen is (8*emLen - 264) or (8*emLen - 520) bits, respectively. For example, when RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or1528-bits1528 bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively.</t> <t>The RSASSA-PSS saltLengthMUST<bcp14>MUST</bcp14> be 32 bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerFieldMUST<bcp14>MUST</bcp14> be 1, which represents the trailer field with hexadecimal value 0xBC <xreftarget="RFC8017"/>.</t>target="RFC8017" format="default"/>.</t> </section> <sectiontitle="ECDSA Signatures" anchor="ecdsa-sigs">anchor="ecdsa-sigs" numbered="true" toc="default"> <name>ECDSA Signatures</name> <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in <xreftarget="X9.62"/>.target="X9.62" format="default"/>. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 (specified in <xreftarget="oids"/>)target="oids" format="default"/>) algorithm identifier appears, the respective SHAKE function is used as the hash. The encodingMUST<bcp14>MUST</bcp14> omit the parameters field. That is, the AlgorithmIdentifierSHALL<bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID id-ecdsa-with-shake128 or id-ecdsa-with-shake256.</t> <t>For simplicity and compliance with the ECDSA standardspecification,specification <xref target="X9.62" format="default"/>, the output length of the hash function must be explicitly determined. The output length for SHAKE128 or SHAKE256 used in ECDSAMUST<bcp14>MUST</bcp14> be 32 or 64 bytes, respectively. </t> <t>ConformingCACertification Authority (CA) implementations that generate ECDSA with SHAKE signatures in certificates orCRLs SHOULDCertificate Revocation Lists (CRLs) <bcp14>SHOULD</bcp14> generate such signatures with a deterministically generated,non-randomnonrandom k in accordance with all the requirements specified in <xreftarget="RFC6979"/>. <!-- Sections 7.2 and 7.3 of <xref target="X9.62"/> or with all the requirements specified in Section 4.1.3 of <xref target="SEC1"/>. -->target="RFC6979" format="default"/>. TheyMAY<bcp14>MAY</bcp14> also generate such signatures in accordance with all other recommendations in <xreftarget="X9.62"/>target="X9.62" format="default"/> or <xreftarget="SEC1"/>target="SEC1" format="default"/> if they have a stated policy that requires conformance to those standards. Those standards have not specified SHAKE128and SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 with output length being 32 and 64 octets, respectively can be used instead of 256 and 512-bit output hash algorithms such as SHA256 and SHA512.</t> <!-- <t>In Section 3.2 "Generation of k" of <xref target="RFC6979"/>, HMAC is used to derive the deterministic k. Conforming implementations that generate deterministic ECDSA with SHAKE signatures in X.509 MUST use KMAC with SHAKE128 or KMAC with SHAKE256 as specfied in <xref target="SP800-185"/> when SHAKE128 orand SHAKE256is usedasthe message hashing algorithm, respectively. In this situation, KMAC withhash algorithm options. However, SHAKE128 andKMAC withSHAKE256have 256-bitwith output length being 32 and512-bit outputs64 octets, respectively, can be used instead of 256 andthe optional customization bit string S is an empty string.</t> -->512-bit output hash algorithms, such as SHA256 and SHA512.</t> </section> </section> <sectiontitle="Public Keys">numbered="true" toc="default"> <name>Public Keys</name> <t>In CMS, the signer's public key algorithm identifiers are located in the OriginatorPublicKey's algorithm attribute. The conventions and encoding for RSASSA-PSS and ECDSA<!-- and EdDSA -->public keys algorithm identifiers are as specified inSection 2.3 of <xref target="RFC3279"/>, Section 3.1 of<xreftarget="RFC4055"/> and Section 2.1 of <xref target="RFC5480"/>. <!--target="RFC3279" sectionFormat="of" section="2.3"/>, <xref target="RFC4055" sectionFormat="of" section="3.1"/>, and <xreftarget="I-D.josefsson-pkix-eddsa"/> --></t>target="RFC5480" sectionFormat="of" section="2.1"/>. </t> <t>Traditionally, the rsaEncryption object identifier is used to identify RSA public keys. The rsaEncryption object identifier continues to identify the public key when the RSA private key owner does not wish to limit the use of the public key exclusively to RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifier for RSASSA-PSS defined in <xreftarget="oids"/> SHOULDtarget="oids" format="default"/> <bcp14>SHOULD</bcp14> be used as the algorithm attribute in the OriginatorPublicKey sequence. Conforming client implementations that process RSASSA-PSS with SHAKE public keys in CMS messageMUST<bcp14>MUST</bcp14> recognize the corresponding OIDs in <xreftarget="oids"/>.</t>target="oids" format="default"/>.</t> <t>Conforming implementationsMUST<bcp14>MUST</bcp14> specify and process the algorithms explicitly by using the OIDs specified in <xreftarget="oids"/>target="oids" format="default"/> when encoding ECDSA with SHAKE public keys in CMS messages. </t> <t>The identifier parameters, as explained in <xreftarget="oids"/>, MUSTtarget="oids" format="default"/>, <bcp14>MUST</bcp14> be absent. </t> </section> <section anchor="kmac"title="Messagenumbered="true" toc="default"> <name>Message AuthenticationCodes"> <t>KMACCodes</name> <t>Keccak message authentication code (KMAC) is specified in <xreftarget="SP800-185"/>.target="SP800-185" format="default"/>. In CMS, KMAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field. The KMAC values are located in the AuthenticatedData mac field.</t> <t>When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 OID is used as the MAC algorithm identifier, the parameters field is optional (absent or present). If absent, the SHAKE256 output length used in KMAC is 32 or 64 bytes, respectively, and the customization string is an empty string by default.</t> <t>Conforming implementations that process KMACs with the SHAKEs when processing CMS dataMUST<bcp14>MUST</bcp14> recognize these identifiers.</t> <t>When calculating the KMAC output, the variable N is 0xD2B282C2, S is an empty string, andL, theL (the integer representing the requested output length inbits,bits) is 256 or 512 for KmacWithSHAKE128 or KmacWithSHAKE256, respectively, in this specification.</t> </section> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>One object identifier for the ASN.1 modulein <xref target="section-a"/> was requested for the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) registry: </t> <texttable> <ttcol align='center'>Decimal</ttcol> <ttcol align='center'>Description</ttcol> <ttcol align='center'>References</ttcol> <c>70</c> <c>CMSAlgsForSHAKE-2019</c> <c>[EDNOTE: THIS RFC]</c> </texttable> <!-- <t>EDNOTE: If the PKIX draft is standardized first maybe we should not keep these OIDS as they are not new. </t> <t>IANA has assigned four OID identifiers in the SMI Security for PKIX Algorithms <xref target="SMI-PKIX"/> (1.3.6.1.5.5.7.6) registry </t> <t><figure><artwork><![CDATA[ id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } ]]></artwork></figure></t> --> </section> <section title="Security Considerations" anchor="sec_cons"> <t>This document updates <xref target="RFC3370"/>. The security considerations section of that document applies to this specification as well.</t> <!-- <t>The SHAKEs are deterministic functions. Like any other deterministic function, executing each function with the same input multiple times will produce the same output. Therefore, users should not expect unrelated outputs (with the same or different output lengths) from excuting a SHAKE function with the same input multiple times. The shorter one of any 2 outputs produced from a SHAKE with the same input is a prefix of the longer one. It is a similar situation as truncating a 512-bit output of SHA-512 by taking its 256 left-most bits. These 256 left-most bits are a prefix of the 512-bit output.</t> --> <!-- <t>Implementations must protectin <xref target="asn-app" format="default"/> was updated in thesigner's private key. Compromise"Structure ofthe signer's private key permits masquerade.</t> -->Management Information (SMI) Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry: </t> <table align="left"> <thead> <tr> <th align="center">Decimal</th> <th align="center">Description</th> <th align="center">References</th> </tr> </thead> <tbody> <tr> <td align="center">70</td> <td align="center">CMSAlgsForSHAKE-2019</td> <td align="center">RFC 8702</td> </tr> </tbody> </table> </section> <section anchor="sec_cons" numbered="true" toc="default"> <name>Security Considerations</name> <t>This document updates <xref target="RFC3370" format="default"/>. The security considerations section of that document applies to this specification as well.</t> <t>NIST has defined appropriate use of the hash functions in terms of the algorithm strengths and expected time frames for secure use in Special Publications (SPs) <xreftarget="SP800-78-4"/>target="SP800-78-4" format="default"/> and <xreftarget="SP800-107"/>.target="SP800-107" format="default"/>. These documents can be used as guides to choose appropriate key sizes for various security scenarios. </t> <t>SHAKE128 with an output length of 32 bytes offers128-bits128 bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification areRECOMMENDED<bcp14>RECOMMENDED</bcp14> with2048a 2048- (112-bit security) or 3072-bit (128-bit security) RSA modulus or curves with a group order of256-bits256 bits (128-bit security). SHAKE256 with64 bytesa 64-byte output length offers256-bits256 bits of collision and preimage resistance. Thus, the SHAKE256 OIDs in this specification areRECOMMENDED<bcp14>RECOMMENDED</bcp14> with 4096-bit RSA modulus or higher or curveswith group order of at least 512 bits such as NIST Curve P-521 (256-bit security). Note that we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bits of security which is impractical for today's technology.</t> <t>When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties.</t> <!-- <t>Implementations must randomly generate message-authentication keys and one-time values, such as the k value when generating a ECDSA signature. In addition, the generation of public/private key pairs relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate such cryptographic values can result in little or no security. The generation of quality random numbers is difficult. <xref target="RFC4086"/> offers important guidance in this area, and <xref target="SP800-90A"/> series provide acceptable PRNGs.</t> --> <!--<t>Implementers should be aware that cryptographic algorithms may become weaker with time. As new cryptanalysis techniques are developed and computing power increases, the work factor or time required to break a particular cryptographic algorithm may decrease. Therefore, cryptographic algorithm implementations should be modular 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 title="Acknowledgements" anchor="ack"> <t>This document is based on Russ Housley's draft <xref target="I-D.housley-lamps-cms-sha3-hash"/>. It replaces SHA3 hash functions by SHAKE128 and SHAKE256 as the LAMPS WG agreed.</t> <t>The authors would like to thank Russ Housley for his guidance and very valuable contributions with the ASN.1 module. Valuable feedback was also provided by Eric Rescorla. </t> </section> </middle> <back> <references title="Normative References"> &RFC2119; &RFC3370; &RFC8174; &RFC5652; &RFC8017; <!-- RFC8017 is Informational draft butwith group order of at least 512 bits, such as NIST curve P-521 (256-bit security). Note that weare keeping it in the Normative References even though idnits complainsrecommended a 4096-bit RSA because we would need anormative reference15360-bit modulus forRSASSA-PSS. RFC4056 does256 bits of security, which is impractical for today's technology.</t> <t>When more than two parties share the samething with RSASS-PSS v2.1 --> &RFC4055; &RFC5480;message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC; therefore, the content could originate from any one of the parties.</t> </section> </middle> <back> <displayreference target="I-D.housley-lamps-cms-sha3-hash" to="CMS-SHA3"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/> <referenceanchor="SHA3">anchor="SHA3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf"> <front> <title>SHA-3Standard -Standard: Permutation-Based Hash and Extendable-Output Functions</title> <author> <organization>National Institute of Standards andTechnology, U.S. Department of Commerce</organization>Technology (NIST)</organization> </author> <date month="August" year="2015"/> </front> <seriesInfo name="FIPS" value="PUB 202"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/> </reference> <reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf"> <front> <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash andParallelHash. NIST SP 800-185</title>ParallelHash</title> <author> <organization>National Institute of Standards andTechnology</organization>Technology (NIST)</organization> </author> <date month="December"year="2016" /> </front> </reference> <!-- <reference anchor="ASN1-B"><front> <title>Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2015"/> </front> <seriesInfo name="ITU-T" value="Recommendation X.680"/> </reference> --> <!-- <reference anchor="ASN1-E"><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="2015"/>year="2016"/> </front> <seriesInfoname="ITU-T" value="Recommendation X.690"/> </reference> --> <!-- <reference anchor="DSS"><front> <title>Digital Signature Standard, version 4</title> <author> <organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization> </author> <date year="2013"/> </front>name="NIST Special Publication" value="800-185"/> <seriesInfoname="NIST" value="FIPS PUB 186-4"/>name="DOI" value="10.6028/NIST.SP.800-185"/> </reference>--></references><references title="Informative References"> &RFC3279;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8692.xml"/> <!--&RFC4086;housley-lamps-cms-sha3-hash Expired -->&RFC5753; &RFC5911; &RFC6268; &RFC6979; &I-D.ietf-lamps-pkix-shake; <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-housley-lamps-cms-sha3-hash-00.xml"?><xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.housley-lamps-cms-sha3-hash.xml"/> <reference anchor="shake-nist-oids" target="https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration"> <front> <title>Computer Security Objects Register</title> <author> <organization>National Institute of Standards andTechnology</organization>Technology (NIST)</organization> </author> <date month="October"year="2017" />year="2019"/> </front> </reference> <reference anchor="X9.62"> <front><title>X9.62-2005 Public<title>Public Key Cryptography for the Financial Services Industry:Thethe Elliptic Curve Digital SignatureStandardAlgorithm (ECDSA)</title> <author> <organization>American National Standard for Financial Services (ANSI)</organization> </author> <date month="November"year="2005" />year="2005"/> </front> <seriesInfo name="ANSI" value="X9.62"/> </reference> <reference anchor="SP800-78-4"target="https://csrc.nist.gov/csrc/media/publications/sp/800-78/4/final/documents/sp800_78-4_revised_draft.pdf">target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf"> <front><title>SP800-78-4: Cryptographic<title>Cryptographic Algorithms and Key Sizes for Personal Identity Verification</title> <author> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <date month="May"year="2014" />year="2015"/> </front> <seriesInfo name="NIST Special Publication" value="800-78-4"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-78-4"/> </reference> <reference anchor="SP800-107"target="https://csrc.nist.gov/csrc/media/publications/sp/800-107/rev-1/final/documents/draft_revised_sp800-107.pdf">target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf"> <front><title>SP800-107: Recommendation<title>Recommendation for Applications Using Approved Hash Algorithms</title> <author> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <datemonth="May" year="2014" />month="August" year="2012"/> </front> <seriesInfo name="Draft NIST Special Publication" value="800-107 Revised"/> </reference> <reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf"> <front> <title>SEC 1: Elliptic Curve Cryptography</title> <author> <organization>Standards for Efficient Cryptography Group</organization> </author> <date month="May"year="2009" /> </front> </reference> <!-- <reference anchor="SMI-PKIX" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6"> <front> <title>SMI Security for PKIX Algorithms</title> <author> <organization>IANA</organization> </author> <date month="March" year="2019" /> </front> </reference> --> <!-- <reference anchor="SP800-90A" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf"> <front> <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST SP 800-90A</title> <author> <organization>National Institute of Standards and Technology</organization> </author> <date month="June" year="2015" />year="2009"/> </front> </reference>--></references> </references> <sectiontitle="ASN.1 Module" anchor="section-a">anchor="asn-app" numbered="true" toc="default"> <name>ASN.1 Module</name> <t>This appendix includes the ASN.1 modules for SHAKEs in CMS. This module includes some ASN.1 from other standards for reference.</t><t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-shakes-2019(70) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS FROM AlgorithmInformation-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } RSAPublicKey, rsaEncryption, id-ecPublicKey FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms2008-02(56) } sa-rsassapssWithSHAKE128, sa-rsassapssWithSHAKE256, sa-ecdsaWithSHAKE128, sa-ecdsaWithSHAKE256 FROM PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-shakes-2019(94) } ; -- MessageDigestdigest Algorithms (mda-) -- used in SignedData, SignerInfo, DigestedData, -- and the AuthenticatedData digestAlgorithm -- fields in CMS -- -- This expands MessageAuthAlgs from [RFC5652] and -- MessageDigestAlgs in [RFC5753] -- -- MessageDigestAlgs DIGEST-ALGORITHM ::= { -- mda-shake128 | -- mda-shake256, -- ... -- } -- -- One-Way Hash Functions -- SHAKE128 mda-shake128 DIGEST-ALGORITHM ::= { IDENTIFIER id-shake128 -- with output length 32 bytes. } id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 11 } -- SHAKE256 mda-shake256 DIGEST-ALGORITHM ::= { IDENTIFIER id-shake256 -- with output length 64 bytes. } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 12 } -- -- Public key algorithm identifiers located in the -- OriginatorPublicKey's algorithm attribute in CMS. -- And Signature identifiers used in SignerInfo -- signatureAlgorithm field ofSignedDatasigned-data content -- type and countersignature attribute in CMS. -- -- FromRFC5280,RFC 5280, forreference.reference: -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } -- When the rsaEncryption algorithm identifier is used -- for a public key, the AlgorithmIdentifier parameters -- field MUST contain NULL. -- id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } -- When the id-RSASSA-PSS-* algorithm identifiers are used -- for a public key or signature in CMS, the AlgorithmIdentifier -- parameters field MUST be absent. The message digest algorithm -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a3232- or --64 byte outout64-byte output length, respectively. The mask generation -- function MUST be SHAKE128 or SHAKE256 with an output length -- of (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, -- respectively, where n is the RSA modulus in bits. -- The RSASSA-PSS saltLength MUST be 32 or 64 bytes, respectively. -- The trailerField MUST be 1, which represents the trailer -- field with hexadecimal value 0xBC. Regardless of -- id-RSASSA-PSS-* or rsaEncryption being used as the -- AlgorithmIdentifier of the OriginatorPublicKey, the RSA -- public key MUST be encoded using the RSAPublicKey type. -- FromRFC4055,RFC 4055, forreference.reference: -- RSAPublicKey ::= SEQUENCE { -- modulus INTEGER, -- -- n -- publicExponent INTEGER } -- -- e id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } -- When the id-ecdsa-with-shake* algorithm identifiers are -- used in CMS, the AlgorithmIdentifier parameters field -- MUST be absent and the signature algorithm should be -- deterministic ECDSA [RFC6979]. The message digest MUST -- be SHAKE128 or SHAKE256 with a3232- or64 byte outout64-byte output -- length, respectively. In both cases, the ECDSA public key, -- MUST be encoded using the id-ecPublicKey type. -- FromRFC5480,RFC 5480, forreference.reference: -- id-ecPublicKey OBJECT IDENTIFIER ::= { -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } -- The id-ecPublicKey parameters must be absent or present -- and are definedasas: -- ECParameters ::= CHOICE { -- namedCurve OBJECT IDENTIFIER -- -- -- implicitCurve NULL -- -- -- specifiedCurve SpecifiedECDomain -- } -- This expandsSignatureAlgorithmsSignatureAlgs from [RFC5912] -- -- SignatureAlgs SIGNATURE-ALGORITHM ::= { -- sa-rsassapssWithSHAKE128 | -- sa-rsassapssWithSHAKE256 | -- sa-ecdsaWithSHAKE128 | -- sa-ecdsaWithSHAKE256, -- ... -- } -- This expands MessageAuthAlgs from [RFC5652] and [RFC6268] -- -- Message Authentication (maca-) Algorithms -- used in AuthenticatedData macAlgorithm in CMS -- MessageAuthAlgs MAC-ALGORITHM ::= { maca-KMACwithSHAKE128 | maca-KMACwithSHAKE256, ... } -- This expands SMimeCaps from [RFC5911] -- SMimeCaps SMIME-CAPS ::= { -- sa-rsassapssWithSHAKE128.&smimeCaps | -- sa-rsassapssWithSHAKE256.&smimeCaps | -- sa-ecdsaWithSHAKE128.&smimeCaps | -- sa-ecdsaWithSHAKE256.&smimeCaps, maca-KMACwithSHAKE128.&smimeCaps | maca-KMACwithSHAKE256.&smimeCaps, ... } -- -- KMAC with SHAKE128 maca-KMACwithSHAKE128 MAC-ALGORITHM ::= { IDENTIFIER id-KMACWithSHAKE128 PARAMS TYPE KMACwithSHAKE128-params ARE optional -- If KMACwithSHAKE128-params parameters areabsentabsent, -- the SHAKE128 output length used in KMAC is 256 bits -- and the customization string is an empty string. IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE128} } id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 19 } KMACwithSHAKE128-params ::= SEQUENCE { kMACOutputLength INTEGER DEFAULT 256, -- Output length in bits customizationString OCTET STRING DEFAULT ''H } -- KMAC with SHAKE256 maca-KMACwithSHAKE256 MAC-ALGORITHM ::= { IDENTIFIER id-KMACWithSHAKE256 PARAMS TYPE KMACwithSHAKE256-params ARE optional -- If KMACwithSHAKE256-params parameters areabsentabsent, -- the SHAKE256 output length used in KMAC is 512 bits -- and the customization string is an empty string. IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE256} } id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 20 } KMACwithSHAKE256-params ::= SEQUENCE { kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits customizationString OCTET STRING DEFAULT ''H } END]]></artwork></figure>]]></sourcecode> </section> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>This document is based on <contact fullname="Russ Housley"/>'s document <xref target="I-D.housley-lamps-cms-sha3-hash" format="default"/>. It replaces SHA3 hash functions by SHAKE128 and SHAKE256, as the LAMPS WG agreed.</t> <t>The authors would like to thank <contact fullname="Russ Housley"/> for his guidance and very valuable contributions with the ASN.1 module. Valuable feedback was also provided by Eric Rescorla. </t> </section> </back> </rfc>