wdiff draft-ietf-pkix-ocdp-00.txt draft-ietf-pkix-ocdp-01.txt

PKIX Working Group P. Hallam-Baker (VeriSign)
Internet Draft W. Ford (VeriSign)

expires

Expires in six months April 21, August 7, 1998

Internet X.509 Public Key Infrastructure

OPEN

ENHANCED CRL DISTRIBUTION PROCESS (OpenCDP)

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

<draft-ietf-pkix-ocdp-01.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).

Abstract

This Internet Draft specifies mechanisms for determining some proposed enhancements to the X.509
CRL mechanism used to determine if a public-key certificate is valid or revoked, using CRL partitions.
revoked. These mechanisms
are considered superior to the enhancements provide advantages over existing CRL Distribution Points (CDP) mechanism
mechanisms, including those that use static CRL partitioning as defined
in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons. X.509. In particular, OpenCDP: the mechanisms
proposed can:

(a) accommodates 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;
(b)
(d) better supports support use of certificates in multiple environments with
different CRL stores;
(c) includes a means for improving cachability and timeliness
characteristics with CRLs; and
(d) stores.

This document is believed not to be encumbered by submitted for consideration as the patent claims applying to
CDPs. 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 <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
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 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 original CRL/CDP mechanism merged these two functions into one
mechanism. In
contrast, the OpenCDP mechanism separates However, there can be benefit in separating these two functions and
thereby achieves various benefits.

First, functions:

(1) Since the location function becomes a non-security-critical function,
in that location information does not need to be embedded into inherently require a
certificate and signed by CA
signature, omitting it from the CA. Among other benefits, this helps certificate may help reduce certificate
sizes.

Second,

(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 structures, subtrees or 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 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 is does not have to be 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 environments.

This document defines two X.509 CRL
store when traversing a firewall.

Fourth, given the provision of an attribute external extensions: The Status Referrals
extension designed primarily to a certificate
for conveying support the CRL location information, function and
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 Scope 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 designed primarily to
implement the function of the cRLIssuer element of support the
cRLDistributionPoints extension (which is no longer used in PKIX) - see
later section on Revocation Issuer Extension.

2. certificate-
CRL LOCATION FUNCTION validation function.

2.1 CRL Location Function

A certificate-using system that uses partitioned (possibly 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, obtained 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., various ways, including:

(a) Via a CRL "map" (or direct pointer thereto) for an enterprise, based on user names, might be
incorporated into in a configuration file CRL Distribution Points extension in end-user products of that
enterprise.

However, it is advantageous to have the
certificate;
(b) Via a standard format for specifying
such information, for use Status Referrals extension in protocols and directory entries. This
specification therefore defines a standard attribute type for holding
revocation information, including CRL obtained from a directory
or server whose location information. This
attribute type and typical ways is indicated by the name of using it are described below under
Revocation Information Attribute.

This specification also defines another mechanism for locating CRLs.
This involves the issuing CA;
(c) Via a list of CRLs stored Status Referrals extension in the CA's a CRL obtained from a directory entry. This
mechanism
or server whose location, and an indication of its trustworthiness, is described below under the CRL List Attribute.

3. CERTIFICATE-CRL VALIDATION FUNCTION
indicated by local domain configuration data; or
(d) Via unspecified local means.

2.2 Certificate-CRL Validation Function

The scope of a CRL partition (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) A time range for certificate issuance (more precisely, for the
notBefore time in the certificate);
(e) End-user certificate vs CA-certificate. 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,
C=US, O=foobar, ..." ...
(3) All of the certificates of a CA with subject DNS names
"<anything>.foobar.com". names:
<anything>.foobar.com.
(4) All of the certificates of a CA for the subject "C=US, subject:
C=US, O=foo, OU=bar, CN=myname".
(5) All of the certificates of a CA with a notBefore date in April,
1998. CN=myname.

3. CRL SCOPE EXTENSION

The scope of a CRL is indicated within that CRL using the following CRL
extension:
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 {
serialNumberRange
cAName [0] NumberRange GeneralName OPTIONAL,
subjectKeyIdRange
distributionPoint [1] NumberRange OPTIONAL,
nameSubtrees [2] GeneralNames OPTIONAL,
notBeforeRange [3] NotBeforeRange DistributionPointName OPTIONAL,
onlyContainsUserCerts [4] [2] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [5] [3] BOOLEAN DEFAULT FALSE,
onlySomeReasons [6] [4] ReasonFlags OPTIONAL,
indirectCRL
serialNumberRange [5] NumberRange OPTIONAL,
subjectKeyIdRange [6] NumberRange OPTIONAL,
nameSubtrees [7] BOOLEAN DEFAULT FALSE GeneralNames OPTIONAL
}

NumberRange ::= SEQUENCE {
startingNumber INTEGER,
endingNumber INTEGER,
modulus INTEGER OPTIONAL }

notBeforeRange ::= SEQUENCE {
startingNotBeforeTime GeneralizedTime,
endingNotBeforeTime GeneralizedTime }

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
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
onlySomeReasons are used as described for the X.509
issuingDistributionPoint extension. (Note that the
issuingDistributionPoint extension and cRLScope extension can conflict
with each other -- the issuingDistributionPoint extension is and are not permitted in
a CRL which contains a cRLScope extension.) intended to be used together.)

When a certificate-using system uses a CRL to check status of a
certificate, it should 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
such a certificate falls within the scope of the
CRL is inconsistent with PKIX if and should not be used. only if it meets the criteria of both extensions.

(b) If the CRL contains a cRLScope extension, then the certificate-
using system must MUST check that the certificate falls within the scope
indicated by the intersection of the serialNumberRange,
subjectKeyIdRange, nameSubtrees, and notBeforeRange nameSubtrees scopes, and is consistent with
distributionPoint, onlyContainsUserCerts and onlyContainsCACerts if
present.
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. 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: STATUS REFERRALS EXTENSION

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.

5. CRL LIST ATTRIBUTE

This optional attribute type is for use in CRLs distributed by a CA or locally-
trusted server in presenting a list of identifying other revocation sources (CRLs or OCSP-
servers) available CRLs to certificate-users. This list can The CRL will typically be
stored in the
CA's a directory entry. (That entry can be determined from issuer name or
an issuerAltName value.)

The list is signed and there is 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 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 CRL List attribute Status Referrals extension type:

cRLList ATTRIBUTE

statusReferrals EXTENSION ::= {
WITH
SYNTAX CRLList
ID StatusReferrals
IDENTIFIED BY <oid tbd> }

CRLList ::= SIGNED { SEQUENCE {
signature AlgorithmIdentifier,
issuer GeneralNames,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
cRLLocators CRLLocators }}

CRLLocators

StatusReferrals ::= SEQUENCE SIZE (1..MAX) OF StatusReferral

StatusReferral ::= CHOICE {
cRLReferral [0] CRLReferral,
deltaReferral [1] DeltaReferral,
oCSPReferral [2] OCSPReferral}

CRLReferral ::= SEQUENCE {
locator GeneralName,
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 signature, issuer, thisUpdate, location field gives an
address at which the referral is to be directed, and nextUpdate fields are interpreted
similarly as defaults to in the
same value as the issuer name.

In a CRL. 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 most recently issued referenced
CRL.

6. REVOCATION ISSUER EXTENSION

This noncritical certificate extension 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 by 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 indicate that have flexibility in how it has delegated authority
partitions its certificate space across CRLs, wants to one or more 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 entities 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 issue 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
sign wishes to
also issue delta CRLs or sign OCSP responses for each partition to reduce data transfer loads
on its behalf.

revocationIssuer EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY { <oid tbd> } } 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. 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