idnits 2.17.1 draft-ietf-pkix-ipki3cmp-02.txt: -(818): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1054): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1743): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1806): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1966): 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-19) 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 26 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 67 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 68 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 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 7 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 535: '..., it is STRONGLY RECOMMENDED that CAs/...' RFC 2119 keyword, line 804: '... protection [0] PKIProtection OPTIONAL,...' RFC 2119 keyword, line 805: '... extraCerts [1] SEQUENCE OF Certificate OPTIONAL...' RFC 2119 keyword, line 841: '... messageTime [0] GeneralizedTime OPTIONAL,...' RFC 2119 keyword, line 845: '... protectionAlg [1] AlgorithmIdentifier OPTIONAL,...' (112 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 262 has weird spacing: '...ntities a |...' == Line 317 has weird spacing: '...eeds to be is...' == Line 334 has weird spacing: '...update but in...' == Line 339 has weird spacing: '...oducing a cer...' == Line 693 has weird spacing: '...cate is the...' == (34 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1997) is 9805 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3229 -- Looks like a reference, but probably isn't: '1' on line 3231 -- Looks like a reference, but probably isn't: '2' on line 3209 -- Looks like a reference, but probably isn't: '3' on line 3194 -- Looks like a reference, but probably isn't: '4' on line 2959 -- Looks like a reference, but probably isn't: '5' on line 2960 -- Looks like a reference, but probably isn't: '6' on line 2961 -- Looks like a reference, but probably isn't: '7' on line 2962 -- Looks like a reference, but probably isn't: '8' on line 2963 -- Looks like a reference, but probably isn't: '9' on line 2964 -- Looks like a reference, but probably isn't: '10' on line 2905 -- Looks like a reference, but probably isn't: '11' on line 2906 -- Looks like a reference, but probably isn't: '12' on line 2907 -- Looks like a reference, but probably isn't: '13' on line 2908 -- Looks like a reference, but probably isn't: '14' on line 2909 -- Looks like a reference, but probably isn't: '15' on line 2910 -- Looks like a reference, but probably isn't: '16' on line 2911 -- Looks like a reference, but probably isn't: '17' on line 2912 -- Looks like a reference, but probably isn't: '18' on line 2913 -- Looks like a reference, but probably isn't: '19' on line 2914 -- Looks like a reference, but probably isn't: '20' on line 2915 -- Looks like a reference, but probably isn't: '21' on line 2916 -- Looks like a reference, but probably isn't: '22' on line 2917 -- Looks like a reference, but probably isn't: '23' on line 2918 == Unused Reference: 'MvOV97' is defined on line 2116, but no explicit reference was found in the text == Unused Reference: 'PKCS11' is defined on line 2127, 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-2' Summary: 12 errors (**), 0 flaws (~~), 12 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-02.txt 4 Expires in 6 months June 1997 6 Internet Public Key Infrastructure 7 Part III: 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 1. Introduction 35 The layout of this draft 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 including those that must be supported by conforming 42 implementations and those that are optional; 43 - Section 5 describes a simple protocol for transporting PKI messages; 44 - the Appendices specify profiles for conforming implementations and 45 provide an ASN.1 module containing the syntax for all defined 46 messages. 48 1.1 PKI Management Overview 50 The PKI must be structured to be consistent with the types of 51 individuals who must administer it. Providing such administrators with 52 unbounded choices not only complicates the software required but also 53 increases the chances that a subtle mistake by an administrator or 54 software developer will result in broader compromise. Similarly, 55 restricting administrators with cumbersome mechanisms will cause them 56 not to use the PKI. 58 Management protocols are required to support on-line interactions 59 between Public Key Infrastructure (PKI) components. For example, a 60 management protocol might be used between a CA and a client system with 61 which a key pair is associated, or between two CAs which cross-certify 62 each other. 64 2.1 PKI Management Model 66 Before specifying particular message formats and procedures we first 67 define the entities involved in PKI management and their interactions 68 (in terms of the PKI management functions required). We then group 69 these functions in order to accommodate different identifiable types of 70 end entities. 72 1.2 Definitions of PKI Entities 74 The entities involved in PKI management include the end entity (i.e. 75 the entity to be named in the subject field of a certificate) and the 76 certification authority (i.e. the entity named in the issuer field of a 77 certificate). A registration authority may also be involved in PKI 78 management. 80 1.2.1 Subjects and End Entities 82 The term "subject" is used here to refer to the entity named by the 83 subject field of a certificate; when we wish to distinguish the tools 84 and/or software used by the subject (e.g. a local certificate management 85 module) we will use the term "subject equipment". In general, we prefer 86 the term "end entity" rather than subject in order to avoid confusion 87 with the field name. 89 It is important to note that the end entities here will include not only 90 human users of applications, but also applications themselves (e.g. for 91 IP security). This factor influences the protocols which the PKI 92 management operations use; e.g., applications software is far more 93 likely to know exactly which certificate extensions are required than 94 are human users. PKI management entities are also end entities in the 95 sense that they are sometimes named in the subject field of a 96 certificate or cross-certificate. Where appropriate, the term "end- 97 entity" will be used to refer to end entities who are not PKI management 98 entities. 100 All end entities require secure local access to some information -- at a 101 minimum, their own name and private key, the name of a CA which is 102 directly trusted by this subject and that CA's public key (or a 103 fingerprint of the public key where a self-certified version is 104 available elsewhere). Implementations may use secure local storage for 105 more than this minimum (e.g. the end entity's own certificate or 106 application-specific information). The form of storage will also vary -- 107 from files to tamper resistant cryptographic tokens. Such local trusted 108 storage is referred to here as the end entity's Personal Security 109 Environment (PSE). 111 Though PSE formats are out of scope of this document (they are very 112 dependent on equipment, et cetera), a generic interchange format for 113 PSEs is defined here - a certification response message may be used. 115 1.2.2 Certification Authority 117 The certification authority (CA) may or may not actually be a real 118 "third party" from the end entity's point of view. Quite often, the CA 119 will actually belong to the same organisation as the end entities it 120 supports. 122 Again, we use the term CA to refer to the entity named in the issuer 123 field of a certificate; when it is necessary to distinguish the software 124 or hardware tools used by the CA we use the term "CA equipment". 126 The CA equipment will often include both an "off-line" component and an 127 "on-line" component, with the CA private key only available to the "off- 128 line" component. This is, however, a matter for implementers (though it 129 is also relevant as a policy issue). 131 We use the term "root CA" to indicate a CA which is directly trusted by 132 an end entity, that is, securely acquiring the value of a root CA public 133 key requires some out-of-band step(s). This term does not indicate that 134 a root CA is at the top of any hierarchy, simply that the CA in question 135 is trusted directly. 137 A subordinate CA is one which is not a root CA for the end entity in 138 question. Often, a subordinate CA will not be a root CA for any entity 139 but this is not mandatory. 141 1.2.3 Registration Authority 143 In addition to end entities and CAs, many environments call for the 144 existence of a registration authority (RA) separate from the 145 certification authority. The functions which the registration authority 146 may carry out will vary from case to case but may include personal 147 authentication, token distribution, revocation reporting, name 148 assignment, key generation, archival of key pairs, et cetera. 150 This document views the RA as an optional component - when it is not 151 present the CA is assumed to be able to carry out the RA's functions so 152 that the PKI management protocols are the same from the end entity's 153 point of view. 155 Again, we distinguish, where necessary, between the RA and the tools 156 used (the "RA equipment"). 158 Note that an RA is itself an end entity. We further assume that all RAs 159 are in fact certified end entities and that RA private keys are usable 160 for signing. How a particular CA equipment identifies some end entities 161 as RAs is an implementation issue (so there is no special RA 162 certification operation). We do not mandate that the RA is certified by 163 the CA with which it is interacting at the moment (so one RA may work 164 with more than one CA whilst only being certified once). 166 In some circumstances end entities will communicate directly with a CA 167 even where an RA is present. For example, for initial registration 168 and/or certification the subject may use its RA, but communicate 169 directly with the CA in order to refresh its certificate. 171 1.3 PKI Management Requirements 173 The protocols given here meet the following requirements on PKI 174 management. 176 1. PKI management must conform to ISO 9594-8 and the associated 177 amendments (certificate extensions) 179 2. PKI management must conform to the other parts of this series. 181 3. It must be possible to regularly update any key pair without 182 affecting any other key pair. 184 4. The use of confidentiality in PKI management protocols must be kept 185 to a minimum in order to ease regulatory problems. 187 5. PKI management protocols must allow the use of different industry- 188 standard cryptographic algorithms, (specifically including, RSA, DSA, 189 MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in 190 principal, use whichever algorithms suit it for its own key pair(s). 192 6. PKI management protocols must not preclude the generation of key 193 pairs by the end entity concerned, by an RA, or by a CA -- key 194 generation may also occur elsewhere, but for the purposes of PKI 195 management we can regard key generation as occurring wherever the key is 196 first present at an end entity, RA or CA. 198 7. PKI management protocols must support the publication of certificates 199 by the end entity concerned, by an RA or by a CA. Different 200 implementations and different environments may choose any of the above 201 approaches. 203 8. PKI management protocols must support the production of CRLs by 204 allowing certified end entities to make requests for the revocation of 205 certificates - this must be done in such a way that the denial-of- 206 service attacks which are possible are not made simpler. 208 9. PKI management protocols must be usable over a variety of "transport" 209 mechanisms, specifically including mail, http, TCP/IP and ftp. 211 10. Final authority for certification creation rests with the CA; no RA 212 or end entity equipment can assume that any certificate issued by a CA 213 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 may 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 must be supported (CA key update). An end entity whose 224 PSE contains the new CA public key (following a CA key update) must also 225 be able to verify certificates verifiable using the old public key. End 226 entities who directly trust the old CA key pair must also be able to 227 verify certificates signed using the new CA private key. (Required for 228 situations where the old CA public key is "hardwired" into the end 229 entity's cryptographic equipment). 231 12. The Functions of an RA may, in some implementations or 232 environments, be carried out by the CA itself. The protocols must be 233 designed so that end entities will use the same protocol (but, of 234 course, not the same key!) regardless of whether the communication is 235 with an RA or CA. 237 13. Where an end entity requests a certificate containing a given public 238 key value, the end entity must be ready to demonstrate possession of the 239 corresponding private key value (if this is required by the CA/RA with 240 whom the end entity is communicating). This may be accomplished in 241 various ways, depending on the type of certification request. See the 242 section "Proof of Possession of Private Key" for details 243 PKI Management Operations 245 The following diagram shows the relationship between the entities 246 defined above in terms of the PKI management operations. The letters in 247 the diagram indicate "protocols" in the sense that a defined set of PKI 248 management messages can be sent along each of the lettered lines. 250 cert. publish +------------+ 251 +---+ +------------ | End Entity | Operations 252 | C | | g +------------+ 253 | e | <--------+ | ^ initial 254 | r | a | | b registration/ 255 | t | PKI "users" | | certification 256 | | | | key pair recovery 257 | / | | | key pair update 258 | | | | certificate update 259 | C | V | revocation request 260 | R | -------+-+-----+-+------+-+----- 261 | L | PKI management | ^ | ^ 262 | | entities a | | b a | | b 263 | | V | | | 264 | R | g +------+ d | | 265 | e | <------------ | RA | <-----+ | | 266 | p | cert. | | ----+ | | | 267 | o | publish +------+ c | | | | 268 | s | | | | | 269 | i | V | V | 270 | t | h +------------+ i 271 | o | <------------------------| CA |-------> 272 | r | +------------+ "out-of-band" 273 | y | cert. publish | ^ publication 274 | | CRL publish | | 275 +---+ | | cross-certification 276 e | | f cross-certificate 277 | | update 278 | | 279 V | 280 +------+ 281 | CA-2 | 282 +------+ 284 Figure 1 - PKI Entities 286 At a high level the set of operations for which management messages are 287 defined can be grouped as follows. 289 1 CA establishment: When establishing a new CA, certain steps are 290 required (e.g., production of initial CRLs, export of CA public 291 key). 293 2 End entity initialisation: this includes importing a CA public key 294 and requesting information about the options supported by a PKI 295 management entity. 297 3 Certification: various operations result in the creation of new 298 certificates: 300 3.1 initial registration/certification: This is the process 301 whereby a subject first makes itself known to a CA or RA, 302 prior to the CA issuing a certificate or certificates for 303 that user. The end result of this process (when it is 304 successful) is that a CA issues a certificate for an end 305 entity's public key, and returns that certificate to the 306 subject and/or posts that certificate in a public 307 repository. This process may, and typically will, involve 308 multiple "steps", possibly including an initialization of 309 the end entity's equipment. For example, the subject 310 equipment must be securely initialized with the public key 311 of a CA, to be used in validating certificate paths. 312 Furthermore, a subject typically needs to be initialized 313 with its own key pair(s). 315 3.2 key pair update: Every key pair needs to be updated 316 regularly (i.e., replaced with a new key pair), and a new 317 certificate needs to be issued. 319 3.3 certificate update: As certificates expire they may be 320 "refreshed" if nothing relevant in the environment has 321 changed. 323 3.4 CA key pair update: As with end entities, CA key pairs need 324 to be updated regularly; however, different mechanisms are 325 required. 327 3.5 cross-certification: An initiating CA provides to a 328 responding CA the information necessary for the responding 329 CA to issue a cross-certificate. Note: this action may be 330 mutual, so that two cross-certificates are issued (one in 331 each direction). 333 3.6 cross-certificate update: Similar to a normal certificate 334 update but involving a cross-certificate. 336 4 Certificate/CRL discovery operations: some PKI management 337 operations result in the publication of certificates or CRLs 338 4.1 certificate publication: Having gone to the trouble of 339 producing a certificate some means for publishing it is 340 needed. The "means" defined in PKIX may involve the 341 messages specified in Sections 3.3.13 - 3.3.16, or may 342 involve other methods (LDAP, for example) as described in 343 Part II of this series (see [PKIX-2]). 345 4.2 CRL publication: As for certificates. 347 5 Recovery operations: some PKI management operations are used when 348 an end entity has "lost" it�s PSE 350 5.1 key pair recovery: As an option, user client key materials 351 (e.g., a user's private key used for decryption purposes) 352 may be backed up by a CA, an RA or a key backup system 353 associated with a CA or RA. If a subject needs to recover 354 these backed up key materials (e.g., as a result of a 355 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 which can form the basis 367 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 protocols supporting the above 377 operations. The protocols for conveying these exchanges in different 378 environments (file based, on-line, E-mail, and WWW) may also be 379 specified. 381 2. Assumptions and restrictions 383 2.1 End entity initialisation 385 The first step for and end entity in dealing with PKI management 386 entities is to request information about the PKI functions supported and 387 optionally to securely acquire a copy of the relevant root CA public 388 key(s). 390 2.2 Initial registration/certification 392 There are many schemes which can be used to achieve initial registration 393 and certification of end entities. No one method is suitable for all 394 situations due to the range of policies which a CA may implement and the 395 variation in the types of end entity which can occur. 397 We can however, classify the initial registration / certification 398 schemes which are supported by this specification. Note that the word 399 "initial", above, is crucial - we are dealing with the situation where 400 the end entity in question has had no previous contact with the PKI. 401 Where the end entity already possesses certified keys then some 402 simplifications/alternatives are possible. 404 Having classified the schemes which are supported by this specification 405 we can then specify some as mandatory and some as optional. The goal is 406 that the mandatory schemes cover a sufficient number of the cases which 407 will arise in real use, whilst the optional schemes are available for 408 special cases which arise less frequently. In this way we achieve a 409 balance between flexibility and ease of implementation. 411 We will now describe the classification of initial registration / 412 certification schemes. 414 2.2.1 Criteria used 416 2.2.1.1 Initiation of registration / certification 418 In terms of the PKI messages which are produced we can regard the 419 initiation of the initial registration / certification exchanges as 420 occurring wherever the first PKI message relating to the end entity is 421 produced. Note that the real world initiation of the registration / 422 certification procedure may occur elsewhere (e.g. a personnel department 423 may telephone an RA operator). 425 The possible locations are: at the end entity, an RA or a CA. 427 2.2.1.2 End entity message origin authentication 429 The on-line messages produced by the end entity which requires a 430 certificate may be authenticated or not. The requirement here is to 431 authenticate the origin of any messages from the end entity to the PKI 432 (CA/RA). 434 In this specification, such authentication is achieved by the PKI 435 (CA/RA) issuing the end entity with a secret value (initial 436 authentication key) and reference value (used to identify the 437 transaction) via some out-of-band means. The initial authentication key 438 can then be used to protect relevant PKI messages. 440 We can thus classify the initial registration/certification scheme 441 according to whether or not the on-line end entity -> PKI messages are 442 authenticated or not. 444 Note 1: We do not discuss the authentication of the PKI -> end entity 445 messages here as this is always required. In any case, it can be 446 achieved simply once the root-CA public key has been installed at the 447 end entity�s equipment or based on the initial authentication 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 wherever 456 either the public or private component of a key pair first occurs in a 457 PKI message. Note that this does not preclude a centralised key 458 generation service - the actual key pair may have been generated 459 elsewhere and transported to the end entity, RA or CA. 461 There are thus three possibilities for the location of key generation: 462 the end entity, an RA or a CA. 464 2.2.1.4 Confirmation of successful certification 466 Following the creation of an initial certificate for an end entity, 467 additional assurance can be gained by having the end entity explicitly 468 confirm successful receipt of the message containing (or indicating the 469 creation of) the certificate. Naturally, this confirmation message must 470 be protected (based on the initial authentication key or other means). 472 This gives two further possibilities: confirmed or not. 474 2.2.2 Mandatory schemes 476 The criteria above allow for a large number of initial registration / 477 certification schemes. This specification mandates that conforming RA/CA 478 equipment must support both of the schemes listed below. Conforming end 479 entity equipment must support one of the schemes listed below. 481 2.2.2.1 Centralised scheme 483 In terms of the classification above, this scheme is where: 485 - initiation occurs at the certifying CA; 486 - no on-line message authentication is required; 487 - key generation occurs at the certifying CA; 488 - no confirmation message is required. 490 In terms of message flow, this scheme means that the only message 491 required is sent from the CA to the end entity. The message must contain 492 the entire PSE for the end entity. Some out-of-band means must be 493 provided to allow the end entity to authenticate the message received. 495 2.2.2.2 Basic authenticated scheme 497 In terms of the classification above, this scheme is where: 499 - initiation occurs at the end entity 500 - message authentication is required 501 - key generation occurs at the end entity 502 - a confirmation message is required 504 In terms of message flow, the scheme is as follows: 506 End entity CA 507 ========== ============= 508 out-of-band distribution of 509 initial authentication key and 510 reference value 511 Key generation 512 Creation of certification request 513 Protect request with IAK 514 -->>--certification request-->> 515 verify request 516 process request 517 create response 518 --<<--certification response--<<-- 519 handle response 520 create confirmation 521 -->>--confirmation message-->>-- 522 verify confirmation 524 (Where verification of the confirmation message fails, the CA must 525 revoke the newly issued certificate if necessary.) 526 2.3 Proof of Possession (POP) of Private Key 528 In order to prevent certain attacks and to allow a CA/RA to properly 529 check the validity of the binding between an end entity and a key pair, 530 the PKI management operations specified here make it possible for an end 531 entity to prove that it has possession of (i.e., is able to use) the 532 private key corresponding to the public key for which a certificate is 533 requested. A given CA/RA is free to choose whether or not to enforce 534 POP in its certification exchanges (i.e., this may be a policy issue). 535 However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because 536 there are currently many non-PKIX operational protocols in use (various 537 electronic mail protocols are one example) which do not explicitly check 538 the binding between the end entity and the private key. Until 539 operational protocols which do verify the binding (for both signature 540 and encryption key pairs) exist, and are ubiquitous, this binding can 541 only be assumed to be verified by the CA/RA. Therefore, if the binding 542 is not verified by the CA/RA, certificates in the Internet Public-Key 543 Infrastructure end up being somewhat less meaningful. 545 POP is accomplished in different ways depending on the type of key for 546 which a certificate is requested. If a key can be used for multiple 547 purposes (e.g. an RSA key) then any of the methods may be used. 549 This specification explicitly allows for cases where an end entity 550 supplies the relevant proof to an RA and the RA subsequently attests to 551 the CA that the required proof has been received (and validated!). For 552 example, an end entity wishing to have a signing key certified could 553 send the appropriate signature to the RA which then simply notifies the 554 relevant CA that the end entity has supplied the required proof. Of 555 course, such a situation may be disallowed by some policies. 557 2.3.1 Signature Keys 559 For signature keys, the end entity can sign a value to prove possession 560 of the private key. 562 2.3.2 Encryption Keys 564 For encryption keys, the end entity can provide the private key to the 565 CA/RA, or can be required to decrypt a value in order to prove 566 possession of the private key (see Section 3.2.8). Decrypting a value 567 can be achieved either directly or indirectly. 569 The direct method is to issue a random challenge to which an immediate 570 response is required. 572 The indirect method is to issue a certificate which is encrypted for the 573 end entity (and have the end entity demonstrate its ability to decrypt 574 this certificate in the confirmation message). This allows a CA to issue 575 a certificate in a form which can only be used by the intended end 576 entity. 578 This specification encourages the indirect method because this requires 579 no extra messages to be sent (i.e., the proof can be demonstrated using 580 the {request, response, confirmation} triple of messages). 582 2.3.3 Key Agreement Keys 584 For key agreement keys, the end entity and the PKI management entity 585 (i.e. CA or RA) must establish a shared secret key in order to prove 586 that the end entity has possession of the private key. 588 Note that this need not impose any restrictions on the keys which can be 589 certified by a given CA -- in particular, for Diffie-Hellman keys the 590 end entity may freely choose its algorithm parameters -- provided that 591 the CA can generate a short-term (or one-time) key pair with the 592 appropriate parameters when necessary. 594 2.4 Root CA key update 596 This discussion only applies to CAs which are a root CA for some end 597 entity. 599 The basis of the procedure described here is that the CA protects its 600 new public key using its previous private key and vice versa. Thus when 601 a CA updates its key pair it must generate two new cACertificate 602 attribute values if certificates are made available using an X.500 603 directory. 605 When a CA changes its key pair those entities who have acquired the old 606 CA public key via "out-of-band" means are most affected. It is these end 607 entities who will need access to the new CA public key protected with 608 the old CA private key. However, they will only require this for a 609 limited period (until they have acquired the new CA public key via the 610 "out-of-band" mechanism). This will typically be easily achieved when 611 these end entity's certificates expire. 613 The data structure used to protect the new and old CA public keys is a 614 standard certificate (which may also contain extensions). There are no 615 new data structures required. 617 Notes: 619 1.This scheme does not make use of any of the X.509 v3 extensions as it 620 must be able to work even for version 1 certificates. The presence of 621 the KeyIdentifier extension would make for efficiency improvements. 623 2.While the scheme could be generalized to cover cases where the CA 624 updates its key pair more than once during the validity period of one of 625 its end entity's certificates, this generalization seems of dubious 626 value. This means that the validity period of a CA key pair must be 627 greater than the validity period of any certificate issued by that CA 628 using that key pair. 630 3.This scheme forces end entities to acquire the new CA public key on 631 the expiry of the last certificate they owned which was signed with the 632 old CA private key (via the "out-of-band" means). Certificate and/or 633 key update operations occurring at other times do not necessarily 634 require this (depending on the end entity's equipment). 636 2.4.1 CA Operator actions 638 To change the key of the CA, the CA operator does the following: 640 1.Generate a new key pair. 642 2.Create a certificate containing the old CA public key signed with 643 the new private key (the "old with new" certificate). 645 3.Create a certificate containing the new CA public key signed with 646 the old private key (the "new with old" certificate). 648 4.Create a certificate containing the new CA public key signed with 649 the new private key (the "new with new" certificate). 651 5.Publish these new certificates via the directory and/or other means. 652 (A CAKeyUpdAnn message.) 654 6.Export the new CA public key so that end entities may acquire it 655 using the "out-of-band" mechanism. 657 The old CA private key is then no longer required. The old CA public key 658 will however remain in use for some time. The time when the old CA 659 public key is no longer required (other than for non-repudiation) will 660 be when all end entities of this CA have acquired the new CA public key 661 via "out-of-band" means. 663 The "old with new" certificate must have a validity period starting at 664 the generation time of the old key pair and ending at the time at which 665 the CA will next update its key pair. 667 The "new with old" certificate must have a validity period starting at 668 the generation time of the new key pair and ending at the time by which 669 all end entities of this CA will securely possess the new CA public key. 671 The "new with new" certificate must have a validity period starting at 672 the generation time of the new key pair and ending at the time at which 673 the CA will next update its key pair. 675 2.4.2 Verifying Certificates. 677 Normally when verifying a signature the verifier verifies, among other 678 things, the certificate containing the public key of the signer. 679 However, once a CA is allowed to update its key there are a range of new 680 possibilities. These are shown in the table below. 682 Repository contains NEW Repository contains only OLD 683 and OLD public keys public key (due to e.g. 684 delay in publication) 686 PSE PSE Contains PSE Contains PSE Contains 687 Contains OLD public NEW public OLD public 688 NEW public key key key 689 key 691 Signer's Case 1: Case 3: Case 5: Case 7: 692 certifi- This is In this case Although the In this case 693 cate is the the verifier CA operator the CA 694 protected standard must access has not operator has 695 using NEW case where the updated the not updated 696 public the directory in directory the the directory 697 key verifier order to get verifier can and so the 698 can the value of verify the verification 699 directly the NEW certificate will FAIL 700 verify the public key directly - 701 certificate this is thus 702 without the same as 703 using the case 1. 704 directory 706 Signer's Case 2: Case 4: Case 6: Case 8: 707 certifi- In this In this case The verifier Although the 708 cate is case the the verifier thinks this CA operator 709 protected verifier can directly is the has not 710 using OLD must verify the situation of updated the 711 public access the certificate case 2 and directory the 712 key directory without will access verifier can 713 in order using the the verify the 714 to get the directory directory, certificate 715 value of however the directly - 716 the OLD verification this is thus 717 public key will FAIL the same as 718 case 4. 720 2.4.2.1 Verification in cases 1, 4, 5 and 8. 722 In these cases the verifier has a local copy of the CA public key which 723 can be used to verify the certificate directly. This is the same as the 724 situation where no key change has ever occurred. 726 Note that case 8 may arise between the time when the CA operator has 727 generated the new key pair and the time when the CA operator stores the 728 updated attributes in the directory. Case 5 can only arise if the CA 729 operator has issued both the signer's and verifier's certificates during 730 this "gap" (the CA operator should avoid this as it leads to the failure 731 cases described below). 733 2.4.2.2 Verification in case 2. 735 In case 2 the verifier must get access to the old public key of the CA. 736 The verifier does the following: 738 1.Lookup the CACertificate attribute in the directory and pick the 739 appropriate value (based on validity periods) 740 2.Verify that this is correct using the new CA key (which the verifier 741 has locally). 742 3.If correct then check the signer's certificate using the old CA key. 744 Case 2 will arise when the CA operator has issued the signer's 745 certificate, then changed key and then issued the verifier's 746 certificate, so it is quite a typical case. 748 2.4.2.3 Verification in case 3. 750 In case 3 the verifier must get access to the new public key of the CA. 751 The verifier does the following: 753 1.Lookup the CACertificate attribute in the directory and pick the 754 appropriate value (based on validity periods). 755 2.Verify that this is correct using the old CA key (which the verifier 756 has stored locally). 757 3.If correct then check the signer's certificate using the new CA key. 759 Case 3 will arise when the CA operator has issued the verifier's 760 certificate, then changed key and then issued the signer's certificate, 761 so it is also quite a typical case. 763 2.4.2.4 Failure of verification in case 6. 765 In this case the CA has issued the verifier's PSE containing the new key 766 without updating the directory attributes. This means that the verifier 767 has no means to get a trustworthy version of the CA's old key and so 768 verification fails. 770 Note that the failure is the CA operator's fault. 772 2.4.2.5 Failure of verification in case 7. 774 In this case the CA has issued the signer's certificate protected with 775 the new key without updating the directory attributes. This means that 776 the verifier has no means to get a trustworthy version of the CA's new 777 key and so verification fails. 779 Note that the failure is again the CA operator's fault. 781 2.4.3 Revocation - Change of CA key 783 As we saw above the verification of a certificate becomes more complex 784 once the CA is allowed to change its key. This is also true for 785 revocation checks as the CA may have signed the CRL using a newer 786 private key than the one that is within the user's PSE. 788 The analysis of the alternatives is as for certificate verification. 790 3. Data Structures 791 This section contains descriptions of the data structures required for 792 PKI management messages. Section 4 describes constraints on their values 793 and the sequence of events for each of the various PKI management 794 operations. Section 5 describes how these may be encapsulated in various 795 transport mechanisms. 797 3.1 Overall PKI Message 799 All of the messages used in PKI management use the following structure: 801 PKIMessage ::= SEQUENCE { 802 header PKIHeader, 803 body PKIBody, 804 protection [0] PKIProtection OPTIONAL, 805 extraCerts [1] SEQUENCE OF Certificate OPTIONAL 806 } 808 The PKIHeader contains information which is common to many PKI messages. 810 The PKIBody contains message-specific information. 812 The PKIProtection, when used, contains bits which protect the PKI 813 message. 815 The extra certificates field can contain certificates which may be 816 useful to the recipient. For example, this can be used by a CA or RA to 817 present an end entity with certificates which it needs to verify it�s 818 own new certificate (if the CA that issued the end entity�s certificate 819 is not a root CA for the end entity). 821 Note also that this field does not necessarily contain a certification 822 path - the recipient may have to sort, select from, or otherwise process 823 the extra certificates in order to use them. 825 3.1.1 PKI Message Header 827 All PKI messages require some header information for addressing and 828 transaction identification. Some of this information will also be 829 present in a transport-specific envelope; however, if the PKI message is 830 protected then this information is also protected (i.e. we make no 831 assumption about secure transport). 833 The following data structure is used to contain this information: 835 PKIHeader ::= SEQUENCE { 836 pvno INTEGER { ietf-version1 (0) }, 837 sender GeneralName, 838 -- identifies the sender 839 recipient GeneralName, 840 -- identifies the intended recipient 841 messageTime [0] GeneralizedTime OPTIONAL, 842 -- time of production of this message (used when sender 843 -- believes that the transport will be "suitable"; i.e., 844 -- that the time will still be meaningful upon receipt) 845 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 846 -- algorithm used for calculation of protection bits 847 senderKID [2] KeyIdentifier OPTIONAL, 848 recipKID [3] KeyIdentifier OPTIONAL, 849 -- to identify specific keys used for protection 850 transactionID [4] OCTET STRING OPTIONAL, 851 -- identifies the transaction, i.e. this will be the same in 852 -- corresponding request, response and confirmation messages 853 senderNonce [5] OCTET STRING OPTIONAL, 854 recipNonce [6] OCTET STRING OPTIONAL, 855 -- nonces used to provide replay protection, senderNonce 856 -- is inserted by the creator of this message; recipNonce 857 -- is a nonce previously inserted in a related message by 858 -- the intended recipient of this message 859 freeText [7] PKIFreeText OPTIONAL 860 -- this may be used to indicate context-specific 861 -- instructions (this field is intended for human 862 -- consumption) 863 } 865 PKIFreeText ::= CHOICE { 866 iA5String [0] IA5String, 867 bMPString [1] BMPString 868 } -- note that the text included here would ideally be in the 869 -- preferred language of the recipient 871 The pvno field is fixed for this version of IPKI. 873 The sender field contains the name of the sender of the PKIMessage. This 874 name (in conjunction with senderKID, if supplied) should be usable to 875 verify the protection on the message. If nothing about the sender is 876 known to the sending entity (e.g., in the InitReqContent message, where 877 the end entity may not know its own DN, e-mail name, IP address, etc.), 878 then the "sender" field must contain a "NULL" value; that is, the 879 SEQUENCE OF relative distinguished names is of zero length. In such a 880 case the senderKID field must hold an identifier (i.e., a reference 881 number) which indicates to the receiver the appropriate shared secret 882 information to use to verify the message. 884 The recipient field contains the name of the recipient of the 885 PKIMessage. This name (in conjunction with recipKID, if supplied) should 886 be usable to verify the protection on the message. 888 The protectionAlg field specifies the algorithm used to protect the 889 message. If no protection bits are supplied (PKIProtection is optional) 890 then this field must be omitted; if protection bits are supplied then 891 this field must be supplied. 893 senderKID and recipKID are usable to indicate which keys have been used 894 to protect the message (recipKID will normally only be required where 895 protection of the message uses DH keys). 897 The transactionID field within the message header is required so that 898 the recipient of a response message can correlate this with a previously 899 issued request. For example, in the case of an RA there may be many 900 requests "outstanding" at a given moment. 902 The senderNonce and recipNonce fields protect the PKIMessage against 903 replay attacks. 905 The messageTime field contains the time at which the sender created the 906 message. This may be useful to allow end entities to correct their local 907 time to be consistent with the time on a central system. 909 The freeText field may be used to send a human-readable message to the 910 recipient. 912 3.1.2 PKI Message Body 914 PKIBody ::= CHOICE { -- message-specific body elements 915 ir [0] InitReqContent, 916 ip [1] InitRepContent, 917 cr [2] CertReqContent, 918 cp [3] CertRepContent, 919 p10cr [4] PKCS10CertReqContent, 920 popdecc [5] POPODecKeyChallContent, 921 popdecr [6] POPODecKeyRespContent, 922 kur [7] KeyUpdReqContent, 923 kup [8] KeyUpdRepContent, 924 krr [9] KeyRecReqContent, 925 krp [10] KeyRecRepContent, 926 rr [11] RevReqContent, 927 rp [12] RevRepContent, 928 ccr [13] CrossCertReqContent, 929 ccp [14] CrossCertRepContent, 930 ckuann [15] CAKeyUpdAnnContent, 931 cann [16] CertAnnContent, 932 rann [17] RevAnnContent, 933 crlann [18] CRLAnnContent, 934 conf [19] PKIConfirmContent, 935 nested [20] NestedMessageContent, 936 infor [21] PKIInfoReqContent, 937 infop [22] PKIInfoRepContent, 938 error [23] ErrorMsgContent 939 } 941 The specific types are described in section 3.3 below. 943 3.1.3 PKI Message Protection 945 Some PKI messages will be protected for integrity. (Note that if an 946 asymmetric algorithm is used to protect a message and the relevant 947 public component has been certified already, then the origin of message 948 can also be authenticated. On the other hand, if the public component 949 is uncertified then the message origin cannot be automatically 950 authenticated, but may be authenticated via out-of-band means.) 952 When protection is applied the following structure is used: 954 PKIProtection ::= BIT STRING 956 The input to the calculation of the protectionBits is the DER encoding 957 of the following data structure: 959 ProtectedPart ::= SEQUENCE { 960 header PKIHeader, 961 body PKIBody 962 } 964 There may be cases in which the PKIProtection BIT STRING is deliberately 965 not used to protect a message (i.e., this OPTIONAL field is omitted) 966 because other protection, external to PKIX, will instead be applied. 967 Such a choice is explicitly allowed in this specification. Examples of 968 such external protection include PKCS #7 [PKCS7] and Security Multiparts 969 [RFC1847] encapsulation of the PKIMessage. It is noted, however, that 970 many such external mechanisms require that the end entity already 971 possesses a public-key certificate, and/or a unique Distinguished Name, 972 and/or other such infrastructure-related information. Thus, they may 973 not be appropriate for initial registration, key-recovery, or any other 974 process with "boot-strapping" characteristics. For those cases it may 975 be necessary that the PKIProtection parameter be used. In the future, 976 if/when external mechanisms are modified to accommodate boot-strapping 977 scenarios, the use of the PKIProtection parameter may become rare or 978 non-existent. 980 Depending on the circumstances the PKIProtection bits may contain a MAC 981 or signature. Only the following cases can occur: 983 - shared secret information 985 In this case the sender and recipient share secret information 986 (established via out-of-band means or from a previous PKI management 987 operation). The protection bits will typically contain a MAC value and 988 the protectionAlg will be the following: 990 PasswordBasedMac ::= OBJECT IDENTIFIER 992 PBMParameter ::= SEQUENCE { 993 salt OCTET STRING, 994 owf AlgorithmIdentifier, 995 -- AlgId for a One-Way Function (SHA-1 recommended) 996 iterationCount INTEGER, 997 -- number of times the OWF is applied 998 mac AlgorithmIdentifier 999 -- the MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11]) 1000 } 1002 In the above protectionAlg the salt value is appended to the shared 1003 secret input. The OWF is then applied iterationCount times, where the 1004 salted secret is the input to the first iteration and, for each 1005 successive iteration, the input is set to be the output of the previous 1006 iteration. The output of the final iteration (called "BASEKEY" for ease 1007 of reference, with a size of "H") is what is used to form the symmetric 1008 key. If the MAC algorithm requires a K-bit key and K <= H, then the most 1009 significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is 1010 used for the most significant H bits of the key, OWF("1" || BASEKEY) is 1011 used for the next most significant H bits of the key, OWF("2" || 1012 BASEKEY) is used for the next most significant H bits of the key, and so 1013 on, until all K bits have been derived. [Here "N" is the ASCII byte 1014 encoding the number N and "||" represents concatenation.] 1015 - DH key pairs 1017 Where the sender and receiver possess Diffie-Hellman certificates with 1018 compatible DH parameters, then in order to protect the message the end 1019 entity must generate a symmetric key based on its private DH key value 1020 and the DH public key of the recipient of the PKI message. The 1021 protection bits will typically contain a MAC value keyed with this 1022 derived symmetric key and the protectionAlg will be the following:. 1024 DHBasedMac ::= OBJECT IDENTIFIER 1026 DHBMParameter ::= SEQUENCE { 1027 owf AlgorithmIdentifier, 1028 -- AlgId for a One-Way Function (SHA-1 recommended) 1029 mac AlgorithmIdentifier 1030 -- the MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11]) 1031 } 1033 In the above protectionAlg OWF is applied to the result of the Diffie- 1034 Hellman computation. The OWF output (called "BASEKEY" for ease of 1035 reference, with a size of "H") is what is used to form the symmetric 1036 key. If the MAC algorithm requires a K-bit key and K <= H, then the most 1037 significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is 1038 used for the most significant H bits of the key, OWF("1" || BASEKEY) is 1039 used for the next most significant H bits of the key, OWF("2" || 1040 BASEKEY) is used for the next most significant H bits of the key, and so 1041 on, until all K bits have been derived. [Here "N" is the ASCII byte 1042 encoding the number N and "||" represents concatenation.] 1044 - signature 1046 Where the sender possesses a signature key pair it may simply sign the 1047 PKI message. The protection bits will contain a signature value and the 1048 protectionAlg will be an AlgorithmIdentifier for a digital signature 1049 (e.g., md5WithRSAEncryption or dsaWithSha-1). 1051 - multiple protection 1053 In cases where an end entity sends a protected PKI message to an RA, the 1054 RA may forward that message to a CA, attaching it�s own protection. This 1055 is accomplished by nesting the entire message sent by the end entity 1056 within a new PKI message. The structure used is as follows. 1058 NestedMessageContent ::= ANY 1059 -- This will be a PKIMessage 1061 3.2 Common Data Structures 1063 Before specifying the specific types which may be placed in a PKIBody we 1064 define some useful data structures which are used in more than one case. 1066 3.2.1 Requested Certificate Contents 1068 Various PKI management messages require that the originator of the 1069 message indicate some of the fields which are required to be present in 1070 a certificate. The CertTemplate structure allows an end entity or RA to 1071 specify as much as they wish about the certificate it requires. 1072 ReqCertContent is basically the same as a Certificate but with all 1073 fields optional. 1075 Note that even if the originator completely specifies the contents of a 1076 certificate it requires, a CA is free to modify fields within the 1077 certificate actually issued. 1079 CertTemplate ::= SEQUENCE { 1080 version [0] Version OPTIONAL, 1081 -- used to ask for a particular syntax version 1082 serial [1] INTEGER OPTIONAL, 1083 -- used to ask for a particular serial number 1084 signingAlg [2] AlgorithmIdentifier OPTIONAL, 1085 -- used to ask the CA to use this alg. for signing the cert 1086 subject [3] Name OPTIONAL, 1087 validity [4] OptionalValidity OPTIONAL, 1088 issuer [5] Name OPTIONAL, 1089 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 1090 issuerUID [7] UniqueIdentifier OPTIONAL, 1091 subjectUID [8] UniqueIdentifier OPTIONAL, 1092 extensions [9] Extensions OPTIONAL 1093 -- the extensions which the requester would like in the cert. 1094 } 1096 OptionalValidity ::= SEQUENCE { 1097 notBefore [0] UTCTime OPTIONAL, 1098 notAfter [1] UTCTime OPTIONAL 1099 } 1101 3.2.2 Encrypted Values 1103 Where encrypted values (restricted, in this specification, to be either 1104 private keys or certificates) are sent in PKI messages the following 1105 data structure is used. 1107 EncryptedValue ::= SEQUENCE { 1108 encValue BIT STRING, 1109 -- the encrypted value itself 1110 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 1111 -- the intended algorithm for which the value will be used 1112 symmAlg [1] AlgorithmIdentifier OPTIONAL, 1113 -- the symmetric algorithm used to encrypt the value 1114 encSymmKey [2] BIT STRING OPTIONAL, 1115 -- the (encrypted) symmetric key used to encrypt the value 1116 keyAlg [3] AlgorithmIdentifier OPTIONAL 1117 -- algorithm used to encrypt the symmetric key 1118 } 1120 Use of this data structure requires that the creator and intended 1121 recipient are respectively able to encrypt and decrypt. Typically, this 1122 will mean that the sender and recipient have, or are able to generate, a 1123 shared secret key. 1125 If the recipient of the PKIMessage already possesses a private key 1126 usable for decryption, then the encSymmKey field may contain a session 1127 key encrypted using the recipient's public key. 1129 3.2.3 Status codes and Failure Information for PKI messages 1131 All response messages will include some status information. The 1132 following values are defined. 1134 PKIStatus ::= INTEGER { 1135 granted (0), 1136 -- you got exactly what you asked for 1137 grantedWithMods (1), 1138 -- you got something like what you asked for; the 1139 -- requester is responsible for ascertaining the differences 1140 rejection (2), 1141 -- you don't get it, more information elsewhere in the message 1142 waiting (3), 1143 -- the request body part has not yet been processed, 1144 -- expect to hear more later 1145 revocationWarning (4), 1146 -- this message contains a warning that a revocation is 1147 -- imminent 1148 revocationNotification (5), 1149 -- notification that a revocation has occurred 1150 keyUpdateWarning (6) 1151 -- update already done for the oldCertId specified in 1152 -- FullCertTemplate 1153 } 1155 Responders may use the following syntax to provide more information 1156 about failure cases. 1158 PKIFailureInfo ::= BIT STRING { 1159 -- since we can fail in more than one way! 1160 -- More codes may be added in the future if/when required. 1161 badAlg (0), 1162 -- unrecognized or unsupported Algorithm Identifier 1163 badMessageCheck (1), 1164 -- integrity check failed (e.g., signature did not verify) 1165 badRequest (2), 1166 -- transaction not permitted or supported 1167 badTime (3), 1168 -- messageTime was not sufficiently close to the system time, 1169 -- as defined by local policy 1170 badCertId (4), 1171 -- no certificate could be found matching the provided criteria 1172 badDataFormat (5), 1173 -- the data submitted has the wrong format 1174 wrongAuthority (6), 1175 -- the authority indicated in the request is different from the 1176 -- one creating the response token 1177 incorrectData (7), 1178 -- the requester's data is incorrect (for notary services) 1179 missingTimeStamp (8) 1180 -- when the timestamp is missing but should be there (by policy) 1181 } 1183 PKIStatusInfo ::= SEQUENCE { 1184 status PKIStatus, 1185 statusString PKIFreeText OPTIONAL, 1186 failInfo PKIFailureInfo OPTIONAL 1187 } 1189 3.2.4 Certificate Identification 1191 In order to identify particular certificates the following data 1192 structure is used. 1194 CertId ::= SEQUENCE { 1195 issuer GeneralName, 1196 serialNumber INTEGER 1197 } 1199 3.2.5 "Out-of-band" root CA public key 1201 Each root CA must be able to publish its current public key via some 1202 "out-of-band" means. While such mechanisms are beyond the scope of this 1203 document, we define data structures which can support such mechanisms. 1205 There are generally two methods available; either the CA directly 1206 publishes its self-signed certificate, or this information is available 1207 via the Directory (or equivalent) and the CA publishes a hash of this 1208 value to allow verification of its integrity before use. 1210 OOBCert ::= Certificate 1212 The fields within this certificate are restricted as follows: 1214 - The certificate must be self-signed, i.e. the signature must be 1215 verifiable using the subjectPublicKey field. 1216 - The subject and issuer fields should be identical. 1217 - If the subject field is NULL then both subjectAltNames and 1218 issuerAltNames extensions must be present and have exactly the same 1219 value. 1220 - The values of all other extensions must be suitable for a self- 1221 certificate (e.g. key identifiers for subject and issuer must be the 1222 same). 1224 OOBCertHash ::= SEQUENCE { 1225 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1226 certId [1] CertId OPTIONAL, 1227 hashVal BIT STRING 1228 -- hashVal is calculated over the self-signed 1229 -- certificate with the identifier certID. 1230 } 1232 The intention of the hash value here is that anyone who has securely 1233 gotten the hash value (via the out-of-band means) can verify a self- 1234 signed certificate for that CA. 1236 3.2.6 Archival Options 1238 Requesters may indicate that they wish the PKI to archive a private key 1239 value using the following structure: 1241 PKIArchiveOptions ::= CHOICE { 1242 encryptedPrivKey [0] EncryptedValue, 1243 -- the actual value of the private key 1244 keyGenParameters [1] KeyGenParameters, 1245 -- parameters which allow the private key to be re-generated 1246 archiveRemGenPrivKey [2] BOOLEAN 1247 -- set to TRUE if sender wishes receiver to archive the private 1248 -- key of a key pair which the receiver generates in response to 1249 -- this request; set to FALSE if no archival is desired. 1250 } 1251 KeyGenParameters ::= OCTET STRING 1252 -- an alternative to sending the key is to send the information 1253 -- about how to re-generate the key (e.g. for many RSA 1254 -- implementations one could send the first random numbers tested 1255 -- for primality). 1256 -- The actual syntax for this parameter may be defined in a 1257 -- subsequent version of this document or in another standard. 1259 3.2.7 Publication Information 1260 Requesters may indicate that they wish the PKI to publish a certificate 1261 using the structure below. 1263 If the dontPublish option is chosen, the requester indicates that the 1264 PKI should not publish the certificate (this may indicate that the 1265 requester intends to publish the certificate him/herself). 1267 If the dontCare method is chosen, the requester indicates that the PKI 1268 may publish the certificate using whatever means it chooses. 1270 The pubLocation field, if supplied, indicates where the requester would 1271 like the certificate to be found (note that the CHOICE within 1272 GeneralName includes a URL and an IP address, for example). 1274 PKIPublicationInfo ::= SEQUENCE { 1275 action INTEGER { 1276 dontPublish (0), 1277 pleasePublish (1) 1278 }, 1279 pubInfos SEQUENCE OF SinglePubInfo OPTIONAL 1280 -- pubInfos must not be present if action is "dontPublish" 1281 -- (if action is "pleasePublish" and pubInfos is omitted, 1282 -- "dontCare" is assumed) 1283 } 1285 SinglePubInfo ::= SEQUENCE { 1286 pubMethod INTEGER { 1287 dontCare (0), 1288 x500 (1), 1289 web (2) 1290 }, 1291 pubLocation GeneralName OPTIONAL 1292 } 1294 3.2.8 "Full" Request Template 1296 The following structure groups together the fields which may be sent as 1297 part of a certification request: 1299 FullCertTemplates ::= SEQUENCE OF FullCertTemplate 1300 FullCertTemplate ::= SEQUENCE { 1301 certReqId INTEGER, 1302 -- to match this request with corresponding response 1303 -- (note: must be unique over all FullCertReqs in this message) 1304 certTemplate CertTemplate, 1305 popoPrivKeyVerified BOOLEAN DEFAULT FALSE, 1306 popoSigningKey [0] POPOSigningKey OPTIONAL, 1307 archiveOptions [1] PKIArchiveOptions OPTIONAL, 1308 publicationInfo [2] PKIPublicationInfo OPTIONAL, 1309 oldCertId [3] CertId OPTIONAL 1310 -- id. of cert. which is being updated by this one 1311 } 1313 When the certification request is made by an RA on behalf of some other 1314 end entity, then the RA may indicate to the CA that it has already 1315 verified proof-of-possession (of the private key corresponding to the 1316 public key for which a certificate is being requested) by setting 1317 popoPrivKeyVerified to TRUE. If the proof-of-possession has not yet 1318 been verified, or if the request is not being made by an RA, then the 1319 popoPrivKeyVerified field is omitted (defaulting to FALSE) and the 1320 popoSigningKey field or the challenge-response protocol described below 1321 may be used to prove possession (depending on the type of key involved). 1323 If the certification request is for a signing key pair (i.e., a request 1324 for a verification certificate), then the proof of possession of the 1325 private signing key is demonstrated through use of the POPOSigningKey 1326 structure. 1328 POPOSigningKey ::= SEQUENCE { 1329 poposkInput POPOSKInput, 1330 alg AlgorithmIdentifier, 1331 signature BIT STRING 1332 -- the signature (using "alg") on the DER-encoded 1333 -- value of poposkInput 1334 } 1336 POPOSKInput ::= CHOICE { 1337 popoSigningKeyInput [0] POPOSigningKeyInput, 1338 certificationRequestInfo CertificationRequestInfo 1339 -- imported from [PKCS10] (note that if this choice is used, 1340 -- POPOSigningKey is simply a standard PKCS #10 request; this 1341 -- allows a bare PKCS #10 request to be augmented with other 1342 -- desired information in the FullCertTemplate before being 1343 -- sent to the CA/RA) 1344 } 1345 POPOSigningKeyInput ::= SEQUENCE { 1346 authInfo CHOICE { 1347 sender [0] GeneralName, 1348 -- from PKIHeader (used only if an authenticated identity 1349 -- has been established for the sender (e.g., a DN from a 1350 -- previously-issued and currently-valid certificate) 1351 publicKeyMAC [1] BIT STRING 1352 -- used if no authenticated GeneralName currently exists for 1353 -- the sender; publicKeyMAC contains a password-based MAC 1354 -- (using the protectionAlg AlgId from PKIHeader) on the 1355 -- DER-encoded value of publicKey 1356 }, 1357 publicKey SubjectPublicKeyInfo -- from CertTemplate 1358 } 1360 On the other hand, if the certification request is for an encryption key 1361 pair (i.e., a request for an encryption certificate), then the proof of 1362 possession of the private decryption key may be demonstrated in one of 1363 three ways. 1365 1) By the inclusion of the private key (encrypted) in the 1366 FullCertTemplate (in the PKIArchivalOptions structure). 1368 2) By having the CA return not the certificate, but an encrypted 1369 certificate (i.e., the certificate encrypted under a randomly-generated 1370 symmetric key, and the symmetric key encrypted under the public key for 1371 which the certification request is being made). The end entity proves 1372 knowledge of the private decryption key to the CA by MACing the 1373 PKIConfirm message using a key derived from this symmetric key. [Note 1374 that if several FullCertTemplates are included in the PKIMessage, then 1375 the CA uses a different symmetric key for each FullCertTemplate and the 1376 MAC uses a key derived from the concatenation of all these keys.] The 1377 MACing procedure uses the PasswordBasedMac AlgId defined in Section 3.1. 1379 3) By having the end entity engage in a challenge-response protocol 1380 (using the messages POPODecKeyChallContent and POPODecKeyRespContent) 1381 between the CertReq and CertRep messages. [This method would typically 1382 be used in an environment in which an RA verifies POP and then makes a 1383 certification request to the CA on behalf of the end entity. In such a 1384 scenario, the CA trusts the RA to have done POP correctly before the RA 1385 requests a certificate for the end entity.] The complete protocol then 1386 looks as follows (note that req' does not necessarily encapsulate req as 1387 a nested message): 1389 EE RA CA 1390 ---- req ----> 1391 <--- chall --- 1392 ---- resp ---> 1393 ---- req' ---> 1394 <--- rep ----- 1395 ---- conf ---> 1396 <--- rep ----- 1397 ---- conf ---> 1399 This protocol is obviously much longer than the 3-way exchange given in 1400 choice (2) above, but allows a local Registration Authority to be 1401 involved and has the property that the certificate itself is not 1402 actually created until the proof of possession is complete. 1404 3.3 Operation-Specific Data Structures 1406 3.3.1 Initialization Request 1408 An Initialization request message (InitReq) contains an InitReqContent 1409 data structure which specifies the requested certificate(s). Typically, 1410 SubjectPublicKeyInfo, KeyId, and Validity are the template fields which 1411 may be supplied for each certificate requested (see Appendix B profiles 1412 for further information). 1414 InitReqContent ::= SEQUENCE { 1415 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 1416 fullCertTemplates FullCertTemplates 1417 } 1419 3.3.2 Initialization Response 1421 An Initialization response message (InitRep) contains an InitRepContent 1422 data structure which has for each certificate requested a PKIStatusInfo 1423 field, a subject certificate, and possibly a private key (normally 1424 encrypted with a session key, which is itself encrypted with the 1425 protocolEncKey). 1427 InitRepContent ::= CertRepContent 1429 3.3.3 Registration/Certification Request 1431 A Registration/Certification request message (CertReq) contains a 1432 CertReqContent data structure which specifies the requested 1433 FullCertTemplates. 1435 Alternatively, for the cases in which it can be used, the CertReq may 1436 contain a PKCS10CertReqContent. This structure is fully specified by 1437 the ASN.1 structure CertificationRequest given in [PKCS10]. 1439 CertReqContent ::= CHOICE { 1440 fullCertTemplates [0] FullCertTemplates, 1441 pkcs10CertReqContent [1] PKCS10CertReqContent 1442 } 1444 The challenge-response messages for proof of possession of a private 1445 decryption key are specified as follows (see [MvOV97, p.404], for 1446 details). Note that this challenge-response exchange is associated with 1447 the preceding cert. request message (and subsequent cert. response and 1448 confirmation messages) by the nonces used in the PKIHeader and by the 1449 protection (MACing or signing) applied to the PKIMessage. 1451 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1452 -- One Challenge per encryption key certification request (in the 1453 -- same order as these requests appear in FullCertTemplates). 1455 Challenge ::= SEQUENCE { 1456 owf AlgorithmIdentifier OPTIONAL, 1457 -- must be present in the first Challenge; may be omitted in any 1458 -- subsequent Challenge in POPODecKeyChallContent (if omitted, 1459 -- then the owf used in the immediately preceding Challenge is 1460 -- to be used). 1461 witness OCTET STRING, 1462 -- the result of applying the one-way function (owf) to a 1463 -- randomly-generated INTEGER, A. [Note that a different 1464 -- INTEGER must be used for each Challenge.] 1465 challenge OCTET STRING 1466 -- the encryption (under the public key for which the cert. 1467 -- request is being made) of Rand, where Rand is specified as 1468 -- Rand ::= SEQUENCE { 1469 -- int INTEGER, 1470 -- - the randomly-generated INTEGER A (above) 1471 -- sender GeneralName 1472 -- - the sender's name (as included in PKIHeader) 1473 -- } 1474 } 1476 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1477 -- One INTEGER per encryption key certification request (in the 1478 -- same order as these requests appear in FullCertTemplates). The 1479 -- retrieved INTEGER A (above) is returned to the sender of the 1480 -- corresponding Challenge. 1482 3.3.4 Registration/Certification Response 1484 A registration response message (CertRep) contains a CertRepContent data 1485 structure which has a CA public key, a status value and optionally 1486 failure information, a subject certificate, and an encrypted private 1487 key. 1489 CertRepContent ::= SEQUENCE { 1490 caPub [1] Certificate OPTIONAL, 1491 response SEQUENCE OF CertResponse 1492 } 1494 CertResponse ::= SEQUENCE { 1495 certReqId INTEGER, 1496 -- to match this response with corresponding request 1497 status PKIStatusInfo, 1498 certifiedKeyPair CertifiedKeyPair OPTIONAL 1499 } 1501 CertifiedKeyPair ::= SEQUENCE { 1502 certificate [0] Certificate OPTIONAL, 1503 encryptedCert [1] EncryptedValue OPTIONAL, 1504 privateKey [2] EncryptedValue OPTIONAL, 1505 publicationInfo [3] PKIPublicationInfo OPTIONAL 1506 } 1508 Only one of the failInfo (in PKIStatusInfo) and certificate (in 1509 CertifiedKeyPair) fields can be present in each CertResponse (depending 1510 on the status). For some status values (e.g., waiting) neither of the 1511 optional fields will be present. 1513 The CertifiedKeyPair structure must contain either a Certificate or an 1514 EncryptedCert, and an optional EncryptedPrivateKey (i.e. not both a 1515 Certificate and EncryptedCert). 1517 Given an EncryptedCert and the relevant decryption key the certificate 1518 may be obtained. The purpose of this is to allow a CA to return the 1519 value of a certificate, but with the constraint that only the intended 1520 recipient can obtain the actual certificate. The benefit of this 1521 approach is that a CA may reply with a certificate even in the absence 1522 of a proof that the requester is the end entity which can use the 1523 relevant private key (note that the proof is not obtained until the 1524 PKIConfirm message is received by the CA). Thus the CA will not have to 1525 revoke that certificate in the event that something goes wrong with the 1526 proof of possession. 1528 3.3.5 Key update request content 1530 For key update requests the following syntax is used. Typically, 1531 SubjectPublicKeyInfo, KeyId, and Validity are the template fields which 1532 may be supplied for each key to be updated. 1534 KeyUpdReqContent ::= SEQUENCE { 1535 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 1536 fullCertTemplates [1] FullCertTemplates OPTIONAL 1537 } 1539 3.3.6 Key Update response content 1541 For key update responses the syntax used is identical to the 1542 initialization response. 1544 KeyUpdRepContent ::= InitRepContent 1546 3.3.7 Key Recovery Request content 1548 For key recovery requests the syntax used is identical to the 1549 initialization request InitReqContent. Typically, SubjectPublicKeyInfo 1550 and KeyId are the template fields which may be used to supply a 1551 signature public key for which a certificate is required (see Appendix B 1552 profiles for further information). 1554 KeyRecReqContent ::= InitReqContent 1556 3.3.8 Key recovery response content 1558 For key recovery responses the following syntax is used. For some 1559 status values (e.g., waiting) none of the optional fields will be 1560 present. 1562 KeyRecRepContent ::= SEQUENCE { 1563 status PKIStatusInfo, 1564 newSigCert [0] Certificate OPTIONAL, 1565 caCerts [1] SEQUENCE OF Certificate OPTIONAL, 1566 keyPairHist [2] SEQUENCE OF CertifiedKeyPair OPTIONAL 1567 } 1569 3.3.9 Revocation Request Content 1571 When requesting revocation of a certificate (or several certificates) 1572 the following data structure is used. The name of the requester is 1573 present in the PKIHeader structure. 1575 RevReqContent ::= SEQUENCE OF RevDetails 1577 RevDetails ::= SEQUENCE { 1578 certDetails CertTemplate, 1579 -- allows requester to specify as much as they can about 1580 -- the cert. for which revocation is requested 1581 -- (e.g. for cases in which serialNumber is not available) 1582 revocationReason ReasonFlags, 1583 -- from the DAM, so that CA knows which Dist. point to use 1584 badSinceDate GeneralizedTime OPTIONAL, 1585 -- indicates best knowledge of sender 1586 crlEntryDetails Extensions 1587 -- requested crlEntryExtensions 1588 } 1590 3.3.10 Revocation Response Content 1592 The response to the above message. If produced, this is sent to the 1593 requester of the revocation. (A separate revocation announcement message 1594 may be sent to the subject of the certificate for which revocation was 1595 requested.) 1597 RevRepContent ::= SEQUENCE { 1598 status PKIStatusInfo, 1599 revCerts [0] SEQUENCE OF CertId OPTIONAL, 1600 -- identifies the certs for which revocation was requested 1601 crls [1] SEQUENCE OF CertificateList OPTIONAL 1602 -- the resulting CRLs (there may be more than one) 1603 } 1605 3.3.11 Cross certification request content 1607 Cross certification requests use the same syntax as for normal 1608 certification requests with the restriction that the key pair must have 1609 been generated by the requesting CA and the private key must not be sent 1610 to the responding CA. 1612 CrossCertReqContent ::= CertReqContent 1614 3.3.12 Cross certification response content 1616 Cross certification responses use the same syntax as for normal 1617 certification responses with the restriction that no encrypted private 1618 key can be sent. 1620 CrossCertRepContent ::= CertRepContent 1622 3.3.13 CA Key Update Announcement content 1624 When a CA updates its own key pair the following data structure may be 1625 used to announce this event. 1627 CAKeyUpdAnnContent ::= SEQUENCE { 1628 oldWithNew Certificate, -- old pub signed with new priv 1629 newWithOld Certificate, -- new pub signed with old priv 1630 newWithNew Certificate -- new pub signed with new priv 1631 } 1633 3.3.14 Certificate Announcement 1635 This data structure may be used to announce the existence of 1636 certificates. 1638 Note that this structure (and the CertAnn message itself) is intended to 1639 be used for those cases (if any) where there is no pre-existing method 1640 for publication of certificates; it is not intended to be used where, 1641 for example, X.500 is the method for publication of certificates. 1643 CertAnnContent ::= Certificate 1645 3.3.15 Revocation Announcement 1647 When a CA has revoked, or is about to revoke, a particular certificate 1648 it may issue an announcement of this (possibly upcoming) event. 1650 RevAnnContent ::= SEQUENCE { 1651 status PKIStatus, 1652 certId CertId, 1653 willBeRevokedAt GeneralizedTime, 1654 badSinceDate GeneralizedTime, 1655 crlDetails Extensions OPTIONAL 1656 -- extra CRL details(e.g., crl number, reason, location, etc.) 1657 } 1659 A CA may use such an announcement to warn (or notify) a subject that its 1660 certificate is about to be (or has been) revoked. This would typically 1661 be used where the request for revocation did not come from the subject 1662 concerned. 1664 The willBeRevokedAt field contains the time at which a new entry will be 1665 added to the relevant CRLs. 1667 3.3.16 CRL Announcement 1669 When a CA issues a new CRL (or set of CRLs) the following data structure 1670 may be used to announce this event. 1672 CRLAnnContent ::= SEQUENCE OF CertificateList 1674 3.3.17 PKI Confirmation content 1676 This data structure is used in three-way protocols as the final 1677 PKIMessage. Its content is the same in all cases - actually there is no 1678 content since the PKIHeader carries all the required information. 1680 PKIConfirmContent ::= NULL 1682 3.3.18 PKI Information Request content 1684 InfoTypeAndValue ::= SEQUENCE { 1685 infoType OBJECT IDENTIFIER, 1686 infoValue ANY DEFINED BY infoType OPTIONAL 1687 } 1688 -- Example InfoTypeAndValue contents include, but are not limited to: 1689 -- { CAProtEncCert = { xx }, Certificate } 1690 -- { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 1691 -- { EncKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 1692 -- { PreferredSymmAlg = { xx }, AlgorithmIdentifier } 1693 -- { CAKeyUpdateInfo = { xx }, CAKeyUpdAnnContent } 1694 -- { CurrentCRL = { xx }, CertificateList } 1695 PKIInfoReqContent ::= SET OF InfoTypeAndValue 1696 -- The OPTIONAL infoValue parameter of InfoTypeAndValue is unused. 1697 -- The CA is free to ignore any contained OBJ. IDs that it does not 1698 -- recognize. 1699 -- The empty set indicates that the CA may send any/all information 1700 -- that it wishes. 1702 3.3.19 PKI Information Response content 1704 PKIInfoRepContent ::= SET OF InfoTypeAndValue 1705 -- The end entity is free to ignore any contained OBJ. IDs that it 1706 -- does not recognize. 1708 3.3.20 Error Message content 1710 ErrorMsgContent ::= SEQUENCE { 1711 pKIStatusInfo PKIStatusInfo, 1712 errorCode INTEGER OPTIONAL, 1713 -- implementation-specific error codes 1714 errorDetails PKIFreeText OPTIONAL 1715 -- implementation-specific error details 1716 } 1718 4. PKI Management functions 1720 The PKI management functions outlined in section 1 above are described 1721 in this section. 1723 This section is split into two, the first part dealing with functions 1724 which are "mandatory" in the sense that all end entity and CA/RA 1725 implementations must be able to provide functionality described via one 1726 of the transport mechanisms defined in section 5. This part is 1727 effectively the profile of the PKI management functionality which must 1728 be supported. 1730 The second part defines "additional" functions. 1732 Note that not all PKI management functions result in the creation of a 1733 PKI message. 1735 4.1 Mandatory Functions 1737 4.1.1 Root CA initialisation 1739 A newly created root CA must produce a "self-certificate" which is a 1740 Certificate structure with the profile defined for the "newWithNew" 1741 certificate issued following a root CA key update. 1743 In order to make the CA�s self certificate useful to end entities which 1744 do not acquire this information via "out-of-band" means, the CA must 1745 also produce a fingerprint for its public key. End entities which 1746 acquire this value securely via some "out-of-band" means can then verify 1747 the CA�s self-certificate and hence the other attributes contained 1748 therein. 1750 The data structure used to carry the fingerprint is the OOBCertHash. 1752 The root CA must also produce an initial revocation list. 1754 4.1.2 Root CA key update 1756 4.1.3 Subordinate CA initialisation 1758 From the perspective of PKI management protocols the initialisation of a 1759 subordinate CA is the same as the initialisation of an end entity. The 1760 only difference is that the subordinate CA must also produce an initial 1761 revocation list. 1763 4.1.4 CRL production 1765 Before issuing any certificates a newly established CA (which issues 1766 CRLs) must produce "empty" versions of each CRL which is to be 1767 periodically produced. 1769 4.1.5 PKI information request 1771 The above operations produce various data structures which are used in 1772 PKI management protocols. 1774 When a PKI entity wishes to acquire information about the current status 1775 of a CA it may send that CA a PKIInfoReq PKIMessage. The response will 1776 be a PKIInfoRep message. 1778 The CA must respond to the request with a response providing (at least) 1779 all of the information requested by the requester. If some of the 1780 information cannot be provided then an error message must be returned. 1782 The PKIInfoReq and PKIInfoRep messages are protected using a MAC based 1783 on shared secret information (i.e., PasswordBasedMAC) or any other 1784 authenticated means (if the end entity has an existing certificate). 1786 4.1.6 Cross certification 1788 The initiating CA is the CA which will become the subject of the cross- 1789 certificate, the responding CA will become the issuer of the cross- 1790 certificate. 1792 The initiating CA must be "up and running" before initiating the cross- 1793 certification operation. 1795 As with registration/certification there are a few possibilities here. 1797 4.1.6.1 One-way request-response scheme: 1799 The cross-certification scheme is essentially a one way operation; that 1800 is, when successful, this operation results in the creation of one new 1801 cross-certificate. If the requirement is that cross- certificates be 1802 created in "both directions" then each CA in turn must initiate a cross- 1803 certification operation (or use another scheme). 1805 This scheme is suitable where the two CAs in question can already verify 1806 each other�s signatures (they have some common points of trust) or where 1807 there is an out-of-band verification of the origin of the certification 1808 request. 1810 The followings steps occur: 1812 1.The initiating CA gathers the information required for the cross 1813 certification request; 1814 2.The initiating CA creates the cross-certification request message 1815 (CrossCertReq); 1816 3.The CrossCertReq message is transported to the responding CA; 1817 4.The responding CA processes the CrossCertReq -- this results in the 1818 creation of a cross-certification response (CrossCertRep) message; 1819 5.The CrossCertRep message is transported to the initiating CA; 1820 6.The initiating CA processes the CrossCertRep (depending on its content 1821 some looping may be required; that is, the initiating CA may have to 1822 await further responses or generate a new CrossCertReq for the 1823 responding CA); 1824 7.The initiating CA creates a PKIConfirm message and transports it to 1825 the responding CA. 1827 Notes: 1829 1.The CrossCertReq must contain a "complete" certification request, that 1830 is, all fields (including e.g. a BasicConstraints extension) must be 1831 specified by the initiating CA. 1832 2.The CrossCertRep message should contain the verification certificate 1833 of the responding CA - if present, the initiating CA must then verify 1834 this certificate (for example, via the "out-of-band" mechanism). 1836 4.1.7 End entity initialisation 1838 As with CAs, end entity�s must be initialised. Initialisation of end 1839 entities requires at least two steps: 1841 - acquisition of PKI information 1842 - out-of-band verification of one root-CA public key 1844 (other possible steps include the retrieval of trust condition 1845 information and/or out-of-band verification of other CA public keys). 1847 4.1.7.1 Acquisition of PKI information 1849 The information required is: 1851 - the current root-CA public key 1852 - (if the certifying CA is not a root-CA) the certification path from 1853 the root CA to the certifying CA together with appropriate revocation 1854 lists 1855 - the algorithms and algorithm parameters which the certifying CA 1856 supports for each relevant usage 1858 Additional information could be required (e.g. supported extensions 1859 or CA policy information) in order to produce a certification request 1860 which will be successful. However, for simplicity we do not mandate that 1861 the end entity acquires this information via the PKI messages. The end 1862 result is simply that some certification requests may fail (e.g., if the 1863 end entity wants to generate its own encryption key but the CA doesn�t 1864 allow that). 1866 The required information is acquired as follows (see Section 3.3.18): 1868 - the end entity sends a pKIInfoReq to the certifying CA requesting 1869 the information it requires; 1871 - the certifying CA responds with a pKIInfoRep message which contains 1872 the requested information. 1874 4.1.8 Certificate Update 1876 When a certificate is due to expire the relevant end entity may request 1877 that the CA update the certificate - that is, that the CA issue a new 1878 certificate which differs from the previous one only in terms of PKI 1879 attributes (serialNumber, validity, some extensions) and is otherwise 1880 identical. 1882 Two options must be catered for here, where the end entity initiates 1883 this operation, and where the CA initiates the operation and then 1884 creates a message informing the end entity of the existence of the new 1885 certificate. 1887 4.2 Additional Functions 1889 4.2.1 Cross certification 1891 4.2.1.1 Two-way request-response scheme: 1893 4.2.1.1.1 Overview of Exchange 1895 This cross certification exchange allows two CAs to simultaneously 1896 certify each other. This means that each CA will create a certificate 1897 that contains the CA verification key of the other CA. 1899 Cross certification is initiated at one CA known as the responder. The 1900 CA administrator for the responder identifies the CA it wants to cross 1901 certify and the responder CA equipment generates an authorization code. 1902 The responder CA administrator passes this authorization code by out-of- 1903 band means to the requester CA administrator. The requester CA 1904 administrator enters the authorization code at the requester CA in order 1905 to initiate the on-line exchange. 1907 The authorization code is used for authentication and integrity 1908 purposes. This is done by generating a symmetric key based on the 1909 authorization code and using the symmetric key for generating Message 1910 Authentication Codes (MACs) on all messages exchanged. 1912 Serial numbers and protocol version are used in the same manner as in 1913 the above CA-client exchanges. 1915 4.2.1.1.2 Detailed Description 1917 The requester CA initiates the exchange by generating a random number 1918 (requester random number). The requester CA then sends the responder CA 1919 the message CrossReq. The fields in this message are protected from 1920 modification with a MAC based on the authorization code. 1922 Upon receipt of the CrossReq message, the responder CA checks the 1923 protocol version, saves the requester random number, generates its own 1924 random number (responder random number) and validates the MAC. It then 1925 generates and archives a new requester certificate which contains the 1926 requester CA public key and is signed with the responder CA signature 1927 private key. The responder CA responds with the message CrossRep. The 1928 fields in this message are protected from modification with a MAC based 1929 on the authorization code. 1931 Upon receipt of the CrossRep message, the requester CA checks that its 1932 own system time is close to the responder CA system time, checks the 1933 received random numbers and validates the MAC. It then generates and 1934 archives a new responder certificate which contains the responder CA 1935 public key and is signed by the requester CA signature private key. The 1936 requester CA responds with the message PKIConfirm. The fields in this 1937 message are protected from modification with a MAC based on the 1938 authorization code. 1940 Upon receipt of the PKIConfirm message, the responder CA checks the 1941 random numbers, archives the responder certificate, and validates the 1942 MAC. It writes both the request and responder certificates to the 1943 Directory. It then responds with its own PKIConfirm message. The fields 1944 in this message are protected from modification with a MAC based on the 1945 authorization code. 1947 Upon receipt of the PKIConfirm message, the requester CA checks the 1948 random numbers and validates the MAC. The requester CA writes both the 1949 requester and responder certificates to the Directory. 1951 4.2.2 End entity initialisation 1953 As with CAs, end entities must be initialised. Initialisation of end 1954 entities requires two steps: 1956 - acquisition of PKI information 1957 - out-of-band verification of root-CA public key 1959 4.2.2.1 Acquisition of PKI information 1961 See previous section. 1963 4.2.2.2 Import of CA key fingerprint 1965 An end entity must securely possess the public key of its root CA. One 1966 method to achieve this is to provide the end entity with the CA�s self- 1967 certificate fingerprint via some secure "out-of-band" means. The end 1968 entity can then securely use the CA�s self-certificate. 1970 The data structure used is the OOBcertHash 1972 5. Transports 1974 The transport protocols specified below allow end entities, RAs and CAs 1975 to pass PKI messages between them. There is no requirement for specific 1976 security mechanisms to be applied at this level if the PKI messages are 1977 suitably protected (that is, if the optional PKIProtection parameter is 1978 used as specified for each message). 1980 5.1 File based protocol 1982 A file containing a PKI message must contain only the DER encoding of 1983 one PKI message, i.e. there must be no extraneous header or trailer 1984 information in the file. 1986 Such files can be used to transport PKI messages using e.g. FTP. 1988 5.2 Socket based Management Protocol 1990 The following simple socket based protocol is to be used for transport 1991 of PKI messages. This protocol is suitable for cases where an end entity 1992 (or an RA) initiates a transaction and can poll to pick up the results. 1994 If a transaction is initiated by a PKI entity (RA or CA) then an end 1995 entity must either supply a listener process or be supplied with a 1996 polling reference (see below) in order to allow it to pick up the PKI 1997 message from the PKI management component. 1999 The protocol basically assumes a listener process on an RA or CA which 2000 can accept PKI messages on a well-defined port (port number 829). 2001 Typically an initiator binds to this port and submits the initial PKI 2002 message for a given transaction ID. The responder replies with a PKI 2003 message and/or with a reference number to be used later when polling for 2004 the actual PKI message response. 2006 If a number of PKI response messages are to be produced for a given 2007 request (say if some part of the request is handled more quickly than 2008 another) then a new polling reference is also returned. 2010 When the final PKI response message has been picked up by the initiator 2011 then no new polling reference is supplied. 2013 The initiator of a transaction sends a "socket PKI message" to the 2014 recipient. The recipient responds with a similar message. 2016 A "socket PKI message" consists of: 2018 length (32-bits), flag (8-bits), value (defined below) 2020 The length field contains the number of octets of the remainder of the 2021 message (i.e., number of octets of "value" plus one). 2023 Message name flag value 2025 msgReq �00�H DER-encoded PKI message 2026 -- PKI message from initiator 2027 pollRep �01�H polling reference (32 bits), 2028 time-to-check-back (32 bits) 2029 -- poll response where no PKI message response ready; use polling 2030 -- reference value (and estimated time value) for later polling 2031 pollReq �02�H polling reference (32 bits) 2032 -- request for a PKI message response to initial message 2033 negPollRep �03�H �00�H 2034 -- no further polling responses (i.e., transaction complete) 2035 partialMsgRep �04�H next polling reference (32 bits), 2036 time-to-check-back (32 bits), 2037 DER-encoded PKI message 2038 -- partial response to initial message plus new polling reference 2039 -- (and estimated time value) to use to get next part of response 2040 finalMsgRep �05�H DER-encoded PKI message 2041 -- final (and possibly sole) response to initial message 2042 errorMsgRep �06�H human readable error message 2043 -- produced when an error is detected (e.g., a polling reference is 2044 -- received which doesn�t exist or is finished with) 2046 Where a PKIConfirm message is to be transported (always from the 2047 initiator to the responder) then a msgReq message is sent and a 2048 negPollRep is returned. 2050 The sequence of messages which can occur is then: 2052 a) end entity sends msgReq and receives one of pollRep, negPollRep, 2053 partialMsgRep or finalMsgRep in response. 2054 b) end entity sends pollReq message and receives one of negPollRep, 2055 partialMsgRep, finalMsgRep or ErrorMsgRep in response. 2057 The "time-to-check-back" parameter is a 32-bit integer, defined to be 2058 the number of seconds which have elapsed since midnight, January 1, 2059 1970, coordinated universal time. It provides an estimate of the time 2060 that the end entity should send its next pollReq. 2062 5.3 Management Protocol via E-mail 2064 This subsection specifies a means for conveying ASN.1-encoded messages 2065 for the protocol exchanges described in Section 4 via Internet mail. 2067 A simple MIME object is specified as follows. 2069 Content-Type: application/x-pkix3 2070 Content-Transfer-Encoding: base64 2072 <> 2074 This MIME object can be sent and received using common MIME processing 2075 engines and provides a simple Internet mail transport for PKIX-3 2076 messages. 2078 5.4 Management Protocol via HTTP 2080 This subsection specifies a means for conveying ASN.1-encoded messages 2081 for the protocol exchanges described in Section 4 via the HyperText 2082 Transfer Protocol. 2084 A simple MIME object is specified as follows. 2086 Content-Type: application/x-pkix3 2088 <> 2090 This MIME object can be sent and received using common HTTP processing 2091 engines over WWW links and provides a simple browser-server transport 2092 for PKIX-3 messages. 2094 SECURITY CONSIDERATIONS 2096 This entire memo is about security mechanisms. 2098 One cryptographic consideration is worth explicitly spelling out. In 2099 the protocols specified above, when an end entity is required to 2100 prove possession of a decryption key, it is effectively challenged 2101 to decrypt something (its own certificate). This scheme (and many 2102 others!) could be vulnerable to an attack if the possessor of the 2103 decryption key in question could be fooled into decrypting an 2104 arbitrary challenge and returning the cleartext to an attacker. 2105 Although in this specification a number of other failures in 2106 security are required in order for this attack to succeed, it is 2107 conceivable that some future services (e.g., notary, trusted time) 2108 could potentially be vulnerable to such attacks. For this reason we 2109 re-iterate the general rule that implementations should be very 2110 careful about decrypting arbitrary "ciphertext" and revealing 2111 recovered "plaintext" since such a practice can lead to serious 2112 security vulnerabilities. 2114 References 2116 [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of 2117 Applied Cryptography", CRC Press, 1997. 2119 [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards 2120 (PKCS)", RSA Data Security Inc., Redwood City, California, 2121 November 1993 Release. 2123 [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards 2124 (PKCS)", RSA Data Security Inc., Redwood City, California, 2125 November 1993 Release. 2127 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 2128 PKCS #11: Cryptographic token interface standard", RSA 2129 Data Security Inc., Redwood City, California, April 28, 2130 1995. 2132 [PKIX-2] S. Boeyen, R. Housley, T. Howes, M. Myers, P. Richard, 2133 "Internet Public Key Infrastructure Part 2: Operational 2134 Protocols", Internet Draft draft-ietf-pkix-ipki2opp-0x.txt 2135 (work in progress). 2137 [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 2138 Multiparts for MIME: Multipart/Signed and Multipart/ 2139 Encrypted", Internet Request for Comments 1847, October 2140 1995. 2142 Authors' Addresses 2144 Carlisle Adams 2145 Entrust Technologies 2146 750 Heron Road 2147 Ottawa, Ontario 2148 Canada K1V 1A7 2149 cadams@entrust.com 2151 Stephen Farrell 2152 Software and Systems Engineering Ltd. 2153 Fitzwilliam Court 2154 Leeson Close 2155 Dublin 2 2156 IRELAND 2157 stephen.farrell@sse.ie 2159 APPENDIX A: Reasons for the presence of RAs 2161 The reasons which justify the presence of an RA can be split into those 2162 which are due to technical factors and those which are organizational in 2163 nature. Technical reasons include the following. 2165 -If hardware tokens are in use, then not all end entities will have 2166 the equipment needed to initialize these; the RA equipment can include 2167 the necessary functionality (this may also be a matter of policy). 2169 -Some end entities may not have the capability to publish 2170 certificates; again, the RA may be suitably placed for this. 2172 -The RA will be able to issue signed revocation requests on behalf of 2173 end entities associated with it, whereas the end entity may not be able 2174 to do this (if the key pair is completely lost). 2176 Some of the organisational reasons which argue for the presence of an 2177 RA are the following. 2179 -It may be more cost effective to concentrate functionality in the RA 2180 equipment than to supply functionality to all end entities (especially 2181 if special token initialization equipment is to be used). 2183 -Establishing RAs within an organization can reduce the number of CAs 2184 required, which is sometimes desirable. 2186 -RAs may be better placed to identify people with their "electronic" 2187 names, especially if the CA is physically remote from the end entity. 2189 -For many applications there will already be in place some 2190 administrative structure so that candidates for the role of RA are easy 2191 to find (which may not be true of the CA). 2193 Appendix B. PKI management message profiles. 2195 This appendix contains detailed profiles for those PKIMessages which 2196 must be supported by conforming implementations. 2198 Profiles for the PKIMessages used in the following PKI management 2199 operations are provided: 2201 - root CA key update 2202 - information request/reponse 2203 - cross-certification (1-way) 2204 - initial registration and certification 2205 - centralised scheme 2206 - basic authenticated scheme 2208 <> 2211 - certificate update 2212 - end entity initiated 2213 - PKI initiated 2214 - key update 2215 - revocation request 2216 - certificate publication 2217 - CRL publication 2219 B1. General Rules for interpretation of these profiles. 2221 1. Where OPTIONAL or DEFAULT fields are not mentioned in individual 2222 profiles, they should be absent from the relevant message. 2223 Mandatory fields are not mentioned if they have an obvious value 2224 (e.g., pvno). 2225 2. Where structures occur in more than one message, they are 2226 separately profiled as appropriate. 2227 3. The algorithmIdentifiers from PKIMessage structures are profiled 2228 separately. 2229 4. A "special" X.500 DN is called the "NULL-DN"; this means a DN 2230 containing a zero-length SEQUENCE OF rdns (it�s DER encoding is 2231 then �3000�H). 2232 5. Where a GeneralName is required for a field but no suitable 2233 value is available (e.g. an end entity produces a request before 2234 knowing its name) then the GeneralName is to be an X.500 NULL-DN 2235 (i.e., the Name field of the CHOICE is to contain a NULL-DN). 2236 This special value can be called a "NULL-GeneralName". 2237 6. Where a profile omits to specify the value for a GeneralName 2238 then the NULL-GeneralName value is to be present in the relevant 2239 PKIMessage field. This occurs with the sender field of the 2240 PKIHeader for some messages. 2241 7. Where any ambiguity arises due to naming of fields, the profile 2242 names these using a "dot" notation (e.g., "certTemplate.subject" 2243 means the subject field within a field called certTemplate). 2245 8. Where a "SEQUENCE OF types" is part of a message, a zero-based 2246 array notation is used to describe fields within the SEQUENCE OF 2247 (e.g., FullCertTemplates[0].certTemplate.subject refers to a 2248 subfield of the first FullCertTemplate contained in a request 2249 message). 2250 9. All PKI message exchanges (other than the centralised initial 2251 registration/certification scheme) require a PKIConfirm message 2252 to be sent by the initiating entity. This message is not 2253 included in many of the profiles given below since its body is 2254 NULL and its header contents are clear from the context. Any 2255 authenticated means can be used for the protectionAlg (e.g., 2256 password-based MAC, if shared secret information is known, or 2257 signature). 2259 B2. Algorithm Use Profile 2261 The following table contains definitions of algorithm uses within PKI 2262 management protocols. 2264 The columns in the table are: 2266 Name: an identifier used for message profiles 2267 Use: description of where and for what the algorithm is used 2268 Mandatory: an AlgorithmIdentifier which must be supported by 2269 conforming implementations 2270 Others: alternatives to the mandatory AlgorithmIdentifier 2272 Name Use Mandatory Others 2274 CA_FP_ALG Calculation of root CA SHA-1 + ASCII MD5,... 2275 public key fingerprint mapping 2276 MSG_SIG_ALG Protection of PKI RSA/SHA-1 RSA/MD5... 2277 messages using signature 2278 MSG_MAC_ALG protection of PKI HMAC X9.9... 2279 messages using MACing 2280 SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5,CAST... 2281 an end entity�s private EDE, CBC mode) 2282 key where symmetric 2283 key is distributed 2284 out-of-band 2285 PROT_ENC_ALG asymmetric algorithm RSA D-H 2286 used for encryption of 2287 (symmetric keys for 2288 encryption of) private 2289 keys transported in 2290 PKIMessages 2291 PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5,CAST... 2292 algorithm used for EDE, CBC mode) 2293 encryption of private 2294 key bits (a key of this 2295 type is encrypted using 2296 PROT_ENC_ALG) 2298 B3. "Self-signed" certificates 2300 Profile of how a Certificate structure may be "self-signed". These 2301 strucures are used for distribution of "root" CA public keys. This can 2302 occur in one of three ways (see section 2.4 above for a description of 2303 the use of these structures): 2305 Type Function 2307 newWithNew a true "self-signed" certificate; the contained public 2308 key must be usable to verify the signature (though this 2309 provides only integrity and no authentication whatsoever) 2310 oldWithNew previous root CA public key signed with new private key 2311 newWithOld new root CA public key signed with previous private key 2313 <> 2317 B4. Proof of Possession Profile 2319 "popo" fields for use when proving possession of a private signing key 2320 which corresponds to a public verification key for which a certificate 2321 has been requested. 2323 Field Value Comment 2325 alg MSG_SIG_ALG only signature protection is 2326 allowed for this proof 2327 signature present bits calculated using MSG_SIG_ALG 2329 <> 2334 Not every CA/RA will require Proof-of-Possession (of signing key or of 2335 decryption key) in the certification request protocol. Although this 2336 specification STRONGLY RECOMMENDS that POP be verified by the CA/RA 2337 (because created certificates become less meaningful in the PKI 2338 otherwise; see Section 2.3), this may ultimately be a policy issue which 2339 is made explicit for any given CA in its publicized Policy OID and 2340 Certification Practice Statement. All end entities must be prepared to 2341 provide POP (i.e., these components of the PKIX-3 protocol must be 2342 supported). 2344 CAs/RAs may therefore conceptually be divided into two classes (those 2345 which require POP as a condition of certificate creation and those which 2346 do not). End entities may choose to make verification decisions (as one 2347 step in certificate chain processing) at least partly by considering 2348 which classes of CAs (as indicated, for example, by their policy OIDs or 2349 Certification Practice Statements) have created the certificates 2350 included in the chain. 2352 B5. Root CA Key upate 2354 A root CA updates its key pair. It then produces a CA key update 2355 announcement message which can be made available (via one of the 2356 transport mechanisms) to the relevant end entities. 2358 ckuann message: 2360 Field Value Comment 2362 sender CA name responding CA name 2363 body ckuann(CAKeyUpdAnnContent) 2364 oldWithNew present see section B.0 above 2365 newWithOld present see section B.0 above 2366 newWithNew present see section B.0 above 2367 extraCerts optionally present can be used to "publish" 2368 certificates (e.g., 2369 certificates signed using 2370 the new private key) 2372 B6. PKI Information request/response 2374 End entity sends information request to PKI requesting details which 2375 will be required for later PKI managment operations. RA/CA responds with 2376 information response. If an RA generates the response then it will 2377 simply forward the equivalent message which it previously received from 2378 the CA, with the possible addition of the certificates to the extracerts 2379 fields of the PKIMessage. 2381 Message Flows: 2383 Step# End entity PKI 2385 1 format infor 2386 2 -> infor -> 2387 3 handle infor 2388 4 produce infop 2389 5 <- infop <- 2390 6 handle infop 2391 infor: 2393 Field Value 2395 recipient CA name 2396 -- the name of the CA as contained in issuerAltName extensions or 2397 -- issuer fields within certificates 2398 protectionAlg MSG_MAC_ALG or MSG_SIG_ALG 2399 -- any authenticated protection alg. 2400 SenderKID present if required 2401 -- must be present if required for verification of message protection 2402 freeText any valid value 2403 body infor (PKIInfoReqContent) 2404 PKIInfoReqContent empty SET 2405 -- all relevant information requested 2406 protection present 2407 -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG 2409 infop: 2411 Field Value 2413 sender CA name 2414 -- name of the CA which produced the message 2415 protectionAlg MSG_MAC_ALG or MSG_SIG_ALG 2416 -- any authenticated protection alg. 2417 senderKID present if required 2418 -- must be present if required for verification of message protection 2419 body infop (PKIInfoRepContent) 2420 CAProtEncCert present (object identifier one 2421 of PROT_ENC_ALG), with relevant 2422 value 2423 -- to be used if end entity needs to encrypt information for the CA 2424 -- (e.g., private key for recovery purposes) 2425 SignKeyPairTypes present, with relevant value 2426 -- the set of signature algorithm identifiers which this CA will 2427 -- certify for subject public keys 2428 EncKeypairTypes present, with relevant value 2429 -- the set of encryption/key agreement algorithm identifiers which 2430 -- this CA will certify for subject public keys 2431 PreferredSymmAlg present (object identifier one 2432 of PROT_SYM_ALG) , with relevant 2433 value 2434 -- the symmetric algorithm which this CA expects to be used in later 2435 -- PKI messages (for encryption) 2436 CAKeyUpdateInfo optionally present, with 2437 relevant value 2438 -- the CA may provide information about a relevant root CA key pair 2439 -- using this field (note that this does not imply that the responding 2440 -- CA is the root CA in question) 2442 CurrentCRL present, with relevant value 2443 -- the CA may provide a copy of a complete CRL (i.e. fullest possible 2444 -- one) 2445 protection present 2446 -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG 2447 extraCerts optionally present 2448 -- can be used to send some certificates to the end entity. An RA may 2449 -- add its certificate here. 2451 B7. Cross certification (1-way) 2453 Creation of a single cross-certificate (i.e., not two at once). The 2454 requesting CA is responsible for publication of the cross-certificate 2455 created by the responding CA. 2457 Preconditions: 2459 1. Responding CA can verify the origin of the request (possibly 2460 requiring out-of-band means) before processing the request. 2461 2. Requesting CA can authenticate the authenticity of the origin of the 2462 response (possibly requiring out-of-band means) before processing the 2463 response 2465 Message Flows: 2467 Step# Requesting CA Responding CA 2468 1 format ccr 2469 2 -> ccr -> 2470 3 handle ccr 2471 4 produce ccp 2472 5 <- ccp <- 2473 6 handle ccp 2475 ccr: 2476 Field Value 2478 sender Requesting CA name 2479 -- the name of the CA who produced the message 2480 recipient Responding CA name 2481 -- the name of the CA who is being asked to produce a certificate 2482 messageTime time of production of message 2483 -- current time at requesting CA 2484 protectionAlg MSG_SIG_ALG 2485 -- only signature protection is allowed for this request 2486 senderKID present if required 2487 -- must be present if required for verification of message protection 2488 transactionID present 2489 -- implementation-specific value, meaningful to requesting CA. 2490 -- [If already in use at responding CA then a rejection message 2491 -- to be produced by responding CA] 2493 senderNonce present 2494 -- 128 (pseudo-)random bits 2495 freeText any valid value 2496 body ccr (CrossCertReqContent) 2497 only one FullCertTemplate 2498 allowed 2499 -- if multiple cross certificates are required they must be packaged 2500 -- in separate PKIMessages 2501 certTemplate present 2502 -- details below 2503 version v1 or v3 2504 -- <> 2505 signingAlg present 2506 -- the requesting CA must know in advance with which algorithm it 2507 -- wishes the certificate to be signed 2509 subject present 2510 -- may be NULL-DN only if subjectAltNames extension value proposed 2511 validity present 2512 -- must be completely specified (i.e., both fields present) 2513 issuer present 2514 -- may be NULL-DN only if issuerAltNames extension value proposed 2515 publicKey present 2516 -- the key to be certified which must be for a signing algorithm 2517 extensions optionally present 2518 -- a requesting CA must propose values for all extensions which it 2519 -- requires to be in the cross-certificate 2520 popoSigningKey present 2521 -- see "Proof of possession profile" (section B.4) 2522 protection present 2523 -- bits calculated using MSG_SIG_ALG 2524 extraCerts optionally present 2525 -- can contain certificates usable to verify the protection on 2526 -- this message 2528 ccp: 2529 Field Value 2531 sender Responding CA name 2532 -- the name of the CA who produced the message 2533 recipient Requesting CA name 2534 -- the name of the CA who asked for production of a certificate 2535 messageTime time of production of message 2536 -- current time at responding CA 2537 protectionAlg MSG_SIG_ALG 2538 -- only signature protection is allowed for this message 2539 senderKID present if required 2540 -- must be present if required for verification of message 2541 -- protection 2542 recipKID present if required 2543 transactionID present 2544 -- value from corresponding ccr message 2545 senderNonce present 2546 -- 128 (pseudo-)random bits 2547 recipNonce present 2548 -- senderNonce from corresponding ccr message 2549 freeText any valid value 2550 body ccp (CrossCertRepContent) 2551 only one CertResponse allowed 2552 -- if multiple cross certificates are required they must be packaged 2553 -- in separate PKIMessages 2554 response present 2555 status present 2556 PKIStatusInfo.status present 2557 -- if PKIStatusInfo.status is one of: 2558 -- granted, or 2559 -- grantedWithMods, 2560 -- then certifiedKeyPair to be present and failInfo to be absent 2561 failInfo present depending on 2562 PKIStatusInfo.status 2563 -- if PKIStatusInfo.status is: 2564 -- rejection 2565 -- then certifiedKeyPair to be absent and failInfo to be present 2566 -- and contain appropriate bit settings 2568 certifiedKeyPair present depending on 2569 PKIStatusInfo.status 2570 certificate present depending on 2571 certifiedKeyPair 2572 -- content of actual certificate must be examined by requesting CA 2573 -- before publication 2574 protection present 2575 -- bits calculated using MSG_SIG_ALG 2576 extraCerts optionally present 2577 -- can contain certificates usable to verify the protection on 2578 -- this message 2580 B8. Initial registration / certification 2582 B8.1 Centralised scheme 2584 In this scheme the CA effectively issues a personal security environment 2585 (PSE) directly to an end entity using a PKIMessage to transport the 2586 resulting certificate, private key, etc. 2588 This profile only allows one certificate and private key to be contained 2589 within the PKIMessage. 2591 Preconditions: 2593 1. The end entity possesses the relevant root CA public key before 2594 processing the PKIMessage. 2595 2. The end entity is supplied with a symmetric key for decryption of its 2596 private key before processing the PKIMessage. 2598 cp: 2599 Field Value 2601 sender CA name 2602 -- the name of the CA who produced the message 2603 recipient end entity name 2604 -- the name of the end entity who is the subject of the certificate 2605 -- (possibly NULL-DN) 2606 protectionAlg MSG_SIG_ALG 2607 -- only signature protection is allowed for this message 2608 senderKID present if required 2609 -- must be present if required for verification of message 2610 -- protection 2611 senderNonce present 2612 -- 128 (pseudo-)random bits 2613 freeText any valid value 2614 body cp (CertRepContent) 2615 only one CertResponse allowed 2616 -- if multiple certificates are required they must be packaged in 2617 -- separate PKIMessages 2618 response present 2619 status present 2620 PKIStatusInfo.status "granted" 2621 -- no other values allowed (CA must only produce a message if a 2622 -- certificate has been produced) 2623 certifiedKeyPair present 2624 certifcate present 2625 -- according to pkix-1 profile 2627 privateKey present 2628 -- see below 2629 encValue present 2630 -- bits of private key encrypted (cleartext bits must be according 2631 -- to PKCS #1 spec.) 2632 symmAlg present, SYM_PENC_ALG 2633 -- algo. to use to decipher encValue using symmetric key distributed 2634 -- out-of-band 2635 protection present 2636 -- bits calculated using MSG_SIG_ALG 2637 extraCerts optionally present 2638 -- can contain certificates usable to verify the protection on 2639 -- this message 2641 B8.2 Basic authenticated scheme 2643 The end entity requests a certificate from a CA. When the CA responds 2644 with a message containing a certificate the end entity replies with a 2645 confirmation. All messages are authenticated. 2647 This scheme allows the end entity to request certification of a locally- 2648 generated public key (typically a signature key). The end entity may 2649 also choose to request the centralised generation and certification of 2650 another key pair (typically an encryption key pair). 2652 Certification may only be requested for one locally generated public key 2653 (for more, use separate PKIMessages). 2655 The end entity must support proof-of-possession of the private key 2656 associated with the locally-generated public key. 2658 Preconditions: 2660 1. The end entity can authenticate the CA�s signature based on out-of- 2661 band means 2662 2. The end entity and the CA share a symmetric MACing key 2664 Message flow: 2666 Step# End entity PKI 2667 1 format ir 2668 2 -> ir -> 2669 3 handle ir 2670 4 produce ip 2671 5 <- ip <- 2672 6 handle ip 2673 7 format confirm 2674 8 -> conf -> 2675 9 handle conf 2677 For this profile, we mandate that the end entity must include all (i.e. 2678 one or two) fullCertTemplates in a single PKIMessage and that the PKI 2679 (CA) must produce a single response PKIMessage which contains the 2680 complete response (i.e., including the optional second key pair, if it 2681 was requested). For simplicity, we also mandate that this message be the 2682 final one (i.e. no use of "waiting" status value). 2684 ir: 2685 Field Value 2687 recipient CA name 2688 -- the name of the CA who is being asked to produce a certificate 2689 protectionAlg MSG_MAC_ALG 2690 -- only MAC protection is allowed for this request, based on 2691 -- initial authentication key 2693 senderKID referenceNum 2694 -- the reference number which the CA has previously issued to 2695 -- the end entity (together with the MACing key) 2696 transactionID present 2697 -- implementation-specific value, meaningful to end entity. 2698 -- [If already in use at the CA then a rejection message to be 2699 -- produced by the CA] 2700 senderNonce present 2701 -- 128 (pseudo-)random bits 2702 freeText any valid value 2703 body ir (InitReqContent) 2704 only one or two FullCertTemplates 2705 are allowed 2706 -- if more certificates are required requests must be packaged in 2707 -- separate PKIMessages 2708 protocolEncKey optionally present. 2709 [If present, object identifier 2710 must be PROT_ENC_ALG] 2711 -- if supplied, this short-term asymmetric encryption key (generated 2712 -- by the end entity) will be used by the CA to encrypt (symmetric 2713 -- keys used to encrypt) a private key generated by the CA on behalf 2714 -- of the end entity 2715 fullCertTemplates one or two present 2716 -- see below for details, note: fct[0] means the first (which must 2717 -- be present), fct[1] means the second (which is optional, and used 2718 -- to ask for a centrally-generated key) 2719 fct[0]. fixed value of zero 2720 certReqId 2721 -- this is the index of the template within the message 2722 fct[0]. present 2723 certTemplate 2724 -- must include subject public key value, otherwise unconstrained 2725 fct[0]. optionally present if public key 2726 popoSigningKey from fct[0].certTemplate is a 2727 signing key 2728 -- proof of possession may be required in this exchange (see section 2729 -- B.4 for details) 2730 fct[0]. optionally present 2731 archiveOptions 2732 -- the end entity may request that the locally-generated private key 2733 -- be archived 2734 fct[0]. optionally present 2735 publicationInfo 2736 -- the end entity may ask for publication of resulting cert. 2737 fct[1]. fixed value of one 2738 certReqId 2739 -- the index of the template within the message 2740 fct[1]. present if protocolEncKey is 2741 certTemplate present 2742 -- must not include actual public key bits, otherwise unconstrained 2743 -- (e.g., the names need not be the same as in fct[0]) 2745 fct[1]. optionally present 2746 archiveOptions 2747 fct[1]. 2748 publicationInfo optionally present 2749 protection present 2750 -- bits calculated using MSG_MAC_ALG 2752 ip: 2753 Field Value 2755 sender CA name 2756 -- the name of the CA who produced the message 2757 messageTime present 2758 -- time at which CA produced message 2759 protectionAlg MSG_MAC_ALG 2760 -- only MAC protection is allowed for this response 2761 recipKID referenceNum 2762 -- the reference number which the CA has previously issued to the 2763 -- end entity (together with the MACing key) 2764 transactionID present 2765 -- value from corresponding ir message 2766 senderNonce present 2767 -- 128 (pseudo-)random bits 2768 recipNonce present 2769 -- value from senderNonce in corresponding ir message 2770 freeText any valid value 2771 body ir (CertRepContent) 2772 contains exactly one response 2773 for each request 2774 -- The PKI (CA) responds to either one or two requests as appropriate. 2775 -- crc[0] denotes the first (always present); crc[1] denotes the 2776 -- second (only present if the ir message contained two requests). 2777 crc[0]. fixed value of zero 2778 certReqId 2779 -- must contain the response to the first request in the corresponding 2780 -- ir message 2781 crc[0].status. present, positive values allowed: 2782 status "granted", "grantedWithMods" 2783 negative values allowed: 2784 "rejection" 2785 crc[0].status. present if and only if 2786 failInfo crc[0].status.status is "rejection" 2787 crc[0]. present if and only if 2788 certifiedKeyPair crc[0].status.status is 2789 "granted" or "grantedWithMods" 2790 certificate present unless end entity�s public 2791 key is an encryption key and POP 2792 is required by CA/RA 2793 encryptedCert present if and only if end entity�s 2794 public key is an encryption key 2795 and POP is required by CA/RA 2797 publicationInfo optionally present 2798 -- indicates where certificate has been published (present at 2799 -- discretion of CA) 2800 crc[1]. fixed value of one 2801 certReqId 2802 -- must contain the response to the second request in the 2803 -- corresponding ir message 2805 crc[1].status. present, positive values allowed: 2806 status "granted", "grantedWithMods" 2807 negative values allowed: 2808 "rejection" 2809 crc[1].status. present if and only if 2810 failInfo crc[0].status.status is "rejection" 2811 crc[1]. present if and only if 2812 certifiedKeyPair crc[0].status.status is "granted" 2813 or "grantedWithMods" 2814 certificate present 2815 privateKey present 2816 publicationInfo optionally present 2817 -- indicates where certificate has been published (present at 2818 -- discretion of CA) 2819 protection present 2820 -- bits calculated using MSG_MAC_ALG 2821 extraCerts optionally present 2822 -- the CA may provide additional certificates to the end entity 2824 conf: 2825 Field Value 2827 recipient CA name 2828 -- the name of the CA who was asked to produce a certificate 2829 transactionID present 2830 -- value from corresponding ir and ip messages 2831 senderNonce present 2832 -- value from recipNonce in corresponding ir message 2833 recipNonce present 2834 -- value from senderNonce in corresponding ip message 2835 protectionAlg MSG_MAC_ALG 2836 -- only MAC protection is allowed for this request. The MAC is 2837 -- based on the initial authentication key if only a signing key 2838 -- pair has been sent in ir for certification or if POP is not 2839 -- required by CA/RA. Otherwise, the MAC is based on a key derived 2840 -- from the symmetric key used to decrypt the returned encryptedCert. 2841 senderKID referenceNum 2842 -- the reference number which the CA has previously issued to the 2843 -- end entity (together with the MACing key) 2844 body conf (PKIConfirmContent) 2845 -- this is an ASN.1 NULL 2846 protection present 2847 -- bits calculated using MSG_MAC_ALG 2849 Appendix C: "Compilable" ASN.1 Module 2851 PKIMessage ::= SEQUENCE { 2852 header PKIHeader, 2853 body PKIBody, 2854 protection [0] PKIProtection OPTIONAL, 2855 extraCerts [1] SEQUENCE OF Certificate OPTIONAL 2856 } 2858 PKIHeader ::= SEQUENCE { 2859 pvno INTEGER { ietf-version1 (0) }, 2860 sender GeneralName, 2861 -- identifies the sender 2862 recipient GeneralName, 2863 -- identifies the intended recipient 2864 messageTime [0] GeneralizedTime OPTIONAL, 2865 -- time of production of this message (used when sender 2866 -- believes that the transport will be "suitable"; i.e., 2867 -- that the time will still be meaningful upon receipt) 2868 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 2869 -- algorithm used for calculation of protection bits 2870 senderKID [2] KeyIdentifier OPTIONAL, 2871 recipKID [3] KeyIdentifier OPTIONAL, 2872 -- to identify specific keys used for protection 2873 transactionID [4] OCTET STRING OPTIONAL, 2874 -- identifies the transaction, i.e. this will be the same in 2875 -- corresponding request, response and confirmation messages 2876 senderNonce [5] OCTET STRING OPTIONAL, 2877 recipNonce [6] OCTET STRING OPTIONAL, 2878 -- nonces used to provide replay protection, senderNonce 2879 -- is inserted by the creator of this message; recipNonce 2880 -- is a nonce previously inserted in a related message by 2881 -- the intended recipient of this message 2882 freeText [7] PKIFreeText OPTIONAL 2883 -- this may be used to indicate context-specific 2884 -- instructions (this field is intended for human 2885 -- consumption) 2886 } 2888 PKIFreeText ::= CHOICE { 2889 iA5String [0] IA5String, 2890 bMPString [1] BMPString 2891 } -- note that the text included here would ideally be in the 2892 -- preferred language of the recipient 2894 PKIBody ::= CHOICE { -- message-specific body elements 2895 ir [0] InitReqContent, 2896 ip [1] InitRepContent, 2897 cr [2] CertReqContent, 2898 cp [3] CertRepContent, 2899 p10cr [4] PKCS10CertReqContent, -- imported from [PKCS10] 2900 popdecc [5] POPODecKeyChallContent, 2901 popdecr [6] POPODecKeyRespContent, 2902 kur [7] KeyUpdReqContent, 2903 kup [8] KeyUpdRepContent, 2904 krr [9] KeyRecReqContent, 2905 krp [10] KeyRecRepContent, 2906 rr [11] RevReqContent, 2907 rp [12] RevRepContent, 2908 ccr [13] CrossCertReqContent, 2909 ccp [14] CrossCertRepContent, 2910 ckuann [15] CAKeyUpdAnnContent, 2911 cann [16] CertAnnContent, 2912 rann [17] RevAnnContent, 2913 crlann [18] CRLAnnContent, 2914 conf [19] PKIConfirmContent, 2915 nested [20] NestedMessageContent, 2916 infor [21] PKIInfoReqContent, 2917 infop [22] PKIInfoRepContent, 2918 error [23] ErrorMsgContent 2919 } 2921 PKIProtection ::= BIT STRING 2923 ProtectedPart ::= SEQUENCE { 2924 header PKIHeader, 2925 body PKIBody 2926 } 2928 PasswordBasedMac ::= OBJECT IDENTIFIER 2930 PBMParameter ::= SEQUENCE { 2931 salt OCTET STRING, 2932 owf AlgorithmIdentifier, 2933 -- AlgId for a One-Way Function (SHA-1 recommended) 2934 iterationCount INTEGER, 2935 -- number of times the OWF is applied 2936 mac AlgorithmIdentifier 2937 -- the MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11]) 2938 } 2940 DHBasedMac ::= OBJECT IDENTIFIER 2942 DHBMParameter ::= SEQUENCE { 2943 owf AlgorithmIdentifier, 2944 -- AlgId for a One-Way Function (SHA-1 recommended) 2945 mac AlgorithmIdentifier 2946 -- the MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11]) 2947 } 2948 NestedMessageContent ::= ANY 2949 -- This will be a PKIMessage 2951 CertTemplate ::= SEQUENCE { 2952 version [0] Version OPTIONAL, 2953 -- used to ask for a particular syntax version 2954 serial [1] INTEGER OPTIONAL, 2955 -- used to ask for a particular serial number 2956 signingAlg [2] AlgorithmIdentifier OPTIONAL, 2957 -- used to ask the CA to use this alg. for signing the cert 2958 subject [3] Name OPTIONAL, 2959 validity [4] OptionalValidity OPTIONAL, 2960 issuer [5] Name OPTIONAL, 2961 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 2962 issuerUID [7] UniqueIdentifier OPTIONAL, 2963 subjectUID [8] UniqueIdentifier OPTIONAL, 2964 extensions [9] Extensions OPTIONAL 2965 -- the extensions which the requester would like in the cert. 2966 } 2968 OptionalValidity ::= SEQUENCE { 2969 notBefore [0] UTCTime OPTIONAL, 2970 notAfter [1] UTCTime OPTIONAL 2971 } 2973 EncryptedValue ::= SEQUENCE { 2974 encValue BIT STRING, 2975 -- the encrypted value itself 2976 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 2977 -- the intended algorithm for which the value will be used 2978 symmAlg [1] AlgorithmIdentifier OPTIONAL, 2979 -- the symmetric algorithm used to encrypt the value 2980 encSymmKey [2] BIT STRING OPTIONAL, 2981 -- the (encrypted) symmetric key used to encrypt the value 2982 keyAlg [3] AlgorithmIdentifier OPTIONAL 2983 -- algorithm used to encrypt the symmetric key 2984 } 2985 PKIStatus ::= INTEGER { 2986 granted (0), 2987 -- you got exactly what you asked for 2988 grantedWithMods (1), 2989 -- you got something like what you asked for; the 2990 -- requester is responsible for ascertaining the differences 2991 rejection (2), 2992 -- you don't get it, more information elsewhere in the message 2993 waiting (3), 2994 -- the request body part has not yet been processed, 2995 -- expect to hear more later 2996 revocationWarning (4), 2997 -- this message contains a warning that a revocation is 2998 -- imminent 2999 revocationNotification (5), 3000 -- notification that a revocation has occurred 3001 keyUpdateWarning (6) 3002 -- update already done for the oldCertId specified in 3003 -- FullCertTemplate 3004 } 3006 PKIFailureInfo ::= BIT STRING { 3007 -- since we can fail in more than one way! 3008 -- More codes may be added in the future if/when required. 3009 badAlg (0), 3010 -- unrecognized or unsupported Algorithm Identifier 3011 badMessageCheck (1), 3012 -- integrity check failed (e.g., signature did not verify) 3013 badRequest (2), 3014 -- transaction not permitted or supported 3015 badTime (3), 3016 -- messageTime was not sufficiently close to the system time, 3017 -- as defined by local policy 3018 badCertId (4), 3019 -- no certificate could be found matching the provided criteria 3020 badDataFormat (5), 3021 -- the data submitted has the wrong format 3022 wrongAuthority (6), 3023 -- the authority indicated in the request is different from the 3024 -- one creating the response token 3025 incorrectData (7), 3026 -- the requester's data is incorrect (for notary services) 3027 missingTimeStamp (8) 3028 -- when the timestamp is missing but should be there (by policy) 3029 } 3031 PKIStatusInfo ::= SEQUENCE { 3032 status PKIStatus, 3033 statusString PKIFreeText OPTIONAL, 3034 failInfo PKIFailureInfo OPTIONAL 3035 } 3036 CertId ::= SEQUENCE { 3037 issuer GeneralName, 3038 serialNumber INTEGER 3039 } 3041 OOBCert ::= Certificate 3043 OOBCertHash ::= SEQUENCE { 3044 hashAlg [0] AlgorithmIdentifier OPTIONAL, 3045 certId [1] CertId OPTIONAL, 3046 hashVal BIT STRING 3047 -- hashVal is calculated over DER encoding of the 3048 -- subjectPublicKey field of the corresponding cert. 3049 } 3051 PKIArchiveOptions ::= CHOICE { 3052 encryptedPrivKey [0] EncryptedValue, 3053 -- the actual value of the private key 3054 keyGenParameters [1] KeyGenParameters, 3055 -- parameters which allow the private key to be re-generated 3056 archiveRemGenPrivKey [2] BOOLEAN 3057 -- set to TRUE if sender wishes receiver to archive the private 3058 -- key of a key pair which the receiver generates in response to 3059 -- this request; set to FALSE if no archival is desired. 3060 } 3062 KeyGenParameters ::= OCTET STRING 3063 -- an alternative to sending the key is to send the information 3064 -- about how to re-generate the key (e.g. for many RSA 3065 -- implementations one could send the first random number tested 3066 -- for primality). 3067 -- The actual syntax for this parameter may be defined in a 3068 -- subsequent version of this document or in another standard. 3070 PKIPublicationInfo ::= SEQUENCE { 3071 action INTEGER { 3072 dontPublish (0), 3073 pleasePublish (1) 3074 }, 3075 pubInfos SEQUENCE OF SinglePubInfo OPTIONAL 3076 -- pubInfos must not be present if action is "dontPublish" 3077 -- (if action is "pleasePublish" and pubInfos is omitted, 3078 -- "dontCare" is assumed) 3079 } 3081 SinglePubInfo ::= SEQUENCE { 3082 pubMethod INTEGER { 3083 dontCare (0), 3084 x500 (1), 3085 web (2) 3086 }, 3087 pubLocation GeneralName OPTIONAL 3088 } 3089 FullCertTemplates ::= SEQUENCE OF FullCertTemplate 3091 FullCertTemplate ::= SEQUENCE { 3092 certReqId INTEGER, 3093 -- to match this request with corresponding response 3094 -- (note: must be unique over all FullCertReqs in this message) 3095 certTemplate CertTemplate, 3096 popoSigningKey [0] POPOSigningKey OPTIONAL, 3097 archiveOptions [1] PKIArchiveOptions OPTIONAL, 3098 publicationInfo [2] PKIPublicationInfo OPTIONAL, 3099 oldCertId [3] CertId OPTIONAL 3100 -- id. of cert. which is being updated by this one 3101 } 3103 POPOSigningKey ::= SEQUENCE { 3104 poposkInput POPOSKInput, 3105 alg AlgorithmIdentifier, 3106 signature BIT STRING 3107 -- the signature (using "alg") on the DER-encoded 3108 -- value of poposkInput 3109 } 3111 POPOSKInput ::= CHOICE { 3112 popoSigningKeyInput [0] POPOSigningKeyInput, 3113 certificationRequestInfo CertificationRequestInfo 3114 -- imported from [PKCS10] (note that if this choice is used, 3115 -- POPOSigningKey is simply a standard PKCS #10 request; this 3116 -- allows a bare PKCS #10 request to be augmented with other 3117 -- desired information in the FullCertTemplate before being 3118 -- sent to the CA/RA) 3119 } 3121 POPOSigningKeyInput ::= SEQUENCE { 3122 authInfo CHOICE { 3123 sender [0] GeneralName, 3124 -- from PKIHeader (used only if an authenticated identity 3125 -- has been established for the sender (e.g., a DN from a 3126 -- previously-issued and currently-valid certificate) 3127 publicKeyMAC [1] BIT STRING 3128 -- used if no authenticated GeneralName currently exists for 3129 -- the sender; publicKeyMAC contains a password-based MAC 3130 -- (using the protectionAlg AlgId from PKIHeader) on the 3131 -- DER-encoded value of publicKey 3132 }, 3133 publicKey SubjectPublicKeyInfo -- from CertTemplate 3134 } 3136 InitReqContent ::= SEQUENCE { 3137 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 3138 fullCertTemplates FullCertTemplates 3139 } 3141 InitRepContent ::= CertRepContent 3142 CertReqContent ::= CHOICE { 3143 fullCertTemplates [0] FullCertTemplates, 3144 pkcs10CertReqContent [1] PKCS10CertReqContent 3145 } 3147 POPODecKeyChallContent ::= SEQUENCE OF Challenge 3148 -- One Challenge per encryption key certification request (in the 3149 -- same order as these requests appear in FullCertTemplates). 3151 Challenge ::= SEQUENCE { 3152 owf AlgorithmIdentifier OPTIONAL, 3153 -- must be present in the first Challenge; may be omitted in any 3154 -- subsequent Challenge in POPODecKeyChallContent (if omitted, 3155 -- then the owf used in the immediately preceding Challenge is 3156 -- to be used). 3157 witness OCTET STRING, 3158 -- the result of applying the one-way function (owf) to a 3159 -- randomly-generated INTEGER, A. [Note that a different 3160 -- INTEGER must be used for each Challenge.] 3161 challenge OCTET STRING 3162 -- the encryption (under the public key for which the cert. 3163 -- request is being made) of Rand, where Rand is specified as 3164 -- Rand ::= SEQUENCE { 3165 -- int INTEGER, 3166 -- - the randomly-generated INTEGER A (above) 3167 -- sender GeneralName 3168 -- - the sender's name (as included in PKIHeader) 3169 -- } 3170 } 3172 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 3173 -- One INTEGER per encryption key certification request (in the 3174 -- same order as these requests appear in FullCertTemplates). The 3175 -- retrieved INTEGER A (above) is returned to the sender of the 3176 -- corresponding Challenge. 3178 CertRepContent ::= SEQUENCE { 3179 caPub [1] Certificate OPTIONAL, 3180 response SEQUENCE OF CertResponse 3181 } 3183 CertResponse ::= SEQUENCE { 3184 certReqId INTEGER, 3185 -- to match this response with corresponding request 3186 status PKIStatusInfo, 3187 certifiedKeyPair CertifiedKeyPair OPTIONAL 3188 } 3190 CertifiedKeyPair ::= SEQUENCE { 3191 certificate [0] Certificate OPTIONAL, 3192 encryptedCert [1] EncryptedValue OPTIONAL, 3193 privateKey [2] EncryptedValue OPTIONAL, 3194 publicationInfo [3] PKIPublicationInfo OPTIONAL 3195 } 3196 KeyUpdReqContent ::= SEQUENCE { 3197 protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, 3198 fullCertTemplates [1] FullCertTemplates OPTIONAL 3199 } 3201 KeyUpdRepContent ::= InitRepContent 3203 KeyRecReqContent ::= InitReqContent 3205 KeyRecRepContent ::= SEQUENCE { 3206 status PKIStatusInfo, 3207 newSigCert [0] Certificate OPTIONAL, 3208 caCerts [1] SEQUENCE OF Certificate OPTIONAL, 3209 keyPairHist [2] SEQUENCE OF CertifiedKeyPair OPTIONAL 3210 } 3212 RevReqContent ::= SEQUENCE OF RevDetails 3214 RevDetails ::= SEQUENCE { 3215 certDetails CertTemplate, 3216 -- allows requester to specify as much as they can about 3217 -- the cert. for which revocation is requested 3218 -- (e.g. for cases in which serialNumber is not available) 3219 revocationReason ReasonFlags, 3220 -- from the DAM, so that CA knows which Dist. point to use 3221 badSinceDate GeneralizedTime OPTIONAL, 3222 -- indicates best knowledge of sender 3223 crlEntryDetails Extensions 3224 -- requested crlEntryExtensions 3225 } 3227 RevRepContent ::= SEQUENCE { 3228 status PKIStatusInfo, 3229 revCerts [0] SEQUENCE OF CertId OPTIONAL, 3230 -- identifies the certs for which revocation was requested 3231 crls [1] SEQUENCE OF CertificateList OPTIONAL 3232 -- the resulting CRLs (there may be more than one) 3233 } 3235 CrossCertReqContent ::= CertReqContent 3237 CrossCertRepContent ::= CertRepContent 3239 CAKeyUpdAnnContent ::= SEQUENCE { 3240 oldWithNew Certificate, -- old pub signed with new priv 3241 newWithOld Certificate, -- new pub signed with old priv 3242 newWithNew Certificate -- new pub signed with new priv 3243 } 3245 CertAnnContent ::= Certificate 3246 RevAnnContent ::= SEQUENCE { 3247 status PKIStatus, 3248 certId CertId, 3249 willBeRevokedAt GeneralizedTime, 3250 badSinceDate GeneralizedTime, 3251 crlDetails Extensions OPTIONAL 3252 -- extra CRL details(e.g., crl number, reason, location, etc.) 3253 } 3255 CRLAnnContent ::= SEQUENCE OF CertificateList 3257 PKIConfirmContent ::= NULL 3259 InfoTypeAndValue ::= SEQUENCE { 3260 infoType OBJECT IDENTIFIER, 3261 infoValue ANY DEFINED BY infoType OPTIONAL 3262 } 3263 -- Example InfoTypeAndValue contents include, but are not limited to: 3264 -- { CAProtEncCert = { xx }, Certificate } 3265 -- { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 3266 -- { EncKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier } 3267 -- { PreferredSymmAlg = { xx }, AlgorithmIdentifier } 3268 -- { CAKeyUpdateInfo = { xx }, CAKeyUpdAnnContent } 3269 -- { CurrentCRL = { xx }, CertificateList } 3271 PKIInfoReqContent ::= SET OF InfoTypeAndValue 3272 -- The OPTIONAL infoValue parameter of InfoTypeAndValue is unused. 3273 -- The CA is free to ignore any contained OBJ. IDs that it does not 3274 -- recognize. 3275 -- The empty set indicates that the CA may send any/all information 3276 -- that it wishes. 3278 PKIInfoRepContent ::= SET OF InfoTypeAndValue 3279 -- The end entity is free to ignore any contained OBJ. IDs that it 3280 -- does not recognize. 3282 ErrorMsgContent ::= SEQUENCE { 3283 pKIStatusInfo PKIStatusInfo, 3284 errorCode INTEGER OPTIONAL, 3285 -- implementation-specific error codes 3286 errorDetails PKIFreeText OPTIONAL 3287 -- implementation-specific error details 3288 }