< draft-ietf-pkix-ocdp-00.txt		draft-ietf-pkix-ocdp-01.txt >
	PKIX Working Group P. Hallam-Baker (VeriSign)		PKIX Working Group P. Hallam-Baker (VeriSign)
	Internet Draft W. Ford (VeriSign)		Internet Draft W. Ford (VeriSign)
	expires in six months April 21, 1998		Expires in six months August 7, 1998
	Internet X.509 Public Key Infrastructure		Internet X.509 Public Key Infrastructure
	OPEN CRL DISTRIBUTION PROCESS (OpenCDP)		ENHANCED CRL DISTRIBUTION OPTIONS
	<draft-ietf-pkix-ocdp-00.txt>		<draft-ietf-pkix-ocdp-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at line 36 ¶		skipping to change at line 36 ¶
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net		Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
	(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au		(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
	(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu		(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
	(US West Coast).		(US West Coast).
	Copyright (C) The Internet Society (date). All Rights Reserved.		Copyright (C) The Internet Society (date). All Rights Reserved.
	Abstract		Abstract
	This Internet Draft specifies mechanisms for determining if a public-key		This Internet Draft specifies some proposed enhancements to the X.509
	certificate is valid or revoked, using CRL partitions. These mechanisms		CRL mechanism used to determine if a public-key certificate is valid or
	are considered superior to the CRL Distribution Points (CDP) mechanism		revoked. These enhancements provide advantages over existing CRL
	defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons. In		mechanisms, including those that use static CRL partitioning as defined
	particular, OpenCDP:		in ISO/IEC 9504-8/ITU-T Rec. X.509. In particular, the mechanisms
	(a) accommodates dynamic partitioning as opposed to fixed partitioning;		proposed can:
	(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		(a) reduce the need for unnecessarily fetching unchanged CRLs, thereby
	list.		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		Acknowledgments
	The following individuals made significant contributions to the		The following individuals made significant contributions to the
	development of this proposal: Arn Schaeffer, Mahi de Silva, Michael		development of this proposal: Arn Schaeffer, Mahi de Silva, Michael
	Myers, and Alex Deacon of VeriSign, Brian LaMacchia and Barbara Fox of		Myers, and Alex Deacon of VeriSign, Brian LaMacchia and Barbara Fox of
	Microsoft, and Jeff Weinstein of Netscape.		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. PRINCIPLES		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		A certification authority may issue distinct CRLs for different subsets
	of its certificate population. The partitioning may be based on various		of its certificate population. The partitioning may be based on various
	requirements, such as the need to partition evenly for pure performance		requirements, such as the need to partition evenly for pure performance
	purposes, the need to produce separate CRLs on the basis of revocation		purposes, the need to produce separate CRLs on the basis of revocation
	reason, or the need to group together revocation information for related		reason, or the need to group together revocation information for related
	entities, e.g., all the servers or clients of one organization.		entities, e.g., all the servers or clients of one organization.
	CRL partitioning involves two functions:		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		(a) a CRL location function, which allows for a certificate-using
	system to find a CRL applicable to a given certificate;		system to find a CRL applicable to a given certificate;
	(b) a certificate-CRL validation function, which provides for the		(b) a certificate-CRL validation function, which provides for the
	certificate-using system to confirm that a CRL to hand is indeed an		certificate-using system to confirm that a CRL to hand is indeed an
	applicable CRL for the certificate under consideration.		applicable CRL for the certificate under consideration.
	The CDP mechanism merged these two functions into one mechanism. In		The original CRL/CDP mechanism merged these two functions into one
	contrast, the OpenCDP mechanism separates these two functions and		mechanism. However, there can be benefit in separating these functions:
	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		(1) Since the location function does not inherently require a CA
	possible to change that information for use of the certificate in		signature, omitting it from the certificate may help reduce certificate
	different environments, e.g., change it to point to a different CRL		sizes.
	store when traversing a firewall.
	Fourth, given the provision of an attribute external to a certificate		(2) By making the location function a server- or directory-lookup
	for conveying CRL location information, the same attribute can convey		function, a signed status indicator (last update time) can be associated
	other useful revocation information such as a pointer to an OCSP server.		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.
	The OpenCDP mechanism employs a single X.509 CRL extension and two		(3)The certificate-CRL validation function can be made a dynamic mapping
	attribute types for use in directories or in protocol construction. No		relationship, as opposed to the static relationship afforded by CDPs.
	certificate extensions are needed except that, if indirectCRLs are to be		For example, this function can be based on such certificate population
	implemented, there is a need for a new revocationIssuer extension to		characteristics as subject name subtrees or certificate serial number
	implement the function of the cRLIssuer element of the		ranges. Such CRL partition definitional criteria can be changed
	cRLDistributionPoints extension (which is no longer used in PKIX) - see		dynamically by the CA if needed, without affecting the issued
	later section on Revocation Issuer Extension.		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.
	2. CRL LOCATION FUNCTION		(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.
	A certificate-using system that uses partitioned CRLs needs to locate an		This document defines two X.509 CRL extensions: The Status Referrals
	appropriate CRL for a given certificate. Information on CRL location		extension designed primarily to support the CRL location function and
	does not need to be inside a certificate. Furthermore, it can be		the CRL Scope extension designed primarily to support the certificate-
	advantageous not to have such information within certificates, in order		CRL validation function.
	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,		2.1 CRL Location Function
	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		A certificate-using system that uses (possibly partitioned) CRLs needs
	such information, for use in protocols and directory entries. This		to locate an appropriate CRL for a given certificate. Information on
	specification therefore defines a standard attribute type for holding		CRL location can be obtained in various ways, including:
	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.		(a) Via a direct pointer in a CRL Distribution Points extension in the
	This involves a list of CRLs stored in the CA's directory entry. This		certificate;
	mechanism is described below under the CRL List Attribute.		(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.
	3. CERTIFICATE-CRL VALIDATION FUNCTION		2.2 Certificate-CRL Validation Function
	The scope of a CRL partition can be defined by specifying ranges on any		The scope of a CRL (or CRL partition) can be defined by specifying
	of the fields in a certificate. For Internet (PKIX) purposes, it is		ranges on any of the fields in a certificate. For Internet (PKIX)
	proposed that the scoping be limited to the following criteria or any		purposes, it is proposed that the scoping be limited to the following
	combination thereof:		criteria or any combination thereof:
	(a) A certificate serial number range;		(a) A certificate serial number range;
	(b) A subject key identifier range;		(b) A subject key identifier range;
	(c) One or more subject name subtrees;		(c) One or more subject name subtrees;
	(d) A time range for certificate issuance (more precisely, for the		(d) End-user certificate vs CA-certificate;
	notBefore time in the certificate);		(e) Certificates containing a particular CRL Distribution Point name.
	(e) End-user certificate vs CA-certificate.
	Examples of CRL partition scopes are:		Examples of CRL partition scopes are:
	(1) All of the certificates of a CA with serial numbers between 10,000		(1) All of the certificates of a CA with serial numbers between 10,000
	and 19,999 inclusive.		and 19,999 inclusive.
	(2) All of the certificates of a CA with subject names commencing:		(2) All of the certificates of a CA with subject names commencing:
	"C=US, O=foobar, ..."		C=US, O=foobar, ...
	(3) All of the certificates of a CA with subject DNS names		(3) All of the certificates of a CA with subject DNS names:
	"<anything>.foobar.com".		<anything>.foobar.com.
	(4) All of the certificates of a CA for the subject "C=US, O=foo,		(4) All of the certificates of a CA for the subject:
	OU=bar, CN=myname".		C=US, O=foo, OU=bar, CN=myname.
	(5) All of the certificates of a CA with a notBefore date in April,
	1998.		3. CRL SCOPE EXTENSION
	The scope of a CRL is indicated within that CRL using the following CRL		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 ::= {		cRLScope EXTENSION ::= {
	SYNTAX CRLScopeSyntax		SYNTAX CRLScopeSyntax
	IDENTIFIED BY { <oid tbd> } }		IDENTIFIED BY { <oid tbd> } }
	CRLScopeSyntax ::= SEQUENCE {		CRLScopeSyntax ::= SEQUENCE SIZE (1..MAX) OF PerCAScope
	serialNumberRange [0] NumberRange OPTIONAL,
	subjectKeyIdRange [1] NumberRange OPTIONAL,		PerCAScope ::= SEQUENCE {
	nameSubtrees [2] GeneralNames OPTIONAL,		cAName [0] GeneralName OPTIONAL,
	notBeforeRange [3] NotBeforeRange OPTIONAL,		distributionPoint [1] DistributionPointName OPTIONAL,
	onlyContainsUserCerts [4] BOOLEAN DEFAULT FALSE,		onlyContainsUserCerts [2] BOOLEAN DEFAULT FALSE,
	onlyContainsCACerts [5] BOOLEAN DEFAULT FALSE,		onlyContainsCACerts [3] BOOLEAN DEFAULT FALSE,
	onlySomeReasons [6] ReasonFlags OPTIONAL,		onlySomeReasons [4] ReasonFlags OPTIONAL,
	indirectCRL [7] BOOLEAN DEFAULT FALSE }		serialNumberRange [5] NumberRange OPTIONAL,
			subjectKeyIdRange [6] NumberRange OPTIONAL,
			nameSubtrees [7] GeneralNames OPTIONAL
			}
	NumberRange ::= SEQUENCE {		NumberRange ::= SEQUENCE {
	startingNumber INTEGER,		startingNumber INTEGER,
	endingNumber INTEGER,		endingNumber INTEGER,
	modulus INTEGER OPTIONAL }		modulus INTEGER OPTIONAL }
	notBeforeRange ::= SEQUENCE {		The potential presence of multiple PerCAScope constructs provides for
	startingNotBeforeTime GeneralizedTime,		support for indirect CRLs, in which a CRL issuer provides revocation
	endingNotBeforeTime GeneralizedTime }		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		The serialNumberRange element, if present, is used as follows. When a
	modulus value is present, the serial number is reduced modulo the given		modulus value is present, the serial number is reduced modulo the given
	value before checking for presence in the range. Then, certificates		value before checking for presence in the range. Then, certificates
	with a (reduced) serial number equal to or greater than startingNumber		with a (reduced) serial number equal to or greater than startingNumber
	and less than endingNumber are considered to be within scope of the CRL.		and less than endingNumber are considered to be within scope of the CRL.
	The subjectKeyId range element, if present, is interpreted the same as		The subjectKeyId range element, if present, is interpreted the same as
	serialNumberRange, except that the number used is the value in the		serialNumberRange, except that the number used is the value in the
	certificate's subjectKeyIdentifier extension, interpreted as an unsigned		certificate’s subjectKeyIdentifier extension, interpreted as an unsigned
	integer.		integer.
	Conventions for the nameSubtrees option are the same as for the Name		Conventions for the nameSubtrees option are the same as for the Name
	Constraints extension.		Constraints extension.
	If the notBeforeRange element is present, certificates with a notBefore		The fields onlyContainsUserCerts, onlyContainsCACerts, and
	time equal to or greater than startingNotBeforeTime and less than		onlySomeReasons are used as described for the X.509
	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. (Note that the
	issuingDistributionPoint extension and cRLScope extension conflict with		issuingDistributionPoint extension and cRLScope extension can conflict
	each other -- the issuingDistributionPoint extension is not permitted in		with each other and are not intended to be used together.)
	a CRL which contains a cRLScope extension.)
	When a certificate-using system uses a CRL to check status of a		When a certificate-using system uses a CRL to check status of a
	certificate, it should check that the CRL scope includes the		certificate, it SHOULD check that the CRL scope includes the
	certificate, as follows:		certificate, as follows:
	(a) If the CRL contains an issuingDistributionPoint extension, then		(a) If the CRL contains both an issuingDistributionPoint extension and
	such CRL is inconsistent with PKIX and should not be used.		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-		(b) If the CRL contains a cRLScope extension, then the certificate-
	using system must check that the certificate falls within the scope		using system MUST check that the certificate falls within the scope
	indicated by the intersection of the serialNumberRange,		indicated by the intersection of the serialNumberRange,
	subjectKeyIdRange, nameSubtrees, and notBeforeRange scopes, and is		subjectKeyIdRange, and nameSubtrees scopes, and is consistent with
	consistent with onlyContainsUserCerts and onlyContainsCACerts if		distributionPoint, onlyContainsUserCerts and onlyContainsCACerts if
	present.		present, for the PerCAScope construct for the certificate issuer.
	(c) If the CRL contains neither an issuingDistributionPoint nor		(c) If the CRL contains neither an issuingDistributionPoint nor
	cRLScope extension, then the scope is the entire scope of the CA, and		cRLScope extension, then the scope is the entire scope of the CA, and
	the CRL may be used for any certificate from that CA.		the CRL may be used for any certificate from that CA.
	4. REVOCATION INFORMATION ATTRIBUTE		4. STATUS REFERRALS EXTENSION
	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,		This CRL extension is for use in CRLs distributed by a CA or locally-
	the corresponding revocation information can be conveyed in a HTTP		trusted server in identifying other revocation sources (CRLs or OCSP-
	header.		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.
	(e) When a certificate is issued using CRMF or PKCSReq (see [CRMF] or		A status referral makes provision for inclusion of a last-update
	[CMMF] respectively), the corresponding revocation information can be		time/date for every referenced CRL. A CA is able to use this mechanism
	conveyed as an unauthenticated attribute in the "response" field of a		as follows. A new, authenticated CRL list is reissued periodically,
	CertRep message body (see [CMMF] for details on CertRep syntax.)		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.
	As new IETF protocols are defined, it is anticipated that the protocols		Following is the definition of the Status Referrals extension type:
	will make explicit provision for conveying revocation information along
	with certificates.
	Note that there may be circumstances in which an intermediary (e.g.,		statusReferrals EXTENSION ::= {
	firewall) may change revocation information, such as CRL location		SYNTAX StatusReferrals
	pointers, in transit.		IDENTIFIED BY <oid tbd> }
	Following is the definition of the Revocation Information attribute		StatusReferrals ::= SEQUENCE SIZE (1..MAX) OF StatusReferral
	type:
	revocInfo ATTRIBUTE ::= {		StatusReferral ::= CHOICE {
	WITH SYNTAX RevocInfo		cRLReferral [0] CRLReferral,
	ID <oid tbd> }		deltaReferral [1] DeltaReferral,
			oCSPReferral [2] OCSPReferral}
	RevocInfo ::= SEQUENCE {		CRLReferral ::= SEQUENCE {
	certIssuer GeneralNames,		issuer GeneralName OPTIONAL,
	certSerialNumber INTEGER,		location GeneralName OPTIONAL,
	infoLocations [0] SEQUENCE SIZE (1..MAX) OF InfoLocation		deltaLocation GeneralName OPTIONAL,
	OPTIONAL,		cRLScope CRLScopeSyntax,
	extensions [1] SEQUENCE OF INSTANCE OF		lastUpdate GeneralizedTime OPTIONAL,
	TYPE-IDENTIFIER OPTIONAL }		lastDelta GeneralizedTime OPTIONAL}
	InfoLocation ::= SEQUENCE {		DeltaReferral ::= GeneralName
	locator GeneralNames,
	infoType InfoType DEFAULT crl,
	reasons ReasonFlags OPTIONAL }
	InfoType ::= ENUMERATED {		OCSPReferral ::= SEQUENCE {
	crl (0),		issuer GeneralName OPTIONAL,
	oCSPServer (1) }		location GeneralName OPTIONAL }
	ReasonFlags ::= BIT STRING {		In both the CRL and OCSP referral cases, the issuer field identifies the
	unused (0),		entity that signs the CRL or status response; this defaults to the
	keyCompromise (1),		issuer name of the encompassing CRL. The location field gives an
	cACompromise (2),		address at which the referral is to be directed, and defaults to the
	affiliationChanged (3),		same value as the issuer name.
	superseded (4),
	cessationOfOperation (5),
	certificateHold (6) }
	For the semantics of the reasons field, see the definition of the CRL		In a CRL referral, the deltaLocation field gives an optional alternative
	Distribution Points certificate extension in X.509.		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.
	Certification authorities that are conformant to OpenCDP must not insert		The deltaReferral option shall be used only to indicate, in a CRL, the
	a revocation information attribute within a certificate.		location for retrieving delta CRLs for that CRL.
	5. CRL LIST ATTRIBUTE		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.
	This optional attribute type is for use by a CA in presenting a list of		5. EXAMPLES OF USE
	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		Some examples of use of the above mechanisms follow:
	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:		(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.
	cRLList ATTRIBUTE ::= {		Solution: The CA stores, in the CRL attribute of its directory entry, a
	WITH SYNTAX CRLList		referencing CRL which contains, rather than specific certificate
	ID <oid tbd> }		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.
	CRLList ::= SIGNED { SEQUENCE {		(2) Requirement: An enterprise wants to operate its own certificate-
	signature AlgorithmIdentifier,		status services for its clients, including status-checking for multiple
	issuer GeneralNames,		external CAs with which the enterprise interoperates.
	thisUpdate GeneralizedTime,
	nextUpdate GeneralizedTime OPTIONAL,
	cRLLocators CRLLocators }}
	CRLLocators ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {		Solution: The enterprise operates a server which issues its own CRLs
	locator GeneralName,		covering all of the certificates of concern, using the indirect CRL
	cRLScope CRLScopeSyntax,		capabilities afforded by Status Referrals. Timeliness demands may be
	lastUpdate GeneralizedTime OPTIONAL }		supported. The address of the enterprise server is installed in all the
			enterprise clients.
	The signature, issuer, thisUpdate, and nextUpdate fields are interpreted		(3) Requirement: A CA has multiple fixed CRL partitions, and wishes to
	similarly as to in a CRL. The lastUpdate field is the value of the		also issue delta CRLs for each partition to reduce data transfer loads
	thisUpdate field in the most-recently issued referenced CRL.		on busy clients.
	6. REVOCATION ISSUER EXTENSION		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.
	This noncritical certificate extension is used by a CA to indicate that		6. SECURITY ISSUES
	it has delegated authority to one or more other entities to issue and
	sign CRLs or sign OCSP responses on its behalf.
	revocationIssuer EXTENSION ::= {		An attacker might use a CRL with partial scope to cause an application
	SYNTAX GeneralNames		which does not implement the scope extension to erroneously believe that
	IDENTIFIED BY { <oid tbd> } }		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		7. INTELLECTUAL PROPERTY STATEMENT
	The authors have no knowledge of any pending or granted patents covering		The authors have no knowledge of any pending or granted patents covering
	the techniques described.		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:		Author Addresses:
	Phillip Hallam-Baker		Phillip Hallam-Baker
	VeriSign, Inc.		VeriSign, Inc.
	301 Edgewater Place, Suite 210		301 Edgewater Place, Suite 210
	Wakefield, MA 01880		Wakefield, MA 01880
	USA		USA
	pbaker@verisign.com		pbaker@verisign.com
End of changes. 57 change blocks.
	219 lines changed or deleted		236 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/