Internet DRAFT - draft-gerck-pkix-revocation
draft-gerck-pkix-revocation
PKIX Working Group
Internet Draft Ed Gerck
Document: draft-gerck-pkix-revocation-00.txt NMA, Inc.
Expires: November 2004 May 2004
Certificate Revocation Revisited
Internet X.509 Public Key Infrastructure
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
PKIX certificate revocation protocols are primarily described in
RFC3280. This Document revisits limitations on determining the
revocation status of a certificate. Ambiguous aspects of revocation
and revocation delegation are resolved. An objective point of view
is introduced as a reference that does not depend on the observer
(e.g., the RP). The revocation status of a certificate issued by a
conforming CA is shown to be always well-defined from a relying
party's point of view -- i.e., it is unambiguous (revoked or not
revoked) and ultimately determinable at any period in time. The
limitations on determining the revocation status of a certificate
have nothing to do with the eventual result of the determination
process by a relying party. The limitations have to do with the
efforts for that determination, which may require a large (actually
unspecified) amount of time and work. Some practices are also
suggested, allowing a relying party to determine the revocation
status of a certificate with higher reliability in less time. The
same considerations apply to determinations of status "change"
processes, including certificateHold and removefromCRL.
Gerck Expires - November 2004 [Page 1]
Certificate Revocation Revisited May 2004
Conventions used in this document
In this document, a relying party (RP) is a user who processes a
certificate chain, and then acts in reliance on the end-entity (EE)
certificate issued by a CA (the issuer CA) and any associated
revocation information. "Trust" is defined in [Ger98]. The
"objective point of view" is defined as a coincident view that any RP
can see in a given time period when not constrained by access, amount
of work and processing time. The "RP point of view" is defined as a
view that a particular RP can see in a given time period, which is
constrained by several factors including access, amount of work and
processing time.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Table of Contents
1. Overview.......................................................3
2. Relying Party, RP Reliance and Reliance Limitations............5
3. Revocation Revisited...........................................6
3.1 Objective Point Of View....................................7
3.2 RP Point Of View...........................................8
3.3 RP Reliance Limitations....................................9
3.4 Revocation vs. Validity....................................9
3.5 Reliance vs. Use..........................................10
3.6 When is a Certificate Revoked?............................10
3.7 Conclusion................................................10
4. Revocation Conditions and Improvements........................11
4.1 Summary of Revocation Conditions..........................11
4.2 Available Revocation of Delegation........................11
4.3 Limitations of Indirect CRLs..............................12
4.4 Limitations of Revocation Status Services.................12
4.5 Limitations of Revocation Status Processing...............13
4.6 Increasing Reliability....................................13
4.7 Can A Certificate Be Valid When Revoked?..................14
4.8 Alternative Authoritative Revocation Mechanisms...........14
4.9 Validation Services.......................................14
4.10 New Environments.........................................15
Security Considerations..........................................15
References.......................................................15
Acknowledgments..................................................16
Author's Addresses...............................................16
Full Copyright Statement.........................................16
Gerck Expires - November 2004 [Page 2]
Certificate Revocation Revisited May 2004
1. Overview
This Document revisits the limitations of RP reliance on the
revocation status of a X.509/PKIX certificate. This Document also
points out the conditions on those limitations with a view to
reducing their effect in current and future implementations, allowing
a relying party to determine the revocation status of a certificate
with higher reliability in less time.
The same considerations apply to determinations of status "change"
processes, including certificateHold and removefromCRL.
PKIX certificate revocation protocols are primarily described in
RFC3280, involving the conditions for designating a certificate as
revoked as well as the conditions that enable a user to actually
determine the revocation status of a certificate. The PKIX
standardization effort aimed to safely automate the process of RP
reliance. This goal required the PKIX certificate path processing
algorithm to eliminate any violations of those policies (i.e.,
vulnerabilities) that might be hard to recognize or difficult to
foresee, which would interfere with the goal of specifying a wholly
automated process of handling certificates.
For a particular certificate, revocation can be delegated to entities
other than the issuer of the certificate. Similarly, parties other
than the issuer, including the delegate responsible for revocation,
can perform publication of revocation information. This means that an
RP verifying the certificate's revocation status (e.g., using
mechanisms such as querying a repository or receiving notices
delivered via a message service) will depend on the administration
and management of that status by one or more authoritative entities.
In addition, different RPs may or may not have access to one or more
of the authoritative repositories and/or authoritative message
notification services.
Also, each one of the repositories and notification services may
possibly have different values and different delay properties
concerning communication of revocation status for the same
certificate, at any given time. Therefore, the revocation status of a
particular certificate may appear to be revoked, non-revoked and
undefined, all at the same time, for different RPs.
Similar issues have been recognized and addressed in distributed
transaction coordination protocols, such as file-locking in a multi-
user environment, and these techniques are also useful for the
reliance problem at hand.
This document revisits and resolves the ambiguities besetting
certificate revocation in PKIX, answering the following questions:
Gerck Expires - November 2004 [Page 3]
Certificate Revocation Revisited May 2004
1. What are the conditions for a certificate's revocation status to
be true?
2. Can a certificate be, at the same time, revoked and not revoked?
3. Can a revocation status service ever correctly indicate a given
certificate to be revoked when its revocation conditions are
false?
4. Can a revocation status service ever correctly indicate non-
revocation status for a given certificate when its revocation
conditions are true?
5. When is a certificate revoked?
6. What are the limitations for an RP relying on the revocation
status of a certificate?
7. Can current limitations for RP reliance on revocation information
be reduced?
This Document also calls attention to the distinction between
"revocation conditions" and "revocation status". Revocation status is
a binary value (revoked or not revoked) that depends on time and the
revocation conditions. The revocation conditions are the logical
conditions for defining the revocation status. Revocation conditions
are normally defined for the life of the certificate, when the
certificate is issued; however, they may also be authoritatively
redefined from time to time. For example, to better address the needs
of RPs.
The revocation status of a certificate is not enough to define the
validity of that certificate from a particular RP's point of view.
Certificate validity is a function of a number of additional
parameters, including the certificate path that the RP trusts to
validate the certificate, the access to revocation status information
available to the RP, the local policy used by the RP, and the PKI
application that motivates the RP to employ certificates. The
validity of a certificate refers to conditions that are
authoritatively defined locally.
The distinction between "revocation" and "validation" has been
somewhat blurred in the documentation and practice. The distinction
is, however, necessary to preserve both the control needs for PKI,
requiring centralized conditions of revocation that are
authoritatively defined by the issuer CA, and those business and user
needs, requiring local authoritative definition of validation.
Gerck Expires - November 2004 [Page 4]
Certificate Revocation Revisited May 2004
RP reliance is discussed as a technical term. The concept of RP
reliance is needed in PKIX/X.509 because not every aspect of
certificate management can be fully verified by an RP. For example,
an RP does not rely on the CA for certificate path processing but may
rely on the CA for ensuring that the CA's signing key is properly
secure and not compromised. The latter cannot be verified by the RP
and becomes, thus, a limitation for reliance.
Another important distinction is between "reliance" and "use". PKIX
defines certificate reliance by an RP in terms of its issuance and
revocation conditions as determined by the issuer CA. This may
include how, where and when the revocation status is provided for a
certificate. However, there is no violation of PKIX if a user
(otherwise known as an RP) decides to be on its own and simply "uses"
the certificate and its information, ignoring one or even all the
limitations for reliance defined in PKIX and by an authority. A user
can also use any source it desires for the revocation status of a
certificate, including none at all.
Notwithstanding all the above limitations, the conclusion of this
Document is that the revocation status of a certificate issued by a
conforming CA is always well-defined from the issuer's, the issuer's
delegates and any RP's point of view -- i.e., it is objectively
unambiguous (revoked or not revoked) and ultimately determinable at
any period in time by any entity.
The above limitations on determining the revocation status of a
certificate have nothing to do with the eventual result of the
determination process. The limitations have to do with the effort an
RP must expend to make that determination, which may require a large
(actually unspecified) amount of time and work. Depending on the
users' reliance obligations, furthermore, Human intervention may also
be necessary to augment automated path processing in those situations
when complete elimination of Human oversight might cause foreseeable
policy violations. For example, for the purpose of a user reading a
timely message subject to a legal policy requiring it to be read upon
receipt, a user may override waiting for the automated path
processing result.
In addition, some practices are suggested for publishing and
verifying revocation information, allowing an RP to verify the
revocation status of a certificate with greater reliability in less
time.
2. Relying Party, RP Reliance and Reliance Limitations
A relying party (RP) is a user who processes a certificate chain, and
then acts in reliance on the end-entity (EE) certificate issued by a
CA (the issuer CA) and any associated revocation information.
Gerck Expires - November 2004 [Page 5]
Certificate Revocation Revisited May 2004
RP reliance is a technical term in PKIX. The concept of RP reliance
is needed in PKIX/X.509 because not every aspect of certificate
management can be fully verified by an RP.
For example, a user verifying a certificate's revocation status
(e.g., using mechanisms such as querying a repository or receiving
notices delivered via a message service) will depend on the
conforming administration and management of that status by one or
more authoritative entities -- i.e., the user becomes a relying party
to these entities.
More generally, a user who depends on values provided by an entity
(e.g., CA) that seem reasonable on their face value to the user but
are especially hard to check by the user is an RP to that entity.
What does the RP rely on? The RP relies on entities (e.g., the CA)
following PKIX recommendations that the RP CANNOT verify. For
example, an RP does not rely on the CA for certificate path
processing (because the RP CAN verify it) but may rely on the CA for
ensuring that the CA's signing key is properly secure and not
compromised. The latter cannot be verified by the RP and becomes,
thus, a limitation for reliance.
RP reliance limitations are objectively defined in PKIX, without
reference to domain policies, user security policy, jurisdiction-
based rules of laws and contracts or anything else that needs to be
locally defined.
As a literal value, RP reliance on the revocation status of a
certificate is defined by a conforming certificate path procedure
leading to a bit value -- "revoked" or "not revoked". The literal bit
value depends both on processes that the RP CAN verify and processes
that the RP CANNOT verify. The latter defines the limitations of RP
reliance. The lesser the limitations of RP reliance, the lesser the
risk faced by the RP that RP reliance might be broken by factors
outside RP control.
The literal bit value has no associated semantics outside the scope
of PKIX. In other words, RP reliance is syntactic, not semantic. Any
semantic value (e.g., legal reliance, contractual obligations
concerning use, public policy, etc.) MUST lie outside the scope of
PKIX and is, for example, regulated by terms in the CA's CPS.
3. Revocation Revisited
Certificate revocation, involving the conditions for certificate
revocation as well as the actual value of the revocation status for a
certificate, has been defined in the PKIX specification with the
Gerck Expires - November 2004 [Page 6]
Certificate Revocation Revisited May 2004
requirement that a certificate path processing could be securely
mechanized in support of RP reliance.
Because a particular certificate may be used by different RPs at
different times, it is desirable that all RPs have the same view of
the revocation status of the certificate at a given time. Otherwise,
the information that the certificate is not revoked at a given time
cannot be relied on by an RP, or represented to another RP, at a
later time.
In other words, while the PKIX notion of RP reliance defines a value
that is determined subjectively (i.e., the revocation status of a
certificate from the RP's point of view) at a point in time, the
application PKI requires the RP to use such value as an objective
representation of the revocation status when communicating with other
entities at a later point in time.
A clear definition of the revocation status of a certificate from an
objective point of view is necessary, therefore, to eliminate the
ambiguity as to what that status might be for different RPs and
entities. Central to this requirement is the determination when the
certificate was revoked, also expressed in terms that an RP can use
in communication with other entities.
2.13.1 Objective Point Of View
The "objective point of view" is defined as a coincident view that
any RP can see in a given time period when not constrained by access,
amount of work and processing time. This point of view is called
objective because it does not depend on the observer (e.g., the RP).
What matters to the objective point of view is the revocation status
of a certificate, be this represented in a repository or as a status
message, and whether it has been published by some means reasonably
available to any RP.
3.1.1 Does the objective point of view exist for PKIX certificates?
Yes. In X.509/PKIX each certificate is unique and there is only one
issuer CA for a given certificate. Only the issuer CA of a
certificate is authoritative for revocation conditions of the
certificate. Therefore, the issuer CA can define conditions leading
to an objective view (i.e., a coincident view that any RP can see in
a given time period when RPs are not constrained by practical limits
such as access, amount of work and processing time) of the revocation
status of a certificate.
3.1.2 What are the conditions for a certificate's revocation status
to be true from the objective point of view?
Gerck Expires - November 2004 [Page 7]
Certificate Revocation Revisited May 2004
If a certificate is listed as revoked by means of one of those
mechanisms identified by the issuer CA in a conforming certificate
extension (e.g., a CRL signed by the CA, an indirect CRL signed by
the CRL issuer, an OCSP status, an HTTP CRL list), OR if any other
revocation condition defined by the issuer CA applies (e.g., a root
certificate is compromised), the certificate is revoked. Otherwise,
the certificate is not revoked.
3.1.3 Can a certificate be, at the same time, revoked and not revoked
from the objective point of view?
No. Because the revocation status of a certificate refers to
conditions that a conforming issuer CA authoritatively and
unambiguously defines for each certificate, a certificate is either
revoked or not from the objective point of view.
3.1.4 Is the revocation status of a certificate ambiguous, for
different RPs?
No. When not limited by access, amount of work and time, any RP sees
the same value for the revocation status of a certificate at any
period in time.
2.23.2 RP Point Of View
From a particular RP's point of view, there are several limitations
on determining the revocation status of a certificate at any given
period in time. Generally, the RP's point of view is limited by
access, amount of work and processing time, which are locally defined
and may be different for each RP.
For example, if an RP does not support any of the mechanisms defined
by the issuer CA to verify the revocation status, or times out during
such verification, or cannot find a path to verify the authenticity
of messages used in certificate status protocols, then the revocation
status is undefined for that RP. According to RFC3280, this can
happen even for a conforming CA and conforming RP software. For
example, conforming CAs are not required to issue CRLs if other
revocation or certificate status mechanisms are provided. This fails
to interoperate with conforming applications, that are NOT REQUIRED
to support processing of delta CRLs, indirect CRLs, or CRLs with a
scope other than all certificates issued by one CA. Furthermore,
since no CA MUST offer even one of the standardized mechanisms,
conforming applications may be left groping in the dark for
revocation information.
Also, since there may be more than one scheme used to determine the
revocation status of the same certificate, the occurrence of race
Gerck Expires - November 2004 [Page 8]
Certificate Revocation Revisited May 2004
conditions, differently available paths (even within the same
scheme), and the conditions affecting the revocation status of the
parent certificates can lead to ambiguous results for different RPs.
Therefore, different RPs may arrive at a different "view" of the
revocation status of a EE, CA or cross certificate at a particular
time.
2.33.3 RP Reliance Limitations
What are the limitations for an RP relying on the revocation status
of a certificate?
An RP relying on the revocation status of a certificate, determined
by any mechanism (i.e., whose reliance is authorized or not by the
issuer CA of the certificate), is nonetheless limited by the
revocation conditions defined by the issuer CA. Those conditions may
change from time to time. Some mechanisms may not include direct
evidence of the issuer CA's assertion of a certificate's revocation
status or conditions, at a particular time.
2.43.4 Revocation vs. Validity
Another important distinction concerns the processes of "revocation"
and "validation". Revocation and validation should be understood as
distinct technical terms -- revocation has to do with the issuer's
actions (or the actions of an issuer's delegate) while validation has
to do with a relying party's actions.
This distinction reflects the needs of the issuer (who seeks to
control RP reliance limitations in order to impose uniform conditions
of revocation and hence RP reliance) and the concurrent needs of each
domain of business and individual users (whose reliance obligations
require them to comply with their own domain's local, and possibly
conflicting to other domains', authoritative definition of
certificate validity).
Clearly, revocation could not be well-defined if it were defined to
be, at the same time, centralized and local. Introducing the
validation concept provides the richer conceptual framework that
addresses the presumed antagonistic needs of the issuer and the user,
in the handling of RP reliance.
There are also those cases in which user communities (i.e., domains)
may choose to adopt one or other validation model based on some
prevailing operational rationale. The flexibility of having both a
centralized control over the conditions of revocation while
supporting localized validation is an important feature of
X.509/PKIX.
Gerck Expires - November 2004 [Page 9]
Certificate Revocation Revisited May 2004
2.53.5 Reliance vs. Use
Another important distinction is between "reliance" and "use". The
PKIX standards define the limitations for certificate reliance by an
RP in terms of a certificate user complying with the issuance and
revocation conditions for a certificate. Furthermore, PKIX requires
that compliance must occur through execution of the standardized
certificate path processing algorithm. However, there is no act of
non-compliance if an RP simply decides to act independently of the
authority, with a "use" of the certificate, rather than a "reliance
upon" the certificate, its revocation conditions and its revocation
status. When merely "using" a certificate in this sense, the user
will normally be ignoring any or all the compliance requirements
defined in PKIX and/or the authority, when processing a chain of
certificates and using an EE certificate issued by a CA.
2.63.6 When is a Certificate Revoked?
Here we ask the critical question: When is a certificate revoked? The
answer is: when the corresponding revocation status is published by
means of one of those mechanisms identified by the issuer CA in a
conforming certificate extension, OR when any other revocation
condition defined by the issuer CA applies. It does not matter when a
particular RP is able to verify that status, or what mechanisms an RP
can use for such purpose. Nor does it depend on the ultimate purpose
of reliance, or the actual secondary use made of reliance during
private communications between the RP and others after the reliance
determination has been made. The revocation status of a certificate
issued by a conforming CA does not depend on an RP and is always
well-defined from an RP's point of view -- i.e., it is unambiguous
(revoked or not revoked) and ultimately verifiable by the RP at any
period in time.
2.73.7 Conclusion
From an objective point of view, valid for all RPs relying on a
particular certificate, a PKIX certificate is either revoked or not
revoked at any period in time.
From a particular RP's point of view, the limitations on determining
the revocation status of a certificate have nothing to do with the
eventual result of that determination, which is always well-defined -
- i.e., it is unambiguous (revoked or not revoked) and ultimately
determinable by the RP at any period in time. The limitations have to
do with the efforts for that determination, which may require a large
(actually, unspecified) amount of time and work. Human intervention
may also be necessary.
Gerck Expires - November 2004 [Page 10]
Certificate Revocation Revisited May 2004
The same considerations apply to determinations of status "change"
processes, including certificateHold and removefromCRL .
3.4. Revocation Conditions and Improvements
This section expands and points out the conditions on some of the
limitations discussed in section 2, with a view to reducing their
effect. Further, practices are suggested for publishing and verifying
revocation information, allowing an RP to determine the revocation
status of a certificate with higher reliability in less time.
3.14.1 Summary of Revocation Conditions
In X.509/PKIX there is only one issuer CA for a given certificate.
Only the issuer CA of a certificate is authoritative for revocation
conditions of the certificate, which is assumed to be uniquely
identifiable (e.g., issued with a unique serial number for that CA).
One of those revocation conditions is that the certificate must be
signed by the CA's private "certificate signing" key. This key must
be issued formally by the issuer CA, must not be expired and must not
be presently revoked. Another condition is that the issuer CA may
delegate the authority for a particular certificate's revocation
notices and/or status publication to another entity called the CRL
issuer, identified by the CA in the CRL Distribution Point (CDP)
extension of the certificate. Another condition is that the issuer
CA may send the revocation notice for a particular certificate as a
status service to other types of delegated status services,
identified by the CA in the Authority Information Access (AIA)
extension of the certificate with an OCSP access descriptor or an
HTTP CRL access descriptor.
The RP should also determine if any of the CA certificates along the
chain from the issuer CA to an acceptable root CA is expired or has
been revoked or suspended, because such expiration, revocation or
suspension could have the effect of prematurely terminating the
operational period of the certificate and all certificates signed by
it.
3.24.2 Available Revocation of Delegation
Is there a mechanism to limit the period of delegation?
Yes. The issuer CA can authoritatively revoke delegation to the CRL
issuer, or other types of delegated status services. Delegation is
not decided, although implied, for the whole lifetime of the
certificate. Delegation is also not necessarily done for all
certificates issued by a CA (e.g., an indirect CRL issuer may be a
partial CRL issuer, in X.509). The issuer CA could revoke any signing
Gerck Expires - November 2004 [Page 11]
Certificate Revocation Revisited May 2004
certificate in the chain and re-issue all certificates it desires
with a different delegation specification or even no delegation.
This mechanism provides the CA with ultimate control over a wayward
CRL issuer or other type of delegated status service provider.
3.34.3 Limitations of Indirect CRLs
If the indirect CRL is verified by an RP, is there any requirement
for the RP to also verify any CRL issued by the issuer CA?
Yes. Because the RP must verify the signed CRL using certificates,
and in particular must recursively rely upon the certificate showing
that the CRL issuer (or other party) has current delegation
authority, certificate revocation status also depends on whether the
issuer CA signing certificate (or any certificate in an acceptable
chain to the root) is expired, revoked or suspended, OR whether any
other revocation condition defined by the issuer CA applies. See
(2.3), (3.1), and (3.2).
3.44.4 Limitations of Revocation Status Services
4.4.1 Can a revocation status service or a CRL publishing service
indicate a certificate to be revoked when the certificate is not
revoked?
Yes. If a CA sends status data to an OCSP Responder including a
revocation notice before creating a CRL, the certificate in question
is revoked for an RP receiving the OCSP Responder's status but not
for an RP accessing only the current CRL. Even along a single
certificate chain, different RPs may have access to different
revocation status for the CA's own certificate or any cross
certificate used in the chain.
Further, as demanded by chain processing rules, an expired, revoked
or suspended parent certificate may or may not cause an RP to deduce
that a child certificate status is revoked, independently of the
current authoritative revocation status of the certificate.
Similarly, by recursion, an expired certificate used when relying
upon an indirect CRL can also influence whether or not a user
performs the act of reliance.
4.4.2 Can a revocation status service indicate non-revocation status
when the certificate is revoked?
Yes. As given above.
Gerck Expires - November 2004 [Page 12]
Certificate Revocation Revisited May 2004
3.54.5 Limitations of Revocation Status Processing
Resolution of revocation status may be difficult for the RP's
software. For example: the software may need, under the local
validation policy, to wait for a fresher CRL then that currently
available; the software may need more time than what is available for
the desired action; the software may need additional communication
channels that are not available to the software at the time of
checking; the validation policy might require human intervention, and
so on. Using any single mechanism to verify revocation status can be
seen by an RP as introducing a single point of failure, which might
not be acceptable.
An RP relying on the revocation status of a certificate is also
subject to the RP Reliance Limitations described in section (2.3).
3.64.6 Increasing Reliability
With a view to reducing the effect of the limitations discussed in
this Document, an RP can verify bounds on the extent of those
limitations, or at least establish bounds.
An RP can also define multiple paths, to provide redundancy and
diversity. The additional efforts should increase the ability of the
RP to make a reliance determination of a certificate's revocation
status in less time.
For example:
- There are various unspecified and unpublished delays between the
time a CA, CRL issuer or OCSP Responder receives notice to revoke,
suspend, or reinstate a certificate and the time the information
status is made available through the CA's CRL, an indirect CRL, a
delta CRL, an OCSP Responder, a DPV Server, or a client.
Nonetheless, some of these bounds can be actually known or modeled
by an RP, and be addressed in the local validation policy
underpinning the decision to rely.
- To prevent single access faults and race conditions, a certificate
can include multiple mechanisms to specify revocation information,
some of which can be redundant mechanisms, where an RP should be
able to interoperate with any of those mechanisms that it trusts.
Multiple mechanisms available to an issuer CA include a CDP
extension with a URI DistributionPointName, an AIA extension with
an OCSP access descriptor, and an AIA extension with an HTTP CRL
access descriptor. An RP receiving both an OCSP Responder's status
and the CA's CRL for a certificate is less susceptible to race
conditions caused by CA's delays when sending status data to the
Gerck Expires - November 2004 [Page 13]
Certificate Revocation Revisited May 2004
OCSP Responder with a revocation notice and publishing a CRL for
the certificate in question.
3.74.7 Can A Certificate Be Valid When Revoked?
4.7.1 Can a certificate be valid when its revocation status is
revoked?
Yes. The validity of a certificate refers to conditions that are
authoritatively defined locally (see section 2.4). For example, for
the purpose of an RP reading a timely message, a validation policy
may consider a certificate to be valid when no revocation status can
be contacted.
Generalizing this behavior is an implementation flaw, however. For
example, the widely used TLS/SSL security application in Internet
browsers does not currently verify the revocation status of EE and CA
certificates and always considers the resulting undefined revocation
status as valid.
4.7.2 Can an RP rely on validity information alone?
Yes. As above.
3.84.8 Alternative Authoritative Revocation Mechanisms
The PKIX WG has defined a number of certificate revocation protocols.
However, it may be sometimes desirable to revoke certificates using
alternative schemes as well. For example, a certificate can also be
authoritatively revoked when the issuer CA or the CRL issuer makes
the revocation status available to an RP in a reasonable way. For
example, by signed XML messages in a wireless network, by SQL over
HTTPS, or in a signed SOAP response for database lookup over web
services. What matters to the RP is the revocation status, in a
repository or as a status message, and whether it has been published
by some means acceptable by the RP under its validation policy.
3.94.9 Validation Services
A CRL Issuer or an OCSP responder may perform additional processing,
beyond aggregating and republishing revocation notices as revocation
status services. If the operator of the service knows an RP's
validation policy/criteria, they may apply those criteria when
creating a validation service for that RP. In this case, the
"validation service" is a policy-enhanced validation (not revocation)
status service tuned to the acceptance processes of the RP, rather
than only to the revocation processes of CAs and their delegates.
Gerck Expires - November 2004 [Page 14]
Certificate Revocation Revisited May 2004
A validation service can help reduce the limitations described in
this Document, for example by implementing the multiple mechanisms
discussed in section (3.6). In this case, the service provider is an
agent of the RP, performing the same validation processing as the
user would have performed when making a reliance determination.
3.104.10 New Environments
This Document also intends to provide a framework for the development
of new PKI environments, including IPSEC, Internet 2, IPv6 and
routing table distribution schemes, DNS, and spam control. These new
environments will also present new demands on PKI techniques, in
particular on the handling of revocation information.
Security Considerations
Revocation lists, or CRLs, are needed to notify that an otherwise
valid certificate is not valid. This, which relies on the issuer CA
for centralized revocation conditions, presents several unsolved
(implementation wise) and unsolvable (design wise) problems in
X.509/PKIX.
For example, there may be a considerable delay (no boundaries are
provided within PKIX on upper limits for such delays) between a
revocation notice (e.g., as submitted by the certificate's subject)
and the reflection of this need in a CRL or revocation status. The
available documentation is also silent about some aspects of
revocation and revocation delegation. This silence may be read as
implying some affirmations and denying others. This is faulty,
because the meaning of the text is ambiguous for security purposes.
This Document clarifies affirmations and limitations on certificate
revocation that are coherent with the corpus of X.509/PKIX documents,
thereby potentially improving security. The final section of this
Document also points out the conditions on those limitations, with a
view to reducing their effect. Using any single mechanism to verify
revocation status is seen as introducing a single point of failure
from the RP's software point of view. Using multiple sources of
information on the revocation status of a certificate can provide
diversity and redundancy, reducing the influence of race conditions
and ambiguity.
References
[Ger98] In terms of a communication process, trust has nothing to do
with feelings or emotions. Trust is qualified reliance on
information, based on factors independent of that
information. Trust needs multiple, independent channels to
be communicated. Trust cannot be induced by self-assertions.
Gerck Expires - November 2004 [Page 15]
Certificate Revocation Revisited May 2004
More precisely, "Trust is that which is essential to a
communication channel but cannot be transferred using that
channel." See "Trust Points" by E. Gerck in "Digital
Certificates: Applied Internet Security" by Jalal Feghhi,
Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20-
130980-7, pages 194-195, 1998.
[Sha48] Shannon, C. A Mathematical Theory of Communication. Bell
Syst. Tech. J., vol. 27, pp. 379-423, July 1948.
http://cm.belllabs.com/cm/ms/what/shannonday/paper.html
Acknowledgments
The names cited do not mean endorsement of this work, which is the
sole responsibility of the author. I would like to thank very useful
comments by Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp,
Steve Kent, Stefan Santesson, Peter Williams, Julien Stern and the
PKIX list. I am also thankful to Peter Williams for final editing
comments.
Author's Addresses
Questions about this Document can be directed to:
Ed Gerck
NMA, Inc.
1001 D Street
San Rafael, CA 94901
Email: egerck@nma.com
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Gerck Expires - November 2004 [Page 16]
Certificate Revocation Revisited May 2004
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gerck Expires - November 2004 [Page 17]
