idnits 2.17.1 draft-ietf-pkix-rfc2510bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. -- The draft header indicates that this document obsoletes RFC2510, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 947 has weird spacing: '...cate is the...' == Line 948 has weird spacing: '...otected stand...' == Line 949 has weird spacing: '...e where the ...' == Line 951 has weird spacing: '... to get verif...' == Line 952 has weird spacing: '...alue of verif...' == (22 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (February 12, 2004) is 7377 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 4190 -- Looks like a reference, but probably isn't: '1' on line 4194 -- Looks like a reference, but probably isn't: '2' on line 4172 -- Looks like a reference, but probably isn't: '3' on line 3935 -- Looks like a reference, but probably isn't: '4' on line 3936 -- Looks like a reference, but probably isn't: '5' on line 3937 -- Looks like a reference, but probably isn't: '6' on line 3938 -- Looks like a reference, but probably isn't: '7' on line 3939 -- Looks like a reference, but probably isn't: '8' on line 3940 -- Looks like a reference, but probably isn't: '9' on line 3941 -- Looks like a reference, but probably isn't: '10' on line 3942 -- Looks like a reference, but probably isn't: '11' on line 3943 -- Looks like a reference, but probably isn't: '12' on line 3944 -- Looks like a reference, but probably isn't: '13' on line 3945 -- Looks like a reference, but probably isn't: '14' on line 3946 -- Looks like a reference, but probably isn't: '15' on line 3947 -- Looks like a reference, but probably isn't: '16' on line 3948 -- Looks like a reference, but probably isn't: '17' on line 3949 -- Looks like a reference, but probably isn't: '18' on line 3950 -- Looks like a reference, but probably isn't: '19' on line 3951 -- Looks like a reference, but probably isn't: '20' on line 3952 -- Looks like a reference, but probably isn't: '21' on line 3953 -- Looks like a reference, but probably isn't: '22' on line 3954 -- Looks like a reference, but probably isn't: '23' on line 3955 -- Looks like a reference, but probably isn't: '24' on line 3956 -- Looks like a reference, but probably isn't: '25' on line 3957 -- Looks like a reference, but probably isn't: '26' on line 3958 -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' -- Possible downref: Non-RFC (?) normative reference: ref. 'MvOV97' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2202 ** Obsolete normative reference: RFC 2482 (Obsoleted by RFC 6082) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 2559 (Obsoleted by RFC 3494) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Adams 3 Internet-Draft University of Ottawa 4 Obsoletes: 2510 (if approved) S. Farrell 5 Expires: August 12, 2004 Trinity College Dublin 6 T. Kause 7 SSH 8 T. Mononen 9 SafeNet 10 February 12, 2004 12 Internet X.509 Public Key Infrastructure -- Certificate Management 13 Protocol (CMP) 14 draft-ietf-pkix-rfc2510bis-09.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 12, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document describes the Internet X.509 Public Key Infrastructure 45 (PKI) Certificate Management Protocol (CMP). Protocol messages are 46 defined for X.509v3 certificate creation and management. CMP 47 provides online interactions between PKI components, including an 48 exchange between a Certification Authority (CA) and a client system. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . 5 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . 6 54 3. PKI Management Overview . . . . . . . . . . . . . . . 7 55 3.1 PKI Management Model . . . . . . . . . . . . . . . . . 7 56 3.1.1 Definitions of PKI Entities . . . . . . . . . . . . . 7 57 3.1.1.1 Subjects and End Entities . . . . . . . . . . . . . . 7 58 3.1.1.2 Certification Authority . . . . . . . . . . . . . . . 8 59 3.1.1.3 Registration Authority . . . . . . . . . . . . . . . . 9 60 3.1.2 PKI Management Requirements . . . . . . . . . . . . . 9 61 3.1.3 PKI Management Operations . . . . . . . . . . . . . . 11 62 4. Assumptions and Restrictions . . . . . . . . . . . . . 16 63 4.1 End Entity Initialization . . . . . . . . . . . . . . 16 64 4.2 Initial Registration/Certification . . . . . . . . . . 16 65 4.2.1 Criteria Used . . . . . . . . . . . . . . . . . . . . 16 66 4.2.1.1 Initiation of Registration / Certification . . . . . . 16 67 4.2.1.2 End Entity Message Origin Authentication . . . . . . . 17 68 4.2.1.3 Location of Key Generation . . . . . . . . . . . . . . 17 69 4.2.1.4 Confirmation of Successful Certification . . . . . . . 17 70 4.2.2 Mandatory Schemes . . . . . . . . . . . . . . . . . . 18 71 4.2.2.1 Centralized Scheme . . . . . . . . . . . . . . . . . . 18 72 4.2.2.2 Basic Authenticated Scheme . . . . . . . . . . . . . . 18 73 4.3 Proof of Possession (POP) of Private Key . . . . . . . 19 74 4.3.1 Signature Keys . . . . . . . . . . . . . . . . . . . . 20 75 4.3.2 Encryption Keys . . . . . . . . . . . . . . . . . . . 20 76 4.3.3 Key Agreement Keys . . . . . . . . . . . . . . . . . . 20 77 4.4 Root CA Key Update . . . . . . . . . . . . . . . . . . 21 78 4.4.1 CA Operator Actions . . . . . . . . . . . . . . . . . 22 79 4.4.2 Verifying Certificates . . . . . . . . . . . . . . . . 22 80 4.4.2.1 Verification in Cases 1, 4, 5 and 8 . . . . . . . . . 23 81 4.4.2.2 Verification in Case 2 . . . . . . . . . . . . . . . . 24 82 4.4.2.3 Verification in Case 3 . . . . . . . . . . . . . . . . 24 83 4.4.2.4 Failure of Verification in Case 6 . . . . . . . . . . 24 84 4.4.2.5 Failure of Verification in Case 7 . . . . . . . . . . 25 85 4.4.3 Revocation - Change of CA Key . . . . . . . . . . . . 25 86 5. Data Structures . . . . . . . . . . . . . . . . . . . 26 87 5.1 Overall PKI Message . . . . . . . . . . . . . . . . . 26 88 5.1.1 PKI Message Header . . . . . . . . . . . . . . . . . . 26 89 5.1.1.1 ImplicitConfirm . . . . . . . . . . . . . . . . . . . 29 90 5.1.1.2 ConfirmWaitTime . . . . . . . . . . . . . . . . . . . 29 91 5.1.2 PKI Message Body . . . . . . . . . . . . . . . . . . . 29 92 5.1.3 PKI Message Protection . . . . . . . . . . . . . . . . 30 93 5.1.3.1 Shared Secret Information . . . . . . . . . . . . . . 31 94 5.1.3.2 DH Key Pairs . . . . . . . . . . . . . . . . . . . . . 32 95 5.1.3.3 Signature . . . . . . . . . . . . . . . . . . . . . . 32 96 5.1.3.4 Multiple Protection . . . . . . . . . . . . . . . . . 33 97 5.2 Common Data Structures . . . . . . . . . . . . . . . . 33 98 5.2.1 Requested Certificate Contents . . . . . . . . . . . . 33 99 5.2.2 Encrypted Values . . . . . . . . . . . . . . . . . . . 34 100 5.2.3 Status codes and Failure Information for PKI Messages 34 101 5.2.4 Certificate Identification . . . . . . . . . . . . . . 35 102 5.2.5 Out-of-band root CA Public Key . . . . . . . . . . . . 35 103 5.2.6 Archive Options . . . . . . . . . . . . . . . . . . . 36 104 5.2.7 Publication Information . . . . . . . . . . . . . . . 36 105 5.2.8 Proof-of-Possession Structures . . . . . . . . . . . . 37 106 5.2.8.1 Inclusion of the Private Key . . . . . . . . . . . . . 37 107 5.2.8.2 Indirect Method . . . . . . . . . . . . . . . . . . . 37 108 5.2.8.3 Challenge-Response Protocol . . . . . . . . . . . . . 38 109 5.2.8.4 Summary of PoP Options . . . . . . . . . . . . . . . . 39 110 5.3 Operation-Specific Data Structures . . . . . . . . . . 41 111 5.3.1 Initialization Request . . . . . . . . . . . . . . . . 41 112 5.3.2 Initialization Response . . . . . . . . . . . . . . . 41 113 5.3.3 Certification Request . . . . . . . . . . . . . . . . 41 114 5.3.4 Certification Response . . . . . . . . . . . . . . . . 41 115 5.3.5 Key Update Request Content . . . . . . . . . . . . . . 43 116 5.3.6 Key Update Response Content . . . . . . . . . . . . . 43 117 5.3.7 Key Recovery Request Content . . . . . . . . . . . . . 43 118 5.3.8 Key Recovery Response Content . . . . . . . . . . . . 43 119 5.3.9 Revocation Request Content . . . . . . . . . . . . . . 44 120 5.3.10 Revocation Response Content . . . . . . . . . . . . . 44 121 5.3.11 Cross Certification Request Content . . . . . . . . . 44 122 5.3.12 Cross Certification Response Content . . . . . . . . . 44 123 5.3.13 CA Key Update Announcement Content . . . . . . . . . . 45 124 5.3.14 Certificate Announcement . . . . . . . . . . . . . . . 45 125 5.3.15 Revocation Announcement . . . . . . . . . . . . . . . 45 126 5.3.16 CRL Announcement . . . . . . . . . . . . . . . . . . . 46 127 5.3.17 PKI Confirmation Content . . . . . . . . . . . . . . . 46 128 5.3.18 Certificate Confirmation Content . . . . . . . . . . . 46 129 5.3.19 PKI General Message Content . . . . . . . . . . . . . 47 130 5.3.19.1 CA Protocol Encryption Certificate . . . . . . . . . . 47 131 5.3.19.2 Signing Key Pair Types . . . . . . . . . . . . . . . . 47 132 5.3.19.3 Encryption/Key Agreement Key Pair Types . . . . . . . 47 133 5.3.19.4 Preferred Symmetric Algorithm . . . . . . . . . . . . 48 134 5.3.19.5 Updated CA Key Pair . . . . . . . . . . . . . . . . . 48 135 5.3.19.6 CRL . . . . . . . . . . . . . . . . . . . . . . . . . 48 136 5.3.19.7 Unsupported Object Identifiers . . . . . . . . . . . . 48 137 5.3.19.8 Key Pair Parameters . . . . . . . . . . . . . . . . . 48 138 5.3.19.9 Revocation Passphrase . . . . . . . . . . . . . . . . 49 139 5.3.19.10 ImplicitConfirm . . . . . . . . . . . . . . . . . . . 49 140 5.3.19.11 ConfirmWaitTime . . . . . . . . . . . . . . . . . . . 49 141 5.3.19.12 Original PKIMessage . . . . . . . . . . . . . . . . . 49 142 5.3.19.13 Supported Language Tags . . . . . . . . . . . . . . . 49 143 5.3.20 PKI General Response Content . . . . . . . . . . . . . 49 144 5.3.21 Error Message Content . . . . . . . . . . . . . . . . 50 145 5.3.22 Polling Request and Response . . . . . . . . . . . . . 50 146 6. Mandatory PKI Management Functions . . . . . . . . . . 53 147 6.1 Root CA Initialization . . . . . . . . . . . . . . . . 53 148 6.2 Root CA Key Update . . . . . . . . . . . . . . . . . . 53 149 6.3 Subordinate CA Initialization . . . . . . . . . . . . 53 150 6.4 CRL production . . . . . . . . . . . . . . . . . . . . 54 151 6.5 PKI Information Request . . . . . . . . . . . . . . . 54 152 6.6 Cross Certification . . . . . . . . . . . . . . . . . 54 153 6.6.1 One-Way Request-Response Scheme: . . . . . . . . . . . 54 154 6.7 End Entity Initialization . . . . . . . . . . . . . . 56 155 6.7.1 Acquisition of PKI Information . . . . . . . . . . . . 56 156 6.7.2 Out-of-Band Verification of Root-CA Key . . . . . . . 57 157 6.8 Certificate Request . . . . . . . . . . . . . . . . . 57 158 6.9 Key Update . . . . . . . . . . . . . . . . . . . . . . 57 159 7. Version Negotiation . . . . . . . . . . . . . . . . . 58 160 7.1 Supporting RFC 2510 Implementations . . . . . . . . . 58 161 7.1.1 Clients Talking to RFC 2510 Servers . . . . . . . . . 58 162 7.1.2 Servers Receiving Version cmp1999 PKIMessages . . . . 59 163 8. Security Considerations . . . . . . . . . . . . . . . 60 164 8.1 Proof-Of-Possesion with a Decryption Key . . . . . . . 60 165 8.2 Proof-Of-Possession by Exposing the Private Key . . . 60 166 8.3 Attack Against Diffie-Hellman Key Exchange . . . . . . 60 167 9. IANA considerations . . . . . . . . . . . . . . . . . 62 168 Normative References . . . . . . . . . . . . . . . . . 63 169 Informative References . . . . . . . . . . . . . . . . 64 170 Authors' Addresses . . . . . . . . . . . . . . . . . . 65 171 A. Reasons for the Presence of RAs . . . . . . . . . . . 66 172 B. The Use of Revocation Passphrase . . . . . . . . . . . 67 173 C. Request Message Behavioral Clarifications . . . . . . 69 174 D. PKI Management Message Profiles (REQUIRED). . . . . . 71 175 D.1 General Rules for Interpretation of These Profiles. . 71 176 D.2 Algorithm Use Profile . . . . . . . . . . . . . . . . 72 177 D.3 Proof of Possession Profile . . . . . . . . . . . . . 74 178 D.4 Initial Registration/Certification (Basic 179 Authenticated Scheme) . . . . . . . . . . . . . . . . 75 180 D.5 Certificate Request . . . . . . . . . . . . . . . . . 81 181 D.6 Key Update Request . . . . . . . . . . . . . . . . . . 82 182 E. PKI Management Message Profiles (OPTIONAL). . . . . . 83 183 E.1 General Rules for Interpretation of These Profiles. . 83 184 E.2 Algorithm Use Profile . . . . . . . . . . . . . . . . 83 185 E.3 Self-signed Certificates . . . . . . . . . . . . . . . 83 186 E.4 Root CA Key Update . . . . . . . . . . . . . . . . . . 84 187 E.5 PKI Information Request/Response . . . . . . . . . . . 84 188 E.6 Cross Certification Request/Response (1-way) . . . . . 86 189 E.7 In-band Initialization Using External Identity 190 Certificate . . . . . . . . . . . . . . . . . . . . . 89 191 F. Compilable ASN.1 Definitions . . . . . . . . . . . . . 91 192 G. Acknowledgements . . . . . . . . . . . . . . . . . . . 102 193 Intellectual Property and Copyright Statements . . . . 103 195 1. Introduction 197 This document describes the Internet X.509 Public Key Infrastructure 198 (PKI) Certificate Management Protocol (CMP). Protocol messages are 199 defined for certificate creation and management. The term 200 "certificate" in this document refers to an X.509v3 Certificate as 201 defined in [X509]. 203 This specification obsoletes RFC 2510. This specification differs 204 from RFC 2510 in the following areas: 206 The PKI management message profile section is split to two 207 appendices: the required profile and the optional profile. Some of 208 the formerly mandatory functionality is moved to the optional 209 profile. 211 The message confirmation mechanism has changed substantially. 213 A new polling mechanism is introduced, deprecating the old polling 214 method at the CMP transport level. 216 The CMP transport protocol issues are handled in a separate 217 document [CMPtrans], thus the Transports section is removed. 219 A new implicit confirmation method is introduced to reduce the 220 number of protocol messages exchanged in a transaction. 222 The new specification contains some less prominent protocol 223 enhancements and improved explanatory text on several issues. 225 2. Requirements 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 228 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 229 as shown) are to be interpreted as described in [RFC2119]. 231 3. PKI Management Overview 233 The PKI must be structured to be consistent with the types of 234 individuals who must administer it. Providing such administrators 235 with unbounded choices not only complicates the software required but 236 also increases the chances that a subtle mistake by an administrator 237 or software developer will result in broader compromise. Similarly, 238 restricting administrators with cumbersome mechanisms will cause them 239 not to use the PKI. 241 Management protocols are REQUIRED to support on-line interactions 242 between Public Key Infrastructure (PKI) components. For example, a 243 management protocol might be used between a Certification Authority 244 (CA) and a client system with which a key pair is associated, or 245 between two CAs that issue cross-certificates for each other. 247 3.1 PKI Management Model 249 Before specifying particular message formats and procedures we first 250 define the entities involved in PKI management and their interactions 251 (in terms of the PKI management functions required). We then group 252 these functions in order to accommodate different identifiable types 253 of end entities. 255 3.1.1 Definitions of PKI Entities 257 The entities involved in PKI management include the end entity (i.e., 258 the entity to whom the certificate is issued) and the certification 259 authority (i.e., the entity that issues the certificate). A 260 registration authority MAY also be involved in PKI management. 262 3.1.1.1 Subjects and End Entities 264 The term "subject" is used here to refer to the entity to whom the 265 certificate is issued, typically named in the subject or 266 subjectAltName field of a certificate. When we wish to distinguish 267 the tools and/or software used by the subject (e.g., a local 268 certificate management module) we will use the term "subject 269 equipment". In general, the term "end entity" (EE) rather than 270 subject is preferred in order to avoid confusion with the field name. 271 It is important to note that the end entities here will include not 272 only human users of applications, but also applications themselves 273 (e.g., for IP security). This factor influences the protocols which 274 the PKI management operations use; for example, application software 275 is far more likely to know exactly which certificate extensions are 276 required than are human users. PKI management entities are also end 277 entities in the sense that they are sometimes named in the subject or 278 subjectAltName field of a certificate or cross-certificate. Where 279 appropriate, the term "end-entity" will be used to refer to end 280 entities who are not PKI management entities. 282 All end entities require secure local access to some information -- 283 at a minimum, their own name and private key, the name of a CA which 284 is directly trusted by this entity and that CA's public key (or a 285 fingerprint of the public key where a self-certified version is 286 available elsewhere). Implementations MAY use secure local storage 287 for more than this minimum (e.g., the end entity's own certificate or 288 application-specific information). The form of storage will also vary 289 -- from files to tamper-resistant cryptographic tokens. The 290 information stored in such local trusted storage is referred to here 291 as the end entity's Personal Security Environment (PSE). 293 Though PSE formats are beyond the scope of this document (they are 294 very dependent on equipment, et cetera), a generic interchange format 295 for PSEs is defined here - a certification response message MAY be 296 used. 298 3.1.1.2 Certification Authority 300 The certification authority (CA) may or may not actually be a real 301 "third party" from the end entity's point of view. Quite often, the 302 CA will actually belong to the same organization as the end entities 303 it supports. 305 Again, we use the term CA to refer to the entity named in the issuer 306 field of a certificate; when it is necessary to distinguish the 307 software or hardware tools used by the CA we use the term "CA 308 equipment". 310 The CA equipment will often include both an "off-line" component and 311 an "on-line" component, with the CA private key only available to the 312 "off-line" component. This is, however, a matter for implementers 313 (though it is also relevant as a policy issue). 315 We use the term "root CA" to indicate a CA that is directly trusted 316 by an end entity; that is, securely acquiring the value of a root CA 317 public key requires some out-of-band step(s). This term is not meant 318 to imply that a root CA is necessarily at the top of any hierarchy, 319 simply that the CA in question is trusted directly. 321 A "subordinate CA" is one that is not a root CA for the end entity in 322 question. Often, a subordinate CA will not be a root CA for any 323 entity but this is not mandatory. 325 3.1.1.3 Registration Authority 327 In addition to end-entities and CAs, many environments call for the 328 existence of a Registration Authority (RA) separate from the 329 Certification Authority. The functions which the registration 330 authority may carry out will vary from case to case but MAY include 331 personal authentication, token distribution, revocation reporting, 332 name assignment, key generation, archival of key pairs, et cetera. 334 This document views the RA as an OPTIONAL component - when it is not 335 present the CA is assumed to be able to carry out the RA's functions 336 so that the PKI management protocols are the same from the end- 337 entity's point of view. 339 Again, we distinguish, where necessary, between the RA and the tools 340 used (the "RA equipment"). 342 Note that an RA is itself an end entity. We further assume that all 343 RAs are in fact certified end entities and that RAs have private keys 344 that are usable for signing. How a particular CA equipment identifies 345 some end entities as RAs is an implementation issue (i.e., this 346 document specifies no special RA certification operation). We do not 347 mandate that the RA is certified by the CA with which it is 348 interacting at the moment (so one RA may work with more than one CA 349 whilst only being certified once). 351 In some circumstances end entities will communicate directly with a 352 CA even where an RA is present. For example, for initial registration 353 and/or certification the subject may use its RA, but communicate 354 directly with the CA in order to refresh its certificate. 356 3.1.2 PKI Management Requirements 358 The protocols given here meet the following requirements on PKI 359 management 361 1. PKI management must conform to the ISO/IEC 9594-8 / ITU-T X.509 362 standards. 364 2. It must be possible to regularly update any key pair without 365 affecting any other key pair. 367 3. The use of confidentiality in PKI management protocols must be 368 kept to a minimum in order to ease acceptance in environments 369 where strong confidentiality might cause regulatory problems. 371 4. PKI management protocols must allow the use of different 372 industry-standard cryptographic algorithms, (specifically 373 including RSA, DSA, MD5, SHA-1) -- this means that any given CA, 374 RA, or end entity may, in principle, use whichever algorithms 375 suit it for its own key pair(s). 377 5. PKI management protocols must not preclude the generation of key 378 pairs by the end-entity concerned, by an RA, or by a CA -- key 379 generation may also occur elsewhere, but for the purposes of PKI 380 management we can regard key generation as occurring wherever 381 the key is first present at an end entity, RA, or CA. 383 6. PKI management protocols must support the publication of 384 certificates by the end-entity concerned, by an RA, or by a CA. 385 Different implementations and different environments may choose 386 any of the above approaches. 388 7. PKI management protocols must support the production of 389 Certificate Revocation Lists (CRLs) by allowing certified end 390 entities to make requests for the revocation of certificates - 391 this must be done in such a way that the denial-of-service 392 attacks which are possible are not made simpler. 394 8. PKI management protocols must be usable over a variety of 395 "transport" mechanisms, specifically including mail, http, TCP/ 396 IP and ftp. 398 9. Final authority for certification creation rests with the CA; no 399 RA or end-entity equipment can assume that any certificate 400 issued by a CA will contain what was requested -- a CA may alter 401 certificate field values or may add, delete or alter extensions 402 according to its operating policy. In other words, all PKI 403 entities (end-entities, RAs, and CAs) must be capable of 404 handling responses to requests for certificates in which the 405 actual certificate issued is different from that requested (for 406 example, a CA may shorten the validity period requested). Note 407 that policy may dictate that the CA must not publish or 408 otherwise distribute the certificate until the requesting entity 409 has reviewed and accepted the newly-created certificate 410 (typically through use of the certConf message). 412 10. A graceful, scheduled change-over from one non-compromised CA 413 key pair to the next (CA key update) must be supported (note 414 that if the CA key is compromised, re-initialization must be 415 performed for all entities in the domain of that CA). An end 416 entity whose PSE contains the new CA public key (following a CA 417 key update) must also be able to verify certificates verifiable 418 using the old public key. End entities who directly trust the 419 old CA key pair must also be able to verify certificates signed 420 using the new CA private key. (Required for situations where 421 the old CA public key is "hardwired" into the end entity's 422 cryptographic equipment). 424 11. The functions of an RA may, in some implementations or 425 environments, be carried out by the CA itself. The protocols 426 must be designed so that end entities will use the same protocol 427 regardless of whether the communication is with an RA or CA. 428 Naturally the end entity must use the correct RA of CA public 429 key to protect the communication. 431 12. Where an end entity requests a certificate containing a given 432 public key value, the end entity must be ready to demonstrate 433 possession of the corresponding private key value. This may be 434 accomplished in various ways, depending on the type of 435 certification request. See Section 4.3 for details of the 436 in-band methods defined for the PKIX-CMP (i.e., Certificate 437 Management Protocol) messages. 439 3.1.3 PKI Management Operations 441 The following diagram shows the relationship between the entities 442 defined above in terms of the PKI management operations. The letters 443 in the diagram indicate "protocols" in the sense that a defined set 444 of PKI management messages can be sent along each of the lettered 445 lines. 447 +---+ cert. publish +------------+ j 448 | | <--------------------- | End Entity | <------- 449 | C | g +------------+ "out-of-band" 450 | e | | ^ loading 451 | r | | | initial 452 | t | a | | b registration/ 453 | | | | certification 454 | / | | | key pair recovery 455 | | | | key pair update 456 | C | | | certificate update 457 | R | PKI "USERS" V | revocation request 458 | L | -------------------+-+-----+-+------+-+------------------- 459 | | PKI MANAGEMENT | ^ | ^ 460 | | ENTITIES a | | b a | | b 461 | R | V | | | 462 | e | g +------+ d | | 463 | p | <------------ | RA | <-----+ | | 464 | o | cert. | | ----+ | | | 465 | s | publish +------+ c | | | | 466 | i | | | | | 467 | t | V | V | 468 | o | g +------------+ i 469 | r | <------------------------| CA |-------> 470 | y | h +------------+ "out-of-band" 471 | | cert. publish | ^ publication 472 | | CRL publish | | 473 +---+ | | cross-certification 474 e | | f cross-certificate 475 | | update 476 | | 477 V | 478 +------+ 479 | CA-2 | 480 +------+ 482 Figure 1 - PKI Entities 484 At a high level the set of operations for which management messages 485 are defined can be grouped as follows. 487 1. CA establishment: When establishing a new CA, certain steps are 488 required (e.g., production of initial CRLs, export of CA public 489 key). 491 2. End entity initialization: this includes importing a root CA 492 public key and requesting information about the options supported 493 by a PKI management entity. 495 3. Certification: various operations result in the creation of new 496 certificates: 498 1. initial registration/certification: This is the process 499 whereby an end entity first makes itself known to a CA or RA, 500 prior to the CA issuing a certificate or certificates for 501 that end entity. The end result of this process (when it is 502 successful) is that a CA issues a certificate for an end 503 entity's public key, and returns that certificate to the end 504 entity and/or posts that certificate in a public repository. 505 This process may, and typically will, involve multiple 506 "steps", possibly including an initialization of the end 507 entity's equipment. For example, the end entity's equipment 508 must be securely initialized with the public key of a CA, to 509 be used in validating certificate paths. Furthermore, an end 510 entity typically needs to be initialized with its own key 511 pair(s). 513 2. key pair update: Every key pair needs to be updated regularly 514 (i.e., replaced with a new key pair), and a new certificate 515 needs to be issued. 517 3. certificate update: As certificates expire they may be 518 "refreshed" if nothing relevant in the environment has 519 changed. 521 4. CA key pair update: As with end entities, CA key pairs need 522 to be updated regularly; however, different mechanisms are 523 required. 525 5. cross-certification request: One CA requests issuance of a 526 cross-certificate from another CA. For the purposes of this 527 standard, the following terms are defined. A "cross- 528 certificate" is a certificate in which the subject CA and the 529 issuer CA are distinct and SubjectPublicKeyInfo contains a 530 verification key (i.e., the certificate has been issued for 531 the subject CA's signing key pair). When it is necessary to 532 distinguish more finely, the following terms may be used: a 533 cross-certificate is called an "inter-domain 534 cross-certificate" if the subject and issuer CAs belong to 535 different administrative domains; it is called an "intra- 536 domain cross-certificate" otherwise. 538 1. Note 1. The above definition of "cross-certificate" 539 aligns with the defined term "CA-certificate" in X.509. 540 Note that this term is not to be confused with the X.500 541 "cACertificate" attribute type, which is unrelated. 543 2. Note 2. In many environments the term 544 "cross-certificate", unless further qualified, will be 545 understood to be synonymous with "inter-domain 546 cross-certificate" as defined above. 548 3. Note 3. Issuance of cross-certificates may be, but is not 549 necessarily, mutual; that is, two CAs may issue 550 cross-certificates for each other. 552 6. cross-certificate update: Similar to a normal certificate 553 update but involving a cross-certificate. 555 4. Certificate/CRL discovery operations: some PKI management 556 operations result in the publication of certificates or CRLs: 558 1. certificate publication: Having gone to the trouble of 559 producing a certificate, some means for publishing it is 560 needed. The "means" defined in PKIX MAY involve the messages 561 specified in Section Section 5.3.13 - Section 5.3.16, or MAY 562 involve other methods (LDAP, for example) as described in 563 [RFC2559], [RFC2585] (the "Operational Protocols" documents 564 of the PKIX series of specifications). 566 2. 4.2 CRL publication: As for certificate publication. 568 5. Recovery operations: some PKI management operations are used when 569 an end entity has "lost" its PSE: 571 1. key pair recovery: As an option, user client key materials 572 (e.g., a user's private key used for decryption purposes) MAY 573 be backed up by a CA, an RA, or a key backup system 574 associated with a CA or RA. If an entity needs to recover 575 these backed up key materials (e.g., as a result of a 576 forgotten password or a lost key chain file), a protocol 577 exchange may be needed to support such recovery. 579 6. Revocation operations: some PKI operations result in the creation 580 of new CRL entries and/or new CRLs: 582 1. revocation request: An authorized person advises a CA of an 583 abnormal situation requiring certificate revocation. 585 7. PSE operations: whilst the definition of PSE operations (e.g., 586 moving a PSE, changing a PIN, etc.) are beyond the scope of this 587 specification, we do define a PKIMessage (CertRepMessage) which 588 can form the basis of such operations. 590 Note that on-line protocols are not the only way of implementing the 591 above operations. For all operations there are off-line methods of 592 achieving the same result, and this specification does not mandate 593 use of on-line protocols. For example, when hardware tokens are 594 used, many of the operations MAY be achieved as part of the physical 595 token delivery. 597 Later sections define a set of standard messages supporting the above 598 operations. Transport protocols for conveying these exchanges in 599 different environments (file based, on-line, E-mail, and WWW) are 600 beyond the scope of this document and are specified separately. 602 4. Assumptions and Restrictions 604 4.1 End Entity Initialization 606 The first step for an end entity in dealing with PKI management 607 entities is to request information about the PKI functions supported 608 and to securely acquire a copy of the relevant root CA public key(s). 610 4.2 Initial Registration/Certification 612 There are many schemes that can be used to achieve initial 613 registration and certification of end entities. No one method is 614 suitable for all situations due to the range of policies which a CA 615 may implement and the variation in the types of end entity which can 616 occur. 618 We can however, classify the initial registration / certification 619 schemes that are supported by this specification. Note that the word 620 "initial", above, is crucial - we are dealing with the situation 621 where the end entity in question has had no previous contact with the 622 PKI. Where the end entity already possesses certified keys then some 623 simplifications/alternatives are possible. 625 Having classified the schemes that are supported by this 626 specification we can then specify some as mandatory and some as 627 optional. The goal is that the mandatory schemes cover a sufficient 628 number of the cases which will arise in real use, whilst the optional 629 schemes are available for special cases which arise less frequently. 630 In this way we achieve a balance between flexibility and ease of 631 implementation. 633 We will now describe the classification of initial registration / 634 certification schemes. 636 4.2.1 Criteria Used 638 4.2.1.1 Initiation of Registration / Certification 640 In terms of the PKI messages which are produced we can regard the 641 initiation of the initial registration / certification exchanges as 642 occurring wherever the first PKI message relating to the end entity 643 is produced. Note that the real-world initiation of the registration 644 / certification procedure may occur elsewhere (e.g., a personnel 645 department may telephone an RA operator). 647 The possible locations are at the end entity, an RA, or a CA. 649 4.2.1.2 End Entity Message Origin Authentication 651 The on-line messages produced by the end entity that requires a 652 certificate may be authenticated or not. The requirement here is to 653 authenticate the origin of any messages from the end entity to the 654 PKI (CA/RA). 656 In this specification, such authentication is achieved by the PKI 657 (CA/RA) issuing the end entity with a secret value (initial 658 authentication key) and reference value (used to identify the secret 659 value) via some out-of-band means. The initial authentication key can 660 then be used to protect relevant PKI messages. 662 We can thus classify the initial registration/certification scheme 663 according to whether or not the on-line end entity -> PKI messages 664 are authenticated or not. 666 Note 1: We do not discuss the authentication of the PKI -> end entity 667 messages here as this is always REQUIRED. In any case, it can be 668 achieved simply once the root-CA public key has been installed at the 669 end entity's equipment or it can be based on the initial 670 authentication key. 672 Note 2: An initial registration / certification procedure can be 673 secure where the messages from the end entity are authenticated via 674 some out- of-band means (e.g., a subsequent visit). 676 4.2.1.3 Location of Key Generation 678 In this specification, "key generation" is regarded as occurring 679 wherever either the public or private component of a key pair first 680 occurs in a PKIMessage. Note that this does not preclude a 681 centralized key generation service - the actual key pair MAY have 682 been generated elsewhere and transported to the end entity, RA, or CA 683 using a (proprietary or standardized) key generation request/response 684 protocol (outside the scope of this specification). 686 There are thus three possibilities for the location of "key 687 generation": the end entity, an RA, or a CA. 689 4.2.1.4 Confirmation of Successful Certification 691 Following the creation of an initial certificate for an end entity, 692 additional assurance can be gained by having the end entity 693 explicitly confirm successful receipt of the message containing (or 694 indicating the creation of) the certificate. Naturally, this 695 confirmation message must be protected (based on the initial 696 authentication key or other means). 698 This gives two further possibilities: confirmed or not. 700 4.2.2 Mandatory Schemes 702 The criteria above allow for a large number of initial registration / 703 certification schemes. This specification mandates that conforming CA 704 equipment, RA equipment, and EE equipment MUST support the second 705 scheme listed below (Section 4.2.2.2) Any entity MAY additionally 706 support other schemes, if desired. 708 4.2.2.1 Centralized Scheme 710 In terms of the classification above, this scheme is, in some ways, 711 the simplest possible, where: 713 o initiation occurs at the certifying CA; 715 o no on-line message authentication is required; 717 o "key generation" occurs at the certifying CA (see Section 718 4.2.1.3); 720 o no confirmation message is required. 722 In terms of message flow, this scheme means that the only message 723 required is sent from the CA to the end entity. The message must 724 contain the entire PSE for the end entity. Some out-of-band means 725 must be provided to allow the end entity to authenticate the message 726 received and decrypt any encrypted values. 728 4.2.2.2 Basic Authenticated Scheme 730 In terms of the classification above, this scheme is where: 732 o initiation occurs at the end entity; 734 o message authentication is REQUIRED; 736 o "key generation" occurs at the end entity (see Section 4.2.1.3); 738 o a confirmation message is REQUIRED. 740 In terms of message flow, the basic authenticated scheme is as 741 follows: 743 End entity RA/CA 744 ========== ============= 745 out-of-band distribution of Initial Authentication 746 Key (IAK) and reference value (RA/CA -> EE) 747 Key generation 748 Creation of certification request 749 Protect request with IAK 750 -->>-- certification request -->>-- 751 verify request 752 process request 753 create response 754 --<<-- certification response --<<-- 755 handle response 756 create confirmation 757 -->>-- cert conf message -->>-- 758 verify confirmation 759 create response 760 --<<-- conf ack (optional) --<<-- 761 handle response 763 (Where verification of the cert confirmation message fails, the RA/CA 764 MUST revoke the newly issued certificate if it has been published or 765 otherwise made available.) 767 4.3 Proof of Possession (POP) of Private Key 769 In order to prevent certain attacks and to allow a CA/RA to properly 770 check the validity of the binding between an end entity and a key 771 pair, the PKI management operations specified here make it possible 772 for an end entity to prove that it has possession of (i.e., is able 773 to use) the private key corresponding to the public key for which a 774 certificate is requested. A given CA/RA is free to choose how to 775 enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in- 776 band messages) in its certification exchanges (i.e., this may be a 777 policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP 778 by some means because there are currently many non-PKIX operational 779 protocols in use (various electronic mail protocols are one example) 780 that do not explicitly check the binding between the end entity and 781 the private key. Until operational protocols that do verify the 782 binding (for signature, encryption, and key agreement key pairs) 783 exist, and are ubiquitous, this binding can only be assumed to have 784 been verified by the CA/RA. Therefore, if the binding is not verified 785 by the CA/RA, certificates in the Internet Public-Key Infrastructure 786 end up being somewhat less meaningful. 788 POP is accomplished in different ways depending upon the type of key 789 for which a certificate is requested. If a key can be used for 790 multiple purposes (e.g., an RSA key) then any appropriate method MAY 791 be used (e.g., a key which may be used for signing, as well as other 792 purposes, SHOULD NOT be sent to the CA/RA in order to prove 793 possession). 795 This specification explicitly allows for cases where an end entity 796 supplies the relevant proof to an RA and the RA subsequently attests 797 to the CA that the required proof has been received (and validated!). 798 For example, an end entity wishing to have a signing key certified 799 could send the appropriate signature to the RA which then simply 800 notifies the relevant CA that the end entity has supplied the 801 required proof. Of course, such a situation may be disallowed by some 802 policies (e.g., CAs may be the only entities permitted to verify POP 803 during certification). 805 4.3.1 Signature Keys 807 For signature keys, the end entity can sign a value to prove 808 possession of the private key. 810 4.3.2 Encryption Keys 812 For encryption keys, the end entity can provide the private key to 813 the CA/RA, or can be required to decrypt a value in order to prove 814 possession of the private key (see Section 5.2.8). Decrypting a value 815 can be achieved either directly or indirectly. 817 The direct method is for the RA/CA to issue a random challenge to 818 which an immediate response by the EE is required. 820 The indirect method is to issue a certificate which is encrypted for 821 the end entity (and have the end entity demonstrate its ability to 822 decrypt this certificate in the confirmation message). This allows a 823 CA to issue a certificate in a form which can only be used by the 824 intended end entity. 826 This specification encourages use of the indirect method because this 827 requires no extra messages to be sent (i.e., the proof can be 828 demonstrated using the {request, response, confirmation} triple of 829 messages). 831 4.3.3 Key Agreement Keys 833 For key agreement keys, the end entity and the PKI management entity 834 (i.e., CA or RA) must establish a shared secret key in order to prove 835 that the end entity has possession of the private key. 837 Note that this need not impose any restrictions on the keys that can 838 be certified by a given CA -- in particular, for Diffie-Hellman keys 839 the end entity may freely choose its algorithm parameters -- provided 840 that the CA can generate a short-term (or one-time) key pair with the 841 appropriate parameters when necessary. 843 4.4 Root CA Key Update 845 This discussion only applies to CAs that are directly trusted by some 846 end entities. Self-signed CAs SHALL be considered as directly trusted 847 CAs. Recognizing whether a non self-signed CA is supposed to be 848 directly trusted for some end entities is a matter of CA policy and 849 is thus beyond the scope of this document. 851 The basis of the procedure described here is that the CA protects its 852 new public key using its previous private key and vice versa. Thus 853 when a CA updates its key pair it must generate two extra 854 cACertificate attribute values if certificates are made available 855 using an X.500 directory (for a total of four: OldWithOld; 856 OldWithNew; NewWithOld; and NewWithNew). 858 When a CA changes its key pair those entities who have acquired the 859 old CA public key via "out-of-band" means are most affected. It is 860 these end entities who will need access to the new CA public key 861 protected with the old CA private key. However, they will only 862 require this for a limited period (until they have acquired the new 863 CA public key via the "out-of-band" mechanism). This will typically 864 be easily achieved when these end entities' certificates expire. 866 The data structure used to protect the new and old CA public keys is 867 a standard certificate (which may also contain extensions). There are 868 no new data structures required. 870 Note 1. This scheme does not make use of any of the X.509 v3 871 extensions as it must be able to work even for version 1 872 certificates. The presence of the KeyIdentifier extension would make 873 for efficiency improvements. 875 Note 2. While the scheme could be generalized to cover cases where 876 the CA updates its key pair more than once during the validity period 877 of one of its end entities' certificates, this generalization seems 878 of dubious value. Not having this generalization simply means that 879 the validity periods of certificates issued with the old CA key pair 880 cannot exceed the end of the OldWithNew validity period. 882 Note 3. This scheme ensures that end entities will acquire the new CA 883 public key, at the latest by the expiry of the last certificate they 884 owned that was signed with the old CA private key (via the 885 "out-of-band" means). Certificate and/or key update operations 886 occurring at other times do not necessarily require this (depending 887 on the end entity's equipment). 889 4.4.1 CA Operator Actions 891 To change the key of the CA, the CA operator does the following: 893 1. Generate a new key pair; 895 2. Create a certificate containing the old CA public key signed with 896 the new private key (the "old with new" certificate); 898 3. Create a certificate containing the new CA public key signed with 899 the old private key (the "new with old" certificate); 901 4. Create a certificate containing the new CA public key signed with 902 the new private key (the "new with new" certificate); 904 5. Publish these new certificates via the repository and/or other 905 means (perhaps using a CAKeyUpdAnn message); 907 6. Export the new CA public key so that end entities may acquire it 908 using the "out-of-band" mechanism (if required). 910 The old CA private key is then no longer required. The old CA public 911 key will however remain in use for some time. The time when the old 912 CA public key is no longer required (other than for non-repudiation) 913 will be when all end entities of this CA have securely acquired the 914 new CA public key. 916 The "old with new" certificate must have a validity period starting 917 at the generation time of the old key pair and ending at the expiry 918 date of the old public key. 920 The "new with old" certificate must have a validity period starting 921 at the generation time of the new key pair and ending at the time by 922 which all end entities of this CA will securely possess the new CA 923 public key (at the latest, the expiry date of the old public key). 925 The "new with new" certificate must have a validity period starting 926 at the generation time of the new key pair and ending at or before 927 the time by which the CA will next update its key pair. 929 4.4.2 Verifying Certificates 931 Normally when verifying a signature, the verifier verifies (among 932 other things) the certificate containing the public key of the 933 signer. However, once a CA is allowed to update its key there are a 934 range of new possibilities. These are shown in the table below. 936 Repository contains NEW Repository contains only OLD 937 and OLD public keys public key (due to, e.g., 938 delay in publication) 940 PSE PSE Contains PSE Contains PSE Contains 941 Contains OLD public NEW public OLD public 942 NEW public key key key 943 key 945 Signer's Case 1: Case 3: Case 5: Case 7: 946 certifi- This is In this case Although the In this case 947 cate is the the verifier CA operator the CA 948 protected standard must access has not operator has 949 using NEW case where the updated the not updated 950 public the repository in repository the the repository 951 key verifier order to get verifier can and so the 952 can the value of verify the verification 953 directly the NEW certificate will FAIL 954 verify the public key directly - 955 certificate this is thus 956 without the same as 957 using the case 1. 958 repository 960 Signer's Case 2: Case 4: Case 6: Case 8: 961 certifi- In this In this case The verifier Although the 962 cate is case the the verifier thinks this CA operator 963 protected verifier can directly is the has not 964 using OLD must verify the situation of updated the 965 public access the certificate case 2 and repository the 966 key repository without will access verifier can 967 in order using the the verify the 968 to get the repository repository; certificate 969 value of however, the directly - 970 the OLD verification this is thus 971 public key will FAIL the same as 972 case 4. 974 4.4.2.1 Verification in Cases 1, 4, 5 and 8 976 In these cases the verifier has a local copy of the CA public key 977 which can be used to verify the certificate directly. This is the 978 same as the situation where no key change has occurred. 980 Note that case 8 may arise between the time when the CA operator has 981 generated the new key pair and the time when the CA operator stores 982 the updated attributes in the repository. Case 5 can only arise if 983 the CA operator has issued both the signer's and verifier's 984 certificates during this "gap" (the CA operator SHOULD avoid this as 985 it leads to the failure cases described below) 987 4.4.2.2 Verification in Case 2 989 In case 2 the verifier must get access to the old public key of the 990 CA. The verifier does the following: 992 1. Look up the caCertificate attribute in the repository and pick 993 the OldWithNew certificate (determined based on validity periods; 994 note that the subject and issuer fields must match); 996 2. Verify that this is correct using the new CA key (which the 997 verifier has locally); 999 3. If correct, check the signer's certificate using the old CA key. 1001 Case 2 will arise when the CA operator has issued the signer's 1002 certificate, then changed key and then issued the verifier's 1003 certificate, so it is quite a typical case. 1005 4.4.2.3 Verification in Case 3 1007 In case 3 the verifier must get access to the new public key of the 1008 CA. The verifier does the following: 1010 1. Look up the CACertificate attribute in the repository and pick 1011 the NewWithOld certificate (determined based on validity periods; 1012 note that the subject and issuer fields must match); 1014 2. Verify that this is correct using the old CA key (which the 1015 verifier has stored locally); 1017 3. If correct, check the signer's certificate using the new CA key. 1019 Case 3 will arise when the CA operator has issued the verifier's 1020 certificate, then changed key and then issued the signer's 1021 certificate, so it is also quite a typical case. 1023 4.4.2.4 Failure of Verification in Case 6 1025 In this case the CA has issued the verifier's PSE containing the new 1026 key without updating the repository attributes. This means that the 1027 verifier has no means to get a trustworthy version of the CA's old 1028 key and so verification fails. 1030 Note that the failure is the CA operator's fault. 1032 4.4.2.5 Failure of Verification in Case 7 1034 In this case the CA has issued the signer's certificate protected 1035 with the new key without updating the repository attributes. This 1036 means that the verifier has no means to get a trustworthy version of 1037 the CA's new key and so verification fails. 1039 Note that the failure is again the CA operator's fault. 1041 4.4.3 Revocation - Change of CA Key 1043 As we saw above the verification of a certificate becomes more 1044 complex once the CA is allowed to change its key. This is also true 1045 for revocation checks as the CA may have signed the CRL using a newer 1046 private key than the one that is within the user's PSE. 1048 The analysis of the alternatives is as for certificate verification. 1050 5. Data Structures 1052 This section contains descriptions of the data structures required 1053 for PKI management messages. Section 6 describes constraints on their 1054 values and the sequence of events for each of the various PKI 1055 management operations. 1057 5.1 Overall PKI Message 1059 All of the messages used in this specification for the purposes of 1060 PKI management use the following structure: 1062 PKIMessage ::= SEQUENCE { 1063 header PKIHeader, 1064 body PKIBody, 1065 protection [0] PKIProtection OPTIONAL, 1066 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1067 OPTIONAL 1068 } 1069 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1071 The PKIHeader contains information which is common to many PKI 1072 messages. 1074 The PKIBody contains message-specific information. 1076 The PKIProtection, when used, contains bits that protect the PKI 1077 message. 1079 The extraCerts field can contain certificates that may be useful to 1080 the recipient. For example, this can be used by a CA or RA to present 1081 an end entity with certificates that it needs to verify its own new 1082 certificate (if, for example, the CA that issued the end entity's 1083 certificate is not a root CA for the end entity). Note that this 1084 field does not necessarily contain a certification path - the 1085 recipient may have to sort, select from, or otherwise process the 1086 extra certificates in order to use them. 1088 5.1.1 PKI Message Header 1090 All PKI messages require some header information for addressing and 1091 transaction identification. Some of this information will also be 1092 present in a transport-specific envelope; however, if the PKI message 1093 is protected then this information is also protected (i.e., we make 1094 no assumption about secure transport). 1096 The following data structure is used to contain this information: 1098 PKIHeader ::= SEQUENCE { 1099 pvno INTEGER { cmp1999(1), cmp2000(2) }, 1100 sender GeneralName, 1101 recipient GeneralName, 1102 messageTime [0] GeneralizedTime OPTIONAL, 1103 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1104 senderKID [2] KeyIdentifier OPTIONAL, 1105 recipKID [3] KeyIdentifier OPTIONAL, 1106 transactionID [4] OCTET STRING OPTIONAL, 1107 senderNonce [5] OCTET STRING OPTIONAL, 1108 recipNonce [6] OCTET STRING OPTIONAL, 1109 freeText [7] PKIFreeText OPTIONAL, 1110 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1111 InfoTypeAndValue OPTIONAL 1112 } 1113 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1115 The pvno field is fixed (at 2) for this version of this 1116 specification. 1118 The sender field contains the name of the sender of the PKIMessage. 1119 This name (in conjunction with senderKID, if supplied) should be 1120 sufficient to indicate the key to use to verify the protection on the 1121 message. If nothing about the sender is known to the sending entity 1122 (e.g., in the init. req. message, where the end entity may not know 1123 its own Distinguished Name (DN), e-mail name, IP address, etc.), then 1124 the "sender" field MUST contain a "NULL" value; that is, the SEQUENCE 1125 OF relative distinguished names is of zero length. In such a case the 1126 senderKID field MUST hold an identifier (i.e., a reference number) 1127 which indicates to the receiver the appropriate shared secret 1128 information to use to verify the message. 1130 The recipient field contains the name of the recipient of the 1131 PKIMessage. This name (in conjunction with recipKID, if supplied) 1132 should be usable to verify the protection on the message. 1134 The protectionAlg field specifies the algorithm used to protect the 1135 message. If no protection bits are supplied (note that PKIProtection 1136 is OPTIONAL) then this field MUST be omitted; if protection bits are 1137 supplied then this field MUST be supplied. 1139 senderKID and recipKID are usable to indicate which keys have been 1140 used to protect the message (recipKID will normally only be required 1141 where protection of the message uses Diffie-Hellman (DH) keys). 1142 These fields MUST be used if required to uniquely identify a key 1143 (e.g., if more than one key is associated with a given sender name) 1144 and SHOULD be omitted otherwise. 1146 The transactionID field within the message header is to be used to 1147 allow the recipient of a message to correlate this with an ongoing 1148 transaction. This is needed for all transactions that consist of more 1149 than just a single request/response pair. For transactions that 1150 consist of a single request/response pair the rules are as follows. 1151 A client MAY populate the transactionID field of the request. If a 1152 server receives such a request which has the transactionID field set, 1153 then it MUST set the transactionID field of the response to the same 1154 value; if a server receives such request with a missing transactionID 1155 field then it MAY set transactionID field of the response. 1157 For transactions that consist of more than just a single request/ 1158 response pair the rules are as follows. Clients SHOULD generate a 1159 transactionID for the first request. If a server receives such a 1160 request which has the transactionID field set, then it MUST set the 1161 transactionID field of the response to the same value; if a server 1162 receives such request with a missing transactionID field then it MUST 1163 populate transactionID field of the response with a server-generated 1164 ID. Subsequent requests and responses MUST all set the transactionID 1165 field to the thus established value. In all cases where a 1166 transactionID is being used, a given client MUST NOT have more than 1167 one transaction with the same transactionID in progress at any time 1168 (to a given server). Servers are free to require uniqueness of the 1169 transactionID or not, as long as they are able to correctly associate 1170 messages with the corresponding transaction. Typically this means 1171 that a server will require the {client, transactionID} tuple to be 1172 unique, or even the transactionID alone to be unique if it cannot 1173 distinguish clients based on transport level information. A server 1174 receiving the first message of a transaction (which requires more 1175 than a single request/response pair) that contains a transactionID 1176 that does not allow it to meet the above constraints (typically 1177 because the transactionID is already in use) MUST send back an 1178 ErrorMsgContent with a PKIFailureInfo of transactionIdInUse. It is 1179 RECOMMENDED that the clients fill the transactionID field with 128 1180 bits of (pseudo-) random data for the start of a transaction to 1181 reduce the probability of having the transactionID in use at the 1182 server. 1184 The senderNonce and recipNonce fields protect the PKIMessage against 1185 replay attacks. The senderNonce will typically be 128 bits of 1186 (pseudo-) random data generated by the sender, whereas the recipNonce 1187 is copied from the senderNonce of the previous message in the 1188 transaction. 1190 The messageTime field contains the time at which the sender created 1191 the message. This may be useful to allow end entities to correct/ 1192 check their local time for consistency with the time on a central 1193 system. 1195 The freeText field may be used to send a human-readable message to 1196 the recipient (in any number of languages). The first language used 1197 in this sequence indicates the desired language for replies. 1199 The generalInfo field may be used to send machine-processable 1200 additional data to the recipient. The following generalInfo 1201 extensions are defined and MAY be supported. 1203 5.1.1.1 ImplicitConfirm 1205 This is used by the EE to inform the CA that it does not wish to send 1206 a certificate confirmation for issued certificates. 1208 implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1209 ImplicitConfirmValue ::= NULL 1211 If the CA grants the request to the EE, it MUST put the same 1212 extension in the PKIHeader of the response. If the EE does not find 1213 the extension in the response, it MUST send the certificate 1214 confirmation. 1216 5.1.1.2 ConfirmWaitTime 1218 This is used by the CA to inform the EE how long it intends to wait 1219 for the certificate confirmation before revoking the certificate and 1220 deleting the transaction. 1222 confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1223 ConfirmWaitTimeValue ::= GeneralizedTime 1225 5.1.2 PKI Message Body 1226 PKIBody ::= CHOICE { 1227 ir [0] CertReqMessages, --Initialization Req 1228 ip [1] CertRepMessage, --Initialization Resp 1229 cr [2] CertReqMessages, --Certification Req 1230 cp [3] CertRepMessage, --Certification Resp 1231 p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. 1232 popdecc [5] POPODecKeyChallContent --pop Challenge 1233 popdecr [6] POPODecKeyRespContent, --pop Response 1234 kur [7] CertReqMessages, --Key Update Request 1235 kup [8] CertRepMessage, --Key Update Response 1236 krr [9] CertReqMessages, --Key Recovery Req 1237 krp [10] KeyRecRepContent, --Key Recovery Resp 1238 rr [11] RevReqContent, --Revocation Request 1239 rp [12] RevRepContent, --Revocation Response 1240 ccr [13] CertReqMessages, --Cross-Cert. Request 1241 ccp [14] CertRepMessage, --Cross-Cert. Resp 1242 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1243 cann [16] CertAnnContent, --Certificate Ann. 1244 rann [17] RevAnnContent, --Revocation Ann. 1245 crlann [18] CRLAnnContent, --CRL Announcement 1246 pkiconf [19] PKIConfirmContent, --Confirmation 1247 nested [20] NestedMessageContent, --Nested Message 1248 genm [21] GenMsgContent, --General Message 1249 genp [22] GenRepContent, --General Response 1250 error [23] ErrorMsgContent, --Error Message 1251 certConf [24] CertConfirmContent, --Certificate confirm 1252 pollReq [25] PollReqContent, --Polling request 1253 pollRep [26] PollRepContent --Polling response 1254 } 1256 The specific types are described in Section Section 5.3 below. 1258 5.1.3 PKI Message Protection 1260 Some PKI messages will be protected for integrity. (Note that if an 1261 asymmetric algorithm is used to protect a message and the relevant 1262 public component has been certified already, then the origin of the 1263 message can also be authenticated. On the other hand, if the public 1264 component is uncertified then the message origin cannot be 1265 automatically authenticated, but may be authenticated via out-of-band 1266 means.) 1268 When protection is applied the following structure is used: 1270 PKIProtection ::= BIT STRING 1272 The input to the calculation of PKIProtection is the DER encoding of 1273 the following data structure: 1275 ProtectedPart ::= SEQUENCE { 1276 header PKIHeader, 1277 body PKIBody 1278 } 1280 There MAY be cases in which the PKIProtection BIT STRING is 1281 deliberately not used to protect a message (i.e., this OPTIONAL field 1282 is omitted) because other protection, external to PKIX, will instead 1283 be applied. Such a choice is explicitly allowed in this 1284 specification. Examples of such external protection include PKCS #7 1285 [PKCS7] and Security Multiparts [RFC1847] encapsulation of the 1286 PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the 1287 relevant PKIHeader information is securely carried in the external 1288 mechanism). It is noted, however, that many such external mechanisms 1289 require that the end entity already possesses a public-key 1290 certificate, and/or a unique Distinguished Name, and/or other such 1291 infrastructure-related information. Thus, they may not be appropriate 1292 for initial registration, key-recovery, or any other process with 1293 "boot-strapping" characteristics. For those cases it may be necessary 1294 that the PKIProtection parameter be used. In the future, if/when 1295 external mechanisms are modified to accommodate boot-strapping 1296 scenarios, the use of PKIProtection may become rare or non-existent. 1298 Depending on the circumstances the PKIProtection bits may contain a 1299 Message Authentication Code (MAC) or signature. Only the following 1300 cases can occur: 1302 5.1.3.1 Shared Secret Information 1304 In this case the sender and recipient share secret information 1305 (established via out-of-band means or from a previous PKI management 1306 operation). PKIProtection will contain a MAC value and the 1307 protectionAlg will be the following (see also Appendix D.2): 1309 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1310 PBMParameter ::= SEQUENCE { 1311 salt OCTET STRING, 1312 owf AlgorithmIdentifier, 1313 iterationCount INTEGER, 1314 mac AlgorithmIdentifier 1315 } 1317 In the above protectionAlg the salt value is appended to the shared 1318 secret input. The OWF is then applied iterationCount times, where the 1319 salted secret is the input to the first iteration and, for each 1320 successive iteration, the input is set to be the output of the 1321 previous iteration. The output of the final iteration (called 1322 "BASEKEY" for ease of reference, with a size of "H") is what is used 1323 to form the symmetric key. If the MAC algorithm requires a K-bit key 1324 and K <= H, then the most significant K bits of BASEKEY are used. If 1325 K > H, then all of BASEKEY is used for the most significant H bits of 1326 the key, OWF("1" || BASEKEY) is used for the next most significant H 1327 bits of the key, OWF("2" || BASEKEY) is used for the next most 1328 significant H bits of the key, and so on, until all K bits have been 1329 derived. [Here "N" is the ASCII byte encoding the number N and "||" 1330 represents concatenation.] 1332 Note: it is RECOMMENDED that the fields of PBMParameter remain 1333 constant throughout the messages of a single transaction (e.g., ir/ 1334 ip/certConf/pkiConf) in order to reduce the overhead associated with 1335 PasswordBasedMac computation). 1337 5.1.3.2 DH Key Pairs 1339 Where the sender and receiver possess Diffie-Hellman certificates 1340 with compatible DH parameters, then in order to protect the message 1341 the end entity must generate a symmetric key based on its private DH 1342 key value and the DH public key of the recipient of the PKI message. 1343 PKIProtection will contain a MAC value keyed with this derived 1344 symmetric key and the protectionAlg will be the following: 1346 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1348 DHBMParameter ::= SEQUENCE { 1349 owf AlgorithmIdentifier, 1350 -- AlgId for a One-Way Function (SHA-1 recommended) 1351 mac AlgorithmIdentifier 1352 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1353 } -- or HMAC [RFC2104, RFC2202]) 1355 In the above protectionAlg OWF is applied to the result of the 1356 Diffie-Hellman computation. The OWF output (called "BASEKEY" for ease 1357 of reference, with a size of "H") is what is used to form the 1358 symmetric key. If the MAC algorithm requires a K-bit key and K <= H, 1359 then the most significant K bits of BASEKEY are used. If K > H, then 1360 all of BASEKEY is used for the most significant H bits of the key, 1361 OWF("1" || BASEKEY) is used for the next most significant H bits of 1362 the key, OWF("2" || BASEKEY) is used for the next most significant H 1363 bits of the key, and so on, until all K bits have been derived. [Here 1364 "N" is the ASCII byte encoding the number N and "||" represents 1365 concatenation.] 1367 5.1.3.3 Signature 1369 In this case the sender possesses a signature key pair and simply 1370 signs the PKI message. PKIProtection will contain the signature value 1371 and the protectionAlg will be an AlgorithmIdentifier for a digital 1372 signature (e.g., md5WithRSAEncryption or dsaWithSha-1). 1374 5.1.3.4 Multiple Protection 1376 In cases where an end entity sends a protected PKI message to an RA, 1377 the RA MAY forward that message to a CA, attaching its own protection 1378 (which MAY be a MAC or a signature, depending on the information and 1379 certificates shared between the RA and the CA). This is accomplished 1380 by nesting the entire message sent by the end entity within a new PKI 1381 message. The structure used is as follows. 1383 NestedMessageContent ::= PKIMessages 1385 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 1386 the requests of several EEs in a single new message. For simplicity, 1387 all messages in the batch MUST be of the same type (e.g., ir)). If 1388 the RA wishes to modify the message(s) in some way (e.g., add 1389 particular field values or new extensions), then it MAY create its 1390 own desired PKIBody. The original PKIMessage from the EE MAY be 1391 included in the generalInfo field of PKIHeader (to accommodate, for 1392 example, cases in which the CA wishes to check POP or other 1393 information on the original EE message). The infoType to be used in 1394 this situation is {id-it 15} (see Section 5.3.19 for the value of 1395 id-it) and the infoValue is PKIMessages (contents MUST be in the same 1396 order as the requests in PKIBody). 1398 5.2 Common Data Structures 1400 Before specifying the specific types that may be placed in a PKIBody 1401 we define some data structures that are used in more than one case. 1403 5.2.1 Requested Certificate Contents 1405 Various PKI management messages require that the originator of the 1406 message indicate some of the fields that are required to be present 1407 in a certificate. The CertTemplate structure allows an end entity or 1408 RA to specify as much as it wishes about the certificate it requires. 1409 CertTemplate is identical to a Certificate but with all fields 1410 optional. 1412 Note that even if the originator completely specifies the contents of 1413 a certificate it requires, a CA is free to modify fields within the 1414 certificate actually issued. If the modified certificate is 1415 unacceptable to the requester, the requester MUST send back a 1416 certConf message which either does not include this certificate (via 1417 a CertHash), or does include this certificate (via a CertHash) along 1418 with a status of "rejected". See Section 5.3.18 for the definition 1419 and use of CertHash and the certConf message. 1421 See Appendix C and [CRMF] for CertTemplate syntax. 1423 5.2.2 Encrypted Values 1425 Where encrypted values (restricted, in this specification, to be 1426 either private keys or certificates) are sent in PKI messages the 1427 EncryptedValue data structure is used. 1429 See [CRMF] for EncryptedValue syntax. 1431 Use of this data structure requires that the creator and intended 1432 recipient respectively be able to encrypt and decrypt. Typically, 1433 this will mean that the sender and recipient have, or are able to 1434 generate, a shared secret key. 1436 If the recipient of the PKIMessage already possesses a private key 1437 usable for decryption, then the encSymmKey field MAY contain a 1438 session key encrypted using the recipient's public key. 1440 5.2.3 Status codes and Failure Information for PKI Messages 1442 All response messages will include some status information. The 1443 following values are defined. 1445 PKIStatus ::= INTEGER { 1446 accepted (0), 1447 grantedWithMods (1), 1448 rejection (2), 1449 waiting (3), 1450 revocationWarning (4), 1451 revocationNotification (5), 1452 keyUpdateWarning (6) 1453 } 1455 Responders may use the following syntax to provide more information 1456 about failure cases. 1458 PKIFailureInfo ::= BIT STRING { 1459 badAlg (0), 1460 badMessageCheck (1), 1461 badRequest (2), 1462 badTime (3), 1463 badCertId (4), 1464 badDataFormat (5), 1465 wrongAuthority (6), 1466 incorrectData (7), 1467 missingTimeStamp (8), 1468 badPOP (9), 1469 certRevoked (10), 1470 certConfirmed (11), 1471 wrongIntegrity (12), 1472 badRecipientNonce (13), 1473 timeNotAvailable (14), 1474 unacceptedPolicy (15), 1475 unacceptedExtension (16), 1476 addInfoNotAvailable (17), 1477 badSenderNonce (18), 1478 badCertTemplate (19), 1479 signerNotTrusted (20), 1480 transactionIdInUse (21), 1481 unsupportedVersion (22), 1482 notAuthorized (23), 1483 systemUnavail (24), 1484 systemFailure (25), 1485 duplicateCertReq (26) 1486 } 1488 PKIStatusInfo ::= SEQUENCE { 1489 status PKIStatus, 1490 statusString PKIFreeText OPTIONAL, 1491 failInfo PKIFailureInfo OPTIONAL 1492 } 1494 5.2.4 Certificate Identification 1496 In order to identify particular certificates the CertId data 1497 structure is used. 1499 See [CRMF] for CertId syntax. 1501 5.2.5 Out-of-band root CA Public Key 1503 Each root CA must be able to publish its current public key via some 1504 "out-of-band" means. While such mechanisms are beyond the scope of 1505 this document, we define data structures which can support such 1506 mechanisms. 1508 There are generally two methods available: either the CA directly 1509 publishes its self-signed certificate; or this information is 1510 available via the Directory (or equivalent) and the CA publishes a 1511 hash of this value to allow verification of its integrity before use. 1513 OOBCert ::= Certificate 1515 The fields within this certificate are restricted as follows: 1517 o The certificate MUST be self-signed (i.e., the signature must be 1518 verifiable using the SubjectPublicKeyInfo field); 1520 o The subject and issuer fields MUST be identical; 1522 o If the subject field is NULL then both subjectAltNames and 1523 issuerAltNames extensions MUST be present and have exactly the 1524 same value; 1526 o The values of all other extensions must be suitable for a self- 1527 signed certificate (e.g., key identifiers for subject and issuer 1528 must be the same). 1530 OOBCertHash ::= SEQUENCE { 1531 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1532 certId [1] CertId OPTIONAL, 1533 hashVal BIT STRING 1534 } 1536 The intention of the hash value is that anyone who has securely 1537 received the hash value (via the out-of-band means) can verify a 1538 self-signed certificate for that CA. 1540 5.2.6 Archive Options 1542 Requesters may indicate that they wish the PKI to archive a private 1543 key value using the PKIArchiveOptions structure. 1545 See [CRMF] for PKIArchiveOptions syntax. 1547 5.2.7 Publication Information 1549 Requesters may indicate that they wish the PKI to publish a 1550 certificate using the PKIPublicationInfo structure. 1552 See [CRMF] for PKIPublicationInfo syntax. 1554 5.2.8 Proof-of-Possession Structures 1556 If the certification request is for a signing key pair (i.e., a 1557 request for a verification certificate), then the proof of possession 1558 of the private signing key is demonstrated through use of the 1559 POPOSigningKey structure. 1561 See Appendix C and [CRMF] for POPOSigningKey syntax, but note that 1562 POPOSigningKeyInput has the following semantic stipulations in this 1563 specification. 1565 POPOSigningKeyInput ::= SEQUENCE { 1566 authInfo CHOICE { 1567 sender [0] GeneralName, 1568 publicKeyMAC PKMACValue 1569 }, 1570 publicKey SubjectPublicKeyInfo 1571 } 1573 On the other hand, if the certification request is for an encryption 1574 key pair (i.e., a request for an encryption certificate), then the 1575 proof of possession of the private decryption key may be demonstrated 1576 in one of three ways. 1578 5.2.8.1 Inclusion of the Private Key 1580 By the inclusion of the private key (encrypted) in the CertRequest 1581 (in the thisMessage field of POPOPrivKey (see Appendix C) or in the 1582 PKIArchiveOptions control structure, depending upon whether or not 1583 archival of the private key is also desired). 1585 5.2.8.2 Indirect Method 1587 By having the CA return not the certificate, but an encrypted 1588 certificate (i.e., the certificate encrypted under a randomly- 1589 generated symmetric key, and the symmetric key encrypted under the 1590 public key for which the certification request is being made) -- this 1591 is the "indirect" method mentioned previously in Section 4.3.2. The 1592 end entity proves knowledge of the private decryption key to the CA 1593 by providing the correct CertHash for this certificate in the 1594 certConf message. This demonstrates POP because the EE can only 1595 compute the correct CertHash if it is able to recover the 1596 certificate, and it can only recover the certificate if it is able to 1597 decrypt the symmetric key using the required private key. Clearly, 1598 for this to work, the CA MUST NOT publish the certificate until the 1599 certConf message arrives (when certHash is to be used to demonstrate 1600 POP). See Section 5.3.18 for further details. 1602 5.2.8.3 Challenge-Response Protocol 1604 By having the end entity engage in a challenge-response protocol 1605 (using the messages POPODecKeyChall and POPODecKeyResp; see below) 1606 between CertReqMessages and CertRepMessage -- this is the "direct" 1607 method mentioned previously in Section 4.3.2 [This method would 1608 typically be used in an environment in which an RA verifies POP and 1609 then makes a certification request to the CA on behalf of the end 1610 entity. In such a scenario, the CA trusts the RA to have done POP 1611 correctly before the RA requests a certificate for the end entity.] 1612 The complete protocol then looks as follows (note that req' does not 1613 necessarily encapsulate req as a nested message): 1615 EE RA CA 1616 ---- req ----> 1617 <--- chall --- 1618 ---- resp ---> 1619 ---- req' ---> 1620 <--- rep ----- 1621 ---- conf ---> 1622 <--- ack ----- 1623 <--- rep ----- 1624 ---- conf ---> 1625 <--- ack ----- 1627 This protocol is obviously much longer than the 3-way exchange given 1628 in choice (2) above, but allows a local Registration Authority to be 1629 involved and has the property that the certificate itself is not 1630 actually created until the proof of possession is complete. In some 1631 environments a different order of the above messages may be required, 1632 such as the following (this may be determined by policy): 1634 EE RA CA 1635 ---- req ----> 1636 <--- chall --- 1637 ---- resp ---> 1638 ---- req' ---> 1639 <--- rep ----- 1640 <--- rep ----- 1641 ---- conf ---> 1642 ---- conf ---> 1643 <--- ack ----- 1644 <--- ack ----- 1646 If the cert. request is for a key agreement key (KAK) pair, then the 1647 POP can use any of the 3 ways described above for enc. key pairs, 1648 with the following changes: (1) the parenthetical text of bullet 2) 1649 is replaced with "(i.e., the certificate encrypted under the 1650 symmetric key derived from the CA's private KAK and the public key 1651 for which the certification request is being made)"; (2) the first 1652 parenthetical text of the challenge field of "Challenge" below is 1653 replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and 1654 Appendix E.5) and a symmetric key derived from the CA's private KAK 1655 and the public key for which the certification request is being 1656 made)". Alternatively, the POP can use the POPOSigningKey structure 1657 given in [CRMF] (where the alg field is DHBasedMAC and the signature 1658 field is the MAC) as a fourth alternative for demonstrating POP if 1659 the CA already has a D-H certificate that is known to the EE. 1661 The challenge-response messages for proof of possession of a private 1662 decryption key are specified as follows (see [MvOV97], p.404 for 1663 details). Note that this challenge-response exchange is associated 1664 with the preceding cert. request message (and subsequent cert. 1665 response and confirmation messages) by the transactionID used in the 1666 PKIHeader and by the protection (MACing or signing) applied to the 1667 PKIMessage. 1669 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1670 Challenge ::= SEQUENCE { 1671 owf AlgorithmIdentifier OPTIONAL, 1672 witness OCTET STRING, 1673 challenge OCTET STRING 1674 } 1676 Note that the size of Rand needs to be appropriate for encryption 1677 under the public key of the requester. Given that "int" will 1678 typically not be longer than 64 bits, this leaves well over 100 bytes 1679 of room for the "sender" field when the modulus is 1024 bits. If, in 1680 some environment, names are so long that they cannot fit (e.g., very 1681 long DNs), then whatever portion will fit should be used (as long as 1682 it includes at least the common name, and as long as the receiver is 1683 able to deal meaningfully with the abbreviation). 1685 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1687 5.2.8.4 Summary of PoP Options 1689 The text in this section provides several options with respect to POP 1690 techniques. Using "SK" for "signing key", "EK" for "encryption key", 1691 and "KAK" for "key agreement key", the techniques may be summarized 1692 as follows: 1694 RAVerified; 1695 SKPOP; 1696 EKPOPThisMessage; 1697 KAKPOPThisMessage; 1698 KAKPOPThisMessageDHMAC; 1699 EKPOPEncryptedCert; 1700 KAKPOPEncryptedCert; 1701 EKPOPChallengeResp; and 1702 KAKPOPChallengeResp. 1704 Given this array of options, it is natural to ask how an end entity 1705 can know what is supported by the CA/RA (i.e., which options it may 1706 use when requesting certificates). The following guidelines should 1707 clarify this situation for EE implementers. 1709 RAVerified. This is not an EE decision; the RA uses this if and only 1710 if it has verified POP before forwarding the request on to the CA, so 1711 it is not possible for the EE to choose this technique. 1713 SKPOP. If the EE has a signing key pair, this is the only POP method 1714 specified for use in the request for a corresponding certificate. 1716 EKPOPThisMessage and KAKPOPThisMessage. It is an EE decision whether 1717 or not to give up its private key to the CA/RA. If the EE decides to 1718 reveal its key, then these are the only POP methods available in this 1719 specification to achieve this (and the key pair type will determine 1720 which of these two methods to use). 1722 KAKPOPThisMessageDHMAC. The EE can only use this method if (1) the 1723 CA has a DH certificate available for this purpose, and (2) the EE 1724 already has a copy of this certificate. If both these conditions 1725 hold, then this technique is clearly supported and may be used by the 1726 EE, if desired. 1728 EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, 1729 KAKPOPChallengeResp. The EE picks one of these (in the 1730 subsequentMessage field) in the request message, depending upon 1731 preference and key pair type. The EE is not doing POP at this point; 1732 it is simply indicating which method it wants to use. Therefore, if 1733 the CA/RA replies with a "badPOP" error, the EE can re-request using 1734 the other POP method chosen in subsequentMessage. Note, however, 1735 that this specification encourages the use of the EncryptedCert 1736 choice and, furthermore, says that the challenge-response would 1737 typically be used when an RA is involved and doing POP verification. 1738 Thus, the EE should be able to make an intelligent decision regarding 1739 which of these POP methods to choose in the request message. 1741 5.3 Operation-Specific Data Structures 1743 5.3.1 Initialization Request 1745 An Initialization request message contains as the PKIBody a 1746 CertReqMessages data structure which specifies the requested 1747 certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity 1748 are the template fields which may be supplied for each certificate 1749 requested (see Appendix D profiles for further information). This 1750 message is intended to be used for entities first initializing into 1751 the PKI. 1753 See Appendix C and [CRMF] for CertReqMessages syntax. 1755 5.3.2 Initialization Response 1757 An Initialization response message contains as the PKIBody an 1758 CertRepMessage data structure which has for each certificate 1759 requested a PKIStatusInfo field, a subject certificate, and possibly 1760 a private key (normally encrypted with a session key, which is itself 1761 encrypted with the protocolEncrKey). 1763 See Section 5.3.4 for CertRepMessage syntax. Note that if the PKI 1764 Message Protection is "shared secret information" (see Section 1765 5.1.3), then any certificate transported in the caPubs field may be 1766 directly trusted as a root CA certificate by the initiator. 1768 5.3.3 Certification Request 1770 A Certification request message contains as the PKIBody a 1771 CertReqMessages data structure which specifies the requested 1772 certificates. This message is intended to be used for existing PKI 1773 entities who wish to obtain additional certificates. 1775 See Appendix C and [CRMF] for CertReqMessages syntax. 1777 Alternatively, the PKIBody MAY be a CertificationRequest (this 1778 structure is fully specified by the ASN.1 structure 1779 CertificationRequest given in [PKCS10]). This structure may be 1780 required for certificate requests for signing key pairs when 1781 interoperation with legacy systems is desired, but its use is 1782 strongly discouraged whenever not absolutely necessary. 1784 5.3.4 Certification Response 1786 A Certification response message contains as the PKIBody a 1787 CertRepMessage data structure which has a status value for each 1788 certificate requested, and optionally has a CA public key, failure 1789 information, a subject certificate, and an encrypted private key. 1791 CertRepMessage ::= SEQUENCE { 1792 caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate 1793 OPTIONAL, 1794 response SEQUENCE OF CertResponse 1795 } 1797 CertResponse ::= SEQUENCE { 1798 certReqId INTEGER, 1799 status PKIStatusInfo, 1800 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1801 rspInfo OCTET STRING OPTIONAL 1802 -- analogous to the id-regInfo-utf8Pairs string defined 1803 -- for regInfo in CertReqMsg [CRMF] 1804 } 1806 CertifiedKeyPair ::= SEQUENCE { 1807 certOrEncCert CertOrEncCert, 1808 privateKey [0] EncryptedValue OPTIONAL, 1809 -- see [CRMF] for comment on encoding 1810 publicationInfo [1] PKIPublicationInfo OPTIONAL 1811 } 1813 CertOrEncCert ::= CHOICE { 1814 certificate [0] Certificate, 1815 encryptedCert [1] EncryptedValue 1816 } 1818 Only one of the failInfo (in PKIStatusInfo) and certificate (in 1819 CertifiedKeyPair) fields can be present in each CertResponse 1820 (depending on the status). For some status values (e.g., waiting) 1821 neither of the optional fields will be present. 1823 Given an EncryptedCert and the relevant decryption key the 1824 certificate may be obtained. The purpose of this is to allow a CA to 1825 return the value of a certificate, but with the constraint that only 1826 the intended recipient can obtain the actual certificate. The benefit 1827 of this approach is that a CA may reply with a certificate even in 1828 the absence of a proof that the requester is the end entity which can 1829 use the relevant private key (note that the proof is not obtained 1830 until the certConf message is received by the CA). Thus the CA will 1831 not have to revoke that certificate in the event that something goes 1832 wrong with the proof of possession (but MAY do so anyway, depending 1833 upon policy). 1835 5.3.5 Key Update Request Content 1837 For key update requests the CertReqMessages syntax is used. 1838 Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template 1839 fields which may be supplied for each key to be updated. This 1840 message is intended to be used to request updates to existing (non- 1841 revoked and non-expired) certificates (therefore, it is sometimes 1842 referred to as a "Certificate Update" operation). An update is a 1843 replacement certificate containing either a new subject public key or 1844 the current subject public key (although the latter practice may not 1845 be appropriate for some environments). 1847 See Appendix C and [CRMF] for CertReqMessages syntax. 1849 5.3.6 Key Update Response Content 1851 For key update responses the CertRepMessage syntax is used. The 1852 response is identical to the initialization response. 1854 See Section 5.3.4 for CertRepMessage syntax. 1856 5.3.7 Key Recovery Request Content 1858 For key recovery requests the syntax used is identical to the 1859 initialization request CertReqMessages. Typically, 1860 SubjectPublicKeyInfo and KeyId are the template fields which may be 1861 used to supply a signature public key for which a certificate is 1862 required (see Appendix D profiles for further information). 1864 See Appendix C and [CRMF] for CertReqMessages syntax. Note that if a 1865 key history is required, the requester must supply a Protocol 1866 Encryption Key control in the request message. 1868 5.3.8 Key Recovery Response Content 1870 For key recovery responses the following syntax is used. For some 1871 status values (e.g., waiting) none of the optional fields will be 1872 present. 1874 KeyRecRepContent ::= SEQUENCE { 1875 status PKIStatusInfo, 1876 newSigCert [0] Certificate OPTIONAL, 1877 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1878 Certificate OPTIONAL, 1879 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1880 CertifiedKeyPair OPTIONAL 1881 } 1883 5.3.9 Revocation Request Content 1885 When requesting revocation of a certificate (or several certificates) 1886 the following data structure is used. The name of the requester is 1887 present in the PKIHeader structure. 1889 RevReqContent ::= SEQUENCE OF RevDetails 1891 RevDetails ::= SEQUENCE { 1892 certDetails CertTemplate, 1893 crlEntryDetails Extensions OPTIONAL 1894 } 1896 5.3.10 Revocation Response Content 1898 The response to the above message. If produced, this is sent to the 1899 requester of the revocation. (A separate revocation announcement 1900 message MAY be sent to the subject of the certificate for which 1901 revocation was requested.) 1903 RevRepContent ::= SEQUENCE { 1904 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1905 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 1906 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1907 OPTIONAL 1908 } 1910 5.3.11 Cross Certification Request Content 1912 Cross certification requests use the same syntax (CertReqMessages) as 1913 for normal certification requests with the restriction that the key 1914 pair MUST have been generated by the requesting CA and the private 1915 key MUST NOT be sent to the responding CA. This request MAY also be 1916 used by subordinate CAs to get their certificates signed by the 1917 parent CA. 1919 See Appendix C and [CRMF] for CertReqMessages syntax. 1921 5.3.12 Cross Certification Response Content 1923 Cross certification responses use the same syntax (CertRepMessage) as 1924 for normal certification responses with the restriction that no 1925 encrypted private key can be sent. 1927 See Section 5.3.4 for CertRepMessage syntax. 1929 5.3.13 CA Key Update Announcement Content 1931 When a CA updates its own key pair the following data structure MAY 1932 be used to announce this event. 1934 CAKeyUpdAnnContent ::= SEQUENCE { 1935 oldWithNew Certificate, 1936 newWithOld Certificate, 1937 newWithNew Certificate 1938 } 1940 5.3.14 Certificate Announcement 1942 This structure MAY be used to announce the existence of certificates. 1944 Note that this message is intended to be used for those cases (if 1945 any) where there is no pre-existing method for publication of 1946 certificates; it is not intended to be used where, for example, X.500 1947 is the method for publication of certificates. 1949 CertAnnContent ::= Certificate 1951 5.3.15 Revocation Announcement 1953 When a CA has revoked, or is about to revoke, a particular 1954 certificate it MAY issue an announcement of this (possibly upcoming) 1955 event. 1957 RevAnnContent ::= SEQUENCE { 1958 status PKIStatus, 1959 certId CertId, 1960 willBeRevokedAt GeneralizedTime, 1961 badSinceDate GeneralizedTime, 1962 crlDetails Extensions OPTIONAL 1963 } 1965 A CA MAY use such an announcement to warn (or notify) a subject that 1966 its certificate is about to be (or has been) revoked. This would 1967 typically be used where the request for revocation did not come from 1968 the subject concerned. 1970 The willBeRevokedAt field contains the time at which a new entry will 1971 be added to the relevant CRLs. 1973 5.3.16 CRL Announcement 1975 When a CA issues a new CRL (or set of CRLs) the following data 1976 structure MAY be used to announce this event. 1978 CRLAnnContent ::= SEQUENCE OF CertificateList 1980 5.3.17 PKI Confirmation Content 1982 This data structure is used in the protocol exchange as the final 1983 PKIMessage. Its content is the same in all cases - actually there is 1984 no content since the PKIHeader carries all the required information. 1986 PKIConfirmContent ::= NULL 1988 Use of this message for certificate confirmation is NOT RECOMMENDED; 1989 certConf SHOULD be used instead. The recipient on receiving a 1990 PKIConfirm for a certificate response MAY treat it as a certConf with 1991 all certificates being accepted. 1993 5.3.18 Certificate Confirmation Content 1995 This data structure is used by the client to send a confirmation to 1996 the CA/RA to accept or reject certificates. 1998 CertConfirmContent ::= SEQUENCE OF CertStatus 2000 CertStatus ::= SEQUENCE { 2001 certHash OCTET STRING, 2002 certReqId INTEGER, 2003 statusInfo PKIStatusInfo OPTIONAL 2004 } 2006 For any particular CertStatus, omission of the statusInfo field 2007 indicates ACCEPTANCE of the specified certificate. Alternatively, 2008 explicit status details (with respect to acceptance or rejection) MAY 2009 be provided in the statusInfo field, perhaps for auditing purposes at 2010 the CA/RA. 2012 Within CertConfirmContent, omission of a CertStatus structure 2013 corresponding to a certificate supplied in the previous response 2014 message indicates REJECTION of the certificate. Thus, an empty 2015 CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate 2016 rejection of all supplied certificates. See Section 5.2.8, item (2), 2017 for a discussion of the certHash field with respect to 2018 proof-of-possession. 2020 5.3.19 PKI General Message Content 2022 InfoTypeAndValue ::= SEQUENCE { 2023 infoType OBJECT IDENTIFIER, 2024 infoValue ANY DEFINED BY infoType OPTIONAL 2025 } 2026 -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} 2027 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2029 5.3.19.1 CA Protocol Encryption Certificate 2031 This MAY be used by the EE to get from the CA a certificate to use to 2032 protect sensitive information during the protocol. 2034 GenMsg: {id-it 1}, < absent > 2035 GenRep: {id-it 1}, Certificate | < absent > 2037 EEs MUST ensure that the correct certificate is used for this 2038 purpose. 2040 5.3.19.2 Signing Key Pair Types 2042 This MAY be used by the EE to get the list of signature algorithms 2043 (e.g., RSA, DSA) whose subject public key values the CA is willing to 2044 certify. Note that for the purposes of this exchange, rsaEncryption 2045 and rsaWithSHA1, for example, are considered to be equivalent; the 2046 question being asked is, "Is the CA willing to certify an RSA public 2047 key?" 2049 GenMsg: {id-it 2}, < absent > 2050 GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF 2051 AlgorithmIdentifier 2053 5.3.19.3 Encryption/Key Agreement Key Pair Types 2055 This MAY be used by the client to get the list of encryption/key 2056 agreement algorithms whose subject public key values the CA is 2057 willing to certify. 2059 GenMsg: {id-it 3}, < absent > 2060 GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF 2061 AlgorithmIdentifier 2063 5.3.19.4 Preferred Symmetric Algorithm 2065 This MAY be used by the client to get the CA-preferred symmetric 2066 encryption algorithm for any confidential information that needs to 2067 be exchanged between the EE and the CA (for example, if the EE wants 2068 to send its private decryption key to the CA for archival purposes). 2070 GenMsg: {id-it 4}, < absent > 2071 GenRep: {id-it 4}, AlgorithmIdentifier 2073 5.3.19.5 Updated CA Key Pair 2075 This MAY be used by the CA to announce a CA key update event. 2077 GenMsg: {id-it 5}, CAKeyUpdAnnContent 2079 5.3.19.6 CRL 2081 This MAY be used by the client to get a copy of the latest CRL. 2083 GenMsg: {id-it 6}, < absent > 2084 GenRep: {id-it 6}, CertificateList 2086 5.3.19.7 Unsupported Object Identifiers 2088 This is used by the server to return a list of object identifiers 2089 that it does not recognize or support from the list submitted by the 2090 client. 2092 GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 2094 5.3.19.8 Key Pair Parameters 2096 This MAY be used by the EE to request the domain parameters to use 2097 for generating the key pair for certain public-key algorithms. It 2098 can be used, for example, to request the appropriate P, Q and G to 2099 generate the DH/DSA key, or to request a set of well-known elliptic 2100 curves. 2102 GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id) 2103 GenRep: {id-it 11}, AlgorithmIdentifier | < absent > 2105 An absent infoValue in the GenRep indicates that the algorithm 2106 specified in GenMsg is not supported. 2108 EEs MUST ensure that the parameters are acceptable to it and that the 2109 GenRep message is authenticated (to avoid substitution attacks). 2111 5.3.19.9 Revocation Passphrase 2113 This MAY be used by the EE to send a passphrase to a CA/RA for the 2114 purpose of authenticating a later revocation request (in the case 2115 that the appropriate signing private key is no longer available to 2116 authenticate the request). See Appendix B for further details on the 2117 use of this mechanism. 2119 GenMsg: {id-it 12}, EncryptedValue 2120 GenRep: {id-it 12}, < absent > 2122 5.3.19.10 ImplicitConfirm 2124 See Section 5.1.1.1 for the definition and use of {id-it 13}. 2126 5.3.19.11 ConfirmWaitTime 2128 See Section 5.1.1.2 for the definition and use of {id-it 14}. 2130 5.3.19.12 Original PKIMessage 2132 See Section 5.1.3 for the definition and use of {id-it 15}. 2134 5.3.19.13 Supported Language Tags 2136 This MAY be used to determine the appropriate language tag to use in 2137 subsequent messages. The sender sends its list of supported 2138 languages (in order, most preferred to least); the receiver returns 2139 the one it wishes to use. (Note: each UTF8String MUST include a 2140 language tag.) If none of the offered tags are supported, an error 2141 MUST be returned. 2143 GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String 2144 GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String 2146 5.3.20 PKI General Response Content 2148 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2150 Example GenRep that MAY be supported include those listed in the 2151 subsections of Section 5.3.19. 2153 5.3.21 Error Message Content 2155 This data structure MAY be used by EE, CA, or RA to convey error 2156 info. 2158 ErrorMsgContent ::= SEQUENCE { 2159 pKIStatusInfo PKIStatusInfo, 2160 errorCode INTEGER OPTIONAL, 2161 errorDetails PKIFreeText OPTIONAL 2162 } 2164 This message MAY be generated at any time during a PKI transaction. 2165 If the client sends this request the server MUST respond with a 2166 PKIConfirm response, or another ErrorMsg if any part of the header is 2167 not valid. Both sides MUST treat this message as the end of the 2168 transaction (if a transaction is in progress). 2170 If protection is desired on the message, the client MUST protect it 2171 using the same technique (i.e., signature or MAC) as the starting 2172 message of the transaction. The CA MUST always sign it with a 2173 signature key. 2175 5.3.22 Polling Request and Response 2177 This pair of messages is intended to handle scenarios in which the 2178 client needs to poll the server in order to determine the status of 2179 an outstanding ir, cr, or kur transaction (i.e., when the "waiting" 2180 PKIStatus has been received). 2182 PollReqContent ::= SEQUENCE OF SEQUENCE { 2183 certReqId INTEGER } 2185 PollRepContent ::= SEQUENCE OF SEQUENCE { 2186 certReqId INTEGER, 2187 checkAfter INTEGER, -- time in seconds 2188 reason PKIFreeText OPTIONAL } 2190 The following clauses describe when polling messages are used, and 2191 how they are used. It is assumed that multiple certConf messages can 2192 be sent during transactions. There will be one sent in response to 2193 each ip, cp, or kup containing a CertStatus for an issued 2194 certificate. 2196 1. In response to an ip, cp, or kup message, an EE will send a 2197 certConf for all issued certificates and, following the ack, a 2198 pollReq for all pending certificates. 2200 2. In respose to a pollReq, a CA/RA will return an ip, cp, or kup if 2201 one or more of the pending certificates is ready; otherwise, it 2202 will return a pollRep. 2204 3. If the EE receives a pollRep, it will wait for at least as long 2205 as the checkAfter value before sending another pollReq. 2207 4. If an ip, cp, or kup is received in response to a pollReq, then 2208 it will be treated in the same way as the initial response. 2210 START 2211 | 2212 v 2213 Send ir 2214 | ip 2215 v 2216 Check status 2217 of returned <------------------------+ 2218 certs | 2219 | | 2220 +------------------------>|<------------------+ | 2221 | | | | 2222 | (issued) v (waiting) | | 2223 Add to <----------- Check CertResponse ------> Add to | 2224 conf list for each certificate pending list | 2225 /\ | 2226 / \ | 2227 (conf list) / \ (empty conf list) | 2228 / \ ip | 2229 / \ +----------------+ 2230 (empty pending list) / \ | pRep 2231 END <---- Send certConf Send pReq------------>Wait 2232 | ^ ^ | 2233 | | | | 2234 +-----------------+ +---------------+ 2235 (pending list) 2237 In the following exchange, the end entity is enrolling for two 2238 certificates in one request. 2240 Step End Entity PKI 2241 -------------------------------------------------------------------- 2242 1 Format ir 2243 2 -> ir -> 2244 3 Handle ir 2245 4 Manual intervention is 2246 required for both certs. 2247 5 <- ip <- 2248 6 Process ip 2249 7 Format pReq 2250 8 -> pReq -> 2251 9 Check status of cert requests 2252 10 Certificates not ready 2253 11 Format pRep 2254 12 <- pRep <- 2255 13 Wait 2256 14 Format pReq 2257 15 -> pReq -> 2258 16 Check status of cert requests 2259 17 One certificate is ready 2260 18 Format ip 2261 19 <- ip <- 2262 20 Handle ip 2263 21 Format certConf 2264 22 -> certConf -> 2265 23 Handle certConf 2266 24 Format ack 2267 25 <- pkiConf <- 2268 26 Format pReq 2269 27 -> pReq -> 2270 28 Check status of certificate 2271 29 Certificate is ready 2272 30 Format ip 2273 31 <- ip <- 2274 31 Handle ip 2275 32 Format certConf 2276 33 -> certConf -> 2277 34 Handle certConf 2278 35 Format ack 2279 36 <- pkiConf <- 2281 6. Mandatory PKI Management Functions 2283 Some of the PKI management functions outlined in Section 3.1 above 2284 are described in this section. 2286 This section deals with functions that are "mandatory" in the sense 2287 that all end entity and CA/RA implementations MUST be able to provide 2288 the functionality described. This part is effectively the profile of 2289 the PKI management functionality that MUST be supported. Note, 2290 however, that the management functions described in this section do 2291 not need to be accomplished using the PKI messages defined in Section 2292 5 if alternate means are suitable for a given environment (see 2293 Appendix D for profiles of the PKIMessages that MUST be supported). 2295 6.1 Root CA Initialization 2297 [See Section 3.1.1.2 for this document's definition of "root CA".] 2299 A newly created root CA must produce a "self-certificate" which is a 2300 Certificate structure with the profile defined for the "newWithNew" 2301 certificate issued following a root CA key update. 2303 In order to make the CA's self certificate useful to end entities 2304 that do not acquire the self certificate via "out-of-band" means, the 2305 CA must also produce a fingerprint for its certificate. End entities 2306 that acquire this fingerprint securely via some "out-of-band" means 2307 can then verify the CA's self-certificate and hence the other 2308 attributes contained therein. 2310 The data structure used to carry the fingerprint is the OOBCertHash. 2312 6.2 Root CA Key Update 2314 CA keys (as all other keys) have a finite lifetime and will have to 2315 be updated on a periodic basis. The certificates NewWithNew, 2316 NewWithOld, and OldWithNew (see Section 4.4.1) MAY be issued by the 2317 CA to aid existing end entities who hold the current self-signed CA 2318 certificate (OldWithOld) to transition securely to the new self- 2319 signed CA certificate (NewWithNew), and to aid new end entities who 2320 will hold NewWithNew to acquire OldWithOld securely for verification 2321 of existing data. 2323 6.3 Subordinate CA Initialization 2325 [See Section 3.1.1.2 for this document's definition of "subordinate 2326 CA".] 2328 From the perspective of PKI management protocols the initialization 2329 of a subordinate CA is the same as the initialization of an end 2330 entity. The only difference is that the subordinate CA must also 2331 produce an initial revocation list. 2333 6.4 CRL production 2335 Before issuing any certificates a newly established CA (which issues 2336 CRLs) must produce "empty" versions of each CRL which is to be 2337 periodically produced. 2339 6.5 PKI Information Request 2341 When a PKI entity (CA, RA, or EE) wishes to acquire information about 2342 the current status of a CA it MAY send that CA a request for such 2343 information. 2345 The CA MUST respond to the request by providing (at least) all of the 2346 information requested by the requester. If some of the information 2347 cannot be provided then an error must be conveyed to the requester. 2349 If PKIMessages are used to request and supply this PKI information, 2350 then the request MUST be the GenMsg message, the response MUST be the 2351 GenRep message, and the error MUST be the Error message. These 2352 messages are protected using a MAC based on shared secret information 2353 (i.e., PasswordBasedMAC) or any other authenticated means (if the end 2354 entity has an existing certificate). 2356 6.6 Cross Certification 2358 The requester CA is the CA that will become the subject of the 2359 cross-certificate; the responder CA will become the issuer of the 2360 cross-certificate. 2362 The requester CA must be "up and running" before initiating the 2363 cross-certification operation. 2365 6.6.1 One-Way Request-Response Scheme: 2367 The cross-certification scheme is essentially a one way operation; 2368 that is, when successful, this operation results in the creation of 2369 one new cross-certificate. If the requirement is that cross- 2370 certificates be created in "both directions" then each CA in turn 2371 must initiate a cross-certification operation (or use another 2372 scheme). 2374 This scheme is suitable where the two CAs in question can already 2375 verify each other's signatures (they have some common points of 2376 trust) or where there is an out-of-band verification of the origin of 2377 the certification request. 2379 Detailed Description: 2381 Cross certification is initiated at one CA known as the responder. 2382 The CA administrator for the responder identifies the CA it wants to 2383 cross certify and the responder CA equipment generates an 2384 authorization code. The responder CA administrator passes this 2385 authorization code by out-of-band means to the requester CA 2386 administrator. The requester CA administrator enters the 2387 authorization code at the requester CA in order to initiate the on- 2388 line exchange. 2390 The authorization code is used for authentication and integrity 2391 purposes. This is done by generating a symmetric key based on the 2392 authorization code and using the symmetric key for generating Message 2393 Authentication Codes (MACs) on all messages exchanged. 2394 (Authentication may alternatively be done using signatures instead of 2395 MACs, if the CAs are able to retrieve and validate the required 2396 public keys by some means, such as an out-of-band hash comparison.) 2398 The requester CA initiates the exchange by generating a cross- 2399 certification request (ccr) with a fresh random number(requester 2400 random number). The requester CA then sends to the responder CA the 2401 ccr message. The fields in this message are protected from 2402 modification with a MAC based on the authorization code. 2404 Upon receipt of the ccr message, the responder CA validates the 2405 message and the MAC, saves the requester random number, and generates 2406 its own random number (responder random number). It then generates 2407 (and archives, if desired) a new requester certificate that contains 2408 the requester CA public key and is signed with the responder CA 2409 signature private key. The responder CA responds with the cross 2410 certification response (ccp) message. The fields in this message are 2411 protected from modification with a MAC based on the authorization 2412 code. 2414 Upon receipt of the ccp message, the requester CA validates the 2415 message (including the received random numbers) and the MAC. The 2416 requester CA responds with the certConf message. The fields in this 2417 message are protected from modification with a MAC based on the 2418 authorization code. The requester CA MAY write the requester 2419 certificate to the Repository as an aid to later certificate path 2420 construction. 2422 Upon receipt of the certConf message, the responder CA validates the 2423 message and the MAC, and sends back an acknowledgment using the 2424 PKIConfirm message. It MAY also publish the requester certificate as 2425 an aid to later path construction. 2427 Notes: 2429 1. The ccr message must contain a "complete" certification request, 2430 that is, all fields except the serial number (including, e.g., a 2431 BasicConstraints extension) must be specified by the requester 2432 CA. 2434 2. The ccp message SHOULD contain the verification certificate of 2435 the responder CA - if present, the requester CA must then verify 2436 this certificate (for example, via the "out-of-band" mechanism). 2438 (A simpler, non-interactive model of cross-certification may also be 2439 envisioned, in which the issuing CA acquires the subject CA's public 2440 key from some repository, verifies it via some out-of-band mechanism, 2441 and creates and publishes the cross-certificate without the subject 2442 CA's explicit involvement. This model may be perfectly legitimate 2443 for many environments, but since it does not require any protocol 2444 message exchanges, its detailed description is outside the scope of 2445 this specification.) 2447 6.7 End Entity Initialization 2449 As with CAs, end entities must be initialized. Initialization of end 2450 entities requires at least two steps: 2452 o acquisition of PKI information 2454 o out-of-band verification of one root-CA public key 2456 (other possible steps include the retrieval of trust condition 2457 information and/or out-of-band verification of other CA public keys). 2459 6.7.1 Acquisition of PKI Information 2461 The information REQUIRED is: 2463 o the current root-CA public key 2465 o (if the certifying CA is not a root-CA) the certification path 2466 from the root CA to the certifying CA together with appropriate 2467 revocation lists 2469 o the algorithms and algorithm parameters which the certifying CA 2470 supports for each relevant usage 2472 Additional information could be required (e.g., supported extensions 2473 or CA policy information) in order to produce a certification request 2474 which will be successful. However, for simplicity we do not mandate 2475 that the end entity acquires this information via the PKI messages. 2476 The end result is simply that some certification requests may fail 2477 (e.g., if the end entity wants to generate its own encryption key but 2478 the CA doesn't allow that). 2480 The required information MAY be acquired as described in Section 6.5. 2482 6.7.2 Out-of-Band Verification of Root-CA Key 2484 An end entity must securely possess the public key of its root CA. 2485 One method to achieve this is to provide the end entity with the CA's 2486 self-certificate fingerprint via some secure "out-of-band" means. The 2487 end entity can then securely use the CA's self-certificate. 2489 See Section 6.1 for further details. 2491 6.8 Certificate Request 2493 An initialized end entity MAY request an additional certificate at 2494 any time (for any purpose). This request will be made using the 2495 certification request (cr) message. If the end entity already 2496 possesses a signing key pair (with a corresponding verification 2497 certificate), then this cr message will typically be protected by the 2498 entity's digital signature. The CA returns the new certificate (if 2499 the request is successful) in a CertRepMessage. 2501 6.9 Key Update 2503 When a key pair is due to expire the relevant end entity MAY request 2504 a key update - that is, it MAY request that the CA issue a new 2505 certificate for a new key pair (or, in certain circumstances, a new 2506 certificate for the same key pair). The request is made using a key 2507 update request (kur) message (referred to, in some environments, as a 2508 "Certificate Update" operation). If the end entity already possesses 2509 a signing key pair (with a corresponding verification certificate), 2510 then this message will typically be protected by the entity's digital 2511 signature. The CA returns the new certificate (if the request is 2512 successful) in a key update response (kup) message, which is 2513 syntactically identical to a CertRepMessage. 2515 7. Version Negotiation 2517 This section defines version negotiation used to support older 2518 protocols between client and servers. 2520 If a client knows the protocol version(s) supported by the server 2521 (e.g. from a previous PKIMessage exchange or via some out-of-band 2522 means) then it MUST send a PKIMessage with the highest version 2523 supported by both it and the server. If a client does not know what 2524 version(s) the server supports then it MUST send a PKIMessage using 2525 the highest version it supports. 2527 If a server receives a message with a version that it supports, then 2528 the version of the response message MUST be the same as the received 2529 version. If a server receives a message with a version higher or 2530 lower than it supports, then it MUST send back an ErrorMsg with the 2531 unsupportedVersion bit set (in the failureInfo field of the 2532 pKIStatusInfo). If the received version is higher than the highest 2533 supported version then the version in the error message MUST be the 2534 highest version the server supports; if the received version is lower 2535 than the lowest supported version then the version in the error 2536 message MUST be the lowest version the server supports. 2538 If a client gets back an ErrorMsgContent with the unsupportedVersion 2539 bit set and a version it supports, then it MAY retry the request with 2540 that version. 2542 7.1 Supporting RFC 2510 Implementations 2544 RFC 2510 did not specify the behaviour of implementations receiving 2545 versions they did not understand since there was only one version in 2546 existence. With the introduction of the present revision of the 2547 specification, the following versioning behaviour is recommended. 2549 7.1.1 Clients Talking to RFC 2510 Servers 2551 If, after sending a cmp2000 message, a client receives an 2552 ErrorMsgContent with a version of cmp1999 then it MUST abort the 2553 current transaction. It MAY subsequently retry the transaction using 2554 version cmp1999 messages. 2556 If client receives a non-error PKIMessage with a version of cmp1999 2557 then it MAY decide to continue the transaction (if the transaction 2558 hasn't finished) using RFC 2510 semantics. If it does not choose to 2559 do so and the transaction is not finished, then it MUST abort the 2560 transaction and send an ErrorMsgContent with a version of cmp1999. 2562 7.1.2 Servers Receiving Version cmp1999 PKIMessages 2564 If a server receives a version cmp1999 message it MAY revert to RFC 2565 2510 behaviour and respond with version cmp1999 messages. If it does 2566 not choose to do so, then it MUST send back an ErrorMsgContent as 2567 described above in Section 7. 2569 8. Security Considerations 2571 8.1 Proof-Of-Possesion with a Decryption Key 2573 Some cryptographic considerations are worth explicitly spelling out. 2574 In the protocols specified above, when an end entity is required to 2575 prove possession of a decryption key, it is effectively challenged to 2576 decrypt something (its own certificate). This scheme (and many 2577 others!) could be vulnerable to an attack if the possessor of the 2578 decryption key in question could be fooled into decrypting an 2579 arbitrary challenge and returning the cleartext to an attacker. 2580 Although in this specification a number of other failures in security 2581 are required in order for this attack to succeed, it is conceivable 2582 that some future services (e.g., notary, trusted time) could 2583 potentially be vulnerable to such attacks. For this reason we re- 2584 iterate the general rule that implementations should be very careful 2585 about decrypting arbitrary "ciphertext" and revealing recovered 2586 "plaintext" since such a practice can lead to serious security 2587 vulnerabilities. 2589 8.2 Proof-Of-Possession by Exposing the Private Key 2591 Note also that exposing a private key to the CA/RA as a proof-of- 2592 possession technique can carry some security risks (depending upon 2593 whether or not the CA/RA can be trusted to handle such material 2594 appropriately). Implementers are advised to: 2596 Exercise caution in selecting and using this particular POP 2597 mechanism 2599 When appropriate, have the user of the application explicitly 2600 state that they are willing to trust the CA/RA to have a copy of 2601 their private key before proceeding to reveal the private key. 2603 8.3 Attack Against Diffie-Hellman Key Exchange 2605 A small subgroup attack during a Diffie-Hellman key exchange may be 2606 carried out as follows. A malicious end entity may deliberately 2607 choose D-H parameters that enable him/her to derive (a significant 2608 number of bits of) the D-H private key of the CA during a key 2609 archival or key recovery operation. Armed with this knowledge, the 2610 EE would then be able to retrieve the decryption private key of 2611 another unsuspecting end entity, EE2, during EE2's legitimate key 2612 archival or key recovery operation with that CA. In order to avoid 2613 the possibility of such an attack, two courses of action are 2614 available. (1) The CA may generate a fresh D-H key pair to be used 2615 as a protocol encryption key pair for each EE with which it 2616 interacts. (2) The CA may enter into a key validation protocol (not 2617 specified in this document) with each requesting end entity to ensure 2618 that the EE's protocol encryption key pair will not facilitate this 2619 attack. Option (1) is clearly simpler (requiring no extra protocol 2620 exchanges from either party) and is therefore RECOMMENDED. 2622 9. IANA considerations 2624 The PKI General Message types are identified by object identifiers 2625 (OIDs). The OIDs for the PKI General Message types defined in this 2626 document were assigned from an arc delegated by the IANA to the PKIX 2627 Working Group. 2629 The cryptographic algorithms referred to in this document are 2630 identified by object identifiers (OIDs). The OIDs for cryptographic 2631 algorithms were assigned from several arcs owned by various 2632 organizations, including RSA Security, Entrust Technologies, IANA and 2633 IETF. 2635 Should additional encryption algorithms be introduced, the advocates 2636 for such algorithms are expected to assign the necessary OIDs from 2637 their own arcs. 2639 No further action by the IANA is necessary for this document or any 2640 anticipated updates. 2642 Normative References 2644 [X509] International Organization for Standardization and 2645 International Telecommunications Union, "Information 2646 technology - Open Systems Interconnection - The Directory: 2647 Public-key and attribute certificate frameworks", ISO 2648 Standard 9594-8:2001, ITU-T Recommendation X.509, March 2649 2000. 2651 [MvOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook 2652 of Applied Cryptography", CRC Press ISBN 0-8493-8523-7, 2653 1996. 2655 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 2656 Keyed-Hashing for Message Authentication", RFC 2104, 2657 February 1997. 2659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2660 Requirement Levels", BCP 14, RFC 2119, March 1997. 2662 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and 2663 HMAC-SHA-1", RFC 2202, September 1997. 2665 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2666 10646", STD 63, RFC 3629, November 2003. 2668 [RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode 2669 Plain Text", RFC 2482, January 1999. 2671 [CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet 2672 X.509 Certificate Request Message Format", 2673 draft-ietf-pkix-rfc2511bis 07, January 0000. 2675 [RFC3066] Alvestrand, H., "Tags for the Identification of 2676 Languages", BCP 47, RFC 3066, January 2001. 2678 Informative References 2680 [CMPtrans] 2681 Kapoor, A., Tschalar, R. and T. Kause, "Internet X.509 2682 Public Key Infrastructure -- Transport Protocols for 2683 CMP", draft-ietf-pkix-cmp-transport-protocols 05, February 2684 2004. 2686 [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards - 2687 Cryptographic Message Syntax Standard. Version 1.5", PKCS 2688 7, November 1993. 2690 [PKCS10] Nystrom, M., Kaliski, B. and RSA Laboratories, RSA Data 2691 Security Inc., "The Public-Key Cryptography Standards - 2692 Certification Request Syntax Standard. Version 1.7", PKCS 2693 10, RFC 2986, May 2000. 2695 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 2696 Cryptographic Token Interface Standard. Version 2.10", 2697 PKCS 11, December 1999. 2699 [RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, 2700 "Security Multiparts for MIME: Multipart/Signed and 2701 Multipart/Encrypted", RFC 1847, October 1995. 2703 [RFC2559] Boeyen, S., Howes, T. and P. Richard, "Internet X.509 2704 Public Key Infrastructure Operational Protocols - LDAPv2", 2705 RFC 2559, April 1999. 2707 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 2708 Infrastructure Operational Protocols: FTP and HTTP", RFC 2709 2585, May 1999. 2711 [FIPS-180] 2712 National Institute of Standards and Technology, "Secure 2713 Hash Standard", FIPS PUB 180-1, May 1994. 2715 [FIPS-186] 2716 National Institute of Standards and Technology, "Digital 2717 Signature Standard", FIPS PUB 186, May 1994. 2719 [ANSI-X9.42] 2720 American National Standards Institute, "Public Key 2721 Cryptography for The Financial Services Industry: 2722 Agreement of Symmetric Keys Using Discrete Logarithm 2723 Cryptography", ANSI X9.42, February 2000. 2725 Authors' Addresses 2727 Carlisle Adams 2728 University of Ottawa 2729 800 King Edward Avenue 2730 P.O.Box 450, Station A 2731 Ottawa, Ontario K1N 6N5 2732 CA 2734 Phone: (613) 562-5800 ext. 2345 2735 Fax: (613) 562-5664 2736 EMail: cadams@site.uottawa.ca 2738 Stephen Farrell 2739 Trinity College Dublin 2740 Distributed Systems Group 2741 Computer Science Department 2742 Dublin 2743 IE 2745 Phone: +353-1-608-3070 2746 EMail: stephen.farrell@cs.tcd.ie 2748 Tomi Kause 2749 SSH Communications Security Corp. 2750 Fredrikinkatu 42 2751 Helsinki 00100 2752 FI 2754 Phone: +358 20 500 7415 2755 EMail: toka@ssh.com 2757 Tero Mononen 2758 SafeNet, Inc. 2759 Fredrikinkatu 42 2760 Helsinki 00100 2761 FI 2763 EMail: tmononen@safenet-inc.com 2765 Appendix A. Reasons for the Presence of RAs 2767 The reasons which justify the presence of an RA can be split into 2768 those which are due to technical factors and those which are 2769 organizational in nature. Technical reasons include the following. 2771 o If hardware tokens are in use, then not all end entities will have 2772 the equipment needed to initialize these; the RA equipment can 2773 include the necessary functionality (this may also be a matter of 2774 policy). 2776 o Some end entities may not have the capability to publish 2777 certificates; again, the RA may be suitably placed for this. 2779 o The RA will be able to issue signed revocation requests on behalf 2780 of end entities associated with it, whereas the end entity may not 2781 be able to do this (if the key pair is completely lost). 2783 Some of the organizational reasons which argue for the presence of an 2784 RA are the following. 2786 o It may be more cost effective to concentrate functionality in the 2787 RA equipment than to supply functionality to all end entities 2788 (especially if special token initialization equipment is to be 2789 used). 2791 o Establishing RAs within an organization can reduce the number of 2792 CAs required, which is sometimes desirable. 2794 o RAs may be better placed to identify people with their 2795 "electronic" names, especially if the CA is physically remote from 2796 the end entity. 2798 o For many applications there will already be in place some 2799 administrative structure so that candidates for the role of RA are 2800 easy to find (which may not be true of the CA). 2802 Appendix B. The Use of Revocation Passphrase 2804 A revocation request must incorporate suitable security mechanisms, 2805 including proper authentication, in order to reduce the probability 2806 of successful denial-of-service attacks. A digital signature on the 2807 request - MANDATORY to support within this specification if 2808 revocation requests are supported - can provide the authentication 2809 required, but there are circumstances under which an alternative 2810 mechanism may be desirable (e.g., when the private key is no longer 2811 accessible and the entity wishes to request a revocation prior to 2812 re-certification of another key pair). In order to accommodate such 2813 circumstances, a PasswordBasedMAC on the request is also MANDATORY to 2814 support within this specification (subject to local security policy 2815 for a given environment) if revocation requests are supported and if 2816 shared secret information can be established between the requester 2817 and the responder prior to the need for revocation. 2819 A mechanism that has seen use in some environments is "revocation 2820 passphrase", in which a value of sufficient entropy (i.e., a 2821 relatively long passphrase rather than a short password) is shared 2822 between (only) the entity and the CA/RA at some point prior to 2823 revocation, and this value is later used to authenticate the 2824 revocation request. 2826 In this specification, the following technique to establish shared 2827 secret information (i.e., a revocation passphrase) is OPTIONAL to 2828 support. Its precise use in CMP messages is as follows. 2830 o The OID and value specified in Section 5.3.19.9 MAY be sent in a 2831 GenMsg message at any time, or MAY be sent in the generalInfo 2832 field of the PKIHeader of any PKIMessage at any time. (In 2833 particular, the EncryptedValue may be sent in the header of the 2834 certConf message that confirms acceptance of certificates 2835 requested in an initialization request or certificate request 2836 message.) This conveys a revocation passphrase chosen by the 2837 entity (i.e., the decrypted bytes of the encValue field) to the 2838 relevant CA/RA; furthermore, the transfer is accomplished with 2839 appropriate confidentiality characteristics (since the passphrase 2840 is encrypted under the CA/RA's protocolEncryptionKey). 2842 o If a CA/RA receives the revocation passphrase (OID and value 2843 specified in Section 5.3.19.9) in a GenMsg, it MUST construct and 2844 send a GenRep message which includes the OID (with absent value) 2845 specified in Section Section 5.3.19.9. If the CA/RA receives the 2846 revocation passphrase in the generalInfo field of a PKIHeader of 2847 any PKIMessage, it MUST include the OID (with absent value) in the 2848 generalInfo field of the PKIHeader of the corresponding response 2849 PKIMessage. If the CA/RA is unable to return the appropriate 2850 response message for any reason, it MUST send an error message 2851 with a status of "rejection" and, optionally, a failInfo reason 2852 set. 2854 o The valueHint field of EncryptedValue MAY contain a key identifier 2855 (chosen by the entity, along with the passphrase itself) to assist 2856 in later retrieval of the correct passphrase (e.g., when the 2857 revocation request is constructed by the entity and received by 2858 the CA/RA). 2860 o The revocation request message is protected by a PasswordBasedMAC, 2861 with the revocation passphrase as the key. If appropriate, the 2862 senderKID field in the PKIHeader MAY contain the value previously 2863 transmitted in valueHint. 2865 Using the technique specified above, the revocation passphrase may be 2866 initially established and updated at any time without requiring extra 2867 messages or out-of-band exchanges. For example, the revocation 2868 request message itself (protected and authenticated through a MAC 2869 that uses the revocation passphrase as a key) may contain in the 2870 PKIHeader a new revocation passphrase to be used for authenticating 2871 future revocation requests for any of the entity's other 2872 certificates. In some environments this may be preferable to 2873 mechanisms that reveal the passphrase in the revocation request 2874 message, since this can allow a denial-of-service attack in which the 2875 revealed passphrase is used by an unauthorized third party to 2876 authenticate revocation requests on the entity's other certificates. 2877 However, because the passphrase is not revealed in the request 2878 message, there is no requirement that the passphrase must always be 2879 updated when a revocation request is made (that is, the same 2880 passphrase MAY be used by an entity to authenticate revocation 2881 requests for different certificates at different times). 2883 Furthermore, the above technique can provide strong cryptographic 2884 protection over the entire revocation request message even when a 2885 digital signature is not used. Techniques that do authentication of 2886 the revocation request by simply revealing the revocation passphrase 2887 typically do not provide cryptographic protection over the fields of 2888 the request message (so that a request for revocation of one 2889 certificate may be modified by an unauthorized third party to a 2890 request for revocation of another certificate for that entity). 2892 Appendix C. Request Message Behavioral Clarifications 2894 In the case of updates to [CRMF] which cause interpretation or 2895 interoperability issues, [CRMF] SHALL be the normative document. 2897 The following definitions are from [CRMF]. They are included here in 2898 order to codify behavioral clarifications to that request message; 2899 otherwise, all syntax and semantics are identical to [CRMF]. 2901 CertRequest ::= SEQUENCE { 2902 certReqId INTEGER, 2903 certTemplate CertTemplate, 2904 controls Controls OPTIONAL } 2906 -- If certTemplate is an empty SEQUENCE (i.e., all fields 2907 -- omitted), then controls MAY contain the 2908 -- id-regCtrl-altCertTemplate control, specifying a template 2909 -- for a certificate other than an X.509v3 public-key 2910 -- certificate. Conversely, if certTemplate is not empty 2911 -- (i.e., at least one field is present), then controls MUST 2912 -- NOT contain id-regCtrl- altCertTemplate. The new control is 2913 -- defined as follows: 2915 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7} 2916 AltCertTemplate ::= AttributeTypeAndValue 2918 POPOSigningKey ::= SEQUENCE { 2919 poposkInput [0] POPOSigningKeyInput OPTIONAL, 2920 algorithmIdentifier AlgorithmIdentifier, 2921 signature BIT STRING } 2923 -- ********** 2924 -- * For the purposes of this specification, the ASN.1 comment 2925 -- * given in [CRMF] pertains not only to certTemplate, but 2926 -- * also to the altCertTemplate control. That is, 2927 -- ********** 2928 -- * The signature (using "algorithmIdentifier") is on the 2929 -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs 2930 -- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg 2931 -- * certReq certTemplate (or the altCertTemplate control) 2932 -- * contains the subject and publicKey values, then poposkInput 2933 -- * MUST be omitted and the signature MUST be computed on the 2934 -- * DER-encoded value of CertReqMsg certReq (or the DER- 2935 -- * encoded value of AltCertTemplate). If 2936 -- * certTemplate/altCertTemplate does not contain both the 2937 -- * subject and public key values (i.e., if it contains only 2938 -- * one of these, or neither), then poposkInput MUST be present 2939 -- * and MUST be signed. 2940 -- ********** 2942 POPOPrivKey ::= CHOICE { 2943 thisMessage [0] BIT STRING, 2945 -- ********** 2946 -- * the type of "thisMessage" is given as BIT STRING in 2947 -- * [CRMF]; it should be "EncryptedValue" (in accordance 2948 -- * with Section 5.2.2, "Encrypted Values", of this specification). 2950 -- * Therefore, this document makes the behavioral clarification 2951 -- * of specifying that the contents of "thisMessage" MUST be encoded 2952 -- * as an EncryptedValue and then wrapped in a BIT STRING. This 2953 -- * allows the necessary conveyance and protection of the 2954 -- * private key while maintaining bits-on-the-wire compatibility 2955 -- * with [CRMF]. 2957 -- ********** 2958 subsequentMessage [1] SubsequentMessage, 2959 dhMAC [2] BIT STRING } 2961 Appendix D. PKI Management Message Profiles (REQUIRED). 2963 This appendix contains detailed profiles for those PKIMessages which 2964 MUST be supported by conforming implementations (see Section 6). 2966 Profiles for the PKIMessages used in the following PKI management 2967 operations are provided: 2969 o initial registration/certification 2971 o basic authenticated scheme 2973 o certificate request 2975 o key update 2977 D.1 General Rules for Interpretation of These Profiles. 2979 1. Where OPTIONAL or DEFAULT fields are not mentioned in individual 2980 profiles, they SHOULD be absent from the relevant message (i.e., 2981 a receiver can validly reject a message containing such fields as 2982 being syntactically incorrect). Mandatory fields are not 2983 mentioned if they have an obvious value (e.g., in this version of 2984 the specification, pvno is always 2). 2986 2. Where structures occur in more than one message, they are 2987 separately profiled as appropriate. 2989 3. The algorithmIdentifiers from PKIMessage structures are profiled 2990 separately. 2992 4. A "special" X.500 DN is called the "NULL-DN"; this means a DN 2993 containing a zero-length SEQUENCE OF RelativeDistinguishedNames 2994 (its DER encoding is then '3000'H). 2996 5. Where a GeneralName is required for a field but no suitable value 2997 is available (e.g., an end entity produces a request before 2998 knowing its name) then the GeneralName is to be an X.500 NULL-DN 2999 (i.e., the Name field of the CHOICE is to contain a NULL-DN). 3000 This special value can be called a "NULL-GeneralName". 3002 6. Where a profile omits to specify the value for a GeneralName 3003 then the NULL-GeneralName value is to be present in the 3004 relevant PKIMessage field. This occurs with the sender field of 3005 the PKIHeader for some messages. 3007 7. Where any ambiguity arises due to naming of fields, the profile 3008 names these using a "dot" notation (e.g., "certTemplate.subject" 3009 means the subject field within a field called certTemplate). 3011 8. Where a "SEQUENCE OF types" is part of a message, a zero-based 3012 array notation is used to describe fields within the SEQUENCE OF 3013 (e.g., crm[0].certReq.certTemplate.subject refers to a subfield 3014 of the first CertReqMsg contained in a request message). 3016 9. All PKI message exchanges in Appendix D.4 - Appendix D.6 require 3017 a certConf message to be sent by the initiating entity and a 3018 PKIConfirm to be sent by the responding entity. The PKIConfirm is 3019 not included in some of the profiles given since its body is NULL 3020 and its header contents are clear from the context. Any 3021 authenticated means can be used for the protectionAlg (e.g., 3022 password-based MAC, if shared secret information is known, or 3023 signature). 3025 D.2 Algorithm Use Profile 3027 The following table contains definitions of algorithm uses within PKI 3028 management protocols. The columns in the table are: 3030 Name: an identifier used for message profiles 3032 Use: description of where and for what the algorithm is used 3034 Mandatory: an AlgorithmIdentifier which MUST be supported by 3035 conforming implementations 3037 Others: alternatives to the mandatory AlgorithmIdentifier 3038 Name Use Mandatory Others 3040 MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5, 3041 messages using signature ECDSA, ... 3042 MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC, 3043 messages using MACing X9.9... 3044 SYM_PENC_ALG symmetric encryption of 3-DES (3-key- AES,RC5, 3045 an end entity's private EDE, CBC mode) CAST-128... 3046 key where symmetric 3047 key is distributed 3048 out-of-band 3049 PROT_ENC_ALG asymmetric algorithm D-H RSA, 3050 used for encryption of ECDH, ... 3051 (symmetric keys for 3052 encryption of) private 3053 keys transported in 3054 PKIMessages 3055 PROT_SYM_ALG symmetric encryption 3-DES (3-key- AES,RC5, 3056 algorithm used for EDE, CBC mode) CAST-128... 3057 encryption of private 3058 key bits (a key of this 3059 type is encrypted using 3060 PROT_ENC_ALG) 3062 Mandatory AlgorithmIdentifiers and Specifications: 3064 DSA/SHA-1: 3065 AlgId: {1 2 840 10040 4 3}; 3067 Digital Signature Standard [FIPS-186] 3069 Public Modulus size: 1024 bits. 3071 PasswordBasedMac: 3073 AlgId: {1 2 840 113533 7 66 13}, 3074 with SHA-1 {1 3 14 3 2 26} as the owf parameter 3075 and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter; 3077 (this specification), along with 3079 Secure Hash Standard [FIPS-180] and [RFC2104] 3080 HMAC key size: 160 bits (i.e., "K" = "H" in Section 5.1.3.1, 3081 "Shared secret information") 3083 3-DES: 3085 AlgId: {1 2 840 113549 3 7}; 3086 (used in RSA's BSAFE and in S/MIME). 3088 D-H: 3090 AlgId: {1 2 840 10046 2 1}; 3092 [ANSI-X9.42] 3094 Public Modulus Size: 1024 bits. 3095 DomainParameters ::= SEQUENCE { 3096 p INTEGER, -- odd prime, p=jq +1 3097 g INTEGER, -- generator, g^q = 1 mod p 3098 q INTEGER, -- prime factor of p-1 3099 j INTEGER OPTIONAL, -- cofactor, j>=2 3100 validationParms ValidationParms OPTIONAL 3101 } 3102 ValidationParms ::= SEQUENCE { 3103 seed BIT STRING, -- seed for prime generation 3104 pGenCounter INTEGER -- parameter verification 3105 } 3107 D.3 Proof of Possession Profile 3109 POP fields for use (in signature field of pop field of 3110 ProofOfPossession structure) when proving possession of a private 3111 signing key which corresponds to a public verification key for which 3112 a certificate has been requested. 3114 Field Value Comment 3116 algorithmIdentifier MSG_SIG_ALG only signature protection is 3117 allowed for this proof 3119 signature present bits calculated using MSG_SIG_ALG 3121 Proof of possession of a private decryption key which corresponds to 3122 a public encryption key for which a certificate has been requested 3123 does not use this profile; the CertHash field of the certConf message 3124 is used instead. 3126 Not every CA/RA will do Proof-of-Possession (of signing key, 3127 decryption key, or key agreement key) in the PKIX-CMP in-band 3128 certification request protocol (how POP is done MAY ultimately be a 3129 policy issue which is made explicit for any given CA in its 3130 publicized Policy OID and Certification Practice Statement). 3131 However, this specification MANDATES that CA/RA entities MUST do POP 3132 (by some means) as part of the certification process. All end 3133 entities MUST be prepared to provide POP (i.e., these components of 3134 the PKIX-CMP protocol MUST be supported). 3136 D.4 Initial Registration/Certification (Basic Authenticated Scheme) 3138 An (uninitialized) end entity requests a (first) certificate from a 3139 CA. When the CA responds with a message containing a certificate, the 3140 end entity replies with a certificate confirmation. The CA sends a 3141 PKIConfirm back, closing the transaction. All messages are 3142 authenticated. 3144 This scheme allows the end entity to request certification of a 3145 locally-generated public key (typically a signature key). The end 3146 entity MAY also choose to request the centralized generation and 3147 certification of another key pair (typically an encryption key pair). 3149 Certification may only be requested for one locally generated public 3150 key (for more, use separate PKIMessages). 3152 The end entity MUST support proof-of-possession of the private key 3153 associated with the locally-generated public key. 3155 Preconditions: 3157 1. The end entity can authenticate the CA's signature based on 3158 out-of-band means 3160 2. The end entity and the CA share a symmetric MACing key 3161 Message flow: 3163 Step# End entity PKI 3164 1 format ir 3165 2 -> ir -> 3166 3 handle ir 3167 4 format ip 3168 5 <- ip <- 3169 6 handle ip 3170 7 format certConf 3171 8 -> certConf -> 3172 9 handle certConf 3173 10 format PKIConf 3174 11 <- PKIConf <- 3175 12 handle PKIConf 3177 For this profile, we mandate that the end entity MUST include all 3178 (i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI 3179 (CA) MUST produce a single response PKIMessage which contains the 3180 complete response (i.e., including the OPTIONAL second key pair, if 3181 it was requested and if centralized key generation is supported). For 3182 simplicity, we also mandate that this message MUST be the final one 3183 (i.e., no use of "waiting" status value). 3185 The end entity has an out of band interaction with the CA/RA. This 3186 transaction established the shared secret, the referenceNumber and 3187 OPTIONALLY the distinguished name used for both sender and subject 3188 name in the certificate template. It is RECOMMENDED that the shared 3189 secret be at least 12 characters long. 3191 Initialization Request -- ir 3193 Field Value 3195 recipient CA name 3196 -- the name of the CA who is being asked to produce a certificate 3197 protectionAlg MSG_MAC_ALG 3198 -- only MAC protection is allowed for this request, based 3199 -- on initial authentication key 3200 senderKID referenceNum 3201 -- the reference number which the CA has previously issued 3202 -- to the end entity (together with the MACing key) 3203 transactionID present 3204 -- implementation-specific value, meaningful to end 3205 -- entity. 3206 -- [If already in use at the CA then a rejection message MUST 3207 -- be produced by the CA] 3209 senderNonce present 3210 -- 128 (pseudo-)random bits 3211 freeText any valid value 3212 body ir (CertReqMessages) 3213 only one or two CertReqMsg 3214 are allowed 3215 -- if more certificates are required requests MUST be 3216 -- packaged in separate PKIMessages 3218 CertReqMsg one or two present 3219 -- see below for details, note: crm[0] means the first 3220 -- (which MUST be present), crm[1] means the second (which 3221 -- is OPTIONAL, and used to ask for a centrally-generated key) 3223 crm[0].certReq. fixed value of zero 3224 certReqId 3225 -- this is the index of the template within the message 3226 crm[0].certReq present 3227 certTemplate 3228 -- MUST include subject public key value, otherwise unconstrained 3229 crm[0].pop... optionally present if public key 3230 POPOSigningKey from crm[0].certReq.certTemplate is 3231 a signing key 3232 -- proof of possession MAY be required in this exchange 3233 -- (see Appendix D.3 for details) 3234 crm[0].certReq. optionally present 3235 controls.archiveOptions 3236 -- the end entity MAY request that the locally-generated 3237 -- private key be archived 3239 crm[0].certReq. optionally present 3240 controls.publicationInfo 3241 -- the end entity MAY ask for publication of resulting cert. 3243 crm[1].certReq fixed value of one 3244 certReqId 3245 -- the index of the template within the message 3246 crm[1].certReq present 3247 certTemplate 3248 -- MUST NOT include actual public key bits, otherwise 3249 -- unconstrained (e.g., the names need not be the same as in 3250 -- crm[0]). Note that subjectPublicKeyInfo MAY be present 3251 -- and contain an AlgorithmIdentifier followed by a 3252 -- zero-length BIT STRING for the subjectPublicKey if it is 3253 -- desired to inform the CA/RA of algorithm and parameter 3254 -- preferences regarding the to-be-generated key pair. 3256 crm[1].certReq. present [object identifier MUST be PROT_ENC_ALG] 3257 controls.protocolEncrKey 3258 -- if centralized key generation is supported by this CA, 3259 -- this short-term asymmetric encryption key (generated by 3260 -- the end entity) will be used by the CA to encrypt (a 3261 -- symmetric key used to encrypt) a private key generated by 3262 -- the CA on behalf of the end entity 3264 crm[1].certReq. optionally present 3265 controls.archiveOptions 3266 crm[1].certReq. optionally present 3267 controls.publicationInfo 3268 protection present 3269 -- bits calculated using MSG_MAC_ALG 3271 Initialization Response -- ip 3273 Field Value 3275 sender CA name 3276 -- the name of the CA who produced the message 3277 messageTime present 3278 -- time at which CA produced message 3279 protectionAlg MS_MAC_ALG 3280 -- only MAC protection is allowed for this response 3281 senderKID referenceNum 3282 -- the reference number which the CA has previously issued to the 3283 -- end entity (together with the MACing key) 3284 transactionID present 3285 -- value from corresponding ir message 3286 senderNonce present 3287 -- 128 (pseudo-)random bits 3288 recipNonce present 3289 -- value from senderNonce in corresponding ir message 3290 freeText any valid value 3291 body ip (CertRepMessage) 3292 contains exactly one response 3293 for each request 3295 -- The PKI (CA) responds to either one or two requests as 3296 -- appropriate. crc[0] denotes the first (always present); 3297 -- crc[1] denotes the second (only present if the ir message 3298 -- contained two requests and if the CA supports centralized 3299 -- key generation). 3300 crc[0]. fixed value of zero 3301 certReqId 3302 -- MUST contain the response to the first request in the 3303 -- corresponding ir message 3305 crc[0].status. present, positive values allowed: 3306 status "accepted", "grantedWithMods" 3307 negative values allowed: 3308 "rejection" 3309 crc[0].status. present if and only if 3310 failInfo crc[0].status.status is "rejection" 3311 crc[0]. present if and only if 3312 certifiedKeyPair crc[0].status.status is 3313 "accepted" or "grantedWithMods" 3314 certificate present unless end entity's public 3315 key is an encryption key and POP 3316 is done in this in-band exchange 3317 encryptedCert present if and only if end entity's 3318 public key is an encryption key and 3319 POP done in this in-band exchange 3320 publicationInfo optionally present 3322 -- indicates where certificate has been published (present 3323 -- at discretion of CA) 3325 crc[1]. fixed value of one 3326 certReqId 3327 -- MUST contain the response to the second request in the 3328 -- corresponding ir message 3329 crc[1].status. present, positive values allowed: 3330 status "accepted", "grantedWithMods" 3331 negative values allowed: 3332 "rejection" 3333 crc[1].status. present if and only if 3334 failInfo crc[0].status.status is "rejection" 3335 crc[1]. present if and only if 3336 certifiedKeyPair crc[0].status.status is "accepted" 3337 or "grantedWithMods" 3338 certificate present 3339 privateKey present 3340 -- see Appendix C, Request Message Behavioral Clarifications 3341 publicationInfo optionally present 3342 -- indicates where certificate has been published (present 3343 -- at discretion of CA) 3345 protection present 3346 -- bits calculated using MSG_MAC_ALG 3347 extraCerts optionally present 3348 -- the CA MAY provide additional certificates to the end 3349 -- entity 3351 Certficate confirm; certConf 3353 Field Value 3355 sender present 3356 -- same as in ir 3357 recipient CA name 3358 -- the name of the CA who was asked to produce a certificate 3359 transactionID present 3360 -- value from corresponding ir and ip messages 3361 senderNonce present 3362 -- 128 (pseudo-) random bits 3363 recipNonce present 3364 -- value from senderNonce in corresponding ip message 3365 protectionAlg MSG_MAC_ALG 3366 -- only MAC protection is allowed for this message. The 3367 -- MAC is based on the initial auth'n key shared between 3368 -- the EE and the CA. 3370 senderKID referenceNum 3371 -- the reference number which the CA has previously issued 3372 -- to the end entity (together with the MACing key) 3374 body certConf 3375 -- see Section 5.3.18, "PKI Confirmation Content", for the 3376 -- contents of the certConf fields. 3377 -- Note: two CertStatus structures are required if both an 3378 -- encryption and a signing certificate were sent. 3380 protection present 3381 -- bits calculated using MSG_MAC_ALG 3383 Confirmation; PKIConf 3385 Field Value 3387 sender present 3388 -- same as in ip 3389 recipient present 3390 -- sender name from certConf 3391 transactionID present 3392 -- value from certConf message 3393 senderNonce present 3394 -- 128 (pseudo-) random bits 3395 recipNonce present 3396 -- value from senderNonce from certConf message 3397 protectionAlg MSG_MAC_ALG 3398 -- only MAC protection is allowed for this message. 3399 senderKID referenceNum 3400 body PKIConf 3401 protection present 3402 -- bits calculated using MSG_MAC_ALG 3404 D.5 Certificate Request 3406 An (initialized) end entity requests a certificate from a CA (for any 3407 reason). When the CA responds with a message containing a 3408 certificate, the end entity replies with a certificate confirmation. 3409 The CA replies with a PKIConfirm, to close the transaction. All 3410 messages are authenticated. 3412 The profile for this exchange is identical to that given in Appendix 3413 D.4 with the following exceptions: 3415 o sender name SHOULD be present 3417 o protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY 3418 also be supported) in request, response, certConfirm and 3419 PKIConfirm messages; 3421 o senderKID and recipKID are only present if required for message 3422 verification; 3424 o body is cr or cp; 3426 o body may contain one or two CertReqMsg structures, but either 3427 CertReqMsg may be used to request certification of a locally- 3428 generated public key or a centrally-generated public key (i.e., 3429 the position-dependence requirement of Appendix D.4is removed); 3431 o protection bits are calculated according to the protectionAlg 3432 field. 3434 D.6 Key Update Request 3436 An (initialized) end entity requests a certificate from a CA (to 3437 update the key pair and/or corresponding certificate that it already 3438 possesses). When the CA responds with a message containing a 3439 certificate, the end entity replies with a certificate confirmation. 3440 The CA replies with a PKIConfirm, to close the transaction. All 3441 messages are authenticated. 3443 The profile for this exchange is identical to that given in Appendix 3444 D.4 with the following exceptions: 3446 1. sender name SHOULD be present 3448 2. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY 3449 also be supported) in request, response, certConfirm and 3450 PKIConfirm messages; 3452 3. senderKID and recipKID are only present if required for message 3453 verification; 3455 4. body is kur or kup; 3457 5. body may contain one or two CertReqMsg structures, but either 3458 CertReqMsg may be used to request certification of a locally- 3459 generated public key or a centrally-generated public key (i.e., 3460 the position-dependence requirement of Appendix D.4 is removed); 3462 6. protection bits are calculated according to the protectionAlg 3463 field; 3465 7. regCtrl OldCertId SHOULD be used (unless it is clear to both 3466 sender and receiver - by means not specified in this document - 3467 that it is not needed). 3469 Appendix E. PKI Management Message Profiles (OPTIONAL). 3471 This appendix contains detailed profiles for those PKIMessages which 3472 MAY be supported by implementations (in addition to the messages 3473 which MUST be supported - see Section 6 and Appendix D). 3475 Profiles for the PKIMessages used in the following PKI management 3476 operations are provided: 3478 o root CA key update 3480 o information request/response 3482 o cross-certification request/response (1-way) 3484 o in-band initialization using external identity certificate 3486 Later versions of this document may extend the above to include 3487 profiles for the operations listed below (along with other 3488 operations, if desired). 3490 o revocation request 3492 o certificate publication 3494 o CRL publication 3496 E.1 General Rules for Interpretation of These Profiles. 3498 (Identical to Appendix D.1 3500 E.2 Algorithm Use Profile 3502 (Identical to Appendix D.2 3504 E.3 Self-signed Certificates 3506 Profile of how a Certificate structure may be "self-signed". These 3507 structures are used for distribution of CA public keys. This can 3508 occur in one of three ways (see Section 4.4 above for a description 3509 of the use of these structures): 3511 Type Function 3512 ----------------------------------------------------------------- 3513 newWithNew a true "self-signed" certificate; the contained 3514 public key MUST be usable to verify the signature 3515 (though this provides only integrity and no 3516 authentication whatsoever) 3517 oldWithNew previous root CA public key signed with new private key 3518 newWithOld new root CA public key signed with previous private key 3520 Such certificates (including relevant extensions) must contain 3521 "sensible" values for all fields. For example, when present 3522 subjectAltName MUST be identical to issuerAltName, and when present 3523 keyIdentifiers must contain appropriate values, et cetera. 3525 E.4 Root CA Key Update 3527 A root CA updates its key pair. It then produces a CA key update 3528 announcement message which can be made available (via some transport 3529 mechanism) to the relevant end entities. A confirmation message is 3530 NOT REQUIRED from the end entities. 3532 ckuann message: 3534 Field Value Comment 3535 -------------------------------------------------------------- 3536 sender CA name CA name 3537 body ckuann(CAKeyUpdAnnContent) 3538 oldWithNew present see Section E3 above 3539 newWithOld present see Section E3 above 3540 newWithNew present see Section E3 above 3541 extraCerts optionally present can be used to "publish" 3542 certificates (e.g., 3543 certificates signed using 3544 the new private key) 3546 E.5 PKI Information Request/Response 3548 The end entity sends general message to the PKI requesting details 3549 which will be required for later PKI management operations. RA/CA 3550 responds with general response. If an RA generates the response then 3551 it will simply forward the equivalent message which it previously 3552 received from the CA, with the possible addition of certificates to 3553 the extraCerts fields of the PKIMessage. A confirmation message is 3554 NOT REQUIRED from the end entity. 3556 Message Flows: 3558 Step# End entity PKI 3560 1 format genm 3561 2 -> genm -> 3562 3 handle genm 3563 4 produce genp 3564 5 <- genp <- 3565 6 handle genp 3567 genM: 3569 Field Value 3571 recipient CA name 3572 -- the name of the CA as contained in issuerAltName 3573 -- extensions or issuer fields within certificates 3574 protectionAlg MSG_MAC_ALG or MSG_SIG_ALG 3575 -- any authenticated protion alg. 3576 SenderKID present if required 3577 -- must be present if required for verification of message 3578 -- protection 3579 freeText any valid value 3580 body genr (GenReqContent) 3581 GenMsgContent empty SEQUENCE 3582 -- all relevant information requested 3583 protection present 3584 -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG 3586 genP: 3588 Field Value 3590 sender CA name 3591 -- name of the CA which produced the message 3592 protectionAlg MSG_MAC_ALG or MSG_SIG_ALG 3593 -- any authenticated protection alg. 3594 senderKID present if required 3595 -- must be present if required for verification of message 3596 -- protection 3597 body genp (GenRepContent) 3598 CAProtEncCert present (object identifier one 3599 of PROT_ENC_ALG), with relevant 3600 value 3601 -- to be used if end entity needs to encrypt information for 3602 -- the CA (e.g., private key for recovery purposes) 3604 SignKeyPairTypes present, with relevant value 3605 -- the set of signature algorithm identifiers which this CA will 3606 -- certify for subject public keys 3607 EncKeyPairTypes present, with relevant value 3608 -- the set of encryption/key agreement algorithm identifiers which 3609 -- this CA will certify for subject public keys 3610 PreferredSymmAlg present (object identifier one 3611 of PROT_SYM_ALG) , with relevant 3612 value 3613 -- the symmetric algorithm which this CA expects to be used 3614 -- in later PKI messages (for encryption) 3615 CAKeyUpdateInfo optionally present, with 3616 relevant value 3617 -- the CA MAY provide information about a relevant root CA 3618 -- key pair using this field (note that this does not imply 3619 -- that the responding CA is the root CA in question) 3620 CurrentCRL optionally present, with relevant value 3621 -- the CA MAY provide a copy of a complete CRL (i.e., 3622 -- fullest possible one) 3623 protection present 3624 -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG 3625 extraCerts optionally present 3626 -- can be used to send some certificates to the end 3627 -- entity. An RA MAY add its certificate here. 3629 E.6 Cross Certification Request/Response (1-way) 3631 Creation of a single cross-certificate (i.e., not two at once). The 3632 requesting CA MAY choose who is responsible for publication of the 3633 cross-certificate created by the responding CA through use of the 3634 PKIPublicationInfo control. 3636 Preconditions: 3638 1. Responding CA can verify the origin of the request (possibly 3639 requiring out-of-band means) before processing the request. 3641 2. Requesting CA can authenticate the authenticity of the origin of 3642 the response (possibly requiring out-of-band means) before 3643 processing the response 3645 The use of certificate confirmation and the corresponding server 3646 confirmation is determined by the generalInfo field in the PKIHeader 3647 (see Section 5.1.1). The following profile does not mandate support 3648 for either confirmation. 3650 Message Flows: 3652 Step# Requesting CA Responding CA 3653 1 format ccr 3654 2 -> ccr -> 3655 3 handle ccr 3656 4 produce ccp 3657 5 <- ccp <- 3658 6 handle ccp 3660 ccr: 3662 Field Value 3664 sender Requesting CA name 3665 -- the name of the CA who produced the message 3666 recipient Responding CA name 3667 -- the name of the CA who is being asked to produce a certificate 3668 messageTime time of production of message 3669 -- current time at requesting CA 3670 protectionAlg MSG_SIG_ALG 3671 -- only signature protection is allowed for this request 3672 senderKID present if required 3673 -- must be present if required for verification of message 3674 -- protection 3675 recipKID present if required 3676 -- must be present if required for verification of message 3677 -- protection 3678 transactionID present 3679 -- implementation-specific value, meaningful to requesting CA. 3680 -- [If already in use at responding CA then a rejection message 3681 -- MUST be produced by responding CA] 3682 senderNonce present 3683 -- 128 (pseudo-)random bits 3684 freeText any valid value 3685 body ccr (CertReqMessages) 3686 only one CertReqMsg 3687 allowed 3688 -- if multiple cross certificates are required they MUST be 3689 -- packaged in separate PKIMessages 3690 certTemplate present 3691 -- details follow 3692 version v1 or v3 3693 -- v3 STRONGLY RECOMMENDED 3694 signingAlg present 3695 -- the requesting CA must know in advance with which algorithm it 3696 -- wishes the certificate to be signed 3698 subject present 3699 -- may be NULL-DN only if subjectAltNames extension value proposed 3700 validity present 3701 -- MUST be completely specified (i.e., both fields present) 3702 issuer present 3703 -- may be NULL-DN only if issuerAltNames extension value proposed 3704 publicKey present 3705 -- the key to be certified (which must be for a signing algorithm) 3706 extensions optionally present 3707 -- a requesting CA must propose values for all extensions 3708 -- which it requires to be in the cross-certificate 3709 POPOSigningKey present 3710 -- see Section D3: Proof of possession profile 3711 protection present 3712 -- bits calculated using MSG_SIG_ALG 3713 extraCerts optionally present 3714 -- MAY contain any additional certificates that requester wishes 3715 -- to include 3717 ccp: 3719 Field Value 3721 sender Responding CA name 3722 -- the name of the CA who produced the message 3723 recipient Requesting CA name 3724 -- the name of the CA who asked for production of a certificate 3725 messageTime time of production of message 3726 -- current time at responding CA 3727 protectionAlg MSG_SIG_ALG 3728 -- only signature protection is allowed for this message 3729 senderKID present if required 3730 -- must be present if required for verification of message 3731 -- protection 3732 recipKID present if required 3733 transactionID present 3734 -- value from corresponding ccr message 3735 senderNonce present 3736 -- 128 (pseudo-)random bits 3737 recipNonce present 3738 -- senderNonce from corresponding ccr message 3739 freeText any valid value 3740 body ccp (CertRepMessage) 3741 only one CertResponse allowed 3742 -- if multiple cross certificates are required they MUST be 3743 -- packaged in separate PKIMessages 3744 response present 3745 status present 3746 PKIStatusInfo.status present 3747 -- if PKIStatusInfo.status is one of: 3748 -- accepted, or 3749 -- grantedWithMods, 3750 -- then certifiedKeyPair MUST be present and failInfo MUST 3751 -- be absent 3753 failInfo present depending on 3754 PKIStatusInfo.status 3755 -- if PKIStatusInfo.status is: 3756 -- rejection 3757 -- then certifiedKeyPair MUST be absent and failInfo MUST be 3758 -- present and contain appropriate bit settings 3760 certifiedKeyPair present depending on 3761 PKIStatusInfo.status 3762 certificate present depending on 3763 certifiedKeyPair 3764 -- content of actual certificate must be examined by requesting CA 3765 -- before publication 3766 protection present 3767 -- bits calculated using MSG_SIG_ALG 3768 extraCerts optionally present 3769 -- MAY contain any additional certificates that responder wishes 3770 -- to include 3772 E.7 In-band Initialization Using External Identity Certificate 3774 An (uninitialized) end entity wishes to initialize into the PKI with 3775 a CA, CA-1. It uses, for authentication purposes, a pre-existing 3776 identity certificate issued by another (external) CA, CA-X. A trust 3777 relationship must already have been established between CA-1 and CA-X 3778 so that CA-1 can validate the EE identity certificate signed by CA-X. 3779 Furthermore, some mechanism must already have been established within 3780 the Personal Security Environment (PSE) of the EE that would allow it 3781 to authenticate and verify PKIMessages signed by CA-1 (as one 3782 example, the PSE may contain a certificate issued for the public key 3783 of CA-1, signed by another CA that the EE trusts on the basis of 3784 out-of-band authentication techniques). 3786 The EE sends an initialization request to start the transaction. When 3787 CA-1 responds with a message containing the new certificate, the end 3788 entity replies with a certificate confirmation. CA-1 replies with a 3789 PKIConfirm to close the transaction. All messages are signed (the EE 3790 messages are signed using the private key corresponding to the public 3791 key in its external identity certificate; the CA-1 messages are 3792 signed using the private key corresponding to the public key in a 3793 certificate that can be chained to a trust anchor in the EE's PSE). 3795 The profile for this exchange is identical to that given in Appendix 3796 D.4 with the following exceptions: 3798 o the EE and CA-1 do not share a symmetric MACing key (i.e., there 3799 is no out-of-band shared secret information between these 3800 entities); 3802 o sender name in ir MUST be present (and identical to the subject 3803 name present in the external identity certificate); 3805 o protectionAlg of MSG_SIG_ALG MUST be used in all messages; 3807 o external identity cert. MUST be carried in ir extraCerts field 3809 o senderKID and recipKID are not used; 3811 o body is ir or ip; 3813 o protection bits are calculated according to the protectionAlg 3814 field. 3816 Appendix F. Compilable ASN.1 Definitions 3818 PKIXCMP {iso(1) identified-organization(3) 3819 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3820 id-mod(0) id-mod-cmp2000(16)} 3822 DEFINITIONS EXPLICIT TAGS ::= 3824 BEGIN 3826 -- EXPORTS ALL -- 3828 IMPORTS 3830 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 3831 UTF8String -- if required; otherwise, comment out 3832 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 3833 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3834 id-mod(0) id-pkix1-explicit-88(1)} 3836 GeneralName, KeyIdentifier 3837 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 3838 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3839 id-mod(0) id-pkix1-implicit-88(2)} 3841 CertTemplate, PKIPublicationInfo, EncryptedValue, CertId, 3842 CertReqMessages 3843 FROM PKIXCRMF {iso(1) identified-organization(3) 3844 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3845 id-mod(0) id-mod-crmf(5)} 3847 -- see also the behavioral clarifications to CRMF codified in 3848 -- Appendix C of this specification 3850 CertificationRequest 3851 FROM PKCS-10 {iso(1) member-body(2) 3852 us(840) rsadsi(113549) 3853 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 3855 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 3856 -- tags). Alternatively, implementers may directly include 3857 -- the [PKCS10] syntax in this module 3859 ; 3861 -- the rest of the module contains locally-defined OIDs and 3862 -- constructs 3863 CMPCertificate ::= CHOICE { 3864 x509v3PKCert Certificate 3865 } 3866 -- This syntax, while bits-on-the-wire compatible with the 3867 -- standard X.509 definition of "Certificate", allows the 3868 -- possibility of future certificate types (such as X.509 3869 -- attribute certificates, WAP WTLS certificates, or other kinds 3870 -- of certificates) within this certificate management protocol, 3871 -- should a need ever arise to support such generality. Those 3872 -- implementations that do not foresee a need to ever support 3873 -- other certificate types MAY, if they wish, comment out the 3874 -- above structure and "un-comment" the following one prior to 3875 -- compiling this ASN.1 module. (Note that interoperability 3876 -- with implementations that don't do this will be unaffected by 3877 -- this change.) 3879 -- CMPCertificate ::= Certificate 3881 PKIMessage ::= SEQUENCE { 3882 header PKIHeader, 3883 body PKIBody, 3884 protection [0] PKIProtection OPTIONAL, 3885 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 3886 OPTIONAL 3887 } 3889 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 3891 PKIHeader ::= SEQUENCE { 3892 pvno INTEGER { cmp1999(1), cmp2000(2) }, 3893 sender GeneralName, 3894 -- identifies the sender 3895 recipient GeneralName, 3896 -- identifies the intended recipient 3897 messageTime [0] GeneralizedTime OPTIONAL, 3898 -- time of production of this message (used when sender 3899 -- believes that the transport will be "suitable"; i.e., 3900 -- that the time will still be meaningful upon receipt) 3901 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 3902 -- algorithm used for calculation of protection bits 3903 senderKID [2] KeyIdentifier OPTIONAL, 3904 recipKID [3] KeyIdentifier OPTIONAL, 3905 -- to identify specific keys used for protection 3906 transactionID [4] OCTET STRING OPTIONAL, 3907 -- identifies the transaction; i.e., this will be the same in 3908 -- corresponding request, response, certConf, and PKIConf 3909 -- messages 3910 senderNonce [5] OCTET STRING OPTIONAL, 3911 recipNonce [6] OCTET STRING OPTIONAL, 3912 -- nonces used to provide replay protection, senderNonce 3913 -- is inserted by the creator of this message; recipNonce 3914 -- is a nonce previously inserted in a related message by 3915 -- the intended recipient of this message 3916 freeText [7] PKIFreeText OPTIONAL, 3917 -- this may be used to indicate context-specific instructions 3918 -- (this field is intended for human consumption) 3919 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 3920 InfoTypeAndValue OPTIONAL 3921 -- this may be used to convey context-specific information 3922 -- (this field not primarily intended for human consumption) 3923 } 3925 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 3926 -- text encoded as UTF-8 String [RFC3629] (note: each 3927 -- UTF8String MAY include an [RFC3066] language tag 3928 -- to indicate the language of the contained text 3929 -- see [RFC2482] for details) 3931 PKIBody ::= CHOICE { -- message-specific body elements 3932 ir [0] CertReqMessages, --Initialization Request 3933 ip [1] CertRepMessage, --Initialization Response 3934 cr [2] CertReqMessages, --Certification Request 3935 cp [3] CertRepMessage, --Certification Response 3936 p10cr [4] CertificationRequest, --imported from [PKCS10] 3937 popdecc [5] POPODecKeyChallContent, --pop Challenge 3938 popdecr [6] POPODecKeyRespContent, --pop Response 3939 kur [7] CertReqMessages, --Key Update Request 3940 kup [8] CertRepMessage, --Key Update Response 3941 krr [9] CertReqMessages, --Key Recovery Request 3942 krp [10] KeyRecRepContent, --Key Recovery Response 3943 rr [11] RevReqContent, --Revocation Request 3944 rp [12] RevRepContent, --Revocation Response 3945 ccr [13] CertReqMessages, --Cross-Cert. Request 3946 ccp [14] CertRepMessage, --Cross-Cert. Response 3947 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 3948 cann [16] CertAnnContent, --Certificate Ann. 3949 rann [17] RevAnnContent, --Revocation Ann. 3950 crlann [18] CRLAnnContent, --CRL Announcement 3951 pkiconf [19] PKIConfirmContent, --Confirmation 3952 nested [20] NestedMessageContent, --Nested Message 3953 genm [21] GenMsgContent, --General Message 3954 genp [22] GenRepContent, --General Response 3955 error [23] ErrorMsgContent, --Error Message 3956 certConf [24] CertConfirmContent, --Certificate confirm 3957 pollReq [25] PollReqContent, --Polling request 3958 pollRep [26] PollRepContent --Polling response 3960 } 3962 PKIProtection ::= BIT STRING 3964 ProtectedPart ::= SEQUENCE { 3965 header PKIHeader, 3966 body PKIBody 3967 } 3969 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 3970 PBMParameter ::= SEQUENCE { 3971 salt OCTET STRING, 3972 -- note: implementations MAY wish to limit acceptable sizes 3973 -- of this string to values appropriate for their environment 3974 -- in order to reduce the risk of denial-of-service attacks 3975 owf AlgorithmIdentifier, 3976 -- AlgId for a One-Way Function (SHA-1 recommended) 3977 iterationCount INTEGER, 3978 -- number of times the OWF is applied 3979 -- note: implementations MAY wish to limit acceptable sizes 3980 -- of this integer to values appropriate for their environment 3981 -- in order to reduce the risk of denial-of-service attacks 3982 mac AlgorithmIdentifier 3983 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 3984 } -- or HMAC [RFC2104, RFC2202]) 3986 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 3987 DHBMParameter ::= SEQUENCE { 3988 owf AlgorithmIdentifier, 3989 -- AlgId for a One-Way Function (SHA-1 recommended) 3990 mac AlgorithmIdentifier 3991 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 3992 } -- or HMAC [RFC2104, RFC2202]) 3994 NestedMessageContent ::= PKIMessages 3996 PKIStatus ::= INTEGER { 3997 accepted (0), 3998 -- you got exactly what you asked for 3999 grantedWithMods (1), 4000 -- you got something like what you asked for; the 4001 -- requester is responsible for ascertaining the differences 4002 rejection (2), 4003 -- you don't get it, more information elsewhere in the message 4004 waiting (3), 4005 -- the request body part has not yet been processed; expect to 4006 -- hear more later (note: proper handling of this status 4007 -- response MAY use the polling req/rep PKIMessages specified 4008 -- in Section 5.3.22; alternatively, polling in the underlying 4009 -- transport layer MAY have some utility in this regard) 4010 revocationWarning (4), 4011 -- this message contains a warning that a revocation is 4012 -- imminent 4013 revocationNotification (5), 4014 -- notification that a revocation has occurred 4015 keyUpdateWarning (6) 4016 -- update already done for the oldCertId specified in 4017 -- CertReqMsg 4018 } 4020 PKIFailureInfo ::= BIT STRING { 4021 -- since we can fail in more than one way! 4022 -- More codes may be added in the future if/when required. 4023 badAlg (0), 4024 -- unrecognized or unsupported Algorithm Identifier 4025 badMessageCheck (1), 4026 -- integrity check failed (e.g., signature did not verify) 4027 badRequest (2), 4028 -- transaction not permitted or supported 4029 badTime (3), 4030 -- messageTime was not sufficiently close to the system time, 4031 -- as defined by local policy 4032 badCertId (4), 4033 -- no certificate could be found matching the provided criteria 4034 badDataFormat (5), 4035 -- the data submitted has the wrong format 4036 wrongAuthority (6), 4037 -- the authority indicated in the request is different from the 4038 -- one creating the response token 4039 incorrectData (7), 4040 -- the requester's data is incorrect (for notary services) 4041 missingTimeStamp (8), 4042 -- when the timestamp is missing but should be there 4043 -- (by policy) 4044 badPOP (9), 4045 -- the proof-of-possession failed 4046 certRevoked (10), 4047 -- the certificate has already been revoked 4048 certConfirmed (11), 4049 -- the certificate has already been confirmed 4050 wrongIntegrity (12), 4051 -- invalid integrity, password based instead of signature or 4052 -- vice versa 4053 badRecipientNonce (13), 4054 -- invalid recipient nonce, either missing or wrong value 4056 timeNotAvailable (14), 4057 -- the TSA's time source is not available 4058 unacceptedPolicy (15), 4059 -- the requested TSA policy is not supported by the TSA. 4060 unacceptedExtension (16), 4061 -- the requested extension is not supported by the TSA. 4062 addInfoNotAvailable (17), 4063 -- the additional information requested could not be 4064 -- understood or is not available 4065 badSenderNonce (18), 4066 -- invalid sender nonce, either missing or wrong size 4067 badCertTemplate (19), 4068 -- invalid cert. template or missing mandatory information 4069 signerNotTrusted (20), 4070 -- signer of the message unknown or not trusted 4071 transactionIdInUse (21), 4072 -- the transaction identifier is already in use 4073 unsupportedVersion (22), 4074 -- the version of the message is not supported 4075 notAuthorized (23), 4076 -- the sender was not authorized to make the preceding 4077 -- request or perform the preceding action 4078 systemUnavail (24), 4079 -- the request cannot be handled due to system unavailability 4080 systemFailure (25), 4081 -- the request cannot be handled due to system failure 4082 duplicateCertReq (26) 4083 -- certificate cannot be issued because a duplicate 4084 -- certificate already exists 4085 } 4087 PKIStatusInfo ::= SEQUENCE { 4088 status PKIStatus, 4089 statusString PKIFreeText OPTIONAL, 4090 failInfo PKIFailureInfo OPTIONAL 4091 } 4093 OOBCert ::= CMPCertificate 4095 OOBCertHash ::= SEQUENCE { 4096 hashAlg [0] AlgorithmIdentifier OPTIONAL, 4097 certId [1] CertId OPTIONAL, 4098 hashVal BIT STRING 4099 -- hashVal is calculated over the DER encoding of the 4100 -- self-signed certificate with the identifier certID. 4101 } 4103 POPODecKeyChallContent ::= SEQUENCE OF Challenge 4104 -- One Challenge per encryption key certification request (in the 4105 -- same order as these requests appear in CertReqMessages). 4107 Challenge ::= SEQUENCE { 4108 owf AlgorithmIdentifier OPTIONAL, 4110 -- MUST be present in the first Challenge; MAY be omitted in 4111 -- any subsequent Challenge in POPODecKeyChallContent (if 4112 -- omitted, then the owf used in the immediately preceding 4113 -- Challenge is to be used). 4115 witness OCTET STRING, 4116 -- the result of applying the one-way function (owf) to a 4117 -- randomly-generated INTEGER, A. [Note that a different 4118 -- INTEGER MUST be used for each Challenge.] 4119 challenge OCTET STRING 4120 -- the encryption (under the public key for which the cert. 4121 -- request is being made) of Rand, where Rand is specified as 4122 -- Rand ::= SEQUENCE { 4123 -- int INTEGER, 4124 -- - the randomly-generated INTEGER A (above) 4125 -- sender GeneralName 4126 -- - the sender's name (as included in PKIHeader) 4127 -- } 4128 } 4130 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 4131 -- One INTEGER per encryption key certification request (in the 4132 -- same order as these requests appear in CertReqMessages). The 4133 -- retrieved INTEGER A (above) is returned to the sender of the 4134 -- corresponding Challenge. 4136 CertRepMessage ::= SEQUENCE { 4137 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 4138 OPTIONAL, 4139 response SEQUENCE OF CertResponse 4140 } 4142 CertResponse ::= SEQUENCE { 4143 certReqId INTEGER, 4144 -- to match this response with corresponding request (a value 4145 -- of -1 is to be used if certReqId is not specified in the 4146 -- corresponding request) 4147 status PKIStatusInfo, 4148 certifiedKeyPair CertifiedKeyPair OPTIONAL, 4149 rspInfo OCTET STRING OPTIONAL 4150 -- analogous to the id-regInfo-utf8Pairs string defined 4151 -- for regInfo in CertReqMsg [CRMF] 4153 } 4155 CertifiedKeyPair ::= SEQUENCE { 4156 certOrEncCert CertOrEncCert, 4157 privateKey [0] EncryptedValue OPTIONAL, 4158 -- see [CRMF] for comment on encoding 4159 publicationInfo [1] PKIPublicationInfo OPTIONAL 4160 } 4162 CertOrEncCert ::= CHOICE { 4163 certificate [0] CMPCertificate, 4164 encryptedCert [1] EncryptedValue 4165 } 4167 KeyRecRepContent ::= SEQUENCE { 4168 status PKIStatusInfo, 4169 newSigCert [0] CMPCertificate OPTIONAL, 4170 caCerts [1] SEQUENCE SIZE (1..MAX) OF 4171 CMPCertificate OPTIONAL, 4172 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 4173 CertifiedKeyPair OPTIONAL 4174 } 4176 RevReqContent ::= SEQUENCE OF RevDetails 4178 RevDetails ::= SEQUENCE { 4179 certDetails CertTemplate, 4180 -- allows requester to specify as much as they can about 4181 -- the cert. for which revocation is requested 4182 -- (e.g., for cases in which serialNumber is not available) 4183 crlEntryDetails Extensions OPTIONAL 4184 -- requested crlEntryExtensions 4185 } 4187 RevRepContent ::= SEQUENCE { 4188 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 4189 -- in same order as was sent in RevReqContent 4190 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 4191 OPTIONAL, 4192 -- IDs for which revocation was requested 4193 -- (same order as status) 4194 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 4195 OPTIONAL 4196 -- the resulting CRLs (there may be more than one) 4197 } 4199 CAKeyUpdAnnContent ::= SEQUENCE { 4200 oldWithNew CMPCertificate, -- old pub signed with new priv 4201 newWithOld CMPCertificate, -- new pub signed with old priv 4202 newWithNew CMPCertificate -- new pub signed with new priv 4203 } 4205 CertAnnContent ::= CMPCertificate 4207 RevAnnContent ::= SEQUENCE { 4208 status PKIStatus, 4209 certId CertId, 4210 willBeRevokedAt GeneralizedTime, 4211 badSinceDate GeneralizedTime, 4212 crlDetails Extensions OPTIONAL 4213 -- extra CRL details(e.g., crl number, reason, location, etc.) 4214 } 4216 CRLAnnContent ::= SEQUENCE OF CertificateList 4218 CertConfirmContent ::= SEQUENCE OF CertStatus 4220 CertStatus ::= SEQUENCE { 4221 certHash OCTET STRING, 4222 -- the hash of the certificate, using the same hash algorithm 4223 -- as is used to create and verify the certificate signature 4224 certReqId INTEGER, 4225 -- to match this confirmation with the corresponding req/rep 4226 statusInfo PKIStatusInfo OPTIONAL 4227 } 4229 PKIConfirmContent ::= NULL 4231 InfoTypeAndValue ::= SEQUENCE { 4232 infoType OBJECT IDENTIFIER, 4233 infoValue ANY DEFINED BY infoType OPTIONAL 4234 } 4235 -- Example InfoTypeAndValue contents include, but are not limited 4236 -- to, the following (un-comment in this ASN.1 module and use as 4237 -- appropriate for a given environment): 4238 -- 4239 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 4240 -- CAProtEncCertValue ::= CMPCertificate 4241 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 4242 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 4243 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 4244 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 4245 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 4246 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 4247 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 4248 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 4249 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 4250 -- CurrentCRLValue ::= CertificateList 4251 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 4252 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 4253 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 4254 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 4255 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 4256 -- KeyPairParamRepValue ::= AlgorithmIdentifer 4257 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 4258 -- RevPassphraseValue ::= EncryptedValue 4259 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 4260 -- ImplicitConfirmValue ::= NULL 4261 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 4262 -- ConfirmWaitTimeValue ::= GeneralizedTime 4263 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 4264 -- OrigPKIMessageValue ::= PKIMessages 4265 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 4266 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 4267 -- 4268 -- where 4269 -- 4270 -- id-pkix OBJECT IDENTIFIER ::= { 4271 -- iso(1) identified-organization(3) 4272 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 4273 -- and 4274 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 4275 -- 4276 -- 4277 -- This construct MAY also be used to define new PKIX Certificate 4278 -- Management Protocol request and response messages, or general- 4279 -- purpose (e.g., announcement) messages for future needs or for 4280 -- specific environments. 4282 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 4284 -- May be sent by EE, RA, or CA (depending on message content). 4285 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 4286 -- typically be omitted for some of the examples given above. 4287 -- The receiver is free to ignore any contained OBJ. IDs that it 4288 -- does not recognize. If sent from EE to CA, the empty set 4289 -- indicates that the CA may send 4290 -- any/all information that it wishes. 4292 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 4293 -- Receiver MAY ignore any contained OIDs that it does not 4294 -- recognize. 4296 ErrorMsgContent ::= SEQUENCE { 4297 pKIStatusInfo PKIStatusInfo, 4298 errorCode INTEGER OPTIONAL, 4299 -- implementation-specific error codes 4300 errorDetails PKIFreeText OPTIONAL 4301 -- implementation-specific error details 4302 } 4304 PollReqContent ::= SEQUENCE OF SEQUENCE { 4305 certReqId INTEGER 4306 } 4308 PollRepContent ::= SEQUENCE OF SEQUENCE { 4309 certReqId INTEGER, 4310 checkAfter INTEGER, -- time in seconds 4311 reason PKIFreeText OPTIONAL 4312 } 4314 END -- of CMP module 4316 Appendix G. Acknowledgements 4318 The authors gratefully acknowledge the contributions of various 4319 members of the IETF PKIX Working Group and the ICSA CA-talk mailing 4320 list (a list solely devoted to discussing CMP interoperability 4321 efforts). Many of these contributions significantly clarified and 4322 improved the utility of this specification. Tomi Kause thanks Vesa 4323 Suontama and Toni Tammisalo for review and comments. 4325 Intellectual Property Statement 4327 The IETF takes no position regarding the validity or scope of any 4328 intellectual property or other rights that might be claimed to 4329 pertain to the implementation or use of the technology described in 4330 this document or the extent to which any license under such rights 4331 might or might not be available; neither does it represent that it 4332 has made any effort to identify any such rights. Information on the 4333 IETF's procedures with respect to rights in standards-track and 4334 standards-related documentation can be found in BCP-11. Copies of 4335 claims of rights made available for publication and any assurances of 4336 licenses to be made available, or the result of an attempt made to 4337 obtain a general license or permission for the use of such 4338 proprietary rights by implementors or users of this specification can 4339 be obtained from the IETF Secretariat. 4341 The IETF invites any interested party to bring to its attention any 4342 copyrights, patents or patent applications, or other proprietary 4343 rights which may cover technology that may be required to practice 4344 this standard. Please address the information to the IETF Executive 4345 Director. 4347 Full Copyright Statement 4349 Copyright (C) The Internet Society (2004). All Rights Reserved. 4351 This document and translations of it may be copied and furnished to 4352 others, and derivative works that comment on or otherwise explain it 4353 or assist in its implementation may be prepared, copied, published 4354 and distributed, in whole or in part, without restriction of any 4355 kind, provided that the above copyright notice and this paragraph are 4356 included on all such copies and derivative works. However, this 4357 document itself may not be modified in any way, such as by removing 4358 the copyright notice or references to the Internet Society or other 4359 Internet organizations, except as needed for the purpose of 4360 developing Internet standards in which case the procedures for 4361 copyrights defined in the Internet Standards process must be 4362 followed, or as required to translate it into languages other than 4363 English. 4365 The limited permissions granted above are perpetual and will not be 4366 revoked by the Internet Society or its successors or assignees. 4368 This document and the information contained herein is provided on an 4369 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4370 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4371 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4372 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4373 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4375 Acknowledgment 4377 Funding for the RFC Editor function is currently provided by the 4378 Internet Society.