P1: JDW
PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0
164 PUBLICKEYINFRASTRUCTURE(PKI)
ACs may be short- or long-lived. In Figure 6, the AC per-
mits Alice to administer the VPN for 4 hours. As a result
of the short validity period, the AC issuer does not need to
maintain revocation information. By the time revocation
information could be compiled and distributed, the AC
would expire. So, with short-lived ACs, revocation infor-
mation is not distributed. If an AC has a longer life span
(for example, weeks or months), then the organizations
would need to maintain AC status information.
An AC can be obtained in two ways. The AC holder
may provide the AC; this is known as thepush model.
Alternatively, the AC is requested from the AC issuer or a
repository; this is known as thepull model.A major benefit
of the pull model is that it can be implemented without
changes to the client or to the communications protocol.
The pull model is especially well suited to interdomain
communication.
The AC is linked to a public key certificate in one of
two ways. The AC holder can contain the issuer and serial
number of a particular public key certificate, or the AC
holder can contain a subject name. In the first case, the AC
is linked to a specific public key certificate. In the second
case, the AC is linked to a particular subject, and the AC
may be used in conjunction with any public key certificate
held by that subject.
FUTURE DEVELOPMENTS
One of the criticisms of PKI is that CRLs can become too
large. When this happens, the overhead associated with
CRL distribution is unacceptable.Sliding window delta
CRLscan be used to reduce this overhead. Another crit-
icism of PKI is that certification path construction and
validation can be difficult. By delegating these functions
to a trusted server, the amount of processing an applica-
tion needs to perform before it can accept a certificate can
be significantly reduced. Sliding window delta CRLs and
delegated path validationare not widely deployed today,
but they are likely to be employed in the future.
Sliding Window Delta CRLs
For PKIs that rely on CRLs, the challenge is to provide
the freshest information to certificate users while mini-
mizing network bandwidth consumption. Unfortunately,
when PKIs rely on full CRLs, these requirements are in
direct conflict. To maximize the freshness, CRLs must
be updated frequently. As the time interval between up-
dates shrinks, the probability that a client will find a use-
ful CRL in its cache diminishes. At the extreme, certifi-
cate users will download a full CRL for each certificate
validation. Most of the information on the CRL is the
same, and identical information is transmitted repeatedly,
consuming bandwidth without providing any benefit. To
minimize the consumption of network bandwidth, CRLs
should have reasonably long lifetimes. As the time inter-
val between updates grows, the greater the probability
that relying parties will have the appropriate CRL in their
cache.
In the simple case,delta CRLsand full CRLs are is-
sued together, and the delta CRL lists all the certificates
revoked since the last full CRL was issued. A certificate
user, who has the previous full CRL, may obtain complete
information by obtaining the delta CRL and combining
it with the already cached, previous full CRL. The certifi-
cate user obtains the freshest information available but
consumes a fraction of the bandwidth. If the certificate
user does not have the previous full CRL, the full CRL
must be downloaded.
A sliding window delta CRL lists all the certificates re-
voked since an earlier full CRL, perhaps six generations
earlier. This delta CRL may be combined with any of the
full CRLs from the previous six generations. By repeating
some of the revocation information in the delta CRL, there
is a greater likelihood that the certificate user will have an
acceptable full CRL in the cache, yet the amount of re-
peated information is small enough to avoid consuming
significant bandwidth.
Most of the PKI-enabled applications do not exceed
the limitations of full CRLs. As a result, delta CRLs are
not widely deployed. Few commercial PKI client imple-
mentations process delta CRLs. Fewer CA products can
generate sliding window deltas. As PKIs grow, however,
the incentive to deploy innovative certificate status will
likely grow.
Delegated Path Validation
Some PKI implementers want to offload the entire cer-
tification path construction and validation process to a
trusted server. A relying party would provide a validation
server with an end-entity certificate, one or more trust
points, and the initial values for certification path valida-
tion, then the path validation server would respond with
a message informing the relying party whether the certifi-
cate was acceptable. Standard protocols for these services
have not yet been developed. This work is currently un-
derway in the IETF PKIX Working Group.
Delegating the certificate validation process to a
trusted server has a number of advantages. The certifi-
cate user achieves path construction and validation with
a single roundtrip protocol, and then the certificate user
verifies a single digital signature on the response. The
single roundtrip is especially important in bandwidth-
limited environments, especially wireless environments.
If the certificate user has limited processing power, the
reduction in signature verifications is also significant.
Delegating the certificate validation process to a trus-
ted server may also provide performance advantages. If
the path validation server has cached the necessary cer-
tificates and CRLs, the path validation server may be able
to construct and validate a certification path quickly.
These benefits are not free. The path validation server
performs all of the security-relevant operations. The path
validation server must be secure, because it is the sole
trust point for the relying party. In addition, some of the
performance enhancements are based on the ability of the
server to obtain and cache information. PKIs that rely on
OCSP may be counterproductive to this model. In such a
case, the path validation server is not likely to hold the re-
quired status information. The server will have to retrieve
revocation information from the OCSP responder for each
certificate in the certification path, mitigating much of the
performance gain.