Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS
draft-jenkins-cnsa-cmc-profile-00

Document Type Active Internet-Draft (individual)
Last updated 2018-09-28
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         M. Jenkins
Internet-Draft                                                L. Zieglar
Intended status: Informational                                       NSA
Expires: April 1, 2019                                September 28, 2018

     Commercial National Security Algorithm (CNSA) Suite Profile of
                    Certificate Management over CMS
                   draft-jenkins-cnsa-cmc-profile-00

Abstract

   The United States government has published the NSA Commercial
   National Security Algorithm (CNSA) Suite, which defines cryptographic
   algorithm policy for national security applications.  This document
   specifies a profile of the Certificate Management over CMS (CMC)
   protocol for managing X.509 public key certificates in applications
   using the CNSA Suite.  This profile is a refinement of RFCs 5272,
   5273, and 5274.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 1, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Jenkins & Zieglar         Expires April 1, 2019                 [Page 1]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Commercial National Security Algorithm Suite  . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Requirements and Assumptions  . . . . . . . . . . . . . . . .   4
   5.  Client Requirements: Generating PKI Requests  . . . . . . . .   5
     5.1.  Tagged Certification Request  . . . . . . . . . . . . . .   6
     5.2.  Certificate Request Message . . . . . . . . . . . . . . .   7
   6.  RA Requirements . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  RA Processing of Requests . . . . . . . . . . . . . . . .   9
     6.2.  RA-Generated PKI Requests . . . . . . . . . . . . . . . .   9
     6.3.  RA-Generated Errors . . . . . . . . . . . . . . . . . . .  10
   7.  CA Requirements . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  CA Processing of PKI Requests . . . . . . . . . . . . . .  11
     7.2.  CA-Generated PKI Responses  . . . . . . . . . . . . . . .  11
   8.  Client Requirements: Processing PKI Responses . . . . . . . .  13
   9.  Shared-Secrets  . . . . . . . . . . . . . . . . . . . . . . .  13
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Scenarios  . . . . . . . . . . . . . . . . . . . . .  17
     A.1.  Initial Enrollment  . . . . . . . . . . . . . . . . . . .  17
     A.2.  Rekey . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   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
   [CNSSP15].  CMC is defined in [RFC5272], [RFC5273], and [RFC5274],
   and is updated by [RFC6402].  This document profiles CMC to manage
   X.509 public key certificates in compliance with the CNSA Suite
   Certificate and Certificate Revocation List (CRL) Profile
   [ID.cnsa-cert-profile].  This document specifically focuses on
   defining CMC interactions for both 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

Jenkins & Zieglar         Expires April 1, 2019                 [Page 2]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   needs.  Specific communities will also define Certificate Policies
   that implementations need to comply with.

2.  The Commercial National Security Algorithm Suite

   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
   USG transition to new algorithms, and to provide vendors - and the
   Internet community in general - with information concerning their
   proper use and configuration.

   Recently, cryptographic transition plans have become overshadowed by
   the prospect of the development of a cryptographically-relevant
   quantum computer.  NSA has established the Commercial National
   Security Algorithm (CNSA) Suite to provide vendors and IT users near-
   term flexibility in meeting their IA interoperability requirements.
   The purpose behind this flexibility is to avoid vendors and customers
   making two major transitions in a relatively short timeframe, as we
   anticipate a need to shift to quantum-resistant cryptography in the
   near future.

   NSA is publishing 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.

3.  Terminology

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The terminology in [RFC5272] Section 2.1 applies to this profile.

   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.

Jenkins & Zieglar         Expires April 1, 2019                 [Page 3]
Internet-Draft           CNSA Suite CMC Profile           September 2018

4.  Requirements and Assumptions

   Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve
   Diffie-Hellman (ECDH) key pairs are on the curve P-384.  FIPS 186-4
   [DSS], Appendix B.4, provides useful guidance for elliptic curve key
   pair generation that SHOULD be followed by systems that conform to
   this document.

   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.

   RSA signature key pairs used in CNSA Suite compliant implementations
   are either RSA-3072 or RSA-4096.  The RSA exponent e MUST satisfy
   2^16<e<2^256 and be odd per [DSS].

   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 X.509 certificates will be issued in accordance with
   [ID.cnsa-cert-profile], and while they must be validated using
   RSASSA-PKCS1-v1_5, they can be used to produce signatures with either
   signing scheme.  Where use of RSASSA-PSS is indicated in this
   document, the following parameters apply:

   o  the hash algorithm must be id-sha384 as defined in [RFC8017];

   o  the mask generation function must use the algorithm identifier
      mfg1SHA384Identifier as defined in [RFC4055];

   o  the salt length must be 48 octets; and

   o  the trailerField must have value 1.

   These parameters will not appear in a certificate and must be
   securely communicated with the signature as specified in [RFC4056].
   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.

   This document assumes that the required trust anchors have been
   securely provisioned to the client and, when applicable, to any RAs.

   All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402]
   apply, except where overridden by this profile.

