X.509 specification

   http://www.ietf.org/rfc/rfc2459.txt

 

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.

 

 

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.

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 reliably

   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.


4.2.1.14  CRL Distribution Points
The CRL distribution points extension identifies how CRL information
   is obtained.  The extension SHOULD be non-critical, but this profile
   recommends support for this extension by CAs and applications.
   Further discussion of CRL management is contained in section 5.

If the cRLDistributionPoints extension contains a
   DistributionPointName of type URI, the following semantics MUST be
   assumed: the URI is a pointer to the current CRL for the associated
   reasons and will be issued by the associated cRLIssuer.  The expected
   values for the URI are those defined in 4.2.1.7. Processing rules for
   other values are not defined by this specification.  If the
   distributionPoint omits reasons, the CRL MUST include revocations for
   all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST
   be issued by the CA that issued the certificate.

   id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }

   cRLDistributionPoints ::= {
        CRLDistPointsSyntax }

   CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

   DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName OPTIONAL,
        reasons                 [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL }

   DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

   ReasonFlags ::= BIT STRING {
        unused                  (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6) }


5  CRL and CRL Extensions Profile

   As described above, one goal of this X.509 v2 CRL profile is to
   foster the creation of an interoperable and reusable Internet PKI.
   To achieve this goal, guidelines for the use of extensions are
   specified, and some assumptions are made about the nature of
   information included in the CRL.

   CRLs may be used in a wide range of applications and environments
   covering a broad spectrum of interoperability goals and an even
   broader spectrum of operational and assurance requirements.  This
   profile establishes a common baseline for generic applications
   requiring broad interoperability.  The profile defines a baseline set
   of information that can be expected in every CRL.  Also, the profile
   defines common locations within the CRL for frequently used
   attributes as well as common representations for these attributes.

   This profile does not define any private Internet CRL extensions or
   CRL entry extensions.

   Environments with additional or special purpose requirements may
   build on this profile or may replace it.

   Conforming CAs are not required to issue CRLs if other revocation or
   certificate status mechanisms are provided.  Conforming CAs that
   issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date
   by which the next CRL will be issued in the nextUpdate field (see


 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the
   authority key identifier extension (see sec. 5.2.1).  Conforming
   applications are required to process version 1 and 2 CRLs.

5.1  CRL Fields

   The X.509 v2 CRL syntax is as follows.  For signature calculation,
   the data that is to be signed is ASN.1 DER encoded.  ASN.1 DER
   encoding is a tag, length, value encoding system for each element.

   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, shall be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                           -- if present, shall be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                           -- if present, shall be v2
                                  }

   -- Version, Time, CertificateSerialNumber, and Extensions
   -- are all defined in the ASN.1 in section 4.1

   -- AlgorithmIdentifier is defined in section 4.1.1.2

   The following items describe the use of the X.509 v2 CRL in the
   Internet PKI.

5.1.1  CertificateList Fields

   The CertificateList is a SEQUENCE of three required fields. The
   fields are described in detail in the following subsections.

5.1.1.1  tbsCertList

   The first field in the sequence is the tbsCertList.  This field is
   itself a sequence containing the name of the issuer, issue date,
   issue date of the next list, the list of revoked certificates, and
   optional CRL extensions.  Further, each entry on the revoked
   certificate list is defined by a sequence of user certificate serial
   number, revocation date, and optional CRL entry extensions.

5.1.1.2  signatureAlgorithm

   The signatureAlgorithm field contains the algorithm identifier for
   the algorithm used by the CA to sign the CertificateList.  The field
   is of type AlgorithmIdentifier, which is defined in section 4.1.1.2.
   Section 7.2 lists the supported algorithms for this specification.
   Conforming CAs MUST use the algorithm identifiers presented in
   section 7.2 when signing with a supported signature algorithm.

   This field MUST contain the same algorithm identifier as the
   signature field in the sequence tbsCertList (see sec. 5.1.2.2).

5.1.1.3  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
   is used as the input to the signature function. This signature value
   is then ASN.1 encoded as a BIT STRING and included in the CRL's
   signatureValue field. The details of this process are specified for
   each of the supported algorithms in section 7.2.

