idnits 2.17.00 (12 Aug 2021) /tmp/idnits53350/draft-turner-cmc-serverkeygeneration-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2014) is 2976 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) -- Looks like a reference, but probably isn't: '1' on line 1415 -- Looks like a reference, but probably isn't: '2' on line 1416 ** 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 (~~), 1 warning (==), 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: September 28, 2014 IECA 6 P. Timmel 7 National Security Agency 8 March 27, 2014 10 CMC (Certificate Management over Cryptographic Message Syntax) 11 Extensions: Server Side Key Generation 12 draft-turner-cmc-serverkeygeneration-01.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 for 19 certificates. This service is provided by the definition of 20 additional control statements within the CMC architecture. 21 Additional CMC errors are 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 Copyright and License Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 50 I-D CMC Extensions: Server Side Key Generation March 27, 2014 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Protocol Flows for Supported Scenarios . . . . . . . . . . . . 5 62 2.1. Shared Secret for Authentication and Key Protection . . . 9 63 2.2 Shared Secret for Authentication and Ephemeral Key for 64 Protection . . . . . . . . . . . . . . . . . . . . . . . . 11 65 2.3. Certificate for Authentication and Ephemeral Key for 66 Protection . . . . . . . . . . . . . . . . . . . . . . . . 12 67 2.4. Certificate for Authentication and Key Protection . . . . . 13 68 2.4.1. Same Certificate for Authentication and Key 69 Protection . . . . . . . . . . . . . . . . . . . . . . 14 70 2.4.2. Different Certificates for Authentication and Key 71 Protection . . . . . . . . . . . . . . . . . . . . . . 14 72 2.5. RA Scenarios . . . . . . . . . . . . . . . . . . . . . . . 14 73 2.5.1. RA-Generated Key Scenarios . . . . . . . . . . . . . . 16 74 2.5.2. RA-Involved Scenarios . . . . . . . . . . . . . . . . 19 75 3. Generating PKIData and PKIResponse . . . . . . . . . . . . . . 20 76 3.1. Client Requests . . . . . . . . . . . . . . . . . . . . . 21 77 3.2. RA Processing of Client Requests . . . . . . . . . . . . . 21 78 3.3. CA Processing . . . . . . . . . . . . . . . . . . . . . . 23 79 3.4. RA Processing of CA Responses . . . . . . . . . . . . . . 25 80 3.5. Client Processing of Responses . . . . . . . . . . . . . . 27 81 4. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 27 82 4.1. Shroud with a Public Key . . . . . . . . . . . . . . . . . 28 83 4.2. Shroud with a Shared-Secret Key . . . . . . . . . . . . . . 29 84 5. Returned Key Format . . . . . . . . . . . . . . . . . . . . . . 30 85 6. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 31 86 6.1. Server-Side Key Generation Request Attribute . . . . . . . 31 87 6.2. Server-side Key Generation Response . . . . . . . . . . . . 33 88 7. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 34 89 8. Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . 35 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 35 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 11.1 Normative References . . . . . . . . . . . . . . . . . . . 38 94 12.2 Informative References . . . . . . . . . . . . . . . . . . 38 95 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 39 96 Appendix B. Additional Message Flows . . . . . . . . . . . . . . . 40 97 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 43 98 B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 43 99 B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 43 101 I-D CMC Extensions: Server Side Key Generation March 27, 2014 103 B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 43 104 B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 43 105 B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 43 106 B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 43 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 109 1 Introduction 111 This document defines a set of extensions to and errors for 112 Certificate Management over Cryptographic Message Syntax (CMC) 113 [RFC5272] that allows for server-side generation of key material for 114 certificates [RFC5280]. There are strong reasons for providing this 115 service: 117 o Clients may have poor, unknown, or non-existent key generation 118 capabilities. The creation of private keys relies on the use of 119 good key generation algorithms and a robust random number 120 generator. Server key generation can use specialized hardware 121 that may not always be available on clients. 123 o Central storage of keys may be desired in some environments to 124 permit key recovery. This document only addresses a request to 125 archive server-generated keys; archival of locally generated keys 126 and the control to retrieve archived keys is out-of-scope. 128 o Server key generation may be useful for provisioning keys to 129 disconnected clients (e.g., clients that receive keys from a fill 130 device [RFC4949] because the clients are not able to connect to 131 the server due to an air gap). 133 These extensions to the CMC protocol are designed to provide server 134 key generation without adding any additional round trips to the 135 enrollment process; however, additional round trips may be required 136 based on the mechanism chosen to protect the returned key. 138 Section 2 describes the enrollment scenarios supported. Section 3 139 provides CMC requirements. Sections 4 and 5 describe the concepts and 140 structures used in transporting private keys between the server and 141 client applications. Section 6 describes the structure and processes 142 for server-side key generation. Section 7 describes additional CMC 143 error codes. Section 8 describes additional exchanges when the 144 server requires the client provide Proof-of-Possession (POP). 145 Appendix A provides the ASN.1 module for the CMC controls and errors. 146 Appendix B provides example encodings. 148 1.1. Terminology 149 I-D CMC Extensions: Server Side Key Generation March 27, 2014 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 [RFC5652] SignedData, AuthenticatedData, and EnvelopedData content 159 types is assumed. 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 189 to apply to both key transport and key agreement keys. The 190 ephemeral key has two parts: the private part and the public 191 part. The client provides the public part to the server to allow 192 the server to protect the server-generated keys. Note that an 193 ephemeral key has a security advantage by being unique to the 194 session; it SHOULD be freshly generated when possible, but MAY be 195 pre-placed when local key generation is of poor or unknown 196 quality (see Section 9). An ephemeral key is innately 197 unauthenticated, and so must be carried in a suitably 198 authenticated protocol. 200 I-D CMC Extensions: Server Side Key Generation March 27, 2014 202 o Identification: A generic term for a process by which a name, 203 generally assigned by a server, is used to match a request 204 against a known entity. Identification can be either 205 authenticated (a subject name in a certificate) or 206 unauthenticated (a text string). 208 o Perfect Forward Secrecy (PFS): For this protocol, it is the 209 property that the compromise of long-term keying material does 210 not lead to the compromise of the new long-term keying material 211 carried in the protocol. 213 o Shared Secret: A value known to two or more entities in advance 214 of a protocol session in which it will be used, and intended to 215 be unknown to any others. In this document, the value must be a 216 suitable basis for derivation of a MAC (Message Authentication 217 Code) or encryption key. Pass phrases that are used as a shared 218 secret must be treated as confidential by the holders of the 219 secret. 221 o Shrouding: A generic term to cover methods of masking the content 222 of an object from unauthorized viewers, taken from RSA's PKCS 223 specifications. The most common method of shrouding used is 224 encryption of the data at the application layer. This document 225 defines two shrouding methods that employ encryption at the 226 application layer but other shrouding methods can be defined that 227 don't employ encryption at the application layer. 229 o Signature-capable: Applies to certificates or keys. Certificates 230 that can be used to verify signatures and keys that can be used 231 to generate digital signatures. This refers to either dual-use 232 or signature-only certificates/keys. 234 o Signature-only: Applies to certificate or keys. Certificates 235 that can only be used to verify digital signatures, when the Key 236 Usage extension is set to digitalSignature, and keys whose only 237 intended key usage is digital signature. 239 In this document the server is the entity that generates the key. 240 This can be either the RA or CA. 242 2. Protocol Flows for Supported Scenarios 244 This section describes the supported scenarios, and specifies the CMC 245 requests and responses to support them: 247 1. Clients use a shared secret (e.g., password) (see Section 1.2) to 248 provide authentication and request that the server use the same 249 shared secret to encrypt the server-generated keys. 251 I-D CMC Extensions: Server Side Key Generation March 27, 2014 253 2. Clients use a shared secret to provide authentication and request 254 that the server use an ephemeral key (see Section 1.2) to encrypt 255 the server-generated keys. 257 3. Clients use a key pair previously certified by a CA (i.e., a 258 private key and a certificate) to support digital signature 259 authentication and request that the server use an ephemeral key 260 to encrypt the server-generated keys. 262 4. Clients use a key pair previously certified by a CA (i.e., a 263 private key and a certificate) to support digital signature 264 authentication and request that the server use a certificate to 265 encrypt the server-generated keys. Some additional details: 267 * If the client's authentication certificate is signature-only, 268 then the client also needs an encryption-capable certificate 269 that the server will use to protect the private key. 270 * If the client's certificate is dual-use, then the client only 271 needs the one certified key pair to generate the SignedData 272 that encapsulates the certificate request and to decrypt the 273 EnvelopedData that encapsulates the server-generated key. 275 The characteristics of the four scenarios are as follows: 277 o Scenarios that employ shared secrets (Scenarios 1 and 2) are 278 consider by some to be more human friendly than scenarios that 279 employ certificates because there is less initial overhead 280 because a CA is not initially and clients do not need to find 281 their smartcard, remember their PIN, etc. Also, shared secrets 282 can be used for rekey but this requires distributing a new shared 283 secret with the newly created private key; this behavior is not 284 described in this document. 286 o For scenarios that use a shared secret for key protection (i.e., 287 Scenario 1), the client needs to maintain secrecy of the shared 288 secret, which is often difficult for clients, for the lifetime of 289 the key (see Section 9) to ensure that if the server-generated 290 and encrypted private key is intercepted and the shared secret is 291 later disclosed/discovered that the encrypted private key private 292 key can not be decrypted. In other words, no PFS is provided if 293 a shared secret is used to protect the returned encrypted private 294 key. 296 o For scenarios that use a shared secret for client authentication 297 (i.e., Scenarios 1 and 2), the client needs to maintain secrecy 298 of the shared secret for as long as it is needed for 299 authentication. Servers can mitigate this issue by limiting the 300 lifetime of the shared secret to one-time-use. 302 I-D CMC Extensions: Server Side Key Generation March 27, 2014 304 o For scenarios that use ephemeral keys to protect the returned 305 private key (i.e., Scenarios 2 and 3): 307 * PFS is provided presuming the ephemeral key is forgotten as 308 well as any other information necessary to generate the 309 ephemeral key after the certificate request is successfully 310 processed by the client. 312 * Client use of the ephemeral key mitigates the risk of 313 compromise of a pre-existing certificate and key while in the 314 supply chain (see Section 9). 316 o For scenarios that only use certificates (i.e., Scenario 4), PFS 317 is not provided because the the client uses a long-term private 318 key for private key protection and if compromised the next key 319 can also be compromised. 321 Note that there are existing CP-based (Certificate Policy) 322 requirements for protecting the private key(s) associated with 323 the certificate(s) (see Section 9). 325 In the scenarios above, the entity generating the key pair can be the 326 Certification Authority (CA) or the Registration Authority (RA), in 327 fact the RA or CA can use a separate key generator device (e.g. a 328 hardware security module) but interactions with that device is out of 329 scope. Sections 2.1-2.4 depict protocol flows for scenarios with a 330 client and CA only where the CA generates the keys. Section 2.5 331 depicts protocol flows for scenarios that involve the client, RA, and 332 CA where the RA generates the keys. Section 2.5 also depicts 333 protocol flows for so-called "RA-involved" scenarios where the CA 334 generates the keys but the RA performs identity checks. 336 All scenarios described herein require the server to have some a 337 priori knowledge of the client. How this knowledge is obtained is 338 out of scope, but the scenarios offer different 339 opportunities/constraints for obtaining the information: 341 o In the shared secret cases, the method for prior knowledge has to 342 cope with securely delivering and storing the shared secret. 343 o In the certificate cases, there are two alternatives: 344 * The key pair was generated by the server, so the certificate is 345 evidence of that prior knowledge. 346 * The certificate was issued from another CA. Even when there 347 are no grounds for cross-certification, the certificate can 348 still be used as an artifact for registration/enrollment prior 349 to the client making a certificate request, which is 350 advantageous because the key pair bound to the identifier in 351 the certificate enables the server to authenticate the source 353 I-D CMC Extensions: Server Side Key Generation March 27, 2014 355 of the eventual certificate request and positively link it to 356 the registration information. 358 Note: The initial certificate key pairs could be considered a 359 special case of the shared secret scenario that improves on the 360 security of the shared secret mechanism and mitigates some of the 361 management burden and cost. For example, the certificates could be 362 special-purpose--issued by the manufacturer and recognized by the 363 server solely for authentication against a registration list (i.e., 364 not usable for anything else). If a manufacturer initializes the 365 device with a shared secret, then that shared secret has to be 366 distributed securely to the eventual enrolling CA via the device 367 owner, but independently of the device. If the manufacturer 368 instead installs a key pair and generic certificate, the 369 certificate can take the place of the shared secret that would 370 otherwise have to be independently provided to the central key 371 generation CA. The management process is roughly the same, but the 372 information that has to be handled now longer has to be kept 373 secret. That means there are many more options for how that 374 information can be managed and distributed. 376 Normally the client's identifier and the shared secret are generated 377 by the server and then securely transported to the client, there is 378 no practical reason why this cannot be done in the opposite 379 direction. In this case, the client will generate an identifier, 380 shared secret and an ephemeral key. When the server receives the CMC 381 message, it recognizes that it does not correspond to an existing 382 identifier/secret pair and puts the request on hold. The end-entity 383 then communicates the identifier and secret to the server via an out- 384 of-band means. The server then performs the necessary user 385 management dealing with identity validation and certificate setup. 386 If that passes and the ephemeral passes applicable public key 387 validation tests, then the certificate will be issued and the 388 response returned protected with ephemeral key. If it does not pass 389 checking then the certificate will fail to issue. An ephemeral is 390 generated by the client, to ensure PFS is provided as the client may 391 not get the same degree of confidentiality because the client is 392 unaware how the private key has been provided. 394 Note that there is no scenario where the response is protected with a 395 key/certificate that only supports digital signatures. This is 396 because the "protection" afforded by digital signatures alone does 397 not include confidentiality, which is required to ensure that the 398 server-generated private key is only disclosed to the client. 400 Note also that there is also no scenario where the client uses an 401 encryption-only certificate and is unable to generate a digital 402 signature to provide authentication. This is because the 404 I-D CMC Extensions: Server Side Key Generation March 27, 2014 406 "protection" afforded by encryption-only certificates does not 407 include authentication. Technically, there are Authenticated 408 Encryption with Associated Data (AEAD) algorithms (i.e., dual-service 409 algorithms) that support both authentication and encryption but their 410 use is beyond the scope of this document. 412 In all of the scenarios, the client can validate that the response 413 came from the CA or RA by validating the digital signature on the 414 SignedData to a Trust Anchor (TA). After the EnvelopedData is 415 decrypted, the client can 1) verify that the private key is 416 associated with the public key in the returned certificate and/or 2) 417 verify that the certificate validates back to an authorized TA. 419 The scenarios in the subsections assume that the transaction 420 identifier and nonce controls are used for transaction processing and 421 replay protection, respectively, but they are optional, as specified 422 in [RFC5272]. Also, the scenarios assume the CMC Status Information 423 v2 control is not included when the response is a success, as allowed 424 by [RFC5272]. See Appendix B for additional example scenarios. 426 A client requesting a certificate for a different name than one 427 already issued, either based on the certificate being used in 428 Scenarios 3 and 4 or the name associated with the shared secret in 429 Scenarios 1 and 2, includes the Change Subject Name attribute to 430 ensure the server will not reject the request because the name in the 431 certificate used to sign the request does not match the name in the 432 request. Note this is not depicted in the diagrams that follow 433 because the attribute is included within the ServerKeyGenRequest. 435 2.1. Shared Secret for Authentication and Key Protection 437 The shared secret allows the server to authenticate the client and 438 allows the server to encrypt the server-side generated key for the 439 client. The shared secret is distributed via an out-of-band 440 mechanism that is out-of-scope of this document. Also note the 441 server and client need to share a non-secret identification string 442 that the client can assert in a request so that the server will know 443 which shared secret is being used. 445 When the client generates its request, the client includes the 446 following control attributes in a PKIData content type [RFC5272]: 447 Server Key Generation Request (see Section 6.1), Transaction 448 Identifier [RFC5272], Sender Nonce [RFC5272], and Identification 449 [RFC5272]. The Server Key Generation Request control indicates that 450 the shroudMethod is shroud with shared-secret key (see Section 4.2). 451 The PKIData is encapsulated in a CMS AuthenticatedData content type 452 and the password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. 453 Note that reqSequence, cmsSequence, and otherMsgSequence are not 455 I-D CMC Extensions: Server Side Key Generation March 27, 2014 457 included in the PKIData for the server-side key generation request. 458 The following depicts this: 460 +----------------------------------------------------------------+ 461 |AuthenticatedData: RecipientInfo: pwri | 462 |+--------------------------------------------------------------|| 463 ||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)|| 464 || control: TransationID || 465 || control: SenderNonce || 466 || control: Identification || 467 |+--------------------------------------------------------------+| 468 +----------------------------------------------------------------+ 470 After the server authenticates the client and verified the request, 471 the server generates a response that includes the server-generated 472 key and any associated parameters in an Asymmetric Key Package 473 content type [RFC5958]. The Asymmetric Key Package is then 474 encapsulated within a SignedData, which is signed by the server, and 475 that is further encapsulated within an EnvelopedData using the 476 password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData, which 477 is encrypted for the client, is then placed in a PKIResponse 478 cmsSequence [RFC5272] and the following controls are included in the 479 PKIResponse: Transaction Identifier, Sender Nonce, Recipient Nonce 480 [RFC5272], and Server Key Generation Response (see Section 4.2). The 481 PKIResponse is then encapsulated in a SignedData, which is signed by 482 the server, and the client's certificate associated with the server- 483 generated key is placed in the outer-most SignedData's certificates 484 field [RFC5652]. The following depicts this: 486 +---------------------------------------------------------+ 487 |SignedData: Signed by the CA | 488 | Client's certificate in certificates field | 489 |+-------------------------------------------------------+| 490 ||PKIResponse: control: TransactionID || 491 || control: SenderNonce || 492 || control: RecipientNonce || 493 || control: ServerKeyGenResponse || 494 || || 495 || cmsSequence: || 496 || +----------------------------------------+|| 497 || |EnvelopedData: RecipientInfo: pwri ||| 498 || |+-----------------------------+ ||| 499 || ||SignedData: Signed by the CA | ||| 500 || ||+---------------------------+| ||| 501 || |||AsymmetricKeyPackage || ||| 502 || ||+---------------------------+| ||| 503 || |+-----------------------------+ ||| 504 || +----------------------------------------+|| 506 I-D CMC Extensions: Server Side Key Generation March 27, 2014 508 |+-------------------------------------------------------+| 509 +---------------------------------------------------------+ 511 2.2 Shared Secret for Authentication and Ephemeral Key for Protection 513 The shared secret allows the server to authenticate the client and 514 the ephemeral key allows the server to use a different key to encrypt 515 the server-side generated key for the client. The shared secret is 516 distributed via an out-of-band mechanism that is out-of-scope of this 517 document. Also note that the client needs an identification string 518 to allow the server to determine which shared secret is being used. 520 When the client provides an ephemeral key to protect the response, 521 the client includes the following control attributes in a PKIData 522 content type [RFC5272]: Server Key Generation Request control (see 523 Section 6.1), Transaction Identifier [RFC5272], Sender Nonce 524 [RFC5272], and Identification [RFC5272]. The Server Key Generation 525 Request control indicates that the shroudMethod is shroud with public 526 key and that the bareKey CHOICE is used (see Section 4.1). The 527 PKIData is encapsulated in an AuthenticatedData content type and the 528 password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note 529 that reqSequence, cmsSequence, or otherMsgSequence are not included. 530 The following depicts this: 532 +-------------------------------------------------------------+ 533 |AuthenticatedData: RecipientInfo: pwri | 534 |+-----------------------------------------------------------+| 535 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)|| 536 || control: TransationID || 537 || control: SenderNonce || 538 || control: Identification || 539 |+-----------------------------------------------------------+| 540 +-------------------------------------------------------------+ 542 After the server has authenticated the client and verified the 543 request, the server returns the server-generated key and any 544 associated parameters in an Asymmetric Key Package content type 545 [RFC5958]. The Asymmetric Key Package is then encapsulated within a 546 SignedData, which is signed by the server, and that is further 547 encapsulated within an EnvelopedData using the key agreement or key 548 transport RecipientInfo (i.e., kari or ktri CHOICE). The 549 EnvelopedData, which is encrypted for the client, is then placed in a 550 PKIResponse cmsSequence [RFC5272] and the following controls are 551 included: Transaction Identifier, Sender Nonce, Recipient Nonce 552 [RFC5272], and Server Key Generation Response (see Section 6.2). The 553 PKIResponse is then encapsulated in a SignedData, which is signed by 554 the server, and the certificate associated with the server-generated 555 key is placed in the outer-most SignedData's certificates field 557 I-D CMC Extensions: Server Side Key Generation March 27, 2014 559 [RFC5652]. The following depicts this: 561 +-----------------------------------------------------------+ 562 |SignedData: Signed by the CA | 563 | Client's certificate in certificates field | 564 |+---------------------------------------------------------+| 565 ||PKIResponse: control: TransactionID || 566 || control: SenderNonce || 567 || control: RecipientNonce || 568 || control: ServerKeyGenResponse || 569 || || 570 || cmsSequence: || 571 || +------------------------------------------+|| 572 || |EnvelopedData: RecipientInfo: kari or ktri||| 573 || |+------------------------------+ ||| 574 || ||SignedData: Signed by the CA | ||| 575 || ||+----------------------------+| ||| 576 || |||AsymmetricKeyPackage || ||| 577 || ||+----------------------------+| ||| 578 || |+------------------------------+ ||| 579 || +------------------------------------------+|| 580 |+---------------------------------------------------------+| 581 +-----------------------------------------------------------+ 583 2.3. Certificate for Authentication and Ephemeral Key for Protection 585 This scenario differs from the scenarios in Sections 2.1 and 2.2 in 586 that the client encapsulates the PKIData in a SignedData instead of 587 an AuthenticatedData (i.e., the client uses its private key 588 associated with its signature-capable certificate to sign the 589 PKIData) but is similar to Section 2.2 for the response. As implied 590 in [RFC5272], clients omit the Identification and Identity Proof 591 controls when using certificates to support digital signature 592 authentication. 594 When the client generates its request, the client includes the 595 following control attributes in a PKIData content type [RFC5272]: 596 Server Key Generation Request (see Section 6.1), Transaction 597 Identifier [RFC5272], and Sender Nonce [RFC5272]. The Server Key 598 Generation Request control indicates the shroudMethod is shroud with 599 public key and the bareKey CHOICE is used (see Section 4.1). The 600 PKIData is encapsulated in a SignedData content type [RFC5652]. Note 601 that reqSequence, cmsSequence, and otherMsgSequence are not included 602 in the PKIData for the server-side key generation request. The 603 following depicts this: 605 +--------------------------------------------------------------+ 606 |SignedData: Signed by the Client | 608 I-D CMC Extensions: Server Side Key Generation March 27, 2014 610 |+------------------------------------------------------------|| 611 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) || 612 || control: TransationID || 613 || control: SenderNonce || 614 |+------------------------------------------------------------+| 615 +--------------------------------------------------------------+ 617 After the server has authenticated the client and verified the 618 request, the server returns the server-generated key and any 619 associated parameters in an AsymmetricKeyPackage content type 620 [RFC5958]. The AsymmetricKeyPackage is then encapsulated within a 621 SignedData, which is signed by the server, and that is encapsulated 622 within an EnvelopedData using the key agreement or key transport 623 RecipientInfo (i.e., kari or ktri CHOICE). The EnvelopedData, which 624 is encrypted for the client, is then placed in a PKIResponse 625 cmsSequence [RFC5272] and the following controls are included: 626 Transaction Identifier, Sender Nonce, Recipient Nonce [RFC5272], and 627 Server Key Generation Response (see Section 6.2). The PKIResponse is 628 then encapsulated in a SignedData, which is signed by the server, and 629 the certificate associated with the server-generated key is placed in 630 the outer-most SignedData's certificates field [RFC5652]. The 631 following depicts this: 633 +-----------------------------------------------------------+ 634 |SignedData: Signed by the CA | 635 | Client's certificate in certificates field | 636 |+---------------------------------------------------------+| 637 ||PKIResponse: control: TransactionID || 638 || control: SenderNonce || 639 || control: RecipientNonce || 640 || control: ServerKeyGenResponse || 641 || || 642 || cmsSequence: || 643 || +------------------------------------------+|| 644 || |EnvelopedData: RecipientInfo: kari or ktri||| 645 || |+-----------------------------+ ||| 646 || ||SignedData: Signed by the CA | ||| 647 || ||+---------------------------+| ||| 648 || |||AsymmetricKeyPackage || ||| 649 || ||+---------------------------+| ||| 650 || |+-----------------------------+ ||| 651 || +------------------------------------------+|| 652 |+---------------------------------------------------------+| 653 +-----------------------------------------------------------+ 655 2.4. Certificate for Authentication and Key Protection 657 If a client already has been issued a signature-capable certificate, 659 I-D CMC Extensions: Server Side Key Generation March 27, 2014 661 then it can use this certificate to authenticate the requests. If 662 the certificate also indicates support for encryption (i.e., the key 663 usage extension is set to keyEncipherment or keyAgreement), then the 664 client can request that the server use the same certificate to 665 protect the server-generated key (see Section 2.4.1). If the 666 certificate does not indicate support for encryption, then the client 667 can provide the server with another certificate to use to encrypt the 668 server-generated key (see Section 2.4.2). The certificate that 669 protects the server-generated key MUST be encryption-capable. 671 These scenarios differ from the scenarios in Section 2.3 in that the 672 response is protected with a previously certified key instead of an 673 ephemeral key. As specified in [RFC5272], clients omit the 674 Identification and Identity Proof controls when using certificates to 675 support digital signature authentication. 677 2.4.1. Same Certificate for Authentication and Key Protection 679 This scenario is the same as in Section 2.3. except the Server Key 680 Generation Request control includes the certificate or certIdentifier 681 CHOICE instead of the bareKey CHOICE. The certidentifier is 682 sufficient information for the server since the same certificate will 683 have already been used for verifying the encapsulating SignedData. 685 2.4.2. Different Certificates for Authentication and Key Protection 687 This scenario is the same as in Section 2.3. except the Server Key 688 Generation Request control includes the certificate CHOICE instead of 689 the bareKey CHOICE. When using two certificates, the names in the 690 two certificates MUST match to ensure the CA will not reject the 691 request due to name mismatches. 693 2.5. RA Scenarios 695 In Sections 2.1-2.4, client-to-CA protocol flows were illustrated 696 where the CA generates the client's key and no RA was involved. This 697 section illustrates client-to-RA-to-CA protocol flows. The scenarios 698 divide into two basic categories, according to whether the RA or the 699 CA generates the key pair. 701 Regardless of whether the RA or the CA generates the request, the 702 intent of the RA here is to be transparent. That is, client's 703 initial the same request regardless of the entity that ultimately 704 generates the keys. 706 When the RA generates the key on behalf of the client, the RA fleshes 707 out the taggedRequst from the client with the RA-generated public key 708 and applies POP with the corresponding private key. This becomes the 710 I-D CMC Extensions: Server Side Key Generation March 27, 2014 712 requestSequences in a new PKIData that the RA will send to the CA, 713 and that repeats the controls received from the client. Then the PA 714 signs the new PKIData with its own signing key. In this way, the RA 715 effectively becomes the client from the CA's perspective. However, 716 the RA and CA already have an established trust relationship (i.e., 717 the RA has been issued a certificate from the CA), which might not be 718 true for the client. The protocol exchange between the RA and CA is 719 identical to a client enrolling with a CMC Full PKI Request; 720 therefore, the CA need not know about or support the Server Key 721 Generation Request and Server Key Generation Response controls. The 722 PKIResponse to the client now has to accommodate the fact that the 723 asymmetric key package is generated by the RA, whereas the 724 certificate is generated by the CA. This necessitates that the RA 725 intercepts whatever response the CA returns to get the client's 726 certificate and that the RA generates a signed response that includes 727 the asymmetric key package as well as the client's certificate. See 728 section 9 for security considerations. 730 When the RA participates in the process but does not generate the 731 key, there are two possibilities. If the RA does not contribute to 732 the protocol (its effects may be procedural or out-of-band), then it 733 can simply pass the messages it receives to the other party when 734 warranted. If that is not warranted, the RA would generate the usual 735 response for the associated failure. No message flow for this 736 possibility is included. Alternatively, the RA may be responsible 737 for processing certain aspects of the request, and needs to vouch for 738 that when forwarding the client request to the CA. The RA does this 739 per [RFC5272] by embedding the client request in a Full PKI Request 740 that it signs, containing controls for the processing that it 741 performs. Here, as in Sections 2.1-2.4, the CA needs to fully 742 understand and support the Server Key Generation Request and Server 743 Key Generation Response controls, since the CA has to generate the 744 key and construct the asymmetric key package. 746 In the figures that follow, SKGReq is the Server Key Generation 747 Request control (see Section 6.1), the SKGRes denotes the Server Key 748 Generation Response control (see Section 6.2), TransactionId denotes 749 the Transaction Identifier control [RFC5272], SenderNonce denotes the 750 Sender Nonce control [RFC5272], RecipientNonce denotes the Recipient 751 Nonce control [RFC5272]. AKP denotes an Asymmetric Key Package 752 [RFC5958] (i.e., the private key). Also, {} denotes encryption 753 (i.e., EnvelopedData), <> denotes signatures (i.e., SignedData), with 754 () identifying some of the information is carried in unsignedAttrs 755 for clarity, and [] denotes authentication (i.e., SignedData or 756 AuthenticatedData). AuthenticatedData is used when clients use a 757 shared secret for authentication. control denotes controlSequence, 758 reqSeq denotes requestSequence, and cmsSeq denotes cmsSequence. 759 PKCS#10 [RFC2986], CRMF (Certificate Request Message Format) 761 I-D CMC Extensions: Server Side Key Generation March 27, 2014 763 [RFC4211], and other request message [RFC5272] are the certification 764 request formats supported. 766 2.5.1. RA-Generated Key Scenarios 768 There are some differences in the protocol flows when an RA generates 769 the key: 771 o The RA MUST be issued a certificate from the CA. This means all 772 of the RA-generated PKIData are encapsulated in a SignedData. 773 Further, the RA's certificate can be used for identification and 774 linking identity and POP information. 776 o The RA generates the certification request for the client by: 778 1. Using the name from the certificate for the key the RA will 779 use to sign the PKIData. 781 2. Using the information from the client's request. 783 3. The RA includes the Change Subject Name control [RFC6402] 784 either in the PKCS #10 or CRMF TaggedRequest because the name 785 in the certificate used for verifying the PKIData signature 786 must match the name in the certificate request. The Change 787 Subject Name attribute allows the names to be different. 789 4. Modifying the taggedRequest as necessary. Notably adding the 790 public key but also adding certificate extensions, etc. Note 791 that the Modify Certificate Template control is not needed as 792 the RA is generating a new PKIData. 794 5. Generating the POP information for the certificateRequest 795 containing the RA-generated keys. For keys that support 796 digital signatures, the RA includes the POPSigningKey in the 797 CRMF or the signature in the PKCS #10. For encryption-only 798 keys, the RA can indicate that it performed POP by including 799 the RA POP Witness control. Note the CA could force the RA to 800 prove it has possession of the key with the 801 encrypted/decrypted POP mechanism for [RFC5272], but this adds 802 additional round trips and is discussed later in this section. 804 6. Signing the certification request (i.e., the PKIData) with the 805 RA's private key. 807 The RA can also generate bulk requests (i.e., include more than one 808 request in cmsSequence) with the Bulk Request control [RFC5272] but 809 these controls are not depicted in the following sections to simplify 810 the protocol flows. When the RA is requesting more than one key for 812 I-D CMC Extensions: Server Side Key Generation March 27, 2014 814 a given client, the RA includes each request in the reqSequence. 816 The following message flow applies when the RA generates the key. It 817 supports all of the previously defined choices for authentication and 818 shrouding. The diagram below depicts use of a shared secret for 819 authentication by including the Identification control and 820 encapsulating the client's PKIData in an AuthenticatedData. If a 821 digital signature is used for authentication, the Identification 822 control is omitted and the client encapsulates its PKIData in a 823 SignedData. 825 Client RA CA 826 | | | 827 |----------------->| | 828 | [PKIData | | 829 | control: SKGReq, | | 830 | TransactionID, | | 831 | SenderNonce, | | 832 | Identification] | | 833 | |-------------------------------------->| 834 | | | 837 | | (RA signed) | 838 | |<--------------------------------------| 839 | | 842 | | (CA signed includes issued 843 |<-----------------| client certificate) 844 | }> 847 | (RA signed PKIResponse with CA-issued client certificate) 849 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 851 NOTE: There's no need for the RA to provide the SKGReq or the {} 852 to the CA. The CA won't be able to access the contents of the 853 {} because it's encrypted for the client and the CA's response 854 is always returned to the RA because the RA needs to provide the 855 generated {} back to the client. 857 Whether the client's PKIData is encapsulated in a SignedData or 858 AuthenticatedData depends on whether the client used a certificate or 859 shared secret for authentication, respectively. Additionally, the 860 RecipientInfo for the EnvelopedData encapsulating the depends 861 on whether the key was protected with a shared secret (pwri), 863 I-D CMC Extensions: Server Side Key Generation March 27, 2014 865 ephemeral key (ktri or kari), or certificate (ktri or kari). 867 The RA intercepts the response from the CA; it strips the CA's 868 signature and creates a new PKIResponse for the client. The 869 controlSequence is comprised of the Transaction Identifier and 870 Recipient Nonce fields from the client's request, the RA's Sender 871 Nonce, and the Server Key Generation Response (see Section 6.2); the 872 cmsSequence includes the RA-generated {}; and the RA signs the 873 PKIRepsonse and includes the client's certificate, which was returned 874 in the CA's SignedData. 876 When the RA is generating an encryption-only key pair for the client, 877 and the CA wishes to force the RA to prove it has possession of the 878 private key, but the RA cannot use it to generate a one-time 879 signature, then the flow is as follows: 881 Client RA CA 882 | | | 883 |----------------->| | 884 | [PKIData | | 885 | control: SKGReq, | | 886 | TransactionID, | | 887 | SenderNonce, | | 888 | Identification] | | 889 | |--------------------------------------->| 890 | | | 894 | |<---------------------------------------| 895 | | | 899 | |--------------------------------------->| 900 | | | 903 | |<---------------------------------------| 904 | | 907 | }>> 911 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 913 I-D CMC Extensions: Server Side Key Generation March 27, 2014 915 NOTE: The number of round trips between the RA and CA in the above 916 figure is twice as many as the first figure in this Section and in 917 Section 2.5.1.1; however, the additional round trip is specified in 918 [RFC5272] (i.e., this document does not introduce the additional 919 round trip). The additional round trip is necessary when the CA 920 forces the RA to perform POP with the CA. While the additional round 921 trip might be problematic between the client and server, the quality 922 of communication connectivity between RA and CA should not make the 923 additional round trips as problematic as between clients and RAs or 924 CAs. 926 2.5.2. RA-Involved Scenarios 928 This section illustrates a message flow for when the CA generates the 929 client's key. Here too the RA MUST be issued a certificate from the 930 CA, which means that all of the RA-generated PKIData are encapsulated 931 in a SignedData. Further, the RA's certificate can be used for 932 identification and linking identity and POP information and the RA 933 can include the RA Identity Witness control to tell the CA that it 934 performed the client identity checks; the RA will omit the control if 935 it does not perform these checks. 937 The RA can include a Modify Certification Request control [RFC5272] 938 in the PKIData that encapsulates the client's request but these 939 controls are not shown below. The RA does this when it wishes to 940 modify the request present in the Server Key Generation Request 941 control. The RA MUST NOT use the RA POP Witness control if the CA is 942 to generate the key. This control indicates that the RA performed 943 POP, but the key for which POP is claimed has not yet been generated. 945 The diagram below depicts the client's use of a shared secret for 946 authentication by including the Identification control and 947 encapsulating the client's PKIData in an AuthenticatedData. If a 948 digital signature is used for authentication, the Identification 949 control is omitted and the client's PKIData is encapsulated in a 950 SignedData. The RA encapsulates the client's request in its PKIData 951 by placing the client request in the cmsSequence, and includes 952 controls such as Transaction Identifier and Sender Nonce controls as 953 well as RA Identity Witness control if the RA checks the client's 954 identity. 956 Client RA CA 957 | | | 958 |----------------->| | 959 | [PKIData | | 960 | control: SKGReq, | | 961 | TransactionID, | | 962 | SenderNonce, | | 964 I-D CMC Extensions: Server Side Key Generation March 27, 2014 966 | Identification] | | 967 | |--------------------------------------->| 968 | | | 974 | |<---------------------------------------| 975 | | } > 982 | | (CA signed includes issued 983 | | client certificate) 984 |<-----------------| > (CA signed) 985 | }> 988 | (CA signed with issued client certificate) 990 When the RA receives the request from the CA, it strips the CA's 991 response for the RA off and passes the inner response to the client 992 unchanged. The difference between this scenario and the scenarios in 993 Section 2.5.1 is that the signature on the PKIResponse is generated 994 by the CA not the RA. 996 Note that the additional round trips to prove possession of an 997 encryption-only key depicted in Section 2.5.1 are unnecessary here 998 because the CA generates the asymmetric key pair and it does not need 999 to prove to itself that it has the keys. 1001 3. Generating PKIData and PKIResponse 1003 [RFC5272] defines PKIData as follows (included here for convenience): 1005 PKIData ::= SEQUENCE { 1006 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1007 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 1008 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1009 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1010 } 1012 [RFC5272] defines PKIResponse as follows (included here for 1013 convenience): 1015 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1017 PKIResponse ::= SEQUENCE { 1018 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1019 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1020 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1021 } 1023 3.1. Client Requests 1025 When the client generates its request, the Server Key Generation 1026 Request control (see Section 6.1) is included in controlSequence; the 1027 other sequences (i.e., reqSequence, cmsSequence, and 1028 otherMsgSequence) are omitted. If a shared secret is used for 1029 authentication, the Identification control [RFC5272] is included in 1030 the controlSequence to ensure that the server can locate the shared- 1031 secret needed to authenticate the request. Additional controls can 1032 be included in controlSequence such as Sender Nonce and Transaction 1033 Identifier [RFC5272]. The reqSequence, which is included for client- 1034 generated key certification requests, is not needed as the Server Key 1035 Generation Request control includes the certification request. The 1036 client's request is either encapsulated in an AuthenticatedData or a 1037 SignedData depending on whether the client is using a shared secret 1038 or a digital signature key to authenticate the request. If the 1039 client wishes to request a certificate with a different name than the 1040 one that is present in the certificate that authenticates the request 1041 or associated with the shared secret, the client must nevertheless 1042 populate the certificateRequest with the Subject Name used in the 1043 existing certificate, and then include the Change Subject Name 1044 control to identify the Subject Name that is desired instead. 1045 Otherwise the server will reject the request as required in 1046 [RFC6402]. 1048 3.2. RA Processing of Client Requests 1050 If an RA is involved, then it can do the following: 1052 o Forward the request as-is to the CA. This happens when the CA 1053 authenticates the request, performs the identity checks, and 1054 generates the keys. 1056 o Authenticate or not the request and place one or more client- 1057 authenticated PKIData in cmsSequence; reqSequence and 1058 otherMsgSequence are omitted. Here the RA does not have the 1059 shared secret necessary to authenticate the request. The RA can 1060 also include additional controls in controlSequence such as the 1061 Modify Certification Request control if the RA needs to modify 1062 the client's request and the Sender Nonce and Transaction 1063 Identifier controls for replay protection and transaction 1065 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1067 processing. If the RA performs the Identity checks it can 1068 include the RA Identity Witness control [RFC6402] otherwise it is 1069 omitted. After generation of its PKIData, the RA encapsulates it 1070 in a SignedData as part of the digital signature process. 1072 o Authenticate the request and generate the client's keys. When 1073 the RA generates the client's key, the RA generates a new PKIData 1074 with a reqSequence; cmsSequence and otherMsgSequence are omitted. 1075 The RA must assert its own name as the Subject Name in the 1076 certificateRequest, and include the Change Subject Name attribute 1077 carrying the intended client name, as specified in [RFC6402], in 1078 the PKCS#10 or CRMF because [RFC6402] requires that the name in 1079 the request will match the name in the certificate used to 1080 authenticate the request. If the RA-generated key is signature- 1081 capable, POP is provided in the typical fashion (i.e., the 1082 embedded CRMF or PKCS#10 request includes the POP). The RA can 1083 also include additional controls in controlSequence such as 1084 Sender Nonce and Transaction Identifier. After generation of its 1085 PKIData, the RA encapsulates it in a SignedData as part of the 1086 digital signature process. 1088 o Reject the client's request and return a PKIResponse with an 1089 appropriate reason in the CMC Status Information V2 control. 1090 Additionally, the RA includes Transaction Identifier, Sender 1091 Nonce, and Recipient Nonce if the request included Transaction 1092 Identifier and Sender Nonce controls. The PKIResponse is 1093 encapsulated in a SignedData as part of the digital signature 1094 process. This document defines three additional error conditions 1095 (see Section 7): 1097 * For a Server Key Generation Request control using the 1098 ShroudWithPublicKey choice of certificate or certIdentifier, 1099 the RA can check that the certificate provided to protect the 1100 returned private key validates back to an authorized TA. If 1101 the certificate does not validate back to its TA, then the RA 1102 returns a PKIResponse with a CMC Status Information v2 control 1103 indicating the request failed with an extendedFailInfo 1104 indicating badCertificate (see Section 7) encapsulated in a 1105 SignedData. Note that the RA performing this check will lessen 1106 the load on the CA, but it need only be done by the RA when the 1107 RA is generating the client's keys; when the CA is generating 1108 the keys technically it's up to the CA to perform this check if 1109 it receives a CA-generated key request from a client. 1111 * For a Server Key Generation Request control using the 1112 ShroudWithSharedSecret choice and where the RA knows the shared 1113 secret, the RA will reject the request if the shared secret 1114 does not match the one on the RA by returning a PKIResponse 1116 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1118 with a CMC Status Information control indicating the request 1119 failed with an extendedFailInfo indicating badSharedSecret (see 1120 Section 7) encapsulated in a SignedData. This is done because 1121 client authentication failed or the HMAC output was corrupted. 1123 * For a Server Key Generation Request control that has archiveKey 1124 set to TRUE, the RA is generating the client's keys, and the RA 1125 does not support archive, the RA will reject the request by 1126 returning a PKIResponse with a CMC Status Information v2 1127 control indicating the request failed with an extendedFailInfo 1128 indicating archiveNotSupported (see Section 7) encapsulated in 1129 a SignedData. If the RA knows the CA also does not support 1130 archival of keys, the RA, if it wishes, can reject the request 1131 in the same fashion; when the CA is generating the keys, 1132 technically it is up to the CA to perform this check if it 1133 receives a CA-generated key request from a client. Note that 1134 the RA performing this check will lessen the load on the CA, 1135 but it need only be done by the RA when the RA is generating 1136 the client's keys. 1138 RA's can also batch more than one request together, by including each 1139 client request in a separate cmsSequence or reqSequence (for Simple 1140 PKI requests) along with a Batch Request control in the RA's 1141 PKIRequest control field. After generation of the PKIData, the RA 1142 encapsulates it in a SignedData as part of the digital signature 1143 process. 1145 When verifying SignedData signatures, the RA verifies it back to an 1146 authorized TA. 1148 3.3. CA Processing 1150 CA processing of requests depends on the number of layers of 1151 encapsulation: 1153 o Requests with a single layer of encapsulation will be validated 1154 back to an authorized TA if they are encapsulated in a SignedData 1155 or authenticated with the shared secret if they are encapsulated 1156 in an AuthenticatedData. For AuthenticatedData encapsulated 1157 requests the server locates the necessary shared secret with the 1158 information found in the Identification control. For a 1159 PKIRequest with a reqSequence, the server verifies the POP. 1160 Regardless of the encapsulation technique, the server performs 1161 the Identity checks and processes other controls such as 1162 Transaction Identifier and Sender Nonce. If any of these checks 1163 fail or processing of a control fails, the CA rejects the 1164 certification request with the appropriate error code, as 1165 specified in [RFC5272]. 1167 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1169 o Requests with multiple layers of encapsulation (i.e., those 1170 requests that are RA-involved) will first validate the signature 1171 on the outer SignedData back to an authorized TA and process any 1172 controls present such as RA Identity Witness, Modify Certificate 1173 Template, Sender Nonce, and Transaction Identifier, as per 1174 [RFC5272][RFC6402]. Inner requests are also processed as 1175 specified in the previous bullet. Failure to validate back to an 1176 authorized TA or control processing failures result in rejected 1177 requests with the appropriate error code, as specified in 1178 [RFC5272]. 1180 CAs may require that the RA prove that it has possession of 1181 encryption-only keys that do not support one-time signature use, by 1182 returning a PKIResponse indicating the request failed because POP is 1183 required and including the Encrypted POP control along with other 1184 appropriate controls. The response is signed by the CA. See Section 1185 2.5.1. 1187 After successfully authenticating the request and verifying the 1188 client's identity, the CA generates: 1190 o Responses for single layer encapsulated requests for RA-generated 1191 keys by issuing the certificate. If no controls were present in 1192 the request (see Appendix B), the PKIResponse is a Simple PKI 1193 Response [RFC5751], which includes no content and therefore no 1194 signature. With controls (e.g., Transaction Identifier, Sender 1195 Nonce, and Recipient Nonce), the PKIResponse includes the 1196 appropriate controls and is signed by the CA. The CA places the 1197 certificate in the SignedData certificates field. 1199 o Responses for multi-layered encapsulation requests for RA- 1200 generated keys (See Appendix B) beginning as with the previous 1201 bullet to form the inner response. This is placed in 1202 cmsSequences of the outer PKIResponse, which also includes the 1203 Batch Response control as well as any other necessary controls in 1204 controlSequence. The CA generates a signature for the 1205 encapsulating SignedData. 1207 o Responses for single layer encapsulated requests for CA-generated 1208 keys by generating the asymmetric key pair and issuing the 1209 certificate. The signed CA-generated PKIResponse includes the 1210 Server Key Generation Response control (see Section 6.2) along 1211 with other controls based on whether they were present in the 1212 controlSequence as well as the signed and then encrypted 1213 Asymmetric Key Package in cmsSequence. The CA places the 1214 certificate in the SignedData certificates field. 1216 o Responses for multi-layered encapsulation requests for CA- 1218 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1220 generated keys beginning with the previous bullet followed by 1221 encapsulating the inner response in cmsSequence for the outer 1222 PKIResponse. The outer response also includes controls as 1223 necessary in controlSequence and the CA generates a signature for 1224 an encapsulating SignedData. 1226 In all cases, the certificate issued is an X.509 certificate 1227 [RFC5280]. 1229 If the CA is unable to perform the request at this time or the entire 1230 request cannot be processed, it can return a signed PKIResponse 1231 indicating with a CMC Status Information control with a status of 1232 pending or partial along with pendInfo, which the client or RA uses 1233 to know when to ask the CA next about the request. 1235 When the CA fails to or refuses to process the request, it returns a 1236 PKIResponse with a CMC Status Information control with the 1237 appropriate error code from [RFC5272] or from Section 7 of this 1238 document. Additionally, it includes Transaction Identifier, Sender 1239 Nonce, and Recipient Nonce in the response if the request included 1240 Transaction Identifier and Sender Nonce controls. 1242 3.4. RA Processing of CA Responses 1244 If the CA rejected the RA's request as indicated by a PKIResponse 1245 with CMC Status Information control that indicates "failed", then an 1246 out-of-band mechanism may be necessary to determine the cause of 1247 failure in order to avoid a loop of the RA returning the same request 1248 at a later time only to also have it rejected. 1250 If the CA returned a pending or partial response, the RA will use the 1251 information in the CMC Status Information control's pendInfo to poll 1252 the CA with a signed PKIRequest with a Query Pending control. CA 1253 processing continues as in Section 3.3. 1255 RA's that are challenged by the CA to prove possession of an 1256 encryption-only RA-generated key validate the CA's signature back to 1257 an authorized TA, decrypt the POP, and process any other controls 1258 that are present. If any of these fail, then the RA terminates the 1259 request and informs the operator of the fault. Assuming the checks 1260 pass, the RA generates a PKIData that includes a Decrypted POP 1261 control and any other controls with no cmsSequence, reqSequence, or 1262 otherMsgSequence. The RA encapsulates the PKIData in a SignedData as 1263 part of the digital signature process and sends it to the CA. CA 1264 processing resumes as in Section 3.3. 1266 Assuming the response is a success: 1268 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1270 o If there is no signature, either the keys are RA-generated or are 1271 CA-generated. If the keys are CA-generated, then the RA returns 1272 the message to the client unmodified. If the key is RA- 1273 generated, the RA generates a PKIResponse for the client that 1274 includes the signed and then encrypted Asymmetric Key Package in 1275 cmsSequence (see Section 5), the Server Key Generation Response 1276 control (see Section 6.2), and any other controls. Finally, the 1277 RA encapsulates the PKIResponse for the client in a SignedData as 1278 part of the digital signature process and includes the client's 1279 certificate (from the CA) in the SignedData's certificate field. 1281 o If there is a signature: 1283 * The response is for an RA-generated key request that contained 1284 controls and the RA knows this by the presence of the 1285 Transaction Identifier, Sender Nonce, or Recipient Nonce 1286 controls (and possibly other controls) but there is no 1287 cmsSequence or CMC Status Information control indicating the 1288 request failed or is pending. The RA generates a PKIResponse 1289 for the client that includes the signed and then encrypted 1290 Asymmetric Key Package in cmsSequence (see Section 5), the 1291 Server Key Generation Response control (see Section 6.2), and 1292 any other controls as appropriate. Finally, the RA 1293 encapsulates the PKIResponse for the client in a SignedData as 1294 part of the digital signature process and includes the client's 1295 certificate from the CA's response in the RA's SignedData 1296 certificates field. 1298 * The response is for a request where the CA generated the key 1299 and the RA knows this by the presence of a cmsSequence element. 1300 The RA processes any controls and assuming the processing 1301 passes the RA strips off the outer SignedData and forwards the 1302 cmsSequence element (i.e., the SignedData) to the client. 1304 * The response is for a batch request and the RA knows this by 1305 the presence of a Batch Response control. The RA process any 1306 controls and assuming the processing passes the RA strips off 1307 the outer SignedData and forwards the inner SignedData(s) from 1308 the cmsSequence to the appropriate clients. If any of the 1309 requests are marked as failed or pending, then the processing 1310 earlier in this section applies. 1312 The RA, if it wishes, can also check the returned certificate to make 1313 sure it validates back to an authorized TA and that the returned 1314 certificate is consistent with the certificate request found in the 1315 Server Key Generation Request control. These checks cut down on 1316 errors at the client. If the RA detects that the certificate is not 1317 consistent, the RA SHOULD NOT return the certificate to the client 1319 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1321 and the RA SHOULD request that the certificate be revoked. 1323 RA-generated keys for which a PKIResponse with a CMC Status 1324 Information control that is not success SHOULD NOT return the Server 1325 Key Generation Response or the encapsulated Asymmetric Key Package to 1326 the client because the CA didn't certify the public key. 1328 3.5. Client Processing of Responses 1330 Clients validate the signature on all responses back to an authorized 1331 TA. 1333 Responses signed by an RA with a client certificate signed by a CA 1334 whose certificate includes a id-kp-cmcCA EKU (Extended Key Usage) 1335 [RFC6402] will violate the "SHOULD" requirement found in [RFC6402] 1336 that the PKIResponse be signed by an entity with the same name as 1337 found in the certificate. Because the RA has generated the keys 1338 there are many more bad things an RA can do so this seemed like a 1339 tradeoff worth making. 1341 4. Shrouding Algorithms 1343 For the server-side key generation control attribute described in 1344 this document to function, clients need to tell the server in advance 1345 what encryption algorithm and what key value is to be used for 1346 encrypting the returned private key. The encrypted data returned is 1347 returned as an EnvelopedData object as defined by [RFC5652] and 1348 placed in the cmsSequence field of a PKIResponse [RFC5272]. Clients 1349 also need to tell the server what digital signature and hash 1350 algorithms it supports to ensure the certification response and 1351 certificate can be verified. 1353 Each request control for which the response includes encrypted data 1354 contains two fields to define type of encryption used: 1355 algCapabilities and shroudMethod. 1357 The algCapabilities field, see Section 6.1, contains the advertised 1358 capabilities of the client-side entity. This field uses the S/MIME 1359 Capabilities type defined in section 2.5.2 of [RFC5751]. The 1360 capabilities to be listed are digital signature algorithms, message 1361 digest algorithms, content encryption algorithms, key agreement 1362 algorithms, key encipherment algorithms, key-wrap algorithms and key 1363 derivation algorithms. Encodings for SMIME Capability values for 1364 Elliptic Curve Key Agreement, Key Derivation Function, and Key Wrap 1365 algorithms can be found in [RFC5753], Message Digest and Signature 1366 algorithms can be found in [RFC5754], and AES Key Wrap with Padding 1367 can be found in [RFC5959]. 1369 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1371 The shroudMethod field (see Section 6.1) defines the method by which 1372 the server will do the key management of the content encryption key 1373 (CEK) value in EnvelopedData. The shroudMethod field uses the type 1374 ShroudMethod. This type is defined as: 1376 ShroudMethod ::= AlgorithmIdentifier { 1377 SHROUD-ALGORITHM, { ShroudAlgorithmSet } 1378 } 1380 When a new shroud method is defined it includes (a) the source of the 1381 key material, (b) the public or salting information, and (c) the 1382 method of protecting the Content Encryption Key (CEK) using the 1383 requested data, source key material and salt. This document defines 1384 two shroud methods: id-cmc-shroudWithPublicKey and id-cmc- 1385 shroudWithSharedSecret. Clients and servers MUST support id-cmc- 1386 shroudWithPublicKey. Client and servers SHOULD support id-cmc- 1387 shroudWithSharedSecret. 1389 Other shrouding methods could be defined in the future that would not 1390 involve the use of EnvelopedData. For example, one could conceive of 1391 a shrouding method that required the use of Transport Layer Security 1392 (TLS) [RFC5246] to provide the necessary security between the server 1393 and the client. This document does not define any such mechanism. 1395 4.1. Shroud with a Public Key 1397 Clients can indicate that the server use a public key, either wrapped 1398 in a certificate or as a bare public key, to protect the server- 1399 generated key. For this option, the key material is either included 1400 or referenced by a key identifier. The following object identifier 1401 identifies the shroudWithPublicKey shroud method: 1403 id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= { id-cmc XX } 1405 shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey: 1407 srda-shroudWithPublicKey SHROUD-ALGORITHM ::= { 1408 IDENTIFIED BY id-cmc-shroudWithPublicKey, 1409 PARAMS TYPE ShroudWithPublicKey ARE required, 1410 SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithPublicKey } 1411 } 1413 ShroudWithPublicKey ::= CHOICE { 1414 certificate Certificate, 1415 certIdentifier [1] SignerIdentifier, 1416 bareKey [2] SEQUENCE { 1417 publicKey SubjectPublicKeyInfo, 1418 ski SubjectKeyIdentifier 1420 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1422 } 1423 } 1425 The fields of type ShroudWithPublicKey have the following meanings: 1427 o certificate provides a public key certificate containing the 1428 public key to be used for encrypting the server-generated private 1429 key from the server to the client. 1431 o certIdentifier provides a pointer to a public key certificate 1432 located in the SignedData that encapsulates the client's PKIData. 1434 For the above two fields, servers SHOULD check that the subject 1435 and, if included, subject alternative names match in some way 1436 with the entity that the private key is destined for. Servers do 1437 this to ensure the key they have made for the client is intended 1438 for the correct client. This mechanism is beyond the scope of 1439 this document. 1441 o bareKey allows for an arbitrary public key to be used to return 1442 the encrypted private key. 1444 - publicKey contains the public key that is to be used for 1445 encrypting the private key returned from the server to the 1446 client. 1448 - ski contains the SubjectKeyIdentifier that will be used in CMS 1449 EnvelopedData to identify the public key when encrypting the 1450 private key from the server to the client. 1452 When this method is used with the certificate option, the server 1453 validates the certificate back to a trust anchor. Further, the 1454 server checks that the client provided certificate belongs to the 1455 same client that authenticated the certification request (e.g. the 1456 certificate subjects match, or the client provided certificate 1457 belongs to the same entity as the authentication shared secret). If 1458 either of these checks fails, then the server returns a CMCFailInfo 1459 with the value of badCertificate, which is defined in Section 7. 1461 4.2. Shroud with a Shared-Secret Key 1463 Clients can indicate that servers use a shared secret value to 1464 protect the server-generated private key. For this option, the key 1465 material is identified by the identifier; the key derivation 1466 algorithms supported by the client are included in the 1467 algCapabilities field. No salting material is provided by the 1468 client. The derived key is then used as a key encryption key in the 1469 EnvelopedData recipient info structure. The following object 1471 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1473 identifier identifies the shroudWithSharedSecret control attribute: 1475 id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX} 1477 shroudWithSharedSecret attribute values have the ASN.1 type 1478 ShroudWithSharedSecret: 1480 shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= { 1481 IDENTIFIED BY id-cmc-shroudWithSharedSecret 1482 PARAMS TYPE ShroudWithSharedSecret ARE required 1483 SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithSharedSecret } 1484 } 1486 ShroudWithSharedSecret ::= UTF8String 1488 The client includes an identifier in the ShroudWithSharedSecret 1489 field, which is an UTFString [RFC5280], that the server uses to 1490 locate the shared secret to be used to protect the returned server- 1491 generated private key. The secret identified by the 1492 ShroudWithSharedSecret field may be different than the secret 1493 referred to by the identification control, which is used to identify 1494 the shared secret used to authenticate the request. In addition, the 1495 client needs to place both a key derivation function and a key wrap 1496 function in the set of capabilities advertised by the client in the 1497 algCapabilities field. 1499 When this method is used, the server checks that the chosen shared 1500 secret belongs to the authenticated identity of the entity that 1501 generated the certification request. If this check fails, then the 1502 server returns a CMCFailInfo with the value of badSharedSecret, which 1503 is defined in Section 7. In general, while it is expected that the 1504 same identity token and shared secret used to do the identity 1505 authentication are used to derive the key encryption key this is not 1506 required. 1508 5. Returned Key Format 1510 The server returns the private key and optionally the corresponding 1511 public key to the client with the AsymmetricKeyPackage content type 1512 [RFC5958]. The AsymmetricKeyPackage is first encapsulated in a 1513 Cryptographic Message Syntax (CMS) SignedData content type [RFC5652], 1514 then the inner SignedData is further encapsulated in an EnvelopedData 1515 content type [RFC5652], and finally the EnvelopedData is encapsulated 1516 in an outer SignedData. The Content Hints attribute [RFC2634] can be 1517 used in the outer SignedData to provide a hint as to the inner most 1518 content type (i.e., the AsymmetricKeyPacakge). There MUST be only 1519 one OneAsymmetricKey present in the AsymmetricKeyPackage sequence. 1520 When more than one private key is to be returned, multiple 1522 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1524 AsymmetricKeyPackage content types are needed. For example, when 1525 returning more than one private key the separate AsymmetricKeyPackage 1526 content types can be individually encapsulated in SignedData, 1527 packaged together with the ContentCollection content type [RFC4073], 1528 protected with an EnvelopedData around the ContentCollection, and 1529 finally the EnvelopedData is encapsulated in a SignedData. The 1530 public key SHOULD be included in the AsymmetricKeyPackage. 1532 6. Server-Side Key Generation 1534 This section provides the control attributes necessary for doing 1535 server-side generation of keys for clients. The client places the 1536 request for the key generation in a request message and sends it to 1537 the server. The server will generate the key pair, create a 1538 certificate for the public key and return the data in a response 1539 message, or the server will return a failure indication. 1541 6.1. Server-Side Key Generation Request Attribute 1543 The client initiates a request for server-side key generation by 1544 including the server-side key generation request attribute in the 1545 control attributes section of a PKIData object. The request 1546 attribute includes information about how to return the generated key 1547 as well as any client suggested items for the certificate. The 1548 control attribute for doing server-side key generation is identified 1549 by the following OID: 1551 id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX } 1553 The Server-Side Key Generation Request control attribute has the 1554 following ASN.1 definition: 1556 cmc-serverKeyGenRequest CMC-CONTROL ::= { 1557 ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest 1558 } 1560 ServerKeyGenRequest ::= SEQUENCE { 1561 certificateRequest TaggedRequest, 1562 shroudMethod ShroudMethod, 1563 algCapabilities SMimeCapabilties OPTIONAL, 1564 archiveKey BOOLEAN DEFAULT TRUE 1565 } 1567 The fields in ServerKeyGenRequest have the following meaning: 1569 o certificateRequest contains the data fields that the client 1570 suggests for the certificate being requested for the server 1571 generated key pair. The format is TaggedRequest from [RFC5272], 1573 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1575 which supports both PKCS#10 and CRMF requests. In all instances, 1576 the bodyPartID is set to zero. 1578 o shroudMethod contains the identifier of the type of algorithm to 1579 be used in deriving the key used to encrypt the private key. 1581 o algCapabilities contains the set of algorithm capabilities being 1582 advertised by the client. The server uses algorithms from this 1583 set in the ServerKeyGenResponse object to encrypt the private key 1584 of the server-generated key pair. This field is optional because 1585 this information might be carried in a signed attribute, included 1586 within a certificate or be part of the local configuration. 1588 o archiveKey is set to TRUE if the client wishes the key to be 1589 archived as well as generated on the server. Further processing 1590 by the server when this is set to TRUE is out-of-scope. 1592 The client can request that the generated key be for a specific 1593 algorithm by placing data in the publicKey.attribute field of the 1594 CRMF request or in the subjectPKInfo.attribute field of the PKCS#10 1595 request. If the publicKey or subjectPKInfo field is populated, then 1596 the subjectPublicKey is a zero-length bit string. If the client 1597 requests a specific algorithm, the server either generates a key for 1598 that algorithm (with the parameters if defined) or fails to process 1599 the request. If the request fails for this reason, the server 1600 returns a CMCFailInfo with a value of badAlg [RFC5272]. 1602 As specified in [RFC5272]: 1604 "A server is not required to use all of the values suggested by 1605 the client in the certificate template. Servers MUST be able to 1606 process all extensions defined in [RFC5280]. Servers are not 1607 required to be able to process other V3 X.509 extensions 1608 transmitted using this protocol, nor are they required to be able 1609 to process other, private extensions. Servers are permitted to 1610 modify client-requested extensions. Servers MUST NOT alter an 1611 extension so as to invalidate the original intent of a client- 1612 requested extension. (For example change key usage from key 1613 exchange to digital signature.) If a certification request is 1614 denied due to the inability to handle a requested extension, the 1615 server MUST respond with a CMCFailInfo with a value of 1616 unsupportedExt." 1618 A server that does not recognize the algorithm identified in 1619 shroudMethod will reject the request. The server returns a 1620 CMCFailInfo with a value of badAlg [RFC5272]. 1622 A server that does not support at least one of the algCapabilities 1624 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1626 will reject the request. The server returns a CMCFailInfo with a 1627 value of badAlg [RFC5272]. 1629 If archiveKey is set to true and the server does not support 1630 archiving of private keys, the request will be rejected by the 1631 server. The server returns a CMCFailInfo with a value of 1632 archiveNotSupported, see Section 7. 1634 6.2. Server-side Key Generation Response 1636 The server creates a server-side key generation response attribute 1637 for every key generation request made and successfully completed. 1638 The response message has a pointer to both the original request 1639 attribute and to the body part in the current message that holds the 1640 encrypted private keys. The response message also can contain a 1641 pointer to the certificate issued. The key generation response 1642 control attribute is identified by the OID: 1644 id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= { id-cmc XX } 1646 The Server-Side Key Generation Response control attribute has the 1647 following ASN.1 definition: 1649 cmc-serverKeyGenResponse CMC-CONTROL ::= { 1650 ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse 1651 } 1653 ServerKeyGenResponse ::= SEQUENCE { 1654 cmsBodyPartId BodyPartID, 1655 requestBodyPartId BodyPartID, 1656 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 1657 } 1659 The fields in ServerKeyGenResponse have the following meaning: 1661 o cmsBodyPartId identifies a TaggedContentInfo contained within the 1662 enclosing PKIData. The ContentInfo object is of type 1663 EnvelopedData and has an encapsulated content of id-ct-KP- 1664 aKeyPackage (see Section 4). 1666 o requestBodyPartId contains the body part identifier for the 1667 server-side key generation request control attribute. This 1668 allows for clients to associate the resulting key and certificate 1669 with the original request. 1671 o issuerAndSerialNumber if present contains the identity of the 1672 certificate issued to satisfy the request. The certificate is 1673 placed in the certificate bag of the immediately encapsulating 1675 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1677 SignedData object. 1679 As specified in [RFC5272]: 1681 "Clients MUST NOT assume the certificates are in any order. 1682 Servers SHOULD include all intermediate certificates needed to 1683 form complete chains to one or more self-signed certificates, not 1684 just the newly issued certificate(s) in the certificate bag. The 1685 server MAY additionally return CRLs in the CRL bag. Servers MAY 1686 include self-signed certificates. Clients MUST NOT implicitly 1687 trust included self-signed certificate(s) merely due to its 1688 presence in the certificate bag." 1690 7. Additional Error Codes 1692 This section defines ExtendedFailInfo errors from this document: 1694 cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= { 1695 TYPE ErrorList IDENTIFIED BY id-tbd 1696 } 1698 ErrorList ::= INTEGER { 1699 archiveNotSupported (1), 1700 badCertificate (2), 1701 badSharedSecret (3) 1702 } 1704 o archiveNotSupported indicates that the server does not support 1705 archiving of private keys. The syntax for the ExtendedFailInfo 1706 is as follows: 1708 cmc-err-archiveNotSupport EXTENDED-FAILURE-INFO ::={ 1709 IDENTIFIED BY id-tbd 1710 } 1712 o badCertificate indicates that the certificate to be used to 1713 encrypt the response did not validate back to a RA/CA trust 1714 anchor or the certificate does not belong to the client. The 1715 syntax for the ExtendedFailInfo is as follows: 1717 cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={ 1718 IDENTIFIED BY id-tbd 1719 } 1721 o badSharedSecret indicates that the shared secret used by the 1722 client does not match that stored by the server. 1724 cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={ 1726 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1728 IDENTIFIED BY id-tbd 1729 } 1731 8. Proof-of-Possession 1733 Some servers may require that the client prove that it has taken 1734 possession of the server-generated key. This proof requires an 1735 additional roundtrip beyond those previously discussed. 1737 For certificates returned that support digital signatures the process 1738 is as described in [RFC5272]: the server indicates in CMCStatus that 1739 status is confirmRequired; the client returns the Confirm Certificate 1740 Acceptance control in PKIData signed with the server-generated 1741 private key; and the server responds with a CMCStatus of success. 1743 For certificates returned that only support encryption, the server 1744 indicates the CMCStatus is popRequired and includes the Encrypted POP 1745 control; the client returns the Decrypted POP control. Whether the 1746 PKIRequest from the client is encapsulated in an AuthenticatedData or 1747 SignedData depends on which mechanism was used during the server key 1748 generation request. 1750 9. Security Considerations 1752 Central generation of digital signature keys contains risks and is 1753 not always appropriate. Organization-specific CPs (Certificate 1754 Policies) [RFC3647] define whether or not server-side generation of 1755 digital signature keys is permitted. 1757 For the choice of mechanisms to protect the server-generated key, 1758 there is a balance that needs to be maintained between the use of a 1759 potentially poorly generated one-time key (i.e., the shared secret) 1760 and the use of a key externally provided. For externally provided 1761 keys, the external provider of the key will be able to decrypt the 1762 key delivery message as long as it was captured. For poorly generated 1763 one-time keys, any external party might be able to guess the key and 1764 thus decrypt the key delivery message. Different types of keys will 1765 have different requirements for what a poorly generated key means. 1766 Generators of RSA keys need to be able to do good prime checking; 1767 generators of Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman 1768 (ECDH) keys only need a moderate quality random number generator if 1769 the group parameters are externally provided and of good quality. 1771 This specification requires implementations to generate key pairs and 1772 other random values [RFC4086]. The use of inadequate pseudo-random 1773 number generators (PRNGs) can result in little or no security. The 1774 generation of quality random numbers is difficult. NIST Special 1775 Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer 1777 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1779 guidance. 1781 Private keys, regardless of where they are generated, must be 1782 appropriately protected from disclosure or modification on the 1783 server, in transit, and on the client. Cryptographic algorithms and 1784 keys used to protect the private key should be at least as strong as 1785 the private key's intended strength. 1787 This document describes the CA signing certificates and messages as 1788 well as encrypting messages. It should not be assumed that the CA 1789 uses the same key for all of these operations. In fact, CAs may wish 1790 to limit the exposure of their private keys by using different keys 1791 or different purposes. 1793 Key agreement algorithms (i.e., Diffie-Hellam or Elliptic Curve 1794 Diffie-Hellman) can be used to protect the returned server-generated 1795 key. These algorithms support a number of different schemes [SP-800- 1796 56]. Normally, an Ephemeral-Static (E-S) scheme is used (more 1797 formally known as "(Cofactor) One-Pass Diffie-Hellman, 1798 C(1e,1s,ECCCDH) Scheme") see [RFC5753], but here the client provides 1799 an ephemeral key to the server so an S-E scheme is used when the key 1800 is encrypted for the client. Regardless, the client needs to 1801 generate an ephemeral key and provide it to the server and this key 1802 needs to use the same parameters (i.e., p, q, g for DH and elliptic 1803 curve for ECDH) as the server. The client's parameters MUST be 1804 present in the publicKey or certificate field of the Server Key 1805 Generation Request control or MUST be in the certificate referred to 1806 by the ski in the same control. The client can find the server's 1807 parameters in the server's certificate; to make it easy on clients, 1808 server certificates MUST include parameters. How the client obtains 1809 the server's certificate is out of scope. 1811 Servers that support the features specified herein need to document 1812 their procedures in a CPS (Certificate Practice Statement) [RFC3647]. 1813 CAs that certify server-generated private keys are certifying that 1814 they've taken due diligence to ensure that the private key is only 1815 known to and used by the subject. Depending on the Certification 1816 Policy (CP) [RFC3647], the keys have been allocated to the subject, 1817 but the keys may not be strictly owned by the subject. The CA (and 1818 the enterprise it supports) has a reason for issuing the keys (e.g., 1819 employer to employee; school to student) and because the enterprise 1820 CA generated the private keys it is accountable for the 1821 trustworthiness of the private key. But, the subject should beware of 1822 using it for other purposes. 1824 When using an ephemeral key for protecting the server-generated key, 1825 a compromised signature key, when used by the intended party, will 1826 not automatically jeopardize the security of the server-generated 1828 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1830 keys. Procedural controls can help to ensure a one-to-one mapping 1831 between verified requests and intended parties (i.e. mitigate the 1832 risk of masquerade using a compromised authentication key and 1833 certificate), but that is outside the scope of this document. 1835 POP is important; [RFC4211] provides some information about POP; for 1836 server-generated keys it can only be provided after the server- 1837 generated key has been returned by the client (see Section 8). 1838 Whether a server requires POP is a CP dependent [RFC3647], but highly 1839 recommended. 1841 When the shared secret is used to provide client authentication and 1842 protect the server-generated private key, the shared secret must be 1843 kept secret for the lifetime of the key. This is because disclosure 1844 could allow attackers to determine the server-generated private key. 1845 This is different than certification requests with client-generated 1846 keys because the shared secret is no longer needed after the 1847 authentication. 1849 If the key generator and the server are not collocated, then the 1850 exchange between these two entities must be protected from 1851 unauthorized disclosure and modification and both entities must have 1852 a trust relationship. However, these exchanges are beyond the scope 1853 of this document. Note that the CA needs access to the public key to 1854 generate the certificate. If the key generator encrypts the 1855 generated key for the client, then the key generator needs to provide 1856 the public key to the CA (possibly through the RA). 1858 Returning the key to the wrong client can be bad. If an encrypted 1859 key is returned to the wrong client, then it is only bad if the key 1860 was encrypted for the wrong client and then something much worse is 1861 afoot. If the encrypted key is returned to the wrong client and it 1862 is encrypted for the right client (i.e., it was misdirected), then it 1863 is bad but the unencrypted key hasn't been disclosed to an 1864 unauthorized client. The protection afforded by the confidentiality 1865 algorithm is what protects the misdirected key from unauthorized 1866 disclosure. 1868 10. IANA Considerations 1870 This document makes use of object identifiers to register CMC control 1871 attributes and CMC error codes. Additionally, an object identifier 1872 is used to identify the ASN.1 module found in Appendix A. All are 1873 defined in an arc delegated by IANA to the PKIX Working Group. The 1874 current contents of the arc are located here: 1876 http://www.imc.org/ietf-pkix/pkix-oid.asn 1878 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1880 They were obtained by sending a request to ietf-pkix-oid-reg@imc.org. 1881 When the PKIX WG closes, this arc and registration procedures will 1882 be transferred to IANA. No further action by IANA is necessary for 1883 this document or any anticipated updates. 1885 11. References 1887 11.1 Normative References 1889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1890 Requirement Levels", BCP 14, RFC 2119, March 1997. 1892 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1893 Request Syntax Specification Version 1.7", RFC 2986, 1894 November 2000. 1896 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1897 Certificate Request Message Format (CRMF)", RFC 4211, 1898 September 2005. 1900 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1901 (CMC)", RFC 5272, June 2008. 1903 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1904 Housley, R., and W. Polk, "Internet X.509 Public Key 1905 Infrastructure Certificate and Certificate Revocation List 1906 (CRL) Profile", RFC 5280, May 2008. 1908 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1909 RFC 5652, September 2009. 1911 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1912 Mail Extensions (S/MIME) Version 3.2 Message 1913 Specification", RFC 5751, January 2010. 1915 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1916 2010. 1918 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1919 Updates", RFC 6402, November 2011. 1921 12.2 Informative References 1923 [FIPS-186] National Institute of Standards and Technology (NIST), 1924 FIPS 186-3 DRAFT: Digital Signature Standard (DSS), 1925 November 2008. 1927 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1929 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 1930 RFC 2634, June 1999. 1932 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1933 Wu, "Internet X.509 Public Key Infrastructure Certificate 1934 Policy and Certification Practices Framework", RFC 3647, 1935 November 2003. 1937 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1938 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1940 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1941 "Randomness Requirements for Security", BCP 106, RFC 4086, 1942 June 2005. 1944 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 1945 36, RFC 4949, August 2007. 1947 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1948 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1950 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1951 Cryptography (ECC) Algorithms in Cryptographic Message 1952 Syntax (CMS)", RFC 5753, January 2010. 1954 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1955 Message Syntax", RFC 5754, January 2010. 1957 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 1958 Type", RFC 5959, August 2010. 1960 [SP-800-56] Barker, E., Johnson, D., and M. Smid, "Recommendation for 1961 Pair-Wise Key Establishment Schemes Using Discrete 1962 Logarithm Cryptography", NIST Special Publication 800-56A 1963 Revision 1, March 2007. 1965 [SP-800-57] National Institute of Standards and Technology (NIST), 1966 Special Publication 800-57: Recommendation for Key 1967 Management - Part 1 (Revised), March 2007. 1969 [SP-800-90] National Institute of Standards and Technology (NIST), 1970 Special Publication 800-90: Recommendation for Random 1971 Number Generation Using Deterministic Random Number Bit 1972 Generators (Revised), March 2007. 1974 Appendix A. ASN.1 Module 1976 To be supplied later. 1978 I-D CMC Extensions: Server Side Key Generation March 27, 2014 1980 Appendix B. Additional Message Flows 1982 This appendix forms a non-normative part of this specification. 1984 The main body of this document has portrayed protocol flows with 1985 optional controls. This was done to explain the more complicated 1986 scenarios. This appendix depicts the flows without those optional 1987 controls. 1989 For example the figure in Section 2.5.1 without the TransactionId, 1990 SenderNonce, and RecipientNonce, appear as follows: 1992 Client RA CA 1993 | | | 1994 |----------------->| | 1995 | [PKIData | | 1996 | control: SKGReq, | | 1997 | Identification] | | 1998 | |-------------------------------------->| 1999 | | | 2001 | |<--------------------------------------| 2002 |<-----------------| PKIResponse 2003 | }> 2007 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 2009 The PKIResponse from the CA is a certs-only message, which does not 2010 include a signature. 2012 Likewise for the figure in Section 2.5.2: 2014 Client RA CA 2015 | | | 2016 |----------------->| | 2017 | [PKIData | | 2018 | control: SKGReq, | | 2019 | Identification] | | 2020 | |--------------------------------------->| 2021 | | | 2025 | |<---------------------------------------| 2026 | | } > > 2033 | }> 2037 If the RA doesn't perform the Identity checks, then it can forward 2038 the client's request without the additional layers of encapsulation. 2040 Client RA CA 2041 | | | 2042 |----------------->| | 2043 | [PKIData | | 2044 | control: SKGReq, | | 2045 | Identification] | | 2046 | |--------------------------------------->| 2047 | | [PKIData | 2048 | | control: SKGReq, Identification] | 2049 | |<---------------------------------------| 2050 | | }> 2053 |<-----------------| 2054 | }> 2058 Not to be outdone, the scenarios in Section 2.5.1 can be more 2059 complicated by an RA that batch requests together. The following 2060 depicts a number of clients sending requests together that an RA then 2061 batches together. The unsigned PKIResponse (a certs-only message) 2062 includes all of the certificates issued. The CA can also return 2063 individual responses as opposed to batching them all together or it 2064 can batch them together in some other combination. 2066 Client(1-n) RA CA 2067 | | | 2068 |----------------->| | 2069 | [PKIData | | 2070 | control: SKGReq, | | 2071 | Identification] | | 2072 | |-------------------------------------->| 2073 | | | 2075 | |<--------------------------------------| 2076 | | 2080 I-D CMC Extensions: Server Side Key Generation March 27, 2014 2082 | }> 2086 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 2088 In another scenario, all but one of the requests were successfully 2089 processed. The RA returns those that were successful back to the 2090 clients but later polls the CA, based on the value CMCStatusInfoV2 2091 pendInfo, for the one that was not successful. The CA returns the 2092 one successful request. 2094 Client(1-n) RA CA 2095 | | | 2096 |----------------->| | 2097 | [PKIData | | 2098 | control: SKGReq, | | 2099 | Identification] | | 2100 | |-------------------------------------->| 2101 | | | 2104 | |<--------------------------------------| 2105 | | 2109 |<-----------------| 2110 | }> | 2113 | |-------------------------------------->| 2114 | | | 2116 | |<--------------------------------------| 2117 | | PKIResponse 2118 |<-----------------| 2119 | }> 2123 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 2125 Batching the requests can also be performed for CA-generated keys as 2126 shown below. The RA Identity Witness controls indicates all those 2127 client requests that it performed Identity checks on. 2129 Client RA CA 2131 I-D CMC Extensions: Server Side Key Generation March 27, 2014 2133 | | | 2134 |----------------->| | 2135 | [PKIData | | 2136 | control: SKGReq, | | 2137 | TransactionID, | | 2138 | SenderNonce, | | 2139 | Identification] | | 2140 | |--------------------------------------->| 2141 | | | 2147 | |<---------------------------------------| 2148 | | } >> 2155 | }> 2159 Appendix B. Examples 2161 To be supplied later. 2163 B.1. Client Requests 2165 B.1.1. Shroud with Certificate 2167 B.1.2. Shroud with Public Key 2169 B.1.3. Shroud with Shared Secret 2171 B.2. CA-Generate Key Response 2173 B.3. RA-Generate Key Response 2174 I-D CMC Extensions: Server Side Key Generation March 27, 2014 2176 Authors' Addresses 2178 Jim Schaad 2179 Soaring Hawk Consulting 2181 Email: jimsch@exmsft.com 2183 Sean Turner 2184 IECA, Inc. 2185 3057 Nutley Street, Suite 106 2186 Fairfax, VA 22031 2187 USA 2189 Email: turners@ieca.com 2191 Paul Timmel 2192 National Information Assurance Research Laboratory 2193 National Security Agency 2195 Email: pstimme@tycho.ncsc.mil