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

Re: OCSP and CSL



So on Friday I "suspend" my cert ... how do I do that? signing with the cert
I want to suspend? calling a help desk ($$)? ... and then on Monday how do I
activate my cert? Another phone call ($$)? signing a request with the
suspended cert? Oh! I forgot the one time token! But who would trust that
"one time token" left on an insecure office next to the vacationing certs? I
claim it would have no trust associated... unless I carry it with me and
then why not carry the original cert that I'm trying to suspend and avoid
all the hassle? Maybe I should get an additional cert so I can suspend and
activate the one cert I want to leave in my office during the weekend? Does
any of this makes any business sense?

The smart card example is another example on how we are so desperately
trying to change business processes that actually work. Does anyone leave
their passport, driver license, credit card or checkbook in and untrusted
area for a weekend?

Have you considered the costs of involved in this "let's give our certs the
week-end off"? In a large office hiring certsitting personnel could be much
cheaper than all those convoluted motions I see proposed for trivial
reasons. No one in their right state of mind leaves the ATM card, credit
card or any financial relevant document seating in an insecure office over
the weekend for the pleasure of it.


WOW!

----- Original Message -----
From: Antonio Lioy <lioy@polito.it>
To: <ietf-pkix@imc.org>
Cc: 'Massimiliano Pala' <madwolf@comune.modena.it>
Sent: Thursday, January 27, 2000 12:32 PM
Subject: Re: OCSP and CSL


> I think that CSL is a real need in several cases and that it
> cannot be easily substituted with CRL or OCSP.
>
> First of all OCSP is out of question is it is not a trust
> source but rather a delivery channel for fast trust
> information. For non-repudiation service, it needs to be
> backed up by long-term data such as those of a CRL.
>
> CRL is not good either due to revokation costs, that are
> among the highest ones in the PKI world. So I would like to
> minimize the number of revokations, especially if followed
> by a re-issue of the same certificate with a different key
> pair (especially difficult to work with those remote friends
> that have stored remotely my cert to send me encrypted
> e-mail while off-line)
>
> Finally, I'd like to give my users the autonomous ability to
> suspend and then re-activate their certificates. Let's
> imagine the following scenario:
> - I don't want to take my smart-card with me and I leave it
> at the office (or I use a software PSE installed on my PC at
> work)
> - as I don't trust the company in charge of cleaning up the
> office (or may be my co-workers), I'd like to suspend the
> cert validity during week-ends, vacation, or even during
> night hours
> - I'd like to do this by just clicking on a button on a
> secure Web page (with client authentication) or sending a
> signed S/MIME message to an automatic responder
> - the responder (or the Web server) could in turn provide me
> with a one-time token to re-activate the cert at my will
>
> There are other similar scenarios (like I forgot where I put
> my smart-card, and later I find it) where I don't want to
> have the burden of revoking and reissuing certs.
>
> So I'd like to see this scenario supported by the following
> technical details:
> - a status code returned by an OCSP server to tell that a
> cert is SUSPENDED
> - a long term memory that a cert was suspended during a
> certain period of time; this should be provided by a CSL,
> which closely resembles the format (but not the meaning) of
> a CRL
>
> Opinions?
>
> Antonio Lioy