Jenkins & Zieglar         Expires April 1, 2019                 [Page 4]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   This profile was developed with the scenarios described in Appendix A
   in mind.  However, use of this profile is not limited to just those
   scenarios.

   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.

   This profile uses the term "rekey" in the same manner as does CMC
   (defined in Section 2 of [RFC5272]).  The profile makes no specific
   statements about the ability to do "renewal" operations; however, the
   statements applicable to rekey should be applied to renewal as well.

   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.

   This profile does not support 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.

5.  Client Requirements: Generating PKI Requests

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

   The Full PKI Request MUST be used; it MUST be encapsulated in a
   SignedData; and the SignedData MUST be constructed in accordance with
   [ID.cnsa-smime-profile].  The PKIData content type defined in
   [RFC5272] is used with the following additional requirements:

   o  controlSequence SHOULD be present.

      *  TransactionId and SenderNonce SHOULD be included.  Other CMC
         controls MAY be included.

      *  If the request is being authenticated using a shared-secret,
         then Identity Proof Version 2 control MUST be included with the
         following constraints:

         +  hashAlgId MUST be id-sha384 for all certification requests
            (algorithm OIDs are defined in [RFC5754]);

Jenkins & Zieglar         Expires April 1, 2019                 [Page 5]
Internet-Draft           CNSA Suite CMC Profile           September 2018

         +  macAlgId MUST be HMAC-SHA384 (the HMAC algorithm is defined
            in [RFC4231]).

      *  If the subject included in the certification request is NULL or
         otherwise does not uniquely identify the end-entity, then the
         POP Link Random control MUST be included, and the POP Link
         Witness Version 2 control MUST be included in the inner PKCS
         #10 [RFC2986] or Certificate Request Message Format (CRMF)
         [RFC4211] request as described in Sections 4.1 and 4.2.

   o  reqSequence MUST be present.  It MUST include at least one tcr
      (see Section 4.1) or crm (see Section 4.2) TaggedRequest.  Support
      for the orm choice is OPTIONAL.

   The private signing key used to generate the encapsulating SignedData
   MUST correspond to the public key of an existing signature
   certificate unless an appropriate signature certificate does not yet
   exist, such as during initial enrollment.

   The encapsulating SignedData MUST be generated using SHA-384 and
   either ECDSA on P-384, or RSA using either RSASSA-PKCS1-v1_5 or
   RSASSA-PSS with an RSA-3072 or RSA-4096 key.

   If an appropriate signature certificate does not yet 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 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 be signed using a key pair intended for use in a key
   establishment certificate.  However, servers are not required to
   allow this behavior.

5.1.  Tagged Certification Request

   The reqSequence tcr choice conveys PKCS #10 [RFC2986] syntax.  The
   CertificateRequest MUST comply with [RFC5272], Section 3.2.1.2.1,
   with the following additional requirements:

   o  certificationRequestInfo:

      *  subjectPublicKeyInfo MUST be set as defined in Section 4.4 of
         [ID.cnsa-cert-profile];

      *  attributes:

Jenkins & Zieglar         Expires April 1, 2019                 [Page 6]
Internet-Draft           CNSA Suite CMC Profile           September 2018

         +  The ExtensionReq attribute MUST be included with its
            contents as follows:

            -  The Key Usage extension MUST be included, and it MUST be
               set as defined in [ID.cnsa-cert-profile].

            -  For rekey requests, the SubjectAltName extension MUST 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 of the certificate
               being used to generate the signature is NULL.

            -  Other extension requests MAY be included as desired.

         +  The ChangeSubjectName attribute, as defined in [RFC6402],
            MUST 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 or SubjectAltName does not match the
            desired Subject or SubjectAltName of this certification
            request.

         +  The POP Link Witness Version 2 attribute MUST be included if
            the request is being authenticated using a shared-secret and
            the Subject 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
            be id-sha384 for certification requests, as defined in
            [RFC5754]; macAlgorithm MUST be HMAC-SHA384, as defined in
            [RFC4231].

      *  signatureAlgorithm MUST be ecdsa-with-sha384 for P-384
         certification requests, and sha384WithRSAEncryption or id-
         RSASSA-PSS for RSA-3072 and RSA-4096 certification requests;

      *  signature MUST be generated using the private key corresponding
         to the public key in the CertificationRequestInfo, for both
         signature and key establishment certification requests.  The
         signature provides proof-of-possession of the private key to
         the Certification Authority.

