Subject: RE: Candidate for moving OCSP to a Draft Standard

From: [email-masked] (Peter Gutmann)
Date: Fri, 8 Feb 2002 20:23:18 +1300 (NZDT)

"Khaja E. Ahmed" <[email-masked]> writes:

>This sounds like a perfectly reasonable solution. Surprised it was rejected.
>After-all this would be an optional extension, why not add it?  

The reasoning as I recall was that OCSP shouldn't include facilities which
aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
response, and even that only for some cases of invalid certs, OCSP doesn't
include a straighforward yes/no indication.

(IMHO any poor guy who's stuck with feeding their online status service from
 offline CRLs has bigger things to worry about than this...).

Peter.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 08 Feb 2002 12:22:48 -0500

> include a straighforward yes/no indication.

Say what?  CRLs provide positive and negative responses, and the
positive
response is optimized down to 0 bytes.  If you want to know whether a
certificate was issued, the signature on the cert tells you that, and if
it doesn't you've got bigger problems than just revocation status.

The reason OCSP can't say that a cert is valid has nothing to do with
CRLs.
It's crippled by the fact that the request does not include a cert, so
the
responder can't validate the signature unless it fetches the cert
itself.
Presumably the OCSP authors made a conscious decision not to require the
responder to validate certification paths before providing a response.

>  offline CRLs has bigger things to worry about than this...).

Speaking as one such poor guy :-), what's the problem?   I have a user
community of 4.5 million people, and having each of them bang against
a central OCSP server every time they do something PKI-related on their
LAN is going to incur their wrath.  Server delays and Internet
congestion shouldn't be designed into local applications, causing
things that should have happened instantaneously to take 5 seconds,
or more when their pipe to the Internet is loaded.

I've learned to ignore Lynn Wheeler when he refers to CRLs as 
'60's-era blacklists (and I can remember when supermarket clerks thumbed
through those little books).  But I expect you'd have a little more
appreciation for simplicity.  What could be more elegant than having
your
LAN-based OCSP server replicate the PKI revocation database by fetching
delta CRLs from the central server every 15 minutes?

---

From: "Khaja E. Ahmed" <[email-masked]>
Date: Fri, 8 Feb 2002 15:30:42 -0800

I agree that there is no great need for an OCSP server to tell a PKI enabled
client that a certificate exists or was issued if the PKI enabled client has
first performed the required verification of the CAs signature on the cert
and done proper path validation and is now only checking the revocation
status.  My initial reaction was that it might not do any harm to have an
optional extension to satisfy some corner cases.  One such case, that was
put forth was of a situation where the CA's private key was stolen and being
used to mint certificates by an attacker.  Such certificates would not be in
the CA's database. An optional extension like the one proposed by Peter
could afford some limited protection against this.

That said, the CertificateOK optional extension seems to introduce
certificate validation services in a non standardized and potentially
incomplete fashion.  A TTP should probably either limit itself to doing
revocation status response only or provide a proper and complete
certificate/path validity checking service.  Which means that if people are
interested in certificate validation services that might be more in SCVP and
XKMS like services rather than in OCSP extensions. Peters extension in the
meantime, may be temporary/partial solution.

Khaja

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David P. Kemp
> Sent: Friday, February 08, 2002 9:23 AM
> To: [email-masked]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Peter Gutmann wrote:
> >