Subject: Clarification of ServiceLocator in RFC 2560

From: "Andrew Sciberras" <[email-masked]>
Date: Thu, 20 Sep 2001 14:24:48 +1000

Hi,

I have a query regarding the manner in which an OCSP Server should handle
the ServiceLocator extension as specified in RFC2560.
I would firstly like to point out section 3.2 of RFC 2560:
"    Prior to accepting a signed response as being valid, OCSP clients SHALL
confirm that:
        .......
        3. The identity of the signer matches the intended recipient of the
request.
        .....
 "

I would interpret #3 to basically mean that if you send a request to a
particular OCSP Server that it must be the ocsp server that signs the
response.

Image the scenario when an ocsp server forwards the request to the location
stated in the ServiceLocator field.
Upon the external OCSP server processing the request it should return a
signed response regarding the certificate in question.
What should the original ocsp server do now?
    - If it simply gives the client back the signed message, wouldn't the
client have to reject it as stated above in #3?
    - Or, should the server perform all of the steps in 3.2 to ensure that
the signed response is valid, and then just resign it themselves and give
the newly signed copy to the Client?

I would assume that the second statement, where the server authenticates and
resigns, is the method to use, however this was not clear to me from the
RFC.

Thanks,
Andrew Sciberras
Adacel Technologies Ltd

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 19 Sep 2001 22:24:54 -0700

Andrew -
            My answer is in-line:
 
-----Original Message-----
From: Andrew Sciberras [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2001 9:25 PM
To: Pkix (E-mail)
Subject: Clarification of ServiceLocator in RFC 2560
 
Hi,

 
 
<rmh>Both cases are in-fact valid, essentially it is a question to forward
or to proxy; a forward possibly makes sense in the case of an issuer
operating a public responder using a CA delegated responder
certificate.</rmh>

Thanks,
Andrew Sciberras
Adacel Technologies Ltd