> > Do the following: Give every certificate a different
> > AIA, speak: a different GET-URL´s. Then ignore the actual
> request-data at
> > the server and always replying with the preproduced response
> for this URL.
> > Combined with a good DNS-Load-Balancing the fastest
> OCSP-responder you can
> > get. You can call this setup: "abusing the possibility of
> replay-attacks for
> > good".
>
> That's disgusting. I sure hope Identrus isn't doing that for their
> "infrastructure" certs.
No, they don´t. But it is not necessary to abuse the standard that much -
simply think of caching OCSP-Responders, that cache the response of another
OCSP-responder - they cannot send nonce, too. And signing the answer
themselves may spoil the requirements of OCSP-Responder-Certificate
delegation. A solution would be to double sign the request: the answerer
including nonce and the generator giving the result. But this is not within
the scope of RFC2560.
> > 3. If there is no nonce in the response, accept it and (only then)
> > check the timestamping (weaker replacement for nonce).
>
> No no no. First, OpenSSL has no internal code that uses OCSP. It has a
> sample app that does the right thing. Second, it is *totally wrong* to
> silently fall back to weaker security. The proper behavior is this:
> If client wants a nonce, use it.
> If reply comes back without a nonce, return warning
> Allow client to log the fact, change its config, and retry without a
> nonce
Probably you are right with your first point. But I do not see why I should
retry without a nonce - I would get EXACTLY the same response. So your
handling boils down to this:
1) If client wants a nonce, use it.
2) If reply comes back without a nonce, return warning
3) Allow client to log the fact, change its config,
and accept it without a nonce
What would happen in real world: every programmer would have to do your
third step somewhat automatically.
> > I cannot think of any cause why a client wants to omit nonce!)
>
> Because, unless the responder includes the nonce: *the security
> guarantee of the nonce is useles.* It is also useless as a "due
> diligence" proof, since it is trivial for the client to back-date his
> OCSP query.
To do this, one should introduce the options "--do-nonce-check" (default)
and "--no-nonce-check". But sending ... - I think we should always send a
nonce.
ciao, Fl0
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
