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.

--
Michael Richardson <mcr+i...@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to