I have been working with RSA and with Michael Baum's ABA workshop
on Notarization and Nonrepudiation, trying to define/refine policies for CAs and
PCAs. I have been focussing on the RSA Commercial Hierarchy, and have proposed
some additions that might be called a user's Bill of Rights.
In particular, I have been trying to place some reasonable bounds on the
liability
that might be associated with a user's digital signature, especially in the
event
that his key is stolen or compromised. As part of that overall effort, I
started to
think about certificate revocations and their implications for routine business
correspondence, potentially including requests or orders to buy or sell things.
(I am not trying to address wholesale or retail banking or commercial
EDI transactions, which are typically well structured and have or will have
additional mechanisms at their disposal, e.g., the ANSI X9F1 type of
authorization
certificate.) I wanted to include language that would make it clear that the
user has
no oblication or liability for any document allegedly signed after the user's
certificate
has been posted as revoked by the PCA.
However, I have concluded that the current CRL system is a snakepit of problems
masquerading as solutions. (Gentlemen, start your flamethrowers! But first hear
me out.)
As I understand the current PEM CRL mechanism, a user can request his CA to
revoke
his certificate any time he wishes. The CA can also unilaterally revoke a
user's
certificate if the binding implied by that certificate is no longer valid. CAs
are
obligated to post a CRL to their PCA at routine intervals that are defined by
the PCA,
even if the CRL list is empty, just to indicate that no certificates have been
revoked.
The CRL indicates when the next scheduled CRL is supposed to happen, but if
there is an "emergency" CRL posted the various users have no guaranteed
mechanism
to notify them of that fact. If a routine CRL was issued on the 1st of the
month and an
emergency CRL is issued on the 2nd of the month and the user's certificate was
due to
expire on the 29th of the month in any case, it is not clear to me whether the
next
routine CRL submission (on the 1st of the next month) would provide any notice
at all!
The PCA is presumed to post CRLs as soon as they are received, but there is no
statement in the PEM standards that dictates how soon such a CRL should be
posted,
nor any discussion about the degree of reliability, availability and response
time that
should be provided. (Presumably those are issues which each user, or at least
each CA,
must decide for itself in choosing a PCA, i.e., one of those infamous "local
matters".)
The CRL is timestamped by the CA, but not necessarily accurately. And the time
that
really matters, i.e., when the CRL was posted at the PCA, isn't timestamped at
all.
Under these assumptions, if the recipient of a signed document wishes to be
able to
prove that the document was presumably legitimate, he must send the document
off to
a trusted timestamp server to establish exactly when the document was received,
and
then he must wait 30 to 60 days until the next regularly scheduled CRL list is
posted by
that user's CA to establish the fact that the originator's certificate (and
that of his CA)
hadn't expired. And because we haven't required either the CA or the PCA to
apply a
TRUSTED time stamp to the CRL, the recipient has to send the received CRL list
off to
the timestamp server to establish the correct time. (Actually, this isn't
sufficient,
because the recipient might have retrieved an out-of-date CRL and sent it to
the
timestamper to "prove" that the certificate hadn't been revoked yet. So what we
really
need is a trusted timestamp applied by the PCA, or for the timestamp service to
go get
the current CRL list itself, and timestamp that.)
Then, finally, the recipient has to archive the timestamped document itself,
together
with the user's certificate chain (extracted from the recipient's certificate
cache or
X.500 directory if the certificates weren't included in the document itself),
together with
the timestamped CRL list which unfortunately may contain lots of revoked
certificates
pertaining to OTHER users, just to establish the fact that this user's
certificate (nor his
CA's certificate) was not among them!
Nonrepudiation is one of the key attributes that can be provided by a digital
signature
approach, but to say that the current system is a bit clumsy would be an
understatement.
It clearly is not adequate for any type of commercial transaction, for no one
would be
to hold a transaction in abeyance for 30 to 60 days waiting for confirmation of
the user's
certificate. One could even argue that it isn't good enough for determining
whether or
not someone should be able to send encrypted mail to someone else, since that
user's
keys might have been compromised. (Since one of the primary reasons why PEM is
supposed to be superior to PGP is because it "scales better" and it "handles
revocation
better," it would behoove us to take these issues seriously.)
I have to conclude that the routine CRL distribution mechanism is only of value
for the
revocation of certificates that don't matter very much in any case, e.g., for a
routine
change of address notification. I may have moved, or I may have changed jobs
within
my organization, but I am still me, and presumably I still retain all of my
rights and
privileges. I may even get married and change my name, but there is no great
harm
done if the rest of the world continues to rely on my previous certificate for
another 30 to 60 days, or even longer.
If I change companies, however, that may no longer be the case. Even if I
do not have any particular role or agent position such as a Purchasing Agent, I
no longer have the right to speak for or even as an employee of that company.
And others who may have sent me encrypted email or other documents believing
that
I was covered by a nondisclosure agreement signed by my company no longer have
that assurance. And obviously if I somehow discover that my private key has
been
compromised, I want to cancel that certificate immediately -- both to protect
myself
from potential liabilitiy and to ensure that communications that were supposed
to
be sent to me in confidence will not be disclosed to someone else. In all of
these cases,
it is important that the certificate revocation take effect immediately --
certainly within 24
hours.
So far, the periodic distribution of CRLs doesn't satisfy the recipient of a
document who
wishes to verify its authenticity, because it isn't sufficiently timely. It
doesn't
satisfy the originator of an encrypted document, because it dosn't protect his
private
message from being disclosed if the recipient's key has been compromised, or if
he is
no longer entitled to receive it. And it doesn't protect the user against a key
compromise and the various liabilities that may befall him, even if the
recipient were
willing to take a certain amount of risk.
I therefore have to conclude that if the validity of the binding of the user's
public key
to that user's identity matters at all, then the routine, periodic distribution
of CRLs is a
badly flawed mechanism, and that an inquiry-reponse system will eventually be
required.
Presumably many of these difficulties will be alleviated when we all have
access to
a distributed X.500 system. when a user's certificate is revoked, the X.500
directory
administrator will presumably remove the certificate from the directory, as
well as posting
some kind of a revocation notice. However, it should be noted that X.500 is not
designed or even intended to be precisely synchronized at all sites, and there
are
substantial issues to deal with in how to flush out all of the cached
certificates
in the distributed X.500 directory quickly and reliably.
In the meantime, we clearly need some other kind of mechanism. RSA has
committed to
provide both a telephonic and an e-mail based service to inform its users
whether a
particular certificate had been revoked. I would suggest that this be a simple
yes/no
answer that is timestamped and signed by the PCA, e.g., "As of September 17,
1993, at
12:00:01 PM EST, neither the user's certificate number xxxxx, issuer yyyyy, nor
the
issuer's certificate, had been revoked. Signed, RSA-DSI." If the entire
certificate were
submitted, the user's name could be spelled out and the validity period
confirmed as well.
Now if someone holds a document that was signed by me and timestamped by a
trusted
timestamp server on or before 9/17/93 at 12:00:00 PM EST, the holder of that
document should
be entited to what the lawyers call a rebuttable presumption that the document
was in
fact signed by me, and therefore I can and should be held responsible for the
contents. By archiving that statement of nonrevocation along with the
timestamped
document, the recipient has a much simpler and cleaner means of establishing
nonrepudiation.
This simple solution solves a number of important problems, but it also creates
some
others that need to be addressed:
1. Suppose that the RSA Commercial Hierarchy (or any other one) becomes
wildly
successful, and that 10s or even 100s of thousands of users start
validating
certificates every day. What are the network implications of all of
that traffic
flowing to and from a single site -- especially if everyone does it at
9:00 AM?
2. What are the risks and denial of service implications for such a
system? What
happens if California slides off into the ocean, taking Redwood City
and RSA
along with it? Does the entire country or even the entire financial
world shut
down?
3. What are the technical standards and requirements that should apply to
a trusted
timeserver? How is the master time derived, and what degree of fault
tolerance
and accuracy agreement should be required assuming that multiple time
sources
are in use? [I have some thoughts on this, but mercifully the margins
are too
narrow for me to elaborate on this at this time.]
4. Do we need to have a uniform architecture for this type of inquiry and
response
system, so that users will be able to use the same type of system
across multiple
PCAs? [In my opinion, yes.]
5. Considering the risk of putting too many eggs in one basket, not matter
whose
basket it is, should we consider putting some of this burden on the
CAs, instead
of the PCA being the only authoritive source for CRL's? [Either that,
or the
the PCA is going to have to be replicated extensively.]
The issues of network gridlock and denial of service are clearly extremely
important,
so much so that it will probably be necessary for a large PCA to establish an
extremely
reliable system of fault tolerant computers in multiple locations (at least
East and
West coast) that are networked together and precisely synchronized, so that a
certificate is not "posted" as revoked until or unless it is posted everywhere
simultaneously.
Enough said. Comments?
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
617/466-2603 FAX
Jueneman(_at_)GTE(_dot_)COM