[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CDP Alternative Proposal
We have today submitted the attached Internet Draft entitled "Open CRL
Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.
While this work was initially motivated by the IETF and IESG desire that
the PKIX drafts not contain encumbered technology, we believe that the
result also has significant technical advantages over the CDP mechanism.
Given interest in this proposal, we suggest that the PKIX Cert and CRL
Profile (with CDPs expressly forbidden as per LA) progress to proposed
standard as soon as possible, allowing dependent application standards
(e.g., CMS) to progress as well. PKIX may wish to also consider adopting
the OpenCDP specification as the basis of a follow-up adjunct standard.
Warwick and Phillip
-----------------------------------------
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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au Pacific Rim), ds.internic.net (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
"<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.
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 <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 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.
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 { <oid tbd> } }
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
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
wford@verisign.com; 301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------