<?xml version="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 rfc2986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.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 rfc4211 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4211.xml">
<!ENTITY rfc4231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4231.xml">
<!ENTITY rfc5272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5272.xml">
<!ENTITY rfc5273 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5273.xml">
<!ENTITY rfc5274 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5274.xml">
<!ENTITY rfc5754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml">
<!ENTITY rfc6010 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6010.xml">
<!ENTITY rfc6402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6402.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">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent"
     category="info" ipr="trust200902" number="8756" obsoletes="" updates=""
     xml:lang="en" docName="draft-jenkins-cnsa-cmc-profile-05" >

<?rfc strict="yes" ?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc editing="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.39.0 -->

  <front>
    <title abbrev="CNSA Suite CMC Profile">Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS</title>
    <seriesInfo name="RFC" value="8756"/>
    <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>
    <author fullname="Lydia Zieglar" initials="L." surname="Zieglar">
      <organization abbrev="NSA">National Security Agency</organization>
        <address><email>llziegl@tycho.ncsc.mil</email></address>
      <address>
        <email>llziegl@tycho.ncsc.mil</email>
      </address>
    </author>
    <date year="2019"/> year="2020" month="March"/>
    <area>Security</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>NSA</keyword>
    <keyword>CNSA</keyword>
    <keyword>NSS</keyword>
    <keyword>certificate</keyword>
    <keyword>enrollment</keyword>
    <abstract>
      <t>This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government.
</t>
      <t>The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS.  It is also appropriate for all other US Government systems that process high-value information.
</t>
      <t>The profile is made publicly available here for use by developers and operators of these and any other system deployments.
</t>
    </abstract>
  </front>

  <middle>

<section anchor="intro" title="Introduction"> numbered="true" toc="default">
<name>Introduction</name>

<t>This document specifies a profile of the Certificate Management over CMS (CMC) protocol to comply with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite <xref target="CNSA" />. format="default"/>. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems <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> deployments.
</t>

<t>This document does not define any new cryptographic algorithm suite; suites; instead, it defines a CNSA compliant CNSA-compliant profile of CMC. CMC is defined in <xref target="RFC5272" />, format="default"/>, <xref target="RFC5273" />, format="default"/>, and <xref target="RFC5274" />, format="default"/> and is updated by <xref target="RFC6402" />. format="default"/>. This document profiles CMC to manage X.509 public key certificates in compliance with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile profile <xref target="ID.cnsa-cert-profile" />. target="RFC8603" format="default"/>. This document specifically focuses on defining CMC interactions for both the initial enrollment and rekey of CNSA Suite public key certificates between a client and a Certification Authority (CA).  One or more Registration Authorities (RAs) may act as intermediaries between the client and the CA.  This profile may be further tailored by specific communities to meet their needs.  Specific communities will also define Certificate Policies certificate policies that implementations need to comply with.</t> with.
</t>

<section anchor="terms" 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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>
      <t>The terminology in <xref target="RFC5272" sectionFormat="comma" section="2.1"/> applies to this profile.</t>
      <t>The term "certificate request" is used to refer to a single PKCS #10
      or  Certificate Request Message Format (CRMF) structure. All PKI Requests are Full PKI Requests, and all PKI Responses are Full PKI Responses; the respective set of terms should be interpreted synonymously in this document.</t>
    </section>
    <!-- terms -->

    </section>
    <!-- intro -->

   <section anchor="cnsa" title="The numbered="true" toc="default">
      <name>The Commercial National Security Algorithm Suite"> 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 new algorithms, algorithms and to provide vendors - -- and the Internet community in general - -- with information concerning their proper use and configuration within the scope of US Government National Security Systems.</t>
      <t>Recently, cryptographic transition plans have become overshadowed by
      the prospect of the development of a cryptographically-relevant cryptographically 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 customers making make 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 Security Systems.</t>
    </section>
    <!-- cnsa -->

<section anchor="terms" 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>

<t>The terminology in <xref target="RFC5272" /> Section 2.1 applies to this profile.</t>

<t>The term "Certificate Request" is used to refer to a single PKCS #10 or CRMF structure. All PKI Requests are Full PKI Requests, and all PKI Responses are Full PKI Responses; the respective set of terms should be interpreted synonymously in this document.</t>

</section> <!-- terms -->

<section anchor="reqts" title="Requirements numbered="true" toc="default">
      <name>Requirements and Assumptions"> Assumptions</name>
      <t>Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve
      Diffie-Hellman (ECDH) key pairs are on the curve P-384. P-384 curve.  FIPS 186-4 <xref target="FIPS186" />, format="default"/>, Appendix B.4, B.4 provides useful guidance for elliptic curve key pair generation that SHOULD <bcp14>SHOULD</bcp14> be followed by systems that conform to this document.</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 CNSA Suite compliant Suite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST <bcp14>MUST</bcp14> satisfy 2^16&lt;e&lt;2^256 2<sup>16</sup> &lt; e &lt; 2<sup>256</sup> and be odd per <xref target="FIPS186" />.</t> 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.  CNSA Suite compliant Suite-compliant X.509 certificates will be issued in accordance with <xref target="ID.cnsa-cert-profile" />, target="RFC8603" format="default"/>, and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's private key can be used to generate signatures of either signing scheme.  Where use of RSASSA-PSS is indicated in this document, the following parameters apply:

<list style="symbols">
<t>the

</t>
      <ul spacing="normal">
        <li>The hash algorithm MUST <bcp14>MUST</bcp14> be id-sha384 as defined in <xref target="RFC8017" />;</t>
