idnits 2.17.1 

draft-jenkins-cnsa-cmc-profile-00.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 (September 28, 2018) is 2037 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: April 1, 2019                                September 28, 2018

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

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.  This profile is a refinement of RFCs 5272,
19	   5273, and 5274.

21	Status of This Memo

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

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

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

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

38	Copyright Notice

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

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

53	Table of Contents

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

81	1.  Introduction

83	   This document specifies a profile of the Certificate Management over
84	   CMS (CMC) protocol to comply with the United States National Security
85	   Agency's Commercial National Security Algorithm (CNSA) Suite
86	   [CNSSP15].  CMC is defined in [RFC5272], [RFC5273], and [RFC5274],
87	   and is updated by [RFC6402].  This document profiles CMC to manage
88	   X.509 public key certificates in compliance with the CNSA Suite
89	   Certificate and Certificate Revocation List (CRL) Profile
90	   [ID.cnsa-cert-profile].  This document specifically focuses on
91	   defining CMC interactions for both initial enrollment and rekey of
92	   CNSA Suite public key certificates between a client and a
93	   Certification Authority (CA).  One or more Registration Authorities
94	   (RAs) may act as intermediaries between the client and the CA.  This
95	   profile may be further tailored by specific communities to meet their
96	   needs.  Specific communities will also define Certificate Policies
97	   that implementations need to comply with.

99	2.  The Commercial National Security Algorithm Suite

101	   The National Security Agency (NSA) profiles commercial cryptographic
102	   algorithms and protocols as part of its mission to support secure,
103	   interoperable communications for US Government National Security
104	   Systems.  To this end, it publishes guidance both to assist with the
105	   USG transition to new algorithms, and to provide vendors - and the
106	   Internet community in general - with information concerning their
107	   proper use and configuration.

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

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

126	3.  Terminology

128	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
130	   "OPTIONAL" in this document are to be interpreted as described in BCP
131	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
132	   capitals, as shown here.

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

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

141	4.  Requirements and Assumptions

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

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

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

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

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

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

171	   o  the salt length must be 48 octets; and

173	   o  the trailerField must have value 1.

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

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

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

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

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

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

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

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

214	5.  Client Requirements: Generating PKI Requests

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

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

224	   o  controlSequence SHOULD be present.

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

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

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

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

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

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

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

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

259	   If an appropriate signature certificate does not yet exist, and if a
260	   Full PKI Request includes one or more certification requests and is
261	   authenticated using a shared-secret (because no appropriate
262	   certificate exists yet to authenticate the request), the Full PKI
263	   Request MUST be signed using the private key corresponding to the
264	   public key of one of the requested certificates.  When necessary
265	   (i.e., because there is no existing signature certificate and there
266	   is no signature certification request included), a Full PKI Request
267	   MAY be signed using a key pair intended for use in a key
268	   establishment certificate.  However, servers are not required to
269	   allow this behavior.

271	5.1.  Tagged Certification Request

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

277	   o  certificationRequestInfo:

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

282	      *  attributes:

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

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

290	            -  For rekey requests, the SubjectAltName extension MUST be
291	               included and set equal to the SubjectAltName of the
292	               certificate that is being used to sign the SignedData
293	               encapsulating the request (i.e., not the certificate
294	               being rekeyed) if the Subject field of the certificate
295	               being used to generate the signature is NULL.

297	            -  Other extension requests MAY be included as desired.

299	         +  The ChangeSubjectName attribute, as defined in [RFC6402],
300	            MUST be included if the Full PKI Request encapsulating this
301	            Tagged Certification Request is being signed by a key for
302	            which a certificate currently exists and the existing
303	            certificate's Subject or SubjectAltName does not match the
304	            desired Subject or SubjectAltName of this certification
305	            request.

307	         +  The POP Link Witness Version 2 attribute MUST be included if
308	            the request is being authenticated using a shared-secret and
309	            the Subject in the certification request is NULL or
310	            otherwise does not uniquely identify the end-entity.  In the
311	            POP Link Witness Version 2 attribute, keyGenAlgorithm MUST
312	            be id-sha384 for certification requests, as defined in
313	            [RFC5754]; macAlgorithm MUST be HMAC-SHA384, as defined in
314	            [RFC4231].

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

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

