Hi Max > On 29 Oct 2020, at 18:30, Max Pala <[email protected] > <mailto:[email protected]>> wrote: > > 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.
Perfectly reasonable. > > 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. Yep. > > 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. > Worth more. Eliot > Cheers, > Max > > From: Emu <[email protected] <mailto:[email protected]>> on behalf of > Eliot Lear <[email protected] > <mailto:[email protected]>> > Date: Thursday, October 29, 2020 at 10:53 AM > To: Joseph Salowey <[email protected] <mailto:[email protected]>> > Cc: EMU WG <[email protected] <mailto:[email protected]>> > 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 <[email protected] >> <mailto:[email protected]>> 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/ >> <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 >> <https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4> >> _______________________________________________ >> Emu mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/emu >> <https://www.ietf.org/mailman/listinfo/emu> > > _______________________________________________ Emu mailing list [email protected] > <mailto:[email protected]>https://www.ietf.org/mailman/listinfo/emu > <https://www.ietf.org/mailman/listinfo/emu>
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
