Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3280

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

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

ToP   noToC   RFC3280 - Page 80   prevText

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

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.
ToP   noToC   RFC3280 - Page 83
   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:
ToP   noToC   RFC3280 - Page 84
         (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.
ToP   noToC   RFC3280 - Page 85
   (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.
ToP   noToC   RFC3280 - Page 86
      (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.
ToP   noToC   RFC3280 - Page 87
   [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.
ToP   noToC   RFC3280 - Page 88
   [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
ToP   noToC   RFC3280 - Page 89
   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
ToP   noToC   RFC3280 - Page 90
   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
ToP   noToC   RFC3280 - Page 91
   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)

Next Section