Subject: Re: OCSP and CSL

From: "Juan Rodriguez-Torrent" <[email-masked]>
Date: Tue, 1 Feb 2000 00:48:06 -0500

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 <[email-masked]>
To: <[email-masked]>
Cc: 'Massimiliano Pala' <[email-masked]>
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

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 03 Feb 2000 10:51:51 +0100

Antonio Lioy wrote:
 
> This is another view: the CSL is being used as a waiting
> list for possibly revoked certs. If it is later revoked,
> then you'll put it in the CRL, otherwise you'll remove it
> from the CSL.
> 
> But I disagree with this view: if I temporarily lost control
> of my smart-card, I can never know what has happened during
> that period of time.

Yes, but I think that if you are not sure about some misusage
of the private key, then you should request it to be revoked.

This is for two reasons: the first is about how long a CSL will
become if we keep track about every suspension of certificates
and the second is about your trusting in your key-pair.

If we keep every suspension tracked on the CSL, it can get a
very long list and it could suffer from problems related to
this aspect (distribution, definition of delta's CSL, and so
on... ). I'd like to avoid these problems as them tend to
get the CSL more complex than needed.

The second aspect is related on the fact that if you do not
trust your key for a certain period, than you should not trust
it at all because it could be open to every kind of attacks:
let's say someone discovers your password and uses it non only
when it is suspended, but he/her can get in touch with your key
during the working time when you are having a coffe-break...

If you are now trusting your key it is possible you think that
the 5 mins of a coffe break do not represent a real danger...

So my vision is: if you trust your certificate is because it has
never been in danger, if there is a possibility your certificate
(read key-pair) has been compromised (so it con be compromised
again...) either if you are not sure about it, than you should
revoke it...

So if we do not keep track on the CSLs about the suspension of
non-revoked certificates is because them are to be trusted.

> May be two years later someone claims money from me, based
> on a digital signature produced during that exact period of
> time. If you removed the entry from the CSL, you'll not be
> able to prove that it was not you that signed that document.
> 
> Do you agree?

I do understand your point of view, but how to solve problems
related to the CSL's length ?? And, moreover, how to be sure
your certificate is subject to attacks only in suspension times ??
Once a key/pair has been compromised (or possibily compromised)
it should not, to me, being trusted any more.

What do you think about this ???

C'you,

	Massimiliano Pala ([email-masked])

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 03 Feb 2000 11:44:13 +0100

> any of this makes any business sense?

The mechanisms of supension/revoking/re-validation are up to the organization:
some organizations could simply require a signed form to suspend the certificate
and/or using an additional code given to the user at the issuing time, others
could accept it on the phone... etc... I think this is something related to
organizations' policy.

On the certificate suspension/re-validation: if the user trusts again the
certificate (see my previous today mails) than he/she can ask for re-validation,
if this is not the case (he/she do not trust is) the revokation is requested.
I think it is up to the user (or you can simply decide to use the suspension
mechanism when someone asks for revokation to avoid time delays between
the request and the real revokation).

> their passport, driver license, credit card or checkbook in and untrusted

I usually don't. But what if you loose it ?? Or simply you can not remember
where it is ??? We should consider these cases either...
 
> the weekend for the pleasure of it.

You should trust the certificate-sitters ... and what if them sign contracts for
$millions??? You do not have any mechanism to state you were not using it (not
everyone uses smartcards, I think the majority of certificates are simply stored
on removable medias (floppy, CD, Zip, etc... ) as smartcards are not so widely
available... not everywhere at least).

C'you,