rfc3280.txt

RFC 的详细文档！

Housley, et. al.            Standards Track                     [Page 5]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   certificates, this document defines a profile to promote the
   development of certificate management systems; development of
   application tools; and interoperability determined by policy.

   Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.  However, for basic applications, common
   representations of frequently used attributes are defined so that
   application developers can obtain necessary information without
   regard to the issuer of a particular certificate or certificate
   revocation list (CRL).

   A certificate user should review the certificate policy generated by
   the certification authority (CA) before relying on the authentication
   or non-repudiation services associated with the public key in a
   particular certificate.  To this end, this standard does not
   prescribe legally binding rules or duties.

   As supplemental authorization and attribute management tools emerge,
   such as attribute certificates, it may be appropriate to limit the
   authenticated attributes that are included in a certificate.  These
   other management tools may provide more appropriate methods of
   conveying many authenticated attributes.

2.1  Communication and Topology

   The users of certificates will operate in a wide range of
   environments with respect to their communication topology, especially
   users of secure electronic mail.  This profile supports users without
   high bandwidth, real-time IP connectivity, or high connection
   availability.  In addition, the profile allows for the presence of
   firewall or other filtered communication.

   This profile does not assume the deployment of an X.500 Directory
   system or a LDAP directory system.  The profile does not prohibit the
   use of an X.500 Directory or a LDAP directory; however, any means of
   distributing certificates and certificate revocation lists (CRLs) may
   be used.

2.2  Acceptability Criteria

   The goal of the Internet Public Key Infrastructure (PKI) is to meet
   the needs of deterministic, automated identification, authentication,
   access control, and authorization functions.  Support for these
   services determines the attributes contained in the certificate as
   well as the ancillary control information in the certificate such as
   policy data and certification path constraints.



Housley, et. al.            Standards Track                     [Page 6]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


2.3  User Expectations

   Users of the Internet PKI are people and processes who use client
   software and are the subjects named in certificates.  These uses
   include readers and writers of electronic mail, the clients for WWW
   browsers, WWW servers, and the key manager for IPsec within a router.
   This profile recognizes the limitations of the platforms these users
   employ and the limitations in sophistication and attentiveness of the
   users themselves.  This manifests itself in minimal user
   configuration responsibility (e.g., trusted CA keys, rules), explicit
   platform usage constraints within the certificate, certification path
   constraints which shield the user from many malicious actions, and
   applications which sensibly automate validation functions.

2.4  Administrator Expectations

   As with user expectations, the Internet PKI profile is structured to
   support the individuals who generally operate CAs.  Providing
   administrators with unbounded choices increases the chances that a
   subtle CA administrator mistake will result in broad compromise.
   Also, unbounded choices greatly complicate the software that process
   and validate the certificates created by the CA.

3  Overview of Approach

   Following is a simplified view of the architectural model assumed by
   the PKIX specifications.

   The components in this model are:

   end entity: user of PKI certificates and/or end user system that is
               the subject of a certificate;
   CA:         certification authority;
   RA:         registration authority, i.e., an optional system to which
               a CA delegates certain management functions;
   CRL issuer: an optional system to which a CA delegates the
               publication of certificate revocation lists;
   repository: a system or collection of distributed systems that stores
               certificates and CRLs and serves as a means of
               distributing these certificates and CRLs to end entities.

   Note that an Attribute Authority (AA) might also choose to delegate
   the publication of CRLs to a CRL issuer.








Housley, et. al.            Standards Track                     [Page 7]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   +---+
   | C |                       +------------+
   | e | <-------------------->| End entity |
   | r |       Operational     +------------+
   | t |       transactions          ^
   | i |      and management         |  Management
   | f |       transactions          |  transactions        PKI
   | i |                             |                     users
   | c |                             v
   | a | =======================  +--+------------+  ==============
   | t |                          ^               ^
   | e |                          |               |         PKI
   |   |                          v               |      management
   | & |                       +------+           |       entities
   |   | <---------------------|  RA  |<----+     |
   | C |  Publish certificate  +------+     |     |
   | R |                                    |     |
   | L |                                    |     |
   |   |                                    v     v
   | R |                                +------------+
   | e | <------------------------------|     CA     |
   | p |   Publish certificate          +------------+
   | o |   Publish CRL                     ^      ^
   | s |                                   |      |  Management
   | i |                +------------+     |      |  transactions
   | t | <--------------| CRL Issuer |<----+      |
   | o |   Publish CRL  +------------+            v
   | r |                                      +------+
   | y |                                      |  CA  |
   +---+                                      +------+

                      Figure 1 - PKI Entities

