Re: OCSP and CSL

["Juan Rodriguez-Torrent" <torrent@xxxxxxx>]

Massimiliano, the issue of suspension was discussed several times during the
last few years and the bottom line is that nobody was able to show a
reasonable business case for it. In other words, there is not enough
interest in suspension mechanisms to generate income or help sales of a
specific PKI because of that feature. I'm sure the additional complexity
that Russ brings to our attention would be less of a deterrent if someone
was willing to make suspension mechanisms attractive to the vendors. Let's
not forget the ISVs (Independent Software Vendors) that have to add yet
another level of complexity to their products to enable suspension and they
also have to be convinced. Also, let's not forget the additional complexity
to be stated on the policies with the corresponding legal issues arising
from that added feature.  I could go on for a while on that subject but I
think you got my point.

Let me add that the reason you stated for having a certificate suspension
list is trivial and raises fundamental questions:

1. If the CA is offline WHO WOULD create the suspension list?

2. Since without a trusted authority a suspension list will be worthless,
why bother? It appears that the only reason for having a suspension list is
because the CA is offline and want to avoid bringing the CA online to issue
a CRL but the suspension lists needs to be issued by the CA ... (?)

3. Also why do you think that offline CAs are any different than CAs that
only issue CRLs at fixed time intervals (i.e. every 8 hours, every hour or
every minute). There will always be a time gap between CRL instances,
independently if the CA is online or not, and that's were policies -of
relaying parties, CAs, etc.- have a role.

If your environment needs a high level of responsiveness, a more reasonable
approach is to solve the problems you did not state (e.g. why the CA has to
be offline?) and bring your CA on-line using mechanisms and protocols
appropriate for the application. Trying to develop new protocols to solve an
apparently trivial environment/operations issue adds, as stated above,
complexity and also interoperability issues to an already complex and less
that interoperable environment.


Juan Rodriguez-Torrent
torrent@acm.org

"It is better to sleep on things beforehand than lie awake about them
afterwards." Baltasar Gracian



----- Original Message -----
From: Massimiliano Pala <madwolf@comune.modena.it>
To: Russ Housley <housley@spyrus.com>
Sent: Tuesday, January 25, 2000 7:38 PM
Subject: Re: OCSP and CSL


> Russ Housley wrote:
> >
> > Massimiliano:
> >
> > I do not think that we should do anything to encourage CAs to suspend
> > certificates.  This feature adds significant complexity to the whole
> > system, and we should discourage it's use.
> >
> > Russ
> >
>
> You are right saying that adding complexity should be discouraged, by the
> way I suggested them because we need something like that (I am from the
> OpenCA project). Let me explain in more details why I think something
> similar could come in handy.
>
> The CSLs, let's call them CSL to distinguish from CRLs, have sense in env
> where there is a time gap between the 'request for cert revoking' by the
> user and the effective revoking by the CA: this is obvious if you consider
> structures where the main CA computer is disconnected from any network.
>
> Would you allow a certificate to be used when a user says it could have
> been compromised ? You can not either say it is revoked because it is not
> (CRLs do not report it) and there is no way to verify it till the new
> CRL is issued.
>
> With some instrument like the proposed CSLs (that is only a proposal, I am
> not saying it is the best or the only solution to the problem, I am
obviously
> open to EVERY comment... :-D and hopefully to some better solutions) you
can
> say, from the moment the user signals a danger the usage of the
certificate
> is compromised and that itself is to be considered in a 'freezed' state.
>
> Am I completely out of the target ? What do you think about this problem ?
> Thanks for the comments you sent.
>
> C'you,
>
> Massimiliano Pala (madwolf@openca.org)