Subject: RE: RFC 2560 - OCSP - Clarification

From: Khaja Ahmed <[email-masked]>
Date: Sun, 3 Sep 2000 14:43:29 -0400

It sound to me like the debate is really about good choice of words to
describe something.  Looks like everyone (or most) know exactly what "good"
means in rfc.2560.  After all, it is explained there quite clearly.  The
question then is: Why should "good" or any other word describing a state of
anything "imply" anything?  The precise meaning should be, and in this case
is, described in the standard.  From time to time common English words may
be used to describe precise and narrow technical matter.  As long as the
precise meaning in the context is described in the spec one does not need to
fall back on English dictionaries.  I would argue that "not revoked" isn't
any clearer.  "Not revoked and may not have been issued" is getting close
but is too verbose.  Ultimately there needs to be a handle and some text
explaining what is meant by the handle.  I am not sure it is important to
worry excessively about the choice of handle.

Secondly, a case can be made, that "good" in the context is actually the
right term.  An OCSP query is, after all, not a substitute for basic path
validation.  Someone, somewhere - the relying party or a trusted agent or a
server or X is meant to have done quite a lot of work before checking the
revocation status of a certificate.  OCSP was not meant to do remote path
processing as far as I know.  The relying party is expected to have at least
done the following two things in addition to whatever application specific
checking is required:

1.) Verify the signature.
2.) Do RFC.2459 section 6.1 compliant basic path validation

After these two steps the relying party is checking to see if the
certificate has been revoked.  The certificate in question is a certificate
(chain) which the relying party is in physical possession of and has
cryptographically verified.  

What then is the value of being told at this point that the certificate is
no only not revoked but has been issued?  Unless the CA private key has been
compromised or RSA has been broken this additionally info is of no value.
If one of these two thing have happened, then whatever the riches of the
OCSP "good" semantics - they are of little value.  In this context, as far
as I can see, "good" is good.

...or have I misunderstood the whole thing and neglected to consider some
factors?

Khaja

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

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

----- Original Message -----
From: Denis Pinkas <[email-masked]>
To: Michael Myers <[email-masked]>
Cc: Liaquat Khan <[email-masked]>; <[email-masked]>
Sent: Saturday, September 02, 2000 5:34 PM
Subject: Re: RFC 2560 - OCSP - Clarification

> 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: Thu, 14 Sep 2000 20:03:14 +0100

RE: RFC 2560 - OCSP - ClarificationHi Khaja,

Sorry for responding so late to this. But, as per our discussion today, this is not a major issue to me.  I agree that the RFC is quite clear, and if all the processing is done beforehand, then 'good' should really mean good.

I was just worried that the messages end-user are provided with by their software application should be as clear or precise as possible.  They should not have to hunt for definitions in standards.  I realise that this is quite hard to achieve in practice and this may not be the most appropriate place to discuss such issues anyway. 

I also accept that legal implications may not really be tied to the words being used. 

Regards,
Liaquat
  ----- Original Message ----- 
  From: Khaja Ahmed 
  To: 'Liaquat Khan' ; Denis Pinkas ; Michael Myers 
  Cc: [email-masked] 
  Sent: Sunday, September 03, 2000 7:43 PM
  Subject: RE: RFC 2560 - OCSP - Clarification

  It sound to me like the debate is really about good choice of words to describe something.  Looks like everyone (or most) know exactly what "good" means in rfc.2560.  After all, it is explained there quite clearly.  The question then is: Why should "good" or any other word describing a state of anything "imply" anything?  The precise meaning should be, and in this case is, described in the standard.  From time to time common English words may be used to describe precise and narrow technical matter.  As long as the precise meaning in the context is described in the spec one does not need to fall back on English dictionaries.  I would argue that "not revoked" isn't any clearer.  "Not revoked and may not have been issued" is getting close but is too verbose.  Ultimately there needs to be a handle and some text explaining what is meant by the handle.  I am not sure it is important to worry excessively about the choice of handle.

  Secondly, a case can be made, that "good" in the context is actually the right term.  An OCSP query is, after all, not a substitute for basic path validation.  Someone, somewhere - the relying party or a trusted agent or a server or X is meant to have done quite a lot of work before checking the revocation status of a certificate.  OCSP was not meant to do remote path processing as far as I know.  The relying party is expected to have at least done the following two things in addition to whatever application specific checking is required:

  After these two steps the relying party is checking to see if the certificate has been revoked.  The certificate in question is a certificate (chain) which the relying party is in physical possession of and has cryptographically verified.  

  What then is the value of being told at this point that the certificate is no only not revoked but has been issued?  Unless the CA private key has been compromised or RSA has been broken this additionally info is of no value.  If one of these two thing have happened, then whatever the riches of the OCSP "good" semantics - they are of little value.  In this context, as far as I can see, "good" is good.

  ...or have I misunderstood the whole thing and neglected to consider some factors? 

  Khaja 

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

  Regards, 
  Liaquat Khan 

  ----- Original Message ----- 
  From: Denis Pinkas <[email-masked]> 
  To: Michael Myers <[email-masked]> 
  Cc: Liaquat Khan <[email-masked]>; <[email-masked]> 
  Sent: Saturday, September 02, 2000 5:34 PM 
  Subject: Re: RFC 2560 - OCSP - Clarification 

  will 
  status 
  . . 
  and 
  CRLs.