tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3280


Pages: 129
Top     in Index     Prev     Next
 

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Part 1 of 5, p. 1 to 14
None       Next RFC Part

Obsoleted by:    5280
Obsoletes:    2459
Updated by:    4325    4630


Top       ToC       Page 1 
Network Working Group                                         R. Housley
Request for Comments: 3280                              RSA Laboratories
Obsoletes: 2459                                                  W. Polk
Category: Standards Track                                           NIST
                                                                 W. Ford
                                                                VeriSign
                                                                 D. Solo
                                                               Citigroup
                                                              April 2002

                Internet X.509 Public Key Infrastructure
       Certificate and Certificate Revocation List (CRL) Profile

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
   Revocation List (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail, and required extensions are defined.  An
   algorithm for X.509 certification path validation is described.  An
   ASN.1 module and examples are provided in the appendices.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   4
   2  Requirements and Assumptions  . . . . . . . . . . . . . .   5
   2.1  Communication and Topology  . . . . . . . . . . . . . .   6
   2.2  Acceptability Criteria  . . . . . . . . . . . . . . . .   6
   2.3  User Expectations . . . . . . . . . . . . . . . . . . .   7
   2.4  Administrator Expectations  . . . . . . . . . . . . . .   7
   3  Overview of Approach  . . . . . . . . . . . . . . . . . .   7

Top      ToC       Page 2 
   3.1  X.509 Version 3 Certificate . . . . . . . . . . . . . .   8
   3.2  Certification Paths and Trust . . . . . . . . . . . . .   9
   3.3  Revocation  . . . . . . . . . . . . . . . . . . . . . .  11
   3.4  Operational Protocols . . . . . . . . . . . . . . . . .  13
   3.5  Management Protocols  . . . . . . . . . . . . . . . . .  13
   4  Certificate and Certificate Extensions Profile  . . . . .  14
   4.1  Basic Certificate Fields  . . . . . . . . . . . . . . .  15
   4.1.1  Certificate Fields  . . . . . . . . . . . . . . . . .  16
   4.1.1.1  tbsCertificate  . . . . . . . . . . . . . . . . . .  16
   4.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  16
   4.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  16
   4.1.2  TBSCertificate  . . . . . . . . . . . . . . . . . . .  17
   4.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  17
   4.1.2.2  Serial number . . . . . . . . . . . . . . . . . . .  17
   4.1.2.3  Signature . . . . . . . . . . . . . . . . . . . . .  18
   4.1.2.4  Issuer  . . . . . . . . . . . . . . . . . . . . . .  18
   4.1.2.5  Validity  . . . . . . . . . . . . . . . . . . . . .  22
   4.1.2.5.1  UTCTime . . . . . . . . . . . . . . . . . . . . .  22
   4.1.2.5.2  GeneralizedTime . . . . . . . . . . . . . . . . .  22
   4.1.2.6  Subject . . . . . . . . . . . . . . . . . . . . . .  23
   4.1.2.7  Subject Public Key Info . . . . . . . . . . . . . .  24
   4.1.2.8  Unique Identifiers  . . . . . . . . . . . . . . . .  24
   4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . .  24
   4.2  Certificate Extensions  . . . . . . . . . . . . . . . .  24
   4.2.1  Standard Extensions . . . . . . . . . . . . . . . . .  25
   4.2.1.1  Authority Key Identifier  . . . . . . . . . . . . .  26
   4.2.1.2  Subject Key Identifier  . . . . . . . . . . . . . .  27
   4.2.1.3  Key Usage . . . . . . . . . . . . . . . . . . . . .  28
   4.2.1.4  Private Key Usage Period  . . . . . . . . . . . . .  29
   4.2.1.5  Certificate Policies  . . . . . . . . . . . . . . .  30
   4.2.1.6  Policy Mappings . . . . . . . . . . . . . . . . . .  33
   4.2.1.7  Subject Alternative Name  . . . . . . . . . . . . .  33
   4.2.1.8  Issuer Alternative Name . . . . . . . . . . . . . .  36
   4.2.1.9  Subject Directory Attributes  . . . . . . . . . . .  36
   4.2.1.10  Basic Constraints  . . . . . . . . . . . . . . . .  36
   4.2.1.11  Name Constraints . . . . . . . . . . . . . . . . .  37
   4.2.1.12  Policy Constraints . . . . . . . . . . . . . . . .  40
   4.2.1.13  Extended Key Usage . . . . . . . . . . . . . . . .  40
   4.2.1.14  CRL Distribution Points  . . . . . . . . . . . . .  42
   4.2.1.15  Inhibit Any-Policy . . . . . . . . . . . . . . . .  44
   4.2.1.16  Freshest CRL . . . . . . . . . . . . . . . . . . .  44
   4.2.2  Private Internet Extensions . . . . . . . . . . . . .  45
   4.2.2.1  Authority Information Access  . . . . . . . . . . .  45
   4.2.2.2  Subject Information Access  . . . . . . . . . . . .  46
   5  CRL and CRL Extensions Profile  . . . . . . . . . . . . .  48
   5.1  CRL Fields  . . . . . . . . . . . . . . . . . . . . . .  49
   5.1.1  CertificateList Fields  . . . . . . . . . . . . . . .  50
   5.1.1.1  tbsCertList . . . . . . . . . . . . . . . . . . . .  50

Top      ToC       Page 3 
   5.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  50
   5.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  51
   5.1.2  Certificate List "To Be Signed" . . . . . . . . . . .  51
   5.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  52
   5.1.2.2  Signature . . . . . . . . . . . . . . . . . . . . .  52
   5.1.2.3  Issuer Name . . . . . . . . . . . . . . . . . . . .  52
   5.1.2.4  This Update . . . . . . . . . . . . . . . . . . . .  52
   5.1.2.5  Next Update . . . . . . . . . . . . . . . . . . . .  53
   5.1.2.6  Revoked Certificates  . . . . . . . . . . . . . . .  53
   5.1.2.7  Extensions  . . . . . . . . . . . . . . . . . . . .  53
   5.2  CRL Extensions  . . . . . . . . . . . . . . . . . . . .  53
   5.2.1  Authority Key Identifier  . . . . . . . . . . . . . .  54
   5.2.2  Issuer Alternative Name . . . . . . . . . . . . . . .  54
   5.2.3  CRL Number  . . . . . . . . . . . . . . . . . . . . .  55
   5.2.4  Delta CRL Indicator . . . . . . . . . . . . . . . . .  55
   5.2.5  Issuing Distribution Point  . . . . . . . . . . . . .  58
   5.2.6  Freshest CRL  . . . . . . . . . . . . . . . . . . . .  59
   5.3  CRL Entry Extensions  . . . . . . . . . . . . . . . . .  60
   5.3.1  Reason Code . . . . . . . . . . . . . . . . . . . . .  60
   5.3.2  Hold Instruction Code . . . . . . . . . . . . . . . .  61
   5.3.3  Invalidity Date . . . . . . . . . . . . . . . . . . .  62
   5.3.4  Certificate Issuer  . . . . . . . . . . . . . . . . .  62
   6  Certificate Path Validation . . . . . . . . . . . . . . .  62
   6.1  Basic Path Validation . . . . . . . . . . . . . . . . .  63
   6.1.1  Inputs  . . . . . . . . . . . . . . . . . . . . . . .  66
   6.1.2  Initialization  . . . . . . . . . . . . . . . . . . .  67
   6.1.3  Basic Certificate Processing  . . . . . . . . . . . .  70
   6.1.4  Preparation for Certificate i+1 . . . . . . . . . . .  75
   6.1.5  Wrap-up procedure . . . . . . . . . . . . . . . . . .  78
   6.1.6  Outputs . . . . . . . . . . . . . . . . . . . . . . .  80
   6.2  Using the Path Validation Algorithm . . . . . . . . . .  80
   6.3  CRL Validation  . . . . . . . . . . . . . . . . . . . .  81
   6.3.1  Revocation Inputs . . . . . . . . . . . . . . . . . .  82
   6.3.2  Initialization and Revocation State Variables . . . .  82
   6.3.3  CRL Processing  . . . . . . . . . . . . . . . . . . .  83
   7  References  . . . . . . . . . . . . . . . . . . . . . . .  86
   8  Intellectual Property Rights  . . . . . . . . . . . . . .  88
   9  Security Considerations . . . . . . . . . . . . . . . . .  89
   Appendix A.  Pseudo-ASN.1 Structures and OIDs  . . . . . . .  92
   A.1 Explicitly Tagged Module, 1988 Syntax  . . . . . . . . .  92
   A.2 Implicitly Tagged Module, 1988 Syntax  . . . . . . . . . 105
   Appendix B.  ASN.1 Notes . . . . . . . . . . . . . . . . . . 112
   Appendix C.  Examples  . . . . . . . . . . . . . . . . . . . 115
   C.1  DSA Self-Signed Certificate . . . . . . . . . . . . . . 115
   C.2  End Entity Certificate Using DSA  . . . . . . . . . . . 119
   C.3  End Entity Certificate Using RSA  . . . . . . . . . . . 122
   C.4  Certificate Revocation List . . . . . . . . . . . . . . 126
   Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128

Top      ToC       Page 4 
   Full Copyright Statement . . . . . . . . . . . . . . . . . . 129

1  Introduction

   This specification is one part of a family of standards for the X.509
   Public Key Infrastructure (PKI) for the Internet.

   This specification profiles the format and semantics of certificates
   and certificate revocation lists (CRLs) for the Internet PKI.
   Procedures are described for processing of certification paths in the
   Internet environment.  Finally, ASN.1 modules are provided in the
   appendices for all data structures defined or referenced.

   Section 2 describes Internet PKI requirements, and the assumptions
   which affect the scope of this document.  Section 3 presents an
   architectural model and describes its relationship to previous IETF
   and ISO/IEC/ITU-T standards.  In particular, this document's
   relationship with the IETF PEM specifications and the ISO/IEC/ITU-T
   X.509 documents are described.

   Section 4 profiles the X.509 version 3 certificate, and section 5
   profiles the X.509 version 2 CRL.  The profiles include the
   identification of ISO/IEC/ITU-T and ANSI extensions which may be
   useful in the Internet PKI.  The profiles are presented in the 1988
   Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1
   syntax used in the most recent ISO/IEC/ITU-T standards.

   Section 6 includes certification path validation procedures.  These
   procedures are based upon the ISO/IEC/ITU-T definition.
   Implementations are REQUIRED to derive the same results but are not
   required to use the specified procedures.

   Procedures for identification and encoding of public key materials
   and digital signatures are defined in [PKIXALGS].  Implementations of
   this specification are not required to use any particular
   cryptographic algorithms.  However, conforming implementations which
   use the algorithms identified in [PKIXALGS] MUST identify and encode
   the public key materials and digital signatures as described in that
   specification.

   Finally, three appendices are provided to aid implementers.  Appendix
   A contains all ASN.1 structures defined or referenced within this
   specification.  As above, the material is presented in the 1988
   ASN.1.  Appendix B contains notes on less familiar features of the
   ASN.1 notation used within this specification.  Appendix C contains
   examples of a conforming certificate and a conforming CRL.

Top      ToC       Page 5 
   This specification obsoletes RFC 2459.  This specification differs
   from RFC 2459 in five basic areas:

      * To promote interoperable implementations, a detailed algorithm
      for certification path validation is included in section 6.1 of
      this specification; RFC 2459 provided only a high-level
      description of path validation.

      * An algorithm for determining the status of a certificate using
      CRLs is provided in section 6.3 of this specification.  This
      material was not present in RFC 2459.

      * To accommodate new usage models, detailed information describing
      the use of delta CRLs is provided in Section 5 of this
      specification.

      * Identification and encoding of public key materials and digital
      signatures are not included in this specification, but are now
      described in a companion specification [PKIXALGS].

      * Four additional extensions are specified: three certificate
      extensions and one CRL extension.  The certificate extensions are
      subject info access, inhibit any-policy, and freshest CRL.  The
      freshest CRL extension is also defined as a CRL extension.

      * Throughout the specification, clarifications have been
      introduced to enhance consistency with the ITU-T X.509
      specification.  X.509 defines the certificate and CRL format as
      well as many of the extensions that appear in this specification.
      These changes were introduced to improve the likelihood of
      interoperability between implementations based on this
      specification with implementations based on the ITU-T
      specification.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2  Requirements and Assumptions

   The goal of this specification is to develop a profile to facilitate
   the use of X.509 certificates within Internet applications for those
   communities wishing to make use of X.509 technology.  Such
   applications may include WWW, electronic mail, user authentication,
   and IPsec.  In order to relieve some of the obstacles to using X.509

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
   +---+
   | 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

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
   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:

Top      ToC       Page 11 
      (a)  a pure top-down hierarchy, with all certification paths
      starting from IPRA;

      (b)  a naming subordination rule restricting the names of a CA's
      subjects; and

      (c)  use of the PCA concept, which requires knowledge of
      individual PCAs to be built into certificate chain verification
      logic.  Knowledge of individual PCAs was required to determine if
      a chain could be accepted.

   With X.509 v3, most of the requirements addressed by RFC 1422 can be
   addressed using certificate extensions, without a need to restrict
   the CA structures used.  In particular, the certificate extensions
   relating to certificate policies obviate the need for PCAs and the
   constraint extensions obviate the need for the name subordination
   rule.  As a result, this document supports a more flexible
   architecture, including:

      (a)  Certification paths start with a public key of a CA in a
      user's own domain, or with the public key of the top of a
      hierarchy.  Starting with the public key of a CA in a user's own
      domain has certain advantages.  In some environments, the local
      domain is the most trusted.

      (b)  Name constraints may be imposed through explicit inclusion of
      a name constraints extension in a certificate, but are not
      required.

      (c)  Policy extensions and policy mappings replace the PCA
      concept, which permits a greater degree of automation.  The
      application can determine if the certification path is acceptable
      based on the contents of the certificates instead of a priori
      knowledge of PCAs.  This permits automation of certification path
      processing.

3.3  Revocation

   When a certificate is issued, it is expected to be in use for its
   entire validity period.  However, various circumstances may cause a
   certificate to become invalid prior to the expiration of the validity
   period.  Such circumstances include change of name, change of
   association between subject and CA (e.g., an employee terminates
   employment with an organization), and compromise or suspected
   compromise of the corresponding private key.  Under such
   circumstances, the CA needs to revoke the certificate.

Top      ToC       Page 12 
   X.509 defines one method of certificate revocation.  This method
   involves each CA periodically issuing a signed data structure called
   a certificate revocation list (CRL).  A CRL is a time stamped list
   identifying revoked certificates which is signed by a CA or CRL
   issuer and made freely available in a public repository.  Each
   revoked certificate is identified in a CRL by its certificate serial
   number.  When a certificate-using system uses a certificate (e.g.,
   for verifying a remote user's digital signature), that system not
   only checks the certificate signature and validity but also acquires
   a suitably-recent CRL and checks that the certificate serial number
   is not on that CRL.  The meaning of "suitably-recent" may vary with
   local policy, but it usually means the most recently-issued CRL.  A
   new CRL is issued on a regular periodic basis (e.g., hourly, daily,
   or weekly).  An entry is added to the CRL as part of the next update
   following notification of revocation.  An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

   An advantage of this revocation method is that CRLs may be
   distributed by exactly the same means as certificates themselves,
   namely, via untrusted servers and untrusted communications.

   One limitation of the CRL revocation method, using untrusted
   communications and servers, is that the time granularity of
   revocation is limited to the CRL issue period.  For example, if a
   revocation is reported now, that revocation will not be reliably
   notified to certificate-using systems until all currently issued CRLs
   are updated -- this may be up to one hour, one day, or one week
   depending on the frequency that CRLs are issued.

   As with the X.509 v3 certificate format, in order to facilitate
   interoperable implementations from multiple vendors, the X.509 v2 CRL
   format needs to be profiled for Internet use.  It is one goal of this
   document to specify that profile.  However, this profile does not
   require the issuance of CRLs.  Message formats and protocols
   supporting on-line revocation notification are defined in other PKIX
   specifications.  On-line methods of revocation notification may be
   applicable in some environments as an alternative to the X.509 CRL.
   On-line revocation checking may significantly reduce the latency
   between a revocation report and the distribution of the information
   to relying parties.  Once the CA accepts a revocation report as
   authentic and valid, any query to the on-line service will correctly
   reflect the certificate validation impacts of the revocation.
   However, these methods impose new security requirements: the
   certificate validator needs to trust the on-line validation service
   while the repository does not need to be trusted.

Top      ToC       Page 13 
3.4  Operational Protocols

   Operational protocols are required to deliver certificates and CRLs
   (or status information) to certificate using client systems.
   Provisions are needed for a variety of different means of certificate
   and CRL delivery, including distribution procedures based on LDAP,
   HTTP, FTP, and X.500.  Operational protocols supporting these
   functions are defined in other PKIX specifications.  These
   specifications may include definitions of message formats and
   procedures for supporting all of the above operational environments,
   including definitions of or references to appropriate MIME content
   types.

3.5  Management Protocols

   Management protocols are required to support on-line interactions
   between PKI user and management entities.  For example, a management
   protocol might be used between a CA and a client system with which a
   key pair is associated, or between two CAs which cross-certify each
   other.  The set of functions which potentially need to be supported
   by management protocols include:

      (a)  registration:  This is the process whereby a user first makes
      itself known to a CA (directly, or through an RA), prior to that
      CA issuing  a certificate or certificates for that user.

      (b)  initialization:  Before a client system can operate securely
      it is necessary to install key materials which have the
      appropriate relationship with keys stored elsewhere in the
      infrastructure.  For example, the client needs to be securely
      initialized with the public key and other assured information of
      the trusted CA(s), to be used in validating certificate paths.

      Furthermore, a client typically needs to be initialized with its
      own key pair(s).

      (c)  certification:  This is the process in which a CA issues a
      certificate for a user's public key, and returns that certificate
      to the user's client system and/or posts that certificate in a
      repository.

      (d)  key pair recovery:  As an option, user client key materials
      (e.g., a user's private key used for encryption purposes) may be
      backed up by a CA or a key backup system.  If a user needs to
      recover these backed up key materials (e.g., as a result of a
      forgotten password or a lost key chain file), an on-line protocol
      exchange may be needed to support such recovery.

Top      ToC       Page 14 
      (e)  key pair update:  All key pairs need to be updated regularly,
      i.e., replaced with a new key pair, and new certificates issued.

      (f)  revocation request:  An authorized person advises a CA of an
      abnormal situation requiring certificate revocation.

      (g)  cross-certification:  Two CAs exchange information used in
      establishing a cross-certificate.  A cross-certificate is a
      certificate issued by one CA to another CA which contains a CA
      signature key used for issuing certificates.

   Note that on-line protocols are not the only way of implementing the
   above functions.  For all functions there are off-line methods of
   achieving the same result, and this specification does not mandate
   use of on-line protocols.  For example, when hardware tokens are
   used, many of the functions may be achieved as part of the physical
   token delivery.  Furthermore, some of the above functions may be
   combined into one protocol exchange.  In particular, two or more of
   the registration, initialization, and certification functions can be
   combined into one protocol exchange.

   The PKIX series of specifications defines a set of standard message
   formats supporting the above functions.  The protocols for conveying
   these messages in different environments (e.g., e-mail, file
   transfer, and WWW) are described in those specifications.



(page 14 continued on part 2)

Next RFC Part