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