idnits 2.17.00 (12 Aug 2021) /tmp/idnits53082/draft-turner-cmc-serverkeygeneration-02.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 (August 12, 2014) is 2832 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 2093 -- Looks like a reference, but probably isn't: '2' on line 2094 ** 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: February 13, 2015 IECA, Inc. 6 P. Timmel 7 National Security Agency 8 August 12, 2014 10 CMC (Certificate Management over Cryptographic Message Syntax) 11 Extensions: Server-Side Key Generation 12 draft-turner-cmc-serverkeygeneration-02.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 client key 19 material for certificates. This service is provided by the 20 definition of additional control statements within the CMC 21 architecture. 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 GenerationAugust 12, 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 . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 67 2.4. Certificate for Authentication and Key Protection . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 15 72 2.5. RA Scenarios . . . . . . . . . . . . . . . . . . . . . . . 15 73 2.5.1. RA-Generated Key Scenarios . . . . . . . . . . . . . . 16 74 2.5.2. RA-Involved Scenarios . . . . . . . . . . . . . . . . 19 75 3. Generating PKIData and PKIResponse . . . . . . . . . . . . . . 21 76 3.1. Client Requests . . . . . . . . . . . . . . . . . . . . . 21 77 3.2. RA Processing of Client Requests . . . . . . . . . . . . . 22 78 3.3. CA Processing . . . . . . . . . . . . . . . . . . . . . . 24 79 3.4. RA Processing of CA Responses . . . . . . . . . . . . . . 26 80 3.5. Client Processing of Responses . . . . . . . . . . . . . . 27 81 4. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 28 82 4.1. Shroud with a Public Key . . . . . . . . . . . . . . . . . 29 83 4.2. Shroud with a Shared Secret . . . . . . . . . . . . . . . . 30 84 5. Returned Key Format . . . . . . . . . . . . . . . . . . . . . . 31 85 6. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 31 86 6.1. Server-Side Key Generation Request Attribute . . . . . . . 32 87 6.2. Server-side Key Generation Response . . . . . . . . . . . . 33 88 7. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 35 89 8. Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . 35 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 35 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 11.1 Normative References . . . . . . . . . . . . . . . . . . . 39 94 12.2 Informative References . . . . . . . . . . . . . . . . . . 39 95 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 41 96 Appendix B. Additional Message Flows . . . . . . . . . . . . . . . 44 97 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 48 98 B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 48 99 B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 48 101 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 103 B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 48 104 B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 48 105 B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 48 106 B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 48 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 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 client key 114 material for certificates [RFC5280]. The keys that are produced by 115 this service are referred to as server-generated keys. There are 116 strong reasons for providing this service: 118 o Clients may have poor, unknown, or non-existent key generation 119 capabilities. The creation of private keys relies on the use of 120 good key generation algorithms and a robust random number 121 generator. Server-side key generation can use specialized 122 hardware that may not always be available on clients. 124 o Central storage of keys may be desired in some environments to 125 permit key recovery. This document only addresses a request to 126 archive server-generated keys; archival of locally generated keys 127 and the control to retrieve archived keys is out-of-scope. 129 o Server-side key generation may be useful for provisioning keys to 130 disconnected clients (e.g., clients that receive keys from a fill 131 device [RFC4949] because the clients are not able to connect to 132 the server due to an air gap). 134 These extensions to the CMC protocol are designed to provide server- 135 generated keys without adding any additional round trips to the 136 enrollment process; however, additional round trips may be required 137 based on the mechanism chosen to protect the returned key. 139 Section 2 describes the enrollment scenarios supported. Section 3 140 provides CMC requirements. Sections 4 and 5 describe the concepts and 141 structures used in transporting private keys between the server and 142 client applications. Section 6 describes the structure and processes 143 for server-side key generation. Section 7 describes additional CMC 144 error codes. Section 8 describes additional exchanges when the 145 server requires the client provide Proof-of-Possession (POP). 146 Appendix A provides the ASN.1 module for the CMC controls and errors. 147 Appendix B provides example encodings. 149 1.1. Terminology 150 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in RFC 155 2119 [RFC2119]. 157 The terminology in [RFC5272] and in [RFC6402] apply to this profile. 158 Additionally, familiarity with CMS's (Cryptographic Message Syntax) 159 [RFC5652] SignedData, AuthenticatedData, and EnvelopedData content 160 types is assumed. 162 1.2. Definitions 164 This section defines some of the terms that are used in this 165 document: 167 o Dual-use: Applies to certificates or keys. Certificates that can 168 be used to verify both digital signatures and to perform key 169 management, when the KeyUsage extension [RFC5280] is set to 170 digitalSignature and either keyAgreement or keyEncipherment, and 171 keys whose intended use is digital signature and either key 172 agreement or key encipherment. 174 o Encryption-capable: Applies to certificates or keys. 175 Certificates that can be used for key management (i.e., the 176 KeyUsage extension includes keyAgreement or keyEncipherment) and 177 keys that can be used for key management. This refers to either 178 dual-use or encryption-only certificates/keys. 180 o Encryption-only: Applies to certificates or keys. Certificates 181 that can only be used for key management, when the KeyUsage 182 extension is set to either keyAgreement or keyEncipherment, and 183 keys whose only intended use is key agreement or key 184 encipherment. 186 o Ephemeral key [SP-800-57]: A cryptographic key that is generated 187 for each execution of a key establishment process and that meets 188 other requirements of the key type (e.g., unique to each message 189 or session). Often, ephemeral keys are linked to key agreement 190 algorithms; however, this document uses the term ephemeral keys 191 to apply to both key transport and key agreement keys. The 192 ephemeral key has two parts: the private part and the public 193 part. The client provides the public part to the server to allow 194 the server to protect the server-generated keys. Note that an 195 ephemeral key has a security advantage by being unique to the 196 session; it SHOULD be freshly generated when possible, but MAY be 197 pre-placed when local key generation is of poor or unknown 198 quality (see Section 9). An ephemeral key is innately 199 unauthenticated, and so must be carried in a suitably 201 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 203 authenticated protocol. 205 o Identification: A generic term for a process by which a name, 206 generally assigned by a server, is used to match a request 207 against a known entity. Identification can be either 208 authenticated (a subject name in a certificate) or 209 unauthenticated (a text string). 211 o Perfect Forward Secrecy (PFS): For this protocol, it is the 212 property that the compromise of long-term keying material does 213 not lead to the compromise of the new long-term keying material 214 carried in the protocol. 216 o Shared Secret: A value known to two or more entities in advance 217 of a protocol session in which it will be used, and intended to 218 be unknown to any others. In this document, the value must be a 219 suitable basis for derivation of a MAC (Message Authentication 220 Code) or encryption key. Pass phrases that are used as a shared 221 secret must be treated as confidential by the holders of the 222 secret. 224 o Shrouding: A generic term to cover methods of masking the content 225 of an object from unauthorized viewers, taken from RSA's PKCS 226 specifications. The most common method of shrouding used is 227 encryption of the data at the application layer. This document 228 defines two shrouding methods that employ encryption at the 229 application layer but other shrouding methods can be defined that 230 do not employ encryption at the application layer. 232 o Signature-capable: Applies to certificates or keys. Certificates 233 that can be used to verify signatures and keys that can be used 234 to generate digital signatures. This refers to either dual-use 235 or signature-only certificates/keys. 237 o Signature-only: Applies to certificate or keys. Certificates 238 that can only be used to verify digital signatures, when the 239 KeyUsage extension is set to digitalSignature, and keys whose 240 only intended usage is digital signature. 242 In this document the server is the entity that generates the key. 243 This can be either the RA (Registration Authority) or CA 244 (Certification Authority). 246 2. Protocol Flows for Supported Scenarios 248 This section describes the supported scenarios and specifies the CMC 249 requests and responses to support them: 251 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 253 1. Clients use a shared secret (e.g., password) (see Section 1.2) to 254 provide authentication and request that the server use the same 255 shared secret to encrypt the server-generated keys. 257 2. Clients use a shared secret to provide authentication and request 258 that the server use an ephemeral key (see Section 1.2) to encrypt 259 the server-generated keys. 261 3. Clients use a key pair previously certified by a CA (i.e., a 262 private key and a certificate) to support digital signature 263 authentication and request that the server use an ephemeral key 264 to encrypt the server-generated keys. 266 4. Clients use a key pair previously certified by a CA (i.e., a 267 private key and a certificate) to support digital signature 268 authentication and request that the server use a certificate to 269 encrypt the server-generated keys. Some additional details: 271 * If the client's authentication certificate is signature-only, 272 then the client also needs an encryption-capable certificate 273 that the server will use to protect the private key. 274 * If the client's certificate is dual-use, then the client only 275 needs the one certified key pair to generate the SignedData 276 that encapsulates the certificate request and to decrypt the 277 EnvelopedData that encapsulates the server-generated key. 279 The characteristics of the four scenarios are as follows: 281 o Scenarios that employ shared secrets (Scenarios 1 and 2) are 282 consider by some to be more human friendly than scenarios that 283 employ certificates because there is less initial PKI overhead. 284 While true, the use of shared secrets introduces its own set of 285 key management issues. 287 * When a shared secret is used for key protection (Scenario 1), 288 secrecy of the shared secret is required for the lifetime of 289 the key. That burden can be eased by limiting the shared 290 secret to a single use and having all parties destroy it after 291 the key it protects has been received by the subject. Thus, 292 even though by definition Forward Secrecy is not possible, when 293 the shared secret no longer exists it cannot be compromised. 294 However the bigger problem is likely to be compromise of the 295 shared secret before it is ever used. That cannot be mitigated 296 except by starting over with a fresh shared secret in a way 297 that avoids compromise. 299 * When a shared secret is used for authentication only (Scenario 300 2), there is even greater value in limiting use to one 302 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 304 transaction, as that reduces the chance of identity cloning or 305 unintended use of the shared secret as a group identity. 307 * When rekeying server-generated keys originally requested using 308 a shared secret, clients that received signature-capable keys 309 can use them to provide the POP necessary for rekey instead of 310 using a shared secret. The same is true of clients that 311 received encryption only keys assuming they are permitted to 312 generate a one-time signature for rekey purposes. Clients that 313 received encryption-only certificates that are not permitted to 314 generate a one-time signature for rekey requests need a new 315 shared secret for rekeys. The mechanism that distributed 316 shared secrets is out-of-scope. 318 * Note distributing the new shared secret in-band is of dubious 319 value because a) maintaining the secrecy of the new shred 320 secret is just as hard for the user as maintaining the secrecy 321 of the to-be-replaced shared secret b) distribution of a new 322 shared secret protected with a to-be replaced shared secret 323 does not provide PFS. 325 * Servers that place certificate request in the pending state 326 should consider how long they are in that state as well as how 327 long the shared secret is considered valid (i.e., do not delete 328 the shared secret from a pending request before either 329 rejecting the request because of timeout or fulfilling the 330 request because the request that checks on the status will not 331 validate). 333 o For scenarios that use ephemeral keys to protect the returned 334 private key (i.e., Scenarios 2 and 3): 336 * PFS is provided presuming the ephemeral key is forgotten as 337 well as any other information necessary to generate the 338 ephemeral key after the certificate request is successfully 339 processed by the client. 341 * Client use of the ephemeral key mitigates the risk of 342 compromise of a pre-existing certificate and key while in the 343 supply chain (see Section 9). 345 o For scenarios that only use certificates (i.e., Scenario 4), PFS 346 is not provided because the client uses a long-term private key 347 for private key protection and if compromised the next key can 348 also be compromised. 350 Note that there are existing CP-based (Certificate Policy) 351 requirements for protecting the private key(s) associated with 353 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 355 the certificate(s) (see Section 9). 357 In the scenarios above, the entity generating the key pair can be the 358 Certification Authority (CA) or the Registration Authority (RA); in 359 fact the RA or CA can use a separate key generator device (e.g., a 360 hardware security module) but interactions with that device are out- 361 of-scope. Sections 2.1-2.4 depict protocol flows for scenarios with 362 a client and CA only where the CA generates the keys. Section 2.5 363 depicts protocol flows for scenarios that involve the client, RA, and 364 CA where the RA generates the keys. Section 2.5 also depicts 365 protocol flows for so-called "RA-involved" scenarios where the CA 366 generates the keys but the RA performs identity checks. 368 All scenarios described herein require the server to have some a 369 priori knowledge of the client. How this knowledge is obtained is 370 out-of-scope, but the scenarios offer different 371 opportunities/constraints for obtaining the information: 373 o In the shared secret cases, the method for prior knowledge has to 374 cope with securely delivering and storing the shared secret. 375 o In the certificate cases, there are two alternatives: 376 * The key pair was generated by the server, so the certificate is 377 evidence of that prior knowledge. 378 * The certificate was issued from another CA. Even when there 379 are no grounds for cross-certification, the certificate can 380 still be used as an artifact for registration/enrollment prior 381 to the client making a certificate request, which is 382 advantageous because the key pair bound to the identifier in 383 the certificate enables the server to authenticate the source 384 of the eventual certificate request and positively link it to 385 the registration information. 387 Note: The initial certificate key pairs could be considered a 388 special case of the shared secret scenario that improves on the 389 security of the shared secret mechanism and mitigates some of the 390 management burden and cost. For example, the certificates could be 391 special-purpose--issued by the manufacturer and recognized by the 392 server solely for authentication against a registration list (i.e., 393 not usable for anything else). If a manufacturer initializes the 394 device with a shared secret, then that shared secret has to be 395 distributed securely to the eventual enrolling CA via the device 396 owner, but independently of the device. If the manufacturer 397 instead installs a key pair and generic certificate, the 398 certificate can take the place of the shared secret that would 399 otherwise have to be independently provided to the central key 400 generation CA. The management process is roughly the same, but the 401 information that has to be handled now longer has to be kept 402 secret. That means there are many more options for how that 404 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 406 information can be managed and distributed. 408 Normally the client's identifier and the shared secret are generated 409 by the server and then securely transported to the client; there is 410 no practical reason why this cannot be done in the opposite 411 direction. In this case, the client will generate an identifier, 412 shared secret, and an ephemeral key. When the server receives the 413 CMC message, it recognizes that it does not correspond to an existing 414 identifier/secret pair and puts the request on hold. The client then 415 communicates the identifier and secret to the server via an out-of- 416 band means. The server then performs the necessary user management 417 dealing with identity validation and certificate setup. If that 418 passes and the ephemeral key passes applicable public key validation 419 tests, then the certificate will be issued and the response returned 420 protected with ephemeral key. If it does not pass checking then the 421 certificate will fail to issue. An ephemeral key is generated by the 422 client to ensure PFS is provided as the client may not get the same 423 degree of confidentiality because the client is unaware how the 424 private key has been provided. 426 Note that there is no scenario where the response is protected with a 427 key/certificate that only supports digital signatures. This is 428 because the "protection" afforded by digital signatures alone does 429 not include confidentiality, which is required to ensure that the 430 server-generated private key is only disclosed to the client. 432 Note also that there is also no scenario where the client uses an 433 encryption-only certificate and is unable to generate a digital 434 signature to provide authentication. This is because the 435 "protection" afforded by encryption-only certificates does not 436 include authentication. Technically, there are Authenticated 437 Encryption with Associated Data (AEAD) algorithms (i.e., dual-service 438 algorithms) that support both authentication and encryption but their 439 use is beyond the scope of this document. 441 In all of the scenarios, the client can validate that the response 442 came from the CA or RA by validating the digital signature on the 443 SignedData to a Trust Anchor (TA). After the EnvelopedData is 444 decrypted, the client can verify that the private key is associated 445 with the public key in the returned certificate and that the 446 certificate validates back to an authorized TA. 448 The scenarios in the subsections assume that the transaction 449 identifier and nonce controls are used for transaction processing and 450 replay protection, respectively, but they are optional, as specified 451 in [RFC5272]. Also, the scenarios assume the CMC Status Information 452 v2 control is not included when the response is a success, as allowed 453 by [RFC5272]. See Appendix B for additional example scenarios. 455 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 457 A client requesting a certificate for a different name than one 458 already issued, either based on the certificate being used in 459 Scenarios 3 and 4 or the name associated with the shared secret in 460 Scenarios 1 and 2, includes the Change Subject Name attribute to 461 ensure the server will not reject the request because the name in the 462 certificate used to sign the request does not match the name in the 463 request. Note this is not depicted in the diagrams that follow 464 because the attribute is included within the ServerKeyGenRequest. 466 2.1. Shared Secret for Authentication and Key Protection 468 The shared secret allows the server to authenticate the client and 469 allows the server to encrypt the server-generated key for the client. 470 The shared secret is distributed via an out-of-band mechanism that 471 is out-of-scope of this document. Also note that the server and 472 client need to share a non-secret identification string that the 473 client can assert in a request so that the server will know which 474 shared secret is being used. 476 When the client generates its request, the client includes the 477 following control attributes in a PKIData content type [RFC5272]: 478 Server Key Generation Request (see Section 6.1), Transaction 479 Identifier [RFC5272], Sender Nonce [RFC5272], and Identification 480 [RFC5272]. The Server Key Generation Request control indicates that 481 the shroudMethod is shroud with shared secret (see Section 4.2). The 482 PKIData is encapsulated in a CMS AuthenticatedData content type and 483 the password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. 484 Note that reqSequence, cmsSequence, and otherMsgSequence are not 485 included in the PKIData for the server-side key generation request. 486 The following depicts this: 488 +----------------------------------------------------------------+ 489 |AuthenticatedData: RecipientInfo: pwri | 490 |+--------------------------------------------------------------|| 491 ||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)|| 492 || control: ChangeSubjectName if names differ || 493 || control: TransationID || 494 || control: SenderNonce || 495 || control: Identification || 496 |+--------------------------------------------------------------+| 497 +----------------------------------------------------------------+ 499 After the server authenticates the client and verified the request, 500 the server generates a response that includes the server-generated 501 key and any associated parameters in an Asymmetric Key Package 502 content type [RFC5958]. The Asymmetric Key Package is then 503 encapsulated within a SignedData, which is signed by the server, and 504 that is further encapsulated within an EnvelopedData using the 506 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 508 password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData, which 509 is encrypted for the client, is then placed in a PKIResponse 510 cmsSequence [RFC5272] and the following controls are included in the 511 PKIResponse: Transaction Identifier, Sender Nonce, Recipient Nonce 512 [RFC5272], and Server Key Generation Response (see Section 4.2). The 513 PKIResponse is then encapsulated in a SignedData, which is signed by 514 the server, and the client's certificate associated with the server- 515 generated key is placed in the outer-most SignedData's certificates 516 field [RFC5652]. The following depicts this: 518 +---------------------------------------------------------+ 519 |SignedData: Signed by the CA | 520 | Client's certificate in certificates field | 521 |+-------------------------------------------------------+| 522 ||PKIResponse: control: TransactionId || 523 || control: SenderNonce || 524 || control: RecipientNonce || 525 || control: ServerKeyGenResponse || 526 || || 527 || cmsSequence: || 528 || +----------------------------------------+|| 529 || |EnvelopedData: RecipientInfo: pwri ||| 530 || |+-----------------------------+ ||| 531 || ||SignedData: Signed by the CA | ||| 532 || ||+---------------------------+| ||| 533 || |||AsymmetricKeyPackage || ||| 534 || ||+---------------------------+| ||| 535 || |+-----------------------------+ ||| 536 || +----------------------------------------+|| 537 |+-------------------------------------------------------+| 538 +---------------------------------------------------------+ 540 2.2 Shared Secret for Authentication and Ephemeral Key for Protection 542 The shared secret allows the server to authenticate the client and 543 the ephemeral key allows the server to use a different key to encrypt 544 the server-generated key for the client. The shared secret is 545 distributed via an out-of-band mechanism that is out-of-scope of this 546 document. Also note that the client needs an identification string 547 to allow the server to determine which shared secret is being used. 549 When the client provides an ephemeral key to protect the response, 550 the client includes the following control attributes in a PKIData 551 content type [RFC5272]: Server Key Generation Request control (see 552 Section 6.1), Transaction Identifier [RFC5272], Sender Nonce 553 [RFC5272], and Identification [RFC5272]. The Server Key Generation 554 Request control indicates that the shroudMethod is shroud with public 555 key and that the bareKey CHOICE is used (see Section 4.1). The 557 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 559 PKIData is encapsulated in an AuthenticatedData content type and the 560 password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note 561 that reqSequence, cmsSequence, or otherMsgSequence are not included. 562 The following depicts this: 564 +----------------------------------------------------------------+ 565 |AuthenticatedData: RecipientInfo: pwri | 566 |+--------------------------------------------------------------+| 567 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) || 568 || control: ChangeSubjectName if names differ || 569 || control: TransationId || 570 || control: SenderNonce || 571 || control: Identification || 572 |+--------------------------------------------------------------+| 573 +----------------------------------------------------------------+ 575 After the server has authenticated the client and verified the 576 request, the server returns the server-generated key and any 577 associated parameters in an Asymmetric Key Package content type 578 [RFC5958]. The Asymmetric Key Package is then encapsulated within a 579 SignedData, which is signed by the server, and that is further 580 encapsulated within an EnvelopedData using the key agreement or key 581 transport RecipientInfo (i.e., kari or ktri CHOICE). The 582 EnvelopedData, which is encrypted for the client, is then placed in a 583 PKIResponse cmsSequence [RFC5272] and the following controls are 584 included: Transaction Identifier, Sender Nonce, Recipient Nonce 585 [RFC5272], and Server Key Generation Response (see Section 6.2). The 586 PKIResponse is then encapsulated in a SignedData, which is signed by 587 the server, and the certificate associated with the server-generated 588 key is placed in the outer-most SignedData's certificates field 589 [RFC5652]. The following depicts this: 591 +-----------------------------------------------------------+ 592 |SignedData: Signed by the CA | 593 | Client's certificate in certificates field | 594 |+---------------------------------------------------------+| 595 ||PKIResponse: control: TransactionId || 596 || control: SenderNonce || 597 || control: RecipientNonce || 598 || control: ServerKeyGenResponse || 599 || || 600 || cmsSequence: || 601 || +------------------------------------------+|| 602 || |EnvelopedData: RecipientInfo: kari or ktri||| 603 || |+------------------------------+ ||| 604 || ||SignedData: Signed by the CA | ||| 605 || ||+----------------------------+| ||| 606 || |||AsymmetricKeyPackage || ||| 608 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 610 || ||+----------------------------+| ||| 611 || |+------------------------------+ ||| 612 || +------------------------------------------+|| 613 |+---------------------------------------------------------+| 614 +-----------------------------------------------------------+ 616 2.3. Certificate for Authentication and Ephemeral Key for Protection 618 This scenario differs from the scenarios in Sections 2.1 and 2.2 in 619 that the client encapsulates the PKIData in a SignedData instead of 620 an AuthenticatedData (i.e., the client uses its private key 621 associated with its signature-capable certificate to sign the 622 PKIData) but is similar to Section 2.2 for the response. As implied 623 in [RFC5272], clients omit the Identification and Identity Proof 624 controls when using certificates to support digital signature 625 authentication. 627 When the client generates its request, the client includes the 628 following control attributes in a PKIData content type [RFC5272]: 629 Server Key Generation Request (see Section 6.1), Transaction 630 Identifier [RFC5272], and Sender Nonce [RFC5272]. The Server Key 631 Generation Request control indicates the shroudMethod is shroud with 632 public key and the bareKey CHOICE is used (see Section 4.1). The 633 PKIData is encapsulated in a SignedData content type [RFC5652]. Note 634 that reqSequence, cmsSequence, and otherMsgSequence are not included 635 in the PKIData for the server-side key generation request. The 636 following depicts this: 638 +----------------------------------------------------------------+ 639 |SignedData: Signed by the Client | 640 |+--------------------------------------------------------------+| 641 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) || 642 || control: ChangeSubjectName if names differ || 643 || control: TransationId || 644 || control: SenderNonce || 645 |+--------------------------------------------------------------+| 646 +----------------------------------------------------------------+ 648 After the server has authenticated the client and verified the 649 request, the server returns the server-generated key and any 650 associated parameters in an AsymmetricKeyPackage content type 651 [RFC5958]. The AsymmetricKeyPackage is then encapsulated within a 652 SignedData, which is signed by the server, and that is encapsulated 653 within an EnvelopedData using the key agreement or key transport 654 RecipientInfo (i.e., kari or ktri CHOICE). The EnvelopedData, which 655 is encrypted for the client, is then placed in a PKIResponse 656 cmsSequence [RFC5272] and the following controls are included: 657 Transaction Identifier, Sender Nonce, Recipient Nonce [RFC5272], and 659 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 661 Server Key Generation Response (see Section 6.2). The PKIResponse is 662 then encapsulated in a SignedData, which is signed by the server and 663 the certificate associated with the server-generated key is placed in 664 the outer-most SignedData's certificates field [RFC5652]. The 665 following depicts this: 667 +-----------------------------------------------------------+ 668 |SignedData: Signed by the CA | 669 | Client's certificate in certificates field | 670 |+---------------------------------------------------------+| 671 ||PKIResponse: control: TransactionId || 672 || control: SenderNonce || 673 || control: RecipientNonce || 674 || control: ServerKeyGenResponse || 675 || || 676 || cmsSequence: || 677 || +------------------------------------------+|| 678 || |EnvelopedData: RecipientInfo: kari or ktri||| 679 || |+-----------------------------+ ||| 680 || ||SignedData: Signed by the CA | ||| 681 || ||+---------------------------+| ||| 682 || |||AsymmetricKeyPackage || ||| 683 || ||+---------------------------+| ||| 684 || |+-----------------------------+ ||| 685 || +------------------------------------------+|| 686 |+---------------------------------------------------------+| 687 +-----------------------------------------------------------+ 689 2.4. Certificate for Authentication and Key Protection 691 If a client already has been issued a signature-capable certificate, 692 then it can use this certificate to authenticate the requests. If 693 the certificate also indicates support for encryption (i.e., the key 694 usage extension is set to keyEncipherment or keyAgreement), then the 695 client can request that the server use the same certificate to 696 protect the server-generated key (see Section 2.4.1). If the 697 certificate does not indicate support for encryption, then the client 698 can provide the server with another certificate to use to encrypt the 699 server-generated key (see Section 2.4.2). The certificate that 700 protects the server-generated key MUST be encryption-capable. 702 These scenarios differ from the scenarios in Section 2.3 in that the 703 response is protected with a previously certified key instead of an 704 ephemeral key. As specified in [RFC5272], clients omit the 705 Identification and Identity Proof controls when using certificates to 706 support digital signature authentication. 708 2.4.1. Same Certificate for Authentication and Key Protection 709 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 711 This scenario is the same as in Section 2.3. except the Server Key 712 Generation Request control includes the certIdentifier CHOICE instead 713 of the bareKey CHOICE. The certIdentifier is sufficient information 714 for the server since the same certificate is already provided in the 715 SignedData. 717 2.4.2. Different Certificates for Authentication and Key Protection 719 This scenario is the same as in Section 2.3. except the Server Key 720 Generation Request control includes the certificate CHOICE instead of 721 the bareKey CHOICE. When using two certificates, all names in the 722 two certificates MUST match to ensure the CA will not reject the 723 request due to name mismatches. 725 2.5. RA Scenarios 727 In Sections 2.1-2.4, client-to-CA protocol flows were illustrated 728 where the CA generates the client's key and no RA was involved. This 729 section illustrates client-to-RA-to-CA protocol flows. The scenarios 730 divide into two basic categories, according to whether the RA or the 731 CA generates the key pair. 733 Regardless of whether the RA or the CA generates the key pair, the 734 intent of the RA here is to be transparent. That is, clients 735 initiate the same request regardless of the entity that ultimately 736 generates the keys. 738 When the RA generates the key on behalf of the client, the RA 739 augments the taggedRequest from the client with the RA-generated 740 public key and applies POP with the corresponding private key (i.e., 741 the RA includes the public key and signs the request). This becomes 742 the requestSequences in a new PKIData that the RA sends to the CA, 743 and that repeats the controls received from the client. Then the RA 744 signs the new PKIData with its own signing key. In this way, the RA 745 effectively becomes the client from the CA's perspective. However, 746 the RA and CA already have an established trust relationship (i.e., 747 the RA has been issued a certificate from the CA), which might not be 748 true for the client. The protocol exchange between the RA and CA is 749 identical to a client enrolling with a CMC Full PKI Request; 750 therefore, the CA need not know about or support the Server Key 751 Generation Request and Server Key Generation Response controls. The 752 PKIResponse to the client now has to accommodate the fact that the 753 asymmetric key package is generated by the RA, whereas the 754 certificate is generated by the CA. This necessitates that the RA 755 intercepts whatever response the CA returns to get the client's 756 certificate and that the RA generates a signed response that includes 757 the asymmetric key package as well as the client's certificate. See 758 section 9 for security considerations. 760 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 762 When the RA participates in the process but does not generate the 763 key, there are two possibilities. If the RA does not contribute to 764 the protocol (its effects may be procedural or out-of-band), then it 765 can simply pass the messages it receives to the other party when 766 warranted. If that is not warranted, the RA would generate the usual 767 response for the associated failure. No message flow depicting this 768 possibility is included in this document for reasons of brevity. 769 Alternatively, the RA may be responsible for processing certain 770 aspects of the request and needs to vouch for that when forwarding 771 the client request to the CA. The RA does this per [RFC5272] by 772 embedding the client request in a Full PKI Request that it signs, 773 containing controls for the processing that it performs. Here, as in 774 Sections 2.1-2.4, the CA needs to fully understand and support the 775 Server Key Generation Request and Server Key Generation Response 776 controls, since the CA has to generate the key and construct the 777 asymmetric key package. 779 In the figures that follow, the following abbreviations are used: 781 o SKGReq is the Server Key Generation Request control (see Section 782 6.1), 783 o SKGRes is the Server Key Generation Response control (see Section 784 6.2), 785 o TransactionId is the Transaction Identifier control [RFC5272], 786 o SenderNonce is the Sender Nonce control [RFC5272], 787 o RecipientNonce is the Recipient Nonce control [RFC5272], 788 o AKP is an Asymmetric Key Package [RFC5958] (i.e., the private 789 key), 790 o {} denotes encryption (i.e., EnvelopedData), o <> denotes 791 signatures (i.e., SignedData), with () identifying some of the 792 information is carried in unsignedAttrs for clarity, 793 o [] denotes authentication (i.e., SignedData or 794 AuthenticatedData). AuthenticatedData is used when clients use a 795 shared secret for authentication. 796 o control is CMC's controlSequence, 797 o reqSeq is CMC's requestSequence, 798 o cmsSeq is CMC's cmsSequence. 800 PKCS#10 [RFC2986], CRMF (Certificate Request Message Format) 801 [RFC4211], and other request message [RFC5272] are the certification 802 request formats supported. 804 2.5.1. RA-Generated Key Scenarios 806 There are some differences in the protocol flows when an RA generates 807 the key: 809 o The RA MUST be issued a certificate from the CA. This means all 811 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 813 of the RA-generated PKIData are encapsulated in a SignedData. 814 Further, the RA's certificate can be used for identification and 815 linking identity and POP information. 817 o The RA generates the certification request for the client by: 819 1. Using the name from the certificate for the private key the RA 820 will use to sign the PKIData. 822 2. Using the information from the client's request. 824 3. The RA includes the Change Subject Name control [RFC6402] 825 either in the PKCS #10 or CRMF TaggedRequest because the name 826 in the certificate used for verifying the PKIData signature 827 must match the name in the certificate request. The Change 828 Subject Name attribute allows the names to be different. 830 4. Modifying the taggedRequest as necessary. Notably adding the 831 public key but also adding certificate extensions, etc. Note 832 that the Modify Certificate Template control is not needed as 833 the RA is generating a new PKIData. 835 5. Generating the POP information for the certificateRequest 836 containing the RA-generated keys. For keys that support 837 digital signatures, the RA includes the POPSigningKey in the 838 CRMF or the signature in the PKCS #10. For encryption-only 839 keys, the RA can indicate that it performed POP by including 840 the RA POP Witness control. Note the CA could force the RA to 841 prove it has possession of the key with the 842 encrypted/decrypted POP mechanism for [RFC5272], but this adds 843 additional round trips and is discussed later in this section. 845 6. Signing the certification request (i.e., the PKIData) with the 846 RA's private key. 848 The RA can also generate bulk requests (i.e., include more than one 849 request in cmsSequence) with the Bulk Request control [RFC5272] but 850 these controls are not depicted in the following sections to simplify 851 the protocol flows. When the RA is requesting more than one key for 852 a given client, the RA includes each request in the reqSequence. 854 The following message flow applies when the RA generates the key. It 855 supports all of the previously defined choices for authentication and 856 shrouding. The diagram below depicts use of a shared secret for 857 authentication by including the Identification control and 858 encapsulating the client's PKIData in an AuthenticatedData. If a 859 digital signature is used for authentication, the Identification 860 control is omitted and the client encapsulates its PKIData in a 862 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 864 SignedData. In the response, the RecipientInfo for the EnvelopedData 865 encapsulating the depends on whether the key was protected with 866 a shared secret (pwri), ephemeral key (ktri or kari), or certificate 867 (ktri or kari). 869 Client RA CA 870 | | | 871 |----------------->| | 872 | [PKIData | | 873 | control: SKGReq, | | 874 | TransactionId, | | 875 | SenderNonce, | | 876 | Identification] | | 877 | |-------------------------------------->| 878 | | | 881 | | (RA signed) | 882 | |<--------------------------------------| 883 | | 886 | | (CA signed includes issued 887 |<-----------------| client certificate) 888 | }> 891 | (RA signed PKIResponse with CA-issued client certificate) 893 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 895 NOTE: There is no need for the RA to provide the SKGReq or the 896 {} to the CA. The CA will not be able to access the contents of 897 the {} because it is encrypted for the client and the CA's 898 response is always returned to the RA because the RA needs to provide 899 the generated {} back to the client. 901 The RA intercepts the response from the CA; it strips the CA's 902 signature and creates a new PKIResponse for the client. The 903 controlSequence is comprised of the Transaction Identifier and 904 Recipient Nonce fields from the client's request, the RA's Sender 905 Nonce, and the Server Key Generation Response (see Section 6.2); the 906 cmsSequence includes the RA-generated {}; and the RA signs the 907 PKIReponse and includes the client's certificate, which was returned 908 in the CA's SignedData. 910 When the RA is generating an encryption-only key pair for the client, 911 and the CA wishes to force the RA to prove it has possession of the 913 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 915 private key, but the RA cannot use it to generate a one-time 916 signature, then the flow is as follows: 918 Client RA CA 919 | | | 920 |----------------->| | 921 | [PKIData | | 922 | control: SKGReq, | | 923 | TransactionId, | | 924 | SenderNonce, | | 925 | Identification] | | 926 | |--------------------------------------->| 927 | | | 931 | |<---------------------------------------| 932 | | | 936 | |--------------------------------------->| 937 | | | 940 | |<---------------------------------------| 941 | | 944 | }>> 948 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 950 NOTE: The number of round trips between the RA and CA in the above 951 figure is twice as many as the first figure in this Section and in 952 Section 2.5.1.1; however, the additional round trip is specified in 953 [RFC5272] (i.e., this document does not introduce the additional 954 round trip). The additional round trip is necessary when the CA 955 forces the RA to perform POP with the CA. While the additional round 956 trip might be problematic between the client and server, the quality 957 of communication connectivity between RA and CA should not make the 958 additional round trips as problematic as between clients and RAs or 959 CAs. 961 2.5.2. RA-Involved Scenarios 962 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 964 This section illustrates a message flow for when the CA generates the 965 client's key. Here too the RA MUST be issued a certificate from the 966 CA, which means that all of the RA-generated PKIData are encapsulated 967 in a SignedData. Furthermore, the RA's certificate can be used for 968 identification and linking identity and POP information. The RA can 969 include the RA Identity Witness control to tell the CA that it 970 performed the client identity checks; the RA will omit the control if 971 it does not perform these checks. 973 The RA can include a Modify Certification Request control [RFC5272] 974 in the PKIData that encapsulates the client's request but these 975 controls are not shown below. The RA does this when it wishes to 976 modify the request present in the Server Key Generation Request 977 control. The RA MUST NOT use the RA POP Witness control if the CA is 978 to generate the key. This control indicates that the RA performed 979 POP, but the key for which POP is claimed has not yet been generated. 981 The diagram below depicts the client's use of a shared secret for 982 authentication by including the Identification control and 983 encapsulating the client's PKIData in an AuthenticatedData. If a 984 digital signature is used for authentication, the Identification 985 control is omitted and the client's PKIData is encapsulated in a 986 SignedData. The RA encapsulates the client's request in its PKIData 987 by placing the client request in the cmsSequence, and includes 988 controls such as Transaction Identifier and Sender Nonce controls as 989 well as RA Identity Witness control if the RA checks the client's 990 identity. 992 Client RA CA 993 | | | 994 |----------------->| | 995 | [PKIData | | 996 | control: SKGReq, | | 997 | TransactionId, | | 998 | SenderNonce, | | 999 | Identification] | | 1000 | |--------------------------------------->| 1001 | | | 1007 | |<---------------------------------------| 1008 | | } > 1018 | | (CA signed includes issued 1019 | | client certificate) 1020 |<-----------------| > (CA signed) 1021 | }> 1024 | (CA signed with issued client certificate) 1026 When the RA receives the response from the CA, it strips the CA's 1027 response for the RA off and passes the inner response to the client 1028 unchanged. The difference between this scenario and the scenarios in 1029 Section 2.5.1 is that the signature on the PKIResponse is generated 1030 by the CA not the RA. 1032 Note that the additional round trips to prove possession of an 1033 encryption-only key depicted in Section 2.5.1 are unnecessary here 1034 because the CA generates the asymmetric key pair and it does not need 1035 to prove to itself that it has the keys. 1037 3. Generating PKIData and PKIResponse 1039 [RFC5272] defines PKIData as follows: 1041 PKIData ::= SEQUENCE { 1042 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1043 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 1044 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1045 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1046 } 1048 [RFC5272] defines PKIResponse as follows: 1050 PKIResponse ::= SEQUENCE { 1051 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1052 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1053 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1054 } 1056 3.1. Client Requests 1058 When the client generates its request, the Server Key Generation 1059 Request control (see Section 6.1) is included in controlSequence; the 1060 other sequences (i.e., reqSequence, cmsSequence, and 1061 otherMsgSequence) are omitted. If a shared secret is used for 1063 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1065 authentication, the Identification control [RFC5272] is included in 1066 the controlSequence to ensure that the server can locate the shared 1067 secret needed to authenticate the request. Additional controls can 1068 be included in controlSequence such as Sender Nonce and Transaction 1069 Identifier [RFC5272]. The reqSequence, which is included for client- 1070 generated key certification requests, is not needed as the Server Key 1071 Generation Request control includes the certification request. The 1072 client's request is either encapsulated in an AuthenticatedData or a 1073 SignedData depending on whether the client is using a shared secret 1074 or a digital signature key to authenticate the request. If the 1075 client wishes to request a certificate with a different name than the 1076 one that is present in the certificate that authenticates the request 1077 or associated with the shared secret, the client must nevertheless 1078 populate the certificateRequest with the Subject Name used in the 1079 existing certificate, and then include the Change Subject Name 1080 control to identify the Subject Name that is desired instead. 1081 Otherwise the server will reject the request as required in 1082 [RFC6402]. 1084 3.2. RA Processing of Client Requests 1086 If an RA is involved, then it can do the following: 1088 o Forward the request as-is to the CA. This happens when the CA 1089 authenticates the request, performs the identity checks, and 1090 generates the keys. 1092 o Authenticate or not the request and place one or more client- 1093 authenticated PKIData in cmsSequence; reqSequence and 1094 otherMsgSequence are omitted. Here the RA does not have the 1095 shared secret necessary to authenticate the request. The RA can 1096 also include additional controls in controlSequence such as the 1097 Modify Certification Request control if the RA needs to modify 1098 the client's request and the Sender Nonce and Transaction 1099 Identifier controls for replay protection and transaction 1100 processing. If the RA performs the Identity checks it can 1101 include the RA Identity Witness control [RFC6402], otherwise it 1102 is omitted. After generation of its PKIData, the RA encapsulates 1103 it in a SignedData as part of the digital signature process. 1105 o Authenticate the request and generate the client's keys. When 1106 the RA generates the client's key, the RA generates a new PKIData 1107 with a reqSequence; cmsSequence and otherMsgSequence are omitted. 1108 The RA must assert its own name as the Subject Name in the 1109 certificateRequest, and include the Change Subject Name attribute 1110 carrying the intended client name, as specified in [RFC6402], in 1111 the PKCS#10 or CRMF because [RFC6402] requires that the name in 1112 the request match the name in the certificate used to 1114 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1116 authenticate the request. If the RA-generated key is signature- 1117 capable, POP is provided in the typical fashion (i.e., the 1118 embedded CRMF or PKCS#10 request includes the POP). The RA can 1119 also include additional controls in controlSequence such as 1120 Sender Nonce and Transaction Identifier. After generation of its 1121 PKIData, the RA encapsulates it in a SignedData as part of the 1122 digital signature process. 1124 o Reject the client's request and return a PKIResponse with an 1125 appropriate reason in the CMC Status Information V2 control. 1126 Additionally, the RA includes Transaction Identifier, Sender 1127 Nonce, and Recipient Nonce if the request included Transaction 1128 Identifier and Sender Nonce controls. The PKIResponse is 1129 encapsulated in a SignedData as part of the digital signature 1130 process. This document defines three additional error conditions 1131 (see Section 7): 1133 * For a Server Key Generation Request control using the 1134 ShroudWithPublicKey choice of certificate or certIdentifier, 1135 the RA can check that the certificate provided to protect the 1136 returned private key validates back to an authorized TA. If 1137 the certificate does not validate back to an authorized TA, 1138 then the RA returns a PKIResponse with a CMC Status Information 1139 v2 control indicating the request failed with an 1140 extendedFailInfo indicating badCertificate (see Section 7) 1141 encapsulated in a SignedData. Note that the RA performing this 1142 check will lessen the load on the CA, but this check need only 1143 be done by the RA when the RA is generating the keys; when the 1144 CA is generating the keys, technically it is up to the CA to 1145 perform this check if it receives a server-side key generation 1146 request from a client. 1148 * For a Server Key Generation Request control using the 1149 ShroudWithSharedSecret choice and where the RA knows the shared 1150 secret, the RA will reject the request if the shared secret 1151 does not match the one on the RA by returning a PKIResponse 1152 with a CMC Status Information control indicating the request 1153 failed with an extendedFailInfo indicating badSharedSecret (see 1154 Section 7) encapsulated in a SignedData. This is done because 1155 client authentication failed or the HMAC output was corrupted. 1157 * For a Server Key Generation Request control that has archiveKey 1158 set to TRUE, the RA is generating the client's keys, and the RA 1159 does not support archive, the RA will reject the request by 1160 returning a PKIResponse with a CMC Status Information v2 1161 control indicating the request failed with an extendedFailInfo 1162 indicating archiveNotSupported (see Section 7) encapsulated in 1163 a SignedData. If the RA knows the CA also does not support 1165 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1167 archival of keys, the RA, if it wishes, can reject the request 1168 in the same fashion; when the CA is generating the keys, 1169 technically it is up to the CA to perform this check if it 1170 receives a CA-generated key request from a client. Note that 1171 the RA performing this check will lessen the load on the CA, 1172 but it need only be done by the RA when the RA is generating 1173 the client's keys. 1175 RAs can also batch more than one request together, by including each 1176 client request in a separate cmsSequence or reqSequence (for Simple 1177 PKI requests) along with a Batch Request control in the RA's 1178 PKIRequest control field. After generation of the PKIData, the RA 1179 encapsulates it in a SignedData as part of the digital signature 1180 process. 1182 When verifying a SignedData signature, the RA verifies it back to an 1183 authorized TA. 1185 3.3. CA Processing 1187 CA processing of requests depends on the number of layers of 1188 encapsulation: 1190 o Requests with a single layer of encapsulation will be validated 1191 back to an authorized TA if they are encapsulated in a SignedData 1192 or authenticated with the shared secret if they are encapsulated 1193 in an AuthenticatedData. For AuthenticatedData encapsulated 1194 requests the server locates the necessary shared secret with the 1195 information found in the Identification control. For a 1196 PKIRequest with a reqSequence, the server verifies the POP. 1197 Regardless of the encapsulation technique, the server performs 1198 the Identity checks and processes other controls such as 1199 Transaction Identifier and Sender Nonce. If any of these checks 1200 fail or processing of a control fails, the CA rejects the 1201 certification request with the appropriate error code, as 1202 specified in [RFC5272]. 1204 o Requests with multiple layers of encapsulation (i.e., those 1205 requests that are RA-involved) will first validate the signature 1206 on the outer SignedData back to an authorized TA and process any 1207 controls present such as RA Identity Witness, Modify Certificate 1208 Template, Sender Nonce, and Transaction Identifier, as per 1209 [RFC5272][RFC6402]. Inner requests are also processed as 1210 specified in the previous bullet. Failure to validate back to an 1211 authorized TA or control processing failures result in rejected 1212 requests with the appropriate error code, as specified in 1213 [RFC5272]. 1215 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1217 CAs may require that the RA prove that it has possession of 1218 encryption-only keys that do not support one-time signature use, by 1219 returning a PKIResponse indicating the request failed because POP is 1220 required and including the Encrypted POP control along with other 1221 appropriate controls. The response is signed by the CA. See Section 1222 2.5.1. 1224 After successfully authenticating the request and verifying the 1225 client's identity, the CA generates: 1227 o Responses for single-layer encapsulated requests for RA-generated 1228 keys by issuing the certificate. If no controls were present in 1229 the request (see Appendix B), the PKIResponse is a Simple PKI 1230 Response [RFC5272], which includes no content and therefore no 1231 signature. With controls (e.g., Transaction Identifier, Sender 1232 Nonce, and Recipient Nonce), the PKIResponse includes the 1233 appropriate controls and is signed by the CA. The CA places the 1234 certificate in the SignedData certificates field. 1236 o Responses for multi-layered encapsulation requests for RA- 1237 generated keys (See Appendix B) beginning as with the previous 1238 bullet to form the inner response. This is placed in 1239 cmsSequences of the outer PKIResponse, which also includes the 1240 Batch Response control as well as any other necessary controls in 1241 controlSequence. The CA generates a signature for the 1242 encapsulating SignedData. 1244 o Responses for single layer encapsulated requests for CA-generated 1245 keys by generating the asymmetric key pair and issuing the 1246 certificate. The signed CA-generated PKIResponse includes the 1247 Server Key Generation Response control (see Section 6.2) along 1248 with other controls based on whether they were present in the 1249 controlSequence as well as the signed and then encrypted 1250 Asymmetric Key Package in cmsSequence. The CA places the 1251 certificate in the SignedData certificates field. 1253 o Responses for multi-layered encapsulation requests for CA- 1254 generated keys beginning with the previous bullet followed by 1255 encapsulating the inner response in cmsSequence for the outer 1256 PKIResponse. The outer response also includes controls as 1257 necessary in controlSequence and the CA generates a signature for 1258 an encapsulating SignedData. 1260 In all cases, the certificate issued is an X.509 certificate 1261 [RFC5280]. 1263 If the CA is unable to perform the request at this time or the entire 1264 request cannot be processed, it can return a signed PKIResponse with 1266 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1268 a CMC Status Information control with a status of pending or partial 1269 along with pendInfo, which the client or RA uses to know when to ask 1270 the CA next about the request. 1272 When the CA fails to or refuses to process the request, it returns a 1273 PKIResponse with a CMC Status Information control with the 1274 appropriate error code from [RFC5272] or from Section 7 of this 1275 document. Additionally, it includes Transaction Identifier, Sender 1276 Nonce, and Recipient Nonce in the response if the request included 1277 Transaction Identifier and Sender Nonce controls. 1279 3.4. RA Processing of CA Responses 1281 If the CA rejected the RA's request as indicated by a PKIResponse 1282 with CMC Status Information control that indicates "failed", then an 1283 out-of-band mechanism may be needed to determine the cause of failure 1284 in order to avoid a loop of the RA returning the same request at a 1285 later time only to have it also rejected. 1287 If the CA returned a pending or partial response, the RA will use the 1288 information in the CMC Status Information control's pendInfo to poll 1289 the CA with a signed PKIRequest with a Query Pending control. CA 1290 processing continues as in Section 3.3. 1292 RAs that are challenged by the CA to prove possession of an 1293 encryption-only RA-generated key validate the CA's signature back to 1294 an authorized TA, decrypt the POP, and process any other controls 1295 that are present. If any of these fail, then the RA terminates the 1296 request and informs the operator of the fault. Assuming the checks 1297 pass, the RA generates a PKIData that includes a Decrypted POP 1298 control and any other controls with no cmsSequence, reqSequence, or 1299 otherMsgSequence. The RA encapsulates the PKIData in a SignedData as 1300 part of the digital signature process and sends it to the CA. CA 1301 processing resumes as in Section 3.3. 1303 Assuming the response is a success: 1305 o If the CA returned a Simple PKI Response (i.e., the CA returns a 1306 certs-only message for RA-generated keys whose PKIRequest 1307 includes no additional controls), then the RA generates a 1308 PKIResponse for the client that includes the signed and then 1309 encrypted Asymmetric Key Package in cmsSequence (see Section 5), 1310 the Server Key Generation Response control (see Section 6.2), and 1311 any other controls. The RA encapsulates the PKIResponse for the 1312 client in a SignedData as part of the digital signature process 1313 and includes the client's certificate (from the returned certs- 1314 only message) in the SignedData's certificate field. 1316 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1318 o If the CA returned a Full PKI Response, then one of three cases 1319 is possible: 1321 * The response is for RA-generated keys. The RA generates a 1322 PKIResponse for the client that includes the signed and then 1323 encrypted Asymmetric Key Package in cmsSequence (see Section 1324 5), the Server Key Generation Response control (see Section 1325 6.2), and any other controls as appropriate. Finally, the RA 1326 encapsulates the PKIResponse for the client in a SignedData as 1327 part of the digital signature process and includes the client's 1328 certificate from the CA's response in the RA's SignedData 1329 certificates field. 1331 * The response is for CA-generated keys. The RA processes any 1332 controls and assuming the processing passes, the RA strips off 1333 the outer SignedData and forwards the cmsSequence element 1334 (i.e., the inner SignedData) to the client. 1336 Responses to batch requests (i.e., those Full PKI Requests that 1337 include the Batch Request control) are distributed by the RA to 1338 clients depending on whether the keys are RA-generated or CA- 1339 generated. 1341 The RA, if it wishes, can also check the returned certificate to make 1342 sure it validates back to an authorized TA and that the returned 1343 certificate is consistent with the certificate request found in the 1344 Server Key Generation Request control. These checks cut down on 1345 errors at the client. If the RA detects that the certificate is not 1346 consistent, the RA SHOULD NOT return the certificate to the client 1347 and the RA SHOULD request that the certificate be revoked. 1349 RA-generated keys for which a PKIResponse with a CMC Status 1350 Information control that is not success SHOULD NOT return the Server 1351 Key Generation Response or the encapsulated Asymmetric Key Package to 1352 the client because the CA did not certify the public key. 1354 3.5. Client Processing of Responses 1356 Clients validate the signature on all responses back to an authorized 1357 TA. 1359 Responses signed by an RA with a client certificate signed by a CA 1360 whose certificate includes an id-kp-cmcCA EKU (Extended Key Usage) 1361 [RFC6402] will violate the "SHOULD" requirement found in [RFC6402] 1362 that the PKIResponse be signed by an entity with the same name as 1363 found in the certificate. Because the RA has generated the keys 1364 there are many more bad things an RA can do so this seemed like a 1365 tradeoff worth making. 1367 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1369 4. Shrouding Algorithms 1371 For the server-side key generation control attribute described in 1372 this document to function, clients need to tell the server in advance 1373 what encryption algorithm and what key value is to be used for 1374 encrypting the returned private key. The encrypted data returned is 1375 returned as an EnvelopedData object as defined by [RFC5652] and 1376 placed in the cmsSequence field of a PKIResponse [RFC5272]. Clients 1377 also need to tell the server what digital signature and hash 1378 algorithms they support to ensure the certification response and 1379 certificate can be verified. 1381 Each request control for which the response includes encrypted data 1382 contains two fields to define the type of encryption used: 1383 algCapabilities and shroudMethod. 1385 The algCapabilities field, see Section 6.1, contains the advertised 1386 capabilities of the client-side entity. This field uses the S/MIME 1387 Capabilities type defined in section 2.5.2 of [RFC5751]. The 1388 capabilities to be listed are digital signature algorithms, message 1389 digest algorithms, content encryption algorithms, key agreement 1390 algorithms, key encipherment algorithms, key-wrap algorithms, and key 1391 derivation algorithms. Encodings for SMIME Capability values for 1392 Elliptic Curve Key Agreement, Key Derivation Function, and Key Wrap 1393 algorithms can be found in [RFC5753], Message Digest and Signature 1394 algorithms can be found in [RFC5754], and AES Key Wrap with Padding 1395 can be found in [RFC5959]. 1397 The shroudMethod field (see Section 6.1) defines the method by which 1398 the server will do the key management of the content encryption key 1399 (CEK) value in EnvelopedData. The shroudMethod field uses the type 1400 ShroudMethod. This type is defined as: 1402 ShroudMethod ::= AlgorithmIdentifier { 1403 SHROUD-ALGORITHM, { ShroudAlgorithmSet } 1404 } 1406 When a new shroud method is defined it includes (a) the source of the 1407 key material, (b) the public or salting information, and (c) the 1408 method of protecting the Content Encryption Key (CEK) using the 1409 requested data, source key material, and salt. This document defines 1410 two shroud methods: id-cmc-shroudWithPublicKey and id-cmc- 1411 shroudWithSharedSecret. Clients and servers MUST support id-cmc- 1412 shroudWithPublicKey. Client and servers SHOULD support id-cmc- 1413 shroudWithSharedSecret. 1415 Other shrouding methods could be defined in the future that would not 1416 involve the use of EnvelopedData. For example, one could conceive of 1418 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1420 a shrouding method that required the use of Transport Layer Security 1421 (TLS) [RFC5246] to provide the necessary security between the server 1422 and the client. This document does not define any such mechanism. 1424 4.1. Shroud with a Public Key 1426 Clients can indicate that the server use a public key, either wrapped 1427 in a certificate or as a bare public key, to protect the server- 1428 generated key. For this option, the key material is either included 1429 or referenced by a key identifier. The following object identifier 1430 identifies the shroudWithPublicKey shroud method: 1432 id-alg-shroudWithPublicKey OBJECT IDENTIFIER ::= { id-alg XX } 1434 shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey: 1436 srda-shroudWithPublicKey SHROUD-ALGORITHM ::= { 1437 IDENTIFIED BY id-alg-shroudWithPublicKey, 1438 PARAMS TYPE ShroudWithPublicKey ARE required, 1439 SMIME-CAPS { IDENTIFIED BY id-alg-shroudWithPublicKey } 1440 } 1442 ShroudWithPublicKey ::= CHOICE { 1443 certificate Certificate, 1444 certIdentifier [1] SignerIdentifier, 1445 bareKey [2] SEQUENCE { 1446 publicKey SubjectPublicKeyInfo, 1447 ski SubjectKeyIdentifier 1448 } 1449 } 1451 The fields of type ShroudWithPublicKey have the following meanings: 1453 o certificate provides a public key certificate containing the 1454 public key to be used for encrypting the server-generated private 1455 key from the server to the client. 1457 o certIdentifier provides a pointer to a public key certificate 1458 located in the SignedData that encapsulates the client's PKIData. 1460 For the above two fields, servers SHOULD check that the subject 1461 and, if included, subject alternative names match in some way 1462 with the entity that the private key is destined for. Servers do 1463 this to ensure the key they have made for the client is intended 1464 for the correct client. This mechanism is beyond the scope of 1465 this document. 1467 o bareKey allows for an arbitrary public key to be used to return 1469 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1471 the encrypted private key. 1473 - publicKey contains the public key to be used when generating 1474 the EnvelopedData returned from the server to the client. 1476 - ski contains the SubjectKeyIdentifier that will be used in CMS 1477 EnvelopedData to identify the public key when encrypting the 1478 private key from the server to the client. 1480 When this method is used with the certificate option, the server 1481 validates the certificate back to a trust anchor. Further, the 1482 server checks that the client-provided certificate belongs to the 1483 same client that authenticated the certification request (e.g. the 1484 certificate subjects match or the client-provided certificate belongs 1485 to the same entity as the authentication shared secret). If either 1486 of these checks fails, then the server returns a CMCFailInfo with the 1487 value of badCertificate, which is defined in Section 7. 1489 4.2. Shroud with a Shared Secret 1491 Clients can indicate that servers use a shared secret value to 1492 protect the server-generated private key. For this option, the key 1493 material is identified by the identifier; the key derivation 1494 algorithms supported by the client are included in the 1495 algCapabilities field. No salting material is provided by the 1496 client. The derived key is then used as a key encryption key in the 1497 EnvelopedData recipient info structure. The following object 1498 identifier identifies the shroudWithSharedSecret shroud method: 1500 id-alg-shroudWithSharedSecret OBJECT IDENTIFIER ::= {id-alg XX} 1502 shroudWithSharedSecret has the ASN.1 type ShroudWithSharedSecret: 1504 shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= { 1505 IDENTIFIED BY id-alg-shroudWithSharedSecret 1506 PARAMS TYPE ShroudWithSharedSecret ARE required 1507 SMIME-CAPS { IDENTIFIED BY id-alg-shroudWithSharedSecret } 1508 } 1510 ShroudWithSharedSecret ::= UTF8String 1512 The client includes an identifier in the ShroudWithSharedSecret 1513 field, which is an UTFString [RFC5280], that the server uses to 1514 locate the shared secret to be used to protect the returned server- 1515 generated private key. The secret identified by the 1516 ShroudWithSharedSecret field may be different than the secret 1517 referred to by the identification control, which is used to identify 1518 the shared secret used to authenticate the request. In addition, the 1520 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1522 client needs to place both a key derivation function and a key wrap 1523 function in the set of capabilities advertised by the client in the 1524 algCapabilities field. 1526 When this method is used, the server checks that the chosen shared 1527 secret belongs to the authenticated identity of the entity that 1528 generated the certification request. If this check fails, then the 1529 server returns a CMCFailInfo with the value of badSharedSecret, which 1530 is defined in Section 7. In general, while it is expected that the 1531 same identity token and shared secret used to do the identity 1532 authentication are used to derive the key encryption key this is not 1533 required. 1535 5. Returned Key Format 1537 Server-generated keys are returned to the client with the 1538 AsymmetricKeyPackage content type [RFC5958]. There MUST be only one 1539 OneAsymmetricKey present in the AsymmetricKeyPackage sequence and the 1540 public key SHOULD be included in the OneAsymmetricKey. The public 1541 key is provided by the server for convenience and for uniformity of 1542 message format because the client either compute the public from the 1543 private key or extract it from the certificate. If the client 1544 exchanges the public key, either in a certificate or the bare key, 1545 with another party it should check that the public key corresponds to 1546 the returned private key. If not, the client can discard the 1547 returned public key. 1549 The AsymmetricKeyPackage is encapsulated in a CMS SignedData content 1550 type [RFC5652]; during the encapsulation process a digital signature 1551 is applied by the server. After being signed, the 1552 AsymmetricKeyPackage is cryptographically protected by encapsulating 1553 it in an EnvelopedData (i.e., the server-generated and signed private 1554 key is encrypted for the recipient). The resulting EnvelopedData is 1555 then included in a PKIResponse.cmsSequence and the entire PKIResponse 1556 is encapsulated in another SignedData. The Content Hints attribute 1557 [RFC2634] in the outer SignedData can provide a hint as to the inner 1558 most content type (i.e., the AsymmetricKeyPackage). Depending on 1559 where the key was generated the server can be either a CA or an RA. 1561 When multiple keys are returned by the server, the server places each 1562 EnvelopedData in the cmsSequence. 1564 6. Server-Side Key Generation 1566 This section provides the control attributes necessary for doing 1567 server-side generation of keys for clients. The client places the 1568 request for the key generation in a request message and sends it to 1569 the server. The server will generate the key pair, create a 1571 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1573 certificate for the public key and return the data in a response 1574 message, or the server will return a failure indication. 1576 6.1. Server-Side Key Generation Request Attribute 1578 The client initiates a request for server-side key generation by 1579 including the server-side key generation request attribute in the 1580 control attributes section of a PKIData object. The request 1581 attribute includes information about how to return the generated key 1582 as well as any client suggested items for the certificate. The 1583 control attribute for doing server-side key generation is identified 1584 by the following OID: 1586 id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX } 1588 The Server-Side Key Generation Request control attribute has the 1589 following ASN.1 definition: 1591 cmc-serverKeyGenRequest CMC-CONTROL ::= { 1592 ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest 1593 } 1595 ServerKeyGenRequest ::= SEQUENCE { 1596 certificateRequest TaggedRequest, 1597 shroudMethod ShroudMethod, 1598 algCapabilities SMimeCapabilities OPTIONAL, 1599 archiveKey BOOLEAN DEFAULT TRUE 1600 } 1602 The fields in ServerKeyGenRequest have the following meaning: 1604 o certificateRequest contains the data fields that the client 1605 suggests for the certificate being requested for the server 1606 generated key pair. The format is TaggedRequest from [RFC5272], 1607 which supports both PKCS#10 and CRMF requests. In all instances, 1608 the bodyPartID is set to zero. 1610 o shroudMethod contains the identifier of the type of algorithm to 1611 be used in deriving the key used to encrypt the private key. 1613 o algCapabilities contains the set of algorithm capabilities being 1614 advertised by the client. The server uses algorithms from this 1615 set in the ServerKeyGenResponse object to encrypt the private key 1616 of the server-generated key pair. This field is optional because 1617 this information might be carried in a signed attribute, included 1618 within a certificate, or be part of the local configuration. 1620 o archiveKey is set to TRUE if the client wishes the key to be 1622 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1624 archived as well as generated on the server. Further processing 1625 by the server when this is set to TRUE is out-of-scope. 1627 The client can request that the generated key be for a specific 1628 algorithm by placing data in the publicKey.attribute field of the 1629 CRMF request or in the subjectPKInfo.attribute field of the PKCS#10 1630 request. If the publicKey or subjectPKInfo field is populated, then 1631 the subjectPublicKey is a zero-length bit string. If the client 1632 requests a specific algorithm, the server either generates a key for 1633 that algorithm (with the parameters if defined) or fails to process 1634 the request. If the request fails for this reason, the server 1635 returns a CMCFailInfo with a value of badAlg [RFC5272]. 1637 As specified in [RFC5272]: 1639 "A server is not required to use all of the values suggested by 1640 the client in the certificate template. Servers MUST be able to 1641 process all extensions defined in [RFC5280]. Servers are not 1642 required to be able to process other V3 X.509 extensions 1643 transmitted using this protocol, nor are they required to be able 1644 to process other, private extensions. Servers are permitted to 1645 modify client-requested extensions. Servers MUST NOT alter an 1646 extension so as to invalidate the original intent of a client- 1647 requested extension. (For example change key usage from key 1648 exchange to digital signature.) If a certification request is 1649 denied due to the inability to handle a requested extension, the 1650 server MUST respond with a CMCFailInfo with a value of 1651 unsupportedExt." 1653 A server that does not recognize the algorithm identified in 1654 shroudMethod will reject the request. The server returns a 1655 CMCFailInfo with a value of badAlg [RFC5272]. 1657 A server that does not support at least one of the algCapabilities 1658 will reject the request. The server returns a CMCFailInfo with a 1659 value of badAlg [RFC5272]. 1661 If archiveKey is set to TRUE and the server does not support 1662 archiving of private keys, the request will be rejected by the 1663 server. The server returns a CMCFailInfo with a value of 1664 archiveNotSupported, see Section 7. 1666 6.2. Server-side Key Generation Response 1668 The server creates a server-side key generation response attribute 1669 for every key generation request made and successfully completed. 1670 The response message has a pointer to both the original request 1671 attribute and to the body part in the current message that holds the 1673 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1675 encrypted private keys. The response message also can contain a 1676 pointer to the certificate issued. The key generation response 1677 control attribute is identified by the OID: 1679 id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= { id-cmc XX } 1681 The Server-Side Key Generation Response control attribute has the 1682 following ASN.1 definition: 1684 cmc-serverKeyGenResponse CMC-CONTROL ::= { 1685 ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse 1686 } 1688 ServerKeyGenResponse ::= SEQUENCE { 1689 cmsBodyPartId BodyPartID, 1690 requestBodyPartId BodyPartID, 1691 signerIdentifier SignerIdentifier 1692 } 1694 The fields in ServerKeyGenResponse have the following meaning: 1696 o cmsBodyPartId identifies a TaggedContentInfo contained within the 1697 enclosing PKIData. The ContentInfo object is of type 1698 EnvelopedData and has an encapsulated content of id-ct-KP- 1699 aKeyPackage, which is the OID for the Asymmetric Key Pacakge (see 1700 Section 5). 1702 o requestBodyPartId contains the body part identifier of the 1703 server-side key generation request control attribute in the 1704 request message. This allows for clients to associate the 1705 resulting key and certificate with the original request. 1707 o signerIdentifier refers the certificate issued to satisfy the 1708 request. The certificate, if present, is placed in the 1709 certificate bag of the immediately encapsulating SignedData 1710 object. 1712 As specified in [RFC5272]: 1714 "Clients MUST NOT assume the certificates are in any order. 1715 Servers SHOULD include all intermediate certificates needed to 1716 form complete chains to one or more self-signed certificates, not 1717 just the newly issued certificate(s) in the certificate bag. The 1718 server MAY additionally return CRLs in the CRL bag. Servers MAY 1719 include self-signed certificates. Clients MUST NOT implicitly 1720 trust included self-signed certificate(s) merely due to its 1721 presence in the certificate bag." 1723 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1725 7. Additional Error Codes 1727 This section defines ExtendedFailInfo errors from this document. The 1728 ASN.1 is as follows: 1730 id-cet-serverKeyGen OBJECT IDENTIFIER ::= { id-cet TBD } 1732 cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= { 1733 TYPE ErrorList IDENTIFIED BY id-cet-serverKeyGen 1734 } 1736 ErrorList ::= INTEGER { 1737 archiveNotSupported (1), 1738 badCertificate (2), 1739 badSharedSecret (3) 1740 } 1742 The errors have the following meaning: 1743 o archiveNotSupported indicates that the server does not support 1744 archiving of private keys. 1746 o badCertificate indicates that the certificate to be used to 1747 encrypt the response did not validate back to an RA/CA trust 1748 anchor or the certificate does not belong to the client. 1750 o badSharedSecret indicates that the shared secret used by the 1751 client does not match that stored by the server. 1753 8. Proof-of-Possession 1755 Some servers may require that the client prove that it has taken 1756 possession of the server-generated key. This proof requires an 1757 additional roundtrip beyond those previously discussed. 1759 For certificates returned that support digital signatures the process 1760 is as described in [RFC5272]: the server indicates in CMCStatus that 1761 status is confirmRequired; the client returns the Confirm Certificate 1762 Acceptance control in PKIData signed with the server-generated 1763 private key; and the server responds with a CMCStatus of success. 1765 For certificates returned that only support encryption, the server 1766 indicates the CMCStatus is popRequired and includes the Encrypted POP 1767 control; the client returns the Decrypted POP control. Whether the 1768 PKIRequest from the client is encapsulated in an AuthenticatedData or 1769 SignedData depends on which mechanism was used during the server key 1770 generation request. 1772 9. Security Considerations 1773 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1775 Central generation of digital signature keys contains risks and is 1776 not always appropriate. Organization-specific CPs (Certificate 1777 Policies) [RFC3647] define whether server-side generation of digital 1778 signature keys is permitted. 1780 For the choice of mechanisms to protect the server-generated key, 1781 there is a balance that needs to be maintained between the use of a 1782 potentially poorly generated one-time key (i.e., the shared secret) 1783 and the use of a key externally provided. For externally provided 1784 keys, the external provider of the key will be able to decrypt the 1785 key delivery message as long as it was captured. For poorly generated 1786 one-time keys, any external party might be able to guess the key and 1787 thus decrypt the key delivery message. Different types of keys will 1788 have different requirements for what a poorly generated key means. 1789 Generators of RSA keys need to be able to do good prime checking; 1790 generators of Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman 1791 (ECDH) keys only need a moderate quality random number generator if 1792 the group parameters are externally provided and of good quality. 1794 This specification requires implementations to generate key pairs and 1795 other random values [RFC4086]. The use of inadequate pseudo-random 1796 number generators (PRNGs) can result in little or no security. The 1797 generation of quality random numbers is difficult. NIST Special 1798 Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer 1799 guidance. 1801 Private keys, regardless of where they are generated, must be 1802 appropriately protected from disclosure or modification on the 1803 server, in transit, and on the client. Cryptographic algorithms and 1804 keys used to protect the private key should be at least as strong as 1805 the private key's intended strength. 1807 This document describes the CA signing certificates and messages as 1808 well as encrypting messages. It should not be assumed that the CA 1809 uses the same key for all of these operations. In fact, CAs may wish 1810 to limit the exposure of their private keys by using different keys 1811 for different purposes. 1813 Key agreement algorithms (i.e., Diffie-Hellan or Elliptic Curve 1814 Diffie-Hellman) can be used to protect the returned server-generated 1815 key. These algorithms support a number of different schemes [SP-800- 1816 56]. Normally, an Ephemeral-Static (E-S) scheme is used (more 1817 formally known as "(Cofactor) One-Pass Diffie-Hellman, 1818 C(1e,1s,ECCCDH) Scheme") see [RFC5753], but here the client provides 1819 an ephemeral key to the server so an S-E scheme is used when the key 1820 is encrypted for the client. Regardless, the client needs to 1821 generate an ephemeral key and provide it to the server and this key 1822 needs to use the same parameters (i.e., p, q, g for DH and elliptic 1824 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1826 curve for ECDH) as the server. The client's parameters MUST be 1827 present in the publicKey or certificate field of the Server Key 1828 Generation Request control or MUST be in the certificate referred to 1829 by the ski in the same control. The client can find the server's 1830 parameters in the server's certificate; to make it easy on clients, 1831 server certificates MUST include parameters. How the client obtains 1832 the server's certificate is out-of-scope. 1834 Servers that support the features specified herein need to document 1835 their procedures in a CPS (Certificate Practice Statement) [RFC3647]. 1836 CAs that certify server-generated private keys are certifying that 1837 they have taken due diligence to ensure that the private key is only 1838 known to and used by the subject. Depending on the Certification 1839 Policy (CP) [RFC3647], the keys have been allocated to the subject, 1840 but the keys may not be strictly owned by the subject. The CA (and 1841 the enterprise it supports) has a reason for issuing the keys (e.g., 1842 employer to employee; school to student) and because the enterprise 1843 CA generated the private keys it is accountable for the 1844 trustworthiness of the private key. But, the subject should beware of 1845 using it for other purposes. 1847 When using an ephemeral key for protecting the server-generated key, 1848 a compromised signature key, when used by the intended party, will 1849 not automatically jeopardize the security of the server-generated 1850 keys. Procedural controls can help to ensure a one-to-one mapping 1851 between verified requests and intended parties (i.e. mitigate the 1852 risk of masquerade using a compromised authentication key and 1853 certificate), but that is outside the scope of this document. 1855 POP is important; [RFC4211] provides some information about POP; for 1856 server-generated keys it can only be provided after the server- 1857 generated key has been returned by the client (see Section 8). 1858 Whether a server requires POP is CP dependent [RFC3647], but highly 1859 recommended. 1861 When a shared secret is used to provide client authentication and 1862 protect the server-generated private key, the shared secret must be 1863 kept secret for the lifetime of the key or its use must be restricted 1864 to one-time use by the server. The rationale is that disclosure 1865 provides attackers access to the server-generated private key in the 1866 PKIResponse. This is different than certification requests with 1867 client-generated keys because the shared secret never protects the 1868 private key, so its loss does not comprise the private key. 1870 If the key generator and the server are not collocated, then the 1871 exchange between these two entities must be protected from 1872 unauthorized disclosure and modification and both entities must have 1873 a trust relationship. However, these exchanges are beyond the scope 1875 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1877 of this document. Note that the CA needs access to the public key to 1878 generate the certificate. If the key generator encrypts the 1879 generated key for the client, then the key generator needs to provide 1880 the public key to the CA (possibly through the RA). 1882 Returning the key to the wrong client can be bad. If an encrypted 1883 key is returned to the wrong client, then it is only bad if the key 1884 was encrypted for the wrong client and then something much worse is 1885 afoot. If the encrypted key is returned to the wrong client and it 1886 is encrypted for the right client (i.e., it was misdirected), then it 1887 is bad but the unencrypted key has not been disclosed to an 1888 unauthorized client. The protection afforded by the confidentiality 1889 algorithm is what protects the misdirected key from unauthorized 1890 disclosure. 1892 10. IANA Considerations 1894 This document makes use of object identifiers; all object identifiers 1895 are defined in the PKIX arc described in [RFC7299]. IANA is 1896 requested to register the following OIDs: 1898 1) In the SMI Security for PKIX Module Identifier arc: 1900 Decimal Description References 1901 ------- ------------------------------- --------------------- 1902 TBD id-mod-cmc-serverkeygen-2014-02 [This Document] 1904 2) In the SMI Security for PKIX CMC Controls arc: 1906 Decimal Description References 1907 ------- ------------------------------ --------------------- 1908 TBD id-cmc-serverKeyGenRequest [This Document] 1909 TBD id-cmc-serverKeyGenResponse [This Document] 1911 3) In the SMI Security for PKIX Algorithms arc: 1913 Decimal Description References 1914 ------- ------------------------------ --------------------- 1915 TBD id-alg-shroudWithPublicKey [This Document] 1916 TBD id-alg-shroudWithSharedSecret [This Document] 1918 4) In the SMI Security for PKIX CMC Error Types arc: 1920 Decimal Description References 1921 ------- ------------------------------ --------------------- 1922 TBD id-cet-serverKeyGen [This Document] 1924 11. References 1925 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1927 11.1 Normative References 1929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1930 Requirement Levels", BCP 14, RFC 2119, March 1997. 1932 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1933 Request Syntax Specification Version 1.7", RFC 2986, 1934 November 2000. 1936 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1937 Certificate Request Message Format (CRMF)", RFC 4211, 1938 September 2005. 1940 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1941 (CMC)", RFC 5272, June 2008. 1943 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1944 Housley, R., and W. Polk, "Internet X.509 Public Key 1945 Infrastructure Certificate and Certificate Revocation List 1946 (CRL) Profile", RFC 5280, May 2008. 1948 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1949 RFC 5652, September 2009. 1951 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1952 Mail Extensions (S/MIME) Version 3.2 Message 1953 Specification", RFC 5751, January 2010. 1955 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1956 2010. 1958 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1959 Updates", RFC 6402, November 2011. 1961 12.2 Informative References 1963 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 1964 RFC 2634, June 1999. 1966 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1967 Wu, "Internet X.509 Public Key Infrastructure Certificate 1968 Policy and Certification Practices Framework", RFC 3647, 1969 November 2003. 1971 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1972 "Randomness Requirements for Security", BCP 106, RFC 4086, 1973 June 2005. 1975 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 1977 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 1978 36, RFC 4949, August 2007. 1980 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1981 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1983 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1984 Cryptography (ECC) Algorithms in Cryptographic Message 1985 Syntax (CMS)", RFC 5753, January 2010. 1987 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1988 Message Syntax", RFC 5754, January 2010. 1990 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 1991 Type", RFC 5959, August 2010. 1993 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1994 Working Group", RFC 7299, July 2014. 1996 [FIPS-186] National Institute of Standards and Technology (NIST), 1997 FIPS 186-3 DRAFT: Digital Signature Standard (DSS), 1998 November 2008. 2000 [SP-800-56] Barker, E., Johnson, D., and M. Smid, 2001 "Recommendation for Pair-Wise Key Establishment Schemes 2002 Using Discrete Logarithm Cryptography", NIST Special 2003 Publication 800-56A Revision 1, March 2007. 2005 [SP-800-57] National Institute of Standards and Technology (NIST), 2006 Special Publication 800-57: Recommendation for Key 2007 Management - Part 1 (Revised), March 2007. 2009 [SP-800-90] National Institute of Standards and Technology (NIST), 2010 Special Publication 800-90: Recommendation for Random 2011 Number Generation Using Deterministic Random Number Bit 2012 Generators (Revised), March 2007. 2014 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2016 Appendix A. ASN.1 Module 2018 CMC-KeyGen 2019 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 2020 mechanisms(5) pkix(7) id-mod(0) 2021 id-mod-cmc-serverkeygen-2014-02(TBD) } 2022 DEFINITIONS ::= 2023 BEGIN 2024 IMPORTS 2026 AlgorithmIdentifier{}, SMIMECapabilities{}, ParamOptions, SMIME-CAPS 2027 FROM AlgorithmInformation-2009 2028 { iso(1) identified-organization(3) dod(6) internet(1) 2029 security(5) mechanisms(5) pkix(7) id-mod(0) 2030 id-mod-algorithmInformation-02(58) } 2032 Certificate, SubjectPublicKeyInfo 2033 FROM PKIX1Explicit-2009 2034 { iso(1) identified-organization(3) dod(6) internet(1) 2035 security(5) mechanisms(5) pkix(7) id-mod(0) 2036 id-mod-pkix1-explicit-02(51) } 2038 IssuerAndSerialNumber, SubjectKeyIdentifier, SignerIdentifier 2039 FROM CryptographicMessageSyntax-2010 2040 { iso(1) member-body(2) us(840) rsadsi(113549) 2041 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 2043 BodyPartID, EXTENDED-FAILURE-INFO, TaggedRequest, CMC-CONTROL, id-cmc 2044 FROM EnrollmentMessageSyntax-2011-v08 2045 { iso(1) identified-organization(3) dod(6) internet(1) 2046 security(5) mechanisms(5) pkix(7) id-mod(0) 2047 id-mod-enrollMsgSyntax-2011-08(76) } 2049 SMimeCapsSet 2050 FROM SecureMimeMessageV3dot1-2009 2051 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2052 smime(16) modules(0) id-mod-msg-v3dot1-02(39) } 2053 ; 2055 Keygen-controls CMC-CONTROL ::= { 2056 cmc-serverKeyGenRequest | cmc-serverKeyGenResponse, ... 2057 } 2059 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2061 SHROUD-ALGORITHM ::= CLASS { 2062 &id OBJECT IDENTIFIER UNIQUE, 2063 &Params OPTIONAL, 2064 ¶mPresence ParamOptions DEFAULT absent, 2065 &smimeCaps SMIME-CAPS OPTIONAL 2066 } WITH SYNTAX { 2067 IDENTIFIED BY &id 2068 [PARAMS [TYPE &Params] ARE ¶mPresence] 2069 [SMIME-CAPS &smimeCaps] 2070 } 2072 ShroudAlgorithmSet SHROUD-ALGORITHM ::= { 2073 srda-shroudWithPublicKey | shrda-shroudWithSharedSecret, ... } 2075 ShroudMethod ::= AlgorithmIdentifier { 2076 SHROUD-ALGORITHM, { ShroudAlgorithmSet } 2077 } 2079 id-alg OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2080 dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 2081 } 2083 id-alg-shroudWithPublicKey OBJECT IDENTIFIER ::= { id-alg TBD } 2085 srda-shroudWithPublicKey SHROUD-ALGORITHM ::= { 2086 IDENTIFIED BY id-alg-shroudWithPublicKey 2087 PARAMS TYPE ShroudWithPublicKey ARE required 2088 SMIME-CAPS { IDENTIFIED BY id-alg-shroudWithPublicKey } 2089 } 2091 ShroudWithPublicKey ::= CHOICE { 2092 certificate Certificate, 2093 certIdentifier [1] SignerIdentifier, 2094 bareKey [2] SEQUENCE { 2095 publicKey SubjectPublicKeyInfo, 2096 ski SubjectKeyIdentifier 2097 } 2098 } 2100 id-alg-shroudWithSharedSecret OBJECT IDENTIFIER ::= {id-alg TBD } 2102 shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= { 2103 IDENTIFIED BY id-alg-shroudWithSharedSecret 2104 PARAMS TYPE ShroudWithSharedSecret ARE required 2105 SMIME-CAPS { IDENTIFIED BY id-alg-shroudWithSharedSecret } 2106 } 2108 ShroudWithSharedSecret ::= UTF8String 2110 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2112 id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc TBD } 2114 cmc-serverKeyGenRequest CMC-CONTROL ::= { 2115 ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest 2116 } 2118 ServerKeyGenRequest ::= SEQUENCE { 2119 certificateRequest TaggedRequest, 2120 shroudMethod ShroudMethod, 2121 algCapabilities SMimeCapabilities, 2122 archiveKey BOOLEAN DEFAULT TRUE 2123 } 2125 SMimeCapabilities ::= SMIMECapabilities{{SMimeCapsSet}} 2127 id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= { id-cmc TBD } 2129 cmc-serverKeyGenResponse CMC-CONTROL ::= { 2130 ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse 2131 } 2133 ServerKeyGenResponse ::= SEQUENCE { 2134 cmsBodyPartId BodyPartID, 2135 requestBodyPartId BodyPartID, 2136 signerIdentifier SignerIdentifier 2137 } 2139 id-cet OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2140 dod(6) internet(1) security(5) mechanisms(5) pkix(7) cet(15) 2141 } 2143 id-cet-serverKeyGen OBJECT IDENTIFIER ::= { id-cet TBD } 2145 cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= { 2146 TYPE ErrorList IDENTIFIED BY id-cet-serverKeyGen 2147 } 2149 ErrorList ::= INTEGER { 2150 archiveNotSupported (1), 2151 badCertificate (2), 2152 badSharedSecret (3) 2153 } 2155 END 2157 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2159 Appendix B. Additional Message Flows 2161 This appendix forms a non-normative part of this specification. 2163 The main body of this document has portrayed protocol flows with 2164 optional controls. This was done to explain the more complicated 2165 scenarios. This appendix depicts the flows without those optional 2166 controls. 2168 For example the figure in Section 2.5.1 without the TransactionId, 2169 SenderNonce, and RecipientNonce, appears as follows: 2171 Client RA CA 2172 | | | 2173 |----------------->| | 2174 | [PKIData | | 2175 | control: SKGReq, | | 2176 | Identification] | | 2177 | |-------------------------------------->| 2178 | | | 2180 | |<--------------------------------------| 2181 |<-----------------| PKIResponse 2182 | }> 2186 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 2188 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2190 The PKIResponse from the CA is a certs-only message, which does not 2191 include a signature. 2193 Likewise for the figure in Section 2.5.2: 2195 Client RA CA 2196 | | | 2197 |----------------->| | 2198 | [PKIData | | 2199 | control: SKGReq, | | 2200 | Identification] | | 2201 | |--------------------------------------->| 2202 | | | 2206 | |<---------------------------------------| 2207 | | } > > 2211 | }> 2215 If the RA does not perform the Identity checks, then it can forward 2216 the client's request without the additional layers of encapsulation. 2218 Client RA CA 2219 | | | 2220 |----------------->| | 2221 | [PKIData | | 2222 | control: SKGReq, | | 2223 | Identification] | | 2224 | |--------------------------------------->| 2225 | | [PKIData | 2226 | | control: SKGReq, Identification] | 2227 | |<---------------------------------------| 2228 | | }> 2231 |<-----------------| 2232 | }> 2236 Not to be outdone, the scenarios in Section 2.5.1 can be more 2237 complicated by an RA that batches requests together. The following 2239 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2241 depicts a number of clients sending requests together that an RA then 2242 batches together. The unsigned PKIResponse (a certs-only message) 2243 includes all of the certificates issued. The CA can also return 2244 individual responses as opposed to batching them all together or it 2245 can batch them together in some other combination. 2247 Client(1-n) RA CA 2248 | | | 2249 |----------------->| | 2250 | [PKIData | | 2251 | control: SKGReq, | | 2252 | Identification] | | 2253 | |-------------------------------------->| 2254 | | | 2256 | |<--------------------------------------| 2257 | | 2260 | }> 2264 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 2266 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2268 In another scenario, all but one of the requests were successfully 2269 processed. The RA returns those that were successful back to the 2270 clients but later polls the CA, based on the value CMCStatusInfoV2 2271 pendInfo, for the one that was not successful. The CA returns the 2272 one successful request. 2274 Client(1-n) RA CA 2275 | | | 2276 |----------------->| | 2277 | [PKIData | | 2278 | control: SKGReq, | | 2279 | Identification] | | 2280 | |-------------------------------------->| 2281 | | | 2284 | |<--------------------------------------| 2285 | | 2289 |<-----------------| 2290 | }> | 2293 | |-------------------------------------->| 2294 | | | 2296 | |<--------------------------------------| 2297 | | PKIResponse 2298 |<-----------------| 2299 | }> 2303 * Includes ChangeSubjectName attribute in PKCS #10 or CRMF. 2305 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2307 Batching the requests can also be performed for CA-generated keys as 2308 shown below. The RA Identity Witness controls indicates all those 2309 client requests that it performed Identity checks on. 2311 Client RA CA 2312 | | | 2313 |----------------->| | 2314 | [PKIData | | 2315 | control: SKGReq, | | 2316 | TransactionId, | | 2317 | SenderNonce, | | 2318 | Identification] | | 2319 | |--------------------------------------->| 2320 | | | 2326 | |<---------------------------------------| 2327 | | } >> 2334 | }> 2338 Appendix B. Examples 2340 To be supplied later. 2342 B.1. Client Requests 2344 B.1.1. Shroud with Certificate 2346 B.1.2. Shroud with Public Key 2348 B.1.3. Shroud with Shared Secret 2350 B.2. CA-Generate Key Response 2352 B.3. RA-Generate Key Response 2353 I-D CMC Extensions: Server-Side Key GenerationAugust 12, 2014 2355 Authors' Addresses 2357 Jim Schaad 2358 Soaring Hawk Consulting 2360 Email: jimsch@exmsft.com 2362 Sean Turner 2363 IECA, Inc. 2364 3057 Nutley Street, Suite 106 2365 Fairfax, VA 22031 2366 USA 2368 Email: turners@ieca.com 2370 Paul Timmel 2371 National Information Assurance Research Laboratory 2372 National Security Agency 2374 Email: pstimme@tycho.ncsc.mil