Cryptography Reference
In-Depth Information
to be maintained carefully, normally by the CA who is responsible for issuing
the certificates, with clear indications of how often they are updated. The
CRLs need to be digitally signed by the CA and made available to relying
parties.
Whitelisting
. This involves maintaining a database that contains serial numbers
of public-key certificates that are valid. This database can then be queried by
a relying party to find out if a public-key certificate is valid. An example is
the
Online Certificate Status Protocol
(OCSP), which has been standardised
as RFC 2560. This is particularly useful for applications that require real-time
information about the revocation status of a public-key certificate.
Rapid expiration
. This removes the need for revocation by allocating very
short lifetimes to public-key certificates. This, of course, comes at the cost
of requiring certificates to be reissued on a regular basis.
Blacklisting is a common technique when real-time revocation information
is not required. There are many different ways of implementing the blacklisting
concept, often involving networks of distributed CRLs rather than one central
CRL. The main problemwith blacklisting is one of synchronisation. In particular,
there are likely to be:
• reporting delays between the time that a public-key certificate should be
revoked (for example, the time of a private key compromise) and the CA being
informed;
• CRL issuing delays between the time that the CA is informed of the revocation
of a public-key certificate and the time that the next version of the CRL is signed
and made publicly available.
Thus, in theory, a relying party could rely on a public-key certificate in the gap
period between the time the public-key certificate should have been revoked and
the publication time of the updated CRL. This is an issue that must be 'managed'
through suitable processes and procedures. For example:
• The CA should inform all relying parties of the update frequency of CRLs.
• The CA should clarify who is responsible for any damage incurred frommisuse
of a public key in such a gap period.
It might be reasonable to address
this by:
- the CA accepting limited liability during gap periods;
- relying parties accepting full liability if they fail to check the latest CRL before
relying on a public-key certificate.
The means of conveying this information to relying parties is through publication
of the key management policies and practices of a CA (see Section 10.7.1). The
relevant documents for a CA are often referred to as
certificate policy statements
and
certificate practice statements
. They not only clarify the issues just discussed,
but also the wider key management issues relating to public keys that the CA
certifies.
