[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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



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.


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.


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].


The draft <draft-ietf-pkix-ocdp-00.txt> (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

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.


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

(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

(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
(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:
(4)  All of the certificates of a CA for the subject:
        C=US, O=foo, OU=bar, CN=myname.


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   { <oid tbd> } }

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

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.


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 <oid tbd> }

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.


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


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.


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.


[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

   Warwick Ford
   VeriSign, Inc.
   301 Edgewater Place, Suite 210
   Wakefield, MA 01880