idnits 2.17.1 draft-ietf-pkix-ipki-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 29 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 421: '... issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 423: '... subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 425: '... extensions [3] Extensions OPTIONAL...' RFC 2119 keyword, line 592: '...fier KeyIdentifier OPTIONAL,...' RFC 2119 keyword, line 593: '...dedKeyUsage KeyUsage OPTIONAL,...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 210 has weird spacing: '...ication path ...' == Line 338 has weird spacing: '...issuing a cer...' == Line 349 has weird spacing: '...: This is th...' == Line 619 has weird spacing: '...ning or only ...' == Line 1161 has weird spacing: '...otected stand...' == (16 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10361 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 1422' on line 140 looks like a reference -- Missing reference section? 'ISO TC' on line 151 looks like a reference -- Missing reference section? 'ISO DAM' on line 154 looks like a reference -- Missing reference section? '0' on line 830 looks like a reference -- Missing reference section? '1' on line 831 looks like a reference -- Missing reference section? '2' on line 790 looks like a reference -- Missing reference section? '3' on line 558 looks like a reference -- Missing reference section? '4' on line 559 looks like a reference -- Missing reference section? '5' on line 560 looks like a reference -- Missing reference section? '6' on line 561 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Ford (NorTel) 4 S. Farrell (SSE) 5 D. Solo (BBN) 6 expires in six months November 1995 8 Internet Public Key Infrastructure 10 draft-ietf-pkix-ipki-00.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This is the first draft of the Internet Public Key Infrastructure. 33 It is provided as a strawman for the first meeting of the PKIX 34 Working Group. The intent of this strawman is to generate productive 35 discussions at the first meeting. 37 1 Executive Summary 39 << Write this last. >> 41 2 Requirements and Assumptions 43 Goal is to develop a profile and associated management structure to 44 facilitate the adoption/use of X.509 certificates within internet 45 applications for those communities wishing to make use of X.509 46 technology. Such applications may include HTTP, electronic mail, 47 IPSP, user authentication, electronic payment systems, as well as 48 others. In order to relieve some of the obstacles to using X.509 49 certificates, this draft will define profiles, rules, and management 50 protocols that should serve to promote the development of reusable 51 certificate management systems; development of reusable application 52 tools; and interoperabilty determined by policy, not syntax. 54 Many communities will need to supplement, or possibly replace, this 55 profile in order to meet the requirements of specialized domains or 56 environments with additional authorization, assurance, or operational 57 requirements. However, for basic applications, it is essential that 58 a core of features be defined and that common means of representing 59 common information be agreed to so that application developers can 60 obtain necessary information without regard to the issuer of a 61 particular certificate. 63 As supplemental authorization and attribute management tools emerge, 64 such as attribute certificates, it may be appropriate to limit what 65 the certificate is used for in terms of conveying authenticated 66 attributes as opposed to other means of conveying information. 68 << Note, this section needs to be expanded >> 70 2.1 Communication and Topology 72 The users of certificates will operate in a wide range of 73 environments with respect to their communication topology, especially 74 for secure electronic mail users. This profile will allow for users 75 without high bandwidth, real-time IP connectivity, or high 76 availablity of a connection. In addition, the profile must allow for 77 the presence of firewall or other filtered communication. 79 2.2 Access Control and Acceptability Decisions 81 The goal of the Public Key Infrstructure (PKI) is to meet the needs 82 of deterministic, automated access control and authorization 83 functions. This will drive the types of attributes and the nature of 84 the identity contained in the certificate as well as the ancillary 85 control information in the certificate such as policy data and 86 certification path constraints. 88 2.3 User Expectations 90 In this context, user refers to the users of the client software and 91 the subjects of the certificates. These are the readers and writers 92 of electronic mail, the clients for WWW browsers, etc. A goal of 93 this profile is to recognize the limitations of both the platforms 94 these users will employ and the sophistication/attentiveness of the 95 users. This manifests itself in requirements to simplify the 96 configuration responsibility of the user (e.g., root keys, rules), 97 make platform usage constraints explicit in the certificate, to 98 construct certification path constraints which shield the user from 99 malicious action, and to construct applications which sensibly 100 automate checking functions. 102 2.4 Administration Expectations 104 As with users, the certificate profile should also be structured to 105 be consistent with the types of individuals who must administer the 106 CA space. Providing such an administrator with unbounded choices 107 complicates not only the software that must process these 108 certificates but also increases the chances that a subtle mistake by 109 the CA administrator will result in broader compromise. 111 3 Overview of Approach 113 3.1 X.509 Version 3 Certificate 115 Application of public key technology requires the user of a public 116 key to be confident that the public key belongs to the correct remote 117 subject (person or system) with which an encryption or digital 118 signature mechanism will be used. This confidence is obtained 119 through the use of public key certificates, which are data structures 120 that bind public key values to subject identities. The binding is 121 achieved by having a trusted certification authority (CA) digitally 122 sign each certificate. A certificate has a limited valid lifetime 123 which is indicated in its signed contents. Because a certificate's 124 signature and timeliness can be independently checked by a 125 certificate-using client, certificates can be distributed via 126 untrusted communications and server systems, and can be cached in 127 unsecured storage in certificate-using systems. 129 The standard known as ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 130 9594-8, which was first published in 1988 as part of the X.500 131 Directory recommendations, defines a standard certificate format. The 132 certificate format in the 1988 standard is called the version 1 (v1) 133 format. When X.500 was revised in 1993, two more fields were added, 134 resulting in the version 2 (v2) format. These two fields are used to 135 support directory access control, and are not applicable to public 136 key infrastructures. 138 The Internet Privacy Enhanced Mail (PEM) proposals, published in 139 1993, included specifications for a public key infrastructure based 140 on X.509 version 1 certificates [RFC 1422]. The experience gained in 141 attempts to deploy RFC 1422 made it clear that the v1 and v2 142 certificate formats were deficient in several respects. Most 143 importantly, more fields were needed to carry information which PEM 144 design and implementation experience had proven necessary. In 145 response to these new requirements, ISO/IEC and ANSI X9 developed the 146 X.509 version 3 (v3) certificate format. The v3 format extends the 147 v2 format by adding provision for additional extension fields. 148 Particular extension field types may be specified in standards or may 149 be defined and registered by any organization or community having a 150 need. In August, 1995, standardization of the basic v3 format was 151 completed [ISO TC]. 153 ISO/IEC and ANSI X9 have also developed a set of standard extensions 154 for use in the v3 extensions field [ISO DAM]. These extensions can 155 convey such data as additional subject identification information, 156 key attribute information, policy information, and certification path 157 constraints. 159 However, the ISO/IEC and ANSI standard extensions are very broad in 160 their applicability. In order to develop interoperable 161 implementations of X.509 v3 systems for Internet use, it is necessary 162 to specify profiles of use of the X.509 v3 extensions tailored for 163 the Internet. It is one goal of this document to specify such 164 profiles. 166 3.2 Certification Paths and Trust 168 A user of a security service requiring knowledge of a public key 169 generally needs to obtain and validate a certificate containing the 170 required public key. If the public-key user does not already hold an 171 assured copy of the public key of the CA that signed the certificate, 172 then it might need an additional certificate to obtain that public 173 key. In general, a chain of multiple certificates may be needed, 174 comprising a certificate of the public key owner (the end entity) 175 signed by one CA, and zero or more additional certificates of CAs 176 signed by other CAs. Such chains, called certification paths, are 177 required because a public key user is only initialized with a limited 178 number (often one) of assured CA public keys. 180 There are different ways in which CAs might be configured in order 181 for public key users to be able to find certification paths. For 182 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 183 are three types of PEM certification authority: 185 (a) Internet Policy Registration Authority (IPRA): This authority, 186 operated under the auspices of the Internet Society, acts as the root 187 of the PEM certification hierarchy at level 1. It issues 188 certificates only for the next level of authorities, PCAs. All 189 certification paths start with the IPRA. 191 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 of 192 the hierarchy, each PCA being certified by the IPRA. A PCA must 193 establish and publish a statement of its policy with respect to 194 certifying users or subordinate certification authorities. Distinct 195 PCAs aim to satisfy different user needs. For example, one PCA (an 196 organizational PCA) might support the general electronic mail needs 197 of commercial organizations, and another PCA (a high-assurance PCA) 198 might have a more stringent policy designed for satisfying legally 199 binding signature requirements. 201 (c) Certification Authorities (CAs): CAs are at level 3 of the 202 hierarchy and can also be at lower levels. Those at level 3 are 203 certified by PCAs. CAs represent, for example, particular 204 organizations, particular organizational units (e.g., departments, 205 groups, sections), or particular geographical areas. 207 RFC 1422 furthermore has a name subordination rule which requires 208 that a CA can only issue certificates for entities whose names are 209 subordinate (in the X.500 naming tree) to the name of the CA itself. 210 The trust associated with a PEM certification path is implied by the 211 PCA name. The name subordination rule ensures that CAs below the PCA 212 are sensibly constrained as to the set of subordinate entities they 213 can certify (e.g., a CA for an organization can only certify entities 214 in that organization's name tree). Certificate user systems are able 215 to mechanically check that the name subordination rule has been 216 followed. 218 The RFC 1422 CA hierarchical model has been found to have several 219 deficiencies, including: 221 (a) The pure top-down hierarchy, with all ertification paths 222 starting from the root, is too restrictive for many purposes. For 223 some applications, verification of certification paths should start 224 with a public key of a CA in a user's own domain, rather than 225 mandating that verification commence at the top of a hierarchy. In 226 many environments, the local domain is often the most trusted. 227 Also,initialization and key-pair-update operations can be more 228 effectively conducted between an end entity and a local management 229 system. 231 (b) The name subordination rule introduces undesirable constraints 232 upon the X.500 naming system an organization may use. 234 (c) Use of the PCA concept requires knowledge of individual PCAs to 235 be built into certificate chain verification logic. In the 236 particular case of Internet mail, this is not a major problem -- the 237 PCA name can always be displayed to the human user who can make a 238 decision as to what trust to imply from a particular chain. However, 239 in many commercial applications, such as electronic commerce or EDI, 240 operator intervention to make policy decisions is impractical. The 241 process needs to be automated to a much higher degree. In fact, the 242 full process of certificate chain processing needs to be 243 implementable in trusted software. 245 Because of the above shortcomings, it is proposed that more flexible 246 CA structures than the RFC 1422 hierarchy be supported by the PKIX 247 specifications. In fact, the main reason for the structural 248 restrictions imposed by RFC 1422 was the restricted certificate 249 format provided with X.509 v1. With X.509 v3, most of the 250 requirements addressed by RFC 1422 can be addressed using certificate 251 extensions, without a need to restrict the CA structures used. In 252 particular, the certificate extensions relating to certificate 253 policies obviate the need for PCAs and the constraint extensions 254 obviate the need for the name subordination rule. 256 3.3 Revocation 258 When a certificate is issued, it is expected to be in use for its 259 entire validity period. However, various circumstances may cause a 260 certificate to become invalid prior to the expiration of the validity 261 period. Such circumstances might include change of name, change of 262 association between subject and CA (e.g., an employee terminates 263 employment with an organization), and compromise or suspected 264 compromise of the corresponding private key. Under such 265 circumstances, the CA needs to revoke the certificate. 267 X.509 defines one method of certificate revocation. This method 268 involves each CA periodically issuing a signed data structure called 269 a certificate revocation list (CRL). A CRL is a time stamped list 270 identifying revoked certificates which is signed by a CA and made 271 freely available in a public repository. Each revoked certificate is 272 identified in a CRL by its certificate serial number. When a 273 certificate-using system uses a certificate (e.g., for verifying a 274 remote user's digital signature), that system not only checks the 275 certificate signature and validity but also acquires a suitably- 276 recent CRL and checks that the certificate serial number is not on 277 that CRL. The meaning of "suitably-recent" may vary with local 278 policy, but it usually means the most recently-issued CRL. A CA 279 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 280 weekly). Entries are added to CRLs as revocations occur, and an 281 entry may be removed when the certificate expiration date is reached. 283 An advantage of this revocation method is that CRLs may be 284 distributed by exactly the same means as certificates themselves, 285 namely, via untrusted communications and server systems. 287 One limitation of the CRL revocation method, using untrusted 288 communications and servers, is that the time granularity of 289 revocation is limited to the CRL issue period. For example, if a 290 revocation is reported now, that revocation will not be reliably 291 notified to certificate-using systems until the next periodic CRL is 292 issued -- this may be up to one hour, one day, or one week depending 293 on the frequency that the CA issues CRLs. 295 Another potential problem with CRLs is a risk of a CRL growing to an 296 entirely unacceptable size. In the 1988 and 1993 versions of X.509, 297 the CRL for the end-user certificates needed to cover the entire 298 population of end-users for one CA. It is desirable to allow such 299 populations to be in the range of thousands, tens of thousands, or 300 possibly even hundreds of thousands of users. The end-user CRL is 301 therefore at risk of growing to such sizes, which present major 302 communication and storage overhead problems. With the version 2 CRL 303 format, introduced along with the v3 certificate format, it becomes 304 possible to arbitrarily divide the population of certificates for one 305 CA into a number of partitions, each partition being associated with 306 one CRL distribution point (e.g., directory entry or URL) from which 307 CRLs are distributed. Therefore, the maximum CRL size can be 308 controlled by a CA. Separate CRL distribution points can also exist 309 for different revocation reasons. For example, routine revocations 310 (e.g., name change) may be placed on a different CRL to revocations 311 resulting from suspected key compromises, and policy may specify that 312 the latter CRL be updated and issued more frequently than the former. 314 As with the X.509 v3 certificate format, in order to facilitate 315 interoperable implementations from multiple vendors, the X.509 v2 CRL 316 format needs to be profiled for Internet use. It is one goal of this 317 document to specify such profiles. 319 Furthermore, it is recognized that on-line methods of revocation 320 notification may be applicable in some environments as an alternative 321 to the X.509 CRL. On-line revocation checking elimiates the latency 322 between a revocation report and CRL the next issue. Once the 323 revocation is reported, any query to the on- line service will 324 correctly reflect the certificate validation impacts of the 325 revocation. Therefore, this document will also consider standard 326 approaches to on-line revocation notification. 328 3.4 Supporting Protocols 330 Management protocols are required to support on-line interactions 331 between Public Key Infrastructure (PKI) components. For example, 332 management protocol might be used between a CA and a client system 333 with which a key pair is associated, or between two CAs which cross- 334 certify each other. The set of functions which potentially need to 335 be supported by management protocols include: 337 (a) registration: This is the process whereby a user first makes 338 itself known to a CA, prior to that CA issuing a certificate or 339 certificates for that user. 341 (b) initialization: Before a client system can operate securely it 342 is necessary to install in it necessary key materials which have the 343 appropriate relationship with keys stored elsewhere in the 344 infrastructure. For example, the client needs to be securely 345 initialized with the public key of a CA, to be used in validating 346 certificate paths. Furthermore, a client typically needs to be 347 initialized with its own key pair(s). 349 (c) certification: This is the process in which a CA issues a 350 certificate for a user's public key, and returns that certificate to 351 the user's client system and/or posts that certificate in a public 352 repository. 354 (d) key pair recovery: As an option, user client key materials 355 (e.g., a user's private key used for encryption purposes) may be 356 backed up by a CA or a key backup system associated with a CA. If a 357 user needs to recover these backed up key materials (e.g., as a 358 result of a forgotten password or a lost key chain file), an on-line 359 protocol exchange may be needed to support such recovery. 361 (e) key pair update: All key pairs need to be updated regularly, 362 i.e., replaced with a new key pair, and new certificates issued. 364 (f) revocation request: An authorized person advises a CA of an 365 abnormal situation requiring certificate revocation. 367 (g) cross-certification: Two CAs exchange the information necessary 368 to establish cross-certificates between those CAs. 370 Note that on-line protocols are not the only way of implementing the 371 above functions. For all functions there are off-line methods of 372 achieving the same result, and this specification does not mandate 373 use of on- line protocols. For example, when hardware tokens are 374 used, many of the functions may be achieved through as part of the 375 physical token delivery. Furthermore, some of the above functions 376 may be combined into one protocol exchange. In particular, two or 377 more of the registration, initialization, and certification functions 378 can be combined into one protocol exchange. 380 Section 9 defines a set of standard protocols supporting the above 381 functions. The protocols for conveying these exchanges in different 382 environments (on-line, E-mail, and WWW) are specified in Section 10. 384 4 Certificate and Certificate Extensions Profile 386 As described above, one goal of this draft is to create a profile for 387 X.509 v3 certificates that will foster interoperability and a 388 reusable public key infrastructure. To achieve this goal, some 389 assumptions need to be made about the nature of information to be 390 included along with guidelines for how extensibility will be 391 employed. 393 Certificates may be used in a wide range of applications and 394 environments covering a broad spectrum of interoperability goals and 395 a broader spectrum of operational and assurance requirements. The 396 goal of this draft is to establish a common baseline for generic 397 applications requiring broad interoperability and limited special 398 purpose requirements. In particular, the emphasis will be on 399 supporting the use of X.509 v3 certificates for informal internet 400 electronic mail, IPSEC, and WWW applications. The draft will define 401 a baseline set of information along with common locations within a 402 certificate and common representations for common information. 403 Environments with additional requirements may build on this profile 404 or may replace it. 406 4.1 Basic Certificate Fields 408 The X.509 v3 certificate Basic syntax is as follows. For signature 409 calculation, the certificate is ASN.1 DER encoded (reference). ASN.1 410 DER encoding is a tag, length, value encoding system for each 411 element. 413 Certificate ::= SIGNED { SEQUENCE { 414 version [0] Version DEFAULT v1, 415 serialNumber CertificateSerialNumber, 416 signature AlgorithmIdentifier, 417 issuer Name, 418 validity Validity, 419 subject Name, 420 subjectPublicKeyInfo SubjectPublicKeyInfo, 421 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 422 -- If present, version must be v2 or v3 423 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 424 -- If present, version must be v2 or v3 425 extensions [3] Extensions OPTIONAL 426 -- If present, version must be v3 427 } } 429 Version ::= INTEGER { v1(0), v2(1), v3(2) } 431 CertificateSerialNumber ::= INTEGER 432 Validity ::= SEQUENCE { 433 notBefore UTCTime, 434 notAfter UTCTime } 436 UniqueIdentifier ::= BIT STRING 438 SubjectPublicKeyInfo ::= SEQUENCE { 439 algorithm AlgorithmIdentifier, 440 subjectPublicKey BIT STRING } 442 The following items describe a proposed use of the X.509 v3 443 certificate for the Internet. 445 4.1.1 Version 447 This field describes the version of the encoded certificate. When 448 extensions are used, as expected in this profile, use X.509 version 3 449 (value is 2). If no extensions are present, but a UniqueID is 450 present, use version 2 (value is 1). If only basic fields are 451 present, use version 1 (the value is omitted from the certificate as 452 the default value). 454 << All capabilites available in X.509 v2 certificates are available 455 in X.509 v3 certificates. Since there are so few X.509 v2 456 certificate implementations, should the profile prohibit the use of 457 v2? >> 459 4.1.2 Serial number 461 The serial number is an integer assigned by the certification 462 authority to each certificate. It must be unique for each 463 certificate issued by a given CA (i.e., the issuer name and serial 464 number identify a unique certificate). 466 << Do we want to define a maximum value for the serial number? >> 468 4.1.3 Signature 470 This field contains the algorithm identifier for the algorithm used 471 to sign the certificate. 473 4.1.4 Issuer Name 475 The issuer name provides a globally unique identifier of the 476 authority signing the certificate. The syntax of the issuer name is 477 an X.500 distinguished name. A name in the certificate may provide 478 semantic information, may provide a reference to an external 479 information store or service, provides a unique identifier, may 480 provide authorization information, or may provide a basis for 481 managing the CA relationships and certificate paths (other purposes 482 are also possible). This strawman suggests that the issuer (and 483 subject) name fields must provide a globally unique identifier. In 484 addition, they should contain semantic information identifying the 485 issuer/subject (e.g. a full name, organization name, etc.). Access 486 information will be provided in a separate extension (when other than 487 via X.500 directory) and internet specific identities (electronic 488 mail address, DNS name, and URLs) will be carried in alternative name 489 extensions. 491 << Further discussion of naming guidelines for internet use is 492 needed. >> 494 4.1.5 Validity 496 This field indicates the dates on which the certificate becomes valid 497 (notBefore) and on which the certificate ceases to be valid 498 (notAfter). 500 4.1.6 Subject Name 502 The purpose of the subject name is to provide a unique identifier of 503 the subject of the certificate. The syntax of the subject name is an 504 X.500 distinguished name. The discussion in section 4.1.4 on issuer 505 names applies to subject names as well. 507 4.1.7 Subject Public Key Info 509 This field is used to carry the public key and identify the algorithm 510 with which the key is used. 512 4.1.8 Unique Identifiers 514 The subject and issuer unique identifier are present in the 515 certificate to handle the possibility of reuse of subject and/or 516 issuer names over time. Based on the approach to naming, names will 517 not be reused and internet certificates will not make use of these 518 unique identifiers. 520 4.2 Certificate Extensions 522 The extensions already defined by ANSI X9 and ISO for X.509 v3 523 certificates provide methods for associating additional attributes 524 with users or public keys and for managing the certification 525 hierarchy. The X.509 v3 certificate format also allows communities to 526 define private extensions to carry information unique to those 527 communities. Each extension in a certificate may be designated as 528 critical or non-critical. A certificate using system (an application 529 validating a certificate) must reject the certificate if it 530 encounters a critical extension it does not recognize. A non- 531 critical extension may be ignored if it is not recognized. The 532 following presents recommended extensions used within Internet 533 certificates and standard locations for information. Communities may 534 elect to use additional extensions; however, caution should be 535 exercised in adopting any critical extensions in certificates which 536 might be used in a general context. 538 4.2.1 Subject Alternative Name 540 The altNames extension allows additional identities to be bound to 541 the subject of the certificate. Defined options include an rfc822 542 name (electronic mail address), a DNS name, and a URL. Each of these 543 are IA5 strings. Multiple instances may be included. Whenever such 544 identities are to be bound in a certificate, the subject alternative 545 name (or issuer alternative name) field shall be used. 547 << This implies that encoding of such identities within the subject 548 or issuer distinguished name is discouraged. >> 550 << Note definition is based on a recommended change to the DAM. >> 552 AltNames ::= SEQUENCE OF GeneralName 554 GeneralName ::= CHOICE { 555 otherName [0] INSTANCE OF OTHER-NAME, 556 rfc822Name [1] IA5String, 557 dNSName [2] IA5String, 558 x400Address [3] ORAddress, 559 directoryName [4] Name, 560 ediPartyName [5] IA5String, 561 url [6] IA5String } 563 << Should we permit an IP address? With the current list of choices, 564 IPSec would use dnsName. This leads to trusted resolution of DNS 565 Names to IP Addresses which is not done today. Maybe IP address is 566 too specific and LAN address should be allowed too. >> 568 4.2.2 Issuer Alternative Name 570 As with 4.2.1, this extension is used to bind Internet style 571 identities to the issuer name. 573 4.2.3 Certificate Policies 575 The certificatePolicies extension contains an object identifier (OID) 576 which indicates the policy under which the certificate has been 577 issued. Use of policies is discussed elsewhere in this draft. 579 4.2.4 Key Attributes 581 The keyAttributes extension contains information about the key itself 582 including a unique key identifier, a key usage period (lifetime of 583 the key as opposed to the lifetime of the certificate), and key 584 usage. The Internet certificate should use the keyAttributes 585 extension and contain a key identifier and private key validity to 586 aid in system management. The key usage field in this extension is 587 intended to be advisory (as contrasted with the key usage restriction 588 extension which imposes mandatory restrictions). The key usage field 589 in this extension should not be used. 591 KeyAttributes ::= SEQUENCE { 592 keyIdentifier KeyIdentifier OPTIONAL, 593 intendedKeyUsage KeyUsage OPTIONAL, 594 privateKeyUsagePeriod PrivateKeyValidity OPTIONAL } 596 KeyIdentifier ::= OCTET STRING 598 PrivateKeyValidity ::= SEQUENCE { 599 notBefore [0] GeneralizedTime OPTIONAL, 600 notAfter [1] GeneralizedTime OPTIONAL } 602 KeyUsage ::= BIT STRING { 603 digitalSignature (0), 604 nonRepudiation (1), 605 keyEncipherment (2), 606 dataEncipherment (3), 607 keyAgreement (4), 608 keyCertSign (5), 609 offLineCRLSign (6) } 611 4.2.5 Key Usage Restriction 613 The keyUsageRestriction extension defines mandatory restrictions on 614 the use of the key contained in the certificate based on policy 615 and/or usage (e.g., signature, encryption). This field should be 616 used whenever the use of the key is to be restricted based on either 617 usage or policy (see discussion in policies). The usage restriction 618 would be employed when a multipurpose key is to be restricted (e.g., 619 when an RSA key should be used only for signing or only for key 620 encipherment). 622 keyUsageRestriction ::= SEQUENCE { 623 certPolicySet SEQUENCE OF CertPolicyId OPTIONAL, 624 restrictedKeyUsage KeyUsage OPTIONAL } 626 4.2.6 Basic Constraints 628 The basicConstraints extension identifies whether the subject of the 629 certificate is a CA or an end user. In addition, this field can 630 limit the authority of the CA in terms of the certificates it can 631 issue. Discussion of certification path restriction is covered 632 elsewhere in this draft. The subject type field should be present in 633 all Internet certificates. 635 basicConstraints ::= SEQUENCE { 636 subjectType SubjectType, 637 pathLenConstraint INTEGER OPTIONAL, 638 permittedSubtrees SEQUENCE OF GeneralName OPTIONAL, 639 excludedSubtrees SEQUENCE OF GeneralName OPTIONAL } 641 SubjectType ::= BIT STRING { 642 cA (0), 643 endEntity (1) } 645 4.2.7 CRL Distribution Points 647 The cRLDistributionPoints extension identifies the CRL distribution 648 point or points to which a certificate user should refer to acertain 649 if the certificate has been revoked. This extenstion provides a 650 mechanism to divide the CRL inot manageable pieces if the CA has a 651 large constituency. 653 << Need a section which discusses the alternatives. Should permit 654 URLs as one method to name the location for the most recent CRL. >> 656 4.2.8 Information Access 658 The informationAccess field is proposed as a private extension to 659 tell how information about a subject or CA (or ancillary CA services) 660 may be accessed. For example, this field might provide a pointer to 661 information about a user (e.g., a URL) or might tell how to access CA 662 information such as certificate status or on-line validation 663 services. The structure of this extension is TBD. 665 << Suggestions on the ASN.1 syntax are welcome. >> 667 4.2.9 Other extensions 669 The DAM defines additional extensions; however, this draft does not 670 include them as there use is not part of the basic Internet profile. 672 4.3 Examples 674 << Certificate samples including descriptive text and ASN.1 encoded 675 blobs will be inserted. >> 677 5 CRL and CRL Extensions Profile 679 As described above, one goal of this draft is to create a profile for 680 X.509 v2 CRLs that will foster interoperability and a reusable public 681 key infrastructure. To achieve this goal, some assumptions need to 682 be made about the nature of information to be included along with 683 guidelines for how extensibility will be employed. 685 CRLs may be used in a wide range of applications and environments 686 covering a broad spectrum of interoperability goals and a broader 687 spectrum of operational and assurance requirements. The goal of this 688 draft is to establish a common baseline for generic applications 689 requiring broad interoperability and limited special purpose 690 requirements. Emphasis will be on support for X.509 v2 CRLs. The 691 draft will define a baseline set of information along with common 692 locations within a CRL and common representations for common 693 information. Environments with additional requirements may build on 694 this profile or may replace it. 696 5.1 CRL Fields 698 The X.509 v2 CRL syntax is as follows. For signature calculation, 699 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 700 encoding is a tag, length, value encoding system for each element. 702 CertificateList ::= SIGNED SEQUENCE { 703 version Version DEFAULT v1, 704 signature AlgorithmIdentifier, 705 issuer Name, 706 lastUpdate UTCTime, 707 nextUpdate UTCTime, 708 revokedCertificates SIGNED SEQUENCE OF SEQUENCE { 709 signature AlgorithmIdentifier, 710 issuer Name, 711 userCertificate SerialNumber, 712 revocationDate UTCTime, 713 crlEntryExtensions Extensions OPTIONAL } OPTIONAL, 714 crlExtensions [0] Extensions OPTIONAL } } 716 Version ::= INTEGER { v1(0), v2(1) } 718 SerialNumber ::= INTEGER 720 The following items describe a proposed use of the X.509 v2 CRL for 721 the Internet. 723 5.1.1 Version 725 This field describes the version of the encoded CRL. When extensions 726 are used, as expected in this profile, use version 2 (value is 1). 727 If neither CRL extensions nor CRL entry extensions are present, use 728 version 1 (the value is omitted). 730 5.1.2 Signature 732 This field contains the algorithm identifier for the algorithm used 733 to sign the CRL. 735 5.1.3 Issuer Name 737 The issuer name provides a globally unique identifier of the 738 certification authority signing the CRL. The syntax of the issuer 739 name is an X.500 distinguished name. This strawman suggests that the 740 issuer name must provide a globally unique identifier. In addition, 741 it should contain semantic information identifying the certification 742 authority. 744 << Any changes to 4.1.4 must be reflected here too. >> 746 5.1.4 Last Update 748 This field indicates the date on which this CRL was issued. 750 5.1.5 Next Update 752 This field indicates the date by which the next CRL will be issued. 753 The next CRL could be issued before the indicated date, but it will 754 not be issued any later than the indicated date. 756 5.1.6 Revoked Certificates 758 Revoked certificates are listed. The certificates are named by the 759 combination of the issuer name and the user certificate serial 760 number. The date on which the revocation occured is specified. Each 761 revocation entry is individually signed. This profile mandates the 762 use of same signature algorithm to sign each CRL entry and the whole 763 CRL. CRL entry extensions are discussed in section 5.3. 765 5.2 CRL Extensions 767 The extensions already defined by ANSI X9 and ISO for X.509 v2 CRLs 768 provide methods for associating additional attributes with CRLs. The 769 X.509 v2 CRL format also allows communities to define private 770 extensions to carry information unique to those communities. Each 771 extension in a CRL may be designated as critical or non-critical. A 772 CRL validation must fail if it encounters an critical extension. 773 However, an unrecognized non-critical extension may be ignored. The 774 following presents recommended extensions used within Internet CRLs 775 and standard locations for information. Communities may elect to use 776 additional extensions; however, caution should be exercised in 777 adopting any critical extensions in CRLs which might be used in a 778 general context. 780 5.2.1 Authority Key Identifier 782 The authorityKeyIdentifier is a non-critical CRL extension that 783 allows the CA to include an identifier of the key used to sign the 784 CRL. This extension is useful when a CA uses more than one key. See 785 section 7 for a discussion key changeover. 787 AuthorityKeyId ::= SEQUENCE { 788 keyIdentifier [0] KeyIdentifier OPTIONAL, 789 certIssuer [1] Name OPTIONAL, 790 certSerialNumber [2] CertificateSerialNumber OPTIONAL } 791 ( CONSTRAINED BY { 792 -- certIssuer and certSerialNumber constitute a logical pair, 793 -- and if either is present both must be present. Either this 794 -- pair or the keyIdentifier field or all shall be present. -- } ) 796 5.2.2 Issuer Alternative Name 798 The issuerAltName is a non-critical CRL extension that provides a CA 799 name, in a form other than an X.500 distinguished name. The syntax 800 for the issuerAltName is the same as described in section 4.2.1. Each 801 of the alternate names is an IA5 string. Multiple instances may be 802 included. Whenever such alternative names are included in a CRL, the 803 issuer alternative name field shall be used. 805 5.2.3 CRL Number 807 The cRLNumber is a non-critical CRL extension which conveys a 808 monotonically increacing sequence number for each CRL issued by a 809 given CA through a given CA X.500 Directory entry or CRL distribution 810 point. This extension allows users to easily determine is a 811 particular CRL superceeds another CRL. Use of this CRL extension is 812 strongly encouraged. 814 CRLNumber ::= INTEGER 816 5.2.4 Issuing Distribution Point 818 The issuingDistributionPoint is a critical CRL extension that 819 identifiers the CRL distribution point for this particular CRL, and 820 it indicates whether the CRL covers revocation for end entities 821 certificate only, CA certificates only, or a limitied set of reason 822 codes. Support for CRL distribution points is strongly encouraged. 823 However, the use of certificateHold is strongly discouraged. 825 DistributionPoint ::= SEQUENCE { 826 distributionPoint DistributionPointName, 827 reasons ReasonFlags OPTIONAL } 829 DistributionPointName ::= CHOICE { 830 fullName [0] Name, 831 nameRelativeToCA [1] RelativeDistinguishedName } 833 ReasonFlags ::= BIT STRING { 834 unused (0), 835 keyCompromise (1), 836 caCompromise (2), 837 affiliationChanged (3), 838 superseded (4), 839 cessationOfOperation (5), 840 certificateHold (6) } 842 5.2.5 Delta CRL Indicator 844 The deltaCRLIndicator is a critical CRL extension that identifies a 845 delta-CRL. The use of delta-CRLs is strongly discouraged. Rather, 846 CAs are encouraged to always issue complete CRLs. 848 5.3 CRL Entry Extensions 850 The CRL entry extensions already defined by ANSI X9 and ISO for X.509 851 v2 CRLs provide methods for associating additional attributes with 852 CRL entries. The X.509 v2 CRL format also allows communities to 853 define private CRL entry extensions to carry information unique to 854 those communities. Each extension in a CRL entry may be designated 855 as critical or non-critical. A CRL validation must fail if it 856 encounters an critical CRL entry extension. However, an unrecognized 857 non-critical CRL entry extension may be ignored. The following 858 presents recommended extensions used within Internet CRL entries and 859 standard locations for information. Communities may elect to use 860 additional CRL entry extensions; however, caution should be exercised 861 in adopting any critical extensions in CRL entries which might be 862 used in a general context. 864 5.3.1 Reason Code 866 The reasonCode is a non-critical CRL entry extension that identifies 867 the reason for the certificate revocation. The inclusion of reason 868 codes is encouraged. The reasonCode extension permits certificates 869 to placed on hold or suspended. The processing associated with 870 suspended certificates greatly complicates certificate validation. 871 The use of this feature is strongly discouraged. 873 CRLReason ::= ENUMERATED { 874 unspecified (0), 875 keyCompromise (1), 876 caCompromise (2), 877 affiliationChanged (3), 878 superseded (4), 879 cessationOfOperation (5), 880 certificateHold (6), 881 certHoldRelease (7), 882 removeFromCRL (8) } 884 5.3.2 Expiration Date 886 The expirationDate is a non-critical CRL entry extension that 887 indicates the expiration of a hold entry in a CRL. The use of this 888 extension is strongly discouraged. 890 5.3.3 Instruction Code 892 The instructionCode is a non-critical CRL entry extension that 893 provides a registered instruction identifier which indicates the 894 action to be taken after encountering a certificate that has been 895 placed on hold. The use of this extension is strongly discouraged. 897 5.3.4 Invalidity Date 899 The invalidityDate is a non-critical CRL entry extension that 900 provides the date on which it is known or suspected that the private 901 key was compromised or that the certificate otherwise became invalid. 902 This date may be earlier than the revocation date in the CRL entry 903 (which is the date that the CA revoked the certificate). The use of 904 this extension is encouraged. 906 InvalidityDate ::= GeneralizedTime 908 5.4 Examples 910 << CRL samples including descriptive text and ASN.1 encoded blobs 911 will be inserted. >> 913 6 Certificate and CRL Distribution 915 6.1 Distribution via X.500 917 Within an X.500 Directory, the certificate for an end entity can be 918 found in the userCertificate attribute. This attribute is normally 919 associated with the strongAuthenticationUser object class. 921 Within an X.500 Directory, the certificate for a certification 922 authority can be found in the cACertificate attribute, and the most 923 recent CRL can be found in the certificateRevocationList attribute. 924 These attributes are normally associated with the 925 certificationAuthority object class. 927 6.2 Distribution via Electronic Mail 929 RFC 1424 specifies methods for key certification, certificate 930 revocation list (CRL) storage, and CRL retrieval. These services are 931 required of an RFC 1422 certification authority. Each service 932 involves an electronic mail request and an electronic mail reply. 934 << Need to define a format for one user to send his certificate to 935 another. This format could be used to obtain arbitrary certificates 936 from a certificate server or to solicit certificates from the user 937 themselves. >> 939 6.3 Distribution via HTTP 941 << Need to define a convention for using HTTP to obtain certificates 942 from a server. >> 944 As discussed in section 4.2.7, the user certificate may contain a URL 945 that specifies the location where the most recent CRL which could 946 contain an entry revoking the certificate can be found. HTTP can be 947 used to fetch the most recent CRL from this location. 949 6.4 On-line Certificate Validation 951 As discussed above, consumers of certificates must be able to 952 determine the validity of a certificate when using the certificate. 953 There are many possible approaches to informing consumers on the 954 status of the certificate and these approaches have different 955 operational characteristics. One alternative is to provide an on- 956 line validation service. Such a service reduces the complexity of 957 the client applications (by moving it to the on-line service), and it 958 provides the most timely status possible. 960 In addition, on-line validation servers can also help to resolve the 961 root key management a distribution problem by providing a single 962 trusted agent for asserting root key status where the agent is 963 independent of the certification hierarchy itself. 965 The on-line validation could be performed by either the CA who issued 966 the certificate (directly or via a delegatee) or as a general service 967 by a "trusted" third party. Note, this service could also be 968 extended to the validation of any certificate like item (e.g., PGP 969 credential, DNS record, STT credential) and could facilitate 970 application interaction between users using different certificate 971 formats. 973 The general model involves a request/response format which might be 974 transferred using a number of alternative transport protocols. In 975 general, the requestor sends the certificate (or a user reference) 976 along with an indication of the service to be provided. This service 977 might be coupled with the general certificate distribution service by 978 adding service flags to that request as well. 980 The request should contain: << this section is still in progress >> 982 Certificate (or cert path) 983 Service parameters 984 Parse cert for me 985 Check CRLs 986 Result format (ASN, Text, HTML, ....) 987 Sign result (with a specified algorithm) 988 Other qualifiers 989 Desired domain/policy OID (does this validate to a specific Root) 991 A possible Syntax: 993 ValidationRequest ::= SEQUENCE { 994 CertPathType OBJECT IDENTIFIER, 995 CertPath SEQUENCE OF OCTET STRING, 996 TargetRootID Name OPTIONAL, 997 ServiceParams SEQUENCE OF ServiceParam OPTIONAL } 999 ServiceParam ::= INTEGER { 1000 ASNresult (1), 1001 Textresult (2), 1002 HTMLresult (3), 1003 .... } 1005 The response should contain: 1007 Status: current/valid, expired (date), revoked (date/reason), suspended 1008 Cert path problem: what failed, where, and why 1009 Policy/attribute/constraints from validated cert path 1010 Parsed data: name, key, attributes 1011 Could be signed by validator or rely on secure channel 1013 A possible syntax: 1015 ValidationResponse ::= OPTIONALLY SIGNED SEQUENCE { 1016 validator Name OPTIONAL, 1017 certInfo CHOICE { 1018 cert OCTET STRING, 1019 reference IssuerSerial, 1020 certdata T61 STRING }, 1021 -- text including name, key, and attributes 1022 status StatusCode, 1023 detail ANY Defined By StatusCode OPTIONAL, 1024 validationData ???? } 1025 -- problems with cert path, policy attributes, etc. 1027 StatusCode ::= INTEGER { 1028 valid (1), 1029 revoked (2), 1030 expired (3), 1031 suspended (4) } 1033 7 Key Pair Updating Procedures 1035 A fundamental principle of the PKI is that it must be possible to 1036 update all of the cryptographic keys used, both by end entity's and 1037 by PKI components (e.g., CAs). Furthermore, for the PKI to be 1038 usable, the update of one key pair must not force the update of any 1039 other key pair or Certificate. In this section, we deal with the 1040 update of CA key pairs. Key updating for end entities is dealt with 1041 in section 9.4. 1043 For CA key pair updating we will fulfil the following requirements: 1045 (a) All certificates valid before the update must remain valid. 1047 (b) A subject whose certificate is verifiable using the new CA 1048 public key must also be able to verify certificates verifiable using 1049 the old public key. 1051 (c) End entities who directly trust the old CA key pair must be able 1052 to verify certificates signed using the new key CA private key. This 1053 is required for situations where the old CA public key is "hardwired" 1054 into the end entity's cryptographic equipment (e.g., smartcard 1055 memory). 1057 (d) All entities (not just those certified by that CA) must have 1058 both the new and old CA public keys available from the time of the 1059 change (whether or not they trust it is a local matter). 1061 The basis of the scheme described below is that the CA protects its 1062 new public key using its previous private key and vice-versa. Thus 1063 when a CA updates its key pair it must generate two new cACertificate 1064 attribute values if certificates are made available using an X.500 1065 directory. 1067 Note that the scheme below does not make use of any of the X.509 v3 1068 certificate extensions as it must be able to work for X.509 v1 1069 certificates. However, the presence of the KeyIdentifier extension 1070 permits efficiency improvements. 1072 Note that the change of a CA key affects both certificate 1073 verification and CRL checking. 1075 It is worth noting that the operation involved here is key update, 1076 only the key pair (and related attributes) of the CA are changed. 1077 Thus, this operation cannot be used in the event of a CA key 1078 compromise. 1080 While the scheme could be generalised to cover cases where the CA 1081 updates its key pair more than once during the validity period of one 1082 of its end entity's certificates, this generalisation seems of 1083 dubious value. Therefore, the validity period of a CA key must be 1084 greater than the validity period of any certificate issued by that 1085 CA. 1087 We first present the data structures required then specify the steps 1088 involved in changing the CA key and the various possibilities for 1089 certificate verification. Note that the description below assumes 1090 that X.500 is used for publishing certificates. This assumption is 1091 simply for clarity of presentation, if the same data structures are 1092 published some other way, the scheme still works. 1094 7.1 ASN.1 Data Types 1096 -- existing CA cert from X.509 1097 -- this contains the current and old CA certificate(s) 1098 -- all entities under this CA need a local copy of 1099 -- one of these 1100 CACertificate ::= ATTRIBUTE 1101 WITH ATTRIBUTE-SYNTAX Certificate 1103 -- Securing the old CA public key with the new private key and 1104 -- vice-versa. Securing the new CA public key with the old private 1105 -- key is needed to avoid having to issue the new CA public key 1106 -- using out-of-band means to entities certified using the old CA 1107 -- key; with this they can verify certificates signed using the new 1108 -- CA private key. 1109 -- The data structures can be stored in this X.500 attribute 1110 CALinkages ::= ATTRIBUTE 1111 WITH ATTRIBUTE-SYNTAX CALinkage 1113 CALinkage ::= SIGNED SEQUENCE { 1114 protectedCACertSerial INTEGER, 1115 -- the serial number in the CACertificate 1116 -- value which we wish to link to 1117 protectingCACertSerial INTEGER, 1118 -- the serial number in the CACertificate 1119 -- value which contains the public key 1120 -- corresponding to the private key used 1121 -- to sign this 1122 caName Name, 1123 link HASH Certificate } 1125 7.2 CA Operator Actions 1127 To change the key of the CA, the CA operator does the following: 1129 (1) Generates a new key pair. 1131 (2) Calculate the certificate for the new key pair. 1133 (3) Create a CALinkage (based on the old CA certificate) using the 1134 new private key. 1136 (4) Create a CALinkage (based on the new CA certificate) using the 1137 old private key. 1139 (5) Publish these new data structures. 1141 7.3 Verifying Certificates 1143 Normally when verifying a signature, the verifier simply verifies the 1144 certificate containing the public key of the signer. However, once a 1145 CA is allowed to update it's key there are a range of new 1146 possibilities. These are shown in the table below. 1148 The term PSE (personal security environment) is used to denote 1149 locally held and trusted information. This can only be assumed to 1150 include a single CA public key. 1152 CACertificate contains CACertificate contains only 1153 NEW public key OLD public key 1155 PSE Contains PSE Contains PSE Contains PSE Contains 1156 NEW public OLD public NEW public OLD public 1157 key key key key 1159 Signer's Case 1: Case 3: Case 5: Case 7: 1160 cert is This is the In this case Although the In this case 1161 protected standard the verifier CA operator the CA 1162 using NEW case where must access has not operator has 1163 public the the updated the not updated 1164 key verifier directory in directory the the directory 1165 can order to get verifier can attributes 1166 directly the value of verify the and so the 1167 verify the the NEW certificate verification 1168 certificate public key directly - will FAIL 1169 without this is thus 1170 using the the same as 1171 directory case 1. 1173 Signer's Case 2: Case 4: Case 6: Case 8: 1174 cert is In this In this case The verifier Although the 1175 protected case the the verifier thinks this CA operator 1176 using OLD verifier can directly is the has not 1177 public must access verify the situation of updated the 1178 key the certificate case 2 and directory, the 1179 directory without will access verifier can 1180 in order to using the the verify the 1181 get the directory directory, certificate 1182 value of however the directly -- 1183 the OLD verification this is thus 1184 public key will FAIL the same as 1185 case 4. 1187 7.3.1 Verification in cases 1, 4, 5 and 8 1189 In these cases the verifier has a local copy of the CA public key 1190 which can be used to verify the certificate directly. This is the 1191 same as the situation where no key change has ever occurred. 1193 Note that case 8 may arise between the time when the CA operator has 1194 generated the new key pair and the time when the CA operator stores 1195 the updated attributes in the Directory. Case 5 can only arise if 1196 the CA operator has issued both the signer's and verifier's 1197 certificates during this "gap" (the CA operator should avoid this as 1198 it leads to the failure cases described below). 1200 7.3.2 Verification in case 2 1202 In case 2 the verifier must get access to the old public key of the 1203 CA. The verifier does the following: 1205 (1) Lookup the CACertificate attribute in the directory and pick the 1206 appropriate value. 1208 (2) Lookup the associated CALinkages attribute value. 1210 (3) Verify that these are correct using the new CA key (which the 1211 verifier has locally). 1213 (4) If correct then check the signer's certificate using the old CA 1214 key. 1216 Case 2 will arise when the CA operator has issued the signer's 1217 certificate, then changed key and then issued the verifier's 1218 certificate, so it is quite a typical case. 1220 7.3.3 Verification in case 3 1222 In case 3 the verifier must get access to the new public key of the 1223 CA. The verifier does the following: 1225 (1) Lookup the CACertificate attribute in the directory and pick the 1226 appropriate value. 1228 (2) Lookup the associated CALinkages attribute value. 1230 (3) Verify that these are correct using the old CA key (which the 1231 verifier has stored locally). 1233 (4) If correct then check the signer's certificate using the new CA 1234 key. 1236 Case 3 will arise when the CA operator has issued the verifier's 1237 certificate, then changed key and then issued the signer's 1238 certificate, so it is also quite a typical case. 1240 7.3.4 Failure of verification in case 6 1242 In this case, the CA has issued the verifier's PSE containing the new 1243 key without updating the directory attributes. This means that the 1244 verifier has no means to get a trustworthy version of the CA's old 1245 key and so verification fails. 1247 Note that the failure is the CA operator's fault. 1249 7.3.5 Failure of verification in case 7 1251 In this case the CA has issued the signer's certificate protected 1252 with the new key without updating the directory attributes. This 1253 means that the verifier has no means to get a trustworthy version of 1254 the CA's new key and so verification fails. 1256 Note that the failure is the CA operator's fault. 1258 7.4 Revocation - Change of CA Key 1260 As we saw above, the verification of a certificate becomes more 1261 complex once the CA is allowed to change its key. This is also true 1262 for revocation checks as the CA may have signed the CRL using a newer 1263 private key than the one within the user's PSE. The analysis of the 1264 alternatives is exactly as for certificate verification. 1266 8 Guidelines for Certificate Policy Definition 1268 << To Be Decided >> 1270 9 Supporting Management Protocols 1272 The certificate management protocol exchanges defined in this section 1273 support management communications between client systems, each of 1274 which supports one or more users, and CAs. In addition, one 1275 management protocol exchange is defined for use between two CAs, for 1276 the purpose of establishing cross-certificates. Each exchange is 1277 defined in terms of a sequence of messages between the two systems 1278 concerned. This section defines the contents of the messages 1279 exchanged. 1281 The protocols for conveying these exchanges in different environments 1282 (on-line, E-mail, and WWW) are specified in Section 10. 1284 The protocol exchanges defined in this document are: 1286 - One-Step Registration/Certification 1287 - User Registration 1288 - User Initialization/Certification with Client-Generated 1289 Encryption Key Pair 1290 - User Initialization/Certification with Centrally-Generated 1291 Encryption Key Pair 1292 - Encryption Key Pair Recovery 1293 - Key Pair Update for Client-Generated Key Pair 1294 - Key Pair Update for Centrally-Generated Key Pair 1295 - Key Pair Update (Centrally-Initiated) 1296 - Revocation Request 1297 - Cross-Certification 1299 The following notes apply to the protocol exchange descriptions: 1301 - In exchanges between a client system and a CA, the protocol exchange 1302 is initiated by the client system. The one exception to this is the 1303 Key Pair Update (Centrally-Initiated) exchange. 1304 - To provide an upgrade path, a protocol version indicator is always 1305 included in the first message of an exchange. 1306 - A message type indicator is included in the protected part of all 1307 messages. 1308 - All messages include an optional transaction identifier which is used 1309 to assist correlation of request and response messages for one 1310 transaction. This identifier is generated by the initiator of the 1311 exchange and will typically include the initiator's name plus a 1312 transaction sequence number. 1313 - The initial message from the client to the CA may optionally contain 1314 the client system time. This is used to facilitate the correction 1315 of client time problems by central administrators. 1316 - Responses from CA to client include the CA system time. The client 1317 can use this time to check that its own system time is within a 1318 reasonable range. 1319 - Random numbers are used in some of the protocols to prevent replay 1320 of the exchanges. 1321 - Responses can be aborted at any time. An enumerated error code is 1322 sent from the aborting end and can be decoded into a user readable 1323 error string at the other end. Error codes are not specified in 1324 this version of this document. 1325 - Items in square brackets [] are optional. 1326 - In every instance in which a public key is transferred, it is 1327 transferred in the form of X.509 subjectPublicKeyInfo, including 1328 algorithm identifier and (optional) parameters. 1329 - When a new key pair is generated by a client, a key identifier may 1330 optionally be sent to the CA along with the public key for inclusion 1331 in the certificate. However, the CA may override this value with a 1332 key identifier of its own. If the client is concerned about the key 1333 identifier value used, it should check the new certificate. 1334 - Where this description refers to an encryption key pair, this could 1335 be a key pair for RSA key transport or could be key pair for key 1336 establishment using, for example, a Diffie-Hellman based algorithm. 1338 Note that in this version of this document, the message contents are 1339 defined at an outline level only. A future version of this document 1340 will fill out the full details of message syntax in ASN.1. 1342 9.1 One-Step Registration/Certification 1344 9.1.1 Overview of Exchange 1346 This protocol exchange is used to support registration of a user, 1347 together with request and issue of certificate(s), for use in 1348 environments in which client systems generate their own key pair or 1349 pairs. It is a simple exchange, designed 1351 for easy implementation, but lacks some of the features and 1352 protective measures inherent in the exchanges defined subsequently. 1353 The user must have a pre-established digital signature key pair. 1354 Furthermore, the user must have a preestablished reliably-known copy 1355 of the public key of the CA concerned (this generally requires some 1356 form of off-line data exchange to ensure that the correct public key 1357 is known). 1359 If the request is accepted by the CA, it results in the generation of 1360 certificate(s) for client-generated digital signature and/or 1361 encryption public keys. 1363 9.1.2 Detailed Description 1365 A single message is used for a user to register with a CA and request 1366 certificate issuance. 1368 RegCertRequest:: client-to-CA 1369 { 1370 protocol version 1371 message type 1372 [transaction identifier] 1373 [client system time] 1374 user unique name (DN) 1375 [user signature public key] 1376 [user signature key identifier] 1377 [client-generated encryption public key] 1378 [client-generated encryption key identifier] 1379 user attributes 1380 [certificate policy] 1381 } Signature (signed with user signature private key) 1383 No specific message is defined to return the generated 1384 certificate(s). It is assumed that the client will obtain a copy of 1385 the certificate(s) by other means and, by checking the certificate 1386 contents and CA signature, ensure that the request was processed by 1387 the correct CA. 1389 9.2 User Registration 1391 9.2.1 Overview of Exchange 1393 This protocol exchange is used for a user to request registration 1394 with a CA. It is a first step in the establishment of key materials 1395 and certificates between client and CA for that user. Assuming the 1396 CA accepts the request, it will be necessary to follow-up this 1397 exchange with a User Initialization/Certification exchange as 1398 described in 9.3 or 9.4. At the time this request is issued, it is 1399 not necessary for the client to have any established key materials. 1401 9.2.2 Detailed Description 1403 A single message is used for a user to request registration with a 1404 CA. 1406 RegisterUserRequest:: client-to-CA 1407 { 1408 protocol version 1409 message type 1410 [transaction identifier] 1411 [client system time] 1412 user unique name (DN) 1413 user attributes 1414 [certificate policy] 1415 } Signature (signed with user signature private key) 1417 No specific message is defined to respond to this request. It is 1418 asumed that the procedure defined in 9.3 or 9.4 will follow. 1420 9.3 User Initialization/Certification with Client-Generated Encryption 1421 Key Pair 1423 9.3.1 Overview of Exchange 1425 This protocol exchange is used to support client initialization, 1426 including certificate issuance, for one user, with provision for 1427 simultaneously establishing and certifying separate key pairs for 1428 digital signature and encryption (or encryption key exchange) 1429 purposes. Both key pairs are generated by the client and no private 1430 key is exposed to the CA. Generation and certification of the 1431 encryption key pair is optional. 1433 Prior to conducting this exchange, the user must have registered with 1434 the CA, either using the user registration exchange defined in 9.2 or 1435 by other means. 1437 Following registration, the CA creates a secret data item, called an 1438 authorization code, and transfers this data item by out-of-band 1439 means to the user. The authorization code is used to establish 1440 authentication and integrity protection of the user 1441 initialization/certification on-line exchange. This is done by 1442 generating a symmetric key based on the authorization code and using 1443 this symmetric key for generating Message Authentication Codes (MACs) 1444 on all exchanges between client and CA. 1446 In the first two messages exchanged, the client sends its user 1447 signature public key (and, optionally, a client-generated encryption 1448 public key) to the CA and the CA returns the currently valid CA 1449 certificate(s). This exchange of public keys allows the client and CA 1450 to authenticate each other. 1452 9.3.2 Detailed Description 1454 The user receives a reference number and a secret machine-generated 1455 authorization code from the CA administrator. Both pieces of 1456 information are transferred to the user in a secure manner which 1457 preserves their integrity and confidentiality. The reference number 1458 is used to uniquely identify the client at the CA and the 1459 authorization code is used to secure the exchange integrity-wise. The 1460 reference number is used instead of a DN to uniquely identify the 1461 client because a DN may be lengthy and difficult for a user to 1462 manually type without error. 1464 After the reference number and authorization code have been entered 1465 by the user, the client generates: 1467 - a client random number, 1468 - (if a new user signature key pair is required) a new user 1469 signature key pair, 1470 - (if a new client-generated encryption key pair is required) a 1471 new encryption key pair. 1473 The client securely stores locally any new signature private key 1474 and/or client-generated encryption private key. The client then 1475 sends the message InitClientRequest to the CA. The entire structure 1476 is protected from modification with a MAC based on the authorization 1477 code. 1479 InitClientRequest:: client-to-CA 1480 { 1481 protocol version 1482 message type 1483 [transaction identifier] 1484 [client system time] 1485 client random number 1486 reference number 1487 user signature public key 1488 [user signature key id] 1489 [client-generated encryption public key] 1490 [client-generated encryption key id] 1491 MAC algorithm id 1492 } MAC (key based on authorization code) 1494 Upon receipt of the InitClientRequest structure, if the CA recognizes 1495 the reference number and if the protocol version is valid, it saves 1496 the client random number, generates its own random number (CA random 1497 number), and validates the MAC. Then for the user encryption public 1498 key, it creates: 1500 - a new certificate for the user?s digital signature public key, 1501 - (if a new client-generated encryption key pair is required) a 1502 new certificate. 1504 The CA responds to the client with the message InitClientResponse. 1505 The entire structure is protected from modification with a MAC based 1506 on the authorization code. 1508 InitClientResponse:: CA-to-client 1509 { 1510 message type 1511 [transaction identifier] 1512 client random number 1513 CA random number 1514 CA signature public key certificate 1515 new user signature public-key certificate 1516 [new user encryption public-key certificate] 1517 CA system time 1518 MAC algorithm id 1519 } MAC (key based on authorization code) 1521 Upon receipt of the InitClientResponse structure, the client checks 1522 that its own system time is sufficiently close to the CA system time, 1523 checks the client random number, and validates the MAC. The client 1524 then securely stores the new certificates and acknowledges the 1525 transaction by sending back the message InitClientConfirm. The fields 1526 in this message are protected from modification with a MAC based on 1527 the authorization code. 1529 InitClientConfirm:: client-to-CA 1530 { 1531 message type 1532 [transaction identifier] 1533 client random number 1534 CA random number 1535 MAC algorithm id 1536 } MAC (key based on authorization code) 1538 Upon receipt of the InitClientConfirm structure, the CA checks the 1539 random numbers and validates the MAC. If no errors occur, the CA 1540 archives the new user public-key certificate(s). 1542 9.4 User Initialization/Certification with Centrally-Generated 1543 Encryption Key Pair 1545 9.4.1 Overview of Exchange 1547 This protocol exchange is used to support client initialization, 1548 including certificate issuance, for one user, with provision for 1549 simultaneously establishing and certifying separate key pairs for 1550 digital signature and encryption (or encryption key exchange) 1551 purposes. The digital signature key pair is generated by the client. 1552 Optionally, a new encryption key pair is generated by (and, 1553 optionally, backed up by) a central facility associated with the CA. 1555 Prior to conducting this exchange, the user must have registered with 1556 the CA, either using the user registration exchange defined in 9.2 or 1557 by other means. 1559 Following registration, the CA creates a secret data item, called an 1560 authorization code, and transfers this data item by out-of-band 1561 means to the user. The authorization code is used to establish 1562 authentication and integrity protection of the user 1563 initialization/certification on-line exchange. This is done by 1564 generating a symmetric key based on the authorization code and using 1565 this symmetric key for generating Message Authentication Codes (MACs) 1566 on all exchanges between client and CA. 1568 In the first two messages exchanged, the client sends its user 1569 signature public key to the CA and the CA returns the currently valid 1570 CA certificate(s). This exchange of public keys allows the client and 1571 CA to authenticate each other. 1573 If a centrally-generated encryption key pair is to be established, 1574 the private key of the newly generated key pair is sent from the CA 1575 to the client. The client first generates a protocol encryption key 1576 pair and sends the public protocol encryption key to the CA. The CA 1577 creates a random symmetric key called the session key and encrypts 1578 the user encryption private key with it and then encrypts the session 1579 key with the public protocol encryption key it received from the 1580 client. The CA sends the encrypted user encryption private key and 1581 encrypted session key back to the client. The client uses its private 1582 protocol decryption key to decrypt the session key and then uses the 1583 session key to decrypt the encryption private key. The protocol 1584 encryption key pair and session key are discarded after the exchange. 1586 9.4.2 Detailed Description 1588 The user receives a reference number and a secret machine-generated 1589 authorization code from the CA administrator. Both pieces of 1590 information are transferred to the user in a secure manner which 1591 preserves their integrity and confidentiality. The reference number 1592 is used to uniquely identify the client at the CA and the 1593 authorization code is used to secure the exchange integrity-wise. The 1594 reference number is used instead of a DN to uniquely identify the 1595 client because a DN may be lengthy and difficult for a user to 1596 manually type without error. 1598 After the reference number and authorization code have been entered 1599 by the user, the client generates: 1601 - a client random number, 1602 - (if a new user signature key pair is required) a new user 1603 signature key pair, 1604 - (if a new centrally-generated encryption key pair is required) 1605 a protocol encryption key pair. 1607 The client securely stores locally any new signature private key 1608 and/or client-generated encryption private key. The client then 1609 sends the message InitCentralRequest to the CA. The entire structure 1610 is protected from modification with a MAC based on the authorization 1611 code. 1613 InitCentralRequest:: client-to-CA 1614 { 1615 protocol version 1616 message type 1617 [transaction identifier] 1618 [client system time] 1619 client random number 1620 reference number 1621 user signature public key 1622 [user signature key id] 1623 [protocol encryption key] 1624 MAC algorithm id 1625 } MAC (key based on authorization code) 1627 Upon receipt of the InitCentralRequest structure, if the CA 1628 recognizes the reference number and if the protocol version is valid, 1629 it saves the client random number, generates its own random number 1630 (CA random number), and validates the MAC. It then creates: 1632 - a new certificate for the user?s digital signature public key, 1633 - (if a new centrally-generated encryption key pair is required) 1634 a session key, a new user encryption key pair, and a new 1635 certificate for the user encryption public key. 1637 The CA responds to the client with the message InitCentralResponse. 1638 If a new centrally-generated encryption key pair is being generated, 1639 the user encryption private key is encrypted using the session key 1640 and the session key is encrypted with the protocol encryption public 1641 key. The entire structure is protected from modification with a MAC 1642 based on the authorization code. 1644 InitCentralResponse:: CA-to-client 1645 { 1646 message type 1647 [transaction identifier] 1648 client random number 1649 CA random number 1650 CA signature public key certificate 1651 new user signature public-key certificate 1652 [new user encryption public-key certificate] 1653 [new user encryption private key encrypted with session key] 1654 [session key encrypted with protocol encryption key] 1655 CA system time 1656 MAC algorithm id 1657 } MAC (key based on authorization code) 1659 Upon receipt of the InitCentralResponse structure, the client checks 1660 that its own system time is sufficiently close to the CA system time, 1661 checks the client random number, and validates the MAC. If a new 1662 centrally-generated encryption key pair is included, the client 1663 decrypts the encryption private key. The client then securely stores 1664 the new certificates and encryption private key (if present) and 1665 acknowledges the transaction by sending back the message 1666 InitCentralConfirm. The fields in this message are protected from 1667 modification with a MAC based on the authorization code. 1669 InitCentralConfirm:: client-to-CA 1670 { 1671 message type 1672 [transaction identifier] 1673 client random number 1674 CA random number 1675 MAC algorithm id 1676 } MAC (key based on authorization code) 1677 Upon receipt of the InitCentralConfirm structure, the CA checks the 1678 random numbers and validates the MAC. If no errors occur, the CA 1679 archives the new user public-key certificate(s) and (if there is a 1680 new centrally-generated encryption key pair and key recovery is to be 1681 supported) the encryption private key. 1683 9.5 Encryption Key-Pair Recovery 1685 9.5.1 Overview of Exchange 1687 This protocol exchange is used to support recovery in the event that 1688 a client no longer has a valid signature key pair (due to expiration 1689 or revocation), or client system key materials have been lost, e.g., 1690 as a result of a forgotten user password. This exchange assumes a 1691 system in which an encryption key pair has been centrally generated 1692 and backed up (by a central system associated with a CA). 1694 This exchange is very similar to the exchange for User 1695 Initialization/Certification with Centrally-Generated Encryption Key 1696 Pair. The client and CA start without a way to trust one another, 1697 i.e., they have no reliable shared key pairs. 1699 9.5.2 Detailed Description 1701 The user must first receive, by out-of-band means, a reference number 1702 and a secret machine-generated authorization code from the CA 1703 administrator. The on-line exchange then consists of a sequence of 1704 KeyRecoverRequest, KeyRecoverResponse and KeyRecoverConfirm, which 1705 are the same as the exchange in 9.4 except for two differences. 1706 First, the CA does not generate (or archive) a new encryption key 1707 pair and encryption public-key certificate for the user. Second, the 1708 user?s entire encryption key history (list of encryption public-key 1709 certificates and matching encryption private keys) are sent back to 1710 the client with KeyRecoverResponse. 1712 KeyRecoverRequest:: client-to-CA 1713 { 1714 protocol version 1715 message type 1716 [transaction identifier] 1717 [client system time] 1718 client random number 1719 reference number 1720 user signature public key 1721 [user signature key id] 1722 protocol encryption key 1723 MAC algorithm id 1724 } MAC (key based on authorization code) 1725 KeyRecoverResponse:: CA-to-client 1726 { 1727 message type 1728 [transaction identifier] 1729 client random number 1730 CA random number 1731 CA certificate(s) 1732 user encryption private key history encrypted with session key 1733 session key encrypted with protocol encryption key 1734 user encryption public-key certificate history 1735 new user signature public-key certificate 1736 CA system time 1737 MAC algorithm id 1738 } MAC(key based on authorization code) 1740 KeyRecoverConfirm:: client-to-CA 1741 { 1742 message type 1743 [transaction identifier] 1744 client random number 1745 CA random number 1746 MAC algorithm id 1747 } MAC (key based on authorization code) 1749 9.6 Key Pair Update for Client-Generated Key Pair(s) 1751 9.6.1 Overview of Exchange 1753 This exchange is used to update the signature key pair and/or 1754 client-generated encrypyion key pair of a user, (e.g., as a result of 1755 routine cryptoperiod expiry). 1757 A user must have a valid signature key pair in order to do this 1758 exchange. It is up to the client to determine when a new signature 1759 key pair should be generated; this has to be done prior to the 1760 expiration of its signature public-key certificate. 1762 A key pair update request from a client is digitally signed using the 1763 original user signature private key, this signature being verifiable 1764 using an existing signature certificate. If the key pair update is 1765 for a new user digital signature key, then the client signs the 1766 request message once more (including the first signature), this time 1767 using the new signature private key. The reason for this second 1768 signature is to prove to the CA that the client possesses both the 1769 new and old private keys. 1771 The request is verified at the CA by using the matching user 1772 signature public key. A protocol signature key pair is used to 1773 authenticate messages from the CA to the client. CA responses are 1774 signed with the protocol signature private key. 1776 A CA response is validated at the client by using a protocol 1777 signature public-key certificate which is included in the CA 1778 response. The protocol signature public-key certificate can be 1779 validated by using the CA certificate stored at the client. A new 1780 user initialization (as in 9.3) or key pair recovery (as in 9.4) must 1781 be done if the user signature key pair becomes invalid. 1783 In some client system implementations, local key materials are stored 1784 in an encrypted key data disk file. A user may have several copies of 1785 this key data file on different computers. It is possible that a key 1786 update could occur and the user could forget to copy the updated key 1787 data file to all the computers they use. To help keep the client 1788 using the latest keys, the client sends the CA the serial number of 1789 the latest user signature public-key certificate it has in the key 1790 update request. Serial numbers are sent so that the CA can check if 1791 the client has the latest key pair. If the client does not have the 1792 latest signature private key and the signature public-key certificate 1793 serial number is equal to that of a previous certificate, the CA 1794 sends back an error code which indicates that the client has an old 1795 version of the key data file. After this, the client can either find 1796 the latest key data file or, if that fails, key recovery can be done. 1798 9.6.2 Detailed Description 1800 The client initiates the exchange by creating a new signature and/or 1801 encryption key pair and generating a random number (client random 1802 number). The client then sends the CA the message 1803 UpdateClientKeyRequest. The fields in this message are protected from 1804 modification and authenticated by a digital signature using the pre- 1805 existing user signature private key. If the update includes a new 1806 signature key pair, the result is additionally signed using the new 1807 user signature private key. 1809 UpdateClientKeyRequest:: client-to-CA 1810 { 1811 protocol version 1812 message type 1813 [transaction identifier] 1814 [client system time] 1815 client random number 1816 user unique name (DN) 1817 [new user signature public key] 1818 [new user signature key id] 1819 [new user encryption public key] 1820 [new user encryption key id] 1821 serial number of latest signature public-key certificate 1822 } Signature (signed with pre-existing user signature private key) 1823 [Signature (signed with new user signature private key)] 1825 Upon receipt of the UpdateClientKeyRequest structure, the CA checks 1826 the protocol version, checks the serial number, saves the client 1827 random number, generates its own random number (CA random number) and 1828 verifies the signature using the previous user verification key which 1829 is archived at the CA. If a user digital signature key pair is being 1830 updated, the CA also checks the second signature. It then generates 1831 new user signature and/or encryption public-key certificate(s). The 1832 CA responds with the message UpdateClientKeyResponse. The fields in 1833 this message are protected from modification and authenticated by a 1834 digital signature using the CA protocol signature private key. 1836 UpdateClientKeyResponse:: CA-to-client 1837 { 1838 message type 1839 [transaction identifier] 1840 client random number 1841 CA random number 1842 protocol signature public-key certificate 1843 [new user signature public-key certificate] 1844 [new user encryption public-key certificate] 1845 CA system time 1846 } Signature (signed with protocol signature private key) 1848 Upon receipt of the UpdateClientKeyResponse structure, the client 1849 verifies the digital signature using the protocol verification key 1850 contained in the protocol signature public-key certificate, checks 1851 that its own system time is close to the CA system time, and checks 1852 the received client random number. The client then securely stores 1853 locally the new user public-key certificate(s). It responds with the 1854 message UpdateClientKeyConfirm. The fields in this message are 1855 protected from modification and authenticated by a digital signature 1856 using the pre-existing user signature private key. 1858 UpdateClientKeyConfirm:: client-to-CA 1859 { 1860 message type 1861 [transaction identifier] 1862 client random number 1863 CA random number 1864 } Signature (signed with pre-existing user signature private key) 1866 Upon receipt of the UpdateClientKeyConfirm structure, the CA checks 1867 that the client and CA random numbers are the same as the ones 1868 initially generated, and verifies the received signature using the 1869 previous user signature public key which is archived at the CA. The 1870 CA then archives the new user public-key certificate(s) and updates 1871 its data stores to reflect the new status of the user. 1873 9.7 Key Pair Update for Centrally-Generated Encryption Key Pair 1875 9.7.1 Overview of Exchange 1877 This exchange is used to update the encryption key pair of an user, 1878 under the assumption that encryption key pairs are generated (and, 1879 optionally, backed up) centrally. A user must have a valid signature 1880 key pair in order to do this exchange. It is up to the client to 1881 determine when a new encryption key pair should be generated; this 1882 has to be done some time before the expiration date in its encryption 1883 public-key certificate. 1885 9.7.2 Detailed Description 1887 The client initiates the exchange by generating a random number 1888 (client random number) and a protocol encryption key pair. The client 1889 then sends the CA the message UpdateEncKeyRequest1. The fields in 1890 this message are protected from modification and authenticated by a 1891 digital signature using the latest user signature private key. 1893 UpdateCentralKeyRequest:: client-to-CA 1894 { 1895 protocol version 1896 message type 1897 [transaction identifier] 1898 [client system time] 1899 client random number 1900 user unique name (DN) 1901 latest user encryption public-key certificate serial number 1902 latest user signature public-key certificate serial number 1903 protocol encryption key 1904 } Signature (signed with latest user signature private key) 1906 Upon receipt of the UpdateCentralKeyRequest structure, the CA checks 1907 the protocol version, checks the serial numbers, saves the client 1908 random number, generates its own random number (CA random number), 1909 generates a session key, and verifies the received signature using 1910 the latest user signature public key which is archived at the CA. It 1911 then generates a new end-user encryption key pair and encryption 1912 public-key certificate for the user. In the case where the encryption 1913 public-key certificate serial number is the second latest, the CA 1914 does not generate any keys and uses the latest encryption public-key 1915 certificate and encryption private key that it has. The CA responds 1916 with the message UpdateEncKeyResponse1. In this message, the new or 1917 latest encryption private key is encrypted with the session key and 1918 the session key is encrypted with the protocol encryption key. The 1919 fields in this message are protected from modification and 1920 authenticated by a digital signature using the protocol signature 1921 private key. 1923 UpdateCentralKeyResponse:: CA-to-client 1924 { 1925 message type 1926 [transaction identifier] 1927 client random number 1928 CA random number 1929 new or latest user encryption private key encrypted with session key 1930 new or latest user encryption public-key certificate 1931 session key encrypted with protocol encryption key 1932 protocol signature public-key certificate 1933 CA system time 1934 } Signature (signed with protocol signature private key) 1936 Upon receipt of the UpdateCentralKeyResponse structure, the client 1937 verifies the digital signature using the protocol signature public- 1938 key certificate, makes sure its own system time is close to the CA 1939 system time, and checks the received client random number. The client 1940 then decrypts the new or latest encryption private key and securely 1941 stores locally the new or latest user encryption public-key 1942 certificate and encryption private key. It responds with the message 1943 UpdateCentralKeyConfirm. The fields in this message are protected 1944 from modification and authenticated by a digital signature using the 1945 latest user signature private key. 1947 UpdateCentralKeyConfirm:: client-to-CA 1948 { 1949 message type 1950 [transaction identifier] 1951 client random number 1952 CA random number 1953 } Signature (signed with latest user signature private key) 1955 Upon receipt of the UpdateClientKeyConfirm structure, the CA checks 1956 that the client and CA random numbers are correct and verifies the 1957 signature using the latest user signature public key which is 1958 archived at the CA. If no errors occur, the CA archives the new user 1959 encryption public-key certificate and encryption private key, and 1960 updates its data stores to reflect the new status of the user. 1962 9.8 Key Pair Update (Centrally-Initiated) 1964 9.8.1 Overview of Exchange 1966 This exchange is used to update the encryption key pair of an user, 1967 under the assumption that encryption key pairs are generated (and, 1968 optionally, backed up) centrally. This exchange differs from the 1969 preceding exchange (Key Pair Update for Centrally-Generated 1970 Encryption Key Pair) in that the exchange is initiated by the CA 1971 rather than the client. 1973 9.8.2 Detailed Description 1975 << To be supplied >> 1977 9.9 Revocation Request 1979 9.9.1 Overview of Exchange 1981 This protocol exchange is used to support a revocation request from a 1982 user or other authorized party. 1984 9.9.2 Detailed Description 1986 << To be supplied >> 1988 9.10 Cross-Certification 1990 9.10.1 Overview of Exchange 1992 The cross certification exchange allows two CAs to simultaneously 1993 certify each other. This means that each CA will create a certificate 1994 that contains the CA verification key of the other CA. 1996 Cross certification is initiated at one CA known as the responder. 1997 The CA administrator for the responder identifies the CA it wants to 1998 cross certify and the responder CA equipment generates an 1999 authorization code. The responder CA administrator passes this 2000 authorization code by out-of-band means to the requester CA 2001 administrator. The requester CA administrator enters the 2002 authorization code at the requester CA in order to initiate the on- 2003 line exchange. 2005 The authorization code is used for authentication and integrity 2006 purposes. This is done by generating a symmetric key based on the 2007 authorization code and using the symmetric key for generating Message 2008 Authentication Codes (MACs) on all messages exchanged. 2010 Serial numbers and protocol version are used in the same manner as in 2011 the above CA-client exchanges. 2013 9.10.2 Detailed Description 2015 The requester CA initiates the exchange by generating a random number 2016 (requester random number). The requester CA then sends the responder 2017 CA the message CrossCertifyRequest. The fields in this message are 2018 protected from modification with a MAC based on the authorization 2019 code. 2021 CrossCertifyRequest:: requester CA to responder CA 2022 { 2023 protocol version 2024 message type 2025 [transaction identifier] 2026 requester random number 2027 requester CA unique name (DN) 2028 requester CA public key 2029 [requester CA key id] 2030 MAC algorithm id 2031 } MAC (key based on authorization code) 2033 Upon receipt of the CrossCertifyRequest structure, the responder CA 2034 checks the protocol version, saves the requester random number, 2035 generates its own random number (reponder random number) and 2036 validates the MAC. It then generates and archives a new requester 2037 certificate which contains the requester CA public key and is signed 2038 with the responder CA signature private key. The responder CA 2039 responds with the message CrossCertifyResponse. The fields in this 2040 message are protected from modification with a MAC based on the 2041 authorization code. 2043 CrossCertifyResponse:: responder CA to requester CA 2044 { 2045 message type 2046 [transaction identifier] 2047 requester random number 2048 reponder random number 2049 requester certificate (requester CA is the subject, signed by responder CA) 2050 responder CA public key 2051 [responder CA key id] 2052 responder CA system time 2053 MAC algorithm id 2054 } MAC (key based on authorization code) 2056 Upon receipt of the CrossCertifyResponse structure, the requester CA 2057 checks that its own system time is close to the responder CA system 2058 time, checks the received random numbers and validates the MAC. It 2059 then generates and archives a new responder certificate which 2060 contains the responder CA public key and is signed by the requester 2061 CA signature private key. The requester CA responds with the message 2062 CrossCertifyConfirm. The fields in this message are protected from 2063 modification with a MAC based on the authorization code. 2065 CrossCertifyConfirm:: requester CA to responder CA 2066 { 2067 message type 2068 [transaction identifier] 2069 requester random number 2070 reponder random number 2071 reponder certificate (responder CA is the subject, signed by requester CA) 2072 MAC algorithm id 2073 } MAC (key based on authorization code) 2075 Upon receipt of the CrossCertifyConfirm structure, the responder CA 2076 checks the random numbers, archives the reponder certificate, and 2077 validates the MAC. It writes both the request and reponder 2078 certificates to the Directory. It then responds with the message 2079 CrossCertifyFinish. The fields in this message are protected from 2080 modification with a MAC based on the authorization code. 2082 CrossCertifyFinish:: responder CA to requester CA 2083 { 2084 message type 2085 [transaction identifier] 2086 requester random number 2087 responder random number 2088 MAC algorithm id 2089 } MAC (key based on authorization code) 2091 Upon receipt of the CrossCertifyFinish message, the requester CA 2092 checks the random numbers and validates the MAC. The requester CA 2093 writes both the requester and reponder certificates to the Directory. 2095 10 Management Protocol Transport 2097 10.1 On-line Management Protocol 2099 << To be supplied. This subsection will specify a means for 2100 conveying ASN.1-encoded messages for the protocol exchanges described 2101 in Section 9 over a TCP connection. >> 2103 10.2 Management Protocol via E-mail 2105 << To be supplied. This subsection will specify a means for 2106 conveying ASN.1-encoded messages for the protocol exchanges described 2107 in Section 9 via Internet mail. >> 2109 10.3 Management Protocol via HTTP 2111 << To be supplied. This subsection will specify a means for 2112 conveying ASN.1-encoded messages for the protocol exchanges described 2113 in Section 9 over WWW browser-server links, employing HTTP or related 2114 WWW protocols. >> 2116 11 Algorithm Support 2118 11.1 One-way Hash Functions 2120 One-way hash functions are also called message digest algorithms. 2121 MD5 and SHA-1 will be the most popular one-way hash functions used in 2122 the Internet PKI. However, PEM uses MD2 for certificates [RFC1422, 2123 RFC1423]. For this reason, MD2 will continue to be used in 2124 certificates for many years. 2126 11.1.1 MD5 One-way Hash Function 2128 MD5 was developed by Ron Rivest, and RSA Data Security has placed the 2129 MD5 algorithm in the public domain. MD5 is fully described in RFC 2130 1321. 2132 MD5 is the one-way hash function of choice for use with the RSA 2133 signature algorithm. 2135 11.1.2 MD2 One-way Hash Function 2137 MD2 was also developed by Ron Rivest, but RSA Data Security has not 2138 placed the MD2 algorithm in the public domain. Rather, RSA Data 2139 Security has granted license to use MD2 for non-commerical Internet 2140 Privacy-Enhanced Mail. For this reason, MD2 may continue to be used 2141 with PEM certificates, but MD5 is preferred. MD2 is fully described 2142 in RFC 1319. 2144 11.1.3 SHA-1 One-way Hash Function 2146 SHA-1 was developed by the U.S. Government. SHA-1 is fully described 2147 in FIPS 180-1. 2149 SHA-1 is the one-way hash function of choice for use with the DSA 2150 signature algorithm. 2152 11.2 Signature Algorithms 2154 RSA and DSA will be the most popular signature algorithms used in the 2155 Internet PKI. 2157 There is some ambiguity in 1988 X.509 document regarding the 2158 definition of the SIGNED macro regarding, the representation of a 2159 signature in a certificate or a CRL. The interpretation selected for 2160 the Internet requires that the data to be signed (e.g., the one-way 2161 function output value) is first ASN.1 encoded as an OCTET STRING and 2162 the result is encrypted (e.g., using RSAEncryption) to form the 2163 signed quantity, which is then ASN.1 encoded as a BIT STRING. 2165 11.2.1 RSA Signature Algorithm 2167 The RSA algorithm is named for it's inventors: Rivest, Shamir, and 2168 Adleman. The RSA signature algorithm is defined in PKCS #1. It 2169 combines the either the MD2 or the MD5 one-way hash function with the 2170 RSA asymmetric encryption algorithm. As defined in PKCS #1, the 2171 ASN.1 object identifiers used to identify these signature algorithms 2172 are: 2174 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2175 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 2176 pkcs-1(1) 2 } 2178 md4WithRSAEncryption OBJECT IDENTIFIER ::= { 2179 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 2180 pkcs-1(1) 4 } 2182 << Should we permit RSA with SHA-1? >> 2184 When this object identifier is used with the ASN.1 type 2185 AlgorithmIdentifier, the parameters component of that type is the 2186 ASN.1 type NULL. 2188 11.2.2 DSA Signature Algorithm 2190 The Digital Signature Algorithm (DSA) is also called the Digital 2191 Signature Standard (DSS). DSA was developed by the U.S. Government, 2192 and DSA is used in conjunction with the the SHA-1 one-way hash 2193 function. DSA is fully described in FIPS 186. The ASN.1 object 2194 identifiers used to identify this signature algorithm is: 2196 dsaWithSHA-1 OBJECT IDENTIFIER ::= { 2197 joint-iso-ccitt(2) country(16) US(840) organization(1) 2198 us-government(101) dod(2) infosec(1) algorithms(1) 2 } 2200 When this object identifier is used with the ASN.1 type 2201 AlgorithmIdentifier, the parameters component of that type is 2202 optional. If it is absent, the DSA parameters p, q, and g are 2203 assumed to be known, otherwise the parameters are included using the 2204 following ASN.1 structure: 2206 Dss-Parms ::= SEQUENCE { 2207 p OCTET STRING, 2208 q OCTET STRING, 2209 g OCTET STRING } 2211 Security Considerations 2213 This entire memo is about security mechanisms. 2214 Author Addresses: 2216 Russell Housley 2217 SPYRUS 2218 PO Box 1198 2219 Herndon, VA 22070 2220 USA 2221 housley@spyrus.com 2223 Warwick Ford 2224 Bell-Northern Research 2225 PO Box 3511, Station C 2226 Ottawa, Ontario 2227 Canada KY 4H7 2228 wford@bnr.ca 2230 Stephen Farrell 2231 Software and Systems Engineering Ltd 2232 7984 Fitzwilliam Court 2233 Dublin 2 2234 IRELAND 2235 stephen.farrell@sse.ie 2237 David Solo 2238 BBN 2239 150 CambridgePark Drive 2240 Cambridge, MA 02140 2241 USA 2242 solo@bbn.com