Information Technology Reference
In-Depth Information
between these revocation systems. Although CRL is criticized for its unnecessary
consumption of storage and bandwidth, CRL can be the most ecient solution
in some PKI environments [7]. Therefore, we wish to clarify our design principles
behind ACSP in this section.
Requirement 1: Explicit Revocation Mechanism.
To avoid cumbersome
revocation, some PKIs eliminated explicit revocation mechanisms. For example,
the short-lived certificate proposed by the WAP forum has a very short validity
period with no means of invalidation [13]. Some fundamental questions about
short-lived certificate are presented in [9]. We will use an explicit revocation
mechanism where certificates can be revoked before its expiration time when
the circumstances dictate.
Requirement 2: Online Certificate Status Checking.
Online revocation
status checking may significantly reduce the latency between a revocation report
and the distribution of the information to relying parties. After the CA accepts
the reports as authentic and valid, any response to the revocation status query
will correctly reflect the impacts of the revocation [4]. Since the acceptor requires
the revocation status information as recent as possible, online certificate status
checking can provide the best evidence for validity. Hence, our system will be
constructed based on OCSP.
Requirement 3: No Bulky Data Like CRL.
The main complaint about
CRL is that the size of the revocation list can become huge. The size of CRL is
in linear proportion to the population of entire PKI users. This discourages some
devices such as mobile equipments from accommodating CRL. As our system
will be based on online status checking, we can easily do without a large data
structure like CRL.
Requirement 4: Recency Requirements Must Be Set by the Acceptor,
not by the CA [12].
In general, the acceptor, not the CA, runs the risk if his
decision is wrong. Hence, recency requirements have to be set by the acceptor,
not by the CA. Note that we used the phrase “in general” because there are
some instances where the certificate issuer takes more risks than the acceptor
[7]. The acceptors in CRL and OCSP cannot set their recency requirements. By
contrast, our system will provide acceptor's flexible recency requirements.
Requirement 5: Acceptor Should Take Care of Certificates Not Satis-
fying His Recency Requirements.
Consider the following scenario: Before
leaving on summer vacation, Alice decided to send an e-mail to Bob. Alice sent
a message with her signature and certificate. Then, she enjoyed her vacation in
a silent island. When Bob received Alice's e-mail, he noticed that her certificate
does not satisfy his recency requirements. If Bob can take care of this certificate,
