CRL's are worse than a snakepit, they are a snakepit disguised as
a beautiful garden of solutions.
The revocation of privileges is tough enough in a controlled
environment like a UNIX operating system. In a fully distributed
email security system the certain revocation of a certificate is, IMHO,
an impossibility. As we have seen, it is remarkably easy to construct
scenarios where the revocation is not available when needed.
Let's try to isolate what a certificate is supposed to be. This may be
a near impossibility as I have been unable to find any statement in any
of the PEM RFC's nor in the X.500 stds as to the purpose of a certificate.
There is some reason to believe that the binding of a key to a specific
user was the intended purpose based on some definitions in X.511 and in
several threads on this board that discussed policy statements and what
they might contain.
If the reason for a certificate is to create a binding between a user
and a key then, ipso facto, the only reason to revoke a certificate is
when the binding becomes invalid. The only reasons I can think for
this to occur is when it is found that the individual lied about his
identity or the same key is found to belong to another user. Both
somewhat unlikely situations.
The discussion in this thread has wandered about the issue of the
purpose of a certificate or a certificate revocation. Several problems
unrelated to the binding of a user to a key seem to be looking to
the CRL as a solution. Some of those proposed include:
1> the key is compromised - this should result in a "KEY" revocation
but the certificate is what we know, so we revoke it, or at least one
of the certificates for the key. Other certificates may, of course,
continue in force so we don't know what the meaning of a CRL is if this
is allowed.
2> the authorization of the key holder is changed - this is an internal
issue of the organization and does not necessarily change the key or
the binding of the key to the user, but it does change the user, and
perhaps also the user's Distinguished Name. Since the DN is the ID
contained in the certificate, it does make a certain amount of sense
to issue a new certificate, but that raises another problematic
issue that has been addressed recently here, namely, What is a
Distinguished Name? Should the DN carry all the baggage of a company's
internal organizational structure? A recent editorial in "Open Systems
Today" on X.500 proposed that one reason an X.500 directory will never
succeed is that companies DO NOT WANT their internal mailing lists
open to competitor's and head-hunters. It seems that the CRL is not
the only snake pit around.
It seems to me that the certificate has taken on too many meanings and
that it may be time to restrict it's use to those meanings that it
can reasonably support. One major difficulty is the absence of any
guidance in such issues by the PEM RFC's. It is as though there was
a deliberate attempt to avoid providing such basic definitions there.
- - - IMHO - - -
The CRL was instituted as a means of salvaging the "really neat" means
of distributing certificates directly from the message originator. The
"really neat" way of distributing certificates is the rose garden that
the PEM promoters discuss. The snakepit is not described. It's time
that we start a "Truth in Advertising" statement here, the ease of use
of the certificate is a chimera that is designed to lead the unwary into
the snake pit of certificate revocation.
Peace ..