Subject: Re: RFC 2560 - OCSP - Clarification

From: Denis Pinkas <[email-masked]>
Date: Sat, 02 Sep 2000 18:34:37 +0200

Michael,

> Liaquat,
>
> Thanks for taking a careful look at 2560 regarding CRLs.  This thread will
> feed productively into 2560bis.
>
> But I do need to point out that OCSP does not, nor was ever intended, to
> require the use of CRLs.

As you said, OSCP does not require, but does allow the use of CRLs
as the primary information used by the OCSP server to respond.

> In fact, here are a few references from 2560 as
> currently written:
>
> Abstract
> "This document specifies a protocol useful in determining the current status
> of a digital certificate without requiring CRLs."
>             ^^^^^^^^^^^^^^^^^^^^^^
>
> 2.  Protocol Overview
> "OCSP may be used to satisfy some of the operational requirements of
> providing more timely revocation information than is possible with CRLs  . .
> . ."
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Now, that said, 2560 does recognize that CRLs are a useful input to OCSP and
> so we made certain to accomodate that data source in the event that
> periodically produced CRLs were the ONLY means by which an OCSP service
> could be offered.  We enabled the use of CRL extensions to accomodate
> environments where this feature was useful.
>
> But OCSP is and was primarly intended to address immediate timeliness, a
> feature that is inherently beyond the scope of periodically produced CRLs.
>

The problem is that the protocol does not take advantage of this
feature. So the notion of "immediate timeliness" does not reaaly
make sense, since anyway there is some delay in the overall process.
A "good" status does not guarantee in any way that the certificate
is presently "good", but only that it has not be declared to be
revoked at some previous *undefined* time which may be a few
minutes,
hours (or even days) from the current time.

So let me propose a "clarification" about the meaning of the "good"
status.

 The "good" state indicates a positive response to the status
 inquiry. At a minimum, this positive response indicates 
 that the certificate  has not be declared or requested 
 to be revoked at some point  of time prior the current time, 
 and does not necessarily mean  that the certificate was 
 ever issued by the CA or that the time  at which the 
 response was produced is within the certificate's validity
 interval.

I do know that this definition gives less than the previous one, but
it provides a better reality of the situation: no assurance that, at
the time of the response, the private key is not compromised or the
association between the key value and the content of the certificate
is still correct.

> 2560bis will clarify this intent.

I think it is important to maintain that the use of CRLs as the
primary information used by the OCSP server is one of the options to
provide the real
time information. So be *very* careful when making the
"clarification".

Denis

P.S. Since in your message from August 31, you said:

" Given the current work underway regarding 2560bis, I propose to
include in
the 2560bis work effort an optional "ValidAt" (or some such) field
in the
request syntax to accomodate this requirement."

I do not support your proposal and I fear you are planning to change
RFC 2560 by adding new functionality. So, here is my question: *In
addition* to 2560bis, when are you expecting to provide a draft for
OSCP extensions (i.e. OCSP-X) able to cover additional functionality
? 

> Mike
>
> > -----Original Message-----
> > From: Liaquat Khan [mailto:[email-masked]]
> > Sent: Wednesday, August 30, 2000 9:02 AM
> > To: [email-masked]
> > Subject: Re: RFC 2560 - OCSP - Clarification
> >
> >
> > The problem is linked to the fact that OCSP generally uses
> > CRLs as the base
> > information (although of course this doesn't have to be the
> > case). And CRLs
> > basically contain identifiers for those certificates that
> > have been revoked
> > (or suspended).  Therefore, if a particular certificates
> > serial number is
> > not on a CRL, it maybe because it is still valid or maybe
> > because it was
> > never issued in the first place.
> >
> > Note that the OCSP standard makes a reference that extensions
> > should be used
> > for providing additional information.
> >
> > Regards,
> > Liaquat Khan
> > Technical Manager
> > Global Trust Authority
> >
> >
> >
> > ----- Original Message -----
> > From: Mathew Butler <[email-masked]>
> > To: 'Rich Salz' <[email-masked]>; Sam Schaen
> > <[email-masked]>;
> > <[email-masked]>
> > Sent: Monday, August 28, 2000 9:13 PM
> > Subject: RE: RFC 2560 - OCSP - Clarification
> >
> >
> > > I think that there's a problem with this idea.  If the
> > responder doesn't
> > > know about the CA, or have the ability to verify the CA's
> > signature on the
> > > certificate versus the CRL, the response should be
> > "unknown" rather than
> > > "good".
> > >
> > > "Good" should indicate: "The certificate was apparently
> > issued by a CA
> > that
> > > the responder has current revocation information for, and
> > the certificate
> > > has not been revoked."
> > >
> > > Forgive me for not reading the draft as thoroughly as I
> > should have; is
> > > there any call for the responder to cryptographically check the
> > certificate
> > > at any point during the request?
> > >
> > > -Mat Butler
> > >
> > > -----Original Message-----
> > > From: Rich Salz [mailto:[email-masked]]
> > > Sent: Monday, August 28, 2000 8:08 AM
> > > To: Sam Schaen
> > > Cc: [email-masked]'
> > > Subject: Re: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > The text in uppercase is contradicted by the sentence that
> > immediately
> > > follows.  If good doesn't mean the certificate was issued,
> > then there
> > > need not be a CA that issued it. :)
> > >
> > >
> > > > 'The "good" state indicates that THE RESPONDER HAS
> > CURRENT REVOCATION
> > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND
> > the certificate
> > > has not
> > > > been revoked. It
> > > > does not indicate whether the certificate was ever
> > issued, is still
> > valid
> > > or
> > > > any other assertion.
> > >
> >

---

From: "Liaquat Khan" <[email-masked]>
Date: Sun, 3 Sep 2000 09:25:54 +0100

I tend to agree... a certificate status of "good" is a bit misleading, not
only from the viewpoint that the certificate may never been issued in the
first place, but also because it kind of implies that the certificate is
acceptable for a particular purpose.  It might be better to have a status of
"not-revoked", which simply means that the CA has not revoked the
certificate, for what ever reason  (i.e. either it never issued the
certificate in the first place or because the certificate is still valid).
From a legal point of view this may be better for the CA, than claiming the
certificate is good.

Regards,
Liaquat Khan

---

From: "Peter H. Gien" <[email-masked]>
Date: Sun, 7 Sep 1997 04:07:10 -0400

Liaquat,

RFC 2560 is a technical specification that uses common English words such as
"good" in a strictly defined manner. If you're suggesting that the use of
handles in computer code might have legal implications, then I'm afraid
we're headed down a very slippery slope. I can just imagine lawyers
examining some of my code and trying to attach meaning to my variable names?
This is a ridiculous situation. Every technical discipline has its strictly
defined, context dependent vocabulary that can become highly amusing or
disastrous if taken in a universal context. So let's stick with the choice
of words in RFC2560.

	"The enemy of Good is Better"

Peter H. Gien

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]]
Sent: Sunday, September 03, 2000 4:26 AM
To: Denis Pinkas; Michael Myers
Cc: [email-masked]
Subject: Re: RFC 2560 - OCSP - Clarification

Regards,
Liaquat Khan