idnits 2.17.1 draft-ietf-pkix-cmc-04.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 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 27 longer pages, the longest (page 8) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 129 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == 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: 'PXIXCERT' is mentioned on line 369, but not defined == Missing Reference: 'DSA' is mentioned on line 1611, but not defined -- Looks like a reference, but probably isn't: '0' on line 2018 -- Looks like a reference, but probably isn't: '1' on line 2004 == Unused Reference: 'DH' is defined on line 1703, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 1712, but no explicit reference was found in the text == Unused Reference: 'PKCS8' is defined on line 1718, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-06 ** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC 4211) -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' == Outdated reference: A later version (-03) exists of draft-ietf-pkix-dhpop-00 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2313 (ref. 'PKCS1') (Obsoleted by RFC 2437) ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS7') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS8' ** Obsolete normative reference: RFC 2314 (ref. 'PKCS10') (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 2459 (ref. 'PKIXCERT') (Obsoleted by RFC 3280) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIMEV2') == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-05 -- No information found for draft-ietf-smime-x942- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'X942' Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 9 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 May 7, 1999 Jim Schaad (Microsoft) 4 expires in six months Jeff Weinstein 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 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To learn the current status of any Internet-Draft, please check the "1id- 29 abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document defines a Certificate Management protocol using CMS (CMC). 37 This protocol addresses two immediate needs within the Internet PKI 38 community: 40 1. The need for an interface to public key certification products and 41 services based on [CMS] and [PKCS10], and 42 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA- 43 signed certificates with Diffie-Hellman public keys. 45 A small number of additional services are defined to supplement the core 46 certificate request service. 48 Throughout this specification the term CMS is used to refer to both [CMS] 49 and [PKCS7]. For both signedData and envelopedData, CMS is a superset of 50 the PKCS7. In general, the use of PKCS7 in this document is aligned to 51 the Cryptographic Message Syntax [CMS] that provides a superset of the 52 PKCS7 syntax. The term CMC refers to this specification. 54 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in 55 this document are to be interpreted as described in [RFC 2119]. 57 1. Protocol Requirements 58 - The protocol is to be based as much as possible on the existing CMS, 59 PKCS#10 and CRMF specifications. 60 - The protocol must support the current industry practice of a PKCS#10 61 request followed by a PKCS#7 response as a subset of the protocol. 62 - The protocol needs to easily support the multi-key enrollment 63 protocols required by S/MIME and other groups. 64 - The protocol must supply a way of doing all operations in a single- 65 round trip. When this is not possible the number of round trips is to 66 be minimized. 67 - The protocol will be designed such that all key generation can occur 68 on the client. 69 - The mandatory algorithms must superset the required algorithms for 70 S/MIME. 71 - The protocol will contain POP methods. Optional provisions for 72 multiple-round trip POP will be made if necessary. 73 - The protocol will support deferred and pending responses to 74 certificate request for cases where external procedures are required to 75 issue a certificate. 76 - The protocol needs to support arbitrary chains of local registration 77 authorities as intermediaries between certificate requesters and 78 issuers. 80 2. Protocol Overview 82 An enrollment transaction in this specification is generally composed of 83 a single round trip of messages. In the simplest case an enrollment 84 request is sent from the client to the server and an enrollment response 85 is then returned from the server to the client. In some more complicated 86 cases, such as delayed certificate issuance and polling for responses, 87 more than one round trip is required. 89 This specification supports two different request messages and two 90 different response messages. 92 Public key certification requests can be based on either the PKCS10 or 93 CRMF object. The two different request messages are (a) the bare PKCS10 94 (in the event that no other services are needed), and (b) the PKCS10 or 95 CRMF message wrapped in a CMS encapsulation as part of a PKIData object. 97 Public key certification responses are based on the CMS signedData 98 object. The response may be either (a) a degenerate CMS signedData 99 object (in the event no other services are needed), or (b) a ResponseBody 100 object wrapped in a CMS signedData object. 102 No special services are provided for doing either renewal (new 103 certificates with the same key) or re-keying (new certificates on new 104 keys) of clients. Instead a renewal/re-key message looks the same as any 105 enrollment message, with the identity proof being supplied by existing 106 certificates from the CA. 108 A provision exists for Local Registration Authorities (LRAs) to 109 participate in the protocol by taking client enrollment messages, 110 wrapping them in a second layer of enrollment message with additional 111 requirements or statements from the LRA and then passing this new 112 expanded request on to the Certification Authority. 114 This specification makes no assumptions about the underlying transport 115 mechanism. The use of CMS is not meant to imply an email-based 116 transport. 118 Optional services available through this specification are transaction 119 management, replay detection (through nonces), deferred certificate 120 issuance, certificate revocation requests and certificate/CRL retrieval. 122 2.1 Terminology 124 There are several different terms, abbreviations and acronyms used in 125 this document that we define here for convenience and consistency of 126 usage: 128 "End-Entity" (EE) refers to the entity that owns a key pair and for whom 129 a certificate is issued. 130 "LRA" or "RA" refers to a (Local) Registration Authority. A registration 131 authority acts as an intermediary between an End-Entity and a 132 Certification Authority. Multiple RAs can exist between the End- 133 Entity and the Certification Authority. 134 "CA" refers to a Certification Authority. A Certification Authority is 135 the entity that performs the actual issuance of a certificate. 136 "Client" refers to an entity that creates a PKI request. In this 137 document both RAs and End-Entities can be clients. 138 "Server" refers to the entities that process PKI requests and create PKI 139 responses. CAs and RAs can be servers in this document. 140 "PKCS#10" refers the Public Key Cryptography Standard #10. This is one 141 of a set of standards defined by RSA Laboratories in the 1980s. 142 PKCS#10 defines a Certificate Request Message syntax. 143 "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. We 144 are using certificate request message format defined in this 145 document as part of our management protocol. 146 "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This 147 document provides for basic cryptographic services including 148 encryption and signing with and without key management. 149 "POP" is an acronym for "Proof of Possession". POP refers to a value 150 that can be used to prove that the private key corresponding to a 151 public key is in the possession and can be used by an end-entity. 152 "Transport wrapper" refers to the outermost CMS wrapping layer. 154 2.2 Protocol Flow Charts 156 Figure 1 shows the Simple Enrollment Request and Response messages. The 157 contents of these messages are detailed in Sections 4.1 and 4.3 below. 159 Simple PKI Request Simple PKI Response 160 ------------------------- -------------------------- 162 +----------+ +------------------+ 163 | PKCS #10 | | CMS "certs-only" | 164 +----------+--------------+ | message | 165 | | +------------------+------+ 166 | Certificate Request | | | 167 | | | CMS Signed Data, | 168 | Subject Name | | no signerInfo | 169 | Subject Public Key Info | | | 170 | (K_PUB) | | signedData contains one | 171 | Attributes | | or more certificates in | 172 | | | the "certificates" | 173 +-----------+-------------+ | portion of the | 174 | signed with | | signedData. | 175 | matching | | | 176 | K_PRIV | | encapsulatedContentInfo | 177 +-------------+ | is empty. | 178 | | 179 +--------------+----------+ 180 | unsigned | 181 +----------+ 183 Figure 1: Simple PKI Request and Response Messages 185 Full PKI Request Full PKI Response 186 ----------------------- ------------------------ 188 +----------------+ +----------------+ 189 | CMS signedData | | CMS signedData | 190 | object | | object | 191 +----------------+--------+ +----------------+--------+ 192 | | | | 193 | PKIData object | | ResponseBody object | 194 | | | | 195 | Sequence of: | | Sequence of: | 196 | * | | * | 197 | *| | * | 198 | * | | * | 199 | * | | | 200 | | | where * == zero or more | 201 | where * == zero or more | | | 202 | | | All certificates issued | 203 | Certificate requests | | as part of the response | 204 | are CRMF or PKCS#10 | | are included in the | 205 | objects. Attributes are | | "certificates" portion | 206 | (OID, ANY defined by | | of the signedData. | 207 | OID) pairs. | | | 208 | | +---------+---------------+ 209 +-------+-----------------+ | signed by the | 210 | signed (keypair | | CA or an LRA | 211 | used may be pre-| +---------------+ 212 | existing or | 213 | identified in | 214 | the request) | 215 +-----------------+ 216 Figure 2: Full PKI Request and Response Messages 218 Figure 2 shows the Full Enrollment Request and Response messages. The 219 contents of these messages are detailed in Sections 4.2 and 4.4 below. 221 3. Protocol Elements 223 This section covers each of the different elements that may be used to 224 construct enrollment request and enrollment response messages. Section 4 225 will cover how to build the enrollment request and response messages. 227 3.1 PKIData Object 229 The new content object PKIData has been defined for this protocol. This 230 new object is used as the body of the full PKI request message. The new 231 body is identified by: 233 id-ct-PKIData ::= {id-ct 2 } 235 The ASN.1 structure corresponding to this new content type is: 237 PKIData ::= SEQUENCE { 238 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 239 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 240 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 241 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 242 } 244 -- controlSequence consists of a sequence of control attributes. The 245 control attributes defined in this document are found in section 5. 246 As control sequences are defined by OIDs, other parties can define 247 additional control attributes. Unrecognized OIDs MUST result in no 248 part of the request being successfully processed. 250 -- reqSequence consists of a sequence of certificate requests. The 251 certificate requests can be either a CertificateRequest (PKCS10 252 request) or a CertReqMsg. Details on each of these request types are 253 found in sections 3.3.1 and 3.3.2 respectively. 255 -- cmsSequence consists of a sequence of [CMS] message objects. This 256 protocol only uses EnvelopedData, SignedData and EncryptedData. See 257 section 3.5 for more details. 259 -- otherMsgSequence allows for other arbitrary data items to be 260 placed into the enrollment protocol. The {OID, any} pair of values 261 allows for arbitrary definition of material. Data objects are placed 262 here while control objects are placed in the controlSequence field. 263 See section 3.6 for more details. 265 3.2 ResponseBody Object 266 The new content object ResponseBody has been defined for this protocol. 267 This new object is used as the body of the full PKI response message. 268 The new body is identified by: 270 id-ct-PKIResponse ::= {id-ct 3 } 272 The ASN.1 structure corresponding to this body content type is: 274 ResponseBody ::= SEQUENCE { 275 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 276 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 277 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 278 } 280 -- controlSequence consists of a sequence of control attributes. The 281 control attributes defined in this document are found in section 3.4. 282 Other parties can define additional control attributes. 284 -- cmsSequence consists of a sequence of [CMS] message objects. This 285 protocol only uses EnvelopedData, SignedData and EncryptedData. See 286 section 3.5 for more details. 288 -- otherMsgSequence allows for other arbitrary items to be placed 289 into the enrollment protocol. The {OID, any} pair of values allows 290 for arbitrary definition of material. Data objects are placed here 291 while control objects are placed in the controlSequence field. See 292 section 3.6 for more details. 294 3.3 Certification Requests (PKCS10/CRMF) 296 Certification Requests are based on either PKCS10 or CRMF messages. 297 Section 3.3.1 specifies mandatory and optional requirements for clients 298 and servers dealing with PKCS10 request messages. Section 3.3.2 299 specifies mandatory and optional requirements for clients and servers 300 dealing with CRMF request messages. 302 3.3.1 PKCS10 Request Body 304 Servers MUST be able to understand and process PKCS10 request bodies. 305 Clients MUST produce a PKCS10 request body when using the Simple 306 Enrollment Request message. Clients MAY produce a PKCS10 request body 307 when using the Full Enrollment Request message. 309 When producing a PKCS10 request body, clients MUST produce a PKCS10 310 message body containing a subject name and public key. Some 311 certification products are operated using a central repository of 312 information to assign subject names upon receipt of a public key for 313 certification. To accommodate this mode of operation, the subject name 314 in a CertificationRequest MAY be NULL, but MUST be present. CAs that 315 receive a CertificationRequest with a NULL subject name MAY reject such 316 requests. If rejected and a response is returned, the CA MUST respond 317 with the failInfo attribute of badRequest. 319 The client MAY incorporate one or more standard X.509 v3 extensions in 320 any PKCS10 request as an ExtensionReq attribute. An ExtensionReq 321 attribute is defined as 323 ExtensionReq ::= SEQUENCE OF Extension 325 where Extension is imported from [PKIXCERT] and ExtensionReq is 326 identified by {pkcs-9 14}. 328 Servers MUST be able to process all extensions defined in [PKIXCERT]. 329 Servers are not required to be able to process other V3 X.509 extensions 330 transmitted using this protocol, nor are they required to be able to 331 process other, private extensions. Servers are not required to put all 332 client-requested extensions into a certificate. Servers are permitted to 333 modify client-requested extensions. Servers MUST NOT alter an extension 334 so as to invalidate the original intent of a client-requested extension. 335 (For example changing key usage from key exchange to signing.) If a 336 certification request is denied due to the inability to handle a 337 requested extension and a response is returned, the server MUST respond 338 with the failInfo attribute of unsupportedExt. 340 3.3.2 CRMF Request Body 342 Servers MUST be able to understand and process CRMF request body. Clients 343 MAY produce a CRMF message body when using the Full Enrollment Request 344 message. 346 This draft imposes the following additional changes on the construction 347 and processing of CRMF messages: 349 - When CRMF message bodies are used in the Full Enrollment Request 350 message, each CRMF message MUST include both the subject and publicKey 351 fields in the CertTemplate. As in the case of PKCS10 requests, the 352 subject may be encoded as NULL, but MUST be present. 353 - In general, when both CRMF and CMC controls exist with equivalent 354 functionality, the CMC control SHOULD be used. The CMC control MUST 355 override any CRMF control. 356 - The regInfo field MUST NOT be used on a CRMF message. Equivalent 357 functionality is provided in the regInfo control attribute (section 358 5.12). 359 - The indirect method of proving POP is not supported in this protocol. 360 One of the other methods (including the direct method described in this 361 document) MUST be used instead if POP is desired. The value of 362 encrCert in SubsequentMessage MUST NOT be used. 363 - Since the subject and publicKeyValues are always present, the 364 POPOSigningKeyInput MUST NOT be used when computing the value for 365 POPSigningKey. 367 A server is not required to use all of the values suggested by the client 368 in the certificate template. Servers MUST be able to process all 369 extensions defined in [PXIXCERT]. Servers are not required to be able to 370 process other V3 X.509 extension transmitted using this protocol, nor are 371 they required to be able to process other, private extensions. Servers 372 are permitted to modify client-requested extensions. Servers MUST NOT 373 alter an extension so as to invalidate the original intent of a client- 374 requested extension. (For example change key usage from key exchange to 375 signing.) If a certificate request is denied due to the inability to 376 handle a requested extension, the server MUST respond with a failInfo 377 attribute of unsupportedExt. 379 3.3.3 Production of Diffie-Hellman Public Key Certification Requests 381 Part of a certification request is a signature over the request; Diffie- 382 Hellman is a key agreement algorithm and cannot be used to directly 383 produce the required signature object. [DH-POP] provides two ways to 384 produce the necessary signature value. This document also defines a 385 signature algorithm that does not provide a POP value, but can be used to 386 produce the necessary signature value. 388 3.3.3.1 No-Signature Signature Mechanism 390 Key management (encryption/decryption) private keys cannot always be used 391 to produce some type of signature value as they can be in a decrypt only 392 device. Certification requests require that the signature field be 393 populated. This section provides a signature algorithm specifically for 394 that purposes. The following object identifier and signature value are 395 used to identify this signature type: 397 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 399 NoSignatureValue ::= OCTET STRING 401 The parameters for id-alg-noSignature MUST be present and MUST be encoded 402 as NULL. NoSignatureValue contains the hash of the certification 403 request. It is important to realize that there is no security associated 404 with this signature type. If this signature type is on a certification 405 request and the Certification Authority policy requires proof-of- 406 possession of the private key, the POP mechanism defined in section 5.7 407 MUST be used. 409 3.3.3.2 Diffie-Hellman POP Signature 411 CMC compliant implementations MUST support section 5 of [DH-POP]. 413 3.3.3.3 Diffie-Hellman MAC signature 415 CMC compliant implementations MAY support section 4 of [DH-POP]. 417 3.4 Control Attributes 419 The overall control flow of how a message is processed in this document 420 is based on the control attributes. Each control attribute consists of 421 an object identifier and a value based on the object identifier. 423 Servers MUST fail the processing of an entire PKIData message if any 424 included control attribute is not recognized. The response MUST be the 425 error badRequest and bodyList MUST contain the bodyPartID of the invalid 426 or unrecognized control attribute. 428 The syntax of a control attribute is 430 TaggedAttribute ::= SEQUENCE { 431 bodyPartID BodyPartId, 432 attrType OBJECT IDENTIFIER, 433 attrValues SET OF AttributeValue 434 } 436 -- bodyPartId is a unique integer that is used to reference this 437 control attribute. The id of 0 is reserved for use as the reference 438 to the current PKIData object. 440 -- attrType is the OID defining the associated data in attrValues 442 -- attrValues contains the set of data values used in processing the 443 control attribute. 445 The set of control attributes that are defined by this draft are found in 446 section 5. 448 3.5 Content Info objects 450 The cmsSequence field of the PKIRequest and PKIResponse messages contains 451 zero or more tagged content info objects. The syntax for this structure 452 is 454 TaggedContentInfo ::= SEQUENCE { 455 bodyPartID BodyPartId, 456 contentInfo ContentInfo 457 } 459 -- bodyPartId is a unique integer that is used to reference this 460 content info object. The id of 0 is reserved for use as the 461 reference to the current PKIData object. 463 -- contentInfo contains a ContentInfo object (defined in [CMS]). 464 The three contents used in this location are SignedData, 465 EnvelopedData and Data. 467 EnvelopedData provides for shrouding of data. Data allows for general 468 transport of unstructured data. 470 The SignedData object from [CMS] is also used in this specification to 471 provide for authentication as well as serving as the general transport 472 wrapper of requests and responses. 474 3.5.1 Signed Data 476 The signedData object is used in two different locations when 477 constructing enrollment messages. The signedData object is used as a 478 wrapper for a PKIData as part of the enrollment request message. The 479 signedData object is also used as the outer part of an enrollment 480 response message. 482 For the enrollment response the signedData wrapper allows the server to 483 sign the returning data, if any exists, and to carry the certificates and 484 CRLs for the enrollment request. If no data is being returned beyond the 485 certificates, no signerInfo objects are placed in the signedData object. 487 3.5.2 Enveloped Data 489 EnvelopedData is the primary method of providing confidentiality for 490 sensitive information in this protocol. The protocol currently uses 491 EnvelopedData to provide encryption of an entire request (see section 492 4.5). The envelopedData object would also be used to wrap private key 493 material for key archival. 495 Servers MUST implement envelopedData according to [CMS]. There is an 496 ambiguity (about encrypting content types other than id-data) in the 497 PKCS7 specification that has lead to non-interoperability. 499 3.6 Other Message Bodies 501 The other message body portion of the message allows for arbitrary data 502 objects to be carried as part of a message. This is intended to contain 503 data that is not already wrapped in a CMS contentInfo object. The data 504 is ignored unless a control attribute references the data by bodyPartId. 506 OtherMsg ::= SEQUENCE { 507 bodyPartID BodyPartID, 508 otherMsgType OBJECT IDENTIFIER, 509 otherMsgValue ANY DEFINED BY otherMsgType } 511 -- bodyPartID contains the unique id of this object 513 -- otherMsgType contains the OID defining both the usage of this body 514 part and the syntax of the value associated with this body part 516 -- otherMsgValue contains the data associated with the message body 517 part. 519 3.7 Body Part Identifiers 521 Each element of a PKIData or PKIResponse message has an associated body 522 part identifier. The Body Part Identifier is a 4-octect integer encoded 523 in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in 524 the bodyPartId field of the other objects. The Body Part Identifier MUST 525 be unique within a single PKIData or PKIResponse object. Body Part 526 Identifiers can be duplicated in different layers (for example a CMC 527 message embedded within another). The Body Part Id of zero is reserved 528 to designate the current PKIData object. This value is used in control 529 attributes such as the Add Extensions Control in the pkiDataReference 530 field to refer to a request in the current PKIData object. 532 Some control attribute, such as the CMC Status Info attribute, will also 533 use Body Part Identifiers to refer to elements in the previous message. 534 This allows an error to be explicit about the attribute or request to 535 which the error applies. 537 4. PKI Messages 539 This section discusses the details of putting together the different 540 enrollment request and response messages. 542 4.1 Simple Enrollment Request 544 The simplest form of an enrollment request is a plain PKCS10 message. If 545 this form of enrollment request is used for a private key that is capable 546 of generating a signature, the PKCS10 MUST be signed with that private 547 key. If this form of the enrollment request is used for a D-H key, then 548 the D-H POP mechanism described in [DH-POP] MUST be used. 550 Servers MUST support the Simple Enrollment Request message. If the Simple 551 Enrollment Request message is used, servers MUST return the Simple 552 Enrollment Response message (see Section 4.3) if the enrollment request 553 is granted. If the enrollment request fails, the Full Enrollment 554 Response MAY be returned or no response MAY be returned. 556 Many advanced services specified in this draft are not supported by the 557 Simple Enrollment Request message. 559 4.2 Full PKI Request 561 The Full Enrollment Request provides the most functionality and 562 flexibility. Clients SHOULD use the Full Enrollment Request message when 563 enrolling. Servers MUST support the Full Enrollment Request message. An 564 enrollment response (full or simple as appropriate) MUST be returned to 565 all Full Enrollment Requests. 567 The Full Enrollment Request message consists of a PKIData object wrapped 568 in a signedData CMS object. The objects in the PKIData are ordered as 569 follows: 571 1. All Control Attributes, 572 2. All certification requests, 573 3. All CMS objects, 574 4. All other messages. 576 Each element in a Full Enrollment Request is identified by a Body Part 577 Identifer. If duplicate ids are found, the server MUST return the error 578 badRequest with a bodyPartID of 0. 580 The signedData object wrapping the PKIData may be signed either by the 581 private key material of the signature certification request, or by a 582 previously certified signature key. If the private key of a signature 583 certification request is being used, then: 584 a) the certification request containing the corresponding public key 585 MUST include a Subject Key Identifier extension request, 586 b) the subjectKeyIdentifier form of signerInfo MUST be used, and 587 c) the value of the subjectKeyIdentifier form of signerInfo MUST be the 588 Subject Key Identifier specified in the corresponding certification 589 request. 591 (The subjectKeyIdentifier form of signerInfo is used here because no 592 certificates have yet been issued for the signing key.) If the request 593 key is used for signing, there MUST be only one signerInfo object in the 594 signedData object. 596 When creating a message to renew a certificate, the following should be 597 taken into consideration: 599 1. The identification and identityProof control statements are not 600 required. The same information is provided by the use of an existing 601 certificate from the CA when signing the enrollment message. 602 2. CAs and LRAs may impose additional restrictions on the signing 603 certificate used. They may require that the most recently issued 604 signing certificate for an entity be used. 605 3. A renewal message may occur either by creating a new set of keys, or 606 by re-using an existing set of keys. Some CAs may prevent re-use of 607 keys by policy. In this case the CA MUST return NOKEYREUSE as the 608 failure code. 610 4.3 Simple Enrollment Response 612 Servers SHOULD use the simple enrollment response message whenever 613 possible. Clients MUST be able to process the simple enrollment response 614 message. The simple enrollment response message consists of a signedData 615 object with no signerInfo objects on it. The certificates requested are 616 returned in the certificate bag of the signedData object. 618 Clients MUST NOT assume the certificates are in any order. Servers SHOULD 619 include all intermediate certificates needed to form complete chains to 620 one or more self-signed certificates, not just the newly issued 621 certificate(s). The server MAY additionally return CRLs in the CRL bag. 622 Servers MAY include the self-signed certificates. Clients MUST NOT 623 implicitly trust included self-signed certificate(s) merely due to its 624 presence in the certificate bag. In the event clients receive a new self- 625 signed certificate from the server, clients SHOULD provide a mechanism to 626 enable the user to explicitly trust the certificate. 628 4.4 Full PKI Response 630 Servers MUST return full PKI response messages if a) a full PKI request 631 message failed or b) additional services other than returning 632 certificates are required. Servers MAY return full PKI responses with 633 failure information for simple PKI requests. Following section 4.3 above, 634 servers returning only certificates and a success status to the client 635 SHOULD use the simple PKI response message. 637 Clients MUST be able to process a full PKI response message. 639 The full enrollment response message consists of a signedData object 640 encapsulating a responseBody object. In a responseBody object all 641 Control Attributes MUST precede all CMS objects. The certificates 642 granted in an enrollment response are returned in the certificates field 643 of the immediately encapsulating signedData object. 645 Clients MUST NOT assume the certificates are in any order. Servers SHOULD 646 include all intermediate certificates needed to form complete chains one 647 ore more self-signed certificates, not just the newly issued 648 certificate(s). The server MAY additionally return CRLs in the CRL bag. 649 Servers MAY include the self-signed certificates. Clients MUST NOT 650 implicitly trust included self-signed certificate(s) merely due to its 651 presence in the certificate bag. In the event clients receive a new self- 652 signed certificate from the server, clients SHOULD provide a mechanism to 653 enable the user to explicitly trust the certificate. 655 4.5 Application of Encryption to a PKI Message 657 There are occasions where a PKI request or response message must be 658 encrypted in order to prevent any information about the enrollment from 659 being accessible to unauthorized entities. This section describes the 660 means used to encrypt a PKI message. This section is not applicable to a 661 simple enrollment message. 663 Confidentiality is provided by wrapping the PKI message (a signedData 664 object) in a CMS EnvelopedData object. The nested content type in the 665 EnvelopedData is id-signedData. Note that this is different from S/MIME 666 where there is a MIME layer placed between the encrypted and signed data 667 objects. It is recommended that if an enveloped data layer is applied to 668 a PKI message, a second signing layer be placed outside of the enveloped 669 data layer. The following figure shows how this nesting would be done: 671 Normal Option 1 Option 2 672 ------ -------- -------- 673 SignedData EnvelopedData SignedData 674 PKIData SignedData EnvelopedData 675 PKIData SignedData 676 PKIData 678 Options 1 and 2 provide the benefit of preventing leakage of sensitive 679 data by encrypting the information. LRAs can remove the enveloped data 680 wrapping, and replace or forward without further processing. Section 6 681 contains more information about LRA processing. 683 PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST 684 provided support for all three versions. 686 Alternatively, an authenticated, secure channel could exist between the 687 parties requiring encryption. Clients and servers MAY use such channels 688 instead of the technique described above to provide secure, private 689 communication of PKI request and response messages. 691 5. Control Attributes 693 Control attributes are carried as part of both PKI requests and 694 responses. Each control attribute is encoded as a unique Object 695 Identifier followed by that data for the control attribute. The encoding 696 of the data is based on the control attribute object identifier. 697 Processing systems would first detect the OID and process the 698 corresponding attribute value prior to processing the message body. 700 The following table lists the names, OID and syntactic structure for each 701 of the control attributes documented in this draft. 703 Control Attribute OID Syntax 704 ----------------- ---------- -------------- 705 cMCStatusInfo pkix-cmc 1 CMCStatusInfo 706 identification pkix-cmc 2 UTF8String 707 identityProof pkix-cmc 3 OCTET STRING 708 dataReturn pkix-cmc 4 OCTET STRING 709 transactionId pkix-cmc 5 INTEGER 710 senderNonce pkix-cmc 6 OCTET STRING 711 recipientNonce pkix-cmc 7 OCTET STRING 712 addExtensions pkix-cmc 8 AddExtensions 713 encryptedPOP pkix-cmc 9 EncryptedPOP 714 decryptedPOP pkix-cmc 10 DecryptedPOP 715 lraPOPWitness pkix-cmc 11 LraPOPWitness 716 getCert pkix-cmc 15 GetCert 717 getCRL pkix-cmc 16 GetCRL 718 revokeRequest pkix-cmc 17 RevokeRequest 719 regInfo pkix-cmc 18 OCTET STRING 720 responseInfo pkix-cmc 19 OCTET STRING 721 QueryPending pkix-cmc 21 OCTET STRING 722 idPOPLinkRandom pkix-cmc 22 OCTET STRING 723 idPOPLinkWitness pkix-cmc 23 OCTET STRING 724 idConfirmCertAcceptance pkix-cmc 24 CMCCertId 726 5.1 CMC Status Info Control Attribute 728 The CMC status info control is used in full PKI Response messages to 729 return information on a client request. Servers MAY emit multiple CMC 730 status info controls referring to a single body part. Clients MUST be 731 able to deal with multiple CMC status info controls in a response 732 message. This statement uses the following ASN.1 definition: 734 CMCStatusInfo ::= SEQUENCE { 735 cMCStatus CMCStatus, 736 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, 737 statusString UTF8String OPTIONAL, 738 otherInfo CHOICE { 739 failInfo CMCFailInfo, 740 pendInfo PendInfo } OPTIONAL 741 } 742 PendInfo ::= SEQUENCE { 743 pendToken OCTET STRING, 744 pendTime GeneralizedTime 745 } 747 -- cMCStatus is described in section 5.1.1 749 -- bodyList contains the list of body parts in the request message 750 to which this status information applies. If an error is being 751 returned for a simple enrollment message, body list will contain a 752 single integer of value '1'. 754 -- statusString contains a string with additional description 755 information. This string is human readable. 757 -- failInfo is described in section 5.1.2. It provides a detailed 758 error on what the failure was. This choice is present only if 759 cMCStatus is failed. 761 -- pendToken is the token to be used in the queryPending control 762 attribute. 764 -- pendTime contains the suggested time the server wants to be 765 queried about the status of the request. 767 If the cMCStatus field is success, the CMC Status Info Control MAY be 768 omitted unless it is only item in the response message. If no status 769 exists for a certificate request or other item requiring processing, then 770 the value of success is to be assumed. 772 5.1.1 CMCStatus values 774 CMCStatus is a field in the CMCStatusInfo structure. This field contains 775 a code representing the success or failure of a specific operation. 776 CMCStatus has the ASN.1 structure of: 778 CMCStatus ::= INTEGER { 779 success (0), 780 -- request was granted 781 -- reserved (1), 782 -- not used, defined where the original structure was defined 783 failed (2), 784 -- you don't get what you want, more information elsewhere in 785 the message 786 pending (3), 787 -- the request body part has not yet been processed, 788 -- requester is responsible to poll back on this 789 -- pending may only be return for certificate request 790 operations. 791 noSupport (4), 792 -- the requested operation is not supported 793 confirmRequired (5) 794 -- conformation using the idConfirmCertAcceptance control is 795 required 796 -- before use of certificate 797 } 799 5.1.2 CMCFailInfo 801 CMCFailInfo conveys information relevant to the interpretation of a 802 failure condition. The CMCFailInfo has the following ASN.1 structure: 804 CMCFailInfo ::= INTEGER { 805 badAlg (0) 806 -- Unrecognized or unsupported algorithm 807 badMessageCheck (1) 808 -- integrity check failed 809 badRequest (2) 810 -- transaction not permitted or supported 811 badTime (3) 812 -- Message time field was not sufficiently close to the system 813 time 814 badCertId (4) 815 -- No certificate could be identified matching the provided 816 criteria 817 unsuportedExt (5) 818 -- A requested X.509 extension is not supported by the 819 recipient CA. 820 mustArchiveKeys (6) 821 -- Private key material must be supplied 822 badIdentity (7) 823 -- Identification Attribute failed to verify 824 popRequired (8) 825 -- Server requires a POP proof before issuing certificate 826 popFailed (9) 827 -- POP processing failed 828 noKeyReuse (10) 829 -- Server policy does not allow key re-use 830 internalCAError (11) 831 tryLater (12) 832 } 834 Additional failure reasons MAY be defined for closed environments with a 835 need. 837 5.2 Identification and IdentityProof Control Attributes 839 Some CAs and LRAs require that a proof of identity be included in a 840 certification request. Many different ways of doing this exist with 841 different degrees of security and reliability. Most people are familiar 842 with the request of a bank to provide your mother's maiden name as a form 843 of identity proof. 845 CMC provides one method of proving the client's identity based on a 846 shared secret between the certificate requestor and the verifying 847 authority. If clients support full request messages, clients MUST 848 implement this method of identity proof. Servers MUST provide this 849 method and MAY also have a bilateral method of similar strength 850 available. 852 The CMC method starts with an out-of-band transfer of a token (the shared 853 secret). The distribution of this token is beyond the scope of this 854 document. The client then uses this token for an identity proof as 855 follows: 857 1. The reqSequence field of the PKIData object (encoded exactly as it 858 appears in the request message including the sequence type and length) 859 is the value to be validated. 860 2. A SHA1 hash of the token is computed. 861 3. An HMAC-SHA1 value is then computed over the value produced in Step 1, 862 as described in [HMAC], using the hash of the token from Step 2 as the 863 shared secret value. 864 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value 865 of the identityProof attribute. 867 When the server verifies the identityProof attribute, it computes the 868 HMAC-SHA1 value in the same way and compares it to the identityProof 869 attribute contained in the enrollment request. 871 If a server fails the verification of an identityProof attribute and the 872 server returns a response message, the failInfo attribute MUST be present 873 in the response and MUST have a value of badIdentity. 875 Optionally, servers MAY require the inclusion of the unprotected 876 identification attribute with an identification attribute. The 877 identification attribute is intended to contain either a text string or a 878 numeric quantity, such as a random number, which assists the server in 879 locating the shared secret needed to validate the contents of the 880 identityProof attribute. Numeric values MUST be converted to text string 881 representations prior to encoding as UTF8-STRINGs in this attribute. If 882 the identification control attribute is included in the message, the 883 derivation of the shared secret in step 2 is altered so that the hash of 884 the concatenation of the token and the identity value are hashed rather 885 than just the token. 887 5.2.1 Hardware Shared Secret Token Generation 889 The shared secret between the end-entity and the identity verify is 890 sometimes transferred using a hardware device that generates a series of 891 tokens based on some shared secret value. The user can therefore prove 892 their identity by transferring this token in plain text along with a name 893 string. The above protocol can be used with a hardware shared-secret 894 token generation device by the following modifications: 896 1. The identitification attribute MUST be included and MUST contain the 897 hardware-generated token. 899 2. The shared secret value used above is the same hardware-generated 900 token. 901 3. All certification requests MUST have a subject name and the subject 902 name MUST contain the fields required to identify the holder of the 903 hardware token device. 905 5.3 Linking Identity and POP Information 907 In a PKI Full Request message identity information about the 908 creator/author of the message is carried in the signature of the CMS 909 SignedData object containing all of the certificate requests. Proof-of- 910 possession information for key pairs requesting certification, however, 911 is carried separately for each PKCS#10 or CRMF message. (For keys 912 capable of generating a digital signature, the POP is provided by the 913 signature on the PKCS#10 or CRMF request. For encryption-only keys the 914 controls described in Section 5.7 below are used.) In order to prevent 915 substitution-style attacks we must guarantee that the same entity 916 generated both the POP and proof-of-identity information. 918 This section describes two mechanisms for linking identity and POP 919 information: witness values cryptographically derived from the shared- 920 secret (Section5.3.1) and shared-secret/subject DN matching (Section 921 5.3.2). Clients and servers MUST support the witness value technique. 922 Clients and servers MAY support shared-secret/subject DN matching or 923 other bilateral techniques of similar strength. The idea behind both 924 mechanisms is to force the client to sign some data into each certificate 925 request that can be directly associated with the shared-secret; this will 926 defeat attempts to include certificate requests from different entities 927 in a single Full PKI Request message. 929 5.3.1 Witness values derived from the shared-secret 931 The first technique for doing identity-POP linking works by forcing the 932 client to include a piece of information cryptographically-derived from 933 the shared-secret token as a signed extension within each certificate 934 request (PKCS#10 or CRMF) message. This technique is useful if null 935 subject DNs are used (because, for example, the server can generate the 936 subject DN for the certificate based only on the shared secret). 937 Processing begins when the client receives the shared-secret token out- 938 of-band from the server. The client then computes the following values: 940 1. The client generates a random byte-string, R, which SHOULD be at 941 least 512 bits in length. 942 2. A SHA1 hash of the token is computed. 943 3. An HMAC-SHA1 value is then computed over the random value produced 944 in Step 1, as described in [HMAC], using the hash of the token from 945 Step 2 as the shared secret. 946 4. The random value produced in Step 1 is encoded as the value of an 947 idPOPLinkRandom control attribute. This control attribute MUST be 948 included in the Full PKI Request message. 949 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value of 950 an idPOPLinkWitness extension to the certificate request. 952 a. For CRMF, idPOPLinkWitness is included in the controls section 953 of the CertRequest structure. 954 b. For PKCS#10, idPOPLinkWitness is included in the attributes 955 section of the CertificationRequest structure. 957 Upon receipt, servers MUST verify that each certificate request contains 958 a copy of the idPOPLinkWitness and that its value was derived in the 959 specified manner from the shared secret and the random string included in 960 the idPOPLinkRandom control attribute. 962 5.3.2 Shared-secret/subject DN matching 964 The second technique for doing identity-POP linking is to link a 965 particular subject distinguished name (subject DN) to the shared-secrets 966 that are distributed out-of-band and to require that clients using the 967 shared-secret to prove identity include that exact subject DN in every 968 certificate request. It is expected that many client-server connections 969 using shared-secret based proof-of-identity will use this mechanism. (It 970 is common not to omit the subject DN information from the certificate 971 request messages.) 973 When the shared secret is generated and transferred out-of-band to 974 initiate the registration process (Section 5.2), a particular subject DN 975 is also associated with the shared secret and communicated to the client. 976 (The subject DN generated MUST be unique per entity in accordance with CA 977 policy; a null subject DN cannot be used. A common practice could be to 978 place the identification value as part of the subject DN.) When the 979 client generates the Full PKI Request message, it MUST use these two 980 pieces of information as follows: 982 1. The client MUST include the specific subject DN that it received 983 along with the shared secret as the subject name in every 984 certificate request (PKCS#10 and/or CRMF) in the Full PKI Request. 985 The subject names in the requests MUST NOT be null. 986 2. The client MUST include the identityProof control attribute 987 (Section 5.2), derived from the shared secret, in the Full PKI 988 Request. 990 The server receiving this message MUST (a) validate the identityProof 991 control attribute and then, (b) check that the subject DN included in 992 each certificate request matches that associated with the shared secret. 993 If either of these checks fails the certificate request MUST be rejected. 995 5.3.3 Renewal and Re-Key Messages 997 In a renewal or re-key message, the subject DN in (a) the certificate 998 referenced by the CMS SignerInfo object, and (b) all certificate requests 999 within the request message MUST match according to the standard name 1000 match rules described in [PKIXCERT]. 1002 5.4 Data Return Control Attribute 1003 The data return control attribute allows clients to send arbitrary data 1004 (usually some type of internal state information) to the server and to 1005 have the data returned as part of the enrollment response message. Data 1006 placed in a data return statement is considered to be opaque to the 1007 server. The same control is used for both requests and responses. If 1008 the data return statement appears in an enrollment message, the server 1009 MUST return it as part of the enrollment response message. 1011 In the event that the information in the data return statement needs to 1012 be confidential, it is expected that the client would apply some type of 1013 encryption to the contained data, but the details of this are outside the 1014 scope of this specification. 1016 An example of using this feature is for a client to place an identifier 1017 marking the exact source of the private key material. This might be the 1018 identifier of a hardware device containing the private key. 1020 5.5 Add Extensions Control Attribute 1022 The Add Extensions control attribute is used by LRAs in order to specify 1023 additional extensions that are to be placed on certificates. This 1024 attribute uses the following ASN.1 definition: 1026 AddExtensions ::= SEQUENCE { 1027 pkiDataReference BodyPartID 1028 certReferences SEQUENCE OF BodyPartID, 1029 extensions SEQUENCE OF Extension 1030 } 1032 -- pkiDataReference field contains the body part id of the embedded 1033 request message. 1035 -- certReferences field is a list of references to one or more of 1036 the payloads contained within a PKIData. Each element of the 1037 certReferences sequence MUST be equal to either the bodyPartID of a 1038 TaggedCertificationRequest or the certReqId of the CertRequest 1039 within a CertReqMsg. By definition, the listed extensions are to 1040 be applied to every element referenced in the certReferences 1041 sequence. If a request corresponding to bodyPartID cannot be found, 1042 the error badRequest is returned referencing this control attribute. 1044 -- extensions field contains the sequence of extensions to be 1045 applied to the referenced certificate requests. 1047 Servers MUST be able to process all extensions defined in [PKIXCERT]. 1048 Servers are not required to be able to process every V3 X.509 extension 1049 transmitted using this protocol, nor are they required to be able to 1050 process other, private extensions. Servers are not required to put all 1051 LRA-requested extensions into a certificate. Servers are permitted to 1052 modify LRA-requested extensions. Servers MUST NOT alter an extension so 1053 as to reverse the meaning of a client-requested extension If a 1054 certification request is denied due to the inability to handle a 1055 requested extension and a response is returned, the server MUST return a 1056 failInfo attribute with the value of unsupportedExt. 1058 If multiple Add Extensions statements exist in an enrollment message, the 1059 exact behavior is left up to the certificate issuer policy. However it 1060 is recommended that the following policy be used. These rules would be 1061 applied to individual extensions within an Add Extensions control 1062 attribute (as opposed to an "all or nothing" approach). 1064 1. If the conflict is within a single PKIData object, the certificate 1065 request would be rejected with an error of badRequest. 1066 2. If the conflict is between different PKIData objects, the outermost 1067 version of the extension would be used (allowing an LRA to override 1068 the extension requested by the end-entyt). 1070 5.6 Transaction Management Control Attributes 1072 Transactions are identified and tracked using a transaction identifier. 1073 If used, clients generate transaction identifiers and retain their value 1074 until the server responds with a message that completes the transaction. 1075 Servers correspondingly include received transaction identifiers in the 1076 response. 1078 The transactionId attribute identifies a given transaction. It is used 1079 between client and server to manage the state of an operation. Clients 1080 MAY include a transactionID attribute in request messages. If the 1081 original request contains a transactionID attribute, all subsequent 1082 request and response messages MUST include the same transactionID 1083 attribute. A server MUST use only transactionIds in the outermost 1084 PKIdata object. TransactionIds on inner PKIdata objects are for 1085 intermediate entities. 1087 Replay protection can be supported through the use of sender and 1088 recipient nonces. If nonces are used, in the first message of a 1089 transaction, no recipientNonce is transmitted; a senderNonce is 1090 instantiated by the message originator and retained for later reference. 1091 The recipient of a sender nonce reflects this value back to the 1092 originator as a recipientNonce and includes it's own senderNonce. Upon 1093 receipt by the transaction originator of this message, the originator 1094 compares the value of recipientNonce to its retained value. If the 1095 values match, the message can be accepted for further security 1096 processing. The received value for senderNonce is also retained for 1097 inclusion in the next message associated with the same transaction. 1099 The senderNonce and recipientNonce attribute can be used to provide 1100 application-level replay prevention. Clients MAY include a senderNonce in 1101 the initial request message. Originating messages include only a value 1102 for senderNonce. If a message includes a senderNonce, the response MUST 1103 include the transmitted value of the previously received senderNonce as 1104 recipientNonce and include new value for senderNonce. A server MUST use 1105 only nonces in the outermost PKIdata object. Nonces on inner PKIdata 1106 objects are for intermediate entities. 1108 5.7 Proof-of-possession (POP) for encryption-only keys 1109 Everything described in this section is optional to implement, for both 1110 servers and clients. Servers MAY require this POP method be used only if 1111 another POP method is unavailable. Servers SHOULD reject all requests 1112 contained within a PKIData if any required POP is missing for any element 1113 within the PKIData. 1115 Many servers require proof that an entity requesting a certificate for a 1116 public key actually possesses the corresponding private component of the 1117 key pair. For keys that can be used as signature keys, signing the 1118 certification request with the private key serves as a POP on that key 1119 pair. With keys that can only be used for encryption operations, POP 1120 MUST be performed by forcing the client to decrypt a value. See Section 1121 5 of [CRMF] for a detailed discussion of POP. 1123 By necessity, POP for encryption-only keys cannot be done in one round- 1124 trip, since there are four distinct phases: 1126 1. Client tells the server about the public component of a new encryption 1127 key pair. 1128 2. Server sends the client a POP challenge, encrypted with the presented 1129 public encryption key, which the client must decrypt. 1130 3. Client decrypts the POP challenge and sends it back to the server. 1131 4. Server validates the decrypted POP challenge and continues processing 1132 the certificate request. 1134 CMC defines two different attributes. The first deals with the encrypted 1135 challenge sent from the server to the user in step 2. The second deals 1136 with the decrypted challenge sent from the client to the server in step 1137 3. 1139 The encryptedPOP attribute is used to send the encrypted challenge from 1140 the server to the client. As such, it is encoded as a tagged attribute 1141 within the controlSequence of a ResponseBody. (Note that we assume that 1142 the message sent in Step 1 above is an enrollment request and that the 1143 response in step 2 is a Full Enrollment Response including a failureInfo 1144 specifying that a POP is explicitly required, and providing the POP 1145 challenge in the encryptedPOP attribute.) 1147 EncryptedPOP ::= SEQUENCE { 1149 request TaggedRequest, 1150 cms contentInfo, 1151 thePOPAlgID AlgorithmIdentifier, 1152 witnessAlgID AlgorithmIdentifier, 1153 witness OCTET STRING 1154 } 1156 DecryptedPOP ::= SEQUENCE { 1157 bodyPartID BodyPartID, 1158 thePOPAlgID AlgorithmIdentifier, 1159 thePOP OCTET STRING 1160 } 1162 The encrypted POP algorithm works as follows: 1164 1. The server generates a random value y and associates it with the 1165 request. 1166 2. The server returns the encrypted pop with the following fields set: 1167 a. request is the certificate request in the original request message 1168 (it is included here so the client need not key a copy of the 1169 request), 1170 b. cms is an EnvelopedData object, the content type being id-data and 1171 the content being the value y. If the certificate request contains 1172 a subject key identifier (SKI) extension, then the recipient 1173 identifier SHOULD be the SKI. If the issuerAndSerialNumber form is 1174 used, the IsserName MUST be encoded as NULL and the SerialNumber as 1175 the bodyPartId of the certificate request, 1176 c. thePOPAlgID contains the algorithm to be used in computing the 1177 return POP value, 1178 d. witnessAlgID contains the hash algorithm used on y to create the 1179 field witness, 1180 e. witness contains the hashed value of y. 1181 3. The client decrypts the cms field to obtain the value y. The client 1182 computes H(y) using the witnessAlgID and compares to the value of 1183 witness. If the values do not compare or the decryption is not 1184 successful, the client MUST abort the enrollment process. The client 1185 aborts the process by sending a request message containing a 1186 CMCStatusInfo control attribute with failInfo value of popFailed. 1187 4. The client creates the decryptedPOP as part of a new PKIData message. 1188 The fields in the decryptedPOP are: 1189 a. bodyPartID refers to the certificate request in the new enrollment 1190 message, 1191 b. thePOPAlgID is copied from the encryptedPOP, 1192 c. thePOP contains the possession proof. This value is computed by 1193 thePOPAlgID using the value y and request referenced in (4a). 1194 5. The server then re-computes the value of thePOP from its cached value 1195 of y and the request and compares to the value of thePOP. If the 1196 values do not match, the server MUST NOT issue the certificate. The 1197 server MAY re-issue a new challenge or MAY fail the request 1198 altogether. 1200 When defining the algorithms for thePOPAlgID and witnessAlgID care must 1201 be taken to ensure that the result of witnessAlgID is not a useful value 1202 to shortcut the computation with thePOPAlgID. Clients MUST implement 1203 SHA-1 for witnessAlgID. Clients MUST implement HMAC-SHA1 for 1204 thePOPAlgID. The value of y is used as the secret value in the HMAC 1205 algorithm and the request referenced in (4a) is used as the data. If y 1206 is greater than 64 bytes, only the first 64 bytes of y are used as the 1207 secret. 1209 One potential problem with the algorithm above is the amount of state 1210 that a CA needs to keep in order to verify the returned POP value. This 1211 describes one of many possible ways of addressing the problem by reducing 1212 the amount of state kept on the CA to a single (or small set) of values. 1214 1. Server generates random seed x, constant across all requests. (The 1215 value of x would normally be altered on a regular basis and kept for a 1216 short time afterwards.) 1217 2. For certificate request R, server computes y = F(x,R). F can be, for 1218 example, HMAC-SHA1(x,R). All that's important for statelessness is 1219 that y be consistently computable with only known state constant x and 1220 function F, other inputs coming from the cert request structure. y 1221 should not be predictable based on knowledge of R, thus the use of a 1222 OWF like HMAC-SHA1. 1224 5.8 LRA POP Witnesses Control Attribute 1226 In an enrollment scenario involving an LRAs the CA may allow (or require) 1227 the LRA to perform the POP protocol with the entity requesting 1228 certification. In this case the LRA needs a way to inform the CA it has 1229 done the POP. This control attribute has been created to address this 1230 issue. 1232 The ASN.1 structure for the LRA POP witness is as follows: 1234 LraPopWitness ::= SEQUENCE { 1235 pkiDataBodyid BodyPartID, 1236 bodyIds SEQUENCE of BodyPartID 1237 } 1239 -- pkiDataBodyid field contains the body part id of the nested CMS 1240 body object containing the client's full request message. 1241 pkiDataBodyid is set to 0 if the request is in the current 1242 PKIRequest body. 1244 -- bodyIds contains a list of certificate requests for which the LRA 1245 has performed an out-of-band authentication. The method of 1246 authentication could be archival of private key material, challenge- 1247 response or other means. 1249 If a certificate server does not allow for an LRA to do the POP 1250 verification, it returns an error of POPFAILURE. The CA MUST NOT start a 1251 challenge-response to re-verify the POP itself. 1253 5.9 Get Certificate Control Attribute 1255 Everything described in this section is optional to implement. 1257 The get certificate control attribute is used to retrieve previously 1258 issued certificates from a repository of certificates. A Certificate 1259 Authority, an LRA or an independent service may provide this repository. 1260 The clients expected to use this facility are those operating in a 1261 resource-constrained environment. (An example of a resource-constrained 1262 client would be a low-end IP router that does not retain its own 1263 certificate in non-volatile memory.) 1265 The get certificate control attribute has the following ASN.1 structure: 1267 GetCert ::= SEQUENCE { 1268 issuerName GeneralName, 1269 serialNumber INTEGER } 1271 The service responding to the request will place the requested 1272 certificate in the certificates field of a SignedData object. If the get 1273 certificate attribute is the only control in a Full PKI Request message, 1274 the response would be a Simple Enrollment Response. 1276 5.10 Get CRL Control Attribute 1278 Everything described in this section is optional to implement. 1280 The get CRL control attribute is used to retrieve CRLs from a repository 1281 of CRLs. A Certification Authority, an LRA or an independent service may 1282 provide this repository. The clients expected to use this facility are 1283 those where a fully deployed directory is either infeasible or 1284 undesirable. 1286 The get CRL control attribute has the following ASN.1 structure: 1288 GetCRL ::= SEQUENCE { 1289 issuerName Name, 1290 cRLName GeneralName OPTIONAL, 1291 time GeneralizedTime OPTIONAL, 1292 reasons ReasonFlags OPTIONAL } 1294 The fields in a GetCRL have the following meanings: 1296 -- issuerName is the name of the CRL issuer. 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. Implementers 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.11 Revocation Request Control Attribute 1320 The revocation request control attribute is used to request that a 1321 certificate be revoked. 1323 The revocation request control attribute has the following ASN.1 syntax: 1325 RevRequest ::= SEQUENCE { 1326 issuerName Name, 1327 serialNumber INTEGER, 1328 reason CRLReason, 1329 invalidityDate GeneralizedTime OPTIONAL, 1330 sharedSecret OCTET STRING OPTIONAL, 1331 comment UTF8string OPTIONAL } 1333 -- issuerName contains the issuerName of the certificate to be 1334 revoked. 1336 -- serialNumber contains the serial number of the certificate to be 1337 revoked 1339 -- reason contains the suggested CRLReason code for why the 1340 certificate is being revoked. The CA can use this value at its 1341 discretion in building the CRL. 1343 -- invalidityDate contains the suggested value for the Invalidity 1344 Date CRL Extension. The CA can use this value at its discretion in 1345 building the CRL. 1347 -- sharedSecret contains a secret value registered by the EE when 1348 the certificate was obtained to allow for revocation of a 1349 certificate in the event of key loss. 1351 -- comment contains a human readable comment. 1353 For a revocation request to become a reliable object in the event of a 1354 dispute, a strong proof of originator authenticity is required. However, 1355 in the instance when an end-entity has lost use of its signature private 1356 key, it is impossible for the end-entity to produce a digital signature. 1357 The RevRequest provides for the optional transmission from the end-entity 1358 to the CA of a shared secret that may be used as an alternative 1359 authenticator in the instance of loss of use. The acceptability of this 1360 practice is a matter of local security policy. 1362 (Note that in some situations a Registration Authority may be delegated 1363 authority to revoke certificates on behalf of some population within its 1364 scope control. In these situations the CA would accept the LRA's digital 1365 signature on the request to revoke a certificate, independent of whether 1366 the end entity still had access to the private component of the key 1367 pair.) 1369 Clients MUST provide the capability to produce a digitally signed 1370 revocation request control attribute. Clients SHOULD be capable of 1371 producing an unsigned revocation request containing the end-entity's 1372 shared secret. If a client provides shared secret based self-revocation, 1373 the client MUST be capable of producing a revocation request containing 1374 the shared secret. Servers MUST be capable of accepting both forms of 1375 revocation requests. 1377 The structure of an unsigned, shared secret based revocation request is a 1378 matter of local implementation. The shared secret does not need to be 1379 encrypted when sent in a revocation request. The shared secret has a 1380 one-time use, that of causing the certificate to be revoked, and public 1381 knowledge of the shared secret after the certificate has been revoked is 1382 not a problem. Clients need to inform users that the same shared secret 1383 SHOULD NOT be used for multiple certificates. 1385 A full response message MUST be returned for a revocation request. 1387 5.12 Registration and Response Information Control Attributes 1389 The regInfo control attribute is for clients and LRAs to pass additional 1390 information as part a PKI request. The regInfo control attribute uses 1391 the ASN.1 structure: 1393 RegInfo ::= OCTET STRING 1395 The content of this data is based on bilateral agreement between the 1396 client and server. 1398 If a server (or LRA) needs to return information back to a requestor in 1399 response to data submitted in a regInfo attribute, then that data is 1400 returned as a responseInfo control attribute. The content of the OCTET 1401 STRING forresponse information is based on bilateral agreement between 1402 the client and server. 1404 5.13 Query Pending Control Attribute 1406 In some environments, process requirements for manual intervention or 1407 other identity checking can cause a delay in returning the certificate 1408 related to a certificate request. The query pending attribute allows for 1409 a client to query a server about the state of a pending certificate 1410 request. The server returns a token as part of the CMCStatusInfo 1411 attribute (in the otherInfo field). The client puts the token into the 1412 query pending attribute to identify the correct request to the server. 1413 The server can also return a suggested time for the client to query for 1414 the state of a pending certificate request. 1416 The ASN.1 structure used by the query pending control attribute is: 1418 QueryPending ::= OCTET STRING 1420 If a server returns a pending state (the transaction is still pending), 1421 the otherInfo MAY be omitted. If it is not omitted then the same value 1422 MUST be returned (the token MUST NOT change during the request). 1424 5.14 Confirm Certificate Acceptance 1426 Some Certification Authorities require that clients give a positive 1427 conformation that the certificates issued to it are acceptable. The 1428 Confirm Certificate Acceptance control attribute is used for that 1429 purpose. If the CMCStatusInfo on a certificate request is 1430 confirmRequired, then the client MUST return a Confirm Certificate 1431 Acceptance prior to any usage of the certificate. Clients SHOULD wait 1432 for the response from the server that the conformation has been received. 1434 The confirm certificate acceptance structure is: 1436 CMCCertId ::= IssuerSerial 1438 -- CMCCertId contains the issuer and serial number of the certificate 1439 being accepted. 1441 Servers MUST return a full enrollment response for a confirm certificate 1442 acceptance control. 1444 6. Local Registration Authorities 1446 This specification permits the use of Local Registration Authorities 1447 (LRAs). An LRA sits between the end-entity and the Certification 1448 Authority. From the end-entity's perspective, the LRA appears to be the 1449 Certification Authority and from the server the LRA appears to be a 1450 client. LRAs receive the enrollment messages, perform local processing 1451 and then forward onto Certificate Authorities. Some of the types of local 1452 processing that an LRA can perform include: 1454 - batching multiple enrollment messages together, 1455 - challenge/response POP proofs, 1456 - addition of private or standardized certificate extensions to all 1457 requests, 1458 - archival of private key material, 1459 - routing of requests to different CAs. 1461 When an LRA receives an enrollment message it has three options: it may 1462 forward the message without modification, it may add a new wrapping layer 1463 to the message, or it may remove one or more existing layers and add a 1464 new wrapping layer. 1466 When an LRA adds a new wrapping layer to a message it creates a new 1467 PKIData object. The new layer contains any control attributes required 1468 (for example if the LRA does the POP proof for an encryption key or the 1469 addExtension control attribute to modify an enrollment request) and the 1470 client enrollment message. The client enrollment message is placed in 1471 the cmsSequence if it is a Full Enrollment message and in the reqSequence 1472 if it is a Simple Enrollment message. If an LRA is batching multiple 1473 client messages together, then each client enrollment message is placed 1474 into the appropriate location in the LRA's PKIData object along with all 1475 relevant control attributes. (If multiple LRAs are in the path between 1476 the end-entity and the Certification Authority, this will lead to 1477 multiple wrapping layers on the message.) 1479 In processing an enrollment message, an LRA MUST NOT alter any 1480 certificate request body (PKCS #10 or CRMF) as any alteration would 1481 invalidate the signature on the request and thus the POP for the private 1482 key. 1484 An example of how this would look is illustrated by the following figure: 1486 SignedData (by LRA) 1487 PKIData 1488 controlSequence 1489 LRA added control statements 1490 reqSequence 1491 Zero or more Simple CertificationRequests from clients 1492 cmsSequence 1493 Zero or more Full PKI messages from clients 1494 SignedData (by client) 1495 PKIData 1497 Under some circumstances an LRA is required to remove wrapping layers. 1498 The following sections look at the processing required if encryption 1499 layers and signing layers need to be removed. 1501 6.1 Encryption Removal 1503 There are two cases that require an LRA to remove or change encryption in 1504 an enrollment message. In the first case the encryption was applied for 1505 the purposes of protecting the entire enrollment request from 1506 unauthorized entities. If the CA does not have a recipient info entry in 1507 the encryption layer, the LRA MUST remove the encryption layer. The LRA 1508 MAY add a new encryption layer with or without adding a new signing 1509 layer. 1511 The second change of encryption that may be required is to change the 1512 encryption inside of a signing layer. In this case the LRA MUST remove 1513 all signing layers containing the encryption. All control statements 1514 MUST be merged according to local policy rules as each signing layer is 1515 removed and the resulting merged controls MUST be placed in a new signing 1516 layer provided by the LRA. If the signing layer provided by the end- 1517 entity needs to be removed to the LRA can remove the layer. 1519 6.2 Signature Layer Removal 1521 Only two instances exist where an LRA should remove a signature layer on 1522 a Full Enrollment message. If an encryption needs to be modified within 1523 the message, or if a Certificate Authority will not accept secondary 1524 delegation (i.e. multiple LRA signatures). In all other situations LRAs 1525 SHOULD NOT remove a signing layer from a message. 1527 If an LRA removes a signing layer from a message, all control statements 1528 MUST be merged according to local policy rules. The resulting merged 1529 control statements MUST be placed in a new signing layer provided by the 1530 LRA. 1532 7. Transport Wrapping 1533 Not all methods of transporting data allow for sending unlabeled raw 1534 binary data, in may cases standard methods of encoding can be used to 1535 greatly ease this issue. These methods normally consist of wrapping some 1536 identification of the content around the binary data, possibly applying 1537 an encoding to the data and labeling the data. We document for use 1538 three different wrapping methods. 1540 -- MIME wrapping is for transports that are natively MIME based such as 1541 HTTP and E-mail. 1542 -- Binary file transport is defined since floppy disk transport is still 1543 very common. File transport can be done either as MIME wrapped 1544 (section 7.1) or bare (section 7.2). 1545 -- Socket based transport uses the raw BER encoded object. 1547 7.1 MIME Wrapping 1549 MIME wrapping is defined for those environments that are MIME native. 1550 These include E-Mail based protocols as well as HTTP. 1552 The basic mime wrapping in this section is taken from [SMIMEV2] and 1553 [SMIMEV3]. Simple enrollment requests are encoded using the 1554 application/pkcs10 content type. A file name MUST be included either in 1555 a content type or content disposition statement. The extension for the 1556 file MUST be ".p10". 1558 Simple enrollment response messages MUST be encoded as content-type 1559 application/pkcs7-mime. An smime-type parameter MUST be on the content- 1560 type statement with a value of "certs-only." A file name with the ".p7c" 1561 extension MUST be specified as part of the content-type or content- 1562 disposition. 1564 Full enrollment request messages MUST be encoded as content-type 1565 application/pkcs7-mime. The smime-type parameter MUST be included with a 1566 value of "CMC-enroll". A file name with the ".p7m" extension MUST be 1567 specified as part of the content-type or content-disposition statement. 1569 Full enrollment response messages MUST be encoded as content-type 1570 application/pkcs7-mime. The smime-type parameter MUST be included with a 1571 value of "CMC-response." A file name with the ".p7m" extensions MUST be 1572 specified as part of the content-type or content-disposition. 1574 MIME TYPE File Extension SMIME-TYPE 1576 application/pkcs10 .p10 N/A 1577 (simple PKI request) 1579 application/pkcs7-mime .p7m CMC-request 1580 (full PKI request) 1582 application/pkcs7-mime .p7c certs-only 1583 (simple PKI response) 1585 applicication/pkcs7-mime .p7m CMC-response 1586 (full PKI response) 1587 7.2 File-Based Transport 1589 Enrollment messages and responses may also be transferred between clients 1590 and servers using file system-based mechanisms, such as when enrollment 1591 is performed for an off-line client. When files are used to transport 1592 binary, BER-encoded Full Enrollment Request and Response messages, the 1593 following file type extensions SHOULD be used: 1595 Message Type File Extension 1597 Full PKI Request .crq 1599 Full PKI Response .crp 1601 7.3 Socket-Based Transport 1603 When enrollment messages and responses are sent over sockets, no wrapping 1604 is required. Messages SHOULD be sent in their binary, BER-encoded form. 1606 8. Interoperability 1608 8.1 Mandatory and Optional Algorithms 1610 CMC clients and servers MUST be capable of producing and processing 1611 message signatures using the Digital Signature Algorithm [DSA]. DSA 1612 signatures MUST be indicated by the DSA AlgorithmIdentifier value (as 1613 specified in section 7.2.2 of [PKIXCERT]). PKI clients and servers 1614 SHOULD also be capable of producing and processing RSA signatures (as 1615 specified in section 7.2.1 of [PKIXCERT]). 1617 CMC clients and servers MUST be capable of protecting and accessing 1618 message encryption keys using the Diffie-Hellman (D-H) key exchange 1619 algorithm. D-H/3DES protection MUST be indicated by the D-H 1620 AlgorithmIdentifier value specified in [CMS]. PKI clients and servers 1621 SHOULD also be capable of producing and processing RSA key transport. 1622 When used for PKI messages, RSA key transport MUST be indicated as 1623 specified in section 7.2.1 of [PKIXCERT]. 1625 8.2 Minimum Conformance Requirements 1627 A minimally compliant CMC server: 1629 a) MUST accept a Full PKI Request message 1630 i) MUST accept CRMF Request Bodies within a Full PKI Request 1631 ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request 1632 b) MUST accept a Simple Enrollment Request message 1633 c) MUST be able to return a Full PKI Response. (A Full PKI Response is 1634 always a valid response, but for interoperability with downlevel clients 1635 a compliant server SHOULD use the Simple Enrollment Response whenever 1636 possible.) 1638 A minimally-complaint CMC client: 1640 a) MAY use either the Simple Enrollment Message or the Full PKI Request. 1641 i) clients MUST use PKCS#10 with the Simple Enrollment Message 1642 ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request 1643 b) MUST understand the Simple Enrollment Response. 1644 c) MUST understand the Full PKI Response. 1646 9. Security Considerations 1648 Initiation of a secure communications channel between an end-entity and a 1649 CA or LRA (and, similarly, between an LRA and another LRA or CA) 1650 necessarily requires an out-of-band trust initiation mechanism. For 1651 example, a secure channel may be constructed between the end-entity and 1652 the CA via IPSEC or TLS. Many such schemes exist and the choice of any 1653 particular scheme for trust initiation is outside the scope of this 1654 document. Implementers of this protocol are strongly encouraged to 1655 consider generally accepted principles of secure key management when 1656 integrating this capability within an overall security architecture. 1658 Mechanisms for thwarting replay attacks may be required in particular 1659 implementations of this protocol depending on the operational 1660 environment. In cases where the CA maintains significant state 1661 information, replay attacks may be detectable without the inclusion of 1662 the optional nonce mechanisms. Implementers of this protocol need to 1663 carefully consider environmental conditions before choosing whether or 1664 not to implement the senderNonce and recipientNonce attributes described 1665 in section 5.6. Developers of state-constrained PKI clients are strongly 1666 encouraged to incorporate the use of these attributes. 1668 Under no circumstances should a signing key be archived. Doing so allows 1669 the archiving entity to potentially use the key for forging signatures. 1671 Due care must be taken prior to archiving keys. Once a key is given to 1672 an archiving entity, the archiving entity could use the keys in a way not 1673 conducive to the archiving entity. Users should be made especially aware 1674 that proper verification is made of the certificate used to encrypt the 1675 private key material. 1677 Clients and servers need to do some checks on cryptographic parameters 1678 prior to issuing certificates to make sure that weak parameters are not 1679 used. A description of the small subgroup attack is provided in [X942]. 1680 CMC implementations ought to be aware of this attack when doing parameter 1681 validations. 1683 10. Open Issues 1685 There are currently no open issues. 1687 11. Acknowledgments 1689 The authors would like to thank Brian LaMacchia for his work in 1690 developing and writing up many of the concepts presented in this 1691 document. The authors would also like to thank Alex Deacon and Barb Fox 1692 for their contributions. 1694 12. References 1696 [CMS] R. Housley, "Cryptographic Message Syntax", 1697 draft-ietf-smime-cms-06.txt, June 1998 1699 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet X.509 1700 Certificate Request Message Format", 1701 RFC 2511, March 1999 1703 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" 1705 [DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of- 1706 Possession Algorithms", draft-ietf-pkix-dhpop-00.txt, 1707 February 1999 1709 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1710 for Message Authentication", RFC 2104, February 1997. 1712 [PKCS1] B. Kaliski, "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, 1713 March 1998. 1715 [PKCS7] B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5", 1716 RFC 2315, October 1997 1718 [PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax 1719 Standard, Version 1.2", November 1, 1993. 1721 [PKCS10] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", 1722 RFC 2314, October 1997 1724 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet X.509 Public 1725 Key Infrastructure Certificate and CRL Profile", 1726 RFC 2459, January 1999 1728 [RFC 2119] "Key words for use in RFCs to Indicate Requirement 1729 Levels", RFC 2119 1731 [SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, 1732 "S/MIME Version 2 Message Specification", RFC 2311, March 1998 1734 [SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification", 1735 draft-ietf-smime-msg-05.txt, August 1998 1737 [X942] E. Rescorla, "Diffie-Hellman Key Agreement Method". 1738 (currently draft-ietf-smime-x942-*.txt) 1740 13. Author's Addresses 1742 Michael Myers 1743 VeriSign Inc. 1744 1350 Charlston Road 1745 Mountain View, CA, 94043 1746 (650) 429-3402 1747 mmyers@verisign.com 1748 Xiaoyi Liu 1749 Cisco Systems 1750 170 West Tasman Drive 1751 San Jose, CA 95134 1752 (480) 526-7430 1753 xliu@cisco.com 1755 Jim Schaad 1756 Microsoft Corporation 1757 One Microsoft Way 1758 Redmond, WA 98052 1759 (425) 936-3101 1760 jimsch@microsoft.com 1762 Jeff Weinstein 1763 jsw@meer.net 1765 Appendix A ASN.1 Module 1767 EnrollmentMessageSyntax 1768 { iso(1) identified-organization(3) dod(4) internet(1) 1769 security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) } 1771 DEFINITIONS IMPLICIT TAGS ::= 1772 BEGIN 1774 -- EXPORTS All -- 1775 -- The types and values defined in this module are exported for use 1776 -- in the other ASN.1 modules. Other applications may use them for 1777 -- their own purposes. 1779 IMPORTS 1781 -- Information Directory Framework (X.501) 1782 Name 1783 FROM InformationFramework { joint-iso-itu-t ds(5) 1784 modules(1) informationFramework(1) 3 } 1786 -- Directory Authentication Framework (X.509) 1787 AlgorithmIdentifier, AttributeCertificate, Certificate, 1788 CertificateList, CertificateSerialNumber 1789 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1790 module(1) authenticationFramework(7) 3 } 1792 -- PKIX Part 1 - Implicit 1793 GeneralName, CRLReason, ReasonFlags 1794 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 1795 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1796 id-pkix1-implicit-88(2)} 1798 -- PKIX Part 1 - Explicit 1799 SubjectPublicKeyInfo, Extension 1800 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 1801 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1802 id-pkix1-explicit-88(1)} 1804 -- Cryptographic Message Syntax 1805 ContentInfo, Attribute 1806 FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1} 1808 -- CRMF 1809 CertReqMsg 1810 FROM CRMF { 1 3 6 1 5 5 7 0 5 }; 1812 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1813 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1815 id-pkix-cmc OBJECT IDENTIFIER ::= {id-pkix } 1817 id-dh-private-number OBJECT IDENTIFIER ::= { id-pkix id-alg(6) } 1819 id-identification OBJECT IDENTIFIER ::= {id-pkix-cmc 2} 1820 id-identityProof OBJECT IDENTIFIER ::= {id-pkix-cmc 3} 1821 id-dataReturn OBJECT IDENTIFIER ::= {id-pkix-cmc 4} 1822 id-transactionId OBJECT IDENTIFIER ::= {id-pkix-cmc 5} 1823 id-senderNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 6} 1824 id-recipientNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 7} 1825 id-regInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 18} 1826 id-responseInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 19} 1827 id-queryPending OBJECT IDENTIFIER ::= {id-pkix-cmc 21} 1829 -- This is the content type used for a request message in the 1830 protocol 1832 id-ct-PKIData OBJECT IDENTIFIER ::= { id-pkix id-ct(5) 2 } 1834 PKIData ::= SEQUENCE { 1835 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1836 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 1837 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1838 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1839 } 1841 bodyIdMax INTEGER ::= 4294967295 1843 BodyPartID ::= INETGER(0..bodyIdMax) 1845 TaggedAttribute ::= SEQUENCE { 1846 bodyPartID BodyPartId, 1847 attrType OBJECT IDENTIFIER, 1848 attrValues SET OF AttributeValue 1849 } 1851 AttributeValue ::= ANY 1853 TaggedRequest ::= CHOICE { 1854 tcr [0] TaggedCertificationRequest, 1855 crm [1] CertReqMsg 1856 } 1858 TaggedCertificationRequest ::= SEQUENCE { 1859 bodyPartID BodyPartID, 1860 certificationRequest CertificationRequest 1861 } 1863 CertificationRequest ::= SEQUENCE { 1864 certificationRequestInfo SEQUENCE { 1865 version INTEGER, 1866 subject Name, 1867 subjectPublicKeyInfo SEQUENCE { 1868 algorithm AlgorithmIdentifier, 1869 subjectPublicKey BIT STRING }, 1870 attributes [0] IMPLICIT SET OF Attribute }, 1871 signatureAlgorithm AlgorithmIdentifier, 1872 signature BIT STRING 1873 } 1875 TaggedContentInfo ::= SEQUENCE { 1876 bodyPartID BodyPartId, 1877 contentInfo ContentInfo 1878 } 1880 OtherMsg ::= SEQUENCE { 1881 bodyPartID BodyPartID, 1882 otherMsgType OBJECT IDENTIFIER, 1883 otherMsgValue ANY DEFINED BY otherMsgType } 1885 -- This defines the response message in the protocol 1886 id-ct-PKIResponse OBJECT IDENTIFIER ::= {id-pkix ct(5) 3 } 1888 ResponseBody ::= SEQUENCE { 1889 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1890 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1891 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1892 } 1894 -- Used to return status state in a response 1896 id-cMCStatusInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 1} 1898 CMCStatusInfo ::= SEQUENCE { 1899 cMCStatus CMCStatus, 1900 bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, 1901 statusString UTF8String OPTIONAL, 1902 otherInfo CHOICE { 1903 failInfo CMCFailInfo, 1904 pendInfo PendInfo } OPTIONAL 1905 } 1907 PendInfo ::= SEQUENCE { 1908 pendToken INTEGER, 1909 pendTime GENERALIZEDTIME 1910 } 1912 CMCStatus ::= INTEGER { 1913 success (0), 1914 -- you got exactly what you asked for 1915 failed (2), 1916 -- you don't get it, more information elsewhere in the message 1917 pending (3), 1918 -- the request body part has not yet been processed, 1919 -- requester is responsible to poll back on this 1920 noSupport (4) 1921 -- the requested operation is not supported 1922 } 1924 CMCFailInfo ::= INTEGER { 1925 badAlg (0), 1926 -- Unrecognized or unsupported algorithm 1927 badMessageCheck (1), 1928 -- integrity check failed 1929 badRequest (2), 1930 -- transaction not permitted or supported 1931 badTime (3), 1932 -- Message time field was not sufficiently close to the system 1933 time 1934 badCertId (4), 1935 -- No certificate could be identified matching the provided 1936 criteria 1937 unsuportedExt (5), 1938 -- A requested X.509 extension is not supported by the recipient 1939 CA. 1940 mustArchiveKeys (6), 1941 -- Private key material must be supplied 1942 badIdentity (7), 1943 -- Identification Attribute failed to verify 1944 popRequired (8), 1945 -- Server requires a POP proof before issuing certificate 1946 popFailed (9), 1947 -- Server failed to get an acceptable POP for the request 1948 noKeyReuse (10) 1949 -- Server policy does not allow key re-use 1950 internalCAError (11) 1951 tryLater (12) 1952 } 1954 -- Used for LRAs to add extensions to certificate requests 1955 id-addExtensions OBJECT IDENTIFIER ::= {id-pkix-cmc 8} 1957 AddExtensions ::= SEQUENCE { 1958 pkiDataReference BodyPartID, 1959 certReferences SEQUENCE OF BodyPartID, 1960 extensions SEQUENCE OF Extension 1961 } 1962 id-encryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 9} 1963 id-decryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 10} 1965 EncryptedPOP ::= SEQUENCE { 1966 request TaggedRequest, 1967 cms ContentInfo, 1968 thePOPAlgID AlgorithmIdentifier, 1969 witnessAlgID AlgorithmIdentifier, 1970 witness OCTET STRING 1971 } 1973 DecryptedPOP ::= SEQUENCE { 1974 bodyPartID BodyPartID, 1975 thePOPAlgID AlgorithmIdentifier, 1976 thePOP OCTET STRING 1977 } 1979 id-lraPOPWitness OBJECT IDENTIFIER ::= {id-pkix-cmc 11} 1981 LraPopWitness ::= SEQUENCE { 1982 pkiDataBodyid BodyPartID, 1983 bodyIds SEQUENCE OF BodyPartID 1984 } 1986 id-keyArchival OBJECT IDENTIFIER ::= {id-pkix-cmc 12} 1987 id-keyRecoveryReq OBJECT IDENTIFIER ::= {id-pkix-cmc 13} 1988 id-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-pkix-cmc 14} 1990 KeyArchival ::= SEQUENCE { 1991 reqBodyPartID BodyPartID, 1992 cmsBodyPartID BodyPartID, 1993 selectionCriteria OCTET STRING OPTIONAL 1994 } 1996 KeyRecoveryReq ::= SEQUENCE { 1997 shroudIdentification ShroudIdentification, 1998 bulkEncryptionAlgID AlgorithmIdentifier, 1999 selectionCriterial OCTET STRING OPTIONAL 2000 } 2002 ShroudIdentification ::= CHOICE { 2003 subjectPublicKeyInfo [0] SubjectPublicKeyInfo, 2004 encryptionToken [1] AlgorithmIdentifier 2005 } 2007 KeyRecoveryRsp ::= SEQUENCE { 2008 bodyPartID BodyPartID, 2009 selectionCriteria OCTET STRING OPTIONAL 2010 } 2012 id-privateKey OBJECT IDENTIFIER ::= {id-pkix-cmc 20} 2014 PrivateKeyInfo ::= SEQUENCE { 2015 version INTEGER, 2016 privateKeyAlgorithm AlgorithmIdentifier, 2017 privateKey OCTET STRING, 2018 attributes [0] IMPLICIT Attributes OPTIONAL 2019 } 2021 Attributes ::= SET OF Attribute 2023 DH-PrivateKey ::= INTEGER 2025 -- 2026 id-getCert OBJECT IDENTIFIER ::= {id-pkix-cmc 15} 2028 GetCert ::= SEQUENCE { 2029 issuerName GeneralName, 2030 serialNumber INTEGER } 2032 id-getCRL OBJECT IDENTIFIER ::= {id-pkix-cmc 16} 2034 GetCRL ::= SEQUENCE { 2035 issuerName Name, 2036 cRLName GeneralName OPTIONAL, 2037 time GeneralizedTime OPTIONAL, 2038 reasons ReasonFlags OPTIONAL } 2040 id-revokeRequest OBJECT IDENTIFIER ::= {id-pkix-cmc 17} 2042 RevRequest ::= SEQUENCE { 2043 issuerName Name, 2044 serialNumber INTEGER, 2045 reason CRLReason, 2046 invalidityDate GeneralizedTime OPTIONAL, 2047 passphrase OCTET STRING OPTIONAL, 2048 comment UTF8String OPTIONAL } 2050 -- The following is used to request V3 extensions be added to a 2051 certificate 2053 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 2054 rsadsi(113549) pkcs(1) pkcs-9(9) 14} 2056 ExtensionReq ::= SEQUENCE OF Extension 2058 -- The following exists to allow Diffie-Hellman Certificate Requests 2059 Messages to be 2060 -- well-formed 2062 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 2064 NoSignatureValue ::= OCTET STRING 2066 idClientAccepts OBJECT IDENTIFIER ::= {pkix-cmc 24} 2067 CMCCertId ::= IssuerSerial 2069 END