INTERNET-DRAFT S. Santesson (Microsoft) Updates: 3280 Intended Category: Standards track Expires April 2007 October 2006 Validation Certificates in Certificate Revocation Lists 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. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This specification specifies a Certificate Revocation List (CRL) Extension for storage of X.509 certificates defined in RFC 3280. Certificates stored in this extension may be used to construct a valid certificate path from a CRL to an appropriate trust anchor. Santesson [Page 1] INTERNET DRAFT Validation Certificates in CRLs October 2006 1. Introduction This specification addresses the issue of how to access certificates necessary to construct a valid certificate path from a CRL to an appropriate trust anchor in cases where the certificate being checked for revocation and the associated CRL being used is signed by different keys. This situation may occur when indirect CRLs, as specified in RFC 3280 [N2], are used or when a CA due to key-change provides revocation services by issuing CRLs signed with a new key that covers revocation of certificates signed with an older CA key. In these cases the certificate path for the certificate being checked for revocation does not provide all certificates needed to validate the signature of the CRL. One solution to this problem is provided in RFC 4325 which specifies use of the Authority Information Access extension in CRLs. RFC 4325 enables a CRL checking application to use the access method (id-ad- caIssuers) to locate certificates that may be useful in the construction of a valid CRL issuer certification path to an appropriate trust anchor. The solution specified in RFC 4325 optimizes the problem with respect to CRL size, as the certificates are referenced by an access location pointer rather than stored in the CRL. This specification optimizes the problem with respect to the number of network access cycles needed to obtain necessary certificates by specifying a way to include complete validation certificates in the CRL. Which solution that is optimal depends on many properties such as CRL size, revocation checking frequency, caching, network speed, network latency and network load. Storing validation certificates in the CRL will in some situations provide important advantages such as: 1. Eliminate the second wire retrieval to obtain missing validation certificates for a CRL. This reduces the client time for doing the first revocation verification as network retrievals often dominate this time. In high latency networks the number of retrievals adds substantially more time to the verification process than expanding the size of the CRL with a few certificates. Santesson [Page 2] INTERNET DRAFT Validation Certificates in CRLs October 2006 2. CRL packaging for offline and historical revocation checking scenarios. CRLs can be pre-fetched (previously pulled/pushed to client machines prior to validation) to reduce validation time and to support offline revocation checking. Including the certificates in the CRL makes it easier to manage this scenario. Otherwise, it requires another layer to package the CRL plus certificates within the local environment. These benefits can in some cases be substantial as the added verification time due to extra network retrieval can cause timeouts in network protocols and since introduction of new packaging of CRLs for internal processing makes it harder to adapt some more advance CRL checking scenarios in existing application infrastructures. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [N1]. Santesson [Page 3] INTERNET DRAFT Validation Certificates in CRLs October 2006 2 Validation Certificates CRL extension This section defines the Validation Certificates CRL extension. This extension MAY be included in Certificate Revocation Lists defined in RFC 3280 [N2]. The Validation Certificates CRL extension has the following syntax: id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn } ValidationCertificates ::= SEQUENCE of Certificate This extension MUST NOT be marked critical. The CRL issuer MAY include certificates in this extension that can be useful to construct a valid certificate path from the CRL to a trusted root. 3 Security Considerations Any use of certificates provided in the Validation Certificates CRL extension, to validate signatures on a CRL, MUST be done according rules and conventions defined in RFC 3280. As such, relevant security considerations of RFC 3280 apply. 4 Normative References [N1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [N2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 7 IANA Considerations This document does not require any actions by IANA. Author's Address Stefan Santesson Microsoft Santesson [Page 4] INTERNET DRAFT Validation Certificates in CRLs October 2006 Finlandsgatan 30 164 93 KISTA Sweden EMail: stefans(at)microsoft.com Santesson [Page 5] INTERNET DRAFT Validation Certificates in CRLs October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. 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. Expires April 2007 Santesson [Page 6]