<t>the format="default"/>;</li>
        <li>The mask generation function MUST <bcp14>MUST</bcp14> use the algorithm identifier mfg1SHA384Identifier as defined in <xref target="RFC4055" />;</t>
<t>the format="default"/>;</li>
        <li>The salt length MUST <bcp14>MUST</bcp14> be 48 octets; and</t>
<t>the and</li>
        <li>The trailerField MUST <bcp14>MUST</bcp14> have value 1.</t>
</list> 1.</li>
      </ul>
      <t>

These parameters will not appear in a certificate and MUST <bcp14>MUST</bcp14> be securely
      communicated with the signature signature, as required by Section 2.2 of <xref
      target="RFC4056" />. sectionFormat="of" section="2.2"/>. Application developers are obliged to ensure that the chosen signature scheme is appropriate for the application and will be interoperable within the intended operating scope of the application.</t>
      <t>This document assumes that the required trust anchors have been securely provisioned to the client and, when applicable, to any RAs.</t>
      <t>All requirements in <xref target="RFC5272" />, format="default"/>, <xref target="RFC5273" />, format="default"/>, <xref target="RFC5274" />, format="default"/>, and <xref target="RFC6402" /> format="default"/> apply, except where overridden by this profile.</t>
      <t>This profile was developed with the scenarios described in <xref target="scenarios" /> format="default"/> in mind.  However, use of this profile is not limited to just those scenarios.</t>
      <t>The term "client" in this profile typically refers to an end-entity. However, it may instead refer to a third party acting on the end-entity's behalf.  The client may or may not be the entity that actually generates the key pair, but it does perform the CMC protocol interactions with the RA and/or CA.  For example, the client may be a token management system that communicates with a cryptographic token through an out-of-band secure protocol.</t>
      <t>This profile uses the term "rekey" in the same manner as does CMC does (defined in Section 2 of <xref target="RFC5272" />). sectionFormat="of" section="2"/>).  The profile makes no specific statements about the ability to do "renewal" operations; however, the statements applicable to rekey "rekey" should be applied to renewal "renewal" as well.</t>
      <t>This profile may be used to manage RA and/or CA certificates.  In that case, the RA and/or CA whose certificate is being managed is considered to be the end-entity.</t>
      <t>This profile does not discuss key establishment certification requests from cryptographic modules that cannot generate a one-time signature with a key establishment key for proof-of-possession purposes.  In that case, a separate profile would be needed to define the use of another proof-of-possession technique.</t>
    </section>
    <!-- reqts -->

<section anchor="client-reqts-gen" title="Client numbered="true" toc="default">

<name>Client Requirements: Generating PKI Requests"> Requests</name>

<t>This section specifies the conventions employed when a client requests a certificate from a Public Key Infrastructure (PKI).</t> (PKI).
</t>

<t>The Full PKI Request MUST <bcp14>MUST</bcp14> be used; it MUST <bcp14>MUST</bcp14> be encapsulated in a SignedData; and the SignedData MUST <bcp14>MUST</bcp14> be constructed in accordance with <xref target="ID.cnsa-smime-profile" />. target="RFC8755" format="default"/>. The PKIData content type defined in <xref target="RFC5272" /> format="default"/> is used with the following additional requirements:
<list style="symbols">
</t>

<ul spacing="normal">
        <!-- 1 -->
   <li>
          <t>controlSequence SHOULD <bcp14>SHOULD</bcp14> be present.
   <list style="symbols">
          </t>
          <ul spacing="normal">
            <!-- 2 -->
      <t>TransactionId
      <li>TransactionId and SenderNonce SHOULD <bcp14>SHOULD</bcp14> be included. Other CMC controls MAY <bcp14>MAY</bcp14> be included.</t> included.</li>
            <li>
              <t>If the request is being authenticated using a shared-secret, then Identity Proof Version 2 control MUST <bcp14>MUST</bcp14> be included with the following constraints:
      <list style="symbols">
              </t>
              <ul spacing="normal">
                <!-- 3 -->
         <t>hashAlgId MUST
         <li>hashAlgId <bcp14>MUST</bcp14> be id-sha384 for all certification requests (algorithm OIDs are defined in <xref target="RFC5754" />);</t>
         <t>macAlgId MUST format="default"/>).</li>
                <li>macAlgId <bcp14>MUST</bcp14> be HMAC-SHA384 (the HMAC Hashed
		Message Authentication Code (HMAC) algorithm is defined in <xref target="RFC4231" />).</t>
      </list> format="default"/>).</li>
              </ul>
              <!-- 3 -->
      </t>
      <t>If

            </li>
            <li>If the subject name included in the certification request is NULL
	    or otherwise does not uniquely identify the end-entity, then the
	    POP Link Random control MUST <bcp14>MUST</bcp14> be included, and the
	    POP Link Witness Version 2 control MUST <bcp14>MUST</bcp14> be included
	    in the inner PKCS #10 <xref target="RFC2986">PKCS #10</xref> target="RFC2986" format="default"/> or
	    Certificate Request Message Format (CRMF) <xref target="RFC4211" />
	    format="default"/> request as described in Sections <xref target="tgd-cert-reqst" /> format="counter"/> and <xref target="cert-reqst-msg" />.
      </t>
   </list> format="counter"/>.
      </li>
          </ul>
          <!-- 2 -->
   </t>
   <t>reqSequence MUST
        </li>
        <li>reqSequence <bcp14>MUST</bcp14> be present.  It MUST <bcp14>MUST</bcp14> include at least one tcr (see <xref target="tgd-cert-reqst" />) format="default"/>) or crm (see <xref target="cert-reqst-msg" />) format="default"/>) TaggedRequest. Support for the orm choice is OPTIONAL.
   </t>
