rfc8702xml2.original.xml		rfc8702.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2104 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2104.xml">
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2119.xml">
	<!ENTITY RFC3279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.3279.xml">
	<!ENTITY RFC3370 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.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/referen
	ce.RFC.4086.xml"> -->
	<!ENTITY RFC5480 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5480.xml">
	<!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5652.xml">
	<!ENTITY RFC5753 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5753.xml">
	<!ENTITY RFC5911 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5911.xml">
	<!ENTITY RFC6268 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.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.RF
	C.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.xm
	l">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),		<rfc number="8702" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
	please see http://xml.resource.org/authoring/README.html. -->		consensus="true"
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds		docName="draft-ietf-lamps-cms-shakes-18" ipr="trust200902" updates="3370"
	might want to use.		obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true"
	(Here they are set differently than their defaults in xml2rfc v1.32) -->		symRefs="true" sortRefs="true" version="3">
	<?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 -->
	<rfc category="std" docName="draft-ietf-lamps-cms-shakes-18" ipr="trust200902" u
	pdates="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)" -->
	<!-- ***** FRONT MATTER ***** -->		<!-- ***** FRONT MATTER ***** -->
	<front>		<front>
	<title abbrev="SHAKEs in CMS">Use of the SHAKE One-way Hash		<title abbrev="SHAKEs in CMS">Use of the SHAKE One-Way Hash
	Functions in the Cryptographic Message Syntax (CMS)</title>		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>
			</author>
			<author fullname="Quynh Dang" initials="Q." surname="Dang">
			<organization>NIST</organization>
			<address>
			<postal>
			<street>100 Bureau Drive</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>
			<date month="January" year="2020"/>
			<area>General</area>
			<workgroup>LAMPS WG</workgroup>
	<author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">		<keyword>SHAKEs in CMS</keyword>
	<organization>Cisco Systems</organization>		<keyword>SHAKE</keyword>
	<address><email>pkampana@cisco.com</email></address>		<keyword>CMS with SHAKEs</keyword>
	</author>
	<author fullname="Quynh Dang" initials="Q." surname="Dang">
	<organization>NIST</organization>
	<address><postal><street>100 Bureau Drive</street>
	<street>Gaithersburg, MD 20899</street>
	</postal>
	<email>quynh.Dang@nist.gov</email>
	</address>
	</author>
	<date year="2019"/>
	<area>General</area>
	<workgroup>LAMPS WG</workgroup>
	<abstract>
	<t>This document updates the “Cryptographic Message Syntax Algorithms
	”
	(RFC3370) and describes the conventions for using the SHAKE famil
	y of
	hash functions in the Cryptographic Message Syntax as one-way has
	h
	functions with the RSA Probabilistic signature and ECDSA signature
	algorithms. The conventions for the
	associated signer public keys in CMS are also described. </t>
	</abstract>
	</front>
	<middle>		<abstract>
	<section title="Change Log">		<t>This document updates the "Cryptographic Message Syntax (CMS)
	<t>[ EDNOTE: Remove this section before publication. ]</t>		Algorithms"
	<t><list style="symbols">		(RFC 3370) and describes the conventions for using the SHAKE family of
	<t>draft-ietf-lamps-cms-shake-18:		hash functions in the Cryptographic Message Syntax as one-way hash
	<list>		functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS)
	<t>Minor ASN.1 changes.</t>		and Elliptic Curve Digital Signature Algorithm (ECDSA). The
	</list></t>		conventions for the associated signer public keys in CMS are also
	<t>draft-ietf-lamps-cms-shake-17:		described.</t>
	<list>		</abstract>
	<t>Minor updates for EDNOTE accuracy.</t>		</front>
	</list></t>		<middle>
	<t>draft-ietf-lamps-cms-shake-16:		<section anchor="intro" numbered="true" toc="default">
	<list>		<name>Introduction</name>
	<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 SHA
	128 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 refer
	ences 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 assig
	nments. </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-sh
	a128 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 se
	ction 4.2.1.</t>
	<t>Simplified Public Keys section by removing redundant info fr
	om 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 ab
	out randomness of k because we are using deterministic ECDSA.</t>
	<t>Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's f
	eedback.</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 an
	d 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>"Cryptographic Message Syntax (CMS)" <xref target="RFC5652"
	<t>The "Cryptographic Message Syntax (CMS)" <xref target="RFC5652"/> is u		format="default"/> describes syntax used to
	sed to
	digitally sign, digest, authenticate, or encrypt arbitrary message conten ts.		digitally sign, digest, authenticate, or encrypt arbitrary message conten ts.
	"Cryptographic Message Syntax (CMS) Algorithms" <xref target="RFC3370"/>		"Cryptographic Message Syntax (CMS) Algorithms" <xref target="RFC3370" fo rmat="default"/>
	defines the use of common cryptographic algorithms with CMS. This		defines the use of common cryptographic algorithms with CMS. This
	specification updates RFC3370 and describes the use of the SHAKE128 and S		specification updates RFC 3370 and describes the use of the SHAKE128 and
	HAKE256		SHAKE256
	specified in <xref target="SHA3"/> as new hash functions in CMS. In addition		specified in <xref target="SHA3" format="default"/> as new hash functions in
	,		CMS. In addition,
	it describes the use of these functions with the RSASSA-PSS signature		it describes the use of these functions with the RSA Probabilistic
	algorithm <xref target="RFC8017"/> and the Elliptic Curve Digital Signatu		Signature Scheme (RSASSA-PSS) signature
	re		algorithm <xref target="RFC8017" format="default"/> and the Elliptic Curv
	Algorithm (ECDSA) <xref target="X9.62"/> with the CMS signed-data content		e Digital Signature
	type.</t>		Algorithm (ECDSA) <xref target="X9.62" format="default"/> with the CMS si
			gned-data content type.</t>
	<t>In the SHA-3 family, two extendable-output functions (SHAKEs), SHAKE128 a		<t>In the SHA-3 family, two extendable-output functions (SHAKEs), SHAKE128
	nd SHAKE256,		and SHAKE256,
	are defined. Four other hash function instances, SHA3-224, SHA3-256,		are defined. Four other hash function instances (SHA3-224, SHA3-256,
	SHA3-384, and SHA3-512, are also defined but are out of scope for this do		SHA3-384, and SHA3-512) are also defined but are out of scope for this do
	cument.		cument.
	A SHAKE is a variable length hash function defined as SHAKE(M, d) where t		A SHAKE is a variable-length hash function defined as SHAKE(M, d) where t
	he		he
	output is a d-bits-long digest of message M. The corresponding collision		output is a d-bit-long digest of message M. The corresponding collision a
	and second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and min(		nd second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and min(d,
	d,128) bits,		128) bits,
	respectively (Appendix A.1 <xref target="SHA3"/>). And the		respectively (see Appendix A.1 of <xref target="SHA3" format="default"/>)
			. And the
	corresponding collision and second-preimage-resistance		corresponding collision and second-preimage-resistance
	strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, respectively .		strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, respectively .
	In this specification we use d=256 (for SHAKE128) and d=512 (for SHAKE256		In this specification, we use d=256 (for SHAKE128) and d=512 (for SHAKE25
	).</t>		6).</t>
			<t>A SHAKE can be used in CMS as the message digest function (to hash the
	<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
	message to be signed) in RSASSA-PSS and ECDSA, message		authentication code, and as the mask generation function (MGF) in RSASSA-PSS
	authentication code and as the mask generation function (MGF) in RSASSA-PSS.		.
	This specification describes the identifiers for SHAKEs to be used in		This specification describes the identifiers for SHAKEs to be used in
	CMS and their meaning. </t>		CMS and their 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>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	when, and only when, they appear in all capitals, as shown here.</t>
	</section> <!-- Terminology -->
	</section>
	<section title="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		<section anchor="terminology" numbered="true" toc="default">
	the below public keys and sigs -->		<name>Terminology</name>
	<!-- The mask generation function used in RSASSA-PSS		<t>
	is defined in <xref target="RFC8017"/>, but we include it here as well		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	for convenience:		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	<t><figure><artwork><![CDATA[		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }]]></artwork></figure></t>		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	<t>The parameters field associated with id-mgf1 MUST have a		</section>
	hashAlgorithm value that identifies the hash used with MGF1. To use		<!-- Terminology -->
	SHAKE as this hash, this parameter MUST be id-shake128-len or id-		</section>
	shake256-len as specified in <xref target="mdmgf" /> above. </t> -->		<section anchor="oids" numbered="true" toc="default">
			<name>Identifiers</name>
	<t>This section identifies eight new object identifiers (OIDs)		<t>This section identifies eight new object identifiers (OIDs)
	for using SHAKE128 and SHAKE256 in CMS.</t>		for using SHAKE128 and SHAKE256 in CMS.</t>
			<t>Two object identifiers for SHAKE128 and SHAKE256 hash functions are def
	<t>Two object identifiers for SHAKE128 and SHAKE256 hash functions are d		ined
	efined		in <xref target="shake-nist-oids" format="default"/>, and we include the
	in <xref target="shake-nist-oids"/> and we include them here for conveni		m here for convenience.</t>
	ence.</t>		<sourcecode type="asn.1"><![CDATA[
	<t><figure><artwork><![CDATA[
	id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 11 }		nistAlgorithm(4) 2 11 }
	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 12 }		nistAlgorithm(4) 2 12 }
	]]></artwork></figure></t>		]]></sourcecode>
			<t>In this specification, when using the id-shake128 or id-shake256 algori
	<t>In this specification, when using the id-shake128 or id-shake256 algorit		thm identifiers, the parameters <bcp14>MUST</bcp14> be absent. That is, the iden
	hm identifiers, the parameters MUST be absent. That is, the identifier SHALL be		tifier <bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID.
	a SEQUENCE of one component, the OID.		</t>
	<!-- present, and they MUST employ the ShakeOutputLen -->		<t><xref target="RFC8692" format="default"/>
	<!-- "MUST employ syntax borrowed from RFC4055 -->		defines two identifiers for RSASSA-PSS signatures using SHAKEs, which we
	<!-- syntax that contains an encoded positive integer value of 32 or 64		include here for
	respectively.--></t>
	<t><xref target="I-D.ietf-lamps-pkix-shake"/>
	[ EDNOTE: Update reference with the RFC when it is published. ]
	defines two identifiers for RSASSA-PSS signatures using SHAKEs which we
	include here for
	convenience.		convenience.
	</t>		</t>
	<t><figure><artwork><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)		id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) dod(6) internet(1)		identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) algorithms(6) 30 }		security(5) mechanisms(5) pkix(7) algorithms(6) 30 }
	id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)		id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) dod(6) internet(1)		identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) algorithms(6) 31 }		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
	<t>The same RSASSA-PSS algorithm identifiers can be used for identifying
	public keys and signatures.</t>		public keys and signatures.</t>
			<t><xref target="RFC8692" format="default"/>
	<t><xref target="I-D.ietf-lamps-pkix-shake"/>
	[ EDNOTE: Update reference with the RFC when it is published. ]
	also defines two algorithm		also defines two algorithm
	identifiers of ECDSA signatures using SHAKEs which we include here for		identifiers of ECDSA signatures using SHAKEs, which we include here for
	convenience.		convenience.
	</t>		</t>
	<t><figure><artwork><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)		id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) dod(6) internet(1)		identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) algorithms(6) 32 }		security(5) mechanisms(5) pkix(7) algorithms(6) 32 }
	id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)		id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) dod(6) internet(1)		identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) algorithms(6) 33 }		security(5) mechanisms(5) pkix(7) algorithms(6) 33 }
	]]></artwork></figure></t>		]]></sourcecode>
			<t>The parameters for the four RSASSA-PSS and ECDSA identifiers
	<t>The parameters for the four RSASSA-PSS and ECDSA identifiers		<bcp14>MUST</bcp14> be absent. That is, each identifier <bcp14>SHALL</bc
	MUST be absent. That is, each identifier SHALL be a SEQUENCE of one comp		p14> be a SEQUENCE of one component,
	onent,
	the OID.</t>		the OID.</t>
	<!-- <figure><artwork><![CDATA[		<t>
	sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		In <xref target="shake-nist-oids" format="default"/>, the National
	us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 }		Institute of Standards and Technology (NIST) defines two object
			identifiers for Keccak message authentication codes (KMACs) using SHAKE1
	id-ecdsa-with-shake128 ::= { sigAlgs x }		28 and SHAKE256,
	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 the National Institute of Standards and Technology (NIST)
	in <xref target="shake-nist-oids"/>
	and we include them here for convenience.</t>		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)		id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 19 }		nistAlgorithm(4) 2 19 }
	id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 20 }		nistAlgorithm(4) 2 20 }
	]]></artwork></figure></t>		]]></sourcecode>
			<t>The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 are <bcp
	<t>The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 are OP		14>OPTIONAL</bcp14>.</t>
	TIONAL.</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"/>, <xref target="rsa-sigs"/>, <xref target="ecdsa-sigs
	"/>
	and <xref target="kmac"/> specify the required output length for each us
	e
	of SHAKE128 or SHAKE256 in message digests, RSASSA-PSS, ECDSA
	and KMAC.</t>
	</section>
	<section title="Use in CMS">		<t>Sections <xref target="md" format="counter"/>, <xref
	<section anchor="md" title="Message Digests">		target="rsa-sigs" format="counter"/>, <xref target="ecdsa-sigs"
	<t>The id-shake128 and id-shake256 OIDs (<xref target="oids"/>) can		format="counter"/>, and <xref target="kmac" format="counter"/> specify
			the required output length for each use of SHAKE128 or SHAKE256 in
			message digests, RSASSA-PSS, ECDSA, and KMAC.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Use in CMS</name>
			<section anchor="md" numbered="true" toc="default">
			<name>Message Digests</name>
			<t>The id-shake128 and id-shake256 OIDs (see <xref target="oids" format=
			"default"/>) can
	be used as the digest algorithm identifiers located in the Signed Data,		be used as the digest algorithm identifiers located in the Signed Data,
	SignerInfo, DigestedData, and the AuthenticatedData digestAlgori		SignerInfo, DigestedData, and the AuthenticatedData digestAlgorit
	thm fields		hm fields
	in CMS <xref target="RFC5652"/>. The OID encoding MUST omit the p		in CMS <xref target="RFC5652" format="default"/>. The OID encodin
	arameters field and the output length of SHAKE128 or SHAKE256 as the message dig		g <bcp14>MUST</bcp14> omit the parameters field and the output length of SHAKE12
	est MUST be 32 or 64 bytes, respectively.</t>		8 or SHAKE256 as the message digest <bcp14>MUST</bcp14> be 32 or 64 bytes, respe
			ctively.</t>
	<t>The digest values are located in the DigestedData field and the Me		<t>The digest values are located in the DigestedData field and the Messa
	ssage		ge
	Digest authenticated attribute included in the signedAttributes of th e		Digest authenticated attribute included in the signedAttributes of th e
	SignedData signerInfo. In addition, digest values are input to		SignedData signerInfos. In addition, digest values are input to
	signature algorithms. The digest algorithm MUST be the same as the		signature algorithms. The digest algorithm <bcp14>MUST</bcp14> be the
			same as the
	message hash algorithms used in signatures.</t>		message hash algorithms used in signatures.</t>
	</section>		</section>
			<section anchor="sigs" numbered="true" toc="default">
	<section title="Signatures" anchor="sigs">		<name>Signatures</name>
	<t>In CMS, signature algorithm identifiers are located in the SignerInfo		<t>In CMS, signature algorithm identifiers are located in the SignerInfo
	signatureAlgorithm field of SignedData content type and countersignature attribute.		signatureAlgorithm field of signed-data content type and countersignatur e attribute.
	Signature values are located in the SignerInfo signature field of		Signature values are located in the SignerInfo signature field of
	SignedData content type and countersignature attribute.</t>		signed-data content type and countersignature attribute.</t>
			<t>Conforming implementations that process RSASSA-PSS and
	<t>Conforming implementations that process RSASSA-PSS and		ECDSA with SHAKE signatures when processing CMS data <bcp14>MUST<
	ECDSA with SHAKE signatures when processing CMS data MUST recogni		/bcp14> recognize the
	ze the		corresponding OIDs specified in <xref target="oids" format="defau
	corresponding OIDs specified in <xref target="oids"/>.</t>		lt"/>.</t>
			<t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus or ECDSA
	<t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus or ECD		curve order <bcp14>SHOULD</bcp14> be chosen in line with the SHAK
	SA		E output length. Refer to <xref target="sec_cons" format="default"/> for more de
	curve order SHOULD be chosen in line with the SHAKE output length		tails.</t>
	. Refer to <xref target="sec_cons"/> for more details.</t>		<section anchor="rsa-sigs" numbered="true" toc="default">
			<name>RSASSA-PSS Signatures</name>
	<section title="RSASSA-PSS Signatures" anchor="rsa-sigs">		<t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017" forma
	<t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017"/>.		t="default"/>.
	When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified		When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 (specifie
	in <xref target="oids"/>		d in <xref target="oids" format="default"/>)
	is used, the encoding MUST omit the parameters field. That is,		is used, the encoding <bcp14>MUST</bcp14> omit the parameters f
	the AlgorithmIdentifier SHALL be a SEQUENCE of one component,		ield. That is,
	id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref target=		the AlgorithmIdentifier <bcp14>SHALL</bcp14> be a SEQUENCE of o
	"RFC4055"/>		ne component:
			id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref target=
			"RFC4055" format="default"/>
	defines RSASSA-PSS-params that are used to define the algorithm s and inputs		defines RSASSA-PSS-params that are used to define the algorithm s and inputs
	to the algorithm. This specification does not use parameters be		to the algorithm.
	cause the		This specification does not use parameters because the
	hash, mask generation algorithm, trailer and salt are embedded		hash, mask generation algorithm, trailer, and salt are embedded
	in		in
	the OID definition.</t>		the OID definition.</t>
			<t>The hash algorithm used to hash a message being signed and the hash
	<t>The hash algorithm to hash a message being signed and the ha		algorithm as the mask generation function used in RSASSA-PSS <bcp14>MU
	sh		ST</bcp14> be
	algorithm as the mask generation function used in RSASSA-PSS MUST be
	the same: both SHAKE128 or both SHAKE256. The output length of		the same: both SHAKE128 or both SHAKE256. The output length of
	the hash algorithm which hashes the message SHALL be 32 (for SHAKE128)		the hash algorithm that hashes the message <bcp14>SHALL</bcp14> be 32 (for SHAKE128)
	or 64 bytes (for SHAKE256). </t>		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 SHAKEs
			<bcp14>MUST</bcp14> be used natively as the MGF, instead of the MGF1
			algorithm that uses the hash function in multiple iterations, as
			specified in <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 for
			id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256,
			respectively.
	<t>The mask generation function takes an octet string of variable l		The mgfSeed is an octet string used as the seed to generate
	ength		the mask <xref
	and a desired output length as input, and outputs an octet string of		target="RFC8017" format="default"/>. As explained in Step 9 of
	the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be		<xref target="RFC8017" sectionFormat="of" section="9.1.1"/>, the
	used natively as the MGF function, instead of the MGF1 algorithm that		output length of the MGF is emLen - hLen - 1 bytes. emLen is the
	uses the hash function in multiple iterations as specified in		maximum message length ceil((n-1)/8), where n is the RSA modulus in
	Section B.2.1 of [RFC8017]. In other words, the MGF is defined as		bits. hLen is 32 and 64 bytes for id-RSASSA-PSS-SHAKE128 and
	the SHAKE128 or SHAKE256 with input being the mgfSeed for id-RSASSA-PS		id-RSASSA-PSS-SHAKE256, respectively. Thus, when SHAKE is used as
	S-		the MGF, the SHAKE output length maskLen is (8*emLen - 264) or
	SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the		(8*emLen - 520) bits, respectively. For example, when RSA modulus n
	seed		is 2048, the output length of SHAKE128 or SHAKE256 as the MGF will
	from which mask is generated, an octet string <xref target="RFC		be 1784 or 1528 bits when id-RSASSA-PSS-SHAKE128 or
	8017"/>.		id-RSASSA-PSS-SHAKE256 is used, respectively.</t>
	As explained in Step 9 of section 9.1.1 of <xref target="RFC801		<t>The RSASSA-PSS saltLength <bcp14>MUST</bcp14> be 32 bytes for id-RS
	7"/>, the output		ASSA-PSS-SHAKE128
	length of the MGF is emLen - hLen - 1 bytes. emLen is the maxim
	um message
	length ceil((n-1)/8), where n is the RSA modulus in bits. hLen
	is 32 and
	64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256,
	respectively.
	Thus when SHAKE is used as the MGF, the SHAKE output length mas
	kLen is
	(8*emLen - 264) or (8*emLen - 520) bits, respectively. For exam
	ple, when RSA modulus n is 2048,
	the output length of SHAKE128 or SHAKE256 as the MGF will be 17
	84 or 1528-bits
	when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used,
	respectively.</t>
	<t>The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS
	-SHAKE128
	or 64 bytes for id-RSASSA-PSS-SHAKE256.		or 64 bytes for id-RSASSA-PSS-SHAKE256.
	Finally, the trailerField MUST be 1, which represents the trailer		Finally, the trailerField <bcp14>MUST</bcp14> be 1, which represents t
	field with hexadecimal value 0xBC <xref target="RFC8017"/>.</t>		he trailer
	</section>		field with hexadecimal value 0xBC <xref target="RFC8017" format="defau
			lt"/>.</t>
	<section title="ECDSA Signatures" anchor="ecdsa-sigs">		</section>
	<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is define		<section anchor="ecdsa-sigs" numbered="true" toc="default">
	d in		<name>ECDSA Signatures</name>
	<xref target="X9.62"/>. When the id-ecdsa-with-shake128 or id-ecdsa		<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined i
	-with-shake256		n
	(specified in <xref target="oids"/>) algorithm identifier appea		<xref target="X9.62" format="default"/>. When the id-ecdsa-with-sha
	rs, the		ke128 or id-ecdsa-with-shake256
			(specified in <xref target="oids" format="default"/>) algorithm
			identifier appears, the
	respective SHAKE function is used as the hash.		respective SHAKE function is used as the hash.
	The encoding MUST omit the parameters field. That is, the Algor		The encoding <bcp14>MUST</bcp14> omit the parameters field. Tha
	ithmIdentifier		t is, the AlgorithmIdentifier
	SHALL be a SEQUENCE of one component, the OID id-ecdsa-with-sha		<bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID id
	ke128 or		-ecdsa-with-shake128 or
	id-ecdsa-with-shake256.</t>		id-ecdsa-with-shake256.</t>
	<t>For simplicity and compliance with the ECDSA standard specif		<t>For simplicity and compliance with the ECDSA standard
	ication,		specification <xref target="X9.62" format="default"/>,
	the output length of the hash function must be explicitly deter mined.		the output length of the hash function must be explicitly deter mined.
	The output length for SHAKE128 or SHAKE256 used in ECDSA MUST b e 32		The output length for SHAKE128 or SHAKE256 used in ECDSA <bcp14 >MUST</bcp14> be 32
	or 64 bytes, respectively. </t>		or 64 bytes, respectively. </t>
			<t>Conforming Certification Authority (CA) implementations that genera
			te ECDSA with SHAKE signatures
			in certificates or Certificate Revocation Lists (CRLs) <bcp14>S
			HOULD</bcp14> generate such signatures with a
			deterministically generated, nonrandom k in accordance with all
			the requirements specified in <xref target="RFC6979" format="de
			fault"/>.
	<t>Conforming CA implementations that generate ECDSA with SHAKE		They <bcp14>MAY</bcp14> also generate such signatures
	signatures		in accordance with all other recommendations in <xref target="X
	in certificates or CRLs SHOULD generate such signatures with a		9.62" format="default"/> or
	deterministically generated, non-random k in accordance with al		<xref target="SEC1" format="default"/> if they have a stated po
	l		licy that requires
	the requirements specified in <xref target="RFC6979"/>.
	<!-- Sections 7.2 and 7.3 of
	<xref target="X9.62"/> or with all the requirements specified i
	n Section
	4.1.3 of <xref target="SEC1"/>. -->
	They MAY also generate such signatures
	in accordance with all other recommendations in <xref target="X
	9.62"/> or
	<xref target="SEC1"/> if they have a stated policy that require
	s
	conformance to those standards. Those standards have not specif ied		conformance to those standards. Those standards have not specif ied
	SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE 128 and		SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE 128 and
	SHAKE256 with output length being 32 and 64 octets, respectivel		SHAKE256 with output length being 32 and 64 octets, respectivel
	y can		y, can
	be used instead of 256 and 512-bit output hash algorithms such		be used instead of 256 and 512-bit output hash algorithms, such
	as SHA256		as SHA256
	and SHA512.</t>		and SHA512.</t>
	<!-- <t>In Section 3.2 "Generation of k" of <xref target="RFC69		</section>
	79"/>, HMAC is used to derive		</section>
	the deterministic k. Conforming implementations that generate d		<section numbered="true" toc="default">
	eterministic		<name>Public Keys</name>
	ECDSA with SHAKE signatures in X.509 MUST use KMAC with SHAKE12		<t>In CMS, the signer's public key algorithm identifiers are located in
	8 or KMAC with		the
	SHAKE256 as specfied in <xref target="SP800-185"/> when SHAKE12
	8 or SHAKE256 is
	used as the message hashing algorithm, respectively. In this si
	tuation, KMAC with
	SHAKE128 and KMAC with SHAKE256 have 256-bit and 512-bit output
	s respectively,
	and the optional customization bit string S is an empty string.
	</t> -->
	</section>
	</section>
	<section title="Public Keys">
	<t>In CMS, the signer's public key algorithm identifiers are located
	in the
	OriginatorPublicKey's algorithm attribute.		OriginatorPublicKey's algorithm attribute.
	The conventions and encoding for RSASSA-PSS and ECDSA <!-- and Ed DSA -->		The conventions and encoding for RSASSA-PSS and ECDSA
	public keys algorithm identifiers are as specified in		public keys algorithm identifiers are as specified in
	Section 2.3 of <xref target="RFC3279"/>,		<xref target="RFC3279" sectionFormat="of" section="2.3"/>,
	Section 3.1 of <xref target="RFC4055"/>		<xref target="RFC4055" sectionFormat="of" section="3.1"/>,
	and Section 2.1 of <xref target="RFC5480"/>.		and <xref target="RFC5480" sectionFormat="of" section="2.1"/>.
	<!-- and <xref target="I-D.josefsson-pkix-eddsa"/> --></t>
	<t>Traditionally, the rsaEncryption object identifier is used to		</t>
			<t>Traditionally, the rsaEncryption object identifier is used to
	identify RSA public keys. The rsaEncryption object identifier		identify RSA public keys. The rsaEncryption object identifier
	continues to identify the public key when the RSA private		continues to identify the public key when the RSA private
	key owner does not wish to limit the use of the public key		key owner does not wish to limit the use of the public key
	exclusively to RSASSA-PSS with SHAKEs. When the RSA private key		exclusively to RSASSA-PSS with SHAKEs. When the RSA private key
	owner wishes to limit the use of the public key exclusively		owner wishes to limit the use of the public key exclusively
	to RSASSA-PSS, the AlgorithmIdentifier for RSASSA-PSS defined		to RSASSA-PSS, the AlgorithmIdentifier for RSASSA-PSS defined
	in <xref target="oids"/> SHOULD be used as the algorithm attribut e		in <xref target="oids" format="default"/> <bcp14>SHOULD</bcp14> b e used as the algorithm attribute
	in the OriginatorPublicKey sequence. Conforming client		in the OriginatorPublicKey sequence. Conforming client
	implementations that process RSASSA-PSS with SHAKE public keys		implementations that process RSASSA-PSS with SHAKE public keys
	in CMS message MUST recognize the corresponding OIDs in <xref tar		in CMS message <bcp14>MUST</bcp14> recognize the corresponding OI
	get="oids"/>.</t>		Ds in <xref target="oids" format="default"/>.</t>
			<t>Conforming implementations <bcp14>MUST</bcp14> specify and process th
	<t>Conforming implementations MUST specify and process the		e
	algorithms explicitly by using the OIDs specified in		algorithms explicitly by using the OIDs specified in
	<xref target="oids"/> when encoding ECDSA with SHAKE		<xref target="oids" format="default"/> when encoding ECDSA with S HAKE
	public keys in CMS messages. </t>		public keys in CMS messages. </t>
			<t>The identifier parameters, as explained in <xref target="oids" format
	<t>The identifier parameters, as explained in <xref target="oids"		="default"/>,
	/>,		<bcp14>MUST</bcp14> be absent. </t>
	MUST be absent. </t>		</section>
	</section>		<section anchor="kmac" numbered="true" toc="default">
			<name>Message Authentication Codes</name>
	<section anchor="kmac" title="Message Authentication Codes">		<t>Keccak message authentication code (KMAC) is specified in <xref targe
	<t>KMAC message authentication code (KMAC) is specified in <xref targ		t="SP800-185" format="default"/>.
	et="SP800-185"/>.
	In CMS, KMAC algorithm identifiers are located in the AuthenticatedDa ta		In CMS, KMAC algorithm identifiers are located in the AuthenticatedDa ta
	macAlgorithm field. The KMAC values are located in the AuthenticatedD ata mac field.</t>		macAlgorithm field. The KMAC values are located in the AuthenticatedD ata mac field.</t>
			<t>When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 OID
	<t>When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 OID
	is used as the MAC algorithm identifier, the parameters field is opti onal		is used as the MAC algorithm identifier, the parameters field is opti onal
	(absent or present). If absent, the SHAKE256 output length used in KM AC is		(absent or present). If absent, the SHAKE256 output length used in KM AC is
	32 or 64 bytes, respectively, and the customization string is an empt y string by default.</t>		32 or 64 bytes, respectively, and the customization string is an empt y string by default.</t>
			<t>Conforming implementations that process KMACs with the SHAKEs
	<t>Conforming implementations that process KMACs with the SHAKEs		when processing CMS data <bcp14>MUST</bcp14> recognize these iden
	when processing CMS data MUST recognize these identifiers.</t>		tifiers.</t>
			<t>When calculating the KMAC output, the variable N is 0xD2B282C2, S
	<t>When calculating the KMAC output, the variable N is 0xD2B282C2, S		is an empty string, and L (the integer representing the requested out
	is an empty string, and L, the integer representing the requested out		put
	put		length in bits) is 256 or 512 for KmacWithSHAKE128 or KmacWithSHAKE25
	length in bits, is 256 or 512 for KmacWithSHAKE128 or KmacWithSHAKE25		6,
	6,
	respectively, in this specification.</t>		respectively, in this specification.</t>
	</section>		</section>
	</section>		</section>
			<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">		<name>IANA Considerations</name>
	<t>One object identifier for the ASN.1 module in <xref target="section-		<t>One object identifier for the ASN.1 module in <xref target="asn-app" fo
	a"/>		rmat="default"/>
	was requested for the SMI Security for S/MIME Module Identifiers		was updated in the &quot;Structure of Management Information (SMI) Secu
	(1.2.840.113549.1.9.16.0) registry: </t>		rity for S/MIME Module Identifier
	<texttable>		(1.2.840.113549.1.9.16.0)&quot; registry: </t>
	<ttcol align='center'>Decimal</ttcol>		<table align="left">
	<ttcol align='center'>Description</ttcol>		<thead>
	<ttcol align='center'>References</ttcol>		<tr>
	<c>70</c>		<th align="center">Decimal</th>
	<c>CMSAlgsForSHAKE-2019</c>		<th align="center">Description</th>
	<c>[EDNOTE: THIS RFC]</c>		<th align="center">References</th>
	</texttable>		</tr>
			</thead>
	<!-- <t>EDNOTE: If the PKIX draft is standardized first maybe we should		<tbody>
	not		<tr>
	keep these OIDS as they are not new. </t>		<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 se
			curity considerations
			section of that document applies to this specification as well.</t>
	<t>IANA has assigned four OID identifiers in the		<t>NIST has defined appropriate use of the hash functions in terms of the
	SMI Security for PKIX Algorithms <xref target="SMI-PKIX"/>		algorithm
	(1.3.6.1.5.5.7.6) registry </t>		strengths and expected time frames for secure use in Special Publications
			(SPs)
			<xref target="SP800-78-4" format="default"/> and <xref 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 offers 128 bits of collision
			and preimage resistance. Thus, SHAKE128 OIDs in this specification are
			<bcp14>RECOMMENDED</bcp14> with a 2048- (112-bit security) or 3072-bit
			(128-bit security) RSA modulus or curves with a group order of 256 bits
			(128-bit security). SHAKE256 with a 64-byte output length offers 256 bits
			of collision and preimage resistance. Thus, the SHAKE256 OIDs in this
			specification are <bcp14>RECOMMENDED</bcp14> with 4096-bit RSA modulus
			or higher or curves with group order of at least 512 bits, such as NIST
			curve P-521 (256-bit security). Note that we recommended a 4096-bit RSA
			because we would need a 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>
			</section>
			</middle>
			<back>
	<t><figure><artwork><![CDATA[		<displayreference target="I-D.housley-lamps-cms-sha3-hash" to="CMS-SHA3"/>
	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>		<references>
			<name>References</name>
	<section title="Security Considerations" anchor="sec_cons">		<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.2119.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.3370.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8174.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.5652.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8017.xml"/>
	<t>This document updates <xref target="RFC3370"/>. The security conside		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	rations		ence.RFC.4055.xml"/>
	section of that document applies to this specification as well.</t>		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.5480.xml"/>
	<!-- <t>The SHAKEs are deterministic functions. Like any other determinist		<reference anchor="SHA3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIP
	ic		S.202.pdf">
	function, executing each function with the same input multiple times		<front>
	will produce the same output. Therefore, users should not expect		<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output
	unrelated outputs (with the same or different output lengths) from		Functions</title>
	excuting a SHAKE function with the same input multiple times.		<author>
	The shorter one of any 2 outputs produced from a SHAKE with the same		<organization>National Institute of Standards and
	input is a prefix of the longer one. It is a similar situation as		Technology (NIST)</organization>
	truncating a 512-bit output of SHA-512 by taking its 256 left-most bits		</author>
	.		<date month="August" year="2015"/>
	These 256 left-most bits are a prefix of the 512-bit output.</t> -->		</front>
			<seriesInfo name="FIPS" value="PUB 202"/>
			<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
			</reference>
	<!-- <t>Implementations must protect the signer's private key. Compromi		<reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpubs/Spec
	se of		ialPublications/NIST.SP.800-185.pdf">
	the signer's private key permits masquerade.</t> -->		<front>
			<title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and Parallel
			Hash</title>
			<author>
			<organization>National Institute of Standards and Technology (NIST
			)</organization>
			</author>
			<date month="December" year="2016"/>
			</front>
			<seriesInfo name="NIST Special Publication" value="800-185"/>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/>
			</reference>
	<t>NIST has defined appropriate use of the hash functions in terms of t		</references>
	he algorithm		<references>
	strengths and expected time frames for secure use in Special Publications		<name>Informative References</name>
	(SPs)		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<xref target="SP800-78-4"/> and <xref target="SP800-107"/>.		ence.RFC.3279.xml"/>
	These documents can be used as guides to choose appropriate key sizes		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	for various security scenarios. </t>		ence.RFC.5753.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.5911.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.6268.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.6979.xml"/>
	<t>SHAKE128 with output length of 32 bytes offers 128-bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification are RECOMMEN DED with 2048 (112-bit security) or 3072-bit (128-bit security) RSA modulus or c urves with group order of 256-bits (128-bit security). SHAKE256 with 64 bytes ou tput length offers 256-bits of collision and preimage resistance. Thus, the SHAK E256 OIDs in this specification are RECOMMENDED with 4096-bit RSA modulus or hig her or curves with group order of at least 512 bits such as NIST Curve P-521 (25 6-bit security). Note that we recommended 4096-bit RSA because we would need 153 60-bit modulus for 256-bits of security which is impractical for today's technol ogy.</t>		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC .8692.xml"/>
	<t>When more than two parties share the same message-authentication key		<!-- housley-lamps-cms-sha3-hash Expired -->
	,		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
	data origin authentication is not provided. Any party that knows the		rence.I-D.housley-lamps-cms-sha3-hash.xml"/>
	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 k		<reference anchor="shake-nist-oids" target="https://csrc.nist.gov/Projec
	eys		ts/Computer-Security-Objects-Register/Algorithm-Registration">
	and one-time values, such as the k value when generating a ECDSA		<front>
	signature. In addition, the generation of public/private key pairs		<title>Computer Security Objects Register</title>
	relies on random numbers. The use of inadequate pseudo-random		<author>
	number generators (PRNGs) to generate such cryptographic values can		<organization>National Institute of Standards and Technology (NIST
	result in little or no security. The generation of quality random		)</organization>
	numbers is difficult. <xref target="RFC4086"/> offers important guidance		</author>
	in this area, and <xref target="SP800-90A"/> series provide acceptable		<date month="October" year="2019"/>
	PRNGs.</t> -->		</front>
			</reference>
	<!--<t>Implementers should be aware that cryptographic algorithms may		<reference anchor="X9.62">
	become weaker with time. As new cryptanalysis techniques are developed		<front>
	and computing power increases, the work factor or time required to brea		<title>Public Key Cryptography for the Financial Services Industry:
	k		the Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
	a particular cryptographic algorithm may decrease. Therefore, cryptogra		<author>
	phic		<organization>American National Standard for Financial Services (A
	algorithm implementations should be modular allowing new algorithms to		NSI)</organization>
	be readily inserted. That is, implementers should be prepared to		</author>
	regularly update the set of algorithms in their implementations.</t> --		<date month="November" year="2005"/>
	>		</front>
			<seriesInfo name="ANSI" value="X9.62"/>
			</reference>
	</section>		<reference anchor="SP800-78-4" target="https://nvlpubs.nist.gov/nistpubs
			/SpecialPublications/NIST.SP.800-78-4.pdf">
			<front>
			<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="2015"/>
			</front>
			<seriesInfo name="NIST Special Publication" value="800-78-4"/>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-78-4"/>
			</reference>
	<section title="Acknowledgements" anchor="ack">		<reference anchor="SP800-107" target="https://nvlpubs.nist.gov/nistpubs/
	<t>This document is based on Russ Housley's draft		Legacy/SP/nistspecialpublication800-107r1.pdf">
	<xref target="I-D.housley-lamps-cms-sha3-hash"/>.		<front>
	It replaces SHA3 hash functions by SHAKE128 and SHAKE256 as the LAMPS		<title>Recommendation for Applications Using Approved Hash Algorithm
	WG agreed.</t>		s</title>
	<t>The authors would like to thank Russ Housley for his guidance and		<author>
	very valuable contributions with the ASN.1 module. Valuable		<organization>National Institute of Standards and Technology (NIST
	feedback was also provided by Eric Rescorla. </t>		)</organization>
	</section>		</author>
	</middle>		<date month="August" year="2012"/>
			</front>
			<seriesInfo name="Draft NIST Special Publication"
			value="800-107 Revised"/>
			</reference>
	<back>		<reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
	<references title="Normative References">		<front>
	&RFC2119;		<title>SEC 1: Elliptic Curve Cryptography</title>
	&RFC3370;		<author>
	&RFC8174;		<organization>Standards for Efficient Cryptography Group</organiza
	&RFC5652;		tion>
	&RFC8017; <!-- RFC8017 is Informational draft but we are keeping it in		</author>
	the Normative References even though idnits complains because we need a normativ		<date month="May" year="2009"/>
	e reference for RSASSA-PSS. RFC4056 does the same thing with RSASS-PSS v2.1 -->		</front>
	&RFC4055;		</reference>
	&RFC5480;
	<reference anchor="SHA3">
	<front>
	<title>SHA-3 Standard - Permutation-Based Hash and Extendable-Outpu
	t Functions</title>
	<author>
	<organization>National Institute of Standards and Technology, U.S
	. Department of Commerce</organization>
	</author>
	<date month="August" year="2015"/>
	</front>
	<seriesInfo name="FIPS" value="PUB 202"/>
	</reference>
	<reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpubs/Spe
	cialPublications/NIST.SP.800-185.pdf">
	<front>
	<title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHa
	sh. NIST SP 800-185</title>
	<author>
	<organization>National Institute of Standards and Technology</organi
	zation>
	</author>
	<date month="December" year="2016" />
	</front>
	</reference>
	<!-- <reference anchor="ASN1-B"><front>
	<title>Information technology - Abstract Syntax Notation One (ASN.1): S
	pecification 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 Enc
	oding Rules (DER)</title>
	<author>
	<organization>ITU-T</organization>
	</author>
	<date year="2015"/>
	</front>
	<seriesInfo name="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. Depa
	rtment of Commerce</organization>
	</author>
	<date year="2013"/>
	</front>
	<seriesInfo name="NIST" value="FIPS PUB 186-4"/>
	</reference> -->
	</references>
	<references title="Informative References">		</references>
	&RFC3279;		</references>
	<!-- &RFC4086; -->		<section anchor="asn-app" numbered="true" toc="default">
	&RFC5753;		<name>ASN.1 Module</name>
	&RFC5911;		<t>This appendix includes the ASN.1 modules for SHAKEs in CMS.
	&RFC6268;
	&RFC6979;
	&I-D.ietf-lamps-pkix-shake;
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/refe
	rence.I-D.draft-housley-lamps-cms-sha3-hash-00.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 and Technology</organi
	zation>
	</author>
	<date month="October" year="2017" />
	</front>
	</reference>
	<reference anchor="X9.62">
	<front>
	<title>X9.62-2005 Public Key Cryptography for the Financial Services I
	ndustry: The Elliptic Curve Digital Signature Standard (ECDSA)</title>
	<author>
	<organization>American National Standard for Financial Services (ANS
	I)</organization>
	</author>
	<date month="November" year="2005" />
	</front>
	</reference>
	<reference anchor="SP800-78-4" target="https://csrc.nist.gov/csrc/media/pu
	blications/sp/800-78/4/final/documents/sp800_78-4_revised_draft.pdf">
	<front>
	<title>SP800-78-4: 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" />
	</front>
	</reference>
	<reference anchor="SP800-107" target="https://csrc.nist.gov/csrc/media/pub
	lications/sp/800-107/rev-1/final/documents/draft_revised_sp800-107.pdf">
	<front>
	<title>SP800-107: Recommendation for Applications Using Approved Hash
	Algorithms</title>
	<author>
	<organization>National Institute of Standards and Technology (NIST)<
	/organization>
	</author>
	<date month="May" year="2014" />
	</front>
	</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</organizati
	on>
	</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/nistpub
	s/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</organi
	zation>
	</author>
	<date month="June" year="2015" />
	</front>
	</reference> -->
	</references>
	<section title="ASN.1 Module" anchor="section-a">
	<t>This appendix includes the ASN.1 modules for SHAKEs in CMS.
	This module includes some ASN.1 from other standards for reference.</t>		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)		CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840)
	rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)		rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
	id-mod-cms-shakes-2019(70) }		id-mod-cms-shakes-2019(70) }
	DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		DEFINITIONS EXPLICIT TAGS ::=
	-- EXPORTS ALL;		BEGIN
	IMPORTS		-- EXPORTS ALL;
	DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS		IMPORTS
	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		DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS
	FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)		FROM AlgorithmInformation-2009
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)		{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
	id-mod-pkix1-algorithms2008-02(56) }		mechanisms(5) pkix(7) id-mod(0)
			id-mod-algorithmInformation-02(58) }
	sa-rsassapssWithSHAKE128, sa-rsassapssWithSHAKE256,		RSAPublicKey, rsaEncryption, id-ecPublicKey
	sa-ecdsaWithSHAKE128, sa-ecdsaWithSHAKE256		FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)
	FROM PKIXAlgsForSHAKE-2019 {		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	iso(1) identified-organization(3) dod(6)		id-mod-pkix1-algorithms2008-02(56) }
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkix1-shakes-2019(94) } ;
	-- Message Digest Algorithms (mda-)		sa-rsassapssWithSHAKE128, sa-rsassapssWithSHAKE256,
	-- used in SignedData, SignerInfo, DigestedData,		sa-ecdsaWithSHAKE128, sa-ecdsaWithSHAKE256
	-- and the AuthenticatedData digestAlgorithm		FROM PKIXAlgsForSHAKE-2019 {
	-- fields in CMS		iso(1) identified-organization(3) dod(6)
	--		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	-- This expands MessageAuthAlgs from [RFC5652] and		id-mod-pkix1-shakes-2019(94) } ;
	-- MessageDigestAlgs in [RFC5753]
	--
	-- MessageDigestAlgs DIGEST-ALGORITHM ::= {
	-- mda-shake128 |
	-- mda-shake256,
	-- ...
	-- }
	--		-- Message digest Algorithms (mda-)
	-- One-Way Hash Functions		-- used in SignedData, SignerInfo, DigestedData,
	-- SHAKE128		-- and the AuthenticatedData digestAlgorithm
	mda-shake128 DIGEST-ALGORITHM ::= {		-- fields in CMS
	IDENTIFIER id-shake128 -- with output length 32 bytes.		--
	}		-- This expands MessageAuthAlgs from [RFC5652] and
	id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		-- MessageDigestAlgs in [RFC5753]
	us(840) organization(1) gov(101)		--
	csor(3) nistAlgorithm(4)		-- MessageDigestAlgs DIGEST-ALGORITHM ::= {
	hashAlgs(2) 11 }		-- mda-shake128 |
			-- mda-shake256,
			-- ...
			-- }
	-- SHAKE256		--
	mda-shake256 DIGEST-ALGORITHM ::= {		-- One-Way Hash Functions
	IDENTIFIER id-shake256 -- with output length 64 bytes.		-- SHAKE128
	}		mda-shake128 DIGEST-ALGORITHM ::= {
	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		IDENTIFIER id-shake128 -- with output length 32 bytes.
	us(840) organization(1) gov(101)		}
	csor(3) nistAlgorithm(4)		id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	hashAlgs(2) 12 }		us(840) organization(1) gov(101)
			csor(3) nistAlgorithm(4)
			hashAlgs(2) 11 }
	--		-- SHAKE256
	-- Public key algorithm identifiers located in the		mda-shake256 DIGEST-ALGORITHM ::= {
	-- OriginatorPublicKey's algorithm attribute in CMS.		IDENTIFIER id-shake256 -- with output length 64 bytes.
	-- And Signature identifiers used in SignerInfo		}
	-- signatureAlgorithm field of SignedData content		id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	-- type and countersignature attribute in CMS.		us(840) organization(1) gov(101)
	--		csor(3) nistAlgorithm(4)
	-- From RFC5280, for reference.		hashAlgs(2) 12 }
	-- 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)		-- Public key algorithm identifiers located in the
	security(5) mechanisms(5) pkix(7) algorithms(6) 31 }		-- OriginatorPublicKey's algorithm attribute in CMS.
			-- And Signature identifiers used in SignerInfo
			-- signatureAlgorithm field of signed-data content
			-- type and countersignature attribute in CMS.
			--
			-- From RFC 5280, for 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 }
	-- When the id-RSASSA-PSS-* algorithm identifiers are used		id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
	-- for a public key or signature in CMS, the AlgorithmIdentifier		identified-organization(3) dod(6) internet(1)
	-- parameters field MUST be absent. The message digest algorithm		security(5) mechanisms(5) pkix(7) algorithms(6) 31 }
	-- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or
	-- 64 byte outout 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.
	-- From RFC4055, for reference.		-- When the id-RSASSA-PSS-* algorithm identifiers are used
	-- RSAPublicKey ::= SEQUENCE {		-- for a public key or signature in CMS, the AlgorithmIdentifier
	-- modulus INTEGER, -- -- n		-- parameters field MUST be absent. The message digest algorithm
	-- publicExponent INTEGER } -- -- e		-- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32- or
			-- 64-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.
	id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)		-- From RFC 4055, for reference:
	identified-organization(3) dod(6) internet(1)		-- RSAPublicKey ::= SEQUENCE {
	security(5) mechanisms(5) pkix(7) algorithms(6) 32 }		-- modulus INTEGER, -- -- n
			-- publicExponent INTEGER } -- -- e
	id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)		id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) dod(6) internet(1)		identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) algorithms(6) 33 }		security(5) mechanisms(5) pkix(7) algorithms(6) 32 }
	-- When the id-ecdsa-with-shake* algorithm identifiers are		id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
	-- used in CMS, the AlgorithmIdentifier parameters field		identified-organization(3) dod(6) internet(1)
	-- MUST be absent and the signature algorithm should be		security(5) mechanisms(5) pkix(7) algorithms(6) 33 }
	-- deterministic ECDSA [RFC6979]. The message digest MUST
	-- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout
	-- length, respectively. In both cases, the ECDSA public key,
	-- MUST be encoded using the id-ecPublicKey type.
	-- From RFC5480, for reference.		-- When the id-ecdsa-with-shake* algorithm identifiers are
	-- id-ecPublicKey OBJECT IDENTIFIER ::= {		-- used in CMS, the AlgorithmIdentifier parameters field
	-- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }		-- MUST be absent and the signature algorithm should be
	-- The id-ecPublicKey parameters must be absent or present		-- deterministic ECDSA [RFC6979]. The message digest MUST
	-- and are defined as		-- be SHAKE128 or SHAKE256 with a 32- or 64-byte output
	-- ECParameters ::= CHOICE {		-- length, respectively. In both cases, the ECDSA public key,
	-- namedCurve OBJECT IDENTIFIER		-- MUST be encoded using the id-ecPublicKey type.
	-- -- -- implicitCurve NULL
	-- -- -- specifiedCurve SpecifiedECDomain
	-- }
	-- This expands SignatureAlgorithms from [RFC5912]		-- From RFC 5480, for reference:
	--		-- id-ecPublicKey OBJECT IDENTIFIER ::= {
	-- SignatureAlgs SIGNATURE-ALGORITHM ::= {		-- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
	-- sa-rsassapssWithSHAKE128 |		-- The id-ecPublicKey parameters must be absent or present
	-- sa-rsassapssWithSHAKE256 |		-- and are defined as:
	-- sa-ecdsaWithSHAKE128 |		-- ECParameters ::= CHOICE {
	-- sa-ecdsaWithSHAKE256,		-- namedCurve OBJECT IDENTIFIER
	-- ...		-- -- -- implicitCurve NULL
	-- }		-- -- -- specifiedCurve SpecifiedECDomain
			-- }
	- }		-- This expands SignatureAlgs from [RFC5912]
	-- This expands MessageAuthAlgs from [RFC5652] and [RFC6268]		--
	--		-- SignatureAlgs SIGNATURE-ALGORITHM ::= {
	-- Message Authentication (maca-) Algorithms		-- sa-rsassapssWithSHAKE128 |
	-- used in AuthenticatedData macAlgorithm in CMS		-- sa-rsassapssWithSHAKE256 |
	--		-- sa-ecdsaWithSHAKE128 |
	MessageAuthAlgs MAC-ALGORITHM ::= {		-- sa-ecdsaWithSHAKE256,
	maca-KMACwithSHAKE128 |		-- ...
	maca-KMACwithSHAKE256,		-- }
	...
	}
	-- This expands SMimeCaps from [RFC5911]		-- This expands MessageAuthAlgs from [RFC5652] and [RFC6268]
	--		--
	SMimeCaps SMIME-CAPS ::= {		-- Message Authentication (maca-) Algorithms
	-- sa-rsassapssWithSHAKE128.&smimeCaps |		-- used in AuthenticatedData macAlgorithm in CMS
	-- sa-rsassapssWithSHAKE256.&smimeCaps |		--
	-- sa-ecdsaWithSHAKE128.&smimeCaps |		MessageAuthAlgs MAC-ALGORITHM ::= {
	-- sa-ecdsaWithSHAKE256.&smimeCaps,		maca-KMACwithSHAKE128 |
	maca-KMACwithSHAKE128.&smimeCaps |		maca-KMACwithSHAKE256,
	maca-KMACwithSHAKE256.&smimeCaps,		...
	...		}
	}
	--		-- This expands SMimeCaps from [RFC5911]
	-- KMAC with SHAKE128		--
	maca-KMACwithSHAKE128 MAC-ALGORITHM ::= {		SMimeCaps SMIME-CAPS ::= {
	IDENTIFIER id-KMACWithSHAKE128		-- sa-rsassapssWithSHAKE128.&smimeCaps |
	PARAMS TYPE KMACwithSHAKE128-params ARE optional		-- sa-rsassapssWithSHAKE256.&smimeCaps |
	-- If KMACwithSHAKE128-params parameters are absent		-- sa-ecdsaWithSHAKE128.&smimeCaps |
	-- the SHAKE128 output length used in KMAC is 256 bits		-- sa-ecdsaWithSHAKE256.&smimeCaps,
	-- and the customization string is an empty string.		maca-KMACwithSHAKE128.&smimeCaps |
	IS-KEYED-MAC TRUE		maca-KMACwithSHAKE256.&smimeCaps,
	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 ::= {		-- KMAC with SHAKE128
	IDENTIFIER id-KMACWithSHAKE256		maca-KMACwithSHAKE128 MAC-ALGORITHM ::= {
	PARAMS TYPE KMACwithSHAKE256-params ARE optional		IDENTIFIER id-KMACWithSHAKE128
	-- If KMACwithSHAKE256-params parameters are absent		PARAMS TYPE KMACwithSHAKE128-params ARE optional
	-- the SHAKE256 output length used in KMAC is 512 bits		-- If KMACwithSHAKE128-params parameters are absent,
	-- and the customization string is an empty string.		-- the SHAKE128 output length used in KMAC is 256 bits
	IS-KEYED-MAC TRUE		-- and the customization string is an empty string.
	SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE256}		IS-KEYED-MAC TRUE
	}		SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE128}
	id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		}
	country(16) us(840) organization(1)		id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	gov(101) csor(3) nistAlgorithm(4)		country(16) us(840) organization(1)
	hashAlgs(2) 20 }		gov(101) csor(3) nistAlgorithm(4)
	KMACwithSHAKE256-params ::= SEQUENCE {		hashAlgs(2) 19 }
	kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits		KMACwithSHAKE128-params ::= SEQUENCE {
	customizationString OCTET STRING DEFAULT ''H		kMACOutputLength INTEGER DEFAULT 256, -- Output length in bits
	}		customizationString OCTET STRING DEFAULT ''H
			}
	END		-- KMAC with SHAKE256
	]]></artwork></figure>		maca-KMACwithSHAKE256 MAC-ALGORITHM ::= {
	</t>		IDENTIFIER id-KMACWithSHAKE256
	</section>		PARAMS TYPE KMACwithSHAKE256-params ARE optional
			-- If KMACwithSHAKE256-params parameters are absent,
			-- 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
			}
	</back>		END ]]></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>		</rfc>
End of changes. 98 change blocks.
	980 lines changed or deleted		668 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/