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   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.Housley, et. al.            Standards Track                     [Page 6]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999   This profile does not assume the deployment of an X.500 Directory   system.  The profile does not prohibit the use of an X.500 Directory,   but other 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.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 shall   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.Housley, et. al.            Standards Track                     [Page 7]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999       +---+       | C |                       +------------+       | e | <-------------------->| End entity |       | r |       Operational     +------------+       | t |       transactions          ^       |   |      and management         |  Management       | / |       transactions          |  transactions       |   |                             |                PKI users       | C |                             v       | R |       -------------------+--+-----------+----------------       | L |                          ^              ^       |   |                          |              |  PKI management       |   |                          v              |      entities       | R |                       +------+          |       | e | <---------------------| RA   | <---+    |       | p |  Publish certificate  +------+     |    |       | o |                                    |    |       | s |                                    |    |       | I |                                    v    v       | t |                                +------------+       | o | <------------------------------|     CA     |       | r |   Publish certificate          +------------+       | y |   Publish CRL                         ^       |   |                                       |       +---+                        Management     |                                    transactions   |                                                   v                                               +------+                                               |  CA  |                                               +------+                          Figure 1 - PKI Entities   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;   repository:  a system or collection of distributed systems that                store certificates and CRLs and serves as a means of                distributing these certificates and CRLs to end                entities.Housley, et. al.            Standards Track                     [Page 8]RFC 2459        Internet X.509 Public Key Infrastructure    January 19993.1  X.509 Version 3 Certificate   Users of a public key shall be confident 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 posession 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   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/ITU 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. These two fields may be used   to support directory access control.   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 has proven necessary.  In response to these new   requirements, ISO/IEC/ITU 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 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.Housley, et. al.            Standards Track                     [Page 9]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999   However, the ISO/IEC/ITU 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   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.Housley, et. al.            Standards Track                    [Page 10]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999      (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