<?xmlversion="1.0" encoding="UTF-8"?>version='1.0' encoding='utf-8'?> <!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. -->"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 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 instructionsdocName="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> <title abbrev="CNSA Suite for S/MIME">Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions</title> <seriesInfo name="RFC" value="8755"/> <author fullname="Michael Jenkins" initials="M." surname="Jenkins"> <organization abbrev="NSA">National Security Agency</organization><address><email>mjjenki@nsa.gov</email></address><address> <email>mjjenki@nsa.gov</email> </address> </author> <dateyear="2019"/> <!-- Current month and day will be filled in. --> <!-- Meta-data Declarations -->month="March" year="2020"/> <area>Security</area> <workgroup>Internet Engineering Task Force</workgroup> <keyword>NSA</keyword> <keyword>CNSA</keyword> <keyword>NSS</keyword> <keyword>smime</keyword> <abstract> <t>The United States Government has published theNSANational Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.</t> </abstract> </front> <!-- ***** END FRONT MATTER ***** --> <!-- ***** DOCUMENT BODY ***** --> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This document specifies the conventions for using the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite algorithms <xref target="CNSA"/>format="default"/> in Secure/Multipurpose Internet Mail Extensions (S/MIME) <xref target="RFC8551"/>.format="default"/>. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59 <xref target="SP80059"/>.format="default"/>. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. </t> <t>S/MIME makes use of the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/>format="default"/> <xref target="RFC5083"/>.format="default"/>. In particular, the signed-data, enveloped-data, and authenticated-enveloped-data content types are used. This document only addresses CNSA Suite compliance for S/MIME. Other applications of CMS are outside the scope of this document. </t> <t>This document does not define any new cryptographic algorithmsuite;suites; instead, it defines aCNSA compliantCNSA-compliant profile of S/MIME. Since many of the CNSA Suite algorithms enjoy uses in other environments as well, the majority of the conventions needed for these algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support the CNSA Suite. Where details have been repeated, the cited documents are authoritative. </t> <section anchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <!-- terminology --> </section> <!-- intro --> <section anchor="cnsa"title="Thenumbered="true" toc="default"> <name>The Commercial National Security AlgorithmSuite">Suite</name> <t>The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance both to assist with the US Government transition to newalgorithms,algorithms and to provide vendors--- and the Internet community in general--- with information concerning their proper use and configuration. </t> <t>Recently, cryptographic transition plans have become overshadowed by the prospect of the development of acryptographically-relevantcryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their cybersecurity interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customersmakingmake two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future. </t><t>NSA<t>The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National SecuritySystems..Systems. </t> </section> <!-- cnsa --> <sectionanchor="terminology" title="Terminology"> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, they appear in all capitals, as shown here. </t> </section> <!-- terminology --> <sectionanchor="reqts"title="Requirementsnumbered="true" toc="default"> <name>Requirements andAssumptions">Assumptions</name> <t>CMS values are generated using ASN.1 <xref target="X208"/>,format="default"/>, the Basic Encoding Rules (BER) <xref target="X209"/>,format="default"/>, and the Distinguished Encoding Rules (DER) <xref target="X509"/>.format="default"/>. </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 names. For the sake of clarity, we list both names below:<figure><artwork> Curve NIST Name SECG Name OID [FIPS186] --------------------------------------------------------- nistp384 P-384 secp384r1 1.3.132.0.34 </artwork></figure></t> <table anchor="curve" align="left"> <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/MIME signaturesMUST<bcp14>MUST</bcp14> be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL)Profileprofile specified in <xref target="RFC8603"/>.format="default"/>. </t> <t>Within the CMS signed-data content type, signature algorithm identifiers are located in the signatureAlgorithm field of SignerInfo structures contained within the SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes. Specific requirements for digital signatures are given in <xref target="digital-signature"/>;format="default"/>; compliant implementationsMUST<bcp14>MUST</bcp14> consider signatures not meeting these requirements as invalid. </t><t>Elliptic<t>Implementations based on Elliptic Curve Cryptography (ECC)based implementationsalso require specification of schemes for key derivation and key wrap. Requirements for these schemes are insectionsSections <xref target="kdf"/>format="counter"/> and <xref target="keywrap"/> repectively.format="counter"/>, respectively. </t> <t>RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 bits, respectively. </t> <t>RSA signature key pairs used in CNSASuite compliantSuite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent eMUST<bcp14>MUST</bcp14> satisfy2^16<e<2^2562<sup>16</sup> < e < 2<sup>256</sup> and be odd per <xref target="FIPS186"/>.format="default"/>. </t> <t>It is recognized that, while the vast majority of RSA signatures are currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSASuite compliantSuite-compliant X.509 certificates will be issued in accordance with <xref target="RFC8603"/>,format="default"/>, and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's RSA key pair can be used to generate and validate signatures appropriate for either signing scheme. Where use of RSASSA-PSS is indicated in this document, the parameters in <xref target="rsa-pss"/>format="default"/> apply. </t> <t>This document assumes that the required trust anchors have been securely provisioned to the client. </t> <t>All implementations use SHA-384 for hashing and either AES-CBC or AES-GCM for encryption, the requirements for which are given in <xref target="message-digest"/>format="default"/> and <xref target="content-enc"/>,format="default"/>, respectively. </t> </section> <!-- reqts --> <section anchor="message-digest"title="SHA-384numbered="true" toc="default"> <name>SHA-384 Message DigestAlgorithm">Algorithm</name> <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 Cryptographic Message Syntax (CMS). CNSASuite compliantSuite-compliant S/MIME implementationsMUST<bcp14>MUST</bcp14> follow the conventions in <xref target="RFC5754"/>.format="default"/>. </t> <t>Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field. </t> <t>The SHA-384 message digest algorithm is defined in FIPS Pub 180 <xref target="FIPS180"/>.format="default"/>. The algorithm identifier for SHA-384 is defined in <xref target="RFC5754"/>format="default"/> as follows:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 }</artwork></figure> </t>]]></sourcecode> <t>For SHA-384, the AlgorithmIdentifier parameters field isOPTIONAL,<bcp14>OPTIONAL</bcp14>, and if present, the parameters fieldMUST<bcp14>MUST</bcp14> contain a NULL. As specified in <xref target="RFC5754"/>,format="default"/>, implementationsMUST<bcp14>MUST</bcp14> generate SHA-384 AlgorithmIdentifiers with absent parameters. ImplementationsMUST<bcp14>MUST</bcp14> accept SHA-384 AlgorithmIdentifiers with absent parameters or with NULL parameters. </t> </section> <!-- message-digest --> <section anchor="digital-signature"title="Digital Signature">numbered="true" toc="default"> <name>Digital Signature</name> <section anchor="ecc-dig-sig"title="ECDSA Signature">numbered="true" toc="default"> <name>ECDSA Signature</name> <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Suite digital signature algorithm based on ECC. <xref target="RFC5753"/>format="default"/> specifies the conventions for using ECDSA with the Cryptographic Message Syntax (CMS). CNSASuite compliantSuite-compliant S/MIME implementationsMUST<bcp14>MUST</bcp14> follow the conventions in <xref target="RFC5753"/>.format="default"/>. </t> <t><xref target="RFC5480"/>format="default"/> defines the signature algorithm identifier used in CMS for ECDSA with SHA-384 as follows:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }</artwork></figure> </t>]]></sourcecode> <t>When the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> be absent. </t> <t>When signing, the ECDSA algorithm generates two values, commonly called r and s. These two valuesMUST<bcp14>MUST</bcp14> be encoded using the ECDSA-Sig-Value type specified in <xref target="RFC5480"/>: <figure><artwork>format="default"/>: </t> <sourcecode name="" type="asn.1"><![CDATA[ ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }</artwork></figure> </t>]]></sourcecode> </section> <!-- ecc-dig-sig --> <section anchor="rsa-dig-sig"title="RSA Signature">numbered="true" toc="default"> <name>RSA Signature</name> <t>The RSA signature generation process and the encoding of the result is either RSASSA-PKCS1-v1_5 orRSA-PSSRSA-PSS, as described in detail in PKCS #1 version 2.2 <xref target="RFC8017"/>.format="default"/>. </t> <section anchor="rsa-pkcs1"title="RSA-PKCS1-v1_5">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 follows:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ sha384WithRSAEncryption OBJECT IDENTIFIER:==::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }</artwork></figure> </t>]]></sourcecode> <t>When the sha384WithRSAEncryption algorithm identifier is used, the parametersMUST<bcp14>MUST</bcp14> be NULL. ImplementationsMUST<bcp14>MUST</bcp14> accept the parameters being absent as well as present. </t> </section> <!-- rsa-pkcs1 --> <section anchor="rsa-pss"title="RSA-PSS">numbered="true" toc="default"> <name>RSA-PSS</name> <t><xref target="RFC4056"/>format="default"/> defines the signature algorithm identifier used in CMS for an RSA-PSS signature asfollows: <figure><artwork>follows (presented here in expanded form): </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 }</artwork></figure> </t>]]></sourcecode> <t>The parameters field of an AlgorithmIdentifier that identifies RSASSA-PSS is defined in <xref target="RFC4055"/>format="default"/> as follows:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 }</artwork></figure> </t>]]></sourcecode> <t>The AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> contain RSASSA-PSS-params with the following values:<list style="symbols"> <t>the</t> <ul spacing="normal"> <li>The hash algorithmMUST<bcp14>MUST</bcp14> be id-sha384 as defined in <xref target="RFC8017"/>;</t> <t>theformat="default"/>;</li> <li>The mask generation functionMUST<bcp14>MUST</bcp14> use the algorithm identifier mfg1SHA384Identifier as defined in <xref target="RFC4055"/>;</t> <t>theformat="default"/>;</li> <li>The salt lengthMUST<bcp14>MUST</bcp14> be 48 octets (the same length as the SHA-384 output);and</t> <t>theand</li> <li>The trailerFieldMUST<bcp14>MUST</bcp14> have value1.</t> </list> </t>1.</li> </ul> </section> <!-- rsa-pss --> </section> <!-- rsa-dig-sig --> </section> <!-- digital-signature --> <section anchor="key-establishment"title="Key Establishment">numbered="true" toc="default"> <name>Key Establishment</name> <section anchor="ecc-ka"title="Ellipticnumbered="true" toc="default"> <name>Elliptic Curve KeyAgreement">Agreement</name> <t>Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement algorithm. Since S/MIME is used in store-and-forward communications, ephemeral-static ECDH is always employed. This means that the message originator possesses an ephemeral ECDH key pair and that the message recipient possesses a static ECDH key pair whose public key is provided in an X.509 certificate. The certificate used to obtain the recipient's public keyMUST<bcp14>MUST</bcp14> be compliant with <xref target="RFC8603"/>.format="default"/>. </t> <t>When a key agreement algorithm is used, the following steps are performed:<list style="numbers"> <t>A</t> <ol spacing="normal" type="1"> <li>A content-encryption key (CEK) for a particular content-encryption algorithm is generated atrandom.</t> <t>Therandom.</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).</t> <t>The(Z).</li> <li>The shared secret is used with a key derivation function (KDF) to produce a key-encryption key(KEK).</t> <t>The(KEK).</li> <li>The KEK is used with a key wrap algorithm to encrypt theCEK.</t> </list>CEK.</li> </ol> <t> Key derivation is discussed in <xref target="kdf"/>.format="default"/>. Key wrapping is discussed in <xref target="keywrap"/>.format="default"/>. </t><t>Section 3.1 of <xref<t><xref target="RFC5753"/>sectionFormat="of" section="3.1"/> specifies the conventions for using ECDH with the CMS. CNSASuite compliantSuite-compliant S/MIME implementationsMUST<bcp14>MUST</bcp14> follow these conventions. </t> <t>Within the CMS enveloped-data and authenticated-enveloped-data content types, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. </t> <t>The keyEncryptionAlgorithm field comprises two fields, an algorithm field and a parameter field. The algorithm fieldMUST<bcp14>MUST</bcp14> identify dhSinglePass-stdDH-sha384kdf-scheme. The algorithm identifier for the dhSinglePass-stdDH-sha384kdf-scheme, repeated fromSection 7.1.4 of<xref target="RFC5753"/>, is: <figure><artwork>sectionFormat="of" section="7.1.4"/>, is (presented here in expanded form): </t> <sourcecode name="" type="asn.1"><![CDATA[ dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11 2 }</artwork></figure> </t>]]></sourcecode> <t>The keyEncryptionAlgorithm parameter fieldMUST<bcp14>MUST</bcp14> be constructed as described in <xref target="keywrap"/>.format="default"/>. </t> <section anchor="kdf"title="Keynumbered="true" toc="default"> <name>Key DerivationFunctions">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. Sections7.1.8<xref target="RFC5753" section="7.1.8" sectionFormat="bare"/> and7.2 of<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. CNSASuite compliantSuite-compliant S/MIME implementationsMUST<bcp14>MUST</bcp14> follow these conventions. </t> <t>As specified inSection 7.1.8 of<xref target="RFC5753"/>,sectionFormat="of" section="7.1.8"/>, the ANSI-X9.63-KDF described in Section 3.6.1 of <xreftarget="SEC1" />target="SEC1"/> and based on SHA-384MUST<bcp14>MUST</bcp14> be used. </t> <t>As specified inSection 7.2 of<xref target="RFC5753"/>,sectionFormat="of" section="7.2"/>, when using ECDH 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></t> <sourcecode name="" type="asn.1"><![CDATA[ ECC-CMS-SharedInfo ::= SEQUENCE { keyInfo AlgorithmIdentifier, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, suppPubInfo [2] EXPLICIT OCTET STRING }</artwork></figure> </t>]]></sourcecode> <t>In the CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used as follows:<list style="hanging"> <t>keyInfo</t> <ul empty="false"> <li>keyInfo contains the object identifier of the key-encryption algorithm used to wrap the content-encryption key. If AES-256 Key Wrap is used, then the keyInfo will contain id-aes256-wrap-pad, and the parameters will be absent.</t> <t>entityUInfo</li> <li>entityUInfo optionally contains a random value provided by the message originator. If user keying material (ukm) is included in the KeyAgreeRecipientInfo, then the entityUInfoMUST<bcp14>MUST</bcp14> be present, and itMUST<bcp14>MUST</bcp14> contain the ukm value. If the ukm is not present, then the entityUInfoMUST<bcp14>MUST</bcp14> be absent.</t> <t>suppPubInfo</li> <li>suppPubInfo contains the length of the generated key-encryptionkey,key in bits, represented as a 32-bit unsigned number, as described in <xref target="RFC2631"/>.format="default"/>. When a 256-bit AES key is used, the lengthMUST<bcp14>MUST</bcp14> be 0x00000100.</t> </list> </t></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 <xreftarget="SEC1" />.target="SEC1"/>. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in <xref target="RFC2631"/>.format="default"/>. Here, a counter value is not included in the keyInfo field because the KDF specified in <xref target="SEC1"/>format="default"/> ensures that sufficient keying data is provided. </t> <t>The KDF specified in Section 3.6.1 of <xreftarget="SEC1" />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-encryption key (KEK),KM is computed: <figure><artwork>blocks of key material (KM) are computed by incrementing Counter appropriately until enough material has been generated: </t> <sourcecode name="" type="pseudocode"><![CDATA[ KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )</artwork></figure> incrementing Counter appropriately, until enough material has been generated.]]></sourcecode> <t> The KM blocks are concatenated left toright,right as they are generated, and the first (leftmost) L bits are used as the KEK:<figure><artwork></t> <sourcecode name="" type="pseudocode"><![CDATA[ KEK = the leftmost L bits of [KM ( counter=1 ) || KM ( counter=2 ) ...]</artwork></figure> </t>]]></sourcecode> <t>In the CNSA Suite for S/MIME, the elements of the KDF are defined as follows:<list style="hanging"> <t>Hash</t> <ul empty="false"> <li>Hash is a one-way hash function. The SHA-384 hashMUST<bcp14>MUST</bcp14> be used.</t> <t>Z</li> <li>Z is the shared secret value generated during ephemeral-static ECDH. ZMUST<bcp14>MUST</bcp14> be exactly 384 bits, i.e., leading zero bitsMUST<bcp14>MUST</bcp14> be preserved.</t> <t>Counter</li> <li>Counter is a 32-bit unsignednumber,number represented in network byte order. Its initial valueMUST<bcp14>MUST</bcp14> be 0x00000001 for any key derivation operation.</t> <t>ECC-CMS-SharedInfo</li> <li>ECC-CMS-SharedInfo is composed as described above. ItMUST<bcp14>MUST</bcp14> be DER encoded.</t> </list></t></li> </ul> <t> In the CNSA Suite for S/MIME, exactly one iteration is needed; the Counter is not incremented. The key-encryption key (KEK)MUST<bcp14>MUST</bcp14> be the first (leftmost) 256 bits of the SHA-384 output value:<figure><artwork></t> <sourcecode name="" type="pseudocode"><![CDATA[ KEK = the leftmost 256 bits of SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )</artwork></figure> </t>]]></sourcecode> <t>Note that the only source of secret entropy in this computation is Z. </t> </section> <!-- kdf --> <section anchor="keywrap"title="AESnumbered="true" toc="default"> <name>AES KeyWrap">Wrap</name> <t>The AES Key Wrap with Padding key-encryption algorithm, as specified in <xref target="RFC5649"/>format="default"/> and <xref target="SP80038F"/>,format="default"/>, is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH.Section 8 of<xref target="RFC5753"/>sectionFormat="of" section="8"/> specifies the CMS conventions for using AES Key Wrap with a pairwise key generated through ephemeral-static ECDH. CNSASuite compliantSuite-compliant S/MIME implementationsMUST<bcp14>MUST</bcp14> follow these conventions. </t> <t>Within the CMS enveloped-data content type, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. </t> <t>The KeyWrapAlgorithmMUST<bcp14>MUST</bcp14> be id-aes256-wrap-pad. The required algorithm identifier, specified in <xref target="RFC5649"/>,format="default"/>, is:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ id-aes256-wrap-pad OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 48 }</artwork></figure> </t>]]></sourcecode> </section> <!-- keywrap --> </section> <!-- ecc-ka --> <section anchor="rsa-kt"title="RSAnumbered="true" toc="default"> <name>RSA KeyTransport">Transport</name> <t>RSA encryption (RSA) is the CNSA Suite key transport algorithm. The RSA key transport algorithm is the RSA encryption scheme defined in <xref target="RFC8017"/>,format="default"/>, where the message to be encrypted is the content-encryption key. </t> <t>The recipient of an S/MIME message possesses an RSA key pair whose public key is represented by an X.509 certificate. The certificate used to obtain the recipient's public keyMUST<bcp14>MUST</bcp14> be compliant with <xref target="RFC8603"/>.format="default"/>. These certificates are suitable for use with either RSAES-OAEP or RSAES-PKCS1-v1_5. </t> <section anchor="rsaes-PKCS1"title="RSAES-PKCS1-v1_5"> <t>Section 4.2 of <xrefnumbered="true" toc="default"> <name>RSAES-PKCS1-v1_5</name> <t><xref target="RFC3370"/>sectionFormat="of" section="4.2"/> specifies the conventions for using RSAES-PKCS1-v1_5 with the CMS. S/MIME implementations employing this form of key transportMUST<bcp14>MUST</bcp14> follow these conventions. </t> <t>Within the CMS enveloped-data and authenticated-enveloped-data content types, key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. </t> <t>The algorithm identifier for RSA (PKCS #1 v1.5) is:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }</artwork></figure> </t>]]></sourcecode> <t>The AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> be present, and the parameters fieldMUST<bcp14>MUST</bcp14> contain NULL. </t> </section> <!-- rsaes-PKCS1 --> <section anchor="rsaes-OAEP"title="RSAES-OAEP">numbered="true" toc="default"> <name>RSAES-OAEP</name> <t><xref target="RFC3560"/>format="default"/> specifies the conventions for using RSAES-OAEP with the CMS. CNSASuite compliantSuite-compliant S/MIME implementations employing this form of key transportMUST<bcp14>MUST</bcp14> follow these conventions. </t> <t>Within the CMS enveloped-data and authenticated-enveloped-data content types, key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. </t> <t>The algorithm identifier for RSA (OAEP) is:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }</artwork></figure> </t>]]></sourcecode> <t>The parameters field of an AlgorithmIdentifier that identifies RSAES-OAEP is defined in <xref target="RFC4055"/>format="default"/> as follows:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ RSAES-OAEP-params ::= SEQUENCE { hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier } pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= { id-pSpecified, nullOctetString } nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }</artwork></figure> </t>]]></sourcecode> <t>The AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> be present, and the parameters fieldMUST<bcp14>MUST</bcp14> contain RSAES-OAEP-params with values as follows:<list style="symbols"> <t>the</t> <ul spacing="normal"> <li>The hashFunc algorithm must be id-sha384 as defined in <xref target="RFC8017"/>;</t> <t>theformat="default"/>;</li> <li>The mask generation function must use the algorithm identifier mfg1SHA384Identifier as defined in <xref target="RFC4055"/>;</t> <t>theformat="default"/>;</li> <li>The pSourceFunc field must beabsent.</t> </list> </t>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, itMUST<bcp14>MUST</bcp14> be constructed as defined inSection 5 of<xref target="RFC3560"/>,sectionFormat="of" section="5"/>, with the sequence representing the rSAES-OAEP-SHA384-Identifier. </t> </section> <!-- rsaes-OAEP --> </section> <!-- rsa-kt --> </section> <!-- key-establishment --> <section anchor="content-enc"title="Content Encryption">numbered="true" toc="default"> <name>Content Encryption</name> <t>AES-GCM is the preferred mode for CNSA Suiteapplicationsapplications, as described in the <xreftarget="sec-considerations">Securitytarget="sec-considerations" format="default">Security Considerations</xref>. AES-CBC is acceptable where AES-GCM is not yet available. </t> <section anchor="aes-gcm-enc"title="AES-GCMnumbered="true" toc="default"> <name>AES-GCM ContentEncryption">Encryption</name> <t>CNSASuite compliantSuite-compliant S/MIME implementations using the authenticated-enveloped-data content type <xref target="RFC5083"/> MUSTformat="default"/> <bcp14>MUST</bcp14> use AES <xreftarget="FIPS197">AES</xref>target="FIPS197" format="default"/> in<xref target="SP80038D">GaloisGalois Counter Mode(GCM)</xref>(GCM) <xref target="SP80038D" format="default"/> as the content-authenticated encryptionalgorithm,algorithm andMUST<bcp14>MUST</bcp14> follow the conventions for using AES-GCM with the CMS defined in <xref target="RFC5084"/>.format="default"/>. </t> <t>Within the CMS authenticated-enveloped-data content type, content-authenticated encryption algorithm identifiers are located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-authenticated encryption algorithm is used to encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field. </t> <t>The AES-GCM content-authenticated encryption algorithm is described in <xref target="FIPS197"/>format="default"/> and <xref target="SP80038D"/>.format="default"/>. The algorithm identifier for AES-256 in GCM mode is:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ id-aes256-GCM OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 46 }</artwork></figure> </t>]]></sourcecode> <t>The AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> be present, and the parameters field must contain GCMParameters:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ GCMParameters ::= SEQUENCE { aes-nonce OCTET STRING, aes-ICVlenAES-GCM-IVClenAES-GCM-ICVlen DEFAULT 12 }</artwork></figure> </t>]]></sourcecode> <t>The authentication tag length (aes-ICVlen)SHALL<bcp14>SHALL</bcp14> be 16 (indicating a tag length of 128 bits). </t> <t>The initialization vector (aes-nonce)MUST<bcp14>MUST</bcp14> be generated in accordance with Section 8.2 of[SP80038D].<xref target="SP80038D"/>. AES-GCM loses security catastrophically if a nonce is reused with a given key on more than one distinct set of input data. Therefore, a fresh content-authenticated encryption keyMUST<bcp14>MUST</bcp14> be generated for each message. </t> </section> <!-- aes-gcm-enc --> <section anchor="aes-cbc-enc"title="AES-CBCnumbered="true" toc="default"> <name>AES-CBC ContentEncryption">Encryption</name> <t>CNSASuite compliantSuite-compliant S/MIME implementations using the enveloped-data content typeMUST<bcp14>MUST</bcp14> use AES-256 <xreftarget="FIPS197">AES-256</xref>target="FIPS197" format="default"/> in<xref target="SP80038A">CipherCipher Block Chaining (CBC)mode</xref>mode <xref target="SP80038A" format="default"/> as thecontent encryption algorithm,content-encryption algorithm andMUST<bcp14>MUST</bcp14> follow the conventions for using AES with the CMS defined in <xref target="RFC3565"/>.format="default"/>. </t> <t>Within the CMS enveloped-data content type, content-encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-encryption algorithm is used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field. </t> <t>TheAES CBCAES-CBC content-encryption algorithm is described in <xref target="FIPS197"/>format="default"/> and <xref target="SP80038A"/>.format="default"/>. The algorithm identifier for AES-256 in CBC mode is:<figure><artwork></t> <sourcecode name="" type="asn.1"><![CDATA[ id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 42 }</artwork></figure> </t>]]></sourcecode> <t>The AlgorithmIdentifier parameters fieldMUST<bcp14>MUST</bcp14> 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))</artwork></figure> </t>]]></sourcecode> <t>The 16-octet initialization vector is generated at random by the originator. See <xref target="RFC4086"/>format="default"/> for guidance on generation of random values. </t> </section> <!-- aes-cbc-enc --> </section> <!-- content-enc --> <section anchor="sec-considerations"title="Security Considerations">numbered="true" toc="default"> <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 generation 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,in particularparticularly the recommendation to use authenticated encryption modes(i.e.(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">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANA actions. </t> </section> <!-- iana-considerations --> </middle> <!-- *****END MIDDLE MATTER ***** --> <!-- *****BACK MATTER ***** --> <back><references title="Normative References"><references> <name>References</name> <references> <name>Normative References</name> <reference anchor="CNSA"target="https://www.cnss.gov/CNSS/Issuances/Policies.htm">target="https://www.cnss.gov/CNSS/Issuances/Policies.cfm"> <front> <title>Use of Public Standards for Secure Information Sharing</title><author><organization>Committee<seriesInfo name="CNSS Policy" value="15"/> <author> <organization>Committee for National SecuritySystems</organization></author>Systems</organization> </author> <date month="October"year="2016"></date>year="2016"/> </front><seriesInfo name="CNSSP" value="15"></seriesInfo></reference> <!-- CNSA --> <reference anchor="FIPS197" target="https://csrc.nist.gov/publications/detail/fips/197/final"> <front> <title>Advanced Encryption Standard (AES)</title> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/> <seriesInfo name="FIPS PUB" value="197"/> <author> <organization>National Institute of Standards and Technology</organization> </author> <date month="November"year="2001" />year="2001"/> </front><seriesInfo name="Federal Information Processing Standard" value="197" /></reference> <!-- FIPS197 --> <reference anchor="SP80038A" target="https://csrc.nist.gov/publications/detail/sp/800-38a/final"> <front> <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title><author> <organization>National Institute of Standards and Technology</organization> </author> <date month="December" year="2001" /> </front><seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/> <seriesInfo name="Special Publication"value="800-38A" />value="800-38A"/> <author fullname="Morris Dworkin" initials="M." surname="Dworkin"/> <date month="December" year="2001"/> </front> </reference> <!-- SP80038A --> <reference anchor="SP80038D" target="https://csrc.nist.gov/publications/detail/sp/800-38d/final"> <front> <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title><author> <organization>National Institute of Standards and Technology</organization> </author> <date month="November" year="2007" /> </front><seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/> <seriesInfo name="Special Publication"value="800-38D" />value="800-38D"/> <author fullname="Morris Dworkin" initials="M." surname="Dworkin"/> <date month="November" year="2007"/> </front> </reference> <!-- SP80038D --> <reference anchor="SP80038F" target="https://csrc.nist.gov/publications/detail/sp/800-38f/final"> <front> <title>Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping</title><author> <organization>National Institute of Standards and Technology</organization> </author> <date month="December" year="2012" /> </front><seriesInfo name="DOI" value="10.6028/NIST.SP.800-38F"/> <seriesInfo name="Special Publication"value="800-38F" />value="800-38F"/> <author fullname="Morris Dworkin" initials="M." surname="Dworkin"/> <date month="December" year="2012"/> </front> </reference> <!-- SP80038F --> <reference anchor="FIPS180" target="https://csrc.nist.gov/publications/detail/fips/180/4/final"> <front> <title>Secure Hash Standard (SHS)</title> <seriesInfo name="Federal Information Processing Standard" value="180-4"/> <author> <organization>National Institute of Standards and Technology</organization> </author> <date month="August"year="2015" />year="2015"/> </front><seriesInfo name="Federal Information Processing Standard" value="180-4" /></reference> <!-- FIPS180 --> <reference anchor="FIPS186" target="https://csrc.nist.gov/publications/detail/fips/186/4/final"> <front> <title>Digital SignatureStandard</title>Standard (DSS)</title> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/> <seriesInfo name="FIPS PUB" value="186-4"/> <author> <organization>National Institute of Standards and Technology</organization> </author> <date month="July"year="2013" />year="2013"/> </front><seriesInfo name="Federal Information Processing Standard" value="186-4" /></reference> <!-- FIPS186 --> <reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf"> <front> <title>SEC1: Elliptic Curve Cryptography</title> <author> <organization>Standards for Efficient Cryptography Group</organization> </author> <date month="May" year="2009"/> </front> </reference> <!-- SEC1 -->&rfc2119; &rfc2631; &rfc3370; &rfc3560; &rfc3565; &rfc4055; &rfc4056; &rfc5083; &rfc5084; &rfc5480; &rfc5649; &rfc5652; &rfc5753; &rfc5754; &rfc8017; &rfc8174; &rfc8551; &rfc8603;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3560.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3565.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4056.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5084.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5649.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5754.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/> <reference anchor="X208" target="https://www.itu.int/rec/T-REC-X.208-198811-W/en"> <front><title>Recommendation X.208: Specification<title>Specification of Abstract Syntax Notation One (ASN.1)</title> <seriesInfo name="CCITT Recommendation" value="X.208"/> <author> <organization>CCITT</organization> </author> <datemonth=""year="1988"/> </front> </reference> <!-- X208 --> <reference anchor="X209" target="https://www.itu.int/rec/T-REC-X.209-198811-W/en"> <front><title>Recommendation X.209: Specification<title>Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)</title> <seriesInfo name="CCITT Recommendation" value="X.209"/> <author> <organization>CCITT</organization> </author> <datemonth=""year="1988"/> </front> </reference> <!-- X209 --> <reference anchor="X509" target="https://www.itu.int/rec/T-REC-X.509-198811-S"> <front><title>Recommendation X.509: The<title>The Directory - Authentication Framework</title> <seriesInfo name="CCITT Recommendation" value="X.509"/> <author> <organization>CCITT</organization> </author> <datemonth=""year="1988"/> </front> </reference> <!-- X509 --> </references><!-- Normative --> <references title="Informative References"><references> <name>Informative References</name> <reference anchor="SP80059" target="https://csrc.nist.gov/publications/detail/sp/800-59/final"> <front> <title>Guideline for Identifying an Information System as a National Security System</title><author> <organization>National Institute of Standards and Technology</organization> </author><seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/> <seriesInfo name="Special Publication" value="800-59"/> <author fullname="William Barker" initials="W." surname="Barker"/> <date month="August"year="2003" />year="2003"/> </front><seriesInfo name="Special Publication 800-59" value="" /></reference> <!-- SP-800-57 -->&rfc4086;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> </references> </references><!-- Informative --></back> </rfc>