</list> <bcp14>OPTIONAL</bcp14>.
   </li>
      </ul>
    <!-- 1 -->
</t>
      <t>The private signing key used to generate the encapsulating SignedData MUST <bcp14>MUST</bcp14> correspond to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment.</t>
      <t>The encapsulating SignedData MUST <bcp14>MUST</bcp14> be generated using SHA-384 and either ECDSA on P-384, P-384 or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.</t>
      <t>If an appropriate signature certificate does not yet exist, exist and if a Full PKI Request includes one or more certification requests and is authenticated using a shared-secret (because no appropriate certificate exists yet to authenticate the request), the Full PKI Request MUST <bcp14>MUST</bcp14> be signed using the private key corresponding to the public key of one of the requested certificates.  When necessary (i.e., because there is no existing signature certificate and there is no signature certification request included), a Full PKI Request MAY <bcp14>MAY</bcp14> be signed using a key pair intended for use in a key establishment certificate.  However, servers are not required to allow this behavior.</t>
      <section anchor="tgd-cert-reqst" title="Tagged numbered="true" toc="default">
        <name>Tagged Certification Request"> Request</name>
        <t>The reqSequence tcr choice conveys PKCS #10 <xref target="RFC2986">PKCS #10</xref> target="RFC2986"
	format="default"/> syntax.  The CertificateRequest MUST <bcp14>MUST</bcp14>
	comply with <xref target="RFC5272" />, Section 3.2.1.2.1, sectionFormat="comma" section="3.2.1.2.1"/>, with the following additional requirements:

   <list style="symbols">

        </t>
        <ul spacing="normal">
          <!-- 1 -->

      <li>
            <t>certificationRequestInfo:

      <list style="symbols">

            </t>
            <ul spacing="normal">
              <!-- 2 -->

         <t>subjectPublicKeyInfo MUST
         <li>subjectPublicKeyInfo <bcp14>MUST</bcp14> be set as defined in Section 4.4 of <xref target="ID.cnsa-cert-profile" />;</t>

         <t>attributes:

         <list style="symbols"> target="RFC8603" sectionFormat="of" section="5.4"/>.</li>
              <li>
                <t>Attributes:

                </t>
                <ul spacing="normal">
                  <!-- 3 -->

            <li>
                    <t>The ExtensionReq attribute MUST <bcp14>MUST</bcp14> be included with its contents as follows:

            <list style="symbols">

                    </t>
                    <ul spacing="normal">
                      <!-- 4 -->

               <t>The Key Usage
               <li>The keyUsage extension MUST <bcp14>MUST</bcp14> be included, and it MUST <bcp14>MUST</bcp14> be set as defined in <xref target="ID.cnsa-cert-profile" />.</t>

               <t>For target="RFC8603" format="default"/>.</li>
                      <li>For rekey requests, the SubjectAltName extension MUST <bcp14>MUST</bcp14> be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the Subject subject field of the certificate being used to generate the signature is NULL.</t>

               <t>Other NULL.</li>
                      <li>Other extension requests MAY <bcp14>MAY</bcp14> be included as desired.</t>
            </list></t> desired.</li>
                    </ul>
                  </li>
                  <!-- 4 -->

            <t>The

            <li>The ChangeSubjectName attribute, as defined in <xref target="RFC6402" />, MUST format="default"/>, <bcp14>MUST</bcp14> be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's Subject subject field or SubjectAltName extension does not match the desired Subject subject name or SubjectAltName extension of this certification request.</t>

            <t>The request.</li>
                  <li>The POP Link Witness Version 2 attribute MUST <bcp14>MUST</bcp14> be included if the request is being authenticated using a shared-secret and the Subject subject name in the certification request is NULL or otherwise does not uniquely identify the end-entity.  In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST <bcp14>MUST</bcp14> be id-sha384 for certification requests, as defined in <xref target="RFC5754" />; format="default"/>; macAlgorithm MUST <bcp14>MUST</bcp14> be HMAC-SHA384, as defined in <xref target="RFC4231" />.</t>

         </list></t> format="default"/>.</li>
                </ul>
              </li>
              <!-- 3 -->

      <t>signatureAlgorithm MUST

      <li>signatureAlgorithm <bcp14>MUST</bcp14> be ecdsa-with-sha384 for P-384 certification requests, requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests;</t>

      <t>signature MUST requests.</li>
              <li>signature <bcp14>MUST</bcp14> be generated using the private key corresponding to the public key in the CertificationRequestInfo, CertificationRequestInfo for both signature and key establishment certification requests.  The signature provides proof-of-possession of the private key to the CA.</t>

      </list></t> CA.</li>
            </ul>
          </li>
          <!-- 2 -->

   </list></t>

   </ul>
        <!-- 1 -->

   </section>
      <!-- tgd-cert-reqst -->

   <section anchor="cert-reqst-msg" title="Certificate numbered="true" toc="default">
        <name>Certificate Request Message"> Message</name>
        <t>The reqSequence crm choice conveys <xref target="RFC4211">Certificate Certificate Request Message
	Format (CRMF)</xref> (CRMF) <xref target="RFC4211" format="default"/>
	syntax.  The CertReqMsg MUST <bcp14>MUST</bcp14> comply with <xref target="RFC5272" />, Section 3.2.1.2.2,
	sectionFormat="comma" section="3.2.1.2.2"/>, with the following additional requirements:

   <list style="symbols">

      <t>popo MUST

        </t>
        <ul spacing="normal">
          <li>popo <bcp14>MUST</bcp14> be included using the signature (POPOSigningKey)
	  proof-of-possession choice and be set as defined in <xref
	  target="RFC4211" />, Section 4.1, sectionFormat="comma" section="4.1"/> for both signature and key establishment certification requests. The POPOSigningKey poposkInput field MUST <bcp14>MUST</bcp14> be omitted.  The POPOSigningKey algorithmIdentifier MUST <bcp14>MUST</bcp14> be ecdsa-with-sha384 for P-384 certification requests, requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests.  The signature MUST <bcp14>MUST</bcp14> be generated using the private key corresponding to the public key in the CertTemplate.</t>

   </list></t> CertTemplate.</li>
        </ul>