326	5.2.  Certificate Request Message

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

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

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

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

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

351	   o  extensions:

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

356	      *  For rekey requests, the SubjectAltName extension MUST be
357	         included and set equal to the SubjectAltName of the certificate
358	         that is being used to sign the SignedData encapsulating the
359	         request (i.e., not the certificate being rekeyed) if the
360	         Subject field of the certificate being used to generate the
361	         signature is NULL.

363	      *  Other extension requests MAY be included as desired.

365	   o  controls:

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

374	      *  The POP Link Witness Version 2 attribute MUST be included if
375	         the request is being authenticated using a shared-secret, and
376	         the Subject in the certification request is NULL or otherwise
377	         does not uniquely identify the end-entity.  In the POP Link
378	         Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384
379	         for certification requests; macAlgorithm MUST be HMAC-SHA384
380	         when keyGenAlgorithm is id-sha384.

382	6.  RA Requirements

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

390	6.1.  RA Processing of Requests

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

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

402	   Other RA processing is as in [RFC5272].

404	6.2.  RA-Generated PKI Requests

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

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

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

421	         SignedData (applied by the RA)
422	           PKIData
423	             controlSequence (Transaction ID, Sender Nonce,
424	                                                  Batch Requests)
425	             cmsSequence
426	               SignedData (applied by Client)
427	                 PKIData
428	                   controlSequence (Transaction ID, Sender Nonce)
429	                   reqSequence
430	                     TaggedRequest
431	                     {TaggedRequest}
432	               {SignedData     (second Client request)
433	                 PKIData...}

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

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

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

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

456	6.3.  RA-Generated Errors

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

462	7.  CA Requirements

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

467	7.1.  CA Processing of PKI Requests

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

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

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

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

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

499	7.2.  CA-Generated PKI Responses

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

507	   If the PKI Response is in response to an RA-generated PKI Request,
508	   then the above PKI Response is encapsulated in another CA-generated
509	   PKI Response.  That PKI Response MUST be encapsulated in a SignedData
510	   and the SignedData MUST be constructed in accordance with
511	   [ID.cnsa-smime-profile].  The above PKI Response is placed in the
512	   encapsulating PKI Response cmsSequence field.  The other fields are
513	   as above with the addition of the batch response control in
514	   controlSequence.  The following illustrates a successful CA response
515	   to an RA-encapsulated PKI Request, both of which include Transaction
516	   IDs and Nonces:

518	         SignedData (applied by the CA)
519	           PKIResponse
520	             controlSequence (Transaction ID, Sender Nonce, Recipient
521	                              Nonce, Batch Response)
522	             cmsSequence
523	               SignedData (applied by CA and includes returned
524	                           certificates)
525	                 PKIResponse
526	                   controlSequence (Transaction ID, Sender Nonce,
527	                                    Recipient Nonce)

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

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

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

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

548	   The signature on the SignedData of a successful response to a Client-
549	   generated request, or each individual inner SignedData on the
550	   successful response to a RA-generated request, MUST be generated
551	   using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-
552	   PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.  An
553	   unsuccessful response MUST be signed using the same key-type and
554	   algorithm that signed the request.

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

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

564	8.  Client Requirements: Processing PKI Responses

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

571	   Clients MUST authenticate all Full PKI Responses.  This includes
572	   verifying that the PKI Response is signed by an authorized CA or RA
573	   whose certificate validates back to a trust anchor.  The authorized
574	   CA certificate MUST include the id-kp-cmcCA EKU and/or include a CCC
575	   extension that includes the object identifier for the PKIResponse
576	   content type.  Or, the CA is determined to be authorized to sign
577	   responses through an implementation-specific mechanism.  The PKI
578	   Response can be signed by an RA if it is an error message, if it is a
579	   response to a Get Certificate or Get CRL request, or if the PKI
580	   Response contains an inner PKI Response signed by a CA.  In the last
581	   case, each layer of PKI Response MUST still contain an authorized,
582	   valid signature signed by an entity with a valid certificate that
583	   verifies back to an acceptable trust anchor.  The authorized RA
584	   certificate MUST include the id-kp-cmcRA EKU and/or include a CCC
585	   extension that includes the object identifier for the PKIResponse
586	   content type.  Or, the RA is determined to be authorized to sign
587	   responses through an implementation-specific mechanism.

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

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

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