5.1.2  Certificate List "To Be Signed"

   The certificate list to be signed, or TBSCertList, is a SEQUENCE of
   required and optional fields.  The required fields identify the CRL
   issuer, the algorithm used to sign the CRL, the date and time the CRL
   was issued, and the date and time by which the CA will issue the next
   CRL.

   Optional fields include lists of revoked certificates and CRL
   extensions.  The revoked certificate list is optional to support the
   case where a CA has not revoked any unexpired certificates that it
   has issued.  The profile requires conforming CAs to use the CRL
   extension cRLNumber in all CRLs issued.

5.1.2.1  Version

   This optional field describes the version of the encoded CRL.  When
   extensions are used, as required by this profile, this field MUST be
   present and MUST specify version 2 (the integer value is 1).

5.1.2.2  Signature

   This field contains the algorithm identifier for the algorithm used
   to sign the CRL.  Section 7.2 lists OIDs for the most popular
   signature algorithms used in the Internet PKI.

   This field MUST contain the same algorithm identifier as the
   signatureAlgorithm field in the sequence CertificateList (see section
   5.1.1.2).

5.1.2.3  Issuer Name

   The issuer name identifies the entity who has signed and issued the
   CRL.  The issuer identity is carried in the issuer name field.
   Alternative name forms may also appear in the issuerAltName extension
   (see sec. 5.2.2).  The issuer name field MUST contain an X.500
   distinguished name (DN).  The issuer name field is defined as the
   X.501 type Name, and MUST follow the encoding rules for the issuer
   name field in the certificate (see sec. 4.1.2.4).

5.1.2.4  This Update

   This field indicates the issue date of this CRL. ThisUpdate may be
   encoded as UTCTime or GeneralizedTime.

   CAs conforming to this profile that issue CRLs MUST encode thisUpdate
   as UTCTime for dates through the year 2049. CAs conforming to this
   profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for
   dates in the year 2050 or later.

   Where encoded as UTCTime, thisUpdate MUST be specified and
   interpreted as defined in section 4.1.2.5.1.  Where encoded as
   GeneralizedTime, thisUpdate MUST be specified and interpreted as
   defined in section 4.1.2.5.2.

 

4.1.2.5.1  UTCTime

   The universal time type, UTCTime, is a standard ASN.1 type intended
   for international applications where local time alone is not
   adequate.  UTCTime specifies the year through the two low order
   digits and time is specified to the precision of one minute or one
   second.  UTCTime includes either Z (for Zulu, or Greenwich Mean Time)
   or a time differential.

   For the purposes of this profile, UTCTime values MUST be expressed
   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
   systems MUST interpret the year field (YY) as follows:

      Where YY is greater than or equal to 50, the year shall be
      interpreted as 19YY; and

      Where YY is less than 50, the year shall be interpreted as 20YY.

4.1.2.5.2  GeneralizedTime

   The generalized time type, GeneralizedTime, is a standard ASN.1 type
   for variable precision representation of time.  Optionally, the
   GeneralizedTime field can include a representation of the time
   differential between local and Greenwich Mean Time.

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
   times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
   GeneralizedTime values MUST NOT include fractional seconds.



5.1.2.5  Next Update

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date. CAs SHOULD issue
   CRLs with a nextUpdate time equal to or later than all previous CRLs.
   nextUpdate may be encoded as UTCTime or GeneralizedTime.
   This profile requires inclusion of nextUpdate in all CRLs issued by
   conforming CAs. Note that the ASN.1 syntax of TBSCertList describes
   this field as OPTIONAL, which is consistent with the ASN.1 structure
   defined in [X.509]. The behavior of clients processing CRLs which
   omit nextUpdate is not specified by this profile.

   CAs conforming to this profile that issue CRLs MUST encode nextUpdate
   as UTCTime for dates through the year 2049. CAs conforming to this
   profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for
   dates in the year 2050 or later.

   Where encoded as UTCTime, nextUpdate MUST be specified and
   interpreted as defined in section 4.1.2.5.1.  Where encoded as
   GeneralizedTime, nextUpdate MUST be specified and interpreted as
   defined in section 4.1.2.5.2.

