Re: [TLS] OCSP Stapling confusion

[Ilari Liusvaara <[e-mail]>]

On Mon, Dec 10, 2018 at 07:16:31AM -0500, Daniel Kahn Gillmor wrote:
> On Mon 2018-12-10 02:24:29 +0000, Salz, Rich wrote:
> >>     * the status_request TLS extension doesn't provide a mechanism for
> >        stapling OCSP for intermediate certs.
> >   
> > Nobody does this.  There's a handful of reasons, but the end result is: nobody does this.
> 
> I'd be interested in hearing the reasons enumerated.  It seems to me
> like being able to promptly revoke an intermediate certificate is a
> useful bit of mechanism.  is it just because we hope the major browsers
> are clever and responsive enough that they'll push out a CRLset (or
> equivalent) when they hear of an intermediate that is found to be
> violating the BRs?

One is that in baseline requirements, the maximum intermediate OCSP
lifetime is 12 months(!) (compare this with the maximum end-entity
OCSP lifetime, which is 7 days), which makes them pretty useless for
quickly notifying of intermediate compromises when stapled.

And yes, some CAs actually use those 12 month OCSP responses.

As noted, all the browsers handle intermediate compromise via their
own blacklisting measures (oneCRL/CRLset/Disallowed.stl/etc...)

> >>    So i think this is a big swirling mishmash of not-quite-compatible and
> >     not-quite-complete specs, especially as we think about TLS clients and
> >     servers that want to be interoperable with both TLS 1.2 and TLS 1.3.
> >   
> > Yes, there are many things that could be cleared out with a BCP doc.
> > I would be interested in helping with that.
> 
> I agree that a BCP would be pretty helpful in clarifiying the state of
> play, since it's currently scattered across a few docs over several
> years.
> 
> But I think i'm proposing something that is not quite just a "BCP",
> since it might involve changing the semantics and extensibility of
> status_request (limiting it to OCSP responses (from the authorities
> found in the AIA?))  so that "TLS Feature" can actually provide
> meaningful guarantees of OCSP stapling for X.509v3 certificates.
> 
> Because right now, with all the extra (currently unused) flexibility in
> status_request, it's hard to see how a client or server can meaningfully
> rely on "TLS Feature" as a "must-staple" extension.

The TLS feature extension looks to be woefully underspecified. Even
in the one usecase it was meant to, which was this.

The interpretation I took when writing some releated code was that 5
in any (including CA) TLS feature extension means OCSP stapling EE
certificate is mandatory (or the EE certficate is shortlived). Just
answering the extension 5 is not enough.


-Ilari