<t>The CertTemplate MUST <bcp14>MUST</bcp14> comply with <xref target="RFC5272" />, Section 3.2.1.2.2, sectionFormat="comma" section="3.2.1.2.2"/>, with the following additional requirements:

   <list style="symbols">

      <t>If
</t>

        <ul spacing="normal">
          <li>If version is included, it MUST <bcp14>MUST</bcp14> be set to 2 as defined in Section 4.3 of
	  <xref target="ID.cnsa-cert-profile" />;</t>

      <t>publicKey MUST target="RFC8603" sectionFormat="of" section="5.3"/>.</li>
          <li>publicKey <bcp14>MUST</bcp14> be set as defined in Section 4.4 of <xref target="ID.cnsa-cert-profile" />;</t>

      <t>extensions:

      <list style="symbols">

         <t>The Key Usage
	  target="RFC8603" sectionFormat="of" section="5.4"/>.</li>
          <li>
            <t>Extensions:</t>
            <ul spacing="normal">
              <li>The keyUsage extension MUST <bcp14>MUST</bcp14> be included, and it MUST <bcp14>MUST</bcp14> be set as defined in <xref target="ID.cnsa-cert-profile" />.</t>

         <t>For target="RFC8603" format="default"/>.</li>
              <li>For rekey requests, the SubjectAltName extension MUST <bcp14>MUST</bcp14> be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the Subject field subject name of the certificate being used to generate the signature is NULL.</t>

         <t>Other NULL.</li>
              <li>Other extension requests MAY <bcp14>MAY</bcp14> be included as desired.</t>

      </list></t>

      <t>controls:

      <list style="symbols">

         <t>The desired.</li>
            </ul>
          </li>
          <li>
            <t>Controls:

            </t>
            <ul spacing="normal">
              <li>The ChangeSubjectName attribute, as defined in <xref target="RFC6402" />, MUST format="default"/>, <bcp14>MUST</bcp14> be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's Subject subject name or SubjectAltName extension does not match the desired Subject subject name or SubjectAltName extension of this certification request.</t>

      <t>The request.</li>
              <li>The POP Link Witness Version 2 attribute MUST <bcp14>MUST</bcp14> be included if the request is being authenticated using a shared-secret, shared-secret and the Subject subject name in the certification request is NULL or otherwise does not uniquely identify the end-entity.  In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST <bcp14>MUST</bcp14> be id-sha384 for certification requests; macAlgorithm MUST <bcp14>MUST</bcp14> be HMAC-SHA384 when keyGenAlgorithm is id-sha384.</t>

      </list></t>

   </list></t> id-sha384.</li>
            </ul>
          </li>
        </ul>
      </section>
      <!-- cert-reqst-msg -->

</section>
    <!-- client-reqts-gen -->

<section anchor="ra_reqts" title="RA Requirements"> numbered="true" toc="default">
      <name>RA Requirements</name>
      <t>This section addresses the optional case where one or more RAs act as
      intermediaries between clients and a CA as described in Section 7 of <xref target="RFC5272" />. sectionFormat="of" section="7"/>.  In this section, the term "client" refers to the entity from which the RA received the PKI Request. This section is only applicable to RAs.</t>
      <section anchor="ra-proc-reqst" title="RA numbered="true" toc="default">
        <name>RA Processing of Requests"> Requests</name>
        <t>RAs conforming to this document MUST <bcp14>MUST</bcp14> ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the RA MUST <bcp14>MUST</bcp14> reject those requests.  The RA SHOULD <bcp14>SHOULD</bcp14> return a CMCFailInfo with the value of badAlg <xref target="RFC5272" />.</t> format="default"/>.</t>
        <t>When processing end-entity-generated SignedData objects, RAs MUST NOT <bcp14>MUST NOT</bcp14> perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing <xref target="RFC6010" />.</t> format="default"/>.</t>
        <t>Other RA processing is performed as described in <xref target="RFC5272" />.</t> format="default"/>.</t>
      </section>
      <!-- ra-proc-reqsts -->

   <section anchor="ra-gend-pki-reqst" title="RA-Generated numbered="true" toc="default">

   <name>RA-Generated PKI Requests"> Requests</name>

        <t>RAs mediate the certificate request process by collecting Client client requests in batches. The RA MUST <bcp14>MUST</bcp14> encapsulate client-generated PKI Requests in a new RA-signed PKI Request, it MUST <bcp14>MUST</bcp14> create a Full PKI Request encapsulated in a SignedData, and the SignedData MUST <bcp14>MUST</bcp14> be constructed in accordance with <xref target="ID.cnsa-smime-profile" />. target="RFC8755" format="default"/>.  The PKIData content type complies with <xref target="RFC5272" /> format="default"/> with the following additional requirements:

   <list style="symbols">
      <t>controlSequence MUST

        </t>
        <ul spacing="normal">
          <li>controlSequence <bcp14>MUST</bcp14> be present. It MUST
	  <bcp14>MUST</bcp14> include the following CMC controls: Transaction
	  ID, Sender Nonce, and Batch Requests. Other appropriate CMC controls MAY
	  <bcp14>MAY</bcp14> be included.</t>
      <t>cmsSequence MUST included.</li>
          <li>cmsSequence <bcp14>MUST</bcp14> be present.  It contains the original, unmodified request(s) received from the client.</t>
   </list></t>

   <figure><artwork align="left"> client.</li>
        </ul>
        <sourcecode name="" type=""><![CDATA[
      SignedData (applied by the RA)
        PKIData
          controlSequence (Transaction ID, Sender Nonce,
                                               Batch Requests)
          cmsSequence
            SignedData (applied by Client) client)
              PKIData
                controlSequence (Transaction ID, Sender Nonce)
                reqSequence
                  TaggedRequest
                  {TaggedRequest}
            {SignedData     (second Client client request)
              PKIData...}
   </artwork></figure>
]]></sourcecode>
        <t>Authorization to sign RA-generated Full PKI Requests SHOULD
	<bcp14>SHOULD</bcp14> be indicated in the RA certificate by inclusion
	of the id-kp-cmcRA EKU Extended Key Usage (EKU) from <xref target="RFC6402" />.
	format="default"/>. The RA certificate MAY <bcp14>MAY</bcp14> also include
	the CCC certificate extension <xref target="RFC6010" />,
	format="default"/>, or it MAY <bcp14>MAY</bcp14> indicate authorization
	through inclusion of the CCC certificate extension alone. The RA
	certificate may also be authorized through the local configuration.</t>
        <t>If the RA is authorized via the CCC extension, then the CCC extension MUST <bcp14>MUST</bcp14> include the object identifier for the PKIData content type. CCC SHOULD <bcp14>SHOULD</bcp14> be included if constraints are to be placed on the content types generated.</t>

