First of all, I want to apologize to the good folks at
BellCORE for referring to them as Bell Labs. I certainly
know better, but maybe old habits die hard.
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.
I don't mean to go overboard on this point, but I was concerned about some
smaller companies that might not even have permanent Internet access, but
only run their own local LAN. such companies might not be set up to provide
of routine around the clock network access that we take for granted.
But just as RSA will act as co-issuer for companies that choose not to invest
in a a hardware-based certificate issuing system, I'm sure that service
companies and VANs would be happy to provide such a service for them.
This does tend to lend additional weight to having a very flexible system
for associating DNs with email addresses, though.
At present, however, the lack of correspondence in
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 ...
Anguish and grief are certainly appropriate terms. As we have seem in a
number of other contexts, we have loaded a lot of semantic baggage
onto the DN, because that was all that was available in the X.509
certificate. But X.509 was primarily designed to allow a user to authenticate
himself to the Directory service itself, and for that use it is presumably
sufficient (although we may not know until we actually try to use this feature
for directory access control).
Now, however, we are more or less forced to use it to identify the user
"himself" (plus or minus a number of roles and other attributes) for both
key management and digital signature controls, AND try to figure out a
way of deriving the user's Internet e-mail address(es) from a structure that
was oriented more towards X.400, AND we have imposed name subordination
in order to try to cope with some of these problems, AND now we can't figure
out how to contact the user's CA and/or his PCA, especially in cases of
unaffiliated or residential persons. All this in the absence of an
as-yet-to-be-
proven-to-be-viable distributed directory service. What a mess!
I'm not suggesting that we throw out both the baby and the bath water and
start over -- perish the thought. But these problems are beginning to look
increasingly cumbersome and potentially intractable, so maybe it would
be a good idea for some of the Internet gray beards to drop back a step or
two and take a more general look at this problem. Any volunteers?
Vint Cerf suggested that we think about using something like the Domain Name
Server. Maybe the PCAs should operate something like that, that would at least
tell a user the email address of the CA's CRL server.
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 smaller scale).
I didn't mean to imply a "push" distribution approach, for I don't think
such systems are very effective. By "post" I simply meant that the
PCA and or CA would make the CRL list available for anyone to retrieve
that wanted to. At this point I don't care whether this is accomplished
by an inquiry/response mechanism from the UA, access to a shared file
via NFS, a DNS type of mechanism, etc.
My main point was that posting updates weekly would reduce the number
of certificates that are revoked between updates. Weekly, as opposed to
monthly, updates (and retrievals, if necessary) make sense for weekend
access when the network utilization is lower, whereas the beginning of the
month may fall on a Wednesday.
In addition, I suspect that many user's would feel that the risk of not
checking for the absolutely most current CRL given a weekly update
is sufficiently low as to be acceptable for most applications (but maybe
not for accepting an order to buy or sell stock).
Assuming this is so, it should be feasible to use a positive confirmation
mechanism to solve both the up-to-the-minute need, and also to have
a single certification of a user's certificate validity signed by the CA
for archiving and nonrepudiation purposes.
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.
No, not quite. Under option 4a, the user would receive a CRL
list that would be identical to one from a PCA, at present.
For nonrepudiation, however, the recipient would have to
have a trusted third party (quasi-notary, although that term
is misleading, especially outside of English common-law countries)
request the CRL from the PCA and timestamp it along with the
message.
But the revised option 4b, "Please confirm the validity of issuer X,
certificate Y as of the current moment with a tImestamped and
digitally signed message" is certainly preferable.
The PCA presently does not timestamp the CRL list, so it is necessary
to have this trusted entity that not only has to timestamp a message
but also has to go query the PCA in a trusted manner. This seems to
me to fundamentally wrong, and a serious oversight. (Someone who
has the RFC lying open in front of him, please correct me if I am wrong
on the absence of the PCAs timestamp on the CRL list.)
The CA does timestamp each certificate to be revoked and also
timestamps when the entire list was last posted. but unfortunately we
haven't specified what degree of accuracy or trust is required in
that time. Is an independent stratum 1 rubidium oscillator required,
or WWV, or GPS, or is it sufficient to use a DOS local clock and to
set it once a year with the time changes, according to the local
DJ's Mickey Mouse watch?
Regarding the overall trust model, I don't think it would be wise to
place too much trust in the PCA. Sure, I want them to do a good job.
But even if they screw up the management of the CA certificates, I
can probably establish the validity of my own CAs public key by virtue
of the large number of certificates issued to all my employees. In
addition, any PCA with a lawyer worth his salt is going to be so concerned
about the potential deep pockets liability and consequential damages
issue that the PCA-CA agreements will have disclaimers in 48 point type.
So no matter how much you trust them, don't count on bing able to
sue them for damages.
I HAVE to trust my CA, however, and in most cases the CA will be operated
by the organization that will have most of the liability in any case. I'm
very cautious about making claims for cryptographic protocols, but I THINK
that having the CA of the originator of a message validate the user's
certificate as not expired and not revoked is sound. If they try to play games,
they are hanging themselves with their own rope since they were the ones
that said the certificate was valid. For this same reason, I believe that
although it would be nice if the CA's time server were accurate in an absolute
sense, since it is the CA that specified when a certificate was to expire,
it is that CA's local time that should be definitive in any case.
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.
I agree. I only suggested having the user send the outgoing message
to his CA for timestamping as a means of eliminating the need for the
recipient to go back to the CA with the message digest and request
confirmation as a separate process.
Most messages won't require nonrepudiation, and if the recipient is
concerned he can go get confirmation at the time of receipt.
However, if the originator knows in advance that an up-to-date
confirmation will required because time is of the essence, e.g.,
when puying or selling stock, it would be desirable to reduce or
eliminate the round trip delay. It would also facilitate the archive
and nonrepudiation process, if it is known in advance that that
will be required.
Bob