[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: OCSP stapling
From:       Jeremy Harris <jgh () wizmail ! org>
Date:       2013-02-23 15:03:26
Message-ID: 5128DA3E.6010907 () wizmail ! org
[Download RAW message or body]

On 02/19/2013 02:33 PM, Dr. Stephen Henson wrote:
> On Tue, Feb 19, 2013, Jeremy Harris wrote:
>
>> On 18/02/2013 22:32, Dr. Stephen Henson wrote:
>>>> That's fine except that we're using SSL_CTX_set_verify() callback already
>>>> and the docs say it and SSL_CTX_set_cert_verify_callback() should not
>>>> be mixed.
>>>>
>>>
>>> That explanation could be clearer. In this case it's fine to mix the two.
>>
>> OK, thankyou.  Now, about the need for a store for the OCSP verify?
>
> You can disable verification altogether with the OCSP_NOVERIFY flag to
> OCSP_basic_verify, it should then never reference the passed store and it can
> be NULL.
>
> That's fine if the OCSP response has been signed by a CA in the
> server certificate chain as that chain has already been verified.

(which last is a requirement of the Stapling RFC, if I understand)

So I'm still confused.   What does OCSP_NOVERIFY disable and what
remains?   If it stops the checking of the signing chain of the stapling,
how is the case of a subverted server, which has a valid-but-revoked certificate,
handled?   It would seem that my client would successfully verify the
original server certificate and the content of stapling (invented by the now
malicious server to claim that the server certificate is still valid).

-- 
Thanks,
     Jeremy

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]