idnits 2.17.1 

draft-jenkins-cnsa-cmc-profile-05.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 (May 29, 2019) is 1794 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
  ----------------------------------------------------------------------------

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: November 30, 2019                                  May 29, 2019

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

11	Abstract

13	   This document specifies a profile of the Certificate Management over
14	   CMS (CMC) protocol for managing X.509 public key certificates in
15	   applications that use the Commercial National Security Algorithm
16	   (CNSA) Suite published by the United States Government.

18	   The profile applies to the capabilities, configuration, and operation
19	   of all components of US National Security Systems that manage X.509
20	   public key certificates over CMS.  It is also appropriate for all
21	   other US Government systems that process high-value information.

23	   The profile is made publicly available here for use by developers and
24	   operators of these and any other system deployments.

26	Status of This Memo

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

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

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

41	   This Internet-Draft will expire on November 30, 2019.

43	Copyright Notice

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

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

58	Table of Contents

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

86	1.  Introduction

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

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

111	2.  The Commercial National Security Algorithm Suite

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

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

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

139	3.  Terminology

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

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

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

154	4.  Requirements and Assumptions

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

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

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

170	   It is recognized that, while the vast majority of RSA signatures are
171	   currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
172	   RSA signature scheme for new applications is RSASSA-PSS.  CNSA Suite
173	   compliant X.509 certificates will be issued in accordance with
174	   [ID.cnsa-cert-profile], and while those certificates must be signed
175	   and validated using RSASSA-PKCS1-v1_5, the subject's private key can
176	   be used to generate signatures of either signing scheme.  Where use
177	   of RSASSA-PSS is indicated in this document, the following parameters
178	   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 required by Section 2.2
191	   of [RFC4056].  Application developers are obliged to ensure that the
192	   chosen signature scheme is appropriate for the application and will
193	   be interoperable within the intended operating scope of the
194	   application.

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

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

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

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

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

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

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

229	5.  Client Requirements: Generating PKI Requests

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

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

239	   o  controlSequence SHOULD be present.

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

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

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

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

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

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

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

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

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

286	5.1.  Tagged Certification Request

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

292	   o  certificationRequestInfo:

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

297	      *  attributes:

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

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

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

312	            -  Other extension requests MAY be included as desired.

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

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

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

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

341	5.2.  Certificate Request Message

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

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

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

360	   o  If version is included, it MUST be set to 2 as defined in
361	      Section 4.3 of [ID.cnsa-cert-profile];

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

366	   o  extensions:

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

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

378	      *  Other extension requests MAY be included as desired.

380	   o  controls:

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

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

397	6.  RA Requirements

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

405	6.1.  RA Processing of Requests

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

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

417	   Other RA processing is as in [RFC5272].

419	6.2.  RA-Generated PKI Requests

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

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

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

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

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

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

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

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

471	6.3.  RA-Generated PKI Responses

473	   In order for an RA certificate using the CCC certificate extension to
474	   be authorized to generate responses, the object identifier for the
475	   PKIResponse content type must be present in the CCC certificate
476	   extension.

478	7.  CA Requirements

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

483	7.1.  CA Processing of PKI Requests

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

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

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

503	   If a client-generated PKI Request includes the ChangeSubjectName
504	   attribute as described in Section 5.1 or Section 5.2 above, the CA
505	   MUST ensure that name change is authorized.  The mechanism for
506	   ensuring that the name change is authorized is out of scope.  A CA
507	   that performs this check and finds that the name change is not
508	   authorized MUST reject the PKI Request.  The CA SHOULD return an
509	   Extended CMC Status Info control (CMCStatusInfoV2) with CMCStatus of
510	   failed.

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

514	7.2.  CA-Generated PKI Responses

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

522	   If the PKI Response is in response to an RA-generated PKI Request,
523	   then the above PKI Response is encapsulated in another CA-generated
524	   PKI Response.  That PKI Response MUST be encapsulated in a SignedData
525	   and the SignedData MUST be constructed in accordance with

527	   [ID.cnsa-smime-profile].  The above PKI Response is placed in the
528	   encapsulating PKI Response cmsSequence field.  The other fields are
529	   as above with the addition of the batch response control in
530	   controlSequence.  The following illustrates a successful CA response
531	   to an RA-encapsulated PKI Request, both of which include Transaction
532	   IDs and Nonces:

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

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

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

