On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams
<nicolas.willi...@oracle.com> wrote:

> This is a rather astounding misunderstanding of the protocol.  An
> OCSPResponse does contain unauthenticated plaintext[*], but that
> plaintext says nothing about the status of the given certificates -- it
> only says whether the OCSP Responder was able to handle the request.  If
> a Responder is not able to handle requests it should respond in some
> way, and it may well not be able to authenticate the error response,
> thus the status of the responder is unauthenticated, quite distinctly
> from the status of the certificate, which is authenticated.  Obviously
> only successful responses are useful.

I agree on this and but the implementation of OCSP has to deal with
all "non definitive" (to take the wording of the RFC) answers. That's
where the issue is. All the "exception case", mentioned in 2.3, are
all unauthenticated and it seems rather difficult to provide authenticated
scheme for that part as you already mentioned in [*].

That's why malware authors are already adding fake entries of OCSP
server in the host file... simple and efficient.

I just wanted to raise the point that a model like PK-i relying on complex
scheme for security will easily fail at the obvious as the attacker
is often choosing the shortest/fastest path to reach his goal.

> [*] It's not generally possible to avoid unauthenticated plaintext
>    completely in cryptographic protocols.  The meaning of a given bit
>    of unauthenticated plaintext must be taken into account when
>    analyzing a cryptographic protocol.

--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to