Hi Max > On 29 Oct 2020, at 18:30, Max Pala <madw...@openca.org > <mailto:madw...@openca.org>> 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 <emu-boun...@ietf.org <mailto:emu-boun...@ietf.org>> on behalf of > Eliot Lear <lear=40cisco....@dmarc.ietf.org > <mailto:lear=40cisco....@dmarc.ietf.org>> > Date: Thursday, October 29, 2020 at 10:53 AM > To: Joseph Salowey <j...@salowey.net <mailto:j...@salowey.net>> > Cc: EMU WG <emu@ietf.org <mailto: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 >> <mailto: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/ >> <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 >> Emu@ietf.org <mailto:Emu@ietf.org> >> https://www.ietf.org/mailman/listinfo/emu >> <https://www.ietf.org/mailman/listinfo/emu> > > _______________________________________________ Emu mailing list Emu@ietf.org > <mailto:Emu@ietf.org>https://www.ietf.org/mailman/listinfo/emu > <https://www.ietf.org/mailman/listinfo/emu>
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
