Subject: RE: RFC 2560 - OCSP - Clarification

From: Michael Myers <[email-masked]>
Date: Wed, 30 Aug 2000 13:54:19 -0700

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

2560bis will clarify this intent.

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: "Karl Scheibelhofer" <[email-masked]>
Date: Thu, 31 Aug 2000 10:24:10 +0200

Michael,

> of a digital certificate without requiring CRLs."

the current status of a certificate is very often not so important. when i
verify a signature that was created using a specific certificate, i want to
know, if the certificate was vaild, when the signature was created. to
detemine the time the signature was created, one would ideally use
timestamps. using timestamps, it is possible to determine the signature
creation time to be in an intervall [t1,t2]. here t1 and t2 are the times of
two timestamp (taking time base errors into consideration).
what i would like to see in OCSP is a request with the following meaning:
"what was the state of certificate XYZ in the time interval [t1,t2]?"

the answers could be:
1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...)
throughout the time intervall [t1,t2]
3) certificate XYZ changed its state from state A (e.g. valid) to state B
(e.g. suspended) at tx, where t1 <= tx <= t2

if i get the first answer with 'valid', i can definitely say: "the signature
it was used for is valid".
moreover, this request-response supports any history model for certificate.
by now OCSP assumes that a certificate can never become valid again once it
became invalid.
of course, implementing this based on CRLs will be hard, but if the server
has access to the history of the certificates, it should not be a big deal.

what do you and others think of this requirement for future OCSP

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[email-masked]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540