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:      (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 may 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.Housley, et. al.            Standards Track                    [Page 11]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999      (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 certificate chain      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.   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 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 CA   issues a new CRL 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 may be removed from   the CRL after appearing 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 communications and server systems.   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 reliablyHousley, et. al.            Standards Track                    [Page 12]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999   notified to certificate-using systems until the next periodic CRL is   issued -- this may be up to one hour, one day, or one week depending   on the frequency that the CA issues CRLs.   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 CAs to issue CRLs. Message formats and protocols supporting   on-line revocation notification may be 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 the 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   shall trust the on-line validation service while the repository does   not need to be trusted.3.4  Operational Protocols   Operational protocols are required to deliver certificates and CRLs   (or status information) to certificate using client systems.   Provision is 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.Housley, et. al.            Standards Track                    [Page 13]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999      (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.      (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 may define a set of standard   message formats supporting the above functions in future   specifications.  In that case, the protocols for conveying these   messages in different environments (e.g., on-line, file transfer, e-   mail, and WWW) will also be described in those specifications.Housley, et. al.            Standards Track                    [Page 14]RFC 2459        Internet X.509 Public Key Infrastructure    January 19994  Certificate and Certificate Extensions Profile   This section presents a profile for public key certificates that will   foster interoperability and a reusable PKI.  This section is based   upon the X.509 v3 certificate format and the standard certificate   extensions defined in [X.509].  The ISO/IEC/ITU documents use the   1993 version of ASN.1; while this document uses the 1988 ASN.1   syntax, the encoded certificate and standard extensions are   equivalent.  This section also defines private extensions required to   support a PKI for the Internet community.   Certificates may be used in a wide range of applications and   environments covering a broad spectrum of interoperability goals and   a broader spectrum of operational and assurance requirements.  The   goal of this document is to establish a common baseline for generic   applications requiring broad interoperability and limited special   purpose requirements.  In particular, the emphasis will be on   supporting the use of X.509 v3 certificates for informal Internet   electronic mail, IPsec, and WWW applications.4.1  Basic Certificate Fields   The X.509 v3 certificate basic syntax is as follows.  For signature   calculation, the certificate is encoded using the ASN.1 distinguished   encoding rules (DER) [X.208].  ASN.1 DER encoding is a tag, length,   value encoding system for each element.   Certificate  ::=  SEQUENCE  {        tbsCertificate       TBSCertificate,        signatureAlgorithm   AlgorithmIdentifier,        signatureValue       BIT STRING  }   TBSCertificate  ::=  SEQUENCE  {        version         [0]  EXPLICIT Version DEFAULT v1,        serialNumber         CertificateSerialNumber,        signature            AlgorithmIdentifier,        issuer               Name,        validity             Validity,        subject              Name,        subjectPublicKeyInfo SubjectPublicKeyInfo,        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,                             -- If present, version shall be v2 or v3        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,                             -- If present, version shall be v2 or v3        extensions      [3]  EXPLICIT Extensions OPTIONAL                             -- If present, version shall be v3        }Housley, et. al.            Standards Track                    [Page 15]RFC 2459        Internet X.509 Public Key Infrastructure    January 1999   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }   CertificateSerialNumber  ::=  INTEGER   Validity ::= SEQUENCE {        notBefore      Time,        notAfter       Time }   Time ::= CHOICE {        utcTime        UTCTime,        generalTime    GeneralizedTime }   UniqueIdentifier  ::=  BIT STRING   SubjectPublicKeyInfo  ::=  SEQUENCE  {        algorithm            AlgorithmIdentifier,        subjectPublicKey     BIT STRING  }   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension   Extension  ::=  SEQUENCE  {