tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3647

Pages: 94
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PKIX

Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

Part 1 of 4, p. 1 to 21
None       Next RFC Part

Obsoletes:    2527

Top       ToC       Page 1 
Network Working Group                                        S. Chokhani
Request for Comments: 3647                Orion Security Solutions, Inc.
Obsoletes: 2527                                                  W. Ford
Category: Informational                                   VeriSign, Inc.
                                                               R. Sabett
                                                      Cooley Godward LLP
                                                              C. Merrill
                                                 McCarter & English, LLP
                                                                   S. Wu
                                                        Infoliance, Inc.
                                                           November 2003

                Internet X.509 Public Key Infrastructure
        Certificate Policy and Certification Practices Framework

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   This document presents a framework to assist the writers of
   certificate policies or certification practice statements for
   participants within public key infrastructures, such as certification
   authorities, policy authorities, and communities of interest that
   wish to rely on certificates.  In particular, the framework provides
   a comprehensive list of topics that potentially (at the writer's
   discretion) need to be covered in a certificate policy or a
   certification practice statement.  This document supersedes RFC 2527.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Background . . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Purpose. . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.3.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.  Certificate Policy . . . . . . . . . . . . . . . . . . .  9
       3.2.  Certificate Policy Examples. . . . . . . . . . . . . . . 11
       3.3.  X.509 Certificate Fields . . . . . . . . . . . . . . . . 12

Top      ToC       Page 2 
             3.3.1.  Certificate Policies Extension . . . . . . . . . 12
             3.3.2.  Policy Mappings Extension. . . . . . . . . . . . 13
             3.3.3.  Policy Constraints Extension . . . . . . . . . . 13
             3.3.4.  Policy Qualifiers. . . . . . . . . . . . . . . . 14
       3.4.  Certification Practice Statement . . . . . . . . . . . . 15
       3.5.  Relationship Between CP and CPS. . . . . . . . . . . . . 16
       3.6.  Relationship Among CPs, CPSs, Agreements, and
             Other Documents. . . . . . . . . . . . . . . . . . . . . 17
       3.7.  Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
   4.  Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
       4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . 22
             4.1.1.  Overview . . . . . . . . . . . . . . . . . . . . 22
             4.1.2.  Document Name and Identification . . . . . . . . 22
             4.1.3.  PKI Participants . . . . . . . . . . . . . . . . 23
             4.1.4.  Certificate Usage. . . . . . . . . . . . . . . . 24
             4.1.5.  Policy Administration. . . . . . . . . . . . . . 24
             4.1.6.  Definitions and Acronyms . . . . . . . . . . . . 24
       4.2.  Publication and Repository Responsibilities. . . . . . . 25
       4.3.  Identification and Authentication (I&A). . . . . . . . . 25
             4.3.1.  Naming . . . . . . . . . . . . . . . . . . . . . 25
             4.3.2.  Initial Identity Validation. . . . . . . . . . . 26
             4.3.3.  Identification and Authentication for
                     Re-key Requests. . . . . . . . . . . . . . . . . 27
             4.3.4.  Identification and Authentication for
                     Revocation Requests. . . . . . . . . . . . . . . 27
       4.4.  Certificate Life-Cycle Operational Requirements. . . . . 27
             4.4.1.  Certificate Application. . . . . . . . . . . . . 28
             4.4.2.  Certificate Application Processing . . . . . . . 28
             4.4.3.  Certificate Issuance . . . . . . . . . . . . . . 28
             4.4.4.  Certificate Acceptance . . . . . . . . . . . . . 29
             4.4.5.  Key Pair and Certificate Usage . . . . . . . . . 29
             4.4.6.  Certificate Renewal. . . . . . . . . . . . . . . 30
             4.4.7.  Certificate Re-key . . . . . . . . . . . . . . . 30
             4.4.8.  Certificate Modification . . . . . . . . . . . . 31
             4.4.9.  Certificate Revocation and Suspension. . . . . . 31
             4.4.10. Certificate Status Services. . . . . . . . . . . 33
             4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
             4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
       4.5.  Management, Operational, and Physical Controls . . . . . 33
             4.5.1.  Physical Security Controls . . . . . . . . . . . 34
             4.5.2.  Procedural Controls. . . . . . . . . . . . . . . 35
             4.5.3.  Personnel Controls . . . . . . . . . . . . . . . 35
             4.5.4.  Audit Logging Procedures . . . . . . . . . . . . 36
             4.5.5.  Records Archival . . . . . . . . . . . . . . . . 37
             4.5.6.  Key Changeover . . . . . . . . . . . . . . . . . 38
             4.5.7.  Compromise and Disaster Recovery . . . . . . . . 38
             4.5.8.  CA or RA Termination . . . . . . . . . . . . . . 38
        4.6. Technical Security Controls. . . . . . . . . . . . . . . 39
             4.6.1.  Key Pair Generation and Installation . . . . . . 39
             4.6.2.  Private Key Protection and Cryptographic

