The TL;DR is that in the future we expect OCSP to be a lot less relevant. I checked with our team, and the general story is that currently if there is a valid OCSP stapled response we use it but otherwise do OCSP
In the future when we have CRLite enabled and it applies to the certificate, then we plan to mostly rely on CRLite and ignore what's in OCSP. We have been looking at a transitional mode where we double-check apparently CRLite-revoked certificates with OCSP in which case we would behave as above. -Ekr On Fri, Sep 16, 2022 at 8:43 AM Salz, Rich <rsalz= 40akamai....@dmarc.ietf.org> wrote: > I think this is of general interest, so I’m posting here rather than > poking friends I know. > > > > Browsers are phasing out doing OCSP queries themselves. The common > justification, which makes sense to me, is that there are privacy concerns > about leaking where a user is surfing. > > > > My question is, what are browsers doing, and planning, on doing about OCSP > stapled responses? I think there are three possibilities: > > No stapled response > > A stapled, valid, “good” response > > A stapled, expired or “bad” response > > > > I can imagine two possibilities, proceeding or popping up a warning page. > I haven’t seen the warning when there is no OCSP response, but maybe that > does happen. > > > > We’re still going to staple good responses, when we have them, but I am > wondering if long-term we should still bother? > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
