Vous êtes sur la page 1sur 5

user in the world is quite unlikely.

Instead, the concept of decentralized CAs for different countries,


political organizations and businesses is far better. This allows the CAs not only to worry about a smaller
population of users, but also work independently. Moreover, cross-certification allows CAs and end
users from different PKI domains to interact.
More specifically, cross-certification certificates are issued by the CAs to create a non-hierarchical
trust path. Let us understand this with an example as shown in Fig. 5.25.
As the figure shows, the root CAs of Alice and Bob are different - but they have cross-certified each
other. Technically, this means that Alice's root CA has obtained a certificate for itself from Bob's root
CA. Similarly, Bob's root CA has obtained a certificate for itself from Alice's root CA. Now, even if
Alice's software trusts only her own root CA, it is not a problem. Since Bob's root CA is certified by

Alice's root CA, Alice can and does trust the root CA of Bob. This also means that Alice can verify Bob's
certificate using the path Bob - Q2 - PI - Bob's root CA - Alice's root CA. We shall not describe how this
happens, as we have already explained this process in great detail earlier.
The morale of the story is that with the technologies of certificate hierarchies, self-signed certificates
and cross-certification, virtually any user can verify any other user's digital certificate and based on that,
decide to either trust it or reject it.
5.2.9

Certificate Revocation

Introduction If your credit card is lost or if it gets stolen, you would normally immediately report the loss
to the concerned bank. The bank would cancel your credit card. Similarly, digital certificate can also be
revoked. What can be the reasons for the revocation of a digital certificate? Some of the most common
ones are as follows:

The holder of the digital certificate reports that the private key corresponding to the public key
specified in the digital certificate is compromised (i.e. someone has stolen it).
The CA realizes that it had made some mistake while issuing a certificate.
The certificate holder leaves a job and the certificate was issued specifically while the person was
employed in that job.
In all such cases, the digital certificate of the user gets the same status as that of a stolen credit card.
Therefore, the certificate must be treated as invalid. For this purpose, the certificate must be revoked. What
is the process for this? Normally, just as a credit card user reports a credit card loss or theft, a certificate
holder should report that a certificate should be revoked. Of course, if the user leaves an organization or
indulges in an illegal act because of which the certificate needs to be revoked, the organization should
initiate the process. Finally, if the CA realizes its own mistake in providing a wrong certificate, the CA
initiates the certification revocation process.

In any case, the CA must come to know about this certificate revocation request. Also, the CA must
authenticate the certificate revocation requester before accepting this revocation request. Otherwise,
someone can misuse the certificate revocation process to potentially request for the revocation of a
certificate that belongs to another user!
Let us assume that Alice wants to use Bob's certificate for securely communicating with him.
However, before she uses Bob's certificate, Alice wants answers to the following two questions:

Does this certificate really belong to Bob?


Is this certificate valid or is it revoked?
We know that Alice can use the certificate chain to establish the first fact. Let us assume that Alice is
satisfied that the certificate indeed belongs to Bob. Now, she has to check the second aspect, which is,
whether the certificate is still valid or not. How can Alice do this check? For this, the CA provides the
facilities as shown in Fig. 5.26.

Let us discuss these revocation status check schemes now.


Offline Certificate Revocation Status Checks The Certificate Revocation List (CRL) is the
primary means of checking the status of a digital certificate offline. In its simplest form, a CRL is a list
of certificates published regularly by each CA, identifying all the certificates that have been revoked
through the life of the C A. However, this list does not include certificates whose validity period is over.
A CRL lists only those certificates whose validity period is still within the acceptable range, but they are
revoked for some other reason (such as the ones listed earlier).
Each CA issues its own CRL. The respective CA signs each CRL. Therefore, a CRL can be easily
verified. A CRL is simply a sequential file that grows over time to include all the certificates that have not
expired, but have been revoked. Thus, it is a superset of all the previous CRLs issued by that CA. Each
CRL entry lists the certificate serial number, the date and time on which the certificate was revoked and

the reason behind the, revocation. At the top level, the CRL also includes the information such as the
date and the time this CRL was published and when the next CRL will be published. This logical view
of a CRL file is shown in Fig. 5.27.

Thus, when Alice receives Bob's certificate and wants to see if she should trust it, she should do the
following, in the given sequence:

Certificate expiry check: Compare the current date with the validity period of the certificate to
ensure that the certificate has not expired
Signature check: Check that Bob's certificate can be verified in terms of the signature by his CA
Certificate revocation check: Consult the latest CRL issued by Bob's CA to ensure that Bob's
certificate is not listed there as a revoked certificate
Only after Alice is assured of all these three aspects that she can trust Bob's certificate. This is shown
in Fig. 5.28.
A CRL can become really quite big over time. The general assumption is that about 10% of unexpired
certificates will be revoked every year. Thus, if a CA has about 100,000 users, in two years time, its
CRL could contain 20,000 entries! This is quite large. Moreover, remember that CRL checks need to be
performed even by users who want to use the certificates of other users in applications that execute on
handheld devices! If a mobile phone has to store and check a CRL of size 20,000 users, it has to receive
the CRL file first over the network, which is a great bottleneck. This problem led to the concept of delta
CRL.
Initially, a CA can send a one-time full up-to-date CRL to the users who want to use the CRL
services. This is called as the base CRL. However, at the time of the next update, the CA need not send
the entire CRL file once again. Instead, the CA can simply issue the changes (called a delta) to the CRL
since the last update. This mechanism makes the CRL file size small and, therefore, its transmission
easier. The changes to the base CRL are called as delta CRL. The delta CRL is also a file, like CRL,
which is also signed by the CA. The difference between issuing a complete CRL every time versus only
a delta CRL is shown in Fig. 5.29.
Several points need to be kept in mind when working with delta CRLs. Firstly, a delta CRL file
contains an indicator called as the delta CRL indicator. This indicator informs the user that this CRL
file is not a complete, comprehensive CRL file, but instead, it is only a delta CRL. Therefore, the user
knows that she has to refer to the base CRL along with this CRL file in order to obtain the complete
CRL. Secondly, each CRL also contains a sequence number, which allows the user to check if all the

Vous aimerez peut-être aussi