idnits 2.17.1 draft-ietf-pkix-ipki3cmp-04.txt: -(446): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(824): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1763): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1833): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1920): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 21 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 68 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 69 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 539: '..., it is STRONGLY RECOMMENDED that CAs/...' RFC 2119 keyword, line 810: '... protection [0] PKIProtection OPTIONAL,...' RFC 2119 keyword, line 811: '... extraCerts [1] SEQUENCE OF Certificate OPTIONAL...' RFC 2119 keyword, line 846: '... messageTime [0] GeneralizedTime OPTIONAL,...' RFC 2119 keyword, line 850: '... protectionAlg [1] AlgorithmIdentifier OPTIONAL,...' (110 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 698 has weird spacing: '...cate is the...' == Line 699 has weird spacing: '...otected stand...' == Line 700 has weird spacing: '...e where the ...' == Line 701 has weird spacing: '...tory in direc...' == Line 702 has weird spacing: '... to get verif...' == (27 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3225 -- Looks like a reference, but probably isn't: '1' on line 3227 -- Looks like a reference, but probably isn't: '2' on line 3205 -- Looks like a reference, but probably isn't: '3' on line 3092 -- Looks like a reference, but probably isn't: '4' on line 2946 -- Looks like a reference, but probably isn't: '5' on line 2947 -- Looks like a reference, but probably isn't: '6' on line 2948 -- Looks like a reference, but probably isn't: '7' on line 2949 -- Looks like a reference, but probably isn't: '8' on line 2950 -- Looks like a reference, but probably isn't: '9' on line 2951 -- Looks like a reference, but probably isn't: '10' on line 2893 -- Looks like a reference, but probably isn't: '11' on line 2894 -- Looks like a reference, but probably isn't: '12' on line 2895 -- Looks like a reference, but probably isn't: '13' on line 2896 -- Looks like a reference, but probably isn't: '14' on line 2897 -- Looks like a reference, but probably isn't: '15' on line 2898 -- Looks like a reference, but probably isn't: '16' on line 2899 -- Looks like a reference, but probably isn't: '17' on line 2900 -- Looks like a reference, but probably isn't: '18' on line 2901 -- Looks like a reference, but probably isn't: '19' on line 2902 -- Looks like a reference, but probably isn't: '20' on line 2903 -- Looks like a reference, but probably isn't: '21' on line 2904 -- Looks like a reference, but probably isn't: '22' on line 2905 -- Looks like a reference, but probably isn't: '23' on line 2906 == Unused Reference: 'MvOV97' is defined on line 2091, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MvOV97' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS11' -- No information found for draft-ietf-pkix-ipki2opp-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PKIX-OP' ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Adams (Entrust Technologies) 2 PKIX Working Group S. Farrell (SSE) 3 draft-ietf-pkix-ipki3cmp-04.txt 4 Expires in 6 months Sept. 1997 6 Internet Public Key Infrastructure 7 Certificate Management Protocols 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of 6 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This is a draft of the Internet Public Key Infrastructure (X.509) 30 Certificate Management Protocols. Protocol messages are defined for all 31 relevant aspects of certificate creation and management. 33 Introduction 35 The layout of this document is as follows: 37 - Section 1 contains an overview of PKI management; 38 - Section 2 contains discussion of assumptions and restrictions; 39 - Section 3 contains data structures used for PKI management messages; 40 - Section 4 defines the functions that are to be carried out in PKI 41 management by conforming implementations; 42 - Section 5 describes a simple protocol for transporting PKI messages; 43 - the Appendices specify profiles for conforming implementations and 44 provide an ASN.1 module containing the syntax for all defined 45 messages. 47 1 PKI Management Overview 49 The PKI must be structured to be consistent with the types of 50 individuals who must administer it. Providing such administrators with 51 unbounded choices not only complicates the software required but also 52 increases the chances that a subtle mistake by an administrator or 53 software developer will result in broader compromise. Similarly, 54 restricting administrators with cumbersome mechanisms will cause them 55 not to use the PKI. 57 Management protocols are required to support on-line interactions 58 between Public Key Infrastructure (PKI) components. For example, a 59 management protocol might be used between a CA and a client system with 60 which a key pair is associated, or between two CAs that cross-certify 61 each other. 63 1.1 PKI Management Model 65 Before specifying particular message formats and procedures we first 66 define the entities involved in PKI management and their interactions 67 (in terms of the PKI management functions required). We then group 68 these functions in order to accommodate different identifiable types of 69 end entities. 71 1.2 Definitions of PKI Entities 73 The entities involved in PKI management include the end entity (i.e., 74 the entity to be named in the subject field of a certificate) and the 75 certification authority (i.e., the entity named in the issuer field of a 76 certificate). A registration authority may also be involved in PKI 77 management. 79 1.2.1 Subjects and End Entities 81 The term "subject" is used here to refer to the entity named in the 82 subject field of a certificate; when we wish to distinguish the tools 83 and/or software used by the subject (e.g., a local certificate management 84 module) we will use the term "subject equipment". In general, the term 85 "end entity" rather than subject is preferred in order to avoid confusion 86 with the field name. 88 It is important to note that the end entities here will include not only 89 human users of applications, but also applications themselves (e.g., for 90 IP security). This factor influences the protocols which the PKI 91 management operations use; for example, application software is far more 92 likely to know exactly which certificate extensions are required than 93 are human users. PKI management entities are also end entities in the 94 sense that they are sometimes named in the subject field of a 95 certificate or cross-certificate. Where appropriate, the term "end- 96 entity" will be used to refer to end entities who are not PKI management 97 entities. 99 All end entities require secure local access to some information -- at a 100 minimum, their own name and private key, the name of a CA which is 101 directly trusted by this entity and that CA's public key (or a 102 fingerprint of the public key where a self-certified version is 103 available elsewhere). Implementations may use secure local storage for 104 more than this minimum (e.g., the end entity's own certificate or 105 application-specific information). The form of storage will also vary -- 106 from files to tamper-resistant cryptographic tokens. Such local trusted 107 storage is referred to here as the end entity's Personal Security 108 Environment (PSE). 110 Though PSE formats are beyond the scope of this document (they are very 111 dependent on equipment, et cetera), a generic interchange format for 112 PSEs is defined here - a certification response message may be used. 114 1.2.2 Certification Authority 116 The certification authority (CA) may or may not actually be a real 117 "third party" from the end entity's point of view. Quite often, the CA 118 will actually belong to the same organization as the end entities it 119 supports. 121 Again, we use the term CA to refer to the entity named in the issuer 122 field of a certificate; when it is necessary to distinguish the software 123 or hardware tools used by the CA we use the term "CA equipment". 125 The CA equipment will often include both an "off-line" component and an 126 "on-line" component, with the CA private key only available to the "off- 127 line" component. This is, however, a matter for implementers (though it 128 is also relevant as a policy issue). 130 We use the term "root CA" to indicate a CA that is directly trusted by 131 an end entity; that is, securely acquiring the value of a root CA public 132 key requires some out-of-band step(s). This term is not meant to imply 133 that a root CA is at the top of any hierarchy, simply that the CA in 134 question is trusted directly. 136 A "subordinate CA" is one that is not a root CA for the end entity in 137 question. Often, a subordinate CA will not be a root CA for any entity 138 but this is not mandatory. 140 1.2.3 Registration Authority 142 In addition to end-entities and CAs, many environments call for the 143 existence of a registration authority (RA) separate from the 144 certification authority. The functions which the registration authority 145 may carry out will vary from case to case but may include personal 146 authentication, token distribution, revocation reporting, name 147 assignment, key generation, archival of key pairs, et cetera. 149 This document views the RA as an optional component - when it is not 150 present the CA is assumed to be able to carry out the RA's functions so 151 that the PKI management protocols are the same from the end-entity's 152 point of view. 154 Again, we distinguish, where necessary, between the RA and the tools 155 used (the "RA equipment"). 157 Note that an RA is itself an end entity. We further assume that all RAs 158 are in fact certified end entities and that RA private keys are usable 159 for signing. How a particular CA equipment identifies some end entities 160 as RAs is an implementation issue (i.e., this document specifies no 161 special RA certification operation). We do not mandate that the RA is 162 certified by the CA with which it is interacting at the moment (so one 163 RA may work with more than one CA whilst only being certified once). 165 In some circumstances end entities will communicate directly with a CA 166 even where an RA is present. For example, for initial registration 167 and/or certification the subject may use its RA, but communicate 168 directly with the CA in order to refresh its certificate. 170 1.3 PKI Management Requirements 172 The protocols given here meet the following requirements on PKI 173 management. 175 1. PKI management must conform to ISO 9594-8 and the associated 176 amendments (certificate extensions) 178 2. PKI management must conform to the other parts of this series. 180 3. It must be possible to regularly update any key pair without 181 affecting any other key pair. 183 4. The use of confidentiality in PKI management protocols must be kept 184 to a minimum in order to ease regulatory problems. 186 5. PKI management protocols must allow the use of different industry- 187 standard cryptographic algorithms, (specifically including RSA, DSA, 188 MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in 189 principal, use whichever algorithms suit it for its own key pair(s). 191 6. PKI management protocols must not preclude the generation of key 192 pairs by the end-entity concerned, by an RA, or by a CA -- key 193 generation may also occur elsewhere, but for the purposes of PKI 194 management we can regard key generation as occurring wherever the key is 195 first present at an end entity, RA, or CA. 197 7. PKI management protocols must support the publication of 198 certificates by the end-entity concerned, by an RA, or by a CA. 199 Different implementations and different environments may choose any 200 of the above approaches. 202 8. PKI management protocols must support the production of CRLs by 203 allowing certified end entities to make requests for the revocation of 204 certificates - this must be done in such a way that the denial-of- 205 service attacks which are possible are not made simpler. 207 9. PKI management protocols must be usable over a variety of 208 "transport" mechanisms, specifically including mail, http, TCP/IP and 209 ftp. 211 10. Final authority for certification creation rests with the CA; no 212 RA or end-entity equipment can assume that any certificate issued by a 213 CA will contain what was requested -- a CA may alter certificate field 214 values or may add, delete or alter extensions according to its operating 215 policy; the only exception to this is the public key, which the CA must 216 not modify (assuming that the CA was presented with the public key 217 value). In other words, all PKI entities (end-entities, RAs, and CAs) 218 must be capable of handling responses to requests for certificates in 219 which the actual certificate issued is different from that requested 220 (for example, a CA may shorten the validity period requested). 222 11. A graceful, scheduled change-over from one non-compromised CA key 223 pair to the next (CA key update) must be supported (note that if the 224 CA key is compromised, re-initialization must be performed for all 225 entities in the domain of that CA). An end entity whose PSE contains 226 the new CA public key (following a CA key update) must also be able 227 to verify certificates verifiable using the old public key. End 228 entities who directly trust the old CA key pair must also be able to 229 verify certificates signed using the new CA private key. (Required for 230 situations where the old CA public key is "hardwired" into the end 231 entity's cryptographic equipment). 233 12. The Functions of an RA may, in some implementations or 234 environments, be carried out by the CA itself. The protocols must be 235 designed so that end entities will use the same protocol (but, of 236 course, not the same key!) regardless of whether the communication is 237 with an RA or CA. 239 13. Where an end entity requests a certificate containing a given 240 public key value, the end entity must be ready to demonstrate 241 possession of the corresponding private key value (if this is required 242 by the CA/RA with whom the end entity is communicating). This may be 243 accomplished in various ways, depending on the type of certification 244 request. See Section 2.3, "Proof of Possession of Private Key", for 245 details. 247 PKI Management Operations 249 The following diagram shows the relationship between the entities 250 defined above in terms of the PKI management operations. The letters in 251 the diagram indicate "protocols" in the sense that a defined set of PKI 252 management messages can be sent along each of the lettered lines. 254 +---+ cert. publish +------------+ j 255 | | <--------------------- | End Entity | <------- 256 | C | g +------------+ "out-of-band" 257 | | | ^ loading 258 | e | | | initial 259 | r | a | | b registration/ 260 | t | | | certification 261 | | | | key pair recovery 262 | / | | | key pair update 263 | | | | certificate update 264 | C | PKI "USERS" V | revocation request 265 | R | -------------------+-+-----+-+------+-+------------------- 266 | L | PKI MANAGEMENT | ^ | ^ 267 | | ENTITIES a | | b a | | b 268 | | V | | | 269 | R | g +------+ d | | 270 | e | <------------ | RA | <-----+ | | 271 | p | cert. | | ----+ | | | 272 | o | publish +------+ c | | | | 273 | s | | | | | 274 | i | V | V | 275 | t | g +------------+ i 276 | o | <------------------------| CA |-------> 277 | r | h +------------+ "out-of-band" 278 | y | cert. publish | ^ publication 279 | | CRL publish | | 280 +---+ | | cross-certification 281 e | | f cross-certificate 282 | | update 283 | | 284 V | 285 +------+ 286 | CA-2 | 287 +------+ 289 Figure 1 - PKI Entities 291 At a high level the set of operations for which management messages are 292 defined can be grouped as follows. 294 1 CA establishment: When establishing a new CA, certain steps are 295 required (e.g., production of initial CRLs, export of CA public 296 key). 298 2 End entity initialization: this includes importing a root CA 299 public key and requesting information about the options 300 supported by a PKI management entity. 302 3 Certification: various operations result in the creation of new 303 certificates: 305 3.1 initial registration/certification: This is the process whereby 306 an end entity first makes itself known to a CA or RA, prior to the CA 307 issuing a certificate or certificates for that end entity. The end 308 result of this process (when it is successful) is that a CA issues a 309 certificate for an end entity's public key, and returns that 310 certificate to the end entity and/or posts that certificate in a 311 public repository. This process may, and typically will, involve 312 multiple "steps", possibly including an initialization of the end 313 entity's equipment. For example, the end entity's equipment must be 314 securely initialized with the public key of a CA, to be used in 315 validating certificate paths. Furthermore, an end entity typically 316 needs to be initialized with its own key pair(s). 318 3.2 key pair update: Every key pair needs to be updated regularly 319 (i.e., replaced with a new key pair), and a new certificate needs to 320 be issued. 322 3.3 certificate update: As certificates expire they may be 323 "refreshed" if nothing relevant in the environment has changed. 325 3.4 CA key pair update: As with end entities, CA key pairs need to 326 be updated regularly; however, different mechanisms are required. 328 3.5 cross-certification: An requesting CA provides to a responding 329 CA the information necessary for the responding CA to issue a 330 cross-certificate. Note: this action may be mutual, so that two 331 cross-certificates are issued (one in each direction). 333 3.6 cross-certificate update: Similar to a normal certificate update 334 but involving a cross-certificate. 336 4 Certificate/CRL discovery operations: some PKI management 337 operations result in the publication of certificates or CRLs: 339 4.1 certificate publication: Having gone to the trouble of producing 340 a certificate some means for publishing it is needed. The "means" 341 defined in PKIX may involve the messages specified in Sections 342 3.3.13 - 3.3.16, or may involve other methods (LDAP, for example) as 343 described in the "Operational Protocols" part of this series 344 (see [PKIX-OP]). 346 4.2 CRL publication: As for certificate publication. 348 5 Recovery operations: some PKI management operations are used when 349 an end entity has "lost" its PSE: 351 5.1 key pair recovery: As an option, user client key materials 352 (e.g., a user's private key used for decryption purposes) may be backed 353 up by a CA, an RA, or a key backup system associated with a CA or RA. 354 If an entity needs to recover these backed up key materials (e.g., as a 355 result of a forgotten password or a lost key chain file), a protocol 356 exchange may be needed to support such recovery. 358 6 Revocation operations: some PKI operations result in the creation 359 of new CRL entries and/or new CRLs: 361 6.1 revocation request: An authorized person advises a CA of an 362 abnormal situation requiring certificate revocation. 364 7 PSE operations: whilst the definition of PSE operations (e.g., 365 moving a PSE, changing a PIN, etc.) are beyond the scope of this 366 specification, we do define a PKIMessage (CertRep) which can form the 367 basis of such operations. 369 Note that on-line protocols are not the only way of implementing the 370 above operations. For all operations there are off-line methods of 371 achieving the same result, and this specification does not mandate use 372 of on-line protocols. For example, when hardware tokens are used, many 373 of the operations may be achieved as part of the physical token 374 delivery. 376 Later sections define a set of standard messages supporting the above 377 operations. The protocols for conveying these exchanges in different 378 environments (file based, on-line, E-mail, and WWW) is also 379 specified. 381 2. Assumptions and restrictions 383 2.1 End entity initialization 385 The first step for an end entity in dealing with PKI management 386 entities is to request information about the PKI functions supported and 387 to securely acquire a copy of the relevant root CA public key(s). 389 2.2 Initial registration/certification 391 There are many schemes that can be used to achieve initial registration 392 and certification of end entities. No one method is suitable for all 393 situations due to the range of policies which a CA may implement and the 394 variation in the types of end entity which can occur. 396 We can however, classify the initial registration / certification 397 schemes that are supported by this specification. Note that the word 398 "initial", above, is crucial - we are dealing with the situation where 399 the end entity in question has had no previous contact with the PKI. 400 Where the end entity already possesses certified keys then some 401 simplifications/alternatives are possible. 403 Having classified the schemes that are supported by this specification 404 we can then specify some as mandatory and some as optional. The goal is 405 that the mandatory schemes cover a sufficient number of the cases which 406 will arise in real use, whilst the optional schemes are available for 407 special cases which arise less frequently. In this way we achieve a 408 balance between flexibility and ease of implementation. 410 We will now describe the classification of initial registration / 411 certification schemes. 413 2.2.1 Criteria used 415 2.2.1.1 Initiation of registration / certification 417 In terms of the PKI messages which are produced we can regard the 418 initiation of the initial registration / certification exchanges as 419 occurring wherever the first PKI message relating to the end entity is 420 produced. Note that the real-world initiation of the registration / 421 certification procedure may occur elsewhere (e.g., a personnel 422 department may telephone an RA operator). 424 The possible locations are at the end entity, an RA, or a CA. 426 2.2.1.2 End entity message origin authentication 428 The on-line messages produced by the end entity that requires a 429 certificate may be authenticated or not. The requirement here is to 430 authenticate the origin of any messages from the end entity to the PKI 431 (CA/RA). 433 In this specification, such authentication is achieved by the PKI 434 (CA/RA) issuing the end entity with a secret value (initial 435 authentication key) and reference value (used to identify the 436 transaction) via some out-of-band means. The initial authentication key 437 can then be used to protect relevant PKI messages. 439 We can thus classify the initial registration/certification scheme 440 according to whether or not the on-line end entity -> PKI messages are 441 authenticated or not. 443 Note 1: We do not discuss the authentication of the PKI -> end entity 444 messages here as this is always required. In any case, it can be 445 achieved simply once the root-CA public key has been installed at the 446 end entity�s equipment or it can be based on the initial authentication 447 key. 449 Note 2: An initial registration / certification procedure can be secure 450 where the messages from the end entity are authenticated via some out- 451 of-band means (e.g., a subsequent visit). 453 2.2.1.3 Location of key generation 455 In this specification, "key generation" is regarded as occurring 456 wherever either the public or private component of a key pair first 457 occurs in a PKIMessage. Note that this does not preclude a centralized 458 key generation service - the actual key pair may have been generated 459 elsewhere and transported to the end entity, RA, or CA using a 460 (proprietary or standardized) key generation request/response protocol 461 (outside the scope of this specification). 463 There are thus three possibilities for the location of "key 464 generation": the end entity, an RA, or a CA. 466 2.2.1.4 Confirmation of successful certification 468 Following the creation of an initial certificate for an end entity, 469 additional assurance can be gained by having the end entity explicitly 470 confirm successful receipt of the message containing (or indicating the 471 creation of) the certificate. Naturally, this confirmation message must 472 be protected (based on the initial authentication key or other means). 474 This gives two further possibilities: confirmed or not. 476 2.2.2 Mandatory schemes 478 The criteria above allow for a large number of initial registration / 479 certification schemes. This specification mandates that conforming CA 480 equipment, RA equipment, and EE equipment must support the second 481 scheme listed below. Any entity may additionally support other schemes, 482 if desired. 484 2.2.2.1 Centralized scheme 486 In terms of the classification above, this scheme is, in some ways, 487 the simplest possible, where: 489 - initiation occurs at the certifying CA; 490 - no on-line message authentication is required; 491 - "key generation" occurs at the certifying CA (see Section 2.2.1.3); 492 - no confirmation message is required. 494 In terms of message flow, this scheme means that the only message 495 required is sent from the CA to the end entity. The message must contain 496 the entire PSE for the end entity. Some out-of-band means must be 497 provided to allow the end entity to authenticate the message received 498 and decrypt any encrypted values. 500 2.2.2.2 Basic authenticated scheme 502 In terms of the classification above, this scheme is where: 504 - initiation occurs at the end entity; 505 - message authentication is required; 506 - "key generation" occurs at the end entity (see Section 2.2.1.3); 507 - a confirmation message is required. 509 In terms of message flow, the basic authenticated scheme is as follows: 511 End entity RA/CA 512 ========== ============= 513 out-of-band distribution of initial authentication 514 key (IAK) and reference value (RA/CA -> EE) 515 Key generation 516 Creation of certification request 517 Protect request with IAK 518 -->>--certification request-->>-- 519 verify request 520 process request 521 create response 522 --<<--certification response--<<-- 523 handle response 524 create confirmation 525 -->>--confirmation message-->>-- 526 verify confirmation 528 (Where verification of the confirmation message fails, the RA/CA must 529 revoke the newly issued certificate if necessary.) 530 2.3 Proof of Possession (POP) of Private Key 532 In order to prevent certain attacks and to allow a CA/RA to properly 533 check the validity of the binding between an end entity and a key pair, 534 the PKI management operations specified here make it possible for an end 535 entity to prove that it has possession of (i.e., is able to use) the 536 private key corresponding to the public key for which a certificate is 537 requested. A given CA/RA is free to choose whether or not to enforce 538 POP in its certification exchanges (i.e., this may be a policy issue). 539 However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because 540 there are currently many non-PKIX operational protocols in use (various 541 electronic mail protocols are one example) which do not explicitly check 542 the binding between the end entity and the private key. Until 543 operational protocols that do verify the binding (for both signature 544 and encryption key pairs) exist, and are ubiquitous, this binding can 545 only be assumed to have been verified by the CA/RA. Therefore, if the 546 binding is not verified by the CA/RA, certificates in the Internet 547 Public-Key Infrastructure end up being somewhat less meaningful. 549 POP is accomplished in different ways depending on the type of key for 550 which a certificate is requested. If a key can be used for multiple 551 purposes (e.g., an RSA key) then any of the methods may be used. 553 This specification explicitly allows for cases where an end entity 554 supplies the relevant proof to an RA and the RA subsequently attests to 555 the CA that the required proof has been received (and validated!). For 556 example, an end entity wishing to have a signing key certified could 557 send the appropriate signature to the RA which then simply notifies the 558 relevant CA that the end entity has supplied the required proof. Of 559 course, such a situation may be disallowed by some policies (e.g., CAs 560 may be the only entities permitted to verify POP during certification). 562 2.3.1 Signature Keys 564 For signature keys, the end entity can sign a value to prove possession 565 of the private key. 567 2.3.2 Encryption Keys 569 For encryption keys, the end entity can provide the private key to the 570 CA/RA, or can be required to decrypt a value in order to prove 571 possession of the private key (see Section 3.2.8). Decrypting a value 572 can be achieved either directly or indirectly. 574 The direct method is for the RA/CA to issue a random challenge to which 575 an immediate response by the EE is required. 577 The indirect method is to issue a certificate which is encrypted for the 578 end entity (and have the end entity demonstrate its ability to decrypt 579 this certificate in the confirmation message). This allows a CA to issue 580 a certificate in a form which can only be used by the intended end 581 entity. 583 This specification encourages the indirect method because this requires 584 no extra messages to be sent (i.e., the proof can be demonstrated using 585 the {request, response, confirmation} triple of messages). 587 2.3.3 Key Agreement Keys 589 For key agreement keys, the end entity and the PKI management entity 590 (i.e., CA or RA) must establish a shared secret key in order to prove 591 that the end entity has possession of the private key. 593 Note that this need not impose any restrictions on the keys that can be 594 certified by a given CA -- in particular, for Diffie-Hellman keys the 595 end entity may freely choose its algorithm parameters -- provided that 596 the CA can generate a short-term (or one-time) key pair with the 597 appropriate parameters when necessary. 599 2.4 Root CA key update 601 This discussion only applies to CAs that are a root CA for some end 602 entity. 604 The basis of the procedure described here is that the CA protects its 605 new public key using its previous private key and vice versa. Thus when 606 a CA updates its key pair it must generate two extra cACertificate 607 attribute values if certificates are made available using an X.500 608 directory (for a total of four: OldWithOld; OldWithNew; NewWithOld; 609 and NewWithNew). 611 When a CA changes its key pair those entities who have acquired the old 612 CA public key via "out-of-band" means are most affected. It is these end 613 entities who will need access to the new CA public key protected with 614 the old CA private key. However, they will only require this for a 615 limited period (until they have acquired the new CA public key via the 616 "out-of-band" mechanism). This will typically be easily achieved when 617 these end entities' certificates expire. 619 The data structure used to protect the new and old CA public keys is a 620 standard certificate (which may also contain extensions). There are no 621 new data structures required. 623 Note 1. This scheme does not make use of any of the X.509 v3 extensions 624 as it must be able to work even for version 1 certificates. The presence 625 of the KeyIdentifier extension would make for efficiency improvements. 627 Note 2. While the scheme could be generalized to cover cases where the 628 CA updates its key pair more than once during the validity period of 629 one of its end entities' certificates, this generalization seems of 630 dubious value. Not having this generalization simply means that the 631 validity period of a CA key pair must be greater than the validity 632 period of any certificate issued by that CA using that key pair. 634 Note 3.This scheme forces end entities to acquire the new CA public key 635 on the expiry of the last certificate they owned that was signed with 636 the old CA private key (via the "out-of-band" means). Certificate 637 and/or key update operations occurring at other times do not necessarily 638 require this (depending on the end entity's equipment). 640 2.4.1 CA Operator actions 642 To change the key of the CA, the CA operator does the following: 644 1.Generate a new key pair; 646 2.Create a certificate containing the old CA public key signed with 647 the new private key (the "old with new" certificate); 649 3.Create a certificate containing the new CA public key signed with 650 the old private key (the "new with old" certificate); 652 4.Create a certificate containing the new CA public key signed with 653 the new private key (the "new with new" certificate); 655 5.Publish these new certificates via the directory and/or other means 656 (perhaps using a CAKeyUpdAnn message); 658 6.Export the new CA public key so that end entities may acquire it 659 using the "out-of-band" mechanism (if required). 661 The old CA private key is then no longer required. The old CA public key 662 will however remain in use for some time. The time when the old CA 663 public key is no longer required (other than for non-repudiation) will 664 be when all end entities of this CA have securely acquired the new CA 665 public key. 667 The "old with new" certificate must have a validity period starting at 668 the generation time of the old key pair and ending at the expiry date of 669 the old public key. 671 The "new with old" certificate must have a validity period starting at 672 the generation time of the new key pair and ending at the time by which 673 all end entities of this CA will securely possess the new CA public key 674 (at the latest, the expiry date of the old public key). 676 The "new with new" certificate must have a validity period starting at 677 the generation time of the new key pair and ending at the time by which 678 the CA will next update its key pair. 680 2.4.2 Verifying Certificates. 682 Normally when verifying a signature, the verifier verifies (among other 683 things) the certificate containing the public key of the signer. 684 However, once a CA is allowed to update its key there are a range of new 685 possibilities. These are shown in the table below. 687 Repository contains NEW Repository contains only OLD 688 and OLD public keys public key (due to, e.g., 689 delay in publication) 691 PSE PSE Contains PSE Contains PSE Contains 692 Contains OLD public NEW public OLD public 693 NEW public key key key 694 key 696 Signer's Case 1: Case 3: Case 5: Case 7: 697 certifi- This is In this case Although the In this case 698 cate is the the verifier CA operator the CA 699 protected standard must access has not operator has 700 using NEW case where the updated the not updated 701 public the directory in directory the the directory 702 key verifier order to get verifier can and so the 703 can the value of verify the verification 704 directly the NEW certificate will FAIL 705 verify the public key directly - 706 certificate this is thus 707 without the same as 708 using the case 1. 709 directory 711 Signer's Case 2: Case 4: Case 6: Case 8: 712 certifi- In this In this case The verifier Although the 713 cate is case the the verifier thinks this CA operator 714 protected verifier can directly is the has not 715 using OLD must verify the situation of updated the 716 public access the certificate case 2 and directory the 717 key directory without will access verifier can 718 in order using the the verify the 719 to get the directory directory; certificate 720 value of however, the directly - 721 the OLD verification this is thus 722 public key will FAIL the same as 723 case 4. 725 2.4.2.1 Verification in cases 1, 4, 5 and 8. 727 In these cases the verifier has a local copy of the CA public key which 728 can be used to verify the certificate directly. This is the same as the 729 situation where no key change has occurred. 731 Note that case 8 may arise between the time when the CA operator has 732 generated the new key pair and the time when the CA operator stores the 733 updated attributes in the directory. Case 5 can only arise if the CA 734 operator has issued both the signer's and verifier's certificates during 735 this "gap" (the CA operator should avoid this as it leads to the failure 736 cases described below). 738 2.4.2.2 Verification in case 2. 740 In case 2 the verifier must get access to the old public key of the CA. 741 The verifier does the following: 743 1. Look up the caCertificate attribute in the directory and pick the 744 OldWithNew certificate (determined based on validity periods); 745 2. Verify that this is correct using the new CA key (which the 746 verifier has locally); 747 3. If correct, check the signer's certificate using the old CA key. 749 Case 2 will arise when the CA operator has issued the signer's 750 certificate, then changed key and then issued the verifier's 751 certificate, so it is quite a typical case. 753 2.4.2.3 Verification in case 3. 755 In case 3 the verifier must get access to the new public key of the CA. 756 The verifier does the following: 758 1. Look up the CACertificate attribute in the directory and pick the 759 NewWithOld certificate (determined based on validity periods); 760 2. Verify that this is correct using the old CA key (which the verifier 761 has stored locally); 762 3.If correct, check the signer's certificate using the new CA key. 764 Case 3 will arise when the CA operator has issued the verifier's 765 certificate, then changed key and then issued the signer's certificate, 766 so it is also quite a typical case. 768 2.4.2.4 Failure of verification in case 6. 770 In this case the CA has issued the verifier's PSE containing the new key 771 without updating the directory attributes. This means that the verifier 772 has no means to get a trustworthy version of the CA's old key and so 773 verification fails. 775 Note that the failure is the CA operator's fault. 777 2.4.2.5 Failure of verification in case 7. 779 In this case the CA has issued the signer's certificate protected with 780 the new key without updating the directory attributes. This means that 781 the verifier has no means to get a trustworthy version of the CA's new 782 key and so verification fails. 784 Note that the failure is again the CA operator's fault. 786 2.4.3 Revocation - Change of CA key 788 As we saw above the verification of a certificate becomes more complex 789 once the CA is allowed to change its key. This is also true for 790 revocation checks as the CA may have signed the CRL using a newer 791 private key than the one that is within the user's PSE. 793 The analysis of the alternatives is as for certificate verification. 795 3. Data Structures 797 This section contains descriptions of the data structures required for 798 PKI management messages. Section 4 describes constraints on their values 799 and the sequence of events for each of the various PKI management 800 operations. Section 5 describes how these may be encapsulated in various 801 transport mechanisms. 803 3.1 Overall PKI Message 805 All of the messages used in PKI management use the following structure: 807 PKIMessage ::= SEQUENCE { 808 header PKIHeader, 809 body PKIBody, 810 protection [0] PKIProtection OPTIONAL, 811 extraCerts [1] SEQUENCE OF Certificate OPTIONAL 812 } 814 The PKIHeader contains information which is common to many PKI messages. 816 The PKIBody contains message-specific information. 818 The PKIProtection, when used, contains bits that protect the PKI 819 message. 821 The extraCerts field can contain certificates that may be useful to the 822 recipient. For example, this can be used by a CA or RA to present an end 823 entity with certificates that it needs to verify its own new certificate 824 (if, for example, the CA that issued the end entity�s certificate is not 825 a root CA for the end entity). Note that this field does not 826 necessarily contain a certification path - the recipient may have to 827 sort, select from, or otherwise process the extra certificates in order 828 to use them. 830 3.1.1 PKI Message Header 832 All PKI messages require some header information for addressing and 833 transaction identification. Some of this information will also be 834 present in a transport-specific envelope; however, if the PKI message is 835 protected then this information is also protected (i.e., we make no 836 assumption about secure transport). 838 The following data structure is used to contain this information: 840 PKIHeader ::= SEQUENCE { 841 pvno INTEGER { ietf-version1 (0) }, 842 sender GeneralName, 843 -- identifies the sender 844 recipient GeneralName, 845 -- identifies the intended recipient 846 messageTime [0] GeneralizedTime OPTIONAL, 847 -- time of production of this message (used when sender 848 -- believes that the transport will be "suitable"; i.e., 849 -- that the time will still be meaningful upon receipt) 850 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 851 -- algorithm used for calculation of protection bits 852 senderKID [2] KeyIdentifier OPTIONAL, 853 recipKID [3] KeyIdentifier OPTIONAL, 854 -- to identify specific keys used for protection 855 transactionID [4] OCTET STRING OPTIONAL, 856 -- identifies the transaction; i.e., this will be the same in 857 -- corresponding request, response and confirmation messages 858 senderNonce [5] OCTET STRING OPTIONAL, 859 recipNonce [6] OCTET STRING OPTIONAL, 860 -- nonces used to provide replay protection, senderNonce 861 -- is inserted by the creator of this message; recipNonce 862 -- is a nonce previously inserted in a related message by 863 -- the intended recipient of this message 864 freeText [7] PKIFreeText OPTIONAL, 865 -- this may be used to indicate context-specific 866 -- instructions (this field is intended for human 867 -- consumption) 868 generalInfo [8] SET OF InfoTypeAndValue OPTIONAL 869 -- this may be used to convey context-specific information 870 -- (this field not primarily intended for human consumption) 871 } 873 PKIFreeText ::= CHOICE { 874 iA5String [0] IA5String, 875 bMPString [1] BMPString 876 } -- note that the text included here would ideally be in the 877 -- preferred language of the recipient 879 The pvno field is fixed (at zero) for this version of this 880 specification. 882 The sender field contains the name of the sender of the PKIMessage. This 883 name (in conjunction with senderKID, if supplied) should be usable to 884 verify the protection on the message. If nothing about the sender is 885 known to the sending entity (e.g., in the InitReq message, where the 886 end entity may not know its own DN, e-mail name, IP address, etc.), 887 then the "sender" field must contain a "NULL" value; that is, the 888 SEQUENCE OF relative distinguished names is of zero length. In such a 889 case the senderKID field must hold an identifier (i.e., a reference 890 number) which indicates to the receiver the appropriate shared secret 891 information to use to verify the message. 893 The recipient field contains the name of the recipient of the 894 PKIMessage. This name (in conjunction with recipKID, if supplied) should 895 be usable to verify the protection on the message. 897 The protectionAlg field specifies the algorithm used to protect the 898 message. If no protection bits are supplied (note that PKIProtection 899 is optional) then this field must be omitted; if protection bits are 900 supplied then this field must be supplied. 902 senderKID and recipKID are usable to indicate which keys have been used 903 to protect the message (recipKID will normally only be required where 904 protection of the message uses DH keys). 906 The transactionID field within the message header is required so that 907 the recipient of a response message can correlate this with a previously 908 issued request. For example, in the case of an RA there may be many 909 requests "outstanding" at a given moment. 911 The senderNonce and recipNonce fields protect the PKIMessage against 912 replay attacks. 914 The messageTime field contains the time at which the sender created the 915 message. This may be useful to allow end entities to correct their local 916 time to be consistent with the time on a central system. 918 The freeText field may be used to send a human-readable message to the 919 recipient (in the preferred language of the recipient). 921 The generalInfo field may be used to send machine-processable additional 922 data to the recipient. 924 3.1.2 PKI Message Body 926 PKIBody ::= CHOICE { -- message-specific body elements 927 ir [0] InitReqContent, 928 ip [1] InitRepContent, 929 cr [2] CertReqContent, 930 cp [3] CertRepContent, 931 p10cr [4] CertificationRequest, 932 -- the PKCS #10 certification request (see [PKCS10]) 933 popdecc [5] POPODecKeyChallContent, 934 popdecr [6] POPODecKeyRespContent, 935 kur [7] KeyUpdReqContent, 936 kup [8] KeyUpdRepContent, 937 krr [9] KeyRecReqContent, 938 krp [10] KeyRecRepContent, 939 rr [11] RevReqContent, 940 rp [12] RevRepContent, 941 ccr [13] CrossCertReqContent, 942 ccp [14] CrossCertRepContent, 943 ckuann [15] CAKeyUpdAnnContent, 944 cann [16] CertAnnContent, 945 rann [17] RevAnnContent, 946 crlann [18] CRLAnnContent, 947 conf [19] PKIConfirmContent, 948 nested [20] NestedMessageContent, 949 genr [21] GenReqContent, 950 genp [22] GenRepContent, 951 error [23] ErrorMsgContent 952 } 954 The specific types are described in section 3.3 below. 956 3.1.3 PKI Message Protection 958 Some PKI messages will be protected for integrity. (Note that if an 959 asymmetric algorithm is used to protect a message and the relevant 960 public component has been certified already, then the origin of message 961 can also be authenticated. On the other hand, if the public component 962 is uncertified then the message origin cannot be automatically 963 authenticated, but may be authenticated via out-of-band means.) 965 When protection is applied the following structure is used: 967 PKIProtection ::= BIT STRING 969 The input to the calculation of PKIProtection is the DER encoding 970 of the following data structure: 972 ProtectedPart ::= SEQUENCE { 973 header PKIHeader, 974 body PKIBody 975 } 977 There may be cases in which the PKIProtection BIT STRING is deliberately 978 not used to protect a message (i.e., this OPTIONAL field is omitted) 979 because other protection, external to PKIX, will instead be applied. 980 Such a choice is explicitly allowed in this specification. Examples of 981 such external protection include PKCS #7 [PKCS7] and Security Multiparts 982 [RFC1847] encapsulation of the PKIMessage (examples of external 983 protection using PKCS #7 will be provided in a separate document). It 984 is noted, however, that many such external mechanisms require that the 985 end entity already possesses a public-key certificate, and/or a unique 986 Distinguished Name, and/or other such infrastructure-related information. 987 Thus, they may not be appropriate for initial registration, key-recovery, 988 or any other process with "boot-strapping" characteristics. For those 989 cases it may be necessary that the PKIProtection parameter be used. In 990 the future, if/when external mechanisms are modified to accommodate 991 boot-strapping scenarios, the use of the PKIProtection parameter may 992 become rare or non-existent. 994 Depending on the circumstances the PKIProtection bits may contain a MAC 995 or signature. Only the following cases can occur: 997 - shared secret information 999 In this case the sender and recipient share secret information 1000 (established via out-of-band means or from a previous PKI management 1001 operation). PKIProtection will contain a MAC value and the 1002 protectionAlg will be the following: 1004 PasswordBasedMac ::= OBJECT IDENTIFIER 1006 PBMParameter ::= SEQUENCE { 1007 salt OCTET STRING, 1008 owf AlgorithmIdentifier, 1009 -- AlgId for a One-Way Function (SHA-1 recommended) 1010 iterationCount INTEGER, 1011 -- number of times the OWF is applied 1012 mac AlgorithmIdentifier 1013 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1014 } -- or HMAC [RFC2104]) 1016 In the above protectionAlg the salt value is appended to the shared 1017 secret input. The OWF is then applied iterationCount times, where the 1018 salted secret is the input to the first iteration and, for each 1019 successive iteration, the input is set to be the output of the previous 1020 iteration. The output of the final iteration (called "BASEKEY" for ease 1021 of reference, with a size of "H") is what is used to form the symmetric 1022 key. If the MAC algorithm requires a K-bit key and K <= H, then the most 1023 significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is 1024 used for the most significant H bits of the key, OWF("1" || BASEKEY) is 1025 used for the next most significant H bits of the key, OWF("2" || 1026 BASEKEY) is used for the next most significant H bits of the key, and so 1027 on, until all K bits have been derived. [Here "N" is the ASCII byte 1028 encoding the number N and "||" represents concatenation.] 1029 - DH key pairs 1031 Where the sender and receiver possess Diffie-Hellman certificates with 1032 compatible DH parameters, then in order to protect the message the end 1033 entity must generate a symmetric key based on its private DH key value 1034 and the DH public key of the recipient of the PKI message. 1035 PKIProtection will contain a MAC value keyed with this derived 1036 symmetric key and the protectionAlg will be the following: 1038 DHBasedMac ::= OBJECT IDENTIFIER 1040 DHBMParameter ::= SEQUENCE { 1041 owf AlgorithmIdentifier, 1042 -- AlgId for a One-Way Function (SHA-1 recommended) 1043 mac AlgorithmIdentifier 1044 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1045 } -- or HMAC [RFC2104]) 1047 In the above protectionAlg OWF is applied to the result of the Diffie- 1048 Hellman computation. The OWF output (called "BASEKEY" for ease of 1049 reference, with a size of "H") is what is used to form the symmetric 1050 key. If the MAC algorithm requires a K-bit key and K <= H, then the most 1051 significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is 1052 used for the most significant H bits of the key, OWF("1" || BASEKEY) is 1053 used for the next most significant H bits of the key, OWF("2" || 1054 BASEKEY) is used for the next most significant H bits of the key, and so 1055 on, until all K bits have been derived. [Here "N" is the ASCII byte 1056 encoding the number N and "||" represents concatenation.] 1058 - signature 1060 Where the sender possesses a signature key pair it may simply sign the 1061 PKI message. PKIProtection will contain the signature value and the 1062 protectionAlg will be an AlgorithmIdentifier for a digital signature 1063 (e.g., md5WithRSAEncryption or dsaWithSha-1). 1065 - multiple protection 1067 In cases where an end entity sends a protected PKI message to an RA, the 1068 RA may forward that message to a CA, attaching its own protection. This 1069 is accomplished by nesting the entire message sent by the end entity 1070 within a new PKI message. The structure used is as follows. 1072 NestedMessageContent ::= PKIMessage 1074 3.2 Common Data Structures 1076 Before specifying the specific types that may be placed in a PKIBody we 1077 define some data structures that are used in more than one case. 1079 3.2.1 Requested Certificate Contents 1081 Various PKI management messages require that the originator of the 1082 message indicate some of the fields that are required to be present in 1083 a certificate. The CertTemplate structure allows an end entity or RA to 1084 specify as much as it wishes about the certificate it requires. 1085 CertTemplate is identical to a Certificate but with all fields optional. 1087 Note that even if the originator completely specifies the contents of a 1088 certificate it requires, a CA is free to modify fields within the 1089 certificate actually issued. 1091 CertTemplate ::= SEQUENCE { 1092 version [0] Version OPTIONAL, 1093 -- used to ask for a particular syntax version 1094 serialNumber [1] INTEGER OPTIONAL, 1095 -- used to ask for a particular serial number 1096 signingAlg [2] AlgorithmIdentifier OPTIONAL, 1097 -- used to ask the CA to use this alg. for signing the cert 1098 issuer [3] Name OPTIONAL, 1099 validity [4] OptionalValidity OPTIONAL, 1100 subject [5] Name OPTIONAL, 1101 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 1102 issuerUID [7] UniqueIdentifier OPTIONAL, 1103 subjectUID [8] UniqueIdentifier OPTIONAL, 1104 extensions [9] Extensions OPTIONAL 1105 -- the extensions which the requester would like in the cert. 1106 } 1108 OptionalValidity ::= SEQUENCE { 1109 notBefore [0] CertificateValidityDate OPTIONAL, 1110 notAfter [1] CertificateValidityDate OPTIONAL 1111 } 1113 CertificateValidityDate ::= CHOICE { 1114 utcTime UTCTime, 1115 generalTime GeneralizedTime 1116 } 1118 3.2.2 Encrypted Values 1120 Where encrypted values (restricted, in this specification, to be either 1121 private keys or certificates) are sent in PKI messages the following 1122 data structure is used. 1124 EncryptedValue ::= SEQUENCE { 1125 encValue BIT STRING, 1126 -- the encrypted value itself 1127 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 1128 -- the intended algorithm for which the value will be used 1129 symmAlg [1] AlgorithmIdentifier OPTIONAL, 1130 -- the symmetric algorithm used to encrypt the value 1131 encSymmKey [2] BIT STRING OPTIONAL, 1132 -- the (encrypted) symmetric key used to encrypt the value 1133 keyAlg [3] AlgorithmIdentifier OPTIONAL 1134 -- algorithm used to encrypt the symmetric key 1135 } 1137 Use of this data structure requires that the creator and intended 1138 recipient respectively be able to encrypt and decrypt. Typically, this 1139 will mean that the sender and recipient have, or are able to generate, a 1140 shared secret key. 1142 If the recipient of the PKIMessage already possesses a private key 1143 usable for decryption, then the encSymmKey field may contain a session 1144 key encrypted using the recipient's public key. 1146 3.2.3 Status codes and Failure Information for PKI messages 1148 All response messages will include some status information. The 1149 following values are defined. 1151 PKIStatus ::= INTEGER { 1152 granted (0), 1153 -- you got exactly what you asked for 1154 grantedWithMods (1), 1155 -- you got something like what you asked for; the 1156 -- requester is responsible for ascertaining the differences 1157 rejection (2), 1158 -- you don't get it, more information elsewhere in the message 1159 waiting (3), 1160 -- the request body part has not yet been processed, 1161 -- expect to hear more later 1162 revocationWarning (4), 1163 -- this message contains a warning that a revocation is 1164 -- imminent 1165 revocationNotification (5), 1166 -- notification that a revocation has occurred 1167 keyUpdateWarning (6) 1168 -- update already done for the oldCertId specified in 1169 -- FullCertTemplate 1170 } 1172 Responders may use the following syntax to provide more information 1173 about failure cases. 1175 PKIFailureInfo ::= BIT STRING { 1176 -- since we can fail in more than one way! 1177 -- More codes may be added in the future if/when required. 1178 badAlg (0), 1179 -- unrecognized or unsupported Algorithm Identifier 1180 badMessageCheck (1), 1181 -- integrity check failed (e.g., signature did not verify) 1182 badRequest (2), 1183 -- transaction not permitted or supported 1184 badTime (3), 1185 -- messageTime was not sufficiently close to the system time, 1186 -- as defined by local policy 1187 badCertId (4), 1188 -- no certificate could be found matching the provided criteria 1189 badDataFormat (5), 1190 -- the data submitted has the wrong format 1191 wrongAuthority (6), 1192 -- the authority indicated in the request is different from the 1193 -- one creating the response token 1194 incorrectData (7), 1195 -- the requester's data is incorrect (used for notary services) 1196 missingTimeStamp (8) 1197 -- when the timestamp is missing but should be there (by policy) 1198 } 1200 PKIStatusInfo ::= SEQUENCE { 1201 status PKIStatus, 1202 statusString PKIFreeText OPTIONAL, 1203 failInfo PKIFailureInfo OPTIONAL 1204 } 1206 3.2.4 Certificate Identification 1208 In order to identify particular certificates the following data 1209 structure is used. 1211 CertId ::= SEQUENCE { 1212 issuer GeneralName, 1213 serialNumber INTEGER 1214 } 1216 3.2.5 "Out-of-band" root CA public key 1218 Each root CA must be able to publish its current public key via some 1219 "out-of-band" means. While such mechanisms are beyond the scope of this 1220 document, we define data structures which can support such mechanisms. 1222 There are generally two methods available: either the CA directly 1223 publishes its self-signed certificate; or this information is available 1224 via the Directory (or equivalent) and the CA publishes a hash of this 1225 value to allow verification of its integrity before use. 1227 OOBCert ::= Certificate 1229 The fields within this certificate are restricted as follows: 1231 - The certificate must be self-signed (i.e., the signature must be 1232 verifiable using the subjectPublicKey field); 1233 - The subject and issuer fields must be identical; 1234 - If the subject field is NULL then both subjectAltNames and 1235 issuerAltNames extensions must be present and have exactly the same 1236 value; 1237 - The values of all other extensions must be suitable for a self-signed 1238 certificate (e.g., key identifiers for subject and issuer must be the 1239 same). 1241 OOBCertHash ::= SEQUENCE { 1242 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1243 certId [1] CertId OPTIONAL, 1244 hashVal BIT STRING 1245 -- hashVal is calculated over the self-signed 1246 -- certificate with the identifier certID. 1247 } 1249 The intention of the hash value is that anyone who has securely 1250 received the hash value (via the out-of-band means) can verify a self- 1251 signed certificate for that CA. 1253 3.2.6 Archive Options 1255 Requesters may indicate that they wish the PKI to archive a private key 1256 value using the following structure: 1258 PKIArchiveOptions ::= CHOICE { 1259 encryptedPrivKey [0] EncryptedValue, 1260 -- the actual value of the private key 1261 keyGenParameters [1] KeyGenParameters, 1262 -- parameters which allow the private key to be re-generated 1263 archiveRemGenPrivKey [2] BOOLEAN 1264 -- set to TRUE if sender wishes receiver to archive the private 1265 -- key of a key pair which the receiver generates in response to 1266 -- this request; set to FALSE if no archival is desired. 1267 } 1268 KeyGenParameters ::= OCTET STRING 1269 -- an alternative to sending the key is to send the information 1270 -- about how to re-generate the key (e.g., for many RSA 1271 -- implementations one could send the first random numbers tested 1272 -- for primality). 1273 -- The actual syntax for this parameter may be defined in a 1274 -- subsequent version of this document or in another standard. 1276 3.2.7 Publication Information 1277 Requesters may indicate that they wish the PKI to publish a certificate 1278 using the structure below. 1280 If the dontPublish option is chosen, the requester indicates that the 1281 PKI should not publish the certificate (this may indicate that the 1282 requester intends to publish the certificate him/herself). 1284 If the dontCare method is chosen, the requester indicates that the PKI 1285 may publish the certificate using whatever means it chooses. 1287 The pubLocation field, if supplied, indicates where the requester would 1288 like the certificate to be found (note that the CHOICE within 1289 GeneralName includes a URL and an IP address, for example). 1291 PKIPublicationInfo ::= SEQUENCE { 1292 action INTEGER { 1293 dontPublish (0), 1294 pleasePublish (1) 1295 }, 1296 pubInfos SEQUENCE OF SinglePubInfo OPTIONAL 1297 -- pubInfos must not be present if action is "dontPublish" 1298 -- (if action is "pleasePublish" and pubInfos is omitted, 1299 -- "dontCare" is assumed) 1300 } 1302 SinglePubInfo ::= SEQUENCE { 1303 pubMethod INTEGER { 1304 dontCare (0), 1305 x500 (1), 1306 web (2) 1307 }, 1308 pubLocation GeneralName OPTIONAL 1309 } 1311 3.2.8 "Full" Request Template 1313 The following structure groups together the fields which may be sent as 1314 part of a certification request: 1316 FullCertTemplates ::= SEQUENCE OF FullCertTemplate 1317 FullCertTemplate ::= SEQUENCE { 1318 certReqId INTEGER, 1319 -- a non-negative value to match this request with corresponding 1320 -- response (note: must be unique over all FullCertReqs in this 1321 -- message) 1322 certTemplate CertTemplate, 1323 popoPrivKeyVerified BOOLEAN DEFAULT FALSE, 1324 popoSigningKey [0] POPOSigningKey OPTIONAL, 1325 archiveOptions [1] PKIArchiveOptions OPTIONAL, 1326 publicationInfo [2] PKIPublicationInfo OPTIONAL, 1327 oldCertId [3] CertId OPTIONAL 1328 -- id. of cert. which is being updated by this one 1329 } 1331 When the certification request is made by an RA on behalf of some other 1332 end entity, then the RA may indicate to the CA that it has already 1333 verified proof-of-possession (of the private key corresponding to the 1334 public key for which a certificate is being requested) by setting 1335 popoPrivKeyVerified to TRUE. If the proof-of-possession has not yet 1336 been verified, or if the request is not being made by an RA, then the 1337 popoPrivKeyVerified field is omitted (defaulting to FALSE) and the 1338 popoSigningKey field or the challenge-response protocol described below 1339 may be used to prove possession (depending on the type of key involved). 1341 If the certification request is for a signing key pair (i.e., a request 1342 for a verification certificate), then the proof of possession of the 1343 private signing key is demonstrated through use of the POPOSigningKey 1344 structure. 1346 POPOSigningKey ::= SEQUENCE { 1347 poposkInput POPOSKInput, 1348 alg AlgorithmIdentifier, 1349 signature BIT STRING 1350 -- the signature (using "alg") on the DER-encoded 1351 -- value of poposkInput 1352 } 1354 POPOSKInput ::= CHOICE { 1355 popoSigningKeyInput [0] POPOSigningKeyInput, 1356 certificationRequestInfo CertificationRequestInfo 1357 -- imported from [PKCS10] (note that if this choice is used, 1358 -- POPOSigningKey is simply a standard PKCS #10 request; this 1359 -- allows a bare PKCS #10 request to be augmented with other 1360 -- desired information in the FullCertTemplate before being 1361 -- sent to the CA/RA) 1362 } 1363 POPOSigningKeyInput ::= SEQUENCE { 1364 authInfo CHOICE { 1365 sender [0] GeneralName, 1366 -- from PKIHeader (used only if an authenticated identity 1367 -- has been established for the sender (e.g., a DN from a 1368 -- previously-issued and currently-valid certificate) 1369 publicKeyMAC [1] BIT STRING 1370 -- used if no authenticated GeneralName currently exists for 1371 -- the sender; publicKeyMAC contains a password-based MAC 1372 -- (using the protectionAlg AlgId from PKIHeader) on the 1373 -- DER-encoded value of publicKey 1374 }, 1375 publicKey SubjectPublicKeyInfo -- from CertTemplate 1376 } 1378 On the other hand, if the certification request is for an encryption key 1379 pair (i.e., a request for an encryption certificate), then the proof of 1380 possession of the private decryption key may be demonstrated in one of 1381 three ways. 1383 1) By the inclusion of the private key (encrypted) in the 1384 FullCertTemplate (in the PKIArchiveOptions structure). 1386 2) By having the CA return not the certificate, but an encrypted 1387 certificate (i.e., the certificate encrypted under a randomly-generated 1388 symmetric key, and the symmetric key encrypted under the public key for 1389 which the certification request is being made) -- this is the "indirect" 1390 method mentioned previously in Section 2.3.2. The end entity proves 1391 knowledge of the private decryption key to the CA by MACing the 1392 PKIConfirm message using a key derived from this symmetric key. [Note 1393 that if several FullCertTemplates are included in the PKIMessage, then 1394 the CA uses a different symmetric key for each FullCertTemplate and the 1395 MAC uses a key derived from the concatenation of all these keys.] The 1396 MACing procedure uses the PasswordBasedMac AlgId defined in Section 3.1. 1398 3) By having the end entity engage in a challenge-response protocol 1399 (using the messages POPODecKeyChall and POPODecKeyResp; see below) 1400 between the CertReq and CertRep messages -- this is the "direct" method 1401 mentioned previously in Section 2.3.2. [This method would typically 1402 be used in an environment in which an RA verifies POP and then makes a 1403 certification request to the CA on behalf of the end entity. In such a 1404 scenario, the CA trusts the RA to have done POP correctly before the RA 1405 requests a certificate for the end entity.] The complete protocol then 1406 looks as follows (note that req' does not necessarily encapsulate req as 1407 a nested message): 1409 EE RA CA 1410 ---- req ----> 1411 <--- chall --- 1412 ---- resp ---> 1413 ---- req' ---> 1414 <--- rep ----- 1415 ---- conf ---> 1416 <--- rep ----- 1417 ---- conf ---> 1419 This protocol is obviously much longer than the 3-way exchange given in 1420 choice (2) above, but allows a local Registration Authority to be 1421 involved and has the property that the certificate itself is not 1422 actually created until the proof of possession is complete. 1424 3.3 Operation-Specific Data Structures 1426 3.3.1 Initialization Request 1428 An Initialization request message contains as the PKIBody an 1429 InitReqContent data structure which specifies the requested 1430 certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity 1431 are the template fields which may be supplied for each certificate 1432 requested (see Appendix B profiles for further information). 1434 InitReqContent ::= SEQUENCE { 1435 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 1436 fullCertTemplates FullCertTemplates 1437 } 1439 3.3.2 Initialization Response 1441 An Initialization response message contains as the PKIBody an 1442 InitRepContent data structure which has for each certificate requested 1443 a PKIStatusInfo field, a subject certificate, and possibly a private 1444 key (normally encrypted with a session key, which is itself encrypted 1445 with the protocolEncKey). 1447 InitRepContent ::= CertRepContent 1449 3.3.3 Registration/Certification Request 1451 A Registration/Certification request message contains as the PKIBody a 1452 CertReqContent data structure which specifies the requested 1453 FullCertTemplates. 1455 Alternatively, for the cases in which it can be used, the PKIBody may 1456 be a CertificationRequest. This structure is fully specified by 1457 the ASN.1 structure CertificationRequest given in [PKCS10]. 1459 CertReqContent ::= FullCertTemplates 1461 The challenge-response messages for proof of possession of a private 1462 decryption key are specified as follows (see [MvOV97, p.404], for 1463 details). Note that this challenge-response exchange is associated with 1464 the preceding cert. request message (and subsequent cert. response and 1465 confirmation messages) by the nonces used in the PKIHeader and by the 1466 protection (MACing or signing) applied to the PKIMessage. 1468 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1469 -- One Challenge per encryption key certification request (in the 1470 -- same order as these requests appear in FullCertTemplates). 1472 Challenge ::= SEQUENCE { 1473 owf AlgorithmIdentifier OPTIONAL, 1474 -- must be present in the first Challenge; may be omitted in any 1475 -- subsequent Challenge in POPODecKeyChallContent (if omitted, 1476 -- then the owf used in the immediately preceding Challenge is 1477 -- to be used). 1478 witness OCTET STRING, 1479 -- the result of applying the one-way function (owf) to a 1480 -- randomly-generated INTEGER, A. [Note that a different 1481 -- INTEGER must be used for each Challenge.] 1482 challenge OCTET STRING 1483 -- the encryption (under the public key for which the cert. 1484 -- request is being made) of Rand, where Rand is specified as 1485 -- Rand ::= SEQUENCE { 1486 -- int INTEGER, 1487 -- - the randomly-generated INTEGER A (above) 1488 -- sender GeneralName 1489 -- - the sender's name (as included in PKIHeader) 1490 -- } 1491 } 1493 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1494 -- One INTEGER per encryption key certification request (in the 1495 -- same order as these requests appear in FullCertTemplates). The 1496 -- retrieved INTEGER A (above) is returned to the sender of the 1497 -- corresponding Challenge. 1499 3.3.4 Registration/Certification Response 1501 A registration response message contains as the PKIBody a 1502 CertRepContent data structure which has a CA public key, a status 1503 value and optionally failure information, a subject certificate, and 1504 an encrypted private key. 1506 CertRepContent ::= SEQUENCE { 1507 caPubs [1] SEQUENCE OF Certificate OPTIONAL, 1508 response SEQUENCE OF CertResponse 1509 } 1511 CertResponse ::= SEQUENCE { 1512 certReqId INTEGER, 1513 -- to match this response with corresponding request (a value 1514 -- of -1 is to be used if certReqId is not specified in the 1515 -- corresponding request) 1516 status PKIStatusInfo, 1517 certifiedKeyPair CertifiedKeyPair OPTIONAL 1518 } 1520 CertifiedKeyPair ::= SEQUENCE { 1521 certOrEncCert CertOrEncCert, 1522 privateKey [0] EncryptedValue OPTIONAL, 1523 publicationInfo [1] PKIPublicationInfo OPTIONAL 1524 } 1526 CertOrEncCert ::= CHOICE { 1527 certificate [0] Certificate, 1528 encryptedCert [1] EncryptedValue 1529 } 1531 Only one of the failInfo (in PKIStatusInfo) and certificate (in 1532 CertifiedKeyPair) fields can be present in each CertResponse (depending 1533 on the status). For some status values (e.g., waiting) neither of the 1534 optional fields will be present. 1536 Given an EncryptedCert and the relevant decryption key the certificate 1537 may be obtained. The purpose of this is to allow a CA to return the 1538 value of a certificate, but with the constraint that only the intended 1539 recipient can obtain the actual certificate. The benefit of this 1540 approach is that a CA may reply with a certificate even in the absence 1541 of a proof that the requester is the end entity which can use the 1542 relevant private key (note that the proof is not obtained until the 1543 PKIConfirm message is received by the CA). Thus the CA will not have to 1544 revoke that certificate in the event that something goes wrong with the 1545 proof of possession. 1547 3.3.5 Key update request content 1549 For key update requests the following syntax is used. Typically, 1550 SubjectPublicKeyInfo, KeyId, and Validity are the template fields which 1551 may be supplied for each key to be updated. 1553 KeyUpdReqContent ::= SEQUENCE { 1554 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 1555 fullCertTemplates [1] FullCertTemplates OPTIONAL 1556 } 1558 3.3.6 Key Update response content 1560 For key update responses the syntax used is identical to the 1561 initialization response. 1563 KeyUpdRepContent ::= InitRepContent 1565 3.3.7 Key Recovery Request content 1567 For key recovery requests the syntax used is identical to the 1568 initialization request InitReqContent. Typically, SubjectPublicKeyInfo 1569 and KeyId are the template fields which may be used to supply a 1570 signature public key for which a certificate is required (see Appendix B 1571 profiles for further information). 1573 KeyRecReqContent ::= InitReqContent 1575 3.3.8 Key recovery response content 1577 For key recovery responses the following syntax is used. For some 1578 status values (e.g., waiting) none of the optional fields will be 1579 present. 1581 KeyRecRepContent ::= SEQUENCE { 1582 status PKIStatusInfo, 1583 newSigCert [0] Certificate OPTIONAL, 1584 caCerts [1] SEQUENCE OF Certificate OPTIONAL, 1585 keyPairHist [2] SEQUENCE OF CertifiedKeyPair OPTIONAL 1586 } 1588 3.3.9 Revocation Request Content 1590 When requesting revocation of a certificate (or several certificates) 1591 the following data structure is used. The name of the requester is 1592 present in the PKIHeader structure. 1594 RevReqContent ::= SEQUENCE OF RevDetails 1596 RevDetails ::= SEQUENCE { 1597 certDetails CertTemplate, 1598 -- allows requester to specify as much as they can about 1599 -- the cert. for which revocation is requested 1600 -- (e.g., for cases in which serialNumber is not available) 1601 revocationReason ReasonFlags, 1602 -- from the DAM, so CA knows what to use in Dist. point 1603 badSinceDate GeneralizedTime OPTIONAL, 1604 -- indicates best knowledge of sender 1605 crlEntryDetails Extensions 1606 -- requested crlEntryExtensions 1607 } 1609 3.3.10 Revocation Response Content 1611 The response to the above message. If produced, this is sent to the 1612 requester of the revocation. (A separate revocation announcement message 1613 may be sent to the subject of the certificate for which revocation was 1614 requested.) 1616 RevRepContent ::= SEQUENCE { 1617 status PKIStatusInfo, 1618 revCerts [0] SEQUENCE OF CertId OPTIONAL, 1619 -- identifies the certs for which revocation was requested 1620 crls [1] SEQUENCE OF CertificateList OPTIONAL 1621 -- the resulting CRLs (there may be more than one) 1622 } 1624 3.3.11 Cross certification request content 1626 Cross certification requests use the same syntax as for normal 1627 certification requests with the restriction that the key pair must have 1628 been generated by the requesting CA and the private key must not be sent 1629 to the responding CA. 1631 CrossCertReqContent ::= CertReqContent 1633 3.3.12 Cross certification response content 1635 Cross certification responses use the same syntax as for normal 1636 certification responses with the restriction that no encrypted private 1637 key can be sent. 1639 CrossCertRepContent ::= CertRepContent 1641 3.3.13 CA Key Update Announcement content 1643 When a CA updates its own key pair the following data structure may be 1644 used to announce this event. 1646 CAKeyUpdAnnContent ::= SEQUENCE { 1647 oldWithNew Certificate, -- old pub signed with new priv 1648 newWithOld Certificate, -- new pub signed with old priv 1649 newWithNew Certificate -- new pub signed with new priv 1650 } 1652 3.3.14 Certificate Announcement 1654 This data structure may be used to announce the existence of 1655 certificates. 1657 Note that this message is intended to be used for those cases (if any) 1658 where there is no pre-existing method for publication of certificates; 1659 it is not intended to be used where, for example, X.500 is the 1660 method for publication of certificates. 1662 CertAnnContent ::= Certificate 1664 3.3.15 Revocation Announcement 1666 When a CA has revoked, or is about to revoke, a particular certificate 1667 it may issue an announcement of this (possibly upcoming) event. 1669 RevAnnContent ::= SEQUENCE { 1670 status PKIStatus, 1671 certId CertId, 1672 willBeRevokedAt GeneralizedTime, 1673 badSinceDate GeneralizedTime, 1674 crlDetails Extensions OPTIONAL 1675 -- extra CRL details(e.g., crl number, reason, location, etc.) 1676 } 1678 A CA may use such an announcement to warn (or notify) a subject that its 1679 certificate is about to be (or has been) revoked. This would typically 1680 be used where the request for revocation did not come from the subject 1681 concerned. 1683 The willBeRevokedAt field contains the time at which a new entry will be 1684 added to the relevant CRLs. 1686 3.3.16 CRL Announcement 1688 When a CA issues a new CRL (or set of CRLs) the following data structure 1689 may be used to announce this event. 1691 CRLAnnContent ::= SEQUENCE OF CertificateList 1693 3.3.17 PKI Confirmation content 1695 This data structure is used in three-way protocols as the final 1696 PKIMessage. Its content is the same in all cases - actually there is no 1697 content since the PKIHeader carries all the required information. 1699 PKIConfirmContent ::= NULL 1701 3.3.18 PKI General Request content 1703 InfoTypeAndValue ::= SEQUENCE { 1704 infoType OBJECT IDENTIFIER, 1705 infoValue ANY DEFINED BY infoType OPTIONAL 1706 } 1707 -- Example InfoTypeAndValue contents include, but are not limited to: 1708 -- { CAProtEncCert = { xx }, Certificate } 1709 -- { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 1710 -- { EncKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 1711 -- { PreferredSymmAlg = { xx }, AlgorithmIdentifier } 1712 -- { CAKeyUpdateInfo = { xx }, CAKeyUpdAnnContent } 1713 -- { CurrentCRL = { xx }, CertificateList } 1714 -- This construct may also be used to define new PKIX Certificate 1715 -- Management Protocol request and response messages for future needs 1716 -- or for specific environments. 1718 GenReqContent ::= SET OF InfoTypeAndValue 1719 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically 1720 -- be omitted for some of the examples given above. The CA is free 1721 -- to ignore any contained OBJ. IDs that it does not recognize. 1722 -- The empty set indicates that the CA may send any/all information 1723 -- that it wishes. 1725 3.3.19 PKI General Response content 1727 GenRepContent ::= SET OF InfoTypeAndValue 1728 -- The end entity is free to ignore any contained OBJ. IDs that it 1729 -- does not recognize. 1731 3.3.20 Error Message content 1733 ErrorMsgContent ::= SEQUENCE { 1734 pKIStatusInfo PKIStatusInfo, 1735 errorCode INTEGER OPTIONAL, 1736 -- implementation-specific error codes 1737 errorDetails PKIFreeText OPTIONAL 1738 -- implementation-specific error details 1739 } 1741 4. Mandatory PKI Management functions 1743 The PKI management functions outlined in section 1 above are described 1744 in this section. 1746 This section deals with functions that are "mandatory" in the sense 1747 that all end entity and CA/RA implementations must be able to provide 1748 the functionality described (perhaps via one of the transport mechanisms 1749 defined in Section 5). This part is effectively the profile of the PKI 1750 management functionality that must be supported. 1752 Note that not all PKI management functions result in the creation of a 1753 PKI message. 1755 4.1 Root CA initialization 1757 [See Section 1.2.2 for this document's definition of "root CA".] 1759 A newly created root CA must produce a "self-certificate" which is a 1760 Certificate structure with the profile defined for the "newWithNew" 1761 certificate issued following a root CA key update. 1763 In order to make the CA�s self certificate useful to end entities that 1764 do not acquire this information via "out-of-band" means, the CA must 1765 also produce a fingerprint for its public key. End entities that 1766 acquire this value securely via some "out-of-band" means can then verify 1767 the CA�s self-certificate and hence the other attributes contained 1768 therein. 1770 The data structure used to carry the fingerprint is the OOBCertHash. 1772 4.2 Root CA key update 1774 CA keys (as all other keys) have a finite lifetime and will have to be 1775 updated on a periodic basis. The certificates NewWithNew, NewWithOld, 1776 and OldWithNew (see Section 2.4.1) are issued by the CA to aid existing 1777 end entities who hold the current self-signed CA certificate 1778 (OldWithOld) to transition securely to the new self-signed CA 1779 certificate (NewWithNew), and to aid new end entities who will hold 1780 NewWithNew to acquire OldWithOld securely for verification of existing 1781 data. 1783 4.3 Subordinate CA initialization 1785 [See Section 1.2.2 for this document's definition of "subordinate CA".] 1787 From the perspective of PKI management protocols the initialization of a 1788 subordinate CA is the same as the initialization of an end entity. The 1789 only difference is that the subordinate CA must also produce an initial 1790 revocation list. 1792 4.4 CRL production 1794 Before issuing any certificates a newly established CA (which issues 1795 CRLs) must produce "empty" versions of each CRL which is to be 1796 periodically produced. 1798 4.5 PKI information request 1800 When a PKI entity (CA, RA, or EE) wishes to acquire information about 1801 the current status of a CA it may send that CA a request for such 1802 information. 1804 The CA must respond to the request by providing (at least) all of the 1805 information requested by the requester. If some of the information 1806 cannot be provided then an error must be conveyed to the requester. 1808 If PKIMessages are used to request and supply this PKI information, 1809 then the request must be the GenReq message, the response must be the 1810 GenRep message, and the error must be the Error message. These 1811 messages are protected using a MAC based on shared secret information 1812 (i.e., PasswordBasedMAC) or any other authenticated means (if the end 1813 entity has an existing certificate). 1815 4.6 Cross certification 1817 The requester CA is the CA that will become the subject of the cross- 1818 certificate; the responder CA will become the issuer of the cross- 1819 certificate. 1821 The requester CA must be "up and running" before initiating the cross- 1822 certification operation. 1824 4.6.1 One-way request-response scheme: 1826 The cross-certification scheme is essentially a one way operation; that 1827 is, when successful, this operation results in the creation of one new 1828 cross-certificate. If the requirement is that cross-certificates be 1829 created in "both directions" then each CA in turn must initiate a cross- 1830 certification operation (or use another scheme). 1832 This scheme is suitable where the two CAs in question can already verify 1833 each other�s signatures (they have some common points of trust) or where 1834 there is an out-of-band verification of the origin of the certification 1835 request. 1837 Detailed Description: 1839 Cross certification is initiated at one CA known as the responder. The 1840 CA administrator for the responder identifies the CA it wants to cross 1841 certify and the responder CA equipment generates an authorization code. 1842 The responder CA administrator passes this authorization code by out-of- 1843 band means to the requester CA administrator. The requester CA 1844 administrator enters the authorization code at the requester CA in order 1845 to initiate the on-line exchange. 1847 The authorization code is used for authentication and integrity 1848 purposes. This is done by generating a symmetric key based on the 1849 authorization code and using the symmetric key for generating Message 1850 Authentication Codes (MACs) on all messages exchanged. 1852 The requester CA initiates the exchange by generating a random number 1853 (requester random number). The requester CA then sends to the responder 1854 CA the message CrossCertReq. The fields in this message are protected 1855 from modification with a MAC based on the authorization code. 1857 Upon receipt of the CrossCertReq message, the responder CA checks the 1858 protocol version, saves the requester random number, generates its own 1859 random number (responder random number) and validates the MAC. It then 1860 generates (and archives, if desired) a new requester certificate that 1861 contains the requester CA public key and is signed with the responder 1862 CA signature private key. The responder CA responds with the message 1863 CrossCertRep. The fields in this message are protected from modification 1864 with a MAC based on the authorization code. 1866 Upon receipt of the CrossCertRep message, the requester CA checks that 1867 its own system time is close to the responder CA system time, checks the 1868 received random numbers and validates the MAC. The requester CA 1869 responds with the PKIConfirm message. The fields in this message are 1870 protected from modification with a MAC based on the authorization code. 1871 The requester CA writes the requester certificate to the Repository. 1873 Upon receipt of the PKIConfirm message, the responder CA checks the 1874 random numbers and validates the MAC. 1876 Notes: 1878 1.The CrossCertReq must contain a "complete" certification request, that 1879 is, all fields (including, e.g., a BasicConstraints extension) must be 1880 specified by the requester CA. 1881 2.The CrossCertRep message should contain the verification certificate 1882 of the responder CA - if present, the requester CA must then verify 1883 this certificate (for example, via the "out-of-band" mechanism). 1885 4.7 End entity initialization 1887 As with CAs, end entities must be initialized. Initialization of end 1888 entities requires at least two steps: 1890 - acquisition of PKI information 1891 - out-of-band verification of one root-CA public key 1893 (other possible steps include the retrieval of trust condition 1894 information and/or out-of-band verification of other CA public keys). 1896 4.7.1 Acquisition of PKI information 1898 The information required is: 1900 - the current root-CA public key 1901 - (if the certifying CA is not a root-CA) the certification path from 1902 the root CA to the certifying CA together with appropriate revocation 1903 lists 1904 - the algorithms and algorithm parameters which the certifying CA 1905 supports for each relevant usage 1907 Additional information could be required (e.g., supported extensions 1908 or CA policy information) in order to produce a certification request 1909 which will be successful. However, for simplicity we do not mandate that 1910 the end entity acquires this information via the PKI messages. The end 1911 result is simply that some certification requests may fail (e.g., if the 1912 end entity wants to generate its own encryption key but the CA doesn�t 1913 allow that). 1915 The required information may be acquired as described in Section 4.5. 1917 4.7.2 Out-of-Band Verification of Root-CA Key 1919 An end entity must securely possess the public key of its root CA. One 1920 method to achieve this is to provide the end entity with the CA�s self- 1921 certificate fingerprint via some secure "out-of-band" means. The end 1922 entity can then securely use the CA�s self-certificate. 1924 See Section 4.1 for further details. 1926 4.8 Certificate Request 1928 An initialized end entity may request a certificate at any time (as part 1929 of an update procedure, or for any other purpose). This request will be 1930 made using the CertReq message. If the end entity already possesses a 1931 signing key pair (with a corresponding verification certificate), then 1932 this CertReq message will typically be protected by the entity's 1933 digital signature. The CA returns the new certificate (if the request 1934 is successful) in a CertRep message. 1936 4.9 Key Update 1938 When a key pair is due to expire the relevant end entity may request 1939 a key update - that is, it may request that the CA issue a new 1940 certificate for a new key pair. The request is made using a KeyUpdReq 1941 message. If the end entity already possesses a signing key pair (with a 1942 corresponding verification certificate), then this KeyUpdReq message 1943 will typically be protected by the entity's digital signature. The CA 1944 returns the new certificate (if the request is successful) in a 1945 KeyUpdRep message, which is syntactically identical to a CertRep message. 1947 5. Transports 1949 The transport protocols specified below allow end entities, RAs and CAs 1950 to pass PKI messages between them. There is no requirement for specific 1951 security mechanisms to be applied at this level if the PKI messages are 1952 suitably protected (that is, if the optional PKIProtection parameter is 1953 used as specified for each message). 1955 5.1 File based protocol 1957 A file containing a PKI message must contain only the DER encoding of 1958 one PKI message, i.e., there must be no extraneous header or trailer 1959 information in the file. 1961 Such files can be used to transport PKI messages using, e.g., FTP. 1963 5.2 Socket based Management Protocol 1965 The following simple socket based protocol is to be used for transport 1966 of PKI messages. This protocol is suitable for cases where an end entity 1967 (or an RA) initiates a transaction and can poll to pick up the results. 1969 If a transaction is initiated by a PKI entity (RA or CA) then an end 1970 entity must either supply a listener process or be supplied with a 1971 polling reference (see below) in order to allow it to pick up the PKI 1972 message from the PKI management component. 1974 The protocol basically assumes a listener process on an RA or CA which 1975 can accept PKI messages on a well-defined port (port number 829). 1976 Typically an initiator binds to this port and submits the initial PKI 1977 message for a given transaction ID. The responder replies with a PKI 1978 message and/or with a reference number to be used later when polling for 1979 the actual PKI message response. 1981 If a number of PKI response messages are to be produced for a given 1982 request (say if some part of the request is handled more quickly than 1983 another) then a new polling reference is also returned. 1985 When the final PKI response message has been picked up by the initiator 1986 then no new polling reference is supplied. 1988 The initiator of a transaction sends a "socket PKI message" to the 1989 recipient. The recipient responds with a similar message. 1991 A "socket PKI message" consists of: 1993 length (32-bits), flag (8-bits), value (defined below) 1995 The length field contains the number of octets of the remainder of the 1996 message (i.e., number of octets of "value" plus one). 1998 Message name flag value 2000 msgReq �00�H DER-encoded PKI message 2001 -- PKI message from initiator 2002 pollRep �01�H polling reference (32 bits), 2003 time-to-check-back (32 bits) 2004 -- poll response where no PKI message response ready; use polling 2005 -- reference value (and estimated time value) for later polling 2006 pollReq �02�H polling reference (32 bits) 2007 -- request for a PKI message response to initial message 2008 negPollRep �03�H �00�H 2009 -- no further polling responses (i.e., transaction complete) 2010 partialMsgRep �04�H next polling reference (32 bits), 2011 time-to-check-back (32 bits), 2012 DER-encoded PKI message 2013 -- partial response to initial message plus new polling reference 2014 -- (and estimated time value) to use to get next part of response 2015 finalMsgRep �05�H DER-encoded PKI message 2016 -- final (and possibly sole) response to initial message 2017 errorMsgRep �06�H human readable error message 2018 -- produced when an error is detected (e.g., a polling reference is 2019 -- received which doesn�t exist or is finished with) 2021 Where a PKIConfirm message is to be transported (always from the 2022 initiator to the responder) then a msgReq message is sent and a 2023 negPollRep is returned. 2025 The sequence of messages which can occur is then: 2027 a) end entity sends msgReq and receives one of pollRep, negPollRep, 2028 partialMsgRep or finalMsgRep in response. 2029 b) end entity sends pollReq message and receives one of negPollRep, 2030 partialMsgRep, finalMsgRep or ErrorMsgRep in response. 2032 The "time-to-check-back" parameter is a 32-bit integer, defined to be 2033 the number of seconds which have elapsed since midnight, January 1, 2034 1970, coordinated universal time. It provides an estimate of the time 2035 that the end entity should send its next pollReq. 2037 5.3 Management Protocol via E-mail 2039 This subsection specifies a means for conveying ASN.1-encoded messages 2040 for the protocol exchanges described in Section 4 via Internet mail. 2042 A simple MIME object is specified as follows. 2044 Content-Type: application/x-pkixcmp 2045 Content-Transfer-Encoding: base64 2047 <> 2049 This MIME object can be sent and received using common MIME processing 2050 engines and provides a simple Internet mail transport for PKIX-CMP 2051 messages. 2053 5.4 Management Protocol via HTTP 2055 This subsection specifies a means for conveying ASN.1-encoded messages 2056 for the protocol exchanges described in Section 4 via the HyperText 2057 Transfer Protocol. 2059 A simple MIME object is specified as follows. 2061 Content-Type: application/x-pkixcmp 2063 <> 2065 This MIME object can be sent and received using common HTTP processing 2066 engines over WWW links and provides a simple browser-server transport 2067 for PKIX-CMP messages. 2069 SECURITY CONSIDERATIONS 2071 This entire memo is about security mechanisms. 2073 One cryptographic consideration is worth explicitly spelling out. In 2074 the protocols specified above, when an end entity is required to 2075 prove possession of a decryption key, it is effectively challenged 2076 to decrypt something (its own certificate). This scheme (and many 2077 others!) could be vulnerable to an attack if the possessor of the 2078 decryption key in question could be fooled into decrypting an 2079 arbitrary challenge and returning the cleartext to an attacker. 2080 Although in this specification a number of other failures in 2081 security are required in order for this attack to succeed, it is 2082 conceivable that some future services (e.g., notary, trusted time) 2083 could potentially be vulnerable to such attacks. For this reason we 2084 re-iterate the general rule that implementations should be very 2085 careful about decrypting arbitrary "ciphertext" and revealing 2086 recovered "plaintext" since such a practice can lead to serious 2087 security vulnerabilities. 2089 References 2091 [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of 2092 Applied Cryptography", CRC Press, 1997. 2094 [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards 2095 (PKCS)", RSA Data Security Inc., Redwood City, California, 2096 November 1993 Release. 2098 [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards 2099 (PKCS)", RSA Data Security Inc., Redwood City, California, 2100 November 1993 Release. 2102 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 2103 PKCS #11: Cryptographic token interface standard", RSA 2104 Data Security Inc., Redwood City, California, April 28, 2105 1995. 2107 [PKIX-OP] S. Boeyen, R. Housley, T. Howes, M. Myers, P. Richard, 2108 "Internet Public Key Infrastructure: Operational 2109 Protocols", Internet Draft draft-ietf-pkix-ipki2opp-0x.txt 2110 (work in progress). 2112 [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 2113 Multiparts for MIME: Multipart/Signed and Multipart/ 2114 Encrypted", Internet Request for Comments 1847, October 2115 1995. 2117 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing 2118 for Message Authentication", Internet Request for Comments 2119 2104, February, 1997. 2121 Acknowledgements 2123 The authors gratefully acknowledge the contributions of various members 2124 of the PKIX Working Group. Many of these contributions significantly 2125 clarified and improved the utility of this specification. 2127 Authors' Addresses 2129 Carlisle Adams 2130 Entrust Technologies 2131 750 Heron Road, Suite E08, 2132 Ottawa, Ontario 2133 Canada K1V 1A7 2134 cadams@entrust.com 2136 Stephen Farrell 2137 Software and Systems Engineering Ltd. 2138 Fitzwilliam Court 2139 Leeson Close 2140 Dublin 2 2141 IRELAND 2142 stephen.farrell@sse.ie 2144 APPENDIX A: Reasons for the presence of RAs 2146 The reasons which justify the presence of an RA can be split into those 2147 which are due to technical factors and those which are organizational in 2148 nature. Technical reasons include the following. 2150 -If hardware tokens are in use, then not all end entities will have 2151 the equipment needed to initialize these; the RA equipment can include 2152 the necessary functionality (this may also be a matter of policy). 2154 -Some end entities may not have the capability to publish 2155 certificates; again, the RA may be suitably placed for this. 2157 -The RA will be able to issue signed revocation requests on behalf of 2158 end entities associated with it, whereas the end entity may not be able 2159 to do this (if the key pair is completely lost). 2161 Some of the organizational reasons which argue for the presence of an 2162 RA are the following. 2164 -It may be more cost effective to concentrate functionality in the RA 2165 equipment than to supply functionality to all end entities (especially 2166 if special token initialization equipment is to be used). 2168 -Establishing RAs within an organization can reduce the number of CAs 2169 required, which is sometimes desirable. 2171 -RAs may be better placed to identify people with their "electronic" 2172 names, especially if the CA is physically remote from the end entity. 2174 -For many applications there will already be in place some 2175 administrative structure so that candidates for the role of RA are easy 2176 to find (which may not be true of the CA). 2178 Appendix B. PKI Management Message Profiles. 2180 This appendix contains detailed profiles for those PKIMessages which 2181 must be supported by conforming implementations (see Section 4). 2183 Profiles for the PKIMessages used in the following PKI management 2184 operations are provided: 2186 - root CA key update 2187 - information request/response 2188 - cross-certification (1-way) 2189 - initial registration/certification 2190 - basic authenticated scheme 2191 - certificate request 2192 - key update 2194 <> 2198 - revocation request 2199 - certificate publication 2200 - CRL publication 2201 B1. General Rules for interpretation of these profiles. 2203 1.Where OPTIONAL or DEFAULT fields are not mentioned in individual 2204 profiles, they should be absent from the relevant message. 2205 Mandatory fields are not mentioned if they have an obvious value 2206 (e.g., pvno). 2207 2.Where structures occur in more than one message, they are 2208 separately profiled as appropriate. 2209 3.The algorithmIdentifiers from PKIMessage structures are profiled 2210 separately. 2211 4.A "special" X.500 DN is called the "NULL-DN"; this means a DN 2212 containing a zero-length SEQUENCE OF RDNs (its DER encoding is 2213 then �3000�H). 2214 5.Where a GeneralName is required for a field but no suitable 2215 value is available (e.g., an end entity produces a request before 2216 knowing its name) then the GeneralName is to be an X.500 NULL-DN 2217 (i.e., the Name field of the CHOICE is to contain a NULL-DN). 2218 This special value can be called a "NULL-GeneralName". 2219 6.Where a profile omits to specify the value for a GeneralName 2220 then the NULL-GeneralName value is to be present in the relevant 2221 PKIMessage field. This occurs with the sender field of the 2222 PKIHeader for some messages. 2223 7.Where any ambiguity arises due to naming of fields, the profile 2224 names these using a "dot" notation (e.g., "certTemplate.subject" 2225 means the subject field within a field called certTemplate). 2226 8.Where a "SEQUENCE OF types" is part of a message, a zero-based 2227 array notation is used to describe fields within the SEQUENCE OF 2228 (e.g., FullCertTemplates[0].certTemplate.subject refers to a 2229 subfield of the first FullCertTemplate contained in a request 2230 message). 2231 9.All PKI message exchanges in this profile require a PKIConfirm 2232 message to be sent by the initiating entity. This message is not 2233 included in many of the profiles given below since its body is 2234 NULL and its header contents are clear from the context. Any 2235 authenticated means can be used for the protectionAlg (e.g., 2236 password-based MAC, if shared secret information is known, or 2237 signature). 2239 B2. Algorithm Use Profile 2241 The following table contains definitions of algorithm uses within PKI 2242 management protocols. 2244 The columns in the table are: 2246 Name: an identifier used for message profiles 2247 Use: description of where and for what the algorithm is used 2248 Mandatory: an AlgorithmIdentifier which must be supported by 2249 conforming implementations 2250 Others: alternatives to the mandatory AlgorithmIdentifier 2251 Name Use Mandatory Others 2253 MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5... 2254 messages using signature 2255 MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC, 2256 messages using MACing X9.9... 2257 SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5, 2258 an end entity�s private EDE, CBC mode) CAST-128... 2259 key where symmetric 2260 key is distributed 2261 out-of-band 2262 PROT_ENC_ALG asymmetric algorithm D-H RSA 2263 used for encryption of 2264 (symmetric keys for 2265 encryption of) private 2266 keys transported in 2267 PKIMessages 2268 PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5, 2269 algorithm used for EDE, CBC mode) CAST-128... 2270 encryption of private 2271 key bits (a key of this 2272 type is encrypted using 2273 PROT_ENC_ALG) 2275 Mandatory AlgorithmIdentifiers and Specifications: 2277 DSA/SHA-1: 2278 AlgId: {1 3 14 3 2 27} 2279 X9.30-3, ANSI, "Public Key Cryptography Using Irreversible Algorithms 2280 for the Financial Services Industry: Part 3: Certificate Management 2281 for DSA" 2282 Public Modulus size: 1024 bits 2284 PasswordBasedMac: 2285 {1 2 840 113533 7 66 13} 2286 (this specification) 2288 3-DES: 2289 {1 2 840 113549 3 7} 2290 (used in RSA's BSAFE and in S/MIME) 2292 D-H: 2293 AlgId: {1 2 840 113549 1 3 1} 2294 "PKCS #3: Diffie-Hellman Key-Agreement Standard", in RSA Laboratories, 2295 "The Public-Key Cryptography Standards (PKCS)", RSA Data Security 2296 Inc., Redwood City, California, November 1993 Release. 2297 Public Modulus Size: 1024 bits 2299 B3. "Self-signed" certificates 2301 Profile of how a Certificate structure may be "self-signed". These 2302 structures are used for distribution of "root" CA public keys. This can 2303 occur in one of three ways (see section 2.4 above for a description of 2304 the use of these structures): 2306 Type Function 2308 newWithNew a true "self-signed" certificate; the contained public 2309 key must be usable to verify the signature (though this 2310 provides only integrity and no authentication whatsoever) 2311 oldWithNew previous root CA public key signed with new private key 2312 newWithOld new root CA public key signed with previous private key 2314 <> 2318 B4. Proof of Possession Profile 2320 "POPO" fields for use when proving possession of a private signing key 2321 which corresponds to a public verification key for which a certificate 2322 has been requested. 2324 Field Value Comment 2326 alg MSG_SIG_ALG only signature protection is 2327 allowed for this proof 2328 signature present bits calculated using MSG_SIG_ALG 2330 <> 2335 Not every CA/RA will require Proof-of-Possession (of signing key or of 2336 decryption key) in the certification request protocol. Although this 2337 specification STRONGLY RECOMMENDS that POP be verified by the CA/RA 2338 (because created certificates become less meaningful in the PKI 2339 otherwise; see Section 2.3), this may ultimately be a policy issue which 2340 is made explicit for any given CA in its publicized Policy OID and 2341 Certification Practice Statement. All end entities must be prepared to 2342 provide POP (i.e., these components of the PKIX-CMP protocol must be 2343 supported). 2345 CAs/RAs may therefore conceptually be divided into two classes (those 2346 which require POP as a condition of certificate creation and those which 2347 do not). End entities may choose to make verification decisions (as one 2348 step in certificate chain processing) at least partly by considering 2349 which classes of CAs (as indicated, for example, by their policy OIDs or 2350 Certification Practice Statements) have created the certificates 2351 included in the chain. 2353 B5. Root CA Key Update 2355 A root CA updates its key pair. It then produces a CA key update 2356 announcement message which can be made available (via one of the 2357 transport mechanisms) to the relevant end entities. 2359 ckuann message: 2361 Field Value Comment 2363 sender CA name responding CA name 2364 body ckuann(CAKeyUpdAnnContent) 2365 oldWithNew present see section B.3 above 2366 newWithOld present see section B.3 above 2367 newWithNew present see section B.3 above 2368 extraCerts optionally present can be used to "publish" 2369 certificates (e.g., 2370 certificates signed using 2371 the new private key) 2373 B6. PKI Information request/response 2375 End entity sends general request to the PKI requesting details which 2376 will be required for later PKI management operations. RA/CA responds 2377 with general response. If an RA generates the response then it will 2378 simply forward the equivalent message which it previously received from 2379 the CA, with the possible addition of the certificates to the extraCerts 2380 fields of the PKIMessage. 2382 Message Flows: 2384 Step# End entity PKI 2386 1 format genr 2387 2 -> genr -> 2388 3 handle genr 2389 4 produce genp 2390 5 <- genp <- 2391 6 handle genp 2393 genr: 2395 Field Value 2397 recipient CA name 2398 -- the name of the CA as contained in issuerAltName extensions or 2399 -- issuer fields within certificates 2400 protectionAlg MSG_MAC_ALG or MSG_SIG_ALG 2401 -- any authenticated protection alg. 2402 SenderKID present if required 2403 -- must be present if required for verification of message protection 2404 freeText any valid value 2405 body genr (GenReqContent) 2406 GenReqContent empty SET 2407 -- all relevant information requested 2408 protection present 2409 -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG 2411 genp: 2413 Field Value 2415 sender CA name 2416 -- name of the CA which produced the message 2417 protectionAlg MSG_MAC_ALG or MSG_SIG_ALG 2418 -- any authenticated protection alg. 2419 senderKID present if required 2420 -- must be present if required for verification of message protection 2421 body genp (GenRepContent) 2422 CAProtEncCert present (object identifier one 2423 of PROT_ENC_ALG), with relevant 2424 value 2425 -- to be used if end entity needs to encrypt information for the CA 2426 -- (e.g., private key for recovery purposes) 2427 SignKeyPairTypes present, with relevant value 2428 -- the set of signature algorithm identifiers which this CA will 2429 -- certify for subject public keys 2430 EncKeyPairTypes present, with relevant value 2431 -- the set of encryption/key agreement algorithm identifiers which 2432 -- this CA will certify for subject public keys 2433 PreferredSymmAlg present (object identifier one 2434 of PROT_SYM_ALG) , with relevant 2435 value 2436 -- the symmetric algorithm which this CA expects to be used in later 2437 -- PKI messages (for encryption) 2438 CAKeyUpdateInfo optionally present, with 2439 relevant value 2440 -- the CA may provide information about a relevant root CA key pair 2441 -- using this field (note that this does not imply that the responding 2442 -- CA is the root CA in question) 2444 CurrentCRL present, with relevant value 2445 -- the CA may provide a copy of a complete CRL (i.e., fullest possible 2446 -- one) 2447 protection present 2448 -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG 2449 extraCerts optionally present 2450 -- can be used to send some certificates to the end entity. An RA may 2451 -- add its certificate here. 2453 B7. Cross certification (1-way) 2455 Creation of a single cross-certificate (i.e., not two at once). The 2456 requesting CA is responsible for publication of the cross-certificate 2457 created by the responding CA. 2459 Preconditions: 2461 1. Responding CA can verify the origin of the request (possibly 2462 requiring out-of-band means) before processing the request. 2463 2. Requesting CA can authenticate the authenticity of the origin of the 2464 response (possibly requiring out-of-band means) before processing the 2465 response 2467 Message Flows: 2469 Step# Requesting CA Responding CA 2470 1 format ccr 2471 2 -> ccr -> 2472 3 handle ccr 2473 4 produce ccp 2474 5 <- ccp <- 2475 6 handle ccp 2477 ccr: 2478 Field Value 2480 sender Requesting CA name 2481 -- the name of the CA who produced the message 2482 recipient Responding CA name 2483 -- the name of the CA who is being asked to produce a certificate 2484 messageTime time of production of message 2485 -- current time at requesting CA 2486 protectionAlg MSG_SIG_ALG 2487 -- only signature protection is allowed for this request 2488 senderKID present if required 2489 -- must be present if required for verification of message protection 2490 transactionID present 2491 -- implementation-specific value, meaningful to requesting CA. 2492 -- [If already in use at responding CA then a rejection message 2493 -- to be produced by responding CA] 2495 senderNonce present 2496 -- 128 (pseudo-)random bits 2497 freeText any valid value 2498 body ccr (CrossCertReqContent) 2499 only one FullCertTemplate 2500 allowed 2501 -- if multiple cross certificates are required they must be packaged 2502 -- in separate PKIMessages 2503 certTemplate present 2504 -- details below 2505 version v1 or v3 2506 -- <> 2507 signingAlg present 2508 -- the requesting CA must know in advance with which algorithm it 2509 -- wishes the certificate to be signed 2511 subject present 2512 -- may be NULL-DN only if subjectAltNames extension value proposed 2513 validity present 2514 -- must be completely specified (i.e., both fields present) 2515 issuer present 2516 -- may be NULL-DN only if issuerAltNames extension value proposed 2517 publicKey present 2518 -- the key to be certified which must be for a signing algorithm 2519 extensions optionally present 2520 -- a requesting CA must propose values for all extensions which it 2521 -- requires to be in the cross-certificate 2522 popoSigningKey present 2523 -- see "Proof of possession profile" (section B.4) 2524 protection present 2525 -- bits calculated using MSG_SIG_ALG 2526 extraCerts optionally present 2527 -- can contain certificates usable to verify the protection on 2528 -- this message 2530 ccp: 2531 Field Value 2533 sender Responding CA name 2534 -- the name of the CA who produced the message 2535 recipient Requesting CA name 2536 -- the name of the CA who asked for production of a certificate 2537 messageTime time of production of message 2538 -- current time at responding CA 2539 protectionAlg MSG_SIG_ALG 2540 -- only signature protection is allowed for this message 2541 senderKID present if required 2542 -- must be present if required for verification of message 2543 -- protection 2544 recipKID present if required 2545 transactionID present 2546 -- value from corresponding ccr message 2547 senderNonce present 2548 -- 128 (pseudo-)random bits 2549 recipNonce present 2550 -- senderNonce from corresponding ccr message 2551 freeText any valid value 2552 body ccp (CrossCertRepContent) 2553 only one CertResponse allowed 2554 -- if multiple cross certificates are required they must be packaged 2555 -- in separate PKIMessages 2556 response present 2557 status present 2558 PKIStatusInfo.status present 2559 -- if PKIStatusInfo.status is one of: 2560 -- granted, or 2561 -- grantedWithMods, 2562 -- then certifiedKeyPair to be present and failInfo to be absent 2563 failInfo present depending on 2564 PKIStatusInfo.status 2565 -- if PKIStatusInfo.status is: 2566 -- rejection 2567 -- then certifiedKeyPair to be absent and failInfo to be present 2568 -- and contain appropriate bit settings 2570 certifiedKeyPair present depending on 2571 PKIStatusInfo.status 2572 certificate present depending on 2573 certifiedKeyPair 2574 -- content of actual certificate must be examined by requesting CA 2575 -- before publication 2576 protection present 2577 -- bits calculated using MSG_SIG_ALG 2578 extraCerts optionally present 2579 -- can contain certificates usable to verify the protection on 2580 -- this message 2582 B8. Initial Registration/Certification (Basic Authenticated Scheme) 2584 An (uninitialized) end entity requests a (first) certificate from a CA. 2585 When the CA responds with a message containing a certificate, the end 2586 entity replies with a confirmation. All messages are authenticated. 2588 This scheme allows the end entity to request certification of a locally- 2589 generated public key (typically a signature key). The end entity may 2590 also choose to request the centralized generation and certification of 2591 another key pair (typically an encryption key pair). 2593 Certification may only be requested for one locally generated public key 2594 (for more, use separate PKIMessages). 2596 The end entity must support proof-of-possession of the private key 2597 associated with the locally-generated public key. 2599 Preconditions: 2601 1.The end entity can authenticate the CA�s signature based on out-of- 2602 band means 2603 2.The end entity and the CA share a symmetric MACing key 2605 Message flow: 2607 Step# End entity PKI 2608 1 format ir 2609 2 -> ir -> 2610 3 handle ir 2611 4 produce ip 2612 5 <- ip <- 2613 6 handle ip 2614 7 format confirm 2615 8 -> conf -> 2616 9 handle conf 2618 For this profile, we mandate that the end entity must include all 2619 (i.e., one or two) fullCertTemplates in a single PKIMessage and that 2620 the PKI (CA) must produce a single response PKIMessage which contains 2621 the complete response (i.e., including the optional second key pair, 2622 if it was requested and if centralized key generation is supported). 2623 For simplicity, we also mandate that this message be the final one 2624 (i.e., no use of "waiting" status value). 2626 ir: 2627 Field Value 2629 recipient CA name 2630 -- the name of the CA who is being asked to produce a certificate 2631 protectionAlg MSG_MAC_ALG 2632 -- only MAC protection is allowed for this request, based on 2633 -- initial authentication key 2635 senderKID referenceNum 2636 -- the reference number which the CA has previously issued to 2637 -- the end entity (together with the MACing key) 2638 transactionID present 2639 -- implementation-specific value, meaningful to end entity. 2640 -- [If already in use at the CA then a rejection message to be 2641 -- produced by the CA] 2642 senderNonce present 2643 -- 128 (pseudo-)random bits 2644 freeText any valid value 2645 body ir (InitReqContent) 2646 only one or two FullCertTemplates 2647 are allowed 2648 -- if more certificates are required requests must be packaged in 2649 -- separate PKIMessages 2650 protocolEncKey optionally present. 2651 [If present, object identifier 2652 must be PROT_ENC_ALG] 2653 -- if supplied (and if centralized key generation is supported by 2654 -- this CA), this short-term asymmetric encryption key (generated 2655 -- by the end entity) will be used by the CA to encrypt (a symmetric 2656 -- key used to encrypt) a private key generated by the CA on behalf 2657 -- of the end entity 2658 fullCertTemplates one or two present 2659 -- see below for details, note: fct[0] means the first (which must 2660 -- be present), fct[1] means the second (which is optional, and used 2661 -- to ask for a centrally-generated key) 2662 fct[0]. fixed value of zero 2663 certReqId 2664 -- this is the index of the template within the message 2665 fct[0]. present 2666 certTemplate 2667 -- must include subject public key value, otherwise unconstrained 2668 fct[0]. optionally present if public key 2669 popoSigningKey from fct[0].certTemplate is a 2670 signing key 2671 -- proof of possession may be required in this exchange (see section 2672 -- B.4 for details) 2673 fct[0]. optionally present 2674 archiveOptions 2675 -- the end entity may request that the locally-generated private key 2676 -- be archived 2677 fct[0]. optionally present 2678 publicationInfo 2679 -- the end entity may ask for publication of resulting cert. 2680 fct[1]. fixed value of one 2681 certReqId 2682 -- the index of the template within the message 2683 fct[1]. present if protocolEncKey is 2684 certTemplate present 2685 -- must not include actual public key bits, otherwise unconstrained 2686 -- (e.g., the names need not be the same as in fct[0]) 2688 fct[1]. optionally present 2689 archiveOptions 2690 fct[1]. 2691 publicationInfo optionally present 2692 protection present 2693 -- bits calculated using MSG_MAC_ALG 2695 ip: 2696 Field Value 2698 sender CA name 2699 -- the name of the CA who produced the message 2700 messageTime present 2701 -- time at which CA produced message 2702 protectionAlg MSG_MAC_ALG 2703 -- only MAC protection is allowed for this response 2704 recipKID referenceNum 2705 -- the reference number which the CA has previously issued to the 2706 -- end entity (together with the MACing key) 2707 transactionID present 2708 -- value from corresponding ir message 2709 senderNonce present 2710 -- 128 (pseudo-)random bits 2711 recipNonce present 2712 -- value from senderNonce in corresponding ir message 2713 freeText any valid value 2714 body ir (CertRepContent) 2715 contains exactly one response 2716 for each request 2717 -- The PKI (CA) responds to either one or two requests as appropriate. 2718 -- crc[0] denotes the first (always present); crc[1] denotes the 2719 -- second (only present if the ir message contained two requests and 2720 -- if the CA supports centralized key generation). 2721 crc[0]. fixed value of zero 2722 certReqId 2723 -- must contain the response to the first request in the corresponding 2724 -- ir message 2725 crc[0].status. present, positive values allowed: 2726 status "granted", "grantedWithMods" 2727 negative values allowed: 2728 "rejection" 2729 crc[0].status. present if and only if 2730 failInfo crc[0].status.status is "rejection" 2731 crc[0]. present if and only if 2732 certifiedKeyPair crc[0].status.status is 2733 "granted" or "grantedWithMods" 2734 certificate present unless end entity�s public 2735 key is an encryption key and POP 2736 is required by CA/RA 2737 encryptedCert present if and only if end entity�s 2738 public key is an encryption key 2739 and POP is required by CA/RA 2741 publicationInfo optionally present 2742 -- indicates where certificate has been published (present at 2743 -- discretion of CA) 2744 crc[1]. fixed value of one 2745 certReqId 2746 -- must contain the response to the second request in the 2747 -- corresponding ir message 2749 crc[1].status. present, positive values allowed: 2750 status "granted", "grantedWithMods" 2751 negative values allowed: 2752 "rejection" 2753 crc[1].status. present if and only if 2754 failInfo crc[0].status.status is "rejection" 2755 crc[1]. present if and only if 2756 certifiedKeyPair crc[0].status.status is "granted" 2757 or "grantedWithMods" 2758 certificate present 2759 privateKey present 2760 publicationInfo optionally present 2761 -- indicates where certificate has been published (present at 2762 -- discretion of CA) 2763 protection present 2764 -- bits calculated using MSG_MAC_ALG 2765 extraCerts optionally present 2766 -- the CA may provide additional certificates to the end entity 2768 conf: 2769 Field Value 2771 recipient CA name 2772 -- the name of the CA who was asked to produce a certificate 2773 transactionID present 2774 -- value from corresponding ir and ip messages 2775 senderNonce present 2776 -- value from recipNonce in corresponding ir message 2777 recipNonce present 2778 -- value from senderNonce in corresponding ip message 2779 protectionAlg MSG_MAC_ALG 2780 -- only MAC protection is allowed for this message. The MAC is 2781 -- based on the initial authentication key if only a signing key 2782 -- pair has been sent in ir for certification or if POP is not 2783 -- required by CA/RA. Otherwise, the MAC is based on a key derived 2784 -- from the symmetric key used to decrypt the returned encryptedCert. 2785 senderKID referenceNum 2786 -- the reference number which the CA has previously issued to the 2787 -- end entity (together with the MACing key) 2788 body conf (PKIConfirmContent) 2789 -- this is an ASN.1 NULL 2790 protection present 2791 -- bits calculated using MSG_MAC_ALG 2793 B9. Certificate Request 2795 An (initialized) end entity requests a certificate from a CA (for any 2796 reason). When the CA responds with a message containing a certificate, 2797 the end entity replies with a confirmation. All messages are 2798 authenticated. 2800 The profile for this exchange is identical to that given in Section B8 2801 with the following exceptions: 2803 - protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, response, 2804 and confirm messages (the determination in the confirm message being 2805 dependent upon POP considerations for encryption certificate 2806 requests); 2807 - senderKID and recipKID are only present if required for message 2808 verification; 2809 - body is cr or cp; 2810 - protocolEncKey is not present; 2811 - protection bits are calculated according to the protectionAlg field. 2813 B10. Key Update Request 2815 An (initialized) end entity requests a certificate from a CA (to update 2816 the key pair and corresponding certificate that it already possesses). 2817 When the CA responds with a message containing a certificate, the end 2818 entity replies with a confirmation. All messages are authenticated. 2820 The profile for this exchange is identical to that given in Section B8 2821 with the following exceptions: 2823 - protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, response, 2824 and confirm messages (the determination in the confirm message being 2825 dependent upon POP considerations for encryption certificate 2826 requests); 2827 - senderKID and recipKID are only present if required for message 2828 verification; 2829 - body is kur or kup; 2830 - protection bits are calculated according to the protectionAlg field. 2832 Appendix C: "Compilable" ASN.1 Module 2834 -- note that tagging is EXPLICIT in this module 2836 PKIMessage ::= SEQUENCE { 2837 header PKIHeader, 2838 body PKIBody, 2839 protection [0] PKIProtection OPTIONAL, 2840 extraCerts [1] SEQUENCE OF Certificate OPTIONAL 2841 } 2843 PKIHeader ::= SEQUENCE { 2844 pvno INTEGER { ietf-version1 (0) }, 2845 sender GeneralName, 2846 -- identifies the sender 2847 recipient GeneralName, 2848 -- identifies the intended recipient 2849 messageTime [0] GeneralizedTime OPTIONAL, 2850 -- time of production of this message (used when sender 2851 -- believes that the transport will be "suitable"; i.e., 2852 -- that the time will still be meaningful upon receipt) 2853 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 2854 -- algorithm used for calculation of protection bits 2855 senderKID [2] KeyIdentifier OPTIONAL, 2856 recipKID [3] KeyIdentifier OPTIONAL, 2857 -- to identify specific keys used for protection 2858 transactionID [4] OCTET STRING OPTIONAL, 2859 -- identifies the transaction; i.e., this will be the same in 2860 -- corresponding request, response and confirmation messages 2861 senderNonce [5] OCTET STRING OPTIONAL, 2862 recipNonce [6] OCTET STRING OPTIONAL, 2863 -- nonces used to provide replay protection, senderNonce 2864 -- is inserted by the creator of this message; recipNonce 2865 -- is a nonce previously inserted in a related message by 2866 -- the intended recipient of this message 2867 freeText [7] PKIFreeText OPTIONAL, 2868 -- this may be used to indicate context-specific 2869 -- instructions (this field is intended for human 2870 -- consumption) 2871 generalInfo [8] SET OF InfoTypeAndValue OPTIONAL 2872 -- this may be used to convey context-specific information 2873 -- (this field not primarily intended for human consumption) 2874 } 2876 PKIFreeText ::= CHOICE { 2877 iA5String [0] IA5String, 2878 bMPString [1] BMPString 2879 } -- note that the text included here would ideally be in the 2880 -- preferred language of the recipient 2882 PKIBody ::= CHOICE { -- message-specific body elements 2883 ir [0] InitReqContent, 2884 ip [1] InitRepContent, 2885 cr [2] CertReqContent, 2886 cp [3] CertRepContent, 2887 p10cr [4] CertificationRequest, -- imported from [PKCS10] 2888 popdecc [5] POPODecKeyChallContent, 2889 popdecr [6] POPODecKeyRespContent, 2890 kur [7] KeyUpdReqContent, 2891 kup [8] KeyUpdRepContent, 2892 krr [9] KeyRecReqContent, 2893 krp [10] KeyRecRepContent, 2894 rr [11] RevReqContent, 2895 rp [12] RevRepContent, 2896 ccr [13] CrossCertReqContent, 2897 ccp [14] CrossCertRepContent, 2898 ckuann [15] CAKeyUpdAnnContent, 2899 cann [16] CertAnnContent, 2900 rann [17] RevAnnContent, 2901 crlann [18] CRLAnnContent, 2902 conf [19] PKIConfirmContent, 2903 nested [20] NestedMessageContent, 2904 genr [21] GenReqContent, 2905 genp [22] GenRepContent, 2906 error [23] ErrorMsgContent 2907 } 2909 PKIProtection ::= BIT STRING 2911 ProtectedPart ::= SEQUENCE { 2912 header PKIHeader, 2913 body PKIBody 2914 } 2916 PasswordBasedMac ::= OBJECT IDENTIFIER 2918 PBMParameter ::= SEQUENCE { 2919 salt OCTET STRING, 2920 owf AlgorithmIdentifier, 2921 -- AlgId for a One-Way Function (SHA-1 recommended) 2922 iterationCount INTEGER, 2923 -- number of times the OWF is applied 2924 mac AlgorithmIdentifier 2925 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2926 } -- or HMAC [RFC2104]) 2928 DHBasedMac ::= OBJECT IDENTIFIER 2930 DHBMParameter ::= SEQUENCE { 2931 owf AlgorithmIdentifier, 2932 -- AlgId for a One-Way Function (SHA-1 recommended) 2933 mac AlgorithmIdentifier 2934 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2935 } -- or HMAC [RFC2104]) 2936 NestedMessageContent ::= PKIMessage 2938 CertTemplate ::= SEQUENCE { 2939 version [0] Version OPTIONAL, 2940 -- used to ask for a particular syntax version 2941 serialNumber [1] INTEGER OPTIONAL, 2942 -- used to ask for a particular serial number 2943 signingAlg [2] AlgorithmIdentifier OPTIONAL, 2944 -- used to ask the CA to use this alg. for signing the cert 2945 issuer [3] Name OPTIONAL, 2946 validity [4] OptionalValidity OPTIONAL, 2947 subject [5] Name OPTIONAL, 2948 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 2949 issuerUID [7] UniqueIdentifier OPTIONAL, 2950 subjectUID [8] UniqueIdentifier OPTIONAL, 2951 extensions [9] Extensions OPTIONAL 2952 -- the extensions which the requester would like in the cert. 2953 } 2955 OptionalValidity ::= SEQUENCE { 2956 notBefore [0] CertificateValidityDate OPTIONAL, 2957 notAfter [1] CertificateValidityDate OPTIONAL 2958 } 2960 CertificateValidityDate ::= CHOICE { 2961 utcTime UTCTime, 2962 generalTime GeneralizedTime 2963 } 2965 EncryptedValue ::= SEQUENCE { 2966 encValue BIT STRING, 2967 -- the encrypted value itself 2968 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 2969 -- the intended algorithm for which the value will be used 2970 symmAlg [1] AlgorithmIdentifier OPTIONAL, 2971 -- the symmetric algorithm used to encrypt the value 2972 encSymmKey [2] BIT STRING OPTIONAL, 2973 -- the (encrypted) symmetric key used to encrypt the value 2974 keyAlg [3] AlgorithmIdentifier OPTIONAL 2975 -- algorithm used to encrypt the symmetric key 2976 } 2977 PKIStatus ::= INTEGER { 2978 granted (0), 2979 -- you got exactly what you asked for 2980 grantedWithMods (1), 2981 -- you got something like what you asked for; the 2982 -- requester is responsible for ascertaining the differences 2983 rejection (2), 2984 -- you don't get it, more information elsewhere in the message 2985 waiting (3), 2986 -- the request body part has not yet been processed, 2987 -- expect to hear more later 2988 revocationWarning (4), 2989 -- this message contains a warning that a revocation is 2990 -- imminent 2991 revocationNotification (5), 2992 -- notification that a revocation has occurred 2993 keyUpdateWarning (6) 2994 -- update already done for the oldCertId specified in 2995 -- FullCertTemplate 2996 } 2998 PKIFailureInfo ::= BIT STRING { 2999 -- since we can fail in more than one way! 3000 -- More codes may be added in the future if/when required. 3001 badAlg (0), 3002 -- unrecognized or unsupported Algorithm Identifier 3003 badMessageCheck (1), 3004 -- integrity check failed (e.g., signature did not verify) 3005 badRequest (2), 3006 -- transaction not permitted or supported 3007 badTime (3), 3008 -- messageTime was not sufficiently close to the system time, 3009 -- as defined by local policy 3010 badCertId (4), 3011 -- no certificate could be found matching the provided criteria 3012 badDataFormat (5), 3013 -- the data submitted has the wrong format 3014 wrongAuthority (6), 3015 -- the authority indicated in the request is different from the 3016 -- one creating the response token 3017 incorrectData (7), 3018 -- the requester's data is incorrect (for notary services) 3019 missingTimeStamp (8) 3020 -- when the timestamp is missing but should be there (by policy) 3021 } 3023 PKIStatusInfo ::= SEQUENCE { 3024 status PKIStatus, 3025 statusString PKIFreeText OPTIONAL, 3026 failInfo PKIFailureInfo OPTIONAL 3027 } 3028 CertId ::= SEQUENCE { 3029 issuer GeneralName, 3030 serialNumber INTEGER 3031 } 3033 OOBCert ::= Certificate 3035 OOBCertHash ::= SEQUENCE { 3036 hashAlg [0] AlgorithmIdentifier OPTIONAL, 3037 certId [1] CertId OPTIONAL, 3038 hashVal BIT STRING 3039 -- hashVal is calculated over DER encoding of the 3040 -- subjectPublicKey field of the corresponding cert. 3041 } 3043 PKIArchiveOptions ::= CHOICE { 3044 encryptedPrivKey [0] EncryptedValue, 3045 -- the actual value of the private key 3046 keyGenParameters [1] KeyGenParameters, 3047 -- parameters which allow the private key to be re-generated 3048 archiveRemGenPrivKey [2] BOOLEAN 3049 -- set to TRUE if sender wishes receiver to archive the private 3050 -- key of a key pair which the receiver generates in response to 3051 -- this request; set to FALSE if no archival is desired. 3052 } 3054 KeyGenParameters ::= OCTET STRING 3055 -- an alternative to sending the key is to send the information 3056 -- about how to re-generate the key (e.g., for many RSA 3057 -- implementations one could send the first random number tested 3058 -- for primality). 3059 -- The actual syntax for this parameter may be defined in a 3060 -- subsequent version of this document or in another standard. 3062 PKIPublicationInfo ::= SEQUENCE { 3063 action INTEGER { 3064 dontPublish (0), 3065 pleasePublish (1) 3066 }, 3067 pubInfos SEQUENCE OF SinglePubInfo OPTIONAL 3068 -- pubInfos must not be present if action is "dontPublish" 3069 -- (if action is "pleasePublish" and pubInfos is omitted, 3070 -- "dontCare" is assumed) 3071 } 3073 SinglePubInfo ::= SEQUENCE { 3074 pubMethod INTEGER { 3075 dontCare (0), 3076 x500 (1), 3077 web (2) 3078 }, 3079 pubLocation GeneralName OPTIONAL 3080 } 3081 FullCertTemplates ::= SEQUENCE OF FullCertTemplate 3083 FullCertTemplate ::= SEQUENCE { 3084 certReqId INTEGER, 3085 -- a non-negative value to match this request with corresponding 3086 -- response (note: must be unique over all FullCertReqs in this 3087 -- message) 3088 certTemplate CertTemplate, 3089 popoSigningKey [0] POPOSigningKey OPTIONAL, 3090 archiveOptions [1] PKIArchiveOptions OPTIONAL, 3091 publicationInfo [2] PKIPublicationInfo OPTIONAL, 3092 oldCertId [3] CertId OPTIONAL 3093 -- id. of cert. which is being updated by this one 3094 } 3096 POPOSigningKey ::= SEQUENCE { 3097 poposkInput POPOSKInput, 3098 alg AlgorithmIdentifier, 3099 signature BIT STRING 3100 -- the signature (using "alg") on the DER-encoded 3101 -- value of poposkInput 3102 } 3104 POPOSKInput ::= CHOICE { 3105 popoSigningKeyInput [0] POPOSigningKeyInput, 3106 certificationRequestInfo CertificationRequestInfo 3107 -- imported from [PKCS10] (note that if this choice is used, 3108 -- POPOSigningKey is simply a standard PKCS #10 request; this 3109 -- allows a bare PKCS #10 request to be augmented with other 3110 -- desired information in the FullCertTemplate before being 3111 -- sent to the CA/RA) 3112 } 3114 POPOSigningKeyInput ::= SEQUENCE { 3115 authInfo CHOICE { 3116 sender [0] GeneralName, 3117 -- from PKIHeader (used only if an authenticated identity 3118 -- has been established for the sender (e.g., a DN from a 3119 -- previously-issued and currently-valid certificate) 3120 publicKeyMAC [1] BIT STRING 3121 -- used if no authenticated GeneralName currently exists for 3122 -- the sender; publicKeyMAC contains a password-based MAC 3123 -- (using the protectionAlg AlgId from PKIHeader) on the 3124 -- DER-encoded value of publicKey 3125 }, 3126 publicKey SubjectPublicKeyInfo -- from CertTemplate 3127 } 3129 InitReqContent ::= SEQUENCE { 3130 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 3131 fullCertTemplates FullCertTemplates 3132 } 3134 InitRepContent ::= CertRepContent 3135 CertReqContent ::= FullCertTemplates 3137 POPODecKeyChallContent ::= SEQUENCE OF Challenge 3138 -- One Challenge per encryption key certification request (in the 3139 -- same order as these requests appear in FullCertTemplates). 3141 Challenge ::= SEQUENCE { 3142 owf AlgorithmIdentifier OPTIONAL, 3143 -- must be present in the first Challenge; may be omitted in any 3144 -- subsequent Challenge in POPODecKeyChallContent (if omitted, 3145 -- then the owf used in the immediately preceding Challenge is 3146 -- to be used). 3147 witness OCTET STRING, 3148 -- the result of applying the one-way function (owf) to a 3149 -- randomly-generated INTEGER, A. [Note that a different 3150 -- INTEGER must be used for each Challenge.] 3151 challenge OCTET STRING 3152 -- the encryption (under the public key for which the cert. 3153 -- request is being made) of Rand, where Rand is specified as 3154 -- Rand ::= SEQUENCE { 3155 -- int INTEGER, 3156 -- - the randomly-generated INTEGER A (above) 3157 -- sender GeneralName 3158 -- - the sender's name (as included in PKIHeader) 3159 -- } 3160 } 3162 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 3163 -- One INTEGER per encryption key certification request (in the 3164 -- same order as these requests appear in FullCertTemplates). The 3165 -- retrieved INTEGER A (above) is returned to the sender of the 3166 -- corresponding Challenge. 3168 CertRepContent ::= SEQUENCE { 3169 caPubs [1] SEQUENCE OF Certificate OPTIONAL, 3170 response SEQUENCE OF CertResponse 3171 } 3173 CertResponse ::= SEQUENCE { 3174 certReqId INTEGER, 3175 -- to match this response with corresponding request (a value 3176 -- of -1 is to be used if certReqId is not specified in the 3177 -- corresponding request) 3178 status PKIStatusInfo, 3179 certifiedKeyPair CertifiedKeyPair OPTIONAL 3180 } 3182 CertifiedKeyPair ::= SEQUENCE { 3183 certOrEncCert CertOrEncCert, 3184 privateKey [0] EncryptedValue OPTIONAL, 3185 publicationInfo [1] PKIPublicationInfo OPTIONAL 3186 } 3187 CertOrEncCert ::= CHOICE { 3188 certificate [0] Certificate, 3189 encryptedCert [1] EncryptedValue 3190 } 3192 KeyUpdReqContent ::= SEQUENCE { 3193 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 3194 fullCertTemplates [1] FullCertTemplates OPTIONAL 3195 } 3197 KeyUpdRepContent ::= InitRepContent 3199 KeyRecReqContent ::= InitReqContent 3201 KeyRecRepContent ::= SEQUENCE { 3202 status PKIStatusInfo, 3203 newSigCert [0] Certificate OPTIONAL, 3204 caCerts [1] SEQUENCE OF Certificate OPTIONAL, 3205 keyPairHist [2] SEQUENCE OF CertifiedKeyPair OPTIONAL 3206 } 3208 RevReqContent ::= SEQUENCE OF RevDetails 3210 RevDetails ::= SEQUENCE { 3211 certDetails CertTemplate, 3212 -- allows requester to specify as much as they can about 3213 -- the cert. for which revocation is requested 3214 -- (e.g., for cases in which serialNumber is not available) 3215 revocationReason ReasonFlags, 3216 -- from the DAM, so CA knows what to use in Dist. point 3217 badSinceDate GeneralizedTime OPTIONAL, 3218 -- indicates best knowledge of sender 3219 crlEntryDetails Extensions 3220 -- requested crlEntryExtensions 3221 } 3223 RevRepContent ::= SEQUENCE { 3224 status PKIStatusInfo, 3225 revCerts [0] SEQUENCE OF CertId OPTIONAL, 3226 -- identifies the certs for which revocation was requested 3227 crls [1] SEQUENCE OF CertificateList OPTIONAL 3228 -- the resulting CRLs (there may be more than one) 3229 } 3231 CrossCertReqContent ::= CertReqContent 3232 CrossCertRepContent ::= CertRepContent 3234 CAKeyUpdAnnContent ::= SEQUENCE { 3235 oldWithNew Certificate, -- old pub signed with new priv 3236 newWithOld Certificate, -- new pub signed with old priv 3237 newWithNew Certificate -- new pub signed with new priv 3238 } 3240 CertAnnContent ::= Certificate 3241 RevAnnContent ::= SEQUENCE { 3242 status PKIStatus, 3243 certId CertId, 3244 willBeRevokedAt GeneralizedTime, 3245 badSinceDate GeneralizedTime, 3246 crlDetails Extensions OPTIONAL 3247 -- extra CRL details(e.g., crl number, reason, location, etc.) 3248 } 3250 CRLAnnContent ::= SEQUENCE OF CertificateList 3252 PKIConfirmContent ::= NULL 3254 InfoTypeAndValue ::= SEQUENCE { 3255 infoType OBJECT IDENTIFIER, 3256 infoValue ANY DEFINED BY infoType OPTIONAL 3257 } 3258 -- Example InfoTypeAndValue contents include, but are not limited to: 3259 -- { CAProtEncCert = { xx }, Certificate } 3260 -- { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 3261 -- { EncKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 3262 -- { PreferredSymmAlg = { xx }, AlgorithmIdentifier } 3263 -- { CAKeyUpdateInfo = { xx }, CAKeyUpdAnnContent } 3264 -- { CurrentCRL = { xx }, CertificateList } 3265 -- This construct may also be used to define new PKIX Certificate 3266 -- Management Protocol request and response messages for future needs 3267 -- or for specific environments. 3269 GenReqContent ::= SET OF InfoTypeAndValue 3270 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically 3271 -- be omitted for some of the examples given above. The CA is free 3272 -- to ignore any contained OBJ. IDs that it does not recognize. 3273 -- The empty set indicates that the CA may send any/all information 3274 -- that it wishes. 3276 GenRepContent ::= SET OF InfoTypeAndValue 3277 -- The end entity is free to ignore any contained OBJ. IDs that it 3278 -- does not recognize. 3280 ErrorMsgContent ::= SEQUENCE { 3281 pKIStatusInfo PKIStatusInfo, 3282 errorCode INTEGER OPTIONAL, 3283 -- implementation-specific error codes 3284 errorDetails PKIFreeText OPTIONAL 3285 -- implementation-specific error details 3286 }