PKIX Working Group P. Hallam-Baker (VeriSign) Internet Draft W. Ford (VeriSign) Expires in six months August 7, 1998 Internet X.509 Public Key Infrastructure ENHANCED CRL DISTRIBUTION OPTIONS Status of this Memo This document is 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (date). All Rights Reserved. Abstract This Internet Draft specifies some proposed enhancements to the X.509 CRL mechanism used to determine if a public-key certificate is valid or revoked. These enhancements provide advantages over existing CRL mechanisms, including those that use static CRL partitioning as defined in ISO/IEC 9504-8/ITU-T Rec. X.509. In particular, the mechanisms proposed can: (a) reduce the need for unnecessarily fetching unchanged CRLs, thereby greatly expanding the value of caching CRLs; (b) allow CRL timeliness to be improved; (c) accommodate dynamic partitioning as opposed to fixed partitioning; (d) better support use of certificates in multiple environments with different CRL stores. This document is submitted for consideration as the basis of possible future IETF standardization. Please send comments on this document to the ietf-pkix@imc.com mail list. Acknowledgments The following individuals made significant contributions to the development of this proposal: Arn Schaeffer, Mahi de Silva, Michael Myers, and Alex Deacon of VeriSign, Brian LaMacchia and Barbara Fox of Microsoft, and Jeff Weinstein of Netscape. Ideas developed by Carlisle Adams of Entrust, regarding reuse of CRL syntax for CRL lists and the use of delta CRLs, have also been incorporated and are gratefully acknowledged [ADAMS98]. 1. BACKGROUND The draft (OpenCDP) described some new approaches to managing CRLs with the goal of improving various characteristics of CRL information dissemination without using explicit CRL pointers in certificates (such pointers were, at that time, deprecated by the IETF). Since CRL pointers are no longer deprecated, this derivative draft focuses on exploiting the technical advantages of the OpenCDP mechanisms, regardless of use or non-use of explicit CRL pointers. The main change from the OpenCDP draft is elimination of the Revocation Information Attribute (which is no longer of importance), but keeping the CRL Scopes and CRL List concepts, merging the former with CRL Distribution Points (CDPs) and exploiting the CRL List concept (now renamed Status Referrals) to maximize cachability and timeliness characteristics overall. Interaction with delta-CRL mechanisms is also incorporated. This draft takes into account comments made both on the PKIX list and in other fora. In particular the CRL List mechanism is now realized as a CRL extension. 2. PRINCIPLES A certification authority may issue distinct CRLs for different subsets of its certificate population. The partitioning may be based on various requirements, such as the need to partition evenly for pure performance purposes, the need to produce separate CRLs on the basis of revocation reason, or the need to group together revocation information for related entities, e.g., all the servers or clients of one organization. Indirect CRLs may be issued by entities other than the applicable certificate-issuing CA. Indirect CRLs may also be partitioned. Using a CRL involves two functions: (a) a CRL location function, which allows for a certificate-using system to find a CRL applicable to a given certificate; (b) a certificate-CRL validation function, which provides for the certificate-using system to confirm that a CRL to hand is indeed an applicable CRL for the certificate under consideration. The original CRL/CDP mechanism merged these two functions into one mechanism. However, there can be benefit in separating these functions: (1) Since the location function does not inherently require a CA signature, omitting it from the certificate may help reduce certificate sizes. (2) By making the location function a server- or directory-lookup function, a signed status indicator (last update time) can be associated with each CRL, averting the unnecessary retrieval of unchanged CRLs. Given that the signed location/status information is of very modest size compared with CRLs, this information can be updated much more frequently that CRLs, allowing important revocations to be effectively posted much more quickly than without this mechanism. (3)The certificate-CRL validation function can be made a dynamic mapping relationship, as opposed to the static relationship afforded by CDPs. For example, this function can be based on such certificate population characteristics as subject name subtrees or certificate serial number ranges. Such CRL partition definitional criteria can be changed dynamically by the CA if needed, without affecting the issued certificate base. This benefit is of particular importance when a CRL is to be stored using a medium with a severely limited capacity such as a smartcard. (4) Because the location information does not have to be in the certificate, it is possible to change that information for use of the certificate in different environments. This document defines two X.509 CRL extensions: The Status Referrals extension designed primarily to support the CRL location function and the CRL Scope extension designed primarily to support the certificate- CRL validation function. 2.1 CRL Location Function A certificate-using system that uses (possibly partitioned) CRLs needs to locate an appropriate CRL for a given certificate. Information on CRL location can be obtained in various ways, including: (a) Via a direct pointer in a CRL Distribution Points extension in the certificate; (b) Via a Status Referrals extension in a CRL obtained from a directory or server whose location is indicated by the name of the issuing CA; (c) Via a Status Referrals extension in a CRL obtained from a directory or server whose location, and an indication of its trustworthiness, is indicated by local domain configuration data; or (d) Via unspecified local means. 2.2 Certificate-CRL Validation Function The scope of a CRL (or CRL partition) can be defined by specifying ranges on any of the fields in a certificate. For Internet (PKIX) purposes, it is proposed that the scoping be limited to the following criteria or any combination thereof: (a) A certificate serial number range; (b) A subject key identifier range; (c) One or more subject name subtrees; (d) End-user certificate vs CA-certificate; (e) Certificates containing a particular CRL Distribution Point name. Examples of CRL partition scopes are: (1) All of the certificates of a CA with serial numbers between 10,000 and 19,999 inclusive. (2) All of the certificates of a CA with subject names commencing: C=US, O=foobar, ... (3) All of the certificates of a CA with subject DNS names: .foobar.com. (4) All of the certificates of a CA for the subject: C=US, O=foo, OU=bar, CN=myname. 3. CRL SCOPE EXTENSION The scope of a CRL is indicated within that CRL using the following CRL extension. In order to prevent a CRL substitution attack against an application which does not support the scope extension, the scope extension MUST be marked critical. cRLScope EXTENSION ::= { SYNTAX CRLScopeSyntax IDENTIFIED BY { } } CRLScopeSyntax ::= SEQUENCE SIZE (1..MAX) OF PerCAScope PerCAScope ::= SEQUENCE { cAName [0] GeneralName OPTIONAL, distributionPoint [1] DistributionPointName OPTIONAL, onlyContainsUserCerts [2] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [3] BOOLEAN DEFAULT FALSE, onlySomeReasons [4] ReasonFlags OPTIONAL, serialNumberRange [5] NumberRange OPTIONAL, subjectKeyIdRange [6] NumberRange OPTIONAL, nameSubtrees [7] GeneralNames OPTIONAL } NumberRange ::= SEQUENCE { startingNumber INTEGER, endingNumber INTEGER, modulus INTEGER OPTIONAL } The potential presence of multiple PerCAScope constructs provides for support for indirect CRLs, in which a CRL issuer provides revocation status information for multiple CAs. If cAName is omitted, it defaults to the CRL issuer name. Separate PerCAScope constructs MUST relate to distinct CAs. The serialNumberRange element, if present, is used as follows. When a modulus value is present, the serial number is reduced modulo the given value before checking for presence in the range. Then, certificates with a (reduced) serial number equal to or greater than startingNumber and less than endingNumber are considered to be within scope of the CRL. The subjectKeyId range element, if present, is interpreted the same as serialNumberRange, except that the number used is the value in the certificate’s subjectKeyIdentifier extension, interpreted as an unsigned integer. Conventions for the nameSubtrees option are the same as for the Name Constraints extension. The fields onlyContainsUserCerts, onlyContainsCACerts, and onlySomeReasons are used as described for the X.509 issuingDistributionPoint extension. (Note that the issuingDistributionPoint extension and cRLScope extension can conflict with each other and are not intended to be used together.) When a certificate-using system uses a CRL to check status of a certificate, it SHOULD check that the CRL scope includes the certificate, as follows: (a) If the CRL contains both an issuingDistributionPoint extension and a cRLScope extension, then a certificate falls within the scope of the CRL if and only if it meets the criteria of both extensions. (b) If the CRL contains a cRLScope extension, then the certificate- using system MUST check that the certificate falls within the scope indicated by the intersection of the serialNumberRange, subjectKeyIdRange, and nameSubtrees scopes, and is consistent with distributionPoint, onlyContainsUserCerts and onlyContainsCACerts if present, for the PerCAScope construct for the certificate issuer. (c) If the CRL contains neither an issuingDistributionPoint nor cRLScope extension, then the scope is the entire scope of the CA, and the CRL may be used for any certificate from that CA. 4. STATUS REFERRALS EXTENSION This CRL extension is for use in CRLs distributed by a CA or locally- trusted server in identifying other revocation sources (CRLs or OCSP- servers) available to certificate-users. The CRL will typically be stored in a directory entry or at a specified URL, or it may be distributed along with a certificate in a communications protocol. A status referral makes provision for inclusion of a last-update time/date for every referenced CRL. A CA is able to use this mechanism as follows. A new, authenticated CRL list is reissued periodically, typically with a relatively high reissue frequency (in comparison with CRL reissue frequencies). A certificate user, on obtaining this list, can quickly determine if cached copies of CRLs are still up-to-date. This eliminates much unnecessary retrieval of CRLs. Furthermore, by using this mechanism, certificate users become aware of CRLs issued by the CA between its usual update cycle, thereby improving the timeliness of the CRL system. Following is the definition of the Status Referrals extension type: statusReferrals EXTENSION ::= { SYNTAX StatusReferrals IDENTIFIED BY } StatusReferrals ::= SEQUENCE SIZE (1..MAX) OF StatusReferral StatusReferral ::= CHOICE { cRLReferral [0] CRLReferral, deltaReferral [1] DeltaReferral, oCSPReferral [2] OCSPReferral} CRLReferral ::= SEQUENCE { issuer GeneralName OPTIONAL, location GeneralName OPTIONAL, deltaLocation GeneralName OPTIONAL, cRLScope CRLScopeSyntax, lastUpdate GeneralizedTime OPTIONAL, lastDelta GeneralizedTime OPTIONAL} DeltaReferral ::= GeneralName OCSPReferral ::= SEQUENCE { issuer GeneralName OPTIONAL, location GeneralName OPTIONAL } In both the CRL and OCSP referral cases, the issuer field identifies the entity that signs the CRL or status response; this defaults to the issuer name of the encompassing CRL. The location field gives an address at which the referral is to be directed, and defaults to the same value as the issuer name. In a CRL referral, the deltaLocation field gives an optional alternative address from which a delta CRL may be obtained. The lastUpdate field is the value of the thisUpdate field in the most recently issued referenced CRL. The optional lastDelta field is the value of the thisUpdate field in the most recently issued referenced delta CRL; it MUST be omitted if deltaLocation is not present. The deltaReferral option shall be used only to indicate, in a CRL, the location for retrieving delta CRLs for that CRL. If the extension contains only the deltaReferral option, then it SHOULD be flagged noncritical. Otherwise, it MUST be flagged critical, and the certificate user SHOULD NOT assume the revocation status of a certificate on the basis of this CRL alone. 5. EXAMPLES OF USE Some examples of use of the above mechanisms follow: (1) Requirement: A CA does not have relationships with other CRL issuers (i.e., no indirect CRLs) but wants to have flexibility in how it partitions its certificate space across CRLs, wants to minimize certificate contents, and wants to improve revocation-checking timeliness characteristics for its clients. Solution: The CA stores, in the CRL attribute of its directory entry, a referencing CRL which contains, rather than specific certificate revocation entries, pointers to URLs at which other CRLs are available for various partitions (which may dynamically vary). The referencing CRL, which is updated every 15 minutes, includes lastUpdate values; this reduces the retrieval load on clients that have timeliness requirements and CRL caching capabilities. (2) Requirement: An enterprise wants to operate its own certificate- status services for its clients, including status-checking for multiple external CAs with which the enterprise interoperates. Solution: The enterprise operates a server which issues its own CRLs covering all of the certificates of concern, using the indirect CRL capabilities afforded by Status Referrals. Timeliness demands may be supported. The address of the enterprise server is installed in all the enterprise clients. (3) Requirement: A CA has multiple fixed CRL partitions, and wishes to also issue delta CRLs for each partition to reduce data transfer loads on busy clients. Solution: The CA includes in each certificate a CDP pointer to the location of the applicable CRL partition. Each such CRL contains a noncritical Status Referrals extension with a DeltaReferral value, which clients may optionally use to subsequently fetch delta CRLs for that CRL. 6. SECURITY ISSUES An attacker might use a CRL with partial scope to cause an application which does not implement the scope extension to erroneously believe that a certificate was valid when it had in fact been revoked. For this reason the CRL Scope extension MUST be marked critical. 7. INTELLECTUAL PROPERTY STATEMENT The authors have no knowledge of any pending or granted patents covering the techniques described, except for the Entrust patent on CDPs. The mechanisms described are not inherently dependent on CDPs, and can be used in a way which may not require licensing of the Entrust patent. 8. REFERENCES [ADAMS98] Carlise Adams, Redirect CRL, Presentation to CRADA. May 1998 Author Addresses: Phillip Hallam-Baker VeriSign, Inc. 301 Edgewater Place, Suite 210 Wakefield, MA 01880 USA pbaker@verisign.com Warwick Ford VeriSign, Inc. 301 Edgewater Place, Suite 210 Wakefield, MA 01880 USA wford@verisign.com