Top      ToC       Page 3 
                     Module Engineering Controls. . . . . . . . . . . 40
             4.6.3.  Other Aspects of Key Pair Management . . . . . . 42
             4.6.4.  Activation Data. . . . . . . . . . . . . . . . . 42
             4.6.5.  Computer Security Controls . . . . . . . . . . . 42
             4.6.6.  Life Cycle Security Controls . . . . . . . . . . 43
             4.6.7.  Network Security Controls. . . . . . . . . . . . 43
             4.6.8.  Time-stamping. . . . . . . . . . . . . . . . . . 43
       4.7.  Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
             4.7.1.  Certificate Profile. . . . . . . . . . . . . . . 44
             4.7.2.  CRL Profile. . . . . . . . . . . . . . . . . . . 44
             4.7.3.  OCSP Profile . . . . . . . . . . . . . . . . . . 44
       4.8.  Compliance Audit and Other Assessment. . . . . . . . . . 45
       4.9.  Other Business and Legal Matters . . . . . . . . . . . . 45
             4.9.1.  Fees . . . . . . . . . . . . . . . . . . . . . . 46
             4.9.2.  Financial Responsibility . . . . . . . . . . . . 47
             4.9.3.  Confidentiality of Business Information. . . . . 47
             4.9.4.  Privacy of Personal Information. . . . . . . . . 48
             4.9.5.  Intellectual Property Rights . . . . . . . . . . 48
             4.9.6.  Representations and Warranties . . . . . . . . . 48
             4.9.7.  Disclaimers of Warranties. . . . . . . . . . . . 49
             4.9.8.  Limitations of Liability . . . . . . . . . . . . 49
             4.9.9.  Indemnities. . . . . . . . . . . . . . . . . . . 49
             4.9.10. Term and Termination . . . . . . . . . . . . . . 50
             4.9.11. Individual notices and communications
                     with participants. . . . . . . . . . . . . . . . 50
             4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
             4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
             4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
             4.9.15. Compliance with Applicable Law . . . . . . . . . 51
             4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
             4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 53
   6.  Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
   7.  Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
   10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
   11. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
   12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 92
   13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94

Top      ToC       Page 4 
1.  Introduction

1.1.  Background

   In general, a public-key certificate (hereinafter "certificate")
   binds a public key held by an entity (such as person, organization,
   account, device, or site) to a set of information that identifies the
   entity associated with use of the corresponding private key.  In most
   cases involving identity certificates, this entity is known as the
   "subject" or "subscriber" of the certificate.  Two exceptions,
   however, include devices (in which the subscriber is usually the
   individual or organization controlling the device) and anonymous
   certificates (in which the identity of the individual or organization
   is not available from the certificate itself).  Other types of
   certificates bind public keys to attributes of an entity other than
   the entity's identity, such as a role, a title, or creditworthiness

   A certificate is used by a "certificate user" or "relying party" that
   needs to use, and rely upon the accuracy of, the binding between the
   subject public key distributed via that certificate and the identity
   and/or other attributes of the subject contained in that certificate.
   A relying party is frequently an entity that verifies a digital
   signature from the certificate's subject where the digital signature
   is associated with an email, web form, electronic document, or other
   data.  Other examples of relying parties can include a sender of
   encrypted email to the subscriber, a user of a web browser relying on
   a server certificate during a secure sockets layer (SSL) session, and
   an entity operating a server that controls access to online
   information using client certificates as an access control mechanism.
   In summary, a relying party is an entity that uses a public key in a
   certificate (for signature verification and/or encryption).  The
   degree to which a relying party can trust the binding embodied in a
   certificate depends on several factors.  These factors can include
   the practices followed by the certification authority (CA) in
   authenticating the subject; the CA's operating policy, procedures,
   and security controls; the scope of the subscriber's responsibilities
   (for example, in protecting the private key); and the stated
   responsibilities and liability terms and conditions of the CA (for
   example, warranties, disclaimers of warranties, and limitations of

   A Version 3 X.509 certificate may contain a field declaring that one
   or more specific certificate policies apply to that certificate
   [ISO1].  According to X.509, a certificate policy (CP) is "a named
   set of rules that indicates the applicability of a certificate to a
   particular community and/or class of applications with common
   security requirements."  A CP may be used by a relying party to help

Top      ToC       Page 5 
   in deciding whether a certificate, and the binding therein, are
   sufficiently trustworthy and otherwise appropriate for a particular
   application.  The CP concept is an outgrowth of the policy statement
   concept developed for Internet Privacy Enhanced Mail [PEM1] and
   expanded upon in [BAU1].  The legal and liability aspects presented
   in Section 4.9 are outcomes of a collaborative effort between IETF
   PKIX working group and the American Bar Association (ABA) members who
   have worked on legal acceptance of digital signature and role of PKI
   in that acceptance.

   A more detailed description of the practices followed by a CA in
   issuing and otherwise managing certificates may be contained in a
   certification practice statement (CPS) published by or referenced by
   the CA.  According to the American Bar Association Information
   Security Committee's Digital Signature Guidelines (hereinafter
   "DSG")(1) and the Information Security Committee's PKI Assessment
   Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the
   practices which a certification authority employs in issuing
   certificates." [ABA1, ABA2]  In general, CPSs also describe practices
   relating to all certificate lifecycle services (e.g., issuance,
   management, revocation, and renewal or re-keying), and CPSs provide
   details concerning other business, legal, and technical matters.  The
   terms contained in a CP or CPS may or may not be binding upon a PKI's
   participants as a contract.  A CP or CPS may itself purport to be a
   contract.  More commonly, however, an agreement may incorporate a CP
   or CPS by reference and therefore attempt to bind the parties of the
   agreement to some or all of its terms.  For example, some PKIs may
   utilize a CP or (more commonly) a CPS that is incorporated by
   reference in the agreement between a subscriber and a CA or RA
   (called a "subscriber agreement") or the agreement between a relying
   party and a CA (called a "relying party agreement" or "RPA").  In
   other cases, however, a CP or CPS has no contractual significance at
   all.  A PKI may intend these CPs and CPSs to be strictly
   informational or disclosure documents.