5.2.  Certificate Request Message

   The reqSequence crm choice conveys Certificate Request Message Format
   (CRMF) [RFC4211] syntax.  The CertReqMsg MUST comply with [RFC5272],
   Section 3.2.1.2.2, with the following additional requirements:

Jenkins & Zieglar         Expires April 1, 2019                 [Page 7]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   o  popo MUST be included using the signature (POPOSigningKey) proof-
      of-possession choice and set as defined in [RFC4211], Section 4.1,
      for both signature and key establishment certification requests.
      The POPOSigningKey poposkInput field MUST be omitted.  The
      POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha384 for
      P-384 certification requests, and sha384WithRSAEncryption or id-
      RSASSA-PSS for RSA-3072 and RSA-4096 certification requests.  The
      signature MUST be generated using the private key corresponding to
      the public key in the CertTemplate.

   The CertTemplate MUST comply with [RFC5272], Section 3.2.1.2.2, with
   the following additional requirements:

   o  version MAY be included and, if included, it MUST be set to 2 as
      defined in Section 4.3 of [ID.cnsa-cert-profile];

   o  publicKey MUST be set as defined in Section 4.4 of
      [ID.cnsa-cert-profile];

   o  extensions:

      *  The Key Usage extension MUST be included, and it MUST be set as
         defined in [ID.cnsa-cert-profile].

      *  For rekey requests, the SubjectAltName extension MUST 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 of the certificate being used to generate the
         signature is NULL.

      *  Other extension requests MAY be included as desired.

   o  controls:

      *  The ChangeSubjectName attribute, as defined in [RFC6402], MUST
         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 or SubjectAltName does not match the desired Subject or
         SubjectAltName of this certification request.

      *  The POP Link Witness Version 2 attribute MUST be included if
         the request is being authenticated using a shared-secret, and
         the Subject 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 be id-sha384

Jenkins & Zieglar         Expires April 1, 2019                 [Page 8]
Internet-Draft           CNSA Suite CMC Profile           September 2018

         for certification requests; macAlgorithm MUST be HMAC-SHA384
         when keyGenAlgorithm is id-sha384.

6.  RA Requirements

   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
   [RFC5272].  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.

6.1.  RA Processing of Requests

   RAs conforming to this document MUST 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 reject those
   requests.  The RA SHOULD return a CMCFailInfo with the value of
   badAlg [RFC5272].

   When processing end-entity-generated SignedData objects, RAs MUST NOT
   perform Cryptographic Message Syntax (CMS) Content Constraints (CCC)
   certificate extension processing [RFC6010].

   Other RA processing is as in [RFC5272].

6.2.  RA-Generated PKI Requests

   RAs mediate the certificate request process by collecting Client
   requests in batches.  The RA MUST encapsulate client-generated PKI
   Requests in a new RA-signed PKI Request, it MUST create a Full PKI
   Request encapsulated in a SignedData, and the SignedData MUST be
   constructed in accordance with [ID.cnsa-smime-profile].  The PKIData
   content type complies with [RFC5272] with the following additional
   requirements:

   o  controlSequence MUST be present.  It MUST include the following
      CMC controls: Transaction ID, Sender Nonce, and Batch Requests.
      Other appropriate CMC controls MAY be included.

   o  cmsSequence MUST be present.  It contains the original, unmodified
      request(s) received from the client.

Jenkins & Zieglar         Expires April 1, 2019                 [Page 9]
Internet-Draft           CNSA Suite CMC Profile           September 2018

         SignedData (applied by the RA)
           PKIData
             controlSequence (Transaction ID, Sender Nonce,
                                                  Batch Requests)
             cmsSequence
               SignedData (applied by Client)
                 PKIData
                   controlSequence (Transaction ID, Sender Nonce)
                   reqSequence
                     TaggedRequest
                     {TaggedRequest}
               {SignedData     (second Client request)
                 PKIData...}

   Authorization to sign RA-generated Full PKI Requests SHOULD be
   indicated in the RA certificate by inclusion of the id-kp-cmcRA EKU
   from [RFC6402].  The RA certificate MAY also include the CCC
   certificate extension [RFC6010], or it MAY indicate authorizaton
   thorugh inclusion of the CCC certificate extension alone.  The RA
   certificate may also be authorized through local configuration.

   If the RA is authorized via the CCC extension, then the CCC extension
   MUST include the object identifier for the PKIData content type.  CCC
   SHOULD be included if constraints are to be placed on the content
   types generated.

   The outer SignedData MUST 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.

   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
   SignedData MUST be signed by the algorithm used in the response MUST
   match the algorithm used in the request.

