RE: DPD & DPV requirements - Recursion Issues

[Stephen Kent <kent@xxxxxxx>]

Mike,

>  > . . .
>  > the question I asked was whether the OCSP response carried data that
>  > tied it to a requestor, not a responder.
>
> As Rick Salz noted, RFC 2560 enables such binding via the nonce mechanism.
> Use of this mechanism is not however mandated.  Also, Rich Akney was a
> strong advocate of the OPTIONAL requestorName syntax in an OCSP request.
> The definition of the production of response signature in RFC 2560 does not
> include the contents of the request in its hash.  We might wish to consider
> amending this in the OCSPv2 I-D but it's not yet clear to me that we should
> inhibit response transparency.  A relying party might very well wish to know
> who is ultimately standing behind a certificate.

The nonce is not a big concern, if it is just a way to match a 
request and a response, and can safely be ignored by the client, 
given suitable protection for the client/server query/response 
exchange. The requestorName is more of an issue, as it makes clear 
that the client or the server was not the requestor, in the case of 
nested or recursive server interactions.

I'm confused by your last sentence; presumably the OCSP responder 
stands behind the response, irrespective of the identity of the 
requestor, right?

Steve