idnits 2.17.00 (12 Aug 2021) /tmp/idnits5667/draft-ietf-pkix-cmc-archive-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2119], [CMC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 17: '...oups. Note that other groups MAY also...' RFC 2119 keyword, line 21: '... months and MAY be updated, replace...' RFC 2119 keyword, line 119: '...lization vector.)The parameters SHOULD...' RFC 2119 keyword, line 121: '... MUST be present otherwise. The in...' RFC 2119 keyword, line 132: '...ents and servers MUST support id-alg-c...' (67 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2001) is 7616 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CMC' on line 367 looks like a reference -- Missing reference section? 'RFC 2119' on line 760 looks like a reference -- Missing reference section? 'CMS' on line 736 looks like a reference -- Missing reference section? 'PKCS8' on line 752 looks like a reference -- Missing reference section? '0' on line 892 looks like a reference -- Missing reference section? 'PKIXCERTPKIXALG' on line 248 looks like a reference -- Missing reference section? 'PKCS1' on line 748 looks like a reference -- Missing reference section? 'PXIXCERT' on line 356 looks like a reference -- Missing reference section? '1' on line 893 looks like a reference -- Missing reference section? 'CRMF' on line 739 looks like a reference -- Missing reference section? 'DH' on line 743 looks like a reference -- Missing reference section? 'HMAC' on line 745 looks like a reference -- Missing reference section? 'PKIXCERT' on line 755 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Jim Schaad 3 Internet Draft Soaring Hawk Consulting 4 July 13, 2001 5 Expires: Jan 2002 7 CMC Extensions: 8 Server Side Key Generation and Key Archival 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), 17 its areas, and its working groups. Note that other groups MAY also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and MAY be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 35 munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 This document defines a set of extensions to [CMC] that address the 41 desire for having two additional services: Server generation of 42 keys, and server-side archival and subsequent recovery of key 43 material by the server. These services are provided by the 44 definition of additional control statements within the CMC 45 architecture. 47 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and 48 "MAY" in this document are to be interpreted as described in [RFC 49 2119]. 51 1.Requirements1. Overview 53 This document defines a set of extensions to [CMC] that allow for 54 server side generation of key material and server side key archival 55 and subsequent retrieval of the archived key material. There are 56 some strong reasons for providing each of these services. 58 - Clients can have poor key generation, and having multiple clients 59 means that this must be checked for all clients. 61 - End users routinely lose keys from either user error or software 62 errors. 64 The creation of private keys relies on the use of good key 65 generation algorithms. In most cases this depends on the use of a 66 superior random number generator and strong testing for such things 67 a prime numbers. The client side generation of this material can 68 often times be suspect for either for reasons of poor coding in the 69 multiple client applications, poor input (seeding material) from 70 users and the requirements that user's not spend time waiting for 71 things to occur. Moving the task of key generation to a server 72 process allows for superior key generation as hardware can be 73 installed in servers for the purpose of key generation. There is a 74 trade off for generation of signature keys on server systems. It 75 can provide for better key generation, but the ability for a server 76 to know the signing key is an issue. (Note that in the case of DSS 77 the parameter generation could be done on a server with the private 78 key still being generated on the client's system. This allows for 79 good parameter generation without sharing the private key with the 80 server.) 82 These extensions to the CMC protocol are designed to provide the 83 services without adding any additional round trips to the 84 enrollment process. Server-side key generation is designed so that 85 a client side signature key and server side key-management key can 86 be processed in a single CMC interaction. 88 Sections 2 and 3 describe the concepts and structures used in 89 transporting private keys between the server and client 90 applications. Section 4 describes the structure and processes for 91 server-side key generation. Section 5 describes the structure and 92 process for doing key archival and retrieval. 93 -Server-side generation of keys 94 -Archival of private key material 95 -Recovery of archived private key material. 97 2.Protocol Overview 99 2. Shrouding Algorithms 101 Both the server-side key generation and the key recovery control 102 attributes described in this document require that the client be 103 able to tell the server in advance what encryption algorithm and 104 what key value is to be used in shrouding the private keys being 105 returned. In both of these cases the encrypted data returned is 106 returned as either an EnvelopedData or EncryptedData object as 107 defined by [CMS] and placed in the cmsSequence field of a 108 ResponseBody.ContentInfo field of à. 110 Each request control for which the response includes encrypted data 111 contains two fields to define type of encryption used: 113 The bulkEncryptionAlgId gives the OID of the bulk encryption 114 algorithm to be used as the content encryption key (CEK) of the 115 EnvelopedData or EncryptedData object returned. The parameters 116 provided for this algorithm match the S/MIME capability parameters 117 rather than the full content encryption algorithm. (This omits 118 those parameters that are specific to a single instance of an 119 encryption such as an initialization vector.)The parameters SHOULD 120 be omitted if they consist of just an initialization vector and 121 MUST be present otherwise. The initialization vector MUST be re- 122 generated by the server for the return encryption. 124 The shoudIdentification field defines the method by which the 125 server will do the key management of the CEK value in an 126 EnvelopedData, or derive a common private key for EncryptedData. 127 The shroudIdentification is defined as an AlgorithmIdentifier as it 128 must identify (a) the sourceruce of the key material, (b) and the 129 public or /salting information, and (c) the method of deriving an 130 encryption key management key using the requested data, source key 131 material and salt. This document defines two shroud algorithms; 132 clients and servers MUST support id-alg-cmc-shroudPublicKey. 133 Clients and servers SHOULD support id-alg-cmc-shroudSharedSecret. 135 2.1 Shroud to a Public Key 137 Clients can provide a public key to the server either as a bare key 138 or wrapped in a certificate. 140 id-cmc-shroudPublicKey OBJECT IDENTIFER ::= {id-cmc XX } 142 ShroudPublicKey ::= CHOICE 144 certificate Certificate, 145 publicKey SubjectPublicKey 146 } 148 Servers and clients MUST support use of Diffie-HellmanRSA keys for 149 CEK key management. Servers and clients SHOULD MAY support use of 150 RSA DH keys for CEK key management. 152 2.2 Shroud to a Shared-Secret Key 154 A shared secret value is identified to the server by the client. 155 The derived key is then used as a KEK key in an EnvelopedData 156 recipient info structure. 158 id-cmc-shroudSharedSecret OBJECT IDENTIFER ::= {id-cmc XX} 160 ShroudSharedSecret ::= SEQUENCE 162 keyIdentifier OCTET STRING, 163 salt OCTET STRING OPTIONAL, 164 count INTEGER DEFAULT 1, 165 hash AlgorithmIdentifier OPTIONAL, 166 } 167 -- keyIdentifier provides the value to be encoded as the 168 KEKRecipientInfo.kekid.keyIdentifier key identifierfield in the 169 returned EncryptedData structureKEKRecipientInfo structure. 171 -- salt provides a salt value to be appended to the shared-secret 172 value prior to hashing the value during key derivation 174 -- count provides the number of times that the hash operation is 175 repeated during key derivation 177 -- hash defines the hash algorithm to be used in deriving the 178 shared-secret key from the shared-secret value. 180 Clients and servers MUST support SHA-1 for the hash algorithm. 181 Clients and servers SHOULD include salt as part of a request. 183 If more bits of key material are required for the encryption key 184 that are created by the hash algorithm, subsequent key material is 185 generated by appending one octet containing the binary value for 186 the iteration number (1, 2, 3,à) to the shared secret followed by 187 the salt value and then performing count hash operations. 189 If shared-secret shrouding is supported, clients and servers MUST 190 support the 3DES key wrap. Clients and servers SHOULD MAY support 191 RC2 key-wrap. 193 3. Private Key Info Attribute 195 The private key info attribute is imported from [PKCS8]. Private 196 key information is tagged by the private key info attribute. This 197 attribute has the ASN.1 structure: 199 id-cmc-privateKeyInfo ::= OBJECT IDENTIFER ::= {id-cmc XX20} 201 PrivateKeyInfo ::= SEQUENCE 203 version INTEGER, 204 privateKeyAlgorithm AlgorithmIdentifier, 205 privateKey OCTET STRING, 206 attributes [0] IMPLICIT Attributes OPTIONAL 207 } 209 Attributes ::= SET OF Attribute 211 -- version MUST be the value 0 213 -- privateKeyAlgorithm contains the identifier for the private key 214 object 216 -- privateKey is an octet string whose contents is the private key 217 and whose format is defined by the value of privateKeyAlgorithm. 219 -- attributes is a set of attributes. These are extended 220 information that is part of the private key information. 222 3.1 Private Key Structures 224 We are defining the structures here to be used for three 225 algorithms. 227 3.1.1 D-H Private Keys 229 When creating a PrivateKeyInfo for a D-H key, the following rules 230 apply: 232 1. The privateKeyAlgorithm MUST be set to id-dh-private-number. 233 The parameter for id-dh-private-number is DomainParameters 234 (imported from [PKIXCERTPKIXALG]). 236 2. The ASN structure for privateKey MUST be 238 DH-PrivateKey ::= INTEGER 240 3.3. The attributes field MUST be omitted. 242 3.1.2 DSA Private Keys 244 When creating a PrivateKeyInfo for a DSA key, the following rules 245 apply: 247 1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters 248 for id-dsa is Dss-Parms (imported from [PKIXCERTPKIXALG]). 250 2. The ASN structure for privateKey MUST be 252 DSA-PrivateKey ::= INTEGER 254 3.3. The attributes field MUST be omitted. 256 3.1.3 RSA Private Keys 258 When creating a PrivateKeyInfo for an RSA key, the following rules 259 apply: 261 1. The privateKeyAlgorithm MUST be set to rsaEncryption. 263 2. The ASN structure for privateKey MUST be RSAPrivateKey 264 (defined in [PKCS1]) 266 3. The aAttributes field MUST be omitted. 268 3.24 ContentInfo Objects for Private Key Material 270 The ContentInfo object that contain private key material MUST be 271 one of EnvelopedData, EncryptedData or Data. Private key material 272 placed in a Data ContentInfo MUST be encrypted through some other 273 mechanism; it is beyond the scope of this document to specify that 274 mechanism. 276 The inner content of the EnvelopedData or EncryptedData is a 277 ResponseBody. The private keys are then encoded as private key 278 info control attributes. 280 4. Server-Side Key Generation 282 This section provides the control attributes necessary for doing 283 server-side generation of keys for clients. The client places the 284 request for the key generation in a request message and sends it to 285 the server. The server will generate the key pair, create a 286 certificate for the public key and return the data in a response 287 message, or the server will return a failure. 289 Clients SHOULD NOT request server-side generation of signing-only 290 key pairs. Servers SHOULD NOT grant requests for generation of 291 key-pairs and creating a signing only certificate. This is 292 designed to reduce responsibility on the server's part for possible 293 use of the signing keys. 295 4.1 Server-Side Key Generation Request Attribute 297 The client initiates a request for server-side key generation by 298 including the Server-Side Key Generation Request Attribute in the 299 control attributes section of a PKIData object. The request 300 attribute includes information about how to return the generated 301 key as well as any client suggested items for the certificate. The 302 control attribute for doing Server-side key generation has the 303 following OID and structure: 305 id-cmcCtrl-ServerKeyGenRequest ::= OBJECT IDENTIFIER ::= {pkixid- 306 cmc XX} 308 ServerKeyGenRequest ::= SEQUENCE 310 certificateRequest CertTemplate, 311 shroudIdentification ShroudIdentification, 312 bulkEncryptionAlgID AlgorithmIdentifier, 313 fArchiveKey BOOLEAN DEFAULT FALSE, 314 selectionCriteria OCTET STRING OPTIONAL 315 } 317 -- certificateRequest contains the data fields that the client 318 suggests for the certificate being requested for the server 319 generated key pair. 321 -- shroudIdentification contains the identifier of the algorithm to 322 be used in deriving the key used to encrypt the private key. 324 -- bulkEncryptionAlgId contains the encryption algorithm used in 325 the ServerKeyGenResponse object to encrypt the private key of the 326 server generated key pair. 328 -- fArchiveKey is set to TRUE if the client wishes the key to be 329 archived as well as generated on the server. Servers MAY archive 330 the server-generated key even if fArchiveKey is set to FALSE. 332 Servers SHOULD NOT generate the key pair when archival is requested 333 but the server would not archive the key material. 335 -- selectionCriteria contains a string allowing for the selective 336 retrieval of archived keys from the server. The selectionCriteria 337 field should appear only if fArchiveKey is set to TRUE. 339 The client can request that the generated key be a specific 340 algorithm by placing data in the publicKey field of the 341 certificateRequest field. When the publicKey field is populated, 342 the subjectPublicKey MUST be a zero length bit string and the 343 algorithmIdentifier SHOULD omit the parameters field. If the 344 client requests a specific algorithm, the server MUST generate a 345 key of that algorithm (with the parameters if defined) or it MUST 346 fail the request. Servers MUST support key generation for Diffie- 347 Hellman RSA. Servers SHOULD MAY support key generation for Diffie- 348 HellmanRSA. Servers MAY support key generation for other 349 algorithms. 351 If the request contains no requested algorithm, servers SHOULD 352 generate a Diffie-Hellmann RSA key exchange key pair. 354 A server is not required to use all of the values suggested by the 355 client in the certificate template. Servers MUST be able to 356 process all extensions defined in [PXIXCERT]. Servers are not 357 required to be able to process other V3 X.509 extension transmitted 358 using this protocol, nor are they required to be able to process 359 other, private extensions. Servers are permitted to modify client- 360 requested extensions. Servers MUST NOT alter an extension so as to 361 invalidate the original intent of a client-requested extension. 362 (For example change key usage from key exchange to signing.) If a 363 certificate request is denied due to the inability to handle a 364 requested extension, the server MUST respond with a failInfo 365 attribute of unsupportedExt. 367 The identity proof algorithm presented in section 5.2 in [CMC] does 368 not work if there are no certificate requests present. If the 369 request contains no certificate request objects and the request is 370 not being signed by a pre-existing signing certificate, the 371 algorithm in section 5.2 should be modified to use the set of 372 server key generation requests encoded in a sequence as the data 373 hashed. 375 4.2 Server-side Key Generation Response 377 The server creates a server-side key generation response attribute 378 for every key generation request made and successfully completed. 379 The response message has a pointer to both the originating request 380 attribute and to the body part in the current message that holds 381 the encrypted private keys. The response message also can contain 382 a pointer to the certificate issued. The key recovery response 383 control attribute has the following OID and syntax: 385 id-cmc-Ctrl-ServerKeyGenResponse ::= OBJECT IDENTIFIER ::= {pkixid- 386 cmc XX} 388 ServerKeyGenRsp ServerKeyGenResponse ::= SEQUENCE 390 cmsBodyPartIdD BodyPartID, 391 requestBodyPartId BodyPartID, 392 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 393 } 395 -- cmsBodyPartIdD identifies a TaggedContentInfo contained within 396 the enclosing PKIData. The ContentInfo contains the requested 397 private key material. 399 -- requestBodyPartId contains the body part identifier for the 400 server-side key generation request control attribute. This allows 401 for clients to associate the resulting key and certificate with the 402 original request. 404 -- issuerAndSerialNumber if present contains the identity of the 405 certificate issued to satisfy the request. The certificate is 406 placed in the certificate bag of the immediately encapsulating 407 signedData object. 409 Clients MUST NOT assume the certificates are in any order. Servers 410 SHOULD include all intermediate certificates needed to form 411 complete chains to one or more self-signed certificates, not just 412 the newly issued certificate(s). The server MAY additionally return 413 CRLs in the CRL bag. Servers MAY include the self-signed 414 certificates. Clients MUST NOT implicitly trust included self- 415 signed certificate(s) merely due to its presence in the certificate 416 bag. In the event clients receive a new self-signed certificate 417 from the server, clients SHOULD provide a mechanism to enable the 418 user to explicitly trust the certificate. 420 4.3 Control Flow 422 In the following control flow examples, ôclientö refers to the 423 entity archiving a private key or requesting recovery generation of 424 a private key, and ôserverö refers to the key archive generation 425 facility. 427 1. The client creates a CMC message containing a server-side key 428 generation request. The required information is filled in on 429 the request. 431 2. Optionally, aAny client-side key generation is done (for 432 signing keys) and the certificate requests are constructed and 433 placed in the PKIData request message. 435 3. If the client possesses a signing key, or one was created in 436 step 2,If a signing capable key was created, it is used to 437 sign the CMC message. Otherwise ?????If no signing key 438 exists, the PKIData request body is placed in an 439 AuthenticatedData structure and a shared secret is used to 440 authenticate the message. 442 4. The request is sent to the server. 444 5. The server does the key generation for the request. 446 6. The server issues all required certificates. 448 7. The server creates a CMC response message with the following 449 attributes: 450 a. All certificates requested are placed in the 451 certificateList in the CMS SignedData object 452 b. The private key generated is encoded as a PrivateKeyInfo 453 object. 454 c. The key object is placed in a PKI-Response as an id-cmc- 455 privateKeyInfo control. 456 d. The PKI-Response body ,is wrapped in a CMS EnvelopedData 457 object using the shrouding information from the request. 458 e. The EnvelopedData object is placed in the cmcSequence of 459 a PKI-Respones Body. 461 8. The CMC response message sent to client. 463 4.44.4 Recovery of pre-generated keys 465 Some server-side key generation servers will need to limit the 466 number of current certified key-pairs for clients. Under these 467 circumstances a client server MAY return an already existing 468 certified key-pair if the keys and certificate satisfy the server- 469 side key generation request. 471 4.54.5 LRA behavior modifications 473 In many cases the actual processing of key archival and key 474 generation controls is done not at the Certification Authority, but 475 at a Registration agent. This section discusses the differences in 476 the protocol based on an RA doing the key generation. 478 An LRA that does the key generation operation would behave as 479 follows: 481 1.1. The key generation would be done in response to the request as 482 above. 483 2.2. A certificate request body is placed in a new CMC message 484 along with the clients CMC message. (Optionally a new CMC message 485 containing all requests plus all relevant controls could be 486 constructed.) 487 3.3. The new CMC message is then sent to the Certification 488 Authority. 489 4.4. When the response is returned, the LRA must builds a new CMC 490 response message containing the encrypted private key info and all 491 relevant certificates. 493 If the AuthenticatedData object is used to provide for protection 494 of the data between the client and the RA, two different shared 495 secrets may be needed to provide the originators identity (one for 496 the RA and one for the CA). 498 5.5. Key Archival and Recovery 500 Servers MAY require key archival of encryption keys as a condition 501 of issuing a certificate for that encryption key pair. Servers MAY 502 reject all requests contained within a PKIData if any required key 503 archival message is missing for any element within the PKIData. 505 There are four objects involved in key archival and recovery 506 scenarios: 508 1.1. The Key Archival control attribute, 509 2.2. The Key Recovery Request control attribute, 510 3.3. The Key Recovery Response control attribute, 511 4.4. A ContentInfo containing private key material. 513 It is assumed that a key recovery operation will only return 514 previously archived material. (That is, if an archival operation 515 and a recovery operation happen simultaneously, the newly archived 516 key material is not returned as part of the recovery response.) 518 The specification only allows for archiving of key material at the 519 time that a certificate is requested for the key material. 521 The Key Recovery Response control can also be used to implement 522 off-client generation of encryption keys. A control statement 523 containing the required fields for key generation is generated on 524 the client as part of the enrollment request message. This is then 525 sent up to the server and the server responds with a Key Recovery 526 Response containing the newly generated key. The details of the 527 request control statement not covered in this document and would be 528 done on a bilateral basis. 530 5.15.1 Key Archival Control Attribute 532 The key archival control attribute has the following ASN.1 syntax: 534 id-cmc-keyArchival ::= OBJECT IDENTIIFER ::= { pkixid-cmc XX12} 536 KeyArchival ::= SEQUENCE 538 reqBodyPartID BodyPartID, 539 cmsBodyPartID BodyPartID, 540 selectionCriteria OCTET STRING OPTIONAL 541 } 543 --The reqBodyPartID is a reference to the payload within the 544 enclosing PKIData that contains the certification request for the 545 public key component of the encryption key pair. If multiple 546 certification requests for the same public key are included in the 547 PKIData, reqBodyPartID may point to any one of them. 549 --The cmsBodyPartID is a reference to the payload within the 550 enclosing PKIData that contains the private key to be archived. 551 The private key MUST be the private component corresponding to the 552 public key referenced by reqBodyPartID. 554 --The selectionCriteria is optional information to be associated 555 with the archived key material to facilitate key recovery of 556 subsections of the archive database. 558 5.25.2 Key Recovery Request Control Attribute 560 The key recovery request control attribute has the following ASN.1 561 syntax: 563 id-cmc-keyRecoveryReq ::= OBJECT IDENTIFER ::= {pkixid-cmc 13XX} 565 KeyRecoveryReq ::= SEQUENCE 567 shroudIdentification ShroudIdentification, 568 bulkEncryptionAlgID AlgorithmIdentifier, 569 selectionCriteria OCTET STRING OPTIONAL 570 } 572 ShroudIdentification ::= CHOICE 574 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 575 encryptionToken [1] AlgorithmIdentifier 576 } 578 --The shroudIdentification structure defines the encryption method 579 and key material that MUST be used in the key recovery response to 580 encrypt the recovered private key material. 582 --The bulkEncryptionAlgID identifies the bulk encryption algorithm 583 that MUST be used by the server to encrypt the key material in the 584 subsequent key recovery response. 586 --The selectionCriteria is optional information to be associated 587 with the archived key material to facilitate key recovery of 588 subsections of the archive database. If selectionCriteria is 589 absent, all archived keys associated with the enrolling identity 590 MUST be returned. [the selectionCriteria sounds rather detailed 591 given the abstract quality of the rest of this discussion. Why not 592 just present the public key(s) in question?] 594 Notice that the recovery request does not include any end-entity 595 identification. Determination of the identity comes from other 596 locations: The name in a certificate request, the name in an 597 identity proof, the name in the shrouding certificate or the name 598 in the signing certificate on the containing SignedInfo structure. 599 Servers need to establish a policy to be used by that server for 600 identifying the entity doing the request operation. 602 5.2.15.2.1 Key Recovery Response Control Attribute 603 The key recovery response control attribute has the following ASN.1 604 syntax: 606 id-cmc-keyRecoveryRsp ::= OBJECT IDENTIFER ::= {pkixid-cmc 14XX} 608 KeyRecoveryRsp ::= SEQUENCE 610 cmsBodyPartID BodyPartID, 611 keyAssocations SEQUENCE OF KeyAssocation OPTIONAL, 612 selectionCriteria OCTET STRING OPTIONAL 613 } 615 KeyAssociation ::= SEQUENCE OF 617 privateKeybodyID BodyPartID, 618 issuerAndSerialNumber IssuerAndSerialNumber 619 } 621 -- cmsBodyPartID identifies a TaggedContentInfo contained within 622 the enclosing PKIData. The ContentInfo contains the requested 623 private key material. 625 -- selectionCriteria is the optional information that was used to 626 retrieve a subset of the keys archived in the archive database. 627 [see corresponding comment above] 629 5.35.3 Control Flow 631 In the following control flow examples, ôclientö refers to the 632 entity archiving a private key or requesting recovery of a private 633 key, and ôserverö refers to the key archive facility. 635 Control flow for Key Archival is assumed to proceed as follows: 636 1.1. Client retrieves an encryption certificate for the archiving 637 server, so that key material to be archived may be encrypted to it. 638 2.2. Client generates an encryption key pair. 639 3.3. Client submits an enrollment request for the key pair. As 640 part of the PKIData, the client includes: 641 a.a. A certificate request (PKCS10 or CRMF) for the key pair, which 642 includes the public key component and a message identifier (either 643 bodyPartID or certReqId), 644 b.b. A Key Archival control attribute, which includes two message 645 identifier references: 646 i.i. The identifier of the certification request in (3a), and 647 ii.ii. The identifier of the ContentInfo in (3c). 648 c.c. A ContentInfo containing inside it the private key material 649 corresponding to the public key contained in the request in (3a) 650 and encrypted using the public key from the certificate obtained in 651 (1). 652 4.4. Server receives the request, archives the key material, and 653 issues certificates as appropriate. Server responds with an 654 enrollment response containing the issued certificates. 656 It is assumed that whatever mechanisms are used to identify the 657 entity requesting certification also serve to identify the 658 archiving party. 660 Control flow for Key Recovery is assumed to proceed as follows: 661 1.1. Client sends a Full PKI Request message containing the Key 662 Recovery Request control attribute to the server. (The PKIData 663 need contain only the Key Recovery Request attribute.) 664 2.2. Server performs policy-based operations to determine whether 665 the recovery request is valid. 666 3.3. Assuming the request is indeed valid, the server sends back to 667 the client a Full PKI Response containing: 668 a.a. One or more Key Recovery Response control attributes. 669 b.b. One or more Private Key attributes containing encrypted 670 private key material as defined in section 0 above. 671 4.4. Client processes the response and extracts private key 672 material from the ContentInfo(s). 674 The above control flow for key recovery assumes that the client 675 possesses at least a previously-certified signature key, which is 676 used to sign the Full PKI Request message. In the event of a 677 catastrophic failure on the client resulting in loss of all client 678 keys, generation and certification of a new signature key may occur 679 simultaneously to a request for recovery of private encryption 680 keys. Control flow for recovering from catastrophic failure may 681 proceed as follows: 682 1. Client generates a new signature key pair and creates a 683 certification request for the public component of the new signature 684 key. 685 2. Client creates a Full PKI Request message containing: 686 a. The certificate request from Step 1, 687 b. A Key Recovery Request control attribute. 688 The Full PKI Request message is signed using the private signature 689 key generated as part of Step 1. Following Section 4.2, the 690 signerInfo field of the signed message will contain a NULL issuer 691 name and a serial number corresponding to the bodyPartID of the 692 certificate request within the PKIData. Notice that as it is not 693 possible for the client to prove identity within the PKI (because 694 all certified key pairs have been lost), another form of proof-of- 695 identity is required (such as use of the identification and 696 identityProof control attributes). 697 3. Client sends the Full PKI Request to the server. 698 4. Server performs policy-based operations on the request message 699 to determine: 700 a. Whether the certification request on the new signature key 701 should be granted, and 702 b. Whether the recovery request is valid. 703 5. Assuming that both requests are valid, the server sends back to 704 the client a Full PKI Response containing: 705 a. A certificate for the signature key, corresponding to the 706 certification request generated by the client. 707 b. One or more Key Recovery Response control attributes. 708 c. One or more Private Key attributes containing private key 709 material as defined in section 3.4.8.4. 711 6. Client processes the response and extracts private key material 712 and certificates. 714 6. Additional Error Codes 716 7. Interactions between Server side Key Gen and Archive Retrieval 718 There are no interactions between the two. If a key gen uses an 719 existing key to satisfy the key gen request, that key MUST be 720 omitted from a key recovery request in the same CMC message. It 721 MUST be included if the recovery request comes in a separate 722 message. 724 8. Open Issues: 726 -- What if there were no keys to be recovered in response to a 727 recovery response? 729 -- How about a first request of a key with no existing info. Can't 730 sign the wrapper. 732 -- 734 9. References 736 [CMS] R. Housley, "Cryptographic Message Syntax", 737 draft-ietf-smime-cms-06.txt, June 1998 739 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet X.509 740 Certificate Request Message Format", 741 RFC 2511, March 1999 743 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" 745 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 746 for Message Authentication", RFC 2104, February 1997. 748 [PKCS1] B. Kaliski, "PKCS #1: RSA Encryption, Version 1.5", RFC 749 2313, 750 March 1998. 752 [PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax 753 Standard, Version 1.2", November 1, 1993. 755 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet X.509 756 Public 757 Key Infrastructure Certificate and CRL Profile", 758 RFC 2459, January 1999 760 [RFC 2119] "Key words for use in RFCs to Indicate Requirement 761 Levels", RFC 2119 763 10. Security Considerations 764 - Servers should never generate signing key material. 765 - POP and identity proofs are important. 766 - Protection of key material on user's machine, in transit and on 767 server's machine. 769 Appendix A. ASN.1 Module 771 CMC-ARCHIVE 773 DEFINITIONS IMPLICIT TAGS ::= 774 BEGIN 776 IMPORTS 777 -- PXIX CRMF 778 CertTemplate 779 FROM PKIXCRMF {iso(1) identified-organization(3) dod(6) 780 internet(1) 781 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod- 782 crmf(5)} 784 -- PKIX CMC 785 BodyPartID, id-cmc 786 FROM EnrollmentMessageSyntax { iso(1) identified- 787 organization(3) dod(4) 788 internet(1) security(5) mechansims(5) pkix(7) id- 789 mod(0) 790 id-mod-cmc(6)} 792 -- S/MIME CMS 793 IssuerAndSerialNumber 794 FROM CryptographicMessageSyntax { iso(1) member-body(2) 795 us(840) 796 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 797 cms(1) } 799 -- PKIX Part 1 - Implicit 800 AlgorithmIdentifier, Attribute, Certificate, 801 SubjectPublicKeyInfo 802 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 803 internet(1) security(5) mechanisms(5) pkix(7) id- 804 mod(0) 805 id-pkix1-implicit(18)}; 807 id-cmc-shroudPublicKey OBJECT IDENTIFIER ::= {id-cmc XX0} 808 ShroudPublicKey ::= CHOICE 810 certificate Certificate, 811 publicKey SubjectPublicKeyInfo 812 } 814 id-cmc-shroudSharedSecret OBJECT IDENTIFIER ::= {id-cmc XX1} 815 ShroudSharedSecret ::= SEQUENCE 817 keyIdentifier OCTET STRING, 818 salt OCTET STRING OPTIONAL, 819 count INTEGER DEFAULT 1, 820 hash AlgorithmIdentifier OPTIONAL 821 } 823 id-cmc-privateKeyInfo OBJECT IDENTIFIER ::= {id-cmc XX2} 824 PrivateKeyInfo ::= SEQUENCE 826 version INTEGER, 827 privateKeyAlgorithm AlgorithmIdentifier, 828 privateKey OCTET STRING, 829 attributes [0] IMPLICIT Attributes OPTIONAL 830 } 832 Attributes ::= SET OF Attribute 834 -- 835 -- Contains the private number for DH. The parameters for 836 Algorithm 837 -- identifer are DomainParameters (from rfc2459) 838 -- privateKey contains DH-PrivateKey 840 id-dh-private-number OBJECT IDENTIFIER ::= {id-cmc XXA9} 841 DH-PrivateKey ::= INTEGER 843 -- 844 -- privateKeyAlgorithm is id-dsa 845 -- parameters is Dss-Params 846 -- privateKey is DSA-PrivateKey 848 DSA-PrivateKey ::= INTEGER 850 -- RSA 851 -- 852 -- privateKeyAlgorithm is rsaEncryption 853 -- parameters is omitted 854 -- privateKey is RSAPrivateKey 856 id-cmc-ServerKeyGenRequest OBJECT IDENTIFIER ::= {id-cmc XX4} 857 ServerKeyGenRequest ::= SEQUENCE 859 certificateRequest CertTemplate, 860 shroudIdentification ShroudIdentification, 861 bulkEncryptionAlgID AlgorithmIdentifier, 862 fArchiveKey BOOLEAN DEFAULT FALSE, 863 selectionCriteria OCTET STRING OPTIONAL 864 } 866 id-cmc-ServerKeyGenResponse OBJECT IDENTIFIER ::= {id-cmc XX5} 867 ServerKeyGenResponse ::= SEQUENCE 869 cmsBodyPartId BodyPartID, 870 requestBodyPartId BodyPartID, 871 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 872 } 874 id-cmc-KeyArchival OBJECT IDENTIFIER ::= {id-cmc XX6} 875 KeyArchival ::= SEQUENCE 877 reqBodyPartID BodyPartID, 878 cmsBodyPartID BodyPartID, 879 selectionCriteria OCTET STRING OPTIONAL 880 } 882 id-cmc-keyRecoveryReq OBJECT IDENTIFIER ::= {id-cmc XX7} 883 KeyRecoverReq ::= SEQUENCE 885 shroudIdentification ShroudIdentification, 886 bulkEncryptionAlgID AlgorithmIdentifier, 887 selectionCriteria OCTET STRING OPTIONAL 888 } 890 ShroudIdentification ::= CHOICE 892 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 893 encryptionToken [1] AlgorithmIdentifier 894 } 896 id-cmc-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-cmc XX8} 897 KeyRecoveryRsp ::= SEQUENCE 899 cmsBodyPartID BodyPartID, 900 keyAssociations SEQUENCE OF KeyAssociation OPTIONAL, 901 selectionCriteria OCTET STRING OPTIONAL 902 } 904 KeyAssociation ::= SEQUENCE 906 privateKeybodyID BodyPartID, 907 issuerAndSerialNumber IssuerAndSerialNumber 908 } 910 END 912 Authors 914 Jim Schaad 915 Soaring Hawk Consulting 916 jimsch@exmsft.com