idnits 2.17.00 (12 Aug 2021) /tmp/idnits51830/draft-turner-cmc-serverkeygeneration-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 == Line 641 has weird spacing: '... for clarit...' == Line 1121 has weird spacing: '...rmation contr...' -- The document date (July 30, 2013) is 3216 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC57272' is mentioned on line 685, but not defined == Missing Reference: 'RFC5752' is mentioned on line 1074, but not defined == Missing Reference: 'RFC6042' is mentioned on line 1225, but not defined -- Looks like a reference, but probably isn't: '1' on line 1308 -- Looks like a reference, but probably isn't: '2' on line 1309 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended Status: Proposed Standard S. Turner 5 Expires: January 31, 2014 IECA 6 P. Timmel 7 National Security Agency 8 July 30, 2013 10 CMC (Certificate Management over Cryptographic Message Syntax) 11 Extensions: Server Key Generation 12 draft-turner-cmc-serverkeygeneration-00.txt 14 Abstract 16 This document defines a set of extensions to the Certificate 17 Management over Cryptographic Message Syntax (CMC) protocol that 18 addresses the desire to support server-side generation of keys. This 19 service is provided by the definition of additional control 20 statements within the CMC architecture. Additional CMC errors are 21 also defined. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 I-D CMC Extensions: Server Key Generation July 30, 2013 40 Copyright and License Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Protocol Flows for Supported Scenarios . . . . . . . . . . . . 5 61 2.1. Shared Secret for Authentication and Key Protection . . . 7 62 2.2 Shared Secret for Authentication and Ephemeral Key for 63 Protection . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.3. Certificate for Authentication and Ephemeral Key for 65 Protection . . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.4. Certificate for Authentication and Key Protection . . . . . 12 67 2.4.1. Same Certificate for Authentication and Key 68 Protection . . . . . . . . . . . . . . . . . . . . . . 12 69 2.4.2. Different Certificates for Authentication and Key 70 Protection . . . . . . . . . . . . . . . . . . . . . . 12 71 2.5. RA Scenarios . . . . . . . . . . . . . . . . . . . . . . . 12 72 2.5.1. RA-Generated Key Scenarios . . . . . . . . . . . . . . 14 73 2.5.2. RA-Involved Scenarios . . . . . . . . . . . . . . . . 17 74 3. Generating PKIData and PKIResponse . . . . . . . . . . . . . . 18 75 3.1. Client Requests . . . . . . . . . . . . . . . . . . . . . 19 76 3.2. RA Processing of Client Requests . . . . . . . . . . . . . 19 77 3.3. CA Processing . . . . . . . . . . . . . . . . . . . . . . 21 78 3.4. RA Processing of CA Responses . . . . . . . . . . . . . . 23 79 3.4. Client Processing of Responses . . . . . . . . . . . . . . 25 80 4. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 25 81 4.1. Shroud With a Public Key . . . . . . . . . . . . . . . . . 26 82 4.2. Shroud With a Shared-Secret Key . . . . . . . . . . . . . . 27 83 5. Returned Key Format . . . . . . . . . . . . . . . . . . . . . . 28 84 6. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 29 85 6.1. Server-Side Key Generation Request Attribute . . . . . . . 29 86 6.2. Server-side Key Generation Response . . . . . . . . . . . . 31 87 7. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 32 89 I-D CMC Extensions: Server Key Generation July 30, 2013 91 8. Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . 33 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 11.1 Normative References . . . . . . . . . . . . . . . . . . . 35 96 12.2 Informative References . . . . . . . . . . . . . . . . . . 36 97 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 37 98 Appendix B. Additional Message Flows . . . . . . . . . . . . . . . 37 99 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 41 100 B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 41 101 B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 41 102 B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 41 103 B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 41 104 B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 41 105 B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 41 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 108 1 Introduction 110 This document defines a set of extensions to and errors for 111 Certificate Management over Cryptographic Message Syntax (CMC) 112 [RFC5272] that allows for server-side generation of key material. 113 There are strong reasons for providing this service: 115 o Clients may have poor, unknown, or non-existent key generation 116 capabilities. The creation of private keys relies on the use of 117 good key generation algorithms and a robust random number 118 generator. Server key generation can use specialized hardware 119 that may not always be available on clients. 121 o Central storage of keys may be desired in some environments to 122 permit key recovery. This document only addresses a request to 123 archive server-generated keys; archival of locally generated keys 124 and the control to retrieve archived keys is out-of-scope. 126 o Server key generation may be useful for provisioning keys to 127 disconnected clients (e.g., clients that receive keys from a fill 128 device [RFC4949] because the clients are not able to connect to 129 the server due to an air gap). 131 These extensions to the CMC protocol are designed to provide server 132 key generation without adding any additional round trips to the 133 enrollment process; however, additional round trips may be required 134 based on the mechanism chosen to protect the returned key. 136 Section 2 describes the enrollment scenarios supported. Section 3 137 provides CMC requirements. Sections 4 and 5 describe the concepts and 139 I-D CMC Extensions: Server Key Generation July 30, 2013 141 structures used in transporting private keys between the server and 142 client applications. Section 6 describes the structure and processes 143 for server-side key generation. Section 7 describes additional CMC 144 error codes. Section 8 describes additional exchanges when the 145 server requires the client provide Proof-of-Possession (POP). 146 Appendix A provides the ASN.1 module for the CMC controls and errors. 147 Appendix B provides example encodings. 149 1.1. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in RFC 154 2119 [RFC2119]. 156 The terminology in [RFC5272] and in [RFC6402] apply to this profile. 157 Additionally, familiarity with CMS's (Cryptographic Message Syntax) 158 SignedData, AuthenticatedData, and EnvelopedData content types is 159 assumed [rfc5652]. 161 1.2. Definitions 163 This section defines some of the terms that are used in this 164 document: 166 o Dual-use: Applies to certificates or keys. Certificates that can 167 be used to verify both digital signatures and to perform key 168 management, when the Key Usage extension is set to 169 digitalSignature and either keyAgreement or keyEncipherment, and 170 keys whose intended use is digitalSignature and either 171 keyAgreement or keyEncipherment. 173 o Encryption-capable: Applies to certificates or keys. 174 Certificates that can be used for key management (i.e., the Key 175 Usage extension includes keyAgreement or keyEncipherment) and 176 keys that can be used for key management. This refers to either 177 dual-use or encryption-only certificates/keys. 179 o Encryption-only: Applies to certificates or keys. Certificates 180 that can only be used for key management, when the Key Usage 181 extension is set to either keyAgreement or keyEncipherment, and 182 keys whose only intended use is keyAgreement or keyEncipherment. 184 o Ephemeral key [SP-800-57]: A cryptographic key that is generated 185 for each execution of a key establishment process and that meets 186 other requirements of the key type (e.g., unique to each message 187 or session). Often, ephemeral keys are linked to key agreement 188 algorithms; however, this document uses the term ephemeral keys 190 I-D CMC Extensions: Server Key Generation July 30, 2013 192 to apply to both key transport and key agreement keys. The 193 ephemeral key has two parts: the private part and the public 194 part. The client provides the public part to the server to allow 195 the server to protect the server-generated keys. Note that an 196 ephemeral key has a security advantage by being unique to the 197 session; it SHOULD be freshly generated when possible, but MAY be 198 pre-placed when local key generation is of poor or unknown 199 quality (see Section 9). An ephemeral key is innately 200 unauthenticated, and so must be carried in a suitably 201 authenticated protocol. 203 o Identification: A generic term for a process by which a name, 204 generally assigned by a server, is used to match a request 205 against a known entity. Identification can be either 206 authenticated (a subject name in a certificate) or 207 unauthenticated (a text string). 209 o Shared Secret: A value known to two or more entities in advance 210 of a protocol session in which it will be used, and intended to 211 be unknown to any others. In this document, the value must be a 212 suitable basis for derivation of a MAC (Message Authentication 213 Code) or encryption key. Pass phrases that are used as a shared 214 secret must be treated as confidential by the holders of the 215 secret. 217 o Shrouding: A generic term to cover methods of masking the content 218 of an object from unauthorized viewers. The most common method 219 of shrouding used is encryption of the data at the application 220 layer. This document defines two shroud methods that employ 221 encryption at the application layer but other shrouding methods 222 can be defined that don't employ encryption at the application 223 layer. 225 o Signature-capable: Applies to certificates or keys. Certificates 226 that can be used to verify signatures and keys that can be used 227 to generate digital signatures. This refers to either dual-use 228 or signature-only certificates/keys. 230 o Signature-only: Applies to certificate or keys. Certificates 231 that can only be used to verify digital signatures, when the Key 232 Usage extension is set to digitalSignature, and keys whose only 233 intended key usage is digital signature. 235 2. Protocol Flows for Supported Scenarios 237 This section describes five scenarios, and specifies the CMC requests 238 and responses to support them: 240 I-D CMC Extensions: Server Key Generation July 30, 2013 242 1. In the first scenario (see Section 2.1), clients use a shared 243 secret (e.g., password) (see Section 1.2) to provide 244 authentication and request that the server use the same shared 245 secret to encrypt the server-generated keys. Obviously the 246 security in this scenario, and any scenario in which a shared 247 secret is used, is predicated on keeping the shared secret 248 secret. Here, the client need only know a shared secret to 249 request a certificate, but the client needs to maintain secrecy 250 of the shared secret, which is often difficult for clients, for 251 the lifetime of the key (see Section 9). Further, using the same 252 secret for authentication and encryption potentially increases 253 exposure of the server-generated private key among the entities 254 comprising the RA and CA. Note that the use of split-shared 255 secret (i.e., one for authentication and one for encryption) 256 would alleviate the last concern, but this is beyond the scope of 257 this document. 259 2. In the second scenario (see Section 2.2), clients use a shared 260 secret to provide authentication and request that the server use 261 an ephemeral key (see Section 1.2) to encrypt the server- 262 generated keys. Here, the client can still use their shared 263 secret to request the certificate but now once encrypted the 264 private key can only become known to the client. Also, the key 265 that protects the response is ephemeral even if the 266 authentication shared secret is not. 268 3. In the third scenario (see Section 2.3), clients use a 269 certificate to support digital signature authentication and 270 request that the server use an ephemeral key to encrypt the 271 server-generated keys. Here, the primary motivation is that use 272 of the ephemeral key mitigates the risk of compromise of a pre- 273 existing certificate and key while in the supply chain (see 274 Section 9). 276 4. In the fourth scenario (see Section 2.4), clients use a 277 certificate to support digital signature authentication and 278 request that the server use a certificate to encrypt the server- 279 generated keys. Here, clients can request a certificate with a 280 certificate or certificates that the client already has. There 281 are still security requirements for protecting the private key(s) 282 associated with the certificate(s) (see Section 9). If two 283 certificates are used (i.e., one for encryption and one for 284 digital signatures), the separation between signing and key 285 exchange functions is preserved, and supports a broader range of 286 algorithms. Some additional details: 288 o If the client's authentication certificate is signature-only, 289 then the client also needs an encryption-capable certificate 291 I-D CMC Extensions: Server Key Generation July 30, 2013 293 (i.e. having the Key Usage extension set to either keyAgreement 294 or keyEncipherment) that the server will use to protect the 295 private key. 297 o If the client's certificate is dual-use, then the client only 298 needs the one certified key pair to generate the SignedData 299 that encapsulates the certificate request and to decrypt the 300 EnvelopedData that encapsulates the server-generated key. 302 5. The first four scenarios assume that the keys are generated at 303 the Certification Authority (CA) and that the interactions do not 304 involve a Registration Authority (RA) [RFC5280]. But, key 305 generation by an RA is also supported as well as scenarios when 306 the RA verifies the client's identity (see Section 2.5). 308 Note that there is no scenario where the response is protected with a 309 key/certificate that only supports digital signatures. This is 310 because the "protection" afforded by digital signatures alone does 311 not include confidentiality, which is required to ensure that the 312 server-generated private key is only disclosed to the client. 314 Note also that there is also no scenario where the client uses an 315 encryption-only certificate and is unable to generate a digital 316 signature to provide authentication. This is because the 317 "protection" afforded by encryption-only certificates does not 318 include authentication. Technically, there are dual-service 319 algorithms that support both authentication and encryption but their 320 use is beyond the scope of this document. 322 In all of the scenarios, the client can validate that the response 323 came from the CA or RA by validating the digital signature on the 324 SignedData to a Trust Anchor (TA). After the EnvelopedData is 325 decrypted, the client can 1) verify that the private key is 326 associated with the public key in the returned certificate and/or 2) 327 verify that the certificate validates back to an authorized TA. 329 The scenarios in the subsections assume that the transaction 330 identifier and nonce controls are used for transaction processing and 331 replay protection, respectively, but they are optional, as specified 332 in [RFC5272]. Also, the scenarios assume the CMC Status Information 333 v2 control is not included when the response is a success, as allowed 334 by [RFC5272]. See Appendix B for additional example scenarios. 336 2.1. Shared Secret for Authentication and Key Protection 338 The shared secret allows the server to authenticate the client and 339 allows the server to encrypt the server-side generated key for the 340 client. The shared secret is distributed via an out-of-band 342 I-D CMC Extensions: Server Key Generation July 30, 2013 344 mechanism that is out-of-scope of this document. Also note the 345 server and client need to share a non-secret identification string 346 that the client can assert in a request so that the server will know 347 which shared secret is being used. 349 When the client generates their request, the client includes the 350 following control attributes in a PKIData content type [RFC5272]: 351 Server Key Generation Request (see Section 6.1), Transaction 352 Identifier [RFC5272], Sender Nonce [RFC5272], and Identification 353 [RFC5272]. The Server Key Generation Request control indicates that 354 the shroudMethod is shroud with shared-secret key (see Section 4.2). 355 The PKIData is encapsulated in a CMS AuthenticatedData content type 356 and the password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. 357 Note that reqSequence, cmsSequence, and otherMsgSequence are not 358 included in the PKIData for the server-side key generation request. 359 The following depicts this: 361 +----------------------------------------------------------------+ 362 |AuthenticatedData: ReceipientInfo: pwri | 363 |+--------------------------------------------------------------|| 364 ||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)|| 365 || control: TransationID || 366 || control: SenderNonce || 367 || control: Identification || 368 |+--------------------------------------------------------------+| 369 +----------------------------------------------------------------+ 371 After the server authenticates the client, the server generates a 372 response that includes the server-generated key and any associated 373 parameters in an Asymmetric Key Package content type [RFC5958]. The 374 Asymmetric Key Package is then encapsulated within a SignedData and 375 that is further encapsulated within an EnvelopedData using the 376 password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData is 377 then placed in a PKIResponse cmsSequence [RFC5272] and the following 378 controls are included in the PKIResponse: Transaction Identifier, 379 Sender Nonce, Recipient Nonce [RFC5272], and Server Key Generation 380 Response (see Section 4.2). The PKIResponse is then encapsulated in 381 a SignedData and the certificate associated with the server-generated 382 key is placed in the outer-most SignedData's certificate field 383 [RFC5652]. The following depicts this: 385 +---------------------------------------------------------+ 386 |SignedData: Signed by the CA | 387 | Client's certificate found here | 388 |+-------------------------------------------------------+| 389 ||PKIResponse: control: TransactionID || 390 || control: SenderNonce || 391 || control: RecipientNonce || 393 I-D CMC Extensions: Server Key Generation July 30, 2013 395 || control: ServerKeyGenResponse || 396 || || 397 || cmsSequence: || 398 || +----------------------------------------+|| 399 || |EnvelopedData: RecipientInfo: pwri ||| 400 || |+----------------------+ ||| 401 || ||SignedData | ||| 402 || ||+--------------------+| ||| 403 || |||AsymmetricKeyPackage|| ||| 404 || ||+--------------------+| ||| 405 || |+----------------------+ ||| 406 || +----------------------------------------+|| 407 |+-------------------------------------------------------+| 408 +---------------------------------------------------------+ 410 2.2 Shared Secret for Authentication and Ephemeral Key for Protection 412 The shared secret allows the server to authenticate the client and 413 the ephemeral key allows the server to use a different key to encrypt 414 the server-side generated key for the client. The shared secret is 415 distributed via an out-of-band mechanism that is out-of-scope of this 416 document. Also note that the client needs an identification string 417 to allow the server to determine which shared secret is being used. 419 When the client provides an ephemeral key to protect the response, 420 the client includes the following control attributes in a PKIData 421 content type [RFC5272]: Server Key Generation Request control (see 422 Section 6.1), Transaction Identifier [RFC5272], Sender Nonce 423 [RFC5272], and Identification [RFC5272]. The Server Key Generation 424 Request control indicates that the shroudMethod is shroud with public 425 key and that the bareKey CHOICE is used (see Section 4.1). The 426 PKIData is encapsulated in an AuthenticatedData content type and the 427 password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note 428 that reqSequence, cmsSequence, or otherMsgSequence are not included. 429 The following depicts this: 431 +-------------------------------------------------------------+ 432 |AuthenticatedData: ReceipientInfo: pwri | 433 |+-----------------------------------------------------------+| 434 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)|| 435 || control: TransationID || 436 || control: SenderNonce || 437 || control: Identification || 438 |+-----------------------------------------------------------+| 439 +-------------------------------------------------------------+ 441 After the server has authenticated the client, the server returns the 442 server-generated key and any associated parameters in an Asymmetric 444 I-D CMC Extensions: Server Key Generation July 30, 2013 446 Key Package content type [RFC5958]. The Asymmetric Key Package is 447 then encapsulated within a SignedData and that is encapsulated within 448 an EnvelopedData using the key agreement or key transport 449 RecipientInfo (i.e., kari or ktri CHOICE). The EnvelopedData is then 450 placed in a PKIResponse cmsSequence [RFC5272] and the following 451 controls are included: Transaction Identifier, Sender Nonce, 452 Recipient Nonce [RFC5272], and Server Key Generation Response (see 453 Section 6.2). The PKIResponse is then encapsulated in a SignedData 454 and the certificate associated with the server-generated key is 455 placed in the outer-most SignedData's certificate field [RFC5652]. 456 The following depicts this: 458 +-----------------------------------------------------------+ 459 |SignedData: Signed by the CA | 460 | Client's certificate found here | 461 |+---------------------------------------------------------+| 462 ||PKIResponse: control: TransactionID || 463 || control: SenderNonce || 464 || control: RecipientNonce || 465 || control: ServerKeyGenResponse || 466 || || 467 || cmsSequence: || 468 || +------------------------------------------+|| 469 || |EncryptedData: RecipientInfo: kari or ktri||| 470 || |+----------------------+ ||| 471 || ||SignedData | ||| 472 || ||+--------------------+| ||| 473 || |||AsymmetricKeyPackage|| ||| 474 || ||+--------------------+| ||| 475 || |+----------------------+ ||| 476 || +------------------------------------------+|| 477 |+---------------------------------------------------------+| 478 +-----------------------------------------------------------+ 480 2.3. Certificate for Authentication and Ephemeral Key for Protection 482 This scenario differs from the scenarios in Sections 2.1 and 2.2 in 483 that the client encapsulates the PKIData in a SignedData instead of 484 an AuthenticatedData (i.e., the client uses its private key 485 associated with its signature-capable certificate to sign the 486 PKIData) but is similar to Section 2.2 for the response. As implied 487 in [RFC5272], clients omit the Identification and Identity Proof 488 controls when using certificates to support digital signature 489 authentication. A client requesting a certificate for a different 490 name includes the Change Subject Name attribute to ensure the server 491 will not reject the request because the name in the certificate used 492 to sign the request does not match the name in the request. 494 I-D CMC Extensions: Server Key Generation July 30, 2013 496 When the client generates their request, the client includes the 497 following control attributes in a PKIData content type [RFC5272]: 498 Server Key Generation Request (see Section 6.1), Transaction 499 Identifier [RFC5272], and Sender Nonce [RFC5272]. The Server Key 500 Generation Request control indicates the shroudMethod is shroud with 501 public key and the bareKey CHOICE is used (see Section 4.1). The 502 PKIData is encapsulated in a SignedData content type [RFC5652]. Note 503 that reqSequence, cmsSequence, and otherMsgSequence are not included 504 in the PKIData for the server-side key generation request. The 505 following depicts this: 507 +--------------------------------------------------------------+ 508 |SignedData: Signed by the Client | 509 |+------------------------------------------------------------|| 510 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) || 511 || control: TransationID || 512 || control: SenderNonce || 513 |+------------------------------------------------------------+| 514 +--------------------------------------------------------------+ 516 After the server has authenticated the client, the server returns the 517 server-generated key and any associated parameters in an 518 AsymmetricKeyPackage content type [RFC5958]. The 519 AsymmetricKeyPackage is then encapsulated within a SignedData and 520 that is encapsulated within an EnvelopedData using the key agreement 521 or key transport RecipientInfo (i.e., kari or ktri CHOICE). The 522 EnvelopedData is then placed in a PKIResponse cmsSequence [RFC5272] 523 and the following controls are included: Transaction Identifier, 524 Sender Nonce, Recipient Nonce [RFC5272], and Server Key Generation 525 Response (see Section 6.2). The PKIResponse is then encapsulated in 526 a SignedData and the certificate associated with the server-generated 527 key is placed in the outer-most SignedData's certificate field 528 [RFC5652]. The following depicts this: 530 +-----------------------------------------------------------+ 531 |SignedData: Signed by the CA | 532 | Client's certificate found here | 533 |+---------------------------------------------------------+| 534 ||PKIResponse: control: TransactionID || 535 || control: SenderNonce || 536 || control: RecipientNonce || 537 || control: ServerKeyGenResponse || 538 || || 539 || cmsSequence: || 540 || +------------------------------------------+|| 541 || |EnvelopedData: RecipientInfo: kari or ktri||| 542 || |+----------------------+ ||| 543 || ||SignedData | ||| 545 I-D CMC Extensions: Server Key Generation July 30, 2013 547 || ||+--------------------+| ||| 548 || |||AsymmetricKeyPackage|| ||| 549 || ||+--------------------+| ||| 550 || |+----------------------+ ||| 551 || +------------------------------------------+|| 552 |+---------------------------------------------------------+| 553 +-----------------------------------------------------------+ 555 2.4. Certificate for Authentication and Key Protection 557 If a client already has been issued a signature-capable certificate, 558 then it can use this certificate to authenticate the requests. If 559 the certificate also indicates support for encryption (i.e., the key 560 usage extension is set to keyEncipherment or keyAgreement), then the 561 client can request that the server use the same certificate to 562 protect the server-generated key (see Section 2.4.1). If the 563 certificate does not indicate support for encryption, then the client 564 can provide the server with another certificate to use to encrypt the 565 server-generated key (see Section 2.4.2). The certificate that 566 protects the server-generated key MUST be encryption-capable. 568 These scenarios differ from the scenarios in Section 2.3 in that the 569 response is protected with a previously certified key instead of an 570 ephemeral key. As specified in [RFC5272], clients omit the 571 Identification and Identity Proof controls when using certificates to 572 support digital signature authentication. A client requesting a 573 certificate for a different name includes the Change Subject Name 574 attribute to ensure the server will not reject the request because 575 the name in the certificate used to sign the request does not match 576 the name in the request. 578 2.4.1. Same Certificate for Authentication and Key Protection 580 This scenario is the same as in Section 2.3. except Server Key 581 Generation Request control includes the certificate CHOICE instead of 582 the bareKey CHOICE. 584 2.4.2. Different Certificates for Authentication and Key Protection 586 When the client's certificate that is used to sign the PKIData does 587 not support encryption but the client has another certificate that 588 does, the client can include this other certificate in the Server Key 589 Generation Request control's certificate field. When using two 590 certificates, the names in the two certificates MUST match to ensure 591 the CA will not reject the request due to name mismatches. 593 2.5. RA Scenarios 594 I-D CMC Extensions: Server Key Generation July 30, 2013 596 In Sections 2.1-2.4, client-to-CA protocol flows were illustrated 597 where the CA generates the client's key and no RA was involved. This 598 section illustrates client-to-RA-to-CA protocol flows. The scenarios 599 divide into two basic categories, according to whether the RA or the 600 CA generates the key pair. 602 When the RA generates the key on behalf of the client, the RA 603 effectively becomes a proxy for the client from the CA's perspective. 604 The protocol exchange between the RA and CA is identical to other 605 situations in which a client requests a certificate. This means that 606 the CA need not know about or support the Server Key Generation 607 Request and Server Key Generation Response controls. The PKIResponse 608 to the client now has to accommodate the fact that the asymmetric key 609 package is generated by the RA, whereas the certificate is generated 610 by the CA. This necessitates that the RA intercepts whatever 611 response the CA returns to get the client's certificate and that the 612 RA generates a signed response that includes the asymmetric key 613 package as well as the client's certificate. See section 9 for 614 security considerations. 616 When the RA participates in the process but does not generate the 617 key, there are two possibilities. If the RA does not contribute to 618 the protocol (its effects may be procedural or out-of-band), then it 619 can simply pass the messages it receives to the other party when 620 warranted. If that is not warranted, the RA would generate the usual 621 response for the associated failure. No message flow for this 622 possibility is included. Alternatively, the RA may be responsible 623 for processing certain aspects of the request, and needs to vouch for 624 that when forwarding the client request to the CA. The RA does this 625 per [RFC5272] by embedding the client request in a Full PKI Request 626 that it signs, containing controls for the processing that it 627 performs. Here as in Sections 2.1-2.4, the CA needs to fully 628 understand and support the Server Key Generation Request and Server 629 Key Generation Response controls, since the CA has to generate the 630 key and construct the asymmetric key package. 632 In the figures that follow, SKGReq is the Server Key Generation 633 Request control (see Section 6.1), the SKGRes denotes the Server Key 634 Generation Response control (see Section 6.2), TransactionId denotes 635 the Transaction Identifier control [RFC5272], SenderNonce denotes the 636 Sender Nonce control [RFC5272], RecipientNonce denotes the Recipient 637 Nonce control [RFC57272]. AKP denotes an Asymmetric Key Package 638 [RFC5958] (i.e., the private key). Also, {} denotes encryption 639 (i.e., EnvelopedData), <> denotes signatures (i.e., SignedData), with 640 () identifying some of the information in carried in unsignedAttrs 641 for clarity, and [] denotes authentication (i.e., SignedData or 642 AuthenticatedData). control denotes controlSequence, reqSeq denotes 643 requestSequence, and cmsSeq denotes cmsSequence. PKCS#10 [RFC2986] 645 I-D CMC Extensions: Server Key Generation July 30, 2013 647 and CRMF (Certificate Request Message Format) [RFC4211] are the 648 certification requests. 650 2.5.1. RA-Generated Key Scenarios 652 There are some differences in the protocol flows when an RA generates 653 the key: 655 o The RA MUST be issued a certificate from the CA. This means all 656 of the RA-generated PKIData are encapsulated in a SignedData. 657 Further, the RA's certificate can be used for identification and 658 linking identity and POP information. 660 o The RA generates the certification request for the client by: 662 * Using the name from the certificate for the key the RA will use 663 to sign the PKIData. 665 * Using the information from the client's request. 667 * The RA includes the Change Subject Name control [RFC6402] 668 either in the PKCS #10 or CRMF TaggedRequest because the POP 669 and identity linking CMC requirements are that the name in the 670 certificate used to sign the PKIData matches the name in the 671 certification request. The Change Subject Name attribute 672 allows the names to be different. 674 * Modifying the information as necessary. Notably adding the 675 public key but also adding certificate extensions, etc. Note 676 that the Modify Certificate Template control is not needed as 677 the RA is generating a new PKIData. 679 * Generating the POP information for the RA-generated keys. For 680 keys that support digital signatures, the RA includes the 681 POPSigningKey in the CRMF or the signature in the PKCS #10. 682 For encryption-only keys, the RA can indicate that it performed 683 POP by including the RA POP Witness control. Note the CA could 684 force the RA to prove it has possession of the key with the 685 encrypted/decrypted POP mechanism for [RFC57272], but this adds 686 additional round trips and is discussed later in this section. 688 * Signing the certification request (i.e., the PKIData) with the 689 RA's private key. 691 The RA can also generate bulk requests (i.e., include more than one 692 request in cmsSequence) with the Bulk Request control [RFC5272] but 693 these controls are not depicted in the following sections to simplify 694 the protocol flows. When the RA is requesting more than one key for 696 I-D CMC Extensions: Server Key Generation July 30, 2013 698 a given client, the RA includes each request in the reqSequence. 700 The following message flow applies when the RA generates the key. It 701 supports all of the previously defined choices for authentication and 702 shrouding. The diagram below depicts use of a shared secret for 703 authentication by including the Identification control and 704 encapsulating the client's PKIData in an AuthenticatedData. If a 705 digital signature is used for authentication, the Identification 706 control is omitted and the client encapsulates its PKIData in a 707 SignedData. 709 Client RA CA 710 | | | 711 |----------------->| | 712 | [PKIData | | 713 | control: SKGReq, | | 714 | TransactionID, | | 715 | SenderNonce, | | 716 | Identification] | | 717 | |-------------------------------------->| 718 | | | 721 | | (RA signed) | 722 | |<--------------------------------------| 723 | | 726 |<-----------------| (CA signed with issued client certificate) 727 | }> 730 | (RA signed PKIResponse with CA-issued client certificate) 732 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 734 NOTE: There's no need for the RA to provide the SKGReq or the {} 735 to the CA. The CA won't be able to access the contents of the 736 {} because it's encrypted for the client and the CA's response 737 is always returned to the RA because the RA needs to provide the 738 generated {} back to the client. 740 Whether the client's PKIData is encapsulated in a SignedData or 741 AuthenticatedData depends on whether the client used a certificate or 742 shared secret for authentication, respectively. Additionally, the 743 RecipientInfo for the EnvelopedData encapsulating the depends 744 on whether the key was protected with a shared secret (pwri), 745 ephemeral key (ktri or kari), or certificate (ktri or kari). 747 I-D CMC Extensions: Server Key Generation July 30, 2013 749 The RA intercepts the response from the CA; it strips the CA's 750 signature and creates a new PKIResponse for the client. The 751 controlSequence is comprised of the Transaction Identifier and 752 Recipient Nonce fields from the client's request, the RA's Sender 753 Nonce, and the Server Key Generation Response (see Section 6.2); the 754 cmsSequence includes the RA-generated {}; and the RA signs the 755 PKIRepsonse and includes the client's certificate, which was returned 756 in the CA's SignedData. 758 When the RA is generating an encryption-only key pair for the client, 759 and the CA wishes to force the RA to prove it has possession of the 760 private key, but the RA cannot use it to generate a one-time 761 signature, then the flow is as follows: 763 Client RA CA 764 | | | 765 |----------------->| | 766 | [PKIData | | 767 | control: SKGReq, | | 768 | TransactionID, | | 769 | SenderNonce, | | 770 | Identification] | | 771 | |--------------------------------------->| 772 | | | 776 | |<---------------------------------------| 777 | | | 781 | |--------------------------------------->| 782 | | | 785 | |<---------------------------------------| 786 | | 789 | }>> 793 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 795 NOTE: The number of round trips between the RA and CA in the above 796 figure is twice as many as the first figure in this Section and in 798 I-D CMC Extensions: Server Key Generation July 30, 2013 800 Section 2.5.1.1; however, the additional round trip is specified in 801 [RFC5272] (i.e., this document does not introduce the additional 802 round trip). The additional round trip is necessary when the CA 803 forces the RA to perform POP with the CA. While the additional round 804 trip might be problematic between the client and server, the quality 805 of communication connectivity between RA and CA should not make the 806 additional round trips as problematic as between clients and RAs or 807 CAs. 809 2.5.2. RA-Involved Scenarios 811 This section illustrates a message flow for when the CA generates the 812 client's key. Here too the RA MUST be issued a certificate from the 813 CA, which means that all of the RA-generated PKIData are encapsulated 814 in a SignedData. Further, the RA's certificate can be used for 815 identification and linking identity and POP information and the RA 816 can include the RA Identity Witness control to tell the CA that it 817 performed the client identity checks; the RA will omit the control if 818 it does not perform these checks. 820 The RA can include a Modify Certification Request control [RFC5272] 821 in the PKIData that encapsulates the client's request but these 822 controls are not shown below. The RA does this when it wishes to 823 modify the request present in the Server Key Generation Request 824 control. The RA MUST NOT use the RA POP Witness control if the CA is 825 to generate the key. This control indicates that the RA performed 826 POP, but the key for which POP is claimed has not yet been generated. 828 The diagram below depicts the client's use of a shared secret for 829 authentication by including the Identification control and 830 encapsulating the client's PKIData in an AuthenticatedData. If a 831 digital signature is used for authentication, the Identification 832 control is omitted and the client's PKIData is encapsulated in a 833 SignedData. The RA encapsulates the client's request in its PKIData 834 by placing the client request in the cmsSequence, and includes 835 controls such as Transaction Identifier and Sender Nonce controls as 836 well as RA Identity Witness control if the RA checks the client's 837 identity. 839 Client RA CA 840 | | | 841 |----------------->| | 842 | [PKIData | | 843 | control: SKGReq, | | 844 | TransactionID, | | 845 | SenderNonce, | | 846 | Identification] | | 847 | |--------------------------------------->| 849 I-D CMC Extensions: Server Key Generation July 30, 2013 851 | | | 857 | |<---------------------------------------| 858 | | } > 865 | | (CA signed with issued client certificate) 866 |<-----------------| > (CA signed) 867 | }> 870 | (CA signed with issued client certificate) 872 When the RA receives the request from the CA, it strips the CA's 873 response for the RA off and passes the inner response to the client 874 unchanged. The difference between this scenario and the scenarios in 875 Section 2.5.1 is that the signature on the PKIResponse is generated 876 by the CA not the RA. 878 Note that the additional round trips to prove possession of an 879 encryption-only key depicted in Section 2.5.1 are unnecessary here 880 because the CA generates the asymmetric key pair and it does not need 881 to prove to itself that it has the keys. 883 3. Generating PKIData and PKIResponse 885 [RFC5272] defines PKIData as follows (included here for convenience): 887 PKIData ::= SEQUENCE { 888 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 889 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 890 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 891 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 892 } 894 [RFC5272] defines PKIResponse as follows (included here for 895 convenience): 897 PKIResponse ::= SEQUENCE { 898 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 900 I-D CMC Extensions: Server Key Generation July 30, 2013 902 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 903 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 904 } 906 3.1. Client Requests 908 When the client generates their request, the Server Key Generation 909 Request control (see Section 6.1) is included in controlSequence; the 910 other sequences (i.e., reqSequence, cmsSequence, and 911 otherMsgSequence) are omitted. If a shared secret is used for 912 authentication, the Identification control [RFC5272] is included in 913 the controlSequence to ensure that the server can locate the shared- 914 secret needed to authenticate the request. Additional controls can 915 be included in controlSequence such as Sender Nonce and Transaction 916 Identifier [RFC5272]. The reqSequence, which is included for client- 917 generated key certification requests, is not needed as the Server Key 918 Generation Request control includes the certification request. The 919 client's request is either encapsulated in an AuthenticatedData or a 920 SignedData depending on whether the client is using a shared secret 921 or a digital signature key to authenticate the request. If the 922 client wishes to request a certificate with a different name than the 923 one that is present in the certificate that authenticates the 924 request, the client includes the Change Subject Name control 925 [RFC6402] to ensure the server will not reject the request because 926 the name in the certificate used to sign the request does not match 927 the name in the request. 929 3.2. RA Processing of Client Requests 931 If an RA is involved, then it can do the following: 933 o Forward the request as-is to the CA. This happens when the CA 934 authenticates the request, performs the Identity checks, and 935 generates the keys. 937 o Not authenticate the request and place one or more client PKIData 938 in cmsSequence; reqSequence and otherMsgSequence are omitted. 939 Here the RA does not have the shared secret necessary to 940 authenticate the request. The RA can also include additional 941 controls in controlSequence such as the Modify Certification 942 Request control if the RA needs to modify the client's request 943 and the Sender Nonce and Transaction Identifier controls for 944 replay protection and transaction processing. If the RA performs 945 the Identity checks it can include the RA Identity Witness 946 control. After generation of the PKIData, the RA encapsulates it 947 in a SignedData as part of the digital signature process. 949 I-D CMC Extensions: Server Key Generation July 30, 2013 951 o Authenticate the request and place one or more client PKIData in 952 cmsSequence; reqSequence and otherMsgSequence are omitted. The 953 RA can also include additional controls in controlSequence such 954 as the Modify Certification Request control if the RA needs to 955 modify the client's request in the Server Key Generation Request 956 control and Sender Nonce and Transaction Identifier for replay 957 protection and transaction control. If the RA also performs the 958 Identity check, it includes the Identity Proof Witness control 959 [RFC6402] otherwise it is omitted. After generation of the 960 PKIData, the RA encapsulates it in a SignedData as part of the 961 digital signature process. 963 o Authenticate the request and generate the client's keys. When 964 the RA generates the client's key, the RA generates a new PKIData 965 with a reqSequence; cmsSequence and otherMsgSequence are omitted. 966 The RA includes the Change Subject Name attribute, as specified 967 in [RFC6402], in the PKCS#10 or CRMF because the name in the 968 request will not match the name in the certificate used to 969 authenticate the request. If the RA-generated key is signature- 970 capable, POP is provided in the typical fashion (i.e., the 971 embedded CRMF or PKCS#10 request includes the POP). The RA can 972 also include additional controls in controlSequence such as 973 Sender Nonce and Transaction Identifier. After generation of the 974 PKIData, the RA encapsulates it in a SignedData as part of the 975 digital signature process. 977 o Reject the client's request and return a PKIResponse with an 978 appropriate reason in the CMC Status Information V2 control. 979 Additionally, the RA includes Transaction Identifier, Sender 980 Nonce, and Recipient Nonce if the request included Transaction 981 Identifier and Sender Nonce controls. The PKIResponse is 982 encapsulated in a SignedData as part of the digital signature 983 process. This document defines three error conditions (see 984 Section 7): 986 * For a Server Key Generation Request control using the 987 ShroudWithPublicKey choice of certificate or certIdentifier, 988 the RA can check that the certificate provided to protect the 989 returned private key validates back to an authorized TA. If 990 the certificate does not validate back to their TA, then the RA 991 returns a PKIResponse with a CMC Status Information v2 control 992 indicating the request failed with an extendedFailInfo 993 indicating badCertificate (see Section 7) encapsulated in a 994 SignedData. Note that the RA performing this check will lessen 995 the load on the CA, but it need only be done by the RA when the 996 RA is generating the client's keys; when the CA is generating 997 the keys technically it's up to the CA to perform this check if 998 it receives a CA-generated key request from a client. 1000 I-D CMC Extensions: Server Key Generation July 30, 2013 1002 * For a Server Key Generation Request control using the 1003 ShroudWithSharedSecret choice and where the RA knows the shared 1004 secret, the RA will reject the request if the shared secret 1005 does not match the one on the RA by returning a PKIResponse 1006 with a CMC Status Information control indicating the request 1007 failed with an extendedFailInfo indicating badSharedSecret (see 1008 Section 7) encapsulated in a SignedData. This is done because 1009 client authentication failed. 1011 * For a Server Key Generation Request control that has archiveKey 1012 set to TRUE, the RA is generating the client's keys, and the RA 1013 does not support archive, the RA will reject the request by 1014 returning a PKIResponse with a CMC Status Information v2 1015 control indicating the request failed with an extendedFailInfo 1016 indicating archiveNotSupported (see Section 7) encapsulated in 1017 a SignedData. If the RA knows the CA also does not support 1018 archival of keys, the RA, if it wishes, can reject the 1019 certificate in the same fashion; when the CA is generating the 1020 keys, technically it is up to the CA to perform this check if 1021 it receives a CA-generated key request from a client. Note 1022 that the RA performing this check will lessen the load on the 1023 CA, but it need only be done by the RA when the RA is 1024 generating the client's keys; when the CA is generating the 1025 keys technically it is up to the CA to perform this check if it 1026 receives a CA-generated key request from a client. 1028 RA's can also batch more than one request together, by including each 1029 client request in a separate cmsSequence or reqSequence (for Simple 1030 PKI requests) along with a Batch Request control in the RA's 1031 PKIRequest control field. After generation of the PKIData, the RA 1032 encapsulates it in a SignedData as part of the digital signature 1033 process. 1035 When verifying SignedData signatures, the RA verifies it back to an 1036 authorized TA. 1038 3.3. CA Processing 1040 Receipt of a PKIResponse with a CMC Status Information control that 1041 indicates failed results requires an out-of-band mechanism to 1042 adjudicate the error in order to avoid a loop between the client/RA 1043 and CA. 1045 CA processing of requests depends on the number of layers of 1046 encapsulation: 1048 o Requests with a single layer of encapsulation will be validated 1049 back to an authorized TA if they are encapsulated in a SignedData 1051 I-D CMC Extensions: Server Key Generation July 30, 2013 1053 or authenticated with the shared secret if they are encapsulated 1054 in an AuthenticatedData. For AuthenticatedData encapsulated 1055 requests the server locates the necessary shared secret with the 1056 information found in the Identification control. For a PKIRequst 1057 with a reqSequence, the server verifies the POP. Regardless of 1058 the encapsulation technique, the server performs the Identity 1059 checks and processes other controls such as Transaction 1060 Identifier and Sender Nonce. If any of these checks fail or 1061 processing of a control fails, the CA rejects the certification 1062 request with the appropriate error code, as specified in 1063 [RFC5272]. 1065 o Requests with multiple layers of encapsulation (i.e., those 1066 requests that are RA-involved) will first validate the signature 1067 on the outer SignedData back to an authorized TA and process any 1068 controls present such as RA Identity Witness, Modify Certificate 1069 Template, Sender Nonce, and Transaction Identifier, as per 1070 [RFC5272][RFC6402]. Inner requests are also processed as 1071 specified in the previous bullet. Failure to validate back to an 1072 authorized TA or control processing failures result in rejected 1073 requests with the appropriate error code, as specified in 1074 [RFC5752]. 1076 CAs may require that the RA prove that it has possession of 1077 encryption-only keys that do not support one-time signature use, by 1078 returning a PKIResponse indicating the request failed because POP is 1079 required and including the Encrypted POP control along with other 1080 appropriate controls. The response is signed by the CA. See Section 1081 2.5.1. 1083 After successfully authenticating the request and verifying the 1084 client's identity, the CA generates: 1086 o Responses for single layer encapsulated requests for RA-generated 1087 keys by issuing the certificate. If no controls were present in 1088 the request (see Appendix B), the PKIResponse is a Simple PKI 1089 Response [RFC5751], which includes no content and therefore no 1090 signature. With controls (e.g., Transaction Identifier, Sender 1091 Nonce, and Recipient Nonce), the PKIResponse includes the 1092 appropriate controls and is signed by the CA. The CA places the 1093 certificate in the SignedData certificates field. 1095 o Responses for multi-layered encapsulation requests for RA- 1096 generated keys (See Appendix B) beginning with the previous 1097 bullet followed by placing the inner response in a cmsSequence 1098 entry. The outer PKIResponse includes the Batch Response control 1099 as well as any other necessary controls in controlSequence and 1100 the CA generates a signature for the SignedData. 1102 I-D CMC Extensions: Server Key Generation July 30, 2013 1104 o Responses for single layer encapsulated requests for CA-generated 1105 keys by generating the asymmetric key pair and issuing the 1106 certificate. The signed CA-generated PKIResponse includes the 1107 Server Key Generation Response control (see Section 6.2) along 1108 with other controls based on whether they were present in the 1109 controlSequence as well as the signed and then encrypted 1110 Asymmetric Key Package in cmsSequence. The CA places the 1111 certificate in the SignedData certificates field. 1113 o Responses for multi-layered encapsulation requests for CA- 1114 generated keys beginning with the previous bullet followed by 1115 encapsulating the inner response in cmsSequence. The outer 1116 response includes controls as necessary in controlSequence and 1117 the CA generates a signature. 1119 If the CA is unable to perform the request at this time or the entire 1120 request cannot be processed, it can return a signed PKIResponse 1121 indicating with a CMC Status Information control with a status of 1122 pending or partial along with pendInfo, which the client uses to know 1123 when to ask the CA next about the request. 1125 When the CA fails to or refuses to process the request, it returns a 1126 PKIResponse with a CMC Status Information control with the 1127 appropriate error code from [RFC5272] or from Section 7 of this 1128 document. Additionally, it includes Transaction Identifier, Sender 1129 Nonce, and Recipient Nonce in the response if the request included 1130 Transaction Identifier and Sender Nonce controls. 1132 3.4. RA Processing of CA Responses 1134 If the CA rejected the RA's request as indicated by a PKIResponse 1135 with CMC Status Information control that is failed, then an out-of- 1136 band mechanism may be necessary to determine the cause of failure in 1137 order to avoid a loop of the RA returning the same request at a later 1138 time only to also have it rejected. 1140 If the CA returned a pending or partial response, the RA will use the 1141 information in the CMC Status Information control's pendInfo to poll 1142 the CA with a signed PKIRequest with a Query Pending control. CA 1143 processing continues as in Section 3.3. 1145 RA's that are challenged by the CA to prove possession of an 1146 encryption-only RA-generated key validate the CA's signature back to 1147 an authorized TA, decrypt the POP, and process any other controls 1148 that are present. If any of these fail, then the RA terminate the 1149 request and inform the operator of the fault. Assuming the checks 1150 pass, the RA generates a PKIData that includes a Decrypted POP 1151 control and any other controls with no cmsSequence, reqSequence, or 1153 I-D CMC Extensions: Server Key Generation July 30, 2013 1155 otherMsgSequence. The RA encapsulates the PKIData or the PKIResponse 1156 in a SignedData as part of the digital signature process and sends it 1157 to the CA. CA processing resumes as in Section 3.3. 1159 Assuming the response is a success: 1161 o If there is no signature, either the keys are RA-generated or are 1162 client-generated. If the keys are client-generated, then the RA 1163 returns the message to the client unmodified. If the key is RA- 1164 generated, the RA generates a PKIResponse for the client that 1165 includes the signed and then encrypted Asymmetric Key Package in 1166 cmsSequence (see Section 5), the Server Key Generation Response 1167 control (see Section 6.2), and any other controls. Finally, the 1168 RA encapsulates the PKIResponse for the client in a SignedData as 1169 part of the digital signature process and includes the client's 1170 certificate (from the CA) in the SignedData's certificate field. 1172 o If there is a signature: 1174 * The response is for an RA-generated key request that contained 1175 controls and the RA knows this by the presence of the 1176 Transaction Identifier, Sender Nonce, or Recipient Nonce 1177 controls (and possibly other controls) but there is no 1178 cmsSequence or CMC Status Information control indicating the 1179 request failed or is pending. The RA generates a PKIResponse 1180 for the client that includes the signed and then encrypted 1181 Asymmetric Key Package in cmsSequence (see Section 5), the 1182 Server Key Generation Response control (see Section 6.2), and 1183 any other controls as appropriate. Finally, the RA 1184 encapsulates the PKIResponse for the client in a SignedData as 1185 part of the digital signature process and includes the client's 1186 certificate from the CA's response in the RA's SignedData 1187 certificate field. 1189 * The response is for a request where the CA generated the key 1190 and the RA knows this by the presence of a cmsSequence element. 1191 The RA processes any controls and assuming the processing 1192 passes the RA strips off the outer SignedData and forwards the 1193 cmsSequence element (i.e., the SignedData) to the client. 1195 * The response is for a batch request and the RA knows this by 1196 the presence of a Batch Response control. The RA process any 1197 controls and assuming the processing passes the RA strips off 1198 the outer SignedData and forwards the inner SignedData(s) from 1199 the cmsSequence to the appropriate clients. If any of the 1200 requests are marked as failed or pending, then the processing 1201 earlier in this section applies. 1203 I-D CMC Extensions: Server Key Generation July 30, 2013 1205 The RA, if it wishes, can also check the returned certificate to make 1206 sure it validates back to an authorized TA and that the returned 1207 certificate is consistent with the certificate request found in the 1208 Server Key Generation Request control. These checks cut down on 1209 errors at the client. If the RA detects that the certificate is not 1210 consistent, the SHOULD NOT return the certificate to the client and 1211 the RA SHOULD request that the certificate be revoked. 1213 RA-generated keys for which a PKIResponse with a CMC Status 1214 Information control that is not success SHOULD NOT return the Server 1215 Key Generation Response or the encapsulated Asymmetric Key Package to 1216 the client because the the CA didn't certify the public key. 1218 3.4. Client Processing of Responses 1220 Clients validate the signature on all responses back to an authorized 1221 TA. 1223 Responses signed by an RA with a client certificate signed by a CA 1224 whose certificate includes a id-kp-cmcCA EKU (Extended Key Usage) 1225 [RFC6402] will violate the should requirement found in [RFC6042] that 1226 the PKIResponse be signed with an entity with the same name as the 1227 certificate. Because the RA has generated the keys there are many 1228 more bad things an RA can do so this seemed like a tradeoff worth 1229 making. 1231 4. Shrouding Algorithms 1233 For the server-side key generation control attribute described in 1234 this document to function, clients need to tell the server in advance 1235 what encryption algorithm and what key value is to be used for 1236 encrypting the returned private key. The encrypted data returned is 1237 returned as an EnvelopedData object as defined by [RFC5652] and 1238 placed in the cmsSequence field of a PKIResponse [RFC5272]. Clients 1239 also need to tell the server in advance what digital signature and 1240 hash algorithms it supports to ensure the certification response and 1241 certificate can be verified. 1243 Each request control for which the response includes encrypted data 1244 contains two fields to define type of encryption used: 1245 algCapabilities and shroudMethod. 1247 The algCapabilities field, see Section 6.1, contains the advertised 1248 capabilities of the client-side entity. This field uses the S/MIME 1249 Capabilities type defined in section 2.5.2 of [RFC5751]. The 1250 capabilities to be listed are digital signature algorithms, message 1251 digest algorithms, content encryption algorithms, key agreement 1252 algorithms, key encipherment algorithms, key-wrap algorithms and key 1254 I-D CMC Extensions: Server Key Generation July 30, 2013 1256 derivation algorithms. Encodings for SMIME Capability values for 1257 Elliptic Curve Key Agreement, Key Derivation Function, and Key Wrap 1258 algorithms can be found in [RFC5753], Message Digest and Signature 1259 algorithms can be found in [RFC5754], and AES Key Wrap with Padding 1260 can be found in [RFC5959]. 1262 The shroudMethod field, see Section 6.1, defines the method by which 1263 the server will do the key management of the content encryption key 1264 (CEK) value in EnvelopedData. The shroudMethod field uses the type 1265 ShroudMethod. This type is defined as: 1267 ShroudMethod ::= AlgorithmIdentifier { 1268 SHROUD-ALGORITHM, { ShroudAlgorithmSet } 1269 } 1271 When a new shroud method is defined it includes (a) the source of the 1272 key material, (b) the public or salting information, and (c) the 1273 method of protecting the Content Encryption Key (CEK) using the 1274 requested data, source key material and salt. This document defines 1275 two shroud methods: id-cmc-shroudWithPublicKey and id-cmc- 1276 shroudWithSharedSecret. Clients and servers MUST support id-cmc- 1277 shroudWithPublicKey. Client and servers SHOULD support id-cmc- 1278 shroudWithSharedSecret. 1280 Other shrouding methods could be defined in the future that would not 1281 involve the use of EnvelopedData. For example, one could conceive of 1282 a shrouding method that required the use of Transport Layer Security 1283 (TLS) [RFC5246] to provide the necessary security between the server 1284 and the client. This document does not define any such mechanism. 1286 4.1. Shroud With a Public Key 1288 Clients can indicate that the server use a public key, either wrapped 1289 in a certificate or as a bare public key, to protect the server- 1290 generated key. For this option, the key material is either included 1291 or referenced by a key identifier. The following object identifier 1292 identifies the shroudWithPublicKey shroud method: 1294 id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= { id-cmc XX } 1296 shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey: 1298 srda-shroudWithPublicKey SHROUD-ALGORITHM ::= { 1299 IDENTIFIED BY id-cmc-shroudWithPublicKey, 1300 PARAMS TYPE ShroudWithPublicKey ARE required, 1301 SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithPublicKey } 1302 } 1304 I-D CMC Extensions: Server Key Generation July 30, 2013 1306 ShroudWithPublicKey ::= CHOICE { 1307 certificate Certificate, 1308 certIdentifier [1] SignerIdentifier, 1309 bareKey [2] SEQUENCE { 1310 publicKey SubjectPublicKeyInfo, 1311 ski SubjectKeyIdentifier 1312 } 1313 } 1315 The fields of type ShroudWithPublicKey have the following meanings: 1317 o certificate provides a public key certificate containing the 1318 public key to be used for encrypting the server-generated private 1319 key from the server to the client. 1321 o certIdentifier provides a pointer to a public key certificate 1322 located in the SignedData that encapsulates the client's PKIData. 1324 For the above two fields, servers SHOULD check that the subject 1325 and subject alternative names match in some way with the entity 1326 that the private key is destined for. 1328 o bareKey allows for an arbitrary public key to be used to return 1329 the encrypted private key. 1331 - publicKey contains the public key that is to be used for 1332 encrypting the private key returned from the server to the 1333 client. 1335 - ski contains the SubjectKeyIdentifier that will be used in CMS 1336 EnvelopedData to identify the public key when encrypting the 1337 private key from the server to the client. 1339 When this method is used with the certificate option, the server 1340 validates the certificate back to a trust anchor. Further, the 1341 server checks that the client provided certificate belongs to the 1342 same client that authenticated the certification request (e.g. the 1343 certificate subjects match, or the client provided certificate 1344 belongs to the same entity as the authentication shared secret). If 1345 either of these checks fails, then the server returns a CMCFailInfo 1346 with the value of badCertificate, which is defined in Section 7. 1348 4.2. Shroud With a Shared-Secret Key 1350 Clients can indicate that servers use a shared secret value to 1351 protect the server-generated private key. For this option, the key 1352 material is identified by the identifier, the key derivation 1353 algorithms supported by the client are included in the 1355 I-D CMC Extensions: Server Key Generation July 30, 2013 1357 algCapabilities field. No salting material is provided by the 1358 client. The derived key is then used as a key encryption key in the 1359 EnvelopedData recipient info structure. The following object 1360 identifier identifies the shroudWithSharedSecret control attribute: 1362 id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX} 1364 shroudWithSharedSecret attribute values have the ASN.1 type 1365 ShroudWithSharedSecret: 1367 shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= { 1368 IDENTIFIED BY id-cmc-shroudWithSharedSecret 1369 PARAMS TYPE ShroudWithSharedSecret ARE required 1370 SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithSharedSecret } 1371 } 1373 ShroudWithSharedSecret ::= UTF8String 1375 The common identification string for the client and the server is 1376 placed in the ShroudWithSharedSecret field, which is a UTFString 1377 [RFC5280]. In addition the client needs to place both a key 1378 derivation function and a key wrap function in the set of 1379 capabilities advertised by the client in the algCapabilities field. 1380 The identification string is used to identify the pass phrase or 1381 shared key. 1383 When this method is used, the server checks that the chosen shared 1384 secret belongs to the authenticated identity of the entity that 1385 generated the certification request. If this check fails, then the 1386 server returns a CMCFailInfo with the value of badSharedSecret, which 1387 is defined in Section 7. In general, while it is expected that the 1388 same identity token and shared secret used to do the identity 1389 authentication are used to derive the key encryption key this is not 1390 required. 1392 5. Returned Key Format 1394 The server returns the private key and optionally the corresponding 1395 public key to the client with the AsymmetricKeyPackage content type 1396 [RFC5958]. The AsymmetricKeyPackage is first encapsulated in a 1397 Cryptographic Message Syntax (CMS) SignedData content type [RFC5652], 1398 then the inner SignedData is further encapsulated in an EnvelopedData 1399 content type [RFC5652], and finally the EnvelopedData is encapsulated 1400 in an outer SignedData. The Content Hints attribute [RFC2634] can be 1401 used in the outer SignedData to provide a hint as to the inner most 1402 content type (i.e., the AsymmetricKeyPacakge). There MUST be only 1403 one OneAsymmetricKey present in the AsymmetricKeyPackage sequence. 1404 When more than one private key is to be returned, multiple 1406 I-D CMC Extensions: Server Key Generation July 30, 2013 1408 AsymmetricKeyPackage content types are needed. For example, when 1409 returning more than one private key the separate AsymmetricKeyPackage 1410 content types can be individually encapsulated in SignedData, 1411 packaged together with the ContentCollection content type [RFC4073], 1412 protected with an EnvelopedData around the ContentCollection, and 1413 finally the EnvelopedData is encapsulated in a SignedData. The 1414 public key SHOULD be included in the AsymmetricKeyPackage. 1416 6. Server-Side Key Generation 1418 This section provides the control attributes necessary for doing 1419 server-side generation of keys for clients. The client places the 1420 request for the key generation in a request message and sends it to 1421 the server. The server will generate the key pair, create a 1422 certificate for the public key and return the data in a response 1423 message, or the server will return a failure indication. 1425 6.1. Server-Side Key Generation Request Attribute 1427 The client initiates a request for server-side key generation by 1428 including the server-side key generation request attribute in the 1429 control attributes section of a PKIData object. The request 1430 attribute includes information about how to return the generated key 1431 as well as any client suggested items for the certificate. The 1432 control attribute for doing server-side key generation is identified 1433 by the following OID: 1435 id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX } 1437 The Server-Side Key Generation Request control attribute has the 1438 following ASN.1 definition: 1440 cmc-serverKeyGenRequest CMC-CONTROL ::= { 1441 ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest 1442 } 1444 ServerKeyGenRequest ::= SEQUENCE { 1445 certificateRequest CertTemplate, 1446 shroudMethod ShroudMethod, 1447 algCapabilities SMimeCapabilties OPTIONAL, 1448 archiveKey BOOLEAN DEFAULT TRUE 1449 } 1451 The fields in ServerKeyGenRequest have the following meaning: 1453 o certificateRequest contains the data fields that the client 1454 suggests for the certificate being requested for the server 1455 generated key pair. The format is TaggedRequest from [RFC5272], 1457 I-D CMC Extensions: Server Key Generation July 30, 2013 1459 which supports both PKCS#10 and CRMF requests. 1461 o shroudMethod contains the identifier of the type of algorithm to 1462 be used in deriving the key used to encrypt the private key. 1464 o algCapabilities contains the set of algorithm capabilities being 1465 advertised by the client. The server uses algorithms from this 1466 set in the ServerKeyGenResponse object to encrypt the private key 1467 of the server-generated key pair. This field is optional because 1468 this information might be carried in a signed attribute, included 1469 within a certificate or be part of the local configuration. 1471 o archiveKey is set to TRUE if the client wishes the key to be 1472 archived as well as generated on the server. Further processing 1473 by the server when this is set to TRUE is out-of-scope. 1475 The client can request that the generated key be for a specific 1476 algorithm by placing data in the publicKey field of the CRMF request 1477 or in the subjectPKInfo of the PKCS#10 request. If the publicKey 1478 field is populated, then the public key is a zero length bit string. 1479 If the client requests a specific algorithm, the server either 1480 generates a key for that algorithm (with the parameters if defined) 1481 or fails to process the request. If the request fails for this 1482 reason, the server returns a CMCFailInfo with a value of badAlg 1483 [RFC5272]. 1485 As specified in [RFC5272]: 1487 "A server is not required to use all of the values suggested by 1488 the client in the certificate template. Servers MUST be able to 1489 process all extensions defined in [RFC5280]. Servers are not 1490 required to be able to process other V3 X.509 extensions 1491 transmitted using this protocol, nor are they required to be able 1492 to process other, private extensions. Servers are permitted to 1493 modify client-requested extensions. Servers MUST NOT alter an 1494 extension so as to invalidate the original intent of a client- 1495 requested extension. (For example change key usage from key 1496 exchange to digital signature.) If a certification request is 1497 denied due to the inability to handle a requested extension, the 1498 server MUST respond with a CMCFailInfo with a value of 1499 unsupportedExt." 1501 A server that does not recognize the algorithm identified in 1502 shroudMethod will reject the request. The server returns a 1503 CMCFailInfo with a value of badAlg [RFC5272]. 1505 A server that does not support at least one of the algCapabilities 1506 will reject the request. The server returns a CMCFailInfo with a 1508 I-D CMC Extensions: Server Key Generation July 30, 2013 1510 value of badAlg [RFC5272]. 1512 If archiveKey is set to true and the server does not support 1513 archiving of private keys, the request will be rejected by the 1514 server. The server returns a CMCFailInfo with a value of 1515 archiveNotSupported, see Section 7. 1517 6.2. Server-side Key Generation Response 1519 The server creates a server-side key generation response attribute 1520 for every key generation request made and successfully completed. 1521 The response message has a pointer to both the original request 1522 attribute and to the body part in the current message that holds the 1523 encrypted private keys. The response message also can contain a 1524 pointer to the certificate issued. The key generation response 1525 control attribute is identified by the OID: 1527 id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= { id-cmc XX } 1529 The Server-Side Key Generation Response control attribute has the 1530 following ASN.1 definition: 1532 cmc-serverKeyGenResponse CMC-CONTROL ::= { 1533 ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse 1534 } 1536 ServerKeyGenResponse ::= SEQUENCE { 1537 cmsBodyPartId BodyPartID, 1538 requestBodyPartId BodyPartID, 1539 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 1540 } 1542 The fields in ServerKeyGenResponse have the following meaning: 1544 o cmsBodyPartId identifies a TaggedContentInfo contained within the 1545 enclosing PKIData. The ContentInfo object is of type 1546 EnvelopedData and has an encapsulated content of id-ct-KP- 1547 aKeyPackage (see Section 4). 1549 o requestBodyPartId contains the body part identifier for the 1550 server-side key generation request control attribute. This 1551 allows for clients to associate the resulting key and certificate 1552 with the original request. 1554 o issuerAndSerialNumber if present contains the identity of the 1555 certificate issued to satisfy the request. The certificate is 1556 placed in the certificate bag of the immediately encapsulating 1557 signedData object. 1559 I-D CMC Extensions: Server Key Generation July 30, 2013 1561 As specified in [RFC5272]: 1563 "Clients MUST NOT assume the certificates are in any order. 1564 Servers SHOULD include all intermediate certificates needed to 1565 form complete chains to one or more self-signed certificates, not 1566 just the newly issued certificate(s) in the certificate bag. The 1567 server MAY additionally return CRLs in the CRL bag. Servers MAY 1568 include self-signed certificates. Clients MUST NOT implicitly 1569 trust included self-signed certificate(s) merely due to its 1570 presence in the certificate bag." 1572 7. Additional Error Codes 1574 This section defines ExtendedFailInfo errors from this document: 1576 cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= { 1577 TYPE ErrorList IDENTIFIED BY id-tbd 1578 } 1580 ErrorList ::= INTEGER { 1581 archiveNotSupported (1), 1582 badCertificate (2), 1583 badSharedSecret (3) 1584 } 1586 o archiveNotSupported indicates that the server does not support 1587 archiving of private keys. The syntax for the ExtendedFailInfo 1588 is as follows: 1590 cmc-err-archiveNotSupport EXTENDED-FAILURE-INFO ::={ 1591 IDENTIFIED BY id-tbd 1592 } 1594 o badCertificate indicates that the certificate to be used to 1595 encrypt the response did not validate back to a RA/CA trust 1596 anchor or the certificate does not belong to the client. The 1597 syntax for the ExtendedFailInfo is as follows: 1599 cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={ 1600 IDENTIFIED BY id-tbd 1601 } 1603 o badSharedSecret indicates that the shared secret provided by the 1604 client does not match that stored by the server. 1606 cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={ 1607 IDENTIFIED BY id-tbd 1608 } 1610 I-D CMC Extensions: Server Key Generation July 30, 2013 1612 8. Proof-of-Possession 1614 Some servers may require that the client prove that it has possession 1615 of the server-generated key. This requires an additional roundtrip 1616 beyond those previously discussed. 1618 For certificates returned that support digital signatures the process 1619 is as described in [RFC5272]: the server indicates in CMCStatus is 1620 confirmRequired, the client returns the Confirm Certificate 1621 Acceptance control in PKIData signed with the server-generated 1622 private key, and the server responds with a CMCStatus of success. 1624 For certificates returned that only support encryption, the server 1625 indicates the CMCStatus is popRequired and includes the Encrypted POP 1626 control, the client returns the Decrypted POP control. Whether the 1627 PKIRequest from the client is encapsulated in an Authenticated Data 1628 or Signed Data depends on which mechanism was used during the server 1629 key generation request. 1631 9. Security Considerations 1633 Central generation of digital signature keys contains risks and is 1634 not always appropriate. Organization-specific CPs (Certificate 1635 Policies) [RFC3647] define whether or not server-side generation of 1636 digital signature keys is permitted. 1638 There is a balance that needs to be maintained between the use of a 1639 potentially poorly generated one time key and the use of a key 1640 externally provided. For externally provided keys, the external 1641 provider of the key will be able to decrypt the key delivery message 1642 as long as it was captured. For poorly generated one time keys, any 1643 external party might be able to guess the key and thus decrypt the 1644 key delivery message. Different types of keys will have different 1645 requirements for what a poorly generated key means. Generators of RSA 1646 keys need to be able to do good prime checking, generators of Diffie- 1647 Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) keys only need a 1648 moderate quality random number generator if the group parameters are 1649 externally provided. 1651 This specification requires implementations to generate key pairs and 1652 other random values [RFC4086]. The use of inadequate pseudo-random 1653 number generators (PRNGs) can result in little or no security. The 1654 generation of quality random numbers is difficult. NIST Special 1655 Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer 1656 guidance. 1658 Private keys, regardless of where they are generated, must be 1659 appropriately protected from disclosure or modification on the 1661 I-D CMC Extensions: Server Key Generation July 30, 2013 1663 server, in transit, and on the client. Cryptographic algorithms and 1664 keys used to protect the private key should be at least as strong as 1665 the private key's intended strength. 1667 Key agreement algorithms (i.e., Diffie-Hellam or Elliptic Curve 1668 Diffie-Hellman) can be used to protect the returned server-generated 1669 key. These algorithms support a number of different schemes [SP-800- 1670 56]. Normally, an Ephemeral-Static (E-S) scheme is used (more 1671 formally known as "(Cofactor) One-Pass Diffie-Hellman, 1672 C(1e,1s,ECCCDH) Scheme") see [RFC5753], but here the client provides 1673 an ephemeral key to the server so an S-E scheme is used when the key 1674 is encrypted for the client. Regardless, the client needs to 1675 generate an ephemeral key and provide it to the server and this key 1676 needs to use the same parameters (i.e., p, q, g for DH and elliptic 1677 curve for ECDH) as the server. The client's parameters MUST be 1678 present in the publicKey or certificate field of the Server Key 1679 Generation Request control or MUST be in the certificate referred to 1680 by the ski in the same control. The client can find the server's 1681 parameters in the server's certificate; to make it easy on clients, 1682 server certificates MUST include parameters. How the client 1683 obtains the server's certificate is out of scope. 1685 Servers that support the features specified herein need to document 1686 their procedures in a CPS (Certificate Practice Statement) [RFC3647]. 1687 CAs that certify server-generated private keys are certifying that 1688 they've taken due diligence to ensure that the private key is only 1689 known to and used by the subject. Depending on the Certification 1690 Policy [RFC3647], the keys have been allocated to the subject, but 1691 the keys may not be strictly owned by the subject. The CA (and the 1692 enterprise it supports) has a reason for issuing the keys (e.g., 1693 employer to employee; school to student) and because the enterprise 1694 CA generated the private keys it is accountable for the 1695 trustworthiness of the private key. But, the subject should beware 1696 using it for other purposes. 1698 When using an ephemeral key for protecting the server-generated key, 1699 A compromised signature key, when used by the intended party, will 1700 not automatically jeopardize the security of the server-generated 1701 keys. Procedural controls can help to ensure a one-to-one mapping 1702 between verified requests and intended parties (i.e. mitigate the 1703 risk of masquerade using a compromised authentication key and 1704 certificate), but that is outside the scope of this document. 1706 POP is important, but for server-generated keys it can only be 1707 provided after the server-generated key has been returned by the 1708 client (see Section 8). 1710 When the shared secret is used to provide client authentication and 1712 I-D CMC Extensions: Server Key Generation July 30, 2013 1714 protect the server-generated private key, the shared secret must be 1715 kept secret for the lifetime of the key. This is because disclosure 1716 could allow attackers to determine the server-generated private key. 1717 This is different than certification requests with client-generated 1718 keys because the shared secret is no longer needed after the 1719 authentication. 1721 If the key generator and the server are not collocated, then the 1722 exchange between these two entities must be protected from 1723 unauthorized disclosure and modification and both entities must have 1724 a trust relationship. However, these exchanges are beyond the scope 1725 of this document. Note that the CA needs access to the public key to 1726 generate the certificate. If the key generator encrypts the 1727 generated key for the client, then the key generator needs to provide 1728 the public key to the CA (possibly through the RA). 1730 Returning the key to the wrong client can be bad. If an encrypted 1731 key is returned to the wrong client, then it is only bad if the key 1732 was encrypted for the wrong client and then something much worse is 1733 afoot. If the encrypted key is returned to the wrong client and it 1734 is encrypted for the right client (i.e., it was misdirected), then it 1735 is bad but the unencrypted key hasn't been disclosed to an 1736 unauthorized client. The protection afforded by the confidentiality 1737 algorithm is what protects the misdirected key from unauthorized 1738 disclosure. 1740 10. IANA Considerations 1742 This document makes use of object identifiers to register CMC control 1743 attributes and CMC error codes. Additionally, an object identifier 1744 is used to identify the ASN.1 module found in Appendix A. All are 1745 defined in an arc delegated by IANA to the PKIX Working Group. The 1746 current contents of the arc are located here: 1748 http://www.imc.org/ietf-pkix/pkix-oid.asn 1750 They were obtained by sending a request to ietf-pkix-oid-reg@imc.org. 1751 When the PKIX WG closes, this arc and registration procedures will 1752 be transferred to IANA. No further action by IANA is necessary for 1753 this document or any anticipated updates. 1755 11. References 1757 11.1 Normative References 1759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1760 Requirement Levels", BCP 14, RFC 2119, March 1997. 1762 I-D CMC Extensions: Server Key Generation July 30, 2013 1764 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1765 Request Syntax Specification Version 1.7", RFC 2986, 1766 November 2000. 1768 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1769 Certificate Request Message Format (CRMF)", RFC 4211, 1770 September 2005. 1772 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1773 (CMC)", RFC 5272, June 2008. 1775 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1776 Housley, R., and W. Polk, "Internet X.509 Public Key 1777 Infrastructure Certificate and Certificate Revocation List 1778 (CRL) Profile", RFC 5280, May 2008. 1780 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1781 RFC 5652, September 2009. 1783 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1784 Mail Extensions (S/MIME) Version 3.2 Message 1785 Specification", RFC 5751, January 2010. 1787 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1788 2010. 1790 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1791 Updates", RFC 6402, November 2011. 1793 12.2 Informative References 1795 [FIPS-186] National Institute of Standards and Technology (NIST), 1796 FIPS 186-3 DRAFT: Digital Signature Standard (DSS), 1797 November 2008. 1799 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 1800 RFC 2634, June 1999. 1802 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1803 Wu, "Internet X.509 Public Key Infrastructure Certificate 1804 Policy and Certification Practices Framework", RFC 3647, 1805 November 2003. 1807 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1808 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1810 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1812 I-D CMC Extensions: Server Key Generation July 30, 2013 1814 "Randomness Requirements for Security", BCP 106, RFC 4086, 1815 June 2005. 1817 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 1818 36, RFC 4949, August 2007. 1820 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1821 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1823 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1824 Cryptography (ECC) Algorithms in Cryptographic Message 1825 Syntax (CMS)", RFC 5753, January 2010. 1827 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1828 Message Syntax", RFC 5754, January 2010. 1830 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 1831 Type", RFC 5959, August 2010. 1833 [SP-800-56] Barker, E., Johnson, D., and M. Smid, "Recommendation for 1834 Pair-Wise Key Establishment Schemes Using Discrete 1835 Logarithm Cryptography", NIST Special Publication 800-56A 1836 Revision 1, March 2007. 1838 [SP-800-57] National Institute of Standards and Technology (NIST), 1839 Special Publication 800-57: Recommendation for Key 1840 Management - Part 1 (Revised), March 2007. 1842 [SP-800-90] National Institute of Standards and Technology (NIST), 1843 Special Publication 800-90: Recommendation for Random 1844 Number Generation Using Deterministic Random Number Bit 1845 Generators (Revised), March 2007. 1847 Appendix A. ASN.1 Module 1849 To be supplied later. 1851 Appendix B. Additional Message Flows 1853 This appendix forms a non-normative part of this specification. 1855 The main body of this document has portrayed protocol flows with 1856 optional controls. This was done to explain the more complicated 1857 scenarios. This appendix depicts the flows without those optional 1858 controls. 1860 For example the figure in Section 2.5.1 without the TransactionId, 1861 SenderNonce, and RecipientNonce, appear as follows: 1863 I-D CMC Extensions: Server Key Generation July 30, 2013 1865 Client RA CA 1866 | | | 1867 |----------------->| | 1868 | [PKIData | | 1869 | control: SKGReq, | | 1870 | Identification] | | 1871 | |-------------------------------------->| 1872 | | | 1874 | |<--------------------------------------| 1875 |<-----------------| PKIResponse 1876 | }> 1880 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 1882 The PKIResponse from the CA is a certs-only message, which does not 1883 include a signature. 1885 Likewise for the figure in Section 2.5.2: 1887 Client RA CA 1888 | | | 1889 |----------------->| | 1890 | [PKIData | | 1891 | control: SKGReq, | | 1892 | Identification] | | 1893 | |--------------------------------------->| 1894 | | | 1898 | |<---------------------------------------| 1899 | | } > > 1903 | }> 1907 If the RA doesn't perform the Identity checks, then it can forward 1908 the client's request without the additional layers of encapsulation. 1910 Client RA CA 1911 | | | 1912 |----------------->| | 1914 I-D CMC Extensions: Server Key Generation July 30, 2013 1916 | [PKIData | | 1917 | control: SKGReq, | | 1918 | Identification] | | 1919 | |--------------------------------------->| 1920 | | [PKIData | 1921 | | control: SKGReq, Identification] | 1922 | |<---------------------------------------| 1923 | | }> 1926 |<-----------------| 1927 | }> 1931 Not to be outdone, the scenarios in Section 2.5.1 can be more 1932 complicated by an RA that batch requests together. The following 1933 depicts a number of clients sending requests together that an RA then 1934 batches together. The unsigned PKIResponse (a certs-only message) 1935 includes all of the certificates issued. The CA can also return 1936 individual responses as opposed to batching them all together or it 1937 can batch them together in some other combination. 1939 Client(1-n) RA CA 1940 | | | 1941 |----------------->| | 1942 | [PKIData | | 1943 | control: SKGReq, | | 1944 | Identification] | | 1945 | |-------------------------------------->| 1946 | | | 1948 | |<--------------------------------------| 1949 | | 1952 | }> 1956 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 1958 In another scenario, all but one of the requests were successfully 1959 processed. The RA returns those that were successful back to the 1960 clients but later polls the CA, based on the value CMCStatusInfoV2 1961 pendInfo, for the one that was not successful. The CA returns the 1962 one successful request. 1964 I-D CMC Extensions: Server Key Generation July 30, 2013 1966 Client(1-n) RA CA 1967 | | | 1968 |----------------->| | 1969 | [PKIData | | 1970 | control: SKGReq, | | 1971 | Identification] | | 1972 | |-------------------------------------->| 1973 | | | 1976 | |<--------------------------------------| 1977 | | 1981 |<-----------------| 1982 | }> | 1985 | |-------------------------------------->| 1986 | | | 1988 | |<--------------------------------------| 1989 | | PKIResponse 1990 |<-----------------| 1991 | }> 1995 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 1997 Batching the requests can also be performed for CA-generated keys as 1998 shown below. The RA Identity Witness controls indicates all those 1999 client requests that it performed Identity checks on. 2001 Client RA CA 2002 | | | 2003 |----------------->| | 2004 | [PKIData | | 2005 | control: SKGReq, | | 2006 | TransactionID, | | 2007 | SenderNonce, | | 2008 | Identification] | | 2009 | |--------------------------------------->| 2010 | | | 2019 | |<---------------------------------------| 2020 | | } >> 2027 | }> 2031 Appendix B. Examples 2033 To be supplied later. 2035 B.1. Client Requests 2037 B.1.1. Shroud with Certificate 2039 B.1.2. Shroud with Public Key 2041 B.1.3. Shroud with Shared Secret 2043 B.2. CA-Generate Key Response 2045 B.3. RA-Generate Key Response 2047 Authors' Addresses 2049 Jim Schaad 2050 Soaring Hawk Consulting 2052 Email: jimsch@exmsft.com 2054 Sean Turner 2055 IECA, Inc. 2056 3057 Nutley Street, Suite 106 2057 Fairfax, VA 22031 2058 USA 2060 Email: turners@ieca.com 2062 I-D CMC Extensions: Server Key Generation July 30, 2013 2064 Paul Timmel 2065 National Information Assurance Research Laboratory 2066 National Security Agency 2068 Email: pstimme@tycho.ncsc.mil