Traditional way
of certificate validation (CRL)
The need
for validation satisfies the Certificate Revocation Lists (CRL).
This list is issued (and digitally signed) by a trustcenter
and contains the serial numbers of all revoked (= invalid) certificates.
As this list is subject to change, newer lists get issued from
time to time.To allow clients access to the most current CRL most
trustcenters make them available using LDAP (Short for Lightweight
Directory Access Protocol, a set of protocols for accessing information
directories) or HTTP (Short for HyperText Transfer Protocol,
the underlying protocol used by the World Wide Web that defines
how messages are formatted and transmitted, and what actions Web
servers and browsers should take in response to various commands).
Technical details and specification of CRL can be found at RFC2459.
Risks
of validation by CRL
To allow
caching of a CRL at the users location, every CRL contains informations
of its period of validity. That means a CRL can be issued every
5 minutes and have a period of validity of somewhat like an hour.
As one can imagine this caching is directly linked to the risk
that a revoked certificate is used. The longer a client is allowed
to use (cache) an old CRL, the higher is the risk of
using a revoked certificate.
The
way of distributing a CRL (via HTTP or LDAP) imposes the problem
of network traffic. CRLs of large Trust Centers can reach big
size (around 0,5 MB). Every client trusting a server of one of
this large Trust Centers should download the complete CRL. This
is not only a significant delay in accessing these websites for
the user but also generates a very high network traffic.
The solution to this maybe to allow caching of these CRLs for
a longer time, but as mentioned before this imposes a higher risk
of using revoked certificates.
An alternative
way that eliminates the disadvanteges of CRL is the OnlineCertificateStatusProtocol.
