idnits 2.17.1 draft-ietf-pkix-cmc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 36 longer pages, the longest (page 22) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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. 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: 'HMAC' is mentioned on line 726, but not defined -- Looks like a reference, but probably isn't: '0' on line 1920 -- Looks like a reference, but probably isn't: '1' on line 1905 == Missing Reference: 'PKCS8' is mentioned on line 1113, but not defined == Missing Reference: 'PKCS1' is mentioned on line 1158, but not defined == Missing Reference: 'DSA' is mentioned on line 1542, but not defined == Unused Reference: 'DH' is defined on line 1616, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Normative reference to a draft: ref. 'DH-SIG' ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS7') ** Obsolete normative reference: RFC 2314 (ref. 'PKCS10') (Obsoleted by RFC 2986) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIMEV2') == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-05 Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Michael Myers (VeriSign) 3 Internet Draft Xiaoyi Liu (Cisco) 4 November 11, 1998 Barbara Fox (Microsoft) 5 expires in six months Jeff Weinstein (Netscape) 7 Certificate Management Messages over CMS 8 10 Status of this Memo 12 This document is an Internet-Draft. 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 18 and MAY be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-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 43 [CMS] and [PKCS7]. For signedData the two specifications are 44 equivalent. For envelopedData CMS is a superset of the PKCS7. In 45 general, the use of PKCS7 in this document is aligned to the 46 Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 47 syntax. The term CMC refers 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 63 for 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 72 to issue a certificate. 73 - The protocol needs to support arbitrary chains of local registration 74 agents as intermediaries between certificate requesters and issuers. 76 2. Protocol Overview 78 An enrollment transaction in this specification is generally composed of 79 a single round trip of messages. In the simplest case an enrollment 80 request is sent from the client to the server and an enrollment response 81 is then returned from the server to the client. In some more 82 complicated cases, such as delayed certificate issuance and polling for 83 responses, more than one round trip is required. 85 This specification supports two different request messages and two 86 different response messages. 88 Public key certification requests are based on the PKCS10 object. The 89 two different request messages are (a) the bare PKCS10 (in the event 90 that no other services are needed), and (b) the PKCS10 (or, optionally, 91 a CRMF message) wrapped in a CMS encapsulation as part of a PKIData 92 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 97 ResponseBody 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 102 any enrollment message, with the identity proof being supplied by 103 existing certificates from the CA. 105 A provision exists for Local Registration Agents (LRAs) to participate 106 in the protocol by taking client enrollment messages, wrapping them in a 107 second layer of enrollment message with additional requirements or 108 statements from the LRA and then passing this new expanded request on to 109 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 used in this document that we define 123 here for convenience and consistency of usage: 125 End-Entity refers to the entity that owns a key pair and for whom a 126 certificate is issued. 127 LRA is a Local Registration Agent. A local registration agent acts as 128 an intermediary between an End-Entity and a Certificate Authority. 129 Multiple LRAs can exist between the End-Entity and the Certificate 130 Authority. 131 CA is a Certificate Authority. A certificate authority is the entity 132 that performs the actual issuance of a certificate. 133 Client refers to an entity that creates a PKI request. In this document 134 both LRAs and End-Entities can be clients. 135 Server refers to the entities that process PKI requests and create PKI 136 responses. CAs and LRAs can be servers in this document. 138 2.2 Protocol Flow Charts 140 Figure 1 shows the Simple Enrollment Request and Response messages. The 141 contents of these messages are detailed in Sections 4.1 and 4.3 below. 143 Simple PKI Request Simple PKI Response 144 ------------------------- -------------------------- 146 +----------+ +------------------+ 147 | PKCS #10 | | CMS "certs-only" | 148 +----------+--------------+ | message | 149 | | +------------------+------+ 150 | Certificate Request | | | 151 | | | CMS Signed Data, | 152 | Subject Name | | no signerInfo | 153 | Subject Public Key Info | | | 154 | (K_PUB) | | signedData contains one | 155 | Attributes | | or more certificates in | 156 | | | the "certificates" | 157 +-----------+-------------+ | portion of the | 158 | signed with | | signedData. | 159 | matching | | | 160 | K_PRIV | | encapsulatedContentInfo | 161 +-------------+ | is empty. | 162 | | 163 +--------------+----------+ 164 | unsigned | 165 +----------+ 167 Figure 1: Simple PKI Request and Response Messages 169 Full PKI Request Full PKI Response 170 ----------------------- ------------------------ 172 +----------------+ +----------------+ 173 | CMS signedData | | CMS signedData | 174 | object | | object | 175 +----------------+--------+ +----------------+--------+ 176 | | | | 177 | PKIData object | | ResponseBody object | 178 | | | | 179 | Sequence of: | | Sequence of: | 180 | * | | * | 181 | *| | * | 182 | * | | * | 183 | * | | | 184 | | | where * == zero or more | 185 | where * == zero or more | | | 186 | | | All certificates issued | 187 | Cert requests are CRMF | | as part of the response | 188 | or PKCS#10 objects. | | are included in the | 189 | Attributes are (OID, | | "certificates" portion | 190 | set of ANY defined by | | of the signedData. | 191 | OID) pairs. | | | 192 | | +---------+---------------+ 193 +-------+-----------------+ | signed by the | 194 | signed (keypair | | CA or an LRA | 195 | used may be pre-| +---------------+ 196 | existing or | 197 | identified in | 198 | the request) | 199 +-----------------+ 201 Figure 2: Full PKI Request and Response Messages 203 Figure 2 shows the Full Enrollment Request and Response messages. The 204 contents of these messages are detailed in Sections 4.2 and 4.4 below. 206 3. Protocol Elements 208 This section covers each of the different elements that may be used to 209 construct enrollment request and enrollment response messages. Section 210 4 will cover how to build the enrollment request and response messages. 212 3.1 PKIData Object 214 The new content object PKIData has been defined for this protocol. This 215 new object is used as the body of the full PKI request message. The new 216 body is identified by: 218 id-ct-PKIData ::= {id-pkix } 220 The ASN.1 structure corresponding to this new content type is: 222 PKIData ::= SEQUENCE { 223 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 224 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 225 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 226 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 227 } 229 controlSequence consists of a sequence of control attributes. The 230 control attributes defined in this document are found in section 5. 231 Other parties can define additional control attributes. 232 reqSequence consists of a sequence of certificate requests. The 233 certificate requests can be either a CertificateRequest (PKCS10 234 request) or a CertReqMsg. Details on each of these requests types 235 are found in sections Error! Reference source not found. and Error! 236 Reference source not found. respectively. 237 cmsSequence consists of a sequence of [CMS] message objects. This 238 protocol only uses EnvelopedData, SignedData and EncryptedData. See 239 section 3.5 for more details. 240 otherMsgSequence allows for other arbitrary items to be placed into 241 the enrollment protocol. The {OID, any} pair of values allows for 242 arbitrary definition of material. Data objects are placed here 243 while control objects are placed in the controlSequence field. 245 3.2 ResponseBody Object 247 The new content object ResponseBody has been defined for this protocol. 248 This new object is used as the body of the full PKI response message. 249 The new body is identified by: 251 id-ct-enrollResponse ::= {id-pkix } 253 The ASN.1 structure corresponding to this body content type is: 255 ResponseBody ::= SEQUENCE { 256 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 257 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 258 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 259 } 261 controlSequence consists of a sequence of control attributes. The 262 control attributes defined in this document are found in section 263 3.4. Other parties can define additional control attributes. 265 cmsSequence consists of a sequence of [CMS] message objects. This 266 protocol only uses EnvelopedData, SignedData and EncryptedData. See 267 section 3.5 for more details. 268 otherMsgSequence allows for other arbitrary items to be placed into 269 the enrollment protocol. The {OID, any} pair of values allows for 270 arbitrary definition of material. Data objects are placed here 271 while control objects are placed in the controlSequence field. 273 3.3 Certification Requests (PKCS10/CRMF) 275 Certification Requests are based on either PKCS10 or CRMF messages. 276 Section Error! Reference source not found. specifies mandatory and 277 optional requirements for clients and servers dealing with PKCS10 278 request messages. Section Error! Reference source not found. specifies 279 mandatory and optional requirements for clients and servers dealing with 280 CRMF request messages. 282 3.3.1 PKCS10 Request Body 284 Servers MUST be able to understand and process PKCS10 request bodies. 285 Clients MUST produce a PKCS10 request body when using the Simple 286 Enrollment Request message. Clients MAY produce a PKCS10 request body 287 when using the Full Enrollment Request message. 289 When producing a PKCS10 request body, clients MUST produce a PKCS10 290 message body containing a subject name and public key. Some 291 certification products are operated using a central repository of 292 information to assign subject names upon receipt of a public key for 293 certification. To accommodate this mode of operation, the subject name 294 in a CertificationRequest MAY be NULL, but MUST be present. CAs that 295 receive a CertificationRequest with a NULL subject name MAY reject such 296 requests. If rejected and a response is returned, the CA MUST respond 297 with the failInfo attribute of BADREQUEST. 299 The client MAY incorporate one or more standard X.509 v3 extensions in 300 any PKCS10 request as an ExtensionReq attribute. An ExtensionReq 301 attribute is defined as 303 ExtensionReq ::= SEQUENCE OF Extension 305 where Extension is imported from [PKIXCERT] and ExtensionReq is 306 identified by {pkcs-9 14}. 308 Servers are not required to be able to process every v3 X.509 extension 309 transmitted using this protocol, nor are they required to be able to 310 process other, private extensions. Servers are not required to put all 311 client-requested extensions into a certificate. Servers are permitted 312 to modify client-requested extensions. Servers MUST NOT alter an 313 extension so as to invalidate the original intent of a client-requested 314 extension. (For example change key usage from key exchange to signing.) 315 If a certification request is denied due to the inability to handle a 316 requested extension and a response is returned, the server MUST respond 317 with the failInfo attribute of UNSUPPORTEDEXT. 319 3.3.2 CRMF Request Body 321 Servers MUST be able to understand and process CRMF request body. 322 Clients MAY produce a CRMF message body when using the Full Enrollment 323 Request message. 325 This draft imposes the following additional changes on the construction 326 and processing of CRMF messages: 328 - When CRMF message bodies are used in the Full Enrollment Request 329 message, each CRMF message MUST include both the subject and publicKey 330 fields in the CertTemplate. As in the case of PKCS10 requests the 331 subject may be encoded as NULL, but MUST be present. 332 - The regInfo field MUST NOT be used on a CRMF message. Equivalent 333 functionality is provided in the regInfo control attribute (section 334 5.14). 335 - The indirect method of proving POP is not supported in this protocol. 336 One of the other methods (including the direct method described in 337 this document) MUST used instead if POP is desired. The value of 338 encrCert in SubsequentMessage MUST NOT be used. 339 - Since the subject and publicKeyValues are always present, the 340 POPOSigningKeyInput MUST NOT be used when computing the value for 341 POPSigningKey. 343 A server is not required to use all of the values suggested by the 344 client in the certificate template. Servers are not required to be able 345 to process every V3 X.590 extension transmitted using this protocol, nor 346 are they required to be able to process other, private extensions. 347 Servers are permitted to modify client-requested extensions. Servers 348 MUST NOT alter an extension so as to invalidate the original intent of a 349 client-requested extension. (For example change key usage from key 350 exchange to signing.) If a certificate request is denied due to the 351 inability to handle a requested extension, the server MUST respond with 352 a failInfo attribute of UNSUPPORTEDEXT. 354 3.3.3 Production of Diffie-Hellman Public Key Certification Requests 356 Part of a certification request is a signature over the request; Diffie- 357 Hellman is a key agreement algorithm and cannot be used to directly 358 produce the required signature object. [DH-SIG] provides a way to 359 product necessary signature. 361 In brief the "self-signature" method requires either the CA publish a D- 362 H certificate or the client create a temporary D-H key pair. The client 363 then computes an HMAC over the certification content using the key 364 agreement as the shared secret. The details of how this works are found 365 in [DH-SIG]. 367 Clients and servers producing self-signed D-H certification requests 368 MUST support ephemeral D-H signature method. 370 3.4 Control Attributes 372 The overall control flow of how a message is processed in this document 373 is based on the control attributes. Each control attribute consists of 374 an object identifier and a value based on the object identifier. 375 Servers are permitted to fail the processing of an entire PKIData 376 message if some object identifiers are not fully understood. The set of 377 control attributes that are defined by this draft are found in section 378 5. 380 3.5 Content Info objects 382 This specification uses two different wrapping objects from the CMS 383 draft. SignedData is used for authentication purposes as well as a 384 general transport wrapper. EnvelopedData is used for encryption 385 purposes. 387 3.5.1 Signed Data 389 The signedData object is used in two different locations when 390 constructing enrollment messages. The signedData object is used as a 391 wrapper to an EnrollmentBody as part of the enrollment request message. 392 The signedData object is also used as the outer part of an enrollment 393 response message. 395 For the enrollment response the signedData wrapper allows the server to 396 sign the returning data, if any exists, and to carry the certificates 397 and CRLs for the enrollment request. If no data is being returned 398 beyond the certificates, no signerInfo objects are placed on the 399 signedData object. 401 3.5.2 Enveloped Data 403 EnvelopedData is the primary method of providing for the protection of 404 sensitive in this protocol. The protocol currently uses EnvelopedData 405 in two different areas: The global shrouding of an entire request (see 406 section 4.5) and the shrouding of private key material. 408 The envelopedData object is also used to wrap private key material when 409 sent as part of either the enrollment request or enrollment response 410 message. Private key archival MAY be supported through the use of the 411 CMS envelopedData. If used, clients generate an encrypted blob and 412 include it in the request message. Senders return this value on later 413 enrollment messages if requested to do so. 415 Servers MUST NOT implement envelopedData according to [PKCS7]. There is 416 an ambiguity (about encrypting content types other than id-data) in the 417 language that has lead to non-interoperability. 419 4. PKI Messages 421 This section discusses the details of putting together the different 422 enrollment request and response messages. 424 4.1 Simple Enrollment Request 426 The simplest form of an enrollment request is a plain PKCS10 message. 427 If this form of enrollment request is used, the PKCS10 MUST be self- 428 signed. For Diffie-Hellman "self-signed" means that the ephemeral HMAC 429 signature algorithm in [DH-SIG] MUST be used. 431 Servers MUST support the simple enrollment request message. If the 432 simple enrollment request message is supported, servers MUST return the 433 simple enrollment response message (see Section 3.3) if the enrollment 434 request is granted. If the enrollment request fails, the full 435 enrollment response MAY be returned or no response MAY be returned. 437 Private key archival is not supported by the simple enrollment request 438 message. 440 4.2 Full PKI Request 442 The Full Enrollment Request provides the most functionality and 443 flexibility. Clients SHOULD use the Full Enrollment Request message 444 when doing client enrollment. Servers MUST support the Full Enrollment 445 Request message. 447 The full enrollment request message consists of an enrollmentBody object 448 wrapped in a signedData CMS object. The objects in the enrollmentBody 449 are ordered as follows: 451 1. All Control Attributes, 452 2. All certification requests, 453 3. All CMS objects, 454 4. All other messages. 456 All bodyPartIDs and certReqIds within a PKIData MUST be unique. 458 The signedData object wrapping the enrollmentBody may be signed either 459 by the private key material of the signature certification request, or 460 by a pre-existing signature key and certificate. If the private key of 461 the a signature certification request is being used, the 462 issuerAndSerialNumber field of signerInfo MUST be encoded with the 463 bodyPartID of the signature certificate request for the serial number 464 and a NULL for the issuer name. (This is because no existing issuer and 465 serial number are yet known and a standard method of representing this 466 is needed.) If the request key is used for signing, there MUST be only 467 one signerInfo object in the signedData object. 469 When creating a renewal message the following should be taken into 470 consideration: 472 1. The identification and identificationProof control statements are not 473 required. The same information is provided by the use of an existing 474 certificate from the CA when signing the enrollment message. 475 2. CAs and LRAs may impose additional restrictions on the signing 476 certificate used. They may require that the most recently issued 477 signing certificate for an entity be used. 478 3. A renewal message may occur either by creating a new set of keys, or 479 by re-using an existing set of keys. Some CAs may prevent re-use of 480 keys by policy. In this case the CA MUST return NOKEYREUSE as the 481 failure code. 483 4.3 Simple Enrollment Response 485 Servers SHOULD use the simple enrollment response message whenever 486 possible. Clients MUST understand the simple enrollment response 487 message. The simple enrollment response message consists of a 488 signedData object with no signerInfo objects on it. The certificates 489 requested are returned in the certificate bag of the signedData object. 491 Clients MUST NOT assume the certificates are in any order. Servers 492 SHOULD include all certificates to form complete chains to the root. The 493 server MAY additionally return CRLs in the CRL bag. Servers MAY include 494 the root certificates. Clients MUST NOT implicitly trust a self-signed 495 certificate merely due to its presence in the certificate bag. In the 496 event clients receive a new root certificate from the server, clients 497 SHOULD provide a mechanism to enable the user to explicitly trust the 498 received root certificate. 500 4.4 Full PKI Response 502 Servers MUST return full PKI response messages if a) a full PKI request 503 message failed or b) additional services other than returning 504 certificates are required. Servers MAY return full PKI responses with 505 failure information for simple PKI requests. Following section 4.3 506 above, servers returning only certificates and a success status to the 507 client SHOULD use the simple PKI response message. 509 Clients MUST understand the full PKI response message. 511 The full enrollment response message consists of a signedData object 512 wrapped around a responseBody object. In a responseBody object all 513 Control Attributes MUST precede all cms objects. The certificates 514 granted in an enrollment response are returned in the certificates field 515 of the immediately encapsulating signedData object. 517 Clients MUST NOT assume the certificates are in any order. Servers 518 SHOULD include all certificates to form complete chains to the root. The 519 server MAY additionally return CRLs in the CRL bag. Servers MAY include 520 the root certificates. Clients MUST NOT implicitly trust a self-signed 521 certificate merely due to its presence in the certificate bag. In the 522 event clients receive a new root certificate from the server, clients 523 SHOULD provide a mechanism to enable the user to explicitly trust the 524 received root certificate. 526 4.5 Application of Encryption to a PKI Message 528 There are occasions where a PKI request or response message must be 529 encrypted in order to prevent any information about the enrollment. 530 This section describes the means used to encrypt a PKI message. This 531 section is not applicable to a simple enrollment message. 533 Shrouding is obtained by wrapping the PKI message (a signedData object) 534 in a CMS EnvelopedData object. The nested content type in the 535 EnvelopedData is id-signedData. Note that this is different from S/MIME 536 where there is a MIME layer placed between the encrypted and signed data 537 objects. It is recommended that if an enveloped data layer is applied 538 to a PKI message, a second signing layer be placed outside of the 539 enveloped data layer. The following figure shows how this nesting would 540 be done: 542 Normal Option 1 Option 2 543 ------ -------- -------- 544 SignedData EnvelopedData SignedData 545 PKIData SignedData EnvelopedData 546 PKIData SignedData 547 PKIData 549 Options 1 and 2 provide the benefit of preventing leakage of sensitive 550 data by encrypting the information. LRAs may remove the enveloped data 551 wrapping, and replace or forward without further processing. 553 PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST 554 provided support for all three versions. 556 Alternatively, an authenticated, secure channel could exist between the 557 parties requiring encryption. Clients and servers MAYuse such channels 558 instead of the shrouding technique described above to provide secure, 559 private communication of PKI request and response messages. 561 5. Control Attributes 563 Control attributes are carried as part of both PKI requests and 564 responses. 566 Each control attribute is encoded as a unique Object Identifier followed 567 by that data for the control attribute. The encoding of the data is 568 based on the control attribute object identifier. Processing systems 569 would first detect the OID and process the corresponding attribute value 570 prior to processing the message body. 572 The following table lists the names, OID and syntactic structure for 573 each of the control attributes documented in this draft. 575 Control Attribute OID Syntax 576 ----------------- ---------- -------------- 577 cMCStatusInfo pkix-cmc 1 CMCStatusInfo 578 identification pkix-cmc 2 UTF8String 579 identityProof pkix-cmc 3 OCTET STRING 580 dataReturn pkix-cmc 4 OCTET STRING 581 transactionId pkix-cmc 5 INTEGER 582 senderNonce pkix-cmc 6 OCTET STRING 583 recipientNonce pkix-cmc 7 OCTET STRING 584 addExtensions pkix-cmc 8 AddExtensions 585 encryptedPOP pkix-cmc 9 EncryptedPOP 586 decryptedPOP pkix-cmc 10 DecryptedPOP 587 lraPOPWitness pkix-cmc 11 LraPOPWitness 588 keyArchival pkix-cmc 12 KeyArchival 589 keyRecoveryReq pkix-cmc 13 KeyRecoveryReq 590 keyRecoveryRsp pkix-cmc 14 KeyRecoveryRsp 591 getCert pkix-cmc 15 GetCert 592 getCRL pkix-cmc 16 GetCRL 593 revokeRequest pkix-cmc 17 RevokeRequest 594 regInfo pkix-cmc 18 OCTET STRING 595 responseInfo pkix-cmc 19 OCTET STRING 596 privateKey pkix-cmc 20 PrivateKeyInfo 597 QueryPending pkix-cmc 21 INTEGER 599 NOTE: It is expected that the number assignments will change in a later 600 draft to group items together according to usage and protocols. 602 5.1 CMC Status Info Control Attribute 604 The CMC status info control is used in full PKI Response messages to 605 return information on a client request. This statement uses the 606 following ASN.1 definition: 608 CMCStatusInfo ::= SEQUENCE { 609 cMCStatus CMCStatus, 610 bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, 611 statusString UTF8String OPTIONAL, 612 otherInfo CHOICE { 613 failInfo CMCFailInfo, 614 pendInfo PendInfo } OPTIONAL 615 } 617 PendInfo ::= SEQUENCE { 618 pendToken INTEGER, 619 pendTime GENERALIZEDTIME 620 } 622 cMCStatus is described in section 5.2 623 bodyList contains the list of body parts to which this status 624 information applies. 625 statusString contains a string with additional description 626 information. This string is human readable. 627 failInfo is described in section 5.3. It provides a detailed error 628 on what the failure was. This choice is present only if cMCStatus 629 is failed. 631 pendToken is the token to be used in the queryPending control 632 attribute. 633 pendTime contains the suggested time the server wants to be queried 634 about the status of the request. 636 If the cMCStatus field is success, the CMC Status Info Control MAY be 637 omitted unless the cMCStatus is the only item in the response message. 638 If no status exists for a certificate request or other item requiring 639 processing, then the value of success is to be assumed. 641 5.2 CMCStatus values 643 CMCStatus is a field in the CMCStatusInfo structure. This field 644 contains a code representing the success or failure of a specific 645 operation. CMCStatus has the ASN.1 structure of: 647 CMCStatus ::= INTEGER { 648 success (0), 649 -- you got exactly what you asked for 650 failed (2), 651 -- you don't get it, more information elsewhere in the 652 message 653 pending (3), 654 -- the request body part has not yet been processed, 655 -- requester is responsible to poll back on this 656 -- pending may only be return for certificate request 657 operations. 658 noSupport (4), 659 -- the requested operation is not supported 660 } 662 5.3 CMCFailInfo 664 CMCFailInfo conveys information relevant to the interpretation of a 665 failure condition. The CMCFailInfo has the following ASN.1 structure: 667 CMCFailInfo ::= INTEGER { 668 badAlg (0) 669 -- Unrecognized or unsupported algorithm 670 badMessageCheck (1) 671 -- integrity check failed 672 badRequest (2) 673 -- transaction not permitted or supported 674 badTime (3) 675 -- Message time field was not sufficiently close to the system 677 time 678 badCertId (4) 679 -- No certificate could be identified matching the provided 680 criteria 681 unsuportedExt (5) 682 -- A requested X.509 extension is not supported by the 683 recipient CA. 684 mustArchiveKeys (6) 685 - 686 -- Private key material must be supplied 688 badIdentity (7) 689 -- Identification Attribute failed to verify 690 popRequired (8) 691 -- Server requires a POP proof before issuing certificate 692 popFailed (9) 693 -- Server failed to get an acceptable POP for the request 694 noKeyReuse (10) 695 -- Server policy does not allow key re-use 696 internalCAError (11) 697 tryLater (12) 698 } 700 Additional failure reasons MAY be defined for closed environments with a 701 need. 703 5.4 Identification and Identity-Proof Control Attributes 705 Some CAs and LRAs require that a proof of identity be included in a 706 certification request. Many different ways of doing this exist with 707 different degrees of security and reliability. Most people are familiar 708 with the request of a bank to provide your mother's maiden name as a 709 form of identity proof. 711 CMC provides one method of proving the client's identity based on a 712 shared secret between the certificate requestor and the verifying 713 authority. If clients support full request messages, clients MUST 714 implement this method of identity proof. Servers SHOULD provide this 715 method or have a bilateral method of similar strength available. 717 The CMC method starts with an out-of-band transfer of a token (the 718 shared secret). The distribution of this token is beyond the scope of 719 this document. The client then uses this token for an identity proof as 720 follows: 722 1. The reqSequence fields of the PKIData object is the value to be 723 validated. 724 2. A SHA1 hash of the token is computed. 725 3. An HMAC-SHA1 value is then computed over the stream produced in Step 726 1, as described in [HMAC], using the hash of the token from Step 2 as 727 the shared secret value. 728 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value 729 of the identity-proof attribute. 731 When the server verifies the identity-proof attribute, it computes the 732 HMAC-SHA1 value in the same way and compares it to the identity-proof 733 attribute contained in the enrollment request. 735 If a server fails the verification of an identity-proof attribute and 736 the server returns a response message, the failInfo attribute MUST be 737 present in the response and MUST have a value of BADIDENTITY. 739 Optionally, servers may require the inclusion of the unprotected 740 identification attribution with an identity-proof attribute. The 741 identification attribute is intended to contain either a text string or 742 a numeric quantity, such as a random number, which assists the server in 743 locating the shared secret needed to validate the contents of the 744 identity-proof attribute. Numeric values MUST be converted to text 745 string representations prior to encoding as UTF8-STRINGs in this 746 attribute. If the identity field is included in the message, the 747 derivation of the shared secret in step 2 is altered so that the hash of 748 the concatenation of the token and the identity value are hashed rather 749 than just the token. 751 To facilitate one pass processing of a PKIData object, the identity 752 attribute SHOULD proceed the identity-proof attribute. 754 5.5 Data Return Control Attribute 756 The data return control attribute allows clients to send arbitrary data 757 (usually some type of internal state information) to the server and to 758 have the data returned as part of the enrollment response message. Data 759 placed in a data return statement is considered to be opaque to the 760 server. The same control is used for both requests and responses. If 761 the data return statement appears in an enrollment message, the server 762 MUST return it as part of the enrollment response message. 764 In the event that the information in the data return statement needs to 765 be confidential, it is expected that the client would apply some type of 766 encryption to the contained data. 768 An example of using this statement is for a client to place an 769 identifier marking the exact source of the private key material. This 770 might be the identifier of a hardware device containing the private key. 772 5.6 Add Extensions Control Attribute 774 The Add Extensions control attribute is used by LRAs in order to specify 775 additional extensions that are to be placed on certificates. This 776 attribute uses the following ASN.1 definition: 778 AddExtensions ::= SEQUENCE { 779 pkiDataReference INTEGER 780 certReferences SEQUENCE OF INTEGER, 781 extensions SEQUENCE OF Extension 782 } 784 The certReferences field is a list of references to one or more of the 785 payloads contained within a PKIData. Each element of the certReferences 786 sequence MUST be equal to either the bodyPartID of a 787 TaggedCertificationRequest or the certReqId of the CertRequest within a 788 CertReqMsg. By definition, the listed extensions are to be applied to 789 every element referenced in the certReferences sequence. 790 Servers are not required to be able to process every v3 X.509 extension 791 transmitted using this protocol, nor are they required to be able to 792 process other, private extensions. Servers are not required to put all 793 LRA-requested extensions into a certificate. Servers are permitted to 794 modify LRA-requested extensions. Servers MUST NOT alter an extension so 795 as to reverse the meaning of a client-requested extension. If a 796 certification request is denied due to the inability to handle a 797 requested extension and a response is returned, the server MUST return a 798 failInfo attribute with the value of UNSUPPORTEDEXT. 800 If multiple Add Extensions statements exist in an enrollment message, 801 the exact behavior is left up to the certificate issuer policy. However 802 it is recommended that the following policy be used on an extension by 803 extension basis: 805 1. If the conflict is within a single EnrollmentBody object, the 806 certificate request would be rejected with and error of BADREQUEST. 807 2. If the conflict is between different EnrollmentBody objects, the 808 outermost version of the extension would be used. 810 5.7 Transaction Management Control Attributes 812 Transaction management attributes are an optional portion of CMC. A 813 server does not need to implement this section to be compliant with CMC. 815 Transactions MAY be identified and tracked using a transaction 816 identifier. If used, clients generate transaction identifiers and 817 retain their value until the server responds with a message that 818 completes the transaction. Servers correspondingly include received 819 transaction identifiers in the response. 821 The transactionId attribute identifies a given transaction. It is used 822 between client and server to manage the state of an operation. It MAY be 823 included in service request messages. If included, responses MUST 824 included the transmitted value. A server MUST use only transactionIds 825 in the outermost PKIdata object. TransactionIds on inner PKIdata objects 826 are for intermediate entities. 828 Replay protection MAY be supported through the use of sender and 829 recipient nonces. If used, clients generate a nonce value and include 830 it in the request as a sender nonce. Servers return this value as 831 recipient nonce along their own value for sender nonce. A server MUST 832 use only nonces in the outermost PKIdata object. Nonces on inner PKIdata 833 objects are for intermediate entities. 835 The senderNonce and recipientNonce attribute can be used to provide 836 application-level replay prevention. They MAY be included in service 837 request messages. Originating messages include only a value for 838 senderNonce. If included, responses MUST include the transmitted value 839 of the previously received senderNonce as recipientNonce and include a 840 value for senderNonce. 842 If nonces are used, in the first message of a transaction, no 843 recipientNonce is transmitted; a senderNonce is instantiated by the 844 message originator and retained for later reference. The recipient of a 845 sender nonce reflects this value back to the originator as a 846 recipientNonce and includes it's own senderNonce. Upon receipt by the 847 transaction originator of this message, the originator compares the 848 value of recipientNonce to its retained value. If the values match, the 849 message can be accepted for further security processing. The received 850 value for senderNonce is also retained for inclusion in the next message 851 associated with the same transaction. 853 If a transaction originator includes a value for the senderNonce 854 attribute, responses MUST include this value as a value for recipient- 855 Nonce AND include a value for the SenderNonce attribute. 857 If a transaction originator includes a value for the transaction-id 858 attribute in a service request, responses MUST include this value as a 859 value for transaction-id attribute. 861 5.8 Proof-of-possession (POP) for encryption-only keys 863 Everything described in this section is optional to implement. Servers 864 MAY require this POP be used only if another POP method is unavailable. 865 Servers MAY reject all requests contained within a PKIData if any 866 required POP is missing for any element within the PKIData. 868 Many servers require proof that an entity requesting a certificate on a 869 public key actually possesses the corresponding private component of the 870 key pair. For keys that may be used as signature keys, signing the 871 certification request with the private key may serve as a POP on that 872 key pair. With keys that can only be used for encryption operations, 873 POP MUST be performed by forcing the client to decrypt a value. See 874 Section 5 of [CRMF] for a detailed discussion of POP. 876 By necessity, POP for encryption-only keys cannot be done in one round- 877 trip, since there are four distinct phases: 878 1. Client tells the server about the public component of a new 879 encryption key pair. 880 2. Server sends the client a POP challenge, encrypted with the presented 881 public encryption key, which the client must decrypt. 882 3. Client decrypts the POP challenge and sends it back to the server. 883 4. Server validates the decrypted POP challenge and continues processing 884 the certificate request. 886 CMC defines two different attributes. The first deals with the 887 encrypted challenge sent from the server to the user in step 2. The 888 second deals with the decrypted challenge sent from the client to the 889 server in step 3. 891 The encryptedPOP attribute is used to send the encrypted challenge from 892 the server to the client. As such, it is encoded as a tagged attribute 893 within the controlSequence of a ResponseBody. (Note that we assume that 894 the message sent in Step 1 above is an enrollment request and that the 895 response in step 2 is a Full Enrollment Response including a failureInfo 896 specifying that a POP is explicitly required, and providing the POP 897 challenge in the encryptedPOP attribute.) 899 EncryptedPOP ::= SEQUENCE { 900 bodyPartID INTEGER, 901 cms contentInfo, 902 thePOPAlgID AlgorithmIdentifier, 903 witnessAlgID AlgorithmIdentifier, 904 witness OCTET STRING 905 } 907 DecryptedPOP ::= SEQUENCE { 908 bodyPartID INTEGER, 909 thePOPAlgID AlgorithmIdentifier, 910 thePOP OCTET STRING 911 } 913 The encrypted POP algorithm works as follows: 915 1. The server generates a random value y and associates it with the 916 request. 917 2. The server returns the encrypted pop with the following fields set: 918 a. bodyPartID refers to the certificate request in the original 919 request message, 920 b. cms is an EnvelopedData object, the content type being id-data and 921 the content begin the value y. If the certificate request 922 contains a subject key identifier (SKI) extension, then the 923 recipient identifier SHOULD be the SKI. If the 924 issuerAndSerialNumber form is used, the IsserName MUST be encoded 925 as NULL and the SerialNumber as the bodyPartId of the certificate 926 request, 927 c. thePOPAlgID contains the algorithm to be used in computing the 928 return POP value, 929 d. witnessAlgID contains the hash algorithm used on y to create the 930 field witness, 931 e. witness contains the hashed value of y. 932 3. The client decrypts the cms field to obtain the value y. The client 933 computes H(y) using the witnessAlgID and compares to the value of 934 witness. If the values do not compare or the decryption is not 935 successful, the client MUST abort the enrollment process. 936 4. The client creates the decryptedPOP as part of a new PKIData message. 937 The fields in the decryptedPOP are: 938 a. bodyPartID contains the certificate request in the new enrollment 939 message, 940 b. thePOPAlgID is copied from the encryptedPOP, 941 c. thePOP contains the possession proof. This value is computed by 942 thePOPAlgID using the value y and request referenced in (4a). 943 5. The server then re-computes the value of thePOP from its cached value 944 of y and the request and compares to the value of thePOP. If the 945 values do not match, the server MUST NOT issue the certificate. The 946 server MAY re-issue a new challenge or MAY fail the request 947 altogether. 949 When defining the algorithms for thePOPAlgID and witnessAlgID care must 950 be taken to ensure that the result of witnessAlgID is not a useful value 951 to shortcut the computation with thePOPAlgID. Clients MUST implement 952 SHA-1 for witnessAlgID. Clients MUST implement HMAC-SHA1 for 953 thePOPAlgID. The value of y is used as the secret value in the HMAC 954 algorithm. If y is greater than 64 bytes, only the first 64 bytes of y 955 are used as the secret. 957 One potential problem with the algorithm above is the amount of state 958 that a CA needs to keep in order to verify the returned POP value. This 959 describes one of many possible ways of addressing the problem by 960 reducing the amount of state kept on the CA to a single (or small set) 961 of values. 963 1. Server generates random seed x, constant across all requests. (The 964 value of x would normally be altered on a regular basis and kept for 965 a short time afterwards.) 966 2. For request on public encryption key PK, server computes y = F(x,PK). 967 F can be, for example, HMAC-SHA1(x,PK). All that's important for 968 statelessness is that y be consistently computable with only known 969 state constant x and function F, other inputs coming from the cert 970 request structure. y should not be predictable based on knowledge of 971 PK, thus the use of a OWF like HMAC-SHA1. 973 5.9 LRA POP Witnesses Control Attribute 975 If an out-of-band POP is required for a certificate enrollment, an LRA 976 can be the entity that does the out-of-band POP rather than the CA. In 977 this case the LRA needs a way to inform the CA it has done the POP. 978 This control attribute has been created to address this issue. 980 The ASN.1 structure for the LRA POP witness is as follows: 982 LraPopWitness ::= SEQUENCE { 983 pkiDataBodyid INTEGER, 984 bodyIds SEQUENCE of INTEGER 985 } 987 The attribute contains a list of certificate requests for which the LRA 988 has performed an out-of-band authentication. The method of 989 authentication could be archival of private key material, challenge- 990 response or other means. 992 If a certificate server does not allow for an LRA to do the POP 993 verification, it returns an error of POPFAILURE. The CA MUST NOT start 994 a challenge-response to re-verify the POP itself. 996 5.10 Key Archival and Recovery 998 Everything described in this section is optional to implement. Servers 999 MAY require key archival of encryption keys as a condition of issuing a 1000 certificate for that encryption key pair. Servers MAY reject all 1001 requests contained within a PKIData if any required key archival message 1002 is missing for any element within the PKIData. 1004 There are four objects involved in key archival and recovery scenarios: 1006 1. The Key Archival control attribute, 1007 2. The Key Recovery Request control attribute, 1008 3. The Key Recovery Response control attribute, 1009 4. A ContentInfo containing private key material. 1011 It is assumed that a key recovery operation will only return previously- 1012 archive material. (That is, if an archival and recovery operation 1013 happen simultaneously, the newly archived key material is not returned 1014 as part of the recovery response.) 1016 The Key Recover Response control can also be used to implment off-client 1017 generation of encryption keys. A control statement containing the 1018 required fields for key generation is generated on the client as part of 1019 the enrollment request message. This is then sent up to the server and 1020 the server responds with a Key Recovery Response containing the newly 1021 generated key. The details of the request control statement not covered 1022 in this document and would be done on a bilateral basis. 1024 5.10.1 Key Archival Control Attribute 1026 The key archival control attribute has the following ASN.1 syntax: 1028 KeyArchival ::= SEQUENCE { 1029 reqBodyPartID INTEGER, 1030 cmsBodyPartID INTEGER, 1031 selectionCriteria OCTET STRING OPTIONAL 1032 } 1034 The reqBodyPartID is a reference to the payload within the enclosing 1035 PKIData that contains the certification request for the public key 1036 component of the encryption key pair. If multiple certification 1037 requests for the same public key are included in the PKIData, 1038 reqBodyPartID may point to any one of them. 1040 The cmsBodyPartID is a reference to the payload within the enclosing 1041 PKIData that contains the private key to be archived. The private key 1042 MUST be the private component corresponding to the public key referenced 1043 by reqBodyPartID. 1045 The selectionCriteria is optional information to be associated with the 1046 archived key material to facilitate key recovery of subsections of the 1047 archive database. 1049 5.10.2 Key Recovery Request Control Attribute 1051 The key recovery request control attribute has the following ASN.1 1052 syntax: 1054 KeyRecoveryReq ::= SEQUENCE { 1055 shroudIdentification ShroudIdentification, 1056 bulkEncryptionAlgID AlgorithmIdentifier, 1057 selectionCriterial OCTET STRING OPTIONAL 1058 } 1060 ShroudIdentification ::= CHOICE { 1061 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 1062 encryptionToken [1] AlgorithmIdentifier 1063 } 1065 The shroudIdentification structure defines the encryption method and key 1066 material that MUST be used in the recovery reply to encrypt the 1067 recovered private key material. Two methods of identification are 1068 currently defined. In the first, the public key component of an 1069 encryption key pair is explicitly included in the request. The second 1070 method derives a key from a known secret shared between client and 1071 server, such as an out-of-band token. This method is defined as an 1072 AlgorithmIdentifier as it must identify (a) the source of the key 1073 material, (b) any public/salt information, and (c) the method of 1074 deriving an encryption key using the request data, source key material 1075 and salt. Clients and servers MUST support the subject public key 1076 method. Clients and servers support of other methods is based on a 1077 bilateral agreement. 1079 The bulkEncryptionAlgID identifies the bulk encryption algorithm that 1080 MUST be used by the server to encrypt the key material. 1082 The selectionCriteria is optional information to be associated with the 1083 archived key material to facilitate key recovery of subsections of the 1084 archive database. If selectionCriteria is absent, all archived keys 1085 associated with the enrolling identity MUST be returned. 1087 Notice that the recovery request does not include an entity identifier. 1088 Determination of the identity comes from other locations: The name in a 1089 certificate request, the name in an identity proof, the name in the 1090 shrouding certificate or the name in the signing certificate on the 1091 containing SignedInfo structure. Servers need to establish a policy to 1092 be used by that server for identifying the entity doing the request 1093 operation. 1095 5.10.3 Key Recovery Response Control Attribute 1097 The key recovery response control attribute has the following ASN.1 1098 syntax: 1100 KeyRecoveryRsp ::= SEQUENCE { 1101 bodyPartID INTEGER, 1102 selectionCriteria OCTET STRING OPTIONAL 1103 } 1105 The bodyPartID identifies a TaggedContentInfo contained within the 1106 enclosing PKIData. The ContentInfo contains the requested private key 1107 material. 1109 The selectionCriteria is the optional information that was used to 1110 retrieve a subset of the keys archived in the archive database. 1112 5.10.4 Private Key Info Attribute 1113 The private key info attribute is imported from [PKCS8]. The encrypted 1114 private key info object is not imported as the only difference between 1115 it and an EncryptedData object is the inclusion of a version number in 1116 the ASN.1 structure. 1118 Private key information is tagged by the private key info attribute. 1119 This attribute has the ASN.1 structure: 1121 PrivateKeyInfo ::= SEQUENCE { 1122 version INTEGER, 1123 privateKeyAlgorithm AlgorithmIdentifier, 1124 privateKey OCTET STRING, 1125 attributes [0] IMPLICIT Attributes OPTIONAL 1126 } 1128 Attributes ::= SET OF Attribute 1130 version MUST be the value 0 1131 privateKeyAlgorithm contains the identifier for the private key 1132 object 1133 privateKey is an octet string whose contents is the private key and 1134 whose format is defined by the value of privateKeyAlgorithm. 1135 attributes is a set of attributes. These are extended information 1136 that is part of the private key information. 1138 We are defining the structures here to be used for two algorithms. 1140 5.10.4.1 D-H Private Keys 1142 When creating a PrivateKeyInfo for a D-H key, the following rules apply: 1143 1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The 1144 parameter for id-dh-private-number is DomainParameters (imported from 1145 [PKIXCERT]). 1146 2. The ASN structure for privateKey MUST be 1148 DH-PrivateKey ::= INTEGER 1150 3. attributes MUST be omitted. 1152 5.10.4.2 RSA Private Keys 1154 When creating a PrivateKeyInfo for an RSA key, the following rules 1155 apply: 1156 1. The privateKeyAlgorithm MUST be set to rsaEncryption. 1157 2. The ASN structure for privateKey MUST be RSAPrivateKey (defined in 1158 [PKCS1]) 1159 3. Attributes MUST be omitted. 1161 5.10.5 ContentInfo Objects for Private Key Material 1163 ContentInfo object that contain private key material MUST be one of 1164 EnvelopedData, EncryptedData or Data. Private key material placed in a 1165 Data ContentInfo MUST be encrypted through some other mechanism; it is 1166 beyond the scope of this document to specify that mechanism. 1168 The inner content of the EnvelopedData or EncryptedData is a 1169 ResponseBody. The private keys are then encoded as private key info 1170 control attributes. 1172 5.10.6 Control Flow 1174 Control flow for Key Archival is assumed to proceed as follows: 1175 1. Client retrieves an encryption certificate for the archiving server, 1176 so that key material to be archived may be encrypted to it. 1177 2. Client generates an encryption key pair. 1178 3. Client submits an enrollment request for the key pair. As part of 1179 the PKIData, the client includes: 1180 a. A certificate request (PKCS10 or CRMF) for the key pair, which 1181 include the public key component and a message identifier (either 1182 bodyPartID or certReqId), 1183 b. A Key Archival control attribute, which includes two message 1184 identifier references: 1185 i. The identifier of the certification request in (3a), and 1186 ii. The identifier of the ContentInfo in (3c). 1187 c. A ContentInfo containing inside it the private key material 1188 corresponding to the public key contained in the request in (3a) 1189 and encrypted using the public key from the certificate obtained 1190 in (1). 1191 4. Server receives the request, archives the key material, and issues 1192 certificates as appropriate. Server responds with an enrollment 1193 response containing the issued certificates. 1194 It is assumed that whatever mechanisms are used to identify the entity 1195 requesting certification also serve to identify the archiving party. 1197 Control flow for Key Recovery is assumed to proceed as follows: 1198 1. Client sends a Full Enrollment Request message containing the Key 1199 Recovery Request control attribute to the server. (The PKIData need 1200 contain only the Key Recovery Request attribute.) 1201 2. Server performs policy-based operations to determine whether the 1202 recovery request is valid. 1203 3. Assuming the request is indeed valid, the server sends back to the 1204 client a Full Enrollment Response containing: 1205 a. One or more Key Recovery Response control attributes. 1206 b. One or more Private Key attributes containing private key material 1207 as defined in section 5.10.4 above. 1208 4. Client processes the response and extracts private key material from 1209 the ContentInfo(s). 1211 The above control flow for key recovery assumes that the client 1212 possesses at least a previously-certified signature key, which is used 1213 to sign the Full Enrollment Request message. In the event of a 1214 catastrophic failure on the client resulting in loss of all client keys, 1215 generation and certification of a new signature key may occur 1216 simultaneously to a request for recovery of private encryption keys. 1218 Control flow for recovering from catastrophic failure may proceed as 1219 follows: 1220 1. Client generates a new signature key pair and creates a certification 1221 request for the public component of the new signature key. 1222 2. Client creates a Full Enrollment Request message containing: 1223 a. The certificate request from Step 1, 1224 b. A Key Recovery Request control attribute. 1225 The Full Enrollment Request message is signed using the private 1226 signature key generated as part of Step 1. Following Section 4.2, 1227 the signerInfo field of the signed message will contain a NULL issuer 1228 name an a serial number corresponding to the bodyPartID of the 1229 certificate request within the PKIData. Notice that as it is not 1230 possible for the client to prove identity within the PKI (because all 1231 certified key pairs have been lost), another form of proof-of- 1232 identity is required (such as use of the identification and 1233 identificationProof control attributes). 1234 3. Client sends the Full Enrollment Request to the server. 1235 4. Server performs policy-based operations on the request message to 1236 determine: 1237 a. Whether the certification request on the new signature key should 1238 be granted, and 1239 b. Whether the recovery request is valid. 1240 5. Assuming that both requests are valid, the server sends back to the 1241 client a Full Enrollment Response containing: 1242 a. A certificate for the signature key, corresponding to the 1243 certification request generated by the client. 1244 b. One or more Key Recovery Response control attributes. 1245 c. One or more Private Key attributes containing private key material 1246 as defined in section 3.4.8.4. 1247 6. Client processes the response and extracts private key material and 1248 certificates. 1250 5.11 Get Certificate Control Attribute 1252 The get certificate control attribute is used to retrieve previously 1253 issued certificates from a repository of certificates. A certificate 1254 server, an LRA or an independent service may provide this repository. 1255 The clients expected to use this facility are those operating in a 1256 resource-constrained environment. (An example of a resource-constrained 1257 client would be a low-end IP router that does not retain it's 1258 certificate in non-volatile memory.) 1260 CAs do not need to implement this control attribute to be compliant with 1261 CMC. 1263 The get certificate control attribute has the following ASN.1 structure: 1265 GetCert ::= SEQUENCE { 1266 issuerName GeneralName, 1267 serialNumber INTEGER } 1269 The service responding to the request will place the requested 1270 certificate in the certificates field of a SignedData object. If the 1271 get certificate attribute is the only control in a full enrollment 1272 message, the response would be a simple enrollment response. 1274 5.12 Get CRL Control Attribute 1276 The get CRL control attribute is used to retrieve CRLs from a repository 1277 of CRLs. A certificate server, an LRA or an independent service may 1278 provide this repository. The clients expected to use this facility are 1279 those where a fully deployed directory is either infeasible or 1280 undesirable. 1282 CAs do not need to implement this control attribute to be compliant with 1283 this specification. 1285 The get CRL control attribute has the following ASN.1 structure: 1287 GetCRL ::= SEQUENCE { 1288 issuerName Name, 1289 cRLName GeneralName OPTIONAL, 1290 time GeneralizedTime OPTIONAL, 1291 reasons ReasonFlags OPTIONAL } 1293 The fields in a GetCRL have the following meanings: 1295 issuerName is the value of the Issuer DN in the subject 1296 certificate. 1298 cRLName may be the value of CRLDistributionPoints in the subject 1299 certificate or equivalent value in the event the certificate does 1300 not contain such a value. 1302 time is used by the client to specify from among potentially 1303 several issues of CRL that one whose thisUpdate value is less than 1304 but nearest to the specified time. In the absence of a time 1305 component, the CA always returns with the most recent CRL. 1307 reasons is used to specify from among CRLs partitioned by 1308 revocation reason. Implementors should bear in mind that while a 1309 specific revocation request has a single CRLReason code--and 1310 consequently entries in the CRL would have a single CRLReason code 1311 value--a single CRL can aggregate information for one or more 1312 reasonFlags. 1314 A service responding to the request will place the requested CRL in the 1315 crls field of a SignedData object. If the get CRL attribute is the only 1316 control in a full enrollment message, the response would be a simple 1317 enrollment response. 1319 5.13 Revocation Request Control Attribute 1321 The revocation request control attribute is used to request that a 1322 certificate be revoked. 1324 The revocation request control attribute has the following ASN.1 syntax: 1326 RevRequest ::= SEQUENCE { 1327 issuerName Name, 1328 serialNumber INTEGER, 1329 reason CRLReason, 1330 sharedSecret OCTET STRING OPTIONAL, 1331 comment UTF8string OPTIONAL } 1333 For a revocation request to become a reliable object in the event of a 1334 dispute, a strong proof of originator authenticity is required. A 1335 Registration Authority's digital signature on the request can provide 1336 this proof for certificates within the scope of the LRA's revocation 1337 authority. The means by which an LRA is delegated this authority is a 1338 matter of operational policy. 1340 However, in the instance when an end-entity has lost use of their 1341 signature private key, it is impossible to produce a reliable digital 1342 signature. The RevRequest provides for the optional transmission from 1343 the end-entity to the CA of a shared secret that may be used as an 1344 alternative authenticator in the instance of loss of use. The 1345 acceptability of this practice is a matter of local security policy. 1347 Clients MUST provide the capability to produce a digitally signed 1348 revocation request control attribute. Clients SHOULD provide the 1349 capability produce an unsigned revocation request containing the end- 1350 entity's shared secret. If a client provides shared secret based self- 1351 revocation, the client MUST be capable of producing a revocation request 1352 containing the shared secret. 1354 The structure of an unsigned, shared secret based revocation request is 1355 a matter of local implementation. The shared secret does not need to be 1356 shrouded when sent in a revocation request. The shared secret has a one 1357 time use, that of causing the certificate to be revoked, and public 1358 knowledge of the shared secret after the certificate has been revoked is 1359 not a problem. Clients need to inform users that the same shared secret 1360 SHOULD NOT be used for multiple certificates. 1361 A full response message MUST be returned for a revocation request. 1363 5.14 Registration and Response Information Control Attributes 1365 The registration information control attribute is for clients and LRAs 1366 to pass additional information as part a PKI request. The registration 1367 information control attribute uses the ASN.1 structure: 1369 RegInfo ::= OCTET STRING 1371 The content of this data is based on bilateral agreement between the 1372 client and server. 1374 If a server (or LRA) needs to return information back to a requestor in 1375 response to registration info, then that data is returned as a response 1376 information control attribute. The content of the OCTET STRING for a 1377 response information is based on bilateral agreement between the client 1378 and server. 1380 5.15 Query Pending Control Attribute 1382 In some environments, process requirements for manual intervention or 1383 other identity checking can cause a delay in returning the certificate 1384 related to a certificate request. The query pending attribute allows for 1385 a client to query a server about the state of a pending certificate 1386 request. The server returns a token as part of the CMCStatusInfo 1387 attribute (in the otherInfo field). The client puts the token into the 1388 query pending attribute to identify the correct request to the server. 1390 The ASN.1 structure used by the query pending control attribute is: 1392 QueryPending ::= INTEGER 1394 If a server returns a pending state (the transaction is still pending), 1395 the otherInfo MAY be omitted. If it is not omitted then the same value 1396 MUST be returned (the token MUST NOT change during the request). 1398 6. Local Registration Agents 1400 This specification permits the use of Local Registration Agents (LRAs). 1401 An LRA sits between the client and the certification authority. From 1402 the client the LRA appears to be the certification authority and from 1403 the server the LRA appears to be a client. LRAs receive the enrollment 1404 messages, perform local processing and then forward onto certificate 1405 authorities. Some of the types of local processing that an LRA can 1406 perform include: 1408 - batching multiple enrollment messages together, 1409 - challenge/response POP proofs, 1410 - addition of private or standardized certificate extensions to all 1411 requests, 1412 - archival of private key material, 1413 - routing of requests to different CAs. 1415 When an LRA receives an enrollment message, it may either add its own 1416 layer of wrapping to produce a nested message or strip off the 1417 SignedData objects and produce a new non-nested message. LRAs SHOULD 1418 use nested messages rather than non-nested messages when possible. LRAs 1419 SHOULD NOT remove a signedData object wrapping layer if it was added by 1420 the original requesting entity. LRAs MUST NOT alter a certificate 1421 request body (PKCS #10 or CRMF) as any alteration invalidates the 1422 signature on the body and thus the POP for the private key. 1424 6.1 Nested Messages 1426 The expected procedure for an LRA to add information to an end entities 1427 certificate request message is to take the request and place it into a 1428 new PKIData object. The request is placed in the cmsSequence if it is a 1429 full pki message and the reqSequence field for a simple enrollment 1430 message. Control attributes, such as the add extension attribute, are 1431 then added to the controlSequence field of the PKIData object. An LRA 1432 can combine multiple messages into a single new PKIData object by 1433 placing more than one item in the sequence. 1435 An example of how this would look is illustrated by the following 1436 figure: 1438 SignedData (by LRA) 1439 PKIData 1440 controlSequence 1441 LRA added control statements 1442 reqSequence 1443 Zero or more Simple CertificationRequests from clients 1444 cmsSequence 1445 Zero or more Full PKI messages from clients 1446 SignedData (by client) 1447 PKIData 1449 6.2 Non-Nested Messages 1451 LRAs occasionally need to strip off the SignedData portion of a PKIData 1452 message. In this case it is necessary for the LRA to correctly merge 1453 the control statements in the submitted full PKI message with the 1454 changes to be made by this LRA. 1456 6.3 Multiple LRA Operation 1458 In some instances there may be more than one LRA in the validation path, 1459 in this case the second LRA in the sequence has two options for adding 1460 new control statements. The LRA may either add a new layer of wrapping 1461 (resulting in three levels of nested signedData objects) or it may strip 1462 the previous LRA's signature and create a new signedData object. In 1463 this case the LRA is responsible for merging together any control 1464 statements that the previous LRA may have added. 1466 7. Transport Wrapping 1468 Depending on the transport mechanism that is being used to deliver the 1469 enrollment request and responses different types of wrapping is 1470 required. We document for use three different wrapping items here. 1471 Mime wrapping is for transports that are natively mime based such as 1472 HTTP and E-mail. A binary file transport is defined since floppy disk 1473 transport is still very common. File transport can be done either bare 1474 (section 7.2) or MIME wrapped (section 7.1). 1476 7.1 MIME Wrapping 1478 MIME wrapping is defined for those environments that are MIME native. 1479 These include E-Mail based protocols as well as HTTP. 1481 The basic mime wrapping in this section is taken from [SMIMEV2] and 1482 [SMIMEV3]. Simple enrollment requests are encoded using the 1483 application/pkcs10 content type. A file name MUST be included either in 1484 a content type or content disposition statement. The extension for the 1485 file MUST be ".p10". 1487 Simple enrollment response messages MUST be encoded as content-type 1488 application/pkcs7-mime. An smime-type parameter MUST be on the content- 1489 type statement with a value of "certs-only." A file name with the ".p7c" 1490 extension MUST be specified as part of the content-type or content- 1491 disposition. 1493 Full enrollment request messages MUST be encoded as content-type 1494 application/pkcs7-mime. The smime-type parameter MUST be included with 1495 a value of "CMC-enroll". A file name with the ".p7m" extension MUST be 1496 specified as part of the content-type or content-disposition statement. 1498 Full enrollment response messages MUST be encoded as content-type 1499 application/pkcs7-mime. The smime-type parameter MUST be included with 1500 a value of "CMC-response." A file name with the ".p7m" extensions MUST 1501 be specified as part of the content-type or content-disposition. 1503 MIME TYPE File Extension SMIME-TYPE 1505 application/pkcs10 .p10 N/A 1506 (simple PKI request) 1508 application/pkcs7-mime .p7m CMC-request 1509 (full PKI request) 1511 application/pkcs7-mime .p7c certs-only 1512 (simple PKI response) 1514 applicication/pkcs7-mime .p7m CMC-response 1515 (full PKI response) 1517 7.2 File-Based Transport 1519 Enrollment messages and responses may also be transferred between 1520 clients and servers using file system-based mechanisms, such as when 1521 enrollment is performed for an off-line client. When files are used to 1522 transport binary, BER-encoded Full Enrollment Request and Repsonse 1523 messages, the following file type extensions SHOULD be used: 1525 Message Type File Extension 1527 Full PKI Request .crq 1529 Full PKI Response .crp 1531 7.3 Socket-Based Transport 1533 When enrollment messages and responses are sent over sockets, no 1534 wrapping is required. Messages SHOULD be sent in their binary, BER- 1535 encoded form. 1537 8. Interoperability 1539 8.1 Mandatory and Optional Algorithms 1541 CMC clients and servers MUST be capable of producing and processing 1542 message signatures using the Digital Signature Algorithm [DSA]. DSA 1543 signatures MUST be indicated by the DSA AlgorithmIdentifier value 1544 specified in section 7.2.2 of PKIXCERT. PKI clients and servers SHOULD 1545 also be capable of producing and processing RSA signatures as specified 1546 in section 7.2.1 of PKIXCERT. 1548 CMC clients and servers MUST be capable of protecting and accessing 1549 message encryption keys using the Diffie-Hellman (D-H) key exchange 1550 algorithm. D-H/3DES protection MUST be indicated by the D-H 1551 AlgorithmIdentifier value specified in CMS. PKI clients and servers 1552 SHOULD also be capable of producing and processing RSA key transport. 1553 When used for PKI messages, RSA key transport MUST be indicated as 1554 specified in section 7.2.1 of PKIXCERT. 1556 9. Security Considerations 1558 Initiation of a secure communications channel between an end-entity and 1559 a CA necessarily requires an out-of-band trust initiation mechanism. For 1560 example, a secure channel may be constructed between the end-entity and 1561 the CA via IPSEC or TLS. Many such schemes exist and the choice of any 1562 particular scheme for trust initiation is outside the scope of this 1563 document. Implementers of this protocol are strongly encouraged to 1564 consider generally accepted principles of secure key management when 1565 integrating this capability within an overall security architecture. 1567 Mechanisms for thwarting replay attacks may be required in particular 1568 implementations of this protocol depending on the operational 1569 environment. In cases where the CA maintains significant state 1570 information, replay attacks may be detectable without the inclusion of 1571 the optional nonce mechanisms. Implementers of this protocol need to 1572 carefully consider environmental conditions before choosing whether or 1573 not to implement the senderNonce and recipientNonce attributes described 1574 in section 5.7. Developers of state-constrained PKI clients are 1575 strongly encouraged to incorporate the use of these attributes. 1577 Under no circumstances should a signing key be archived. Doing so 1578 allows the archiving entity to potentially use the key for forging 1579 signatures. 1581 Due care must be taken prior to archiving keys. Once a key is given to 1582 an archiving entity, the archiving entity could use the keys in a way 1583 not conducive to the archiving entity. Users should be made especially 1584 aware that proper verification is made of the certificate used to 1585 encrypt the private key material. 1587 Clients and servers need to do some checks on cryptographic parameters 1588 prior to issuing certificates to make sure that weak parameters are not 1589 used. 1591 Small Group Attack 1593 10. Open Issues 1595 There appears to be a need to add one or more control statements to 1596 acknowledge the fact that key archival has been completed. (In fact, 1597 there may be a need for a general mechanism for an LRA to communicate 1598 certain process-related information to the next upstream LRA/CA.) 1600 11. Acknowledgments 1602 The authors would like to thank Jim Schaad and Brian LaMacchia for their 1603 work in developing and writing up many of the concepts presented in this 1604 document. The authors would also like to thank Alex Deacon for his 1605 contributions. 1607 12. References 1609 [CMS] R. Housley, "Cryptographic Message Syntax", 1610 draft-ietf-smime-cms-06.txt, June 1998 1612 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet X.509 1613 Certificate Request Message Format", 1614 draft-ietf-pkix-crmf-01.txt, May 1998 1616 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" 1618 [DH-SIG] H. Prafullchandra, J. Schaad, "Diffie-Hellman Signing 1619 Algorithm", draft-schaad-dhsign-00.txt, November 1998 1621 [PKCS7] B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5", 1622 RFC 2315, October 1997 1624 [PKCS10] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", 1625 RFC 2314, October 1997 1627 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet Public 1628 Key Infrastructure X.509 Certificate and CRL Profile", 1629 draft-ietf-pkix-ipki-part1-11.txt, September 1998 1631 [RFC 2119] "Key words for use in RFCs to Indicate Requirement 1632 Levels", RFC 2119 1634 [SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, 1635 "S/MIME Version 2 Message Specification", RFC 2311, March 1998 1637 [SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification", 1638 draft-ietf-smime-msg-05.txt, August 1998 1640 13. Author's Addresses 1642 Michael Myers 1643 VeriSign Inc. 1644 1390 Shorebird Way 1645 Mountain View, CA, 94019 1646 (650) 429-3402 1647 mmyers@verisign.com 1649 Xiaoyi Liu 1650 Cisco Systems 1651 170 West Tasman Drive 1652 San Jose, CA 95134 1653 (480) 526-7430 1654 xliu@cisco.com 1656 Barbara Fox 1657 Microsoft Corporation 1658 One Microsoft Way 1659 Redmond, WA 98052 1660 (425) 936-9542 1661 bfox@microsoft.com 1663 Jeff Weinstein 1664 Netscape Communications Corporation 1665 501 Middlefield Road 1666 Mountain View, CA 94043 1667 jsw@netscape.com 1669 Appendix A ASN.1 Module 1671 EnrollmentMessageSyntax 1672 { iso(1) identified-organization(3) dod(4) internet(1) 1673 security(5) mechansims(5) pkix(7) id-mod(0) TBD } 1675 DEFINITIONS IMPLICIT TAGS ::= 1676 BEGIN 1678 -- EXPORTS All -- 1679 -- The types and values defined in this module are exported for use 1680 -- in the other ASN.1 modules. Other applications may use them for 1681 -- their own purposes. 1683 IMPORTS 1685 -- Information Directory Framework (X.501) 1686 Name 1687 FROM InformationFramework { joint-iso-itu-t ds(5) 1688 modules(1) informationFramework(1) 3 } 1690 -- Directory Authentication Framework (X.509) 1691 AlgorithmIdentifier, AttributeCertificate, Certificate, 1692 CertificateList, CertificateSerialNumber 1693 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1694 module(1) authenticationFramework(7) 3 } 1696 -- PKIX Part 1 - Implicit 1697 GeneralName, CRLReason, ReasonFlags 1698 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 1699 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1700 id-pkix1-implicit-88(2)} 1702 -- PKIX Part 1 - Explicit 1703 SubjectPublicKeyInfo, Extension 1704 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 1705 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1706 id-pkix1-explicit-88(1)} 1708 -- Cryptographic Message Syntax 1709 ContentInfo, Attribute 1710 FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1} 1712 -- CRMF 1713 CertReqMsg 1714 FROM CRMF { }; 1716 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1717 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1719 id-pkix-cmc OBJECT IDENTIFIER ::= {id-pkix } 1721 id-dh-private-number OBJECT IDENTIFIER ::= {} 1723 id-identification OBJECT IDENTIFIER ::= {id-pkix-cmc 2} 1724 id-identityProof OBJECT IDENTIFIER ::= {id-pkix-cmc 3} 1725 id-dataReturn OBJECT IDENTIFIER ::= {id-pkix-cmc 4} 1726 id-transactionId OBJECT IDENTIFIER ::= {id-pkix-cmc 5} 1727 id-senderNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 6} 1728 id-recipientNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 7} 1729 id-regInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 18} 1730 id-responseInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 19} 1731 id-queryPending OBJECT IDENTIFIER ::= {id-pkix-cmc 21} 1733 -- This is the content type used for a request message in the 1734 protocol 1736 id-ct-PKIData OBJECT IDENTIFIER ::= { id-pkix } 1738 PKIData ::= SEQUENCE { 1739 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1740 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 1741 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1742 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1743 } 1745 TaggedAttribute ::= SEQUENCE { 1746 bodyPartID INTEGER, 1747 attrType OBJECT IDENTIFIER, 1748 attrValues SET OF AttributeValue 1750 } 1752 AttributeValue ::= ANY 1754 TaggedRequest ::= CHOICE { 1755 tcr [0] TaggedCertificationRequest, 1756 crm [1] CertReqMsg 1757 } 1759 TaggedCertificationRequest ::= SEQUENCE { 1760 bodyPartID INTEGER, 1761 certificationRequest CertificationRequest 1762 } 1764 CertificationRequest ::= SEQUENCE { 1765 certificationRequestInfo SEQUENCE { 1766 version INTEGER, 1767 subject Name, 1768 subjectPublicKeyInfo SEQUENCE { 1769 algorithm AlgorithmIdentifier, 1770 subjectPublicKey BIT STRING }, 1771 attributes [0] IMPLICIT SET OF Attribute }, 1772 signatureAlgorithm AlgorithmIdentifier, 1773 signature BIT STRING 1774 } 1776 TaggedContentInfo ::= SEQUENCE { 1777 bodyPartID INTEGER, 1778 contentInfo ContentInfo 1779 } 1781 OtherMsg ::= SEQUENCE { 1782 bodyPartID INTEGER, 1783 otherMsgType OBJECT IDENTIFIER, 1784 otherMsgValue ANY DEFINED BY otherMsgType } 1786 -- This defines the response message in the protocol 1787 id-ct-enrollResponse OBJECT IDENTIFIER ::= {id-pkix } 1789 ResponseBody ::= SEQUENCE { 1790 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1791 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1792 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1793 } 1795 -- Used to return status state in a response 1797 id-cMCStatusInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 1} 1799 CMCStatusInfo ::= SEQUENCE { 1800 cMCStatus CMCStatus, 1801 bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, 1802 statusString UTF8String OPTIONAL, 1803 otherInfo CHOICE { 1804 failInfo CMCFailInfo, 1805 pendInfo PendInfo } OPTIONAL 1806 } 1808 PendInfo ::= SEQUENCE { 1809 pendToken INTEGER, 1810 pendTime GENERALIZEDTIME 1811 } 1813 CMCStatus ::= INTEGER { 1814 success (0), 1815 -- you got exactly what you asked for 1816 failed (2), 1817 -- you don't get it, more information elsewhere in the message 1818 pending (3), 1819 -- the request body part has not yet been processed, 1820 -- requester is responsible to poll back on this 1821 noSupport (4) 1822 -- the requested operation is not supported 1823 } 1825 CMCFailInfo ::= INTEGER { 1826 badAlg (0), 1827 -- Unrecognized or unsupported algorithm 1828 badMessageCheck (1), 1829 -- integrity check failed 1830 badRequest (2), 1831 -- transaction not permitted or supported 1832 badTime (3), 1833 -- Message time field was not sufficiently close to the system 1834 time 1835 badCertId (4), 1836 -- No certificate could be identified matching the provided 1837 criteria 1838 unsuportedExt (5), 1839 -- A requested X.509 extension is not supported by the recipient 1840 CA. 1841 mustArchiveKeys (6), 1842 -- Private key material must be supplied 1843 badIdentity (7), 1844 -- Identification Attribute failed to verify 1845 popRequired (8), 1846 -- Server requires a POP proof before issuing certificate 1847 popFailed (9), 1848 -- Server failed to get an acceptable POP for the request 1849 noKeyReuse (10) 1850 -- Server policy does not allow key re-use 1851 internalCAError (11) 1852 tryLater (12) 1853 } 1855 -- Used for LRAs to add extensions to certificate requests 1856 id-addExtensions OBJECT IDENTIFIER ::= {id-pkix-cmc 8} 1857 AddExtensions ::= SEQUENCE { 1858 pkiDataReference INTEGER, 1859 certReferences SEQUENCE OF INTEGER, 1860 extensions SEQUENCE OF Extension 1861 } 1863 id-encryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 9} 1864 id-decryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 10} 1866 EncryptedPOP ::= SEQUENCE { 1867 bodyPartID INTEGER, 1868 cms ContentInfo, 1869 thePOPAlgID AlgorithmIdentifier, 1870 witnessAlgID AlgorithmIdentifier, 1871 witness OCTET STRING 1872 } 1874 DecryptedPOP ::= SEQUENCE { 1875 bodyPartID INTEGER, 1876 thePOPAlgID AlgorithmIdentifier, 1877 thePOP OCTET STRING 1878 } 1880 id-lraPOPWitness OBJECT IDENTIFIER ::= {id-pkix-cmc 11} 1882 LraPopWitness ::= SEQUENCE { 1883 pkiDataBodyid INTEGER, 1884 bodyIds SEQUENCE OF INTEGER 1885 } 1887 id-keyArchival OBJECT IDENTIFIER ::= {id-pkix-cmc 12} 1888 id-keyRecoveryReq OBJECT IDENTIFIER ::= {id-pkix-cmc 13} 1889 id-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-pkix-cmc 14} 1891 KeyArchival ::= SEQUENCE { 1892 reqBodyPartID INTEGER, 1893 cmsBodyPartID INTEGER, 1894 selectionCriteria OCTET STRING OPTIONAL 1895 } 1897 KeyRecoveryReq ::= SEQUENCE { 1898 shroudIdentification ShroudIdentification, 1899 bulkEncryptionAlgID AlgorithmIdentifier, 1900 selectionCriterial OCTET STRING OPTIONAL 1901 } 1903 ShroudIdentification ::= CHOICE { 1904 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 1905 encryptionToken [1] AlgorithmIdentifier 1906 } 1908 KeyRecoveryRsp ::= SEQUENCE { 1909 bodyPartID INTEGER, 1910 selectionCriteria OCTET STRING OPTIONAL 1912 } 1914 id-privateKey OBJECT IDENTIFIER ::= {id-pkix-cmc 20} 1916 PrivateKeyInfo ::= SEQUENCE { 1917 version INTEGER, 1918 privateKeyAlgorithm AlgorithmIdentifier, 1919 privateKey OCTET STRING, 1920 attributes [0] IMPLICIT Attributes OPTIONAL 1921 } 1923 Attributes ::= SET OF Attribute 1925 DH-PrivateKey ::= INTEGER 1927 -- 1928 id-getCert OBJECT IDENTIFIER ::= {id-pkix-cmc 15} 1930 GetCert ::= SEQUENCE { 1931 issuerName GeneralName, 1932 serialNumber INTEGER } 1934 id-getCRL OBJECT IDENTIFIER ::= {id-pkix-cmc 16} 1936 GetCRL ::= SEQUENCE { 1937 issuerName Name, 1938 cRLName GeneralName OPTIONAL, 1939 time GeneralizedTime OPTIONAL, 1940 reasons ReasonFlags OPTIONAL } 1942 id-revokeRequest OBJECT IDENTIFIER ::= {id-pkix-cmc 17} 1944 RevRequest ::= SEQUENCE { 1945 issuerName Name, 1946 serialNumber INTEGER, 1947 reason CRLReason, 1948 passphrase OCTET STRING OPTIONAL, 1949 comment UTF8String OPTIONAL } 1951 -- The following is used to request V3 extensions be added to a 1952 certificate 1954 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 1955 rsadsi(113549) pkcs(1) pkcs-9(9) 14} 1957 ExtensionReq ::= SEQUENCE OF Extension 1959 END