Re: [TLS] OCSP Must Staple

[Brian Smith <[e-mail]>]

On Wed, Oct 23, 2013 at 8:58 AM, Tom Ritter <[e-mail]> wrote:
> I support this.  I would also like to seek to have it added to the
> HTTP Strict Transport Security header as an option (same as
> includeSubdomains), so that it can pin to the domain as well as the
> certificate - although that may need to wait until this is
> standardized and identifiers solidified.

FWIW, I am working on a draft that is almost exactly that, but with a
separate header named "Must-Staple." It has basically has the same
syntax and similar semantics as Strict-Transport-Security (including
includeSubDomains), with the additional qualification that it must be
ignored unless it was received on a connection that stapled an OCSP
response. This is complementary with the work that PHB is doing and it
can be done independently. In fact, I'm planning to have Firefox
support this Must-Staple header before it supports the X.509
extension, since we don't know what OID to use for the X.509 extension
yet. I also intend for us to support the X.509 extension.

We designed our normal OCSP stapling implementation with this in mind.
In Firefox (beta) right now, if you staple an OCSP response then it
must be a valid "Good" response or the connection fails.
Unfortunately, we've seen servers stapling expired OCSP responses, so
we're probably going to temporarily make an exception: If you staple
an otherwise-valid "Good" response that is expired, then we'll do the
fetching over OCSP with "hard fail" semantics. Then, the additional
semantics of "Must-Staple" become "Fail the connection if there is no
OCSP response stapled."

PHB: I am happy to help with the "OCSP Stapling Required" X.509 draft
too, if you would like. There are several editorial issues that should
be addressed. If people are interested, we could set up a side
discussion in Vancouver to go over these things, so that we can have a
new, unexpired draft to finish up soon.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)