Subject: OCSP authorized responder clarification.

From: Dr S N Henson <[email-masked]>
Date: Mon, 08 Jan 2001 12:33:55 +0000

In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if
it:

>    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
>    extension and is issued by the CA that issued the certificate in
>    question."

A certain CA issues end user certificates signed by an intermediate CA
which is in turn signed by the root CA. 

The responder certificate is signed by the root CA. Does this, as
appears to be the case, mean that the above condition does not apply
because the OCSP reponder certificate is not signed by the intermediate
CA?

Alternatively is the condition satisfied because they both have the same
root CA?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: Rich Salz <[email-masked]>
Date: Mon, 08 Jan 2001 13:36:43 -0500

> which is in turn signed by the root CA.

So do you mean this
          Root->Certain CA->End-Entity
              \->Responder->

Now a client has an EE cert and wants to know if Responder is authorized?

Then you are right, there is nothing inherent in the PKI.  A client would have
to treat it as case two, at the top of page 2 of RFC 2560 -- a trusted
responder whose key it trusts (because it has out of band information.)

I can think of two ways to strengthen the trust decision for a client. First,
the "Certain CA" could include an AIA in the end-entity certs that points to
where the Responder is listening. Second, the Certain CA could on its own
cross-certify the Responder and distribute the cert that *IT* signed. The root
might also issue the Responder cert using the same DN as it did for the
Certain CA.
(Just as some vendors like(d) to sure DN's for signing and CRL-issuing.)

The first method only provides a hint, since no crypto rigor is involved, just
the foundation of sand that is DNS. The second could be seen as voiding your
hypothesis.

In my limited experience of OCSP deployment, the client trust issue is almost
always addressed by saying "trust this responder" analogous to the way the
client is told to "just trust this root."

	/r$