Network Working Group D.Pinkas(Bull) INTERNET-DRAFT July 2005 Expires January 2006 Target Category: not intended to be published as an RFC Conforming CRL validation for relying parties Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The text currently present in section 6.3 from RFC 3280 is dedicated to CRL validation. This text needs to be more detailed to explain exactly how it can made be sure that a CRL is issued by the right entity. In addition, a text dedicated to the characteristics that conforming applications MUST support needs to be provided: the current text covers the most complex case and is too complicated to be easily simplified. Text is proposed to be included in 3280bis and to partially replace section 6.3 . Pinkas [Page 1] INTERNET DRAFT CRL Validation July 2005 1. Introduction Section 6.3 from RFC 3280 [1] covers many features that are not required to be supported by conforming relying party applications. According to section 5, conforming applications are NOT REQUIRED to support processing of delta CRLs, or CRLs with a scope other than all certificates issued by one CA. According to section 5.2.5, conforming implementations are NOT REQUIRED to support the CRL Issuer Distribution Point extension (IDP) that MAY be present in a CRL. According to section 4.2.1.14, this profile RECOMMENDS to support the CRL distribution points extension. So the two cases where this extension is present and not present need to be covered. Its also currently unclear to know which key shall be used to verify a CRL and how it can be made sure that this key is the right one. The current text which covers the most complicated case should be reviewed and aligned with the proposed text since it contains many points to be fixed (e.g. incorrect initial variables, insufficient output variables, insufficient tests, etc ...). The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119 [STDWORDS] 2. Scope The text below is a proposal to clarify the above issues. The section numbering of RFC 3280 has been kept below. The next section of this document (i.e. Security considerations )is numbered section 3. The proposed text is as follows: 6.3 CRL Validation This section describes the steps necessary to determine if a certificate is not revoked, revoked, or revoked with an on hold status when CRLs are the revocation mechanism used by the certificate issuer. Conforming applications are NOT REQUIRED to support processing of delta CRLs, or CRLs with a scope other than all certificates issued by one CA. Pinkas [Page 2] INTERNET DRAFT CRL Validation July 2005 According to section 5.2.5, conforming implementations are NOT REQUIRED to support the Issuer Distribution Point extension (IDP) that MAY be present in a CRL. According to section 4.2.1.14, this profile RECOMMENDS to support the CRL distribution points extension. So the two cases where this extension is present and not present are covered. 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 same result. This algorithm assumes that a certification path has already been constructed and that it is only needed to verify that none of the certificates from that revocation path is revoked. In order to simplify the description, the algorithm focuses on the last certificate from the certification path, called the target certificate, but the same checks MUST be done on every certificate from the certification path. This algorithm assumes that all of the available CRLs are accessible in a local cache, whether or not CRL DP extensions have been used to fetch them. Further, if the next update time of a CRL has passed, the algorithm assumes that a mechanism to fetch a current available CRL, if any is available , and place it in the local CRL cache is existing. 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 and, if indicated, the revocation reason. In order to simplify the description of the algorithm, the description is first limited to the case of conforming applications. These applications do NOT need to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA, nor to support the processing of the Issuer Distribution Point extension (IDP) from CRLs. 6.3.1 Revocation Inputs To support revocation processing, the algorithm requires two inputs: (a) the target certificate. The basicConstraints extension is used to determine whether the supplied certificate is associated with a CA or an end entity. Pinkas [Page 3] INTERNET DRAFT CRL Validation July 2005 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. (b) certificates from the certification path: all the certificates from the certification path to be validated MUST be known. 6.3.2 Initialization and Revocation State Variables To support CRL processing, the algorithm requires the following two state variables: (a) cert_revoc_status: This variable contains the revocation status of the certificate. This variable may be assigned one of the following three values: REVOKED, NOT_REVOKED or UNKNOWN. This variable is initialized to UNKNOWN. (b) revoc_reason: This variable contains the revocation reason. This variable is initialized to an empty value. 6.3.3 CRL Processing This algorithm begins by assuming that the revocation status of the target certificate is UNKNOWN. The algorithm checks one or more CRLs until either the certificate revocation status is determined, if possible, to be REVOKED or NOT_REVOKED. 6.3.3.1 CRL Processing start for all applications It is first necessary to select a candidate CRL and then verify that this CRL is adequate for the target certificate. The candidate CRL MUST first be selected in the following way: (a) If the target certificate does not include a CRL DP extension, then the candidate CRL MUST have the following properties: (1) The issuer field from the CRL MUST be identical to the issuer field from the target certificate. (2) The signature from the CRL MUST be verified using an issuing key from the CA that has issued the target certificate. Pinkas [Page 4] INTERNET DRAFT CRL Validation July 2005 NOTE: This key may be the same key as the key used to issue the target certificate, but it may be a different key. In the later case, the same sequence of CA DNs, up to the same trust anchor, MUST be used. (3) The thisUpdate field from the CRL MUST be both greater than the notBefore field from the validity field of the target certificate and smaller than the notAfter field from the validity field of the target certificate. If several CRLs in the local cache satisfy these conditions, then the CRL that has the thisUpdate field closest to the current time SHALL be chosen. (b) If the target certificate includes a CRL DP extension with the cRLIssuer field present, then the candidate CRL MUST have the following properties: (1) The issuer field from the CRL MUST be identical to one of the values contained the cRLIssuer field from CRL DP extension of the target certificate. (2) A CRL Issuer certificate issued by the same CA that has issued the target certificate MUST be found. That certificate MUST have the cRLSign bit set, and MUST include in its subject field the same DN as the one of the DNs present in the crLIssuer field and MUST be within its validity period. NOTE: The key used to sign the CRL Issuer certificate may be the same key as the key used to issue the target certificate, but it may be a different key. In the later case, the same sequence of CA DNs, up to the same trust anchor, MUST be used. (3) The signature from the CRL MUST be verified using the key found in the subjectPublicKeyInfo field from the CRL Issuer certificate. (4) The thisUpdate field from the CRL MUST be both greater than the notBefore field from the validity field of the target certificate and smaller than the notAfter field from the validity field of the target certificate. If several CRLs in the local cache satisfy these conditions, then the CRL that has the thisUpdate field closest to the current time SHALL be chosen. If no CRL has the above properties, then the variables keep their initial values and the algorithm terminates. 6.3.3.2 CRL Processing for conforming applications If one CRL with the above properties may be found, then look for a CRL entry where the userCertificate field matches the certificate serial number of the target certificate : Pinkas [Page 5] INTERNET DRAFT CRL Validation July 2005 (a) if such an entry is found, then make sure that this CRL entry does not include a CRL entry extension that is critical and not recognized and then set the cert_revoc_status variable to REVOKED. In that case, if the CRL entry extension " reasonCode " is present in that CRL entry, then set the revoc_reason variable to the value contained in that CRL entry extension and the algorithm terminates. NOTE: if that CRL entry includes a CRL entry extension that is critical and not recognized, then the CRL SHALL be discarded, the variables keep their initial values and the algorithm terminates. (b) if such an entry cannot be found, then check if the nextUpdate field is less than the current time and, if this is the case, then set the cert_revoc_status variable to UNKNOWN and the algorithm terminates; otherwise set the cert_revoc_status variable to NOT_REVOKED and the algorithm terminates. 6.3.3.3. CRL Processing for applications supporting Certificate Issuer CRL entry extensions Conforming applications are NOT REQUIRED to support the issuing distribution point extension (IDP) which is a critical CRL extension. As a consequence they are NOT REQUIRED to support the indirectCRL boolean from the IDP extension that indicates that the scope of the CRL includes certificates issued by more than one authority. However, the following applies when the IDP extension is present and the indirectCRL boolean is set to TRUE. In such a case the CRL will contain one or more certificate issuer CRL entry extension. If one CRL with the properties from section 6.3.3.1 has been found, then the following applies : Look for one or more CRL entry where the userCertificate field matches the certificate serial number of the target certificate. If no entry can be found, then check if the nextUpdate field is less than the current time and, if this is the case, then set the cert_revoc_status variable to UNKNOWN and the algorithm terminates; otherwise set the cert_revoc_status variable to NOT_REVOKED and the algorithm terminates. If one or more entry can be found, then, for each found entry, check if the entry contains a Certificate Issuer CRL entry extension : (1) If it does, then check if its content matches the content of the issuer field of the target certificate. Pinkas [Page 6] INTERNET DRAFT CRL Validation July 2005 - If it does, then set the cert_revoc_status variable to REVOKED and if the CRL entry extension "reasonCode" is present in that CRL entry, then set the revoc_reason variable to the value contained in that CRL entry extension and the algorithm terminates. - If it does not, then : (i) check if there exists a previous CRL entry: - If there is no previous CRL entry, then this is an error in the structure of the CRL and the algorithm terminates. - otherwise check if that CRL entry contains a Certificate Issuer CRL entry extension : - If it does, then check if its content matches the content of the issuer field of the target certificate. - If it does, then set the cert_revoc_status variable to REVOKED and if the CRL entry extension "reasonCode" is present in that CRL entry, then set the revoc_reason variable to the value contained in that CRL entry extension and the algorithm terminates. - If it does not, and if each found entry has been processed, then set the cert_revoc_status variable to NOT_REVOKED and the algorithm terminates. - If it does not, then proceed with (i). (2) If it does not, then proceed with (i). 6.3.3.4. CRL Processing for applications supporting delta CRLs Conforming applications are NOT REQUIRED to support delta CRLs. However, for applications supporting delta CRLs, as well as the previous features, the following applies: [Text to be provided, e.g. by David Cooper] Pinkas [Page 7] INTERNET DRAFT CRL Validation July 2005 3 Security considerations 1. A CA is free to allocate the DN of an entity as it wishes. Therefor name collision may happen: the same DN, as assigned by two different CAs, may designate two different entities. Name collision between CA names is a particular concern and the proposal takes care of such a issue, if an additional requirement that applies to CRL Issuers issuing indirect CRLs (and which is currently not present) in RFC 3280 is added. A CRL Issuer is delegated the responsibility to generate and publish the revocation status information for the certificates issued by a CA by accepting this duty and by receiving a CRL Issuer certificate from the CA that delegated that responsibility. The CRL Issuer name will be assigned by the CA and name collision between CRL Issuer names is not an issue. However, a CRL Issuer shall not accept this duty, if it already agreed to perform that task for another CA that has the same DN. This avoids the possible confusion between CA names that may be contained in the Certificate Issuer CRL entry extension from an indirect CRL. 2. RFC 3280 is dedicated to the case where CRL Issuer receives the delegation to generate and issue certificate revocation information from CAs. The OCSP model recognizes another case, where the relying party is directly trusting a given OCSP responder independently of what CAs are saying. In the same way, a model where an entity is directly trusted by some relying parties, for some kind of certificates, to issue CRLs for some CAs, could exist, but that model is not supported nor described in RFC 3280. In such an hypothetical case, the current CRL structure of an indirect CRL might be used, provided that additional local trust conditions are defined in a validation policy. Such definitions are outside the scope of RFC 3280. 4. IANA Considerations Not applicable 5. References 5.1 Normative references [1] IETF RFC 3280 (2002): "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". Pinkas [Page 8] INTERNET DRAFT CRL Validation July 2005 [STDWORDS] IETF RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2 5.2 Informative references None. 6. Authors' address Denis Pinkas Bull S.A. Rue Jean-Jaures 78340 Les Clayes sous Bois CEDEX FRANCE EMail: Denis.Pinkas@bull.net Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer This document and the information contained herein are provided on An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Pinkas [Page 9] INTERNET DRAFT CRL Validation July 2005 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Pinkas [Page 10]