CRL
Click on the red underlined text to get to the source
... X.509 version 2 certificate revocation list (CRL) in
Section 5. The profiles include the identification of ISO/IEC ...
... this specification. Appendix D contains examples of a conforming
certificate and a conforming CRL.
...
... but other means of distributing certificates and certificate
revocation lists (CRLs) may be used.
...
... distributed systems that
store certificates and CRLs and serves as a means of
distributing these certificates and CRLs ...
... signed data structure called
a certificate revocation list (CRL). A CRL is a time stamped list
identifying revoked certificates ...
... a certificate revocation list (CRL). A CRL is a time stamped list
identifying revoked certificates which is signed by a CA ...
... freely available in a public repository. Each revoked certificate is
identified in a CRL by its certificate serial number. When a
...
... signature and validity but also acquires a suitably-
recent CRL and checks that the certificate serial number is not on
...
... certificate serial number is not on
that CRL. The meaning of "suitably-recent" may vary with local
policy, but it usually means the most recently-issued CRL. A CA ...
... that CRL. The meaning of "suitably-recent" may vary with local
policy, but it usually means the most recently-issued CRL. A CA
issues a new CRL ...
... CRL. A CA
issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
weekly). An entry is added to the CRL as part of the next update ...
... issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
weekly). An entry is added to the CRL as part of the next update
following notification ...
... revocation. An entry may be removed from
the CRL after appearing on one regularly scheduled CRL issued beyond
the revoked certificate ...
... removed from
the CRL after appearing on one regularly scheduled CRL issued beyond
the revoked certificate's validity ...
... An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves,
...
... communications and servers, is that the time granularity of
revocation is limited to the CRL issue period. For example, if a
revocation is reported now, that revocation ...
... revocation will not be reliably
notified to certificate-using systems until the next periodic CRL is
issued -- this may be up to one hour, one day, or one week depending
on the frequency that the CA ...
... issued -- this may be up to one hour, one day, or one week depending
on the frequency that the CA issues CRLs.
...
... interoperable implementations from multiple vendors, the X.509 v2 CRL
format needs to be profiled for Internet use. It is one goal of this
...
... profile does not
require CAs to issue CRLs. Message formats and protocols supporting
on-line ...
... notification may be
applicable in some environments as an alternative to the X.509 CRL.
On-line revocation ...
...
Operational protocols are required to deliver certificates and CRLs
(or status information) to certificate using client systems ...
... Provision is needed for a variety of different means of certificate
and CRL delivery, including distribution procedures based on LDAP,
...
... CRL Distribution Points ...
...
The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical ...
...
The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical, but this profile ...
... semantics MUST be
assumed: the URI is a pointer to the current CRL for the associated
reasons and will be issued by the associated cRLIssuer. The expected
values for the URI ...
... Processing rules for
other values are not defined by this specification. If the
distributionPoint omits reasons, the CRL MUST include revocations for
all reasons. If the distributionPoint omits cRLIssuer, the CRL ...
... CRL MUST include revocations for
all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST
be issued by the CA that issued the certificate ...
... validation services and CA policy data. (The location of CRLs is not
specified in this extension; that information is provided by the
cRLDistributionPoints extension.) This extension may be included in
...
...
As described above, one goal of this X.509 v2 CRL profile is to
foster the creation of an interoperable and reusable Internet ...
... 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 ...
... interoperability. The profile defines a baseline set
of information that can be expected in every CRL. Also, the profile
defines common locations within the CRL ...
... CRL. Also, the profile
defines common locations within the CRL for frequently used
attributes as well as common representations for these attributes.
...
... certificate status mechanisms are provided. Conforming CAs that
issue CRLs MUST issue version 2 CRLs, and CAs ...
... CRLs, and CAs MUST include the date
by which the next CRL will be issued in the nextUpdate field (see
sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the
...
... by which the next CRL will be issued in the nextUpdate field (see
sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the
authority key identifier ...
... key identifier extension (see sec. 5.2.1). Conforming
applications are required to process version 1 and 2 CRLs.
...
... CRL Fields ...
...
The X.509 v2 CRL syntax is as follows. For signature calculation,
the data that is to be signed is ASN.1 ...
... issue date of the next list, the list of revoked certificates, and
optional CRL extensions. Further, each entry on the revoked
certificate list is defined by a sequence of user certificate ...
... is then ASN.1 encoded as a BIT STRING and included in the CRL's
signatureValue field. The details of this process are specified for
each of the supported algorithms ...
... The certificate list to be signed, or TBSCertList, is a SEQUENCE of
required and optional fields. The required fields identify the CRL
issuer, the algorithm used to sign the CRL, the date and time the CRL ...
... required and optional fields. The required fields identify the CRL
issuer, the algorithm used to sign the CRL, the date and time the CRL
was issued, and the date and time by which the CA ...
... CRL
issuer, the algorithm used to sign the CRL, the date and time the CRL
was issued, and the date and time by which the CA will issue the next
...
...
Optional fields include lists of revoked certificates and CRL
extensions. The revoked certificate list is optional to support the
case where a CA ...
... has issued. The profile requires conforming CAs to use the CRL
extension cRLNumber in all CRLs issued.
...
...
This optional field describes the version of the encoded CRL. When
extensions are used, as required by this profile, this field MUST be
...
... algorithm identifier for the algorithm used
to sign the CRL. Section 7.2 lists OIDs for the most popular
signature ...
... issuer name identifies the entity who has signed and issued the
CRL. The issuer identity is carried in the issuer ...
...
This field indicates the issue date of this CRL. ThisUpdate may be
encoded as UTCTime or GeneralizedTime.
...
... CAs conforming to this profile that issue CRLs MUST encode thisUpdate
as UTCTime for dates through the year 2049. CAs ...
... CAs conforming to this
profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for
dates in the year 2050 or later.
...
...
This field indicates the date by which the next CRL will be issued.
The next CRL could be issued before the indicated date, but it will
...
... This field indicates the date by which the next CRL will be issued.
The next CRL could be issued before the indicated date, but it will
not be issued any later than the indicated date. CAs SHOULD issue
...
... not be issued any later than the indicated date. CAs SHOULD issue
CRLs with a nextUpdate time equal to or later than all previous CRLs.
nextUpdate may be encoded as UTCTime ...
... CAs SHOULD issue
CRLs with a nextUpdate time equal to or later than all previous CRLs.
nextUpdate may be encoded as UTCTime or GeneralizedTime.
...
...
This profile requires inclusion of nextUpdate in all CRLs issued by
conforming CAs. Note that the ASN.1 ...
... defined in [X.509]. The behavior of clients processing CRLs which
omit nextUpdate is not specified by this profile.
...
... CAs conforming to this profile that issue CRLs MUST encode nextUpdate
as UTCTime for dates through the year 2049. CAs ...
... CAs conforming to this
profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for
dates in the year 2050 or later.
...
... revocation occurred is specified. The time for revocationDate MUST
be expressed as described in section 5.1.2.4. Additional information
may be supplied in CRL entry extensions; CRL entry extensions are
discussed in section 5.3.
...
... be expressed as described in section 5.1.2.4. Additional information
may be supplied in CRL entry extensions; CRL entry extensions are
discussed in section 5.3.
...
... This field may only appear if the version is 2 (see sec. 5.1.2.1).
If present, this field is a SEQUENCE of one or more CRL extensions.
CRL extensions are discussed in section 5.2.
...
... If present, this field is a SEQUENCE of one or more CRL extensions.
CRL extensions are discussed in section 5.2.
...
... CRL Extensions ...
... X9.55] provide methods for associating additional attributes
with CRLs. The X.509 v2 CRL format also allows communities to define
...
... with CRLs. The X.509 v2 CRL format also allows communities to define
private extensions to carry information unique to those communities.
Each extension in a CRL ...
... CRL format also allows communities to define
private extensions to carry information unique to those communities.
Each extension in a CRL may be designated as critical or non-
critical ...
... critical or non-
critical. A CRL validation MUST fail if it encounters a critical
extension which it does not know how to process. However, an
...
... critical extension may be ignored. The following
subsections present those extensions used within Internet CRLs.
Communities may elect to include extensions in CRLs which are not
...
... Internet CRLs.
Communities may elect to include extensions in CRLs which are not
defined in this specification. However, caution should be exercised
in adopting any critical ...
... defined in this specification. However, caution should be exercised
in adopting any critical extensions in CRLs which might be used in a
general context.
...
... authority
key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3)
extensions in all CRLs issued.
...
... key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3)
extensions in all CRLs issued.
...
... public key corresponding to the private key used to
sign a CRL. The identification can be based on either the key
identifier (the subject key identifier ...
...
The syntax for this CRL extension is defined in section 4.2.1.1.
...
... alternative names extension allows additional identities
to be associated with the issuer of the CRL. Defined options include
an rfc822 name (electronic mail address ...
...
The OID and syntax for this CRL extension are defined in section
4.2.1.8.
...
... CRL Number ...
... The CRL number is a non-critical CRL extension which conveys a
monotonically increasing sequence number for each CRL ...
... CRL extension which conveys a
monotonically increasing sequence number for each CRL issued by a CA.
This extension allows users to easily determine when a particular CRL ...
... CRL issued by a CA.
This extension allows users to easily determine when a particular CRL
supersedes another CRL. CAs ...
... This extension allows users to easily determine when a particular CRL
supersedes another CRL. CAs conforming to this profile MUST include
...
... Delta CRL Indicator ...
... The delta CRL indicator is a critical CRL extension that identifies a
delta-CRL. The use of delta-CRLs ...
... critical CRL extension that identifies a
delta-CRL. The use of delta-CRLs can significantly improve
processing time for applications which store revocation ...
... CRL extension that identifies a
delta-CRL. The use of delta-CRLs can significantly improve
processing time for applications which store revocation information
...
... processing time for applications which store revocation information
in a format other than the CRL structure. This allows changes to be
added to the local database while ignoring unchanged information that
...
...
The value of BaseCRLNumber identifies the CRL number of the base CRL
that was used as the starting ...
...
The value of BaseCRLNumber identifies the CRL number of the base CRL
that was used as the starting point in the generation of this delta-
...
... that was used as the starting point in the generation of this delta-
CRL. The delta-CRL contains the changes between the base CRL and the
...
... starting point in the generation of this delta-
CRL. The delta-CRL contains the changes between the base CRL and the
current CRL ...
... CRL. The delta-CRL contains the changes between the base CRL and the
current CRL issued along with the delta-CRL ...
... CRL contains the changes between the base CRL and the
current CRL issued along with the delta-CRL. It is the decision of a
CA ...
... CRL and the
current CRL issued along with the delta-CRL. It is the decision of a
CA as to whether to provide delta-CRLs ...
... CRL. It is the decision of a
CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT
be issued without a corresponding complete CRL ...
... CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT
be issued without a corresponding complete CRL. The value of
...
... CRLs. Again, a delta-CRL MUST NOT
be issued without a corresponding complete CRL. The value of
CRLNumber for both the delta-CRL and the corresponding complete CRL ...
... be issued without a corresponding complete CRL. The value of
CRLNumber for both the delta-CRL and the corresponding complete CRL
MUST be identical.
...
... CRL. The value of
CRLNumber for both the delta-CRL and the corresponding complete CRL
MUST be identical.
...
...
A CRL user constructing a locally held CRL from delta-CRLs MUST
consider the constructed CRL ...
... A CRL user constructing a locally held CRL from delta-CRLs MUST
consider the constructed CRL incomplete and unusable if the CRLNumber
...
... CRL from delta-CRLs MUST
consider the constructed CRL incomplete and unusable if the CRLNumber
of the received delta-CRL is more than one greater than the CRLnumber
...
... consider the constructed CRL incomplete and unusable if the CRLNumber
of the received delta-CRL is more than one greater than the CRLnumber
of the delta-CRL last processed.
...
... of the received delta-CRL is more than one greater than the CRLnumber
of the delta-CRL last processed.
...
...
The issuing distribution point is a critical CRL extension that
identifies the CRL distribution point for a particular CRL ...
... critical CRL extension that
identifies the CRL distribution point for a particular CRL, and it
indicates whether the CRL ...
... CRL extension that
identifies the CRL distribution point for a particular CRL, and it
indicates whether the CRL covers revocation ...
... CRL distribution point for a particular CRL, and it
indicates whether the CRL covers revocation for end entity
certificates only, CA ...
... CRL is signed using the CA's private key. CRL Distribution
Points do not have their own key pairs. If the CRL ...
... CRL Distribution
Points do not have their own key pairs. If the CRL is stored in the
X.500 Directory, it is stored in the Directory entry corresponding to
...
... X.500 Directory, it is stored in the Directory entry corresponding to
the CRL distribution point, which may be different than the Directory
entry of the CA.
...
... revocations for all reason codes.
CAs may use CRL distribution points to partition the CRL on the basis
...
... CAs may use CRL distribution points to partition the CRL on the basis
of compromise and routine revocation. In this case, the revocations ...
... following semantics MUST be assumed: the object is a pointer to the
most current CRL issued by this CA. The URI schemes ftp, http,
...
... CRL Entry Extensions ...
... CRLs provide methods for associating additional
attributes with CRL entries [X.509] [X9.55]. The X.509 ...
... X.509] [X9.55]. The X.509 v2 CRL format
also allows communities to define private CRL entry extensions to
...
... X.509 v2 CRL format
also allows communities to define private CRL entry extensions to
carry information unique to those communities. Each extension in a
CRL ...
... CRL entry extensions to
carry information unique to those communities. Each extension in a
CRL entry may be designated as critical or non-critical. A CRL
validation ...
... CRL entry may be designated as critical or non-critical. A CRL
validation MUST fail if it encounters a critical CRL entry extension
...
... critical. A CRL
validation MUST fail if it encounters a critical CRL entry extension
which it does not know how to process. However, an unrecognized
non-critical ...
... which it does not know how to process. However, an unrecognized
non-critical CRL entry extension may be ignored. The following
subsections present recommended extensions used within Internet CRL ...
... CRL entry extension may be ignored. The following
subsections present recommended extensions used within Internet CRL
entries and standard locations for information. Communities may
elect to use additional CRL ...
... CRL
entries and standard locations for information. Communities may
elect to use additional CRL entry extensions; however, caution should
be exercised in adopting any critical extensions in CRL ...
... CRL entry extensions; however, caution should
be exercised in adopting any critical extensions in CRL entries which
might be used in a general context.
...
...
All CRL entry extensions used in this specification are non-critical.
Support for these extensions is optional for conforming CAs ...
... CAs and
applications. However, CAs that issue CRLs SHOULD include reason
codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever
this information is available.
...
...
The reasonCode is a non-critical CRL entry extension that identifies
the reason for the certificate revocation ...
... revocation. CAs are strongly
encouraged to include meaningful reason codes in CRL entries;
however, the reason code CRL entry extension SHOULD be absent instead
...
... encouraged to include meaningful reason codes in CRL entries;
however, the reason code CRL entry extension SHOULD be absent instead
of using the unspecified (0) reasonCode value.
...
...
The hold instruction code is a non-critical CRL entry extension that
provides a registered instruction identifier which indicates the
...
...
The invalidity date is a non-critical CRL entry extension that
provides the date on which it is known or suspected that the private
key was compromised or that the certificate ...
... certificate otherwise became invalid.
This date may be earlier than the revocation date in the CRL entry,
which is the date at which the CA processed the revocation ...
... revocation is first posted by a CA in a CRL, the invalidity date may
precede the date of issue of earlier CRLs, but the revocation ...
... CA in a CRL, the invalidity date may
precede the date of issue of earlier CRLs, but the revocation date
SHOULD NOT precede the date of issue of earlier CRLs ...
... CRLs, but the revocation date
SHOULD NOT precede the date of issue of earlier CRLs. Whenever this
information is available, CAs are strongly encouraged to share it
...
... certificate issuer associated
with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
indicator set in its issuing distribution point extension. If this
...
... issuer associated
with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
indicator set in its issuing distribution point extension. If this
extension is not present on the first entry in an indirect CRL ...
... CRL that has the indirectCRL
indicator set in its issuing distribution point extension. If this
extension is not present on the first entry in an indirect CRL, the
certificate issuer ...
... certificate issuer defaults to the CRL issuer. On subsequent entries
in an indirect CRL, if this extension is not present, the certificate ...
... issuer defaults to the CRL issuer. On subsequent entries
in an indirect CRL, if this extension is not present, the certificate
issuer ...
...
If used by conforming CAs that issue CRLs, this extension is always
critical. If an implementation ignored this extension it could not
...
... critical. If an implementation ignored this extension it could not
correctly attribute CRL entries to certificates. This specification
RECOMMENDS that implementations recognize this extension.
...
... certificate had not been revoked at time T and is not
currently on hold status that commenced before time T, (this
may be determined by obtaining the appropriate CRL or status
information, or by out-of-band mechanisms), and
...
... algorithms which may be used to sign certificates
and CRLs, and identifies OIDs for public keys contained in a
...
...
Certificates and CRLs described by this standard may be signed with
any public key signature algorithm ...
... public key signature algorithm. The certificate or CRL indicates
the algorithm through an algorithm identifier ...
... one-way hash function used to sign a
certificate or CRL is indicated by use of an algorithm identifier.
An algorithm identifier ...
... The majority of this specification is devoted to the format and
content of certificates and CRLs. Since certificates and CRLs are
...
... certificates and CRLs. Since certificates and CRLs are
digitally signed, no additional integrity service is necessary.
...
... integrity service is necessary.
Neither certificates nor CRLs need be kept secret, and unrestricted
and anonymous access to certificates and CRLs ...
... CRLs need be kept secret, and unrestricted
and anonymous access to certificates and CRLs has no security
implications.
...
... CRLs. Existence of bogus certificates and
CRLs will undermine confidence in the system. If the compromise is
detected, all certificates issued to the CA ...
... signing key may also be problematic. The CA
would not be able to produce CRLs or perform normal key rollover.
CAs are advised to maintain secure backup for signing ...
... extnValue OCTET STRING }
-- CRL structures
CertificateList ::= SEQUENCE {
...
...
-- The following information object set is defined to constrain the
-- set of legal CRL extensions.
CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier |
...
...
-- The following information object set is defined to constrain the
-- set of legal CRL entry extensions.
EntryExtensionSet EXTENSION ::= { reasonCode |
...
... object classes used in the defintion --
-- of certificates and CRLs --
-- Parameterized Type SIGNED --
...
... INTEGER (0..MAX)
-- Basic CRL extensions --
cRLNumber EXTENSION ::= {
...
... IDENTIFIED BY id-ce-invalidityDate }
-- CRL distribution points and delta-CRL extensions --
...
...
-- CRL distribution points and delta-CRL extensions --
cRLDistributionPoints EXTENSION ::= {
...
...
This section contains four examples: three certificates and a CRL.
The first two certificates and the CRL ...
...
Section D.4 contains an annotated hex dump of a CRL. The CRL is
issued by the CA whose distinguished name ...
...
This section contains an annotated hex dump of a version 2 CRL with
one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us
...
... version 2 CRL with
one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us
on July 7, 1996; the next scheduled issuance was August 7, 1996. The
CRL ...
... CRL was issued by OU=nist;O=gov;C=us
on July 7, 1996; the next scheduled issuance was August 7, 1996. The
CRL includes one revoked certificates: serial number 18 (12 hex).
...
... certificates: serial number 18 (12 hex).
The CRL itself is number 18, and it was signed with DSA and SHA-1.
...