idnits 2.17.1 draft-turner-suiteb-cmc-03.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 (June 30, 2010) is 5039 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-pkix-rfc5272-bis-00 ** Obsolete normative reference: RFC 5008 (Obsoleted by RFC 6318) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lydia Zieglar, NSA 2 Internet-Draft Sean Turner, IECA 3 Intended Status: Informational Mike Peck 4 Expires: December 30, 2010 June 30, 2010 6 Suite B Profile of Certificate Management over CMS 7 draft-turner-suiteb-cmc-03.txt 9 Abstract 11 The United States Government has published guidelines for "NSA Suite 12 B Cryptography", which defines cryptographic algorithm policy for 13 national security applications. This document specifies a profile of 14 the Certificate Management over CMS (CMC) protocol for managing Suite 15 B X.509 public key certificates. This profile is a refinement of RFC 16 5272, RFC 5273, and RFC 5274. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on December 30, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 This document specifies a profile for using the Certificate 59 Management over CMS (CMC) protocol, defined in [RFC5272], [RFC5273], 60 and [RFC5274], and updated by [CMCbis], to manage X.509 public key 61 certificates compliant with the United States National Security 62 Agency's Suite B Cryptography as defined in the Suite B Certificate 63 and Certificate Revocation List (CRL) Profile [RFC5759]. This 64 document specifically focuses on defining CMC interactions for both 65 initial enrollment and rekey of Suite B public key certificates 66 between a client and a Certification Authority (CA). One or more 67 Registration Authorities (RAs) may act as intermediaries between the 68 client and the CA. This profile may be further tailored by specific 69 communities to meet their needs. Specific communities will also 70 define Certificate Policies that implementations need to comply with. 72 2. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 The terminology in [RFC5272] Section 2.1 applies to this profile. 80 3. Requirements and Assumptions 82 All key pairs are on either the curve P-256 or the curve P-384. FIPS 83 186-3 [DSS] Appendix B.4 provides useful guidance for elliptic curve 84 key pair generation that SHOULD be followed by systems that conform 85 to this document. 87 This document assumes that the required trust anchors have been 88 securely provisioned to the client and, when applicable, to any RAs. 90 All requirements in [RFC5272], [RFC5273], [RFC5274], and [CMCbis] 91 apply, except where overridden by this profile. 93 This profile was developed with the scenarios described in Appendix A 94 in mind. However, use of this profile is not limited to just those 95 scenarios. 97 The term "client" in this profile typically refers to an end-entity. 98 However, it may instead refer to a third party acting on the 99 end-entity's behalf. The client may or may not be the entity that 100 actually generates the key pair, but it does perform the CMC protocol 101 interactions with the RA and/or CA. For example, the client may be a 102 token management system that communicates with a cryptographic token 103 through an out-of-band secure protocol. 105 This profile uses the term "rekey" in the same manner as does CMC 106 (defined in section 2 of [RFC5272]). The profile makes no specific 107 statements about the ability to do "renewal" operations, however the 108 statements applicable to rekey should be applied to renewal as well. 110 This profile may be used to manage RA and/or CA certificates. In 111 that case, the RA and/or CA whose certificate is being managed is 112 considered to be the end-entity. 114 This profile does not support key establishment certificate requests 115 from cryptographic modules that cannot generate a one-time signature 116 with a key establishment key for proof-of-possession purposes. In 117 that case, a separate profile would be needed to define the use of 118 another proof-of-possession technique. 120 4. Client Requirements: Generating PKI Requests 122 This section specifies the conventions employed when a client 123 requests a certificate from a Public Key Infrastructure (PKI). 125 The Full PKI Request MUST be used; it MUST be encapsulated in a 126 SignedData; and the SignedData MUST be constructed as defined in 127 [RFC5008]. The PKIData content type complies with [RFC5272] with the 128 following additional requirements: 130 o controlSequence SHOULD be present; and it SHOULD include the 131 following CMC controls: Transaction ID and Sender Nonce. Other 132 CMC controls MAY be included. If the request is being 133 authenticated using a shared secret, then the following 134 requirements in this paragraph apply: Identity Proof Version 2 135 control, as defined in [RFC5272], MUST be included; hashAlgId 136 MUST be id-sha256 or id-sha384 for P-256 certificate requests, 137 and MUST be id-sha384 for P-384 certificate requests, both 138 algorithm OIDs are defined in [RFC5754]; macAlgId MUST be HMAC- 139 SHA256 when the hashAlgId is id-sha256, and MUST be HMAC-SHA384 140 when the hashAlgId is id-sha384, both HMAC algorithms are 141 defined in [RFC4231]. If the subject included in the 142 certificate request is NULL or otherwise does not uniquely 143 identify the end-entity, then the POP Link Random control MUST 144 be included, and the POP Link Witness Version 2 control MUST be 145 included in the inner PKCS #10 or CRMF request as described in 146 Sections 4.1 and 4.2. 148 o reqSequence MUST be present. It MUST include at least one tcr 149 (see Section 4.1) or crm (see Section 4.2) TaggedRequest. 150 Support for the orm choice is OPTIONAL. 152 If the Full PKI Request contains a P-256 public key certificate 153 request, then the SignedData encapsulating the Full PKI Request MUST 154 be generated using either SHA-256 and ECDSA with P-256 or using SHA- 155 384 and ECDSA with P-384. If the Full PKI Request contains a P-384 156 public key certificate request, then the SignedData MUST be generated 157 using SHA-384 and ECDSA with P-384. 159 A Full PKI Request MUST be signed using the private key that 160 corresponds to the public key of an existing signature certificate 161 unless an appropriate signature certificate does not yet exist, such 162 as during initial enrollment. 164 If an appropriate signature certificate does not yet exist, a Full 165 PKI Request includes one or more certificate requests, and is 166 authenticated using a shared secret (because no appropriate 167 certificate exists yet to authenticate the request), the Full PKI 168 Request MUST be signed using the private key corresponding to the 169 public key of one of the requested certificates. A Full PKI Request 170 MAY be signed using a key pair intended for use in a key 171 establishment certificate when necessary because there is no existing 172 signature certificate and there is no signature certificate request 173 included. However, servers are not required to allow this behavior. 175 4.1. Tagged Certificate Request 177 The reqSequence tcr choice conveys PKCS #10 [RFC2986] syntax. The 178 CertificateRequest MUST comply with [RFC5272] Section 3.2.1.2.1 with 179 the following additional requirements: 181 o certificationRequestInfo: 183 o subjectPublicKeyInfo MUST be set as defined in 4.4 of 184 [RFC5759]; 186 o attributes: 188 o The ExtensionReq attribute MUST be included and contain: 190 o The Key Usage extension MUST be included and it MUST be 191 set as defined in [RFC5759]. 193 o For rekey requests, the SubjectAltName extension MUST be 194 included and set equal to the SubjectAltName of the 195 certificate which is being used to sign the SignedData 196 encapsulating the request (i.e., not the certificate 197 being re-keyed) if its Subject field of the certificate 198 being used to generate the signature is NULL. 200 o Other extension requests MAY be included as desired. 202 o The ChangeSubjectName attribute, as defined in [CMCbis], 203 MUST be included if the Full PKI Request encapsulating this 204 Tagged Certificate Request is being signed by a key for 205 which a certificate currently exists and the existing 206 certificate's Subject or SubjectAltName does not match the 207 desired Subject or SubjectAltName of this certificate 208 request. 210 o The POP Link Witness Version 2 attribute MUST be included if 211 the request is being authenticated using a shared secret 212 and the Subject in the certificate request is NULL or 213 otherwise does not uniquely identify the end-entity. In 214 the POP Link Witness Version 2 attribute, keyGenAlgorithm 215 MUST be id-sha256 or id-sha384 for P-256 certificate 216 requests and MUST be id-sha384 for P-384 certificate 217 requests, as defined in [RFC5754]; macAlgorithm MUST be 218 HMAC-SHA256 when the keyGenAlgorithm is id-sha256, and MUST 219 be HMAC-SHA384 when the keyGenAlgorithm is id-sha384, as 220 defined in [RFC4231]. 222 o signatureAlgorithm MUST be ecdsa-with-sha256 for P-256 223 certificate requests, and MUST be ecdsa-with-sha384 for P-384 224 certificate requests; 226 o signature MUST be generated using the private key 227 corresponding to the public key in the 228 CertificationRequestInfo, for both signature and key 229 establishment certificate requests. The signature provides 230 proof-of-possession of the private key to the Certification 231 Authority. 233 4.2. Certificate Request Message 235 The reqSequence crm choice conveys Certificate Request Message Format 236 (CRMF) [RFC4211] syntax. The CertReqMsg MUST comply with [RFC5272] 237 Section 3.2.1.2.2 with the following additional requirements: 239 o popo MUST be included using the signature (POPOSigningKey) proof- 240 of-possession choice and set as defined in [RFC4211] section 4.1 241 for both signature and key establishment certification requests. 242 The POPOSigningKey poposkInput field MUST be omitted. The 243 POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha256 for 244 P-256 certificate requests, and MUST be ecdsa-with-sha384 for 245 P-384 certificate requests. The signature MUST be generated 246 using the private key corresponding to the public key in the 247 CertTemplate. 249 The CertTemplate MUST comply with [RFC5272] Section 3.2.1.2.2 with 250 the following additional requirements: 252 o version MAY be included and, if included, it MUST be set to 2 as 253 defined in paragraph 4.3 of [RFC5759]; 255 o publicKey MUST be set as defined in 4.4 of [RFC5759]; 257 o extensions: 259 o The Key Usage extension MUST be included and it MUST be set as 260 defined in [RFC5759]. 262 o For rekey requests, the SubjectAltName extension MUST be 263 included and set equal to the SubjectAltName of the 264 certificate which is being used to sign the SignedData 265 encapsulating the request (i.e., not the certificate being re- 266 keyed) if the Subject field of the certificate being used to 267 generate the signature is NULL. 269 o Other extension requests MAY be included as desired. 271 o controls: 273 o The ChangeSubjectName attribute, as defined in [CMCbis], MUST 274 be included if the Full PKI Request encapsulating this Tagged 275 Certificate Request is being signed by a key for which a 276 certificate currently exists and the existing certificate's 277 Subject or SubjectAltName does not match the desired Subject 278 or SubjectAltName of this certificate request. 280 o The POP Link Witness Version 2 attribute MUST be included if 281 the request is being authenticated using a shared secret, and 282 the Subject in the certificate request is NULL or otherwise 283 does not uniquely identify the end-entity. In POP Link Witness 284 Version 2 attribute, keyGenAlgorithm MUST be id-sha256 or id- 285 sha384 for P-256 certificate requests and MUST be id-sha384 286 for P-384 certificate requests; macAlgorithm MUST be HMAC- 287 SHA256 when keyGenAlgorithm is id-sha256 and MUST be 288 HMAC-SHA384 when keyGenAlgorithm is id-sha384. 290 5. RA Requirements 292 This section addresses the optional case where one or more RAs act as 293 intermediaries between the client and CA as described in Section 7 of 294 [RFC5272]. In this section, the term "client" refers to the entity 295 from which the RA received the PKI Request. This section is only 296 applicable to RAs. 298 5.1. RA Processing of Requests 300 RAs conforming to this document MUST ensure that only the permitted 301 signature, hash, and MAC algorithms described throughout this profile 302 are used in requests; if they are not, the CA MUST reject those 303 requests. The RA SHOULD return a CMCFailInfo with the value of 304 badAlg [RFC5272]. 306 When processing end-entity generated SignedData objects, RAs MUST NOT 307 perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) 308 certificate extension [CCC] processing. 310 Other RA processing is as in [RFC5272]. 312 5.2. RA-Generated PKI Requests 314 If the RA encapsulates the client-generated PKI Request in a new 315 RA-signed PKI Request, it MUST create a Full PKI Request encapsulated 316 in a SignedData and the SignedData MUST be constructed as defined in 317 [RFC5008]. The PKIData content type complies with [RFC5272] with the 318 following additional requirements: 320 o controlSequence MUST be present. It MUST include the following 321 CMC controls: Transaction ID, Sender Nonce, and Batch Requests. 322 Other appropriate CMC controls MAY be included. 324 o cmsSequence MUST be present. It contains the original, 325 unmodified request(s) received from the client. 327 RA certificates are authorized to sign Full PKI Requests either with 328 an Extended Key Usage (EKU) and/or with the CCC certificate extension 329 [CCC]. Certificates may also be authorized through local 330 configuration. Authorized Certificates SHOULD include the id-kp- 331 cmcRA Extended Key Usage (EKU) from [CMCbis]. Authorized 332 certificates MAY also include the CCC certificate extension [CCC] or 333 authorized certificate MAY just include the CCC certificate 334 extension. If the RA is authorized via the CCC extension, then the 335 CCC extension MUST include the object identifier for the PKIData 336 content type. CCC SHOULD be included if constraints are to be placed 337 on the content types generated. 339 If the RA-signed PKI Request contains a certification request for a 340 P-256 public key, then the SignedData MUST be generated using either 341 SHA-256 and ECDSA with P-256 or SHA-384 and ECDSA with P-384. If the 342 request contains a certification request for a P-384 public key, then 343 the SignedData MUST be generated using SHA-384 and ECDSA with P-384. 344 If the RA-signed PKI Request contains requests for certificates on 345 the P-256 and P-384 curve, then the SignedData MUST be generated 346 using SHA-384 and ECDSA with P-384. If the Full PKI Response is a 347 successful response to a PKI Request that only contained a Get 348 Certificate or Get CRL control, then the SignedData MUST be signed by 349 either SHA-256 and ECDSA with P-256 or SHA-384 and ECDSA with P-384. 351 5.3. RA-Generated Errors 353 RA certificates authorized with the CCC certificate extension [CCC] 354 MUST include the object identifier for the PKIResponse content type 355 to authorize them to generate responses. 357 6. CA Requirements 359 This section specifies the requirements for CAs that receive PKI 360 Requests and that generate PKI Responses. 362 6.1. CA Processing of PKI Requests 364 CAs conforming to this document MUST ensure that only the permitted 365 signature, hash, and MAC algorithms described throughout this profile 366 are used in requests; if they are not, the CA MUST reject those 367 requests. The CA SHOULD return a CMCStatusInfoV2 control with 368 CMCStatus of failed and a CMCFailInfo with the value of badAlg 369 [RFC5272]. 371 For requests involving an RA, the CA MUST verify the RA's 372 authorization. The following certificate fields MUST NOT be 373 modifiable using the Modify Certification Request control: publicKey 374 and the key usage extension. The request MUST be rejected if an 375 attempt to modify those certificate request fields is present. The 376 CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed 377 and a CMCFailInfo with a value of badRequest. 379 When processing end-entity generated SignedData objects, RAs MUST NOT 380 perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) 381 certificate extension [CCC] processing. 383 If the client-generated PKI Request includes a ChangeSubjectName 384 attribute either in the CertRequest controls field for a CRMF request 385 or in the tcr attributes field for a PKCS#10 request, then the CA 386 MUST ensure that name change is authorized. The mechanism for 387 ensuring that the name change is authorized is out-of-scope. If the 388 CA performs this check, and the name change is not authorized, then 389 the CA MUST reject the PKI Request. The CA SHOULD return a 390 CMCStatusInfoV2 control with CMCStatus of failed. 392 Other processing of PKIRequests is as in [RFC5272]. 394 6.2. CA-Generated PKI Responses 396 If a Full PKI Response is returned; it MUST be encapsulated in a 397 SignedData; and the SignedData MUST be constructed as defined in 398 [RFC5008]. 400 If the PKI Response is in response to an RA-encapsulated PKI Request, 401 then the above PKI Response is encapsulated in another CA-generated 402 PKI Response. That PKI Response MUST be encapsulated in a SignedData 403 and the SignedData MUST be constructed as defined in [RFC5008]. The 404 above PKI Response is placed in the encapsulating PKI Response 405 cmsSequence field. The other fields are as above with the addition of 406 the batch response control in controlSequence. The following 407 illustrates a successful CA response to an RA-encapsulated PKI 408 Request both of which include Transaction IDs and Nonces: 410 SignedData (applied by the CA) 411 PKIData 412 controlSequence (Transaction ID, Sender Nonce, Recipient 413 Nonce, Batch Response) 414 cmsSequence 415 SignedData (applied by CA and includes returned 416 certificates) 417 PKIData 418 controlSequence (Transaction ID, Sender Nonce, 419 Recipient Nonce) 421 The same private key used to sign certificates MUST NOT be used to 422 sign Full PKI Response messages. Instead, a separate certificate 423 authorized to sign CMC responses MUST be used. Certificates are 424 authorized to sign Full PKI Responses with an Extended Key Usage 425 (EKU) and/or with the Cryptographic Message Syntax (CMS) Content 426 Constraints (CCC) certificate extension [CCC]. Certificates may also 427 be authorized through local configuration. Authorized Certificates 428 SHOULD include the id-kp-cmcCA EKU from [CMCbis]. Authorized 429 certificates MAY also include the CCC certificate extension [CCC] or 430 authorized certificate MAY just include the CCC certificate 431 extension. If the CA is authorized via the CCC extension, then the 432 CCC extension MUST include the object identifier for the PKIResponse 433 content type. CCC SHOULD be included if constraints are to be placed 434 on the content types generated. 436 The signature on the SignedData MUST be generated using either ECDSA 437 P-256 with SHA-256 or ECDSA P-384 with SHA-384. If the Full PKI 438 Response is a successful response to a P-256 public key certificate 439 request, then the SignedData MUST be generated using either SHA-256 440 and ECDSA with P-256 or SHA-384 and ECDSA with P-384. If the Full 441 PKI Response is a successful response to a P-384 public key 442 certificate request, then the SignedData MUST be generated using SHA- 443 384 and ECDSA with P-384. If the Full PKI Response is a successful 444 response to certificate requests on both the P-256 and P-356 curves, 445 then the SignedData MUST be generated using SHA-384 and ECDSA with P- 446 384. If the Full PKI Response is an unsuccessful response to a PKI 447 Request, then the SignedData MUST be signed by either SHA-256 and 448 ECDSA with P-256 or SHA-384 and ECDSA with P-384. If the Full PKI 449 Response is an unsuccessful response to certificate requests on both 450 the P-256 and P-356 curves, then the SignedData MUST be generated 451 using SHA-384 and ECDSA with P-384. If the Full PKI Response is a 452 successful response to a PKI Request that only contained a Get 453 Certificate or Get CRL control, then the SignedData MUST be signed by 454 either SHA-256 and ECDSA with P-256 or SHA-384 and ECDSA with P-384. 456 If the PKI Response is in response to an RA-encapsulated PKI Request, 457 the signature algorithm for each SignedData is selected 458 independently. 460 7. Client Requirements: Processing PKI Responses 462 Clients conforming to this document MUST ensure that only the 463 permitted signature, hash, and MAC algorithms described throughout 464 this profile are used in responses; if they are not, the client MUST 465 reject those responses. 467 Clients MUST authenticate all Full PKI Responses. This includes 468 verifying that the PKI Response is signed by an authorized CA or RA 469 whose certificate validates back to a trust anchor. The authorized 470 CA certificate MUST include the id-kp-cmcCA EKU and/or include a CCC 471 extension that includes the object identifier for the PKIResponse 472 content type. Or, the CA is determined to be authorized to sign 473 responses through an implementation-specific mechanism. The PKI 474 Response can be signed by an RA if it is an error message, if it a 475 response to a Get Certificate or Get CRL request, or if the PKI 476 Response contains an inner PKI Response signed by a CA. In the later 477 case, each layer of PKI Response MUST still contain an authorized, 478 valid signature signed by an entity with a valid certificate that 479 verifies back to an acceptable trust anchor. The authorized RA 480 certificate MUST include the id-kp-cmcRA EKU and/or include a CCC 481 extension that includes the object identifier for the PKIResponse 482 content type. Or, the RA is determined to be authorized to sign 483 responses through an implementation-specific mechanism. 485 When a newly issued certificate is included in the PKI Response, the 486 client MUST verify that the newly issued certificate's public key 487 matches the public key that the client requested. The client MUST 488 also ensure that the certificate's signature is valid and that the 489 signature validates back to an acceptable trust anchor. 491 Clients MUST reject PKI Responses that do not pass these tests. 492 Local policy will determine whether the client returns a Full PKI 493 Response with an Extended CMC Status Info control with CMCStatus set 494 to failed to a user console, error log, or the server. 496 If the Full PKI Response contains an Extended Status Info with a 497 CMCStatus set to failed, then local policy will determine whether the 498 client resends a duplicate certificate request back to the server or 499 whether an error state is returned to a console or error log. 501 8. Shared Secrets 503 When the Identity Proof V2 and POP Link Witness V2 controls are used, 504 the shared-secret MUST be randomly generated and securely 505 distributed. The shared-secret MUST provide at least 128 bits of 506 strength for P-256 certificate requests and at least 192 bits of 507 strength for P-384 certificate requests. 509 9. Security Considerations 511 Protocol security considerations are found in [RFC2986], [RFC4211], 512 [RFC5008], [RFC5272], [RFC5273], [RFC5274], [RFC5759], and [CMCbis]. 513 When CCC is used to authorize RA and CA certificates, then the 514 security considerations in [CCC] also apply. Algorithm security 515 considerations are found in [RFC5008]. 517 Compliant with NIST Special Publication 800-57 [SP80057], this 518 profile defines proof-of-possession of a key establishment private 519 key by performing a digital signature. Except for one-time proof-of- 520 possession, a single key pair MUST NOT be used for both signature and 521 key establishment. 523 This specification requires implementations to generate key pairs and 524 other random values. The use of inadequate pseudo-random number 525 generators (PRNGs) can result in little or no security. The 526 generation of quality random numbers is difficult. NIST Special 527 Publication 800-90 [SP80090], FIPS 186-3 [DSS], and [RFC4086] offer 528 random number generation guidance. 530 When RAs are used, the list of authorized RAs must be securely 531 distributed out-of-band to CAs. 533 Presence of the POP Link Witness Version 2 and POP Link Random 534 attributes protect against substitution attacks. 536 The Certificate Policy for a particular environment will specify 537 whether expired certificates can be used to sign certificate 538 requests. 540 10. IANA Considerations 542 None: All identifiers are already registered. Please remove this 543 section prior to publication as an RFC. 545 11. References 547 11.1. Normative References 549 [CCC] Housley, R., Wallace, C., and S. Ashmore, "Cryptographic 550 Message Syntax (CMS) Content Constraints X.509 551 Certificate Extension", draft-housley-cms-content- 552 constraints-extn-06, work-in-progress. 554 [CMCbis] Schaad, J., "Certificate Management over CMS (CMC) 555 Updates", draft-ietf-pkix-rfc5272-bis-00.txt, work-in- 556 progress. 558 [DSS] National Institute of Standards and Technology (NIST), 559 FIPS 186-3: Digital Signature Standard (DSS), June 2009. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", RFC 2119, BCP 14, March 1997. 564 [RFC2986] Kaliski, B., "PKCS #10: Certification Request Syntax 565 v1.5", RFC 2986, November 2000. 567 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 568 "Randomness Requirements for Security", BCP 106, RFC 569 4086, June 2005. 571 [RFC4211] J. Schaad, "Internet X.509 Public Key Infrastructure 572 Certificate Request Message Format (CRMF)", RFC 4211, 573 September 2005. 575 [RFC4231] M. Nystrom, "Identifiers and Test Vectors for HMAC-SHA- 576 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 577 4231, December 2005. 579 [RFC5008] Solinas, J. and R. Housley, "Suite B in 580 Secure/Multipurpose Internet Mail Extensions (S/MIME)", 581 RFC 5008, September 2007. 583 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 584 (CMC)", RFC 5272, June 2008. 586 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 587 (CMC): Transport Protocols", RFC 5273, June 2008. 589 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 590 over CMS (CMC): Compliance Requirements", RFC 5274, June 591 2008. 593 [RFC5754] S. Turner, "Using SHA2 Algorithms with CMS", RFC 5754, 594 January 2010. 596 [RFC5759] Solinas, J., and L. Zieglar, "Suite B Certificate and 597 Certificate Revocation List (CRL) Profile", RFC5759, 598 January 2010. 600 11.2. Informative References 602 [SP80057] National Institute of Standards and Technology (NIST), 603 Special Publication 800-57 Part 1: Recommendation for Key 604 Management, March 2007. 606 [SP80090] National Institute of Standards and Technology (NIST), 607 Special Publication 800-90: Recommendation for Random 608 Number Generation Using Deterministic Random Number Bits 609 Generators (Revised), March 2007. 611 Appendix A. Scenarios 613 This section illustrates several potential certificate enrollment and 614 rekey scenarios supported by this profile. This section does not 615 intend to place any limits or restrictions on the use of CMC. 617 A.1. Initial Enrollment 619 This section describes three scenarios for authenticating initial 620 enrollment requests: 622 1. Previously installed signature certificate (e.g., Manufacturer 623 Installed Certificate); 625 2. Shared secret distributed securely out-of-band; 627 3. RA authentication. 629 A.1.1. Previously Installed Signature Certificate 631 In this scenario, the end-entity has had a signature certificate 632 installed by the cryptographic module manufacturer. As the 633 end-entity already has a signature certificate, it can be used to 634 authenticate a request for a new certificate. The end-entity signs 635 the Full PKI Request with the private key that corresponds to the 636 subject public key of a previously installed signature certificate. 637 The CA will recognize the authorization of the previously installed 638 certificate and issue an appropriate certificate to the end-entity. 640 A.1.2. Shared Secret Distributed Securely Out-of-Band 642 In this scenario, the CA distributes a shared secret out-of-band to 643 the end-entity that the end-entity uses to authenticate its 644 certificate request. The end-entity signs the Full PKI Request with 645 the private key for which the certification is being requested. The 646 end-entity includes the Identity Proof Version 2 control to 647 authenticate the request using the shared secret. The CA uses either 648 the Identification control or the Subject in the end-entity's 649 enclosed PKCS #10 or CRMF certification request message to identify 650 the request. The end-entity performs either the POP Link Witness 651 Version 2 mechanism as described in [RFC5272] section 6.3.1.1 or the 652 Shared-Subject/Subject DN Linking mechanism as described in [RFC5272] 653 section 6.3.2. The Subject in the enclosed PKCS #10 or CRMF 654 certificate request does not necessarily match the issued 655 certificate, as it may just be used to help identify the request (and 656 corresponding shared secret) to the CA. 658 A.1.3. RA Authentication 660 In this scenario, the end-entity does not automatically authenticate 661 its enrollment request to the CA, either because the end-entity has 662 nothing to authenticate the request with, or because organizational 663 policy requires RA involvement. The end-entity creates a Full PKI 664 Request and sends it to an RA. The RA verifies the authenticity of 665 the request, then, if approved, encapsulates and signs the request as 666 described in Section 5.2, forwarding the new request on to the CA. 667 The Subject in the PKCS #10 or CRMF certification request is not 668 required to match the issued certificate, it may just be used to help 669 identify the request to the RA and/or CA. 671 A.2. Rekey 673 There are two scenarios to support the rekey of certificates that are 674 already enrolled. One addresses the rekey of signature certificates 675 and the other addresses the rekey of key establishment certificates. 676 Typically, organizational policy will require certificates to be 677 currently valid to be rekeyed, and may require initial enrollment to 678 be repeated when rekey is not possible. However, some organizational 679 policies might allow a grace period during which an expired 680 certificate could be used to rekey. 682 A.2.1. Rekey of Signature Certificates 684 When a signature certificate is rekeyed, the PKCS #10 or CRMF 685 certification request message enclosed in the Full PKI Request will 686 include the same Subject as the current signature certificate. The 687 Full PKI Request will be signed by the current private key 688 corresponding to the current signature certificate. 690 A.2.2. Rekey of Key Establishment Certificates 692 When a key establishment certificate is rekeyed, the Full PKI Request 693 will generally be signed by the current private key corresponding to 694 the current signature certificate. If there is no current signature 695 certificate, one of the initial enrollment options in section A.1 may 696 be used. 698 Authors' Addresses 700 Michael Peck 701 National Security Agency 703 Email: mpeck@alumni.virginia.edu 705 Lydia Zieglar 706 National Information Assurance Research Laboratory 707 National Security Agency 709 Email: llziegl@tycho.ncsc.mil 711 Sean Turner 712 IECA, Inc. 713 3057 Nutley Street, Suite 106 714 Fairfax, VA 22031 715 USA 717 Email: turners@ieca.com