OCSP stapling limitations (was Re: [PATCH 0 of 4] OCSP stapling)

[Rob Stradling]

On 06/10/13 11:14, Maxim Dounin wrote:
<snip>
>> 2. The CA/Browser Forum are defining a "must staple" certificate
>> extension [2], which we anticipate that browsers (e.g. [3]) will
>> recognize and enforce, by aborting the TLS handshake if a stapled
>> OCSP response was not sent.
>
> I believe it was said more than once that this changes OCSP
> stapling quite significantly.  As of now it's an optimization
> technology,

Yes, but it's an optimization technology that seems to work reliably in 
httpd and IIS.  ;-)

> while with "must staple" it will become a required part of a
> certificate.  There is no surprise such change requires quite a
> different coding aproach.
>
> BTW, the draft in question was already expired.

So it has.  I've notified the author.  Thanks.

>> 3. Google are planning [4] to require the use of Certificate
>> Transparency (CT) [5], and this plan expects OCSP Stapling to work
>> reliably.
>
> It looks like there is more than one way to include signed
> certificate timestamp, and OCSP stapling is just one of them.  And
> I'm not sure it's a good way - the X509v3 certificate extension
> should be better, as long as it's a required part of a
> certificate.

Both approaches have advantages and disadvantages.  Google plan to 
require multiple Signed Certificate Timestamps (SCTs) when the X509v3 
certificate extension approach is used (= certificate size bloat), but 
only 1 SCT when the OCSP Stapling approach is used.

>> What work needs to be done to enable Nginx to send a stapled OCSP
>> response every time (without having to use the "ssl_stapling_file"
>> directive)?
>
> I tend to think that ssl_stapling_file is a good way to provide an
> OCSP response if it's required for some reason.

It works, but doesn't it require the user to regularly download a newer 
OCSP Response for each certificate, update the contents of their 
stapling file(s), and reload Nginx?
IMHO, this needs to be fully automated, just as it is in httpd and IIS.

Are you saying that there's zero chance of this ever happening?

>> Could you work around the fact that the OpenSSL certificate status
>> callback is blocking?  Or would you absolutely require a
>> non-blocking alternative to be available?
>> (Ben Laurie, who is on both the OpenSSL and CT teams, told me
>> recently: "If there's changes needed to OpenSSL, it'd be helpful to
>> know sooner rather than later.")
>
> I don't think changing OpenSSL to support non-blocking callbacks
> is feasible.  While it's something we would like to have (just couple
> of weeks ago we've discussed here that non-blocking callbacks are
> required to support external session store), it looks like too
> major change for OpenSSL.  It will also take several years to be
> actually usable.

I'll discuss this further with Ben.  Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online