Diff: rfc8755xml2.original.xml

	rfc8755xml2.original.xml	rfc8755.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version='1.0' encoding='utf-8'?>
		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY rfc2631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2631.xml">
	<!ENTITY rfc3370 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3370.xml">
	<!ENTITY rfc3560 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3560.xml">
	<!ENTITY rfc3565 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3565.xml">
	<!ENTITY rfc4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4055.xml">
	<!ENTITY rfc4056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4056.xml">
	<!ENTITY rfc4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4086.xml">
	<!ENTITY rfc5083 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5083.xml">
	<!ENTITY rfc5084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5084.xml">
	<!ENTITY rfc5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5480.xml">
	<!ENTITY rfc5649 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5649.xml">
	<!ENTITY rfc5652 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5652.xml">
	<!ENTITY rfc5753 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5753.xml">
	<!ENTITY rfc5754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5754.xml">
	<!ENTITY rfc6318 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6318.xml">
	<!ENTITY rfc8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8017.xml">
	<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY rfc8551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8551.xml">
	<!ENTITY rfc8603 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8603.xml">
	]>

	<!-- Extra statement used by XSLT processors to control the output style. -->
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

	<!-- Information about the document. -->
	<rfc category="info" ipr="trust200902" docName="draft-jenkins-cnsa-smime-profile
	-03">

	<!-- Processing Instructions- PIs (for a complete list and description,
	see file http://xml.resource.org/authoring/README.html and below... --
	>

	<?rfc strict="yes" ?>
	<?rfc comments="no" ?>
	<?rfc inline="no" ?>
	<?rfc editing="no" ?>

	<!-- Table of Contents (ToC) options. -->
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="2"?>

	<!-- References options. -->
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>

	<!-- Vertical spacing options. -->
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>


	<!-- end of list of popular I-D processing instructions -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
		ipr="trust200902" docName="draft-jenkins-cnsa-smime-profile-03"
		obsoletes="" updates="" submissionType="independent" xml:lang="en"
		tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3"
		number="8755">
		<!-- xml2rfc v2v3 conversion 2.38.1 -->

	<!-- *** FRONT MATTER *** -->	<!-- *** FRONT MATTER *** -->

	<front>	<front>
	<title abbrev="CNSA Suite for S/MIME">Using Commercial National Security Alg orithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions</title>	<title abbrev="CNSA Suite for S/MIME">Using Commercial National Security Alg orithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions</title>

		<seriesInfo name="RFC" value="8755"/>
	<author fullname="Michael Jenkins" initials="M." surname="Jenkins">	<author fullname="Michael Jenkins" initials="M." surname="Jenkins">

	<organization abbrev="NSA">National Security Agency</organization>	<organization abbrev="NSA">National Security Agency</organization>
	<address><email>mjjenki@nsa.gov</email></address>	<address>
		<email>mjjenki@nsa.gov</email>
		</address>
	</author>	</author>

		<date month="March" year="2020"/>
	<date year="2019"/> <!-- Current month and day will be filled in. -->

	<!-- Meta-data Declarations -->

	<area>Security</area>	<area>Security</area>
	<workgroup>Internet Engineering Task Force</workgroup>	<workgroup>Internet Engineering Task Force</workgroup>


		<keyword>NSA</keyword>
		<keyword>CNSA</keyword>
		<keyword>NSS</keyword>
		<keyword>smime</keyword>

	<abstract>	<abstract>

	<t>The United States Government has published the NSA Commercial Nationa	<t>The United States Government has published the National Security
	l Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy	Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which de
	for national security applications. This document specifies the conventions for	fines cryptographic algorithm policy for national security applications. This do
	using the United States National Security Agency's CNSA Suite algorithms in Secu	cument specifies the conventions for using the United States National Security A
	re/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It a	gency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S
	pplies to the capabilities, configuration, and operation of all components of US	/MIME) as specified in RFC 8551. It applies to the capabilities, configuration,
	National Security Systems that employ S/MIME messaging. US National Security Sy	and operation of all components of US National Security Systems that employ S/MI
	stems are described in NIST Special Publication 800-59. It is also appropriate f	ME messaging. US National Security Systems are described in NIST Special Publica
	or all other US Government systems that process high-value information. It is ma	tion 800-59. It is also appropriate for all other US Government systems that pro
	de publicly available for use by developers and operators of these and any other	cess high-value information. It is made publicly available for use by developers
	system deployments.</t>	and operators of these and any other system deployments.</t>
	</abstract>	</abstract>

		</front>
	</front>	<!-- *** END FRONT MATTER *** -->
	<!-- *** END FRONT MATTER *** -->

	<!-- *** DOCUMENT BODY *** -->	<!-- *** DOCUMENT BODY *** -->

	<middle>	<middle>

		<section anchor="intro" numbered="true" toc="default">
	<section anchor="intro" title="Introduction">	<name>Introduction</name>
		<t>This document specifies the conventions for using the United States Nat
	<t>This document specifies the conventions for using the United States National	ional Security Agency's Commercial National Security Algorithm (CNSA) Suite algo
	Security Agency's Commercial National Security Algorithm (CNSA) Suite algorithms	rithms <xref target="CNSA" format="default"/> in Secure/Multipurpose Internet Ma
	<xref target="CNSA" /> in Secure/Multipurpose Internet Mail Extensions (S/MIME)	il Extensions (S/MIME) <xref target="RFC8551" format="default"/>. It applies to
	<xref target="RFC8551" />. It applies to the capabilities, configuration, and o	the capabilities, configuration, and operation of all components of US National
	peration of all components of US National Security Systems that employ S/MIME me	Security Systems that employ S/MIME messaging. US National Security Systems are
	ssaging. US National Security Systems are described in NIST Special Publication	described in NIST Special Publication 800-59 <xref target="SP80059" format="defa
	800-59 <xref target="SP80059" />. It is also appropriate for all other US Govern	ult"/>. It is also appropriate for all other US Government systems that process
	ment systems that process high-value information. It is made publicly available	high-value information. It is made publicly available for use by developers and
	for use by developers and operators of these and any other system deployments.	operators of these and any other system deployments.
	</t>

	<t>S/MIME makes use of the Cryptographic Message Syntax (CMS) <xref target="RFC5
	652" /> <xref target="RFC5083" />. In particular, the signed-data, enveloped-dat
	a, and authenticated-enveloped-data content types are used. This document only a
	ddresses CNSA Suite compliance for S/MIME. Other applications of CMS are outside
	the scope of this document.
	</t>	</t>

		<t>S/MIME makes use of the Cryptographic Message Syntax (CMS) <xref target
	<t>This document does not define any new cryptographic algorithm suite; instead,	="RFC5652" format="default"/> <xref target="RFC5083" format="default"/>. In part
	it defines a CNSA compliant profile of S/MIME. Since many of the CNSA Suite alg	icular, the signed-data, enveloped-data, and authenticated-enveloped-data conten
	orithms enjoy uses in other environments as well, the majority of the convention	t types are used. This document only addresses CNSA Suite compliance for S/MIME.
	s needed for these algorithms are already specified in other documents. This doc	Other applications of CMS are outside the scope of this document.
	ument references the source of these conventions, with some relevant details rep
	eated to aid developers that choose to support the CNSA Suite. Where details hav
	e been repeated, the cited documents are authoritative.
	</t>	</t>

		<t>This document does not define any new cryptographic algorithm suites; i
	</section> <!-- intro -->	nstead, it defines a CNSA-compliant profile of S/MIME. Since many of the CNSA Su
		ite algorithms enjoy uses in other environments as well, the majority of the con
	<section anchor="cnsa" title="The Commercial National Security Algorithm Suite">	ventions needed for these algorithms are already specified in other documents. T
		his document references the source of these conventions, with some relevant deta
	<t>The National Security Agency (NSA) profiles commercial cryptographic algorith	ils repeated to aid developers that choose to support the CNSA Suite. Where deta
	ms and protocols as part of its mission to support secure, interoperable communi	ils have been repeated, the cited documents are authoritative.
	cations for US Government National Security Systems. To this end, it publishes g
	uidance both to assist with the US Government transition to new algorithms, and
	to provide vendors - and the Internet community in general - with information co
	ncerning their proper use and configuration.
	</t>	</t>


	<t>Recently, cryptographic transition plans have become overshadowed by the pros	<section anchor="terminology" numbered="true" toc="default">
	pect of the development of a cryptographically-relevant quantum computer. NSA ha	<name>Terminology</name>
	s established the Commercial National Security Algorithm (CNSA) Suite to provide	<t>
	vendors and IT users near-term flexibility in meeting their cybersecurity inter	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	operability requirements. The purpose behind this flexibility is to avoid vendor	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	s and customers making two major transitions in a relatively short timeframe, as	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	we anticipate a need to shift to quantum-resistant cryptography in the near fut	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	ure.	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	</t>	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>
		<!-- intro -->


	<t>NSA is authoring a set of RFCs, including this one, to provide updated guidan	<section anchor="cnsa" numbered="true" toc="default">
	ce concerning the use of certain commonly available commercial algorithms in IET	<name>The Commercial National Security Algorithm Suite</name>
	F protocols. These RFCs can be used in conjunction with other RFCs and cryptogra	<t>The National Security Agency (NSA) profiles commercial cryptographic al
	phic guidance (e.g., NIST Special Publications) to properly protect Internet tra	gorithms and protocols as part of its mission to support secure, interoperable c
	ffic and data-at-rest for US Government National Security Systems..	ommunications for US Government National Security Systems. To this end, it publi
		shes guidance both to assist with the US Government transition to new algorithms
		and to provide vendors -- and the Internet community in general -- with informa
		tion concerning their proper use and configuration.
	</t>	</t>

		<t>Recently, cryptographic transition plans have become overshadowed by
	</section> <!-- cnsa -->	the prospect of the development of a cryptographically relevant quantum
		computer. The NSA has established the Commercial National Security Algorit
	<section anchor="terminology" title="Terminology">	hm
		(CNSA) Suite to provide vendors and IT users near-term flexibility in
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",	meeting their cybersecurity interoperability requirements. The purpose
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d	behind this flexibility is to avoid having vendors and customers make two
	ocument are to be interpreted as described in BCP 14 <xref target="RFC2119" />	major transitions in a relatively short timeframe, as we anticipate a need to sh
	<xref target="RFC8174" /> when, and only when, they appear in all capitals, as s	ift to quantum-resistant cryptography in the near future.
	hown here.
	</t>	</t>

		<t>The NSA is authoring a set of RFCs, including this one, to provide upda
	</section> <!-- terminology -->	ted guidance concerning the use of certain commonly available commercial algorit
		hms in IETF protocols. These RFCs can be used in conjunction with other RFCs and
	<section anchor="reqts" title="Requirements and Assumptions">	cryptographic guidance (e.g., NIST Special Publications) to properly protect In
		ternet traffic and data-at-rest for US Government National Security Systems.
	<t>CMS values are generated using ASN.1 <xref target="X208" />, the Basic Encodi
	ng Rules (BER) <xref target="X209" />, and the Distinguished Encoding Rules (DER
	) <xref target="X509" />.
	</t>	</t>

		</section>
		<!-- cnsa -->


	<t>The elliptic curve used in the CNSA Suite is specified in <xref target="FIPS1	<section anchor="reqts" numbered="true" toc="default">
	86" />, and appears in the literature under two different names. For the sake of	<name>Requirements and Assumptions</name>
	clarity, we list both names below:	<t>CMS values are generated using ASN.1 <xref target="X208" format="defaul
		t"/>, the Basic Encoding Rules (BER) <xref target="X209" format="default"/>, and
	<figure><artwork>	the Distinguished Encoding Rules (DER) <xref target="X509" format="default"/>.

	Curve NIST Name SECG Name OID [FIPS186]
	---------------------------------------------------------
	nistp384 P-384 secp384r1 1.3.132.0.34

	</artwork></figure>
	</t>	</t>

		<t>The elliptic curve used in the CNSA Suite is specified in <xref target= "FIPS186" format="default"/> and appears in the literature under two different n ames. For the sake of clarity, we list both names below:


	<t>For CNSA Suite applications, public key certificates used to verify S/MIME si	</t>
	gnatures MUST be compliant with the CNSA Suite Certificate and Certificate Revoc	<table anchor="curve" align="left">
	ation List (CRL) Profile specified in <xref target="RFC8603" />.	<thead>
		<tr>
		<th align="left">Curve</th>
		<th align="left">NIST Name</th>
		<th align="left">SECG Name</th>
		<th align="left">OID [FIPS186]</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">nistp384</td>
		<td align="left">P-384</td>
		<td align="left">secp384r1</td>
		<td align="left">1.3.132.0.34</td>
		</tr>
		</tbody>
		</table>
		<t>For CNSA Suite applications, public key certificates used to verify S/M
		IME signatures <bcp14>MUST</bcp14> be compliant with the CNSA Suite Certificate
		and Certificate Revocation List (CRL) profile specified in <xref target="RFC8603
		" format="default"/>.
	</t>	</t>

		<t>Within the CMS signed-data content type, signature algorithm identifier
	<t>Within the CMS signed-data content type, signature algorithm identifiers are	s are located in the signatureAlgorithm field of SignerInfo structures contained
	located in the signatureAlgorithm field of SignerInfo structures contained withi	within the SignedData. In addition, signature algorithm identifiers are located
	n the SignedData. In addition, signature algorithm identifiers are located in th	in the SignerInfo signatureAlgorithm field of countersignature attributes. Spec
	e SignerInfo signatureAlgorithm field of countersignature attributes. Specific r	ific requirements for digital signatures are given in <xref target="digital-sign
	equirements for digital signatures are given in <xref target="digital-signature"	ature" format="default"/>; compliant implementations <bcp14>MUST</bcp14> conside
	/>; compliant implementations MUST consider signatures not meeting these requir	r signatures not meeting these requirements as invalid.
	ements as invalid.
	</t>	</t>

		<t>Implementations based on Elliptic Curve Cryptography (ECC) also require
	<t>Elliptic Curve Cryptography (ECC) based implementations also require specific	specification of schemes for key derivation and key wrap. Requirements for thes
	ation of schemes for key derivation and key wrap. Requirements for these schemes	e schemes are in Sections <xref target="kdf" format="counter"/> and <xref target
	are in sections <xref target="kdf" /> and <xref target="keywrap" /> repectively	="keywrap" format="counter"/>, respectively.
	.
	</t>	</t>

		<t>RSA key pairs (public, private) are identified by the modulus size expr
	<t>RSA key pairs (public, private) are identified by the modulus size expressed	essed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and
	in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 b	4096 bits, respectively.
	its, respectively.
	</t>	</t>

		<t>RSA signature key pairs used in CNSA Suite-compliant implementations
	<t>RSA signature key pairs used in CNSA Suite compliant implementations are eith	are either RSA-3072 or RSA-4096. The RSA exponent e <bcp14>MUST</bcp14>
	er RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2^16<e<2^256 and	satisfy 2<sup>16</sup> < e < 2<sup>256</sup> and be odd per <xref ta
	be odd per <xref target="FIPS186" />.	rget="FIPS186" format="default"/>.
	</t>	</t>

		<t>It is recognized that, while the vast majority of RSA signatures are cu
	<t>It is recognized that, while the vast majority of RSA signatures are currentl	rrently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature
	y made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme	scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certifica
	for new applications is RSASSA-PSS. CNSA Suite compliant X.509 certificates wi	tes will be issued in accordance with <xref target="RFC8603" format="default"/>,
	ll be issued in accordance with <xref target="RFC8603" />, and while those certi	and while those certificates must be signed and validated using RSASSA-PKCS1-v1
	ficates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's RSA	_5, the subject's RSA key pair can be used to generate and validate signatures a
	key pair can be used to generate and validate signatures appropriate for either	ppropriate for either signing scheme. Where use of RSASSA-PSS is indicated in t
	signing scheme. Where use of RSASSA-PSS is indicated in this document, the para	his document, the parameters in <xref target="rsa-pss" format="default"/> apply.
	meters in <xref target="rsa-pss" /> apply.
	</t>	</t>

		<t>This document assumes that the required trust anchors have been securel
	<t>This document assumes that required trust anchors have been securely provisio	y provisioned to the client.
	ned to the client.
	</t>	</t>

		<t>All implementations use SHA-384 for hashing and either AES-CBC or AES-G
	<t>All implementations use SHA-384 for hashing and either AES-CBC or AES-GCM for	CM for encryption, the requirements for which are given in <xref target="message
	encryption, the requirements for which are given in <xref target="message-diges	-digest" format="default"/> and <xref target="content-enc" format="default"/>, r
	t" /> and <xref target="content-enc" />, respectively.	espectively.
	</t>	</t>

		</section>
		<!-- reqts -->


	</section> <!-- reqts -->	<section anchor="message-digest" numbered="true" toc="default">
		<name>SHA-384 Message Digest Algorithm</name>
	<section anchor="message-digest" title="SHA-384 Message Digest Algorithm">	<t>SHA-384 is the sole CNSA Suite message digest algorithm. <xref target="
		RFC5754" format="default"/> specifies the conventions for using SHA-384 with the
	<t>SHA-384 is the sole CNSA Suite message digest algorithm. <xref target="RFC575	Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations
	4" /> specifies the conventions for using SHA-384 with the Cryptographic Message	<bcp14>MUST</bcp14> follow the conventions in <xref target="RFC5754" format="de
	Syntax (CMS). CNSA Suite compliant S/MIME implementations MUST follow the conve	fault"/>.
	ntions in <xref target="RFC5754" />.
	</t>	</t>

		<t>Within the CMS signed-data content type, message digest algorithm ident
	<t>Within the CMS signed-data content type, message digest algorithm identifiers	ifiers are located in the SignedData digestAlgorithms field and the SignerInfo d
	are located in the SignedData digestAlgorithms field and the SignerInfo digestA	igestAlgorithm field.
	lgorithm field.
	</t>	</t>

		<t>The SHA-384 message digest algorithm is defined in FIPS Pub 180 <xref t
	<t>The SHA-384 message digest algorithm is defined in FIPS Pub 180 <xref target=	arget="FIPS180" format="default"/>. The algorithm identifier for SHA-384 is defi
	"FIPS180" />. The algorithm identifier for SHA-384 is defined in <xref target="R	ned in <xref target="RFC5754" format="default"/> as follows:
	FC5754" /> as follows:	</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	<figure><artwork>

	id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-sha384 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) hashalgs(2) 2 }	nistalgorithm(4) hashalgs(2) 2 }

		]]></sourcecode>
	</artwork></figure>	<t>For SHA-384, the AlgorithmIdentifier parameters field is <bcp14>OPTIONA
	</t>	L</bcp14>, and if present, the parameters field <bcp14>MUST</bcp14> contain a NU
		LL. As specified in <xref target="RFC5754" format="default"/>, implementations <
	<t>For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL, and if pre	bcp14>MUST</bcp14> generate SHA-384 AlgorithmIdentifiers with absent parameters.
	sent, the parameters field MUST contain a NULL. As specified in <xref target="RF	Implementations <bcp14>MUST</bcp14> accept SHA-384 AlgorithmIdentifiers with ab
	C5754" />, implementations MUST generate SHA-384 AlgorithmIdentifiers with absen	sent parameters or with NULL parameters.
	t parameters. Implementations MUST accept SHA-384 AlgorithmIdentifiers with abse
	nt parameters or with NULL parameters.
	</t>	</t>

		</section>
		<!-- message-digest -->


	</section> <!-- message-digest -->	<section anchor="digital-signature" numbered="true" toc="default">
		<name>Digital Signature</name>
	<section anchor="digital-signature" title="Digital Signature">	<section anchor="ecc-dig-sig" numbered="true" toc="default">
		<name>ECDSA Signature</name>
	<section anchor="ecc-dig-sig" title="ECDSA Signature">	<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Su
		ite digital signature algorithm based on ECC. <xref target="RFC5753" format="def
	<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Suite digi	ault"/> specifies the conventions for using ECDSA with the Cryptographic Message
	tal signature algorithm based on ECC. <xref target="RFC5753" /> specifies the co	Syntax (CMS). CNSA Suite-compliant S/MIME implementations <bcp14>MUST</bcp14> f
	nventions for using ECDSA with the Cryptographic Message Syntax (CMS). CNSA Suit	ollow the conventions in <xref target="RFC5753" format="default"/>.
	e compliant S/MIME implementations MUST follow the conventions in <xref target="
	RFC5753" />.
	</t>	</t>

		<t><xref target="RFC5480" format="default"/> defines the signature algor ithm identifier used in CMS for ECDSA with SHA-384 as follows:


	<t><xref target="RFC5480" /> defines the signature algorithm identifier used in	</t>
	CMS for ECDSA with SHA-384 as follows:	<sourcecode name="" type="asn.1"><![CDATA[

	<figure><artwork>

	ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1)	ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) us(840) ansi-X9-62(10045) signatures(4)	member-body(2) us(840) ansi-X9-62(10045) signatures(4)
	ecdsa-with-sha2(3) 3 }	ecdsa-with-sha2(3) 3 }

		]]></sourcecode>
	</artwork></figure>	<t>When the ecdsa-with-SHA384 algorithm identifier is used, the Algorith
	</t>	mIdentifier parameters field <bcp14>MUST</bcp14> be absent.

	<t>When the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentif
	ier parameters field MUST be absent.
	</t>	</t>

		<t>When signing, the ECDSA algorithm generates two values, commonly call ed r and s. These two values <bcp14>MUST</bcp14> be encoded using the ECDSA-Sig -Value type specified in <xref target="RFC5480" format="default"/>:


	<t>When signing, the ECDSA algorithm generates two values, commonly called r and	</t>
	s. These two values MUST be encoded using the ECDSA-Sig-Value type specified i	<sourcecode name="" type="asn.1"><![CDATA[
	n <xref target="RFC5480" />:

	<figure><artwork>

	ECDSA-Sig-Value ::= SEQUENCE {	ECDSA-Sig-Value ::= SEQUENCE {
	r INTEGER,	r INTEGER,
	s INTEGER }	s INTEGER }

		]]></sourcecode>
		</section>
		<!-- ecc-dig-sig -->


	</artwork></figure>	<section anchor="rsa-dig-sig" numbered="true" toc="default">
	</t>	<name>RSA Signature</name>
		<t>The RSA signature generation process and the encoding of the result i
	</section> <!-- ecc-dig-sig -->	s either RSASSA-PKCS1-v1_5 or RSA-PSS, as described in detail in PKCS #1 version
		2.2 <xref target="RFC8017" format="default"/>.
	<section anchor="rsa-dig-sig" title="RSA Signature">

	<t>The RSA signature generation process and the encoding of the result is either
	RSASSA-PKCS1-v1_5 or RSA-PSS as described in detail in PKCS #1 version 2.2 <xre
	f target="RFC8017" />.
	</t>	</t>

		<section anchor="rsa-pkcs1" numbered="true" toc="default">
		<name>RSA-PKCS1-v1_5</name>
		<t><xref target="RFC5754" format="default"/> defines the signature
		algorithm identifier used in CMS for an RSA signature with SHA-384 as f
		ollows:


	<section anchor="rsa-pkcs1" title="RSA-PKCS1-v1_5">	</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	<t><xref target="RFC5754" /> defines the signature algorithm identifier used in	sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
	CMS for RSA signature with SHA-384 as follows:

	<figure><artwork>

	sha384WithRSAEncryption OBJECT IDENTIFIER :== { iso(1)
	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }

		]]></sourcecode>
	</artwork></figure>	<t>When the sha384WithRSAEncryption algorithm identifier is used, the
	</t>	parameters <bcp14>MUST</bcp14> be NULL. Implementations <bcp14>MUST</bcp14> acce
		pt the parameters being absent as well as present.
	<t>When the sha384WithRSAEncryption algorithm identifier is used, the parameters
	MUST be NULL. Implementations MUST accept the parameters being absent as well a
	s present.
	</t>	</t>

		</section>
		<!-- rsa-pkcs1 -->


	</section> <!-- rsa-pkcs1 -->	<section anchor="rsa-pss" numbered="true" toc="default">
		<name>RSA-PSS</name>
	<section anchor="rsa-pss" title="RSA-PSS">

	<t><xref target="RFC4056" /> defines the signature algorithm identifier used in
	CMS for RSA-PSS signature as follows:


	<figure><artwork>	<t><xref target="RFC4056" format="default"/> defines the signature
		algorithm identifier used in CMS for an RSA-PSS signature as follows (p
		resented here in expanded form):


	RSASSA-PSS OBJECT IDENTIFIER :== { iso(1)	</t>
		<sourcecode name="" type="asn.1"><![CDATA[
		RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }

		]]></sourcecode>
		<t>The parameters field of an AlgorithmIdentifier that identifies RSAS
		SA-PSS is defined in <xref target="RFC4055" format="default"/> as follows:


	</artwork></figure>	</t>
	</t>	<sourcecode name="" type="asn.1"><![CDATA[

	<t>The parameters field of an AlgorithmIdentifier that identifies RSASSA-PSS is
	defined in <xref target="RFC4055" /> as follows:

	<figure><artwork>

	RSASSA-PSS-params ::= SEQUENCE {	RSASSA-PSS-params ::= SEQUENCE {
	hashAlgorithm [0] HashAlgorithm DEFAULT	hashAlgorithm [0] HashAlgorithm DEFAULT
	sha1Identifier,	sha1Identifier,
	maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT	maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
	mgf1SHA1Identifier,	mgf1SHA1Identifier,
	saltLength [2] INTEGER DEFAULT 20,	saltLength [2] INTEGER DEFAULT 20,
	trailerField [3] INTEGER DEFAULT 1 }	trailerField [3] INTEGER DEFAULT 1 }

		]]></sourcecode>
		<t>The AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> contai
		n RSASSA-PSS-params with the following values:


	</artwork></figure>
	</t>

	<t>The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-params with
	the following values:

	<list style="symbols">
	<t>the hash algorithm MUST be id-sha384 as defined in <xref target="RFC8017" />;
	</t>
	<t>the mask generation function MUST use the algorithm identifier mfg1SHA384Iden
	tifier as defined in <xref target="RFC4055" />;</t>
	<t>the salt length MUST be 48 octets (the same length as the SHA-384 output); an
	d</t>
	<t>the trailerField MUST have value 1.</t>
	</list>
	</t>	</t>

		<ul spacing="normal">
		<li>The hash algorithm <bcp14>MUST</bcp14> be id-sha384 as defined i
		n <xref target="RFC8017" format="default"/>;</li>
		<li>The mask generation function <bcp14>MUST</bcp14> use the algorit
		hm identifier mfg1SHA384Identifier as defined in <xref target="RFC4055" format="
		default"/>;</li>
		<li>The salt length <bcp14>MUST</bcp14> be 48 octets (the same lengt
		h as the SHA-384 output); and</li>
		<li>The trailerField <bcp14>MUST</bcp14> have value 1.</li>
		</ul>
		</section>
		<!-- rsa-pss -->


	</section> <!-- rsa-pss -->	</section>
		<!-- rsa-dig-sig -->
	</section> <!-- rsa-dig-sig -->

	</section> <!-- digital-signature -->

	<section anchor="key-establishment" title="Key Establishment">


	<section anchor="ecc-ka" title="Elliptic Curve Key Agreement">	</section>
		<!-- digital-signature -->


	<t>Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement algorith	<section anchor="key-establishment" numbered="true" toc="default">
	m. Since S/MIME is used in store-and-forward communications, ephemeral-static EC	<name>Key Establishment</name>
	DH is always employed. This means that the message originator possesses an ephem	<section anchor="ecc-ka" numbered="true" toc="default">
	eral ECDH key pair and that the message recipient possesses a static ECDH key pa	<name>Elliptic Curve Key Agreement</name>
	ir whose public key is provided in an X.509 certificate. The certificate used to	<t>Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement
	obtain the recipient's public key MUST be compliant with <xref target="RFC8603"	algorithm. Since S/MIME is used in store-and-forward communications, ephemeral-s
	/>.	tatic ECDH is always employed. This means that the message originator possesses
		an ephemeral ECDH key pair and that the message recipient possesses a static ECD
		H key pair whose public key is provided in an X.509 certificate. The certificate
		used to obtain the recipient's public key <bcp14>MUST</bcp14> be compliant with
		<xref target="RFC8603" format="default"/>.
	</t>	</t>

		<t>When a key agreement algorithm is used, the following steps are perfo rmed:


	<t>When a key agreement algorithm is used, the following steps are performed:

	<list style="numbers">
	<t>A content-encryption key (CEK) for a particular content-encryption algorit
	hm is generated at random.</t>
	<t>The recipient's public key and sender's private key are used with a key ag
	reement scheme to generate a shared secret (Z).</t>
	<t>The shared secret is used with a key derivation function (KDF) to produce
	a key-encryption key (KEK).</t>
	<t>The KEK is used with a key wrap algorithm to encrypt the CEK.</t>
	</list>

	Key derivation is discussed in <xref target="kdf" />. Key wrapping is discussed
	in <xref target="keywrap" />.
	</t>	</t>

		<ol spacing="normal" type="1">
		<li>A content-encryption key (CEK) for a particular content-encryption
		algorithm is generated at random.</li>
		<li>The recipient's public key and sender's private key are used with
		a key agreement scheme to generate a shared secret (Z).</li>
		<li>The shared secret is used with a key derivation function (KDF) to
		produce a key-encryption key (KEK).</li>
		<li>The KEK is used with a key wrap algorithm to encrypt the CEK.</li>
		</ol>
		<t>


	<t>Section 3.1 of <xref target="RFC5753" /> specifies the conventions for using ECDH with the CMS. CNSA Suite compliant S/MIME implementations MUST follow these conventions.	Key derivation is discussed in <xref target="kdf" format="default"/>. Key wrappi ng is discussed in <xref target="keywrap" format="default"/>.
	</t>	</t>

		<t><xref target="RFC5753" sectionFormat="of" section="3.1"/> specifies t
	<t>Within the CMS enveloped-data and authenticated-enveloped-data content types,	he conventions for using ECDH with the CMS. CNSA Suite-compliant S/MIME implemen
	key agreement algorithm identifiers are located in the EnvelopedData RecipientI	tations <bcp14>MUST</bcp14> follow these conventions.
	nfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.	</t>
		<t>Within the CMS enveloped-data and authenticated-enveloped-data conten
		t types, key agreement algorithm identifiers are located in the EnvelopedData Re
		cipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
	</t>	</t>


	<t>The keyEncryptionAlgorithm field comprises two fields, an algorithm field and	<t>The keyEncryptionAlgorithm field comprises two fields, an algorithm
	a parameter field. The algorithm field MUST identify dhSinglePass-stdDH-sha384k	field and a parameter field. The algorithm field <bcp14>MUST</bcp14>
	df-scheme. The algorithm identifier for the dhSinglePass-stdDH-sha384kdf-scheme,	identify dhSinglePass-stdDH-sha384kdf-scheme. The algorithm identifier
	repeated from Section 7.1.4 of <xref target="RFC5753" />, is:	for the dhSinglePass-stdDH-sha384kdf-scheme, repeated from <xref target="
		RFC5753" sectionFormat="of" section="7.1.4"/>, is (presented here in expanded fo
	<figure><artwork>	rm):


		</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=	dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
	{ iso(1) identified-organization(3) certicom(132)	{ iso(1) identified-organization(3) certicom(132)
	schemes(1) 11 2 }	schemes(1) 11 2 }

		]]></sourcecode>
	</artwork></figure>	<t>The keyEncryptionAlgorithm parameter field <bcp14>MUST</bcp14> be con
	</t>	structed as described in <xref target="keywrap" format="default"/>.

	<t>The keyEncryptionAlgorithm parameter field MUST be constructed as described i
	n <xref target="keywrap" />.
	</t>	</t>

		<section anchor="kdf" numbered="true" toc="default">
		<name>Key Derivation Functions</name>
		<t>KDFs based on SHA-384 are used to derive a pairwise
		key-encryption key from the shared secret produced by
		ephemeral-static ECDH. Sections <xref
		target="RFC5753" section="7.1.8" sectionFormat="bare"/> and <xref
		target="RFC5753" sectionFormat="bare" section="7.2"/> in <xref
		target="RFC5753"/> specify the CMS conventions for using a KDF with the
		shared secret generated during ephemeral-static ECDH. CNSA Suite-compliant S/MI
		ME implementations <bcp14>MUST</bcp14> follow these conventions.
		</t>
		<t>As specified in <xref target="RFC5753" sectionFormat="of"
		section="7.1.8"/>, the ANSI-X9.63-KDF described in Section 3.6.1 of <xr
		ef target="SEC1"/> and based on SHA-384 <bcp14>MUST</bcp14> be used.
		</t>
		<t>As specified in <xref target="RFC5753" sectionFormat="of" section="
		7.2"/>, when using ECDH with the CMS enveloped-data or authenticated-enveloped-d
		ata content type, the derivation of key-encryption keys makes use of the ECC-CMS
		-SharedInfo type:


	<section anchor="kdf" title="Key Derivation Functions">	</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	<t>KDFs based on SHA-384 are used to derive a pairwise key-encryption key
	from the shared secret produced by ephemeral-static ECDH. Sections 7.1.8 and 7.2
	of <xref target="RFC5753" /> specify the CMS conventions for using a KDF with t
	he shared secret generated during ephemeral-static ECDH. CNSA Suite compliant S/
	MIME implementations MUST follow these conventions.
	</t>

	<t>As specified in Section 7.1.8 of <xref target="RFC5753" />, the ANSI-X9
	.63-KDF described in Section 3.6.1 of <xref target="SEC1" /> and based on SHA-38
	4 MUST be used.
	</t>

	<t>As specified in Section 7.2 of <xref target="RFC5753" />, when using EC
	DH with the CMS enveloped-data or authenticated-enveloped-data content type, the
	derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo type:

	<figure><artwork>

	ECC-CMS-SharedInfo ::= SEQUENCE {	ECC-CMS-SharedInfo ::= SEQUENCE {
	keyInfo AlgorithmIdentifier,	keyInfo AlgorithmIdentifier,
	entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,	entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
	suppPubInfo [2] EXPLICIT OCTET STRING }	suppPubInfo [2] EXPLICIT OCTET STRING }

		]]></sourcecode>
		<t>In the CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are
		used as follows:


	</artwork></figure>	</t>
	</t>	<ul empty="false">

	<t>In CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used as
	follows:

	<list style="hanging">
	<t>keyInfo contains the object identifier of the key-encryption algorit
	hm used to wrap the content-encryption key. If AES-256 Key Wrap is used, then th
	e keyInfo will contain id-aes256-wrap-pad, and the parameters will be absent.
	</t>

	<t>entityUInfo optionally contains a random value provided by the messa
	ge originator. If user keying material (ukm) is included in the KeyAgreeRecipien
	tInfo, then the entityUInfo MUST be present, and it MUST contain the ukm value.
	If the ukm is not present, then the entityUInfo MUST be absent.
	</t>

	<t>suppPubInfo contains the length of the generated key-encryption key,
	in bits, represented as a 32-bit unsigned number, as described in <xref target=
	"RFC2631" />. When a 256-bit AES key is used, the length MUST be 0x00000100.
	</t>

	</list>
	</t>

	<t>ECC-CMS-SharedInfo is DER encoded and used as input to the key derivati
	on function, as specified in Section 3.6.1 of <xref target="SEC1" />. Note that
	ECC-CMS-SharedInfo differs from the OtherInfo specified in <xref target="RFC263
	1" />. Here, a counter value is not included in the keyInfo field because the KD
	F specified in <xref target="SEC1" /> ensures that sufficient keying data is pro
	vided.
	</t>

	<t>The KDF specified in Section 3.6.1 of <xref target="SEC1" /> describes
	how to generate an essentially arbitrary amount of keying material from a shared
	secret, Z, produced by ephemeral-static ECDH. To generate an L-bit key-encrypti
	on key (KEK), KM is computed:

	<figure><artwork>


		<li>keyInfo contains the object identifier of the key-encryption alg
		orithm used to wrap the content-encryption key. If AES-256 Key Wrap is used, the
		n the keyInfo will contain id-aes256-wrap-pad, and the parameters will be absent
		.
		</li>
		<li>entityUInfo optionally contains a random value provided by the m
		essage originator. If user keying material (ukm) is included in the KeyAgreeReci
		pientInfo, then the entityUInfo <bcp14>MUST</bcp14> be present, and it <bcp14>MU
		ST</bcp14> contain the ukm value. If the ukm is not present, then the entityUInf
		o <bcp14>MUST</bcp14> be absent.
		</li>
		<li>suppPubInfo contains the length of the generated key-encryption
		key in bits, represented as a 32-bit unsigned number, as described in <xref targ
		et="RFC2631" format="default"/>. When a 256-bit AES key is used, the length <bcp
		14>MUST</bcp14> be 0x00000100.
		</li>
		</ul>
		<t>ECC-CMS-SharedInfo is DER encoded and is used as input to the key
		derivation function, as specified in Section 3.6.1 of <xref target="SEC
		1"/>. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in <xre
		f target="RFC2631" format="default"/>. Here, a counter value is not included in
		the keyInfo field because the KDF specified in <xref target="SEC1" format="defau
		lt"/> ensures that sufficient keying data is provided.
		</t>
		<t>The KDF specified in Section 3.6.1 of <xref target="SEC1"/> describ
		es how to generate an essentially arbitrary amount of keying material from a sha
		red secret, Z, produced by ephemeral-static ECDH. To generate an L-bit key-encry
		ption key (KEK), blocks of key material (KM) are computed by incrementing Counte
		r appropriately until enough material has been generated:
		</t>
		<sourcecode name="" type="pseudocode"><![CDATA[
	KM(Counter) = Hash ( Z \|\| Counter \|\| ECC-CMS-SharedInfo )	KM(Counter) = Hash ( Z \|\| Counter \|\| ECC-CMS-SharedInfo )

		]]></sourcecode>
		<t>
		The KM blocks are concatenated left to right as they are
		generated, and the first (leftmost) L bits are used as the KEK:


	</artwork></figure>	</t>
		<sourcecode name="" type="pseudocode"><![CDATA[
	incrementing Counter appropriately, until enough material has been generat
	ed. The KM blocks are concatenated left to right, as they are generated, and th
	e first (leftmost) L bits are used as the KEK:

	<figure><artwork>

	KEK = the leftmost L bits of	KEK = the leftmost L bits of
	[KM ( counter=1 ) \|\| KM ( counter=2 ) ...]	[KM ( counter=1 ) \|\| KM ( counter=2 ) ...]

		]]></sourcecode>
		<t>In the CNSA Suite for S/MIME, the elements of the KDF are defined a
		s follows:


	</artwork></figure>	</t>
	</t>	<ul empty="false">
		<li>Hash is a one-way hash function. The SHA-384 hash <bcp14>MUST</b
	<t>In CNSA Suite for S/MIME, the elements of the KDF are defined as follow	cp14> be used.
	s:	</li>
		<li>Z is the shared secret value generated during ephemeral-static E
	<list style="hanging">	CDH.
	<t>Hash is a one-way hash function. The SHA-384 hash MUST be used.	Z <bcp14>MUST</bcp14> be exactly 384 bits, i.e., leading zero bits <bcp
	</t>	14>MUST</bcp14> be preserved.
		</li>
	<t>Z is the shared secret value generated during ephemeral-static ECDH.	<li>Counter is a 32-bit unsigned number represented in network byte
	Z MUST be exactly 384 bits, i.e., leading zero bits MUST be preserved.	order. Its initial value <bcp14>MUST</bcp14> be 0x00000001 for any key
	</t>

	<t>Counter is a 32-bit unsigned number, represented in network byte
	order. Its initial value MUST be 0x00000001 for any key
	derivation operation.	derivation operation.

	</t>	</li>
		<li>ECC-CMS-SharedInfo is composed as described above. It <bcp14>MUS
	<t>ECC-CMS-SharedInfo is composed as described above. It MUST be DER	T</bcp14> be DER
	encoded.	encoded.

	</t>	</li>
		</ul>
	</list></t>	<t> In the CNSA Suite for S/MIME, exactly one iteration is needed; the
		Counter is not incremented. The key-encryption key (KEK) <bcp14>MUST</bcp14> be
	<t> In CNSA Suite for S/MIME, exactly one iteration is needed; the Counter	the first (leftmost) 256 bits of the SHA-384 output value:
	is not incremented. The key-encryption key (KEK) MUST be the first (leftmost) 2
	56 bits of the SHA-384 output value:

	<figure><artwork>


		</t>
		<sourcecode name="" type="pseudocode"><![CDATA[
	KEK = the leftmost 256 bits of	KEK = the leftmost 256 bits of
	SHA-384 ( Z \|\| 0x00000001 \|\| ECC-CMS-SharedInfo )	SHA-384 ( Z \|\| 0x00000001 \|\| ECC-CMS-SharedInfo )

		]]></sourcecode>
		<t>Note that the only source of secret entropy in this computation is
		Z.
		</t>
		</section>
		<!-- kdf -->


	</artwork></figure>	<section anchor="keywrap" numbered="true" toc="default">
	</t>	<name>AES Key Wrap</name>
		<t>The AES Key Wrap with Padding key-encryption algorithm, as specifie
	<t>Note that the only source of secret entropy in this computation is Z.	d in <xref target="RFC5649" format="default"/> and <xref target="SP80038F" forma
	</t>	t="default"/>, is used to encrypt the content-encryption key with a pairwise key
		-encryption key that is generated using ephemeral-static ECDH. <xref target="RFC
	</section> <!-- kdf -->	5753" sectionFormat="of" section="8"/> specifies the CMS conventions for using A
		ES Key Wrap with a pairwise key generated through ephemeral-static ECDH. CNSA Su
	<section anchor="keywrap" title="AES Key Wrap">	ite-compliant S/MIME implementations <bcp14>MUST</bcp14> follow these convention
		s.
	<t>The AES Key Wrap with Padding key-encryption algorithm, as specified in <xref
	target="RFC5649" /> and <xref target="SP80038F" />, is used to encrypt the cont
	ent-encryption key with a pairwise key-encryption key that is generated using ep
	hemeral-static ECDH. Section 8 of <xref target="RFC5753" /> specifies the CMS co
	nventions for using AES Key Wrap with a pairwise key generated through ephemeral
	-static ECDH. CNSA Suite compliant S/MIME implementations MUST follow these conv
	entions.
	</t>	</t>

		<t>Within the CMS enveloped-data content type, key wrap algorithm iden
	<t>Within the CMS enveloped-data content type, key wrap algorithm identifiers ar	tifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData
	e located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientI	RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
	nfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
	</t>	</t>

		<t>The KeyWrapAlgorithm <bcp14>MUST</bcp14> be id-aes256-wrap-pad. The required algorithm identifier, specified in <xref target="RFC5649" format="defa ult"/>, is:


	<t>The KeyWrapAlgorithm MUST be id-aes256-wrap-pad. The required algorithm ident	</t>
	ifier, specified in <xref target="RFC5649" />, is:	<sourcecode name="" type="asn.1"><![CDATA[

	<figure><artwork>

	id-aes256-wrap-pad OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-aes256-wrap-pad 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) aes(1) 48 }	nistAlgorithm(4) aes(1) 48 }

		]]></sourcecode>
		</section>
		<!-- keywrap -->


	</artwork></figure>	</section>
	</t>	<!-- ecc-ka -->

	</section> <!-- keywrap -->

	</section> <!-- ecc-ka -->

	<section anchor="rsa-kt" title="RSA Key Transport">


	<t>RSA encryption (RSA) is the CNSA Suite key transport algorithm. The RSA key t	<section anchor="rsa-kt" numbered="true" toc="default">
	ransport algorithm is the RSA encryption scheme defined in <xref target="RFC8017	<name>RSA Key Transport</name>
	" />, where the message to be encrypted is the content-encryption key.	<t>RSA encryption (RSA) is the CNSA Suite key transport algorithm. The R
		SA key transport algorithm is the RSA encryption scheme defined in <xref target=
		"RFC8017" format="default"/>, where the message to be encrypted is the content-e
		ncryption key.
	</t>	</t>

		<t>The recipient of an S/MIME message possesses an RSA key pair whose pu
	<t>The recipient of an S/MIME message possesses an RSA key pair whose public key	blic key is represented by an X.509 certificate. The certificate used to obtain
	is represented by an X.509 certificate. The certificate used to obtain the reci	the recipient's public key <bcp14>MUST</bcp14> be compliant with <xref target="R
	pient's public key MUST be compliant with <xref target="RFC8603" />. These certi	FC8603" format="default"/>. These certificates are suitable for use with either
	ficates are suitable for use with either RSAES-OAEP or RSAES-PKCS1-v1_5.	RSAES-OAEP or RSAES-PKCS1-v1_5.
	</t>	</t>

		<section anchor="rsaes-PKCS1" numbered="true" toc="default">
	<section anchor="rsaes-PKCS1" title="RSAES-PKCS1-v1_5">	<name>RSAES-PKCS1-v1_5</name>
		<t><xref target="RFC3370" sectionFormat="of" section="4.2"/> specifies
	<t>Section 4.2 of <xref target="RFC3370" /> specifies the conventions for using	the conventions for using RSAES-PKCS1-v1_5 with the CMS. S/MIME implementations
	RSAES-PKCS1-v1_5 with the CMS. S/MIME implementations employing this form of key	employing this form of key transport <bcp14>MUST</bcp14> follow these conventio
	transport MUST follow these conventions.	ns.
	</t>	</t>

		<t>Within the CMS enveloped-data and authenticated-enveloped-data cont
	<t>Within the CMS enveloped-data and authenticated-enveloped-data content types,	ent types, key transport algorithm identifiers are located in the EnvelopedData
	key transport algorithm identifiers are located in the EnvelopedData RecipientI	RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
	nfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
	</t>	</t>

		<t>The algorithm identifier for RSA (PKCS #1 v1.5) is:


	<t>The algorithm identifier for RSA (PKCS #1 v1.5) is:	</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	<figure><artwork>

	rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)	rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

		]]></sourcecode>
	</artwork></figure>	<t>The AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> be pre
	</t>	sent, and the parameters field <bcp14>MUST</bcp14> contain NULL.

	<t>The AlgorithmIdentifier parameters field MUST be present, and the parameters
	field MUST contain NULL.
	</t>	</t>

		</section>
		<!-- rsaes-PKCS1 -->


	</section> <!-- rsaes-PKCS1 -->	<section anchor="rsaes-OAEP" numbered="true" toc="default">
		<name>RSAES-OAEP</name>
	<section anchor="rsaes-OAEP" title="RSAES-OAEP">	<t><xref target="RFC3560" format="default"/> specifies the conventions
		for using RSAES-OAEP with the CMS. CNSA Suite-compliant S/MIME implementations
	<t><xref target="RFC3560" /> specifies the conventions for using RSAES-OAEP with	employing this form of key transport <bcp14>MUST</bcp14> follow these convention
	the CMS. CNSA Suite compliant S/MIME implementations employing this form of key	s.
	transport MUST follow these conventions.
	</t>	</t>

		<t>Within the CMS enveloped-data and authenticated-enveloped-data cont
	<t>Within the CMS enveloped-data and authenticated-enveloped-data content types,	ent types, key transport algorithm identifiers are located in the EnvelopedData
	key transport algorithm identifiers are located in the EnvelopedData RecipientI	RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
	nfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
	</t>	</t>

		<t>The algorithm identifier for RSA (OAEP) is:


	<t>The algorithm identifier for RSA (OAEP) is:	</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	<figure><artwork>

	id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)	id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }

		]]></sourcecode>
		<t>The parameters field of an AlgorithmIdentifier that identifies RSAE
		S-OAEP is defined in <xref target="RFC4055" format="default"/> as follows:


	</artwork></figure>	</t>
	</t>	<sourcecode name="" type="asn.1"><![CDATA[

	<t>The parameters field of an AlgorithmIdentifier that identifies RSAES-OAEP is
	defined in <xref target="RFC4055" /> as follows:

	<figure><artwork>

	RSAES-OAEP-params ::= SEQUENCE {	RSAES-OAEP-params ::= SEQUENCE {
	hashFunc [0] AlgorithmIdentifier DEFAULT	hashFunc [0] AlgorithmIdentifier DEFAULT
	sha1Identifier,	sha1Identifier,
	maskGenFunc [1] AlgorithmIdentifier DEFAULT	maskGenFunc [1] AlgorithmIdentifier DEFAULT
	mgf1SHA1Identifier,	mgf1SHA1Identifier,
	pSourceFunc [2] AlgorithmIdentifier DEFAULT	pSourceFunc [2] AlgorithmIdentifier DEFAULT
	pSpecifiedEmptyIdentifier }	pSpecifiedEmptyIdentifier }

	pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=	pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=
	{ id-pSpecified, nullOctetString }	{ id-pSpecified, nullOctetString }

	nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }	nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }

		]]></sourcecode>
		<t>The AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> be pre
		sent, and the parameters field <bcp14>MUST</bcp14> contain RSAES-OAEP-params wit
		h values as follows:


	</artwork></figure>
	</t>

	<t>The AlgorithmIdentifier parameters field MUST be present, and the parameters
	field MUST contain RSAES-OAEP-params with values as follows:

	<list style="symbols">
	<t>the hashFunc algorithm must be id-sha384 as defined in <xref target="RFC8017"
	/>;</t>
	<t>the mask generation function must use the algorithm identifier mfg1SHA384Iden
	tifier as defined in <xref target="RFC4055" />;</t>
	<t>the pSourceFunc field must be absent.</t>
	</list>
	</t>	</t>

		<ul spacing="normal">
	<t>The SMIMECapabilities signed attribute is used to specify a partial list of a	<li>The hashFunc algorithm must be id-sha384 as defined in <xref tar
	lgorithms that the software announcing the SMIMECapabilities can support. If the	get="RFC8017" format="default"/>;</li>
	SMIMECapabilities signed attribute is included to announce support for the RSAE	<li>The mask generation function must use the algorithm identifier m
	S-OAEP algorithm, it MUST be constructed as defined in Section 5 of <xref target	fg1SHA384Identifier as defined in <xref target="RFC4055" format="default"/>;</li
	="RFC3560" />, with the sequence representing the rSAES-OAEP-SHA384-Identifier.	>
		<li>The pSourceFunc field must be absent.</li>
		</ul>
		<t>The SMIMECapabilities signed attribute is used to specify a
		partial list of algorithms that the software announcing the
		SMIMECapabilities can support. If the SMIMECapabilities signed
		attribute is included to announce support for the RSAES-OAEP
		algorithm, it <bcp14>MUST</bcp14> be constructed as defined in <xref
		target="RFC3560" sectionFormat="of" section="5"/>, with the sequence re
		presenting the rSAES-OAEP-SHA384-Identifier.
	</t>	</t>

		</section>
		<!-- rsaes-OAEP -->


	</section> <!-- rsaes-OAEP -->	</section>
		<!-- rsa-kt -->
	</section> <!-- rsa-kt -->

	</section> <!-- key-establishment -->


	<section anchor="content-enc" title="Content Encryption">	</section>
		<!-- key-establishment -->


	<t>AES-GCM is the preferred mode for CNSA Suite applications as described in the	<section anchor="content-enc" numbered="true" toc="default">
	<xref target="sec-considerations">Security Considerations</xref>. AES-CBC is ac	<name>Content Encryption</name>
	ceptable where AES-GCM is not yet available.	<t>AES-GCM is the preferred mode for CNSA Suite applications, as described
		in the <xref target="sec-considerations" format="default">Security Consideratio
		ns</xref>. AES-CBC is acceptable where AES-GCM is not yet available.
	</t>	</t>

		<section anchor="aes-gcm-enc" numbered="true" toc="default">
	<section anchor="aes-gcm-enc" title="AES-GCM Content Encryption">	<name>AES-GCM Content Encryption</name>
		<t>CNSA Suite-compliant S/MIME implementations using the
	<t>CNSA Suite compliant S/MIME implementations using the authenticated-enveloped	authenticated-enveloped-data content type <xref target="RFC5083"
	-data content type <xref target="RFC5083" /> MUST use <xref target="FIPS197">AES	format="default"/> <bcp14>MUST</bcp14> use AES <xref target="FIPS197"
	</xref> in <xref target="SP80038D">Galois Counter Mode (GCM)</xref> as the conte	format="default"/> in Galois Counter Mode (GCM) <xref
	nt-authenticated encryption algorithm, and MUST follow the conventions for using	target="SP80038D" format="default"/> as the content-authenticated encrypt
	AES-GCM with the CMS defined in <xref target="RFC5084" />.	ion algorithm and <bcp14>MUST</bcp14> follow the conventions for using AES-GCM w
		ith the CMS defined in <xref target="RFC5084" format="default"/>.
	</t>	</t>

		<t>Within the CMS authenticated-enveloped-data content type, content-aut
	<t>Within the CMS authenticated-enveloped-data content type, content-authenticat	henticated encryption algorithm identifiers are located in the AuthEnvelopedData
	ed encryption algorithm identifiers are located in the AuthEnvelopedData Encrypt	EncryptedContentInfo contentEncryptionAlgorithm field. The content-authenticat
	edContentInfo contentEncryptionAlgorithm field. The content-authenticated encry	ed encryption algorithm is used to encipher the content located in the AuthEnvel
	ption algorithm is used to encipher the content located in the AuthEnvelopedData	opedData EncryptedContentInfo encryptedContent field.
	EncryptedContentInfo encryptedContent field.
	</t>	</t>

		<t>The AES-GCM content-authenticated encryption algorithm is described i n <xref target="FIPS197" format="default"/> and <xref target="SP80038D" format=" default"/>. The algorithm identifier for AES-256 in GCM mode is:


	<t>The AES-GCM content-authenticated encryption algorithm is described in <xref	</t>
	target="FIPS197" /> and <xref target="SP80038D" />. The algorithm identifier fo	<sourcecode name="" type="asn.1"><![CDATA[
	r AES-256 in GCM mode is:

	<figure><artwork>
	id-aes256-GCM OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-aes256-GCM 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) aes(1) 46 }	nistAlgorithm(4) aes(1) 46 }

	</artwork></figure>	]]></sourcecode>
	</t>	<t>The AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> be prese
		nt, and the parameters field must contain GCMParameters:
	<t>The AlgorithmIdentifier parameters field MUST be present, and the parameters	</t>
	field must contain GCMParameters:


	<figure><artwork>	<sourcecode name="" type="asn.1"><![CDATA[
	GCMParameters ::= SEQUENCE {	GCMParameters ::= SEQUENCE {
	aes-nonce OCTET STRING,	aes-nonce OCTET STRING,

	aes-ICVlen AES-GCM-IVClen DEFAULT 12 }	aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
	</artwork></figure>	]]></sourcecode>
	</t>	<t>The authentication tag length (aes-ICVlen) <bcp14>SHALL</bcp14> be 16
		(indicating a tag length of 128 bits).
	<t>The authentication tag length (aes-ICVlen) SHALL be 16 (indicating a tag leng
	th of 128 bits).
	</t>	</t>

		<t>The initialization vector (aes-nonce) <bcp14>MUST</bcp14> be
	<t>The initialization vector (aes-nonce) MUST be generated in accordance with Se	generated in accordance with Section 8.2 of <xref target="SP80038D"/>. AE
	ction 8.2 of [SP80038D]. AES-GCM loses security catastrophically if a nonce is r	S-GCM loses security catastrophically if a nonce is reused with a given key on m
	eused with a given key on more than one distinct set of input data. Therefore, a	ore than one distinct set of input data. Therefore, a fresh content-authenticate
	fresh content-authenticated encryption key MUST be generated for each message.	d encryption key <bcp14>MUST</bcp14> be generated for each message.
	</t>	</t>

		</section>
		<!-- aes-gcm-enc -->


	</section> <!-- aes-gcm-enc -->	<section anchor="aes-cbc-enc" numbered="true" toc="default">
		<name>AES-CBC Content Encryption</name>
	<section anchor="aes-cbc-enc" title="AES-CBC Content Encryption">	<t>CNSA Suite-compliant S/MIME implementations using the
		enveloped-data content type <bcp14>MUST</bcp14> use AES-256 <xref
	<t>CNSA Suite compliant S/MIME implementations using the enveloped-data content	target="FIPS197" format="default"/> in Cipher Block Chaining (CBC)
	type MUST use <xref target="FIPS197">AES-256</xref> in <xref target="SP80038A">C	mode <xref target="SP80038A" format="default"/> as the content-encryption
	ipher Block Chaining (CBC) mode</xref> as the content encryption algorithm, and	algorithm and <bcp14>MUST</bcp14> follow the conventions for using AES with the
	MUST follow the conventions for using AES with the CMS defined in <xref target="	CMS defined in <xref target="RFC3565" format="default"/>.
	RFC3565" />.
	</t>	</t>

		<t>Within the CMS enveloped-data content type, content-encryption algori
	<t>Within the CMS enveloped-data content type, content-encryption algorithm iden	thm identifiers are located in the EnvelopedData EncryptedContentInfo contentEnc
	tifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionA	ryptionAlgorithm field. The content-encryption algorithm is used to encipher the
	lgorithm field. The content-encryption algorithm is used to encipher the content	content located in the EnvelopedData EncryptedContentInfo encryptedContent fiel
	located in the EnvelopedData EncryptedContentInfo encryptedContent field.	d.
	</t>	</t>

		<t>The AES-CBC content-encryption algorithm is described in <xref target ="FIPS197" format="default"/> and <xref target="SP80038A" format="default"/>. Th e algorithm identifier for AES-256 in CBC mode is:


	<t>The AES CBC content-encryption algorithm is described in <xref target="FIPS19	</t>
	7" /> and <xref target="SP80038A" />. The algorithm identifier for AES-256 in CB	<sourcecode name="" type="asn.1"><![CDATA[
	C mode is:

	<figure><artwork>
	id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-aes256-CBC 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) aes(1) 42 }	nistAlgorithm(4) aes(1) 42 }

	</artwork></figure>	]]></sourcecode>
	</t>	<t>The AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> be prese
		nt, and the parameters field must contain AES-IV:
	<t>The AlgorithmIdentifier parameters field MUST be present, and the parameters
	field must contain AES-IV:

	<figure><artwork>


		</t>
		<sourcecode name="" type="asn.1"><![CDATA[
	AES-IV ::= OCTET STRING (SIZE(16))	AES-IV ::= OCTET STRING (SIZE(16))

		]]></sourcecode>
	</artwork></figure>	<t>The 16-octet initialization vector is generated at random by the orig
	</t>	inator. See <xref target="RFC4086" format="default"/> for guidance on generation
		of random values.
	<t>The 16-octet initialization vector is generated at random by the originator.
	See <xref target="RFC4086" /> for guidance on generation of random values.
	</t>	</t>

		</section>
		<!-- aes-cbc-enc -->


	</section> <!-- aes-cbc-enc -->	</section>
		<!-- content-enc -->
	</section> <!-- content-enc -->

	<section anchor="sec-considerations" title="Security Considerations">

	<t>This document specifies the conventions for using the NSA's CNSA Suite alg
	orithms in S/MIME. All of the algorithms and algorithm identifiers have been spe
	cified in previous documents.
	</t>

	<t>See <xref target="RFC4086" /> for guidance on generation of random values.
	</t>

	<t>The security considerations in <xref target="RFC5652" /> discuss the CMS a
	s a method for digitally signing data and encrypting data.
	</t>

	<t>The security considerations in <xref target="RFC3370" /> discuss cryptogra
	phic algorithm implementation concerns in the context of the CMS.
	</t>

	<t>The security considerations in <xref target="RFC5753" /> discuss the use o
	f elliptic curve cryptography (ECC) in the CMS.
	</t>

	<t>The security considerations in <xref target="RFC3565" /> discuss the use o
	f AES in the CMS.
	</t>

	<t>The security considerations in <xref target="RFC8551" /> apply to this pro
	file, in particular the recommendation to use authenticated encryption modes (i.
	e. use authenticated-enveloped-data with AES-GCM rather than enveloped-data with
	AES-CBC).
	</t>

	</section> <!-- sec-considerations -->

	<section anchor="iana-considerations" title="IANA Considerations">


	<t>This document has no IANA actions.	<section anchor="sec-considerations" numbered="true" toc="default">
	</t>	<name>Security Considerations</name>
		<t>This document specifies the conventions for using the NSA's CNSA Suite
		algorithms in S/MIME. All of the algorithms and algorithm identifiers have been
		specified in previous documents.
		</t>
		<t>See <xref target="RFC4086" format="default"/> for guidance on generatio
		n of random values.
		</t>
		<t>The security considerations in <xref target="RFC5652" format="default"/
		> discuss the CMS as a method for digitally signing data and encrypting data.
		</t>
		<t>The security considerations in <xref target="RFC3370" format="default"/
		> discuss cryptographic algorithm implementation concerns in the context of the
		CMS.
		</t>
		<t>The security considerations in <xref target="RFC5753" format="default"/
		> discuss the use of elliptic curve cryptography (ECC) in the CMS.
		</t>
		<t>The security considerations in <xref target="RFC3565" format="default"/
		> discuss the use of AES in the CMS.
		</t>
		<t>The security considerations in <xref target="RFC8551" format="default"/
		> apply to this profile, particularly the recommendation to use authenticated en
		cryption modes (i.e., use authenticated-enveloped-data with AES-GCM rather than
		enveloped-data with AES-CBC).
		</t>
		</section>
		<!-- sec-considerations -->


	</section> <!-- iana-considerations -->	<section anchor="iana-considerations" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>This document has no IANA actions.
		</t>
		</section>
		<!-- iana-considerations -->

	</middle>	</middle>

		<!-- ***END MIDDLE MATTER *** -->
	<!-- ***END MIDDLE MATTER *** -->

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

	<back>	<back>

		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>


	<references title="Normative References">	<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Pol
		icies.cfm">
	<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Polic	<front>
	ies.htm">	<title>Use of Public Standards for Secure Information Sharing</title
	<front>	>
	<title>Use of Public Standards for Secure Information Sharing</title>	<seriesInfo name="CNSS Policy" value="15"/>
	<author><organization>Committee for National Security Systems</organiz	<author>
	ation></author>	<organization>Committee for National Security Systems</organizatio
	<date month="October" year="2016"></date>	n>
	</front>	</author>
	<seriesInfo name="CNSSP" value="15"></seriesInfo>	<date month="October" year="2016"/>
	</reference> <!-- CNSA -->	</front>
		</reference>
		<!-- CNSA -->

	<reference anchor="FIPS197" target="https://csrc.nist.gov/publications/det ail/fips/197/final">	<reference anchor="FIPS197" target="https://csrc.nist.gov/publications/det ail/fips/197/final">

	<front>	<front>
	<title>Advanced Encryption Standard (AES)</title>	<title>Advanced Encryption Standard (AES)</title>

		<seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
		<seriesInfo name="FIPS PUB" value="197"/>
	<author>	<author>

	<organization>National Institute of Standards and Technology</org anization>	<organization>National Institute of Standards and Technology</orga nization>
	</author>	</author>

	<date month="November" year="2001" />	<date month="November" year="2001"/>
	</front>	</front>
	<seriesInfo name="Federal Information Processing Standard" value="19	</reference>
	7" />	<!-- FIPS197 -->
	</reference> <!-- FIPS197 -->

	<reference anchor="SP80038A" target="https://csrc.nist.gov/publications/de tail/sp/800-38a/final">	<reference anchor="SP80038A" target="https://csrc.nist.gov/publications/de tail/sp/800-38a/final">

	<front>	<front>
	<title>Recommendation for Block Cipher Modes of Operation: Methods a	<title>Recommendation for Block Cipher Modes of Operation: Methods
	nd Techniques</title>	and Techniques</title>
	<author>	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
	<organization>National Institute of Standards and Technology</org	<seriesInfo name="Special Publication" value="800-38A"/>
	anization>	<author fullname="Morris Dworkin" initials="M." surname="Dworkin"/>
	</author>	<date month="December" year="2001"/>
	<date month="December" year="2001" />	</front>
	</front>	</reference>
	<seriesInfo name="Special Publication" value="800-38A" />	<!-- SP80038A -->
	</reference> <!-- SP80038A -->

	<reference anchor="SP80038D" target="https://csrc.nist.gov/publications/de tail/sp/800-38d/final">	<reference anchor="SP80038D" target="https://csrc.nist.gov/publications/de tail/sp/800-38d/final">

	<front>	<front>
	<title>Recommendation for Block Cipher Modes of Operation: Galois/Co	<title>Recommendation for Block Cipher Modes of Operation:
	unter Mode (GCM) and GMAC</title>	Galois/Counter Mode (GCM) and GMAC</title>
	<author>	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
	<organization>National Institute of Standards and Technology</org	<seriesInfo name="Special Publication" value="800-38D"/>
	anization>	<author fullname="Morris Dworkin" initials="M." surname="Dworkin"/>
	</author>	<date month="November" year="2007"/>
	<date month="November" year="2007" />	</front>
	</front>	</reference>
	<seriesInfo name="Special Publication" value="800-38D" />	<!-- SP80038D -->
	</reference> <!-- SP80038D -->

	<reference anchor="SP80038F" target="https://csrc.nist.gov/publications/de tail/sp/800-38f/final">	<reference anchor="SP80038F" target="https://csrc.nist.gov/publications/de tail/sp/800-38f/final">

	<front>	<front>
	<title>Recommendation for Block Cipher Modes of Operation: Methods f	<title>Recommendation for Block Cipher Modes of Operation: Methods
	or Key Wrapping</title>	for Key Wrapping</title>
	<author>	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38F"/>
	<organization>National Institute of Standards and Technology</org	<seriesInfo name="Special Publication" value="800-38F"/>
	anization>	<author fullname="Morris Dworkin" initials="M." surname="Dworkin"/>
	</author>	<date month="December" year="2012"/>
	<date month="December" year="2012" />	</front>
	</front>	</reference>
	<seriesInfo name="Special Publication" value="800-38F" />	<!-- SP80038F -->
	</reference> <!-- SP80038F -->

	<reference anchor="FIPS180" target="https://csrc.nist.gov/publications/det ail/fips/180/4/final">	<reference anchor="FIPS180" target="https://csrc.nist.gov/publications/det ail/fips/180/4/final">

	<front>	<front>
	<title>Secure Hash Standard (SHS)</title>	<title>Secure Hash Standard (SHS)</title>

		<seriesInfo name="Federal Information Processing Standard" value="18 0-4"/>
	<author>	<author>

	<organization>National Institute of Standards and Technology</org anization>	<organization>National Institute of Standards and Technology</orga nization>
	</author>	</author>

	<date month="August" year="2015" />	<date month="August" year="2015"/>
	</front>	</front>
	<seriesInfo name="Federal Information Processing Standard" value="18	</reference>
	0-4" />	<!-- FIPS180 -->
	</reference> <!-- FIPS180 -->

	<reference anchor="FIPS186" target="https://csrc.nist.gov/publications/det ail/fips/186/4/final">	<reference anchor="FIPS186" target="https://csrc.nist.gov/publications/det ail/fips/186/4/final">

	<front>	<front>
	<title>Digital Signature Standard</title>	<title>Digital Signature Standard (DSS)</title>
	<author>	<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
	<organization>National Institute of Standards and Technology</organi	<seriesInfo name="FIPS PUB" value="186-4"/>
	zation>	<author>
	</author>	<organization>National Institute of Standards and Technology</orga
	<date month="July" year="2013" />	nization>
	</front>	</author>
	<seriesInfo name="Federal Information Processing Standard" value="186-4"	<date month="July" year="2013"/>
	/>	</front>
	</reference> <!-- FIPS186 -->	</reference>
		<!-- FIPS186 -->

	<reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">	<reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">

	<front>	<front>
	<title>SEC1: Elliptic Curve Cryptography</title>	<title>SEC1: Elliptic Curve Cryptography</title>
	<author>	<author>
	<organization>Standards for Efficient Cryptography Group</organizati	<organization>Standards for Efficient Cryptography Group</organiza
	on>	tion>
	</author>	</author>
	<date month="May" year="2009"/>	<date month="May" year="2009"/>
	</front>	</front>
	</reference> <!-- SEC1 -->	</reference>
		<!-- SEC1 -->


	&rfc2119;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
	&rfc2631;	xml"/>
	&rfc3370;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc3560;	FC.2631.xml"/>
	&rfc3565;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc4055;	FC.3370.xml"/>
	&rfc4056;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc5083;	FC.3560.xml"/>
	&rfc5084;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc5480;	FC.3565.xml"/>
	&rfc5649;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc5652;	FC.4055.xml"/>
	&rfc5753;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc5754;	FC.4056.xml"/>
	&rfc8017;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc8174;	FC.5083.xml"/>
	&rfc8551;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&rfc8603;	FC.5084.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5480.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5649.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5652.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5753.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5754.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8017.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8551.xml"/>
		<xi:include
		href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.x
		ml"/>


	<reference anchor="X208" target="https://www.itu.int/rec/T-REC-X.208-19881	<reference anchor="X208" target="https://www.itu.int/rec/T-REC-X.208-198
	1-W/en">	811-W/en">
	<front>	<front>
	<title>Recommendation X.208: Specification of Abstract Syntax Notation	<title>Specification of Abstract Syntax Notation One (ASN.1)</title>
	One (ASN.1)</title>	<seriesInfo name="CCITT Recommendation" value="X.208"/>
	<author>	<author>
	<organization>CCITT</organization>	<organization>CCITT</organization>
	</author>	</author>
	<date month="" year="1988"/>	<date year="1988"/>
	</front>	</front>
	</reference> <!-- X208 -->	</reference>
		<!-- X208 -->

	<reference anchor="X209" target="https://www.itu.int/rec/T-REC-X.209-19881 1-W/en">	<reference anchor="X209" target="https://www.itu.int/rec/T-REC-X.209-19881 1-W/en">

	<front>	<front>
	<title>Recommendation X.209: Specification of Basic Encoding Rules for	<title>Specification of Basic Encoding Rules
	Abstract Syntax Notation One (ASN.1)</title>	for Abstract Syntax Notation One (ASN.1)</title>
	<author>	<seriesInfo name="CCITT Recommendation" value="X.209"/>
	<organization>CCITT</organization>	<author>
	</author>	<organization>CCITT</organization>
	<date month="" year="1988"/>	</author>
	</front>	<date year="1988"/>
	</reference> <!-- X209 -->	</front>
		</reference>
		<!-- X209 -->

	<reference anchor="X509" target="https://www.itu.int/rec/T-REC-X.509-19881 1-S">	<reference anchor="X509" target="https://www.itu.int/rec/T-REC-X.509-19881 1-S">

	<front>	<front>
	<title>Recommendation X.509: The Directory - Authentication Framework<	<title>The Directory - Authentication Framework</title>
	/title>	<seriesInfo name="CCITT Recommendation" value="X.509"/>
	<author>	<author>
	<organization>CCITT</organization>	<organization>CCITT</organization>
	</author>	</author>
	<date month="" year="1988"/>	<date year="1988"/>
	</front>	</front>
	</reference> <!-- X509 -->	</reference>
		<!-- X509 -->
	</references> <!-- Normative -->

	<references title="Informative References">


		</references>
		<references>
		<name>Informative References</name>
	<reference anchor="SP80059" target="https://csrc.nist.gov/publications/d etail/sp/800-59/final">	<reference anchor="SP80059" target="https://csrc.nist.gov/publications/d etail/sp/800-59/final">
	<front>	<front>

	<title>Guideline for Identifying an Information System as a Nation	<title>Guideline for Identifying an Information System as a
	al Security System</title>	National Security System</title>
	<author>	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
	<organization>National Institute of Standards and Technology</	<seriesInfo name="Special Publication" value="800-59"/>
	organization>	<author fullname="William Barker" initials="W." surname="Barker"/>
	</author>	<date month="August" year="2003"/>
	<date month="August" year="2003" />
	</front>	</front>

	<seriesInfo name="Special Publication 800-59" value="" />	</reference>
	</reference> <!-- SP-800-57 -->	<!-- SP-800-57 -->

	&rfc4086;


	</references> <!-- Informative -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.
		xml"/>
		</references>
		</references>

	</back>	</back>


	</rfc>	</rfc>

End of changes. 148 change blocks.
	837 lines changed or deleted	754 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/