RFC 3280
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
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 validation procedure. 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 invalid.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 revocation status. (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 entity.6.3.2 Initialization and Revocation State Variables
To support CRL processing, the algorithm requires the following state variables: (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 processed.
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 codes.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
the DP.
(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
asserted.
(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
not asserted.
(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
issuer.
(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
extension.
(3) Verify that the delta CRL authority key identifier
extension matches complete CRL authority key identifier
extension.
(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
extension.
(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
UNREVOKED.
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
then the revocation status has been determined, so return
cert_status.
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.
7 References
[ISO 10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic
Multilingual Plane.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[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, March 1995. [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 1999. [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, 1997-02-06.
[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 December, 1995. [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 implications. 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 CAs. 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 compromise. 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 support it. 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 this specification. 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 rejected. 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.
(next page on part 5)
