Florian Oelmaier wrote:
>
> >
> > Then why can't it send the nonce for inclusion to whatever does sign the
> > response?
>
> Because in this case, the responses will be pre-produced (as it is specified
> and allowed in RFC 2560 - chapter 2.5) at a central responder (and therefore
> pre-signed).
>
> These responses will then be distributed to many Web-Servers (not
> necessarily OCSP-Responders, see (*)!) that only distribute them. Security
> will be ensured using the time-stamps of the pre-produced response - thus
> invalidating the pre-rpoduced responce after a few minutes.
>
> This maybe necessary if you have a CA with only a few "users" (speak:
> certificates) but a lot of OCSP-requests. This is the case for a root CA. It
> has only few Sub-CAs, but every time when any certificate in the whole PKI
> will be checked, while verifying the certificate-path the client will
> generate an OCSP-request to the responder of the root-CA to verify the
> Sub-CA certificate.
>
So you are precomputing the OCSP responses for *every* certificate every
two minutes? Yes that would require that you only have a small number of
certificates. It would also require that you prohibit multiple queries
in a request otherwise the number of responses you would need to
precompute could get rather large.
> > So the best we can probably do to check nonces is:
> >
> > 1. Check the nonce if it is present in both request and response.
> > 2. If the request does not include a nonce don't check the response
> > (i.e. tolerate nonce-less and nonce responses).
> > 3. Otherwise reject it.
> >
> > If any responders don't process the nonce value then the request can
> > either not send one in the request or not check it in the response for
> > those particular responders.
>
> >From a security standpoint of view: You are right. But the problem is,
> client configuration is a nasty bitch. Its hard to reconfigure a client if
> you change the usage of pre-produced responses.
>
Unfortunately the current OCSP reponders I've tried all have their own
quirks and will need handling on a case by case basis anyway. There's so
much scope for "interpretation" in RFC2560 that writing a client that
can handle all possible responder behaviours securely without per
responder configuarion is almost impossible.
Its possible that some of the misbehaviour will be fixed but if past
experience is anything to go by its unlikely.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
