Subject: Re: OCSP and CSL

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

In this case I interpret your "suspend" as the relying party will stop
accepting certs until the he/she can verify the certs for that specific CA.
This is far from Massimo's inquiry.
----- Original Message -----
From: Brian Ford <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: Massimiliano Pala <[email-masked]>; Stephen Kent
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 26, 2000 1:19 PM
Subject: Re: OCSP and CSL

> 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
>
> At 05:27 PM 01/26/00, Ben Laurie wrote:
> >Massimiliano Pala wrote:
> >>
> >> Stephen Kent wrote:
> >> >
> >> > Massimiliano,
> >> >
> >> > Would not a CRL DP that holds only suspended certs achieve the effect
> >> > you attribute to a CSL?
> >> >
> >> > Steve
> >>
> >> 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 ???
> >
> >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
> >
>
>
> Brian Ford
> Consulting Engineer, CCIE #2106
> Cisco Systems Inc.
>
>

---

From: Philip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2000 08:55:03 -0800

>Russ, I cannot agree more. I'm just trying to figure out if these are
real
>customer requirements or some folks in a glass house tinkering with
>possibilities.

Juan,

	Now that we have real customers doing real business with PKI it
may 
be time to start improving PKIX by throwing out features that are in 
widespread disuse and pare down the schemas to a manageable size. 

	We can anticipate equal success for our researches into porcine 
aviation.

		Phill

---

From: Simon Tardell <[email-masked]>
Date: Wed, 2 Feb 2000 19:07:56 +0100

I do tend to agree to some of what Antonio is saying here:

There is a need for a historical account of the status of certificates. The
simplest way of doing this would be to allow multiple CRL entries for a
single certificate in a CRL (e.g. onHold, removeFromCrl, onHold,
keyCompromise) and indicating this extended type of CRL by some extension
(so that the consumer of the CRL understands this special use). This has to
be accompanied by an OCSP request extension that asks the responder to
evaluate the query at some certain historical point in time.

If a CA wants to do allow suspension and unsuspension is purely a policy
issue. If he does, he likely wants to keep track of this status and be able
to communicate this between relying parties in some standard way.

> 1. "revoked" means revoked, i.e. the cert is no more valid
> for any use starting from a certain date

As other people have pointed out 'onHold' (suspension) is really a type of
revocation. Whether this makes sense semantically may be a cultural thing.
For instance, in Swedish the word for revocation ("spärr") indicates that
the certificate is 'barred against use' -- which is true both for a
temporary and permanent revocation. Anyway, I don't think we can change the
words anymore (sorry).

Simon.

Simon Tardell		voice +46 8 7755225, fax +46 8 191499
iD2 Technologies		[email-masked], [email-masked]
Grand Winner of the European IT-prize 1998 http://www.it-prize.org/

---

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

Juan Rodriguez-Torrent wrote:
> 
> 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.

I know, adding complexity is never a feature... at least when that complexity is
not needed. My thinking about it are very clear... we need something to provide
such service ...

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

The OCSP server could do that as it is a trusted suorce of information and it
have to keep track of the 'validity' of the certificates. So you can retrieve
the certificate status by getting the OCSP response about it, or just get the
CSL/CRL pair in this case you'll know exaclty wich certificates are suspended
and/or revoked).

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

You NEVER bring your CA on-line... the CSL indeed is not issued by the CA itself
as it is needed to provide a new CSL when a user asks for its suspension...
he CSL issuing should be tied to an on-line authority (as described at point
1).
 
> 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.

CSLs are not CRLs... when the user asks for a suspension the status gets to
suspended in a metter of seconds (or less). This suspends the certificates
immediately and if the certificate will get revoked then track of this suspension
will be held and if some misusage of the certificate arise than you can prove
that should not be trusted as an authorized usage because it was suspended.

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

