idnits 2.17.1 draft-ietf-pkix-2797-bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3805. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 112 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 260 has weird spacing: '...esponse a PKI...' == Line 314 has weird spacing: '... Client refer...' == Line 317 has weird spacing: '... Server refer...' == Line 331 has weird spacing: '...esponse refer...' == Line 336 has weird spacing: '...dentity refer...' == (107 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2008) is 5891 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3123 -- Looks like a reference, but probably isn't: '1' on line 3103 -- Looks like a reference, but probably isn't: '2' on line 3104 -- Looks like a reference, but probably isn't: '3' on line 751 -- Looks like a reference, but probably isn't: '4' on line 752 -- Looks like a reference, but probably isn't: '5' on line 753 -- Looks like a reference, but probably isn't: '6' on line 754 -- Looks like a reference, but probably isn't: '7' on line 755 -- Looks like a reference, but probably isn't: '8' on line 756 -- Looks like a reference, but probably isn't: '9' on line 757 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3047, but not defined == Unused Reference: 'HMAC' is defined on line 2936, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 2961, but no explicit reference was found in the text == Unused Reference: 'IPsec' is defined on line 2964, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 2971, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 2974, but no explicit reference was found in the text == Unused Reference: 'PKCS8' is defined on line 2977, but no explicit reference was found in the text == Unused Reference: 'SMIMEV2' is defined on line 2989, but no explicit reference was found in the text == Unused Reference: 'SMIMEV3' is defined on line 2993, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 2996, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 2875 (ref. 'DH-POP') (Obsoleted by RFC 6955) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2314 (ref. 'PKCS10') (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 3280 (ref. 'PKIXCERT') (Obsoleted by RFC 5280) == Outdated reference: A later version (-08) exists of draft-ietf-pkix-cmc-trans-00 -- No information found for draft-ietf-pkix-cmc-must - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. 'SMIMEV3') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2797 (Obsoleted by RFC 5272) Summary: 8 errors (**), 0 flaws (~~), 19 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Expires: September 11, 2008 M. Myers 5 TraceRoute Security, Inc. 6 March 10, 2008 8 Certificate Management Messages over CMS 9 draft-ietf-pkix-2797-bis-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 11, 2008. 36 Abstract 38 This document defines the base syntax for CMC, a Certificate 39 Management protocol using the Cryptographic Message Syntax (CMS). 40 This protocol addresses two immediate needs within the Internet 41 Public Key Infrastructure (PKI) community: 43 1. The need for an interface to public key certification products 44 and services based on CMS and PKCS #10 (Public Key Cryptography 45 Standard), and 47 2. The need for a PKI enrollment protocol for encryption only keys 48 due to algorithm or hardware design. 50 CMC also requires the use of the transport document and the 51 requirements usage document along with this document for a full 52 definition. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 5 58 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 6 59 1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 6 60 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.2. Protocol Request/Responses . . . . . . . . . . . . . . . . 9 63 3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 12 65 3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 13 66 3.2.1. PKIData content type . . . . . . . . . . . . . . . . . 14 67 3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 16 68 3.2.1.2. Certification Request Formats . . . . . . . . . . 16 69 3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 17 70 3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 18 71 3.2.1.2.3. Other Certification Request . . . . . . . . . 19 72 3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19 73 3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 20 74 3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20 75 3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 21 76 3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 21 77 3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21 78 3.2.2. Body Part Identification . . . . . . . . . . . . . . . 22 79 3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 23 80 4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 25 81 4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 25 82 4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 25 83 4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 26 84 5. Application of Encryption to a PKI Request/Response . . . . . 28 85 6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 31 87 6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 31 88 6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 33 89 6.1.3. CMCStatus values . . . . . . . . . . . . . . . . . . . 34 90 6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 35 91 6.2. Identification and Identity Proof Controls . . . . . . . . 36 92 6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 37 93 6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 38 94 6.2.3. Identification Control . . . . . . . . . . . . . . . . 39 95 6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 39 96 6.3. Linking Identity and POP Information . . . . . . . . . . . 40 97 6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 40 98 6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 40 99 6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 42 100 6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 42 101 6.3.2. Shared-secret/subject DN linking . . . . . . . . . . . 42 102 6.3.3. Renewal and Re-Key Messages . . . . . . . . . . . . . 43 103 6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 43 104 6.5. RA Certificate Modification Controls . . . . . . . . . . . 44 105 6.5.1. Modify Certificate Request Control . . . . . . . . . . 44 106 6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 45 107 6.6. Transaction Identifier, Sender and Recipient Nonce 108 Controls . . . . . . . . . . . . . . . . . . . . . . . . . 47 109 6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 48 110 6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 51 111 6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 52 112 6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 53 113 6.11. Revocation Request Control . . . . . . . . . . . . . . . . 54 114 6.12. Registration and Response Information Controls . . . . . . 55 115 6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 56 116 6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 56 117 6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 57 118 6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 58 119 6.17. Batch Request and Response Controls . . . . . . . . . . . 59 120 6.18. Publication Information Control . . . . . . . . . . . . . 60 121 6.19. Control Processed Control . . . . . . . . . . . . . . . . 62 122 7. Registration Authorities . . . . . . . . . . . . . . . . . . . 63 123 7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 64 124 7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 64 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 65 126 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 127 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 128 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 129 11.1. Normative References . . . . . . . . . . . . . . . . . . . 69 130 11.2. Informational References . . . . . . . . . . . . . . . . . 69 131 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 71 132 Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 79 133 Appendix B.1. Request of a Signing Certificate . . . . . . . . . . 79 134 Appendix B.2. Single Certification Request, But Modified by RA . . 80 135 Appendix B.3. Direct POP for an RSA certificate . . . . . . . . . 83 136 Appendix C. Production of Diffie-Hellman Public Key 137 Certification Requests . . . . . . . . . . . . . . . 88 138 Appendix C.1. No-Signature Signature Mechanism . . . . . . . . . . 88 139 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 89 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 141 Intellectual Property and Copyright Statements . . . . . . . . . . 92 143 1. Introduction 145 This document defines the base syntax for CMC, a Certificate 146 Management protocol using the Cryptographic Message Syntax (CMS). 147 This protocol addresses two immediate needs within the Internet PKI 148 community: 150 1. The need for an interface to public key certification products 151 and services based on CMS and PKCS #10, and 153 2. The need for a PKI enrollment protocol for encryption only keys 154 due to algorithm or hardware design. 156 A small number of additional services are defined to supplement the 157 core certification request service. 159 1.1. Protocol Requirements 161 The protocol must be based as much as possible on the existing 162 CMS, PKCS #10 [PKCS10] and CRMF (Certificate Request Message 163 Format) [CRMF] specifications. 165 The protocol must support the current industry practice of a PKCS 166 #10 certification request followed by a PKCS#7 "certs-only" 167 response as a subset of the protocol. 169 The protocol must easily support the multi-key enrollment 170 protocols required by S/MIME and other groups. 172 The protocol must supply a way of doing all enrollment operations 173 in a single-round trip. When this is not possible the number of 174 round trips is to be minimized. 176 The protocol must be designed such that all key generation can 177 occur on the client. 179 Support must exist for the mandatory algorithms used by S/MIME. 180 Support should exist for all other algorithms cited by the S/MIME 181 core documents. 183 The protocol must contain Proof-of-Possession (POP) methods. 184 Optional provisions for multiple-round trip POP will be made if 185 necessary. 187 The protocol must support deferred and pending responses to 188 enrollment requests for cases where external procedures are 189 required to issue a certificate. 191 The protocol must support arbitrary chains of Registration 192 Authorities (RAs) as intermediaries between certification 193 requesters and Certification Authorities (CAs). 195 1.2. Requirements Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 1.3. Changes since RFC 2797 203 We have done a major overhaul on the layout of the document. This 204 included two different steps. Firstly we removed some sections from 205 the document and moved them to two other documents. Information on 206 how to transport our messages are now found in [CMC-TRANS]. 207 Information on which controls and sections of this document must be 208 implemented along with which algorithms are required can now be found 209 in [CMC-MUST]. 211 A number of new controls have been added in this version: 213 Extended CMC Status Info Section 6.1.1 215 Publish Trust Anchors Section 6.15 217 Authenticate Data Section 6.16 219 Batch Request and Response Processing Section 6.17 221 Publication Information Section 6.18 223 Modify Certificate Request Section 6.5.1 225 Control Processed Section 6.19 227 Identity Proof Section 6.2.2 229 Identity POP Link Witness V2 Section 6.3.1.1 231 2. Protocol Overview 233 A PKI enrollment transaction in this specification is generally 234 composed of a single round trip of messages. In the simplest case a 235 PKI enrollment request, henceforth referred to as a PKI Request, is 236 sent from the client to the server and a PKI enrollment response, 237 henceforth referred to as a PKI Response, is then returned from the 238 server to the client. In more complicated cases, such as delayed 239 certificate issuance, more than one round trip is required. 241 This specification defines two PKI Request types and two PKI Response 242 types. 244 PKI Requests are formed using either the PKCS #10 or CRMF structure. 245 The two PKI Requests are: 247 Simple PKI Request: the bare PKCS #10 (in the event that no other 248 services are needed), and 250 Full PKI Request: one or more PKCS #10, CRMF or Other Request 251 Messages structures wrapped in a CMS encapsulation as part of a 252 PKIData. 254 PKI Responses are based on SignedData [CMS]. The two PKI Responses 255 are 257 Simple PKI Response: a "certs-only" SignedData (in the event no 258 other services are needed), or 260 Full PKI Response a PKIResponse content-type wrapped in a 261 SignedData. 263 No special services are provided for either renewal (i.e., a new 264 certificate with the same key) or re-key (i.e., a new certificate 265 with a new key) of client certificates. Instead renewal and re-key 266 requests look the same as any certification request, except that the 267 identity proof is supplied by existing certificates from a trusted 268 CA. (This is usually the same CA, but could be a different CA in the 269 same organization where naming is shared.) 271 No special services are provided to distinguish between a re-key 272 request and a new certification request (generally for a new 273 purpose). A control to unpublish a certificate would normally be 274 included in a re-key request, and be omitted in a new certification 275 request. CAs or other publishing agents are also expected to have 276 policies for removing certificates from publication either based on 277 new certificates being added or the expiration or revocation of a 278 certificate. 280 A provision exists for RAs to participate in the protocol by taking 281 PKI Requests, wrapping them in a second layer of PKI Request with 282 additional requirements or statements from the RA and then passing 283 this new expanded PKI Request on to the CA. 285 This specification makes no assumptions about the underlying 286 transport mechanism. The use of CMS does not imply an email-based 287 transport. Several different possible transport methods are defined 288 in [CMC-TRANS]. 290 Optional services available through this specification are 291 transaction management, replay detection (through nonces), deferred 292 certificate issuance, certificate revocation requests and 293 certificate/certificate revocation list (CRL) retrieval. 295 2.1. Terminology 297 There are several different terms, abbreviations and acronyms used in 298 this document. These are defined here for convenience and 299 consistency of usage in no particular order: 301 End-Entity (EE) refers to the entity that owns a key pair and for 302 whom a certificate is issued. 304 Registration Authority (RA) or Local RA (LRA) refers to an entity 305 that acts as an intermediary between the EE and the CA. Multiple 306 RAs can exist between the End-Entity and the Certification 307 Authority. RAs may perform additional services such as key 308 generation or key archival. This document uses the term RA for 309 both RA and LRA. 311 Certification Authority (CA) refers to the entity that issues 312 certificates. 314 Client refers to an entity that creates a PKI Request. In this 315 document both RAs and EEs can be clients. 317 Server refers to the entities that process PKI Requests and create 318 PKI Responses. In this document both CAs and RAs can be servers. 320 PKCS #10 refers to the Public Key Cryptography Standard #10 321 [PKCS10], which defines a certification request syntax. 323 CRMF refers to the Certificate Request Message Format RFC [CRMF]. 324 CMC uses this certification request syntax defined in this 325 document as part of the protocol. 327 CMS refers to the Cryptographic Message Syntax RFC [CMS]. This 328 document provides for basic cryptographic services including 329 encryption and signing with and without key management. 331 PKI Request/Response refers to the requests/responses described in 332 this document. PKI Requests include certification requests, 333 revocation requests, etc. PKI Responses include certs-only 334 messages, failure messages, etc. 336 Proof-Of-Identity refers to the client proving they are who they say 337 that they are to the server. 339 Enrollment or certification request refers to the process of a 340 client requesting a certificate. A certification request is a 341 subset of the PKI Requests. 343 Proof-Of-Possession (POP) refers to a value that can be used to 344 prove that the private key corresponding to a public key is in the 345 possession and can be used by an end-entity. This document uses 346 the following different types of POP: 348 Signature provides the required POP by a signature operation over 349 some data. 351 Direct provides the required POP operation by an encrypted 352 challange/response mechinism. 354 Indirect provides the required POP opepration by returning the 355 issued certificate in an encrypted state. 357 Publish provides the required POP operation by providing the 358 private key the the certificate issuer. 360 Attested provides the required POP operation by allowing a 361 trusted entity to assert that the POP has been proven by one of 362 the above methods. 364 Object IDentifier (OID) is a primitive type in Abstract Syntax 365 Notation One (ASN.1). 367 2.2. Protocol Request/Responses 369 Figure 1 shows the Simple PKI Requests and Responses. The contents 370 of Simple PKI Request and Response are detailed in Section 3.1 and 371 Section 4.1. 373 Simple PKI Request Simple PKI Response 374 ------------------------- -------------------------- 376 +----------+ +------------------+ 377 | PKCS #10 | | CMS ContentInfo | 378 +----------+--------------+ +------------------+------+ 379 | Certification Request | | CMS Signed Data, | 380 | | | no SignerInfo | 381 | Subject Name | | 382 | Subject Public Key Info | | SignedData contains one | 383 | (K_PUB) | | or more certificates in | 384 | Attributes | | the certificates field | 385 | | | Relevant CA certs and | 386 +-----------+-------------+ | CRLs can be included | 387 | signed with | | as well. | 388 | matching | | | 389 | K_PRIV | | encapsulatedContentInfo | 390 +-------------+ | is absent. | 391 +--------------+----------+ 392 | unsigned | 393 +----------+ 395 Figure 1: Simple PKI Requests and Responses 397 Figure 2 shows the Full PKI Requests and Responses. The contents of 398 the Full PKI Request and Responses are detailed in Section 3.2 and 399 Section 4.2. 401 Full PKI Request Full PKI Response 402 ----------------------- ------------------------ 403 +----------------+ +----------------+ 404 | CMS ContentInfo| | CMS ContentInfo| 405 | CMS SignedData | | CMS SignedData | 406 | or Auth Data | | or Auth Data | 407 | object | | object | 408 +----------------+--------+ +----------------+--------+ 409 | | | | 410 | PKIData | | PKIResponseBody | 411 | | | | 412 | Sequence of: | | Sequence of: | 413 | * | | * | 414 | *| | * | 415 | * | | * | 416 | * | | | 417 | | | where * == zero or more | 418 | where * == zero or more | | | 419 | | | All certificates issued | 420 | Certification requests | | as part of the response | 421 | are CRMF, PKCS #10, or | | are included in the | 422 | Other. | | "certificates" field | 423 | | | of the SignedData. | 424 +-------+-----------------+ | Relevant CA certs and | 425 | signed (keypair | | CRLs can be included as | 426 | used may be pre-| | well. | 427 | existing or | | | 428 | identified in | +---------+---------------+ 429 | the request) | | signed by the | 430 +-----------------+ | CA or an LRA | 431 +---------------+ 433 Figure 2: Full PKI Requests and Responses 435 3. PKI Requests 437 Two types of PKI Requests exist. This section gives the details for 438 both types. 440 3.1. Simple PKI Request 442 A Simple PKI Request uses the PKCS #10 syntax CertificationRequest 443 [PKCS10]. 445 When a server processes a Simple PKI Request, the PKI Response 446 returned is: 448 Simple PKI Response on success. 450 Full PKI Response on failure. The server MAY choose not to return a 451 PKI Response in this case. 453 The Simple PKI Request MUST NOT be used if a proof-of-identity needs 454 to be included. 456 The Simple PKI Request cannot be used if the private key is not 457 capable of producing some type of signature (i.e. DH keys can use 458 the signature algorithms in [DH-POP] for production of the 459 signature). 461 The Simple PKI Request cannot be used for any of the advanced 462 services specified in this document. 464 The client MAY incorporate one or more X.509v3 extensions in any 465 certification request based on PKCS #10 as an ExtensionReq attribute. 466 The ExtensionReq attribute is defined as: 468 ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension 470 where Extension is imported from [PKIXCERT] and ExtensionReq is 471 identified by: 473 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 474 rsadsi(113549) pkcs(1) pkcs-9(9) 14} 476 Servers MUST be able to process all extensions defined, but not 477 prohibited, in [PKIXCERT]. Servers are not required to be able to 478 process other X.509v3 extensions transmitted using this protocol, nor 479 are they required to be able to process private extensions. Servers 480 are not required to put all client-requested extensions into a 481 certificate. Servers are permitted to modify client-requested 482 extensions. Servers MUST NOT alter an extension so as to invalidate 483 the original intent of a client-requested extension. (For example, 484 changing key usage from keyAgreement to digitalSignature.) If a 485 certification request is denied due to the inability to handle a 486 requested extension and a PKI Response is returned, the server MUST 487 return a PKI Response with a CMCFailInfo value with the value 488 unsupportedExt. 490 3.2. Full PKI Request 492 The Full PKI Request provides the most functionality and flexibility. 494 The Full PKI Request is encapsulated in either a SignedData or an 495 AuthenticatedData with an encapsulated content type of id-cct-PKIData 496 (Section 3.2.1). 498 When a server process a Full PKI Request, a PKI Response MUST be 499 returned. The PKI Response returned is: 501 Simple PKI Response if the enrollment was successful and only 502 certificates are returned. (A CMCStatusInfoV2 control with 503 success is implied.) 505 Full PKI Response if the enrollment was successful and information 506 is returned in addition to certificates, if the enrollment is 507 pending, or if the enrollment failed. 509 If SignedData is used, the signature can be generated using either 510 the private key material of an embedded signature certification 511 request (i.e., included in the TaggedRequest tcr or crm fields), or a 512 previously certified signature key. If the private key of a 513 signature certification request is used, then: 515 a. The certification request containing the corresponding public key 516 MUST include a Subject Key Identifier extension. 518 b. The subjectKeyIdentifier form of the signerIdentifier in 519 SignerInfo MUST be used. 521 c. The value of the subjectKeyIdentifier form of SignerInfo MUST be 522 the Subject Key Identifier specified in the corresponding 523 certification request. (The subjectKeyIdentifier form of 524 SignerInfo is used here because no certificates have yet been 525 issued for the signing key.) If the request key is used for 526 signing, there MUST be only one SignerInfo in the SignedData. 528 If AuthenticatedData is used, then: 530 a. The Password Recipient Info option of RecipientInfo MUST be used. 532 b. A randomly generated key is used to compute the MAC value on the 533 encapsulated content. 535 c. The input for the key derivation algorithm is a concatenation of 536 the identifier (encoded as UTF8) and the shared-secret. 538 When creating a PKI Request to renew or rekey a certificate: 540 a. The Identification and Identity Proof controls are absent. The 541 same information is provided by the use of an existing 542 certificate from a CA when signing the PKI Request. In this case 543 the CA that issued the original certificate and the CA the 544 request is made to will usually be the same, but could have a 545 common operator. 547 b. CAs and RAs can impose additional restrictions on the signing 548 certificate used. They may require that the most recently issued 549 signing certificate for a client be used. 551 c. Some CAs may prevent renewal operations (i.e., reuse of the same 552 keys). In this case the CA MUST return a PKI Response with 553 noKeyReuse as the CMCFailInfo failure code. 555 3.2.1. PKIData content type 557 The PKIData content type is used for the Full PKI Request. A PKIData 558 content type is identified by: 560 id-cct-PKIData ::= {id-pkix id-cct(12) 2 } 562 The ASN.1 structure corresponding to the PKIData content type is: 564 PKIData ::= SEQUENCE { 565 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 566 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 567 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 568 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 569 } 571 The fields in PKIData have the following meaning: 573 controlSequence is a sequence of controls. The controls defined in 574 this document are found in Section 6. Controls can be defined by 575 other parties. Details on the TaggedAttribute structure can be 576 found in Section 3.2.1.1. 578 reqSequence is a sequence of certification requests. The 579 certification requests can be a CertificationRequest (PKCS #10), a 580 CertReqMsg (CRMF) or an externally defined PKI request. Full 581 details are found in Section 3.2.1.2. If an externally defined 582 certification request is present, but the server does not 583 understand the certification request (or will not process it), a 584 CMCStatus of noSupport MUST be returned for the certification 585 request item and no other certification requests are processed. 587 cmsSequence is a sequence of [CMS] message objects. See 588 Section 3.2.1.3 for more details. 590 otherMsgSequence is a sequence of arbitrary data objects. Data 591 objects placed here are referred to by one or more controls. This 592 allows for controls to use large amounts of data without the data 593 being embedded in the control. See Section 3.2.1.4 for more 594 details. 596 All certification requests encoded into a single PKIData SHOULD be 597 for the same identity. RAs that batch process (see Section 6.17) are 598 expected to place the PKI Requests received into the cmsSequence of a 599 PKIData. 601 Processing of the PKIData by a recipient is as follows: 603 1. All controls should be examined and processed in an appropriate 604 manner. The appropriate processing is to complete processing at 605 this time, to ignore the control or to place the control on a 606 to-do list for later processing. Controls can be processed in 607 any order; the order in the sequence is not significant. 609 2. Items in the reqSequence are not referenced by a control. These 610 items, which are certification requests, also need to be 611 processed. As with controls, the appropriate processing can be 612 either immediate processing or addition to a to-do list for later 613 processing. 615 3. Finally the to-do list is processed. In many cases the to-do 616 list will be ordered by grouping specific tasks together. 618 No processing is required for cmsSequence or otherMsgSequence members 619 of PKIData if they are present and are not referenced by a control. 620 In this case, the cmsSequence and otherMsgSequence members are 621 ignored. 623 3.2.1.1. Control Syntax 625 The actions to be performed for a PKI Request/Response are based on 626 the included controls. Each control consists of an object identifier 627 and a value based on the object identifier. 629 The syntax of a control is: 631 TaggedAttribute ::= SEQUENCE { 632 bodyPartID BodyPartID, 633 attrType OBJECT IDENTIFIER, 634 attrValues SET OF AttributeValue 635 } 637 AttributeValue ::= ANY 639 The fields in TaggedAttribute have the following meaning: 641 bodyPartID is a unique integer that identifies this control. 643 attrType is the OID that identifies the control. 645 attrValues is the data values used in processing the control. The 646 structure of the data is dependent on the specific control. 648 The final server MUST fail the processing of an entire PKIData if any 649 included control is not recognized, that control is not already 650 marked as processed by a Control Processed control (see Section 6.19) 651 and no other error is generated. The PKI Response MUST include a 652 CMCFailInfo value with the value badRequest and the bodyList MUST 653 contain the bodyPartID of the invalid or unrecognized control(s). A 654 server is the final server if and only if it is not passing the PKI 655 Request on to another server. A server is not considered to be the 656 final server if the server would have passed the PKI Request on, but 657 instead it returned a processing error. 659 The controls defined by this document are found in Section 6. 661 3.2.1.2. Certification Request Formats 663 Certification Requests are based on PKCS #10, CRMF or Other Request 664 formats. Section 3.2.1.2.1 specifies the requirements for clients 665 and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the 666 requirements for clients and servers dealing with CRMF. 667 Section 3.2.1.2.3 specifies the requirements for clients and servers 668 dealing with Other Request. 670 TaggedRequest ::= CHOICE { 671 tcr [0] TaggedCertificationRequest, 672 crm [1] CertReqMsg, 673 orm [2] SEQUENCE { 674 bodyPartID BodyPartID, 675 requestMessageType OBJECT IDENTIFIER, 676 requestMessageValue ANY DEFINED BY requestMessageType 677 } 678 } 680 The fields in TaggedRequest have the following meaning: 682 tcr is a certification request that uses the PKCS #10 syntax. 683 Details on PKCS #10 are found in Section 3.2.1.2.1. 685 crm is a certification request that uses the CRMF syntax. Details 686 on CRMF are found in Section 3.2.1.2.2. 688 orm is an externally defined certification request. One example is 689 an attribute certification request. The fields of this structure 690 are: 692 bodyPartID is the identifier number for this certification 693 request. Details on body part identifiers are found in 694 Section 3.2.2. 696 requestMessageType identifies the other request type. These 697 values are defined outside of this document. 699 requestMessageValue is the data associated with the other request 700 type. 702 3.2.1.2.1. PKCS #10 Certification Syntax 704 A certification request based on PKCS #10 uses the following ASN.1 705 structure: 707 TaggedCertificationRequest ::= SEQUENCE { 708 bodyPartID BodyPartID, 709 certificationRequest CertificationRequest 710 } 712 The fields in TaggedCertificationRequest have the following meaning: 714 bodyPartID is the identifier number for this certification request. 715 Details on body part identifiers are found in Section 3.2.2. 717 certificationRequest contains the PKCS #10 based certification 718 request. Its fields are described in [PKCS10]. 720 When producing a certification request based on PKCS #10, clients 721 MUST produce the certification request with a subject name and public 722 key. Some PKI products are operated using a central repository of 723 information to assign subject names upon receipt of a certification 724 request. To accommodate this mode of operation, the subject field in 725 a CertificationRequest MAY be NULL, but MUST be present. CAs that 726 receive a CertificationRequest with a NULL subject field MAY reject 727 such certification requests. If rejected and a PKI Response is 728 returned, the CA MUST return a PKI Response with the CMCFailInfo 729 value with the value badRequest. 731 3.2.1.2.2. CRMF Certification Syntax 733 A CRMF message uses the following ASN.1 structure (defined in [CRMF] 734 and included here for convenience): 736 CertReqMsg ::= SEQUENCE { 737 certReq CertRequest, 738 popo ProofOfPossession OPTIONAL, 739 -- content depends upon key type 740 regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL } 742 CertRequest ::= SEQUENCE { 743 certReqId INTEGER, -- ID for matching request and reply 744 certTemplate CertTemplate, --Selected fields of cert to be issued 745 controls Controls OPTIONAL } -- Attributes affecting issuance 747 CertTemplate ::= SEQUENCE { 748 version [0] Version OPTIONAL, 749 serialNumber [1] INTEGER OPTIONAL, 750 signingAlg [2] AlgorithmIdentifier OPTIONAL, 751 issuer [3] Name OPTIONAL, 752 validity [4] OptionalValidity OPTIONAL, 753 subject [5] Name OPTIONAL, 754 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 755 issuerUID [7] UniqueIdentifier OPTIONAL, 756 subjectUID [8] UniqueIdentifier OPTIONAL, 757 extensions [9] Extensions OPTIONAL } 759 The fields in CertReqMsg are explained in [CRMF]. 761 This document imposes the following additional restrictions on the 762 construction and processing of CRMF certification requests: 764 When a Full PKI Request includes a CRMF certification request, 765 both the subject and publicKey fields in the CertTemplate MUST be 766 defined. The subject field can be encoded as NULL, but MUST be 767 present. 769 When both CRMF and CMC controls exist with equivalent 770 functionality, the CMC control SHOULD be used. The CMC control 771 MUST override the CRMF control. 773 The regInfo field MUST NOT be used on a CRMF certification 774 request. Equivalent functionality is provided in the CMC regInfo 775 control (Section 6.12). 777 The indirect method of proving POP is not supported in this 778 protocol. One of the other methods (including the direct method 779 described in this document) MUST be used. The value of encrCert 780 in SubsequentMessage MUST NOT be used. 782 Since the subject and publicKeyValues are always present, the 783 POPOSigningKeyInput MUST NOT be used when computing the value for 784 POPSigningKey. 786 A server is not required to use all of the values suggested by the 787 client in the CRMF certification request. Servers MUST be able to 788 process all extensions defined, but not prohibited in [PKIXCERT]. 789 Servers are not required to be able to process other X.509v3 790 extensions transmitted using this protocol, nor are they required to 791 be able to process private extensions. Servers are permitted to 792 modify client-requested extensions. Servers MUST NOT alter an 793 extension so as to invalidate the original intent of a client- 794 requested extension. (For example change key usage from keyAgreement 795 to digitalSignature.) If a certification request is denied due to 796 the inability to handle a requested extension, the server MUST 797 respond with a Full PKI Response with a CMCFailInfo value with the 798 value of unsupportedExt. 800 3.2.1.2.3. Other Certification Request 802 This document allows for other certification request formats to be 803 defined and used as well. An example of an other certification 804 request format is one for Attribute Certificates. These other 805 certification request formats are defined by specifying an OID for 806 identification and the structure to contain the data to be passed. 808 3.2.1.3. Content Info Objects 810 The cmsSequence field of the PKIData and PKIResponse messages 811 contains zero or more tagged content info objects. The syntax for 812 this structure is: 814 TaggedContentInfo ::= SEQUENCE { 815 bodyPartID BodyPartID, 816 contentInfo ContentInfo 817 } 819 The fields in TaggedContentInfo have the following meaning: 821 bodyPartID is a unique integer that identifies this content info 822 object. 824 contentInfo is a ContentInfo object (defined in [CMS]). 826 The four content types used in cmsSequence are AuthenticatedData, 827 Data, EnvelopedData and SignedData. All of these content types are 828 defined in [CMS]. 830 3.2.1.3.1. Authenticated Data 832 The AuthenticatedData content type provides a method of doing pre- 833 shared secret based validation of data being sent between two 834 parties. Unlike SignedData it does not specify which party actually 835 generated the information. 837 AuthenticatedData provides origination authentication in those 838 circumstances where a shared-secret exists, but a PKI based trust has 839 not yet been established. No PKI based trust may have been 840 established because a trust anchor has not been installed on the 841 client or no certificate exists for a signing key. 843 AuthenticatedData content type is used by this document for: 845 The id-cmc-authData control (Section 6.16), and 847 As the top-level wrapper in environments where an encryption only 848 key is being certified. 850 This content type can include both PKIData and PKIResponse as the 851 encapsulated content types. These embedded content types can contain 852 additional controls that need to be processed. 854 3.2.1.3.2. Data 856 The Data content type allows for general transport of unstructured 857 data. 859 The Data content type is used by this document for: 861 Holding the encrypted random value y for POP proof in the 862 encrypted POP control (see Section 6.7). 864 3.2.1.3.3. Enveloped Data 866 The EnvelopedData content type provides for shrouding of data. 868 The EnvelopedData content type is the primary confidentiality method 869 for sensitive information in this protocol. EnvelopedData can 870 provide encryption of an entire PKI Request (see Section 5). 871 EnvelopedData can also be used to wrap private key material for key 872 archival. If the decryption on an EnvelopedData fails, the Full PKI 873 Response with a CMCFailInfo value with a value of badMessageCheck and 874 a bodyPartId of 0. 876 3.2.1.3.4. Signed Data 878 The SignedData content type provides for authentication and 879 integrity. 881 The SignedData content type is used by this document for: 883 The outer wrapper for a PKI Request. 885 The outer wrapper for a PKI Response. 887 As part of processing a PKI Request/Response, the signature(s) MUST 888 be verified. If the signature does not verify and the PKI Request/ 889 Response contains anything other than a CMC Status Info control, a 890 Full PKI Response containing a CMC Status Info control MUST be 891 returned using a CMCFailInfo with a value of badMessageCheck and a 892 bodyPartId of 0. 894 For the PKI Response, SignedData allows the server to sign the 895 returning data, if any exists, and to carry the certificates and CRLs 896 corresponding to the PKI Request. If no data is being returned 897 beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo 898 fields are not populated. 900 3.2.1.4. Other Message Bodies 902 The otherMsgSequence field of the PKI Request/Response allows for 903 arbitrary data objects to be carried as part of a PKI Request/ 904 Response. This is intended to contain a data object that is not 905 already wrapped in a cmsSequence field Section 3.2.1.3. The data 906 object is ignored unless a control references the data object by 907 bodyPartID. 909 OtherMsg ::= SEQUENCE { 910 bodyPartID BodyPartID, 911 otherMsgType OBJECT IDENTIFIER, 912 otherMsgValue ANY DEFINED BY otherMsgType } 914 The fields in OtherMsg have the following meaning: 916 bodyPartID is the unique id identifying this data object. 918 otherMsgType is the OID that defines the type of message body 920 otherMsgValue is the data. 922 3.2.2. Body Part Identification 924 Each element of a PKIData or PKIResponse has an associated body part 925 identifier. The body part identifier is a 4-octet integer using the 926 ASN.1 of: 928 bodyIdMax INTEGER ::= 4294967295 930 BodyPartID ::= INTEGER(0..bodyIdMax) 932 Body part identifiers are encoded in the certReqIds field for 933 CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of 934 the other objects. The body part identifier MUST be unique within a 935 single PKIData or PKIResponse. Body part identifiers can be 936 duplicated in different layers (for example a PKIData embedded within 937 another). 939 The bodyPartId value of 0 is reserved for use as the reference to the 940 current PKIData object. 942 Some controls, such as the Add Extensions control (Section 6.5.2) use 943 the body part identifier in the pkiDataReference field to refer to a 944 PKI Request in the current PKIData. Some controls, such as the 945 Extended CMC Status Info control (Section 6.1.1), will also use body 946 part identifiers to refer to elements in the previous PKI Request/ 947 Response. This allows an error to be explicit about the control or 948 PKI Request to which the error applies. 950 A BodyPartList contains a list of body parts in a PKI Request/ 951 Response (i.e. the Batch Request control in Section 6.17). The ASN.1 952 type BodyPartList is defined as: 954 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 956 A BodyPartPath contains a path of body part identifiers moving 957 through nesting (i.e. the Modify Certificate Request control in 958 Section 6.5.1). The ASN.1 type BodyPartPath is defined as: 960 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 962 3.2.3. CMC Unsigned Data Attribute 964 There is sometimes a need to include data in a PKI Request designed 965 to be removed by an RA during processing. An example of this is the 966 inclusion of an encrypted private key, where a key archive agent 967 removes the encrypted private key before sending it on to the CA. 968 One side effect of this desire is that every RA which encapsulates 969 this information needs to move the data so that it is not covered by 970 that RA's signature. (A client PKI Request, encapsulated by an RA 971 cannot have a signed control removed by the key archive agent without 972 breaking the RA's signature.) The CMC Unsigned Data attribute 973 addresses this problem. 975 The CMC Unsigned Data attribute contains information that is not 976 directly signed by a client. When an RA encounters this attribute in 977 the unsigned or unauthenticated attribute field of a request it is 978 aggregating, the CMC Unsigned Data attribute is removed from the 979 request prior to placing it in a cmsSequence and placed in the 980 unsigned or unauthenticated attributes of the RA's signed or 981 authenticated data wrapper. 983 The CMC Unsigned Data attribute is identified by: 985 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34} 987 The CMC Unsigned Data attribute has the ASN.1 definition: 989 CMCUnsignedData ::= SEQUENCE { 990 bodyPartPath BodyPartPath, 991 identifier OBJECT IDENTIFIER, 992 content ANY DEFINED BY identifier 993 } 995 The fields in CMCUnsignedData have the following meaning: 997 bodyPartPath is the path pointing to the control associated with 998 this data. When an RA moves the control in an unsigned or 999 unauthenticated attribute up one level as part of wrapping the 1000 data in a new SignedData or AuthenticatedData, the body part 1001 identifier of the embedded item in the PKIData is pre-pended to 1002 the bodyPartPath sequence. 1004 identifier is the OID that defines the associated data. 1006 content is the data. 1008 There MUST be at most one CMC Unsigned Data attribute in the 1009 UnsignedAttribute sequence of a SignerInfo or in the 1010 UnauthenticatedAttribute sequence of an AuthenticatedData. 1011 UnsignedAttribute consists of a set of values, the attribute can have 1012 any number of values greater than zero in that set. If the CMC 1013 Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it 1014 MUST appear with the same values(s) in all SignerInfo and 1015 AuthenticatedData items. 1017 4. PKI Responses 1019 Two types of PKI Responses exist. This section gives the details on 1020 both types. 1022 4.1. Simple PKI Response 1024 Clients MUST be able to process the Simple PKI Response. The Simple 1025 PKI Response consists of a SignedData with no EncapsulatedContentInfo 1026 and no SignerInfo. The certificates requested in the PKI Response 1027 are returned in the certificate field of the SignedData. 1029 Clients MUST NOT assume the certificates are in any order. Servers 1030 SHOULD include all intermediate certificates needed to form complete 1031 certification paths to one or more trust anchors, not just the newly 1032 issued certificate(s). The server MAY additionally return CRLs in 1033 the CRL bag. Servers MAY include the self-signed certificates. 1034 Clients MUST NOT implicitly trust included self-signed certificate(s) 1035 merely due to its presence in the certificate bag. In the event 1036 clients receive a new self-signed certificate from the server, 1037 clients SHOULD provide a mechanism to enable the user to use the 1038 certificate as a trust anchor. (The Publish Trust Anchors control 1039 Section 6.15 should be used in the event that the server intends the 1040 client to accept one or more certificates as trust anchors. This 1041 requires the use of the Full PKI Response message.) 1043 4.2. Full PKI Response 1045 Clients MUST be able to process a Full PKI Response. 1047 The Full PKI Response consists of a SignedData encapsulating a 1048 PKIResponse content type. The certificates issued in a PKI Response 1049 are returned in the certificates field of the immediately 1050 encapsulating SignedData. 1052 Clients MUST NOT assume the certificates are in any order. Servers 1053 SHOULD include all intermediate certificates needed to form complete 1054 chains one or more trust anchors, not just the newly issued 1055 certificate(s). The server MAY additionally return CRLs in the CRL 1056 bag. Servers MAY include self-signed certificates. Clients MUST NOT 1057 implicitly trust included self-signed certificate(s) merely due to 1058 its presence in the certificate bag. In the event clients receive a 1059 new self-signed certificate from the server, clients MAY provide a 1060 mechanism to enable the user to explicitly use the certificate as a 1061 trust anchor. (The Publish Trust Anchors control Section 6.15 exists 1062 for the purpose of allowing for distribution of trust anchor 1063 certificates. If a trusted anchor publishes a new trusted anchor, 1064 this is one case where automated trust of the new trust anchor could 1065 be allowed.) 1067 4.2.1. PKIResponse Content Type 1069 The PKIResponse content type is used for the Full PKI Response. The 1070 PKIResponse content type is identified by: 1072 id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 } 1074 The ASN.1 structure corresponding to the PKIResponse content type is: 1076 PKIResponse ::= SEQUENCE { 1077 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1078 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1079 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1080 } 1082 ReponseBody ::= PKIResponse 1084 Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has 1085 been renamed to PKIResponse for clarity and the old name kept as a 1086 synonym. 1088 The fields in PKIResponse have the following meaning: 1090 controlSequence is a sequence of controls. The controls defined in 1091 this document are found in Section 6. Controls can be defined by 1092 other parties. Details on the TaggedAttribute structure are found 1093 in Section 3.2.1.1. 1095 cmsSequence is a sequence of [CMS] message objects. See 1096 Section 3.2.1.3 for more details. 1098 otherMsgSequence is a sequence of arbitrary data objects. Data 1099 objects placed here are referred to by one or more controls. This 1100 allows for controls to use large amounts of data without the data 1101 being embedded in the control. See Section 3.2.1.4 for more 1102 details. 1104 Processing of PKIResponse by a recipient is as follows: 1106 1. All controls should be examined and processed in an appropriate 1107 manner. The appropriate processing is to complete processing at 1108 this time, to ignore the control or to place the control on a 1109 to-do list for later processing. 1111 2. Additional processing of non-element items includes the saving of 1112 certificates and CRLs present in wrapping layers. This type of 1113 processing is based on the consumer of the element and should not 1114 be relied on by generators. 1116 No processing is required for cmsSequence or otherMsgSequence members 1117 of the PKIResponse, if items are present and are not referenced by a 1118 control. In this case, the cmsSequence and otherMsgSequence members 1119 are to be ignored. 1121 5. Application of Encryption to a PKI Request/Response 1123 There are occasions when a PKI Request or Response must be encrypted 1124 in order to prevent disclosure of information in the PKI Request/ 1125 Response from being accessible to unauthorized entities. This 1126 section describes the means to encrypt Full PKI Requests and 1127 Responses (Simple PKI Requests cannot be encrypted). Data portions 1128 of PKI Requests and Responses that are placed in the cmsSequence 1129 field can be encrypted separately. 1131 Confidentiality is provided by wrapping the PKI Request/Response (a 1132 SignedData) in an EnvelopedData. The nested content type in the 1133 EnvelopedData is id-SignedData. Note that this is different from 1134 S/MIME where there is a MIME layer placed between the encrypted and 1135 signed data. It is recommended that if an EnvelopedData layer is 1136 applied to a PKI Request/Response, a second signature layer be placed 1137 outside of the EnvelopedData layer. The following figure shows how 1138 this nesting would be done: 1140 Normal Option 1 Option 2 1141 ------ -------- -------- 1142 SignedData EnvelopedData SignedData 1143 PKIData SignedData EnvelopedData 1144 PKIData SignedData 1145 PKIData 1147 Note: PKIResponse can be substituted for PKIData in the above figure. 1149 Options 1 and 2 prevent leakage of sensitive data by encrypting the 1150 Full PKI Request/Response. An RA that receives a PKI Request that it 1151 cannot decrypt MAY reject the PKI Request unless it can process the 1152 PKI Request without knowledge of the contents (i.e., all it does is 1153 amalgamate multiple PKI Requests and forwards them to a server). 1154 After the RA removes the envelope and completes processing, it may 1155 then apply a new EnvelopedData layer to protect PKI Requests for 1156 transmission to the next processing agent. Section 7 contains more 1157 information about RA processing. 1159 Full PKI Requests/Responses can be encrypted or transmitted in the 1160 clear. Servers MUST provide support for all three options. 1162 Alternatively, an authenticated, secure channel could exist between 1163 the parties that require confidentiality. Clients and servers MAY 1164 use such channels instead of the technique described above to provide 1165 secure, private communication of Simple and Full PKI Requests/ 1166 Responses. 1168 6. Controls 1170 Controls are carried as part of both Full PKI Requests and Responses. 1171 Each control is encoded as a unique OID followed by the data for the 1172 control (see syntax in Section 3.2.1.1. The encoding of the data is 1173 based on the control. Processing systems would first detect the OID 1174 (TaggedAttribute attrType) and process the corresponding control 1175 value (TaggedAttribute attrValues) prior to processing the message 1176 body. 1178 The OIDs are all defined under the following arc: 1180 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1181 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1183 id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 } 1185 The following table lists the names, OID and syntactic structure for 1186 each of the controls described in this document. 1188 +------------------------+-------+------------------+---------------+ 1189 | Control Identifier | OID | Syntax | Section | 1190 +------------------------+-------+------------------+---------------+ 1191 | id-cmc-statusInfo | id-cm | CMCStatusInfo | Section 6.1.2 | 1192 | | c1 | | | 1193 | | | | | 1194 | id-cmc-identification | id-cm | UTF8String | Section 6.2.3 | 1195 | | c2 | | | 1196 | | | | | 1197 | id-cmc-identityProof | id-cm | OCTET STRING | Section 6.2.2 | 1198 | | c3 | | | 1199 | | | | | 1200 | id-cmc-dataReturn | id-cm | OCTET STRING | Section 6.4 | 1201 | | c4 | | | 1202 | | | | | 1203 | id-cmc-transactionId | id-cm | INTEGER | Section 6.6 | 1204 | | c5 | | | 1205 | | | | | 1206 | id-cmc-senderNonce | id-cm | OCTET STRING | Section 6.6 | 1207 | | c6 | | | 1208 | | | | | 1209 | id-cmc-recipientNonce | id-cm | OCTET STRING | Section 6.6 | 1210 | | c7 | | | 1211 | | | | | 1212 | id-cmc-addExtensions | id-cm | AddExtensions | Section 6.5.2 | 1213 | | c8 | | | 1214 | | | | | 1215 | id-cmc-encryptedPOP | id-cm | EncryptedPOP | Section 6.7 | 1216 | | c9 | | | 1217 | | | | | 1218 | id-cmc-decryptedPOP | id-cm | DecryptedPOP | Section 6.7 | 1219 | | c10 | | | 1220 | | | | | 1221 | id-cmc-lraPOPWitness | id-cm | LraPOPWitness | Section 6.8 | 1222 | | c11 | | | 1223 | | | | | 1224 | id-cmc-getCert | id-cm | GetCert | Section 6.9 | 1225 | | c15 | | | 1226 | | | | | 1227 | id-cmc-getCRL | id-cm | GetCRL | Section 6.10 | 1228 | | c16 | | | 1229 | | | | | 1230 | id-cmc-revokeRequest | id-cm | RevokeRequest | Section 6.11 | 1231 | | c17 | | | 1232 | | | | | 1233 | id-cmc-regInfo | id-cm | OCTET STRING | Section 6.12 | 1234 | | c18 | | | 1235 | | | | | 1236 | id-cmc-responseInfo | id-cm | OCTET STRING | Section 6.12 | 1237 | | c19 | | | 1238 | | | | | 1239 | id-cmc-queryPending | id-cm | OCTET STRING | Section 6.13 | 1240 | | c21 | | | 1241 | | | | | 1242 | id-cmc-popLinkRandom | id-cm | OCTET STRING | Section 6.3.1 | 1243 | | c22 | | .3 | 1244 | | | | | 1245 | id-cmc-popLinkWitness | id-cm | OCTET STRING | Section 6.3.1 | 1246 | | c23 | | .2 | 1247 | | | | | 1248 | id-cmc-popLinkWitnessV | id-cm | OCTET STRING | Section 6.3.1 | 1249 | 2 | c33 | | .1 | 1250 | | | | | 1251 | id-cmc-confirmCertAcce | id-cm | CMCCertId | Section 6.14 | 1252 | ptance | c24 | | | 1253 | | | | | 1254 | id-cmc-statusInfoV2 | id-cm | CMCStatusInfoV2 | Section 6.1.1 | 1255 | | c25 | | | 1256 | | | | | 1257 | id-cmc-trustedAnchors | id-cm | PublishTrustAnch | Section 6.15 | 1258 | | c26 | ors | | 1259 | | | | | 1260 | id-cmc-authData | id-cm | AuthPublish | Section 6.16 | 1261 | | c27 | | | 1262 | | | | | 1263 | id-cmc-batchRequests | id-cm | BodyPartList | Section 6.17 | 1264 | | c28 | | | 1265 | | | | | 1266 | id-cmc-batchResponses | id-cm | BodyPartList | Section 6.17 | 1267 | | c29 | | | 1268 | | | | | 1269 | id-cmc-publishCert | id-cm | CMCPublicationIn | Section 6.18 | 1270 | | c30 | fo | | 1271 | | | | | 1272 | id-cmc-modCertTemplate | id-cm | ModCertTemplate | Section 6.5.1 | 1273 | | c31 | | | 1274 | | | | | 1275 | id-cmc-controlProcesse | id-cm | ControlsProcesse | Section 6.19 | 1276 | d | c32 | d | | 1277 | | | | | 1278 | id-cmc-identityProofV2 | id-cm | IdentityProofV2 | Section 6.2.1 | 1279 | | c34 | | | 1280 +------------------------+-------+------------------+---------------+ 1282 Table 1: CMC Control Attributes 1284 6.1. CMC Status Info Controls 1286 The CMC Status Info controls return information about the status of a 1287 client/server request/response. Two controls are described in this 1288 section. The Extended CMC Status Info control is the preferred 1289 control; the CMC Status Info control is included for backwards 1290 compatibility with RFC 2797. 1292 Servers MAY emit multiple CMC status info controls referring to a 1293 single body part. Clients MUST be able to deal with multiple CMC 1294 status info controls in a PKI Response. Servers MUST use the 1295 Extended CMC Status Info control, but MAY additionally use the CMC 1296 Status Info control. Clients MUST be able to process the Extended 1297 CMC Status Info control. 1299 6.1.1. Extended CMC Status Info Control 1301 The Extended CMC Status Info control is identified by the OID: 1303 id-cmc-statusInfoV2 ::= { id-cmc 25 } 1305 The Extended CMC Status Info control has the ASN.1 definition: 1307 CMCStatusInfoV2 ::= SEQUENCE { 1308 cMCStatus CMCStatus, 1309 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference, 1310 statusString UTF8String OPTIONAL, 1311 otherInfo OtherStatusInfo OPTIONAL 1312 } 1314 OtherStatusInfo ::= CHOICE { 1315 failInfo CMCFailInfo, 1316 pendInfo PendInfo, 1317 extendedFailInfo ExtendedFailInfo 1318 } 1320 PendInfo ::= SEQUENCE { 1321 pendToken OCTET STRING, 1322 pendTime GeneralizedTime 1323 } 1325 ExtendedFailInfo ::= SEQUENCE { 1326 failInfoOID OBJECT IDENTIFIER, 1327 failInfoValue ANY DEFINED BY failInfoOID 1328 } 1330 BodyPartReference ::= CHOICE { 1331 bodyPartID BodyPartID, 1332 bodyPartPath BodyPartPath 1333 } 1335 The fields in CMCStatusInfoV2 have the following meaning: 1337 cMCStatus contains the returned status value. Details are in 1338 Section 6.1.3. 1340 bodyList identifies the controls or other elements to which the 1341 status value applies. If an error is returned for a Simple PKI 1342 Request, this field is the bodyPartID choice of BodyPartReference 1343 with the single integer of value 1. 1345 statusString contains additional description information. This 1346 string is human readable. 1348 otherInfo contains additional information that expands on the CMC 1349 status code returned in the cMCStatus field. 1351 The fields in OtherStatusInfo have the following meaning: 1353 failInfo is described in Section 6.1.4. It provides an error code 1354 that details what failure occurred. This choice is present only 1355 if cMCStatus contains the value failed. 1357 pendInfo contains information about when and how the client should 1358 request for the result of this request. It is present when the 1359 cMCStatus is either pending or partial. pendInfo uses the 1360 structure PendInfo, which has the fields: 1362 pendToken is the token used in the Query Pending control 1363 Section 6.13. 1365 pendTime contains the suggested time the server wants to be 1366 queried about the status of the certification request. 1368 extendedFailInfo includes application dependent detail error 1369 information. This choice is present only if cMCStatus contains 1370 the value failed. Caution should be used when defining new values 1371 as they may not be correctly recognized by all clients and 1372 servers. The CMCFailInfo value of internalCAError may be assumed 1373 if the extended error is not recognized. This field uses the type 1374 ExtendedFailInfo. ExtendedFailInfo has the fields: 1376 failInfoOID contains an OID that is associated with a set of 1377 extended error values. 1379 failInfoValue contains an extended error code from the defined 1380 set of extended error codes. 1382 If the cMCStatus field is success, the Extended CMC Status Info 1383 control MAY be omitted unless it is the only item in the response. 1385 6.1.2. CMC Status Info Control 1387 The CMC Status Info control is identified by the OID: 1389 id-cmc-statusInfo ::= { id-cmc 1 } 1391 The CMC Status Info control has the ASN.1 definition: 1393 CMCStatusInfo ::= SEQUENCE { 1394 cMCStatus CMCStatus, 1395 bodyList BodyPartList, 1396 statusString UTF8String OPTIONAL, 1397 otherInfo CHOICE { 1398 failInfo CMCFailInfo, 1399 pendInfo PendInfo } OPTIONAL 1400 } 1402 The fields in CMCStatusInfo have the following meaning: 1404 cMCStatus contains the returned status value. Details are in 1405 Section 6.1.3. 1407 bodyList contains the list of controls or other element to which the 1408 status value applies. If an error is being returned for a Simple 1409 PKI Request, this field contains a single integer of value 1. 1411 statusString contains additional description information. This 1412 string is human readable. 1414 otherInfo provides additional information that expands on the CMC 1415 status code returned in the cMCStatus field. 1417 failInfo is described in Section 6.1.4. It provides an error 1418 code that details what failure occurred. This choice is 1419 present only if cMCStatus is failed. 1421 pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It 1422 contains information about when and how the client should 1423 request for results on this request. The pendInfo field MUST 1424 be populated for a cMCStatus value of pending or partial. 1425 Further details can be found in Section 6.1.1 (Extended CMC 1426 Status Info Control) and Section 6.13 (Query Pending Control). 1428 If the cMCStatus field is success, the CMC Status Info control MAY be 1429 omitted unless it is the only item in the response. If no status 1430 exists for a Simple or Full PKI Request, then the value of success is 1431 assumed. 1433 6.1.3. CMCStatus values 1435 CMCStatus is a field in the Extended CMC Status Info and CMC Status 1436 Info controls. This field contains a code representing the success 1437 or failure of a specific operation. CMCStatus has the ASN.1 1438 structure: 1440 CMCStatus ::= INTEGER { 1441 success (0), 1442 -- reserved (1), 1443 failed (2), 1444 pending (3), 1445 noSupport (4), 1446 confirmRequired (5), 1447 popRequired (6), 1448 partial (7) 1449 } 1451 The values of CMCStatus have the following meaning: 1453 success indicates the request was granted or the action was 1454 completed. 1456 failed indicates the request was not granted or the action was not 1457 completed. More information is included elsewhere in the 1458 response. 1460 pending indicates the PKI Request has yet to be processed. The 1461 requestor is responsible to poll back on this Full PKI request. 1462 pending may only be returned for certification request operations. 1464 noSupport indicates the requested operation is not supported. 1466 confirmRequired indicates a Confirm Certificate Acceptance control 1467 Section 6.14 must be returned before the certificate can be used. 1469 popRequired indicates an direct POP operation is required 1470 Section 6.3.1.3. 1472 partial indicates a partial PKI Response is returned. The requestor 1473 is responsible to poll back for the unfulfilled portions of the 1474 Full PKI Request. 1476 6.1.4. CMCFailInfo 1478 CMCFailInfo is a field in the Extended CMC Status Info and CMC Status 1479 Info controls. CMCFailInfo conveys more detailed information 1480 relevant to the interpretation of a failure condition. The 1481 CMCFailInfo has the following ASN.1 structure: 1483 CMCFailInfo ::= INTEGER { 1484 badAlg (0), 1485 badMessageCheck (1), 1486 badRequest (2), 1487 badTime (3), 1488 badCertId (4), 1489 unsuportedExt (5), 1490 mustArchiveKeys (6), 1491 badIdentity (7), 1492 popRequired (8), 1493 popFailed (9), 1494 noKeyReuse (10), 1495 internalCAError (11), 1496 tryLater (12), 1497 authDataFail (13) 1498 } 1500 The values of CMCFailInfo have the following meanings: 1502 badAlg indicates unrecognized or unsupported algorithm. 1504 badMessageCheck indicates integrity check failed. 1506 badRequest indicates transaction not permitted or supported. 1508 badTime indicates message time field was not sufficiently close to 1509 the system time. 1511 badCertId indicates no certificate could be identified matching the 1512 provided criteria. 1514 unsuportedExt indicates a requested X.509 extension is not supported 1515 by the recipient CA. 1517 mustArchiveKeys indicates private key material must be supplied. 1519 badIdentity indicates identification control failed to verify. 1521 popRequired indicates server requires a POP proof before issuing 1522 certificate. 1524 popFailed indicates POP processing failed. 1526 noKeyReuse indicates server policy does not allow key reuse. 1528 internalCAError indicates that the CA had an unknown internal 1529 failure. 1531 tryLater indicates that the server is not accepting requests at this 1532 time and the client should try at a later time. 1534 authDataFail indicates failure occurred during processing of 1535 authenticated data 1537 If additional failure reasons are needed, they SHOULD use the 1538 ExtendedFailureInfo item in the Extended CMC Status Info control. 1539 However for closed environments they can be defined using this type. 1540 Such codes MUST be in the range from 1000 to 1999. 1542 6.2. Identification and Identity Proof Controls 1544 Some CAs and RAs require that a proof-of-identity be included in a 1545 certification request. Many different ways of doing this exist with 1546 different degrees of security and reliability. Most are familiar 1547 with a bank's request to provide your mother's maiden name as a form 1548 of identity proof. The reasoning behind requiring a proof-of- 1549 identity can be found in Appendix C of [CRMF]. 1551 CMC provides a method to prove the client's identity based on a 1552 client/server shared-secret. If clients support the Full PKI 1553 Request, clients MUST implement this method of identity proof 1554 (Section 6.2.2). Servers MUST provide this method, but MAY 1555 additionally support bilateral methods of similar strength. 1557 This document also provides an Identification control 1558 (Section 6.2.3). This control is a simple method to allow a client 1559 to state who they are to the server. Generally, a shared secret AND 1560 an identifier of that shared-secret is passed from the server to the 1561 client. The identifier is placed in the Identification control and 1562 the shared-secret is used to compute the Identity Proof control. 1564 6.2.1. Identity Proof Version 2 Control 1566 The Identity Proof Version 2 control is identified by the OID: 1568 id-cmc-identityProofV2 ::= { id-cmc 34 } 1570 The Identity Proof Version 2 control has the ASN.1 definition: 1572 IdentifyProofV2 ::= SEQUENCE { 1573 hashAlgID AlgorithmIdentifier, 1574 macAlgID AlgorithmIdentifier, 1575 witness OCTET STRING 1576 } 1578 The fields of IdentityProofV2 have the following meaning: 1580 hashAlgID is the identifier and parameters for the hash algorithm 1581 used to convert the shared-secret into a key for the MAC 1582 algorithm. 1584 macAlgID is the identifier and the parameters for the message 1585 authentication code algorithm used to compute the value of the 1586 witness field. 1588 witness is the identity proof. 1590 The required method starts with an out-of-band transfer of a token 1591 (the shared-secret). The shared-secret should be generated in a 1592 random manner. The distribution of this token is beyond the scope of 1593 this document. The client then uses this token for an identity proof 1594 as follows: 1596 1. The PKIData reqSequence field (encoded exactly as it appears in 1597 the Full PKI Request including the sequence type and length) is 1598 the value to be validated. 1600 2. A hash of the shared-secret as a UTF8 string is computed using 1601 hashAlgID. 1603 3. A MAC is then computed using the value produced in Step 1 as the 1604 message and the value from Step 2 as the key. 1606 4. The result from Step 3 is then encoded as the witness value in 1607 the Identity Proof Version 2 control. 1609 When the server verifies the Identity Proof Version 2 control, it 1610 computes the MAC value in the same way and compares it to the witness 1611 value contained in the PKI Request. 1613 If a server fails the verification of an Identity Proof Version 2 1614 control, the CMCFailInfo value MUST be present in the Full PKI 1615 Response and MUST have a value of badIdentity. 1617 Reuse of the shared-secret on certification request retries allows 1618 the client and server to maintain the same view of acceptable 1619 identity proof values. However, reuse of the shared-secret can 1620 potentially open the door for some types of attacks. 1622 Implementations MUST be able to support tokens at least 16 characters 1623 long. Guidance on the amount of entropy actually obtained from a 1624 given length token based on character sets can be found in Appendix A 1625 of [PASSWORD]. 1627 6.2.2. Identity Proof Control 1629 The Identity Proof control is identified by the OID: 1631 id-cmc-identityProof ::= { id-cmc 3 } 1633 The Identity Proof control has the ASN.1 definition: 1635 IdentifyProof ::= OCTET STRING 1637 This control is processed in the same way as the Identity Proof 1638 Version 2 control. In this case the hash algorithm is fixed to SHA-1 1639 and the MAC algorithm is fixed to HMAC-SHA1. 1641 6.2.3. Identification Control 1643 Optionally, servers MAY require the inclusion of the unprotected 1644 Identification control with an Identification Proof control. The 1645 Identification control is intended to contain a text string which 1646 assists the server in locating the shared-secret needed to validate 1647 the contents of the Identity Proof control. If the Identification 1648 control is included in the Full PKI Request, the derivation of the 1649 key in step 2 (from Section 6.2.1 is altered so that the hash of the 1650 concatenation of the shared-secret and the UTF8 identity value 1651 (without the type and length bytes) are hashed rather than just the 1652 shared-secret. 1654 The Identification control is identified by the OID: 1656 id-cmc-identification ::= { id-cmc 2 } 1658 The Identification control has the ASN.1 definition: 1660 Identification ::= UTF8String 1662 6.2.4. Hardware Shared-Secret Token Generation 1664 The shared-secret between the EE and the server is sometimes computed 1665 using a hardware device that generates a series of tokens. The EE 1666 can therefore prove their identity by transferring this token in 1667 plain text along with a name string. The above protocol can be used 1668 with a hardware shared-secret token generation device by the 1669 following modifications: 1671 1. The Identification control MUST be included and MUST contain the 1672 hardware-generated token. 1674 2. The shared-secret value used above is the same hardware-generated 1675 token. 1677 3. All certification requests MUST have a subject name and the 1678 subject name MUST contain the fields required to identify the 1679 holder of the hardware token device. 1681 4. The entire certification request MUST be shrouded in some fashion 1682 to prevent eavesdropping. Although the token is time critical, 1683 an active eavesdropper cannot be permitted to extract the token 1684 and submit a different certification request with the same token 1685 value. 1687 6.3. Linking Identity and POP Information 1689 In a Full PKI Request, identity information about the client is 1690 carried in the signature of the SignedData containing all of the 1691 certification requests. Proof-of-possession information for key 1692 pairs, however, is carried separately for each PKCS #10 or CRMF 1693 certification request. (For keys capable of generating a digital 1694 signature, the POP is provided by the signature on the PKCS #10 or 1695 CRMF request. For encryption-only keys the controls described in 1696 Section 6.7 are used.) In order to prevent substitution-style 1697 attacks, the protocol must guarantee that the same entity generated 1698 both the POP and proof-of-identity information. 1700 This section describes two mechanisms for linking identity and POP 1701 information: witness values cryptographically derived from the 1702 shared-secret (Section 6.3.1.3) and shared-secret/subject DN matching 1703 (Section 6.3.2). Clients and servers MUST support the witness value 1704 technique. Clients and servers MAY support shared-secret/subject DN 1705 matching or other bilateral techniques of similar strength. The idea 1706 behind both mechanisms is to force the client to sign some data into 1707 each certification request that can be directly associated with the 1708 shared-secret; this will defeat attempts to include certification 1709 requests from different entities in a single Full PKI Request. 1711 6.3.1. Cryptographic Linkage 1713 The first technique that links identity and POP information forces 1714 the client to include a piece of information cryptographically- 1715 derived from the shared-secret as a signed extension within each 1716 certification request (PKCS #10 or CRMF). 1718 6.3.1.1. POP Link Witness Version 2 Controls 1720 The POP Link Witness Version 2 control is identified by the OIDs: 1722 id-cmc-popLinkWitnessV2 ::= { id-cmc 33 } 1724 The POP Link Witness Version 2 control has the ASN.1 definition: 1726 PopLinkWitnessV2 ::= SEQUENCE { 1727 keyGenAlgorithm AlgorithmIdentifier, 1728 macAlgorithm AlgorithmIdentifier, 1729 witness OCTET STRING 1730 } 1732 The fields of PopLinkWitnessV2 have the meaning: 1734 keyGenAlgorithm contains the algorithm used to generate the key for 1735 the MAC algorithm. This will generally be a hash algorithm, but 1736 could be a more complex algorithm. 1738 macAlgorithm contains the algorithm used to create the witness 1739 value. 1741 witness contains the computed witness value. 1743 This technique is useful if null subject DNs are used (because, for 1744 example, the server can generate the subject DN for the certificate 1745 based only on the shared-secret). Processing begins when the client 1746 receives the shared-secret out-of-band from the server. The client 1747 then computes the following values: 1749 1. The client generates a random byte-string, R, which SHOULD be at 1750 least 512 bits in length. 1752 2. The key is computed from the shared-secret using the algorithm in 1753 keyGenAlgorithm. 1755 3. A MAC is then computed over the random value produced in Step 1, 1756 using the key computed in Step 2. 1758 4. The random value produced in Step 1 is encoded as the value of a 1759 POP Link Random control. This control MUST be included in the 1760 Full PKI Request. 1762 5. The MAC value produced in Step 3 is placed in either the POP Link 1763 Witness control or the witness field of the POP Link Witness V2 1764 control. 1766 * For CRMF, the POP Link Witness/POP Link Witness V2 control is 1767 included in the controls field of the CertRequest structure. 1769 * For PKCS #10, the POP Link Witness/POP Link Witness V2 control 1770 is included in the attributes field of the 1771 CertificationRequestInfo structure. 1773 Upon receipt, servers MUST verify that each certification request 1774 contains a copy of the POP Link Witness/POP Link Witness V2 control 1775 and that its value was derived using the above method from the 1776 shared-secret and the random string included in the POP Link Random 1777 control. 1779 The Identification control (see Section 6.2.3) or the subject DN of a 1780 certification request can be used to help identify which shared- 1781 secret was used. 1783 6.3.1.2. POP Link Witness Control 1785 The POP Link Witness control is identified by the OIDs: 1787 id-cmc-popLinkWitness ::= { id-cmc 23 } 1789 The POP Link Witness control has the ASN.1 definition: 1791 PopLinkWitness ::= OCTET STRING 1793 For this control, SHA-1 is used as the key generation algorithm. 1794 HMAC-SHA1 is used as the mac algorithm. 1796 6.3.1.3. POP Link Random Control 1798 The POP Link Random control is identified by the OID: 1800 The POP Link Random is identified by the OID: 1802 id-cmc-popLinkRandom ::= { id-cmc 22 } 1804 The POP Link Random control has the ASN.1 definition: 1806 PopLinkRandom ::= OCTET STRING 1808 6.3.2. Shared-secret/subject DN linking 1810 The second technique to link identity and POP information is to link 1811 a particular subject distinguished name (subject DN) to the shared- 1812 secrets that are distributed out-of-band and to require that clients 1813 using the shared-secret to prove identity include that exact subject 1814 DN in every certification request. It is expected that many client- 1815 server connections that use shared-secret based proof-of-identity 1816 will use this mechanism. (It is common not to omit the subject DN 1817 information from the certification request.) 1819 When the shared-secret is generated and transferred out-of-band to 1820 initiate the registration process (Section 6.2), a particular subject 1821 DN is also associated with the shared-secret and communicated to the 1822 client. (The subject DN generated MUST be unique per entity in 1823 accordance with the CA policy; a null subject DN cannot be used. A 1824 common practice could be to place the identification value as part of 1825 the subject DN.) When the client generates the Full PKI Request, it 1826 MUST use these two pieces of information as follows: 1828 1. The client MUST include the specific subject DN that it received 1829 along with the shared-secret as the subject name in every 1830 certification request (PKCS #10 and/or CRMF) in the Full PKI 1831 Request. The subject names in the certification requests MUST 1832 NOT be null. 1834 2. The client MUST include an Identity Proof control (Section 6.2.2) 1835 or Identity Proof Version 2 (Section 6.2.1), derived from the 1836 shared-secret, in the Full PKI Request. 1838 The server receiving this message MUST (a) validate the Identity 1839 Proof control and then, (b) check that the subject DN included in 1840 each certification request matches that associated with the shared- 1841 secret. If either of these checks fails the certification request 1842 MUST be rejected. 1844 6.3.3. Renewal and Re-Key Messages 1846 When doing a renewal or re-key certification request, linking 1847 identity and POP information is simple. The client copies the 1848 subject DN for a current signing certificate into the subject name 1849 field of each certification request that is made. The POP for each 1850 certification request will now cover that information. The outmost 1851 signature layer is created using the current signing certificate, 1852 which allows the original identity to be associated with the 1853 certification request. Since the name in the current signing 1854 certificate and the names in the certification requests match, the 1855 necessary linking has been achieved. 1857 6.4. Data Return Control 1859 The Data Return control allows clients to send arbitrary data 1860 (usually some type of internal state information) to the server and 1861 to have the data returned as part of the Full PKI Response. Data 1862 placed in a Data Return control is considered to be opaque to the 1863 server. The same control is used for both Full PKI Requests and 1864 Responses. If the Data Return control appears in a Full PKI Request, 1865 the server MUST return it as part of the PKI Response. 1867 In the event that the information in the Data Return control needs to 1868 be confidential, it is expected that the client would apply some type 1869 of encryption to the contained data, but the details of this are 1870 outside the scope of this specification. 1872 The Data Return control is identified by the OID: 1874 id-cmc-dataReturn ::= { id-cmc 4 } 1876 The Data Return control has the ASN.1 definition: 1878 DataReturn ::= OCTET STRING 1880 A client could use this control to place an identifier marking the 1881 exact source of the private key material. This might be the 1882 identifier of a hardware device containing the private key. 1884 6.5. RA Certificate Modification Controls 1886 These controls exist for RAs to be able to modify the contents of a 1887 certification request. Modifications might be necessary for various 1888 reasons. These include: addition of certificate extensions or 1889 modification of subject and/or subject alternative names. 1891 Two controls exist for this purpose. The first control, Modify 1892 Certificate Request (Section 6.5.1), allows the RA to replace or 1893 remove of any field in the certificate. The second control, Add 1894 Extensions (Section 6.5.2), only allows for the addition of 1895 extensions. 1897 6.5.1. Modify Certificate Request Control 1899 The Modify Certificate Request control is used by RAs to change 1900 fields in a requested certificate. 1902 The Modify Certificate Request control is identified by the OID: 1904 id-cmc-modCertTemplate ::= { id-cmc 31 } 1906 The Modify Certificate Request has the ASN.1 definition: 1908 ModCertTemplate ::= SEQUENCE { 1909 pkiDataReference BodyPartPath, 1910 certReferences BodyPartList, 1911 replace BOOLEAN DEFAULT TRUE, 1912 certTemplate CertTemplate 1913 } 1915 The fields in ModCertTemplate have the following meaning: 1917 pkiDataReference is the path to the PKI Request containing 1918 certification request(s) to be modified. 1920 certReferences refers to one or more certification requests in the 1921 PKI Request referenced by pkiDataReference to be modified. Each 1922 BodyPartID of the certReferences sequence MUST be equal to either 1923 the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the 1924 certReqId of the CertRequest within a CertReqMsg (CRMF). By 1925 definition, the certificate extensions included in the 1926 certTemplate field are applied to every certification request 1927 referenced in the certReferences sequence. If a request 1928 corresponding to bodyPartID cannot be found, the CMCFailInfo with 1929 a value of badRequest is returned that references this control. 1931 replace specifies if the target certification request is to be 1932 modified by replacing or deleting fields. If the value is TRUE, 1933 the data in this control replaces the data in the target 1934 certification request. If the value is FALSE, the data in the 1935 target certification request is deleted. The action is slightly 1936 different for the extensions field of certTemplate, each extension 1937 is treated individually rather than as a single unit. 1939 certTemplate is a certificate template object [CRMF]. If a field is 1940 present and replace is TRUE, it replaces that field in the 1941 certification request. If the field is present and replace is 1942 FALSE, the field in the certification request is removed. If the 1943 field is absent, no action is performed. Each extension is 1944 treated as a single field. 1946 Servers MUST be able to process all extensions defined, but not 1947 prohibited, in [PKIXCERT]. Servers are not required to be able to 1948 process every X.509v3 extension transmitted using this protocol, nor 1949 are they required to be able to process other, private extensions. 1950 Servers are not required to put all RA-requested extensions into a 1951 certificate. Servers are permitted to modify RA-requested 1952 extensions. Servers MUST NOT alter an extension so as to reverse the 1953 meaning of a client-requested extension. If a certification request 1954 is denied due to the inability to handle a requested extension and a 1955 Full PKI Response is returned, the server MUST return a CMCFailInfo 1956 value with the value of unsupportedExt. 1958 If a certification request is the target of multiple Modify 1959 Certificate Request controls, the behavior is: 1961 o If control A exists in a layer that contains the layer of control 1962 B, control A MUST override control B. In other words, controls 1963 should be applied from the innermost layer to the outermost layer. 1965 o If control A and control B are in the same PKIData (i.e. the same 1966 wrapping layer), the order of application is non-determinate. 1968 The same order of application is used if a certification request is 1969 the target of both a Modify Certificate Request control and an Add 1970 Extensions control. 1972 6.5.2. Add Extensions Control 1974 The Add Extensions control has been deprecated in favor of the Modify 1975 Certificate Request control. It was replaced so that fields in the 1976 certification request other than extensions could be modified. 1978 The Add Extensions control is used by RAs to specify additional 1979 extensions that are to be included in certificates. 1981 The Add Extensions control is identified by the OID: 1983 id-cmc-addExtensions ::= { id-cmc 8 } 1985 The Add Extensions control has the ASN.1 definition: 1987 AddExtensions ::= SEQUENCE { 1988 pkiDataReference BodyPartID, 1989 certReferences SEQUENCE OF BodyPartID, 1990 extensions SEQUENCE OF Extension 1991 } 1993 The fields in AddExtensions have the following meaning: 1995 pkiDataReference contains the body part identity of the embedded 1996 certification request. 1998 certReferences is a list of references to one or more of the 1999 certification requests contained within a PKIData. Each body part 2000 identifier of the certReferences sequence MUST be equal to either 2001 the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the 2002 certReqId of the CertRequest within a CertReqMsg (CRMF). By 2003 definition, the listed extensions are to be applied to every 2004 certification request referenced in the certReferences sequence. 2005 If a certification request corresponding to bodyPartID cannot be 2006 found, the CMCFailInfo with a value of badRequest is returned 2007 referencing this control. 2009 extensions is a sequence of extensions to be applied to the 2010 referenced certification requests. 2012 Servers MUST be able to process all extensions defined, but not 2013 prohibited, in [PKIXCERT]. Servers are not required to be able to 2014 process every X.509v3 extension transmitted using this protocol, nor 2015 are they required to be able to process other, private extensions. 2016 Servers are not required to put all RA-requested extensions into a 2017 certificate. Servers are permitted to modify RA-requested 2018 extensions. Servers MUST NOT alter an extension so as to reverse the 2019 meaning of a client-requested extension If a certification request is 2020 denied due to the inability to handle a requested extension and a 2021 response is returned, the server MUST return a CMCFailInfo with the 2022 value of unsupportedExt. 2024 If multiple Add Extensions controls exist in a Full PKI Request, the 2025 exact behavior is left up to the CA policy. However it is 2026 recommended that the following policy be used. These rules would be 2027 applied to individual extensions within an Add Extensions control (as 2028 opposed to an "all or nothing" approach). 2030 1. If the conflict is within a single PKIData, the certification 2031 request would be rejected with a CMCFailInfo value of badRequest. 2033 2. If the conflict is between different PKIData, the outermost 2034 version of the extension would be used (allowing an RA to 2035 override the requested extension). 2037 6.6. Transaction Identifier, Sender and Recipient Nonce Controls 2039 Transactions are identified and tracked with a transaction 2040 identifier. If used, clients generate transaction identifiers and 2041 retain their value until the server responds with a Full PKI Response 2042 that completes the transaction. Servers correspondingly include 2043 received transaction identifiers in the Full PKI Response. 2045 The Transaction Identifier control is identified by the OID: 2047 id-cmc-transactionId ::= { id-cmc 5 } 2049 The Transaction Identifier control has the ASN.1 definition: 2051 TransactionId ::= INTEGER 2053 The Transaction Identifier control identifies a given transaction. 2054 It is used by client and server to manage the state of an operation. 2055 Clients MAY include a Transaction Identifier control in request. If 2056 the original request contains a Transaction Identifier control, all 2057 subsequent requests and responses MUST include the same Transaction 2058 Identifier control. 2060 Replay protection is supported through the use of the Sender and 2061 Recipient Nonce controls. If nonces are used, in the first message 2062 of a transaction, a Recipient Nonce control is not transmitted; a 2063 Sender Nonce control is included by the transaction originator and 2064 retained for later reference. The recipient of a Sender Nonce 2065 control reflects this value back to the originator as a Recipient 2066 Nonce control and includes its own Sender Nonce control. Upon 2067 receipt by the transaction originator of this response, the 2068 transaction originator compares the value of Recipient Nonce control 2069 to its retained value. If the values match, the message can be 2070 accepted for further security processing. The received value for a 2071 Sender Nonce control is also retained for inclusion in the next 2072 message associated with the same transaction. 2074 The Sender Nonce and Recipient controls are identified by the OIDs: 2076 id-cmc-senderNonce ::= { id-cmc 6 } 2077 id-cmc-recipientNonce ::= { id-cmc 7 } 2079 The Sender Nonce control has the ASN.1 definition: 2081 SenderNonce ::= OCTET STRING 2083 The Recipient Nonce control has the ASN.1 definition: 2085 RecepientNonce ::= OCTET STRING 2087 Clients MAY include a Sender Nonce control in the initial PKI 2088 Request. If a message includes a Sender Nonce control, the response 2089 MUST include the transmitted value of the previously received Sender 2090 Nonce control as a Recipient Nonce control and include a new value as 2091 its Sender Nonce control. 2093 6.7. Encrypted and Decrypted POP Controls 2095 Servers MAY require that this POP method be used only if another POP 2096 method is unavailable. Servers SHOULD reject all certification 2097 requests contained within a PKIData if any required POP is missing 2098 for any element within the PKIData. 2100 Many servers require proof that the entity that generated the 2101 certification request actually possesses the corresponding private 2102 component of the key pair. For keys that can be used as signature 2103 keys, signing the certification request with the private key serves 2104 as a POP on that key pair. With keys that can only be used for 2105 encryption operations, POP MUST be performed by forcing the client to 2106 decrypt a value. See Section 5 of [CRMF] for a detailed discussion 2107 of POP. 2109 By necessity, POP for encryption-only keys cannot be done in one 2110 round-trip, since there are four distinct steps: 2112 1. Client tells the server about the public component of a new 2113 encryption key pair. 2115 2. Server sends the client a POP challenge, encrypted with the 2116 presented public encryption key. 2118 3. Client decrypts the POP challenge using the private key that 2119 corresponds to the presented public key and sends the plaintext 2120 back to the server. 2122 4. Server validates the decrypted POP challenge and continues 2123 processing the certification request. 2125 CMC defines two different controls. The first deals with the 2126 encrypted challenge sent from the server to the user in step 2. The 2127 second deals with the decrypted challenge sent from the client to the 2128 server in step 3. 2130 The Encrypted POP control is used to send the encrypted challenge 2131 from the server to the client as part of the PKIResponse. (Note that 2132 it is assumed that the message sent in Step 1 above is a Full PKI 2133 Request and that the response in step 2 is a Full PKI Response 2134 including a CMCFailInfo specifying that a POP is explicitly required, 2135 and providing the POP challenge in the encryptedPOP control.) 2137 The Encrypted POP control is identified by the OID: 2139 id-cmc-encryptedPOP ::= { id-cmc 9 } 2141 The Encrypted POP control has the ASN.1 definition: 2143 EncryptedPOP ::= SEQUENCE { 2144 request TaggedRequest, 2145 cms ContentInfo, 2146 thePOPAlgID AlgorithmIdentifier, 2147 witnessAlgID AlgorithmIdentifier, 2148 witness OCTET STRING 2149 } 2151 The Decrypted POP control is identified by the OID: 2153 id-cmc-decryptedPOP ::= { id-cmc 10 } 2155 The Decrypted POP control has the ASN.1 definition: 2157 DecryptedPOP ::= SEQUENCE { 2158 bodyPartID BodyPartID, 2159 thePOPAlgID AlgorithmIdentifier, 2160 thePOP OCTET STRING 2161 } 2163 The encrypted POP algorithm works as follows: 2165 1. The server randomly generates the POP Proof Value and associates 2166 it with the request. 2168 2. The server returns the Encrypted POP control with the following 2169 fields set: 2171 request is the original certification request (it is included 2172 here so the client need not keep a copy of the request), 2174 cms is an EnvelopedData, the encapsulated content type being id- 2175 data and the content being the POP Proof Value, this value 2176 needs to be long enough that one cannot reverse the value from 2177 the witness hash. If the certification request contains a 2178 Subject Key Identifier (SKI) extension, then the recipient 2179 identifier SHOULD be the SKI. If the issuerAndSerialNumber 2180 form is used, the IssuerName MUST be encoded as NULL and the 2181 SerialNumber as the bodyPartID of the certification request, 2183 thePOPAlgID identifies the algorithm to be used in computing the 2184 return POP value, 2186 witnessAlgID identifies the hash algorithm used on POP Proof 2187 Value to create the field witness, 2189 witness is the hashed value of POP Proof Value. 2191 3. The client decrypts the cms field to obtain the POP Proof Value. 2192 The client computes H(POP Proof Value) using the witnessAlgID and 2193 compares to the value of witness. If the values do not compare 2194 or the decryption is not successful, the client MUST abort the 2195 enrollment process. The client aborts the process by sending a 2196 request containing a CMC Status Info control with CMCFailInfo 2197 value of popFailed. 2199 4. The client creates the Decrypted POP control as part of a new 2200 PKIData. The fields in the DecryptedPOP are: 2202 bodyPartID refers to the certification request in the new PKI 2203 Request, 2205 thePOPAlgID is copied from the encryptedPOP, 2207 thePOP contains the possession proof. This value is computed by 2208 thePOPAlgID using the POP Proof Value and the request. 2210 5. The server then re-computes the value of thePOP from its cached 2211 value and the request and compares to the value of thePOP. If 2212 the values do not match, the server MUST NOT issue the 2213 certificate. The server MAY re-issue a new challenge or MAY fail 2214 the request altogether. 2216 When defining the algorithms for thePOPAlgID and witnessAlgID care 2217 must be taken to ensure that the result of witnessAlgID is not a 2218 useful value to shortcut the computation with thePOPAlgID. The POP 2219 Proof Value is used as the secret value in the HMAC algorithm and the 2220 request is used as the data. If the POP Proof Value is greater than 2221 64 bytes, only the first 64 bytes of the POP Proof Value is used as 2222 the secret. 2224 One potential problem with the algorithm above is the amount of state 2225 that a CA needs to keep in order to verify the returned POP value. 2226 The following describes one of many possible ways of addressing the 2227 problem by reducing the amount of state kept on the CA to a single 2228 (or small set) of values. 2230 1. Server generates random seed x, constant across all requests. 2231 (The value of x would normally be altered on a regular basis and 2232 kept for a short time afterwards.) 2234 2. For certification request R, server computes y = F(x,R). F can 2235 be, for example, HMAC-SHA1(x,R). All that's important for 2236 statelessness is that y be consistently computable with only 2237 known state constant x and function F, other inputs coming from 2238 the certification request structure. y should not be predictable 2239 based on knowledge of R, thus the use of a One-Way-Function like 2240 HMAC-SHA1. 2242 6.8. RA POP Witness Control 2244 In a certification request scenario that involves an RA, the CA may 2245 allow (or require) that the RA perform the POP protocol with the 2246 entity that generated the certification request. In this case, the 2247 RA needs a way to inform the CA it has done the POP. The RA POP 2248 Witness control addresses this issue. 2250 The RA POP Witness control is identified by the OID: 2252 id-cmc-lraPOPWitness ::= { id-cmc 11 } 2254 The RA POP Witness control has the ASN.1 definition: 2256 LraPopWitness ::= SEQUENCE { 2257 pkiDataBodyid BodyPartID, 2258 bodyIds SEQUENCE of BodyPartID 2259 } 2261 The fields in LraPOPWitness have the following meaning: 2263 pkiDataBodyid contains the body part identifier of the nested 2264 TaggedContentInfo containing the client's Full PKI Request. 2265 pkiDataBodyid is set to 0 if the request is in the current 2266 PKIData. 2268 bodyIds is a list of certification requests for which the RA has 2269 performed an out-of-band authentication. The method of 2270 authentication could be archival of private key material, 2271 challenge-response or other means. 2273 If a certification server does not allow an RA to do the POP 2274 verification, it returns a CMCFailInfo with the value of popFailed. 2275 The CA MUST NOT start a challenge-response to re-verify the POP 2276 itself. 2278 6.9. Get Certificate Control 2280 Everything described in this section is optional to implement. 2282 The Get Certificate control is used to retrieve a previously issued 2283 certificate from a certificate repository. A CA, an RA or an 2284 independent service may provide this repository. The clients 2285 expected to use this facility are those where a fully deployed 2286 directory is either infeasible or undesirable. 2288 The Get Certificate control is identified by the OID: 2290 id-cmc-getCert ::= { id-cmc 15 } 2292 The Get Certificate control has the ASN.1 definition: 2294 GetCert ::= SEQUENCE { 2295 issuerName GeneralName, 2296 serialNumber INTEGER } 2298 The fields in GetCert have the following meaning: 2300 issuerName is the name of the certificate issuer. 2302 serialNumber identifies the certificate to be retrieved. 2304 The server that responds to this request places the requested 2305 certificate in the certificates field of a SignedData. If the Get 2306 Certificate control is the only control in a Full PKI Request, the 2307 response should be a Simple PKI Response. 2309 6.10. Get CRL Control 2311 Everything described in this section is optional to implement. 2313 The Get CRL control is used to retrieve CRLs from a repository of 2314 CRLs. A CA, an RA or an independent service may provide this 2315 repository. The clients expected to use this facility are those 2316 where a fully deployed directory is either infeasible or undesirable. 2318 The Get CRL control is identified by the OID: 2320 id-cmc-getCRL ::= { id-cmc 16 } 2322 The Get CRL control has the ASN.1 definition: 2324 GetCRL ::= SEQUENCE { 2325 issuerName Name, 2326 cRLName GeneralName OPTIONAL, 2327 time GeneralizedTime OPTIONAL, 2328 reasons ReasonFlags OPTIONAL } 2330 The fields in a GetCRL have the following meanings: 2332 issuerName is the name of the CRL issuer. 2334 cRLName may be the value of CRLDistributionPoints in the subject 2335 certificate or equivalent value in the event the certificate does 2336 not contain such a value. 2338 time is used by the client to specify from among potentially several 2339 issues of CRL that one whose thisUpdate value is less than but 2340 nearest to the specified time. In the absence of a time 2341 component, the CA always returns with the most recent CRL. 2343 reasons is used to specify from among CRLs partitioned by revocation 2344 reason. Implementers should bear in mind that while a specific 2345 revocation request has a single CRLReason code - and consequently 2346 entries in the CRL would have a single CRLReason code value - a 2347 single CRL can aggregate information for one or more reasonFlags. 2349 A server responding to this request places the requested CRL in the 2350 crls field of a SignedData. If the Get CRL control is the only 2351 control in a Full PKI Request, the response should be a Simple PKI 2352 Response. 2354 6.11. Revocation Request Control 2356 The Revocation Request control is used to request that a certificate 2357 be revoked. 2359 The Revocation Request control is identified by the OID: 2361 id-cmc-revokeRequest ::= { id-cmc 17 } 2363 The Revocation Request control has the ASN.1 definition: 2365 RevokeRequest ::= SEQUENCE { 2366 issuerName Name, 2367 serialNumber INTEGER, 2368 reason CRLReason, 2369 invalidityDate GeneralizedTime OPTIONAL, 2370 sharedSecret OCTET STRING OPTIONAL, 2371 comment UTF8string OPTIONAL } 2373 The fields of RevokeRequest have the following meaning: 2375 issuerName is the issuerName of the certificate to be revoked. 2377 serialNumber is the serial number of the certificate to be revoked. 2379 reason is the suggested CRLReason code for why the certificate is 2380 being revoked. The CA can use this value at its discretion in 2381 building the CRL. 2383 invalidityDate is the suggested value for the Invalidity Date CRL 2384 Extension. The CA can use this value at its discretion in 2385 building the CRL. 2387 sharedSecret is a secret value registered by the EE when the 2388 certificate was obtained to allow for revocation of a certificate 2389 in the event of key loss. 2391 comment is a human readable comment. 2393 For a revocation request to be reliable in the event of a dispute, a 2394 strong proof-of-origin is required. However, in the instance when an 2395 EE has lost use of its signature private key, it is impossible for 2396 the EE to produce a digital signature (prior to the certification of 2397 a new signature key pair). The Revoke Request control allows the EE 2398 to send the CA a shared-secret that may be used as an alternative 2399 authenticator in the instance of loss of use of the EE's signature 2400 private key. The acceptability of this practice is a matter of local 2401 security policy. 2403 It is possible to sign the revocation for the lost certificate with a 2404 different certificate in some circumstances. A client can sign a 2405 revocation for an encryption key with a signing certificate if the 2406 name information matches. Similarly an administrator or RA can be 2407 assigned the ability to revoke the certificate of a third party. 2408 Acceptance of the revocation by the server depends on local policy in 2409 these cases. 2411 Clients MUST provide the capability to produce a digitally signed 2412 Revocation Request control. Clients SHOULD be capable of producing 2413 an unsigned Revocation Request control containing the EE shared- 2414 secret. (The unsigned message consisting of a SignedData with no 2415 signatures.) If a client provides shared-secret based self- 2416 revocation, the client MUST be capable of producing a Revocation 2417 Request control containing the shared-secret. Servers MUST be 2418 capable of accepting both forms of revocation requests. 2420 The structure of an unsigned, shared-secret based revocation request 2421 is a matter of local implementation. The shared-secret does not need 2422 to be encrypted when sent in a Revocation Request control. The 2423 shared-secret has a one-time use (i.e., it is used to request 2424 revocation of the certificate), and public knowledge of the shared- 2425 secret after the certificate has been revoked is not a problem. 2426 Clients need to inform users that the same shared-secret SHOULD NOT 2427 be used for multiple certificates. 2429 A Full PKI Response MUST be returned for a revocation request. 2431 6.12. Registration and Response Information Controls 2433 The Registration Information control allows for clients to pass 2434 additional information as part a Full PKI Request. 2436 The Registration Information control is identified by the OID: 2438 id-cmc-regInfo ::= { id-cmc 18 } 2440 The Registration Information control has the ASN.1 definition: 2442 RegInfo ::= OCTET STRING 2444 The content of this data is based on bilateral agreement between the 2445 client and server. 2447 The Response Information control allows a server to return additional 2448 information as part of a Full PKI Response. 2450 The Response Information control is identified by the OID: 2452 id-cmc-responseInfo ::= { id-cmc 19 } 2454 The Response Information control has the ASN.1 definition: 2456 ResponseInfo ::= OCTET STRING 2458 The content of this data is based on bilateral agreement between the 2459 client and the server. 2461 6.13. Query Pending Control 2463 In some environments, process requirements for manual intervention or 2464 other identity checks can delay the return of the certificate. The 2465 Query Pending control allows clients to query a server about the 2466 state of a pending certification request. The server returns a 2467 pendToken as part of the Extended CMC Status Info and the CMC Status 2468 Info controls (in the otherInfo field). The client copies the 2469 pendToken into the Query Pending control to identify the correct 2470 certification request to the server. The server returns a suggested 2471 time for the client to query for the state of a pending certification 2472 request. 2474 The Query Pending control is identified by the OID: 2476 id-cmc-queryPending ::= { id-cmc 21 } 2478 The Query Pending control has the ASN.1 definition: 2480 QueryPending ::= OCTET STRING 2482 If a server returns a pending or partial CMCStatusInfo (the 2483 transaction is still pending), the otherInfo MAY be omitted. If the 2484 otherInfo is not omitted, the value of 'pendInfo' MUST be the same as 2485 the original pendInfo value. 2487 6.14. Confirm Certificate Acceptance Control 2489 Some CAs require that clients give a positive confirmation that the 2490 certificates issued to the EE are acceptable. The Confirm 2491 Certificate Acceptance control is used for that purpose. If the CMC 2492 Status Info on a PKI Response is confirmRequired, then the client 2493 MUST return a Confirm Certificate Acceptance control contained in a 2494 Full PKI Request. 2496 Clients SHOULD wait for the PKI Response from the server that the 2497 confirmation has been received before using the certificate for any 2498 purpose. 2500 The Confirm Certificate Acceptance control is identified by the OID: 2502 id-cmc-confirmCertAcceptance ::= { id-cmc 24 } 2504 The Confirm Control Acceptance control has the ASN.1 definition: 2506 CMCCertId ::= IssuerAndSerialNumber 2508 CMCCertId contains the issuer and serial number of the certificate 2509 being accepted. 2511 Servers MUST return a Full PKI Response for a Confirm Certificate 2512 Acceptance control. 2514 Note that if the CA includes this control, there will be two full 2515 round trips of messages. 2517 1. The client sends the certification request to the CA. 2519 2. The CA returns a Full PKI Response with the certificate and this 2520 control. 2522 3. The client sends a Full PKI Request to the CA with an Extended 2523 CMC Status Info control accepting and a Confirm Certificate 2524 Acceptance control or an Extended CMC Status Info control 2525 rejecting the certificate. 2527 4. The CA sends a Full PKI Response to the client with an Extended 2528 CMC Status Info of success. 2530 6.15. Publish Trust Anchors Control 2532 The Publish Trust Anchors control allows for the distribution of set 2533 trust anchors from a central authority to an EE. The same control is 2534 also used to update the set of trust anchors. Trust anchors are 2535 distributed in the form of certificates. These are expected, but not 2536 required, to be self-signed certificates. Information is extracted 2537 from these certificates to set the inputs to the certificates 2538 validation algorithm in section 6.1.1 of [PKIXCERT]. 2540 The Publish Trust Anchors control is identified by the OID: 2542 id-cmc-trustedAnchors ::= { id-cmc 26 } 2544 The Publish Trust Anchors control has the ASN.1 definition: 2546 PublishTrustAnchors ::= SEQUENCE { 2547 seqNumber INTEGER, 2548 hashAlgorithm AlgorithmIdentifier, 2549 anchorHashes SEQUENCE OF OCTET STRING 2550 } 2552 The fields in PublishTrustAnchors have the following meaning: 2554 seqNumber is an integer indicating the location within a sequence of 2555 updates. 2557 hashAlgorithm is the identifier and parameters for the hash 2558 algorithm that is used in computing the values of the anchorHashes 2559 field. All implementations MUST implement SHA-1 for this field. 2561 anchorHashes are the hashes for the certificates that are to be 2562 treated as trust anchors by the client. The actual certificates 2563 are transported in the certificate bag of the containing 2564 SignedData structure. 2566 While it is recommended that the sender place the certificates that 2567 are to be trusted in the PKI Response, it is not required as the 2568 certificates should be obtainable using normal discovery techniques. 2570 Prior to accepting the trust anchors changes, a client MUST at least 2571 do the following: validate the signature on the PKI Response to a 2572 current trusted anchor, check with policy to ensure that the signer 2573 is permitted to use the control, validate that the authenticated 2574 publish time in the signature is near to the current time and 2575 validate the sequence number is greater than the previously used one. 2577 In the event that multiple agents publish a set of trust anchors, it 2578 is up to local policy to determine how the different trust anchors 2579 should be combined. Clients SHOULD be able to handle the update of 2580 multiple trust anchors independently. 2582 NOTE: Clients that handle this control must use extreme care in 2583 validating that the operation is permissible. Incorrect handling of 2584 this control allows for an attacker to change the set of trust 2585 anchors on the client. 2587 6.16. Authenticated Data Control 2589 The Authenticated Data control allows a server to provide data back 2590 to the client in an authenticated manner. This control uses the 2591 Authenticated Data structure to allow for validation of the data. 2592 This control is used where the client has a shared-secret and a 2593 secret identifier with the server, but where a trust anchor has not 2594 yet been downloaded onto the client so that a signing certificate for 2595 the server cannot be validated. The specific case that this control 2596 was created for use with the Publish Trust Anchors control 2597 Section 6.15, but may be used in other cases as well. 2599 The Authenticated Data control is identified by the OID: 2601 id-cmc-authData ::= { id-cmc 27 } 2603 The Authenticated Data control has the ASN.1 definition: 2605 AuthPublish ::= BodyPartID 2607 AuthPublish is a body part identifier that refers to a member of the 2608 cmsSequence element for the current PKI Response or PKI Data. The 2609 cmsSequence element is AuthenticatedData. The encapsulated content 2610 is an id-cct-PKIData, there will then be controls in the 2611 controlSequence that would need to be processed (one example being 2612 the Publish Trust Anchors control Section 6.15). 2614 If the authentication operation fails, the CMCFailInfo authDataFail 2615 is returned. 2617 6.17. Batch Request and Response Controls 2619 These controls allow for an RA to collect multiple requests together 2620 into a single Full PKI Request and forward it to a CA. The server 2621 would then process the requests and return the results in a Full PKI 2622 Response. 2624 The Batch Request control is identified by the OID: 2626 id-cmc-batchRequests ::= {id-cmc 28} 2628 The Batch Response control is identified by the OID: 2630 id-cmc-batchResponses ::= {id-cmc 29} 2632 Both the Batch Request and Batch Response controls have the ASN.1 2633 definition: 2635 BodyPartList ::= SEQUENCE of BodyPartID 2637 The data associated with these controls is a set of body part 2638 identifiers. The collection of requests/responses are individually 2639 placed in the cmsSequence of the PKIData/PKIResponse. The body part 2640 identifiers of these elements are then placed in the body part list. 2642 When a server processes a Batch Request control, it MAY return the 2643 responses in one or more PKI Responses. A CMCStatus value of partial 2644 is returned on all but the last PKI Response. The CMCStatus would be 2645 success if the Batch Requests control was processed, the responses 2646 are created with their own CMCStatus code. Errors on individual 2647 requests are not propagated up to the top level. 2649 When a PKI Response with a CMCStatus value of partial is returned, 2650 the Query Pending control (Section 6.13) is used to retrieve 2651 additional results. The returned status includes a suggested time 2652 after which the client should ask for the additional results. 2654 6.18. Publication Information Control 2656 The Publication Information control allows for modifying publication 2657 of already issued certificates, both for publishing and removal from 2658 publication. A common usage for this control is to remove an 2659 existing certificate from publication during a re-key operation. 2660 This control should always be processed after the issuance of new 2661 certificates and revocation requests. This control should not be 2662 processed if a certificate failed to be issued. 2664 The Publication Information control is identified by the OID: 2666 id-cmc-publishCert ::= { id-cmc 30 } 2668 The Publication Information control has the ASN.1 definition: 2670 CMCPublicationInfo ::= SEQUENCE { 2671 hashAlg AlgorithmIdentifier, 2672 certHashes SEQUENCE of OCTET STRING, 2673 pubInfo PKIPublicationInfo 2675 PKIPublicationInfo ::= SEQUENCE { 2676 action INTEGER { 2677 dontPublish (0), 2678 pleasePublish (1) }, 2679 pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } 2681 -- pubInfos MUST NOT be present if action is "dontPublish" 2682 -- (if action is "pleasePublish" and pubInfos is omitted, 2683 -- "dontCare" is assumed) 2685 SinglePubInfo ::= SEQUENCE { 2686 pubMethod INTEGER { 2687 dontCare (0), 2688 x500 (1), 2689 web (2), 2690 ldap (3) }, 2691 pubLocation GeneralName OPTIONAL } 2692 } 2694 The fields in CMCPublicationInfo have the following meaning: 2696 hashAlg is the algorithm identifier of the hash algorithm used to 2697 compute the values in certHashes. 2699 certHashes are the hashes of the certificates for which publication 2700 is to change. 2702 pubInfo is the information where and how the certificates should be 2703 published. The fields in pubInfo (taken from [CRMF]) have the 2704 following meanings: 2706 action indicates the action the service should take. It has two 2707 values: 2709 dontPublish indicates that the PKI should not publish the 2710 certificate (this may indicate that the requester intends to 2711 publish the certificate him/herself). dontPublish has the 2712 added connotation of removing from publication the 2713 certificate if it is already published. 2715 pleasePublish indicates that the PKI MAY publish the 2716 certificate using whatever means it chooses unless pubInfos 2717 is present. Omission of the the CMC Publication Info 2718 control results in the same behavior. 2720 pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the 2721 PKI SHOULD publish the certificate. 2723 A single certificate SHOULD NOT appear in more than one Publication 2724 Information control. The behavior is undefined in the event that it 2725 does. 2727 6.19. Control Processed Control 2729 The Control Processed control allows an RA to indicate to subsequent 2730 control processors that a specific control has already been 2731 processed. This permits an RA in the middle of a processing stream 2732 to process a control defined either in a local context or in a 2733 subsequent document. 2735 The Control Processed control is identified by the OID: 2737 id-cmc-controlProcessed ::= { id-cmc 32 } 2739 The Control Processed control has the ASN.1 definition: 2741 ControlList ::= SEQUENCE { 2742 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference 2743 } 2745 bodyList is a series of body part identifiers that form a path to 2746 each of the controls that were processed by the RA. This control 2747 is only needed for those controls which are not part of this 2748 standard and thus would cause an error condition of a server 2749 attempting to deal with a control which is not defined in this 2750 document. No error status is needed since an error causes the RA 2751 to return the request to the client with the error rather than 2752 passing the request on to the next server in the processing list. 2754 7. Registration Authorities 2756 This specification permits the use of RAs. An RA sits between the EE 2757 and the CA. From the EE's perspective, the RA appears to be the CA 2758 and from the server the RA appears to be a client. RAs receive the 2759 PKI Requests, perform local processing and then forward them onto 2760 CAs. Some of the types of local processing that an RA can perform 2761 include: 2763 o Batching multiple PKI Requests together, 2765 o Performing challenge/response POP proofs, 2767 o Adding private or standardized certificate extensions to all 2768 certification requests, 2770 o Archiving private key material, 2772 o Routing requests to different CAs. 2774 When an RA receives a PKI Request it has three options: it may 2775 forward the PKI Request without modification, it may add a new 2776 wrapping layer to the PKI Request, or it may remove one or more 2777 existing layers and add a new wrapping layer. 2779 When an RA adds a new wrapping layer to a PKI Request it creates a 2780 new PKIData. The new layer contains any controls required (for 2781 example if the RA does the POP proof for an encryption key or the Add 2782 Extension control to modify a PKI Request) and the client PKI 2783 Request. The client PKI Request is placed in the cmsSequence if it 2784 is a Full PKI Request and in the reqSequence if it is a Simple PKI 2785 Request. If an RA is batching multiple client PKI Requests together, 2786 then each client PKI Request is placed into the appropriate location 2787 in the RA's PKIData object along with all relevant controls. 2789 If multiple RAs are in the path between the EE and the CA, this will 2790 lead to multiple wrapping layers on the request. 2792 In processing a PKI Request, an RA MUST NOT alter any certification 2793 requests (PKCS #10 or CRMF) as any alteration would invalidate the 2794 signature on the certification request and thus the POP for the 2795 private key. 2797 An example of how this would look is illustrated by the following 2798 figure: 2800 SignedData (by RA) 2801 PKIData 2802 controlSequence 2803 RA added control statements 2804 reqSequence 2805 Zero or more Simple PKI Requests from clients 2806 cmsSequence 2807 Zero or more Full PKI Requests from clients 2808 SignedData (signed by client) 2809 PKIData 2811 Under some circumstances an RA is required to remove wrapping layers. 2812 The following sections look at the processing required if encryption 2813 layers and signing layers need to be removed. 2815 7.1. Encryption Removal 2817 There are two cases that require an RA to remove or change encryption 2818 in a PKI Request. In the first case the encryption was applied for 2819 the purposes of protecting the entire PKI Request from unauthorized 2820 entities. If the CA does not have a Recipient Info entry in the 2821 encryption layer, the RA MUST remove the encryption layer. The RA 2822 MAY add a new encryption layer with or without adding a new signing 2823 layer. 2825 The second change of encryption that may be required is to change the 2826 encryption inside of a signing layer. In this case the RA MUST 2827 remove all signing layers containing the encryption. All control 2828 statements MUST be merged according to local policy rules as each 2829 signing layer is removed and the resulting merged controls MUST be 2830 placed in a new signing layer provided by the RA. If the signing 2831 layer provided by the EE needs to also be removed, the RA can also 2832 remove this layer. 2834 7.2. Signature Layer Removal 2836 Only two instances exist where an RA should remove a signature layer 2837 on a Full PKI Request. If an encryption layer needs to be modified 2838 within the request, or if a CA will not accept secondary delegation 2839 (i.e., multiple RA signatures). In all other situations, RAs SHOULD 2840 NOT remove a signing layer from a PKI Request. 2842 If an RA removes a signing layer from a PKI Request, all control 2843 statements MUST be merged according to local policy rules. The 2844 resulting merged control statements MUST be placed in a new signing 2845 layer provided by the RA. 2847 8. Security Considerations 2849 Mechanisms for thwarting replay attacks may be required in particular 2850 implementations of this protocol depending on the operational 2851 environment. In cases where the CA maintains significant state 2852 information, replay attacks may be detectable without the inclusion 2853 of the optional nonce mechanisms. Implementers of this protocol need 2854 to carefully consider environmental conditions before choosing 2855 whether or not to implement the senderNonce and recipientNonce 2856 controls described in Section 6.6. Developers of state-constrained 2857 PKI clients are strongly encouraged to incorporate the use of these 2858 controls. 2860 Extreme care needs to be taken when archiving a signing key. The 2861 holder of the archived key may have the ability to use the key to 2862 generate forged signatures. There are however reasons why a signing 2863 key should be archived. An archived CA signing key can be recovered 2864 in the event of failure to continue to produced CRLs following a 2865 disaster. 2867 Due care must be taken prior to archiving keys. Once a key is given 2868 to an archiving entity, the archiving entity could use the keys in a 2869 way not conducive to the archiving entity. Users should be made 2870 especially aware that proper verification is made of the certificate 2871 used to encrypt the private key material. 2873 Clients and servers need to do some checks on cryptographic 2874 parameters prior to issuing certificates to make sure that weak 2875 parameters are not used. A description of the small subgroup attack 2876 is provided in [X942]. Methods of avoiding the small subgroup attack 2877 can be found in [SMALL-GROUP]. CMC implementations ought to be aware 2878 of this attack when doing parameter validations. 2880 When using a shared-secret for authentication purposes, the shared- 2881 secret should be generated using good random number techniques 2882 [RANDOM]. User selection of the secret allows for dictionary attacks 2883 to be mounted. 2885 Extreme care must be used when processing the Publish Trust Anchors 2886 control. Incorrect processing can lead to the practice of slamming 2887 where an attacker changes the set of trusted anchors in order to 2888 weaken security. 2890 One method of controlling the use of the Publish Trust Anchors 2891 control is as follows. The client needs to associate with each trust 2892 anchor accepted by the client the source of the trust anchor. 2893 Additionally the client should associate with each trust anchor the 2894 types of messages that the trust anchor is valid for. (I.e., is the 2895 trust anchor used for validating S/MIME messages, TLS or CMC 2896 enrollment messages.) 2898 When a new message is received with a Publish Trust Anchor control, 2899 the client would accept the set of new trust anchors for specific 2900 applications only if the signature validates, the signer of the 2901 message has the required policy approval for updating the trust 2902 anchors and local policy also would allow updating the trust anchors. 2904 9. IANA Considerations 2906 This document defines a number of control objects. These are 2907 identified by Object Identifiers (OIDs). The objects are defined 2908 from an arc delegated by IANA to the PKIX Working Group. No further 2909 action by IANA is necessary for this document or any anticipated 2910 updates. 2912 10. Acknowledgments 2914 The authors and the PKIX Working Group are grateful for the 2915 participation of Xiaoui Lui and Jeff Weinstein in helping to author 2916 the original versions of this document. 2918 The authors would like to thank Brian LaMacchia for his work in 2919 developing and writing up many of the concepts presented in this 2920 document. The authors would also like to thank Alex Deacon and Barb 2921 Fox for their contributions. 2923 11. References 2925 11.1. Normative References 2927 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 2928 RFC 3852, July 2004. 2930 [CRMF] Schaad, J., "Internet X.509 Certification Request Message 2931 Format", RFC 4211, January 2005. 2933 [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof- 2934 of-Possession Algorithms", RFC 2875, June 2000. 2936 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "Diffie-Hellman 2937 Proof-of-Possession Algorithms", RFC 2104, February 1997. 2939 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax 2940 v1.5", RFC 2314, October 1997. 2942 [PKIXCERT] 2943 Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 2944 X.509 Public Key Infrastructure Certificate and 2945 Certificate Revocation List (CRL) Profile", RFC 3280, 2946 April 2002. 2948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2949 Requirement Levels", RFC 2119, BCP 14, March 1997. 2951 11.2. Informational References 2953 [CMC-TRANS] 2954 Schaad, J. and M. Myers, "CMC Transport", 2955 draft-ietf-pkix-cmc-trans-00.txt , December 2004. 2957 [CMC-MUST] 2958 Schaad, J. and M. Myers, "CMC Compliance", 2959 draft-ietf-pkix-cmc-must-00.txt , December 2004. 2961 [DH] Kaliski, B., "PKCS 3: Diffie-Hellman Key Agreement v1.4", 2962 Lost 1900. 2964 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 2965 Internet Protocol", RFC 4301, December 2005. 2967 [PASSWORD] 2968 Burr, W., Dodson, D., and W. Polk, "Electronic 2969 Authentication Guideline", NIST SP 800-63, April 2006. 2971 [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", 2972 PKCS #1, March 1998. 2974 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5", 2975 RFC 2315, October 1997. 2977 [PKCS8] Laboratories, RSA., "PKCS#8: Private-Key Information 2978 Syntax Standard, Version 1.2", November 1993. 2980 [RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker, 2981 ""Randomness Requirements for Security", BCP 106, 2982 RFC 4086, June 2005. 2984 [SMALL-GROUP] 2985 Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 2986 Attacks on the Diffie-Hellman Key Agreement Method for 2987 S/MIME", RFC 2785, March 2000. 2989 [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 2990 L. Repka, "S/MIME Version 2 Message Specification", 2991 RFC 2311, March 1998. 2993 [SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification", 2994 RFC 3851, July 2004. 2996 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 2997 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2999 [X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", 3000 RFC 2631, June 1999. 3002 [RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, 3003 "Certificate Management Messages over CMS", RFC 2797, 3004 April 2000. 3006 Appendix A. ASN.1 Module 3008 EnrollmentMessageSyntax 3009 { iso(1) identified-organization(3) dod(4) internet(1) 3010 security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) } 3012 DEFINITIONS IMPLICIT TAGS ::= 3013 BEGIN 3015 -- EXPORTS All -- 3016 -- The types and values defined in this module are exported for use 3017 -- in the other ASN.1 modules. Other applications may use them for 3018 -- their own purposes. 3020 IMPORTS 3022 -- PKIX Part 1 - Implicit From [PKIXCERT] 3023 GeneralName, CRLReason, ReasonFlags 3024 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3025 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3026 id-pkix1-implicit(19)} 3028 -- PKIX Part 1 - Explicit From [PKIXCERT] 3029 AlgorithmIdentifier, Extension, Name, CertificateSerialNumber 3030 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 3031 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3032 id-pkix1-explicit(18)} 3034 -- Cryptographic Message Syntax FROM [CMS] 3035 ContentInfo, Attribute, IssuerAndSerialNumber 3036 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) 3037 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3038 modules(0) cms-2004(24)} 3040 -- CRMF FROM [CRMF] 3041 CertReqMsg, PKIPublicationInfo, CertTemplate 3042 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) 3043 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3044 id-mod-crmf2005(36)}; 3046 -- Global Types 3047 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3048 -- The content of this type conforms to RFC 2279. 3050 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3051 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 3053 id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls 3054 id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types 3056 -- The following controls have the type OCTET STRING 3058 id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3} 3059 id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4} 3060 id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18} 3061 id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19} 3062 id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21} 3063 id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22} 3064 id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23} 3066 -- The following controls have the type UTF8String 3068 id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2} 3070 -- The following controls have the type INTEGER 3072 id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5} 3074 -- The following controls have the type OCTET STRING 3076 id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6} 3077 id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7} 3079 -- This is the content type used for a request message in the protocol 3081 id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 } 3083 PKIData ::= SEQUENCE { 3084 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 3085 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 3086 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 3087 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 3088 } 3090 bodyIdMax INTEGER ::= 4294967295 3092 BodyPartID ::= INTEGER(0..bodyIdMax) 3094 TaggedAttribute ::= SEQUENCE { 3095 bodyPartID BodyPartID, 3096 attrType OBJECT IDENTIFIER, 3097 attrValues SET OF AttributeValue 3098 } 3099 AttributeValue ::= ANY 3101 TaggedRequest ::= CHOICE { 3102 tcr [0] TaggedCertificationRequest, 3103 crm [1] CertReqMsg, 3104 orm [2] SEQUENCE { 3105 bodyPartID BodyPartID, 3106 requestMessageType OBJECT IDENTIFIER, 3107 requestMessageValue ANY DEFINED BY requestMessageType 3108 } 3109 } 3111 TaggedCertificationRequest ::= SEQUENCE { 3112 bodyPartID BodyPartID, 3113 certificationRequest CertificationRequest 3114 } 3116 CertificationRequest ::= SEQUENCE { 3117 certificationRequestInfo SEQUENCE { 3118 version INTEGER, 3119 subject Name, 3120 subjectPublicKeyInfo SEQUENCE { 3121 algorithm AlgorithmIdentifier, 3122 subjectPublicKey BIT STRING }, 3123 attributes [0] IMPLICIT SET OF Attribute }, 3124 signatureAlgorithm AlgorithmIdentifier, 3125 signature BIT STRING 3126 } 3128 TaggedContentInfo ::= SEQUENCE { 3129 bodyPartID BodyPartID, 3130 contentInfo ContentInfo 3131 } 3133 OtherMsg ::= SEQUENCE { 3134 bodyPartID BodyPartID, 3135 otherMsgType OBJECT IDENTIFIER, 3136 otherMsgValue ANY DEFINED BY otherMsgType } 3138 -- This defines the response message in the protocol 3139 id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 } 3141 ResponseBody ::= PKIResponse 3143 PKIResponse ::= SEQUENCE { 3144 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 3145 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 3146 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 3148 } 3150 -- Used to return status state in a response 3152 id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1} 3154 CMCStatusInfo ::= SEQUENCE { 3155 cMCStatus CMCStatus, 3156 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, 3157 statusString UTF8String OPTIONAL, 3158 otherInfo CHOICE { 3159 failInfo CMCFailInfo, 3160 pendInfo PendInfo } OPTIONAL 3161 } 3163 PendInfo ::= SEQUENCE { 3164 pendToken OCTET STRING, 3165 pendTime GeneralizedTime 3166 } 3168 CMCStatus ::= INTEGER { 3169 success (0), 3170 failed (2), 3171 pending (3), 3172 noSupport (4), 3173 confirmRequired (5), 3174 popRequired (6), 3175 partial (7) 3176 } 3178 CMCFailInfo ::= INTEGER { 3179 badAlg (0), 3180 badMessageCheck (1), 3181 badRequest (2), 3182 badTime (3), 3183 badCertId (4), 3184 unsuportedExt (5), 3185 mustArchiveKeys (6), 3186 badIdentity (7), 3187 popRequired (8), 3188 popFailed (9), 3189 noKeyReuse (10), 3190 internalCAError (11), 3191 tryLater (12), 3192 authDataFail (13) 3193 } 3195 -- Used for RAs to add extensions to certification requests 3196 id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8} 3198 AddExtensions ::= SEQUENCE { 3199 pkiDataReference BodyPartID, 3200 certReferences SEQUENCE OF BodyPartID, 3201 extensions SEQUENCE OF Extension 3202 } 3204 id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9} 3205 id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10} 3207 EncryptedPOP ::= SEQUENCE { 3208 request TaggedRequest, 3209 cms ContentInfo, 3210 thePOPAlgID AlgorithmIdentifier, 3211 witnessAlgID AlgorithmIdentifier, 3212 witness OCTET STRING 3213 } 3215 DecryptedPOP ::= SEQUENCE { 3216 bodyPartID BodyPartID, 3217 thePOPAlgID AlgorithmIdentifier, 3218 thePOP OCTET STRING 3219 } 3221 id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11} 3223 LraPopWitness ::= SEQUENCE { 3224 pkiDataBodyid BodyPartID, 3225 bodyIds SEQUENCE OF BodyPartID 3226 } 3228 -- 3229 id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15} 3231 GetCert ::= SEQUENCE { 3232 issuerName GeneralName, 3233 serialNumber INTEGER } 3235 id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16} 3237 GetCRL ::= SEQUENCE { 3238 issuerName Name, 3239 cRLName GeneralName OPTIONAL, 3240 time GeneralizedTime OPTIONAL, 3241 reasons ReasonFlags OPTIONAL } 3243 id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17} 3245 RevokeRequest ::= SEQUENCE { 3246 issuerName Name, 3247 serialNumber INTEGER, 3248 reason CRLReason, 3249 invalidityDate GeneralizedTime OPTIONAL, 3250 passphrase OCTET STRING OPTIONAL, 3251 comment UTF8String OPTIONAL } 3253 id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24} 3255 CMCCertId ::= IssuerAndSerialNumber 3257 -- The following is used to request V3 extensions be added to a certificate 3259 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 3260 rsadsi(113549) pkcs(1) pkcs-9(9) 14} 3262 ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension 3264 -- The following exists to allow Diffie-Hellman Certification Requests Messages to 3265 -- be well-formed 3267 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 3269 NoSignatureValue ::= OCTET STRING 3271 -- Unauthenticated attribute to carry removable data. 3272 -- This will be used in the key archive draft among others. 3274 id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3275 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)} 3276 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34} 3278 CMCUnsignedData ::= SEQUENCE { 3279 bodyPartPath BodyPartPath, 3280 identifier OBJECT IDENTIFIER, 3281 content ANY DEFINED BY identifier 3282 } 3284 -- Replaces CMC Status Info 3285 -- 3287 id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25} 3288 CMCStatusInfoV2 ::= SEQUENCE { 3289 cMCStatus CMCStatus, 3290 bodyList SEQUENCE SIZE (1..MAX) OF 3291 BodyPartReference, 3292 statusString UTF8String OPTIONAL, 3293 otherInfo CHOICE { 3294 failInfo CMCFailInfo, 3295 pendInfo PendInfo, 3296 extendedFailInfo SEQUENCE { 3297 failInfoOID OBJECT IDENTIFIER, 3298 failInfoValue AttributeValue 3299 } 3300 } OPTIONAL 3301 } 3303 BodyPartReference ::= CHOICE { 3304 bodyPartID BodyPartID, 3305 bodyPartPath BodyPartPath 3306 } 3308 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 3310 -- Allow for distribution of trust anchors 3311 -- 3313 id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26} 3315 PublishTrustAnchors ::= SEQUENCE { 3316 seqNumber INTEGER, 3317 hashAlgorithm AlgorithmIdentifier, 3318 anchorHashes SEQUENCE OF OCTET STRING 3319 } 3321 id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27} 3323 AuthPublish ::= BodyPartID 3325 -- These two items use BodyPartList 3326 id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28} 3327 id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29} 3329 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 3331 -- 3332 id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30} 3334 CMCPublicationInfo ::= SEQUENCE { 3335 hashAlg AlgorithmIdentifier, 3336 certHashes SEQUENCE OF OCTET STRING, 3337 pubInfo PKIPublicationInfo 3338 } 3340 id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31} 3342 ModCertTemplate ::= SEQUENCE { 3343 pkiDataReference BodyPartPath, 3344 certReferences BodyPartList, 3345 replace BOOLEAN DEFAULT TRUE, 3346 certTemplate CertTemplate 3347 } 3349 -- Inform follow on servers that one or more controls have already been processed 3351 id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32} 3353 ControlsProcessed ::= SEQUENCE { 3354 bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference 3355 } 3357 -- Identity Proof control w/ algorithm agility 3359 id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 } 3361 IdentifyProofV2 ::= SEQUENCE { 3362 proofAlgID AlgorithmIdentifier, 3363 macAlgId AlgorithmIdentifier, 3364 witness OCTET STRING 3365 } 3367 id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 } 3368 PopLinkWitnessV2 ::= SEQUENCE { 3369 keyGenAlgorithm AlgorithmIdentifier, 3370 macAlgorithm AlgorithmIdentifier, 3371 witness OCTET STRING 3372 } 3374 END 3375 Appendix B. Enrollment Message Flows 3377 This section is informational. The purpose of this section is to 3378 present, in an abstracted version, the messages that would flow 3379 between the client and server for several different common cases. 3381 Appendix B.1. Request of a Signing Certificate 3383 This section looks at the messages that would flow in the event that 3384 an enrollment is occurring for a signing only key. If the 3385 certificate was designed for both signing and encryption, the only 3386 difference would be the key usage extension in the certification 3387 request. 3389 Message from client to server: 3391 ContentInfo.contentType = id-signedData 3392 ContentInfo.content 3393 SignedData.encapContentInfo 3394 eContentType = id-ct-PKIData 3395 eContent 3396 controlSequence 3397 {102, id-cmc-identityProof, computed value} 3398 {103, id-cmc-senderNonce, 10001} 3399 reqSequence 3400 certRequest 3401 certReqId = 201 3402 certTemplate 3403 subject = My Proposed DN 3404 publicKey = My Public Key 3405 extensions 3406 {id-ce-subjectPublicKeyIdentifier, 1000} 3407 {id-ce-keyUsage, digitalSignature} 3408 SignedData.SignerInfos 3409 SignerInfo 3410 sid.subjectKeyIdentifier = 1000 3412 Response from server to client: 3414 ContentInfo.contentType = id-signedData 3415 ContentInfo.content 3416 SignedData.encapContentInfo 3417 eContentType = id-ct-PKIResponse 3418 eContent 3419 controlSequence 3420 {102, id-cmc-statusInfoV2, {success, 201}} 3421 {103, id-cmc-senderNonce, 10005} 3422 {104, id-cmc-recipientNonce, 10001} 3423 certificates 3424 Newly issued certificate 3425 Other certificates 3426 SignedData.SignerInfos 3427 Signed by CA 3429 Appendix B.2. Single Certification Request, But Modified by RA 3431 This section looks at the messages that would flow in the event that 3432 an enrollment has one RA in the middle of the data flow. That RA 3433 will modify the certification request before passing it on to the CA. 3435 Message from client to RA: 3437 ContentInfo.contentType = id-signedData 3438 ContentInfo.content 3439 SignedData.encapContentInfo 3440 eContentType = id-ct-PKIData 3441 eContent 3442 controlSequence 3443 {102, id-cmc-identityProof, computed value} 3444 {103, id-cmc-senderNonce, 10001} 3445 reqSequence 3446 certRequest 3447 certReqId = 201 3448 certTemplate 3449 subject = My Proposed DN 3450 publicKey = My Public Key 3451 extensions 3452 {id-ce-subjectPublicKeyIdentifier, 1000} 3453 {id-ce-keyUsage, digitalSignature} 3454 SignedData.SignerInfos 3455 SignerInfo 3456 sid.subjectKeyIdentifier = 1000 3458 Message from RA to CA: 3460 ContentInfo.contentType = id-signedData 3461 ContentInfo.content 3462 SignedData.encapContentInfo 3463 eContentType = id-ct-PKIData 3464 eContent 3465 controlSequence 3466 { 102, id-cmc-batchRequests, { 1, 2} } 3467 { 103, id-cmc-addExtensions, 3468 { {1, 201, {id-ce-certificatePolicies, anyPolicy}} 3469 {1, 201, {id-ce-subjectAltName, {extension data}} 3470 {2, XXX, {id-ce-subjectAltName, {extension data}}} 3471 cmsSequence 3472 { 1, } 3473 { 2, } 3474 SignedData.SignerInfos 3475 SignerInfo 3476 sid = RA key. 3478 Response from the CA to the RA: 3480 ContentInfo.contentType = id-signedData 3481 ContentInfo.content 3482 SignedData.encapContentInfo 3483 eContentType = id-ct-PKIResponse 3484 eContent 3485 controlSequence 3486 {102, id-cmc-BatchResponse, {999, 998}} 3488 {102, id-cmc-statusInfoV2, {failed, 2, badIdentity}} 3489 cmsSequence 3490 { bodyPartID = 999 3491 contentInfo 3492 ContentInfo.contentType = id-signedData 3493 ContentInfo.content 3494 SignedData.encapContentInfo 3495 eContentType = id-ct-PKIResponse 3496 eContent 3497 controlSequence 3498 {102, id-cmc-statusInfoV2, {success, 201}} 3499 certificates 3500 Newly issued certificate 3501 Other certificates 3502 SignedData.SignerInfos 3503 Signed by CA 3504 } 3505 { bodyPartID = 998, 3506 contentInfo 3507 ContentInfo.contentType = id-signedData 3508 ContentInfo.content 3509 SignedData.encapContentInfo 3510 eContentType = id-ct-PKIResponse 3511 eContent 3512 controlSequence 3513 {102, id-cmc-statusInfoV2, {failure, badAlg}} 3514 certificates 3515 Newly issued certificate 3516 Other certificates 3517 SignedData.SignerInfos 3518 Signed by CA 3519 } 3520 SignedData.SignerInfos 3521 Signed by CA 3523 Response from RA to client: 3525 ContentInfo.contentType = id-signedData 3526 ContentInfo.content 3527 SignedData.encapContentInfo 3528 eContentType = id-ct-PKIResponse 3529 eContent 3530 controlSequence 3531 {102, id-cmc-statusInfoV2, {success, 201}} 3532 certificates 3533 Newly issued certificate 3534 Other certificates 3535 SignedData.SignerInfos 3536 Signed by CA 3538 Appendix B.3. Direct POP for an RSA certificate 3540 This section looks at the messages that would flow in the event that 3541 an enrollment is done for an encryption only certificate using an 3542 direct POP method. For simplicity it is assumed that the 3543 certification requestor already has a signing only certificate 3545 The fact that a second round trip is required is implicit rather than 3546 explicit. The server determines this based on fact that no other POP 3547 exists for the certification request. 3549 Message #1 from client to server: 3551 ContentInfo.contentType = id-signedData 3552 ContentInfo.content 3553 SignedData.encapContentInfo 3554 eContentType = id-ct-PKIData 3555 eContent 3556 controlSequence 3557 {102, id-cmc-transactionId, 10132985123483401} 3558 {103, id-cmc-senderNonce, 10001} 3559 {104, id-cmc-dataReturn, } 3561 reqSequence 3562 certRequest 3563 certReqId = 201 3564 certTemplate 3565 subject = 3566 publicKey = My Public Key 3567 extensions 3568 {id-ce-keyUsage, keyEncipherment} 3569 popo 3570 keyEncipherment 3571 subsequentMessage 3572 SignedData.SignerInfos 3573 SignerInfo 3574 Signed by requestor's signing cert 3576 Response #1 from server to client: 3578 ContentInfo.contentType = id-signedData 3579 ContentInfo.content 3580 SignedData.encapContentInfo 3581 eContentType = id-ct-PKIResponse 3582 eContent 3583 controlSequence 3584 {101, id-cmc-statusInfoV2, {failed, 201, popRequired}} 3585 {102, id-cmc-transactionId, 10132985123483401} 3586 {103, id-cmc-senderNonce, 10005} 3587 {104, id-cmc-recipientNonce, 10001} 3588 {105, id-cmc-encryptedPOP, { 3589 request { 3590 certRequest 3591 certReqId = 201 3592 certTemplate 3593 subject = 3594 publicKey = My Public Key 3595 extensions 3596 {id-ce-keyUsage, keyEncipherment} 3597 popo 3598 keyEncipherment 3599 subsequentMessage 3600 } 3601 cms 3602 contentType = id-envelopedData 3603 content 3604 recipipentInfos.riid.issuerSerialNumber = 3605 encryptedContentInfo 3606 eContentType = id-data 3607 eContent = 3608 thePOPAlgID = HMAC-SHA1 3609 witnessAlgID = SHA-1 3610 witness }} 3611 {106, id-cmc-dataReturn, } 3613 certificates 3614 Other certificates (optional) 3615 SignedData.SignerInfos 3616 Signed by CA 3618 ContentInfo.contentType = id-signedData 3619 ContentInfo.content 3620 SignedData.encapContentInfo 3621 eContentType = id-ct-PKIData 3622 eContent 3623 controlSequence 3624 {102, id-cmc-transactionId, 10132985123483401} 3625 {103, id-cmc-senderNonce, 100101} 3626 {104, id-cmc-dataReturn, } 3628 {105, id-cmc-recipientNonce, 10005} 3629 {107, id-cmc-decryptedPOP, { 3630 bodyPartID 201, 3631 thePOPAlgID HMAC-SHA1, 3632 thePOP }} 3633 reqSequence 3634 certRequest 3635 certReqId = 201 3636 certTemplate 3637 subject = 3638 publicKey = My Public Key 3639 extensions 3640 {id-ce-keyUsage, keyEncipherment} 3641 popo 3642 keyEncipherment 3643 subsequentMessage 3644 SignedData.SignerInfos 3645 SignerInfo 3646 Signed by requestor's signing cert 3648 Response from server to client: 3650 ContentInfo.contentType = id-signedData 3651 ContentInfo.content 3652 SignedData.encapContentInfo 3653 eContentType = id-ct-PKIResponse 3654 eContent 3655 controlSequence 3656 {101, id-cmc-transactionId, 10132985123483401} 3657 {102, id-cmc-statusInfoV2, {success, 201}} 3658 {103, id-cmc-senderNonce, 10019} 3659 {104, id-cmc-recipientNonce, 100101} 3660 {104, id-cmc-dataReturn, } 3662 certificates 3663 Newly issued certificate 3664 Other certificates 3665 SignedData.SignerInfos 3666 Signed by CA 3668 Appendix C. Production of Diffie-Hellman Public Key Certification 3669 Requests 3671 Part of a certification request is a signature over the request; 3672 Diffie-Hellman is a key agreement algorithm and cannot be used to 3673 directly produce the required signature object. [DH-POP] provides 3674 two ways to produce the necessary signature value. This document 3675 also defines a signature algorithm that does not provide a POP value, 3676 but can be used to produce the necessary signature value. 3678 Appendix C.1. No-Signature Signature Mechanism 3680 Key management (encryption/decryption) private keys cannot always be 3681 used to produce some type of signature value as they can be in a 3682 decrypt only device. Certification requests require that the 3683 signature field be populated. This section provides a signature 3684 algorithm specifically for that purposes. The following object 3685 identifier and signature value are used to identify this signature 3686 type: 3688 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 3690 NoSignatureValue ::= OCTET STRING 3692 The parameters for id-alg-noSignature MUST be present and MUST be 3693 encoded as NULL. NoSignatureValue contains the hash of the 3694 certification request. It is important to realize that there is no 3695 security associated with this signature type. If this signature type 3696 is on a certification request and the Certification Authority policy 3697 requires proof-of-possession of the private key, the POP mechanism 3698 defined in Section 6.7 MUST be used. 3700 Appendix D. Change History 3702 RFC Editor - please remove this appendix prior to publishing. 3704 RFC 27XX to -00 3706 1. Addition of Extended CMC Status Info 3708 From -00 to -01 3710 1. Removal of Transport section to a new document. 3712 2. Removal of Compliance section to a new document. 3714 From -01 to -02 3716 1. Add processing rules for PKIData and PKIResponse processing. 3718 2. Add unsigned attribute for holding data (to be used by key 3719 archival). 3721 3. Add trust root identification control. 3723 4. Add Server to Client identity proof method. 3725 5. Add controls to identify batch processing, needed by rules added 3726 in item 1. 3728 From -02 to -03 3730 1. Add unpublish control 3732 2. Added use of AuthenticatedData structure from CMS 3734 3. Insert Appendix B - Enrollment Message Flows 3736 4. Add Modify Certification Request control 3738 From -03 to -04 3740 1. Change author list. 3742 2. Add IANA Considerations section 3744 3. Correct module names in ASN.1 3746 4. Add id-cmc-controlProcessed control with associated changes. 3748 From -04 to -05 3750 1. Change Trust Root to Trust Anchor. 3752 Authors' Addresses 3754 Jim Schaad 3755 Soaring Hawk Consulting 3756 PO Box 675 3757 Gold Bar, WA 98251 3759 Phone: (425) 785-1031 3760 Email: jimsch@nwlink.com 3762 Michael Myers 3763 TraceRoute Security, Inc. 3765 Email: mmyers@fastq.inc 3767 Full Copyright Statement 3769 Copyright (C) The IETF Trust (2008). 3771 This document is subject to the rights, licenses and restrictions 3772 contained in BCP 78, and except as set forth therein, the authors 3773 retain all their rights. 3775 This document and the information contained herein are provided on an 3776 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3777 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3778 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3779 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3780 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3781 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3783 Intellectual Property 3785 The IETF takes no position regarding the validity or scope of any 3786 Intellectual Property Rights or other rights that might be claimed to 3787 pertain to the implementation or use of the technology described in 3788 this document or the extent to which any license under such rights 3789 might or might not be available; nor does it represent that it has 3790 made any independent effort to identify any such rights. Information 3791 on the procedures with respect to rights in RFC documents can be 3792 found in BCP 78 and BCP 79. 3794 Copies of IPR disclosures made to the IETF Secretariat and any 3795 assurances of licenses to be made available, or the result of an 3796 attempt made to obtain a general license or permission for the use of 3797 such proprietary rights by implementers or users of this 3798 specification can be obtained from the IETF on-line IPR repository at 3799 http://www.ietf.org/ipr. 3801 The IETF invites any interested party to bring to its attention any 3802 copyrights, patents or patent applications, or other proprietary 3803 rights that may cover technology that may be required to implement 3804 this standard. Please address the information to the IETF at 3805 ietf-ipr@ietf.org.