Subject: RE: OCSP and CSL

From: Philip Hallam-Baker <[email-masked]>
Date: Thu, 27 Jan 2000 07:57:10 -0800

>I cannot find my smartcard... I suppose I left it at my friend's house,
but I am not
>sure... So I ask for a suspesion of the service. Then I go to my
friend's house and
>I find my smartcard... so the certificate have never been in danger, I
can ask the
>CA Org not to revoke it and from the suspended state it returns to the
Valid state.

That is a requirement. Just because there is a technology that is
intended to meet a
requirement is no guarantee that it is a good idea to use that
technology.

Revoking certificates and reissue sounds like an excellent solution to
this problem.
The encryption key can be rolled over in the re-issued card, miniting
new signing
keys is never a problem.

I don't think that the change of the cert status back to valid has much
hope of 
being acurately and reliably tracked. Re-certificatrion is a slam dunk.

If there is a trully dynamic data source (such as when there is
authorization info
embedded in or associated with the cert) then a dynamic data protocol
such as OCSP
is appropriate. Trying to make static data structures such as CRLs and
Certs provide
a dynaic data service is like trying to speed up a tortoise by strapping
on an outboard 
motor.

		Phill

---

From: Antonio Lioy <[email-masked]>
Date: Thu, 27 Jan 2000 18:32:29 +0100

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: Fri, 28 Jan 2000 02:01:11 +0100

Hi Antonio Lioy,

> cannot be easily substituted with CRL or OCSP.

I had different comments on this, some share our opininon, others
have expressed perplexity in defining a new acronymous and/or
definition... :-(

[...]
> - a status code returned by an OCSP server to tell that a

Most of the people reported that the OCSP can be used in conjunction
with extentions to state the certificateHold revokation reason (this
is the widely suggested option we actually have for the OCSP
responder ... ). The same (by absurd) could apply to CRLs: CRLs can
be replaced by an OCSP responder, isn't it ??? But would you abandon
the CRL mechanism??? No ??? Why ??? Probably what you would respond
to this question is very similar to what I would about CSL ...

> which closely resembles the format (but not the meaning) of

Here I do have to point out this: I think it is not required
to keep track of the suspension time of a certificate if it
has not been revoked, if you have doubt about possible misusages
of it, then it should be revoked, otherwise it has never been
in 'danger' and it should be trusted so we don't have to keep
track for suspension time.

To clarify:

	o CSL should keep track of suspension periods for
	  (afterwards) revoked certificates;

	o CSL should not keep track of suspension periods
	  for not (afterwards) revoked certificates;

This should be adopted not to have CSLs too long and carring
not useful data (why keeping track of supension periods if
you, moving again to the valid state the certificate, say it
was never in danger and you trust it.... ).

This is only my vision on CSL :-D More comments on this ???

C'you,

	Massimiliano Pala ([email-masked])

---

From: Brian Tvedt <[email-masked]>
Date: Fri, 28 Jan 2000 11:50:41 -0500

> cannot be easily substituted with CRL or OCSP.
...
> have the burden of revoking and reissuing certs.

If I was that concerned about misuse of my private key, I would password protect
it.  This seems much superior to relying on a complicated mechanism (CSL) being
correctly implemented in every security application out there.

--
Brian Tvedt
Phaos Technology Corp.

---

From: Antonio Lioy <[email-masked]>
Date: Fri, 28 Jan 2000 18:47:55 +0100

> correctly implemented in every security application out there.

My private key IS password-protected, and nonetheless I
could fear its misuse should I forget it around. This fear
is even greater in Public Administrations with automatic
signature servers. Since the law explicitly states that such
servers sign on behalf of a real person, this guy has a real
fear to be held responsible for signatures emitted during
non-working hours. And as these servers typically use a
crypto board, it is not that easy to disable it (could be
used for SSL support too).

Revoking and issuing new certs is a real trouble, especially
when a smart-card (Or crypto board) with one-time on-board
private-key generation is involved.

Perhaps I have the wrong understanding of the Hold code in a
RFC-2459 conformant CRL. I could not find a clear definition
of how is a certificate "temporarily suspended" and yet
placed in a CRL. In my understanding, a CRL is a
monotonically non-decreasing list of revoked certificates.
There is no way to state that a cert is valid again. Issuing
another cert for the same key is simply not possible in
certain environments.
Either a CRL is augmented in meaning to be a list of invalid
certs within specific timeframes (i.e. invalidity start -
invalidity end, the latter being infinite for truly revoked
certs), or a separate concept has to be created: CSL.

OCSP can then be the vehicle to convey punctual information
about a cert status, but given teh current legislation in
several countries, CRLs (and may be CSLs) have to be
produced and archived for legal use.

Antonio Lioy

---

From: Antonio Lioy <[email-masked]>
Date: Fri, 28 Jan 2000 19:01:15 +0100

Massimiliano Pala wrote:
> 
> Hi Antonio Lioy,
> 
> good in reading you again.

Hi Max :-)

>           for not (afterwards) revoked certificates;

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

Antonio Lioy

---

From: Brian Tvedt <[email-masked]>
Date: Fri, 28 Jan 2000 19:28:53 -0500

> used for SSL support too).

If you're that worried that one of your coworkers may have stolen your password
and is going to sneak into your office when you're gone and use your smartcard,
I don't think CSL's are going to help you much.  Won't you have to suspend your
certificate every time you go to the bathroom?

> produced and archived for legal use.

I don't know if there's anything in PKIX which says that if the set of revoked
certificates in a CRL must be a superset of every previously-issued (lower
serial number) CRL from the same CA.  In other words, it's legal (I think) for a
certificate listed on a CRL to "disappear" on the next update.  Then there's the
mysterious business of the certificateHold reason code, which is presumably
intended for this sort of thing.

In sum, I'm not sold that suspension of certificates is really necessary, but if
you're convinced that it is, it seems to me it could be done with CRLs as
currently defined.

--
Brian Tvedt
Phaos Technology Corp.