Subject: Re: More problems with OCSP

From: [email-masked] (Peter Gutmann)
Date: Sat, 7 Nov 1998 11:19:25 (NZDT)

[I've copied this part of the message back to PKIX because I think it's more a 
 general discussion of OCSP philosophy]
 
>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.
 
This only works if you know in advance which CA's you plan to serve.  The 
model I had for an OCSP responder is that they work like an SNMP element 
manager where your toaster contacts the element manager to ask "is this thing 
valid?".  The element manager then goes out and wanders all over the X.500 
directory space pulling out certs and CRL's and whatnot, checks their 
validity, and tells the toaster "yes" or "no".  This means that the responder 
will have to be able to process arbitrary certs from arbitrary CA's.  At the 
moment the CertID only works if either the OCSP responder is run by the CA (it 
knows which CertID's it has to work with) or is tied to a very small number of 
CA's whose CertID's it has hardcoded in.  Given a query with an arbitrary 
CertID, it's not possible for an OCSP responder to provide a useful response.
 
Peter.

---

From: "Ambarish Malpani (test)" <[email-masked]>
Date: Fri, 6 Nov 1998 17:50:45 -0800

Hi Peter,
    Actually, even if you wanted to act as a general OCSP responder,
you would still need to have a set of CAs that you trust - since
you would need to be able to verify their revocation data (or CRL),
to create the OCSP response (except if you assume you have a
trusted directory, whose entries you trust blindly).

Once you have the list of CAs you trust, you should have both their
names and their private keys. So you should be able to act
as a general responder as long as the CAs you trust are a
(improper) superset of the CAs your clients trust.

Ambarish

Subject: Re: More problems with OCSP
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Sat, 7 Nov 1998 03:19:25 -0800

[I've copied this part of the message back to PKIX because I think it's more
a
 general discussion of OCSP philosophy]

This only works if you know in advance which CA's you plan to serve.  The
model I had for an OCSP responder is that they work like an SNMP element
manager where your toaster contacts the element manager to ask "is this
thing
valid?".  The element manager then goes out and wanders all over the X.500
directory space pulling out certs and CRL's and whatnot, checks their
validity, and tells the toaster "yes" or "no".  This means that the
responder
will have to be able to process arbitrary certs from arbitrary CA's.  At the
moment the CertID only works if either the OCSP responder is run by the CA
(it
knows which CertID's it has to work with) or is tied to a very small number
of
CA's whose CertID's it has hardcoded in.  Given a query with an arbitrary
CertID, it's not possible for an OCSP responder to provide a useful
response.

Peter.