idnits 2.17.1 

draft-jenkins-cnsa-cmc-profile-01.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (February 7, 2019) is 1903 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: A later version (-06) exists of
     draft-jenkins-cnsa-cert-crl-profile-01


     Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	Network Working Group                                         M. Jenkins
3	Internet-Draft                                                L. Zieglar
4	Intended status: Informational                                       NSA
5	Expires: August 11, 2019                                February 7, 2019

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

11	Abstract

13	   The United States government has published the NSA Commercial
14	   National Security Algorithm (CNSA) Suite, which defines cryptographic
15	   algorithm policy for national security applications.  This document
16	   specifies a profile of the Certificate Management over CMS (CMC)
17	   protocol for managing X.509 public key certificates in applications
18	   using the CNSA Suite.  It is a refinement of RFCs 5272, 5273, and
19	   5274.  The profile applies to the capabilities, configuration, and
20	   operation of all components of US National Security Systems that
21	   manage X.509 public key certificates over CMS.  US National Security
22	   Systems are described in NIST Special Publication SP-800-59.  It is
23	   also appropriate for all other US Government systems that process
24	   high-value information.  It is made publicly available for use by
25	   developers and operators of these and any other system deployments.

27	Status of This Memo

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

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

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

42	   This Internet-Draft will expire on August 11, 2019.

44	Copyright Notice

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

