[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft delta crl text
Folks,
Russ Housley, David Cooper, and I have tried to draft what we hope *will
become* consensus text for the delta CRL and CRL number text. We believe
that the attached text clarifies (1) the requirements for "conforming
applications that support CRLs", (2) the CRL issuer's responsibilities when
including the delta CRL indicator and CRL number extensions, (3) the
algorithm followed by a CRL issuer when determining what certificates
should be listed on a delta CRL, and (4) the algorithm followed by an
application when determining whether a complete CRL and a delta CRL may be
combined.
To do this we have introduced a number of changes, beginning in section
3. In section 3, we introduce the "CRL issuer" in an enhanced version of
the ASCII art model of a pKI (figure 1.) In section 5, we define several
more terms including CRL scope, base CRL, delta CRL and complete CRL. All
this was necessary to set the stage for the CRL number extension and delta
CRL indicator extension text.
Please read these excerpts carefully. We believe that the text is flexible
enough to support reasonable implementations of delta CRLs, does not unduly
burden clients that wish to support deltas, and is consistent with
X.509. When you read this please ask yourself if you can *live* with it.
The attachment contains the following excerpts: Figure 1 from section 3,
section 5 (the intro to CRLs), section 5.2.3 (CRL number extension) and
5.2.4 (delta CRL indicator extension). Please ignore the blank spaces; I
was trying to remove anything irrelevant to this discussion.
Thanks,
Tim Polk
INTERNET DRAFT May 2001
+---+
| C | +------------+
| e | <-------------------->| End entity |
| r | Operational +------------+
| t | transactions ^
| i | and management | Management
| f | transactions | transactions
| i | | PKI users
| c | v
| a | ======================= +--+------------+ ==============
| t | ^ ^
| e | | | PKI management
| | v | entities
| & | +------+ |
| | <---------------------| RA |<----+ |
| C | Publish certificate +------+ | |
| R | | |
| L | | |
| | v v
| R | +------------+
| e | <------------------------------| CA |
| p | Publish certificate +------------+
| o | Publish CRL ^ ^
| s | | | Management
| i | +------------+ | | transactions
| t | <--------------| CRL Issuer |<----+ |
| o | Publish CRL +------------+ v
| r | +------+
| y | | CA |
+---+ +------+
Figure 1 - PKI Entities
The components in this model are:
end entity: user of PKI certificates and/or end user system that
is the subject of a certificate;
CA: certification authority;
RA: registration authority, i.e., an optional system to
which a CA delegates certain management functions;
CRL issuer: an optional system to which a CA delegates the
publication of certificate revocation lists;
repository: a system or collection of distributed systems that
store certificates and CRLs and serves as a means of
distributing these certificates and CRLs to end
entities.
Housley, Ford, Polk, & Solo [Page 9]
INTERNET DRAFT May 2001
5 CRL and CRL Extensions Profile
As described above, one goal of this X.509 v2 CRL profile is to
foster the creation of an interoperable and reusable Internet PKI.
To achieve this goal, guidelines for the use of extensions are
specified, and some assumptions are made about the nature of
information included in the CRL.
CRLs may be used in a wide range of applications and environments
covering a broad spectrum of interoperability goals and an even
broader spectrum of operational and assurance requirements. This
profile establishes a common baseline for generic applications
requiring broad interoperability. The profile defines a set of
information that can be expected in every CRL. Also, the profile
defines common locations within the CRL for frequently used
attributes as well as common representations for these attributes.
The entity that issues the CRL is referred to as the CRL issuer. In
Housley, Ford, Polk, & Solo [Page 47]
INTERNET DRAFT May 2001
general, CAs publish CRLs to provide status information on the
certificates they generated. However, a CA MAY delegate this
responsibility to another trusted authority. Whenever the CRL issuer
is not the CA that issued the certificates, the CRL is referred to as
an indirect CRL.
Each CRL has a particular scope. The CRL scope is the set of
certificates that could appear on a given CRL. For example, the
scope could be "all certificates issued by CA X", "all CA
certificates issued by CA X", "all certificates issued by CA X that
have been revoked for reasons of key compromise and CA compromise",
or could be a set of certificates based on arbitrary local
information, such as "all certificates issued to the NIST employees
located in Boulder".
A complete CRL lists all un-expired certificates, within its scope,
that have been revoked for one of the revocation reasons covered by
the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta
CRL only lists those un-expired certificates, within its scope, whose
revocation status has changed since the issuance of a referenced
complete CRL. The referenced complete CRL is referred to as a base
CRL. The scope of a delta CRL MUST be the same as the base CRL that
it references.
This profile does not define any private Internet CRL extensions or
CRL entry extensions.
Environments with additional or special purpose requirements may
build on this profile or may replace it.
Conforming CAs are not required to issue CRLs if other revocation or
certificate status mechanisms are provided. Conforming CAs that
issue CRLs MUST issue version 2 CRLs, include the date by which the
next CRL will be issued in the nextUpdate field (see sec. 5.1.2.5),
include the CRL number extension (see sec. 5.2.3), and include the
authority key identifier extension (see sec. 5.2.1). Conforming
applications that support CRLs are required to process both version 1
and 2 CRLs that are complete for a given scope. Conforming
applications are not required to support processing of delta CRLs or
indirect CRLs.
<<stuff deleted>>
Housley, Ford, Polk, & Solo [Page 48]
INTERNET DRAFT May 2001
5.2.3 CRL Number
The CRL number is a non-critical CRL extension which conveys a
monotonically increasing sequence number for a given CRL scope and
CRL issuer. This extension allows users to easily determine when a
particular CRL supersedes another CRL. CRL issuers conforming to
this profile MUST include this extension in all CRLs.
If a CRL issuer generates delta CRLs in addition to complete CRLs for
a given scope, the complete CRLs and delta CRLs MUST share one
numbering sequence. If a delta CRL and a complete CRL that cover the
same scope are issued at the same time, they MUST have the same CRL
number. This indicates that the combination of the delta CRL and an
acceptable complete CRL provide the same revocation information as
the simultaneously issued complete CRL.
If a CRL issuer generates a delta CRL and a complete CRL at different
times, the delta and complete CRL MUST NOT have the same CRL number.
That is, if the this update field (see sec. 5.1.2.4.) in the delta
and complete CRL are not identical, the CRL numbers are required to
be different.
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
cRLNumber ::= INTEGER (0..MAX)
5.2.4 Delta CRL Indicator
The delta CRL indicator is a critical CRL extension that identifies a
CRL as being a delta CRL. Delta CRLs contain updates to revocation
information previously distributed, rather than all the information
that would appear in a complete CRL. The use of delta CRLs can
significantly reduce network load and processing time in some
environments. Delta CRLs are generally smaller than the CRLs they
update, so applications that obtain delta CRLs consume less network
bandwidth than applications that obtain the corresponding complete
CRLs. Applications which store revocation information in a format
other than the CRL structure can add new revocation information to
the local database without reprocessing information.
The delta CRL indicator extension contains the single value of type
BaseCRLNumber. This value identifies the CRL number of the base CRL
that was used as the foundation in the generation of this delta CRL.
The referenced base CRL is a CRL that was explicitly issued as a CRL
that is complete for a given scope. The CRL containing the delta CRL
indicator extension contains all updates to the certificate
revocation status for that same scope. The combination of a CRL
containing the delta CRL indicator extension plus the CRL referenced
Housley, Ford, Polk, & Solo [Page 54]
INTERNET DRAFT May 2001
in the BaseCRLNumber component of this extension is equivalent to a
complete CRL, for the applicable scope, at the time of publication of
the delta CRL.
When a conforming CRL issuer generates a delta CRL, the delta CRL
MUST include a critical delta CRL indicator extension.
When a delta CRL is issued, it MUST cover the same set of reasons and
the same set of certificates that were covered by the base CRL it
references. That is, the scope of the delta CRL MUST be the same as
the scope of the complete CRL referenced as the base.
An application that supports delta CRLs can construct a CRL that is
complete for a given scope, at the current time, in either of the
following ways:
(a) by retrieving the current delta CRL for that scope, and
combining it with an issued CRL that is complete for that scope
and that has a cRLNumber greater than or equal to the base CRL
number referenced in the current delta CRL; or
(b) by retrieving the current delta CRL for that scope and
combining it with a locally constructed CRL whose cRLNumber is
greater than or equal to the base CRL number referenced in the
current delta CRL.
When a delta CRL is combined with a complete CRL or a locally
constructed CRL, the resulting locally constructed CRL has the CRL
number specified in the CRL number extension found in the delta CRL
used in its construction.
A complete CRL and a delta CRL MUST NOT be combined unless both of
the following conditions are satisfied:
(a) The CRL number specified in the complete CRL MUST be greater
than or equal to the CRL number of the base CRL referenced in the
delta CRL. That is, the complete CRL contains (at a minimum) all
the revocation information held by the referenced base CRL.
(b) The CRL number of the complete CRL MUST be less than the CRL
number of the delta CRL. That is, the delta CRL follows the
complete CRL in the numbering sequence.
CRL issuers MUST ensure that the combination of a delta CRL and any
appropriate complete CRL accurately reflects the current status of
revocation. For each certificate whose status has changed since the
generation of the referenced base CRL:
Housley, Ford, Polk, & Solo [Page 55]
INTERNET DRAFT May 2001
(a) If the certificate is revoked for a reason included in the
scope of the CRL, list the certificate as revoked.
(b) If not (a), list the certificate with the reason code
removeFromCRL.
It is appropriate to list a certificate with reason code
removeFromCRL on a delta CRL even if the certificate was not on hold
on the referenced base CRL. If the certificate was placed on hold on
any CRL issued after the base but before this delta CRL and then
released from hold, it MUST be listed on the delta CRL with
revocation reason removeFromCRL.
Applications that support delta CRLs are not required to support
local construction of CRLs. Since the delta CRLs are required to
reference a base CRL that was explicitly issued as a complete CRL,
the information required to process delta CRLs is always available in
a complete CRL.
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
baseCRLNumber ::= CRLNumber
Housley, Ford, Polk, & Solo [Page 56]