+1 > On Oct 29, 2020, at 1:37 PM, Eliot Lear <lear=40cisco....@dmarc.ietf.org> > wrote: > > Hi Max > >> On 29 Oct 2020, at 18:30, Max Pala <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> 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.orghttps://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
