Diff: rfc8692xml2.original.xml

	rfc8692xml2.original.xml	rfc8692.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!-- This template is for creating an Internet Draft using xml2rfc,	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	which is available here: http://xml.resource.org. -->
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.
	An alternate method (rfc include) is described in the references. -->

	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY RFC3279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3279.xml">
	<!-- <!ENTITY RFC3280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.3280.xml"> -->
	<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4055.xml">
	<!-- <!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.4086.xml"> -->
	<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5280.xml">
	<!ENTITY RFC5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5480.xml">
	<!ENTITY RFC5912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5912.xml">
	<!ENTITY RFC6979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6979.xml">
	<!ENTITY RFC8017 SYSTEM "http://xml.resource.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.draft-josefsson-pkix-eddsa SYSTEM "http://xml2rfc.tools.ietf.org/pu
	blic/rfc/bibxml-ids/reference.I-D.draft-josefsson-pkix-eddsa-04.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 -->
	<rfc category="std" docName="draft-ietf-lamps-pkix-shake-15" ipr="trust200902" u
	pdates="3279">
	<!-- 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)" -->


		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
		docName="draft-ietf-lamps-pkix-shake-15" submissionType="IETF" category="st
		d" consensus="yes" number="8692" ipr="trust200902" updates="3279" obsoletes="" x
		ml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" versi
		on="3">
		<!-- xml2rfc v2v3 conversion 2.35.0 -->
	<!-- *** FRONT MATTER *** -->	<!-- *** FRONT MATTER *** -->


	<front>	<front>

	<!-- The abbreviated title is used in the page header - it is only necessary	<title abbrev="SHAKE Identifiers in X.509">Internet X.509 Public Key Infrast
	if the	ructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs<
	full title is longer than 39 characters -->	/title>
		<seriesInfo name="RFC" value="8692"/>
	<title abbrev="SHAKE identifiers in X.509">Internet X.509 Public Key Infrast	<author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
	ructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs<
	/title>

	<!-- add 'role="editor"' below for the editors if appropriate -->
	<author fullname="Panos Kampanakis" initials="P.K."
	surname="Kampanakis">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>
	<address>	<address>
	<email>pkampana@cisco.com</email>	<email>pkampana@cisco.com</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Quynh Dang" initials="Q.D."	<author fullname="Quynh Dang" initials="Q." surname="Dang">
	surname="Dang">
	<organization>NIST</organization>	<organization>NIST</organization>
	<address>	<address>

	<postal>	<postal>
	<street>100 Bureau Drive, Stop 8930</street>	<street>100 Bureau Drive, Stop 8930</street>
	<city>Gaithersburg</city>	<city>Gaithersburg</city>
	<region>MD</region>	<region>MD</region>
	<code>20899-8930</code>	<code>20899-8930</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>

	<!-- <phone>+44 7889 488 335</phone> -->
	<email>quynh.dang@nist.gov</email>	<email>quynh.dang@nist.gov</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

		<date month="December" year="2019"/>
	<!-- <author fullname="Sean Turner" initials="S.T."
	surname="Turner">
	<organization>sn3rd</organization>
	<address>
	<postal>
	<street></street>
	<city>Soham</city>
	<region></region>
	<code></code>
	<country>UK</country>
	</postal>
	<phone>+44 7889 488 335</phone>
	<email>sean@sn3rd.com</email>
	</address>
	</author> -->

	<date year="2019" />

	<!-- If the month and year are both specified and are the current ones, xml2
	rfc will fill
	in the current day for you. If only the current year is specified, xml2
	rfc will fill
	in the current day and month for you. If the year is not the current one
	, it is
	necessary to specify at least a month (xml2rfc assumes day="1" if not sp
	ecified for the
	purpose of calculating the expiry date). With drafts it is normally suf
	ficient to
	specify just the year. -->

	<!-- Meta-data Declarations -->

	<area>General</area>	<area>General</area>
	<workgroup>LAMPS WG</workgroup>	<workgroup>LAMPS WG</workgroup>


	<!-- WG name at the upperleft corner of the doc,	<keyword>SHAKE in X.509, SHAKEs in PKIX, certificates with SHAKE hashes</key
	IETF is fine for individual submissions.	word>
	If this element is not present, the default is "Network Working Group",
	which is used by the RFC Editor as a nod to the history of the IETF. --
	>

	<!-- <keyword>template</keyword> -->

	<!-- Keywords will be incorporated into HTML output
	files in a meta tag but they have no effect on text or nroff
	output. If you submit your draft to the RFC Editor, the
	keywords will be used for the searPKIch engine. -->

	<abstract>	<abstract>
	<t>Digital signatures are used to sign messages, X.509	<t>Digital signatures are used to sign messages, X.509

	certificates and CRLs. This document updates the	certificates, and Certificate Revocation Lists (CRLs). This document up dates the
	"Algorithms and Identifiers for the Internet	"Algorithms and Identifiers for the Internet
	X.509 Public Key Infrastructure Certificate and	X.509 Public Key Infrastructure Certificate and

	Certificate Revocation List Profile" (RFC3279)	Certificate Revocation List (CRL) Profile" (RFC 3279)
	and describes the conventions for using the SHAKE function	and describes the conventions for using the SHAKE function
	family in Internet X.509 certificates and revocation lists	family in Internet X.509 certificates and revocation lists
	as one-way hash functions with the RSA Probabilistic signature	as one-way hash functions with the RSA Probabilistic signature

	and ECDSA signature algorithms. The conventions for the	and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algori thms. The conventions for the
	associated subject public keys are also described.</t>	associated subject public keys are also described.</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

		<section numbered="true" toc="default">
	<section title="Change Log">	<name>Introduction</name>
	<t>[ EDNOTE: Remove this section before publication. ]</t>	<t><xref target="RFC3279" format="default"/> defines cryptographic algorit
	<t><list style="symbols">	hm
	<t>draft-ietf-lamps-pkix-shake-15:	identifiers for the "Internet X.509 Public Key Infrastructure Certificate
	<list>	and Certificate Revocation List (CRL) Profile"
	<t>Minor editorial nits.</t>	<xref target="RFC5280" format="default"/>. This document updates RFC 3279
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-14:
	<list>
	<t>Fixing error with incorrect preimage resistance bits for SHA
	128 and SHA256.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-13:
	<list>
	<t>Addressing one applicable comment from Dan M. about sec leve
	ls while in secdir review of draft-ietf-lamps-cms-shakes.</t>
	<t>Addressing comment from Scott B.'s opsdir review about refer
	ences in the abstract.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-12:
	<list>
	<t>Nits identified by Roman, Eric V. Ben K., Barry L. in ballot
	position review.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-11:
	<list>
	<t>Nits identified by Roman in AD Review.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-10:
	<list>
	<t>Updated IANA considerations section to request for OID assig
	nments. </t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-09:
	<list>
	<t>Fixed minor text nits.</t>
	<t>Added text name allocation for SHAKEs in IANA considerations
	.</t>
	<t>Updates in Sec Considerations section.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-08:
	<list>
	<t>Small nits from Russ while in WGLC.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-07:
	<list>
	<t>Incorporated Eric's suggestion from WGLC.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-06:
	<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-pkix-shake-05:
	<list>
	<t>Added RFC8174 reference and text.</t>
	<t>Explicitly explained why RSASSA-PSS-params are omitted in se
	ction 5.1.1.</t>
	<t>Simplified Public Keys section by removing redundant info fr
	om RFCs.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-04:
	<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>Various ASN.1 fixes.</t>
	<t>Text fixes.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-03:
	<list>
	<t>Updates based on suggestions and clarifications by Jim. </t>
	<t>Added ASN.1.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-02:
	<list>
	<t>Significant reorganization of the sections to simplify the i
	ntroduction, the new OIDs and their use in PKIX.</t>
	<t>Added new OIDs for RSASSA-PSS that hardcode hash, salt and M
	GF, according the WG consensus.</t>
	<t>Updated Public Key section to use the new RSASSA-PSS OIDs an
	d clarify the algorithm identifier usage.</t>
	<t>Removed the no longer used SHAKE OIDs from section 3.1.</t>
	<t>Consolidated subsection for message digest algorithms.</t>
	<t>Text fixes.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-01:
	<list>
	<t>Changed titles and section names.</t>
	<t>Removed DSA after WG discussions.</t>
	<t>Updated shake OID names and parameters, added MGF1 section.<
	/t>
	<t>Updated RSASSA-PSS section.</t>
	<t>Added Public key algorithm OIDs.</t>
	<t>Populated Introduction and IANA sections.</t>
	</list></t>
	<t>draft-ietf-lamps-pkix-shake-00:
	<list>
	<t>Initial version</t>
	</list></t>
	</list></t>
	</section>

	<section title="Introduction">
	<t><xref target="RFC3279"/> defines cryptographic algorithm
	identifiers for the Internet X.509 Certificate and Certificate Revocati
	on
	Lists (CRL) profile <xref target="RFC5280"/>. This document updates RFC
	3279
	and defines identifiers for several cryptographic algorithms that use	and defines identifiers for several cryptographic algorithms that use

	variable length output SHAKE functions introduced in <xref target="SHA3	variable-length output SHAKE functions introduced in
	"/>	<xref target="SHA3" format="default"/>
	which can be used with . </t>	which can be used with RFC 5280.</t>

	<t>In the SHA-3 family, two extendable-output functions (SHAKEs),
	SHAKE128 and SHAKE256, 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
	document.
	A SHAKE is a variable length hash function defined as SHAKE(M, d) where
	the
	output is a d-bits-long digest of message M. The corresponding collisio
	n and second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and mi
	n(d,128)
	bits, respectively (Appendix A.1 <xref target="SHA3"/>).
	And the corresponding collision and second-preimage-resistance strength
	s for SHAKE256
	are min(d/2,256) and min(d,256) bits, respectively.</t>


	<t>A SHAKE can be used as the message digest function (to hash the mess	<t>In the SHA-3 family, two extendable-output functions (SHAKEs)
	age to be signed)	are defined: SHAKE128 and SHAKE256. Four other hash function
	in RSASSA-PSS <xref target="RFC8017"/> and ECDSA <xref target="X9.62"/>	instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also
		defined but are out of scope for this document. A SHAKE is a
		variable-length hash function defined as SHAKE(M, d) where the
		output is a d-bits-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 (see Appendix A.1 of
		<xref 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.</t>
		<t>A SHAKE can be used as the message digest function (to hash the message
		to be signed)
		in RSA Probabilistic Signature Scheme (RSASSA-PSS) <xref target="RFC801
		7" format="default"/> and ECDSA <xref target="X9.62" format="default"/>
	and as the hash in the mask generation function (MGF) in RSASSA-PSS.	and as the hash in the mask generation function (MGF) in RSASSA-PSS.

	<!-- This specification describes the identifiers for SHAKEs to be used	</t>
	in X.509 and their
	meaning.--> </t>
	</section>	</section>

	<!-- This PI places the pagebreak correctly (before the section title) in th	<section anchor="terminology" numbered="true" toc="default">
	e text output. -->	<name>Terminology</name>
		<t>
	<section anchor="terminology" title="Terminology">	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	when, and only when, they appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	</section> <!-- Terminology -->	be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
	<?rfc needLines="8" ?>	target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
	<section title="Identifiers" anchor="oids">	</t>
	<!-- Commention out the below OIDs as they are no longer pertinent for	</section>
	the below public keys and sigs -->	<!-- Terminology -->
	<!-- The Object Identifiers (OIDs) for these two hash functions are def	<section anchor="oids" numbered="true" toc="default">
	ined in	<name>Identifiers</name>
	<xref target="shake-nist-oids"/> and are included here for convenience:	<t>This section defines four new object identifiers (OIDs), for RSASSA-PSS
	</t>	and ECDSA with each

	<t><figure><artwork><![CDATA[
	id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)
	nistalgorithm(4) hashalgs(2) 17 }

	ShakeOutputLen ::= INTEGER - - Output length in octets
	]]></artwork></figure></t>
	<t>When using the id-shake128-len algorithm identifier, the parameters
	MUST be present, and they MUST employ the ShakeOutputLen -->
	<!-- "MUST employ syntax borrowed from RFC4055 -->
	<!-- syntax that contains an encoded positive integer value at least 32
	in this specification.</t>
	<t><figure><artwork><![CDATA[
	id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)
	nistalgorithm(4) hashalgs(2) 18 }

	ShakeOutputLen ::= INTEGER - - Output length in octets
	]]></artwork></figure></t>
	<t>When using the id-shake256-len algorithm identifier, the parameters
	MUST be present, and they MUST employ the ShakeOutputLen -->
	<!-- "MUST employ syntax borrowed from RFC4055 -->
	<!-- syntax that contains an encoded positive integer value at least 64
	in this specification.</t> -->

	<t>This section defines four new object identifiers (OIDs), for RSASSA-
	PSS and ECDSA with each
	of SHAKE128 and SHAKE256. The same algorithm identifiers can be	of SHAKE128 and SHAKE256. The same algorithm identifiers can be
	used for identifying a public key in RSASSA-PSS.</t>	used for identifying a public key in RSASSA-PSS.</t>

		<t>The new identifiers for RSASSA-PSS signatures using SHAKEs are below.</
	<t>The new identifiers for RSASSA-PSS signatures using SHAKEs are below	t>
	.</t>	<sourcecode type="asn.1"><![CDATA[

	<t><figure><artwork><![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)	security(5) mechanisms(5) pkix(7) algorithms(6)

	TBD1 }	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)	security(5) mechanisms(5) pkix(7) algorithms(6)

	TBD2 }	31 }
	]]></artwork></figure></t>	]]></sourcecode>
		<t>The new algorithm identifiers of ECDSA signatures using SHAKEs are belo
		w.


	<t>The new algorithm identifiers of ECDSA signatures using SHAKEs are b	</t>
	elow.</t>	<sourcecode type="asn.1"><![CDATA[
	<t><list>
	<t><figure><artwork><![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)	security(5) mechanisms(5) pkix(7) algorithms(6)

	TBD3 }	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)	security(5) mechanisms(5) pkix(7) algorithms(6)

	TBD4 }	33 }
	]]></artwork></figure></t>	]]></sourcecode>
	</list></t>	<t>The parameters for the four identifiers above <bcp14>MUST</bcp14> be ab
		sent. That is,
	<!-- <xref target="RFC8017"/>, but we include it here as well for conve	the identifier <bcp14>SHALL</bcp14> be a SEQUENCE of one component: the
	nience:</t>	OID.</t>
	<t><figure><artwork><![CDATA[	<t>Sections <xref target="rsa-sigs" format="counter"/> and <xref target="e
	id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }	cdsa-sigs" format="counter"/> specify the required output length
	]]></artwork></figure>-->
	<!-- <t>The parameters field associated with id-mgf1 MUST have a hashAl
	gorithm 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="xofs"
	/> above. </t>-->

	<t>The parameters for the four identifiers above MUST be absent. That i
	s,
	the identifier SHALL be a SEQUENCE of one component, the OID.</t>
	<t><xref target="rsa-sigs"/> and <xref target="ecdsa-sigs"/> specify th
	e required output length
	for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In summar y, when hashing messages	for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In summar y, when hashing messages

	to be signed, output lengths of SHAKE128 and SHAKE256 are 256 and 512 bits	to be signed, output lengths of SHAKE128 and SHAKE256 are 256 and 512 b
	respectively.	its, respectively.
	When the SHAKEs are used as mask generation functions RSASSA-PSS, their
	output length is
	(8ceil((n-1)/8) - 264) or (8ceil((n-1)/8) - 520) bits, respectively,
	where n is the RSA modulus size in bits.</t>
	</section>

	<section title="Use in PKIX">


	<section title="Signatures" anchor="sigs">	When the SHAKEs are used as MGFs in RSASSA-PSS, their output length is
		(8ceil((n-1)/8) - 264) or (8ceil((n-1)/8) - 520) bits, respectively,
		where n is the RSA modulus size in bits.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Use in PKIX</name>
		<section anchor="sigs" numbered="true" toc="default">
		<name>Signatures</name>


	<t>Signatures are used in a number of different ASN.1 structures.	<t>Signatures are used in a number of different ASN.1 structures.
	As shown in the ASN.1 representation from <xref target="RFC5280"/>	As shown in the ASN.1 representation from <xref target="RFC5280" format=
		"default"/>
	below, in an X.509 certificate, a signature is encoded with an	below, in an X.509 certificate, a signature is encoded with an
	algorithm identifier in the signatureAlgorithm attribute and	algorithm identifier in the signatureAlgorithm attribute and
	a signatureValue attribute that contains the actual signature.	a signatureValue attribute that contains the actual signature.

	</t>	</t>
	<t><figure><artwork><![CDATA[	<sourcecode type="asn.1"><![CDATA[
	Certificate ::= SEQUENCE {	Certificate ::= SEQUENCE {
	tbsCertificate TBSCertificate,	tbsCertificate TBSCertificate,
	signatureAlgorithm AlgorithmIdentifier,	signatureAlgorithm AlgorithmIdentifier,
	signatureValue BIT STRING }	signatureValue BIT STRING }

	]]></artwork></figure></t>	]]></sourcecode>
		<t>The identifiers defined in <xref target="oids" format="default"/> can
	<t>The identifiers defined in <xref target="oids"/> can be used	be used
	as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence	as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence
	Certificate and the signature field in the sequence TBSCertificat e in X.509	Certificate and the signature field in the sequence TBSCertificat e in X.509

	<xref target="RFC5280"/>.	<xref target="RFC5280" format="default"/>.
	The parameters of these signature algorithms are absent as explai	The parameters of these signature algorithms are absent, as expla
	ned	ined
	in <xref target="oids"/>.</t>	in <xref target="oids" format="default"/>.</t>
		<t>Conforming Certification Authority (CA) implementations <bcp14>MUST</
	<t>Conforming CA implementations MUST specify the algorithms	bcp14> specify the algorithms
	explicitly by using the OIDs specified in <xref target="oids"/> w	explicitly by using the OIDs specified in <xref target="oids" for
	hen	mat="default"/> when
	encoding RSASSA-PSS or ECDSA with SHAKE signatures	encoding RSASSA-PSS or ECDSA with SHAKE signatures
	in certificates and CRLs.	in certificates and CRLs.
	Conforming client implementations that process certificates and C RLs	Conforming client implementations that process certificates and C RLs

	using RSASSA-PSS or ECDSA with SHAKE MUST recognize the correspon ding OIDs.	using RSASSA-PSS or ECDSA with SHAKE <bcp14>MUST</bcp14> recogniz e the corresponding OIDs.
	Encoding rules for RSASSA-PSS and ECDSA	Encoding rules for RSASSA-PSS and ECDSA

	signature values are specified in <xref target="RFC4055"/> and	signature values are specified in <xref target="RFC4055" format="
	<xref target="RFC5480"/>, respectively.</t>	default"/> and
		<xref target="RFC5480" format="default"/>, respectively.</t>
	<t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and EC	<t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA
	DSA	curve order <bcp14>SHOULD</bcp14> be chosen in line with the SHAK
	curve order SHOULD be chosen in line with the SHAKE output length	E output length.
	.	Refer to <xref target="Security" format="default"/> for more deta
	Refer to <xref target="Security"/> for more details.</t>	ils.</t>
		<section anchor="rsa-sigs" numbered="true" toc="default">
		<name>RSASSA-PSS Signatures</name>
		<t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017" forma
		t="default"/>.
		When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 (specifie
		d in <xref target="oids" format="default"/>)
		is used, the encoding <bcp14>MUST</bcp14> omit the parameters f
		ield. That is,
		the AlgorithmIdentifier <bcp14>SHALL</bcp14> be a SEQUENCE of o
		ne component:
		id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256.


	<section title="RSASSA-PSS Signatures" anchor="rsa-sigs">	<xref target="RFC4055" format="default"/>
	<t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017	defines RSASSA-PSS-params that is used to define the algorithms
	"/>.	and inputs
	When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified
	in <xref target="oids"/>
	is used, the encoding MUST omit the parameters field. That is,
	the AlgorithmIdentifier SHALL be a SEQUENCE of one component,
	id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref target=
	"RFC4055"/>
	defines RSASSA-PSS-params that are used to define the algorithm
	s and inputs
	to the algorithm. This specification does not use parameters be cause the	to the algorithm. This specification does not use parameters be cause the

	hash, mask generation algorithm, trailer and salt are embedded in	hash, mask generation algorithm, trailer, and salt are embedded in
	the OID definition.</t>	the OID definition.</t>

		<t>The hash algorithm to hash a message being signed and the hash algo
	<t>The hash algorithm to hash a message being signed and the ha	rithm used as the
	sh algorithm used as the	MGF
	mask generation function <!-- "MGF(H, emLen - hLen - 1)" <xref	in RSASSA-PSS <bcp14>MUST</bcp14> be the same: both SHAKE128 or
	target="RFC8017"/> -->	both SHAKE256. The
	in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256.	output length of the hash algorithm that hashes the message <bc
	The	p14>SHALL</bcp14> be 32 bytes
	output length of the hash algorithm which hashes the message SH
	ALL be 32
	(for SHAKE128) or 64 bytes (for SHAKE256). </t>	(for SHAKE128) or 64 bytes (for SHAKE256). </t>

	<t>The mask generation function takes an octet string of variab	<t>The MGF takes an octet string of variable length and
	le length and	a desired output length as input and outputs an octet
	a desired output length as input, and outputs an octet	string of the desired length. In RSASSA-PSS with SHAKEs, the SH
	string of the desired length. In RSASSA-PSS with SHAKEs, the SH	AKEs <bcp14>MUST</bcp14> be
	AKEs MUST be	used natively as the MGF, instead of the MGF1 algorithm that us
	used natively as the MGF function, instead of the MGF1 algorith	es
	m that uses	the hash function in multiple iterations, as specified in
	the hash function in multiple iterations as specified in Sectio	<xref target="RFC8017" section="B.2.1" sectionFormat="of"/>. In
	n B.2.1 of	other words, the MGF is defined as
	<xref target="RFC8017"/>. In other words, the MGF is defined as
	<!-- <t><figure><artwork><![CDATA[
	SHAKE128(mgfSeed, maskLen)
	]]></artwork></figure>
	and
	<figure><artwork><![CDATA[
	SHAKE256(mgfSeed, maskLen)
	]]></artwork></figure></t> -->
	the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-SHAKE 128 and	the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-SHAKE 128 and

	id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the seed	id-RSASSA-PSS-SHAKE256, respectively.
	from which mask is generated, an octet string <xref target="RFC
	8017"/>.	The mgfSeed is the seed
	As explained in Step 9 of section 9.1.1 of <xref target="RFC801	from which the mask is generated, an octet string <xref target=
	7"/>, the output	"RFC8017" format="default"/>.
		As explained in Step 9 of <xref
		target="RFC8017" sectionFormat="of" section="9.1.1"/>, the outp
		ut
	length of the MGF is emLen - hLen - 1 bytes. emLen is the maxim um message	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	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,	64 bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256,
	respectively.	respectively.
	Thus when SHAKE is used as the MGF, the SHAKE output length mas	Thus, when SHAKE is used as the MGF, the SHAKE output length ma
	kLen is	skLen is
	(8emLen - 264) or (8emLen - 520) bits, respectively. For exam	(8emLen - 264) or (8emLen - 520) bits, respectively.
	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	For example, when RSA modulus n is 2048 bits,
	-SHAKE128	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 <bcp14>MUST</bcp14> be 32 bytes for id-RS
		ASSA-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	Finally, the trailerField <bcp14>MUST</bcp14> be 1, which repre
	the trailer field with hexadecimal value 0xBC <xref target="RFC	sents
	8017"/>.</t>	the trailer field with hexadecimal value 0xBC <xref target="RFC
	<!-- <t><figure><artwork><![CDATA[	8017" format="default"/>.</t>
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 k }	</section>
		<section anchor="ecdsa-sigs" numbered="true" toc="default">
	RSASSA-PSS-params ::= SEQUENCE {	<name>ECDSA Signatures</name>
	hashAlgorithm HashAlgorithm,	<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined i
	maskGenAlgorithm MaskGenAlgorithm,	n
	saltLength INTEGER,	<xref target="X9.62" format="default"/>. When the id-ecdsa-with-sha
	trailerField INTEGER }	ke128 or id-ecdsa-with-shake256
	]]></artwork></figure></t> -->	(specified in <xref target="oids" format="default"/>) algorithm
		identifier appears, the respective SHAKE
	<!-- <section title="EdDSA with SHAKE">
	<t>[ EDNOTE: For the group to decide: pre-hash version or non-prehash
	version EdDSAs. PureEdDSA, the pre-hashed version of EdDSA, as currently also pr
	oposed in draft-ietf-curdle-cms-eddsa-signatures mandates the hash function as S
	HA512 for Ed25519 and SHAKE256(x,64) for Ed448. The HashEdDSA version of EdDSA d
	oes not define the hash. It is up to the WG to go the Pre-hash route which would
	require an OID that contained the hash. ] </t>
	<t>
	<list>
	<t><figure><artwork><![CDATA[
	id-eddsa-with-shake128 OBJECT IDENTIFIER ::= { }
	]]></artwork></figure></t>
	<t><figure><artwork><![CDATA[
	id-eddsa-with-shake256 OBJECT IDENTIFIER ::= { }
	]]></artwork></figure></t>
	</list></t>
	</section> -->
	</section>

	<section title="ECDSA Signatures" anchor="ecdsa-sigs">
	<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is define
	d in
	<xref target="X9.62"/>. When the id-ecdsa-with-shake128 or id-ecdsa
	-with-shake256
	(specified in <xref target="oids"/>) algorithm identifier appea
	rs, the respective SHAKE
	function (SHAKE128 or SHAKE256) is used as the hash.	function (SHAKE128 or SHAKE256) 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 specification	<t>For simplicity and compliance with the ECDSA standard specification
	,	<xref target="X9.62" format="default"/>,
	the output length of the hash function must be explicitly determine d. The	the output length of the hash function must be explicitly determine d. The

	output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 25 6 or 512	output length, d, for SHAKE128 or SHAKE256 used in ECDSA <bcp14>MUS T</bcp14> be 256 or 512
	bits, respectively. </t>	bits, respectively. </t>

		<t>Conforming CA implementations that generate ECDSA with SHAKE signat
		ures
		in certificates or CRLs <bcp14>SHOULD</bcp14> generate such sig
		natures 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 y, can	SHAKE256 with output length being 32 and 64 octets, respectivel y, can

	be used instead of 256 and 512-bit output hash algorithms such as SHA256	be used instead of 256- and 512-bit output hash algorithms such as SHA256
	and SHA512.</t>	and SHA512.</t>

		</section>
	<!-- <t>In Section 3.2 "Generation of k" of <xref target="RFC69	</section>
	79"/>, HMAC is used to derive	<section numbered="true" toc="default">
	the deterministic k. Conforming implementations that generate d	<name>Public Keys</name>
	eterministic	<t>Certificates conforming to <xref target="RFC5280" format="default"/>
	ECDSA with SHAKE signatures in X.509 MUST use KMAC with SHAKE12	can convey a
	8 or KMAC with
	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>Certificates conforming to <xref target="RFC5280"/> can convey a
	public key for any public key algorithm. The certificate indicate s	public key for any public key algorithm. The certificate indicate s

	the public key algorithm through an algorithm identifier. This al	the public key algorithm through an algorithm identifier.
	gorithm
	identifier is an OID and optionally associated parameters.
	The conventions and encoding for RSASSA-PSS and ECDSA <!-- and Ed
	DSA -->
	public keys algorithm identifiers are as specified in
	Section 2.3.1 and 2.3.5 of <xref target="RFC3279"/>,
	Section 3.1 of <xref target="RFC4055"/>
	and Section 2.1 of <xref target="RFC5480"/>.
	<!-- and <xref target="I-D.josefsson-pkix-eddsa"/>--></t>


	<t>Traditionally, the rsaEncryption object identifier is used to	This algorithm identifier is an OID with optionally associated
		parameters. The conventions and encoding for RSASSA-PSS and
		ECDSA public key algorithm identifiers are as specified in
		Sections <xref target="RFC3279" section="2.3.1"
		sectionFormat="bare"/> and <xref target="RFC3279"
		section="2.3.5" sectionFormat="bare"/> of <xref
		target="RFC3279" format="default"/>,
		<xref target="RFC4055" sectionFormat="of" section="3.1"/>
		and <xref 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	identify RSA public keys. The rsaEncryption object identifier
	continues to identify the subject public key when the RSA private	continues to identify the subject 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	exclusively to RSASSA-PSS with SHAKEs. When the RSA private
	key owner wishes to limit the use of the public key exclusively	key owner wishes to limit the use of the public key exclusively
	to RSASSA-PSS with SHAKEs, the AlgorithmIdentifiers for	to RSASSA-PSS with SHAKEs, the AlgorithmIdentifiers for

	RSASSA-PSS defined in <xref target="oids"/> SHOULD be used as the	RSASSA-PSS defined in <xref target="oids" format="default"/> <bcp
	algorithm	14>SHOULD</bcp14> be used as the algorithm
	field in the SubjectPublicKeyInfo sequence <xref target="RFC5280"	field in the SubjectPublicKeyInfo sequence <xref target="RFC5280"
	/>.	format="default"/>.
	Conforming client implementations that process RSASSA-PSS	Conforming client implementations that process RSASSA-PSS

	with SHAKE public keys when processing certificates and CRLs MUST	with SHAKE public keys when processing certificates and CRLs <bcp 14>MUST</bcp14>
	recognize the corresponding OIDs. </t>	recognize the corresponding OIDs. </t>

		<t>Conforming CA implementations <bcp14>MUST</bcp14> specify the X.509 p
	<t>Conforming CA implementations MUST specify the X.509 public ke	ublic key
	y	algorithm explicitly by using the OIDs specified in <xref target=
	algorithm explicitly by using the OIDs specified in <xref target=	"oids" format="default"/>
	"oids"/>
	when encoding ECDSA with SHAKE public keys in certificates and CR Ls.	when encoding ECDSA with SHAKE public keys in certificates and CR Ls.
	Conforming client implementations that process ECDSA with	Conforming client implementations that process ECDSA with

	SHAKE public keys when processing certificates and CRLs MUST reco gnize	SHAKE public keys when processing certificates and CRLs <bcp14>MU ST</bcp14> recognize
	the corresponding OIDs. </t>	the corresponding OIDs. </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>
		<section anchor="IANA" numbered="true" toc="default">
	</section>	<name>IANA Considerations</name>
		<t>One object identifier for the ASN.1 module in <xref target="asn" format
	<section anchor="IANA" title="IANA Considerations">	="default"/>
	<t>One object identifier for the ASN.1 module in <xref target="asn"/>	has been assigned in the "SMI Security for PKIX Module Identifier"
	is requested for the SMI Security for PKIX Module Identifiers
	(1.3.6.1.5.5.7.0) registry: </t>	(1.3.6.1.5.5.7.0) registry: </t>

	<texttable>	<table align="center">
	<ttcol align='center'>Decimal</ttcol>	<thead>
	<ttcol align='center'>Description</ttcol>	<tr>
	<ttcol align='center'>References</ttcol>	<th align="center">Decimal</th>
	<c>TBD</c>	<th align="center">Description</th>
	<c>id-mod-pkix1-shakes-2019</c>	<th align="center">References</th>
	<c>[EDNOTE: THIS RFC]</c>	</tr>
	</texttable>	</thead>
		<tbody>
	<t>IANA is requested to update the	<tr>
	SMI Security for PKIX Algorithms <xref target="SMI-PKIX"/>	<td align="center">94</td>
	(1.3.6.1.5.5.7.6) registry with four additional entries: </t>	<td align="center">id-mod-pkix1-shakes-2019</td>
	<texttable>	<td align="center">RFC 8692</td>
	<ttcol align='center'>Decimal</ttcol>	</tr>
	<ttcol align='center'>Description</ttcol>	</tbody>
	<ttcol align='center'>References</ttcol>	</table>
	<c>TBD1</c>	<t>IANA has updated the
	<c>id-RSASSA-PSS-SHAKE128</c>	"SMI Security for PKIX Algorithms"
	<c>[EDNOTE: THIS RFC]</c>	(1.3.6.1.5.5.7.6) registry <xref target="SMI-PKIX"
	<c>TBD2</c>	format="default"/> with four additional entries: </t>
	<c>id-RSASSA-PSS-SHAKE256</c>	<table align="center">
	<c>[EDNOTE: THIS RFC]</c>	<thead>
	<c>TBD3</c>	<tr>
	<c>id-ecdsa-with-shake128</c>	<th align="center">Decimal</th>
	<c>[EDNOTE: THIS RFC]</c>	<th align="center">Description</th>
	<c>TBD4</c>	<th align="center">References</th>
	<c>id-ecdsa-with-shake256</c>	</tr>
	<c>[EDNOTE: THIS RFC]</c>	</thead>
	</texttable>	<tbody>
		<tr>
	<t>IANA is also requested to update the	<td align="center">30</td>
	Hash Function Textual Names Registry <xref target="Hash-Texts"/>	<td align="center">id-RSASSA-PSS-SHAKE128</td>
		<td align="center">RFC 8692</td>
		</tr>
		<tr>
		<td align="center">31</td>
		<td align="center">id-RSASSA-PSS-SHAKE256</td>
		<td align="center">RFC 8692</td>
		</tr>
		<tr>
		<td align="center">32</td>
		<td align="center">id-ecdsa-with-shake128</td>
		<td align="center">RFC 8692</td>
		</tr>
		<tr>
		<td align="center">33</td>
		<td align="center">id-ecdsa-with-shake256</td>
		<td align="center">RFC 8692</td>
		</tr>
		</tbody>
		</table>
		<t>IANA has updated the
		"Hash Function Textual Names" registry <xref target="Hash-Texts" format
		="default"/>
	with two additional entries for SHAKE128	with two additional entries for SHAKE128
	and SHAKE256: </t>	and SHAKE256: </t>

	<texttable>	<table align="center">
	<ttcol align='center'>Hash Function Name</ttcol>	<thead>
	<ttcol align='center'>OID</ttcol>	<tr>
	<ttcol align='center'>Reference</ttcol>	<th align="center">Hash Function Name</th>
	<c>shake128</c>	<th align="center">OID</th>
	<c>2.16.840.1.101.3.4.2.11</c>	<th align="center">Reference</th>
	<c>[EDNOTE: THIS RFC]</c>	</tr>
	<c>shake256</c>	</thead>
	<c>2.16.840.1.101.3.4.2.12</c>	<tbody>
	<c>[EDNOTE: THIS RFC]</c>	<tr>
	</texttable>	<td align="center">shake128</td>
		<td align="center">2.16.840.1.101.3.4.2.11</td>
		<td align="center">RFC 8692</td>
		</tr>
		<tr>
		<td align="center">shake256</td>
		<td align="center">2.16.840.1.101.3.4.2.12</td>
		<td align="center">RFC 8692</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
		<t>This document updates <xref target="RFC3279" format="default"/>. The Se
	<t>This document updates <xref target="RFC3279"/>. The security conside	curity Considerations
	rations
	section of that document applies to this specification as well.</t>	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
	<t>NIST has defined appropriate use of the hash functions in terms of t	algorithm
	he algorithm
	strengths and expected time frames for secure use in Special Publications (SPs)	strengths and expected time frames for secure use in Special Publications (SPs)

	<xref target="SP800-78-4"/> and <xref target="SP800-107"/>.	<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	These documents can be used as guides to choose appropriate key sizes
	for various security scenarios. </t>	for various security scenarios. </t>

		<t>SHAKE128 with output length of 256 bits offers 128 bits
	<!-- <t>The SHAKEs are deterministic functions. Like any other determinist	of collision and preimage resistance. Thus, SHAKE128 OIDs in
	ic function,	this specification are <bcp14>RECOMMENDED</bcp14> with 2048- (112-bit
	executing multiple times with the same input will produce the	security) or 3072-bit (128-bit security) RSA modulus or
	same output. Therefore, users should not expect unrelated outputs (with	curves with group order of 256 bits (128-bit
	the	security). SHAKE256 with a 512-bit output length offers
	same or different output lengths) from running a SHAKE function with th	256 bits of collision and preimage resistance. Thus, the
	e	SHAKE256 OIDs in this specification are <bcp14>RECOMMENDED</bcp14> with
	same input multiple times. The shorter of any two outputs produced from	4096-bit RSA modulus or higher or curves with a group order of
	a	at least 512 bits, such as the NIST Curve P-521 (256-bit
	SHAKE with the same input is a prefix of the longer one. It is a simila	security). Note that we recommended a 4096-bit RSA because we
	r	would need a 15360-bit modulus for 256 bits of security, which
	situation as truncating a 512-bit output of SHA-512 by taking its 256	is impractical for today's technology.</t>
	left-most bits. These 256 left-most bits are a prefix of the 512-bit ou
	tput.</t> -->

	<!-- <t>Implementations must protect the signer's private key. Compromi
	se of
	the signer's private key permits masquerade attacks.</t> -->

	<!-- <t>Implementations must randomly generate 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 brea
	k a
	particular cryptographic algorithm may decrease. Therefore, cryptograph
	ic
	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> -->

	<t>SHAKE128 with output length of 256-bits 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 512-bits 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 521-bits (256-bit security). Note tha
	t we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bi
	ts of security which is impractical for today's technology.</t>

	</section>

	<!-- Possibly a 'Contributors' section ... -->
	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>We would like to thank Sean Turner, Jim Schaad and Eric
	Rescorla for their valuable contributions to this document.</t>
	<t>The authors would like to thank Russ Housley for his guidance and
	very valuable contributions with the ASN.1 module.</t>
	</section>	</section>
	</middle>	</middle>


	<!-- ***BACK MATTER *** -->	<!-- ***BACK MATTER *** -->


	<back>	<back>

	<!-- References split into informative and normative -->	<references>
		<name>References</name>
	<!-- There are 2 ways to insert reference entries from the citation librarie	<references>
	s:	<name>Normative References</name>
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	(as shown)	ence.RFC.2119.xml"/>
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	l"?> here	ence.RFC.3279.xml"/>
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	xml")	ence.RFC.8174.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Both are cited textually in the same manner: by using xref elements.	ence.RFC.4055.xml"/>
	If you use the PI option, xml2rfc will, by default, try to find included fi	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	les in the same	ence.RFC.5280.xml"/>
	directory as the including file. You can also define the XML_LIBRARY enviro	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	nment variable	ence.RFC.5480.xml"/>
	with a value containing a set of directories to search. These can be eithe	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	r in the local	ence.RFC.8017.xml"/>
	filing system or remote ones accessed by http (http://domain/dir/... ).-->	<reference anchor="SHA3">
		<front>
	<references title="Normative References">	<title>
	<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.	SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
	2119.xml"?-->	</title>
	&RFC2119;	<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
	&RFC3279;	<seriesInfo name="FIPS PUB" value="202"/>
	&RFC8174;	<author>
	<!-- &RFC3280; -->	<organization>
	&RFC4055;	National Institute of Standards and Technology
	&RFC5280;	</organization>
	&RFC5480;	</author>
	&RFC8017; <!-- RFC8017 is Informational draft but we are keeping it in	<date year="2015" month="August"/>
	the Normative References even though idnits complains because we need a normativ	</front>
	e reference for RSASSA-PSS. RFC4056 does the same thing with RSASS-PSS v2.1 -->	</reference>
	<!-- <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids	</references>
	/reference.I-D.draft-josefsson-pkix-eddsa-04.xml"?> -->	<references>
	<reference anchor="SHA3" target="https://www.nist.gov/publications/sha-3-s	<name>Informative References</name>
	tandard-permutation-based-hash-and-extendable-output-functions">	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<front>	ence.RFC.5912.xml"/>
	<title>SHA-3 Standard - Permutation-Based Hash and Extendable-Output F	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	unctions FIPS PUB 202</title>	ence.RFC.6979.xml"/>
	<author>	<reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
	<organization>National Institute of Standards and Technology (NIST)<	<front>
	/organization>	<title>SEC 1: Elliptic Curve Cryptography</title>
	</author>	<author>
	<date month="August" year="2015" />	<organization>Standards for Efficient Cryptography Group</organiza
	</front>	tion>
	</reference>	</author>
	</references>	<date month="May" year="2009"/>
		</front>
	<references title="Informative References">	</reference>
	<!-- Here we use entities that we defined at the beginning. -->	<reference anchor="X9.62">
	<!--&RFC2629; -->	<front>
	&RFC5912;	<title>Public Key Cryptography for the Financial Services Industry:
	&RFC6979;	the
	<!-- &RFC4086; -->	Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
	<!--<reference anchor="shake-nist-oids" target="https://csrc.nist.gov/Proj	<seriesInfo name="ANSI" value="X9.62"/>
	ects/Computer-Security-Objects-Register/Algorithm-Registration">	<author>
	<front>	<organization>ANSI</organization>
	<title>Computer Security Objects Register</title>	</author>
	<author>	<date year="2005"/>
	<organization>National Institute of Standards and Technology</organi	</front>
	zation>	</reference>
	</author>	<reference anchor="SP800-78-4" target="http://dx.doi.org/10.6028/NIST.SP
	<date month="October" year="2017" />	.800-78-4">
	</front>	<front>
	</reference> -->	<title>Cryptographic Algorithms and Key Sizes for Personal Identity
	<reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">	Verification</title>
	<front>	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-78-4"/>
	<title>SEC 1: Elliptic Curve Cryptography</title>	<seriesInfo name="NIST Special Publication (SP)" value="800-78-4"/>
	<author>	<author>
	<organization>Standards for Efficient Cryptography Group</organizati	<organization>National Institute of Standards and Technology (NIST
	on>	)</organization>
	</author>	</author>
	<date month="May" year="2009" />	<date month="May" year="2015"/>
	</front>	</front>
	</reference>	</reference>
	<reference anchor="X9.62">	<reference anchor="SMI-PKIX" target="https://www.iana.org/assignments/sm
	<front>	i-numbers">
	<title>X9.62-2005: Public Key Cryptography for the Financial Services	<front>
	Industry: The Elliptic Curve Digital Signature Standard (ECDSA)</title>	<title>SMI Security for PKIX Algorithms</title>
	<author>	<author>
	<organization>American National Standard for Financial Services (ANS	<organization>IANA</organization>
	I)</organization>	</author>
	</author>	<date/>
	<date month="November" year="2005" />	</front>
	</front>	</reference>
	</reference>	<reference anchor="Hash-Texts" target="https://www.iana.org/assignments/
	<reference anchor="SP800-78-4" target="https://csrc.nist.gov/csrc/media/pu	hash-function-text-names/">
	blications/sp/800-78/4/final/documents/sp800_78-4_revised_draft.pdf">	<front>
	<front>	<title>Hash Function Textual Names</title>
	<title>SP800-78-4: Cryptographic Algorithms and Key Sizes for Personal	<author>
	Identity Verification</title>	<organization>IANA</organization>
	<author>	</author>
	<organization>National Institute of Standards and Technology (NIST)<	<date/>
	/organization>	</front>
	</author>	</reference>
	<date month="May" year="2014" />	<reference anchor="SP800-107" target="http://dx.doi.org/10.6028/NIST.SP.
	</front>	800-107r1">
	</reference>	<front>
	<reference anchor="SMI-PKIX" target="https://www.iana.org/assignments/smi-	<title>Recommendation for Applications Using Approved Hash Algorithm
	numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6">	s</title>
	<front>	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-107r1"/>
	<title>SMI Security for PKIX Algorithms</title>	<seriesInfo name="Revision" value="1"/>
	<author>	<seriesInfo name="NIST Special Publication (SP)" value="800-107"/>
	<organization>IANA</organization>	<author>
	</author>	<organization>National Institute of Standards and Technology (NIST
	<date month="March" year="2019" />	)</organization>
	</front>	</author>
	</reference>	<date month="August" year="2012"/>
	<reference anchor="Hash-Texts" target="https://www.iana.org/assignments/ha	</front>
	sh-function-text-names/hash-function-text-names.xhtml">	</reference>
	<front>	</references>
	<title>Hash Function Textual Names</title>
	<author>
	<organization>IANA</organization>
	</author>
	<date month="July" year="2017" />
	</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="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> -->
	<!-- <reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpub
	s/SpecialPublications/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> -->
	</references>	</references>

		<section anchor="asn" numbered="true" toc="default">
		<name>ASN.1 Module</name>
		<t>This appendix includes the ASN.1 module for SHAKEs in X.509.
		This module does not come from any previously existing RFC. This module refe
		rences <xref target="RFC5912" format="default"/>.</t>
		<sourcecode type="asn.1"><![CDATA[
		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) }


	<section anchor="asn" title="ASN.1 module">	DEFINITIONS EXPLICIT TAGS ::=
	<t>This appendix includes the ASN.1 module for SHAKEs in X.509.
	This module does not come from any existing RFC. </t>
	<t><figure><artwork><![CDATA[
	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(TBD) }

	DEFINITIONS EXPLICIT TAGS ::=


	BEGIN	BEGIN


	-- EXPORTS ALL;	-- EXPORTS ALL;


	IMPORTS	IMPORTS


	-- FROM [RFC5912]	-- FROM RFC 5912


	PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS	PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS
	FROM AlgorithmInformation-2009	FROM AlgorithmInformation-2009
	{ iso(1) identified-organization(3) dod(6) internet(1) security(5)	{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0)	mechanisms(5) pkix(7) id-mod(0)
	id-mod-algorithmInformation-02(58) }	id-mod-algorithmInformation-02(58) }


	-- FROM [RFC5912]	-- FROM RFC 5912


	RSAPublicKey, rsaEncryption, pk-rsa, pk-ec,	RSAPublicKey, rsaEncryption, pk-rsa, pk-ec,
	CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value	CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value
	FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)	FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkix1-algorithms2008-02(56) }	id-mod-pkix1-algorithms2008-02(56) }
	;	;


	--	--
	-- Message Digest Algorithms (mda-)	-- Message Digest Algorithms (mda-)
	--	--
	DigestAlgorithms DIGEST-ALGORITHM ::= {	DigestAlgorithms DIGEST-ALGORITHM ::= {
	-- This expands DigestAlgorithms from [RFC5912]	-- This expands DigestAlgorithms from RFC 5912
	mda-shake128 \|	mda-shake128 \|
	mda-shake256,	mda-shake256,
	...	...
	}	}


	--	--
	-- One-Way Hash Functions	-- One-Way Hash Functions
	--	--


	-	-- SHAKE128
	-- SHAKE128	mda-shake128 DIGEST-ALGORITHM ::= {
	mda-shake128 DIGEST-ALGORITHM ::= {	IDENTIFIER id-shake128 -- with output length 32 bytes.
	IDENTIFIER id-shake128 -- with output length 32 bytes.	}
	}	id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)	us(840) organization(1) gov(101)
	us(840) organization(1) gov(101)	csor(3) nistAlgorithm(4)
	csor(3) nistAlgorithm(4)	hashAlgs(2) 11 }
	hashAlgs(2) 11 }


	-- SHAKE256	-- SHAKE256
	mda-shake256 DIGEST-ALGORITHM ::= {	mda-shake256 DIGEST-ALGORITHM ::= {
	IDENTIFIER id-shake256 -- with output length 64 bytes.	IDENTIFIER id-shake256 -- with output length 64 bytes.
	}	}
	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	us(840) organization(1) gov(101)	us(840) organization(1) gov(101)
	csor(3) nistAlgorithm(4)	csor(3) nistAlgorithm(4)
	hashAlgs(2) 12 }	hashAlgs(2) 12 }


	--	--
	-- Public Key (pk-) Algorithms	-- Public Key (pk-) Algorithms
	--	--
	PublicKeys PUBLIC-KEY ::= {	PublicKeys PUBLIC-KEY ::= {
	-- This expands PublicKeys from [RFC5912]	-- This expands PublicKeys from RFC 5912
	pk-rsaSSA-PSS-SHAKE128 \|	pk-rsaSSA-PSS-SHAKE128 \|
	pk-rsaSSA-PSS-SHAKE256,	pk-rsaSSA-PSS-SHAKE256,
	...	...
	}	}


	-- The hashAlgorithm is mda-shake128	-- The hashAlgorithm is mda-shake128
	-- The maskGenAlgorithm is id-shake128	-- The maskGenAlgorithm is id-shake128
	-- Mask Gen Algorithm is SHAKE128 with output length	-- Mask Gen Algorithm is SHAKE128 with output length
	-- (8*ceil((n-1)/8) - 264) bits, where n is the RSA	-- (8*ceil((n-1)/8) - 264) bits, where n is the RSA
	-- modulus in bits.	-- modulus in bits.
	-- The saltLength is 32. The trailerField is 1.	-- The saltLength is 32. The trailerField is 1.
	pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= {	pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= {
	IDENTIFIER id-RSASSA-PSS-SHAKE128	IDENTIFIER id-RSASSA-PSS-SHAKE128
	KEY RSAPublicKey	KEY RSAPublicKey
	PARAMS ARE absent	PARAMS ARE absent
	-- Private key format not in this module --	-- Private key format not in this module --
	CERT-KEY-USAGE { nonRepudiation, digitalSignature,	CERT-KEY-USAGE { nonRepudiation, digitalSignature,
	keyCertSign, cRLSign }	keyCertSign, cRLSign }
	}	}


	-- The hashAlgorithm is mda-shake256	-- The hashAlgorithm is mda-shake256
	-- The maskGenAlgorithm is id-shake256	-- The maskGenAlgorithm is id-shake256
	-- Mask Gen Algorithm is SHAKE256 with output length	-- Mask Gen Algorithm is SHAKE256 with output length
	-- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA	-- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA
	-- modulus in bits.	-- modulus in bits.
	-- The saltLength is 64. The trailerField is 1.	-- The saltLength is 64. The trailerField is 1.
	pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= {	pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= {
	IDENTIFIER id-RSASSA-PSS-SHAKE256	IDENTIFIER id-RSASSA-PSS-SHAKE256
	KEY RSAPublicKey	KEY RSAPublicKey
	PARAMS ARE absent	PARAMS ARE absent
	-- Private key format not in this module --	-- Private key format not in this module --
	CERT-KEY-USAGE { nonRepudiation, digitalSignature,	CERT-KEY-USAGE { nonRepudiation, digitalSignature,
	keyCertSign, cRLSign }	keyCertSign, cRLSign }
	}	}


	--	--
	-- Signature Algorithms (sa-)	-- Signature Algorithms (sa-)
	--	--
	SignatureAlgs SIGNATURE-ALGORITHM ::= {	SignatureAlgs SIGNATURE-ALGORITHM ::= {
	-- This expands SignatureAlgorithms from [RFC5912]	-- This expands SignatureAlgorithms from RFC 5912
	sa-rsassapssWithSHAKE128 \|	sa-rsassapssWithSHAKE128 \|
	sa-rsassapssWithSHAKE256 \|	sa-rsassapssWithSHAKE256 \|
	sa-ecdsaWithSHAKE128 \|	sa-ecdsaWithSHAKE128 \|
	sa-ecdsaWithSHAKE256,	sa-ecdsaWithSHAKE256,
	...	...
	}	}


	--	--
	-- SMIME Capabilities (sa-)	-- SMIME Capabilities (sa-)
	--	--
	SMimeCaps SMIME-CAPS ::= {	SMimeCaps SMIME-CAPS ::= {
	-- The expands SMimeCaps from [RFC5912]	-- The expands SMimeCaps from RFC 5912
	sa-rsassapssWithSHAKE128.&smimeCaps \|	sa-rsassapssWithSHAKE128.&smimeCaps \|
	sa-rsassapssWithSHAKE256.&smimeCaps \|	sa-rsassapssWithSHAKE256.&smimeCaps \|
	sa-ecdsaWithSHAKE128.&smimeCaps \|	sa-ecdsaWithSHAKE128.&smimeCaps \|
	sa-ecdsaWithSHAKE256.&smimeCaps,	sa-ecdsaWithSHAKE256.&smimeCaps,
	...	...
	}	}


	-- RSASSA-PSS with SHAKE128	-- RSASSA-PSS with SHAKE128
	sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= {	sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-RSASSA-PSS-SHAKE128	IDENTIFIER id-RSASSA-PSS-SHAKE128
	PARAMS ARE absent	PARAMS ARE absent
	-- The hashAlgorithm is mda-shake128	-- The hashAlgorithm is mda-shake128
	-- The maskGenAlgorithm is id-shake128	-- The maskGenAlgorithm is id-shake128
	-- Mask Gen Algorithm is SHAKE128 with output length	-- Mask Gen Algorithm is SHAKE128 with output length
	-- (8*ceil((n-1)/8) - 264) bits, where n is the RSA	-- (8*ceil((n-1)/8) - 264) bits, where n is the RSA
	-- modulus in bits.	-- modulus in bits.
	-- The saltLength is 32. The trailerField is 1	-- The saltLength is 32. The trailerField is 1
	HASHES { mda-shake128 }	HASHES { mda-shake128 }
	PUBLIC-KEYS { pk-rsa \| pk-rsaSSA-PSS-SHAKE128 }	PUBLIC-KEYS { pk-rsa \| pk-rsaSSA-PSS-SHAKE128 }
	SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }	SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }
	}	}
	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)	security(5) mechanisms(5) pkix(7) algorithms(6)
	TBD1 }	30 }


	-- RSASSA-PSS with SHAKE256	-- RSASSA-PSS with SHAKE256
	sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {	sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-RSASSA-PSS-SHAKE256	IDENTIFIER id-RSASSA-PSS-SHAKE256
	PARAMS ARE absent	PARAMS ARE absent
	-- The hashAlgorithm is mda-shake256	-- The hashAlgorithm is mda-shake256
	-- The maskGenAlgorithm is id-shake256	-- The maskGenAlgorithm is id-shake256
	-- Mask Gen Algorithm is SHAKE256 with output length	-- Mask Gen Algorithm is SHAKE256 with output length
	-- (8*ceil((n-1)/8) - 520)-bits, where n is the	-- (8*ceil((n-1)/8) - 520)-bits, where n is the
	-- RSA modulus in bits.	-- RSA modulus in bits.
	-- The saltLength is 64. The trailerField is 1.	-- The saltLength is 64. The trailerField is 1.
	HASHES { mda-shake256 }	HASHES { mda-shake256 }
	PUBLIC-KEYS { pk-rsa \| pk-rsaSSA-PSS-SHAKE256 }	PUBLIC-KEYS { pk-rsa \| pk-rsaSSA-PSS-SHAKE256 }
	SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }	SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }
	}	}
	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)	security(5) mechanisms(5) pkix(7) algorithms(6)
	TBD2 }	31 }


	-- ECDSA with SHAKE128	-- ECDSA with SHAKE128
	sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {	sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ecdsa-with-shake128	IDENTIFIER id-ecdsa-with-shake128
	VALUE ECDSA-Sig-Value	VALUE ECDSA-Sig-Value
	PARAMS ARE absent	PARAMS ARE absent
	HASHES { mda-shake128 }	HASHES { mda-shake128 }
	PUBLIC-KEYS { pk-ec }	PUBLIC-KEYS { pk-ec }
	SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }	SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }
	}	}
	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)	security(5) mechanisms(5) pkix(7) algorithms(6)
	TBD3 }	32 }


	-- ECDSA with SHAKE256	-- ECDSA with SHAKE256
	sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {	sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ecdsa-with-shake256	IDENTIFIER id-ecdsa-with-shake256
	VALUE ECDSA-Sig-Value	VALUE ECDSA-Sig-Value
	PARAMS ARE absent	PARAMS ARE absent
	HASHES { mda-shake256 }	HASHES { mda-shake256 }
	PUBLIC-KEYS { pk-ec }	PUBLIC-KEYS { pk-ec }
	SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }	SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }
	}	}
	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)	security(5) mechanisms(5) pkix(7) algorithms(6)
	TBD4 }	33 }


	END	END
	]]></artwork></figure>	]]></sourcecode>
	</t>	</section>
		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>We would like to thank Sean Turner, Jim Schaad, and Eric
		Rescorla for their valuable contributions to this document.</t>
		<t>The authors would like to thank Russ Housley for his guidance and
		very valuable contributions with the ASN.1 module.</t>
	</section>	</section>


	</back>	</back>
	</rfc>	</rfc>

End of changes. 89 change blocks.
	1002 lines changed or deleted	637 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/