5.1.2.6  Revoked Certificates

   Revoked certificates are listed.  The revoked certificates are named
   by their serial numbers.  Certificates revoked by the CA are uniquely
   identified by the certificate serial number.  The date on which the
   revocation occurred is specified.  The time for revocationDate MUST
   be expressed as described in section 5.1.2.4. Additional information
   may be supplied in CRL entry extensions; CRL entry extensions are
   discussed in section 5.3.

5.1.2.7  Extensions

   This field may only appear if the version is 2 (see sec. 5.1.2.1).
   If present, this field is a SEQUENCE of one or more CRL extensions.
   CRL extensions are discussed in section 5.2.

5.2  CRL Extensions

   The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs
   [X.509] [X9.55] provide methods for associating additional attributes
   with CRLs.  The X.509 v2 CRL format also allows communities to define
   private extensions to carry information unique to those communities.
   Each extension in a CRL may be designated as critical or non-
   critical.  A CRL validation MUST fail if it encounters a critical
   extension which it does not know how to process.  However, an
   unrecognized non-critical extension may be ignored.  The following
   subsections present those extensions used within Internet CRLs.
   Communities may elect to include extensions in CRLs which are not
   defined in this specification. However, caution should be exercised
   in adopting any critical extensions in CRLs which might be used in a
   general context.


   Conforming CAs that issue CRLs are required to include the authority
   key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3)
   extensions in all CRLs issued.

5.2.1  Authority Key Identifier

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a CRL.  The identification can be based on either the key
   identifier (the subject key identifier in the CRL signer's
   certificate) or on the issuer name and serial number. This extension
   is especially useful where an issuer has more than one signing key,
   either due to multiple concurrent key pairs or due to changeover.

   Conforming CAs MUST use the key identifier method, and MUST include
   this extension in all CRLs issued.

   The syntax for this CRL extension is defined in section 4.2.1.1.

5.2.2  Issuer Alternative Name

   The issuer alternative names extension allows additional identities
   to be associated with the issuer of the CRL.  Defined options include
   an rfc822 name (electronic mail address), a DNS name, an IP address,
   and a URI.  Multiple instances of a name and multiple name forms may
   be included.  Whenever such identities are used, the issuer
   alternative name extension MUST be used.

   The issuerAltName extension SHOULD NOT be marked critical.

   The OID and syntax for this CRL extension are defined in section
   4.2.1.8.

5.2.3  CRL Number

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
   This extension allows users to easily determine when a particular CRL
   supersedes another CRL.  CAs conforming to this profile MUST include
   this extension in all CRLs.

   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   cRLNumber ::= INTEGER (0..MAX)

5.2.4  Delta CRL Indicator

   The delta CRL indicator is a critical CRL extension that identifies a
   delta-CRL.  The use of delta-CRLs can significantly improve
   processing time for applications which store revocation information
   in a format other than the CRL structure.  This allows changes to be
   added to the local database while ignoring unchanged information that
   is already in the local database.

   When a delta-CRL is issued, the CAs MUST also issue a complete CRL.

   The value of BaseCRLNumber identifies the CRL number of the base CRL
   that was used as the starting point in the generation of this delta-
   CRL.  The delta-CRL contains the changes between the base CRL and the
   current CRL issued along with the delta-CRL.  It is the decision of a
   CA as to whether to provide delta-CRLs.  Again, a delta-CRL MUST NOT
   be issued without a corresponding complete CRL.  The value of
   CRLNumber for both the delta-CRL and the corresponding complete CRL
   MUST be identical.

   A CRL user constructing a locally held CRL from delta-CRLs MUST
   consider the constructed CRL incomplete and unusable if the CRLNumber
   of the received delta-CRL is more than one greater than the CRLnumber
   of the delta-CRL last processed.

   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

   deltaCRLIndicator ::= BaseCRLNumber

   BaseCRLNumber ::= CRLNumber

