Information Technology Reference
In-Depth Information
can face the risk of accepting this revoked certificate as valid. To overcome these
shortcomings, some remedies can be applied: delta CRL, partitioned CRL, CRT
(Certificate Revocation Tree) [5] and their variants [6,8,11].
Since high value transaction requires that the validity of a given certificate
be checked in real-time, CRL cannot be a suitable revocation mechanism for
this application. The most popular mechanism that provides real-time status of
a certificate is OCSP (Online Certificate Status Protocol) [10], where a client
generates an “OCSP request” and a server replies to the client with an “OCSP
response.” OCSP is appropriate for applications where timeliness is of high pri-
ority. A major drawback of OCSP is the heavy load required by the server. Since
the server has to be involved in every transaction, the number of generations of
OCSP responses can be very large. Fox and LaMacchia pointed out that the
data format of a certificate could be used as that of an OCSP response to reduce
system complexity [2].
In general, the acceptor takes risks concerning his decisions about whether
certificates supplied by a signer are stale or not. Therefore, the acceptor wants
signer's certificates to be as recent as possible. Every acceptor has his “recency
requirements.” Some acceptors will be satisfied with a day-old certificate and
others with a week-old certificate. However, recency requirements in CRL and
OCSP are determined by the CA, not by the acceptor; recency requirements in
CRL are limited by the CRL issuance period, and real-time query is the only
option in OCSP.
The first scheme providing acceptor's flexible recency requirements was intro-
duced by Rivest [12]. His goal was the elimination of CRL by the use of acceptor's
flexible recency requirements. However, there was no explicit revocation method
in his system. Even though he pointed out that this problem could be solved by
“suicide bureaus,” they complicate the trust model. Another scheme providing
acceptor's flexible recency requirements, called ROD (Revocation on Demand),
was introduced by McDaniel and Rubin [7]. ROD uses a publish/subscribe mech-
anism [14] for CRL delivery. Since ROD is based on CRL, ROD has some short-
comings inherited from CRL, e.g., high consumption of storage and bandwidth.
In this paper, we propose a new certificate revocation status checking sys-
tem called ACSP (Advanced Certificate Status Protocol) that provides accep-
tor's flexible recency requirements. ACSP is based on OCSP for real-time status
checking. Hence, ACSP does not need bulky data like CRL. To overcome the
heavy computational load of CA, we reduced the number of generating “ACSP
responses” by certificate re-issuance technique and re-transmission of the re-
issued certificate. In most environments, ACSP requires less computational and
communicational workload compared with OCSP while providing acceptor's flex-
ible recency requirements. We also propose ACSP+ that is a variant of ACSP
with a proxy responder.
2 Design Principles
Until now, many certificate revocation systems have been developed. However,
no revocation system can fit all PKI environments. There are some tradeoffs
