idnits 2.17.1 draft-ietf-pkix-cmc-serverkeygeneration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2, 2012) is 4497 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) == Unused Reference: 'RFC4086' is defined on line 954, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX WORKING GROUP J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended Status: Proposed Standard S. Turner 5 Expires: July 5, 2012 IECA 6 P. Timmel 7 National Security Agency 8 January 2, 2012 10 CMC Extensions: Server Key Generation 11 draft-ietf-pkix-cmc-serverkeygeneration-00.txt 13 Abstract 15 This document defines a set of extensions to the Certificate 16 Management over CMS (CMC) protocol that addresses the desire to 17 support server-side generation of keys. This service is provided by 18 the definition of additional control statements within the CMC 19 architecture. Additional CMC errors are also defined. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 5, 2012. 38 Copyright and License Notice 40 Copyright (c) 2012 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 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1.1 Shared Secret for Authentication and Key Protection . . 4 58 1.1.2 Shared Secret for Authentication and Uncertified Key 59 for Protection . . . . . . . . . . . . . . . . . . . . 5 60 1.1.3. Certificate for Authentication and Uncertified or 61 Certified Key for Protection . . . . . . . . . . . . . 8 62 1.2. Location of Key Generator . . . . . . . . . . . . . . . . . 9 63 1.2.1. CA-generated keys . . . . . . . . . . . . . . . . . . . 9 64 1.2.2. RA-generated keys . . . . . . . . . . . . . . . . . . . 10 65 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 11 67 2. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 11 68 2.1. Shroud With a Public Key . . . . . . . . . . . . . . . . . 12 69 2.2. Shroud With a Shared-Secret Key . . . . . . . . . . . . . . 14 70 3. Enveloping Keys . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 15 72 4.1. Server-Side Key Generation Request Attribute . . . . . . . 16 73 4.2. Server-side Key Generation Response . . . . . . . . . . . . 17 74 5. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 19 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 19 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 8.1 Normative References . . . . . . . . . . . . . . . . . . . 21 79 8.2 Informative References . . . . . . . . . . . . . . . . . . 21 80 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 22 81 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 22 82 B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 22 83 B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 22 84 B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 22 85 B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 22 87 B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 22 88 B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 91 1 Introduction 93 This document defines a set of extensions to and errors for 94 Certificate Management over Cryptographic Message Syntax (CMC) 95 [RFC5272] that allows for server-side generation of key material. 96 There are strong reasons for providing this service: 98 o Clients may have poor, unknown, or non-existent key generation 99 capabilities. The creation of private keys relies on the use of 100 good key generation algorithms and a robust random number 101 generator. Server key generation can use specialized hardware 102 that may not always be available on clients. 104 o Central storage of keys may be desired in some environments to 105 permit key recovery. This document only addresses a request to 106 archive server-generated keys; archival of locally generated keys 107 and the control to retrieve archived keys is out-of-scope. 109 o Server key generation may be useful for provisioning keys to 110 disconnected devices. 112 These extensions to the CMC protocol are designed to provide server 113 key generation without adding any additional round trips to the 114 enrollment process; however, additional round trips may be required 115 based on the mechanism chosen to protect the returned key. 117 Sections 2 and 3 describe the concepts and structures used in 118 transporting private keys between the server and client applications. 119 Section 4 describes the structure and processes for server-side key 120 generation. Section 5 describes additional CMC error codes. 121 Appendix A provides the ASN.1 module for the CMC controls and errors. 122 Appendix B provides example encodings. 124 1.1 Scenarios 126 This section describes the three supported scenarios: where a shared 127 secret is used to provide authentication and is used to encrypt the 128 server-generated private key, where a shared secret is used for 129 authentication and a bare, uncertified key is used for key 130 protection, and where a certified key is used for authentication and 131 a bare, uncertified key or certified key is used for protection. The 132 scenarios described in the following subsections assume that the key 133 is generated at the Certificate Authority (CA), but key generation at 134 Registration Authority (RA) is also supported (see Section 1.2). 135 Also, the scenarios assume that the transaction identifier and nonce 136 controls are used for replay protection but they are optional in 137 [RFC5272]. 139 1.1.1 Shared Secret for Authentication and Key Protection 141 When the client uses a shared secret to authenticate to the server 142 and requests that the server protect the response with the same 143 shared secret, Proof-of-Possession (POP) is not necessary. POP is 144 unnecessary in this case because the client does not need to prove to 145 the server that it has possession of a private key because no client 146 private key is used in the request or the response. The shared 147 secret allows the server to authenticate the client and allows the 148 server to encrypt the server-side generated key for the client. The 149 shared secret is distributed via an out-of-band mechanism that is 150 out-of-scope of this document. 152 When the client generates their request, they include the following 153 control attributes in a PKIData content type [RFC5272]: 154 ServerKeyGenRequest (see Section 4.1), TransactionID [RFC5272], 155 SenderNonce [RFC5272], and Identification [RFC5272]. The 156 Identification control is only needed if the ServerKeyGenRequest's 157 certificateRequest does not include a subject. The PKIData is 158 encapsulated in an AuthenticatedData content type and the password 159 RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note that no 160 reqSequence is included in the PKIData for the server-side key 161 generation request. The following depicts this: 163 +----------------------------------------------------------------+ 164 |AuthenticatedData: ReceipientInfo: pwri | 165 |+--------------------------------------------------------------|| 166 ||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)|| 167 || control: TransationID || 168 || control: SenderNonce || 169 || control: Identification (optional) || 170 |+--------------------------------------------------------------+| 171 +----------------------------------------------------------------+ 173 After the server authenticates the client, the server generates a 174 response that includes the server-generated key and any associated 175 parameters in an AsymmetricKeyPackage content type [RFC6030]. The 176 AsymmetricKeyPackage is then encapsulated within a SignedData and 177 that is further encapsulated within an EnvelopedData using the 178 password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData is 179 then placed in a PKIResponse cmsSeq [RFC5272] and the following 180 controls are included: TransactionID, SenderNonce, RecipientNonce 181 [RFC5272], CMCStausInfoV2 [RFC5272], and ServerKeyGenResponse (see 182 Section 4.2). The PKIResponse is then encapsulated in a SignedData 183 and the certificate associated with the server-generated key is 184 placed in SignedData's certificate field [RFC5652]. The following 185 depicts this: 187 +---------------------------------------------------------+ 188 |SignedData: Signed by the CA | 189 | Certificate signed by the CA | 190 |+-------------------------------------------------------+| 191 ||PKIResponse: control: TransactionID || 192 || control: SenderNonce || 193 || control: RecipientNonce || 194 || control: ServerKeyGenResponse || 195 || control: CMCStatusInfoV2 (status: success)|| 196 || || 197 || cmsSeq: || 198 || +----------------------------------------+|| 199 || |EnvelopedData: RecipientInfo: pwri ||| 200 || |+----------------------+ ||| 201 || ||SignedData | ||| 202 || ||+--------------------+| ||| 203 || |||AsymmetricKeyPackage|| ||| 204 || ||+--------------------+| ||| 205 || |+----------------------+ ||| 206 || +----------------------------------------+|| 207 |+-------------------------------------------------------+| 208 +---------------------------------------------------------+ 210 The client can validate that the response came from the CA by 211 validating the digital signature on the SignedData to a Trust Anchor 212 (TA). After the EnvelopedData is decrypted with the shared secret, 213 the client can also verify that the private key is associated with 214 the public key in the returned certificate and the client can also 215 verify that the certificate validates back to a TA. 217 1.1.2 Shared Secret for Authentication and Uncertified Key for 218 Protection 220 When the client uses a shared secret to authenticate to the server 221 and requests that the server protect the response with an uncertified 222 public key, POP is necessary because the client would like the 223 response encrypted with a public key and the server must determine 224 that the client actually has the private key associated with the 225 public key. If the client requests that the response be encrypted 226 with a key that also supports digital signatures, then the client can 227 provide the POP in the same transaction as the server-side key 228 generation request. If the client requests that the response be 229 encrypted with a key that does not support digital signatures, then 230 additional round trips are necessary to perform POP exchanges with 231 the encrypted/decrypted POP attributes [RFC5272]. 233 When the client's key supports both digital signatures and 234 encryption, the client includes the following control attributes in a 235 PKIData content type [RFC5272]: ServerKeyGenRequest control (see 236 Section 4.1), TransactionID [RFC5272], SenderNonce [RFC5272], 237 Identification [RFC5272], and POPLinkRandom [RFC5272]. The 238 Identification control is only needed if the ServerKeyGenRequest's 239 certificateRequest does not include a subject. The POPLinkRandom and 240 the ServerKeyGenRequest'd witness values, which includes 241 POPLinkWitnessV2, are used to prove to the server that the client has 242 possession of the private key. The PKIData is encapsulated in an 243 AuthenticatedData content type and the password RecipientInfo (i.e., 244 pwri CHOICE) is used [RFC5652]. Note that no reqSequence is included 245 for the server-side key generation request. The following depicts 246 this: 248 +-------------------------------------------------------------+ 249 |AuthenticatedData: ReceipientInfo: pwri | 250 |+-----------------------------------------------------------+| 251 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)|| 252 || control: TransationID || 253 || control: SenderNonce || 254 || control: Identification (optional) || 255 || control: POPLinkRandom || 256 |+-----------------------------------------------------------+| 257 +-------------------------------------------------------------+ 259 After the server has authenticated the client and verified the POP, 260 the server returns the server-generated key and any associated 261 parameters in an AsymmetricKeyPackage content type [RFC6030]. The 262 AsymmetricKeyPackage is then encapsulated within a SignedData and 263 that is encapsulated within an EnvelopedData using the key agreement 264 or key transports RecipientInfo (i.e., kari or ketri CHOICE). The 265 EnvelopedData is then placed in a PKIResponse cmsSeq [RFC5272] and 266 the following controls are included: TransactionID, SenderNonce, 267 RecipientNonce, CMCStatusInfoV2, [RFC5272], and ServerKeyGenResponse 268 (see Section 4.2). The PKIResponse is then encapsulated in a 269 SignedData and the certificate associated with the server-generated 270 key is placed in SignedData's certificate field [RFC5652]. The 271 following depicts this: 273 +-----------------------------------------------------------+ 274 |SignedData: Signed by the CA | 275 | Certificate signed by the CA | 276 |+---------------------------------------------------------+| 277 ||PKIResponse: control: TransactionID || 278 || control: SenderNonce || 279 || control: RecipientNonce || 280 || control: ServerKeyGenResponse || 281 || control: CMCStatusInfoV2 (status: success) || 282 || || 283 || cmsSeq: || 284 || +------------------------------------------+|| 285 || |EncryptedData: RecipientInfo: kari or keti||| 286 || |+----------------------+ ||| 287 || ||SignedData | ||| 288 || ||+--------------------+| ||| 289 || |||AsymmetricKeyPackage|| ||| 290 || ||+--------------------+| ||| 291 || |+----------------------+ ||| 292 || +------------------------------------------+|| 293 |+---------------------------------------------------------+| 294 +-----------------------------------------------------------+ 296 When client's key only supports encryption, the client includes the 297 following in control attributes in a PKIData [RFC5272]: Server Key 298 Generation Request control (see Section 4.1), TransactionID 299 [RFC5272], SenderNonce [RFC5272], and Identification [RFC5272]. The 300 Identification control is only needed if the certificateRequest does 301 not include a subject. The PKIData is encapsulated in an 302 AuthenticatedData content type and the password RecipientInfo (i.e., 303 pwri CHOICE) is used [RFC5652]. Note that no reqSequence is included 304 for the server-side key generation request. The following depicts 305 this: 307 +-------------------------------------------------------------+ 308 |AuthenticatedData: ReceipientInfo: pwri | 309 |+-----------------------------------------------------------+| 310 ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)|| 311 || control: TransationID || 312 || control: SenderNonce || 313 || control: Identification (optional) || 314 |+-----------------------------------------------------------+| 315 +-------------------------------------------------------------+ 317 After the server has authenticated the client, the server must 318 perform POP with the client. This requires additional round trips 319 for the client to prove that it can decrypt date encrypted for it by 320 the server. The server returns a PKIData with the following 321 controls: TransactionID, SenderNonce, EncryptedPOP, and 322 CMCStatusInfoV2. The CMCStatusInfoV2 indicates that the request 323 failed and why: POP required. The EncryptedPOP control attribute 324 contains some encrypted data for the client. The PKIData is the 325 encapsulated in a SignedData. The following depicts this: 327 +----------------------------------------------------------------+ 328 |SignedData: Signed by the CA | 329 |+--------------------------------------------------------------+| 330 ||PKIData: control: TransationID || 331 || control: SenderNonce || 332 || control: RecipientNonce || 333 || control: EncryptedPOP || 334 || control: CMCStatusInfoV2 (status: failed || 335 || OtherStatusInfo: CMCFailInfo: POPRequired)|| 336 |+--------------------------------------------------------------+| 337 +----------------------------------------------------------------+ 339 After the client has validated the signature on the SignedData, it 340 decrypts the EncryptedPOP with its private key and then generates a 341 PKIData with the following controls: TransactionID, SenderNonce, 342 RecipientNonce, and DecryptedPOP. The decrypted data is placed in 343 the DecryptedPOP control. The PKIData is then encapsulated in an 344 AuthenticatedData and then the client returns it to the server. The 345 following depicts this: 347 +---------------------------------------+ 348 |AuthenticatedData: ReceipientInfo: pwri| 349 |+--------------------------------+ | 350 ||PKIData: control: TransationID | | 351 || control: SenderNone | | 352 || control: RecipientNonce| | 353 || control: DecryptedPOP | | 354 |+--------------------------------+ | 355 +---------------------------------------+ 357 After the client has authenticated the client and verified that the 358 decrypted POP is correct, the server returns a response. It is the 359 same response as the one returned when the client's key supports 360 digital signatures. 362 1.1.3. Certificate for Authentication and Uncertified or Certified Key 363 for Protection 365 When the client uses a certificate to authenticate to the server and 366 requests that the server protect the response with a certificate or 367 an uncertified public key or certificate, POP is still necessary 368 because the client would like the response encrypted with a public 369 key and the server must determine that the client actually has the 370 private key associated with public key. If the client requests that 371 the response be encrypted with a key that also supports digital 372 signatures, then the client can provide the POP in the same 373 transaction as the server-side key generation request. If the client 374 requests that the response be encrypted with a key that does not 375 support digital signatures, then additional round trips are necessary 376 to perform encrypted/decrypted POP exchanges [RFC5272]. These 377 additional round trips are necessary for the server to determine that 378 the client posses the private key. 380 The difference between this scenario and the one in Section 1.1.2 is 381 that instead of an AuthenticatedData encapsulating the PKIData a 382 SignedData is used. 384 1.2. Location of Key Generator 386 As noted earlier, these extensions are designed to not add additional 387 round trips to the enrollment process. This section depicts two 388 scenarios: one when the Certification Authority (CA) generates keys 389 and another when the Registration Authority (RA) generates the keys. 391 In the figures below, CR is Certificate Request/Response and KGReq is 392 Key Generation Request, and KGRes is Key Generation Response. {} 393 signifies encrypted. 395 1.2.1. CA-generated keys 397 For CA-generated keys, the message flows is as follows: 399 Client RA CA Key Generator 400 | | | | 401 |------------->|------------->| | 402 | PKIData | | | 403 | includes CR | | | 404 | and KGReq | |------------->| 405 | | | KGReq | 406 | | |(out-of-scope)| 407 | | |<-------------| 408 | | | KGRes | 409 | | |(out-of-scope)| 410 |<-------------|<-------------| 411 | | PKIResponse | 412 | | includes CR | 413 | | and {KGRes} | 415 In this scenario, the CA authenticates the client's request and 416 verifies the client's identity. The CA generates the keys, issues 417 the client's certificate, encrypts the key for the client, and signs 418 the response. As specified in [RFC5272], the RA is optional. If an 419 RA is involved, then the RA does not have access to encrypted portion 420 of the response because it does not have access to either the shared 421 secret or the client's private key. 423 1.2.2. RA-generated keys 425 For RA-generated keys, the message flow is as follows: 427 Client RA Key Generator CA 428 | | | | 429 |------------->| | | 430 | PKIData | | | 431 | includes CR | | | 432 | and KGReq | | | 433 | |------------->| | 434 | | KGReq | | 435 | |(out-of-scope)| | 436 | |<-------------| | 437 | | KGRes | | 438 | |(out-of-scope)| | 439 | | | 440 | | | 441 | |---------------------------->| 442 | | PKIData includes CR | 443 | | and {KGRes} (optional) | 444 | |<----------------------------| 445 | | PKIResponse includes CR | 446 | | and {KGRes} (optional) | 447 |<-------------| | 448 | PKIResponse | | 449 | includes CR | | 450 | and {KGRes} | | 452 NOTE: The encrypted KGRes could be provided to the CA for it to 453 return to the client or the RA can retain the encrypted KGRes and 454 return it as part of the PKIResponse it generates. In this scenario, 455 the RA authenticates the client's request and verifies the client's 456 identity. The RA also verifies the POP verifies the encryption 457 certificate (if used), generates the keys, and returns the encrypted 458 private key. The RA also sends the certificate request to the CA and 459 assuming it performed POP includes an indication that it did so using 460 the LRAPOPWitness control. If the RA performed POP or based on local 461 policy the RA encapsulates the client's request in a SignedData and 462 places it in a PKIData content type for the CA. The CA issues the 463 client's certificate and signs the response. In this scenario the RA 464 does have access to the cleartext private key but the CA does not. 466 1.3 Terminology 468 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 469 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 470 "OPTIONAL" in this document are to be interpreted as described in RFC 471 2119 [RFC2119]. 473 The terminology in [RFC5272] Section 2.1 applies to this profile. 475 1.4. Definitions 477 This section defines some of the terms that are used in this 478 document: 480 o Identification is used as a generic term for a name, generally 481 assigned by a server, used to match a request against a known 482 individual. Identification can be either authenticated (a 483 subject name in a certificate) or unauthenticated (a text 484 string). 486 o Pass phrase is a shared secret string between two or more 487 entities that allows for a MAC or encryption key to be computed. 488 Pass phrases MUST be treated as confidential by the holders of 489 the secret. 491 o Shrouding is used as a generic term to cover methods of masking 492 the content of an object from unauthorized viewers. The most 493 common method of shrouding used is encryption of the data. 495 2. Shrouding Algorithms 497 For the server-side key generation control attribute described in 498 this document to function, the client must be able to tell the server 499 in advance what encryption algorithm and what key value is to be used 500 for encrypting the private keys being returned. In both of these 501 cases, the encrypted data returned is returned as an EnvelopedData 502 object as defined by [RFC5652] and placed in the cmsSequence field of 503 a PKIResponse [RFC5272]. Client also must be able to tell the server 504 in advance what digital signature and hash algorithms it supports to 505 ensure the certificate request response and certificate can be 506 verified. 508 Each request control for which the response includes encrypted data 509 contains two fields to define type of encryption used: 510 algCapabilities and shroudMethod. 512 The algCapabilities field contains the advertised capabilities of the 513 client-side entity. This field uses the S/MIME Capabilities type 514 defined in section 2.5.2 of [RFC5751]. The capabilities to be listed 515 are digital signature algorithms, message digest algorithms, content 516 encryption algorithms, key-wrap algorithms and key derivation 517 algorithms. The shroudMethod field defines the method by which the 518 server will do the key management of the content encrypt key (CEK) 519 value in EnvelopedData. The shroudMethod field uses the type 520 ShroudMethod. This type is defined as: 522 ShroudMethod ::= AlgorithmIdentifier 523 { SHROUD-ALGORITHM, { ShroudAlgorithmSet } } 525 When a new shroud method is defined it MUST include (a) the source of 526 the key material, (b) the public or salting information, and (c) the 527 method of deriving a key management key using the requested data, 528 source key material and salt. This document defines two shroud 529 methods: id-cmc-shroudWithPublicKey and id-cmc- 530 shroudWithSharedSecret. Clients and servers MUST support id-cmc- 531 shroudWithPublicKey. Client and servers SHOULD support id-cmc- 532 shroudWithSharedSecret. 534 Other shrouding methods could be defined in the future that would not 535 involve the use of EnvelopedData. For example, one could conceive of 536 a shrouding method that required the use of Transport Layer Security 537 (TLS) [RFC5246] to provide the necessary security between the key 538 generation server and the end-entity. This document does not define 539 any such mechanism. 541 2.1. Shroud With a Public Key 543 Clients can provide a public key to the server either wrapped in a 544 certificate or as a bare public key. For this shrouding algorithm, 545 the public key provides the all of the information that is needed to 546 allow for the returned key to be encrypted. The following object 547 identifier identifies the shroudWithPublicKey shroud method: 549 id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= {id-cmc XX } 551 shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey: 553 srda-shroudWithPublicKey SHROUD-ALGORITHM ::= { 554 IDENTIFIED BY id-cmc-shroudWithPublicKey, 555 PARAMS TYPE ShroudWithPublicKey ARE required, 556 SMIME-CAPS {IDENTIFIED BY id-cmc-shroudWithPublicKey} 557 } 559 ShroudWithPublicKey ::= CHOICE { 560 certificate Certificate, 561 bareKey SEQUENCE { 562 publicKey SubjectPublicKeyInfo, 563 ski SubjectKeyIdentifier, 564 witness SEQUENCE { 565 signature Signature, 566 sigAlg SignatureAlgorithmIdentifier, 567 value CHOICE { 568 link POPLinkWitnessV2, 569 certID ESSCertIDV2 570 } 571 } OPTIONAL 572 } 573 } 575 The fields of type ShroudWithPublicKey have the following meanings: 577 o certificate provides a public key certificate containing the 578 public key to be used for encrypting the server-generated private 579 key from the server to the client. Servers SHOULD check that the 580 subject and subject alternative names match in some way with the 581 entity that the private key is destined for. 583 o bareKey allows for an arbitrary public key to be used to return 584 the encrypted private key. The server SHOULD perform a POP on 585 the provided key prior to using it. 587 - publicKey contains the public key that is to be used for 588 encrypting the private key returned from the server to the 589 client. 591 - ski contains the SubjectKeyIdentifier that will be used in CMS 592 EnvelopedData to identify the public key when encrypting the 593 private key from the server to the client. 595 - witness provides a method of doing POP using a signature 596 algorithm. This field is only present if the key is capable of 597 doing signature operation. 599 o sigAlg contains the signature algorithm used to compute the 600 signature value. 602 o signature contains the signature value. 604 o value contains the value that was signed. The value MUST be DER 605 encoded prior to performing the signature operation. 607 o link is used when the outer wrapper is an AuthenticatedData 608 structure. If this is present then the POPLinkRandom MUST be 609 present in the list of PKIData controls. The link value is 610 computed over the public key value using the shared secret as the 611 MAC key. 613 o certID is used when the outer wrapper is a SignedData structure. 614 It will identify the certificate that is used to sign the overall 615 message. 617 When this method is used with the certificate option, the server MUST 618 validate the certificate back to a trust anchor. Further, the server 619 MUST check that the client provided certificate belongs to the same 620 client that authenticated the certificate request (e.g. the 621 certificate subjects match, or the client provided certificate 622 belongs to the same entity as the authentication shared secret). If 623 either of these checks fails, then the server MUST return a 624 CMCFailInfo with the value of badCertificate, which is defined in 625 Section 5. 627 When this method is used with the publicKey option and the request is 628 authenticated using a shared secret, the server MUST verify the 629 POPLinkRandom/POPLinkWitnessV2, as specified in [RFC5272]. If this 630 check fails, the server MUST return a CMCFailInfo with the value of 631 popFailed [RFC5272]. 633 If the witness value is missing, the server MAY use the Encrypted and 634 Decrypted POP controls [RFC5272] to perform the required POP 635 operation. Clients MUST support this if encryption-only keys are 636 supported. 638 2.2. Shroud With a Shared-Secret Key 640 Clients can indicate that servers use a shared secret value. For 641 this option the key material is identified by the identifier, the key 642 derivation algorithms supported by the client are included in the 643 algCapabilities field. No salting material is provided by the 644 client. The derived key is then used as a key encryption key in the 645 EnvelopedData recipient info structure. The following object 646 identifier identifies the shroudWithSharedSecret control attribute: 648 id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX} 650 shroudWithSharedSecret attribute values have the ASN.1 type 651 ShroudWithSharedSecret: 653 shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= { 654 IDENTIFIED BY id-cmc-shroudWithSharedSecret 655 PARAMS TYPE ShroudWithSharedSecret ARE required 656 SMIME-CAPS {IDENTIFIED BY id-cmc-shroudWithSharedSecret} 658 ShroudWithSharedSecret ::= UTF8String 660 The common identification string for the client and the server is 661 placed in the ShroudWithSharedSecret field, which a UTFString 662 [RFC5280]. In addition the client needs to place both a key 663 derivation function and a key wrap function in the set of 664 capabilities advertised by the client in the algCapabilities field. 665 The identification string is used to identify the pass phrase or 666 shared key. 668 When this method is used, the server MUST check that the chosen 669 shared secret belongs to the authenticated identity of the entity 670 that generated the certificate request. If this check fails, then 671 the server MUST return a CMCFailInfo with the value of 672 badSharedSecret, which is defined in Section 5. In general, while it 673 is expected that the same identity token and shared secret used to do 674 the identity authentication are used to derive the key encryption key 675 this is not required. 677 3. Enveloping Keys 679 The server returns the private key and optionally the corresponding 680 public key to the client with the AsymmetricKeyPackage content type 681 [RFC5958]. The AsymmetricKeyPackage is encapsulated in a 682 Cryptographic Message Syntax (CMS) EnvelopedData content type. There 683 MUST be only one OneAsymmetricKey present in the AsymmetricKeyPackage 684 sequence. When more than one private key is to be returned, multiple 685 AsymmetricKeyPackages are included. The public key SHOULD be 686 included. 688 4. Server-Side Key Generation 690 This section provides the control attributes necessary for doing 691 server-side generation of keys for clients. The client places the 692 request for the key generation in a request message and sends it to 693 the server. The server will generate the key pair, create a 694 certificate for the public key and return the data in a response 695 message, or the server will return a failure. 697 4.1. Server-Side Key Generation Request Attribute 699 The client initiates a request for server-side key generation by 700 including the server-side key generation request attribute in the 701 control attributes section of a PKIData object. The request 702 attribute includes information about how to return the generated key 703 as well as any client suggested items for the certificate. The 704 control attribute for doing server-side key generation is identified 705 by the following OID: 707 id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX } 709 The Server-Side Key Generation Request control attribute has the 710 following ASN.1 definition: 712 cmc-serverKeyGenRequest CMC-CONTROL ::= { 713 ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest } 715 ServerKeyGenRequest ::= SEQUENCE { 716 certificateRequest CertTemplate, 717 shroudMethod ShroudMethod, 718 algCapabilities SMimeCapabilties OPTIONAL, 719 archiveKey BOOLEAN DEFAULT TRUE 720 } 722 The fields in ServerKeyGenRequest have the following meaning: 724 o certificateRequest contains the data fields that the client 725 suggests for the certificate being requested for the server 726 generated key pair. 728 o shroudMethod contains the identifier of the algorithm to be used 729 in deriving the key used to encrypt the private key. 731 o algCapabilities contains the set of algorithm capabilities being 732 advertised by the client. The server uses algorithms from this 733 set in the ServerKeyGenResponse object to encrypt the private key 734 of the server-generated key pair. Support is OPTIONAL because 735 this information might be carried in a signed attribute, included 736 within a certificate or be part of the local configuration. 738 o archiveKey is set to TRUE if the client wishes the key to be 739 archived as well as generated on the server. Further processing 740 by the server when this is set to TRUE is out-of-scope. 742 The client can request that the generated key be a specific algorithm 743 by placing data in the publicKey field of the certificateRequest 744 field. If the publicKey field is populated, then the public key MUST 745 be a zero length bit string. If the client requests a specific 746 algorithm, the server MUST generate a key of that algorithm (with the 747 parameters if defined) or it MUST fail the request. If the request 748 fails for this reason, the server SHOULD return a CMCFailInfo with a 749 value of badAlg [RFC5272]. 751 A server is not required to use all of the values suggested by the 752 client in the certificate template. Servers MUST be able to process 753 all extensions defined in [RFC5280]. Servers are not required to be 754 able to process other V3 X.509 extension transmitted using this 755 protocol, nor are they required to be able to process other, private 756 extensions. Servers are permitted to modify client-requested 757 extensions. Servers MUST NOT alter an extension so as to invalidate 758 the original intent of a client-requested extension. (For example 759 change key usage from key exchange to digital signature.) If a 760 certificate request is denied due to the inability to handle a 761 requested extension, the server MUST respond with a CMCFailInfo with 762 a value of unsupportedExt [RFC5272]. 764 A server that does not recognize the algorithm identified in 765 shroudMethod MUST reject the request. The server SHOULD return a 766 CMCFailInfo with a value of badAlg [RFC5272]. 768 A server that does not support at least one of the algCapabilities 769 MUST reject the request. The server SHOULD return a CMCFailInfo with 770 a value of badAlg [RFC5272]. 772 If archiveKey is true and the server that does not support archiving 773 of private keys MUST reject the request. The server SHOULD return a 774 CMCFailInfo with a value of archiveNotSupported, defined in this 775 document. 777 4.2. Server-side Key Generation Response 779 The server creates a server-side key generation response attribute 780 for every key generation request made and successfully completed. 781 The response message has a pointer to both the original request 782 attribute and to the body part in the current message that holds the 783 encrypted private keys. The response message also can contain a 784 pointer to the certificate issued. The key generation response 785 control attribute is identified by the OID: 787 id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= {id-cmc XX} 789 The Server-Side Key Generation Response control attribute has the 790 following ASN.1 definition: 792 cmc-serverKeyGenResponse CMC-CONTROL ::= { 794 ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse } 796 ServerKeyGenResponse ::= SEQUENCE { 797 cmsBodyPartId BodyPartID, 798 requestBodyPartId BodyPartID, 799 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 800 } 802 The fields in ServerKeyGenResponse have the following meaning: o 803 cmsBodyPartId identifies a TaggedContentInfo contained within the 804 enclosing PKIData. The ContentInfo object is of type EnvelopedData 805 and has an encapsulated content of id-ct-KP-aKeyPackage. As per 806 Section 3 of this document, the body MUST contain the version, the 807 private key algorithm identifier, and the private key and the body 808 SHOULD contain the public key and MAY contain additional attributes. 810 o requestBodyPartId contains the body part identifier for the 811 server-side key generation request control attribute. This 812 allows for clients to associate the resulting key and certificate 813 with the original request. 815 o issuerAndSerialNumber if present contains the identity of the 816 certificate issued to satisfy the request. The certificate is 817 placed in the certificate bag of the immediately encapsulating 818 signedData object. 820 Clients MUST NOT assume the certificates are in any order. Servers 821 SHOULD include all intermediate certificates needed to form complete 822 chains to one or more self-signed certificates, not just the newly 823 issued certificate(s) in the certificate bag. The server MAY 824 additionally return CRLs in the CRL bag. Servers MAY include self- 825 signed certificates. Clients MUST NOT implicitly trust included 826 self-signed certificate(s) merely due to its presence in the 827 certificate bag. 829 5. Additional Error Codes 831 This section defines ExtendedFailInfo errors from this document: 833 cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= { 834 TYPE ErrorList IDENTIFIED BY id-tbd 835 } 837 ErrorList ::= INTEGER { 838 archiveNotSupported (1), 839 badCertificate (2), 840 badSharedSecret (3) 841 } 843 If you think that you are going to want to return other information 844 than just an error code then we can expand to a sequence of an 845 integer and an any defined by integer or use a different extended 846 error code just for those items. 848 o archiveNotSupported indicates that the server does not support 849 archiving of private keys. The syntax for the ExtendedFailInfo 850 is as follows: 852 cmc-err-archiveNotSupport EXTENDED-FAILURE-INFO ::={ 853 IDENTIFIED BY id-tbd } 855 o badCertificate indicates that the certificate to be used to 856 encrypt the response did not validate back to a RA/CA trust 857 anchor or the certificate does not belong to the client. The 858 syntax for the ExtendedFailInfo is as follows: 860 cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={ 861 IDENTIFIED BY id-tbd } 863 o badSharedSecret indicates that the shared secret provided by the 864 client does not match that stored by the server. 866 cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={ 867 IDENTIFIED BY id-tbd } 869 6. Security Considerations 871 Central generation of digital signature keys contains risks and is 872 not always appropriate. Organization-specific Certificate Policies 873 should define whether or not server-side generation of digital 874 signature keys is permitted. 876 Private keys must be appropriately protected from disclosure or 877 modification on the server, in transit, and on the client. 878 Cryptographic algorithms and keys used to protect the private key 879 should be at least as strong as the private key's intended strength. 881 This specification requires implementations to generate key pairs and 882 other random values. The use of inadequate pseudo-random number 883 generators (PRNGs) can result in little or no security. The 884 generation of quality random numbers is difficult. NIST Special 885 Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer 886 guidance. 888 POP is extremely important. However, POP here is different than in 889 client-generated key certification requests in that the POP is 890 necessary to prove to the server that the client has possession of 891 the private key necessary to decrypt the server-generated private key 892 rather than possess the private key associated with the public key in 893 the request. 895 Further when the shared secret is used to provide client 896 authentication and protect the server-generated private key, the 897 shared secret must be kept secret for the lifetime of the key. This 898 is because disclosure could allow attackers to determine the server- 899 generated private key. This is different than certification requests 900 with client-generated keys because the shared secret is no longer 901 needed after the authentication. Returning data to the wrong client 902 is bad. Disclosure of the private key to the wrong client can result 903 in masquerades. 905 7. IANA Considerations 907 This document makes use of object identifiers to register CMC control 908 attributes and CMC error codes. Additionally, an object identifier 909 is used to identify the ASN.1 module found in Appendix A. All are 910 defined in an arc delegated by IANA to the PKIX Working Group. The 911 current contents of the arc are located here: 913 http://www.imc.org/ietf-pkix/pkix-oid.asn 915 They were obtained by sending a request to ietf-pkix-oid-reg@imc.org. 916 When the PKIX WG closes, this arc and registration procedures will 917 be transferred to IANA. No further action by IANA is necessary for 918 this document or any anticipated updates. 920 8. References 922 8.1 Normative References 924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 925 Requirement Levels", BCP 14, RFC 2119, March 1997. 927 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 928 (CMC)", RFC 5272, June 2008. 930 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 931 Housley, R., and W. Polk, "Internet X.509 Public Key 932 Infrastructure Certificate and Certificate Revocation List 933 (CRL) Profile", RFC 5280, May 2008. 935 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 936 RFC 5652, September 2009. 938 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 939 Mail Extensions (S/MIME) Version 3.2 Message 940 Specification", RFC 5751, January 2010. 942 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 943 2010. 945 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 946 Key Container (PSKC)", RFC 6030, October 2010. 948 8.2 Informative References 950 [FIPS-186] National Institute of Standards and Technology (NIST), 951 FIPS 186-3 DRAFT: Digital Signature Standard (DSS), 952 November 2008. 954 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 955 "Randomness Requirements for Security", BCP 106, RFC 4086, 956 June 2005. 958 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 959 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 961 [SP-800-90] National Institute of Standards and Technology (NIST), 962 Special Publication 800-90: Recommendation for Random 963 Number Generation Using Deterministic Random Number Bit 964 Generators (Revised), March 2007. 966 Appendix A. ASN.1 Module 968 To be supplied later. 970 Appendix B. Examples 972 To be supplied later. 974 B.1. Client Requests 976 B.1.1. Shroud with Certificate 978 B.1.2. Shroud with Public Key 980 B.1.3. Shroud with Shared Secret 982 B.2. CA-Generate Key Response 984 B.3. RA-Generate Key Response 986 Authors' Addresses 988 Jim Schaad 989 Soaring Hawk Consulting 991 Email: jimsch@exmsft.com 993 Sean Turner 994 IECA, Inc. 995 3057 Nutley Street, Suite 106 996 Fairfax, VA 22031 997 USA 999 Email: turners@ieca.com 1001 Paul Timmel 1002 National Information Assurance Research Laboratory 1003 National Security Agency 1005 Email: pstimme@tycho.ncsc.mil