5.2.5  Issuing Distribution Point

   The issuing distribution point is a critical CRL extension that
   identifies the CRL distribution point for a particular CRL, and it
   indicates whether the CRL covers revocation for end entity
   certificates only, CA  certificates only, or a limitied set of reason
   codes.  Although the extension is critical, conforming
   implementations are not required to support this extension.

   The CRL is signed using the CA's private key.  CRL Distribution
   Points do not have their own key pairs.  If the CRL is stored in the
   X.500 Directory, it is stored in the Directory entry corresponding to
   the CRL distribution point, which may be different than the Directory
   entry of the CA.

   The reason codes associated with a distribution point shall be
   specified in onlySomeReasons. If onlySomeReasons does not appear, the
   distribution point shall contain revocations for all reason codes.
   CAs may use CRL distribution points to partition the CRL on the basis
   of compromise and routine revocation.  In this case, the revocations
   with reason code keyCompromise (1) and cACompromise (2) appear in one
   distribution point, and the revocations with other reason codes
   appear in another distribution point.

   Where the issuingDistributionPoint extension contains a URL, the
   following semantics MUST be assumed: the object is a pointer to the
   most current CRL issued by this CA.  The URI schemes ftp, http,
   mailto [RFC1738] and ldap [RFC1778] are defined for this purpose.
   The URI MUST be an absolute, not relative, pathname and MUST specify
   the host.

   id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

   issuingDistributionPoint ::= SEQUENCE {
        distributionPoint       [0] DistributionPointName OPTIONAL,
        onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons         [3] ReasonFlags OPTIONAL,
        indirectCRL             [4] BOOLEAN DEFAULT FALSE }

5.3  CRL Entry Extensions

   The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU
   for X.509 v2 CRLs provide methods for associating additional
   attributes with CRL entries [X.509] [X9.55].  The X.509 v2 CRL format
   also allows communities to define private CRL entry extensions to
   carry information unique to those communities.  Each extension in a
   CRL entry may be designated as critical or non-critical.  A CRL
   validation MUST fail if it encounters a critical CRL entry extension
   which it does not know how to process.  However, an unrecognized
   non-critical CRL entry extension may be ignored.  The following
   subsections present recommended extensions used within Internet CRL
   entries and standard locations for information.  Communities may
   elect to use additional CRL entry extensions; however, caution should
   be exercised in adopting any critical extensions in CRL entries which
   might be used in a general context.

   All CRL entry extensions used in this specification are non-critical.
   Support for these extensions is optional for conforming CAs and
   applications.  However, CAs that issue CRLs SHOULD include reason
   codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever
   this information is available.
5.3.1  Reason Code

   The reasonCode is a non-critical CRL entry extension that identifies
   the reason for the certificate revocation. CAs are strongly
   encouraged to include meaningful reason codes in CRL entries;
   however, the reason code CRL entry extension SHOULD be absent instead
   of using the unspecified (0) reasonCode value.

   id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }

   -- reasonCode ::= { CRLReason }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
        removeFromCRL           (8) }

5.3.2  Hold Instruction Code

   The hold instruction code is a non-critical CRL entry extension that
   provides a registered instruction identifier which indicates the
   action to be taken after encountering a certificate that has been
   placed on hold.

   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

   holdInstructionCode ::= OBJECT IDENTIFIER

   The following instruction codes have been defined.  Conforming
   applications that process this extension MUST recognize the following
   instruction codes.

   holdInstruction    OBJECT IDENTIFIER ::=
                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }

   id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
   id-holdinstruction-callissuer
                             OBJECT IDENTIFIER ::= {holdInstruction 2}
   id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

   Conforming applications which encounter an id-holdinstruction-
   callissuer MUST call the certificate issuer or reject the
   certificate.  Conforming applications which encounter an id-



holdinstruction-reject MUST reject the certificate. The hold
   instruction id-holdinstruction-none is semantically equivalent to the
   absence of a holdInstructionCode, and its use is strongly deprecated
   for the Internet PKI.

5.3.3  Invalidity Date

   The invalidity date is a non-critical CRL entry extension that
   provides the date on which it is known or suspected that the private
   key was compromised or that the certificate otherwise became invalid.
   This date may be earlier than the revocation date in the CRL entry,
   which is the date at which the CA processed the revocation. When a
   revocation is first posted by a CA in a CRL, the invalidity date may
   precede the date of issue of earlier CRLs, but the revocation date
   SHOULD NOT precede the date of issue of earlier CRLs.  Whenever this
   information is available, CAs are strongly encouraged to share it
   with CRL users.

   The GeneralizedTime values included in this field MUST be expressed
   in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
   as defined in section 4.1.2.5.2.

   id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }

   invalidityDate ::=  GeneralizedTime

