Bodo Moeller wrote:
>
> On Thu, Feb 08, 2001 at 08:10:57PM +0100, Richard Levitte - VMS Whacker wrote:
> > "Florian Oelmaier" <[EMAIL PROTECTED]>:
>
> >> Let me try hard to think intelligent: We have a PKI. All people
> >> share the same time (i.e. using NTP). Our CA generates
> >> OCSP-responses for its 10 Sub-CAs every 2 minutes with a
> >> "nextUpdate" interval of 2 minutes. As OCSP-Responses for Sub-CAs
> >> are used very frequently they will be distributed all over our
> >> company every 2 Minutes to 30-50 central webservers that answer
> >> OCSP-responses.
>
> > Those are *your* conditions. You might as well get responses that
> > have "nextUpdate" intervals of an hour!
>
> His point, I think, is that under these conditions the OCSP responders
> *can't* include the client nonce. (They don't sign the responses
> themselves.)
>
Then why can't it send the nonce for inclusion to whatever does sign the
response?
> Under different conditions nonces may be essential, true. So OCSP
> responders that *can* provide nonces should *always* include one, even
> if the request did not include a nonce. (This is to avoid replay of
> nonce-less responses to clients who sent a request with a nonce.)
>
The only potential problem with that is whether client software will
reject such responses.
I've currently tested three different responders and while they have
several anomalies (or clear bugs) all of them process the nonce in a
request.
However none of them include a nonce in the response if the request is
nonce-less.
This, as you indicated, makes clients vulnerable to a replay attack if
they automatically accept a nonce-less response to a request with a
nonce.
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.
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]
