Subject: More on OCSP and CSL

From: Massimiliano Pala <[email-masked]>
Date: Fri, 28 Jan 2000 01:34:44 +0100

Jan Meijer wrote:

> I still have some doubts however regarding the feasibility of implementing
> this thing.  It seems to me you open your CA to a nice little DoS attack if
> you do not carefully authorize the certificate suspension.  How to take care
> of the certificate suspension (signature of course, problem solved).

You are right when you say a DoS attack is possible, but the problem, to me,
it is internal to every organization. Let me explain. How CSL is generated
(got from the 24/h phone service, passwd authenticate service... ) this is
something you should solve within the organization and the software you are
using, it is not a matter of standards...

Some time ago we have talked about this problems, one solution would have been
sending an encrypted mail when the certificate is issued with a 'suspension/
revokation' code/passwd (indeed the true path is more complex, anyway lets cut
off details), but this is only ONE solution... :-D

> Second possible problem, how to trust the CSL.  I can trust the CSL because
> it has been signed by the CA on the offline certification server (sorry, had
> to use the term ;).  I cannot ever trust the CSL because it cannot have been
> generated on the offline certification server (because of arguments given
> before).  I don't see a solution to this.

The CSL could be signed by a certificate allowed to sign CSLs. This could be the
same OCSP server: when a certificate is to be moved from one state to another a
new CSL is issued and signed. This could be useful in OCSP implementations as the
OCSP responder can keep informations in the couple CSL/CRL. When a certificate is
found to be suspended, as suggested by many people, a response of 'revoke' can be
given by the OCSP responder with reason extention set to certificateHold...
 
> Third possible problem, how do you recognize the true owner of a certificate
> if he wants to turn his status back to "OK".  Someone explicitly (and
> probably with client authentication or something similar) stated his
> certificate has possibly been compromised.  You will need a good mechanism
> to make sure that the certificate owner is telling the truth when stating
> his certificate has not been compromised.  This might be more of a
> procedural thing, still is important to think about.  Once a certificate has
> been marked as possibly compromised, how to trust it again?
> 
> Jan

Turning his certificate back to OK could be a feature, supported or not by the
organization, requiring more than one pass to be accomplished or not. I think
this is a procedural matter within the organization...

Many (and different) aknoledgemnt methods can be used ( phone, e-mail, fax,
meeting in person) can be adopted to check the ID to be the authorized one.

C'you,

	Massimiliano Pala ([email-masked])

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 Jan 2000 15:50:38 -0500

Massimiliano,

I think we've established that, syntactically, we can represent the 
CSL concept using a CRL, with appropriate reason codes.  Thus there 
is no motivation to create another syntactic construct.  A CA can 
choose to issues a CDP just for suspended certs if appropriate.

One might choose to propose a new work item, a protocol for 
suspension and reinstantiation of certificates, based on the 
motivations that you are describing here.  Personally, I don't find 
them compelling in most instances. For example, the user who leaves 
his smart card at work before going on vacation.  However, some in 
the financial community have suggested such scenarios to justify the 
existence of suspension in the first place, so I know that you are 
not alone in thinking this way!

Steve