5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
   indicator set in its issuing distribution point extension. If this
   extension is not present on the first entry in an indirect CRL, the
   certificate issuer defaults to the CRL issuer. On subsequent entries
   in an indirect CRL, if this extension is not present, the certificate
   issuer for the entry is the same as that for the preceding entry.
   This field is defined as follows:

   id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }

   certificateIssuer ::=     GeneralNames

   If used by conforming CAs that issue CRLs, this extension is always
   critical.  If an implementation ignored this extension it could not
   correctly attribute CRL entries to certificates.  This specification
   RECOMMENDS that implementations recognize this extension.

6  Certification Path Validation

   Certification path validation procedures for the Internet PKI are
   based on section 12.4.3 of [X.509].  Certification path processing
   verifies the binding between the subject distinguished name and/or
   subject alternative name and subject public key.  The binding is
   limited by constraints which are specified in the certificates which
   comprise the path. The basic constraints and policy constraints
   extensions allow the certification path processing logic to automate
   the decision making process.

   This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST be functionally
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result.

   In section 6.1, the text describes basic path validation. This text
   assumes that all valid paths begin with certificates issued by a
   single "most-trusted CA". The algorithm requires the public key of
   the CA, the CA's name, the validity period of the public key, and any
   constraints upon the set of paths which may be validated using this
   key.

   The "most-trusted CA" is a matter of policy: it could be a root CA in
   a hierarchical PKI; the CA that issued the verifier's own
   certificate(s); or any other CA in a network PKI.  The path
   validation procedure is the same regardless of the choice of "most-
   trusted CA."

   section 6.2 describes extensions to the basic path validation
   algorithm. Two specific cases are discussed: the case where paths may
   begin with one of several trusted CAs; and where compatibility with
   the PEM architecture is required.

6.1 Basic Path Validation

   The text assumes that the trusted public key (and related
   information) is contained in a "self-signed" certificate. This
   simplifies the description of the path processing procedure.  Note
   that the signature on the self-signed certificate does not provide
   any security services.  The trusted public key (and related
   information) may be obtained in other formats; the information is
   trusted because of other procedures used to obtain and protect it.
