Mr. Muftic,
I can see that there might be some merit in having the
CAs distribute CRLs to other CAs directly, rather
than having them all funneled through the PCA (or
the IPRA, worse yet). Apparently the folks at Bell
Labs are planning to do this, and may even have such
a system running.
Let me think out loud as to what some of the pros and
cons might be:
PRO:
1. The communications load would tend to be spread
more or less evenly throughout the network
2. The system would be more robust. The failure of
a PCA or a link to a PCA would not be as disruptive.
3. Assuming that the CAs are operated primarily by
the user's employers and may be certifying their
own agents, they will have a vested interest
in ensuring that certificates are revoked promptly
and reliably. With this scheme the CAs would control
their own destiny and would not have to trust a
PCA to issue (post/distribute) their CRLs.
CON:
1. This would require that every CA operate an online
responder. This would increase the system
installation and operation cost significantly.
2. With the current Distinguished Name structure,
the e-mail address of the CA's CRL responder would
not be obvious. In fact, the CA may not even be
interconnected to the rest of the Internet. Unlike
X.400, PEM does not require network connectivity
in order to provide privacy and nonrepudiation.
As an future CA operator, I would probably be willing
to provide an online server in order to gain the
advantages listed under PRO. I particularly like the
trust model implications of not having to rely on the PCA
to retain and distribute my CRLs, when I may be liable
for the misuse of a certificate. (The CAs sign the CRLs,
but it is difficult to validate the signature on a CRL if
the PCA accidently deletes it or fails to post an
emergency CRL.)
At present, however, the lack of correspondence in
general between the name of a CA and its e-mail
address is a potential show-stopper. If we had a real
X.500 directory this wouldn't be a problem -- we could
look up the address. And if we were using X.400, we
could probably impose a name such as C=US, O=GTE,
CN="CA CRL Server". But I can't control and therefore
don't want to bet on the availability of X.500, and I
am not yet convinced of the merits of X.400 when
compared to SMTP + PEM + MIME (assuming we
can make all that happen before the millenium.)
(I realize that in the COST system you have forced a
correspondence between the DN and the user's e-mail
address and therefore the CA's e-mail address, but
frankly that is the one aspect of your system that I
like the least. I am oriented toward wanting to
ensure accountability for users, but if all that I know
about someone is his e-mail address on DOCKMASTER
or CompuServe or the Well, I really don't know anything
at all.)
Maybe we could come up with some sort of a
compromise solution. The following would seem
reasonable to me, at least at first glance:
1. Continue to rely on the PCA as the CRL distribution
mechanism of last recourse. If you can't get the
information you need anywhere else, go to the PCA.
(But it may cost you.)
2. The PCA could publish a list of CAs and their
CRL responder's e-mail addresses. Of course,
some CAs could contract with the PCA to provide
that service for them.
3. The PCA and the CAs would both post a list of CRLs
for anyone to retrieve that wished to, on a weekly
basis.
4. The CAs would respond to two types of requests:
a. Please send me the up-to-the-minute CRL
list, so I will know the status of everyone in
your domain as of today, or even hourly.
b. Please confirm the current validity of issuer X,
certificate Y.
As long as we are going to consider getting the CA in
loop and online, I would like to add the requirement that
the CA maintain a trusted timestamping service,
at least trusted within its domain. Then I would modify
the positive response option (4b) to say "Please
confirm the current validity of issuer X, certificate Y,
with a timestamped and digitally signed message."
Better yet, lets combine one more function -- that of
timestamping the document in question. Now I can
say "Here is a message digest of a message signed
with issuer name X, certificate Y. Please confirm the
validity of that user's certificate as of the time of receipt
of this request, and include both the validity confirmation
and the message hash in your signed reply."
Since it is the CAs responsibility to issue certificates and
CRLs and to control the validity period, it makes sense
for that CA to be the trusted timekeeper for that function.
The time doesn't even have to be absolutely accurate --
if the CA says that the certificate was valid at the time
the message was received, that should be sufficient.
The net advantage of this hypothetical system would
appear to be:
1. It preserves the existing PEM functionality. Anyone
who needs to can get a CRL from the PCA whenever
necessary.
2. It provides a reasonably efficient mechanism for
handling the daily or even hourly distribution of
emergency CRLs to those who might need them,
and it places the burden of those transactions on
the user's CA where it probably belongs.
3. It provides a convenient mechanism for obtaining
a timestamped confirmation of both the existance of
a message and the validity of the originator's
certificate in one compact message that can be
easily archived along with the message.
A final possibility would be for the user to send the
message, or at least the message digest, to the CA
and have the CA countersign the digest to confirm
the validity of the user's certificate at that instant.
This confirmation could be included in the message
itself. Since the entire purpose of the CRL is to
indicate whether a certificate was valid at the time the
message was sent, having the CA confirm the validity
at the time of transmission in a way that is bound to the
message itself seems to solve the whole problem. The
CRL mechanism could then be used to control
revocation of CAs, which will hopefully be a much
less time-critical problem.
(This almost seems too simple. I hope I haven't fallen
into some obscure and terrible logic trap again, but I
think this works.)
Bob