idnits 2.17.1 draft-ietf-pkix-cmc-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 17) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** 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 document seems to lack an Authors' Addresses Section. ** There are 310 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 14: '...hat other groups MAY also distribute w...' RFC 2119 keyword, line 18: '... MAY be updated, replaced, or obsolete...' RFC 2119 keyword, line 295: '... Servers MUST be able to understand an...' RFC 2119 keyword, line 296: '... Clients MUST produce a PKCS10 request...' RFC 2119 keyword, line 297: '...message. Clients MAY produce a PKCS10 ...' (184 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? 'CMS' on line 1826 looks like a reference -- Missing reference section? 'PKCS10' on line 1850 looks like a reference -- Missing reference section? 'SMIMEV3' on line 1863 looks like a reference -- Missing reference section? 'PKCS7' on line 1844 looks like a reference -- Missing reference section? 'RFC 2119' on line 1857 looks like a reference -- Missing reference section? 'PKIXCERT' on line 1853 looks like a reference -- Missing reference section? 'DH-SIG' on line 1835 looks like a reference -- Missing reference section? 'HMAC' on line 1838 looks like a reference -- Missing reference section? 'CRMF' on line 1829 looks like a reference -- Missing reference section? '0' on line 2151 looks like a reference -- Missing reference section? '1' on line 2137 looks like a reference -- Missing reference section? 'PKCS8' on line 1847 looks like a reference -- Missing reference section? 'PKCS1' on line 1841 looks like a reference -- Missing reference section? 'SMIMEV2' on line 1860 looks like a reference -- Missing reference section? 'DSA' on line 1740 looks like a reference -- Missing reference section? 'X942' on line 1866 looks like a reference -- Missing reference section? 'DH' on line 1833 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Michael Myers (VeriSign) 2 Internet Draft Xiaoyi Liu (Cisco) 3 March 3, 1999 Jim Schaad (Microsoft) 4 expires in six months Jeff Weinstein (Netscape) 6 Certificate Management Messages over CMS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups MAY also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 MAY be updated, replaced, or obsoleted by other documents at any time. 19 It is inappropriate to use Internet-Drafts as reference material or to 20 cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the "1id- 23 abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document defines a Certificate Management protocol using CMS (CMC). 31 This protocol addresses two immediate needs within the Internet PKI 32 community: 34 1. The need for an interface to public key certification products and 35 services based on [CMS] and [PKCS10], and 36 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA- 37 signed certificates with Diffie-Hellman public keys. 39 A small number of additional services are defined to supplement the core 40 certificate request service. 42 Throughout this specification the term CMS is used to refer to both [CMS] 43 and [PKCS7]. For signedData the two specifications are equivalent. For 44 envelopedData CMS is a superset of the PKCS7. In general, the use of 45 PKCS7 in this document is aligned to the Cryptographic Message Syntax 46 [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers 47 to this specification. 49 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in 50 this document are to be interpreted as described in [RFC 2119]. 52 1. Protocol Requirements 53 - The protocol is to be based as much as possible on the existing CMS, 54 PKCS#10 and CRMF specifications. 55 - The protocol must support the current industry practice of a PKCS#10 56 request followed by a PKCS#7 response as a subset of the protocol. 57 - The protocol needs to easily support the multi-key enrollment 58 protocols required by S/MIME and other groups. 59 - The protocol must supply a way of doing all operations in a single- 60 round trip. When this is not possible the number of round trips is to 61 be minimized. 62 - The protocol needs to support optional key escrow and key archival for 63 encryption keys. 64 - The protocol will be designed such that all key generation can occur 65 on the client. 66 - The mandatory algorithms must superset the required algorithms for 67 S/MIME. 68 - The protocol will contain POP methods. Optional provisions for 69 multiple-round trip POP will be made if necessary. 70 - The protocol will support deferred and pending responses to 71 certificate request for cases where external procedures are required to 72 issue a certificate. 73 - The protocol needs to support arbitrary chains of local registration 74 authorities as intermediaries between certificate requesters and 75 issuers. 77 2. Protocol Overview 79 An enrollment transaction in this specification is generally composed of 80 a single round trip of messages. In the simplest case an enrollment 81 request is sent from the client to the server and an enrollment response 82 is then returned from the server to the client. In some more complicated 83 cases, such as delayed certificate issuance and polling for responses, 84 more than one round trip is required. 86 This specification supports two different request messages and two 87 different response messages. 89 Public key certification requests can be based on either the PKCS10 or 90 CRMF object. The two different request messages are (a) the bare PKCS10 91 (in the event that no other services are needed), and (b) the PKCS10 or 92 CRMF message wrapped in a CMS encapsulation as part of a PKIData object. 94 Public key certification responses are based on the CMS signedData 95 object. The response may be either (a) a degenerate CMS signedData 96 object (in the event no other services are needed), or (b) a ResponseBody 97 object wrapped in a CMS signedData object. 99 No special services are provided for doing either renewal (new 100 certificates with the same key) or re-keying (new certificates on new 101 keys) of clients. Instead a renewal/re-key message looks the same as any 102 enrollment message, with the identity proof being supplied by existing 103 certificates from the CA. 105 A provision exists for Local Registration Authorities (LRAs) to 106 participate in the protocol by taking client enrollment messages, 107 wrapping them in a second layer of enrollment message with additional 108 requirements or statements from the LRA and then passing this new 109 expanded request on to the certification authority. 111 This specification makes no assumptions about the underlying transport 112 mechanism. The use of CMS is not meant to imply an email-based 113 transport. 115 Optional services available through this specification are transaction 116 management, replay detection (through nonces), deferred certificate 117 issuance, private key archival, certificate revocation requests and 118 certificate/CRL fetching. 120 2.1 Terminology 122 There are several different terms, abbreviations and acronyms used in 123 this document that we define here for convenience and consistency of 124 usage: 126 "End-Entity" (EE) refers to the entity that owns a key pair and for whom 127 a certificate is issued. 128 "LRA" or "RA" refers to a (Local) Registration Authority. A registration 129 authority acts as an intermediary between an End-Entity and a 130 Certificate Authority. Multiple RAs can exist between the End- 131 Entity and the Certificate Authority. 132 "CA" refers to a Certificate Authority. A certificate authority is the 133 entity that performs the actual issuance of a certificate. 134 "Client" refers to an entity that creates a PKI request. In this 135 document both RAs and End-Entities can be clients. 136 "Server" refers to the entities that process PKI requests and create PKI 137 responses. CAs and RAs can be servers in this document. 138 PKCS#10 139 CRMF 140 CMS 141 DSA 142 RSA 143 D-H 144 SHA-1 145 Transport wrapper 147 2.2 Protocol Flow Charts 149 Figure 1 shows the Simple Enrollment Request and Response messages. The 150 contents of these messages are detailed in Sections 4.1 and 4.3 below. 152 Simple PKI Request Simple PKI Response 153 ------------------------- -------------------------- 155 +----------+ +------------------+ 156 | PKCS #10 | | CMS "certs-only" | 157 +----------+--------------+ | message | 158 | | +------------------+------+ 159 | Certificate Request | | | 160 | | | CMS Signed Data, | 161 | Subject Name | | no signerInfo | 162 | Subject Public Key Info | | | 163 | (K_PUB) | | signedData contains one | 164 | Attributes | | or more certificates in | 165 | | | the "certificates" | 166 +-----------+-------------+ | portion of the | 167 | signed with | | signedData. | 168 | matching | | | 169 | K_PRIV | | encapsulatedContentInfo | 170 +-------------+ | is empty. | 171 | | 172 +--------------+----------+ 173 | unsigned | 174 +----------+ 176 Figure 1: Simple PKI Request and Response Messages 178 Full PKI Request Full PKI Response 179 ----------------------- ------------------------ 181 +----------------+ +----------------+ 182 | CMS signedData | | CMS signedData | 183 | object | | object | 184 +----------------+--------+ +----------------+--------+ 185 | | | | 186 | PKIData object | | ResponseBody object | 187 | | | | 188 | Sequence of: | | Sequence of: | 189 | * | | * | 190 | *| | * | 191 | * | | * | 192 | * | | | 193 | | | where * == zero or more | 194 | where * == zero or more | | | 195 | | | All certificates issued | 196 | Certificate requests | | as part of the response | 197 | are CRMF or PKCS#10 | | are included in the | 198 | objects. Attributes are | | "certificates" portion | 199 | (OID, set of ANY | | of the signedData. | 200 | defined by OID) pairs. | | | 201 | | +---------+---------------+ 202 +-------+-----------------+ | signed by the | 203 | signed (keypair | | CA or an LRA | 204 | used may be pre-| +---------------+ 205 | existing or | 206 | identified in | 207 | the request) | 208 +-----------------+ 210 Figure 2: Full PKI Request and Response Messages 212 Figure 2 shows the Full Enrollment Request and Response messages. The 213 contents of these messages are detailed in Sections 4.2 and 4.4 below. 215 3. Protocol Elements 217 This section covers each of the different elements that may be used to 218 construct enrollment request and enrollment response messages. Section 4 219 will cover how to build the enrollment request and response messages. 221 3.1 PKIData Object 223 The new content object PKIData has been defined for this protocol. This 224 new object is used as the body of the full PKI request message. The new 225 body is identified by: 227 id-ct-PKIData ::= {id-ct 2 } 229 The ASN.1 structure corresponding to this new content type is: 231 PKIData ::= SEQUENCE { 232 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 233 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 234 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 235 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 236 } 238 -- controlSequence consists of a sequence of control attributes. The 239 control attributes defined in this document are found in section 5. 240 Other parties can define additional control attributes. 242 -- reqSequence consists of a sequence of certificate requests. The 243 certificate requests can be either a CertificateRequest (PKCS10 244 request) or a CertReqMsg. Details on each of these requests types 245 are found in sections 3.3.1 and 3.3.2 respectively. 247 -- cmsSequence consists of a sequence of [CMS] message objects. This 248 protocol only uses EnvelopedData, SignedData and EncryptedData. See 249 section 3.5 for more details. 251 -- otherMsgSequence allows for other arbitrary items to be placed 252 into the enrollment protocol. The {OID, any} pair of values allows 253 for arbitrary definition of material. Data objects are placed here 254 while control objects are placed in the controlSequence field. 256 3.2 ResponseBody Object 258 The new content object ResponseBody has been defined for this protocol. 259 This new object is used as the body of the full PKI response message. 260 The new body is identified by: 262 id-ct-PKIResponse ::= {id-ct 3 } 264 The ASN.1 structure corresponding to this body content type is: 266 ResponseBody ::= SEQUENCE { 267 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 268 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 269 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 270 } 272 -- controlSequence consists of a sequence of control attributes. The 273 control attributes defined in this document are found in section 3.4. 274 Other parties can define additional control attributes. 276 -- cmsSequence consists of a sequence of [CMS] message objects. This 277 protocol only uses EnvelopedData, SignedData and EncryptedData. See 278 section 3.5 for more details. 280 -- otherMsgSequence allows for other arbitrary items to be placed 281 into the enrollment protocol. The {OID, any} pair of values allows 282 for arbitrary definition of material. Data objects are placed here 283 while control objects are placed in the controlSequence field. 285 3.3 Certification Requests (PKCS10/CRMF) 287 Certification Requests are based on either PKCS10 or CRMF messages. 288 Section 3.3.1 specifies mandatory and optional requirements for clients 289 and servers dealing with PKCS10 request messages. Section 3.3.2 290 specifies mandatory and optional requirements for clients and servers 291 dealing with CRMF request messages. 293 3.3.1 PKCS10 Request Body 295 Servers MUST be able to understand and process PKCS10 request bodies. 296 Clients MUST produce a PKCS10 request body when using the Simple 297 Enrollment Request message. Clients MAY produce a PKCS10 request body 298 when using the Full Enrollment Request message. 300 When producing a PKCS10 request body, clients MUST produce a PKCS10 301 message body containing a subject name and public key. Some 302 certification products are operated using a central repository of 303 information to assign subject names upon receipt of a public key for 304 certification. To accommodate this mode of operation, the subject name 305 in a CertificationRequest MAY be NULL, but MUST be present. CAs that 306 receive a CertificationRequest with a NULL subject name MAY reject such 307 requests. If rejected and a response is returned, the CA MUST respond 308 with the failInfo attribute of badRequest. 310 The client MAY incorporate one or more standard X.509 v3 extensions in 311 any PKCS10 request as an ExtensionReq attribute. An ExtensionReq 312 attribute is defined as 314 ExtensionReq ::= SEQUENCE OF Extension 316 where Extension is imported from [PKIXCERT] and ExtensionReq is 317 identified by {pkcs-9 14}. 319 Servers are not required to be able to process every v3 X.509 extension 320 transmitted using this protocol, nor are they required to be able to 321 process other, private extensions. Servers are not required to put all 322 client-requested extensions into a certificate. Servers are permitted to 323 modify client-requested extensions. Servers MUST NOT alter an extension 324 so as to invalidate the original intent of a client-requested extension. 325 (For example change key usage from key exchange to signing.) If a 326 certification request is denied due to the inability to handle a 327 requested extension and a response is returned, the server MUST respond 328 with the failInfo attribute of unsupportedExt. 330 3.3.2 CRMF Request Body 332 Servers MUST be able to understand and process CRMF request body. Clients 333 MAY produce a CRMF message body when using the Full Enrollment Request 334 message. 336 This draft imposes the following additional changes on the construction 337 and processing of CRMF messages: 339 - When CRMF message bodies are used in the Full Enrollment Request 340 message, each CRMF message MUST include both the subject and publicKey 341 fields in the CertTemplate. As in the case of PKCS10 requests the 342 subject may be encoded as NULL, but MUST be present. 343 - In general, when both CRMF and CMC controls exist with equivalent 344 functionality, the CMC control SHOULD be used. The CMC control MUST 345 override any CRMF control. 346 - The regInfo field MUST NOT be used on a CRMF message. Equivalent 347 functionality is provided in the regInfo control attribute (section 348 5.13). 349 - The indirect method of proving POP is not supported in this protocol. 350 One of the other methods (including the direct method described in this 351 document) MUST be used instead if POP is desired. The value of 352 encrCert in SubsequentMessage MUST NOT be used. 353 - Since the subject and publicKeyValues are always present, the 354 POPOSigningKeyInput MUST NOT be used when computing the value for 355 POPSigningKey. 357 A server is not required to use all of the values suggested by the client 358 in the certificate template. Servers are not required to be able to 359 process every V3 X.509 extension transmitted using this protocol, nor are 360 they required to be able to process other, private extensions. Servers 361 are permitted to modify client-requested extensions. Servers MUST NOT 362 alter an extension so as to invalidate the original intent of a client- 363 requested extension. (For example change key usage from key exchange to 364 signing.) If a certificate request is denied due to the inability to 365 handle a requested extension, the server MUST respond with a failInfo 366 attribute of unsupportedExt. 368 3.3.3 Production of Diffie-Hellman Public Key Certification Requests 369 Part of a certification request is a signature over the request; Diffie- 370 Hellman is a key agreement algorithm and cannot be used to directly 371 produce the required signature object. [DH-SIG] provides a way to 372 produce the necessary signature. 374 In brief the "self-signature" method requires either the CA publish a D-H 375 certificate or the client create a temporary D-H key pair. The client 376 then computes an HMAC over the certification content using the key 377 agreement as the shared secret. The details of how this works are found 378 in [DH-SIG]. 380 Clients and servers producing self-signed D-H certification requests MUST 381 support [DH-SIG]. 383 3.3.3.1 Diffie-Hellman Empty Signature 385 The Diffie-Hellman private keys cannot always be used to produce some 386 type of signature value as they can be in a decrypt only device. 387 Certification requests require that the signature field be populated. 388 This section provides a signature algorithm specifically for that 389 purposes. The following object identifier and signature value are used 390 to identify this signature type: 392 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 394 NoSignatureValue ::= OCTET STRING 396 The parameters for id-alg-noSignature MUST be present and MUST be encoded 397 as NULL. NoSignatureValue contains the hash of the certification 398 request. It is important to realize that there is no security associated 399 with this signature type. If this signature type is on a certification 400 request and the certificate authority policy requires proof-of-possession 401 on the private key, the POP mechanism defined in section 5.7 MUST be 402 used. 404 3.3.3.2 Diffie-Hellman POP Signature 406 CMC compliant implementations MUST support section 5 of [DH-SIG]. 408 3.3.3.3 Diffie-Hellman MAC signature 410 CMC compliant implementations MAY support section 4 of [DH-SIG]. 412 3.4 Control Attributes 414 The overall control flow of how a message is processed in this document 415 is based on the control attributes. Each control attribute consists of 416 an object identifier and a value based on the object identifier. Servers 417 MUST fail the processing of an entire PKIData message if any included 418 control attribute is not recognized. The response MUST be the error 419 badRequest with the bodyid set to the invalid or unrecognized control. 421 The set of control attributes that are defined by this draft are found in 422 section 5. 424 3.5 Content Info objects 426 This specification uses two different wrapping objects from the CMS 427 draft. SignedData is used for authentication purposes as well as a 428 general transport wrapper. EnvelopedData is used for encryption purposes. 430 3.5.1 Signed Data 432 The signedData object is used in two different locations when 433 constructing enrollment messages. The signedData object is used as a 434 wrapper to a PKIData as part of the enrollment request message. The 435 signedData object is also used as the outer part of an enrollment 436 response message. 438 For the enrollment response the signedData wrapper allows the server to 439 sign the returning data, if any exists, and to carry the certificates and 440 CRLs for the enrollment request. If no data is being returned beyond the 441 certificates, no signerInfo objects are placed in the signedData object. 443 3.5.2 Enveloped Data 445 EnvelopedData is the primary method of providing for the protection of 446 sensitive information in this protocol. The protocol currently uses 447 EnvelopedData in two different areas: The global shrouding of an entire 448 request (see section 4.5) and the shrouding of private key material. 450 The envelopedData object is also used to wrap private key material when 451 sent as part of either the enrollment request or enrollment response 452 message. Private key archival MAY be supported through the use of the CMS 453 envelopedData. If used, clients generate an encrypted blob and include 454 it in the request message. Senders return this value on later enrollment 455 messages if requested to do so. 457 Servers MUST NOT implement envelopedData according to [PKCS7]. There is 458 an ambiguity (about encrypting content types other than id-data) in the 459 language that has lead to non-interoperability. 461 3.5.3 Encrypted Data 463 EncryptedData can be used to protect private key material when doing 464 archive of private key material (see section 5.9). 466 4. PKI Messages 468 This section discusses the details of putting together the different 469 enrollment request and response messages. 471 4.1 Simple Enrollment Request 472 The simplest form of an enrollment request is a plain PKCS10 message. If 473 this form of enrollment request is used for a private key that is capable 474 of generating a signature, the PKCS10 MUST be signed with that private 475 key. If this form of the enrollment request is used for a D-H key, then 476 the D-H POP mechanism described in [DH-SIG] MUST be used. 478 Servers MUST support the Simple Enrollment Request message. If the Simple 479 Enrollment Request message is used, servers MUST return the Simple 480 Enrollment Response message (see Section 3.3) if the enrollment request 481 is granted. If the enrollment request fails, the Full Enrollment 482 Response MAY be returned or no response MAY be returned. 484 Many advanced services specified in this draft are not supported by the 485 Simple Enrollment Request message. 487 4.2 Full PKI Request 489 The Full Enrollment Request provides the most functionality and 490 flexibility. Clients SHOULD use the Full Enrollment Request message when 491 doing client enrollment. Servers MUST support the Full Enrollment 492 Request message. A response MUST be returned to all Full Enrollment 493 Requests. 495 The Full Enrollment Request message consists of a PKIData object wrapped 496 in a signedData CMS object. The objects in the PKIData are ordered as 497 follows: 499 1. All Control Attributes, 500 2. All certification requests, 501 3. All CMS objects, 502 4. All other messages. 504 Each element in a Full Enrollment Request is identified by a unique 4 505 octet integer. This is encoded either the bodyPartIDs or certReqIds 506 field of the element. If duplicate ids are found, the server MUST return 507 the error badRequest with a bodyPartID of 0. The value of 0 has been 508 reserved to refer to the containing PKIData object. 510 The signedData object wrapping the PKIData may be signed either by the 511 private key material of the signature certification request, or by a pre- 512 existing signature key and certificate. If the private key of a 513 signature certification request is being used, then: 514 a) the certification request containing the corresponding public 515 key 516 MUST include a Subject Key Identifier extension request, 517 b) the subjectKeyIdentifier form of signerInfo MUST be used, and 518 c) the value of the subjectKeyIdentifier form of signerInfo MUST 519 be the 520 Subject Key Identifier specified in the corresponding certification 521 request. 523 (The subjectKeyIdentifier form of signerInfo is used here because no 524 certificates have yet been issued for the signing key.) If the request 525 key is used for signing, there MUST be only one signerInfo object in the 526 signedData object. 528 When creating a renewal message the following should be taken into 529 consideration: 531 1. The identification and identityProof control statements are not 532 required. The same information is provided by the use of an existing 533 certificate from the CA when signing the enrollment message. 534 2. CAs and LRAs may impose additional restrictions on the signing 535 certificate used. They may require that the most recently issued 536 signing certificate for an entity be used. 537 3. A renewal message may occur either by creating a new set of keys, or 538 by re-using an existing set of keys. Some CAs may prevent re-use of 539 keys by policy. In this case the CA MUST return NOKEYREUSE as the 540 failure code. 542 4.3 Simple Enrollment Response 544 Servers SHOULD use the simple enrollment response message whenever 545 possible. Clients MUST understand the simple enrollment response 546 message. The simple enrollment response message consists of a signedData 547 object with no signerInfo objects on it. The certificates requested are 548 returned in the certificate bag of the signedData object. 550 Clients MUST NOT assume the certificates are in any order. Servers SHOULD 551 include all certificates to form complete chains to the root, not just 552 the issued certificate. The server MAY additionally return CRLs in the 553 CRL bag. Servers MAY include the root certificates. Clients MUST NOT 554 implicitly trust a self-signed certificate merely due to its presence in 555 the certificate bag. In the event clients receive a new root certificate 556 from the server, clients SHOULD provide a mechanism to enable the user to 557 explicitly trust the received root certificate. 559 4.4 Full PKI Response 561 Servers MUST return full PKI response messages if a) a full PKI request 562 message failed or b) additional services other than returning 563 certificates are required. Servers MAY return full PKI responses with 564 failure information for simple PKI requests. Following section 4.3 above, 565 servers returning only certificates and a success status to the client 566 SHOULD use the simple PKI response message. 568 Clients MUST understand the full PKI response message. 570 The full enrollment response message consists of a signedData object 571 wrapped around a responseBody object. In a responseBody object all 572 Control Attributes MUST precede all CMS objects. The certificates 573 granted in an enrollment response are returned in the certificates field 574 of the immediately encapsulating signedData object. 576 Clients MUST NOT assume the certificates are in any order. Servers SHOULD 577 include all certificates to form complete chains to the root, not just 578 the issued certificate. The server MAY additionally return CRLs in the 579 CRL bag. Servers MAY include the root certificates. Clients MUST NOT 580 implicitly trust a self-signed certificate merely due to its presence in 581 the certificate bag. In the event clients receive a new root certificate 582 from the server, clients SHOULD provide a mechanism to enable the user to 583 explicitly trust the received root certificate. 585 4.5 Application of Encryption to a PKI Message 587 There are occasions where a PKI request or response message must be 588 encrypted in order to prevent any information about the enrollment from 589 being accessible to unintended entities. This section describes the 590 means used to encrypt a PKI message. This section is not applicable to a 591 simple enrollment message. 593 Shrouding is obtained by wrapping the PKI message (a signedData object) 594 in a CMS EnvelopedData object. The nested content type in the 595 EnvelopedData is id-signedData. Note that this is different from S/MIME 596 where there is a MIME layer placed between the encrypted and signed data 597 objects. It is recommended that if an enveloped data layer is applied to 598 a PKI message, a second signing layer be placed outside of the enveloped 599 data layer. The following figure shows how this nesting would be done: 601 Normal Option 1 Option 2 602 ------ -------- -------- 603 SignedData EnvelopedData SignedData 604 PKIData SignedData EnvelopedData 605 PKIData SignedData 606 PKIData 608 Options 1 and 2 provide the benefit of preventing leakage of sensitive 609 data by encrypting the information. LRAs may remove the enveloped data 610 wrapping, and replace or forward without further processing. 612 PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST 613 provided support for all three versions. 615 Alternatively, an authenticated, secure channel could exist between the 616 parties requiring encryption. Clients and servers MAY use such channels 617 instead of the shrouding technique described above to provide secure, 618 private communication of PKI request and response messages. 620 5. Control Attributes 622 Control attributes are carried as part of both PKI requests and 623 responses. Each control attribute is encoded as a unique Object 624 Identifier followed by that data for the control attribute. The encoding 625 of the data is based on the control attribute object identifier. 626 Processing systems would first detect the OID and process the 627 corresponding attribute value prior to processing the message body. 629 The following table lists the names, OID and syntactic structure for each 630 of the control attributes documented in this draft. 632 Control Attribute OID Syntax 633 ----------------- ---------- -------------- 634 cMCStatusInfo pkix-cmc 1 CMCStatusInfo 635 identification pkix-cmc 2 UTF8String 636 identityProof pkix-cmc 3 OCTET STRING 637 dataReturn pkix-cmc 4 OCTET STRING 638 transactionId pkix-cmc 5 INTEGER 639 senderNonce pkix-cmc 6 OCTET STRING 640 recipientNonce pkix-cmc 7 OCTET STRING 641 addExtensions pkix-cmc 8 AddExtensions 642 encryptedPOP pkix-cmc 9 EncryptedPOP 643 decryptedPOP pkix-cmc 10 DecryptedPOP 644 lraPOPWitness pkix-cmc 11 LraPOPWitness 645 keyArchival pkix-cmc 12 KeyArchival 646 keyRecoveryReq pkix-cmc 13 KeyRecoveryReq 647 keyRecoveryRsp pkix-cmc 14 KeyRecoveryRsp 648 getCert pkix-cmc 15 GetCert 649 getCRL pkix-cmc 16 GetCRL 650 revokeRequest pkix-cmc 17 RevokeRequest 651 regInfo pkix-cmc 18 OCTET STRING 652 responseInfo pkix-cmc 19 OCTET STRING 653 privateKey pkix-cmc 20 PrivateKeyInfo 654 QueryPending pkix-cmc 21 OCTET STRING 655 idPOPLinkRandom pkix-cmc 22 OCTET STRING 656 idPOPLinkWitness Pkix-cmc 23 OCTET STRING 658 5.1 CMC Status Info Control Attribute 660 The CMC status info control is used in full PKI Response messages to 661 return information on a client request. This statement uses the 662 following ASN.1 definition: 664 CMCStatusInfo ::= SEQUENCE { 665 cMCStatus CMCStatus, 666 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, 667 statusString UTF8String OPTIONAL, 668 otherInfo CHOICE { 669 failInfo CMCFailInfo, 670 pendInfo PendInfo } OPTIONAL 671 } 673 PendInfo ::= SEQUENCE { 674 pendToken OCTET STRING, 675 pendTime GeneralizedTime 676 } 678 -- cMCStatus is described in section 5.1.1 680 -- bodyList contains the list of body parts in the request message 681 to which this status information applies. If an error is being 682 returned for a simple enrollment message, body list will contain a 683 single integer of value '1'. 685 -- statusString contains a string with additional description 686 information. This string is human readable. 688 -- failInfo is described in section 5.1.2. It provides a detailed 689 error on what the failure was. This choice is present only if 690 cMCStatus is failed. 692 -- pendToken is the token to be used in the queryPending control 693 attribute. 695 -- pendTime contains the suggested time the server wants to be 696 queried about the status of the request. 698 If the cMCStatus field is success, the CMC Status Info Control MAY be 699 omitted unless it is only item in the response message. If no status 700 exists for a certificate request or other item requiring processing, then 701 the value of success is to be assumed. 703 5.1.1 CMCStatus values 705 CMCStatus is a field in the CMCStatusInfo structure. This field contains 706 a code representing the success or failure of a specific operation. 707 CMCStatus has the ASN.1 structure of: 709 CMCStatus ::= INTEGER { 710 success (0), 711 -- request was granted 712 -- reserved (1), 713 -- not used, defined where the original structure was defined 714 failed (2), 715 -- you don't get what you want, more information elsewhere in 716 the message 717 pending (3), 718 -- the request body part has not yet been processed, 719 -- requester is responsible to poll back on this 720 -- pending may only be return for certificate request 721 operations. 722 noSupport (4), 723 -- the requested operation is not supported 724 } 726 5.1.2 CMCFailInfo 728 CMCFailInfo conveys information relevant to the interpretation of a 729 failure condition. The CMCFailInfo has the following ASN.1 structure: 731 CMCFailInfo ::= INTEGER { 732 badAlg (0) 733 -- Unrecognized or unsupported algorithm 734 badMessageCheck (1) 735 -- integrity check failed 736 badRequest (2) 737 -- transaction not permitted or supported 738 badTime (3) 739 -- Message time field was not sufficiently close to the system 741 time 742 badCertId (4) 743 -- No certificate could be identified matching the provided 744 criteria 745 unsuportedExt (5) 746 -- A requested X.509 extension is not supported by the 747 recipient CA. 748 mustArchiveKeys (6) 749 -- Private key material must be supplied 750 badIdentity (7) 751 -- Identification Attribute failed to verify 752 popRequired (8) 753 -- Server requires a POP proof before issuing certificate 754 popFailed (9) 755 -- POP processing failed 756 noKeyReuse (10) 757 -- Server policy does not allow key re-use 758 internalCAError (11) 759 tryLater (12) 760 } 762 Additional failure reasons MAY be defined for closed environments with a 763 need. 765 5.2 Identification and IdentityProof Control Attributes 767 Some CAs and LRAs require that a proof of identity be included in a 768 certification request. Many different ways of doing this exist with 769 different degrees of security and reliability. Most people are familiar 770 with the request of a bank to provide your mother's maiden name as a form 771 of identity proof. 773 CMC provides one method of proving the client's identity based on a 774 shared secret between the certificate requestor and the verifying 775 authority. If clients support full request messages, clients MUST 776 implement this method of identity proof. Servers SHOULD provide this 777 method or have a bilateral method of similar strength available. 779 The CMC method starts with an out-of-band transfer of a token (the shared 780 secret). The distribution of this token is beyond the scope of this 781 document. The client then uses this token for an identity proof as 782 follows: 784 1. The reqSequence field of the PKIData object (encoded exactly as it 785 appears in the request message including the sequence type and length) 786 is the value to be validated. 787 2. A SHA1 hash of the token is computed. 788 3. An HMAC-SHA1 value is then computed over the value produced in Step 1, 789 as described in [HMAC], using the hash of the token from Step 2 as the 790 shared secret value. 792 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value 793 of the identityProof attribute. 795 When the server verifies the identityProof attribute, it computes the 796 HMAC-SHA1 value in the same way and compares it to the identityProof 797 attribute contained in the enrollment request. 799 If a server fails the verification of an identityProof attribute and the 800 server returns a response message, the failInfo attribute MUST be present 801 in the response and MUST have a value of badIdentity. 803 Optionally, servers may require the inclusion of the unprotected 804 identification attribute with an identityProof attribute. The 805 identification attribute is intended to contain either a text string or a 806 numeric quantity, such as a random number, which assists the server in 807 locating the shared secret needed to validate the contents of the 808 identityProof attribute. Numeric values MUST be converted to text string 809 representations prior to encoding as UTF8-STRINGs in this attribute. If 810 the identification control attribute is included in the message, the 811 derivation of the shared secret in step 2 is altered so that the hash of 812 the concatenation of the token and the identity value are hashed rather 813 than just the token. 815 5.3 Linking Identity and POP Information 817 In a PKI Full Request message identity information about the 818 creator/author of the message is carried in the signature of the CMS 819 SignedData object containing all of the certificate requests. Proof-of- 820 possession information for key pairs requesting certification, however, 821 is carried separately for each PKCS#10 or CRMF message. (For keys 822 capable of generating a digital signature the POP is provided by the 823 signature on the PKCS#10 or CRMF. For encryption-only keys the controls 824 described in Section 5.7 below are used.) In order to prevent 825 substitution-style attacks we must guarantee that the same entity 826 generated both the POP and proof-of-identity information. 828 5.3.1 This section describes two mechanisms for linking identity and POP 829 information: witness values cryptographically derived from the 830 shared-secret (Section 5.3.1) and shared-secret/subject DN 831 matching (Section 5.3.2). Clients and servers MUST support the 832 witness value thechnique. Clients and servers MAY support shared- 833 secret/subject DN matching or other bilateral techniques of 834 similar strength. The idea behind both mechanisms is to force the 835 client to sign some data into each certificate request that can be 836 directly associated with the shared-secret; this will defeat 837 attempts to include certificate requests from different entities 838 in a single Full PKI Request message.Witness values derived from 839 the shared-secret 841 The first technique for doing identity-POP linking works by forcing the 842 client to include a piece of information cryptographically-derived from 843 the shared-secret token as a signed extension within each certificate 844 request (PKCS#10 or CRMF) message. This technique is useful if null 845 subject DNs are used (because, for example, the server can generate the 846 subject DN for the certificate based only on the shared secret). 847 Processing begins when the client receives the shared-secret token out- 848 of-band from the server. The client then computes the following values: 850 1. The client generates a random byte-string, R, which SHOULD be 851 at 852 least 512 bits in length. 853 2. A SHA1 hash of the token is computed. 854 3. An HMAC-SHA1 value is then computed over the random value 855 produced 856 in Step 1, as described in [HMAC], using the hash of the token from 857 Step 2 as the shared secret. 858 4. The random value produced in Step 1 is encoded as the value of 859 an 860 idPOPLinkRandom control attribute. This control attribute MUST be 861 included in the Full PKI Request message. 862 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the 863 value of 864 an idPOPLinkWitness extension to the certificate request. 865 a. For CRMF, idPOPLinkWitness is included in the 866 controls section 867 of the CertRequest structure. 868 b. For PKCS#10, idPOPLinkWitness is included in the 869 attributes 870 section of the CertificationRequest structure. 872 Upon receipt, servers MUST verify that each certificate request contains 873 a copy of the idPOPLinkWitness and that its value was derived in the 874 specified manner from the shared secret and the random string included in 875 the idPOPLinkRandom control attribute. 877 5.3.2 Shared-secret/subject DN matching 879 The second technique for doing identity-POP linking is to link a 880 particular subject distinguished name (subject DN) to the shared-secrets 881 that are distributed out-of-band and to require that clients using the 882 shared-secret to prove identity include that exact subject DN in every 883 certificate request. It is expected that many client-server connections 884 using shared-secret based proof-of-identity will use this mechanism. (It 885 is common not to omit the subject DN information from the certificate 886 request messages.) 888 When the shared secret is generated and transferred out-of-band to 889 initiate the registration process (Section 5.2), a particular subject DN 890 is also associated with the shared secret and communicated to the client. 891 (The subject DN generated MUST be unique per entity in accordance with CA 892 policy; a null subject DN cannot be used. A common practice could be to 893 place the identification value as part of the subject DN.) When the 894 client generates the Full PKI Request message, it MUST use these two 895 pieces of information as follows: 896 1. The client MUST include the specific subject DN that it received 897 along with the shared secret as the subject name in every 898 certificate request (PKCS#10 and/or CRMF) in the Full PKI Request. 899 The subject names in the requests MUST NOT be null. 901 2. The client MUST include the identityProof control attribute 902 (Section 5.2), derived from the shared secret, in the Full PKI 903 Request. 904 The server receiving this message MUST (a) validate the identityProof 905 control attribute and then, (b) check that the subject DN included in 906 each certificate request matches that associated with the shared secret. 907 If either of these checks fails the certificate request MUST be rejected. 909 5.3.3 Renewal and Re-Key Messages 911 In a renewal or re-key message, the subject DN in (a) the certificate 912 referenced by the CMS SignerInfo object, and (b) all certificate requests 913 within the request message MUST match according to the standard name 914 match rules described in [PKIXCERT]. 916 5.4 Data Return Control Attribute 918 The data return control attribute allows clients to send arbitrary data 919 (usually some type of internal state information) to the server and to 920 have the data returned as part of the enrollment response message. Data 921 placed in a data return statement is considered to be opaque to the 922 server. The same control is used for both requests and responses. If 923 the data return statement appears in an enrollment message, the server 924 MUST return it as part of the enrollment response message. 926 In the event that the information in the data return statement needs to 927 be confidential, it is expected that the client would apply some type of 928 encryption to the contained data. 930 An example of using this statement is for a client to place an identifier 931 marking the exact source of the private key material. This might be the 932 identifier of a hardware device containing the private key. 934 5.5 Add Extensions Control Attribute 936 The Add Extensions control attribute is used by LRAs in order to specify 937 additional extensions that are to be placed on certificates. This 938 attribute uses the following ASN.1 definition: 940 AddExtensions ::= SEQUENCE { 941 pkiDataReference BodyPartID 942 certReferences SEQUENCE OF BodyPartID, 943 extensions SEQUENCE OF Extension 944 } 946 The pkiDataReference field contains the body part id of the embedded 947 request message. 949 The certReferences field is a list of references to one or more of the 950 payloads contained within a PKIData. Each element of the certReferences 951 sequence MUST be equal to either the bodyPartID of a 952 TaggedCertificationRequest or the certReqId of the CertRequest within a 953 CertReqMsg. By definition, the listed extensions are to be applied to 954 every element referenced in the certReferences sequence. If a request 955 corresponding to bodyPartID cannot be found, the error badRequest is 956 returned referencing this control attribute. 958 The extensions field contains the sequence of extensions to be applied to 959 the referenced certificate requests. 961 Servers are not required to be able to process every v3 X.509 extension 962 transmitted using this protocol, nor are they required to be able to 963 process other, private extensions. Servers are not required to put all 964 LRA-requested extensions into a certificate. Servers are permitted to 965 modify LRA-requested extensions. Servers MUST NOT alter an extension so 966 as to reverse the meaning of a client-requested extension. If a 967 certification request is denied due to the inability to handle a 968 requested extension and a response is returned, the server MUST return a 969 failInfo attribute with the value of unsupportedExt. 971 If multiple Add Extensions statements exist in an enrollment message, the 972 exact behavior is left up to the certificate issuer policy. However it 973 is recommended that the following policy be used. These rules would be 974 applied to individual extensions within an Add Extensions control 975 attribute (as opposed to an "all or nothing" approach). 977 1. If the conflict is within a single PKIData object, the certificate 978 request would be rejected with an error of badRequest. 979 2. If the conflict is between different PKIData objects, the outermost 980 version of the extension would be used. 982 5.6 Transaction Management Control Attributes 984 Transaction management attributes are an optional portion of CMC. A 985 server does not need to implement this section to be compliant with CMC. 987 Transactions MAY be identified and tracked using a transaction 988 identifier. If used, clients generate transaction identifiers and retain 989 their value until the server responds with a message that completes the 990 transaction. Servers correspondingly include received transaction 991 identifiers in the response. 993 The transactionId attribute identifies a given transaction. It is used 994 between client and server to manage the state of an operation. It MAY be 995 included in service request messages. If included, responses MUST 996 included the transmitted value. A server MUST use only transactionIds in 997 the outermost PKIdata object. TransactionIds on inner PKIdata objects are 998 for intermediate entities. 1000 Replay protection can be supported through the use of sender and 1001 recipient nonces. If used, clients generate a nonce value and include it 1002 in the request as a sender nonce. Servers return this value as recipient 1003 nonce along their own value for sender nonce. A server MUST use only 1004 nonces in the outermost PKIdata object. Nonces on inner PKIdata objects 1005 are for intermediate entities. 1007 The senderNonce and recipientNonce attribute can be used to provide 1008 application-level replay prevention. They MAY be included in service 1009 request messages. Originating messages include only a value for 1010 senderNonce. If included, responses MUST include the transmitted value of 1011 the previously received senderNonce as recipientNonce and include a value 1012 for senderNonce. 1014 If nonces are used, in the first message of a transaction, no 1015 recipientNonce is transmitted; a senderNonce is instantiated by the 1016 message originator and retained for later reference. The recipient of a 1017 sender nonce reflects this value back to the originator as a 1018 recipientNonce and includes it's own senderNonce. Upon receipt by the 1019 transaction originator of this message, the originator compares the value 1020 of recipientNonce to its retained value. If the values match, the 1021 message can be accepted for further security processing. The received 1022 value for senderNonce is also retained for inclusion in the next message 1023 associated with the same transaction. 1025 If a transaction originator includes a value for the senderNonce 1026 attribute, responses MUST include this value as a value for 1027 recipientNonce AND include a value for the SenderNonce attribute. 1029 If a transaction originator includes a value for the transactionid 1030 attribute in a service request, responses MUST include this value as a 1031 value for transactionid attribute. 1033 5.7 Proof-of-possession (POP) for encryption-only keys 1035 Everything described in this section is optional to implement. Servers 1036 MAY require this POP be used only if another POP method is unavailable. 1037 Servers MAY reject all requests contained within a PKIData if any 1038 required POP is missing for any element within the PKIData. 1040 Many servers require proof that an entity requesting a certificate for a 1041 public key actually possesses the corresponding private component of the 1042 key pair. For keys that can be used as signature keys, signing the 1043 certification request with the private key serves as a POP on that key 1044 pair. With keys that can only be used for encryption operations, POP 1045 MUST be performed by forcing the client to decrypt a value. See Section 1046 5 of [CRMF] for a detailed discussion of POP. 1048 By necessity, POP for encryption-only keys cannot be done in one round- 1049 trip, since there are four distinct phases: 1050 1. Client tells the server about the public component of a new encryption 1051 key pair. 1052 2. Server sends the client a POP challenge, encrypted with the presented 1053 public encryption key, which the client must decrypt. 1054 3. Client decrypts the POP challenge and sends it back to the server. 1055 4. Server validates the decrypted POP challenge and continues processing 1056 the certificate request. 1058 CMC defines two different attributes. The first deals with the encrypted 1059 challenge sent from the server to the user in step 2. The second deals 1060 with the decrypted challenge sent from the client to the server in step 1061 3. 1063 The encryptedPOP attribute is used to send the encrypted challenge from 1064 the server to the client. As such, it is encoded as a tagged attribute 1065 within the controlSequence of a ResponseBody. (Note that we assume that 1066 the message sent in Step 1 above is an enrollment request and that the 1067 response in step 2 is a Full Enrollment Response including a failureInfo 1068 specifying that a POP is explicitly required, and providing the POP 1069 challenge in the encryptedPOP attribute.) 1071 EncryptedPOP ::= SEQUENCE { 1073 request TaggedRequest, 1074 cms contentInfo, 1075 thePOPAlgID AlgorithmIdentifier, 1076 witnessAlgID AlgorithmIdentifier, 1077 witness OCTET STRING 1078 } 1080 DecryptedPOP ::= SEQUENCE { 1081 bodyPartID BodyPartID, 1082 thePOPAlgID AlgorithmIdentifier, 1083 thePOP OCTET STRING 1084 } 1086 The encrypted POP algorithm works as follows: 1088 1. The server generates a random value y and associates it with the 1089 request. 1090 2. The server returns the encrypted pop with the following fields set: 1091 a. request is the certificate request in the original request message 1092 (it is included here so the client need not key a copy of the 1093 request), 1094 b. cms is an EnvelopedData object, the content type being id-data and 1095 the content being the value y. If the certificate request contains 1096 a subject key identifier (SKI) extension, then the recipient 1097 identifier SHOULD be the SKI. If the issuerAndSerialNumber form is 1098 used, the IsserName MUST be encoded as NULL and the SerialNumber as 1099 the bodyPartId of the certificate request, 1100 c. thePOPAlgID contains the algorithm to be used in computing the 1101 return POP value, 1102 d. witnessAlgID contains the hash algorithm used on y to create the 1103 field witness, 1104 e. witness contains the hashed value of y. 1105 3. The client decrypts the cms field to obtain the value y. The client 1106 computes H(y) using the witnessAlgID and compares to the value of 1107 witness. If the values do not compare or the decryption is not 1108 successful, the client MUST abort the enrollment process. The client 1109 aborts the process by sending a request message containing a 1110 CMCStatusInfo control attribute with failInfo value of popFailed. 1111 4. The client creates the decryptedPOP as part of a new PKIData message. 1112 The fields in the decryptedPOP are: 1114 a. bodyPartID contains the certificate request in the new enrollment 1115 message, 1116 b. thePOPAlgID is copied from the encryptedPOP, 1117 c. thePOP contains the possession proof. This value is computed by 1118 thePOPAlgID using the value y and request referenced in (4a). 1119 5. The server then re-computes the value of thePOP from its cached value 1120 of y and the request and compares to the value of thePOP. If the 1121 values do not match, the server MUST NOT issue the certificate. The 1122 server MAY re-issue a new challenge or MAY fail the request 1123 altogether. 1125 When defining the algorithms for thePOPAlgID and witnessAlgID care must 1126 be taken to ensure that the result of witnessAlgID is not a useful value 1127 to shortcut the computation with thePOPAlgID. Clients MUST implement 1128 SHA-1 for witnessAlgID. Clients MUST implement HMAC-SHA1 for 1129 thePOPAlgID. The value of y is used as the secret value in the HMAC 1130 algorithm and the request referenced in (4a) is used as the data. If y 1131 is greater than 64 bytes, only the first 64 bytes of y are used as the 1132 secret. 1134 One potential problem with the algorithm above is the amount of state 1135 that a CA needs to keep in order to verify the returned POP value. This 1136 describes one of many possible ways of addressing the problem by reducing 1137 the amount of state kept on the CA to a single (or small set) of values. 1139 1. Server generates random seed x, constant across all requests. (The 1140 value of x would normally be altered on a regular basis and kept for a 1141 short time afterwards.) 1142 2. For certificate request R, server computes y = F(x,R). F can be, for 1143 example, HMAC-SHA1(x,R). All that's important for statelessness is 1144 that y be consistently computable with only known state constant x and 1145 function F, other inputs coming from the cert request structure. y 1146 should not be predictable based on knowledge of R, thus the use of a 1147 OWF like HMAC-SHA1. 1149 5.8 LRA POP Witnesses Control Attribute 1151 In an enrollment scenario involving an LRAs the CA may allow (or require) 1152 the LRA to perform the POP protocol with the entity requesting 1153 certification. In this case the LRA needs a way to inform the CA it has 1154 done the POP. This control attribute has been created to address this 1155 issue. 1157 The ASN.1 structure for the LRA POP witness is as follows: 1159 LraPopWitness ::= SEQUENCE { 1160 pkiDataBodyid BodyPartID, 1161 bodyIds SEQUENCE of BodyPartID 1162 } 1164 -- pkiDataBodyid field contains the body part id of the nested CMS 1165 body object containing the client's full request message. 1167 pkiDataBodyid is set to 0 if the request is in the current 1168 PKIRequest body. 1170 -- attribute contains a list of certificate requests for which the 1171 LRA has performed an out-of-band authentication. The method of 1172 authentication could be archival of private key material, challenge- 1173 response or other means. 1175 If a certificate server does not allow for an LRA to do the POP 1176 verification, it returns an error of POPFAILURE. The CA MUST NOT start a 1177 challenge-response to re-verify the POP itself. 1179 5.9 Key Archival and Recovery 1181 Everything described in this section is optional to implement. Servers 1182 MAY require key archival of encryption keys as a condition of issuing a 1183 certificate for that encryption key pair. Servers MAY reject all requests 1184 contained within a PKIData if any required key archival message is 1185 missing for any element within the PKIData. 1187 There are four objects involved in key archival and recovery scenarios: 1189 1. The Key Archival control attribute, 1190 2. The Key Recovery Request control attribute, 1191 3. The Key Recovery Response control attribute, 1192 4. A ContentInfo containing private key material. 1194 It is assumed that a key recovery operation will only return previously- 1195 archived material. (That is, if an archival operation and a recovery 1196 operation happen simultaneously, the newly archived key material is not 1197 returned as part of the recovery response.) 1199 The Key Recovery Response control can also be used to implement off- 1200 client generation of encryption keys. A control statement containing the 1201 required fields for key generation is generated on the client as part of 1202 the enrollment request message. This is then sent up to the server and 1203 the server responds with a Key Recovery Response containing the newly 1204 generated key. The details of the request control statement not covered 1205 in this document and would be done on a bilateral basis. 1207 5.9.1 Key Archival Control Attribute 1209 The key archival control attribute has the following ASN.1 syntax: 1211 KeyArchival ::= SEQUENCE { 1212 reqBodyPartID BodyPartID, 1213 cmsBodyPartID BodyPartID, 1214 selectionCriteria OCTET STRING OPTIONAL 1215 } 1217 The reqBodyPartID is a reference to the payload within the enclosing 1218 PKIData that contains the certification request for the public key 1219 component of the encryption key pair. If multiple certification requests 1220 for the same public key are included in the PKIData, reqBodyPartID may 1221 point to any one of them. 1223 The cmsBodyPartID is a reference to the payload within the enclosing 1224 PKIData that contains the private key to be archived. The private key 1225 MUST be the private component corresponding to the public key referenced 1226 by reqBodyPartID. 1228 The selectionCriteria is optional information to be associated with the 1229 archived key material to facilitate key recovery of subsections of the 1230 archive database. 1232 5.9.2 Key Recovery Request Control Attribute 1234 The key recovery request control attribute has the following ASN.1 1235 syntax: 1237 KeyRecoveryReq ::= SEQUENCE { 1238 shroudIdentification ShroudIdentification, 1239 bulkEncryptionAlgID AlgorithmIdentifier, 1240 selectionCriteria OCTET STRING OPTIONAL 1241 } 1243 ShroudIdentification ::= CHOICE { 1244 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 1245 encryptionToken [1] AlgorithmIdentifier 1246 } 1248 The shroudIdentification structure defines the encryption method and key 1249 material that MUST be used in the key recovery response to encrypt the 1250 recovered private key material. Two methods of identification are 1251 currently defined. In the first, the public key component of an 1252 encryption key pair is explicitly included in the request. The second 1253 method derives a key from a known secret shared between client and 1254 server, such as an out-of-band token. This method is defined as an 1255 AlgorithmIdentifier as it must identify (a) the source of the key 1256 material, (b) any public/salt information, and (c) the method of deriving 1257 an encryption key using the request data, source key material and salt. 1258 Clients and servers MUST support the subject public key method. Clients 1259 and servers support of other methods is based on a bilateral agreement. 1261 The bulkEncryptionAlgID identifies the bulk encryption algorithm that 1262 MUST be used by the server to encrypt the key material in the subsequent 1263 key recovery response. 1265 The selectionCriteria is optional information to be associated with the 1266 archived key material to facilitate key recovery of subsections of the 1267 archive database. If selectionCriteria is absent, all archived keys 1268 associated with the enrolling identity MUST be returned. 1270 Notice that the recovery request does not include any end-entity 1271 identification. Determination of the identity comes from other 1272 locations: The name in a certificate request, the name in an identity 1273 proof, the name in the shrouding certificate or the name in the signing 1274 certificate on the containing SignedInfo structure. Servers need to 1275 establish a policy to be used by that server for identifying the entity 1276 doing the request operation. 1278 5.9.3 Key Recovery Response Control Attribute 1280 The key recovery response control attribute has the following ASN.1 1281 syntax: 1283 KeyRecoveryRsp ::= SEQUENCE { 1284 cmsBodyPartID BodyPartID, 1285 selectionCriteria OCTET STRING OPTIONAL 1286 } 1288 -- cmsBodyPartID identifies a TaggedContentInfo contained within the 1289 enclosing PKIData. The ContentInfo contains the requested private 1290 key material. 1292 -- selectionCriteria is the optional information that was used to 1293 retrieve a subset of the keys archived in the archive database. 1295 5.9.4 Private Key Info Attribute 1297 The private key info attribute is imported from [PKCS8]. Private key 1298 information is tagged by the private key info attribute. This attribute 1299 has the ASN.1 structure: 1301 PrivateKeyInfo ::= SEQUENCE { 1302 version INTEGER, 1303 privateKeyAlgorithm AlgorithmIdentifier, 1304 privateKey OCTET STRING, 1305 attributes [0] IMPLICIT Attributes OPTIONAL 1306 } 1308 Attributes ::= SET OF Attribute 1310 -- version MUST be the value 0 1312 -- privateKeyAlgorithm contains the identifier for the private key 1313 object 1315 -- privateKey is an octet string whose contents is the private key 1316 and whose format is defined by the value of privateKeyAlgorithm. 1318 -- attributes is a set of attributes. These are extended 1319 information that is part of the private key information. 1321 We are defining the structures here to be used for three algorithms. 1323 5.9.4.1 D-H Private Keys 1325 When creating a PrivateKeyInfo for a D-H key, the following rules apply: 1326 1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The 1327 parameter for id-dh-private-number is DomainParameters (imported from 1328 [PKIXCERT]). 1329 2. The ASN structure for privateKey MUST be 1331 DH-PrivateKey ::= INTEGER 1333 3. attributes MUST be omitted. 1335 5.9.4.2 DSA Private Keys 1337 When creating a PrivateKeyInfo for a DSA key, the following rules apply: 1338 1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters for 1339 id- 1340 dsa is Dss-Parms (imported from [PKIXCERT]). 1341 2. The ASN structure for privateKey MUST be 1343 DSA-PrivateKey ::= INTEGER 1345 3. attributes MUST be omitted. 1347 5.9.4.3 RSA Private Keys 1349 When creating a PrivateKeyInfo for an RSA key, the following rules apply: 1350 1. The privateKeyAlgorithm MUST be set to rsaEncryption. 1351 2. The ASN structure for privateKey MUST be RSAPrivateKey (defined in 1352 [PKCS1]) 1353 3. Attributes MUST be omitted. 1355 5.9.5 ContentInfo Objects for Private Key Material 1357 ContentInfo object that contain private key material MUST be one of 1358 EnvelopedData, EncryptedData or Data. Private key material placed in a 1359 Data ContentInfo MUST be encrypted through some other mechanism; it is 1360 beyond the scope of this document to specify that mechanism. 1362 The inner content of the EnvelopedData or EncryptedData is a 1363 ResponseBody. The private keys are then encoded as private key info 1364 control attributes. 1366 5.9.6 Control Flow 1368 In the following control flow examples, "client" refers to the entity 1369 archiving a private key or requesting recovery of a private key, and 1370 "server" refers to the key archive facility. 1372 Control flow for Key Archival is assumed to proceed as follows: 1373 1. Client retrieves an encryption certificate for the archiving server, 1374 so that key material to be archived may be encrypted to it. 1375 2. Client generates an encryption key pair. 1377 3. Client submits an enrollment request for the key pair. As part of the 1378 PKIData, the client includes: 1379 a. A certificate request (PKCS10 or CRMF) for the key pair, which 1380 includes the public key component and a message identifier (either 1381 bodyPartID or certReqId), 1382 b. A Key Archival control attribute, which includes two message 1383 identifier references: 1384 i. The identifier of the certification request in (3a), and 1385 ii. The identifier of the ContentInfo in (3c). 1386 c. A ContentInfo containing inside it the private key material 1387 corresponding to the public key contained in the request in (3a) 1388 and encrypted using the public key from the certificate obtained in 1389 (1). 1390 4. Server receives the request, archives the key material, and issues 1391 certificates as appropriate. Server responds with an enrollment 1392 response containing the issued certificates. 1393 It is assumed that whatever mechanisms are used to identify the entity 1394 requesting certification also serve to identify the archiving party. 1396 Control flow for Key Recovery is assumed to proceed as follows: 1397 1. Client sends a Full PKI Request message containing the Key Recovery 1398 Request control attribute to the server. (The PKIData need contain 1399 only the Key Recovery Request attribute.) 1400 2. Server performs policy-based operations to determine whether the 1401 recovery request is valid. 1402 3. Assuming the request is indeed valid, the server sends back to the 1403 client a Full PKI Response containing: 1404 a. One or more Key Recovery Response control attributes. 1405 b. One or more Private Key attributes containing encrypted private key 1406 material as defined in section 5.9.4 above. 1407 4. Client processes the response and extracts private key material from 1408 the ContentInfo(s). 1410 The above control flow for key recovery assumes that the client possesses 1411 at least a previously-certified signature key, which is used to sign the 1412 Full PKI Request message. In the event of a catastrophic failure on the 1413 client resulting in loss of all client keys, generation and certification 1414 of a new signature key may occur simultaneously to a request for recovery 1415 of private encryption keys. Control flow for recovering from 1416 catastrophic failure may proceed as follows: 1417 1. Client generates a new signature key pair and creates a certification 1418 request for the public component of the new signature key. 1419 2. Client creates a Full PKI Request message containing: 1420 a. The certificate request from Step 1, 1421 b. A Key Recovery Request control attribute. 1422 The Full PKI Request message is signed using the private signature key 1423 generated as part of Step 1. Following Section 4.2, the signerInfo 1424 field of the signed message will contain a NULL issuer name and a 1425 serial number corresponding to the bodyPartID of the certificate 1426 request within the PKIData. Notice that as it is not possible for the 1427 client to prove identity within the PKI (because all certified key 1428 pairs have been lost), another form of proof-of-identity is required 1429 (such as use of the identification and identityProof control 1430 attributes). 1432 3. Client sends the Full PKI Request to the server. 1433 4. Server performs policy-based operations on the request message to 1434 determine: 1435 a. Whether the certification request on the new signature key should 1436 be granted, and 1437 b. Whether the recovery request is valid. 1438 5. Assuming that both requests are valid, the server sends back to the 1439 client a Full PKI Response containing: 1440 a. A certificate for the signature key, corresponding to the 1441 certification request generated by the client. 1442 b. One or more Key Recovery Response control attributes. 1443 c. One or more Private Key attributes containing private key material 1444 as defined in section 3.4.8.4. 1445 6. Client processes the response and extracts private key material and 1446 certificates. 1448 5.10 Get Certificate Control Attribute 1450 Everything described in this section is optional to implement. 1452 The get certificate control attribute is used to retrieve previously 1453 issued certificates from a repository of certificates. A certificate 1454 server, an LRA or an independent service may provide this repository. The 1455 clients expected to use this facility are those operating in a resource- 1456 constrained environment. (An example of a resource-constrained client 1457 would be a low-end IP router that does not retain its own certificate in 1458 non-volatile memory.) 1460 The get certificate control attribute has the following ASN.1 structure: 1462 GetCert ::= SEQUENCE { 1463 issuerName GeneralName, 1464 serialNumber INTEGER } 1466 The service responding to the request will place the requested 1467 certificate in the certificates field of a SignedData object. If the get 1468 certificate attribute is the only control in a Full PKI Request message, 1469 the response would be a Simple Enrollment Response.. 1471 5.11 Get CRL Control Attribute 1473 Everything described in this section is optional to implement. 1475 The get CRL control attribute is used to retrieve CRLs from a repository 1476 of CRLs. A certificate server, an LRA or an independent service may 1477 provide this repository. The clients expected to use this facility are 1478 those where a fully deployed directory is either infeasible or 1479 undesirable. 1481 The get CRL control attribute has the following ASN.1 structure: 1483 GetCRL ::= SEQUENCE { 1484 issuerName Name, 1485 cRLName GeneralName OPTIONAL, 1486 time GeneralizedTime OPTIONAL, 1487 reasons ReasonFlags OPTIONAL } 1489 The fields in a GetCRL have the following meanings: 1491 -- issuerName is the value of the Issuer DN in the subject 1492 certificate. 1494 -- cRLName may be the value of CRLDistributionPoints in the subject 1495 certificate or equivalent value in the event the certificate does 1496 not contain such a value. 1498 -- time is used by the client to specify from among potentially 1499 several issues of CRL that one whose thisUpdate value is less than 1500 but nearest to the specified time. In the absence of a time 1501 component, the CA always returns with the most recent CRL. 1503 -- reasons is used to specify from among CRLs partitioned by 1504 revocation reason. Implementers should bear in mind that while a 1505 specific revocation request has a single CRLReason code--and 1506 consequently entries in the CRL would have a single CRLReason code 1507 value--a single CRL can aggregate information for one or more 1508 reasonFlags. 1510 A service responding to the request will place the requested CRL in the 1511 crls field of a SignedData object. If the get CRL attribute is the only 1512 control in a full enrollment message, the response would be a simple 1513 enrollment response. 1515 5.12 Revocation Request Control Attribute 1517 The revocation request control attribute is used to request that a 1518 certificate be revoked. 1520 The revocation request control attribute has the following ASN.1 syntax: 1522 RevRequest ::= SEQUENCE { 1523 issuerName Name, 1524 serialNumber INTEGER, 1525 reason CRLReason, 1526 sharedSecret OCTET STRING OPTIONAL, 1527 comment UTF8string OPTIONAL } 1529 For a revocation request to become a reliable object in the event of a 1530 dispute, a strong proof of originator authenticity is required. However, 1531 in the instance when an end-entity has lost use of their signature 1532 private key, it is impossible to produce a reliable digital signature. 1533 The RevRequest provides for the optional transmission from the end-entity 1534 to the CA of a shared secret that may be used as an alternative 1535 authenticator in the instance of loss of use. The acceptability of this 1536 practice is a matter of local security policy. 1538 (Note that in some situations a Registration Authority may be delegated 1539 authority to revoke certificates on behalf of some population within its 1540 scope control. In these situations the CA would accept the LRA's digital 1541 signature on the request to revoke a certificate, independent of whether 1542 the end entity still had access to the private component of the key 1543 pair.) 1545 Clients MUST provide the capability to produce a digitally signed 1546 revocation request control attribute. Clients SHOULD be capable of 1547 producing an unsigned revocation request containing the end-entity's 1548 shared secret. If a client provides shared secret based self-revocation, 1549 the client MUST be capable of producing a revocation request containing 1550 the shared secret. 1552 The structure of an unsigned, shared secret based revocation request is a 1553 matter of local implementation. The shared secret does not need to be 1554 shrouded when sent in a revocation request. The shared secret has a one- 1555 time use, that of causing the certificate to be revoked, and public 1556 knowledge of the shared secret after the certificate has been revoked is 1557 not a problem. Clients need to inform users that the same shared secret 1558 SHOULD NOT be used for multiple certificates. 1560 A full response message MUST be returned for a revocation request. 1562 5.13 Registration and Response Information Control Attributes 1564 The regInfo control attribute is for clients and LRAs to pass additional 1565 information as part a PKI request. The regInfo control attribute uses 1566 the ASN.1 structure: 1568 RegInfo ::= OCTET STRING 1570 The content of this data is based on bilateral agreement between the 1571 client and server. 1573 If a server (or LRA) needs to return information back to a requestor in 1574 response to data submitted in a regInfo attribute, then that data is 1575 returned as a responseInfo control attribute. The content of the OCTET 1576 STRING forresponse information is based on bilateral agreement between 1577 the client and server. 1579 5.14 Query Pending Control Attribute 1581 In some environments, process requirements for manual intervention or 1582 other identity checking can cause a delay in returning the certificate 1583 related to a certificate request. The query pending attribute allows for 1584 a client to query a server about the state of a pending certificate 1585 request. The server returns a token as part of the CMCStatusInfo 1586 attribute (in the otherInfo field). The client puts the token into the 1587 query pending attribute to identify the correct request to the server. 1589 The ASN.1 structure used by the query pending control attribute is: 1591 QueryPending ::= OCTET STRING 1593 If a server returns a pending state (the transaction is still pending), 1594 the otherInfo MAY be omitted. If it is not omitted then the same value 1595 MUST be returned (the token MUST NOT change during the request). 1597 6. Local Registration Authorities 1599 This specification permits the use of Local Registration Authorities 1600 (LRAs). An LRA sits between the client and the certification authority. 1601 From the client the LRA appears to be the certification authority and 1602 from the server the LRA appears to be a client. LRAs receive the 1603 enrollment messages, perform local processing and then forward onto 1604 certificate authorities. Some of the types of local processing that an 1605 LRA can perform include: 1607 - batching multiple enrollment messages together, 1608 - challenge/response POP proofs, 1609 - addition of private or standardized certificate extensions to all 1610 requests, 1611 - archival of private key material, 1612 - routing of requests to different CAs. 1614 When an LRA receives an enrollment message, it may either add its own 1615 layer of wrapping to produce a nested message or strip off the SignedData 1616 objects and produce a new non-nested message. LRAs SHOULD use nested 1617 messages rather than non-nested messages when possible. LRAs SHOULD NOT 1618 remove a signedData object wrapping layer if it was added by the original 1619 requesting entity. LRAs MUST NOT alter a certificate request body (PKCS 1620 #10 or CRMF) as any alteration invalidates the signature on the body and 1621 thus the POP for the private key. 1623 6.1 Nested Messages 1625 The expected procedure for an LRA to add information to an end entities 1626 certificate request message is to take the request and place it into a 1627 new PKIData object. The request is placed in the cmsSequence if it is a 1628 full pki message and the reqSequence field for a simple enrollment 1629 message. Control attributes, such as the add extension attribute, are 1630 then added to the controlSequence field of the PKIData object. An LRA 1631 can combine multiple messages into a single new PKIData object by placing 1632 more than one item in the sequence. 1634 An example of how this would look is illustrated by the following figure: 1636 SignedData (by LRA) 1637 PKIData 1638 controlSequence 1639 LRA added control statements 1640 reqSequence 1641 Zero or more Simple CertificationRequests from clients 1642 cmsSequence 1643 Zero or more Full PKI messages from clients 1644 SignedData (by client) 1645 PKIData 1647 6.2 Non-Nested Messages 1649 LRAs occasionally need to strip off the SignedData portion of a PKIData 1650 message. In this case it is necessary for the LRA to correctly merge the 1651 control statements in the submitted full PKI message with the changes to 1652 be made by this LRA. 1654 6.3 Multiple LRA Operation 1656 In some instances there may be more than one LRA in the path from end 1657 entity to certification authority, in this case the second LRA in the 1658 sequence has two options for adding new control statements. The LRA may 1659 either add a new layer of wrapping (resulting in three levels of nested 1660 signedData objects) or it may strip the previous LRA's signature and 1661 create a new signedData object. In this case the LRA is responsible for 1662 merging together any control statements that the previous LRA may have 1663 added. 1665 7. Transport Wrapping 1667 Depending on the transport mechanism that is being used to deliver the 1668 enrollment request and responses different types of wrapping is required. 1669 We document for use three different wrapping items here. Mime wrapping 1670 is for transports that are natively mime based such as HTTP and E-mail. 1671 A binary file transport is defined since floppy disk transport is still 1672 very common. File transport can be done either as MIME wrapped (section 1673 7.1) or bare (section 7.2). 1675 7.1 MIME Wrapping 1677 MIME wrapping is defined for those environments that are MIME native. 1678 These include E-Mail based protocols as well as HTTP. 1680 The basic mime wrapping in this section is taken from [SMIMEV2] and 1681 [SMIMEV3]. Simple enrollment requests are encoded using the 1682 application/pkcs10 content type. A file name MUST be included either in 1683 a content type or content disposition statement. The extension for the 1684 file MUST be ".p10". 1686 Simple enrollment response messages MUST be encoded as content-type 1687 application/pkcs7-mime. An smime-type parameter MUST be on the content- 1688 type statement with a value of "certs-only." A file name with the ".p7c" 1689 extension MUST be specified as part of the content-type or content- 1690 disposition. 1692 Full enrollment request messages MUST be encoded as content-type 1693 application/pkcs7-mime. The smime-type parameter MUST be included with a 1694 value of "CMC-enroll". A file name with the ".p7m" extension MUST be 1695 specified as part of the content-type or content-disposition statement. 1697 Full enrollment response messages MUST be encoded as content-type 1698 application/pkcs7-mime. The smime-type parameter MUST be included with a 1699 value of "CMC-response." A file name with the ".p7m" extensions MUST be 1700 specified as part of the content-type or content-disposition. 1702 MIME TYPE File Extension SMIME-TYPE 1704 application/pkcs10 .p10 N/A 1705 (simple PKI request) 1707 application/pkcs7-mime .p7m CMC-request 1708 (full PKI request) 1710 application/pkcs7-mime .p7c certs-only 1711 (simple PKI response) 1713 applicication/pkcs7-mime .p7m CMC-response 1714 (full PKI response) 1716 7.2 File-Based Transport 1718 Enrollment messages and responses may also be transferred between clients 1719 and servers using file system-based mechanisms, such as when enrollment 1720 is performed for an off-line client. When files are used to transport 1721 binary, BER-encoded Full Enrollment Request and Response messages, the 1722 following file type extensions SHOULD be used: 1724 Message Type File Extension 1726 Full PKI Request .crq 1728 Full PKI Response .crp 1730 7.3 Socket-Based Transport 1732 When enrollment messages and responses are sent over sockets, no wrapping 1733 is required. Messages SHOULD be sent in their binary, BER-encoded form. 1735 8. Interoperability 1737 8.1 Mandatory and Optional Algorithms 1739 CMC clients and servers MUST be capable of producing and processing 1740 message signatures using the Digital Signature Algorithm [DSA]. DSA 1741 signatures MUST be indicated by the DSA AlgorithmIdentifier value (as 1742 specified in section 7.2.2 of [PKIXCERT]). PKI clients and servers 1743 SHOULD also be capable of producing and processing RSA signatures (as 1744 specified in section 7.2.1 of [PKIXCERT]). 1746 CMC clients and servers MUST be capable of protecting and accessing 1747 message encryption keys using the Diffie-Hellman (D-H) key exchange 1748 algorithm. D-H/3DES protection MUST be indicated by the D-H 1749 AlgorithmIdentifier value specified in [CMS]. PKI clients and servers 1750 SHOULD also be capable of producing and processing RSA key transport. 1751 When used for PKI messages, RSA key transport MUST be indicated as 1752 specified in section 7.2.1 of [PKIXCERT]. 1754 8.2 Minimum Conformance Requirements 1756 A minimally compliant CMC server: 1757 a) MUST accept a Full PKI Request message 1758 i) MUST accept CRMF Request Bodies within a Full PKI Request 1759 ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request 1760 b) MUST accept a Simple Enrollment Request message 1761 c) MUST be able to return a Full PKI Response. (A Full PKI Response is 1762 always a valid response, but for interoperability with downlevel clients 1763 a compliant server SHOULD use the Simple Enrollment Response whenever 1764 possible.) 1766 A minimally-complaint CMC client: 1767 a) MAY use either the Simple Enrollment Message or the Full PKI Request. 1768 i) clients MUST use PKCS#10 with the Simple Enrollment Message 1769 ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request 1770 b) MUST understand the Simple Enrollment Response. 1771 c) MUST understand the Full PKI Response. 1773 9. Security Considerations 1775 Initiation of a secure communications channel between an end-entity and a 1776 CA or LRA (and, similarly, between an LRA and another LRA or CA) 1777 necessarily requires an out-of-band trust initiation mechanism. For 1778 example, a secure channel may be constructed between the end-entity and 1779 the CA via IPSEC or TLS. Many such schemes exist and the choice of any 1780 particular scheme for trust initiation is outside the scope of this 1781 document. Implementers of this protocol are strongly encouraged to 1782 consider generally accepted principles of secure key management when 1783 integrating this capability within an overall security architecture. 1785 Mechanisms for thwarting replay attacks may be required in particular 1786 implementations of this protocol depending on the operational 1787 environment. In cases where the CA maintains significant state 1788 information, replay attacks may be detectable without the inclusion of 1789 the optional nonce mechanisms. Implementers of this protocol need to 1790 carefully consider environmental conditions before choosing whether or 1791 not to implement the senderNonce and recipientNonce attributes described 1792 in section 5.6. Developers of state-constrained PKI clients are strongly 1793 encouraged to incorporate the use of these attributes. 1795 Under no circumstances should a signing key be archived. Doing so allows 1796 the archiving entity to potentially use the key for forging signatures. 1798 Due care must be taken prior to archiving keys. Once a key is given to 1799 an archiving entity, the archiving entity could use the keys in a way not 1800 conducive to the archiving entity. Users should be made especially aware 1801 that proper verification is made of the certificate used to encrypt the 1802 private key material. 1804 Clients and servers need to do some checks on cryptographic parameters 1805 prior to issuing certificates to make sure that weak parameters are not 1806 used. A description of the small subgroup attack is provided in [X942]. 1807 CMC implementations ought to be aware of this attack when doing parameter 1808 validations. 1810 10. Open Issues 1812 There appears to be a need to add one or more control statements to 1813 acknowledge the fact that key archival has been completed. (In fact, 1814 there may be a need for a general mechanism for an LRA to communicate 1815 certain process-related information to the next upstream LRA/CA.) 1817 11. Acknowledgments 1819 The authors would like to thank Brian LaMacchia for his work in 1820 developing and writing up many of the concepts presented in this 1821 document. The authors would also like to thank Alex Deacon and Barb Fox 1822 for their contributions. 1824 12. References 1826 [CMS] R. Housley, "Cryptographic Message Syntax", 1827 draft-ietf-smime-cms-06.txt, June 1998 1829 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet X.509 1830 Certificate Request Message Format", 1831 draft-ietf-pkix-crmf-01.txt, May 1998 1833 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" 1835 [DH-SIG] H. Prafullchandra, J. Schaad, "Diffie-Hellman Signing 1836 Algorithm", draft-schaad-dhsign-00.txt, November 1998 1838 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1839 for Message Authentication", RFC 2104, February 1997. 1841 [PKCS1] Kaliski, B. "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, 1842 March 1998. 1844 [PKCS7] B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5", 1845 RFC 2315, October 1997 1847 [PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax 1848 Standard, Version 1.2", November 1, 1993. 1850 [PKCS10] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", 1851 RFC 2314, October 1997 1853 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet Public 1854 Key Infrastructure X.509 Certificate and CRL Profile", 1855 draft-ietf-pkix-ipki-part1-11.txt, September 1998 1857 [RFC 2119] "Key words for use in RFCs to Indicate Requirement 1858 Levels", RFC 2119 1860 [SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, 1861 "S/MIME Version 2 Message Specification", RFC 2311, March 1998 1863 [SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification", 1864 draft-ietf-smime-msg-05.txt, August 1998 1866 [X942] E. Rescorla, "Diffie-Hellman Key Agreement Method". 1867 (currently draft-ietf-smime-x942-*.txt) 1869 13. Author's Addresses 1871 Michael Myers 1872 VeriSign Inc. 1873 1350 Charlston Road 1874 Mountain View, CA, 94043 1875 (650) 429-3402 1876 mmyers@verisign.com 1878 Xiaoyi Liu 1879 Cisco Systems 1880 170 West Tasman Drive 1881 San Jose, CA 95134 1882 (480) 526-7430 1883 xliu@cisco.com 1885 Jim Schaad 1886 Microsoft Corporation 1887 One Microsoft Way 1888 Redmond, WA 98052 1889 (425) 936-3101 1890 jimsch@microsoft.com 1892 Jeff Weinstein 1893 Netscape Communications Corporation 1894 501 Middlefield Road 1895 Mountain View, CA 94043 1896 jsw@netscape.com 1898 Appendix A ASN.1 Module 1900 EnrollmentMessageSyntax 1901 { iso(1) identified-organization(3) dod(4) internet(1) 1902 security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) } 1904 DEFINITIONS IMPLICIT TAGS ::= 1905 BEGIN 1907 -- EXPORTS All -- 1908 -- The types and values defined in this module are exported for use 1909 -- in the other ASN.1 modules. Other applications may use them for 1910 -- their own purposes. 1912 IMPORTS 1914 -- Information Directory Framework (X.501) 1915 Name 1916 FROM InformationFramework { joint-iso-itu-t ds(5) 1917 modules(1) informationFramework(1) 3 } 1919 -- Directory Authentication Framework (X.509) 1920 AlgorithmIdentifier, AttributeCertificate, Certificate, 1921 CertificateList, CertificateSerialNumber 1922 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1923 module(1) authenticationFramework(7) 3 } 1925 -- PKIX Part 1 - Implicit 1926 GeneralName, CRLReason, ReasonFlags 1927 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 1928 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1929 id-pkix1-implicit-88(2)} 1931 -- PKIX Part 1 - Explicit 1932 SubjectPublicKeyInfo, Extension 1933 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 1934 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1935 id-pkix1-explicit-88(1)} 1937 -- Cryptographic Message Syntax 1938 ContentInfo, Attribute 1939 FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1} 1941 -- CRMF 1942 CertReqMsg 1943 FROM CRMF { 1 3 6 1 5 5 7 0 5 }; 1945 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1946 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1948 id-pkix-cmc OBJECT IDENTIFIER ::= {id-pkix } 1950 id-dh-private-number OBJECT IDENTIFIER ::= { id-pkix id-alg(6) } 1952 id-identification OBJECT IDENTIFIER ::= {id-pkix-cmc 2} 1953 id-identityProof OBJECT IDENTIFIER ::= {id-pkix-cmc 3} 1954 id-dataReturn OBJECT IDENTIFIER ::= {id-pkix-cmc 4} 1955 id-transactionId OBJECT IDENTIFIER ::= {id-pkix-cmc 5} 1956 id-senderNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 6} 1957 id-recipientNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 7} 1958 id-regInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 18} 1959 id-responseInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 19} 1960 id-queryPending OBJECT IDENTIFIER ::= {id-pkix-cmc 21} 1961 -- This is the content type used for a request message in the 1962 protocol 1964 id-ct-PKIData OBJECT IDENTIFIER ::= { id-pkix id-ct(5) 2 } 1966 PKIData ::= SEQUENCE { 1967 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1968 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 1969 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1970 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1971 } 1973 bodyIdMax INTEGER ::= 4294967295 1975 BodyPartID ::= INETGER(0..bodyIdMax) 1977 TaggedAttribute ::= SEQUENCE { 1978 bodyPartID BodyPartId, 1979 attrType OBJECT IDENTIFIER, 1980 attrValues SET OF AttributeValue 1981 } 1983 AttributeValue ::= ANY 1985 TaggedRequest ::= CHOICE { 1986 tcr [0] TaggedCertificationRequest, 1987 crm [1] CertReqMsg 1988 } 1990 TaggedCertificationRequest ::= SEQUENCE { 1991 bodyPartID BodyPartID, 1992 certificationRequest CertificationRequest 1993 } 1995 CertificationRequest ::= SEQUENCE { 1996 certificationRequestInfo SEQUENCE { 1997 version INTEGER, 1998 subject Name, 1999 subjectPublicKeyInfo SEQUENCE { 2000 algorithm AlgorithmIdentifier, 2001 subjectPublicKey BIT STRING }, 2002 attributes [0] IMPLICIT SET OF Attribute }, 2003 signatureAlgorithm AlgorithmIdentifier, 2004 signature BIT STRING 2005 } 2007 TaggedContentInfo ::= SEQUENCE { 2008 bodyPartID BodyPartId, 2009 contentInfo ContentInfo 2010 } 2012 OtherMsg ::= SEQUENCE { 2013 bodyPartID BodyPartID, 2014 otherMsgType OBJECT IDENTIFIER, 2015 otherMsgValue ANY DEFINED BY otherMsgType } 2017 -- This defines the response message in the protocol 2018 id-ct-PKIResponse OBJECT IDENTIFIER ::= {id-pkix ct(5) 3 } 2020 ResponseBody ::= SEQUENCE { 2021 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 2022 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 2023 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 2024 } 2026 -- Used to return status state in a response 2028 id-cMCStatusInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 1} 2030 CMCStatusInfo ::= SEQUENCE { 2031 cMCStatus CMCStatus, 2032 bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, 2033 statusString UTF8String OPTIONAL, 2034 otherInfo CHOICE { 2035 failInfo CMCFailInfo, 2036 pendInfo PendInfo } OPTIONAL 2037 } 2039 PendInfo ::= SEQUENCE { 2040 pendToken INTEGER, 2041 pendTime GENERALIZEDTIME 2042 } 2044 CMCStatus ::= INTEGER { 2045 success (0), 2046 -- you got exactly what you asked for 2047 failed (2), 2048 -- you don't get it, more information elsewhere in the message 2049 pending (3), 2050 -- the request body part has not yet been processed, 2051 -- requester is responsible to poll back on this 2052 noSupport (4) 2053 -- the requested operation is not supported 2054 } 2056 CMCFailInfo ::= INTEGER { 2057 badAlg (0), 2058 -- Unrecognized or unsupported algorithm 2059 badMessageCheck (1), 2060 -- integrity check failed 2061 badRequest (2), 2062 -- transaction not permitted or supported 2063 badTime (3), 2064 -- Message time field was not sufficiently close to the system 2065 time 2066 badCertId (4), 2067 -- No certificate could be identified matching the provided 2068 criteria 2069 unsuportedExt (5), 2070 -- A requested X.509 extension is not supported by the recipient 2071 CA. 2072 mustArchiveKeys (6), 2073 -- Private key material must be supplied 2074 badIdentity (7), 2075 -- Identification Attribute failed to verify 2076 popRequired (8), 2077 -- Server requires a POP proof before issuing certificate 2078 popFailed (9), 2079 -- Server failed to get an acceptable POP for the request 2080 noKeyReuse (10) 2081 -- Server policy does not allow key re-use 2082 internalCAError (11) 2083 tryLater (12) 2084 } 2086 -- Used for LRAs to add extensions to certificate requests 2087 id-addExtensions OBJECT IDENTIFIER ::= {id-pkix-cmc 8} 2089 AddExtensions ::= SEQUENCE { 2090 pkiDataReference BodyPartID, 2091 certReferences SEQUENCE OF BodyPartID, 2092 extensions SEQUENCE OF Extension 2093 } 2095 id-encryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 9} 2096 id-decryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 10} 2098 EncryptedPOP ::= SEQUENCE { 2099 request TaggedRequest, 2100 cms ContentInfo, 2101 thePOPAlgID AlgorithmIdentifier, 2102 witnessAlgID AlgorithmIdentifier, 2103 witness OCTET STRING 2104 } 2106 DecryptedPOP ::= SEQUENCE { 2107 bodyPartID BodyPartID, 2108 thePOPAlgID AlgorithmIdentifier, 2109 thePOP OCTET STRING 2110 } 2112 id-lraPOPWitness OBJECT IDENTIFIER ::= {id-pkix-cmc 11} 2114 LraPopWitness ::= SEQUENCE { 2115 pkiDataBodyid BodyPartID, 2116 bodyIds SEQUENCE OF BodyPartID 2117 } 2119 id-keyArchival OBJECT IDENTIFIER ::= {id-pkix-cmc 12} 2120 id-keyRecoveryReq OBJECT IDENTIFIER ::= {id-pkix-cmc 13} 2121 id-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-pkix-cmc 14} 2123 KeyArchival ::= SEQUENCE { 2124 reqBodyPartID BodyPartID, 2125 cmsBodyPartID BodyPartID, 2126 selectionCriteria OCTET STRING OPTIONAL 2127 } 2129 KeyRecoveryReq ::= SEQUENCE { 2130 shroudIdentification ShroudIdentification, 2131 bulkEncryptionAlgID AlgorithmIdentifier, 2132 selectionCriterial OCTET STRING OPTIONAL 2133 } 2135 ShroudIdentification ::= CHOICE { 2136 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 2137 encryptionToken [1] AlgorithmIdentifier 2138 } 2140 KeyRecoveryRsp ::= SEQUENCE { 2141 bodyPartID BodyPartID, 2142 selectionCriteria OCTET STRING OPTIONAL 2143 } 2145 id-privateKey OBJECT IDENTIFIER ::= {id-pkix-cmc 20} 2147 PrivateKeyInfo ::= SEQUENCE { 2148 version INTEGER, 2149 privateKeyAlgorithm AlgorithmIdentifier, 2150 privateKey OCTET STRING, 2151 attributes [0] IMPLICIT Attributes OPTIONAL 2152 } 2154 Attributes ::= SET OF Attribute 2156 DH-PrivateKey ::= INTEGER 2158 -- 2159 id-getCert OBJECT IDENTIFIER ::= {id-pkix-cmc 15} 2161 GetCert ::= SEQUENCE { 2162 issuerName GeneralName, 2163 serialNumber INTEGER } 2165 id-getCRL OBJECT IDENTIFIER ::= {id-pkix-cmc 16} 2167 GetCRL ::= SEQUENCE { 2168 issuerName Name, 2169 cRLName GeneralName OPTIONAL, 2170 time GeneralizedTime OPTIONAL, 2171 reasons ReasonFlags OPTIONAL } 2173 id-revokeRequest OBJECT IDENTIFIER ::= {id-pkix-cmc 17} 2174 RevRequest ::= SEQUENCE { 2175 issuerName Name, 2176 serialNumber INTEGER, 2177 reason CRLReason, 2178 passphrase OCTET STRING OPTIONAL, 2179 comment UTF8String OPTIONAL } 2181 -- The following is used to request V3 extensions be added to a 2182 certificate 2184 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 2185 rsadsi(113549) pkcs(1) pkcs-9(9) 14} 2187 ExtensionReq ::= SEQUENCE OF Extension 2189 -- The following exists to allow Diffie-Hellman Certificate Requests 2190 Messages to be 2191 -- well-formed 2193 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 2195 NoSignatureValue ::= OCTET STRING 2197 END