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)

                     <draft-ietf-pkix-ocdp-00.txt>


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.


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


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


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

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.


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

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.


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

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.


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


.  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