6.3.  RA-Generated Errors

   RA certificates authorized with the CCC certificate extension
   [RFC6010] MUST include the object identifier for the PKIResponse
   content type to authorize them to generate responses.

7.  CA Requirements

   This section specifies the requirements for CAs that receive PKI
   Requests and that generate PKI Responses.

Jenkins & Zieglar         Expires April 1, 2019                [Page 10]
Internet-Draft           CNSA Suite CMC Profile           September 2018

7.1.  CA Processing of PKI Requests

   CAs conforming to this document MUST 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 reject those
   requests.  The CA SHOULD return a CMCStatusInfoV2 control with
   CMCStatus of failed and a CMCFailInfo with the value of badAlg
   [RFC5272].

   For requests involving an RA (i.e., batched requests), the CA MUST
   verify the RA's authorization.  The following certificate fields MUST
   NOT be modifiable using the Modify Certification Request control:
   publicKey and the key usage extension.  The request MUST be rejected
   if an attempt to modify those certification request fields is
   present.  The CA SHOULD return a CMCStatusInfoV2 control with
   CMCStatus of failed and a CMCFailInfo with a value of badRequest.

   When processing end-entity-generated SignedData objects, CAs MUST NOT
   perform CCC certificate extension processing [RFC6010].

   If the client-generated PKI Request includes a ChangeSubjectName
   attribute either in the CertRequest controls field for a CRMF
   [RFC4211] request or in the tcr attributes field for a PKCS #10
   [RFC2986] request, then the CA MUST ensure that name change is
   authorized.  The mechanism for ensuring that the name change is
   authorized is out of scope.  If the CA performs this check, and the
   name change is not authorized, then the CA MUST reject the PKI
   Request.  The CA SHOULD return a CMCStatusInfoV2 control with
   CMCStatus of failed.

   Other processing of PKIRequests is as in [RFC5272].

7.2.  CA-Generated PKI Responses

   CAs send PKI Responses to both Client-generated reqeusts and RA-
   generated requests.  If a Full PKI Response is returned in direct
   response to a Client-generated request, it MUST be encapsulated in a
   SignedData, and the SignedData MUST be constructed in accordance with
   [ID.cnsa-smime-profile].

   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 be encapsulated in a SignedData
   and the SignedData MUST be constructed in accordance with
   [ID.cnsa-smime-profile].  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

Jenkins & Zieglar         Expires April 1, 2019                [Page 11]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   to an RA-encapsulated PKI Request, both of which include Transaction
   IDs and Nonces:

         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)

   The same private key used to sign certificates MUST NOT be used to
   sign Full PKI Response messages.  Instead, a separate certificate
   indicating authorization to sign CMC responses MUST be used.

   Authorization to sign Full PKI Responses SHOULD be indicated in the
   CA certificate by inclusion of the id-kp-cmcCA EKU from [RFC6402].
   The CA certificate MAY also include the CCC certificate extension
   [RFC6010], or it MAY indicate authorizaton thorugh inclusion of the
   CCC certificate extension alone.  The CA certificate may also be
   authorized through local configuration.

   If the CA is authorized via the CCC extension, then the CCC extension
   MUST include the object identifier for the PKIResponse content type.
   CCC SHOULD be included if constraints are to be placed on the content
   types generated.

   Signatures applied to individual certificates are as required in
   [ID.cnsa-cert-profile].

   The signature on the SignedData of a successful response to a Client-
   generated request, or each individual inner SignedData on the
   successful response to a RA-generated request, MUST 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 be signed using the same key-type and
   algorithm that signed the request.

   The outer SignedData on the Full PKI Response to any RA-generated PKI
   Request MUST be signed with the same key-type and algorithm that
   signed the request.

   The SignedData on a successful Full PKI Response to a PKI Request
   that only contained a Get Certificate or Get CRL control MUST be
   signed with the same key-type and algorithm that signed the request.

Jenkins & Zieglar         Expires April 1, 2019                [Page 12]
Internet-Draft           CNSA Suite CMC Profile           September 2018

