pem-dev
[Top] [All Lists]

Re: Certificate revocation

1993-09-17 13:14:00



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.

Isn't there a protocol defined in RFC 1424 (sections 3.3-3.6) for 
CRL request messages and responses? I thought that was the purpose 
behind an inquiry/response system. It would be foolish to have to 
wait for the next issue of a CRL, especially consdering that it may 
not be for another month.


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.

I would contend that it might be beneficial to have a socket-based 
service as well (similar to that used by the "archie" servers. Of 
course, this assumes that such a service (CRL retrieval, not 
necessarily verification of individual certificates) would be 
automated. You also have to deal with the issue of firewalls ...


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.

Timestamping is another issue to itself. We had discussed this 
within Bellcore, when considering how to retrieve CRLs from CAs. 
Even if one were to obtain a CRL from the actual PCA via e-mail, 
without the use of a timestamp, there is no way that PEM can prevent 
against replay. 

A group of people here at Bellcore have developed a digital 
timestamp protocol, which may serve this purpose rather well. 
Contact Peter Winkler (pw(_at_)bellcore(_dot_)com) for more details.


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?


    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.]

Again, I think this is addressed in RFC 1424, combined with the 
idea of timestamping.


    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.]

This brings up an interesting issue. I had always assumed that CAs 
would be doing some sort of lateral CRL/certificate distribution (We 
have a CRL responder service running here at Bellcore). Especially 
if PCAs will be charging on a per-retrieval basis (as I think they 
will - and as I would in the same situation), I think it is inevitable 
that CAs get into the business of distributing their own CRLs among 
each other. This way, CAs would only need to verify the PCA's CRL, 
and could obtain all other certificates and CRLs from other CAs.

        
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.

The issue of denial-of-service and multiple redundancy is, as you 
state, a HUGE one. I guess that's why everybody isn't getting into 
the PCA business! 

----------------------------------------------------------------------------
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)

<Prev in Thread] Current Thread [Next in Thread>