49	   This document is subject to BCP 78 and the IETF Trust's Legal
50	   Provisions Relating to IETF Documents
51	   (https://trustee.ietf.org/license-info) in effect on the date of
52	   publication of this document.  Please review these documents
53	   carefully, as they describe your rights and restrictions with respect
54	   to this document.  Code Components extracted from this document must
55	   include Simplified BSD License text as described in Section 4.e of
56	   the Trust Legal Provisions and are provided without warranty as
57	   described in the Simplified BSD License.

59	Table of Contents

61	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
62	   2.  The Commercial National Security Algorithm Suite  . . . . . .   3
63	   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
64	   4.  Requirements and Assumptions  . . . . . . . . . . . . . . . .   4
65	   5.  Client Requirements: Generating PKI Requests  . . . . . . . .   5
66	     5.1.  Tagged Certification Request  . . . . . . . . . . . . . .   7
67	     5.2.  Certificate Request Message . . . . . . . . . . . . . . .   8
68	   6.  RA Requirements . . . . . . . . . . . . . . . . . . . . . . .   9
69	     6.1.  RA Processing of Requests . . . . . . . . . . . . . . . .   9
70	     6.2.  RA-Generated PKI Requests . . . . . . . . . . . . . . . .   9
71	     6.3.  RA-Generated Errors . . . . . . . . . . . . . . . . . . .  10
72	   7.  CA Requirements . . . . . . . . . . . . . . . . . . . . . . .  11
73	     7.1.  CA Processing of PKI Requests . . . . . . . . . . . . . .  11
74	     7.2.  CA-Generated PKI Responses  . . . . . . . . . . . . . . .  11
75	   8.  Client Requirements: Processing PKI Responses . . . . . . . .  13
76	   9.  Shared-Secrets  . . . . . . . . . . . . . . . . . . . . . . .  14
77	   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
78	   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
79	   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
80	     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
81	     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
82	   Appendix A.  Scenarios  . . . . . . . . . . . . . . . . . . . . .  17
83	     A.1.  Initial Enrollment  . . . . . . . . . . . . . . . . . . .  17
84	     A.2.  Rekey . . . . . . . . . . . . . . . . . . . . . . . . . .  18
85	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

87	1.  Introduction

89	   This document specifies a profile of the Certificate Management over
90	   CMS (CMC) protocol to comply with the United States National Security
91	   Agency's Commercial National Security Algorithm (CNSA) Suite
92	   [CNSSP15].  The profile applies to the capabilities, configuration,
93	   and operation of all components of US National Security Systems
94	   [SP-800-59].  It is also appropriate for all other US Government
95	   systems that process high-value information.  It is made publicly
96	   available for use by developers and operators of these and any other
97	   system deployments.

99	   This document does not define any new cryptographic algorithm suite;
100	   instead, it defines a CNSA compliant profile of CMC.  CMC is defined
101	   in [RFC5272], [RFC5273], and [RFC5274], and is updated by [RFC6402].
102	   This document profiles CMC to manage X.509 public key certificates in
103	   compliance with the CNSA Suite Certificate and Certificate Revocation
104	   List (CRL) Profile [ID.cnsa-cert-profile].  This document
105	   specifically focuses on defining CMC interactions for both initial
106	   enrollment and rekey of CNSA Suite public key certificates between a
107	   client and a Certification Authority (CA).  One or more Registration
108	   Authorities (RAs) may act as intermediaries between the client and
109	   the CA.  This profile may be further tailored by specific communities
110	   to meet their needs.  Specific communities will also define
111	   Certificate Policies that implementations need to comply with.

113	2.  The Commercial National Security Algorithm Suite

115	   The National Security Agency (NSA) profiles commercial cryptographic
116	   algorithms and protocols as part of its mission to support secure,
117	   interoperable communications for US Government National Security
118	   Systems.  To this end, it publishes guidance both to assist with the
119	   USG transition to new algorithms, and to provide vendors - and the
120	   Internet community in general - with information concerning their
121	   proper use and configuration.

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

133	   NSA is publishing a set of RFCs, including this one, to provide
134	   updated guidance concerning the use of certain commonly available
135	   commercial algorithms in IETF protocols.  These RFCs can be used in
136	   conjunction with other RFCs and cryptographic guidance (e.g., NIST
137	   Special Publications) to properly protect Internet traffic and data-
138	   at-rest for US Government National Security Systems.

140	3.  Terminology

142	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
143	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
144	   "OPTIONAL" in this document are to be interpreted as described in BCP
145	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
146	   capitals, as shown here.

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

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

155	4.  Requirements and Assumptions

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

163	   RSA key pairs (public, private) are identified by the modulus size
164	   expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of
165	   3072 bits and 4096 bits, respectively.

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

171	   It is recognized that, while the vast majority of RSA signatures are
172	   currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
173	   RSA signature scheme for new applications is RSASSA-PSS.  CNSA Suite
174	   compliant X.509 certificates will be issued in accordance with
175	   [ID.cnsa-cert-profile], and while they must be validated using
176	   RSASSA-PKCS1-v1_5, they can be used to produce signatures with either
177	   signing scheme.  Where use of RSASSA-PSS is indicated in this
178	   document, the following parameters apply:

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

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

185	   o  the salt length must be 48 octets; and

187	   o  the trailerField must have value 1.

189	   These parameters will not appear in a certificate and must be
190	   securely communicated with the signature as specified in [RFC4056].
191	   Application developers are obliged to ensure that the chosen
192	   signature scheme is appropriate for the application and will be
193	   interoperable within the intended operating scope of the application.

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

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

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

205	   The term "client" in this profile typically refers to an end-entity.
206	   However, it may instead refer to a third party acting on the end-
207	   entity's behalf.  The client may or may not be the entity that
208	   actually generates the key pair, but it does perform the CMC protocol
209	   interactions with the RA and/or CA.  For example, the client may be a
210	   token management system that communicates with a cryptographic token
211	   through an out-of-band secure protocol.

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

218	   This profile may be used to manage RA and/or CA certificates.  In
219	   that case, the RA and/or CA whose certificate is being managed is
220	   considered to be the end-entity.

222	   This profile does not support key establishment certification
223	   requests from cryptographic modules that cannot generate a one-time
224	   signature with a key establishment key for proof-of-possession
225	   purposes.  In that case, a separate profile would be needed to define
226	   the use of another proof-of-possession technique.

228	5.  Client Requirements: Generating PKI Requests

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

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

238	   o  controlSequence SHOULD be present.

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

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

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

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

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

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

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

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

273	   If an appropriate signature certificate does not yet exist, and if a
274	   Full PKI Request includes one or more certification requests and is
275	   authenticated using a shared-secret (because no appropriate
276	   certificate exists yet to authenticate the request), the Full PKI
277	   Request MUST be signed using the private key corresponding to the
278	   public key of one of the requested certificates.  When necessary
279	   (i.e., because there is no existing signature certificate and there
280	   is no signature certification request included), a Full PKI Request
281	   MAY be signed using a key pair intended for use in a key
282	   establishment certificate.  However, servers are not required to
283	   allow this behavior.

285	5.1.  Tagged Certification Request

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

291	   o  certificationRequestInfo:

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

296	      *  attributes:

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

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

304	            -  For rekey requests, the SubjectAltName extension MUST be
305	               included and set equal to the SubjectAltName of the
306	               certificate that is being used to sign the SignedData
307	               encapsulating the request (i.e., not the certificate
308	               being rekeyed) if the Subject field of the certificate
309	               being used to generate the signature is NULL.

311	            -  Other extension requests MAY be included as desired.

313	         +  The ChangeSubjectName attribute, as defined in [RFC6402],
314	            MUST be included if the Full PKI Request encapsulating this
315	            Tagged Certification Request is being signed by a key for
316	            which a certificate currently exists and the existing
317	            certificate's Subject or SubjectAltName does not match the
318	            desired Subject or SubjectAltName of this certification
319	            request.

321	         +  The POP Link Witness Version 2 attribute MUST be included if
322	            the request is being authenticated using a shared-secret and
323	            the Subject in the certification request is NULL or
324	            otherwise does not uniquely identify the end-entity.  In the
325	            POP Link Witness Version 2 attribute, keyGenAlgorithm MUST
326	            be id-sha384 for certification requests, as defined in
327	            [RFC5754]; macAlgorithm MUST be HMAC-SHA384, as defined in
328	            [RFC4231].

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

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

340	5.2.  Certificate Request Message

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

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

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

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

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

365	   o  extensions:

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

370	      *  For rekey requests, the SubjectAltName extension MUST be
371	         included and set equal to the SubjectAltName of the certificate
372	         that is being used to sign the SignedData encapsulating the
373	         request (i.e., not the certificate being rekeyed) if the
374	         Subject field of the certificate being used to generate the
375	         signature is NULL.

377	      *  Other extension requests MAY be included as desired.

379	   o  controls:

381	      *  The ChangeSubjectName attribute, as defined in [RFC6402], MUST
382	         be included if the Full PKI Request encapsulating this Tagged
383	         Certification Request is being signed by a key for which a
384	         certificate currently exists and the existing certificate's
385	         Subject or SubjectAltName does not match the desired Subject or
386	         SubjectAltName of this certification request.

388	      *  The POP Link Witness Version 2 attribute MUST be included if
389	         the request is being authenticated using a shared-secret, and
390	         the Subject in the certification request is NULL or otherwise
391	         does not uniquely identify the end-entity.  In the POP Link
392	         Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384
393	         for certification requests; macAlgorithm MUST be HMAC-SHA384
394	         when keyGenAlgorithm is id-sha384.

396	6.  RA Requirements

398	   This section addresses the optional case where one or more RAs act as
399	   intermediaries between clients and a CA as described in Section 7 of
400	   [RFC5272].  In this section, the term "client" refers to the entity
401	   from which the RA received the PKI Request.  This section is only
402	   applicable to RAs.

404	6.1.  RA Processing of Requests

406	   RAs conforming to this document MUST ensure that only the permitted
407	   signature, hash, and MAC algorithms described throughout this profile
408	   are used in requests; if they are not, the RA MUST reject those
409	   requests.  The RA SHOULD return a CMCFailInfo with the value of
410	   badAlg [RFC5272].

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

416	   Other RA processing is as in [RFC5272].

418	6.2.  RA-Generated PKI Requests

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

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

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

435	         SignedData (applied by the RA)
436	           PKIData
437	             controlSequence (Transaction ID, Sender Nonce,
438	                                                  Batch Requests)
439	             cmsSequence
440	               SignedData (applied by Client)
441	                 PKIData
442	                   controlSequence (Transaction ID, Sender Nonce)
443	                   reqSequence
444	                     TaggedRequest
445	                     {TaggedRequest}
446	               {SignedData     (second Client request)
447	                 PKIData...}

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

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

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

465	   If the Full PKI Response is a successful response to a PKI Request
466	   that only contained a Get Certificate or Get CRL control, then the
467	   SignedData MUST be signed by the algorithm used in the response MUST
468	   match the algorithm used in the request.

470	6.3.  RA-Generated Errors

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

476	7.  CA Requirements

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

481	7.1.  CA Processing of PKI Requests

483	   CAs conforming to this document MUST ensure that only the permitted
484	   signature, hash, and MAC algorithms described throughout this profile
485	   are used in requests; if they are not, the CA MUST reject those
486	   requests.  The CA SHOULD return a CMCStatusInfoV2 control with
487	   CMCStatus of failed and a CMCFailInfo with the value of badAlg
488	   [RFC5272].

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

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

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

511	   Other processing of PKIRequests is as in [RFC5272].

513	7.2.  CA-Generated PKI Responses

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

521	   If the PKI Response is in response to an RA-generated PKI Request,
522	   then the above PKI Response is encapsulated in another CA-generated
523	   PKI Response.  That PKI Response MUST be encapsulated in a SignedData
524	   and the SignedData MUST be constructed in accordance with
525	   [ID.cnsa-smime-profile].  The above PKI Response is placed in the
526	   encapsulating PKI Response cmsSequence field.  The other fields are
527	   as above with the addition of the batch response control in
528	   controlSequence.  The following illustrates a successful CA response
529	   to an RA-encapsulated PKI Request, both of which include Transaction
530	   IDs and Nonces:

532	         SignedData (applied by the CA)
533	           PKIResponse
534	             controlSequence (Transaction ID, Sender Nonce, Recipient
535	                              Nonce, Batch Response)
536	             cmsSequence
537	               SignedData (applied by CA and includes returned
538	                           certificates)
539	                 PKIResponse
540	                   controlSequence (Transaction ID, Sender Nonce,
541	                                    Recipient Nonce)

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

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

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

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

562	   The signature on the SignedData of a successful response to a Client-
563	   generated request, or each individual inner SignedData on the
564	   successful response to a RA-generated request, MUST be generated
565	   using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-
566	   PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.  An
567	   unsuccessful response MUST be signed using the same key-type and
568	   algorithm that signed the request.

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

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

578	8.  Client Requirements: Processing PKI Responses

580	   Clients conforming to this document MUST ensure that only the
581	   permitted signature, hash, and MAC algorithms described throughout
582	   this profile are used in responses; if they are not, the client MUST
583	   reject those responses.

585	   Clients MUST authenticate all Full PKI Responses.  This includes
586	   verifying that the PKI Response is signed by an authorized CA or RA
587	   whose certificate validates back to a trust anchor.  The authorized
588	   CA certificate MUST include the id-kp-cmcCA EKU and/or include a CCC
589	   extension that includes the object identifier for the PKIResponse
590	   content type.  Or, the CA is determined to be authorized to sign
591	   responses through an implementation-specific mechanism.  The PKI
592	   Response can be signed by an RA if it is an error message, if it is a
593	   response to a Get Certificate or Get CRL request, or if the PKI
594	   Response contains an inner PKI Response signed by a CA.  In the last
595	   case, each layer of PKI Response MUST still contain an authorized,
596	   valid signature signed by an entity with a valid certificate that
597	   verifies back to an acceptable trust anchor.  The authorized RA
598	   certificate MUST include the id-kp-cmcRA EKU and/or include a CCC
599	   extension that includes the object identifier for the PKIResponse
600	   content type.  Or, the RA is determined to be authorized to sign
601	   responses through an implementation-specific mechanism.

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

609	   Clients MUST reject PKI Responses that do not pass these tests.
610	   Local policy will determine whether the client returns a Full PKI
611	   Response with an Extended CMC Status Info control with CMCStatus set
612	   to failed to a user console, error log, or the server.

614	   If the Full PKI Response contains an Extended Status Info with a
615	   CMCStatus set to failed, then local policy will determine whether the
616	   client resends a duplicate certification request back to the server
617	   or an error state is returned to a console or error log.

619	9.  Shared-Secrets

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

626	10.  Security Considerations

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

635	   Compliant with NIST Special Publication 800-57 [SP80057], this
636	   profile defines proof-of-possession of a key establishment private
637	   key by performing a digital signature.  Except for one-time proof-of-
638	   possession, a single key pair MUST NOT be used for both signature and
639	   key establishment.

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

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

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

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

658	11.  IANA Considerations

660	   This document has no IANA actions.

662	12.  References
663	12.1.  Normative References

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

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

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

682	              Work in progress.

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

689	              Work in progress.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

764	12.2.  Informative References

766	   [SP-800-59]
767	              National Institute of Standards and Technology, "Guideline
768	              for Identifying an Information System as a National
769	              Security System", Special Publication 800 59, August 2003,
770	              <https://csrc.nist.gov/publications/detail/sp/800-59/ >
771	              final>.

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

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

783	Appendix A.  Scenarios

785	   This section illustrates several potential certificate enrollment and
786	   rekey scenarios supported by this profile.  This section does not
787	   intend to place any limits or restrictions on the use of CMC.

789	A.1.  Initial Enrollment

791	   This section describes three scenarios for authenticating initial
792	   enrollment requests:

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

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

799	   3.  RA authentication.

801	A.1.1.  Previously Installed Signature Certificate

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

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

814	   In this scenario, the CA distributes a shared-secret out-of-band to
815	   the end-entity that the end-entity uses to authenticate its
816	   certification request.  The end-entity signs the Full PKI Request
817	   with the private key for which the certification is being requested.
818	   The end-entity includes the Identity Proof Version 2 control to
819	   authenticate the request using the shared-secret.  The CA uses either
820	   the Identification control or the Subject in the end-entity's
821	   enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request
822	   message to identify the request.  The end-entity performs either the
823	   POP Link Witness Version 2 mechanism as described in [RFC5272],
824	   Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name
825	   (DN) linking mechanism as described in [RFC5272], Section 6.3.2.  The
826	   Subject in the enclosed PKCS #10 [RFC2986] or CRMF [RFC4211]
827	   certification request does not necessarily match the issued
828	   certificate, as it may be used just to help identify the request (and
829	   corresponding shared-secret) to the CA.

831	A.1.3.  RA Authentication

833	   In this scenario, the end-entity does not automatically authenticate
834	   its enrollment request to the CA, either because the end-entity has
835	   nothing to authenticate the request with or because organizational
836	   policy requires an RA's involvement.  The end-entity creates a Full
837	   PKI Request and sends it to an RA.  The RA verifies the authenticity
838	   of the request, then, if approved, encapsulates and signs the request
839	   as described in Section 5.2, forwarding the new request on to the CA.
840	   The Subject in the PKCS #10 [RFC2986] or CRMF [RFC4211] certification
841	   request is not required to match the issued certificate, it may be
842	   used just to help identify the request to the RA and/or CA.

844	A.2.  Rekey

846	   There are two scenarios to support the rekey of certificates that are
847	   already enrolled.  One addresses the rekey of signature certificates
848	   and the other addresses the rekey of key establishment certificates.

850	   Typically, organizational policy will require certificates to be
851	   currently valid to be rekeyed, and it may require initial enrollment
852	   to be repeated when rekey is not possible.  However, some
853	   organizational policies might allow a grace period during which an
854	   expired certificate could be used to rekey.

856	A.2.1.  Rekey of Signature Certificates

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

864	A.2.2.  Rekey of Key Establishment Certificates

866	   When a key establishment certificate is rekeyed, the Full PKI Request
867	   will generally be signed by the current private key corresponding to
868	   the current signature certificate.  If there is no current signature
869	   certificate, one of the initial enrollment options in Appendix A.1
870	   may be used.

872	Authors' Addresses

874	   Michael Jenkins
875	   National Security Agency

877	   Email: mjjenki@nsa.gov

879	   Lydia Zieglar
880	   National Security Agency

882	   Email: llziegl@ntycho.ncsc.mil