<t>The outer SignedData MUST <bcp14>MUST</bcp14> be generated using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.</t> key.
</t>

<t>If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the algorithm used in the response and MUST <bcp14>MUST</bcp14> match the algorithm used in the request.</t> request.
</t>

</section>

<!-- ra-gend-pki-reqst -->

   <section anchor="ra-gend-resp" title="RA-Generated numbered="true" toc="default">
        <name>RA-Generated PKI Responses"> Responses</name>
        <t>In order for an RA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension.</t>
      </section>
      <!-- ra-gend-resp -->

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

<section anchor="ca-reqts" title="CA Requirements"> numbered="true" toc="default">
      <name>CA Requirements</name>
      <t>This section specifies the requirements for CAs that receive PKI Requests and that generate PKI Responses.</t>
      <section anchor="ca-proc-reqst" title="CA numbered="true" toc="default">
        <name>CA Processing of PKI Requests"> Requests</name>
        <t>CAs conforming to this document MUST <bcp14>MUST</bcp14> ensure that
	only the permitted signature, hash, and MAC algorithms described
	throughout this profile are used in requests; if they are not, the CA MUST
	<bcp14>MUST</bcp14> reject those requests.  The CA SHOULD
	<bcp14>SHOULD</bcp14> return a CMCStatusInfoV2 control with a CMCStatus of failed and a CMCFailInfo with the value of badAlg <xref target="RFC5272" />.</t> format="default"/>.</t>
        <t>For requests involving an RA (i.e., batched requests), the CA MUST
	<bcp14>MUST</bcp14> verify the RA's authorization.  The following
	certificate fields MUST NOT <bcp14>MUST NOT</bcp14> be modifiable using the
	Modify Certification Request control: publicKey and the Key Usage keyUsage
	extension.  The request MUST <bcp14>MUST</bcp14> be rejected if an attempt
	to modify those certification request fields is present.  The CA SHOULD
	<bcp14>SHOULD</bcp14> return a CMCStatusInfoV2 control with a CMCStatus of failed and a CMCFailInfo with a value of badRequest.</t>
        <t>When processing end-entity-generated SignedData objects, CAs MUST NOT <bcp14>MUST NOT</bcp14> perform CCC certificate extension processing <xref target="RFC6010" />.</t> format="default"/>.</t>
        <t>If a client-generated PKI Request includes the ChangeSubjectName
	attribute as described in <xref target="tgd-cert-reqst" />
	format="default"/> or <xref target="cert-reqst-msg" /> format="counter"/>
	above, the CA MUST <bcp14>MUST</bcp14> ensure that name change is
	authorized. The mechanism for ensuring that the name change is
	authorized is out of scope.  A CA that performs this check and finds
	that the name change is not authorized MUST <bcp14>MUST</bcp14> reject the
	PKI Request. The CA SHOULD <bcp14>SHOULD</bcp14> return an Extended CMC
	Status Info control (CMCStatusInfoV2) with a CMCStatus of failed.</t>
        <t>Other processing of PKIRequests is performed as described in <xref target="RFC5272" />.</t> format="default"/>.</t>
      </section>
      <!-- ca-proc-reqst -->

   <section anchor="ca-gend-resp" title="CA-Generated numbered="true" toc="default">
        <name>CA-Generated PKI Responses"> Responses</name>
        <t>CAs send PKI Responses to both Client-generated client-generated requests and RA-generated requests. If a Full PKI Response is returned in direct response to a Client-generated client-generated request, it MUST <bcp14>MUST</bcp14> be encapsulated in a SignedData, and the SignedData MUST <bcp14>MUST</bcp14> be constructed in accordance with <xref target="ID.cnsa-smime-profile" />.</t> target="RFC8755" format="default"/>.</t>
        <t>If the PKI Response is in response to an RA-generated PKI Request, then the above PKI Response is encapsulated in another CA-generated PKI Response.  That PKI Response MUST <bcp14>MUST</bcp14> be encapsulated in a SignedData SignedData, and the SignedData MUST <bcp14>MUST</bcp14> be constructed in accordance with <xref target="ID.cnsa-smime-profile" />. target="RFC8755" format="default"/>.  The above PKI Response is placed in the encapsulating PKI Response cmsSequence field.  The other fields are as above with the addition of the batch response control in controlSequence.  The following illustrates a successful CA response to an RA-encapsulated PKI Request, both of which include Transaction IDs and Nonces:</t>

   <figure><artwork align="left">
        <sourcecode name="" type=""><![CDATA[
      SignedData (applied by the CA)
        PKIResponse
          controlSequence (Transaction ID, Sender Nonce, Recipient
                           Nonce, Batch Response)
          cmsSequence
            SignedData (applied by CA and includes returned
                        certificates)
              PKIResponse
                controlSequence (Transaction ID, Sender Nonce,
                                 Recipient Nonce)
   </artwork></figure>
]]></sourcecode>
        <t>The same private key used to sign certificates MUST NOT <bcp14>MUST NOT</bcp14> be used to sign Full PKI Response messages.  Instead, a separate certificate indicating authorization to sign CMC responses MUST <bcp14>MUST</bcp14> be used.</t>
        <t>Authorization to sign Full PKI Responses SHOULD <bcp14>SHOULD</bcp14> be indicated in the CA certificate by inclusion of the id-kp-cmcCA EKU from <xref target="RFC6402" />. format="default"/>. The CA certificate MAY <bcp14>MAY</bcp14> also include the CCC certificate extension <xref target="RFC6010" />, format="default"/>, or it MAY <bcp14>MAY</bcp14> indicate authorization through inclusion of the CCC certificate extension alone. The CA certificate may also be authorized through local configuration.</t>
        <t>In order for an a CA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension. CCC SHOULD <bcp14>SHOULD</bcp14> be included if constraints are to be placed on the content types generated.</t>
        <t>Signatures applied to individual certificates are as required in <xref target="ID.cnsa-cert-profile" />.</t> target="RFC8603" format="default"/>.</t>
        <t>The signature on the SignedData of a successful response to a Client-generated
	client-generated request, or each individual inner SignedData on the
	successful response to a an RA-generated request, MUST <bcp14>MUST</bcp14> be
	generated using SHA-384 and either ECDSA on P-384 or RSA using
	RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key. An
	unsuccessful response MUST <bcp14>MUST</bcp14> be signed using the same key-type key
	type and algorithm that signed the request.</t>
        <t>The outer SignedData on the Full PKI Response to any RA-generated
	PKI Request MUST <bcp14>MUST</bcp14> be signed with the same key-type key type and algorithm that signed the request.</t>
        <t>The SignedData on a successful Full PKI Response to a PKI Request
	that only contained a Get Certificate or Get CRL control MUST
	<bcp14>MUST</bcp14> be signed with the same key-type key type and algorithm that signed the request.</t>
      </section>
      <!-- ca-gend-resp -->

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

