Hi, In EMU WG there was a stong consensus to mandate revocation checking in EAP-TLS 1.3. Mandatory OCSP Stapling was suggested by someone as a way to achieve this. The transition from EAP-TLS 1.2 to EAP-TLS 1.3 made this possible. The mandatory to use OCSP Stapling was softened after comments from Hannes, which was good. I think the used mechanism should the choice of the application. I don't think there was much discussion regarding specific use cases. The current text is:
"the revocation status of all the certificates in the certificate chains MUST be checked (except the trust anchor)." "EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in [RFC6066] and Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and EAP-TLS servers use OCSP stapling" You probably already know this but NIST has introduced strong requirements on OCSP for TLS: "TLS servers shall be configured with certificates issued by a CA that publishes revocation information in Online Certificate Status Protocol (OCSP) [63] responses." "The server shall support the use of the following TLS extensions. 5. Certificate Status Request extension" https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf 3GPP has also introduces requirements on OCSP and OCSP stapling: OSCP should be supported by CAs and "Certificate Status Request" should be supported by TLS clients and servers. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2279 https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2293 Both OCSP and OCSP Stapling are quite widely supported. According to Wikipedia, 16/18 TLS implementations support OCSP. One of the two lacking implementations is from Ericsson, but I know that both OCSP and OCSP Stapling is in actively development right now. https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations https://github.com/erlang/otp/tree/5b6931f001a00bff730867fdf07a8580eb989e24/lib/ssl I think it makes sense to strengthen recommendations and requirements on revocation, OCSP, and OCSP stapling and align RFC7525bis more with NIST.SP.800-52r2. I think the one omission in RFC7525 that should be fixed in RFC7525 is a recommendation to do revocation checking. I think that is the most important thing, not how the revocation checking is done. I think another omission in RFC7525 that should be fixed in RFC7525 is a discussion on certificate life-times, which is often discussed together with revocation checking- Short-lived certificates is an improvement over long-lived certificates, but not at all a replacement for revocation checking. Cheers, John From: Uta <uta-boun...@ietf.org> on behalf of Hannes Tschofenig <hannes.tschofe...@arm.com> Date: Monday, 24 January 2022 at 11:32 To: Yaron Sheffer <yaronf.i...@gmail.com>, uta@ietf.org <uta@ietf.org>, t...@ietf.org <t...@ietf.org> Subject: Re: [Uta] OCSP in RFC7525bis Hi Yaron, That’s exactly my worry. I have seen OCSP being proposed in EMU (with EAP-TLS) and also in IoT environments where it just don’t make a lot of sense to me. Hence, I would like to understand the motivation behind it and the use cases. Ciao Hannes From: Yaron Sheffer <yaronf.i...@gmail.com> Sent: Thursday, January 20, 2022 3:18 PM To: Hannes Tschofenig <hannes.tschofe...@arm.com>; uta@ietf.org; t...@ietf.org Subject: Re: OCSP in RFC7525bis Hi Hannes, This is not about my personal beliefs. RFC 7525 looks at certificate revocation in the context of TLS (and not only TLS for Web use but the broader ecosystem) and recommends OCSP and OCSP Stapling as the best available techniques to enable effective certificate revocation, but with caveats. It’s been more than 6 years since the RFC was published, and we are reviewing our recommendations, which may or may not still be valid. Thanks, Yaron From: Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> Date: Thursday, January 20, 2022 at 12:00 To: Yaron Sheffer <yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>>, uta@ietf.org<mailto:uta@ietf.org> <uta@ietf.org<mailto:uta@ietf.org>>, t...@ietf.org<mailto:t...@ietf.org> <t...@ietf.org<mailto:t...@ietf.org>> Subject: RE: OCSP in RFC7525bis Hi Yaron, Where do you believe OCSP will be a good fit and why? Ciao Hannes From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> On Behalf Of Yaron Sheffer Sent: Wednesday, January 19, 2022 3:57 PM To: uta@ietf.org<mailto:uta@ietf.org>; t...@ietf.org<mailto:t...@ietf.org> Subject: [TLS] OCSP in RFC7525bis 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. So for the new BCP, we have three options: 1. 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.) 2. Remove the whole discussion of OCSP, saying that in its current form it’s not adding value. 3. Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit. 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 [2] https://github.com/yaronf/I-D/pull/279/files<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ec3c68b8ad6f51f9&q=1&e=e5bbdeed-379b-48d2-945b-0fb2813e9ffa&u=https%3A%2F%2Fgithub.com%2Fyaronf%2FI-D%2Fpull%2F279%2Ffiles> [3] https://cbw.sh/static/pdf/chung-imc18.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a9bcddc9d2ae3288&q=1&e=e5bbdeed-379b-48d2-945b-0fb2813e9ffa&u=https%3A%2F%2Fcbw.sh%2Fstatic%2Fpdf%2Fchung-imc18.pdf> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
