Hi Eliot, all,
In our industry we solved this issue by requiring OCSP stapling if and only if the certificate being validated carries the OCSP URI in the certificate. This allows us to live in a mixed environment where support for OCSP might have been introduced later on and allows the CA to explicitly support OCSP for the certificate by including the URL in it. If the “ecosystem” policy allows it – you might suggest that if OCSP responses are not not provided but the URL where to get OCSP responses is known to the device (or it is in the certificate), the device/entity can continue with the authentication but it should not enable any device/entity functionality before successfully executing (and validating) the OCSP protocol first (and disconnect if not reachable/invalid/revoked). Just my 2 cents. Cheers, Max From: Emu <emu-boun...@ietf.org> on behalf of Eliot Lear <lear=40cisco....@dmarc.ietf.org> Date: Thursday, October 29, 2020 at 10:53 AM To: Joseph Salowey <j...@salowey.net> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11 Hi Joe, My suggestion is that we add some discussion about what to do in the case of no connectivity to the CA. This will be a not-uncommon occurrence, IMHO, in industrial use cases. Eliot On 29 Oct 2020, at 17:23, Joseph Salowey <j...@salowey.net> wrote: An issue was raised in a review of draft-ietf-emu-eap-tls13-11 on the mandatory requirement for OCSP stapling [1]. The document makes the use of OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this may not be feasible in all deployments. This is a quick consensus call for this issue. Please indicate which option below you support and why. Please respond by November 5, 2020. 1. Keep the text as is with OCSP mandatory for all implementations 2. Require Servers to Implement and Recommended to Use OCSP with text similar to the following: “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying the status of server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, it MUST use Certificate Status Requests for the server's certificate chain and it MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert.“ Thanks, Joe [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/ [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