3.1  X.509 Version 3 Certificate

   Users of a public key require confidence that the associated private
   key is owned by the correct remote subject (person or system) with
   which an encryption or digital signature mechanism will be used.
   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  The CA may base this assertion upon
   technical means (a.k.a., proof of possession through a challenge-
   response protocol), presentation of the private key, or on an
   assertion by the subject.  A certificate has a limited valid lifetime
   which is indicated in its signed contents.  Because a certificate's
   signature and timeliness can be independently checked by a
   certificate-using client, certificates can be distributed via



Housley, et. al.            Standards Track                     [Page 8]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   untrusted communications and server systems, and can be cached in
   unsecured storage in certificate-using systems.

   ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first
   published in 1988 as part of the X.500 Directory recommendations,
   defines a standard certificate format [X.509].  The certificate
   format in the 1988 standard is called the version 1 (v1) format.
   When X.500 was revised in 1993, two more fields were added, resulting
   in the version 2 (v2) format.

   The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
   include specifications for a public key infrastructure based on X.509
   v1 certificates [RFC 1422].  The experience gained in attempts to
   deploy RFC 1422 made it clear that the v1 and v2 certificate formats
   are deficient in several respects.  Most importantly, more fields
   were needed to carry information which PEM design and implementation
   experience had proven necessary.  In response to these new
   requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version
   3 (v3) certificate format.  The v3 format extends the v2 format by
   adding provision for additional extension fields.  Particular
   extension field types may be specified in standards or may be defined
   and registered by any organization or community.  In June 1996,
   standardization of the basic v3 format was completed [X.509].

   ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions
   for use in the v3 extensions field [X.509][X9.55].  These extensions
   can convey such data as additional subject identification
   information, key attribute information, policy information, and
   certification path constraints.

   However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very
   broad in their applicability.  In order to develop interoperable
   implementations of X.509 v3 systems for Internet use, it is necessary
   to specify a profile for use of the X.509 v3 extensions tailored for
   the Internet.  It is one goal of this document to specify a profile
   for Internet WWW, electronic mail, and IPsec applications.
   Environments with additional requirements may build on this profile
   or may replace it.

3.2  Certification Paths and Trust

   A user of a security service requiring knowledge of a public key
   generally needs to obtain and validate a certificate containing the
   required public key.  If the public key user does not already hold an
   assured copy of the public key of the CA that signed the certificate,
   the CA's name, and related information (such as the validity period
   or name constraints), then it might need an additional certificate to
   obtain that public key.  In general, a chain of multiple certificates



Housley, et. al.            Standards Track                     [Page 9]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   may be needed, comprising a certificate of the public key owner (the
   end entity) signed by one CA, and zero or more additional
   certificates of CAs signed by other CAs.  Such chains, called
   certification paths, are required because a public key user is only
   initialized with a limited number of assured CA public keys.

   There are different ways in which CAs might be configured in order
   for public key users to be able to find certification paths.  For
   PEM, RFC 1422 defined a rigid hierarchical structure of CAs.  There
   are three types of PEM certification authority:

      (a)  Internet Policy Registration Authority (IPRA):  This
      authority, operated under the auspices of the Internet Society,
      acts as the root of the PEM certification hierarchy at level 1.
      It issues certificates only for the next level of authorities,
      PCAs.  All certification paths start with the IPRA.

      (b)  Policy Certification Authorities (PCAs):  PCAs are at level 2
      of the hierarchy, each PCA being certified by the IPRA.  A PCA
      shall establish and publish a statement of its policy with respect
      to certifying users or subordinate certification authorities.
      Distinct PCAs aim to satisfy different user needs.  For example,
      one PCA (an organizational PCA) might support the general
      electronic mail needs of commercial organizations, and another PCA
      (a high-assurance PCA) might have a more stringent policy designed
      for satisfying legally binding digital signature requirements.

      (c)  Certification Authorities (CAs):  CAs are at level 3 of the
      hierarchy and can also be at lower levels.  Those at level 3 are
      certified by PCAs.  CAs represent, for example, particular
      organizations, particular organizational units (e.g., departments,
      groups, sections), or particular geographical areas.

   RFC 1422 furthermore has a name subordination rule which requires
   that a CA can only issue certificates for entities whose names are
   subordinate (in the X.500 naming tree) to the name of the CA itself.
   The trust associated with a PEM certification path is implied by the
   PCA name.  The name subordination rule ensures that CAs below the PCA
   are sensibly constrained as to the set of subordinate entities they
   can certify (e.g., a CA for an organization can only certify entities
   in that organization's name tree).  Certificate user systems are able
   to mechanically check that the name subordination rule has been
   followed.

   The RFC 1422 uses the X.509 v1 certificate formats.  The limitations
   of X.509 v1 required imposition of several structural restrictions to
   clearly associate policy information or restrict the utility of
   certificates.  These restrictions included: