[145488] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: A mighty fortress is our PKI, Part II

daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed Jul 28 23:14:58 2010

Date: Wed, 28 Jul 2010 20:09:29 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Alexandre Dulaunoy <a@foo.be>
Cc: cryptography@metzdowd.com
In-Reply-To: <AANLkTi=aDmqQnUU2bzsMAtXwLx9SM0MO0XHc-r3iT+eU@mail.gmail.com>

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@cs.auckland.ac.nz> wrote:
> > Nicolas Williams <Nicolas.Williams@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@metzdowd.com

home help back first fref pref prev next nref lref last post