<section anchor="client-reqts-proc" title="Client numbered="true" toc="default">
      <name>Client Requirements: Processing PKI Responses"> Responses</name>
      <t>Clients conforming to this document MUST <bcp14>MUST</bcp14> ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in responses; if they are not, the client MUST <bcp14>MUST</bcp14> reject those responses.</t>
      <t>Clients MUST <bcp14>MUST</bcp14> authenticate all Full PKI Responses.  This includes verifying that the PKI Response is signed by an authorized CA or RA whose certificate validates back to a trust anchor.  The authorized CA certificate MUST <bcp14>MUST</bcp14> include the id-kp-cmcCA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type.  Or,  Otherwise, the CA is determined to be authorized to sign responses through an implementation-specific mechanism.  The PKI Response can be signed by an RA if it is an error message, if it is a response to a Get Certificate or Get CRL request, or if the PKI Response contains an inner PKI Response signed by a CA.  In the last case, each layer of PKI Response MUST <bcp14>MUST</bcp14> still contain an authorized, valid signature signed by an entity with a valid certificate that verifies back to an acceptable trust anchor.  The authorized RA certificate MUST <bcp14>MUST</bcp14> include the id-kp-cmcRA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type.  Or,  Otherwise, the RA is determined to be authorized to sign responses through local configuration.</t>
      <t>When a newly issued certificate is included in the PKI Response, the client MUST <bcp14>MUST</bcp14> verify that the newly issued certificate's public key matches the public key that the client requested.  The client MUST <bcp14>MUST</bcp14> also ensure that the certificate's signature is valid and that the signature validates back to an acceptable trust anchor.</t>
      <t>Clients MUST <bcp14>MUST</bcp14> reject PKI Responses that do not pass
      these tests. Local policy will determine whether the client returns a
      Full PKI Response with an Extended CMC Status Info control
      (CMCStatusInfoV2) with the CMCStatus set to failed to a user console, error log, or the server.</t>
      <t>If the Full PKI Response contains an Extended CMC Status Info control with a CMCStatus set to failed, then local policy will determine whether the client resends a duplicate certification request back to the server or an error state is returned to a console or error log.</t>
    </section>
    <!-- client-reqts-proc -->

<section anchor="shared-secrets" title="Shared-Secrets"> numbered="true" toc="default">
      <name>Shared-Secrets</name>
      <t>When the Identity Proof V2 and POP Link Witness V2 controls are used, the shared-secret MUST <bcp14>MUST</bcp14> be randomly generated and securely distributed.  The shared-secret MUST <bcp14>MUST</bcp14> provide at least 192 bits of strength.</t>
    </section>
    <!-- shared-secrets -->