To me the only way of being sure about avoiding network attacks is to have the
CA disconnected from ANY network (being it internal to the organization only or not)
and this to provide an high security profile... This causes the problems related
to the suspension/revoking of certificates and time delays between the request
being received and the real revoking time of the certificate. If you are not
using this CA model than you do not suffer of such a problem (this is obvious).
As we do use this kind of structure we lack a way of providing this service...
:-D

C'you,

	Massimiliano Pala ([email-masked])

---

From: "Duncan Deborde" <[email-masked]>
Date: Thu, 3 Feb 2000 13:57:05 +0000

Jörg Seidel wrote

> I just realized: Maybe there is a small security flaw in this system: If a
> certificate gets revoked just before certificate expiration, but the next CRL
> is released after the expiration time, the revocation might not been stated in
> CRLs at all. The state of the signature is unknown.

RFC2459 states: "An entry may be removed from  the CRL after appearing on one
regularly scheduled CRL issued beyond the revoked certificate's validity
period."

Assuming this implies the entry must be present for the next CRL after the
expiration time, this situation you propose will not arise.

Duncan de Borde

---

From: Ambarish Malpani <[email-masked]>
Date: Sat, 5 Feb 2000 11:48:03 -0800

Hi Joerg,
    No, this isn't a security flaw - PKIX requires a revoked
cert to appear in at least 1 CRL before it is dropped of the
CRL list because of expiry - somebody already thought of
this one!

Regards,
Ambarish

> -----Original Message-----
> From: Joerg Seidel [mailto:[email-masked]]
> Sent: Thursday, February 03, 2000 5:12 AM
> To: Massimiliano Pala
> Cc: [email-masked]
> Massimiliano Pala schrieb:
> > 
> > Irene Gassko wrote:
> > >
> > > >2. once a cert is inserted into a CRL, it can *never* be
> > > >deleted from it
> > >
> > > This is not true. Expired certificates are deleted from CRL.
> > 
> > I am not sure about this. If you delete it from the list how you can
> > prove it is not valid from the revokation date on ??? The 
> CRLs should
> > provide an 'history' of all revoked certificates...
> 
> In order to prove the invalidity of a certain signature you 
> need the CRL of
> the point of time the signature was made. Well, more 
> precisely the CRL which
> was released next after the signature was made. If you want 
> to be able to
> prove the validity of a signature after the expiration date of the
> corresponding certificate you need to store this CRL together with the
> signature. Well and you need to prove the validity of the
> CRL-Signing-Certificate at that time, so you need ... and so 
> on until you are
> got a CRL signed with a private key corresponding to a non-expired and
> non-revoked certificate.
> 
> Jörg Seidel
> timeproof                               phone  +49-40-76629-1911
> Development                             fax    +49-40-76629-551
> Harburger Schloßstraße 6-12             mailto:[email-masked]
> D-21079 Hamburg                         http://www.timeproof.de
> 
>      + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +
>

---

From: Ambarish Malpani <[email-masked]>
Date: Sat, 5 Feb 2000 12:02:33 -0800

Hi Mirko,
    Most commercial software does not remove expired, revoked
certs from their CRLs, but there have already been requests
for that behavior. Expect to see it in CA products this year.

Regards,
Ambarish

> From: Mirko Tedaldi [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2000 6:36 AM
> To: Ilan Shacham
> Cc: [email-masked]
> Subject: RE: OCSP and CSL
> 
> 
> At 14.30 02/02/00 +0200, Ilan Shacham wrote:
> 
> >Section 3.3 of RFC 2459 clearly states:
> >         An entry may be removed from
> >    the CRL after appearing on one regularly scheduled CRL 
> issued beyond
> >    the revoked certificate's validity period.
> >
> >If you want to validate an "old" signature, all you have to do is
> >retrive the crl that was in order at the time of the signature, to
> >see if the certificate was valid at the time.
> 
> About it, do you know how commercial PKI softwares work? Do 
> they remove 
> expired certificates from CRL ?
> 
> Mirko Tedaldi.
>