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
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