556	   In order for an CA certificate using the CCC certificate extension to
557	   be authorized to generate responses, the object identifier for the
558	   PKIResponse content type must be present in the CCC certificate
559	   extension.  CCC SHOULD be included if constraints are to be placed on
560	   the content types generated.

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

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

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

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

581	8.  Client Requirements: Processing PKI Responses

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

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

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

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

618	   If the Full PKI Response contains an Extended CMC Status Info control
619	   with a CMCStatus set to failed, then local policy will determine
620	   whether the client resends a duplicate certification request back to
621	   the server or an error state is returned to a console or error log.

623	9.  Shared-Secrets

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

630	10.  Security Considerations

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

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

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

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

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

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

662	11.  IANA Considerations

664	   This document has no IANA actions.

666	12.  References

668	12.1.  Normative References

670	   [CNSA]     Committee for National Security Systems, "Use of Public
671	              Standards for Secure Information Sharing", CNSS Policy 15,
672	              October 2016,
673	              <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.

675	   [FIPS186]  National Institute of Standards and Technology, "Digital
676	              Signature Standard (DSS)", Federal Information Processing
677	              Standard 186-4, July 2013,
678	              <http://nvlpubs.nist.gov/nistpubs/FIPS/
679	              NIST.FIPS.186-4.pdf>.

681	   [ID.cnsa-cert-profile]
682	              Jenkins, M. and L. Zieglar, "Commercial National Security
683	              Algorithm (CNSA) Suite Certificate and Certificate
684	              Revocation List (CRL) Profile", January 2018,
685	              <https://tools.ietf.org/html/
686	              draft-jenkins-cnsa-cert-crl-profile>.

688	              Work in progress.

690	   [ID.cnsa-smime-profile]
691	              Jenkins, M., "Using CNSA Suite Algorithms in Secure/
692	              Multipurpose Internet Mail Extensions(S/MIME)", February
693	              2018, <https://tools.ietf.org/html/
694	              draft-jenkins-cnsa-smime-profile>.

696	              Work in progress.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

771	12.2.  Informative References

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

778	   [SP80059]  National Institute of Standards and Technology, "Guideline
779	              for Identifying an Information System as a National
780	              Security System", Special Publication 800 59, August 2003,
781	              <https://csrc.nist.gov/publications/detail/sp/800-59/
782	              final>.

784	   [SP80090A]
785	              National Institute of Standards and Technology,
786	              "Recommendation for Random Number Generation Using
787	              Deterministic Random Bit Generators", Special Publication
788	              800-90A Revision 1, June 2015,
789	              <http://doi.org/10.6028/NIST.SP.800-90Ar1>.

791	Appendix A.  Scenarios

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

797	A.1.  Initial Enrollment

799	   This section describes three scenarios for authenticating initial
800	   enrollment requests:

802	   1.  Previously certified signature key-pair (e.g., Manufacturer
803	       Installed Certificate);

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

807	   3.  RA authentication.

809	A.1.1.  Previously Certified Signature Key-pair

811	   In this scenario, the end-entity has a private signing key, and a
812	   corresponding public key certificate obtained from a cryptographic
813	   module manufacturer recognized by the CA.  The end-entity signs a
814	   Full PKI Request with the private key that corresponds to the subject
815	   public key of the previously installed signature certificate.  The CA
816	   will verify the authorization of the previously installed certificate
817	   and issue an appropriate new certificate to the end-entity.

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

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

838	A.1.3.  RA Authentication

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

851	A.2.  Rekey

853	   There are two scenarios to support the rekey of certificates that are
854	   already enrolled.  One addresses the rekey of signature certificates
855	   and the other addresses the rekey of key establishment certificates.
856	   Typically, organizational policy will require certificates to be
857	   currently valid to be rekeyed, and it may require initial enrollment
858	   to be repeated when rekey is not possible.  However, some
859	   organizational policies might allow a grace period during which an
860	   expired certificate could be used to rekey.

862	A.2.1.  Rekey of Signature Certificates

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

870	A.2.2.  Rekey of Key Establishment Certificates

872	   When a key establishment certificate is rekeyed, the Full PKI Request
873	   will generally be signed by the current private key corresponding to
874	   the current signature certificate.  If there is no current signature
875	   certificate, one of the initial enrollment options in Appendix A.1
876	   may be used.

878	Authors' Addresses

880	   Michael Jenkins
881	   National Security Agency

883	   Email: mjjenki@nsa.gov

885	   Lydia Zieglar
886	   National Security Agency

888	   Email: llziegl@tycho.ncsc.mil