HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:26:09 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 27 Apr 1998 14:28:00 GMT ETag: "304c2f-3dcb-354495f0" Accept-Ranges: bytes Content-Length: 15819 Connection: close Content-Type: text/plain PKIX Working Group P. Hallam-Baker (VeriSign) Internet Draft W. Ford (VeriSign) expires in six months April 21, 1998 Internet X.509 Public Key Infrastructure OPEN CRL DISTRIBUTION PROCESS (OpenCDP) 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 mechanisms for determining if a public-key certificate is valid or revoked, using CRL partitions. These mechanisms are considered superior to the CRL Distribution Points (CDP) mechanism defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons. In particular, OpenCDP: (a) accommodates dynamic partitioning as opposed to fixed partitioning; (b) better supports use of certificates in multiple environments with different CRL stores; (c) includes a means for improving cachability and timeliness characteristics with CRLs; and (d) is believed not to be encumbered by the patent claims applying to CDPs. 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. 1. 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. CRL partitioning 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 CDP mechanism merged these two functions into one mechanism. In contrast, the OpenCDP mechanism separates these two functions and thereby achieves various benefits. First, the location function becomes a non-security-critical function, in that location information does not need to be embedded into a certificate and signed by the CA. Among other benefits, this helps reduce certificate sizes. Second, 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 structures, certificate serial number ranges, or date ranges. Such CRL partition definitional criteria can be changed dynamically by the CA if needed, without affecting the issued certificate base. Third, because the location information is not in the certificate, it is possible to change that information for use of the certificate in different environments, e.g., change it to point to a different CRL store when traversing a firewall. Fourth, given the provision of an attribute external to a certificate for conveying CRL location information, the same attribute can convey other useful revocation information such as a pointer to an OCSP server. The OpenCDP mechanism employs a single X.509 CRL extension and two attribute types for use in directories or in protocol construction. No certificate extensions are needed except that, if indirectCRLs are to be implemented, there is a need for a new revocationIssuer extension to implement the function of the cRLIssuer element of the cRLDistributionPoints extension (which is no longer used in PKIX) - see later section on Revocation Issuer Extension. 2. CRL LOCATION FUNCTION A certificate-using system that uses partitioned CRLs needs to locate an appropriate CRL for a given certificate. Information on CRL location does not need to be inside a certificate. Furthermore, it can be advantageous not to have such information within certificates, in order to allow for changing of the partition configuration or storage locations after certificates are issued. Therefore, OpenCDP explicitly forbids the inclusion of location information within certificates. CRL location will not always require standardized protocol features, since it can often be handled by local logic, e.g., a CRL "map" (or pointer thereto) for an enterprise, based on user names, might be incorporated into a configuration file in end-user products of that enterprise. However, it is advantageous to have a standard format for specifying such information, for use in protocols and directory entries. This specification therefore defines a standard attribute type for holding revocation information, including CRL location information. This attribute type and typical ways of using it are described below under Revocation Information Attribute. This specification also defines another mechanism for locating CRLs. This involves a list of CRLs stored in the CA's directory entry. This mechanism is described below under the CRL List Attribute. 3. CERTIFICATE-CRL VALIDATION FUNCTION The scope of a 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) A time range for certificate issuance (more precisely, for the notBefore time in the certificate); (e) End-user certificate vs CA-certificate. 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". (5) All of the certificates of a CA with a notBefore date in April, 1998. The scope of a CRL is indicated within that CRL using the following CRL extension: cRLScope EXTENSION ::= { SYNTAX CRLScopeSyntax IDENTIFIED BY { } } CRLScopeSyntax ::= SEQUENCE { serialNumberRange [0] NumberRange OPTIONAL, subjectKeyIdRange [1] NumberRange OPTIONAL, nameSubtrees [2] GeneralNames OPTIONAL, notBeforeRange [3] NotBeforeRange OPTIONAL, onlyContainsUserCerts [4] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [5] BOOLEAN DEFAULT FALSE, onlySomeReasons [6] ReasonFlags OPTIONAL, indirectCRL [7] BOOLEAN DEFAULT FALSE } NumberRange ::= SEQUENCE { startingNumber INTEGER, endingNumber INTEGER, modulus INTEGER OPTIONAL } notBeforeRange ::= SEQUENCE { startingNotBeforeTime GeneralizedTime, endingNotBeforeTime GeneralizedTime } 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. If the notBeforeRange element is present, certificates with a notBefore time equal to or greater than startingNotBeforeTime and less than endingNotBeforeTime are considered to be within scope of the CRL. The fields onlyContainsUserCerts, onlyContainsCACerts, onlySomeReasons and indirectCRL are used as described for the X.509 issuingDistributionPoint extension. (Note that the issuingDistributionPoint extension and cRLScope extension conflict with each other -- the issuingDistributionPoint extension is not permitted in a CRL which contains a cRLScope extension.) 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 an issuingDistributionPoint extension, then such CRL is inconsistent with PKIX and should not be used. (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, nameSubtrees, and notBeforeRange scopes, and is consistent with onlyContainsUserCerts and onlyContainsCACerts if present. (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. REVOCATION INFORMATION ATTRIBUTE Attributes of this type are used to hold CRL location information or other information pertaining to revocation status of a certificate. Ways of using this attribute type include the following: (a) In a directory entry that holds a certificate. The revocation information is stored in an attribute accompanying the certificate attribute and when anyone retrieves a certificate they can also retrieve the revocation information. [Note: This attribute type needs to be included in the PKIX LDAP schema.] (b) When a certificate is transported by CMS (or any other PKCS#7-based protocol), the corresponding revocation information can be conveyed in an unauthenticated attribute. (c) When a certificate is transported by ISAKMP, the corresponding revocation information can be conveyed as an ISAKMP payload. (d) When a certificate is transported as part of a TLS/HTTP exchange, the corresponding revocation information can be conveyed in a HTTP header. (e) When a certificate is issued using CRMF or PKCSReq (see [CRMF] or [CMMF] respectively), the corresponding revocation information can be conveyed as an unauthenticated attribute in the "response" field of a CertRep message body (see [CMMF] for details on CertRep syntax.) As new IETF protocols are defined, it is anticipated that the protocols will make explicit provision for conveying revocation information along with certificates. Note that there may be circumstances in which an intermediary (e.g., firewall) may change revocation information, such as CRL location pointers, in transit. Following is the definition of the Revocation Information attribute type: revocInfo ATTRIBUTE ::= { WITH SYNTAX RevocInfo ID } RevocInfo ::= SEQUENCE { certIssuer GeneralNames, certSerialNumber INTEGER, infoLocations [0] SEQUENCE SIZE (1..MAX) OF InfoLocation OPTIONAL, extensions [1] SEQUENCE OF INSTANCE OF TYPE-IDENTIFIER OPTIONAL } InfoLocation ::= SEQUENCE { locator GeneralNames, infoType InfoType DEFAULT crl, reasons ReasonFlags OPTIONAL } InfoType ::= ENUMERATED { crl (0), oCSPServer (1) } ReasonFlags ::= BIT STRING { unused (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6) } For the semantics of the reasons field, see the definition of the CRL Distribution Points certificate extension in X.509. Certification authorities that are conformant to OpenCDP must not insert a revocation information attribute within a certificate. 5. CRL LIST ATTRIBUTE This optional attribute type is for use by a CA in presenting a list of available CRLs to certificate-users. This list can be stored in the CA's directory entry. (That entry can be determined from issuer name or an issuerAltName value.) The list is signed and there is provision for inclusion of a last-update time/date for every CRL. A CA is able to use this mechanism as follows. A new 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 CRL List attribute type: cRLList ATTRIBUTE ::= { WITH SYNTAX CRLList ID } CRLList ::= SIGNED { SEQUENCE { signature AlgorithmIdentifier, issuer GeneralNames, thisUpdate GeneralizedTime, nextUpdate GeneralizedTime OPTIONAL, cRLLocators CRLLocators }} CRLLocators ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { locator GeneralName, cRLScope CRLScopeSyntax, lastUpdate GeneralizedTime OPTIONAL } The signature, issuer, thisUpdate, and nextUpdate fields are interpreted similarly as to in a CRL. The lastUpdate field is the value of the thisUpdate field in the most-recently issued referenced CRL. 6. REVOCATION ISSUER EXTENSION This noncritical certificate extension is used by a CA to indicate that it has delegated authority to one or more other entities to issue and sign CRLs or sign OCSP responses on its behalf. revocationIssuer EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY { } } 7. INTELLECTUAL PROPERTY STATEMENT The authors have no knowledge of any pending or granted patents covering the techniques described. 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