A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 10:03:08PM +0200, Alexandre Dulaunoy wrote:
> On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann
> <pgut001 at cs.auckland.ac.nz> wrote:
> > Nicolas Williams <Nicolas.Williams at oracle.com> writes:
> >
> >>Exactly.  OCSP can work in that manner.  CRLs cannot.
> >
> > OCSP only appears to work in that manner.  Since OCSP was designed to be 100%
> > [...]

The protocol allows for more than simple proxy checking of CRLs.  What
implementations do is another matter (which matters, of course, but be
sure to know what you're condemning, the implementations or the
protocol, as they're not the same thing).

> OCSP is even better for an attacker. As the OCSP responses are
> unauthenticated[1], you can be easily fake the response with
> what ever the attacker likes.
> 
> http://www.thoughtcrime.org/papers/ocsp-attack.pdf
> 
> [1] Would be silly to run OCSP over SSL ;-)

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.

The status of a certificate (see SingleResponse ASN.1 type) most
certainly is covered by the signature: SingleResponse is part of
ResponseData, which is the type of tbsResponseData, which is what the
signature covers.

Don't take my word for it, nor that paper's author's.  Read the RFC and
decide for yourself.

[*] 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.


Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com