<section anchor="sec-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Protocol security considerations are found in <xref target="RFC2986" />, format="default"/>, <xref target="RFC4211" />, format="default"/>, <xref target="ID.cnsa-smime-profile" />, target="RFC8755" format="default"/>, <xref target="RFC5272" />, format="default"/>, <xref target="RFC5273" />, format="default"/>, <xref target="RFC5274" />, format="default"/>, <xref target="ID.cnsa-cert-profile" />, target="RFC8603" format="default"/>, and <xref target="RFC6402" />. format="default"/>. When CCC is used to authorize RA and CA certificates, then the security considerations in <xref target="RFC6010" /> format="default"/> also apply.  Algorithm security considerations are found in <xref target="ID.cnsa-smime-profile" />.</t> target="RFC8755" format="default"/>.</t>
      <t>Compliant with NIST Special Publication 800-57 <xref target="SP80057" />, format="default"/>, this profile defines proof-of-possession of a key establishment private key by performing a digital signature.  Except for one-time proof-of-possession, a single key pair MUST NOT <bcp14>MUST NOT</bcp14> be used for both signature and key establishment.</t>
      <t>This specification requires implementations to generate key pairs and other random values.  The use of inadequate pseudo-random pseudorandom number generators (PRNGs) can result in little or no security.  The generation of quality random numbers is difficult.  NIST Special Publication 800-90A <xref target="SP80090A" />, format="default"/>, FIPS 186-3 <xref target="FIPS186" />, format="default"/>, and <xref target="RFC4086" /> format="default"/> offer random number generation guidance.</t>
      <t>When RAs are used, the list of authorized RAs MUST <bcp14>MUST</bcp14> be
      securely distributed out-of-band out of band to CAs.</t>
      <t>Presence of the POP Link Witness Version 2 and POP Link Random attributes protects against substitution attacks.</t>
      <t>The Certificate Policy certificate policy for a particular environment will specify whether expired certificates can be used to sign certification requests.</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>
  <back>
    <!--  ===== BACK MATTER ===== -->

   <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 for
            <seriesInfo name="CNSS Policy" value="15"/>
            <author>
              <organization>Committee on National Security Systems</organization></author> Systems</organization>
            </author>
            <date month="October" year="2016"></date> year="2016"/>
          </front>
        <seriesInfo name="CNSS Policy" value="15" />
        </reference>
        <!-- CNSA -->

      <reference anchor="FIPS186" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">
          <front>
            <title>Digital Signature Standard (DSS)</title>
            <seriesInfo name="FIPS PUB"
			value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.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 -->

        &rfc2119;
        &rfc2986;
        &rfc4055;
        &rfc4056;
        &rfc4086;
        &rfc4211;
        &rfc4231;
        &rfc5272;
        &rfc5273;
        &rfc5274;
        &rfc5754;
        &rfc6010;
        &rfc6402;
        &rfc8017;
        &rfc8174;

      <reference anchor="ID.cnsa-smime-profile" target="https://tools.ietf.org/html/draft-jenkins-cnsa-smime-profile">
          <front>
              <title>Using CNSA Suite Algorithms in Secure/Multipurpose Internet Mail Extensions(S/MIME)</title>
              <author initials="M." surname="Jenkins" />
              <date month="February" year="2018" />
          </front>
          <annotation>Work in progress.</annotation>
      </reference> <!-- ID.cnsa-smime-profile -->

      <reference anchor="ID.cnsa-cert-profile" target="https://tools.ietf.org/html/draft-jenkins-cnsa-cert-crl-profile">
         <front>
           <title>Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile</title>
           <author initials="M." surname="Jenkins" />
           <author initials="L." surname="Zieglar" />
           <date month="January" year="2018" />
         </front>
         <annotation>Work in progress.</annotation>
      </reference> <!-- ID.cnsa-cert-profile -->

        <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.2986.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.4086.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5273.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5274.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.6010.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6402.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.8755.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/>
      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>

      <reference anchor="SP80057" target="http://doi.org/10.6028/NIST.SP.800-57pt1r4">
          <front>
            <title>Recommendation for Key Management, Part 1: General</title>
            <seriesInfo name="Special Publication" value="800-57, Part 1,
							  Revision 4"/>

<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r4"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="January" year="2016" /> year="2016"/>
          </front>
		<seriesInfo name="Special Publication 800-57" value="" />
        </reference>
        <!-- SP80057 -->

        <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
            <seriesInfo name="Special Publication" value="800-59"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
<author><organization>National Institute of Standards and Technology</organization>
              </author> Technology</organization></author>
            <date month="August" year="2003" /> year="2003"/>
          </front>
          <seriesInfo name="Special Publication 800" value="59" />
        </reference>
        <!-- SP80059 -->

<reference anchor="SP80090A" target="http://doi.org/10.6028/NIST.SP.800-90Ar1">
          <front>
            <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators</title>
            <seriesInfo name="Special Publication 800-90A" value="Revision
								  1"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="June" year="2015" /> year="2015"/>
          </front>
		<seriesInfo name="Special Publication 800-90A" value="Revision 1" />
        </reference>
        <!-- SP80090A -->

    </references>
    </references>
    <section anchor="scenarios" title="Scenarios"> numbered="true" toc="default">
      <name>Scenarios</name>
      <!-- Appendix A -->

