Speaking for a broader-than-browser implementation: PKI stack in Windows found hard failure on OCSP non-deployable. This is not to say that OCSP is entirely useless; OCSP information is considered as part of certificate validation. A very much simplified summary:
* If OCSP says "revoked", certificate validation fails. * Without positive OCSP response, CRL processing is used. * "Must staple" extension is supported. * Apps have latitude in how they handle "revocation offline" scenarios. Cheers, Andrei From: Uta <uta-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Wednesday, January 19, 2022 10:50 AM To: Yaron Sheffer <yaronf.i...@gmail.com> Cc: u...@ietf.org; tls@ietf.org Subject: [EXTERNAL] Re: [Uta] OCSP in RFC7525bis On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer <yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>> wrote: Hi, RFC 7525 (the TLS BCP) has a section [1] with "weak" recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if they don't get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it's trying to solve. Well, many browser implementations have just stopped using OCSP entirely, in favor of centralized revocation information a la CRLSets, etc. I don't know what non-browser implementations do. So for the new BCP, we have three options: * Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.) I don't think this is a good idea. * * Remove the whole discussion of OCSP, saying that in its current form it's not adding value. * Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.' I think if we are to have anything here it would need to actually describe the situation and why people soft fail and/or are moving away from OCSP. I might be able to provide some text from the browser perspective, though perhaps AGL or Carrick could also chime in? -Ekr * We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that's more recent than Chung18 [3], that would be very useful. Thanks, Peter, Thomas and Yaron PS: apologies for cross-posting. [1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7525%23section-6.5&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150629004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7889gR6y%2FLANzyYcMKnoaRQWTsOCekiZ3t3mGdh9xBo%3D&reserved=0> [2] https://github.com/yaronf/I-D/pull/279/files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fyaronf%2FI-D%2Fpull%2F279%2Ffiles&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150629004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6zhOrdItJwexqo3TjZ%2F8Xr7ox9VveirU0QktippCURM%3D&reserved=0> [3] https://cbw.sh/static/pdf/chung-imc18.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcbw.sh%2Fstatic%2Fpdf%2Fchung-imc18.pdf&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150678992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b1OpjmGl2nVNIN85yOq2RSbmAEgPsr3xIgLxRSgGhC8%3D&reserved=0> _______________________________________________ Uta mailing list u...@ietf.org<mailto:u...@ietf.org> https://www.ietf.org/mailman/listinfo/uta<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Futa&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150678992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6QlOv9WDCw0Z8WnjYUHb1HhSiYqrjd5tAzXZ5N6EI5w%3D&reserved=0>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