8.  Client Requirements: Processing PKI Responses

   Clients conforming to this document MUST 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
   reject those responses.

   Clients MUST 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 include the id-kp-cmcCA EKU and/or include a CCC
   extension that includes the object identifier for the PKIResponse
   content type.  Or, 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 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 include the id-kp-cmcRA EKU and/or include a CCC
   extension that includes the object identifier for the PKIResponse
   content type.  Or, the RA is determined to be authorized to sign
   responses through an implementation-specific mechanism.

   When a newly issued certificate is included in the PKI Response, the
   client MUST verify that the newly issued certificate's public key
   matches the public key that the client requested.  The client MUST
   also ensure that the certificate's signature is valid and that the
   signature validates back to an acceptable trust anchor.

   Clients MUST 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 with CMCStatus set
   to failed to a user console, error log, or the server.

   If the Full PKI Response contains an Extended Status Info 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.

9.  Shared-Secrets

   When the Identity Proof V2 and POP Link Witness V2 controls are used,
   the shared-secret MUST be randomly generated and securely
   distributed.  The shared-secret MUST provide at least 192 bits of
   strength.

Jenkins & Zieglar         Expires April 1, 2019                [Page 13]
Internet-Draft           CNSA Suite CMC Profile           September 2018

10.  Security Considerations

   Protocol security considerations are found in [RFC2986], [RFC4211],
   [ID.cnsa-smime-profile], [RFC5272], [RFC5273], [RFC5274],
   [ID.cnsa-cert-profile], and [RFC6402].  When CCC is used to authorize
   RA and CA certificates, then the security considerations in [RFC6010]
   also apply.  Algorithm security considerations are found in
   [ID.cnsa-smime-profile].

   Compliant with NIST Special Publication 800-57 [SP80057], 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 be used for both signature and
   key establishment.

   This specification requires implementations to generate key pairs and
   other random values.  The use of inadequate pseudo-random number
   generators (PRNGs) can result in little or no security.  The
   generation of quality random numbers is difficult.  NIST Special
   Publication 800-90 [SP80090], FIPS 186-3 [DSS], and [RFC4086] offer
   random number generation guidance.

   When RAs are used, the list of authorized RAs must be securely
   distributed out-of-band to CAs.

   Presence of the POP Link Witness Version 2 and POP Link Random
   attributes protects against substitution attacks.

   The Certificate Policy for a particular environment will specify
   whether expired certificates can be used to sign certification
   requests.

11.  IANA Considerations

   This document has no IANA actions.

12.  References

12.1.  Normative References

   [CNSSP15]  Committee for National Security Systems, "Use of Public
              Standards for Secure Information Sharing", CNSSP 15,
              October 2016, <https://www.cnss.gov/CNSS/
              openDoc.cfm?RiDpSnrKfby8v6BSiFmVHw==>.

Jenkins & Zieglar         Expires April 1, 2019                [Page 14]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   [DSS]      National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", July 2013,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-4.pdf>.

   [ID.cnsa-cert-profile]
              Jenkins, M. and L. Zieglar, "Commercial National Security
              Algorithm (CNSA) Suite Certificate and Certificate
              Revocation List (CRL) Profile", January 2018,
              <https://www.ietf.org/internet-drafts/
              draft-jenkins-cnsa-cert-crl-profile-01>.

              Work in progress.

   [ID.cnsa-smime-profile]
              Jenkins, M., "Using CNSA Suite Algorithms in Secure/
              Multipurpose Internet Mail Extensions(S/MIME)", February
              2018.

              Work in progress.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              DOI 10.17487/RFC2986, November 2000,
              <https://www.rfc-editor.org/info/rfc2986>.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              DOI 10.17487/RFC4055, June 2005,
              <https://www.rfc-editor.org/info/rfc4055>.

   [RFC4056]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
              Cryptographic Message Syntax (CMS)", RFC 4056,
              DOI 10.17487/RFC4056, June 2005,
              <https://www.rfc-editor.org/info/rfc4056>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

