6.2 Using the Path Validation Algorithm
The path validation algorithm describes the process of validating a
single certification path. While each certification path begins with
a specific trust anchor, there is no requirement that all
certification paths validated by a particular system share a single
trust anchor. An implementation that supports multiple trust anchors
MAY augment the algorithm presented in section 6.1 to further limit
the set of valid certification paths which begin with a particular
trust anchor. For example, an implementation MAY modify the
algorithm to apply name constraints to a specific trust anchor during
the initialization phase, or the application MAY require the presence
of a particular alternative name form in the end entity certificate,
or the application MAY impose requirements on application-specific
extensions. Thus, the path validation algorithm presented in section
6.1 defines the minimum conditions for a path to be considered valid.
The selection of one or more trusted CAs is a local decision. A
system may provide any one of its trusted CAs as the trust anchor for
a particular path. The inputs to the path validation algorithm may
be different for each path. The inputs used to process a path may
reflect application-specific requirements or limitations in the trust
accorded a particular trust anchor. For example, a trusted CA may
only be trusted for a particular certificate policy. This
restriction can be expressed through the inputs to the path
It is also possible to specify an extended version of the above
certification path processing procedure which results in default
behavior identical to the rules of PEM [RFC 1422]. In this extended
version, additional inputs to the procedure are a list of one or more
Policy Certification Authority (PCA) names and an indicator of the
position in the certification path where the PCA is expected. At the
nominated PCA position, the CA name is compared against this list.
If a recognized PCA name is found, then a constraint of
SubordinateToCA is implicitly assumed for the remainder of the
certification path and processing continues. If no valid PCA name is
found, and if the certification path cannot be validated on the basis
of identified policies, then the certification path is considered
6.3 CRL Validation
This section 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. Conforming implementations
that support CRLs are not required to implement this algorithm, but
they MUST be functionally equivalent to the external behavior
resulting from this procedure. Any algorithm may be used by a
particular implementation so long as it derives the correct result.
This algorithm assumes that all of the needed CRLs are available in a
local cache. Further, if the next update time of a CRL has passed,
the algorithm assumes a mechanism to fetch a current CRL and place it
in the local CRL cache.
This algorithm defines a set of inputs, a set of state variables, and
processing steps that are performed for each certificate in the path.
The algorithm output is the revocation status of the certificate.
6.3.1 Revocation Inputs
To support revocation processing, the algorithm requires two inputs:
(a) certificate: The algorithm requires the certificate serial
number and issuer name to determine whether a certificate is on a
particular CRL. The basicConstraints extension is used to
determine whether the supplied certificate is associated with a CA
or an end entity. If present, the algorithm uses the
cRLDistributionsPoint and freshestCRL extensions to determine
(b) use-deltas: This boolean input determines whether delta CRLs
are applied to CRLs.
Note that implementations supporting legacy PKIs, such as RFC 1422
and X.509 version 1, will need an additional input indicating
whether the supplied certificate is associated with a CA or an end
6.3.2 Initialization and Revocation State Variables
To support CRL processing, the algorithm requires the following state
(a) reasons_mask: This variable contains the set of revocation
reasons supported by the CRLs and delta CRLs processed so far.
The legal members of the set are the possible revocation reason
values: unspecified, keyCompromise, caCompromise,
affiliationChanged, superseded, cessationOfOperation,
certificateHold, privilegeWithdrawn, and aACompromise. The
special value all-reasons is used to denote the set of all legal
members. This variable is initialized to the empty set.
(b) cert_status: This variable contains the status of the
certificate. This variable may be assigned one of the following
values: unspecified, keyCompromise, caCompromise,
affiliationChanged, superseded, cessationOfOperation,
certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
the special value UNREVOKED, or the special value UNDETERMINED.
This variable is initialized to the special value UNREVOKED.
(c) interim_reasons_mask: This contains the set of revocation
reasons supported by the CRL or delta CRL currently being
Note: In some environments, it is not necessary to check all reason
codes. For example, some environments are only concerned with
caCompromise and keyCompromise for CA certificates. This algorithm
checks all reason codes. Additional processing and state variables
may be necessary to limit the checking to a subset of the reason
6.3.3 CRL Processing
This algorithm begins by assuming the certificate is not revoked.
The algorithm checks one or more CRLs until either the certificate
status is determined to be revoked or sufficient CRLs have been
checked to cover all reason codes.
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
(1) If the current time is after the value of the CRL next
update field, then do one of the following:
(i) If use-deltas is set and either the certificate or the
CRL contains the freshest CRL extension, obtain a delta CRL
with the a next update value that is after the current time
and can be used to update the locally cached CRL as
specified in section 5.2.4.
(ii) Update the local CRL cache with a current complete
CRL, verify that the current time is before the next update
value in the new CRL, and continue processing with the new
CRL. If use-deltas is set, then obtain the current delta
CRL that can be used to update the new locally cached
complete CRL as specified in section 5.2.4.
(2) If the current time is before the value of the next update
field and use-deltas is set, then obtain the current delta CRL
that can be used to update the locally cached complete CRL as
specified in section 5.2.4.
(b) Verify the issuer and scope of the complete CRL as follows:
(1) If the DP includes cRLIssuer, then verify that the issuer
field in the complete CRL matches cRLIssuer in the DP and that
the complete CRL contains an issuing distribution point
extension with the indrectCRL boolean asserted. Otherwise,
verify that the CRL issuer matches the certificate issuer.
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension check the following:
(i) If the distribution point name is present in the IDP
CRL extension and the distribution field is present in the
DP, then verify that one of the names in the IDP matches one
of the names in the DP. If the distribution point name is
present in the IDP CRL extension and the distribution field
is omitted from the DP, then verify that one of the names in
the IDP matches one of the names in the cRLIssuer field of
(ii) If the onlyContainsUserCerts boolean is asserted in
the IDP CRL extension, verify that the certificate does not
include the basic constraints extension with the cA boolean
(iii) If the onlyContainsCACerts boolean is asserted in the
IDP CRL extension, verify that the certificate includes the
basic constraints extension with the cA boolean asserted.
(iv) Verify that the onlyContainsAttributeCerts boolean is
(c) If use-deltas is set, verify the issuer and scope of the
delta CRL as follows:
(1) Verify that the delta CRL issuer matches complete CRL
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension, verify that the delta CRL contains a
matching IDP CRL extension. If the complete CRL omits an IDP
CRL extension, verify that the delta CRL also omits an IDP CRL
(3) Verify that the delta CRL authority key identifier
extension matches complete CRL authority key identifier
(d) Compute the interim_reasons_mask for this CRL as follows:
(1) If the issuing distribution point (IDP) CRL extension is
present and includes onlySomeReasons and the DP includes
reasons, then set interim_reasons_mask to the intersection of
reasons in the DP and onlySomeReasons in IDP CRL extension.
(2) If the IDP CRL extension includes onlySomeReasons but the
DP omits reasons, then set interim_reasons_mask to the value of
onlySomeReasons in IDP CRL extension.
(3) If the IDP CRL extension is not present or omits
onlySomeReasons but the DP includes reasons, then set
interim_reasons_mask to the value of DP reasons.
(4) If the IDP CRL extension is not present or omits
onlySomeReasons and the DP omits reasons, then set
interim_reasons_mask to the special value all-reasons.
(e) Verify that interim_reasons_mask includes one or more reasons
that is not included in the reasons_mask.
(f) Obtain and validate the certification path for the complete CRL
issuer. If a key usage extension is present in the CRL issuer's
certificate, verify that the cRLSign bit is set.
(g) Validate the signature on the complete CRL using the public key
validated in step (f).
(h) If use-deltas is set, then validate the signature on the delta
CRL using the public key validated in step (f).
(i) If use-deltas is set, then search for the certificate on the
delta CRL. If an entry is found that matches the certificate issuer
and serial number as described in section 5.3.4, then set the
cert_status variable to the indicated reason as follows:
(1) If the reason code CRL entry extension is present, set the
cert_status variable to the value of the reason code CRL entry
(2) If the reason code CRL entry extension is not present, set
the cert_status variable to the value unspecified.
(j) If (cert_status is UNREVOKED), then search for the
certificate on the complete CRL. If an entry is found that
matches the certificate issuer and serial number as described in
section 5.3.4, then set the cert_status variable to the indicated
reason as described in step (i).
(k) If (cert_status is removeFromCRL), then set cert_status to
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
then the revocation status has been determined, so return
If the revocation status has not been determined, repeat the process
above with any available CRLs not specified in a distribution point
but issued by the certificate issuer. For the processing of such a
CRL, assume a DP with both the reasons and the cRLIssuer fields
omitted and a distribution point name of the certificate issuer.
That is, the sequence of names in fullName is generated from the
certificate issuer field as well as the certificate issuerAltName
extension. If the revocation status remains undetermined, then
return the cert_status UNDETERMINED.
[ISO 10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
[RFC 822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management," RFC
1422, February 1993.
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers," RFC 1423, February 1993.
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)," RFC 1510, September 1993.
[RFC 1519] Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
Representation of Standard Attribute Syntaxes," RFC 1778,
[RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2044, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, January 1998.
[RFC 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
Adams, "Online Certificate Status Protocal - OCSP", June
[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A,
[X.501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X.509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The
Directory: Authentication Framework, June 1997.
[X.520] ITU-T Recommendation X.520: Information Technology - Open
Systems Interconnection - The Directory: Selected
Attribute Types, 1993.
[X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
[X.690] ITU-T Recommendation X.690 Information Technology - Open
Systems Interconnection - Procedures for the operation of
OSI Registration Authorities: General procedures, 1992.
[X9.55] ANSI X9.55-1995, Public Key Cryptography For The
Financial Services Industry: Extensions To Public Key
Certificates And Certificate Revocation Lists, 8
[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Lists (CRL) Profile", RFC 3279, April 2002.
[PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
8 Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights (see http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP 11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
9 Security Considerations
The majority of this specification is devoted to the format and
content of certificates and CRLs. Since certificates and CRLs are
digitally signed, no additional integrity service is necessary.
Neither certificates nor CRLs need be kept secret, and unrestricted
and anonymous access to certificates and CRLs has no security
However, security factors outside the scope of this specification
will affect the assurance provided to certificate users. This
section highlights critical issues to be considered by implementers,
administrators, and users.
The procedures performed by CAs and RAs to validate the binding of
the subject's identity to their public key greatly affect the
assurance that ought to be placed in the certificate. Relying
parties might wish to review the CA's certificate practice statement.
This is particularly important when issuing certificates to other
The use of a single key pair for both signature and other purposes is
strongly discouraged. Use of separate key pairs for signature and
key management provides several benefits to the users. The
ramifications associated with loss or disclosure of a signature key
are different from loss or disclosure of a key management key. Using
separate key pairs permits a balanced and flexible response.
Similarly, different validity periods or key lengths for each key
pair may be appropriate in some application environments.
Unfortunately, some legacy applications (e.g., SSL) use a single key
pair for signature and key management.
The protection afforded private keys is a critical security factor.
On a small scale, failure of users to protect their private keys will
permit an attacker to masquerade as them, or decrypt their personal
information. On a larger scale, compromise of a CA's private signing
key may have a catastrophic effect. If an attacker obtains the
private key unnoticed, the attacker may issue bogus certificates and
CRLs. Existence of bogus certificates and CRLs will undermine
confidence in the system. If such a compromise is detected, all
certificates issued to the compromised CA MUST be revoked, preventing
services between its users and users of other CAs. Rebuilding after
such a compromise will be problematic, so CAs are advised to
implement a combination of strong technical measures (e.g., tamper-
resistant cryptographic modules) and appropriate management
procedures (e.g., separation of duties) to avoid such an incident.
Loss of a CA's private signing key may also be problematic. The CA
would not be able to produce CRLs or perform normal key rollover.
CAs SHOULD maintain secure backup for signing keys. The security of
the key backup procedures is a critical factor in avoiding key
The availability and freshness of revocation information affects the
degree of assurance that ought to be placed in a certificate. While
certificates expire naturally, events may occur during its natural
lifetime which negate the binding between the subject and public key.
If revocation information is untimely or unavailable, the assurance
associated with the binding is clearly reduced. Relying parties
might not be able to process every critical extension that can appear
in a CRL. CAs SHOULD take extra care when making revocation
information available only through CRLs that contain critical
extensions, particularly if support for those extensions is not
mandated by this profile. For example, if revocation information is
supplied using a combination of delta CRLs and full CRLs, and the
delta CRLs are issued more frequently than the full CRLs, then
relying parties that cannot handle the critical extensions related to
delta CRL processing will not be able to obtain the most recent
revocation information. Alternatively, if a full CRL is issued
whenever a delta CRL is issued, then timely revocation information
will be available to all relying parties. Similarly, implementations
of the certification path validation mechanism described in section 6
that omit revocation checking provide less assurance than those that
The certification path validation algorithm depends on the certain
knowledge of the public keys (and other information) about one or
more trusted CAs. The decision to trust a CA is an important
decision as it ultimately determines the trust afforded a
certificate. The authenticated distribution of trusted CA public
keys (usually in the form of a "self-signed" certificate) is a
security critical out-of-band process that is beyond the scope of
In addition, where a key compromise or CA failure occurs for a
trusted CA, the user will need to modify the information provided to
the path validation routine. Selection of too many trusted CAs makes
the trusted CA information difficult to maintain. On the other hand,
selection of only one trusted CA could limit users to a closed
community of users.
The quality of implementations that process certificates also affects
the degree of assurance provided. The path validation algorithm
described in section 6 relies upon the integrity of the trusted CA
information, and especially the integrity of the public keys
associated with the trusted CAs. By substituting public keys for
which an attacker has the private key, an attacker could trick the
user into accepting false certificates.
The binding between a key and certificate subject cannot be stronger
than the cryptographic module implementation and algorithms used to
generate the signature. Short key lengths or weak hash algorithms
will limit the utility of a certificate. CAs are encouraged to note
advances in cryptology so they can employ strong cryptographic
techniques. In addition, CAs SHOULD decline to issue certificates to
CAs or end entities that generate weak signatures.
Inconsistent application of name comparison rules can result in
acceptance of invalid X.509 certification paths, or rejection of
valid ones. The X.500 series of specifications defines rules for
comparing distinguished names that require comparison of strings
without regard to case, character set, multi-character white space
substring, or leading and trailing white space. This specification
relaxes these requirements, requiring support for binary comparison
at a minimum.
CAs MUST encode the distinguished name in the subject field of a CA
certificate identically to the distinguished name in the issuer field
in certificates issued by that CA. If CAs use different encodings,
implementations might fail to recognize name chains for paths that
include this certificate. As a consequence, valid paths could be
In addition, name constraints for distinguished names MUST be stated
identically to the encoding used in the subject field or
subjectAltName extension. If not, then name constraints stated as
excludedSubTrees will not match and invalid paths will be accepted
and name constraints expressed as permittedSubtrees will not match
and valid paths will be rejected. To avoid acceptance of invalid
paths, CAs SHOULD state name constraints for distinguished names as
permittedSubtrees wherever possible.