On Thu, Oct 29, 2020 at 10:30 AM 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*. > > > > 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). > > > [Joe] So you are in favor of both clients and servers mandatory implementing OCSP, but only requiring it be used when it is signalled in the certificate? > 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
