idnits 2.17.1 draft-ietf-pkix-ipki-part4-03.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. Found some kind of copyright notice around line 30 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.1 Overview' ) ** The document seems to lack a Security Considerations section. ** 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.) ** There are 658 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([ABA1], [BAU1], [PEM1], [ISO1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...ment is an I...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '...ups may also ...' == Line 20 has weird spacing: '... may be updat...' == Line 24 has weird spacing: '...e check the...' == (653 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 (April 25, 1998) is 9460 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? 'ISO1' on line 1871 looks like a reference -- Missing reference section? 'PEM1' on line 1878 looks like a reference -- Missing reference section? 'BAU1' on line 1868 looks like a reference -- Missing reference section? 'ABA1' on line 1864 looks like a reference -- Missing reference section? 'PKI1' on line 1881 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.) 3 Internet Draft W. Ford (VeriSign, Inc.) 5 Expires in six months from April 25, 1998 7 Internet X.509 Public Key Infrastructure 8 Certificate Policy and Certification Practices Framework 10 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 6 months 20 and may be updated, replaced, or may become obsolete by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as work in progress. 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Copyright (C) The Internet Society (date). All Rights Reserved. 32 Abstract 34 This document presents a framework to assist the writers of 35 certificate policies or certification practice statements for 36 certification authorities and public key infrastructures. In 37 particular, the framework provides a comprehensive list of topics 38 that potentially (at the writer's discretion) need to be covered in a 39 certificate policy definition or a certification practice statement. 40 This document is being submitted to the RFC Editor with a request for 41 publication as an Informational RFC. 43 1. INTRODUCTION 45 1.1 BACKGROUND 47 A public-key certificate (hereinafter "certificate") binds a 48 public-key value to a set of information that identifies the 49 entity (such as person, organization, account, or site) associated 50 with use of the corresponding private key (this entity is known as 51 the "subject" of the certificate). A certificate is used by a 52 "certificate user" or "relying party" that needs to use, and rely 53 upon the accuracy of, the public key distributed via that 54 certificate (a certificate user is typically an entity that is 55 verifying a digital signature from the certificate's subject or an 56 entity sending encrypted data to the subject). The degree to 57 which a certificate user can trust the binding embodied in a 58 certificate depends on several factors. These factors include the 59 practices followed by the certification authority (CA) in 60 authenticating the subject; the CA's operating policy, procedures, 61 and security controls; the subject's obligations (for example, in 62 protecting the private key); and the stated undertakings and legal 63 obligations of the CA (for example, warranties and limitations on 64 liability). 66 A Version 3 X.509 certificate may contain a field declaring that 67 one or more specific certificate policies applies to that 68 certificate [ISO1]. According to X.509, a certificate policy is 69 "a named set of rules that indicates the applicability of a 70 certificate to a particular community and/or class of application 71 with common security requirements." A certificate policy may be 72 used by a certificate user to help in deciding whether a 73 certificate, and the binding therein, is sufficiently trustworthy 74 for a particular application. The certificate policy concept is 75 an outgrowth of the policy statement concept developed for 76 Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1]. 78 A more detailed description of the practices followed by a CA in 79 issuing and otherwise managing certificates may be contained in a 80 certification practice statement (CPS) published by or referenced 81 by the CA. According to the American Bar Association Digital 82 Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a 83 statement of the practices which a certification authority employs 84 in issuing certificates." [ABA1] 86 1.2 PURPOSE 88 The purpose of this document is to establish a clear relationship 89 between certificate policies and CPSs, and to present a framework 90 to assist the writers of certificate policies or CPSs with their 91 tasks. In particular, the framework identifies the elements that 92 may need to be considered in formulating a certificate policy or a 93 CPS. The purpose is not to define particular certificate policies 94 or CPSs, per se. 96 1.3 SCOPE 98 The scope of this document is limited to discussion of the 99 contents of a certificate policy (as defined in X.509) or CPS (as 100 defined in the ABA Guidelines). In particular, this document 101 describes the types of information that should be considered for 102 inclusion in a certificate policy definition or a CPS. While the 103 framework as presented generally assumes use of the X.509 version 104 3 certificate format, it is not intended that the material be 105 restricted to use of that certificate format. Rather, it is 106 intended that this framework be adaptable to other certificate 107 formats that may come into use. 109 The scope does not extend to defining security policies generally 110 (such as organization security policy, system security policy, or 111 data labeling policy) beyond the policy elements that are 112 considered of particular relevance to certificate policies or 113 CPSs. 115 This document does not define a specific certificate policy or 116 CPS. 118 It is assumed that the reader is familiar with the general 119 concepts of digital signatures, certificates, and public-key 120 infrastructure, as used in X.509 and the ABA Guidelines. 122 2. DEFINITIONS 124 This document makes use of the following defined terms: 126 Activation data - Data values, other than keys, that are required 127 to operate cryptographic modules and that need to be protected 128 (e.g., a PIN, a passphrase, or a manually-held key share). 130 CA-certificate - A certificate for one CA's public key issued by 131 another CA. 133 Certificate policy - A named set of rules that indicates the 134 applicability of a certificate to a particular community and/or 135 class of application with common security requirements. For 136 example, a particular certificate policy might indicate 137 applicability of a type of certificate to the authentication of 138 electronic data interchange transactions for the trading of goods 139 within a given price range. 141 Certification path - An ordered sequence of certificates which, 142 together with the public key of the initial object in the path, 143 can be processed to obtain that of the final object in the path. 145 Certification Practice Statement (CPS) - A statement of the 146 practices which a certification authority employs in issuing 147 certificates. 149 Issuing certification authority (issuing CA) - In the context of a 150 particular certificate, the issuing CA is the CA that issued the 151 certificate (see also Subject certification authority). 153 Policy qualifier - Policy-dependent information that accompanies a 154 certificate policy identifier in an X.509 certificate. 156 Registration authority (RA) - An entity that is responsible for 157 identification and authentication of certificate subjects, but 158 that does not sign or issue certificates (i.e., an RA is delegated 159 certain tasks on behalf of a CA). [Note: The term Local 160 Registration Authority (LRA) is used elsewhere for the same 161 concept.] 163 Relying party - A recipient of a certificate who acts in reliance 164 on that certificate and/or digital signatures verified using that 165 certificate. In this document, the terms "certificate user" and 166 "relying party" are used interchangeably. 168 Set of provisions - A collection of practice and/or policy 169 statements, spanning a range of standard topics, for use in 170 expressing a certificate policy definition or CPS employing the 171 approach described in this framework. 173 Subject certification authority (subject CA) - In the context of a 174 particular CA-certificate, the subject CA is the CA whose public 175 key is certified in the certificate (see also Issuing 176 certification authority). 178 3. CONCEPTS 180 This section explains the concepts of certificate policy and CPS, and 181 describes their relationship. Other related concepts are also 182 described. Some of the material covered in this section and in some 183 other sections is specific to certificate policies extensions as 184 defined X.509 version 3. Except for those sections, this framework 185 is intended to be adaptable to other certificate formats that may 186 come into use. 188 3.1 CERTIFICATE POLICY 190 When a certification authority issues a certificate, it is 191 providing a statement to a certificate user (i.e., a relying 192 party) that a particular public key is bound to a particular 193 entity (the certificate subject). However, the extent to which 194 the certificate user should rely on that statement by the CA needs 195 to be assessed by the certificate user. Different certificates 196 are issued following different practices and procedures, and may 197 be suitable for different applications and/or purposes. 199 The X.509 standard defines a certificate policy as "a named set of 200 rules that indicates the applicability of a certificate to a 201 particular community and/or class of application with common 202 security requirements"[ISO1]. An X.509 Version 3 certificate may 203 contain an indication of certificate policy, which may be used by 204 a certificate user to decide whether or not to trust a certificate 205 for a particular purpose. 207 A certificate policy, which needs to be recognized by both the 208 issuer and user of a certificate, is represented in a certificate 209 by a unique, registered Object Identifier. The registration 210 process follows the procedures specified in ISO/IEC and ITU 211 standards. The party that registers the Object Identifier also 212 publishes a textual specification of the certificate policy, for 213 examination by certificate users. Any one certificate will 214 typically declare a single certificate policy or, possibly, be 215 issued consistent with a small number of different policies. 217 Certificate policies also constitute a basis for accreditation of 218 CAs. Each CA is accredited against one or more certificate 219 policies which it is recognized as implementing. When one CA 220 issues a CA-certificate for another CA, the issuing CA must assess 221 the set of certificate policies for which it trusts the subject CA 222 (such assessment may be based upon accreditation with respect to 223 the certificate policies involved). The assessed set of 224 certificate policies is then indicated by the issuing CA in the 225 CA-certificate. The X.509 certification path processing logic 226 employs these certificate policy indications in its well-defined 227 trust model. 229 3.2 CERTIFICATE POLICY EXAMPLES 231 For example purposes, suppose that IATA undertakes to define some 232 certificate policies for use throughout the airline industry, in a 233 public-key infrastructure operated by IATA in combination with 234 public-key infrastructures operated by individual airlines. Two 235 certificate policies are defined - the IATA General-Purpose 236 policy, and the IATA Commercial-Grade policy. 238 The IATA General-Purpose policy is intended for use by industry 239 personnel for protecting routine information (e.g., casual 240 electronic mail) and for authenticating connections from World 241 Wide Web browsers to servers for general information retrieval 242 purposes. The key pairs may be generated, stored, and managed 243 using low-cost, software-based systems, such as commercial 244 browsers. Under this policy, a certificate may be automatically 245 issued to anybody listed as an employee in the corporate directory 246 of IATA or any member airline who submits a signed certificate 247 request form to a network administrator in his or her 248 organization. 250 The IATA Commercial-Grade policy is used to protect financial 251 transactions or binding contractual exchanges between airlines. 252 Under this policy, IATA requires that certified key pairs be 253 generated and stored in approved cryptographic hardware tokens. 254 Certificates and tokens are provided to airline employees with 255 disbursement authority. These authorized individuals are required 256 to present themselves to the corporate security office, show a 257 valid identification badge, and sign an undertaking to protect the 258 token and use it only for authorized purposes, before a token and 259 a certificate are issued. 261 3.3 X.509 CERTIFICATE FIELDS 263 The following extension fields in an X.509 certificate are used to 264 support certificate policies: 266 * Certificate Policies extension; 267 * Policy Mappings extension; and 268 * Policy Constraints extension. 270 3.3.1 Certificate Policies Extension 272 The Certificate Policies extension has two variants - one with 273 the field flagged non-critical and one with the field flagged 274 critical. The purpose of the field is different in the two 275 cases. 277 A non-critical Certificate Policies field lists certificate 278 policies that the certification authority declares are 279 applicable. However, use of the certificate is not restricted 280 to the purposes indicated by the applicable policies. Using 281 the example of the IATA General- Purpose and Commercial-Grade 282 policies defined in Section 3.2, the certificates issued to 283 regular airline employees will contain the object identifier 284 for certificate policy for the General-Purpose policy. The 285 certificates issued to the employees with disbursement 286 authority will contain the object identifiers for both the 287 General-Purpose policy and the Commercial-Grade policy. The 288 Certificate Policies field may also optionally convey qualifier 289 values for each identified policy; use of qualifiers is 290 discussed in Section 3.4. 292 The non-critical Certificate Policies field is designed to be 293 used by applications as follows. Each application is pre- 294 configured to know what policy it requires. Using the example 295 in Section 3.2, electronic mail applications and Web servers 296 will be configured to require the General-Purpose policy. 297 However, an airline's financial applications will be configured 298 to require the Commercial-Grade policy for validating financial 299 transactions over a certain dollar value. 301 When processing a certification path, a certificate policy that 302 is acceptable to the certificate-using application must be 303 present in every certificate in the path, i.e., in CA- 304 certificates as well as end entity certificates. 306 If the Certificate Policies field is flagged critical, it 307 serves the same purpose as described above but also has an 308 additional role. It indicates that the use of the certificate 309 is restricted to one of the identified policies, i.e., the 310 certification authority is declaring that the certificate must 311 only be used in accordance with the provisions of one of the 312 listed certificate policies. This field is intended to protect 313 the certification authority against damage claims by a relying 314 party who has used the certificate for an inappropriate purpose 315 or in an inappropriate manner, as stipulated in the applicable 316 certificate policy definition. 318 For example, the Internal Revenue Service might issue 319 certificates to taxpayers for the purpose of protecting tax 320 filings. The Internal Revenue Service understands and can 321 accommodate the risks of accidentally issuing a bad 322 certificate, e.g., to a wrongly- authenticated person. 323 However, suppose someone used an Internal Revenue Service tax- 324 filing certificate as the basis for encrypting multi-million- 325 dollar-value proprietary secrets which subsequently fell into 326 the wrong hands because of an error in issuing the Internal 327 Revenue Service certificate. The Internal Revenue Service may 328 want to protect itself against claims for damages in such 329 circumstances. The critical-flagged Certificate Policies 330 extension is intended to mitigate the risk to the certificate 331 issuer in such situations. 333 3.3.2 Policy Mappings Extension 335 The Policy Mappings extension may only be used in CA- 336 certificates. This field allows a certification authority to 337 indicate that certain policies in its own domain can be 338 considered equivalent to certain other policies in the subject 339 certification authority's domain. 341 For example, suppose the ACE Corporation establishes an 342 agreement with the ABC Corporation to cross-certify each 343 others' public-key infrastructures for the purposes of mutually 344 protecting electronic data interchange (EDI). Further, suppose 345 that both companies have pre-existing financial transaction 346 protection policies called ace-e- commerce and abc-e-commerce, 347 respectively. One can see that simply generating cross 348 certificates between the two domains will not provide the 349 necessary interoperability, as the two companies' applications 350 are configured with and employee certificates are populated 351 with their respective certificate policies. One possible 352 solution is to reconfigure all of the financial applications to 353 require either policy and to reissue all the certificates with 354 both policies. Another solution, which may be easier to 355 administer, uses the Policy Mapping field. If this field is 356 included in a cross-certificate for the ABC Corporation 357 certification authority issued by the ACE Corporation 358 certification authority, it can provide a statement that the 359 ABC's financial transaction protection policy (i.e., abc-e- 360 commerce) can be considered equivalent to that of the ACE 361 Corporation (i.e., ace-e-commerce). 363 3.3.3 Policy Constraints Extension 365 The Policy Constraints extension supports two optional 366 features. The first is the ability for a certification 367 authority to require that explicit certificate policy 368 indications be present in all subsequent certificates in a 369 certification path. Certificates at the start of a 370 certification path may be considered by a certificate user to 371 be part of a trusted domain, i.e., certification authorities 372 are trusted for all purposes so no particular certificate 373 policy is needed in the Certificate Policies extension. Such 374 certificates need not contain explicit indications of 375 certificate policy. However, when a certification authority in 376 the trusted domain certifies outside the domain, it can 377 activate the requirement for explicit certificate policy in 378 subsequent certificates in the certification path. 380 The other optional feature in the Policy Constraints field is 381 the ability for a certification authority to disable policy 382 mapping by subsequent certification authorities in a 383 certification path. It may be prudent to disable policy 384 mapping when certifying outside the domain. This can assist in 385 controlling risks due to transitive trust, e.g., a domain A 386 trusts domain B, domain B trusts domain C, but domain A does 387 not want to be forced to trust domain C. 389 3.4 POLICY QUALIFIERS 391 The Certificate Policies extension field has a provision for 392 conveying, along with each certificate policy identifier, 393 additional policy-dependent information in a qualifier field. The 394 X.509 standard does not mandate the purpose for which this field 395 is to be used, nor does it prescribe the syntax for this field. 396 Policy qualifier types can be registered by any organization. 398 The following policy qualifier types are defined in PKIX Part I 399 [PKI1]: 401 (a) The CPS Pointer qualifier contains a pointer to a 402 Certification Practice Statement (CPS) published by the CA. 403 The pointer is in the form of a uniform resource identifier 404 (URI). 406 (b) The User Notice qualifier contains a text string that is to 407 be displayed to a certificate user (including subscribers and 408 relying parties) prior to the use of the certificate. The text 409 string may be an IA5String or a BMPString - a subset of the ISO 410 100646-1 multiple octet coded character set. A CA may invoke a 411 procedure that requires that the certficate user acknowledge 412 that the applicable terms and conditions have been disclosed or 413 accepted. 415 Policy qualifiers can be used to support the definition of 416 generic, or parameterized, certificate policy definitions. 417 Provided the base certificate policy definition so provides, 418 policy qualifier types can be defined to convey, on a per- 419 certificate basis, additional specific policy details that fill in 420 the generic definition. 422 3.5 CERTIFICATION PRACTICE STATEMENT 424 The term certification practice statement (CPS) is defined by the 425 ABA Guidelines as: "A statement of the practices which a 426 certification authority employs in issuing certificates." [ABA1] 427 In the 1995 draft of the ABA guidelines, the ABA expands this 428 definition with the following comments: 430 A certification practice statement may take the form of a 431 declaration by the certification authority of the details of 432 its trustworthy system and the practices it employs in its 433 operations and in support of issuance of a certificate, or it 434 may be a statute or regulation applicable to the certification 435 authority and covering similar subject matter. It may also be 436 part of the contract between the certification authority and 437 the subscriber. A certification practice statement may also be 438 comprised of multiple documents, a combination of public law, 439 private contract, and/or declaration. 441 Certain forms for legally implementing certification practice 442 statements lend themselves to particular relationships. For 443 example, when the legal relationship between a certification 444 authority and subscriber is consensual, a contract would 445 ordinarily be the means of giving effect to a certification 446 practice statement. The certification authority's duties to a 447 relying person are generally based on the certification 448 authority's representations, which may include a certification 449 practice statement. 451 Whether a certification practice statement is binding on a 452 relying person depends on whether the relying person has 453 knowledge or notice of the certification practice statement. A 454 relying person has knowledge or at least notice of the contents 455 of the certificate used by the relying person to verify a 456 digital signature, including documents incorporated into the 457 certificate by reference. It is therefore advisable to 458 incorporate a certification practice statement into a 459 certificate by reference. 461 As much as possible, a certification practice statement should 462 indicate any of the widely recognized standards to which the 463 certification authority's practices conform. Reference to 464 widely recognized standards may indicate concisely the 465 suitability of the certification authority's practices for 466 another person's purposes, as well as the potential 467 technological compatibility of the certificates issued by the 468 certification authority with repositories and other systems. 470 3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 471 PRACTICE STATEMENT 473 The concepts of certificate policy and CPS come from different 474 sources and were developed for different reasons. However, their 475 interrelationship is important. 477 A certification practice statement is a detailed statement by a 478 certification authority as to its practices, that potentially 479 needs to be understood and consulted by subscribers and 480 certificate users (relying parties). Although the level of detail 481 may vary among CPSs, they will generally be more detailed than 482 certificate policy definitions. Indeed, CPSs may be quite 483 comprehensive, robust documents providing a description of the 484 precise service offerings, detailed procedures of the life- cycle 485 management of certificates, and more - a level of detail which 486 weds the CPS to a particular (proprietary) implementation of a 487 service offering. 489 Although such detail may be indispensable to adequately disclose, 490 and to make a full assessment of trustworthiness in the absence of 491 accreditation or other recognized quality metrics, a detailed CPS 492 does not form a suitable basis for interoperability between CAs 493 operated by different organizations. Rather, certificate policies 494 best serve as the vehicle on which to base common interoperability 495 standards and common assurance criteria on an industry-wide (or 496 possibly more global) basis. A CA with a single CPS may support 497 multiple certificate policies (used for different application 498 purposes and/or by different certificate user communities). Also, 499 multiple different CAs, with non-identical certification practice 500 statements, may support the same certificate policy. 502 For example, the Federal Government might define a government-wide 503 certificate policy for handling confidential human resources 504 information. The certificate policy definition will be a broad 505 statement of the general characteristics of that certificate 506 policy, and an indication of the types of applications for which 507 it is suitable for use. Different departments or agencies that 508 operate certification authorities with different certification 509 practice statements might support this certificate policy. At the 510 same time, such certification authorities may support other 511 certificate policies. 513 The main difference between certificate policy and CPS can 514 therefore be summarized as follows: 516 (a) Most organizations that operate public or inter- 517 organizational certification authorities will document their 518 own practices in CPSs or similar statements. The CPS is one of 519 the organization's means of protecting itself and positioning 520 its business relationships with subscribers and other entities. 522 (b) There is strong incentive, on the other hand, for a 523 certificate policy to apply more broadly than to just a single 524 organization. If a particular certificate policy is widely 525 recognized and imitated, it has great potential as the basis of 526 automated certificate acceptance in many systems, including 527 unmanned systems and systems that are manned by people not 528 independently empowered to determine the acceptability of 529 different presented certificates. 531 In addition to populating the certificate policies field with the 532 certificate policy identifier, a certification authority may 533 include, in certificates it issues, a reference to its 534 certification practice statement. A standard way to do this, 535 using a certificate policy qualifier, is described in Section 3.4. 537 3.7 SET OF PROVISIONS 539 A set of provisions is a collection of practice and/or policy 540 statements, spanning a range of standard topics, for use in 541 expressing a certificate policy definition or CPS employing the 542 approach described in this framework. 544 A certificate policy can be expressed as a single set of 545 provisions. 547 A CPS can be expressed as a single set of provisions with each 548 component addressing the requirements of one or more certificate 549 policies, or, alternatively, as an organized collection of sets of 550 provisions. For example, a CPS could be expressed as a 551 combination of the following: 553 (a) a list of certificate policies supported by the CPS; 555 (b) for each certificate policy in (a), a set of provisions 556 which contains statements that refine that certificate policy 557 by filling in details not stipulated in that policy or 558 expressly left to the discretion of the CPS by that certificate 559 policy; such statements serve to state how this particular CPS 560 implements the requirements of the particular certificate 561 policy; 563 (c) a set of provisions that contains statements regarding the 564 certification practices on the CA, regardless of certificate 565 policy. 567 The statements provided in (b) and (c) may augment or refine the 568 stipulations of the applicable certificate policy definition, but 569 must not conflict with any of the stipulations of such certificate 570 policy definition. 572 This framework outlines the contents of a set of provisions, in 573 terms of eight primary components, as follows: 575 * Introduction; 577 * General Provisions; 579 * Identification and Authentication; 581 * Operational Requirements; 583 * Physical, Procedural, and Personnel Security Controls; 585 * Technical Security Controls; 587 * Certificate and CRL Profile; and 589 * Specification Administration. 591 Components can be further divided into subcomponents, and a 592 subcomponent may comprise multiple elements. Section 4 provides a 593 more detailed description of the contents of the above components, 594 and their subcomponents. 596 4. CONTENTS OF A SET OF PROVISIONS 598 This section expands upon the contents of a set of provisions, as 599 introduced in Section 3.7. The topics identified in this section 600 are, consequently, candidate topics for inclusion in a certificate 601 policy definition or CPS. 603 While many topics are identified, it is not necessary for a 604 certificate policy or a CPS to include a concrete statement for every 605 such topic. Rather, a particular certificate policy or CPS may 606 state "no stipulation" for a component, subcomponent, or element on 607 which the particular certificate policy or CPS imposes no 608 requirements. In this sense, the list of topics can be considered a 609 checklist of topics for consideration by the certificate policy or 610 CPS writer. It is recommended that each and every component and 611 subcomponent be included in a certificate policy or CPS, even if 612 there is "no stipulation"; this will indicate to the reader that a 613 conscious decision was made to include or exclude that topic. This 614 protects against inadvertent omission of a topic, while facilitating 615 comparison of different certificate policies or CPSs, e.g., when 616 making policy mapping decisions. 618 In a certificate policy definition, it is possible to leave certain 619 components, subcomponents, and/or elements unspecified, and to 620 stipulate that the required information will be indicated in a policy 621 qualifier. Such certificate policy definitions can be considered 622 parameterized definitions. The set of provisions should reference or 623 define the required policy qualifier types and should specify any 624 applicable default values. 626 4.1 INTRODUCTION 628 This component identifies and introduces the set of provisions, 629 and indicates the types of entities and applications for which the 630 specification is targeted. 632 This component has the following subcomponents: 633 * Overview; 635 * Identification; 637 * Community and Applicability; and 639 * Contact Details. 641 4.1.1 Overview 643 This subcomponent provides a general introduction to the 644 specification. 646 4.1.2 Identification 648 This subcomponent provides any applicable names or other 649 identifiers, including ASN.1 object identifiers, for the set of 650 provisions. 652 4.1.3 Community and Applicability 654 This subcomponent describes the types of entities that issue 655 certificates or that are certified as subject CAs (2, 3), the 656 types of entities that perform RA functions (4), and the types 657 of entities that are certified as subject end entities or 658 subscribers. (5, 6) 660 This subcomponent also contains: 662 * A list of applications for which the issued certificates 663 are suitable. (Examples of application in this case are: 664 electronic mail, retail transactions, contracts, travel 665 order, etc.) 667 * A list of applications for which use of the issued 668 certificates is restricted. (This list implicitly prohibits 669 all other uses for the certificates.) 670 * A list of applications for which use of the issued 671 certificates is prohibited. 673 4.1.4 Contact Details 675 This subcomponent includes the name and mailing address of the 676 authority that is responsible for the registration, 677 maintenance, and interpretation of this certificate policy or 678 CPS. It also includes the name, electronic mail address, 679 telephone number, and fax number of a contact person. 681 4.2 GENERAL PROVISIONS 683 This component specifies any applicable presumptions on a range of 684 legal and general practices topics. 686 This component contains the following subcomponents: 688 * Obligations; 690 * Liability; 692 * Financial Responsibility; 694 * Interpretation and Enforcement; 696 * Fees; 698 * Publication and Repositories; 700 * Compliance Audit; 702 * Confidentiality; and 704 * Intellectual Property Rights. 706 Each subcomponent may need to separately state provisions applying 707 to the entity types: CA, repository, RA, subscriber, and relying 708 party. (Specific provisions regarding subscribers and relying 709 parties are only applicable in the Liability and Obligations 710 subcomponents.) 711 4.2.1 Obligations 713 This subcomponent contains, for each entity type, any 714 applicable provisions regarding the entity's obligations to 715 other entities. Such provisions may include: 717 * CA and/or RA obligations: 718 * Notification of issuance of a certificate to the 719 subscriber who is the subject of the certificate being 720 issued; 721 * Notification of issuance of a certificate to others 722 than the subject of the certificate; 723 * Notification of revocation or suspension of a 724 certificate to the subscriber whose certificate is being 725 revoked or suspended; and 726 * Notification of revocation or suspension of a 727 certificate to others than the subject whose certificate 728 is being revoked or suspended. 730 * Subscriber obligations: 732 * Accuracy of representations in certificate application; 733 * Protection of the entity's private key; 734 * Restrictions on private key and certificate use; and 735 * Notification upon private key compromise. 737 * Relying party obligations: 739 * Purposes for which certificate is used; 740 * Digital signature verification responsibilities; 741 * Revocation and suspension checking responsibilities; 742 and 743 * Acknowledgment of applicable liability caps and 744 warranties. 746 * Repository obligations 748 * Timely publication of certificates and revocation 749 information 751 4.2.2 Liability 753 This subcomponent contains, for each entity type, any 754 applicable provisions regarding apportionment of liability, 755 such as: 757 * Warranties and limitations on warranties; 759 * Kinds of damages covered (e.g., indirect, special, 760 consequential, incidental, punitive, liquidated damages, 761 negligence and fraud) and disclaimers; 763 * Loss limitations (caps) per certificate or per 764 transaction; and 766 * Other exclusions (e.g., Acts of God, other party 767 responsibilities). 769 4.2.3 Financial Responsibility 771 This subcomponent contains, for CAs, repository, and RAs, any 772 applicable provisions regarding financial responsibilities, 773 such as: 775 * Indemnification of CA and/or RA by relying parties; 777 * Fiduciary relationships (or lack thereof) between the 778 various entities; and 780 * Administrative processes (e.g., accounting, audit). 782 4.2.4 Interpretation and Enforcement 784 This subcomponent contains any applicable provisions regarding 785 interpretation and enforcement of the certificate policy or 786 CPS, addressing such topics as: 788 * Governing law; 790 * Severability of provisions, survival, merger, and notice; 791 and 793 * Dispute resolution procedures. 795 4.2.5 Fees 797 This subcomponent contains any applicable provisions regarding 798 fees charged by CAs, repositories, or RAs, such as: 800 * Certificate issuance or renewal fees; 802 * Certificate access fee; 804 * Revocation or status information access fee; 806 * Fees for other services such as policy information; and 808 * Refund policy. 810 4.2.6 Publication and Repositories 812 This subcomponent contains any applicable provisions regarding: 814 * A CA's obligations to publish information regarding its 815 practices, its certificates, and the current status of such 816 certificates; 818 * Frequency of publication; 820 * Access control on published information objects including 821 certificate policy definitions, CPS, certificates, 822 certificate status, and CRLs; and 824 * Requirements pertaining to the use of repositories 825 operated by CAs or by other independent parties. 827 4.2.7 Compliance Audit 829 This subcomponent addresses the following: 831 * Frequency of compliance audit for each entity; 833 * Identity/qualifictions of the auditor; 835 * Auditor's relationship to the entity being audited; (30) 837 * List of topics covered under the compliance audit; (31) 839 * Actions taken as a result of a deficiency found during 840 compliance audit; (32) 842 * Compliance audit results: who they are shared with (e.g., 843 subject CA, RA, and/or end entities), who provides them 844 (e.g., entity being audited or auditor), how they are 845 communicated. 847 4.2.8 Confidentiality Policy 849 This subcomponent addresses the following: 851 * Types of information that must be kept confidential by CA 852 or RA; 854 * Types of information that are not considered confidential; 856 * Who is entitled to be informed of reasons for revocation 857 and suspension of certificates; 859 * Policy on release of information to law enforcement 860 officials; 862 * Information that can be revealed as part of civil 863 discovery; 865 * Conditions upon which CA or RA may disclose upon owner's 866 request; and 868 * Any other circumstances under which confidential 869 information may be disclosed. 871 4.2.9 Intellectual Property Rights 873 This subcomponent addresses ownership rights of certificates, 874 practice/policy specifications, names, and keys. 876 4.3 IDENTIFICATION AND AUTHENTICATION 878 This component describes the procedures used to authenticate a 879 certificate applicant to a CA or RA prior to certificate issuance. 880 It also describes how parties requesting rekey or revocation are 881 authenticated. This component also addresses naming practices, 882 including name ownership recognition and name dispute resolution. 884 This component has the following subcomponents: 886 * Initial Registration; 888 * Routine Rekey; 890 * Rekey After Revocation; and 891 * Revocation Request. 893 4.3.1 Initial Registration 895 This subcomponent includes the following elements regarding 896 identification and authentication procedures during entity 897 registration or certificate issuance: 899 * Types of names assigned to the subject (7); 901 * Whether names have to be meaningful or not (8); 903 * Rules for interpreting various name forms; 905 * Whether names have to be unique; 907 * How name claim disputes are resolved; 909 * Recognition, authentication, and role of trademarks; 911 * If and how the subject must prove possession of the 912 companion private key for the public key being registered 913 (9); 915 * Authentication requirements for organizational identity of 916 subject (CA, RA, or end entity) (10); 918 * Authentication requirements for a person acting on behalf 919 of a subject (CA, RA, or end entity) (11), including: 921 * Number of pieces of identification required; 922 * How a CA or RA validates the pieces of identification 923 provided; 924 * If the individual must present personally to the 925 authenticating CA or RA; 926 * How an individual as an organizational person is 927 authenticated (12). 929 4.3.2 Routine Rekey 931 This subcomponent describes the identification and 932 authentication procedures for routine rekey for each subject 933 type (CA, RA, and end entity). (13) 935 4.3.3 Rekey After Revocation -- No Key Compromise 937 This subcomponent describes the identification and 938 authentication procedures for rekey for each subject type (CA, 939 RA, and end entity) after the subject certificate has been 940 revoked. (14) 942 4.3.4 Revocation Request 944 This subcomponent describes the identification and 945 authentication procedures for a revocation request by each 946 subject type (CA, RA, and end entity). (16) 948 4.4 OPERATIONAL REQUIREMENTS 950 This component is used to specify requirements imposed upon 951 issuing CA, subject CAs, RAs, or end entities with respect to 952 various operational activities. 954 This component consists of the following subcomponents: 956 * Certificate Application; 958 * Certificate Issuance; 960 * Certificate Acceptance; 962 * Certificate Suspension and Revocation; 964 * Security Audit Procedures; 966 * Records Archival; 968 * Key Changeover; 970 * Compromise and Disaster Recovery; and 972 * CA Termination. 974 Within each subcomponent, separate consideration may need to be 975 given to issuing CA, repository, subject CAs, RAs, and end 976 entities. 978 4.4.1 Certificate Application 980 This subcomponent is used to state requirements regarding 981 subject enrollment and request for certificate issuance. 983 4.4.2 Certificate Issuance 985 This subcomponent is used to state requirements regarding 986 issuance of a certificate and notification to the applicant of 987 such issuance. 989 4.4.3 Certificate Acceptance 991 This subcomponent is used to state requirements regarding 992 acceptance of an issued certificate and for consequent 993 publication of certificates. 995 4.4.4 Certificate Suspension and Revocation 997 This subcomponent addresses the following: 999 * Circumstances under which a certificate may be revoked; 1001 * Who can request the revocation of the entity certificate; 1003 * Procedures used for certificate revocation request; 1005 * Revocation request grace period available to the subject; 1007 * Circumstances under which a certificate may be suspended; 1009 * Who can request the suspension of a certificate; 1011 * Procedures to request certificate suspension; 1013 * How long the suspension may last; 1015 * If a CRL mechanism is used, the issuance frequency; 1017 * Requirements on relying parties to check CRLs; 1019 * On-line revocation/status checking availability; 1021 * Requirements on relying parties to perform on-line 1022 revocation/status checks; 1024 * Other forms of revocation advertisements available; and 1025 * Requirements on relying parties to check other forms of 1026 revocation advertisements. 1028 * Any variations on the above stipulations when the 1029 suspension or revocation is the result of private key 1030 compromise (as opposed to other reasons for suspension or 1031 revocation). 1033 4.4.5 Security Audit Procedures 1035 This subcomponent is used to describe event logging and audit 1036 systems, implemented for the purpose of maintaining a secure 1037 environment. Elements include the following: 1039 * Types of events recorded; (28) 1041 * Frequency with which audit logs are processed or audited; 1043 * Period for which audit logs are kept; 1045 * Protection of audit logs: 1047 - Who can view audit logs; 1048 - Protection against modification of audit log; and 1049 - Protection against deletion of audit log. 1051 * Audit log back up procedures; 1053 * Whether the audit log accumulation system is internal or 1054 external to the entity; 1056 * Whether the subject who caused an audit event to occur is 1057 notified of the audit action; and 1059 * Vulnerability assessments. 1060 4.4.6 Records Archival 1062 This subcomponent is used to describe general records archival 1063 (or records retention) policies, including the following: 1065 * Types of events recorded; (29) 1067 * Retention period for archive; 1069 * Protection of archive: 1071 - Who can view the archive; 1072 - Protection against modification of archive; and 1073 - Protection against deletion of archive. 1075 * Archive backup procedures; 1077 * Requirements for time-stamping of records; 1079 * Whether the archive collection system is internal or 1080 external; and 1082 * Procedures to obtain and verify archive information. 1084 4.4.7 Key Changeover 1086 This subcomponent describes the procedures to provide a new 1087 public key to a CA's users. 1089 4.4.8 Compromise and Disaster Recovery 1091 This subcomponent describes requirements relating to 1092 notification and recovery procedures in the event of compromise 1093 or disaster. Each of the following circumstances may need to 1094 be addressed separately: 1096 * The recovery procedures used if computing resources, 1097 software, and/or data are corrupted or suspected to be 1098 corrupted. These procedures describe how a secure 1099 environment is reestablished, which certificates are 1100 revoked, whether the entity key is revoked, how the new 1101 entity public key is provided to the users, and how the 1102 subjects are recertified. 1104 * The recovery procedures used if the entity public key is 1105 revoked. These procedures describe how a secure environment 1106 is reestablished, how the new entity public key is provided 1107 to the users, and how the subjects are recertified. 1109 * The recovery procedures used if the entity key is 1110 compromised. These procedures describe how a secure 1111 environment is reestablished, how the new entity public key 1112 is provided to the users, and how the subjects are 1113 recertified. 1115 * The CA's procedures for securing its facility during the 1116 period of time following a natural or other disaster and 1117 before a secure environment is reestablished either at the 1118 original site or a remote hot-site. For example, procedures 1119 to protect against theft of sensitive materials from an 1120 earthquake-damaged site. 1122 4.4.9 CA Termination 1124 This subcomponent describes requirements relating to procedures 1125 for termination and for termination notification of a CA or RA, 1126 including the identity of the custodian of CA and RA archival 1127 records. 1129 4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS 1131 This component describes non-technical security controls (that is, 1132 physical, procedural, and personnel controls) used by the issuing 1133 CA to perform securely the functions of key generation, subject 1134 authentication, certificate issuance, certificate revocation, 1135 audit, and archival. 1137 This component can also be used to define non-technical security 1138 controls on repository, subject CAs, RAs, and end entities. The 1139 non technical security controls for the subject CAs, RAs, and end 1140 entities could be the same, similar, or very different. 1142 These non-technical security controls are critical to trusting the 1143 certificates since lack of security may compromise CA operations 1144 resulting, for example, in the creation of certificates or CRLs 1145 with erroneous information or the compromise of the CA private 1146 key. 1148 This component consists of three subcomponents: 1150 * Physical Security Controls; 1152 * Procedural Controls; and 1154 * Personnel Security Controls. 1156 Within each subcomponent, separate consideration will, in general, 1157 need to be given to each entity type, that is, issuing CA, 1158 repository, subject CAs, RAs, and end entities. 1160 4.5.1 Physical Security Controls 1162 In this subcomponent, the physical controls on the facility 1163 housing the entity systems are described.(21) Topics addressed 1164 may include: 1166 * Site location and construction; 1168 * Physical access; 1169 * Power and air conditioning; 1171 * Water exposures; 1173 * Fire prevention and protection; 1175 * Media storage; 1177 * Waste disposal; and 1179 * Off-site backup. 1181 4.5.2 Procedural Controls 1183 In this subcomponent, requirements for recognizing trusted 1184 roles are described, together with the responsibilities for 1185 each role.(22) 1187 For each task identified for each role, it should also be 1188 stated how many individuals are required to perform the task (n 1189 out m rule). Identification and authentication requirements 1190 for each role may also be defined. 1192 4.5.3 Personnel Security Controls 1194 This subcomponent addresses the following: 1196 * Background checks and clearance procedures required for 1197 the personnel filling the trusted roles; (23) 1199 * Background checks and clearance procedures requirements 1200 for other personnel, including janitorial staff; (24) 1202 * Training requirements and training procedures for each 1203 role; 1205 * Any retraining period and retraining procedures for each 1206 role; 1208 * Frequency and sequence for job rotation among various 1209 roles; 1211 * Sanctions against personnel for unauthorized actions, 1212 unauthorized use of authority, and unauthorized use of 1213 entity systems; (25) 1215 * Controls on contracting personnel, including: 1217 - Bonding requirements on contract personnel; 1218 - Contractual requirements including indemnification for 1219 damages due to the actions of the contractor personnel; 1220 - Audit and monitoring of contractor personnel; and 1221 - Other controls on contracting personnel. 1223 * Documentation to be supplied to personnel. 1225 4.6 TECHNICAL SECURITY CONTROLS 1227 This component is used to define the security measures taken by 1228 the issuing CA to protect its cryptographic keys and activation 1229 data (e.g., PINs, passwords, or manually-held key shares). This 1230 component may also be used to impose constraints on repositories, 1231 subject CAs and end entities to protect their cryptographic keys 1232 and critical security parameters. Secure key management is 1233 critical to ensure that all secret and private keys and activation 1234 data are protected and used only by authorized personnel. 1236 This component also describes other technical security controls 1237 used by the issuing CA to perform securely the functions of key 1238 generation, user authentication, certificate registration, 1239 certificate revocation, audit, and archival. Technical controls 1240 include life-cycle security controls (including software 1241 development environment security, trusted software development 1242 methodology) and operational security controls. 1244 This component can also be used to define other technical security 1245 controls on repositories, subject CAs, RAs, and end entities. 1247 This component has the following subcomponents: 1249 * Key Pair Generation and Installation; 1251 * Private Key Protection; 1253 * Other Aspects of Key Pair Management; 1255 * Activation Data; 1257 * Computer Security Controls; 1259 * Life-Cycle Security Controls; 1261 * Network Security Controls; and 1263 * Cryptographic Module Engineering Controls. 1265 4.6.1 Key Pair Generation and Installation 1267 Key pair generation and installation need to be considered for 1268 the issuing CA, repositories, subject CAs, RAs, and subject end 1269 entities. For each of these types of entities, the following 1270 questions potentially need to be answered: 1272 1. Who generates the entity public, private key pair? 1274 2. How is the private key provided securely to the entity? 1276 3. How is the entity's public key provided securely to the 1277 certificate issuer? 1279 4. If the entity is a CA (issuing or subject) how is the 1280 entity's public key provided securely to the users? 1282 5. What are the key sizes? 1284 6. Who generates the public key parameters? 1286 7. Is the quality of the parameters checked during key 1287 generation? 1289 8. Is the key generation performed in hardware or software? 1291 9. For what purposes may the key be used, or for what 1292 purposes should usage of the key be restricted (for X.509 1293 certificates, these purposes should map to the key usage 1294 flags in the Version 3, X.509 certificates)? 1296 4.6.2 Private Key Protection 1298 Requirements for private key protection need to be considered 1299 for the issuing CA, repositories, subject CAs, RAs, and subject 1300 end entities. For each of these types of entity, the following 1301 questions potentially need to be answered: 1303 1. What standards, if any, are required for the module used 1304 to generate the keys? For example, are the keys certified 1305 by the infrastructure required to be generated using modules 1306 complaint with the US FIPS 140-1? If so, what is the 1307 required FIPS 140-1 level of the module? 1309 2. Is the private key under n out of m multi-person 1310 control?(18) If yes, provide n and m (two person control is 1311 a special case of n out of m, where n = m = 2)? 1312 3. Is the private key escrowed? (19) If so, who is the 1313 escrow agent, what form is the key escrowed in (examples 1314 include plaintext, encrypted, split key), and what are the 1315 security controls on the escrow system? 1317 4. Is the private key backed up? If so, who is the backup 1318 agent, what form is the key backed up in (examples include 1319 plaintext, encrypted, split key), and what are the security 1320 controls on the backup system? 1322 5. Is the private key archived? If so, who is the archival 1323 agent, what form is the key archived in (examples include 1324 plaintext, encrypted, split key), and what are the security 1325 controls on the archival system? 1327 6. Who enters the private key in the cryptographic module? 1328 In what form (i.e., plaintext, encrypted, or split key)? 1329 How is the private key stored in the module (i.e., 1330 plaintext, encrypted, or split key)? 1332 7. Who can activate (use) the private key? What actions 1333 must be performed to activate the private key (e.g., login, 1334 power on, supply PIN, insert token/key, automatic, etc.)? 1335 Once the key is activated, is the key active for an 1336 indefinite period, active for one time, or active for a 1337 defined time period? 1339 8. Who can deactivate the private key and how? Example of 1340 how might include, logout, power off, remove token/key, 1341 automatic, or time expiration. 1343 9. Who can destroy the private key and how? Examples of how 1344 might include token surrender, token destruction, or key 1345 overwrite. 1347 4.6.3 Other Aspects of Key Pair Management 1349 Other aspects of key management need to be considered for the 1350 issuing CA, repositories, subject CAs, RAs, and subject end 1351 entities. For each of these types of entity, the following 1352 questions potentially need to be answered: 1354 1. Is the public key archived? If so, who is the archival 1355 agent and what are the security controls on the archival 1356 system? The archival system should provide integrity 1357 controls other than digital signatures since: the archival 1358 period may be greater than the cryptanalysis period for the 1359 key and the archive requires tamper protection, which is not 1360 provided by digital signatures. 1362 2. What are the usage periods, or active lifetimes, for the 1363 public and the private key respectively? 1365 4.6.4 Activation Data 1367 Activation data refers to data values other than keys that are 1368 required to operate cryptographic modules and that need to be 1369 protected. (20) Protection of activation data potentially 1370 needs to be considered for the issuing CA, subject CAs, RAs, 1371 and end entities. Such consideration potentially needs to 1372 address the entire life-cycle of the activation data from 1373 generation through archival and destruction. For each of the 1374 entity types (issuing CA, repository, subject CA, RA, and end 1375 entity) all of the questions listed in 4.6.1 through 4.6.3 1376 potentially need to be answered with respect to activation data 1377 rather than with respect to keys. 1379 4.6.5 Computer Security Controls 1381 This subcomponent is used to describe computer security 1382 controls such as: use of the trusted computing base concept, 1383 discretionary access control, labels, mandatory access 1384 controls, object reuse, audit, identification and 1385 authentication, trusted path, security testing, and penetration 1386 testing. Product assurance may also be addressed. 1388 A computer security rating for computer systems may be 1389 required. The rating could be based, for example, on the 1390 Trusted System Evaluation Criteria (TCSEC), Canadian Trusted 1391 Products Evaluation Criteria, European Information Technology 1392 Security Evaluation Criteria (ITSEC), or the Common Criteria. 1393 This subcomponent can also address requirements for product 1394 evaluation analysis, testing, profiling, product certification, 1395 and/or product accreditation related activity undertaken. 1397 4.6.6 Life Cycle Security Controls 1399 This subcomponent addresses system development controls and 1400 security management controls. 1402 System development controls include development environment 1403 security, development personnel security, configuration 1404 management security during product maintenance, software 1405 engineering practices, software development methodology, 1406 modularity, layering, use of failsafe design and implementation 1407 techniques (e.g., defensive programming) and development 1408 facility security. 1410 Security management controls include execution of tools and 1411 procedures to ensure that the operational systems and networks 1412 adhere to configured security. These tools and procedures 1413 include checking the integrity of the security software, 1414 firmware, and hardware to ensure their correct operation. 1416 This subcomponent can also address life-cycle security ratings 1417 based, for example, on the Trusted Software Development 1418 Methodology (TSDM) level IV and V, independent life- cycle 1419 security controls audit, and the Software Engineering 1420 Institute's Capability Maturity Model (SEI-CMM). 1422 4.6.7 Network Security Controls 1424 This subcomponent addresses network security related controls, 1425 including firewalls. 1427 4.6.8 Cryptographic Module Engineering Controls (26) 1429 This subcomponent addresses the following aspects of a 1430 cryptographic module: identification of the cryptographic 1431 module boundary, input/output, roles and services, finite state 1432 machine, physical security, software security, operating system 1433 security, algorithm compliance, electromagnetic compatibility, 1434 and self tests. Requirements may be expressed through 1435 reference to a standard such as U.S. FIPS 140-1. (27) 1437 4.7 CERTIFICATE AND CRL PROFILES 1439 This component is used to specify the certificate format and, if 1440 CRLs are used, the CRL format. Assuming use of the X.509 1441 certificate and CRL formats, this includes information on 1442 profiles, versions, and extensions used. 1444 This component has two subcomponents: 1446 * Certificate Profile; and 1448 * CRL Profile. 1450 4.7.1 Certificate Profile 1452 This subcomponent addresses such topics as the following 1453 (potentially by reference to a separate profile definition, 1454 such as the PKIX Part I profile): 1456 * Version number(s) supported; 1458 * Certificate extensions populated and their criticality; 1460 * Cryptographic algorithm object identifiers; 1462 * Name forms used for the CA, RA, and end entity names; 1464 * Name constraints used and the name forms used in the name 1465 constraints; 1467 * Applicable certificate policy Object Identifier(s); 1469 * Usage of the policy constraints extension; 1471 * Policy qualifiers syntax and semantics; and 1473 * Processing semantics for the critical certificate policy 1474 extension. 1476 4.7.2 CRL Profile 1478 This subcomponent addresses such topics as the following 1479 (potentially by reference to a separate profile definition, 1480 such as the PKIX Part I profile): 1482 * Version numbers supported for CRLs; and 1484 * CRL and CRL entry extensions populated and their 1485 criticality. 1487 4.8 SPECIFICATION ADMINISTRATION 1489 This component is used to specify how this particular certificate 1490 policy definition or CPS will be maintained. 1492 It contains the following subcomponents: 1494 * Specification Change Procedures; 1496 * Publication and Notification Procedures; and 1497 * CPS Approval Procedures. 1499 4.8.1 Specification Change Procedures 1501 It will occasionally be necessary to change certificate 1502 policies and Certification Practice Statements. Some of these 1503 changes will not materially reduce the assurance that a 1504 certificate policy or its implementation provides, and will be 1505 judged by the policy administrator as not changing the 1506 acceptability of certificates asserting the policy for the 1507 purposes for which they have been used. Such changes to 1508 certificate policies and Certification Practice Statements need 1509 not require a change in the certificate policy Object 1510 Identifier or the CPS pointer (URL). Other changes to a 1511 specification will change the acceptability of certificates for 1512 specific purposes, and these changes will require changes to 1513 the certificate policy Object Identifier or CPS pointer (URL). 1515 This subcomponent contains the following information: 1517 * A list of specification components, subcomponents, and/or 1518 elements thereof that can be changed without notification 1519 and without changes to the certificate policy Object 1520 Identifier or CPS pointer (URL). 1522 * A list of specification components, subcomponents, and/or 1523 elements thereof that may change following a notification 1524 period without changing the certificate policy Object 1525 Identifier or CPS pointer (URL). The procedures to be used 1526 to notify interested parties (relying parties, certification 1527 authorities, etc.) of the certificate policy or CPS changes 1528 are described. The description of notification procedures 1529 includes the notification mechanism, notification period for 1530 comments, mechanism to receive, review and incorporate the 1531 comments, mechanism for final changes to the policy, and the 1532 period before final changes become effective. 1534 * A list of specification components, subcomponents, and/or 1535 elements, changes to which require a change in certificate 1536 policy Object Identifier or CPS pointer (URL).. 1538 4.8.2 Publication and Notification Procedures 1540 This subcomponent contains the following elements: 1542 * A list of components, subcomponents, and elements thereof 1543 that exist but that are not made publicly available; (33) 1545 * Descriptions of mechanisms used to distribute the 1546 certificate policy definition or CPS, including access 1547 controls on such distribution. 1549 4.8.3 CPS Approval Procedures 1551 In a certificate policy definition, this subcomponent describes 1552 how the compliance of a specific CPS with the certificate 1553 policy can be determined. 1555 5. OUTLINE OF A SET OF PROVISIONS 1557 This section contains a possible outline for a set of provisions, 1558 intended to serve as a checklist or (with some further development) a 1559 standard template for use by certificate policy or CPS writers. Such 1560 a common outline will facilitate: 1562 (a) Comparison of two certificate policies during cross- 1563 certification (for the purpose of equivalency mapping). 1565 (b) Comparison of a CPS with a certificate policy definition to 1566 ensure that the CPS faithfully implements the policy. 1568 (c) Comparison of two CPSs. 1570 1. INTRODUCTION 1572 1.1 Overview 1574 1.2 Identification 1576 1.3 Community and Applicability 1577 1.3.1 Certification authorities 1578 1.3.2 Registration authorities 1579 1.3.3 End entities 1580 1.3.4 Applicability 1582 1.4 Contact Details 1583 1.4.1 Specification administration organization 1584 1.4.2 Contact person 1585 1.4.3 Person determining CPS suitability for the policy 1587 2. GENERAL PROVISIONS 1589 2.1 Obligations 1591 2.1.1 CA obligations 1592 2.1.2 RA obligations 1593 2.1.3 Subscriber obligations 1594 2.1.4 Relying party obligations 1595 2.1.5 Repository obligations 1597 2.2 Liability 1599 2.2.1 CA liability 1600 2.2.2 RA liability 1602 2.3 Financial responsibility 1604 2.3.1 Indemnification by relying parties 1605 2.3.2 Fiduciary relationships 1606 2.3.3 Administrative processes 1608 2.4 Interpretation and Enforcement 1610 2.4.1 Governing law 1611 2.4.2 Severability, survival, merger, notice 1612 2.4.3 Dispute resolution procedures 1614 2.5 Fees 1616 2.5.1 Certificate issuance or renewal fees 1617 2.5.2 Certificate access fees 1618 2.5.3 Revocation or status information access fees 1619 2.5.4 Fees for other services such as policy information 1620 2.5.5 Refund policy 1622 2.6 Publication and Repository 1624 2.6.1 Publication of CA information 1625 2.6.2 Frequency of publication 1626 2.6.3 Access controls 1627 2.6.4 Repositories 1629 2.7 Compliance audit 1631 2.7.1 Frequency of entity compliance audit 1632 2.7.2 Identity/qualifications of auditor 1633 2.7.3 Auditor's relationship to audited party 1634 2.7.4 Topics covered by audit 1635 2.7.5 Actions taken as a result of deficiency 1636 2.7.6 Communication of results 1638 2.8 Confidentiality 1640 2.8.1 Types of information to be kept confidential 1641 2.8.2 Types of information not considered confidential 1642 2.8.3 Disclosure of certificate revocation/suspension information 1643 2.8.4 Release to law enforcement officials 1644 2.8.5 Release as part of civil discovery 1645 2.8.6 Disclosure upon owner's request 1646 2.8.7 Other information release circumstances 1648 2.9 Intellectual Property Rights 1650 3. IDENTIFICATION AND AUTHENTICATION (34) 1652 3.1 Initial Registration 1653 3.1.1 Types of names 1654 3.1.2 Need for names to be meaningful 1655 3.1.3 Rules for interpreting various name forms 1656 3.1.4 Uniqueness of names 1657 3.1.5 Name claim dispute resolution procedure 1658 3.1.6 Recognition, authentication and role of trademarks 1659 3.1.7 Method to prove possession of private key 1660 3.1.8 Authentication of organization identity 1661 3.1.9 Authentication of individual identity 1663 3.2 Routine Rekey 1665 3.3 Rekey after Revocation 1667 3.4 Revocation Request 1669 4. OPERATIONAL REQUIREMENTS (34) 1671 4.1 Certificate Application 1673 4.2 Certificate Issuance 1675 4.3 Certificate Acceptance 1677 4.4 Certificate Suspension and Revocation 1678 4.4.1 Circumstances for revocation 1679 4.4.2 Who can request revocation 1680 4.4.3 Procedure for revocation request 1681 4.4.4 Revocation request grace period 1682 4.4.5 Circumstances for suspension 1683 4.4.6 Who can request suspension 1684 4.4.7 Procedure for suspension request 1685 4.4.8 Limits on suspension period 1686 4.4.9 CRL issuance frequency (if applicable) 1687 4.4.10 CRL checking requirements 1688 4.4.11 On-line revocation/status checking availability 1689 4.4.12 On-line revocation checking requirements 1690 4.4.13 Other forms of revocation advertisements available 1691 4.4.14 Checking requirements for other forms of revocation 1692 advertisements 1693 4.4.15 Special requirements re key compromise 1695 4.5 Security Audit Procedures 1696 4.5.1 Types of event recorded 1697 4.5.2 Frequency of processing log 1698 4.5.3 Retention period for audit log 1699 4.5.4 Protection of audit log 1700 4.5.5 Audit log backup procedures 1701 4.5.6 Audit collection system (internal vs external) 1702 4.5.7 Notification to event-causing subject 1703 4.5.8 Vulnerability assessments 1705 4.6 Records Archival 1707 4.6.1 Types of event recorded 1708 4.6.2 Retention period for archive 1709 4.6.3 Protection of archive 1710 4.6.4 Archive backup procedures 1711 4.6.5 Requirements for time-stamping of records 1712 4.6.6 Archive collection system (internal or external) 1713 4.6.7 Procedures to obtain and verify archive information 1715 4.7 Key changeover 1717 4.8 Compromise and Disaster Recovery 1718 4.8.1 Computing resources, software, and/or data are corrupted 1719 4.8.2 Entity public key is revoked 1720 4.8.3 Entity key is compromised 1721 4.8.4 Secure facility after a natural or other type of disaster 1723 4.9 CA Termination 1725 5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34) 1726 5.1 Physical Controls 1727 5.1.1 Site location and construction 1728 5.1.2 Physical access 1729 5.1.3 Power and air conditioning 1730 5.1.4 Water exposures 1731 5.1.5 Fire prevention and protection 1732 5.1.6 Media storage 1733 5.1.7 Waste disposal 1734 5.1.8 Off-site backup 1736 5.2 Procedural Controls 1737 5.2.1 Trusted roles 1738 5.2.2 Number of persons required per task 1739 5.2.3 Identification and authentication for each role 1741 5.3 Personnel Controls 1742 5.3.1 Background, qualifications, experience, and clearance 1743 requirements 1744 5.3.2 Background check procedures 1745 5.3.3 Training requirements 1746 5.3.4 Retraining frequency and requirements 1747 5.3.5 Job rotation frequency and sequence 1748 5.3.6 Sanctions for unauthorized actions 1749 5.3.7 Contracting personnel requirements 1750 5.3.8 Documentation supplied to personnel 1752 6. TECHNICAL SECURITY CONTROLS (34) 1754 6.1 Key Pair Generation and Installation 1755 6.1.1 Key pair generation 1756 6.1.2 Private key delivery to entity 1757 6.1.3 Public key delivery to certificate issuer 1758 6.1.4 CA public key delivery to users 1759 6.1.5 Key sizes 1760 6.1.6 Public key parameters generation 1761 6.1.7 Parameter quality checking 1762 6.1.8 Hardware/software key generation 1763 6.1.9 Key usage purposes (as per X.509 v3 key usage field) 1765 6.2 Private Key Protection 1766 6.2.1 Standards for cryptographic module 1767 6.2.2 Private key (n out of m) multi-person control 1768 6.2.3 Private key escrow 1769 6.2.4 Private key backup 1770 6.2.5 Private key archival 1771 6.2.6 Private key entry into cryptographic module 1772 6.2.7 Method of activating private key 1773 6.2.8 Method of deactivating private key 1774 6.2.9 Method of destroying private key 1776 6.3 Other Aspects of Key Pair Management 1777 6.3.1 Public key archival 1778 6.3.2 Usage periods for the public and private keys 1780 6.4 Activation Data 1781 6.4.1 Activation data generation and installation 1782 6.4.2 Activation data protection 1783 6.4.3 Other aspects of activation data 1785 6.5 Computer Security Controls 1786 6.5.1 Specific computer security technical requirements 1787 6.5.2 Computer security rating 1789 6.6 Life Cycle Technical Controls 1790 6.6.1 System development controls 1791 6.6.2 Security management controls 1792 6.6.3 Life cycle security ratings 1794 6.7 Network Security Controls 1796 6.8 Cryptographic Module Engineering Controls 1798 7. CERTIFICATE AND CRL PROFILES 1800 7.1 Certificate Profile 1802 7.1.1 Version number(s) 1803 7.1.2 Certificate extensions 1804 7.1.3 Algorithm object identifiers 1805 7.1.4 Name forms 1806 7.1.5 Name constraints 1807 7.1.6 Certificate policy Object Identifier 1808 7.1.7 Usage of Policy Constraints extension 1809 7.1.8 Policy qualifiers syntax and semantics 1810 7.1.9 Processing semantics for the critical certificate policy 1811 extension 1813 7.2 CRL Profile 1815 7.2.1 Version number(s) 1816 7.2.2 CRL and CRL entry extensions 1818 8. SPECIFICATION ADMINISTRATION 1820 8.1 Specification change procedures 1821 8.2 Publication and notification policies 1823 8.3 CPS approval procedures 1825 6. ACKNOWLEDGMENTS 1827 The development of this document was supported by the Government of 1828 Canada's Policy Management Authority (PMA) Committee, the National 1829 Security Agency, the National Institute of Standards and Technology 1830 (NIST), and the American Bar Association Information Security 1831 Committee Accreditation Technical Working Group. Special thanks are 1832 due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their 1833 inspiration, support, and valuable inputs. 1835 The following individuals also deserve credit for their review and 1836 input: 1838 Teresa Acevedo, A&N Associates; 1839 Michael Baum; VeriSign; 1840 Sharon Boeyen, Entrust; 1841 Bob Burger, McCarter & English; 1842 Bill Burr, NIST; 1843 Patrick Cain, BBN; 1844 Michael Harrop, Government of Canada Treasury Board; 1845 Rick Hornbeck, Digital Commerce Services; 1846 Francois Marinier, Domus Software; 1847 John Morris, CygnaCom Solutions; 1848 Tim Moses, Entrust; 1849 Noel Nazario, NIST; 1850 John Nicolletos, A&N Associates; 1851 Jean Petty, CygnaCom Solutions; 1852 Denis Pinkas, Bull; 1853 J.-F. Sauriol, Domus Software; 1854 Robert Shirey, BBN; 1855 Mark Silvern, VeriSign; 1856 David Simonetti, Booz, Allen and Hamilton; and 1857 Darryl Stal, Entrust. 1859 Johnny Hsiung, and Chris Miller assisted in the preparation of the 1860 manuscript. 1862 7. REFERENCES 1864 [ABA1] American Bar Association, Digital Signature Guidelines: Legal 1865 Infrastructure for Certification Authorities and Electronic Commerce, 1866 1995. 1868 [BAU1] Michael. S. Baum, Federal Certification Authority Liability 1869 and Policy, NIST-GCR- 94-654, June 1994. 1871 [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information 1872 Technology - Open Systems Interconnection: The Directory: 1873 Authentication Framework," 1997 edition. (Pending publication of 1997 1874 edition, use 1993 edition with the following amendment applied: 1875 Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate 1876 Extensions, June 1996.) 1878 [PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail, 1879 Part II: Certificate-Based Key Management," Internet RFC 1422, 1993. 1881 [PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 1882 Key Infrastructure, Certificate and CRL Profile," RFC [tbd], 1998. 1884 8. AUTHORS' ADDRESSES 1886 Santosh Chokhani 1887 CygnaCom Solutions, Inc. 1888 Suite 100 West 1889 7927 Jones Branch Drive 1890 McLean, VA 22102 1892 Phone: (703) 848-0883 1893 Fax: (703) 848-0960 1894 EMail: chokhani@cygnacom.com 1896 Warwick Ford 1897 VeriSign, Inc. 1898 301 Edgewater Place, Suite 210 1899 Wakefield, MA 01880 1901 Phone: (781) 245-6996 x225 1902 Fax: (781) 245-6006 1903 EMail: wford@verisign.com 1905 NOTES 1907 1 The ABA Digital Signature Guidelines can be purchased from the ABA. 1908 See http://www.abanet.com for ordering details. 1910 2 Examples of types of entity for subject CAs are a subordinate 1911 organization (e.g., branch or division), a federal government agency, 1912 or a state or provincial government department. 1914 3 This statement can have significant implications. For example, 1915 suppose a bank claims that it issues CA certificates to its branches 1916 only. Now, the user of a CA certificate issued by the bank can 1917 assume that the subject CA in the certificate is a branch of the bank 1919 4 Examples of the types of subject RA entities are branch and 1920 division of an organization. 1922 5 Examples of types of subject end entities are bank customers, 1923 telephone company subscribers, and employees of a government 1924 department 1926 6 This statement can have significant implications. For example, 1927 suppose Government CA claims that it issues certificates to 1928 Government employees only. Now, the user of a certificate issued by 1929 the Government CA can assume that the subject of the certificate is a 1930 Government employee. 1932 7 Examples include X.500 distinguished name, Internet e-mail address, 1933 and URL. 1935 8 The term "meaningful" means that the name form has commonly 1936 understood semantics to determine identity of the person and/or 1937 organization. Directory names and RFC 822 names may be more or less 1938 meaningful. 1940 9 Examples of proof include the issuing CA generating the key, or 1941 requiring the subject to send an electronically signed request or to 1942 sign a challenge. 1944 10 Examples of organization identity authentication are: articles of 1945 incorporation, duly signed corporate resolutions, company seal, and 1946 notarized documents. 1948 11 Examples of individual identity authentication are: biometrics 1949 (thumb print, ten finger print, face, palm, and retina scan), 1950 driver's license, passport, credit card, company badge, and 1951 government badge. 1953 12 Examples include duly signed authorization papers or corporate ID 1954 badge. 1956 13 The identification policy for routine rekey should be the same as 1957 the one for initial registration since the same subject needs 1958 rekeying. The rekey authentication may be accomplished using the 1959 techniques for initial I&A or using digitally signed requests. 1961 14 This identification and authentication policy could be the same as 1962 that for initial registration. 1964 15 This policy could be the same as the one for initial registration. 1966 16 The identification policy for Revocation request could be the same 1967 as that for initial registration since the same subject certificate 1968 needs to be revoked. The authentication policy could accept a 1969 Revocation request digitally signed by subject. The authentication 1970 information used during initial registration could be acceptable for 1971 Revocation request. Other less stringent authentication policy could 1972 be defined. 1974 17 The identification policy for key compromise notification could be 1975 the same as the one for initial registration since the same subject 1976 certificate needs to be revoked. The authentication policy could 1977 accept a Revocation request digitally signed by subject. The 1978 authentication information used during initial registration could be 1979 acceptable for key compromise notification. Other less stringent 1980 authentication policy could be defined. 1982 18 The n out of m rule allows a key to be split in m parts. The m 1983 parts may be given to m different individuals. Any n parts out of 1984 the m parts may be used to fully reconstitute the key, but having any 1985 n- 1 parts provides one with no information about the key. 1987 19 A key may be escrowed, backed up or archived. Each of these 1988 functions have different purpose. Thus, a key may go through any 1989 subset of these functions depending on the requirements. The purpose 1990 of escrow is to allow a third party (such as an organization or 1991 government) to legally obtain the key without the cooperation of the 1992 subject. The purpose of back up is to allow the subject to 1993 reconstitute the key in case of the destruction of the key. The 1994 purpose of archive is to provide for reuse of the key in future, 1995 e.g., use the private key to decrypt a document. 1997 20 An example of activation data is a PIN or passphrase. 1999 21 Examples of physical access controls are: monitored facility , 2000 guarded facility, locked facility, access controlled using tokens, 2001 access controlled using biometrics, and access controlled through an 2002 access list. 2004 22 Examples of the roles include system administrator, system 2005 security officer, and system auditor. The duties of the system 2006 administrator are to configure, generate, boot, and operate the 2007 system. The duties of the system security officer are to assign 2008 accounts and privileges. The duties of the system auditor are to set 2009 up system audit profile, perform audit file management, and audit 2010 review. 2012 23 The background checks may include clearance level (e.g., none, 2013 sensitive, confidential, secret, top secret, etc.) and the clearance 2014 granting authority name. In lieu of or in addition to a defined 2015 clearance, the background checks may include types of background 2016 information (e.g., name, place of birth, date of birth, home address, 2017 previous residences, previous employment, and any other information 2018 that may help determine trustworthiness). The description should 2019 also include which information was verified and how. 2021 24 For example, the certificate policy may impose personnel security 2022 requirements on the network system administrator responsible for a 2023 CA's network access. 2025 25 Regardless of whether authorized persons are employees, practices 2026 should be implemented to ensure that each authorized person is held 2027 accountable for his/her actions. 2029 26 A cryptographic module is hardware, software, or firmware or any 2030 combination of them. 2032 27 The compliance description should be specific and detailed. For 2033 example, for each FIPS 140-1 requirement, describe the level and 2034 whether the level has been certified by an accredited laboratory. 2036 28 Example of audit events are: request to create a certificate, 2037 request to revoke a certificate, key compromise notification, 2038 creation of a certificate, revocation of a certificate, issuance of a 2039 certificate, issuance of a CRL, issuance of key compromise CRL, 2040 establishment of trusted roles on the CA, actions of truste 2041 personnel, changes to CA keys, etc. 2043 29 Example of archive events are: request to create a certificate, 2044 request to revoke a certificate, key compromise notification, 2045 creation of a certificate, revocation of a certificate, issuance of a 2046 certificate, issuance of a CRL, issuance of key compromise CRL, and 2047 changes to CA keys. 2049 30 A parent CA is an example of audit relationship. 2051 31 Example of compliance audit topics: sample check on the various 2052 I&A policies, comprehensive checks on key management policies, 2053 comprehensive checks on system security controls, comprehensive 2054 checks on operations policy, and comprehensive checks on certificate 2055 profiles. 2057 32 The examples include, temporary suspension of operations until 2058 deficiencies are corrected, revocation of entity certificate, change 2059 in personnel, invocation of liability policy, more frequent 2060 compliance audit, etc. 2062 33 An organization may choose not to make public some of its security 2063 controls, clearance procedures, or some others elements due to their 2064 sensitivity. 2066 34 All or some of the following items may be different for the 2067 various types of entities, i.e., CA, RA, and end entities. 2069 LIST OF ACRONYMS 2071 ABA - American Bar Association 2072 CA - Certification Authority 2073 CPS - Certification Practice Statement 2074 CRL - Certificate Revocation List 2075 DAM - Draft Amendment 2076 FIPS - Federal Information Processing Standard 2077 I&A - Identification and Authentication 2078 IEC - International Electrotechnical Commission 2079 IETF - Internet Engineering Task Force 2080 IP - Internet Protocol 2081 ISO - International Organization for Standardization 2082 ITU - International Telecommunications Union 2083 NIST - National Institute of Standards and Technology 2084 OID - Object Identifier 2085 PIN - Personal Identification Number 2086 PKI - Public Key Infrastructure 2087 PKIX - Public Key Infrastructure (X.509) (IETF Working Group) 2088 RA - Registration Authority 2089 RFC - Request For Comment 2090 URL - Uniform Resource Locator 2091 US - United States