The goal of path validation is to verify the binding between a
   subject distinguished name or subject alternative name and subject
   public key, as represented in the "end entity" certificate, based on
   the public key of the "most-trusted CA".  This requires obtaining a
   sequence of certificates that support that binding.  The procedures
   performed to obtain this sequence is outside the scope of this
   section.

   The following text also assumes that certificates do not use subject
   or unique identifier fields or private critical extensions, as
   recommended within this profile.  However, if these components appear
   in certificates, they MUST be processed.  Finally, policy qualifiers
   are also neglected for the sake of clarity.

   A certification path is a sequence of n certificates where:

      * for all x in {1,(n-1)}, the subject of certificate x is the
      issuer of certificate x+1.
      * certificate x=1 is the the self-signed certificate, and
      * certificate x=n is the end entity certificate.

   This section assumes the following inputs are provided to the path
   processing logic:

      (a)  a certification path of length n;

      (b)  a set of initial policy identifiers (each comprising a
      sequence of policy element identifiers), which identifies one or
      more certificate policies, any one of which would be acceptable
      for the purposes of certification path processing, or the special
      value "any-policy";

      (c)  the current date/time (if not available internally to the
      certification path processing module); and

      (d)  the time, T, for which the validity of the path should be
      determined.  (This may be the current date/time, or some point in
      the past.)

   From the inputs, the procedure intializes five state variables:

      (a)  acceptable policy set:  A set of certificate policy
      identifiers comprising the policy or policies recognized by the
      public key user together with policies deemed equivalent through
      policy mapping. The initial value of the acceptable policy set is
      the special value "any-policy".

      (b)  constrained subtrees:  A set of root names defining a set of
      subtrees within which all subject names in subsequent certificates
      in the certification path shall fall. The initial value is
      "unbounded".

      (c)  excluded subtrees:  A set of root names defining a set of
      subtrees within which no subject name in subsequent certificates
      in the certification path may fall. The initial value is "empty".

      (d)  explicit policy: an integer which indicates if an explicit
      policy identifier is required. The integer indicates the first
      certificate in the path where this requirement is imposed. Once
      set, this variable may be decreased, but may not be increased.
      (That is, if a certificate in the path requires explicit policy
      identifiers, a later certificate can not remove this requirement.)
      The initial value is n+1.

      (e)  policy mapping: an integer which indicates if policy mapping
      is permitted.  The integer indicates the last certificate on which
      policy mapping may be applied.  Once set, this variable may be
      decreased, but may not be increased. (That is, if a certificate in
      the path specifies policy mapping is not permitted, it can not be
      overriden by a later certificate.) The initial value is n+1.

   The actions performed by the path processing software for each
   certificate i=1 through n are described below.  The self-signed
   certificate is certificate i=1, the end entity certificate is i=n.
   The processing is performed sequentially, so that processing
   certificate i affects the state variables for processing certificate
   (i+1). Note that actions (h) through (m) are not applied to the end
   entity certificate (certificate n).

   The path processing actions to be performed are:

      (a)  Verify the basic certificate information, including:

         (1) the certificate was signed using the subject public key
         from certificate i-1 (in the special case i=1, this step may be
         omitted; if not, use the subject public key from the same
         certificate),

         (2) the certificate validity period includes time T,

         (3) the certificate had not been revoked at time T and is not
         currently on hold status that commenced before time T, (this
         may be determined by obtaining the appropriate CRL or status
         information, or by out-of-band mechanisms), and

         (4) the subject and issuer names chain correctly (that is, the
         issuer of this certificate was the subject of the previous
         certificate.)

      (b)  Verify that the subject name and subjectAltName extension
      (critical or noncritical) is consistent with the constrained
      subtrees state variables.

      (c)  Verify that the subject name and subjectAltName extension
      (critical or noncritical) is consistent with the excluded subtrees
      state variables.

      (d)  Verify that policy information is consistent with the initial
      policy set:

         (1) if the explicit policy state variable is less than or equal
         to i, a policy identifier in the certificate shall be in the
         initial policy set; and

         (2) if the policy mapping variable is less than or equal to i,
         the policy identifier may not be mapped.

      (e)  Verify that policy information is consistent with the
      acceptable policy set:

         (1) if the certificate policies extension is marked critical,
         the intersection of the policies extension and the acceptable
         policy set shall be non-null;

         (2) the acceptable policy set is assigned the resulting
         intersection as its new value.

      (g) Verify that the intersection of the acceptable policy set and
      the initial policy set is non-null.

      (h)  Recognize and process any other critical extension present in
      the certificate.

      (i) Verify that the certificate is a CA certificate (as specified
      in a basicConstraints extension or as verified out-of-band).

      (j)  If permittedSubtrees is present in the certificate, set the
      constrained subtrees state variable to the intersection of its
      previous value and the value indicated in the extension field.

      (k)  If excludedSubtrees is present in the certificate, set the
      excluded subtrees state variable to the union of its previous
      value and the value indicated in the extension field.
      (l)  If a policy constraints extension is included in the
      certificate, modify the explicit policy and policy mapping state
      variables as follows:

         (1) If requireExplicitPolicy is present and has value r, the
         explicit policy state variable is set to the minimum of its
         current value and the sum of r and i (the current certificate
         in the sequence).

         (2) If inhibitPolicyMapping is present and has value q, the
         policy mapping state variable is set to the minimum of its
         current value and the sum of q and i (the current certificate
         in the sequence).

      (m) If a key usage extension is marked critical, ensure the
      keyCertSign bit is set.

   If any one of the above checks fail, the procedure terminates,
   returning a failure indication and an appropriate reason.  If none of
   the above checks fail on the end-entity certificate, the procedure
   terminates, returning a success indication together with the set of
   all policy qualifier values encountered in the set of certificates.

