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.
These are all good points.
CON:
1. This would require that every CA operate an online
responder. This would increase the system
installation and operation cost significantly.
I don't think so. There really isn't a whole lot involved in setting
up a responder. An important thing to note is that there is no
authentication required to the responder since it acts as just that,
a _responder_. Users/CAs can retrieve CRLs from it, but have to verify
the signatures on the CRLs on their own.
With no authentication, the only thing involved in running a responder is
a database lookup mechanism and a mail processing interface (or a daemon,
depending on the transport mechanism chosen). Our system runs using TIS/PEM
and a mail forwarding script.
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 wholeheartedly agree with this point. The name mapping issue is
one which has caused us great anguish and grief in planning for the
future under this system. One idea I had was to use a standard
mail address (e.g. "ca-server", "crl-service", or some such name)
much in the way "postmaster" is used today. That way, we would have
"crl-service(_at_)gte(_dot_)com", "crl-service(_at_)mit(_dot_)edu",
crl-service(_at_)bellcore(_dot_)com",
etc. This works fine for those organizations which have an internet
address of this form, but doesn't take care of the dockmaster or
CompuServ accounts. Hmm ...
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.)
Good idea - this preserves the PCA's responsibility to maintain
copies of all its subordinate CRLs.
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.
Another possibility.
3. The PCA and the CAs would both post a list of CRLs
for anyone to retrieve that wished to, on a weekly
basis.
This gets us back to the "push" method of distribution - and where
would these lists be posted? It seems that each CA/PCA should post
a list of CRLs to each of its subscriber CAs. However, I'm not sure
what this gains. If we were to expand the distribution of such a list,
we get back to the traffic problem (albeit on a msaller scale).
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."
I also believe that timestamping would greatly enhance the
functionality provided by the CAs. The only way for a user/CA to
be ensured of a valid response under your (4a) would be to have
that response timestamped by the responder.
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.
I believe this to be an elegant solution to the problem of verifying
whether a certificate was valid at the time it was used. One question,
though - what kind of overhead are we adding to the signing process by
doing this? I think this could be an option which a sender could use,
but I don't know whether it should be required for all messages.
- Anish
----------------------------------------------------------------------------
Anish Bhimani | "LAPD - We treat you like a King."
Enterprise Network Integrity, Bellcore | -- T-shirt seen on Venice Beach
anish(_at_)ctt(_dot_)bellcore(_dot_)com
(908) 699-5571 (phone) (908) 336-2969 (fax)