Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3280

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

Pages: 129
Obsoletes:  2459
Obsoleted by:  5280
Updated by:  43254630
Part 3 of 5 – Pages 48 to 80
First   Prev   Next

ToP   noToC   RFC3280 - Page 48   prevText

5 CRL and CRL Extensions Profile

As discussed 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 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. CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority. Whenever the CRL issuer is not the CA that issued the certificates, the CRL is referred to as an indirect CRL. Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be "all certificates issued by CA X", "all CA certificates issued by CA X", "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise", or could be a set of certificates based on arbitrary local information, such as "all certificates issued to the NIST employees located in Boulder".
ToP   noToC   RFC3280 - Page 49
   A complete CRL lists all unexpired certificates, within its scope,
   that have been revoked for one of the revocation reasons covered by
   the CRL scope.  The CRL issuer MAY also generate delta CRLs.  A delta
   CRL only lists those certificates, within its scope, whose revocation
   status has changed since the issuance of a referenced complete CRL.
   The referenced complete CRL is referred to as a base CRL.  The scope
   of a delta CRL MUST be the same as the base CRL that it references.

   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.  When CRLs are issued,
   the CRLs MUST be version 2 CRLs, include the date by which the next
   CRL will be issued in the nextUpdate field (section 5.1.2.5), include
   the CRL number extension (section 5.2.3), and include the authority
   key identifier extension (section 5.2.1).  Conforming applications
   that support CRLs are REQUIRED to process both version 1 and version
   2 complete CRLs that provide revocation information for all
   certificates issued by one CA.  Conforming applications are NOT
   REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
   with a scope other than all certificates issued by one CA.

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 }
ToP   noToC   RFC3280 - Page 50
   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                           -- if present, MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                           -- if present, MUST 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 optional list of revoked certificates, and optional CRL extensions. When there are no revoked certificates, the revoked certificates list is absent. When one or more certificates are revoked, 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 CRL issuer to sign the CertificateList. The field is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. [PKIXALGS] lists the supported algorithms for this specification, but other signature algorithms MAY also be supported.
