RFC 3280
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
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".
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 }
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.
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
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.
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
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.
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.
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.
(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
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.
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.
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.
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.
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 ::= GeneralizedTime5.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
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.
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).
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.
+-------+ | 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 Flowchart6.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.
(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
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
(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.
(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.
(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.
+-----------------+ | 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.
+-----------------+ | 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.
+-----------------+ | 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.
+-----------+ | | 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:
(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.
(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.
(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.
(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.
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)
