Subject: OCSP and CSL

From: Massimiliano Pala <[email-masked]>
Date: Mon, 24 Jan 2000 18:51:03 +0100

Hi all,

(first of all I apologize for my english(?), now let's go on ... )

working about an OCSP server to be included in the OpenCA package
I found very strange the lack of some kind of CSL (Certificate
Suspension List). If there is something similar I'm not aware of,
please report it and ignore this mail ...

For CSL I mean a sort of CRL (same structures, formats), but carrying
a list of only suspended certificates: this is obviously useful for
ocsp implementations and considering the fact that in most env you'll
not be requested for certificate status changing very often, issuing
this kind of lists, I think, could be useful.

First of all the software can, with very few modification, support
this kind of lists because them are built exactly like CRLs (but
them carry informations only on suspension: this can occour for
example when a certificate is requested for revokation but the request
have not been processed by the CA (think about network disconnected
CAs)). These lists can be signed by, let's say, the OCSP server
(certificate assigned to the OCSP authority or another certificate
issued for this porpouse and placed on a network-connected station) and
issued whenever a new certificate is suspended or its state is
changed to revoke/valid . When this last option happens the certificate
simply do not appear on the suspension list.

The correct status of a certificate, then, can be given by the
couple CSL/CRL without having to support OCSP or other protocols and
moreover the CSL are the same as CRLs so you don't have to rewrite
most of the software ... think about Apache (that now correctly
checks CRLs) ... 

Is there anything like this around ??? Do you think this could be
useful or not ??? In case you approve I can take in charge of writing
an initial rfc for publication if needed to ...

Please report ANY comments :-D

C'you,

	Massimiliano Pala ([email-masked])

---

From: Russ Housley <[email-masked]>
Date: Tue, 25 Jan 2000 17:09:35 -0500

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jan 2000 16:46:25 -0500

Massimiliano,

Would not a CRL DP that holds only suspended certs achieve the effect 
you attribute to a CSL?

Steve

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 26 Jan 2000 01:40:16 +0100

> Would not a CRL DP that holds only suspended certs achieve the effect

Yes, I think this is what we definetly need. What I was wondering is if available
software can disitinguish CSLs from CRLs ... As far as I know, actually Netscape
does not support CRLs with extentions. Am I wrong ???

Do you know of some software supporting extentions in CRLs (widely available) ???

To issue a CRL, you'd need the CA certificate/key, but in environment where you
have (for security reasons) a network-less CA how to accomplish this ??? Can you
sign CRLs with a certificate that is not the CA Cert ???

I was also thinking about the OCSP service: if I can remember well the possible states
for a given certificate can be Good/Revoked or Unknown only, right ??? What about,
if there is not yet, adding a 'Suspended' state ???

Thank you for the reply,

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 26 Jan 2000 01:38:46 +0100

> system, and we should discourage it's use.

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,

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Jan 2000 17:27:39 +0000

> sign CRLs with a certificate that is not the CA Cert ???

Since a suspended certificate is as unusable as a revoked one, it makes
no sense to me to permit _any_ differences between the creation of a
suspension and the creation of a revocation. Which means that there's
little point in supporting suspension at all.

Cheers,

Ben.

--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm

http://www.apache-ssl.org/ben.html

Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt

---

From: Brian Ford <[email-masked]>
Date: Wed, 26 Jan 2000 13:15:12 -0500

Massimiliano,

I'm no expert but my read of the RFCs is a little different.

The CSL which you describe seems to me like a subset of a CRL.  If you made
a query at a CA for that info I'd guess that the current CRL at the CA
would be parsed to deliver your answer.  The response would be in the form
of a list.  So depending on the CRL lifetime, that info may (or may not) be
current.

Using OCSP on the other hand the request would be made to a CA regarding a
specific cert.  The CA would be queried directly for a response (so the
info would be current).  The response would be either good, revoked or unknown.

Comments?

Regards,

Brian

>	Massimiliano Pala ([email-masked])

Brian Ford  
Consulting Engineer, CCIE #2106  
Cisco Systems Inc.

---

From: Brian Ford <[email-masked]>
Date: Wed, 26 Jan 2000 13:19:37 -0500

Ben,

It comes down to your interpretation of suspend versus revoke.  If the
network between a client and the CA goes bad and you cannot reach a CA for
a period of time an argument could be made to "suspend" certs from that CA.
 If the user leaves the employ of a company one would hope that their cert
would be "revoked".  No?

Regards,

Brian

Brian Ford

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Jan 2000 21:56:28 +0000

>  If the user leaves the employ of a company one would hope that their cert

If you are talking about suspending _all_ certs from a CA, that's an
entirely different matter. What I (and everyone else, AFAICS) was
talking about was an ability to suspend individual certs.

Cheers,

Ben.

Y19100 no-prize winner!

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Jan 2000 13:36:24 -0500

Massimiliano,

>does not support CRLs with extentions. Am I wrong ???

I think the most recent release of Navigatior does know how to 
process CRLs, but probably not fancy CRLs with extensions.

>Do you know of some software supporting extentions in CRLs (widely 

Check on the Jonah software from IBM, or the NIST or Van Dyke toolkits.

>sign CRLs with a certificate that is not the CA Cert ???

You can sign a CRL with an offline CA key, and transfer the signed 
CRL to a directory or other repository.  Also, you can have the CA 
have two certs, with two different keys, one for signing certs and 
one for signing CRLs.

>if there is not yet, adding a 'Suspended' state ???

I don't recall what OCSP says re suspended certs as a form of revoked cert.

Finally, I have to agree with Russ. I am not fond of suspension as a 
revocation declaration and since 2459 disparages use of this 
facility, I don't think we should spend lots of time on this issue.

Steve

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 27 Jan 2000 12:01:13 +0100

> little point in supporting suspension at all.

But the point is: the certificate is not yet revokable but its state it's
been reported to be 'probably compromised'. It would be useful to get the
server(s) not allowing critical data transmission using such keys...

(refer to a model where the ca machine is disconnected for security
porpouses).

C'you,

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 27 Jan 2000 12:11:00 +0100

> info would be current).  The response would be either good, revoked or unknown.

Sorry, probably I left out the main point. It is true that this can be done with
a subset of CRLs but if you refer to the network-disconnected CA model, the revokation
gets with some delay from the moment the user submits a 'request for revoking'.
The point is: can I sign a CRL using not the CA certificate ??? Will this be trusted
by today applications ?? Also consider this:

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.

Another question I have for the list: it is allowed signing a CRL with a revokation
date prior to the time of the effective revoking ??? Let's say I have a request for
revoking, can I use the time of the receiving of the request instead of the time
when the CA Operatorphisically does the revokation ???

C'you,

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Jan 2000 09:56:33 -0500

A particular client can always refuse to accept certificates from a 
particular CA.  I would assume that a CA that does not have a certificate 
path back to a trust anchor is one such example.  Other rules could also 
cause a client to reject certificates from a CA.  These rules have nothing 
whatsoever to do with suspended certificates or revoked certificates.

In general, the CA that issues a certificate is responsible for suspending 
it or revoking it.  The CA can delegate this responsibility with the CRL 
Distribution Point extension, but generally the CA retains this responsibility.

Russ

---

From: "Juan Rodriguez-Torrent" <[email-masked]>
Date: Sun, 30 Jan 2000 17:10:40 -0500

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
[email-masked]

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