605	9.  Shared-Secrets

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

612	10.  Security Considerations

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

621	   Compliant with NIST Special Publication 800-57 [SP80057], this
622	   profile defines proof-of-possession of a key establishment private
623	   key by performing a digital signature.  Except for one-time proof-of-
624	   possession, a single key pair MUST NOT be used for both signature and
625	   key establishment.

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

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

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

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

644	11.  IANA Considerations

646	   This document has no IANA actions.

648	12.  References

650	12.1.  Normative References

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

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

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

669	              Work in progress.

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

676	              Work in progress.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

751	12.2.  Informative References

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

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

763	Appendix A.  Scenarios

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

769	A.1.  Initial Enrollment

771	   This section describes three scenarios for authenticating initial
772	   enrollment requests:

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

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

779	   3.  RA authentication.

781	A.1.1.  Previously Installed Signature Certificate

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

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

794	   In this scenario, the CA distributes a shared-secret out-of-band to
795	   the end-entity that the end-entity uses to authenticate its
796	   certification request.  The end-entity signs the Full PKI Request
797	   with the private key for which the certification is being requested.
798	   The end-entity includes the Identity Proof Version 2 control to
799	   authenticate the request using the shared-secret.  The CA uses either
800	   the Identification control or the Subject in the end-entity's
801	   enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request
802	   message to identify the request.  The end-entity performs either the
803	   POP Link Witness Version 2 mechanism as described in [RFC5272],
804	   Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name
805	   (DN) linking mechanism as described in [RFC5272], Section 6.3.2.  The
806	   Subject in the enclosed PKCS #10 [RFC2986] or CRMF [RFC4211]
807	   certification request does not necessarily match the issued
808	   certificate, as it may be used just to help identify the request (and
809	   corresponding shared-secret) to the CA.

811	A.1.3.  RA Authentication

813	   In this scenario, the end-entity does not automatically authenticate
814	   its enrollment request to the CA, either because the end-entity has
815	   nothing to authenticate the request with or because organizational
816	   policy requires an RA's involvement.  The end-entity creates a Full
817	   PKI Request and sends it to an RA.  The RA verifies the authenticity
818	   of the request, then, if approved, encapsulates and signs the request
819	   as described in Section 5.2, forwarding the new request on to the CA.
820	   The Subject in the PKCS #10 [RFC2986] or CRMF [RFC4211] certification
821	   request is not required to match the issued certificate, it may be
822	   used just to help identify the request to the RA and/or CA.

824	A.2.  Rekey

826	   There are two scenarios to support the rekey of certificates that are
827	   already enrolled.  One addresses the rekey of signature certificates
828	   and the other addresses the rekey of key establishment certificates.
829	   Typically, organizational policy will require certificates to be
830	   currently valid to be rekeyed, and it may require initial enrollment
831	   to be repeated when rekey is not possible.  However, some
832	   organizational policies might allow a grace period during which an
833	   expired certificate could be used to rekey.

835	A.2.1.  Rekey of Signature Certificates

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

843	A.2.2.  Rekey of Key Establishment Certificates

845	   When a key establishment certificate is rekeyed, the Full PKI Request
846	   will generally be signed by the current private key corresponding to
847	   the current signature certificate.  If there is no current signature
848	   certificate, one of the initial enrollment options in Appendix A.1
849	   may be used.

851	Authors' Addresses

853	   Michael Jenkins
854	   National Security Agency

856	   Email: mjjenki@tycho.ncsc.mil

858	   Lydia Zieglar
859	   National Security Agency

861	   Email: llziegl@ntycho.ncsc.mil