1.2.  Purpose

   The purpose of this document is twofold.  First, the document aims to
   explain the concepts of a CP and a CPS, describe the differences
   between these two concepts, and describe their relationship to
   subscriber and relying party agreements.  Second, this document aims
   to present a framework to assist the writers and users of certificate
   policies or CPSs in drafting and understanding these documents.  In
   particular, the framework identifies the elements that may need to be
   considered in formulating a CP or a CPS.  The purpose is not to
   define particular certificate policies or CPSs, per se.  Moreover,
   this document does not aim to provide legal advice or recommendations

Top      ToC       Page 6 
   as to particular requirements or practices that should be contained
   within CPs or CPSs.  (Such recommendations, however, appear in

1.3.  Scope

   The scope of this document is limited to discussion of the topics
   that can be covered in a CP (as defined in X.509) or CPS (as defined
   in the DSG and PAG).  In particular, this document describes the
   types of information that should be considered for inclusion in a CP
   or a CPS.  While the framework as presented generally assumes use of
   the X.509 version 3 certificate format for the purpose of providing
   assurances of identity, it is not intended that the material be
   restricted to use of that certificate format or identity
   certificates.  Rather, it is intended that this framework be
   adaptable to other certificate formats and to certificates providing
   assurances other than identity that may come into use.

   The scope does not extend to defining security policies generally
   (such as organization security policy, system security policy, or
   data labeling policy).  Further, this document does not define a
   specific CP or CPS.  Moreover, in presenting a framework, this
   document should be viewed and used as a flexible tool presenting
   topics that should be considered of particular relevance to CPs or
   CPSs, and not as a rigid formula for producing CPs or CPSs.

   This document assumes that the reader is familiar with the general
   concepts of digital signatures, certificates, and public-key
   infrastructure (PKI), as used in X.509, the DSG, and the PAG.

2.  Definitions

   This document makes use of the following defined terms:

   Activation data - Data values, other than keys, that are required to
   operate cryptographic modules and that need to be protected (e.g., a
   PIN, a passphrase, or a manually-held key share).

   Authentication - The process of establishing that individuals,
   organizations, or things are who or what they claim to be.  In the
   context of a PKI, authentication can be the process of establishing
   that an individual or organization applying for or seeking access to
   something under a certain name is, in fact, the proper individual or
   organization.  This corresponds to the second process involved with
   identification, as shown in the definition of "identification" below.
   Authentication can also refer to a security service that provides
   assurances that individuals, organizations, or things are who or what

Top      ToC       Page 7 
   they claim to be or that a message or other data originated from a
   specific individual, organization, or device.  Thus, it is said that
   a digital signature of a message authenticates the message's sender.

   CA-certificate - A certificate for one CA's public key issued by
   another CA.

   Certificate policy (CP) - A named set of rules that indicates the
   applicability of a certificate to a particular community and/or class
   of application with common security requirements.  For example, a
   particular CP might indicate applicability of a type of certificate
   to the authentication of parties engaging in business-to-business
   transactions for the trading of goods or services within a given
   price range.

   Certification path - An ordered sequence of certificates that,
   together with the public key of the initial object in the path, can
   be processed to obtain that of the final object in the path.

   Certification Practice Statement (CPS) - A statement of the practices
   that a certification authority employs in issuing, managing,
   revoking, and renewing or re-keying certificates.

   CPS Summary (or CPS Abstract) - A subset of the provisions of a
   complete CPS that is made public by a CA.

   Identification - The process of establishing the identity of an
   individual or organization, i.e., to show that an individual or
   organization is a specific individual or organization.  In the
   context of a PKI, identification refers to two processes:

   (1) establishing that a given name of an individual or organization
       corresponds to a real-world identity of an individual or
       organization, and

   (2) establishing that an individual or organization applying for or
       seeking access to something under that name is, in fact, the
       named individual or organization.  A person seeking
       identification may be a certificate applicant, an applicant for
       employment in a trusted position within a PKI participant, or a
       person seeking access to a network or software application, such
       as a CA administrator seeking access to CA systems.

   Issuing certification authority (issuing CA) - In the context of a
   particular certificate, the issuing CA is the CA that issued the
   certificate (see also Subject certification authority).

Top      ToC       Page 8 
   Participant - An individual or organization that plays a role within
   a given PKI as a subscriber, relying party, CA, RA, certificate
   manufacturing authority, repository service provider, or similar

   PKI Disclosure Statement (PDS) - An instrument that supplements a CP
   or CPS by disclosing critical information about the policies and
   practices of a CA/PKI.  A PDS is a vehicle for disclosing and
   emphasizing information normally covered in detail by associated CP
   and/or CPS documents.  Consequently, a PDS is not intended to replace
   a CP or CPS.

   Policy qualifier - Policy-dependent information that may accompany a
   CP identifier in an X.509 certificate.  Such information can include
   a pointer to the URL of the applicable CPS or relying party
   agreement.  It may also include text (or number causing the
   appearance of text) that contains terms of the use of the certificate
   or other legal information.

   Registration authority (RA) - An entity that is responsible for one
   or more of the following functions:  the identification and
   authentication of certificate applicants, the approval or rejection
   of certificate applications, initiating certificate revocations or
   suspensions under certain circumstances, processing subscriber
   requests to revoke or suspend their certificates, and approving or
   rejecting requests by subscribers to renew or re-key their
   certificates.  RAs, however, do not sign or issue certificates (i.e.,
   an RA is delegated certain tasks on behalf of a CA).  [Note: The term
   Local Registration Authority (LRA) is sometimes used in other
   documents for the same concept.]

   Relying party - A recipient of a certificate who acts in reliance on
   that certificate and/or any digital signatures verified using that
   certificate.  In this document, the terms "certificate user" and
   "relying party" are used interchangeably.

   Relying party agreement (RPA) - An agreement between a certification
   authority and relying party that typically establishes the rights and
   responsibilities between those parties regarding the verification of
   digital signatures or other uses of certificates.

   Set of provisions - A collection of practice and/or policy
   statements, spanning a range of standard topics, for use in
   expressing a CP or CPS employing the approach described in this

Top      ToC       Page 9 
   Subject certification authority (subject CA) - In the context of a
   particular CA-certificate, the subject CA is the CA whose public key
   is certified in the certificate (see also Issuing certification

   Subscriber - A subject of a certificate who is issued a certificate.

   Subscriber Agreement - An agreement between a CA and a subscriber
   that establishes the right and responsibilities of the parties
   regarding the issuance and management of certificates.

   Validation - The process of identification of certificate applicants.
   "Validation" is a subset of "identification" and refers to
   identification in the context of establishing the identity of
   certificate applicants.

3.  Concepts

   This section explains the concepts of CP and CPS, and describes their
   relationship with other PKI documents, such as subscriber agreements
   and relying party agreements.  Other related concepts are also
   described.  Some of the material covered in this section and in some
   other sections is specific to certificate policies extensions as
   defined X.509 version 3.  Except for those sections, this framework
   is intended to be adaptable to other certificate formats that may
   come into use.

3.1.  Certificate Policy

   When a certification authority issues a certificate, it is providing
   a statement to a certificate user (i.e., a relying party) that a
   particular public key is bound to the identity and/or other
   attributes of a particular entity (the certificate subject, which is
   usually also the subscriber).  The extent to which the relying party
   should rely on that statement by the CA, however, needs to be
   assessed by the relying party or entity controlling or coordinating
   the way relying parties or relying party applications use
   certificates.  Different certificates are issued following different
   practices and procedures, and may be suitable for different
   applications and/or purposes.

   The X.509 standard defines a CP as "a named set of rules that
   indicates the applicability of a certificate to a particular
   community and/or class of application with common security
   requirements" [ISO1].  An X.509 Version 3 certificate may identify a
   specific applicable CP, which may be used by a relying party to

Top      ToC       Page 10 
   decide whether or not to trust a certificate, associated public key,
   or any digital signatures verified using the public key for a
   particular purpose.

   CPs typically fall into two major categories.  First, some CPs
   "indicate the applicability of a certificate to a particular
   community" [ISO1].  These CPs set forth requirements for certificate
   usage and requirements on members of a community.  For instance, a CP
   may focus on the needs of a geographical community, such as the ETSI
   policy requirements for CAs issuing qualified certificates [ETS].
   Also, a CP of this kind may focus on the needs of a specific
   vertical-market community, such as financial services [IDT].

   The second category of typical CPs "indicate the applicability of a
   certificate to a . . . class of application with common security
   requirements."  These CPs identify a set of applications or uses for
   certificates and say that these applications or uses require a
   certain level of security.  They then set forth PKI requirements that
   are appropriate for these applications or uses.  A CP within this
   category often makes sets requirements appropriate for a certain
   "level of assurance" provided by certificates, relative to
   certificates issued pursuant to related CPs.  These levels of
   assurance may correspond to "classes" or "types" of certificates.

   For instance, the Government of Canada PKI Policy Management
   Authority (GOC PMA) has established eight certificate policies in a
   single document [GOC], four policies for certificates used for
   digital signatures and four policies for certificates used for
   confidentiality encryption.  For each of these applications, the
   document establishes four levels of assurances:  rudimentary, basic,
   medium, and high.  The GOC PMA described certain types of digital
   signature and confidentiality uses in the document, each with a
   certain set of security requirements, and grouped them into eight
   categories.  The GOC PMA then established PKI requirements for each
   of these categories, thereby creating eight types of certificates,
   each providing rudimentary, basic, medium, or high levels of
   assurance.  The progression from rudimentary to high levels
   corresponds to increasing security requirements and corresponding
   increasing levels of assurance.

   A CP is represented in a certificate by a unique number called an
   "Object Identifier" (OID).  That OID, or at least an "arc", can be
   registered.  An "arc" is the beginning of the numerical sequence of
   an OID and is assigned to a particular organization.  The
   registration process follows the procedures specified in ISO/IEC and
   ITU standards.  The party that registers the OID or arc also can
   publish the text of the CP, for examination by relying parties.  Any
   one certificate will typically declare a single CP or, possibly, be

Top      ToC       Page 11 
   issued consistent with a small number of different policies.  Such
   declaration appears in the Certificate Policies extension of a X.509
   Version 3 certificate.  When a CA places multiple CPs within a
   certificate's Certificate Policies extension, the CA is asserting
   that the certificate is appropriate for use in accordance with any of
   the listed CPs.

   CPs also constitute a basis for an audit, accreditation, or another
   assessment of a CA.  Each CA can be assessed against one or more
   certificate policies or CPSs that it is recognized as implementing.
   When one CA issues a CA-certificate for another CA, the issuing CA
   must assess the set of certificate policies for which it trusts the
   subject CA (such assessment may be based upon an assessment with
   respect to the certificate policies involved).  The assessed set of
   certificate policies is then indicated by the issuing CA in the CA-
   certificate.  The X.509 certification path processing logic employs
   these CP indications in its well-defined trust model.

3.2.  Certificate Policy Examples

   For example purposes, suppose that the International Air Transport
   Association (IATA) undertakes to define some certificate policies for
   use throughout the airline industry, in a PKI operated by IATA in
   combination with PKIs operated by individual airlines.  Two CPs might
   be defined - the IATA General-Purpose CP, and the IATA Commercial-
   Grade CP.

   The IATA General-Purpose CP could be used by industry personnel for
   protecting routine information (e.g., casual electronic mail) and for
   authenticating connections from World Wide Web browsers to servers
   for general information retrieval purposes. The key pairs may be
   generated, stored, and managed using low-cost, software-based
   systems, such as commercial browsers.  Under this policy, a
   certificate may be automatically issued to anybody listed as an
   employee in the corporate directory of IATA or any member airline who
   submits a signed certificate request form to a network administrator
   in his or her organization.

   The IATA Commercial-Grade CP could be used to protect financial
   transactions or binding contractual exchanges between airlines.
   Under this policy, IATA could require that certified key pairs be
   generated and stored in approved cryptographic hardware tokens.
   Certificates and tokens could be provided to airline employees with
   disbursement authority.  These authorized individuals might then be
   required to present themselves to the corporate security office, show
   a valid identification badge, and sign a subscriber agreement
   requiring them to protect the token and use it only for authorized
   purposes, as a condition of being issued a token and a certificate.

Top      ToC       Page 12 
3.3.  X.509 Certificate Fields

   The following extension fields in an X.509 certificate are used to
   support CPs:

   *  Certificate Policies extension;
   *  Policy Mappings extension; and
   *  Policy Constraints extension.

3.3.1.  Certificate Policies Extension

   A Certificate Policies field lists CPs that the certification
   authority declares are applicable.  Using the example of the IATA
   General-Purpose and Commercial-Grade policies defined in Section 3.2,
   the certificates issued to regular airline employees would contain
   the object identifier for General-Purpose policy.  The certificates
   issued to the employees with disbursement authority would contain the
   object identifiers for both the General-Purpose policy and the
   Commercial-Grade policy.  The inclusion of both object identifiers in
   the certificates means that they would be appropriate for either the
   General-Purpose or Commercial-Grade policies.  The Certificate
   Policies field may also optionally convey qualifier values for each
   identified policy; the use of qualifiers is discussed in Section 3.4.

   When processing a certification path, a CP that is acceptable to the
   relying party application must be present in every certificate in the
   path, i.e., in CA-certificates as well as end entity certificates.

   If the Certificate Policies field is flagged critical, it serves the
   same purpose as described above but also has an additional role.
   Specifically, it indicates that the use of the certificate is
   restricted to one of the identified policies, i.e., the certification
   authority is declaring that the certificate must only be used in
   accordance with the provisions of at least one of the listed CPs.
   This field is intended to protect the certification authority against
   claims for damages asserted by a relying party who has used the
   certificate for an inappropriate purpose or in an inappropriate
   manner, as stipulated in the applicable CP.

   For example, the Internal Revenue Service might issue certificates to
   taxpayers for the purpose of protecting tax filings.  The Internal
   Revenue Service understands and can accommodate the risks of
   erroneously issuing a bad certificate, e.g., to an imposter.
   Suppose, however, that someone used an Internal Revenue Service tax-
   filing certificate as the basis for encrypting multi-million-dollar-
   value proprietary trade secrets, which subsequently fell into the
   wrong hands because of a cryptanalytic attack by an attacker who is
   able to decrypt the message.  The Internal Revenue Service may want

Top      ToC       Page 13 
   to defend itself against claims for damages in such circumstances by
   pointing to the criticality of the Certificate Policies extension to
   show that the subscriber and relying party misused the certificate.
   The critical-flagged Certificate Policies extension is intended to
   mitigate the risk to the CA in such situations.

3.3.2.  Policy Mappings Extension

   The Policy Mappings extension may only be used in CA-certificates.
   This field allows a certification authority to indicate that certain
   policies in its own domain can be considered equivalent to certain
   other policies in the subject certification authority's domain.

   For example, suppose that for purposes of facilitating
   interoperability, the ACE Corporation establishes an agreement with
   the ABC Corporation to cross-certify the public keys of each others'
   certification authorities for the purposes of mutually securing their
   respective business-to-business exchanges.  Further, suppose that
   both companies have pre-existing financial transaction protection
   policies called ace-e-commerce and abc-e-commerce, respectively.  One
   can see that simply generating cross-certificates between the two
   domains will not provide the necessary interoperability, as the two
   companies' applications are configured with, and employee
   certificates are populated with, their respective certificate
   policies.  One possible solution is to reconfigure all of the
   financial applications to require either policy and to reissue all
   the certificates with both policies appearing in their Certificate
   Policies extensions.  Another solution, which may be easier to
   administer, uses the Policy Mapping field.  If this field is included
   in a cross-certificate for the ABC Corporation certification
   authority issued by the ACE Corporation certification authority, it
   can provide a statement that the ABC's financial transaction
   protection policy (i.e., abc-e-commerce) can be considered equivalent
   to that of the ACE Corporation (i.e., ace-e-commerce).  With such a
   statement included in the cross-certificate issued to ABC, relying
   party applications in the ACE domain requiring the presence of the
   object identifier for the ace-e-commerce CP can also accept, process,
   and rely upon certificates issued within the ABC domain containing
   the object identifier for the abc-e-commerce CP.

3.3.3.  Policy Constraints Extension

   The Policy Constraints extension supports two optional features.  The
   first is the ability for a certification authority to require that
   explicit CP indications be present in all subsequent certificates in
   a certification path.  Certificates at the start of a certification
   path may be considered by a relying party to be part of a trusted
   domain, i.e., certification authorities are trusted for all purposes

Top      ToC       Page 14 
   so no particular CP is needed in the Certificate Policies extension.
   Such certificates need not contain explicit indications of CP.  When
   a certification authority in the trusted domain, however, certifies
   outside the domain, it can activate the requirement that a specific
   CP's object identifier appear in subsequent certificates in the
   certification path.

   The other optional feature in the Policy Constraints field is the
   ability for a certification authority to disable policy mapping by
   subsequent certification authorities in a certification path.  It may
   be prudent to disable policy mapping when certifying outside the
   domain.  This can assist in controlling risks due to transitive
   trust, e.g., a domain A trusts domain B, domain B trusts domain C,
   but domain A does not want to be forced to trust domain C.

3.3.4.  Policy Qualifiers

   The Certificate Policies extension field has a provision for
   conveying, along with each CP identifier, additional policy-dependent
   information in a qualifier field.  The X.509 standard does not
   mandate the purpose for which this field is to be used, nor does it
   prescribe the syntax for this field.  Policy qualifier types can be
   registered by any organization.

   The following policy qualifier types are defined in PKIX RFC 3280

   (a) The CPS Pointer qualifier contains a pointer to a CPS, CPS
       Summary, RPA, or PDS published by the CA.  The pointer is in the
       form of a uniform resource identifier (URI).

   (b) The User Notice qualifier contains a text string that is to be
       displayed to subscribers and relying parties prior to the use of
       the certificate.  The text string may be an IA5String or a
       BMPString - a subset of the ISO 100646-1 multiple octet coded
       character set.  A CA may invoke a procedure that requires that
       the relying party acknowledge that the applicable terms and
       conditions have been disclosed and/or accepted.

   Policy qualifiers can be used to support the definition of generic,
   or parameterized, CPs.  Provided the base CP so provides, policy
   qualifier types can be defined to convey, on a per-certificate basis,
   additional specific policy details that fill in the generic

Top      ToC       Page 15 
3.4.  Certification Practice Statement

   The term certification practice statement (CPS) is defined by the DSG
   and PAG as:  "A statement of the practices which a certification
   authority employs in issuing certificates." [ABA1, ABA2]  As stated
   above, a CPS establishes practices concerning lifecycle services in
   addition to issuance, such as certificate management (including
   publication and archiving), revocation, and renewal or re-keying.  In
   the DSG, the ABA expands this definition with the following comments:

   "A certification practice statement may take the form of a
   declaration by the certification authority of the details of its
   trustworthy system and the practices it employs in its operations and
   in support of issuance of a certificate . . . ."  This form of CPS is
   the most common type, and can vary in length and level of detail.

   Some PKIs may not have the need to create a thorough and detailed
   statement of practices.  For example, the CA may itself be the
   relying party and would already be aware of the nature and
   trustworthiness of its services.  In other cases, a PKI may provide
   certificates providing only a very low level of assurances where the
   applications being secured may pose only marginal risks if
   compromised.  In these cases, an organization establishing a PKI may
   only want to write or have CAs use a subscriber agreement, relying
   party agreement, or agreement combining subscriber and relying party
   terms, depending on the role of the different PKI participants.  In
   such a PKI, that agreement may serve as the only "statement of
   practices" used by one or more CAs within that PKI.  Consequently,
   that agreement may also be considered a CPS and can be entitled or
   subtitled as such.

   Likewise, since a detailed CPS may contain sensitive details of its
   system, a CA may elect not to publish its entire CPS.  It may instead
   opt to publish a CPS Summary (or CPS Abstract).  The CPS Summary
   would contain only those provisions from the CPS that the CA
   considers to be relevant to the participants in the PKI (such as the
   responsibilities of the parties or the stages of the certificate
   lifecycle).  A CPS Summary, however, would not contain those
   sensitive provisions of the full CPS that might provide an attacker
   with useful information about the CA's operations.  Throughout this
   document, the use of "CPS" includes both a detailed CPS and a CPS
   Summary (unless otherwise specified).

   CPSs do not automatically constitute contracts and do not
   automatically bind PKI participants as a contract would.  Where a
   document serves the dual purpose of being a subscriber or relying
   party agreement and CPS, the document is intended to be a contract
   and constitutes a binding contract to the extent that a subscriber or

Top      ToC       Page 16 
   relying party agreement would ordinarily be considered as such.  Most
   CPSs, however, do not serve such a dual purpose.  Therefore, in most
   cases, a CPS's terms have a binding effect as contract terms only if
   a separate document creates a contractual relationship between the
   parties and that document incorporates part or all of the CPS by
   reference.  Further, if a particular PKI employs a CPS Summary (as
   opposed to the entire CPS), the CPS Summary could be incorporated
   into any applicable subscriber or relying party agreement.

   In the future, a court or applicable statutory or regulatory law may
   declare that a certificate itself is a document that is capable of
   creating a contractual relationship, to the extent its mechanisms
   designed for incorporation by reference (such as the Certificate
   Policies extension and its qualifiers) indicate that terms of its use
   appear in certain documents.  In the meantime, however, some
   subscriber agreements and relying party agreements may incorporate a
   CPS by reference and therefore make its terms binding on the parties
   to such agreements.

3.5.  Relationship Between Certificate Policy and Certification
      Practice Statement

   The CP and CPS address the same set of topics that are of interest to
   the relying party in terms of the degree to and purpose for which a
   public key certificate should be trusted.  Their primary difference
   is in the focus of their provisions.  A CP sets forth the
   requirements and standards imposed by the PKI with respect to the
   various topics.  In other words, the purpose of the CP is to
   establish what participants must do.  A CPS, by contrast, states how
   a CA and other participants in a given domain implement procedures
   and controls to meet the requirements stated in the CP.  In other
   words, the purpose of the CPS is to disclose how the participants
   perform their functions and implement controls.

   An additional difference between a CP and CPS relates the scope of
   coverage of the two kinds of documents.  Since a CP is a statement of
   requirements, it best serves as the vehicle for communicating minimum
   operating guidelines that must be met by interoperating PKIs.  Thus,
   a CP generally applies to multiple CAs, multiple organizations, or
   multiple domains.  By contrast, a CPS applies only to a single CA or
   single organization and is not generally a vehicle to facilitate

   A CA with a single CPS may support multiple CPs (used for different
   application purposes and/or by different relying party communities).
   Also, multiple CAs, with non-identical CPSs, may support the same CP.

Top      ToC       Page 17 
   For example, the Federal Government might define a government-wide CP
   for handling confidential human resources information.  The CP will
   be a broad statement of the general requirements for participants
   within the Government's PKI, and an indication of the types of
   applications for which it is suitable for use.  Each department or
   agency wishing to operate a certification authority in this PKI may
   be required to write its own certification practice statement to
   support this CP by explaining how it meets the requirements of the
   CP.  At the same time, a department's or agency's CPS may support
   other certificate policies.

   An additional difference between a CP and CPS concerns the level of
   detail of the provisions in each.  Although the level of detail may
   vary among CPSs, a CPS will generally be more detailed than a CP.  A
   CPS provides a detailed description of procedures and controls in
   place to meet the CP requirements, while a CP is more general.

   The main differences between CPs and CPSs can therefore be summarized
   as follows:

   (a) A PKI uses a CP to establish requirements that state what
       participants within it must do.  A single CA or organization can
       use a CPS to disclose how it meets the requirements of a CP or
       how it implements its practices and controls.

   (b) A CP facilitates interoperation through cross-certification,
       unilateral certification, or other means.  Therefore, it is
       intended to cover multiple CAs.  By contrast, a CPS is a
       statement of a single CA or organization.  Its purpose is not to
       facilitate interoperation (since doing so is the function of a

   (c) A CPS is generally more detailed than a CP and specifies how the
       CA meets the requirements specified in the one or more CPs under
       which it issues certificates.

   In addition to populating the certificate policies extension with the
   applicable CP object identifier, a certification authority may
   include, in certificates it issues, a reference to its certification
   practice statement.  A standard way to do this, using a CP qualifier,
   is described in Section 3.4.

3.6.  Relationship Among CPs, CPSs, Agreements, and Other Documents

   CPs and CPSs play a central role in documenting the requirements and
   practices of a PKI.  Nonetheless, they are not the only documents
   relevant to a PKI.  For instance, subscriber agreements and relying
   party agreements play a critical role in allocating responsibilities

Top      ToC       Page 18 
   to subscribers and relying parties relating to the use of
   certificates and key pairs.  They establish the terms and conditions
   under which certificates are issued, managed, and used.  The term
   subscriber agreement is defined by the PAG as:  "An agreement between
   a CA and a subscriber that establishes the right and obligations of
   the parties regarding the issuance and management of certificates."
   [ABA2]  The PAG defines a relying party agreement as: "An agreement
   between a certification authority and relying party that typically
   establishes the rights and obligations between those parties
   regarding the verification of digital signatures or other uses of
   certificates." [ABA2]

   As mentioned in Section 3.5, a subscriber agreement, relying party
   agreement, or an agreement that combines subscriber and relying party
   terms may also serve as a CPS.  In other PKIs, however, a subscriber
   or relying party agreement may incorporate some or all of the terms
   of a CP or CPS by reference.  Yet other PKIs may distill from a CP
   and/or CPS the terms that are applicable to a subscriber and place
   such terms in a self-contained subscriber agreement, without
   incorporating a CP or CPS by reference.  They may use the same method
   to distill relying party terms from a CP and/or CPS and place such
   terms in a self-contained relying party agreement.  Creating such
   self-contained agreements has the advantage of creating documents
   that are easier for consumers to review.  In some cases, subscribers
   or relying parties may be deemed to be "consumers" under applicable
   law, who are subject to certain statutory or regulatory protections.
   Under the legal systems of civil law countries, incorporating a CP or
   CPS by reference may not be effective to bind consumers to the terms
   of an incorporated CP or CPS.

   CPs and CPSs may be incorporated by reference in other documents,

   *  Interoperability agreements (including agreements between CAs for
      cross-certification, unilateral certification, or other forms of

   *  Vendor agreements (under which a PKI vendor agrees to meet
      standards set forth in a CP or CPS), or

   *  A PDS.  See [ABA2]

   A PDS serves a similar function to a CPS Summary.  It is a relatively
   short document containing only a subset of critical details about a
   PKI or CA.  It may differ from a CPS Summary, however, in that its
   purpose is to act as a summary of information about the overall
   nature of the PKI, as opposed to simply a condensed form of the CPS.

Top      ToC       Page 19 
   Moreover, its purpose is to distill information about the PKI, as
   opposed to protecting security sensitive information contained in an
   unpublished CPS, although a PDS could also serve that function.

   Just as writers may wish to refer to a CP or CPS or incorporate it by
   reference in an agreement or PDS, a CP or CPS may refer to other
   documents when establishing requirements or making disclosures.  For
   instance, a CP may set requirements for certificate content by
   referring to an external document setting forth a standard
   certificate profile.  Referencing external documents permits a CP or
   CPS to impose detailed requirements or make detailed disclosures
   without having to reprint lengthy provisions from other documents
   within the CP or CPS.  Moreover, referencing a document in a CP or
   CPS is another useful way of dividing disclosures between public
   information and security sensitive confidential information (in
   addition to or as an alternative to publishing a CPS Summary).  For
   example, a PKI may want to publish a CP or CPS, but maintain site
   construction parameters for CA high security zones as confidential
   information.  In that case, the CP or CPS could reference an external
   manual or document containing the detailed site construction

   Documents that a PKI may wish to refer to in a CP or CPS include:

   *  A security policy,

   *  Training, operational, installation, and user manuals (which may
      contain operational requirements),

   *  Standards documents that apply to particular aspects of the PKI
      (such as standards specifying the level of protection offered by
      any hardware tokens used in the PKI or standards applicable to the
      site construction),

   *  Key management plans,

   *  Human resource guides and employment manuals (which may describe
      some aspects of personnel security practices), and

   *  E-mail policies (which may discuss subscriber and relying party
      responsibilities, as well as the implications of key management,
      if applicable).  See [ABA2]

Top      ToC       Page 20 
3.7.  Set of Provisions

   A set of provisions is a collection of practice and/or policy
   statements, spanning a range of standard topics for use in expressing
   a CP or CPS employing the approach described in this framework by
   covering the topic appearing in Section 5 below.  They are also
   described in detail in Section 4 below.

   A CP can be expressed as a single set of provisions.

   A CPS can be expressed as a single set of provisions with each
   component addressing the requirements of one or more certificate
   policies, or, alternatively, as an organized collection of sets of
   provisions.  For example, a CPS could be expressed as a combination
   of the following:

   (a) a list of certificate policies supported by the CPS;

   (b) for each CP in (a), a set of provisions that contains statements
       responding to that CP by filling in details not stipulated in
       that policy or expressly left to the discretion of the CA (in its
       CPS) ; such statements serve to state how this particular CPS
       implements the requirements of the particular CP; or

   (c) a set of provisions that contains statements regarding the
       certification practices on the CA, regardless of CP.

   The statements provided in (b) and (c) may augment or refine the
   stipulations of the applicable CP, but generally must not conflict
   with any of the stipulations of such CP.  In certain cases, however,
   a policy authority may permit exceptions to the requirements in a CP,
   because certain compensating controls of the CA are disclosed in its
   CPS that allow the CA to provide assurances that are equivalent to
   the assurances provided by CAs that are in full compliance with the

   This framework outlines the contents of a set of provisions, in terms
   of nine primary components, as follows:

   1.  Introduction
   2.  Publication and Repository
   3.  Identification and Authentication
   4.  Certificate Life-Cycle Operational Requirements
   5.  Facilities, Management, and Operational Controls
   6.  Technical Security Controls
   7.  Certificate, CRL, and OCSP Profile
   8.  Compliance audit
   9.  Other Business and Legal Matters

Top      ToC       Page 21 
   PKIs can use this simple framework of nine primary components to
   write a simple CP or CPS.  Moreover, a CA can use this same framework
   to write a subscriber agreement, relying party agreement, or
   agreement containing subscriber and relying party terms.  If a CA
   uses this simple framework to construct an agreement, it can use
   paragraph 1 as an introduction or recitals, it can set forth the
   responsibilities of the parties in paragraphs 2-8, and it can use
   paragraph 9 to cover the business and legal issues described in more
   detail, using the ordering of Section 4.9 below (such as
   representations and warranties, disclaimers, and liability
   limitations).  The ordering of topics in this simple framework and
   the business and legal matters Section 4.9 is the same as (or similar
   to) the ordering of topics in a typical software or other technology
   agreement.  Therefore, a PKI can establish a set of core documents
   (with a CP, CPS, subscriber agreement, and relying party agreement)
   all having the same structure and ordering of topics, thereby
   facilitating comparisons and mappings among these documents and among
   the corresponding documents of other PKIs.

   This simple framework may also be useful for agreements other than
   subscriber agreements and relying party agreements.  For instance, a
   CA wishing to outsource certain services to an RA or certificate
   manufacturing authority (CMA) may find it useful to use this
   framework as a checklist to write a registration authority agreement
   or outsourcing agreement.  Similarly, two CAs may wish to use this
   simple framework for the purpose of drafting a cross-certification,
   unilateral certification, or other interoperability agreement.

   In short, the primary components of the simple framework (specified
   above) may meet the needs of drafters of short CPs, CPSs, subscriber
   agreements, and relying party agreements.  Nonetheless, this
   framework is extensible, and its coverage of the nine components is
   flexible enough to meet the needs of drafters of comprehensive CPs
   and CPSs.  Specifically, components appearing above can be further
   divided into subcomponents, and a subcomponent may comprise multiple
   elements.  Section 4 provides a more detailed description of the
   contents of the above components, and their subcomponents.  Drafters
   of CPs and CPSs are permitted to add additional levels of
   subcomponents below the subcomponents described in Section 4 for the
   purpose of meeting the needs of the drafter's particular PKI.

(page 21 continued on part 2)

Next RFC Part