On Thu, Oct 29, 2020 at 3:12 PM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Joseph Salowey <j...@salowey.net> wrote: > > 2. Require Servers to Implement and Recommended to Use OCSP with text > > similar to the following: > > I don't think that this text is quite right. > > I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask > documents to explain what a reasonable exception might look like. > This text does not do that. > > > “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.“ > > I suggest: > > “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate > recovation checks, MUST implement Certificate Status Requests using OCSP > stapling as specified in Section 4.4.2.1 of [RFC8446]. > > It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling) > for > verifying the status of server certificates as specified in Section 4.4.2.1 > of [RFC8446]. > <MCR: BUT, I think that section 4.4.2.1 is not where certificate status is > mandated for TLS. I can't find the right place> > > 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.“ > > I don't know much about the last part. > I suggest it be split as three paragraphs for readability. > > [Joe] Thanks Michael, I think your suggestion is a better way to phrase it > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