6.2 Extending Path Validation

   The path validation algorithm presented in 6.1 is based on several
   simplifying assumptions (e.g., a single trusted CA that starts all
   valid paths). This algorithm may be extended for cases where the
   assumptions do not hold.

   This procedure may be extended for multiple trusted CAs by providing
   a set of self-signed certificates to the validation module.  In this
   case, a valid path could begin with any one of the self-signed
   certificates.  Limitations in the trust paths for any particular key
   may be incorporated into the self-signed certificate's extensions. In
   this way, the self-signed certificates permit the path validation
   module to automatically incorporate local security policy and
   requirements.

   It is also possible to specify an extended version of the above
   certification path processing procedure which results in default
   behavior identical to the rules of PEM [RFC 1422].  In this extended
   version, additional inputs to the procedure are a list of one or more
   Policy Certification Authorities (PCAs) names and an indicator of the
   position in the certification path where the PCA is expected.  At the
   nominated PCA position, the CA name is compared against this list.
   If a recognized PCA name is found, then a constraint of
   SubordinateToCA is implicitly assumed for the remainder of the


 certification path and processing continues.  If no valid PCA name is
   found, and if the certification path cannot be validated on the basis
   of identified policies, then the certification path is considered
   invalid.

D.1 Certificate

   This section contains an annotated hex dump of a 699 byte version 3
   certificate.  The certificate contains the following information:
   (a) the serial number is 17 (11 hex);
   (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
   (c) the issuer's distinguished name is OU=nist; O=gov; C=US
   (d) and the subject's distinguished name is OU=nist; O=gov; C=US
   (e) the certificate was issued on June 30, 1997 and will expire on
   December 31, 1997;
   (f) the certificate contains a 1024 bit DSA public key with
   parameters;
   (g) the certificate contains a subject key identifier extension; and
   (h) the certificate is a CA certificate (as indicated through the
   basic constraints extension.)

0000 30 82 02 b7  695: SEQUENCE
0004 30 82 02 77  631: . SEQUENCE    tbscertificate
0008 a0 03          3: . . [0]
0010 02 01          1: . . . INTEGER 2
                     : 02
0013 02 01          1: . . INTEGER 17
                     : 11


0016 30 09          9: . . SEQUENCE
0018 06 07          7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
                     : 2a 86 48 ce 38 04 03
0027 30 2a         42: . . SEQUENCE
0029 31 0b         11: . . . SET
0031 30 09          9: . . . . SEQUENCE
0033 06 03          3: . . . . . OID 2.5.4.6: C
                     : 55 04 06
0038 13 02          2: . . . . . PrintableString  'US'
                     : 55 53
0042 31 0c         12: . . . SET
0044 30 0a         10: . . . . SEQUENCE
0046 06 03          3: . . . . . OID 2.5.4.10: O
                     : 55 04 0a
0051 13 03          3: . . . . . PrintableString  'gov'
                     : 67 6f 76
0056 31 0d         13: . . . SET
0058 30 0b         11: . . . . SEQUENCE
0060 06 03          3: . . . . . OID 2.5.4.11: OU
                     : 55 04 0b
0065 13 04          4: . . . . . PrintableString  'nist'
                     : 6e 69 73 74
0071 30 1e         30: . . SEQUENCE
0073 17 0d         13: . . . UTCTime  '970630000000Z'
                     : 39 37 30 36 33 30 30 30 30 30 30 30 5a
0088 17 0d         13: . . . UTCTime  '971231000000Z'
                     : 39 37 31 32 33 31 30 30 30 30 30 30 5a
0103 30 2a         42: . . SEQUENCE
0105 31 0b         11: . . . SET
0107 30 09          9: . . . . SEQUENCE
0109 06 03          3: . . . . . OID 2.5.4.6: C
                     : 55 04 06
0114 13 02          2: . . . . . PrintableString  'US'
                     : 55 53
0118 31 0c         12: . . . SET
0120 30 0a         10: . . . . SEQUENCE
0122 06 03          3: . . . . . OID 2.5.4.10: O
                     : 55 04 0a
0127 13 03          3: . . . . . PrintableString  'gov'
                     : 67 6f 76
0132 31 0d         13: . . . SET
0134 30 0b         11: . . . . SEQUENCE
0136 06 03          3: . . . . . OID 2.5.4.11: OU
                     : 55 04 0b
0141 13 04          4: . . . . . PrintableString  'nist'
                     : 6e 69 73 74
0147 30 82 01 b4  436: . . SEQUENCE
0151 30 82 01 29  297: . . . SEQUENCE

0155 06 07          7: . . . . OID 1.2.840.10040.4.1: dsa
                     : 2a 86 48 ce 38 04 01
0164 30 82 01 1c  284: . . . . SEQUENCE
0168 02 81 80     128: . . . . . INTEGER
                     : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3
                     : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2
                     : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03
                     : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6
                     : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a
                     : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be
                     : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d
                     : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
0299 02 14         20: . . . . . INTEGER
                     : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83
                     : 51 0d dc dd
0321 02 81 80     128: . . . . . INTEGER
                     : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca
                     : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90
                     : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5
                     : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb
                     : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d
                     : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42
                     : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90
                     : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
0452 03 81 84     132: . . . BIT STRING  (0 unused bits)
                     : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78
                     : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13
                     : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77
                     : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91
                     : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca
                     : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf
                     : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba
                     : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14
                     : aa 71 e1
0587 a3 32         50: . . [3]
0589 30 30         48: . . . SEQUENCE
0591 30 0f          9: . . . . SEQUENCE
0593 06 03          3: . . . . . OID 2.5.29.19: basicConstraints
                     : 55 1d 13
0598 01 01          1: . . . . . TRUE
                     : ff
0601 04 05          5: . . . . . OCTET STRING
                     : 30 03 01 01 ff
0608 30 1d         29: . SEQUENCE
0610 06 03          3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
                     : 55 1d 0e
0615 04 16         22: . . . . . OCTET STRING
                     : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff

D.4 Certificate Revocation List

   This section contains an annotated hex dump of a version 2 CRL with
   one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us
   on July 7, 1996; the next scheduled issuance was August 7, 1996.  The
   CRL includes one revoked certificates: serial number 18 (12 hex).
   The CRL itself is number 18, and it was signed with DSA and SHA-1.

0000 30 81 ba     186: SEQUENCE
0003 30 7c        124: . SEQUENCE
0005 02 01          1: . . INTEGER 1
                     : 01
0008 30 09          9: . . SEQUENCE
0010 06 07          7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
                     : 2a 86 48 ce 38 04 03
0019 30 2a         42: . . SEQUENCE
0021 31 0b         11: . . . SET
0023 30 09          9: . . . . SEQUENCE
0025 06 03          3: . . . . . OID 2.5.4.6: C
                     : 55 04 06
0030 13 02          2: . . . . . PrintableString  'US'
                     : 55 53
0034 31 0c         12: . . . SET
0036 30 0a         10: . . . . SEQUENCE
0038 06 03          3: . . . . . OID 2.5.4.10: O
                     : 55 04 0a
0043 13 03          3: . . . . . PrintableString  'gov'
                     : 67 6f 76
0048 31 0d         13: . . . SET
0050 30 0b         11: . . . . SEQUENCE
0052 06 03          3: . . . . . OID 2.5.4.11: OU
                     : 55 04 0b



Housley, et. al.            Standards Track                   [Page 126]

RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


0057 13 04          4: . . . . . PrintableString  'nist'
                     : 6e 69 73 74
0063 17 0d         13: . . UTCTime  '970801000000Z'
                     : 39 37 30 38 30 31 30 30 30 30 30 30 5a
0078 17 0d         13: . . UTCTime  '970808000000Z'
                     : 39 37 30 38 30 38 30 30 30 30 30 30 5a
0093 30 22         34: . . SEQUENCE
0095 30 20         32: . . . SEQUENCE
0097 02 01          1: . . . . INTEGER 18
                     : 12
0100 17 0d         13: . . . . UTCTime  '970731000000Z'
                     : 39 37 30 37 33 31 30 30 30 30 30 30 5a
0115 30 0c         12: . . . . SEQUENCE
0117 30 0a         10: . . . . . SEQUENCE
0119 06 03          3: . . . . . . OID 2.5.29.21: reasonCode
                     : 55 1d 15
0124 04 03          3: . . . . . . OCTET STRING
                     : 0a 01 01
0129 30 09          9: . SEQUENCE
0131 06 07          7: . . OID 1.2.840.10040.4.3: dsa-with-sha
                     : 2a 86 48 ce 38 04 03
0140 03 2f         47: . BIT STRING  (0 unused bits)
                     : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9
                     : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea
                     : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2