Cryptography Reference
In-Depth Information
the CAs included in the browser. Another security issue is that of expiration dates,
which leads to the possibility of the user being allowed to accept a certificate even
though it has expired. Thus expiration dates often become meaningless in practice,
since users tend to accept expired certificates anyway.
Yet another PKI model is the “web trust model” in which each user is his own CA.
In this model, a variant of which is adopted by the PGP email encryption software,
anyone can issue certificates to anyone else and each user decides whether or not to
trust certificates issued by other users. Therefore, users are expected to collect public
keys of other users as well as certificates of these public keys issued by other users
and there is also the possibility of storing public keys and certificates in a central
database. Whether the public keys and certificates come directly from users or from
a database, it is up to each user to decide how much trust to place in any of these
public keys.
The web of trust has the advantage of not requiring trust in a central authority
but, in some sense, it is not a true PKI because it requires users to set trust levels by
themselves. This requires a certain degree of technological knowledge and does not
seem adequate for environments in which security is essential. Another drawback is
that there is no revocation mechanism for invalid certificates and no assurance that
forged certificates will be detected. However, as is the case with the PGP software,
it works pretty well for encrypting email for average users.
As we have seen, certificates usually contain an expiration date after which they
are not valid and should not be accepted. When users verify certificates they are
supposed not only to check the validity of the signature but also the validity period.
However, this does not offer a good solution for situations inwhich a certificate should
cease to be valid despite its expiration date not having yet arrived. For example, it
might happen that a certificate is stored in a smart card which is lost or stolen.
Another common reason might be that an employee left an organization losing the
right to use the public key that the organization had supplied. In order to deal with
these situations, it must be possible for the CA to
revoke
certificates by issuing a
certificate revocation list
(CRL, for short) that contains a list of the serial numbers
of the revoked certificates and signing it.
For the CRL to serve its purpose users should check, in addition to the verifications
already mentioned, that the serial number of the certificate does not appear in the
latest CRL issued and should also check the signature of the CA in the CRL itself.
The main drawback of CRLs is that they have to be transmitted to users and, if this
transmission is not done frequently, then there are time intervals in which a certificate
might have been revoked without users being aware of this fact. On the other hand,
contacting the CA each time one wants to use a certificate—in order to learn whether
the certificate has been revoked—is not practical. Thus the best approach seems to
be to update CRLs relatively often but, hopefully, not so often as to provoke network
bandwidth problems.
As can be gleaned from the previous remarks, key management is a very complex
process and is perhaps the weakest component in the implementation of public-key
cryptography. There are important practical difficulties associated with the devel-
opment of PKIs, ranging from the determination of who should be responsible for
