rfc2527.txt

PKIX的RFC英文文档

Network Working Group                                        S. Chokhani
Request for Comments: 2527                      CygnaCom Solutions, Inc.
Category: Informational                                          W. Ford
                                                          VeriSign, Inc.
                                                              March 1999


                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 (1999).  All Rights Reserved.

Abstract

   This document presents a framework to assist the writers of
   certificate policies or certification practice statements for
   certification authorities and public key infrastructures.  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 definition or a certification practice statement.

1. INTRODUCTION

1.1  BACKGROUND

   A public-key certificate (hereinafter "certificate") binds a public-
   key value to a set of information that identifies the entity (such as
   person, organization, account, or site) associated with use of the
   corresponding private key (this entity is known as the "subject" of
   the certificate).  A certificate is used by a "certificate user" or
   "relying party" that needs to use, and rely upon the accuracy of, the
   public key distributed via that certificate (a certificate user is
   typically an entity that is verifying a digital signature from the
   certificate's subject or an entity sending encrypted data to the
   subject).  The degree to which a certificate user can trust the
   binding embodied in a certificate depends on several factors. These
   factors include the practices followed by the certification authority
   (CA) in authenticating the subject; the CA's operating policy,
   procedures, and security controls; the subject's obligations (for
   example, in protecting the private key); and the stated undertakings



Chokhani & Ford              Informational                      [Page 1]

RFC 2527                          PKIX                        March 1999


   and legal obligations of the CA (for example, warranties and
   limitations on liability).

   A Version 3 X.509 certificate may contain a field declaring that one
   or more specific certificate policies applies to that certificate
   [ISO1].  According to X.509, a certificate policy is "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." A certificate policy may be used by a certificate user
   to help in deciding whether a certificate, and the binding therein,
   is sufficiently trustworthy for a particular application.  The
   certificate policy concept is an outgrowth of the policy statement
   concept developed for Internet Privacy Enhanced Mail [PEM1] and
   expanded upon in [BAU1].

   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 Digital Signature
   Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of
   the practices which a certification authority employs in issuing
   certificates." [ABA1]

1.2  PURPOSE

   The purpose of this document is to establish a clear relationship
   between certificate policies and CPSs, and to present a framework to
   assist the writers of certificate policies or CPSs with their tasks.
   In particular, the framework identifies the elements that may need to
   be considered in formulating a certificate policy or a CPS.  The
   purpose is not to define particular certificate policies or CPSs, per
   se.

1.3  SCOPE

   The scope of this document is limited to discussion of the contents
   of a certificate policy (as defined in X.509) or CPS (as defined in
   the ABA Guidelines).  In particular, this document describes the
   types of information that should be considered for inclusion in a
   certificate policy definition or a CPS.  While the framework as
   presented generally assumes use of the X.509 version 3 certificate
   format, it is not intended that the material be restricted to use of
   that certificate format.  Rather, it is intended that this framework
   be adaptable to other certificate formats 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) beyond the policy elements that are considered



Chokhani & Ford              Informational                      [Page 2]

RFC 2527                          PKIX                        March 1999


   of particular relevance to certificate policies or CPSs.

   This document does not define a specific certificate policy or CPS.

   It is assumed that the reader is familiar with the general concepts
   of digital signatures, certificates, and public-key infrastructure,
   as used in X.509 and the ABA Guidelines.

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).

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

      Certificate policy - 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 certificate policy might indicate
      applicability of a type of certificate to the authentication of
      electronic data interchange transactions for the trading of goods
      within a given price range.

      Certification path - An ordered sequence of certificates which,
      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 which a certification authority employs in issuing
      certificates.

      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).

      Policy qualifier - Policy-dependent information that accompanies a
      certificate policy identifier in an X.509 certificate.

      Registration authority (RA) - An entity that is responsible for
      identification and authentication of certificate subjects, but
      that does 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 used elsewhere for the same
      concept.]