<t>This section illustrates several potential certificate enrollment and rekey scenarios supported by this profile.  This section does not intend to place any limits or restrictions on the use of CMC.</t>
      <section anchor="init_enroll" title="Initial Enrollment"> numbered="true" toc="default">
        <name>Initial Enrollment</name>
        <t>This section describes three scenarios for authenticating initial enrollment requests:
   <list style="numbers">
      <t>Previously
        </t>
        <ol spacing="normal" type="1">
          <li>Previously certified signature key-pair (e.g., Manufacturer Installed Certificate);</t>
      <t>Shared-secret Certificate).</li>
          <li>Shared-secret distributed securely out-of-band;</t>
      <t>RA authentication.</t>
   </list></t> out of band.</li>
          <li>RA authentication.</li>
        </ol>
        <section anchor="prev_inst" title="Previously numbered="true" toc="default">
          <name>Previously Certified Signature Key-pair"> Key-Pair</name>
          <t>In this scenario, the end-entity has a private signing key, key and a corresponding public key certificate obtained from a cryptographic module manufacturer recognized by the CA. The end-entity signs a Full PKI Request with the private key that corresponds to the subject public key of the previously installed signature certificate. The CA will verify the authorization of the previously installed certificate and issue an appropriate new certificate to the end-entity.</t>
        </section>
        <!-- prev_inst -->

      <section anchor="ss_oob" title="Shared-Secret numbered="true" toc="default">
          <name>Shared-Secret Distributed Securely Out-of-Band"> Out of Band</name>
          <t>In this scenario, the CA distributes a shared-secret out-of-band out of band
	  to the end-entity that the end-entity uses to authenticate its
	  certification request.  The end-entity signs the Full PKI Request
	  with the private key for which the certification is being
	  requested. The end-entity includes the Identity Proof Version 2
	  control to authenticate the request using the shared-secret.  The CA
	  uses either the Identification control or the Subject subject name in the
	  end-entity's enclosed PKCS #10 <xref target="RFC2986">PKCS #10</xref> target="RFC2986"
	  format="default"/> or CRMF <xref target="RFC4211">CRMF</xref> target="RFC4211" format="default"/>
	  certification request message to identify the request.  The
	  end-entity performs either the POP Link Witness Version 2 mechanism
	  as described in <xref target="RFC5272" />, Section 6.3.1.1, sectionFormat="comma"
	  section="6.3.1.1"/> or the Shared-Subject/Subject Distinguished Name (DN) shared-secret/subject distinguished
	  name linking mechanism as described in <xref target="RFC5272" />, Section 6.3.2.
	  sectionFormat="comma" section="6.3.2"/>.  The Subject subject name in the
	  enclosed PKCS #10 <xref target="RFC2986">PKCS #10</xref> target="RFC2986" format="default"/> or CRMF <xref target="RFC4211">CRMF</xref> target="RFC4211" format="default"/> certification
	  request does not necessarily match the issued certificate, as it may
	  be used just to help identify the request (and the corresponding shared-secret) to the CA.</t>
        </section>
        <!-- ss_oob -->

      <section anchor="ra_auth" title="RA Authentication"> numbered="true" toc="default">
          <name>RA Authentication</name>
          <t>In this scenario, the end-entity does not automatically
	  authenticate its enrollment request to the CA, either because the
	  end-entity has nothing to authenticate the request with or because
	  the organizational policy requires an RA's involvement.  The end-entity
	  creates a Full PKI Request and sends it to an RA.  The RA verifies
	  the authenticity of the request, then, if request. If the request is approved, the RA encapsulates and
	  signs the request as described in Section 5.2, <xref target="cert-reqst-msg"/>,
	  forwarding the new request on to the CA. The Subject subject name in the PKCS
	  #10 <xref target="RFC2986">PKCS #10</xref> target="RFC2986" format="default"/> or CRMF <xref target="RFC4211">CRMF</xref>
	  target="RFC4211" format="default"/> certification request is not required to match the issued certificate, certificate; it may be used just to help identify the request to the RA and/or CA.</t>
        </section>
        <!-- ra_auth -->

   </section>
      <!-- init_enroll -->

   <section anchor="rekey" title="Rekey"> numbered="true" toc="default">
        <name>Rekey</name>
        <t>There are two scenarios to support the rekey of certificates that
	are already enrolled.  One addresses the rekey of signature certificates
	certificates, and the other addresses the rekey of key establishment
	certificates. Typically, organizational policy will require certificates to be currently valid to be rekeyed, and it may require initial enrollment to be repeated when rekey is not possible.  However, some organizational policies might allow a grace period during which an expired certificate could be used to rekey.</t>
        <section anchor="rk_sig" title="Rekey numbered="true" toc="default">
          <name>Rekey of Signature Certificates"> Certificates</name>
          <t>When a signature certificate is rekeyed, the <xref target="RFC2986">PKCS
	  target="RFC2986" format="default">PKCS #10</xref> or <xref target="RFC4211">CRMF</xref> target="RFC4211" format="default">CRMF</xref> certification request message enclosed in the Full PKI Request will include the same Subject subject name as the current signature certificate.  The Full PKI Request will be signed by the current private key corresponding to the current signature certificate.</t>
        </section>
        <!-- rk_sig -->

      <section anchor="rk_kes" title="Rekey numbered="true" toc="default">

      <name>Rekey of Key Establishment Certificates"> Certificates</name>

<t>When a key establishment certificate is rekeyed, the Full PKI Request will generally be signed by the current private key corresponding to the current signature certificate.  If there is no current signature certificate, one of the initial enrollment options in Appendix A.1 <xref target="init_enroll"/> may be used.
</t>
        </section>
        <!-- rk_kes -->

   </section>
      <!-- rekey -->

</section>
    <!-- scenarios -->

</back>
  <!--  ===== END BACK MATTER ===== -->

</rfc>