[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CRL format revision -Reply



One reason field that you might want to consider is a SUSPENDED flag.

Although the need for certificate suspension, rather than outright revocation,
has been argued rather extensively and emotionally even within the PKIX group,
Frank Sudia and others have convinced me that there are circumstances w
here the outright revocation of a certificate would have draconian 
consequences if the certificate were revoked in error, but the potential 
liability of the subscriber or the CA would be too great to tolerate doing nothing
while a more detailed investigation is undertaken as to whether a 
compromise has really occurred, whether the person requesting the 
revocation is really authorized, etc.

It is not intended that the suspended state would last more than 
say 72 hours, after which it would either revert to no suspension, or to a
full revocation. In the meantime, it lets the relying decide whether to 
proceed or not, at his own risk.

An additional application for the suspended state is for applications 
which need to issue light-weight certificates to users with a minimum 
amount of fuss and bother, yet the necessary due diligence may take 
a while to accomplish (checking TRW databases, sending out certified 
mail acknowledgments, etc.). The certificate can be issued to the user, 
but not published in any kind of directory or repository until the due 
diligence has been completed. However, if the user sends the 
certificate off to some other person, rather than relying on the 
repository to publish it, the relying party could be potentially be misled 
as to the certificate's status. If he checks the CRL, however, this 
possibility would be avoided.

(Of course, if the certificate doesn't contain anyone's name or identity,
or is otherwise issued willy-nilly, then there may not be any due diligence 
requirement, so you can just blast them out without confirmation or 
acknowledgment of receipt.)

ON THE OTHER HAND:

As long as you are departing substantially form the X.509
certificate format, you should perhaps consider departing from the
CRL paradigm entirely, and moving to an on-line, positive acknowledgment
of the validity of a signature/certificate.

The CRL paradigm was modeled after the now abandoned credit 
card hot list that was the norm perhaps 10 years ago, when universal 
connectivity to the Internet was not the norm. Perhaps it is time to reexamine 
that premise.

The CRL paradigm is really awkward from the standpoint of non-
repudiation, because it requires a trusted timestamp be applied to both the 
signature of the document (generally not available, except by means of
a trusted third party, and to the CRL (the next one AFTER the document was
signed, and to the certificate itself. Coordinating all of these clocks in a reliable
manner, and having trusted third parties sign statements that they have in fact
checked the status of the certificates with the CA, etc, etc, is extremely 
cumbersome.

Since the CA is the only essentially the only trusted entity which can speak 
authoritatively about the status of a certificate at a particular moment in time, 
it makes a lot more sense for any relying party that wants to establish 
nonrepudiation to send the digital signature portion of a document to the 
CA which allegedly signed the user's certificate, and have that CA say
once and for all time whether the certificate was valid as of the moment the 
document was received. Of course it is still necessary to confirm the 
validity of the CA itself, but this can be done recursively.

The only real problem with this approach is that it cannot be done 
in disconnected mode, i.e., if you want to validate a document while you
are flying at 30,000 feet and don't want to pay for the AirPhone time to
access your network.

The other real virtue of this approach is that it lets the CA know whenever 
a transaction has occurred that someone thinks is important enough to 
validate. From the standpoint of controlling the CA's aggregate liability, this
is exceedingly important.

The ideal solution to the overall problem would be some scheme that would 
distribute base-level CRLs on a CD-ROM-of-the-month, plus delta CRLS 
that could be downloaded according to the relying party's perceived 
risk, plus an on-line positive validation scheme for near real-time, high-value
transactions.

Bob


Robert R. Jueneman
Software Engineering Consultant
NetWare Security R&D
Internet Infrastructure Division
Novell, Inc. M/S-PRV-D241
122 East 1700 South
Provo, UT 84606
801/861-7387