Jenkins & Zieglar         Expires April 1, 2019                [Page 15]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF)", RFC 4211,
              DOI 10.17487/RFC4211, September 2005,
              <https://www.rfc-editor.org/info/rfc4211>.

   [RFC4231]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
              224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
              RFC 4231, DOI 10.17487/RFC4231, December 2005,
              <https://www.rfc-editor.org/info/rfc4231>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
              <https://www.rfc-editor.org/info/rfc5272>.

   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC): Transport Protocols", RFC 5273,
              DOI 10.17487/RFC5273, June 2008,
              <https://www.rfc-editor.org/info/rfc5273>.

   [RFC5274]  Schaad, J. and M. Myers, "Certificate Management Messages
              over CMS (CMC): Compliance Requirements", RFC 5274,
              DOI 10.17487/RFC5274, June 2008,
              <https://www.rfc-editor.org/info/rfc5274>.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
              2010, <https://www.rfc-editor.org/info/rfc5754>.

   [RFC6010]  Housley, R., Ashmore, S., and C. Wallace, "Cryptographic
              Message Syntax (CMS) Content Constraints Extension",
              RFC 6010, DOI 10.17487/RFC6010, September 2010,
              <https://www.rfc-editor.org/info/rfc6010>.

   [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)
              Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
              <https://www.rfc-editor.org/info/rfc6402>.

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <https://www.rfc-editor.org/info/rfc8017>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Jenkins & Zieglar         Expires April 1, 2019                [Page 16]
Internet-Draft           CNSA Suite CMC Profile           September 2018

12.2.  Informative References

   [SP80057]  National Institute of Standards and Technology,
              "Recommendation for Key Management, Part 1: General",
              January 2016,
              <http://doi.org/10.6028/NIST.SP.800-57pt1r4>.

   [SP80090]  National Institute of Standards and Technology,
              "Recommendation for Random Number Generation Using
              Deterministic Random Bit Generators", June 2015,
              <http://doi.org/10.6028/NIST.SP.800-90Ar1>.

Appendix A.  Scenarios

   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.

A.1.  Initial Enrollment

   This section describes three scenarios for authenticating initial
   enrollment requests:

   1.  Previously installed signature certificate (e.g., Manufacturer
       Installed Certificate);

   2.  Shared-secret distributed securely out-of-band;

   3.  RA authentication.

A.1.1.  Previously Installed Signature Certificate

   In this scenario, the end-entity has had a signature certificate
   installed by the cryptographic module manufacturer.  As the end-
   entity already has a signature certificate, it can be used to
   authenticate a request for a new certificate.  The end-entity signs
   the Full PKI Request with the private key that corresponds to the
   subject public key of a previously installed signature certificate.
   The CA will recognize the authorization of the previously installed
   certificate and issue an appropriate certificate to the end-entity.

A.1.2.  Shared-Secret Distributed Securely Out-of-Band

   In this scenario, the CA distributes a shared-secret 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

Jenkins & Zieglar         Expires April 1, 2019                [Page 17]
Internet-Draft           CNSA Suite CMC Profile           September 2018

   authenticate the request using the shared-secret.  The CA uses either
   the Identification control or the Subject in the end-entity's
   enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request
   message to identify the request.  The end-entity performs either the
   POP Link Witness Version 2 mechanism as described in [RFC5272],
   Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name
   (DN) linking mechanism as described in [RFC5272], Section 6.3.2.  The
   Subject in the enclosed PKCS #10 [RFC2986] or CRMF [RFC4211]
   certification request does not necessarily match the issued
   certificate, as it may be used just to help identify the request (and
   corresponding shared-secret) to the CA.

A.1.3.  RA Authentication

   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 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 approved, encapsulates and signs the request
   as described in Section 5.2, forwarding the new request on to the CA.
   The Subject in the PKCS #10 [RFC2986] or CRMF [RFC4211] certification
   request is not required to match the issued certificate, it may be
   used just to help identify the request to the RA and/or CA.

A.2.  Rekey

   There are two scenarios to support the rekey of certificates that are
   already enrolled.  One addresses the rekey of signature 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.

A.2.1.  Rekey of Signature Certificates

   When a signature certificate is rekeyed, the PKCS #10 [RFC2986] or
   CRMF [RFC4211] certification request message enclosed in the Full PKI
   Request will include the same Subject as the current signature
   certificate.  The Full PKI Request will be signed by the current
   private key corresponding to the current signature certificate.

Jenkins & Zieglar         Expires April 1, 2019                [Page 18]
Internet-Draft           CNSA Suite CMC Profile           September 2018

A.2.2.  Rekey of Key Establishment Certificates

   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
   may be used.

Authors' Addresses

   Michael Jenkins
   National Security Agency

   Email: mjjenki@tycho.ncsc.mil

   Lydia Zieglar
   National Security Agency

   Email: llziegl@ntycho.ncsc.mil

Jenkins & Zieglar         Expires April 1, 2019                [Page 19]