Chokhani & Ford              Informational                      [Page 3]

RFC 2527                          PKIX                        March 1999


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

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

      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 authority).

3.  CONCEPTS

   This section explains the concepts of certificate policy and CPS, and
   describes their relationship.  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 a particular entity (the
   certificate subject).  However, the extent to which the certificate
   user should rely on that statement by the CA needs to be assessed by
   the certificate user.  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 certificate policy 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 contain an
   indication of certificate policy, which may be used by a certificate
   user to decide whether or not to trust a certificate for a particular
   purpose.

   A certificate policy, which needs to be recognized by both the issuer
   and user of a certificate, is represented in a certificate by a
   unique, registered Object Identifier.  The registration process
   follows the procedures specified in ISO/IEC and ITU standards.  The



Chokhani & Ford              Informational                      [Page 4]

RFC 2527                          PKIX                        March 1999


   party that registers the Object Identifier also publishes a textual
   specification of the certificate policy, for examination by
   certificate users.  Any one certificate will typically declare a
   single certificate policy or, possibly, be issued consistent with a
   small number of different policies.

   Certificate policies also constitute a basis for accreditation of
   CAs.  Each CA is accredited against one or more certificate policies
   which 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 accreditation 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
   certificate policy indications in its well-defined trust model.

3.2  CERTIFICATE POLICY EXAMPLES

   For example purposes, suppose that IATA undertakes to define some
   certificate policies for use throughout the airline industry, in a
   public-key infrastructure operated by IATA in combination with
   public-key infrastructures operated by individual airlines.  Two
   certificate policies are defined - the IATA General-Purpose policy,
   and the IATA Commercial-Grade policy.

   The IATA General-Purpose policy is intended for use 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 policy is used to protect financial
   transactions or binding contractual exchanges between airlines.
   Under this policy, IATA requires that certified key pairs be
   generated and stored in approved cryptographic hardware tokens.
   Certificates and tokens are provided to airline employees with
   disbursement authority. These authorized individuals are required to
   present themselves to the corporate security office, show a valid
   identification badge, and sign an undertaking to protect the token
   and use it only for authorized purposes, before a token and a
   certificate are issued.




Chokhani & Ford              Informational                      [Page 5]

RFC 2527                          PKIX                        March 1999


3.3 X.509 CERTIFICATE FIELDS

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

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

3.3.1 Certificate Policies Extension

   The Certificate Policies extension has two variants - one with the
   field flagged non-critical and one with the field flagged critical.
   The purpose of the field is different in the two cases.

   A non-critical Certificate Policies field lists certificate policies
   that the certification authority declares are applicable.  However,
   use of the certificate is not restricted to the purposes indicated by
   the applicable policies.  Using the example of the IATA General-
   Purpose and Commercial-Grade policies defined in Section 3.2, the
   certificates issued to regular airline employees will contain the
   object identifier for certificate policy for the General-Purpose
   policy.  The certificates issued to the employees with disbursement
   authority will contain the object identifiers for both the General-
   Purpose policy and the Commercial-Grade policy.  The Certificate
   Policies field may also optionally convey qualifier values for each
   identified policy; use of qualifiers is discussed in Section 3.4.

   The non-critical Certificate Policies field is designed to be used by
   applications as follows.  Each application is pre-configured to know
   what policy it requires.  Using the example in Section 3.2,
   electronic mail applications and Web servers will be configured to
   require the General-Purpose policy.  However, an airline's financial
   applications will be configured to require the Commercial-Grade
   policy for validating financial transactions over a certain dollar
   value.

   When processing a certification path, a certificate policy that is
   acceptable to the certificate-using 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.  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 one of the listed certificate policies. This field is



Chokhani & Ford              Informational                      [Page 6]

RFC 2527                          PKIX                        March 1999


   intended to protect the certification authority against damage claims
   by a relying party who has used the certificate for an inappropriate