ToP   noToC   RFC3280 - Page 51
   This field MUST contain the same algorithm identifier as the
   signature field in the sequence tbsCertList (section 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 encoded as a BIT STRING and included in the CRL signatureValue field. The details of this process are specified for each of the supported algorithms in [PKIXALGS]. CAs that are also CRL issuers MAY use one private key to digitally sign certificates and CRLs, or MAY use separate private keys to digitally sign certificates and CRLs. When separate private keys are employed, each of the public keys associated with these private keys is placed in a separate certificate, one with the keyCertSign bit set in the key usage extension, and one with the cRLSign bit set in the key usage extension (section 4.2.1.3). When separate private keys are employed, certificates issued by the CA contain one authority key identifier, and the corresponding CRLs contain a different authority key identifier. The use of separate CA certificates for validation of certificate signatures and CRL signatures can offer improved security characteristics; however, it imposes a burden on applications, and it might limit interoperability. Many applications construct a certification path, and then validate the certification path (section 6). CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL signature validation certificate. Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys.

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 CRL issuer 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
ToP   noToC   RFC3280 - Page 52
   has issued.  The profile requires conforming CRL issuers to use the
   CRL number and authority key identifier CRL extensions 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. [PKIXALGS] 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 (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 (section 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 (section 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. CRL issuers conforming to this profile MUST encode thisUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile 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.
ToP   noToC   RFC3280 - Page 53
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. CRL issuers 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 CRL issuers. 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. CRL issuers conforming to this profile MUST encode nextUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile 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
When there are no revoked certificates, the revoked certificates list MUST be absent. Otherwise, revoked certificates are listed 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 (section 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, ISO/IEC, and ITU-T 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
ToP   noToC   RFC3280 - Page 54
   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 CRL issuers are REQUIRED to include the authority key
   identifier (section 5.2.1) and the CRL number (section 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 CRL issuers 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; however, a DNS name MAY be represented in the issuer field using the domainComponent attribute as described in section 4.1.2.4. The issuerAltName extension SHOULD NOT be marked critical. The OID and syntax for this CRL extension are defined in section 4.2.1.8.
ToP   noToC   RFC3280 - Page 55

5.2.3 CRL Number

The CRL number is a non-critical CRL extension which conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer. This extension allows users to easily determine when a particular CRL supersedes another CRL. CRL numbers also support the identification of complementary complete CRLs and delta CRLs. CRL issuers conforming to this profile MUST include this extension in all CRLs. If a CRL issuer generates delta CRLs in addition to complete CRLs for a given scope, the complete CRLs and delta CRLs MUST share one numbering sequence. If a delta CRL and a complete CRL that cover the same scope are issued at the same time, they MUST have the same CRL number and provide the same revocation information. That is, the combination of the delta CRL and an acceptable complete CRL MUST provide the same revocation information as the simultaneously issued complete CRL. If a CRL issuer generates two CRLs (two complete CRLs, two delta CRLs, or a complete CRL and a delta CRL) for the same scope at different times, the two CRLs MUST NOT have the same CRL number. That is, if the this update field (section 5.1.2.4) in the two CRLs are not identical, the CRL numbers MUST be different. Given the requirements above, CRL numbers can be expected to contain long integers. CRL verifiers MUST be able to handle CRLNumber values up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber values longer than 20 octets. 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 CRL as being a delta CRL. Delta CRLs contain updates to revocation information previously distributed, rather than all the information that would appear in a complete CRL. The use of delta CRLs can significantly reduce network load and processing time in some environments. Delta CRLs are generally smaller than the CRLs they update, so applications that obtain delta CRLs consume less network bandwidth than applications that obtain the corresponding complete CRLs. Applications which store revocation information in a format other than the CRL structure can add new revocation information to the local database without reprocessing information.
ToP   noToC   RFC3280 - Page 56
   The delta CRL indicator extension contains the single value of type
   BaseCRLNumber.  The CRL number identifies the CRL, complete for a
   given scope, that was used as the starting point in the generation of
   this delta CRL.  A conforming CRL issuer MUST publish the referenced
   base CRL as a complete CRL.  The delta CRL contains all updates to
   the revocation status for that same scope.  The combination of a
   delta CRL plus the referenced base CRL is equivalent to a complete
   CRL, for the applicable scope, at the time of publication of the
   delta CRL.

   When a conforming CRL issuer generates a delta CRL, the delta CRL
   MUST include a critical delta CRL indicator extension.

   When a delta CRL is issued, it MUST cover the same set of reasons and
   the same set of certificates that were covered by the base CRL it
   references.  That is, the scope of the delta CRL MUST be the same as
   the scope of the complete CRL referenced as the base.  The referenced
   base CRL and the delta CRL MUST omit the issuing distribution point
   extension or contain identical issuing distribution point extensions.
   Further, the CRL issuer MUST use the same private key to sign the
   delta CRL and any complete CRL that it can be used to update.

   An application that supports delta CRLs can construct a CRL that is
   complete for a given scope by combining a delta CRL for that scope
   with either an issued CRL that is complete for that scope or a
   locally constructed CRL that is complete for that scope.

   When a delta CRL is combined with a complete CRL or a locally
   constructed CRL, the resulting locally constructed CRL has the CRL
   number specified in the CRL number extension found in the delta CRL
   used in its construction.  In addition, the resulting locally
   constructed CRL has the thisUpdate and nextUpdate times specified in
   the corresponding fields of the delta CRL used in its construction.
   In addition, the locally constructed CRL inherits the issuing
   distribution point from the delta CRL.

   A complete CRL and a delta CRL MAY be combined if the following four
   conditions are satisfied:

      (a)  The complete CRL and delta CRL have the same issuer.

      (b)  The complete CRL and delta CRL have the same scope.  The two
      CRLs have the same scope if either of the following conditions are
      met:

         (1)  The issuingDistributionPoint extension is omitted from
         both the complete CRL and the delta CRL.
ToP   noToC   RFC3280 - Page 57
         (2)  The issuingDistributionPoint extension is present in both
         the complete CRL and the delta CRL, and the values for each of
         the fields in the extensions are the same in both CRLs.

      (c)  The CRL number of the complete CRL is equal to or greater
      than the BaseCRLNumber specified in the delta CRL.  That is, the
      complete CRL contains (at a minimum) all the revocation
      information held by the referenced base CRL.

      (d)  The CRL number of the complete CRL is less than the CRL
      number of the delta CRL.  That is, the delta CRL follows the
      complete CRL in the numbering sequence.

   CRL issuers MUST ensure that the combination of a delta CRL and any
   appropriate complete CRL accurately reflects the current revocation
   status.  The CRL issuer MUST include an entry in the delta CRL for
   each certificate within the scope of the delta CRL whose status has
   changed since the generation of the referenced base CRL:

      (a)  If the certificate is revoked for a reason included in the
      scope of the CRL, list the certificate as revoked.

      (b)  If the certificate is valid and was listed on the referenced
      base CRL or any subsequent CRL with reason code certificateHold,
      and the reason code certificateHold is included in the scope of
      the CRL, list the certificate with the reason code removeFromCRL.

      (c)  If the certificate is revoked for a reason outside the scope
      of the CRL, but the certificate was listed on the referenced base
      CRL or any subsequent CRL with a reason code included in the scope
      of this CRL, list the certificate as revoked but omit the reason
      code.

      (d)  If the certificate is revoked for a reason outside the scope
      of the CRL and the certificate was neither listed on the
      referenced base CRL nor any subsequent CRL with a reason code
      included in the scope of this CRL, do not list the certificate on
      this CRL.

   The status of a certificate is considered to have changed if it is
   revoked, placed on hold, released from hold, or if its revocation
   reason changes.

   It is appropriate to list a certificate with reason code
   removeFromCRL on a delta CRL even if the certificate was not on hold
   in the referenced base CRL.  If the certificate was placed on hold in
ToP   noToC   RFC3280 - Page 58
   any CRL issued after the base but before this delta CRL and then
   released from hold, it MUST be listed on the delta CRL with
   revocation reason removeFromCRL.

   A CRL issuer MAY optionally list a certificate on a delta CRL with
   reason code removeFromCRL if the notAfter time specified in the
   certificate precedes the thisUpdate time specified in the delta CRL
   and the certificate was listed on the referenced base CRL or in any
   CRL issued after the base but before this delta CRL.

   If a certificate revocation notice first appears on a delta CRL, then
   it is possible for the certificate validity period to expire before
   the next complete CRL for the same scope is issued.  In this case,
   the revocation notice MUST be included in all subsequent delta CRLs
   until the revocation notice is included on at least one explicitly
   issued complete CRL for this scope.

   An application that supports delta CRLs MUST be able to construct a
   current complete CRL by combining a previously issued complete CRL
   and the most current delta CRL.  An application that supports delta
   CRLs MAY also be able to construct a current complete CRL by
   combining a previously locally constructed complete CRL and the
   current delta CRL.  A delta CRL is considered to be the current one
   if the current time is between the times contained in the thisUpdate
   and nextUpdate fields.  Under some circumstances, the CRL issuer may
   publish one or more delta CRLs before indicated by the nextUpdate
   field.  If more than one current delta CRL for a given scope is
   encountered, the application SHOULD consider the one with the latest
   value in thisUpdate to be the most current one.

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

   BaseCRLNumber ::= CRLNumber

5.2.5 Issuing Distribution Point

The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension.
ToP   noToC   RFC3280 - Page 59
   The CRL is signed using the CRL issuer'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 CRL issuer.

   The reason codes associated with a distribution point MUST be
   specified in onlySomeReasons.  If onlySomeReasons does not appear,
   the distribution point MUST 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), cACompromise (2), and
   aACompromise (8) appear in one distribution point, and the
   revocations with other reason codes appear in another distribution
   point.

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

   If the distributionPoint field is absent, the CRL MUST contain
   entries for all revoked unexpired certificates issued by the CRL
   issuer, if any, within the scope of the CRL.

   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  The authority responsible for each entry is indicated by
   the certificate issuer CRL entry extension (section 5.3.4).

   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,
        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)

The freshest CRL extension identifies how delta CRL information for this complete CRL is obtained. The extension MUST be non-critical. This extension MUST NOT appear in delta CRLs.
ToP   noToC   RFC3280 - Page 60
   The same syntax is used for this extension as the
   cRLDistributionPoints certificate extension, and is described in
   section 4.2.1.14.  However, only the distribution point field is
   meaningful in this context.  The reasons and CRLIssuer fields MUST be
   omitted from this CRL extension.

   Each distribution point name provides the location at which a delta
   CRL for this complete CRL can be found.  The scope of these delta
   CRLs MUST be the same as the scope of this complete CRL.  The
   contents of this CRL extension are only used to locate delta CRLs;
   the contents are not used to validate the CRL or the referenced delta
   CRLs.  The encoding conventions defined for distribution points in
   section 4.2.1.14 apply to this extension.

   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }

   FreshestCRL ::= CRLDistributionPoints

5.3 CRL Entry Extensions

The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 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 CRL issuers and applications. However, CRL issuers SHOULD include reason codes (section 5.3.1) and invalidity dates (section 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. CRL issuers 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.
ToP   noToC   RFC3280 - Page 61
   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),
        privilegeWithdrawn      (9),
        aACompromise           (10) }

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.
ToP   noToC   RFC3280 - Page 62

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 CRL issuer 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, CRL issuers 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, that is, 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 CRL issuers, this extension MUST always be 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 the algorithm supplied in [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
ToP   noToC   RFC3280 - Page 63
   certificates which comprise the path and inputs which are specified
   by the relying party.  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 provide functionality
   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.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA's name, and any
   constraints upon the set of paths which may be validated using this
   key.

   The selection of a trust anchor is a matter of policy: it could be
   the top 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 trust
   anchor.  In addition, different applications may rely on different
   trust anchor, or may accept paths that begin with any of a set of
   trust anchor.

   Section 6.2 describes methods for using the path validation algorithm
   in specific implementations.  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.

   Section 6.3 describes the steps necessary to determine if a
   certificate is revoked or on hold status when CRLs are the revocation
   mechanism used by the certificate issuer.

6.1 Basic Path Validation

This text describes an algorithm for X.509 path processing. A conformant implementation MUST include an X.509 path processing procedure that is functionally equivalent to the external behavior of this algorithm. However, support for some of the certificate extensions processed in this algorithm are OPTIONAL for compliant implementations. Clients that do not support these extensions MAY omit the corresponding steps in the path validation algorithm.
ToP   noToC   RFC3280 - Page 64
   For example, clients are NOT REQUIRED to support the policy mapping
   extension.  Clients that do not support this extension MAY omit the
   path validation steps where policy mappings are processed.  Note that
   clients MUST reject the certificate if it contains an unsupported
   critical extension.

   The algorithm presented in this section validates the certificate
   with respect to the current date and time.  A conformant
   implementation MAY also support validation with respect to some point
   in the past.  Note that mechanisms are not available for validating a
   certificate with respect to a time outside the certificate validity
   period.

   The trust anchor is an input to the algorithm.  There is no
   requirement that the same trust anchor be used to validate all
   certification paths.  Different trust anchors MAY be used to validate
   different paths, as discussed further in Section 6.2.

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the end entity certificate,
   based on the public key of the trust anchor.  This requires obtaining
   a sequence of certificates that support that binding.  The procedure
   performed to obtain this sequence of certificates is outside the
   scope of this specification.

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated; and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
      time in question.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   are provided as inputs to the certification path validation algorithm
   (section 6.1.1).
ToP   noToC   RFC3280 - Page 65
   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.  The path
   validation process also determines the set of certificate policies
   that are valid for this path, based on the certificate policies
   extension, policy mapping extension, policy constraints extension,
   and inhibit any-policy extension.  To achieve this, the path
   validation algorithm constructs a valid policy tree.  If the set of
   certificate policies that are valid for this path is not empty, then
   the result will be a valid policy tree of depth n, otherwise the
   result will be a null valid policy tree.

   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty.  In general, the
   issuer and subject of the certificates that make up a path are
   different for each certificate.  However, a CA may issue a
   certificate to itself to support key rollover or changes in
   certificate policies.  These self-issued certificates are not counted
   when evaluating path length or name constraints.

   This section presents the algorithm in four basic steps: (1)
   initialization, (2) basic certificate processing, (3) preparation for
   the next certificate, and (4) wrap-up.  Steps (1) and (4) are
   performed exactly once.  Step (2) is performed for all certificates
   in the path.  Step (3) is performed for all certificates in the path
   except the final certificate.  Figure 2 provides a high-level
   flowchart of this algorithm.
ToP   noToC   RFC3280 - Page 66
                           +-------+
                           | START |
                           +-------+
                               |
                               V
                       +----------------+
                       | Initialization |
                       +----------------+
                               |
                               +<--------------------+
                               |                     |
                               V                     |
                       +----------------+            |
                       |  Process Cert  |            |
                       +----------------+            |
                               |                     |
                               V                     |
                       +================+            |
                       |  IF Last Cert  |            |
                       |    in Path     |            |
                       +================+            |
                         |            |              |
                    THEN |            | ELSE         |
                         V            V              |
              +----------------+ +----------------+  |
              |    Wrap up     | |  Prepare for   |  |
              +----------------+ |   Next Cert    |  |
                      |          +----------------+  |
                      V               |              |
                  +-------+           +--------------+
                  | STOP  |
                  +-------+


         Figure 2.  Certification Path Processing Flowchart

6.1.1 Inputs

This algorithm assumes the following seven inputs are provided to the path processing logic: (a) a prospective certification path of length n. (b) the current date/time.
ToP   noToC   RFC3280 - Page 67
      (c)  user-initial-policy-set:  A set of certificate policy
      identifiers naming the policies that are acceptable to the
      certificate user.  The user-initial-policy-set contains the
      special value any-policy if the user is not concerned about
      certificate policy.

      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
         with the public key.

      The trust anchor information may be provided to the path
      processing procedure in the form of a self-signed certificate.
      The trusted anchor information is trusted because it was delivered
      to the path processing procedure by some trustworthy out-of-band
      procedure.  If the trusted public key algorithm requires
      parameters, then the parameters are provided along with the
      trusted public key.

      (e) initial-policy-mapping-inhibit, which indicates if policy
      mapping is allowed in the certification path.

      (f) initial-explicit-policy, which indicates if the path must be
      valid for at least one of the certificate policies in the user-
      initial-policy-set.

      (g) initial-any-policy-inhibit, which indicates whether the
      anyPolicy OID should be processed if it is included in a
      certificate.

6.1.2 Initialization

This initialization phase establishes eleven state variables based upon the seven inputs: (a) valid_policy_tree: A tree of certificate policies with their optional qualifiers; each of the leaves of the tree represents a valid policy at this stage in the certification path validation. If valid policies exist at this stage in the certification path validation, the depth of the tree is equal to the number of
ToP   noToC   RFC3280 - Page 68
      certificates in the chain that have been processed.  If valid
      policies do not exist at this stage in the certification path
      validation, the tree is set to NULL.  Once the tree is set to
      NULL, policy processing ceases.

      Each node in the valid_policy_tree includes four data objects: the
      valid policy, a set of associated policy qualifiers, a set of one
      or more expected policy values, and a criticality indicator.  If
      the node is at depth x, the components of the node have the
      following semantics:

         (1)  The valid_policy is a single policy OID representing a
         valid policy for the path of length x.

         (2)  The qualifier_set is a set of policy qualifiers associated
         with the valid policy in certificate x.

         (3)  The criticality_indicator indicates whether the
         certificate policy extension in certificate x was marked as
         critical.

         (4)  The expected_policy_set contains one or more policy OIDs
         that would satisfy this policy in the certificate x+1.

      The initial value of the valid_policy_tree is a single node with
      valid_policy anyPolicy, an empty qualifier_set, an
      expected_policy_set with the single value anyPolicy, and a
      criticality_indicator of FALSE.  This node is considered to be at
      depth zero.

      Figure 3 is a graphic representation of the initial state of the
      valid_policy_tree.  Additional figures will use this format to
      describe changes in the valid_policy_tree during path processing.

              +----------------+
              |   anyPolicy    |   <---- valid_policy
              +----------------+
              |       {}       |   <---- qualifier_set
              +----------------+
              |     FALSE      |   <---- criticality_indicator
              +----------------+
              |  {anyPolicy}   |   <---- expected_policy_set
              +----------------+

      Figure 3.  Initial value of the valid_policy_tree state variable
ToP   noToC   RFC3280 - Page 69
      (b) permitted_subtrees:  A set of root names for each name type
      (e.g., X.500 distinguished names, email addresses, or ip
      addresses) defining a set of subtrees within which all subject
      names in subsequent certificates in the certification path MUST
      fall.  This variable includes a set for each name type: the
      initial value for the set for Distinguished Names is the set of
      all Distinguished names; the initial value for the set of RFC822
      names is the set of all RFC822 names, etc.

      (c) excluded_subtrees:  A set of root names for each name type
      (e.g., X.500 distinguished names, email addresses, or ip
      addresses) defining a set of subtrees within which no subject name
      in subsequent certificates in the certification path may fall.
      This variable includes a set for each name type, and the initial
      value for each set is empty.

      (d) explicit_policy: an integer which indicates if a non-NULL
      valid_policy_tree is required. The integer indicates the number of
      non-self-issued certificates to be processed before 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 a non-NULL valid_policy_tree, a later certificate can not
      remove this requirement. If initial-explicit-policy is set, then
      the initial value is 0, otherwise the initial value is n+1.

      (e) inhibit_any-policy: an integer which indicates whether the
      anyPolicy policy identifier is considered a match. The integer
      indicates the number of non-self-issued certificates to be
      processed before the anyPolicy OID, if asserted in a certificate,
      is ignored. Once set, this variable may be decreased, but may not
      be increased. That is, if a certificate in the path inhibits
      processing of anyPolicy, a later certificate can not permit it.
      If initial-any-policy-inhibit is set, then the initial value is 0,
      otherwise the initial value is n+1.

      (f) policy_mapping: an integer which indicates if policy mapping
      is permitted.  The integer indicates the number of non-self-issued
      certificates to be processed before policy mapping is inhibited.
      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 overridden by a later
      certificate. If initial-policy-mapping-inhibit is set, then the
      initial value is 0, otherwise the initial value is n+1.

      (g) working_public_key_algorithm: the digital signature algorithm
      used to verify the signature of a certificate.  The
      working_public_key_algorithm is initialized from the trusted
      public key algorithm provided in the trust anchor information.
ToP   noToC   RFC3280 - Page 70
      (h) working_public_key: the public key used to verify the
      signature of a certificate.  The working_public_key is initialized
      from the trusted public key provided in the trust anchor
      information.

      (i) working_public_key_parameters:  parameters associated with the
      current public key, that may be required to verify a signature
      (depending upon the algorithm).  The working_public_key_parameters
      variable is initialized from the trusted public key parameters
      provided in the trust anchor information.

      (j) working_issuer_name:  the issuer distinguished name expected
      in the next certificate in the chain.  The working_issuer_name is
      initialized to the trusted issuer provided in the trust anchor
      information.

      (k) max_path_length:  this integer is initialized to n, is
      decremented for each non-self-issued certificate in the path, and
      may be reduced to the value in the path length constraint field
      within the basic constraints extension of a CA certificate.

   Upon completion of the initialization steps, perform the basic
   certificate processing steps specified in 6.1.3.

6.1.3 Basic Certificate Processing

The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: (1) The certificate was signed with the working_public_key_algorithm using the working_public_key and the working_public_key_parameters. (2) The certificate validity period includes the current time. (3) At the current time, the certificate is not revoked and is not on hold status. This may be determined by obtaining the appropriate CRL (section 6.3), status information, or by out- of-band mechanisms. (4) The certificate issuer name is the working_issuer_name.
ToP   noToC   RFC3280 - Page 71
      (b)  If certificate i is self-issued and it is not the final
      certificate in the path, skip this step for certificate i.
      Otherwise, verify that the subject name is within one of the
      permitted_subtrees for X.500 distinguished names, and verify that
      each of the alternative names in the subjectAltName extension
      (critical or non-critical) is within one of the permitted_subtrees
      for that name type.

      (c)  If certificate i is self-issued and it is not the final
      certificate in the path, skip this step for certificate i.
      Otherwise, verify that the subject name is not within one of the
      excluded_subtrees for X.500 distinguished names, and verify that
      each of the alternative names in the subjectAltName extension
      (critical or non-critical) is not within one of the
      excluded_subtrees for that name type.

      (d)  If the certificate policies extension is present in the
      certificate and the valid_policy_tree is not NULL, process the
      policy information by performing the following steps in order:

         (1)  For each policy P not equal to anyPolicy in the
         certificate policies extension, let P-OID denote the OID in
         policy P and P-Q denote the qualifier set for policy P.
         Perform the following steps in order:

            (i)  If the valid_policy_tree includes a node of depth i-1
            where P-OID is in the expected_policy_set, create a child
            node as follows: set the valid_policy to OID-P; set the
            qualifier_set to P-Q, and set the expected_policy_set to
            {P-OID}.

            For example, consider a valid_policy_tree with a node of
            depth i-1 where the expected_policy_set is {Gold, White}.
            Assume the certificate policies Gold and Silver appear in
            the certificate policies extension of certificate i.  The
            Gold policy is matched but the Silver policy is not.  This
            rule will generate a child node of depth i for the Gold
            policy. The result is shown as Figure 4.
ToP   noToC   RFC3280 - Page 72
                             +-----------------+
                             |       Red       |
                             +-----------------+
                             |       {}        |
                             +-----------------+   node of depth i-1
                             |      FALSE      |
                             +-----------------+
                             |  {Gold, White}  |
                             +-----------------+
                                      |
                                      |
                                      |
                                      V
                             +-----------------+
                             |      Gold       |
                             +-----------------+
                             |       {}        |
                             +-----------------+ node of depth i
                             |  uninitialized  |
                             +-----------------+
                             |     {Gold}      |
                             +-----------------+

                    Figure 4.  Processing an exact match

            (ii)  If there was no match in step (i) and the
            valid_policy_tree includes a node of depth i-1 with the
            valid policy anyPolicy, generate a child node with the
            following values: set the valid_policy to P-OID; set the
            qualifier_set to P-Q, and set the expected_policy_set to
            {P-OID}.

            For example, consider a valid_policy_tree with a node of
            depth i-1 where the valid_policy is anyPolicy.  Assume the
            certificate policies Gold and Silver appear in the
            certificate policies extension of certificate i.  The Gold
            policy does not have a qualifier, but the Silver policy has
            the qualifier Q-Silver.  If Gold and Silver were not matched
            in (i) above, this rule will generate two child nodes of
            depth i, one for each policy.  The result is shown as Figure
            5.
ToP   noToC   RFC3280 - Page 73
                             +-----------------+
                             |    anyPolicy    |
                             +-----------------+
                             |       {}        |
                             +-----------------+ node of depth i-1
                             |      FALSE      |
                             +-----------------+
                             |   {anyPolicy}   |
                             +-----------------+
                                /           \
                               /             \
                              /               \
                             /                 \
               +-----------------+          +-----------------+
               |      Gold       |          |     Silver      |
               +-----------------+          +-----------------+
               |       {}        |          |   {Q-Silver}    |
               +-----------------+ nodes of +-----------------+
               | uninitialized   | depth i  | uninitialized   |
               +-----------------+          +-----------------+
               |     {Gold}      |          |    {Silver}     |
               +-----------------+          +-----------------+

               Figure 5.  Processing unmatched policies when a leaf node
               specifies anyPolicy

         (2)  If the certificate policies extension includes the policy
         anyPolicy with the qualifier set AP-Q and either (a)
         inhibit_any-policy is greater than 0 or (b) i<n and the
         certificate is self-issued, then:

         For each node in the valid_policy_tree of depth i-1, for each
         value in the expected_policy_set (including anyPolicy) that
         does not appear in a child node, create a child node with the
         following values: set the valid_policy to the value from the
         expected_policy_set in the parent node; set the qualifier_set
         to AP-Q, and set the expected_policy_set to the value in the
         valid_policy from this node.

         For example, consider a valid_policy_tree with a node of depth
         i-1 where the expected_policy_set is {Gold, Silver}.  Assume
         anyPolicy appears in the certificate policies extension of
         certificate i, but Gold and Silver do not.  This rule will
         generate two child nodes of depth i, one for each policy.  The
         result is shown below as Figure 6.
ToP   noToC   RFC3280 - Page 74
                          +-----------------+
                          |      Red        |
                          +-----------------+
                          |       {}        |
                          +-----------------+ node of depth i-1
                          |      FALSE      |
                          +-----------------+
                          |  {Gold, Silver} |
                          +-----------------+
                             /           \
                            /             \
                           /               \
                          /                 \
            +-----------------+          +-----------------+
            |      Gold       |          |     Silver      |
            +-----------------+          +-----------------+
            |       {}        |          |       {}        |
            +-----------------+ nodes of +-----------------+
            |  uninitialized  | depth i  |  uninitialized  |
            +-----------------+          +-----------------+
            |     {Gold}      |          |    {Silver}     |
            +-----------------+          +-----------------+

         Figure 6.  Processing unmatched policies when the certificate
         policies extension specifies anyPolicy

         (3)  If there is a node in the valid_policy_tree of depth i-1
         or less without any child nodes, delete that node.  Repeat this
         step until there are no nodes of depth i-1 or less without
         children.

         For example, consider the valid_policy_tree shown in Figure 7
         below.  The two nodes at depth i-1 that are marked with an 'X'
         have no children, and are deleted.  Applying this rule to the
         resulting tree will cause the node at depth i-2 that is marked
         with an 'Y' to be deleted.  The following application of the
         rule does not cause any nodes to be deleted, and this step is
         complete.
ToP   noToC   RFC3280 - Page 75
                              +-----------+
                              |           | node of depth i-3
                              +-----------+
                              /     |     \
                             /      |      \
                            /       |       \
                +-----------+ +-----------+ +-----------+
                |           | |           | |     Y     | nodes of
                +-----------+ +-----------+ +-----------+ depth i-2
                /   \               |             |
               /     \              |             |
              /       \             |             |
   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
   |           | |     X     | |           | |    X      |  depth
   +-----------+ +-----------+ +-----------+ +-----------+   i-1
         |                      /    |    \
         |                     /     |     \
         |                    /      |      \
   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
   |           | |           | |           | |           |  depth
   +-----------+ +-----------+ +-----------+ +-----------+   i

          Figure 7.  Pruning the valid_policy_tree

         (4)  If the certificate policies extension was marked as
         critical, set the criticality_indicator in all nodes of depth i
         to TRUE.  If the certificate policies extension was not marked
         critical, set the criticality_indicator in all nodes of depth i
         to FALSE.

      (e)  If the certificate policies extension is not present, set the
      valid_policy_tree to NULL.

      (f)  Verify that either explicit_policy is greater than 0 or the
      valid_policy_tree is not equal to NULL;

   If any of steps (a), (b), (c), or (f) fails, the procedure
   terminates, returning a failure indication and an appropriate reason.

   If i is not equal to n, continue by performing the preparatory steps
   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
   listed in 6.1.5.

6.1.4 Preparation for Certificate i+1

To prepare for processing of certificate i+1, perform the following steps for certificate i:
ToP   noToC   RFC3280 - Page 76
      (a)  If a policy mapping extension is present, verify that the
      special value anyPolicy does not appear as an issuerDomainPolicy
      or a subjectDomainPolicy.

      (b)  If a policy mapping extension is present, then for each
      issuerDomainPolicy ID-P in the policy mapping extension:

         (1)  If the policy_mapping variable is greater than 0, for each
         node in the valid_policy_tree of depth i where ID-P is the
         valid_policy, set expected_policy_set to the set of
         subjectDomainPolicy values that are specified as equivalent to
         ID-P by the policy mapping extension.

         If no node of depth i in the valid_policy_tree has a
         valid_policy of ID-P but there is a node of depth i with a
         valid_policy of anyPolicy, then generate a child node of the
         node of depth i-1 that has a valid_policy of anyPolicy as
         follows:

            (i)  set the valid_policy to ID-P;

            (ii)  set the qualifier_set to the qualifier set of the
            policy anyPolicy in the certificate policies extension of
            certificate i;

            (iii)  set the criticality_indicator to the criticality of
            the certificate policies extension of certificate i;

            (iv)  and set the expected_policy_set to the set of
            subjectDomainPolicy values that are specified as equivalent
            to ID-P by the policy mappings extension.

         (2)  If the policy_mapping variable is equal to 0:

            (i)  delete each node of depth i in the valid_policy_tree
            where ID-P is the valid_policy.

            (ii)  If there is a node in the valid_policy_tree of depth
            i-1 or less without any child nodes, delete that node.
            Repeat this step until there are no nodes of depth i-1 or
            less without children.

      (c)  Assign the certificate subject name to working_issuer_name.

      (d)  Assign the certificate subjectPublicKey to
      working_public_key.
ToP   noToC   RFC3280 - Page 77
      (e)  If the subjectPublicKeyInfo field of the certificate contains
      an algorithm field with non-null parameters, assign the parameters
      to the working_public_key_parameters variable.

      If the subjectPublicKeyInfo field of the certificate contains an
      algorithm field with null parameters or parameters are omitted,
      compare the certificate subjectPublicKey algorithm to the
      working_public_key_algorithm.  If the certificate subjectPublicKey
      algorithm and the working_public_key_algorithm are different, set
      the working_public_key_parameters to null.

      (f)  Assign the certificate subjectPublicKey algorithm to the
      working_public_key_algorithm variable.

      (g)  If a name constraints extension is included in the
      certificate, modify the permitted_subtrees and excluded_subtrees
      state variables as follows:

         (1)  If permittedSubtrees is present in the certificate, set
         the permitted_subtrees state variable to the intersection of
         its previous value and the value indicated in the extension
         field.  If permittedSubtrees does not include a particular name
         type, the permitted_subtrees state variable is unchanged for
         that name type.  For example, the intersection of nist.gov and
         csrc.nist.gov is csrc.nist.gov.  And, the intersection of
         nist.gov and rsasecurity.com is the empty set.

         (2)  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.  If
         excludedSubtrees does not include a particular name type, the
         excluded_subtrees state variable is unchanged for that name
         type.  For example, the union of the name spaces nist.gov and
         csrc.nist.gov is nist.gov.  And, the union of nist.gov and
         rsasecurity.com is both name spaces.

      (h)  If the issuer and subject names are not identical:

         (1)  If explicit_policy is not 0, decrement explicit_policy by
         1.

         (2)  If policy_mapping is not 0, decrement policy_mapping by 1.

         (3)  If inhibit_any-policy is not 0, decrement inhibit_any-
         policy by 1.
ToP   noToC   RFC3280 - Page 78
      (i)  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 is less than
         explicit_policy, set explicit_policy to the value of
         requireExplicitPolicy.

         (2)  If inhibitPolicyMapping is present and is less than
         policy_mapping, set policy_mapping to the value of
         inhibitPolicyMapping.

      (j)  If the inhibitAnyPolicy extension is included in the
      certificate and is less than inhibit_any-policy, set inhibit_any-
      policy to the value of inhibitAnyPolicy.

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

      (l)  If the certificate was not self-issued, verify that
      max_path_length is greater than zero and decrement max_path_length
      by 1.

      (m)  If pathLengthConstraint is present in the certificate and is
      less than max_path_length, set max_path_length to the value of
      pathLengthConstraint.

      (n)  If a key usage extension is present, verify that the
      keyCertSign bit is set.

      (o)  Recognize and process any other critical extension present in
      the certificate.  Process any other recognized non-critical
      extension present in the certificate.

   If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
   returning a failure indication and an appropriate reason.

   If (a), (k), (l), (n) and (o) have completed successfully, increment
   i and perform the basic certificate processing specified in 6.1.3.

6.1.5 Wrap-up procedure

To complete the processing of the end entity certificate, perform the following steps for certificate n: (a) If certificate n was not self-issued and explicit_policy is not 0, decrement explicit_policy by 1.
ToP   noToC   RFC3280 - Page 79
      (b)  If a policy constraints extension is included in the
      certificate and requireExplicitPolicy is present and has a value
      of 0, set the explicit_policy state variable to 0.

      (c)  Assign the certificate subjectPublicKey to
      working_public_key.

      (d)  If the subjectPublicKeyInfo field of the certificate contains
      an algorithm field with non-null parameters, assign the parameters
      to the working_public_key_parameters variable.

      If the subjectPublicKeyInfo field of the certificate contains an
      algorithm field with null parameters or parameters are omitted,
      compare the certificate subjectPublicKey algorithm to the
      working_public_key_algorithm.  If the certificate subjectPublicKey
      algorithm and the working_public_key_algorithm are different, set
      the working_public_key_parameters to null.

      (e)  Assign the certificate subjectPublicKey algorithm to the
      working_public_key_algorithm variable.

      (f)  Recognize and process any other critical extension present in
      the certificate n.  Process any other recognized non-critical
      extension present in certificate n.

      (g)  Calculate the intersection of the valid_policy_tree and the
      user-initial-policy-set, as follows:

         (i)  If the valid_policy_tree is NULL, the intersection is
         NULL.

         (ii)  If the valid_policy_tree is not NULL and the user-
         initial-policy-set is any-policy, the intersection is the
         entire valid_policy_tree.

         (iii)  If the valid_policy_tree is not NULL and the user-
         initial-policy-set is not any-policy, calculate the
         intersection of the valid_policy_tree and the user-initial-
         policy-set as follows:

            1.  Determine the set of policy nodes whose parent nodes
            have a valid_policy of anyPolicy.  This is the
            valid_policy_node_set.

            2.  If the valid_policy of any node in the
            valid_policy_node_set is not in the user-initial-policy-set
            and is not anyPolicy, delete this node and all its children.
ToP   noToC   RFC3280 - Page 80
            3.  If the valid_policy_tree includes a node of depth n with
            the valid_policy anyPolicy and the user-initial-policy-set
            is not any-policy perform the following steps:

               a. Set P-Q to the qualifier_set in the node of depth n
               with valid_policy anyPolicy.

               b. For each P-OID in the user-initial-policy-set that is
               not the valid_policy of a node in the
               valid_policy_node_set, create a child node whose parent
               is the node of depth n-1 with the valid_policy anyPolicy.
               Set the values in the child node as follows: set the
               valid_policy to P-OID; set the qualifier_set to P-Q; copy
               the criticality_indicator from the node of depth n with
               the valid_policy anyPolicy; and set the
               expected_policy_set to {P-OID}.

               c.  Delete the node of depth n with the valid_policy
               anyPolicy.

            4.  If there is a node in the valid_policy_tree of depth n-1
            or less without any child nodes, delete that node.  Repeat
            this step until there are no nodes of depth n-1 or less
            without children.

   If either (1) the value of explicit_policy variable is greater than
   zero, or (2) the valid_policy_tree is not NULL, then path processing
   has succeeded.

6.1.6 Outputs

If path processing succeeds, the procedure terminates, returning a success indication together with final value of the valid_policy_tree, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters.


(page 80 continued on part 4)

Next Section