idnits 2.17.1 draft-ietf-pkix-rfc5272-bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 113 has weird spacing: '...Witness allow...' == Line 118 has weird spacing: '...se Body allow...' == Line 230 has weird spacing: '...Witness is a ...' == Line 240 has weird spacing: '...Witness is th...' == Line 243 has weird spacing: '...artPath is th...' == (11 more instances...) (Using the creation date from RFC5272, updated by this document, for RFC5378 checks: 2001-03-09) -- 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 (September 12, 2011) is 4572 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNIVERSAL 12' is mentioned on line 642, but not defined -- Looks like a reference, but probably isn't: '0' on line 1173 -- Looks like a reference, but probably isn't: '1' on line 1457 -- Looks like a reference, but probably isn't: '2' on line 1148 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 Updates: 5272, 5273, 5274 September 12, 2011 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 15, 2012 9 Certificate Management over CMS (CMC) Updates 10 draft-ietf-pkix-rfc5272-bis-08 12 Abstract 14 This document contains a set of updates to the base syntax for CMC, a 15 Certificate Management protocol using the Cryptographic Message 16 Syntax (CMS). This document updates RFC 5272, RFC 5273 and RFC 5274. 18 The new items in this document are: New controls for future work in 19 doing server side key generation. Definition of a Subject 20 Information Access value to identify CMC servers. The registration 21 of a port number for TCP/IP for the CMC service to run on. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 15, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3 59 2. Updates to RFC 5272 - Certificate Management over CMS (CMC) . 4 60 2.1. New Section 1.3. Changes Since RFC 5272 . . . . . . . . . 4 61 2.2. Update Section 6. Controls . . . . . . . . . . . . . . . . 4 62 2.3. Replace Section 6.3. Linking Identity and POP 63 Information . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.4. Replace Section 6.3.3. Renewal and Rekey Messages . . . . 5 65 2.5. New Section 6.20 RA Identity Proof Witness control . . . . 6 66 2.6. New Section 6.21 Response Body Control . . . . . . . . . . 7 67 2.7. New Section 7. Other Attributes . . . . . . . . . . . . . 8 68 2.8. New Section 7.1 Change Subject Name Attribute . . . . . . 9 69 2.9. New Section 9. Certificate Requirements . . . . . . . . . 10 70 2.10. New Section 9.1. Extended Key Usage . . . . . . . . . . . 10 71 2.11. New Section 9.2. Subject Information Access . . . . . . . 11 72 2.12. Updates Section 8. Security Considerations . . . . . . . . 11 73 3. Updates to RFC 5273 - Certificate Management over CMS 74 (CMC): Transport Protocols . . . . . . . . . . . . . . . . . . 13 75 3.1. Update to Section 5 TCP-Based Protocol . . . . . . . . . . 13 76 3.2. New Section 6. IANA Considerations . . . . . . . . . . . . 13 77 4. Updates to RFC 5274 - Certificate Management Message over 78 CMS (CMC): Compliance Requirements . . . . . . . . . . . . . . 14 79 4.1. Update to Section 4.2 Controls . . . . . . . . . . . . . . 14 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 84 7.2. Informational References . . . . . . . . . . . . . . . . . 17 85 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 18 86 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 87 A.2. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 26 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 90 1. Introduction 92 While dealing with the Suite B profile of CMC 93 [I-D.turner-suiteb-cmc], a number of deficiencies were noted in the 94 current base CMC specification. This document has a set of updates 95 to [RFC5272], [RFC5273] and [RFC5274] to deal with those issues. 97 1.1. Requirements Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Updates to RFC 5272 - Certificate Management over CMS (CMC) 105 2.1. New Section 1.3. Changes Since RFC 5272 107 This section is inserted before the current section 1.3. 109 The following changes were made in this document. 111 o Addition of new controls: 113 RA Identity Witness allows for an RA to perform identity checking 114 using the identity and shared-secret, and then tell any 115 following servers that the identity check was successfully 116 performed. 118 Response Body allows for an RA to identify a nested response for 119 an EE to process. 121 o Creation of a new attribute, Change Subject Name, that allows a 122 client to request a change in the subject name and subject 123 alternate name fields in a certificate. 125 o Add Extended Key Usages for CMC - Defined a new Subject 126 Information Access to hold locations to contact the CMC server. 128 o Clarify that the use of a pre-existing certificate is not limited 129 to just renewal and rekey messages and is required for support. 130 This formalizes a requirement for the ability to do renewal and 131 rekey which previsously was implicity. 133 2.2. Update Section 6. Controls 135 Table 1 is to be updated by the addition of the following rows: 137 +--------------------------+-----------+--------------+---------+ 138 | Control Identifier | OID | Syntax | Section | 139 +--------------------------+-----------+--------------+---------+ 140 | id-cmc-raIdentityWitness | id-cmc 35 | BodyPartPath | 6.20 | 141 | | | | | 142 | id-cmc-responseBody | id-cmc 37 | BodyPartPath | 6.21 | 143 +--------------------------+-----------+--------------+---------+ 145 Table 1: CMC Control Attributes 147 2.3. Replace Section 6.3. Linking Identity and POP Information 149 Replace the text of the section with the following text. 151 In a CMC Full PKI Request, identity proof information about the 152 client is carried in the certificate associated with the signature of 153 the SignedData containing the certification requests, one of the two 154 identity proof controls or the MAC computed for the AuthenticatedData 155 containing the certification requests. Proof-of-possession 156 information for key pairs, however, is carried separately for each 157 PKCS #10 or CRMF certification request. (For keys capable of 158 generating a digital signature, the POP is provided by the signature 159 on the PKCS #10 or CRMF request. For encryption-only keys, the 160 controls described in Section 6.7 are used.) In order to prevent 161 substitution-style attacks, the protocol must guarantee that the same 162 entity supplied both the POP and proof-of-identity information. 164 We describe three mechanisms for linking identity and POP 165 information: witness values cryptographically derived from a shared- 166 secret (Section 6.3.1), shared-secret/subject name matching (Section 167 6.3.2), and subject name matching to an existing certificate (Section 168 6.3.3). Clients and servers MUST support the witness value and the 169 certificate linking techniques. Clients and servers MAY support 170 shared-secret/name matching or MAY support other bilateral techniques 171 of similar strength. The idea behind the first two mechanisms is to 172 force the client to sign some data into each certification request 173 that can be directly associated with the shared-secret; this will 174 defeat attempts to include certification requests from different 175 entities in a single Full PKI Request. 177 2.4. Replace Section 6.3.3. Renewal and Rekey Messages 179 New section title is "Existing Certificate Linking". Replace all 180 text in this section with this text. 182 Linking between the POP and an identity is easy when an existing 183 certificate is used. The client copies all of the naming information 184 from the existing certificate (subject name and subject alternative 185 name) into the new certification request. The POP on the new public 186 key is then performed by using the new key to sign the identity 187 information (linking the POP to a specific identity). The identity 188 information is then tied to the POP information by signing the entire 189 enrollment request with the private key of the existing certificate. 191 Existing certificate linking can be used in the following 192 circumstances: 194 When replacing a certificate by doing a renewal or rekey 195 certification request. 197 Using an existing certificate to get a new certificate. An 198 example of this would be to get a key establishment certificate 199 after having gotten a signature certificate. 201 Using a third party certificate to get a new certificate from a 202 CA. An example of this would be using a certificate and key pair 203 distributed with a device to prove an identity. This requires 204 that the CA have an out-of-band channel to map the identity in the 205 device certificate to the new EE identity. 207 2.5. New Section 6.20 RA Identity Proof Witness control 209 The RA Identity Proof Witness control allows an RA to indicate to 210 subsequent control processors that all of the identity proof 211 requirements have been met. This permits the identity proof to be 212 performed at a location closer to the end-entity. For example, the 213 identity proof could be done at multiple physical locations while the 214 CA could operate on a company-wide basis. The RA performs the 215 identity proof, and potentially other tasks that require the secret 216 to be used, while the CA would be prevented from knowing the secret. 217 If the identity proof fails, then the RA returns an error to the 218 client denoting that fact. 220 The relevant ASN.1 for the RA Identity Proof Witness control is as 221 follows: 223 cmc-raIdentityWitness CMC-CONTROL ::= 224 { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness } 226 id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35} 228 The above ASN.1 defines the following items: 230 cmc-raIdentityWitness is a CMC-CONTROL associating the object 231 identifier id-cmc-raIdentityWitness and the type BodyPartPath. 232 This object is omitted from the 1988 module. The object is added 233 to the object set Cmc-Control-Set . The control is permitted to 234 appear only in the control sequence of a PKIData object. It MUST 235 NOT appear in the control sequence of a PKIResponse. The control 236 is permitted to be used only by an RA. The control may appear 237 multiple times in a control sequence with each occurrence pointing 238 to a different object. 240 id-cmc-raIdentityWitness is the object identifier used to identify 241 this CMC control. 243 BodyPartPath is the type structure associated with the control. The 244 syntax of BodyPartPath is defined in Section 3.2.2. The path 245 contains a sequence of body part identifiers leading to one of the 246 following items: 248 Identity Proof control if the RA verified the identity proof in 249 this control. 251 Identity Proof Version 2 if the RA verified the identity proof in 252 this control. 254 Full PKI Request if the RA performed an out-of-band identity 255 proof for this request. The request SHOULD NOT contain either 256 Identity Proof control. 258 Simple PKI Request if the RA performed an out-of-band identity 259 proof for this request. 261 The RA Identity Proof Witness control will frequently be associated 262 with a Modify Certification Request control which changes the name 263 fields in the associated certification requests. This is because the 264 RA knows the actual name to be assigned to the entity requesting the 265 certificate and the end entity does not yet have the details of the 266 name. (The association would be set up by the operator at the time 267 the shared secret was generated by the RA.) 269 When this control is placed in a message, it is RECOMMENDED that the 270 Control Processed control be placed in the body sequence as well. 271 Using the explicit new control, rather than implicitly relying on the 272 Control Processed control is important due to the need to know 273 explicitly which identity proofs have been performed. The new 274 control also allows an RA to state that out-of-band identity proofs 275 have been performed. 277 When the identity proof is performed by an RA, the RA also MUST 278 validate the linking between the identity proof and the name 279 information wrapped inside of the key proof-of-possession. 281 2.6. New Section 6.21 Response Body Control 283 This item is to be added to the table in section 6. 285 The Response Body Control is designed to enable an RA to inform an EE 286 that there is an embedded response message that MUST be processed as 287 part of the processing of this message. This control is designed to 288 be used in a couple of different cases where an RA has done some 289 additional processing for the certificate request, e.g., as key 290 generation. When an RA performs key generation on behalf of an EE, 291 the RA MUST respond with both the original response message from the 292 certificate issuer (containing the certificate issuance) as part of 293 the response generated by the RA (containing the new key). Another 294 case where this is useful is when the secret is shared between the RA 295 and the EE (rather than between the CA and the EE) and the RA returns 296 the Publish Trust Anchors control (to populate the correct trust 297 points). 299 The relevant ASN.1 for the Response Body Control is as follows: 301 cmc-responseBody CMC-CONTROL ::= { 302 BodyPartPath IDENTIFIED BY id-cmc-responseBody 303 } 305 id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37} 307 The above ASN.1 defines the following items: 309 cmc-responseBody is a CMC-CONTROL associating the object identifier 310 id-cmc-responseBody with the type BodyPartPath. This object is 311 omitted from the 1988 module. The object is added to the object 312 set Cmc-Control-Set. The control is permitted to appear only in 313 the control sequence of a PKIResponse. The control MUST NOT 314 appear in the control sequence of a PKIData. It is expected that 315 only an intermediary RA will use this control; a CA generally does 316 not need the control as it is creating the original innermost 317 message. 319 id-cmc-responseBody is the object identifier used to identify this 320 CMC control. 322 BodyPartPath is the type structure associated with the control. The 323 syntax of BodyPartPath is defined in Section 3.2.2. The path 324 contains a sequence of body part identifiers leading to a 325 cmsSequence item which contains a PKIResponse within it. 327 2.7. New Section 7. Other Attributes 329 This section is to be inserted before the current section 7. 331 There are a number of different locations where various types of 332 attributes can be placed in either a CMC request or a CMC response 333 message. These places include the attribute sequence of a PKCS #10 334 request, controls in CRMF (Section 6 of [RFC4211]) and the various 335 CMS attribute sequences. 337 2.8. New Section 7.1 Change Subject Name Attribute 339 The Client Name Change Request Attribute is designed for a client to 340 ask for a change in its name as part of a certificate request. This 341 cannot be done in the simple way of just changing the requested 342 subject name in the certificate template because of security issues. 343 The name in the certificate request MUST match the name in the 344 certificate used to verify the request, in order that identity and 345 possession proofs are correctly applied. 347 The relevant ASN.1 for the Client Name Change Request attribute is as 348 follows: 350 at-cmc-changeSubjectName ATTRIBUTE ::= 351 { ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName } 353 id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36} 355 ChangeSubjectName ::= SEQUENCE { 356 subject Name OPTIONAL, 357 subjectAlt SubjectAltName OPTIONAL 358 } 359 (WITH COMPONENTS {..., subject PRESENT} | 360 COMPONENTS {..., subjectAlt PRESENT} ) 362 The attribute is designed to be used as an ATTRIBUTE object. As 363 such, the attribute is placed in one of the following two places: 365 The attributes field in a CertificationRequest. 367 The controls field of a CertRequest for a CRMF certification 368 request. 370 The control is identified by the Object Identifier id-cmc- 371 changeSubjectName. 373 The ASN.1 type associated with control is ChangeSubjectName. The 374 fields of the structure are configured as follows: 376 subject contains the requested subject name for the new certificate. 378 subjectAlt contains the requested subject alternative name for the 379 new certificate. 381 At least one of the fields in the sequence MUST be present when 382 encoding the structure. 384 When the CA processes this attribute in a certification request it 385 will do the following: 387 1. The subject field is copied to the name field of the template if 388 present. If the subject field is absent, the name field of the 389 template will be set to a empty sequence. 391 2. The subjectAlt field is used as the content of a SubjectAltName 392 extension in the certificate if present. The subjectAltName 393 extension is removed from the certificate template if the 394 subjectAlt field is absent. 396 2.9. New Section 9. Certificate Requirements 398 This section is to be inserted before the current section 8. 400 Certificates for servers used in the CMC protocol SHOULD conform to 401 the profile defined in [RFC5280]. This document defines some 402 additional items that MAY appear in CMC server certificates. Section 403 9.1 defines some additional Extended Key Usage values that can appear 404 in certificates. Section 9.2 defines a new Subject Information 405 Access value which allows for a CMC certificate to publish 406 information on how to contact the services it provides. 408 2.10. New Section 9.1. Extended Key Usage 410 The Extended Key Usage (EKU) extension is used to restrict the use of 411 a certificate to specific applications. We define three different 412 EKUs in this document. The ASN.1 to define these EKUs is: 414 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 415 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 416 id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 } 418 The usage description for each of the EKUs is as follows: 420 CMC Certification Authorities are identified by the id-kp-cmcCA 421 extended key usage. The certificate may be the same as the CA 422 certificate or may be different than the CA certificate. If a 423 different certificate is used, the certificates containing the id- 424 kp-cmcCA extended key usage SHOULD have the same name as the 425 certificate used for issuing the certificates. (Using a separate 426 key pair for CMC protocol operations and for issuing Certificates 427 and CRLs decreases the number of operations for which the private 428 key used to sign certificates and CRLs would be used.) 430 CMC Registration Authorities are identified by the id-kp-cmcRA 431 extended key usage. This usage is placed into RA certificates. 433 CMC Archive Servers are identified by the id-kp-cmcArchive extended 434 key usage. CMC Archive Servers and the associated protocol are to 435 be defined in a future document. 437 2.11. New Section 9.2. Subject Information Access 439 The subject information access extension indicates how to access 440 information and services for the subject of the certificate. We 441 define a new value for use in this extension, to identify the 442 different locations that CMC services will be available. If this 443 value is placed in a certificate, an appropriate extended key usage 444 defined in section 9.1 MUST be included in the certificate as well. 446 The id-ad-cmc OID is used when the subject offers certification 447 services using the CMC Protocol. If the CMC services are available 448 via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier. 449 If the CMC services are available via electronic mail, accessLocation 450 MUST be an rfc822Name. If CMC services are available using TCP/IP, 451 the dNSName or iPAddress name forms MUST be used. Since the 452 GeneralName data structure does not permit the inclusion of a port 453 number, in the absence of other external configuration information, 454 the value of TBD1 should be used. (The port registration is in 455 Section 3.2.) The semantics of other name forms of accessLocation 456 (when accessMethod is id-ad-cmc) are not defined by this 457 specification. 459 The ASN.1 for this extension is: GeneralName 461 id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 } 463 2.12. Updates Section 8. Security Considerations 465 The following paragraphs are to be added to the end of section 8. 467 A number of controls such as the RA Identity Proof Witness control 468 exist for an RA to either make assertions about or modify a 469 certificate request. Any upstream request processor, such as a CA, 470 MUST verify that the RA is fully identified and authorized to make 471 assertion or modification it is claiming. If it is not identified or 472 authorized then any request MUST be rejected. 474 CMC servers, both RAs and CAs, need to due diligence in checking the 475 contents of a certificate request. At an absolute minimum all fields 476 should be checked to ensure that the policies of the CA/RA are 477 correctly enforced. While all fields need to be checked, special 478 care should be taken with names, name forms, algorithm choices and 479 algorithm parameters. 481 3. Updates to RFC 5273 - Certificate Management over CMS (CMC): 482 Transport Protocols 484 3.1. Update to Section 5 TCP-Based Protocol 486 The following replaces paragraph 3 in section 5. 488 CMC requires a registered port number to send and receive CMC 489 messages over TCP. The title of this IP Protocol number is "pkix- 490 cmc". The value of this TCP port is TBD1. 492 Prior to this update, CMC did not have a registred port number and 493 used an externally configured port from the Private Port range. 494 Client implementations MAY want to continue to allow for this to 495 occur. Servers SHOULD change to use the new port. It is expected 496 that HTTP will continue to be the primary transport method used by 497 CMC installations. 499 3.2. New Section 6. IANA Considerations 501 This is a new section to be inserted before the current section 6. 503 IANA is requested to assign a TCP port number in the Registered Port 504 Number range for the use of CMC. 506 Service name: pkix-cmc 507 Port Number: [ TBD1 ] 508 Transport protocol: TCP 509 Description: PKIX Certificate Management using CMS (CMC) 510 Reference: [ RFC-to-be ] 511 Assignee: iesg@ietf.org 512 Contact: chair@ietf.org 514 4. Updates to RFC 5274 - Certificate Management Message over CMS (CMC): 515 Compliance Requirements 517 4.1. Update to Section 4.2 Controls 519 The following lines should be added to the end of Table 1. 521 The following table lists the name and level of support required for 522 each control. 524 +---------------------------+-----+------+-----+ 525 | Control | EE | RA | CA | 526 +---------------------------+-----+------+-----+ 527 | RA Identity Proof Witness | N/A | MUST | (2) | 528 | | | | | 529 | Response Body | (6) | (6) | N/A | 530 +---------------------------+-----+------+-----+ 532 Table 1: Table 1: CMC Control Attributes 534 New Note #6 536 6. EE's SHOULD implement if designed to work with RAs and MUST 537 implement if intended to be used in environments where RAs are used 538 for identity validation or key generation. RAs SHOULD implement for 539 checking responses back for consistency. 541 5. IANA Considerations 543 This document contains a new IANA considerations section to be added 544 to [RFC5273] as part of this update. 546 6. Security Considerations 548 No changes are made to the existing security considerations of RFC 549 5273 and RFC 5274. The security considerations for RFC 5272 have 550 been slightly modified (section 2.12). 552 7. References 554 7.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 560 (CMC)", RFC 5272, June 2008. 562 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 563 (CMC): Transport Protocols", RFC 5273, June 2008. 565 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 566 over CMS (CMC): Compliance Requirements", RFC 5274, 567 June 2008. 569 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 570 Housley, R., and W. Polk, "Internet X.509 Public Key 571 Infrastructure Certificate and Certificate Revocation List 572 (CRL) Profile", RFC 5280, May 2008. 574 7.2. Informational References 576 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 577 RFC 5652, September 2009. 579 [I-D.turner-suiteb-cmc] 580 Zieglar, L., Peck, M., and S. Turner, "Suite B Profile of 581 Certificate Management over CMS", 582 draft-turner-suiteb-cmc-03 (work in progress), June 2010. 584 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 585 Certificate Request Message Format (CRMF)", RFC 4211, 586 September 2005. 588 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 589 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 590 June 2010. 592 Appendix A. ASN.1 Modules 594 A.1. 1988 ASN.1 Module 596 This section contains the updated ASN.1 module for [RFC5272]. This 597 module replaces the module in Appendix A. Although a 2008 ASN.1 598 Module is provided, this remains the normative module as per the 599 policy of the PKIX working group. 601 EnrollmentMessageSyntax-2011-v88 602 { iso(1) identified-organization(3) dod(4) internet(1) 603 security(5) mechansims(5) pkix(7) id-mod(0) 604 id-mod-enrollMsgSyntax-2011-88(76) } 606 DEFINITIONS IMPLICIT TAGS ::= 607 BEGIN 609 -- EXPORTS All -- 610 -- The types and values defined in this module are exported for use 611 -- in the other ASN.1 modules. Other applications may use them for 612 -- their own purposes. 614 IMPORTS 616 -- PKIX Part 1 - Implicit From [RFC5280] 617 GeneralName, CRLReason, ReasonFlags, GeneralNames 618 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 619 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 620 id-pkix1-implicit(19)} 622 -- PKIX Part 1 - Explicit From [RFC5280] 623 AlgorithmIdentifier, Extension, Name, CertificateSerialNumber, 624 id-ad, id-kp 625 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 626 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 627 id-pkix1-explicit(18)} 629 -- Cryptographic Message Syntax FROM [CMS] 630 ContentInfo, Attribute, IssuerAndSerialNumber 631 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) 632 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 633 modules(0) cms-2004(24)} 635 -- CRMF FROM [RFC4211] 636 CertReqMsg, PKIPublicationInfo, CertTemplate 637 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) 638 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 639 id-mod-crmf2005(36)}; 641 -- Global Types 642 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 643 -- The content of this type conforms to RFC 2279. 645 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 646 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 648 id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls 649 id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types 651 -- The following controls have the type OCTET STRING 653 id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3} 654 id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4} 655 id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18} 656 id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19} 657 id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21} 658 id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22} 659 id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23} 661 -- The following controls have the type UTF8String 663 id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2} 665 -- The following controls have the type INTEGER 667 id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5} 669 -- The following controls have the type OCTET STRING 671 id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6} 672 id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7} 674 -- This is the content type used for a request message 675 -- in the protocol 677 id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 } 679 PKIData ::= SEQUENCE { 680 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 681 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 682 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 683 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 684 } 686 bodyIdMax INTEGER ::= 4294967295 688 BodyPartID ::= INTEGER(0..bodyIdMax) 690 TaggedAttribute ::= SEQUENCE { 691 bodyPartID BodyPartID, 692 attrType OBJECT IDENTIFIER, 693 attrValues SET OF AttributeValue 694 } 696 AttributeValue ::= ANY 698 TaggedRequest ::= CHOICE { 699 tcr [0] TaggedCertificationRequest, 700 crm [1] CertReqMsg, 701 orm [2] SEQUENCE { 702 bodyPartID BodyPartID, 703 requestMessageType OBJECT IDENTIFIER, 704 requestMessageValue ANY DEFINED BY requestMessageType 705 } 706 } 708 TaggedCertificationRequest ::= SEQUENCE { 709 bodyPartID BodyPartID, 710 certificationRequest CertificationRequest 711 } 713 CertificationRequest ::= SEQUENCE { 714 certificationRequestInfo SEQUENCE { 715 version INTEGER, 716 subject Name, 717 subjectPublicKeyInfo SEQUENCE { 718 algorithm AlgorithmIdentifier, 719 subjectPublicKey BIT STRING }, 720 attributes [0] IMPLICIT SET OF Attribute }, 721 signatureAlgorithm AlgorithmIdentifier, 722 signature BIT STRING 723 } 725 TaggedContentInfo ::= SEQUENCE { 726 bodyPartID BodyPartID, 727 contentInfo ContentInfo 728 } 730 OtherMsg ::= SEQUENCE { 731 bodyPartID BodyPartID, 732 otherMsgType OBJECT IDENTIFIER, 733 otherMsgValue ANY DEFINED BY otherMsgType } 735 -- This defines the response message in the protocol 736 id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 } 737 ResponseBody ::= PKIResponse 739 PKIResponse ::= SEQUENCE { 740 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 741 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 742 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 744 } 746 -- Used to return status state in a response 748 id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1} 750 CMCStatusInfo ::= SEQUENCE { 751 cMCStatus CMCStatus, 752 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, 753 statusString UTF8String OPTIONAL, 754 otherInfo CHOICE { 755 failInfo CMCFailInfo, 756 pendInfo PendInfo } OPTIONAL 757 } 759 PendInfo ::= SEQUENCE { 760 pendToken OCTET STRING, 761 pendTime GeneralizedTime 762 } 764 CMCStatus ::= INTEGER { 765 success (0), 766 failed (2), 767 pending (3), 768 noSupport (4), 769 confirmRequired (5), 770 popRequired (6), 771 partial (7) 772 } 774 -- Note: 775 -- The spelling of unsupportedExt is corrected in this version. 776 -- In RFC 2797, it was unsuportedExt. 778 CMCFailInfo ::= INTEGER { 779 badAlg (0), 780 badMessageCheck (1), 781 badRequest (2), 782 badTime (3), 783 badCertId (4), 784 unsupportedExt (5), 785 mustArchiveKeys (6), 786 badIdentity (7), 787 popRequired (8), 788 popFailed (9), 789 noKeyReuse (10), 790 internalCAError (11), 791 tryLater (12), 792 authDataFail (13) 793 } 795 -- Used for RAs to add extensions to certification requests 796 id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8} 798 AddExtensions ::= SEQUENCE { 799 pkiDataReference BodyPartID, 800 certReferences SEQUENCE OF BodyPartID, 801 extensions SEQUENCE OF Extension 802 } 804 id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9} 805 id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10} 807 EncryptedPOP ::= SEQUENCE { 808 request TaggedRequest, 809 cms ContentInfo, 810 thePOPAlgID AlgorithmIdentifier, 811 witnessAlgID AlgorithmIdentifier, 812 witness OCTET STRING 813 } 815 DecryptedPOP ::= SEQUENCE { 816 bodyPartID BodyPartID, 817 thePOPAlgID AlgorithmIdentifier, 818 thePOP OCTET STRING 819 } 821 id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11} 823 LraPopWitness ::= SEQUENCE { 824 pkiDataBodyid BodyPartID, 825 bodyIds SEQUENCE OF BodyPartID 826 } 828 -- 829 id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15} 831 GetCert ::= SEQUENCE { 832 issuerName GeneralName, 833 serialNumber INTEGER } 835 id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16} 837 GetCRL ::= SEQUENCE { 838 issuerName Name, 839 cRLName GeneralName OPTIONAL, 840 time GeneralizedTime OPTIONAL, 841 reasons ReasonFlags OPTIONAL } 843 id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17} 845 RevokeRequest ::= SEQUENCE { 846 issuerName Name, 847 serialNumber INTEGER, 848 reason CRLReason, 849 invalidityDate GeneralizedTime OPTIONAL, 850 passphrase OCTET STRING OPTIONAL, 851 comment UTF8String OPTIONAL } 853 id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24} 855 CMCCertId ::= IssuerAndSerialNumber 857 -- The following is used to request V3 extensions be added to a 858 -- certificate 860 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) 861 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 14} 863 ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension 865 -- The following exists to allow Diffie-Hellman Certification 866 -- Requests Messages to be well-formed 868 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 870 NoSignatureValue ::= OCTET STRING 872 -- Unauthenticated attribute to carry removable data. 873 -- This could be used in an update of "CMC Extensions: Server 874 -- Side Key Generation and Key Escrow" (February 2005) and in 875 -- other documents. 877 id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 878 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)} 879 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34} 880 CMCUnsignedData ::= SEQUENCE { 881 bodyPartPath BodyPartPath, 882 identifier OBJECT IDENTIFIER, 883 content ANY DEFINED BY identifier 884 } 886 -- Replaces CMC Status Info 887 -- 889 id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25} 891 CMCStatusInfoV2 ::= SEQUENCE { 892 cMCStatus CMCStatus, 893 bodyList SEQUENCE SIZE (1..MAX) OF 894 BodyPartReference, 895 statusString UTF8String OPTIONAL, 896 otherInfo CHOICE { 897 failInfo CMCFailInfo, 898 pendInfo PendInfo, 899 extendedFailInfo SEQUENCE { 900 failInfoOID OBJECT IDENTIFIER, 901 failInfoValue AttributeValue 902 } 903 } OPTIONAL 904 } 906 BodyPartReference ::= CHOICE { 907 bodyPartID BodyPartID, 908 bodyPartPath BodyPartPath 909 } 911 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 913 -- Allow for distribution of trust anchors 914 -- 916 id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26} 918 PublishTrustAnchors ::= SEQUENCE { 919 seqNumber INTEGER, 920 hashAlgorithm AlgorithmIdentifier, 921 anchorHashes SEQUENCE OF OCTET STRING 922 } 924 id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27} 926 AuthPublish ::= BodyPartID 927 -- These two items use BodyPartList 928 id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28} 929 id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29} 931 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 933 -- 934 id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30} 936 CMCPublicationInfo ::= SEQUENCE { 937 hashAlg AlgorithmIdentifier, 938 certHashes SEQUENCE OF OCTET STRING, 939 pubInfo PKIPublicationInfo 940 } 942 id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31} 944 ModCertTemplate ::= SEQUENCE { 945 pkiDataReference BodyPartPath, 946 certReferences BodyPartList, 947 replace BOOLEAN DEFAULT TRUE, 948 certTemplate CertTemplate 949 } 951 -- Inform follow on servers that one or more controls have already 952 -- been processed 954 id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32} 956 ControlsProcessed ::= SEQUENCE { 957 bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference 958 } 960 -- Identity Proof control w/ algorithm agility 962 id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 } 964 IdentifyProofV2 ::= SEQUENCE { 965 proofAlgID AlgorithmIdentifier, 966 macAlgId AlgorithmIdentifier, 967 witness OCTET STRING 968 } 970 id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 } 971 PopLinkWitnessV2 ::= SEQUENCE { 972 keyGenAlgorithm AlgorithmIdentifier, 973 macAlgorithm AlgorithmIdentifier, 974 witness OCTET STRING 976 } 978 -- 980 id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35} 982 -- 983 -- Allow for an End-Entity to request a change in name 984 -- This item is added to RegControlSet in CRMF 985 -- 987 id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36} 989 ChangeSubjectName ::= SEQUENCE { 990 subject Name OPTIONAL, 991 subjectAlt GeneralNames OPTIONAL 992 } 993 -- (WITH COMPONENTS {..., subject PRESENT} | 994 -- WITH COMPONENTS {..., subjectAlt PRESENT} ) 996 -- 997 -- Embedded response from a third party for processing 998 -- 1000 id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37} 1002 -- 1003 -- Key purpose identifiers are in the extended key usage extension 1004 -- 1006 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1007 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1008 id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 28 } 1010 -- 1011 -- Subject Information Access identifier 1012 -- 1014 id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 } 1016 END 1018 A.2. 2008 ASN.1 Module 1020 An updated 2008 ASN.1 module has been provided as part of this 1021 update. The module contains changes that were made as part of the 1022 re-write to current ASN.1 standards in [RFC5912] as well as the 1023 changes for this document. 1025 EnrollmentMessageSyntax-2011-v08 1026 {iso(1) identified-organization(3) dod(6) internet(1) 1027 security(5) mechansims(5) pkix(7) id-mod(0) 1028 id-mod-enrollMsgSyntax-2011-08(76)} 1029 DEFINITIONS IMPLICIT TAGS ::= 1030 BEGIN 1031 EXPORTS ALL; 1032 IMPORTS 1034 AttributeSet{}, Extension{}, EXTENSION, ATTRIBUTE 1035 FROM PKIX-CommonTypes-2009 1036 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1037 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1039 AlgorithmIdentifier{}, DIGEST-ALGORITHM, KEY-WRAP, KEY-DERIVATION, 1040 MAC-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY 1041 FROM AlgorithmInformation-2009 1042 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1043 mechanisms(5) pkix(7) id-mod(0) 1044 id-mod-algorithmInformation-02(58)} 1046 CertificateSerialNumber, GeneralName, CRLReason, ReasonFlags, 1047 CertExtensions, GeneralNames 1048 FROM PKIX1Implicit-2009 1049 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1050 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1052 Name, id-pkix, PublicKeyAlgorithms, SignatureAlgorithms, id-ad, id-kp 1053 FROM PKIX1Explicit-2009 1054 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1055 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1057 ContentInfo, IssuerAndSerialNumber, CONTENT-TYPE 1058 FROM CryptographicMessageSyntax-2010 1059 { iso(1) member-body(2) us(840) rsadsi(113549) 1060 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 1062 CertReqMsg, PKIPublicationInfo, CertTemplate 1063 FROM PKIXCRMF-2009 1064 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1065 mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005-02(55)} 1067 mda-sha1 1068 FROM PKIXAlgs-2009 1069 { iso(1) identified-organization(3) dod(6) 1070 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1071 id-mod-pkix1-algorithms2008-02(56)} 1073 kda-PBKDF2, maca-hMAC-SHA1 1074 FROM CryptographicMessageSyntaxAlgorithms-2009 1075 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1076 smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 1078 mda-sha256 1079 FROM PKIX1-PSS-OAEP-Algorithms-2009 1080 { iso(1) identified-organization(3) dod(6) 1081 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1082 id-mod-pkix1-rsa-pkalgs-02(54) } ; 1084 -- CMS Content types defined in this document 1086 CMC-ContentTypes CONTENT-TYPE ::= { ct-PKIData | ct-PKIResponse, ... } 1088 -- Signature Algorithms defined in this document 1090 SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-noSignature } 1092 -- CMS Unsigned Attributes 1094 CMC-UnsignedAtts ATTRIBUTE ::= { aa-cmc-unsignedData } 1096 -- 1097 -- 1099 id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls 1100 id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types 1102 -- This is the content type for a request message in the protocol 1104 ct-PKIData CONTENT-TYPE ::= 1105 { TYPE PKIData IDENTIFIED BY id-cct-PKIData } 1106 id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 } 1108 PKIData ::= SEQUENCE { 1109 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1110 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 1111 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1112 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1113 } 1115 BodyPartID ::= INTEGER(0..4294967295) 1117 TaggedAttribute ::= SEQUENCE { 1118 bodyPartID BodyPartID, 1119 attrType CMC-CONTROL.&id({Cmc-Control-Set}), 1120 attrValues SET OF CMC-CONTROL. 1121 &Type({Cmc-Control-Set}{@attrType}) 1122 } 1124 Cmc-Control-Set CMC-CONTROL ::= { 1125 cmc-identityProof | cmc-dataReturn | cmc-regInfo | 1126 cmc-responseInfo | cmc-queryPending | cmc-popLinkRandom | 1127 cmc-popLinkWitness | cmc-identification | cmc-transactionId | 1128 cmc-senderNonce | cmc-recipientNonce | cmc-statusInfo | 1129 cmc-addExtensions | cmc-encryptedPOP | cmc-decryptedPOP | 1130 cmc-lraPOPWitness | cmc-getCert | cmc-getCRL | 1131 cmc-revokeRequest | cmc-confirmCertAcceptance | 1132 cmc-statusInfoV2 | cmc-trustedAnchors | cmc-authData | 1133 cmc-batchRequests | cmc-batchResponses | cmc-publishCert | 1134 cmc-modCertTemplate | cmc-controlProcessed | 1135 cmc-identityProofV2 | cmc-popLinkWitnessV2, ..., 1136 cmc-raIdentityWitness | cmc-responseBody } 1138 OTHER-REQUEST ::= TYPE-IDENTIFIER 1140 -- We do not define any other requests in this document 1141 -- examples might be attribute certification requests 1143 OtherRequests OTHER-REQUEST ::= {...} 1145 TaggedRequest ::= CHOICE { 1146 tcr [0] TaggedCertificationRequest, 1147 crm [1] CertReqMsg, 1148 orm [2] SEQUENCE { 1149 bodyPartID BodyPartID, 1150 requestMessageType OTHER-REQUEST.&id({OtherRequests}), 1151 requestMessageValue OTHER-REQUEST.&Type({OtherRequests} 1152 {@.requestMessageType}) 1153 } 1154 } 1156 TaggedCertificationRequest ::= SEQUENCE { 1157 bodyPartID BodyPartID, 1158 certificationRequest CertificationRequest 1159 } 1161 AttributeList ATTRIBUTE ::= {at-extension-req, ..., 1162 at-cmc-changeSubjectName} 1164 CertificationRequest ::= SEQUENCE { 1165 certificationRequestInfo SEQUENCE { 1166 version INTEGER, 1167 subject Name, 1168 subjectPublicKeyInfo SEQUENCE { 1169 algorithm AlgorithmIdentifier{PUBLIC-KEY, 1170 {PublicKeyAlgorithms}}, 1171 subjectPublicKey BIT STRING 1172 }, 1173 attributes [0] IMPLICIT SET OF 1174 AttributeSet{{AttributeList}} 1175 }, 1176 signatureAlgorithm AlgorithmIdentifier 1177 {SIGNATURE-ALGORITHM, 1178 {SignatureAlgorithms}}, 1179 signature BIT STRING 1180 } 1182 TaggedContentInfo ::= SEQUENCE { 1183 bodyPartID BodyPartID, 1184 contentInfo ContentInfo 1185 } 1187 OTHER-MSG ::= TYPE-IDENTIFIER 1189 -- No other messages currently defined 1191 OtherMsgSet OTHER-MSG ::= {...} 1193 OtherMsg ::= SEQUENCE { 1194 bodyPartID BodyPartID, 1195 otherMsgType OTHER-MSG.&id({OtherMsgSet}), 1196 otherMsgValue OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) } 1198 -- This defines the response message in the protocol 1200 ct-PKIResponse CONTENT-TYPE ::= 1201 { TYPE PKIResponse IDENTIFIED BY id-cct-PKIResponse } 1202 id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 } 1204 ResponseBody ::= PKIResponse 1206 PKIResponse ::= SEQUENCE { 1207 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 1208 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 1209 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 1210 } 1212 CMC-CONTROL ::= TYPE-IDENTIFIER 1214 -- The following controls have the type OCTET STRING 1215 cmc-identityProof CMC-CONTROL ::= 1216 { OCTET STRING IDENTIFIED BY id-cmc-identityProof } 1217 id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3} 1219 cmc-dataReturn CMC-CONTROL ::= 1220 { OCTET STRING IDENTIFIED BY id-cmc-dataReturn } 1221 id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4} 1223 cmc-regInfo CMC-CONTROL ::= 1224 { OCTET STRING IDENTIFIED BY id-cmc-regInfo } 1225 id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18} 1227 cmc-responseInfo CMC-CONTROL ::= 1228 { OCTET STRING IDENTIFIED BY id-cmc-responseInfo } 1229 id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19} 1231 cmc-queryPending CMC-CONTROL ::= 1232 { OCTET STRING IDENTIFIED BY id-cmc-queryPending } 1233 id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21} 1235 cmc-popLinkRandom CMC-CONTROL ::= 1236 { OCTET STRING IDENTIFIED BY id-cmc-popLinkRandom } 1237 id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22} 1239 cmc-popLinkWitness CMC-CONTROL ::= 1240 { OCTET STRING IDENTIFIED BY id-cmc-popLinkWitness } 1241 id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23} 1243 -- The following controls have the type UTF8String 1245 cmc-identification CMC-CONTROL ::= 1246 { UTF8String IDENTIFIED BY id-cmc-identification } 1247 id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2} 1249 -- The following controls have the type INTEGER 1251 cmc-transactionId CMC-CONTROL ::= 1252 { INTEGER IDENTIFIED BY id-cmc-transactionId } 1253 id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5} 1255 -- The following controls have the type OCTET STRING 1257 cmc-senderNonce CMC-CONTROL ::= 1258 { OCTET STRING IDENTIFIED BY id-cmc-senderNonce } 1259 id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6} 1261 cmc-recipientNonce CMC-CONTROL ::= 1262 { OCTET STRING IDENTIFIED BY id-cmc-recipientNonce } 1264 id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7} 1266 -- Used to return status in a response 1268 cmc-statusInfo CMC-CONTROL ::= 1269 { CMCStatusInfo IDENTIFIED BY id-cmc-statusInfo } 1270 id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1} 1272 CMCStatusInfo ::= SEQUENCE { 1273 cMCStatus CMCStatus, 1274 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, 1275 statusString UTF8String OPTIONAL, 1276 otherInfo CHOICE { 1277 failInfo CMCFailInfo, 1278 pendInfo PendInfo 1279 } OPTIONAL 1280 } 1282 PendInfo ::= SEQUENCE { 1283 pendToken OCTET STRING, 1284 pendTime GeneralizedTime 1285 } 1287 CMCStatus ::= INTEGER { 1288 success (0), 1289 failed (2), 1290 pending (3), 1291 noSupport (4), 1292 confirmRequired (5), 1293 popRequired (6), 1294 partial (7) 1295 } 1297 CMCFailInfo ::= INTEGER { 1298 badAlg (0), 1299 badMessageCheck (1), 1300 badRequest (2), 1301 badTime (3), 1302 badCertId (4), 1303 unsuportedExt (5), 1304 mustArchiveKeys (6), 1305 badIdentity (7), 1306 popRequired (8), 1307 popFailed (9), 1308 noKeyReuse (10), 1309 internalCAError (11), 1310 tryLater (12), 1311 authDataFail (13) 1313 } 1315 -- Used for RAs to add extensions to certification requests 1317 cmc-addExtensions CMC-CONTROL ::= 1318 { AddExtensions IDENTIFIED BY id-cmc-addExtensions } 1319 id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8} 1321 AddExtensions ::= SEQUENCE { 1322 pkiDataReference BodyPartID, 1323 certReferences SEQUENCE OF BodyPartID, 1324 extensions SEQUENCE OF Extension{{CertExtensions}} 1325 } 1327 cmc-encryptedPOP CMC-CONTROL ::= 1328 { EncryptedPOP IDENTIFIED BY id-cmc-encryptedPOP } 1329 cmc-decryptedPOP CMC-CONTROL ::= 1330 { DecryptedPOP IDENTIFIED BY id-cmc-decryptedPOP } 1331 id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9} 1332 id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10} 1334 EncryptedPOP ::= SEQUENCE { 1335 request TaggedRequest, 1336 cms ContentInfo, 1337 thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}}, 1338 witnessAlgID AlgorithmIdentifier{DIGEST-ALGORITHM, 1339 {WitnessAlgs}}, 1340 witness OCTET STRING 1341 } 1343 POPAlgs MAC-ALGORITHM ::= {maca-hMAC-SHA1, ...} 1344 WitnessAlgs DIGEST-ALGORITHM ::= {mda-sha1, ...} 1346 DecryptedPOP ::= SEQUENCE { 1347 bodyPartID BodyPartID, 1348 thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}}, 1349 thePOP OCTET STRING 1350 } 1352 cmc-lraPOPWitness CMC-CONTROL ::= 1353 { LraPopWitness IDENTIFIED BY id-cmc-lraPOPWitness } 1355 id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11} 1357 LraPopWitness ::= SEQUENCE { 1358 pkiDataBodyid BodyPartID, 1359 bodyIds SEQUENCE OF BodyPartID 1360 } 1361 -- 1363 cmc-getCert CMC-CONTROL ::= 1364 { GetCert IDENTIFIED BY id-cmc-getCert } 1365 id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15} 1367 GetCert ::= SEQUENCE { 1368 issuerName GeneralName, 1369 serialNumber INTEGER } 1371 cmc-getCRL CMC-CONTROL ::= 1372 { GetCRL IDENTIFIED BY id-cmc-getCRL } 1373 id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16} 1375 GetCRL ::= SEQUENCE { 1376 issuerName Name, 1377 cRLName GeneralName OPTIONAL, 1378 time GeneralizedTime OPTIONAL, 1379 reasons ReasonFlags OPTIONAL } 1381 cmc-revokeRequest CMC-CONTROL ::= 1382 { RevokeRequest IDENTIFIED BY id-cmc-revokeRequest} 1383 id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17} 1385 RevokeRequest ::= SEQUENCE { 1386 issuerName Name, 1387 serialNumber INTEGER, 1388 reason CRLReason, 1389 invalidityDate GeneralizedTime OPTIONAL, 1390 passphrase OCTET STRING OPTIONAL, 1391 comment UTF8String OPTIONAL } 1393 cmc-confirmCertAcceptance CMC-CONTROL ::= 1394 { CMCCertId IDENTIFIED BY id-cmc-confirmCertAcceptance } 1395 id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24} 1397 CMCCertId ::= IssuerAndSerialNumber 1399 -- The following is used to request V3 extensions be added 1400 -- to a certificate 1402 at-extension-req ATTRIBUTE ::= 1403 { TYPE ExtensionReq IDENTIFIED BY id-ExtensionReq } 1404 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 1405 rsadsi(113549) pkcs(1) pkcs-9(9) 14} 1407 ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF 1408 Extension{{CertExtensions}} 1410 -- The following allows Diffie-Hellman Certification Request 1411 -- Messages to be well-formed 1413 sa-noSignature SIGNATURE-ALGORITHM ::= { 1414 IDENTIFIER id-alg-noSignature 1415 VALUE NoSignatureValue 1416 PARAMS TYPE NULL ARE required 1417 HASHES { mda-sha1 } 1418 } 1419 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 1421 NoSignatureValue ::= OCTET STRING 1423 -- Unauthenticated attribute to carry removable data. 1425 id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1426 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)} 1428 aa-cmc-unsignedData ATTRIBUTE ::= 1429 { TYPE CMCUnsignedData IDENTIFIED BY id-aa-cmc-unsignedData } 1430 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34} 1432 CMCUnsignedData ::= SEQUENCE { 1433 bodyPartPath BodyPartPath, 1434 identifier TYPE-IDENTIFIER.&id, 1435 content TYPE-IDENTIFIER.&Type 1436 } 1438 -- Replaces CMC Status Info 1439 -- 1441 cmc-statusInfoV2 CMC-CONTROL ::= 1442 { CMCStatusInfoV2 IDENTIFIED BY id-cmc-statusInfoV2 } 1443 id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25} 1445 EXTENDED-FAILURE-INFO ::= TYPE-IDENTIFIER 1447 ExtendedFailures EXTENDED-FAILURE-INFO ::= {...} 1449 CMCStatusInfoV2 ::= SEQUENCE { 1450 cMCStatus CMCStatus, 1451 bodyList SEQUENCE SIZE (1..MAX) OF 1452 BodyPartReference, 1453 statusString UTF8String OPTIONAL, 1454 otherInfo CHOICE { 1455 failInfo CMCFailInfo, 1456 pendInfo PendInfo, 1457 extendedFailInfo [1] SEQUENCE { 1458 failInfoOID TYPE-IDENTIFIER.&id 1459 ({ExtendedFailures}), 1460 failInfoValue TYPE-IDENTIFIER.&Type 1461 ({ExtendedFailures} 1462 {@.failInfoOID}) 1463 } 1464 } OPTIONAL 1465 } 1467 BodyPartReference ::= CHOICE { 1468 bodyPartID BodyPartID, 1469 bodyPartPath BodyPartPath 1470 } 1472 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 1474 -- Allow for distribution of trust anchors 1475 -- 1477 cmc-trustedAnchors CMC-CONTROL ::= 1478 { PublishTrustAnchors IDENTIFIED BY id-cmc-trustedAnchors } 1479 id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26} 1481 PublishTrustAnchors ::= SEQUENCE { 1482 seqNumber INTEGER, 1483 hashAlgorithm AlgorithmIdentifier{DIGEST-ALGORITHM, 1484 {HashAlgorithms}}, 1485 anchorHashes SEQUENCE OF OCTET STRING 1486 } 1488 HashAlgorithms DIGEST-ALGORITHM ::= { 1489 mda-sha1 | mda-sha256, ... 1490 } 1492 cmc-authData CMC-CONTROL ::= 1493 { AuthPublish IDENTIFIED BY id-cmc-authData } 1494 id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27} 1496 AuthPublish ::= BodyPartID 1498 -- These two items use BodyPartList 1500 cmc-batchRequests CMC-CONTROL ::= 1501 { BodyPartList IDENTIFIED BY id-cmc-batchRequests } 1503 id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28} 1505 cmc-batchResponses CMC-CONTROL ::= 1506 { BodyPartList IDENTIFIED BY id-cmc-batchResponses } 1507 id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29} 1509 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID 1511 cmc-publishCert CMC-CONTROL ::= 1512 { CMCPublicationInfo IDENTIFIED BY id-cmc-publishCert } 1513 id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30} 1515 CMCPublicationInfo ::= SEQUENCE { 1516 hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM, 1517 {HashAlgorithms}}, 1518 certHashes SEQUENCE OF OCTET STRING, 1519 pubInfo PKIPublicationInfo 1520 } 1522 cmc-modCertTemplate CMC-CONTROL ::= 1523 { ModCertTemplate IDENTIFIED BY id-cmc-modCertTemplate } 1525 id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31} 1527 ModCertTemplate ::= SEQUENCE { 1528 pkiDataReference BodyPartPath, 1529 certReferences BodyPartList, 1530 replace BOOLEAN DEFAULT TRUE, 1531 certTemplate CertTemplate 1532 } 1534 -- Inform follow-on servers that one or more controls have 1535 -- already been processed 1537 cmc-controlProcessed CMC-CONTROL ::= 1538 { ControlsProcessed IDENTIFIED BY id-cmc-controlProcessed } 1539 id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32} 1541 ControlsProcessed ::= SEQUENCE { 1542 bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference 1543 } 1545 -- Identity Proof control w/ algorithm agility 1547 cmc-identityProofV2 CMC-CONTROL ::= 1548 { IdentityProofV2 IDENTIFIED BY id-cmc-identityProofV2 } 1549 id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 33 } 1550 IdentityProofV2 ::= SEQUENCE { 1551 proofAlgID AlgorithmIdentifier{DIGEST-ALGORITHM, 1552 {WitnessAlgs}}, 1553 macAlgId AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}}, 1554 witness OCTET STRING 1555 } 1557 cmc-popLinkWitnessV2 CMC-CONTROL ::= 1558 { PopLinkWitnessV2 IDENTIFIED BY id-cmc-popLinkWitnessV2 } 1559 id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 34 } 1561 PopLinkWitnessV2 ::= SEQUENCE { 1562 keyGenAlgorithm AlgorithmIdentifier{KEY-DERIVATION, 1563 {KeyDevAlgs}}, 1564 macAlgorithm AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}}, 1565 witness OCTET STRING 1566 } 1568 KeyDevAlgs KEY-DERIVATION ::= {kda-PBKDF2, ...} 1570 cmc-raIdentityWitness CMC-CONTROL ::= 1571 { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness } 1573 id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35} 1575 -- 1576 -- Allow for an End-Entity to request a change in name 1577 -- This item is added to RegControlSet in CRMF 1578 -- 1579 at-cmc-changeSubjectName ATTRIBUTE ::= 1580 { TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName } 1582 id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36} 1584 ChangeSubjectName ::= SEQUENCE { 1585 subject Name OPTIONAL, 1586 subjectAlt GeneralNames OPTIONAL 1587 } 1588 (WITH COMPONENTS {..., subject PRESENT} | 1589 WITH COMPONENTS {..., subjectAlt PRESENT} ) 1591 -- 1592 -- Embedded response from a third party for processing 1593 -- 1595 cmc-responseBody CMC-CONTROL ::= { 1596 BodyPartPath IDENTIFIED BY id-cmc-responseBody 1598 } 1600 id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37} 1602 -- 1603 -- Key purpose identifiers are in the extended key usage extension 1604 -- 1606 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1607 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1608 id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 } 1610 -- 1611 -- Subject Information Access identifier 1612 -- 1614 id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 } 1616 END 1617 Author's Address 1619 Jim Schaad 1620 Soaring Hawk Consulting 1622 Email: jimsch@augustcellars.com