I sent in a revised version of the OCDP draft to the drafts editor last Friday. Looks like there may have been slightly more traffic than usual that day for some reason since it has not appeared yet! In order to make sure everyone has a chance to review before Chicago I thought it best to forward to the list (it is a reasonably short one). The principle changes are: 1) We changed the name but not the acronym. 2) CRLList structures are now an attribute which is transported in a CRL. Other signature packages (e.g. PKCS#7) might well be appropriate BUT we do not define the semantics for this case. 3) The time based scope specifications were removed 4) In response to some comments Carlisle made to the Federal PKI WG there is explicit support for deltas. One significant feature of the proposal is that a CRL can contain the distribution point for its deltas. This allows for more flexibility than is afforded by delta locators in Certs. Phill -----Original Message----- From: Phillip M Hallam-Baker [mailto:pbaker@verisign.com] Sent: Friday, August 07, 1998 3:14 PM To: internet-drafts@ietf.org Cc: Warwick Ford Subject: <draft-ietf-pkix-ocdp-01.txt> Please accept the following revision of our Internet Draft 'draft-ietf-pkix-ocdp-01.txt'. The draft is a submission to the IETF PKIX working group. Phill
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
<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).
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 <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 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:
<anything>.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 { <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
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 <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.
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
Attachment:
smime.p7s
Description: application/pkcs7-signature