Hi Eliot, The EAP server is expected to frequently request a OCSP response from the OCSP responder (a server typically run by the certificate issuer). The OCSP response is then added to the Servers Certificate message as long as it is valid. Before the OCSP response is close to expiring, the EAP server requests a new OCSP response from the OCSP responder.
I assume you mean the client is offline? If use cases where none of the entities can contact the OCSP responder is in scope, OCSP stapling does not work. OCSP Nonce does not work with OCSP stapling. If you want you revocation data to be real-time you need to make an online OCSP request-response to the OCSP responder. John -----Original Message----- From: Eliot Lear <lear=40cisco....@dmarc.ietf.org> Date: Monday, 26 October 2020 at 13:16 To: John Mattsson <john.matts...@ericsson.com> Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling Hi John, My question is one of pragmatics. In an offline industrial environment, what is expected of the server to accomplish the stapling? Especially if the request is nonced. Eliot > On 26 Oct 2020, at 13:08, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > Hi, > > When this was discussed in the group, it was decided to not only mandate > revocation checking, but to also mandate OCSP stapling as is it often the > only viable solution to let an offline peer check the revocation status of > the server. We had a discussion on must-staple, and the decision was to > mandate stapling in the draft instead of waiting for support of the X.509 > must-staple extension. OCSP and OCSP stapling are quite well supported > already and should be even more well-supported in a few years: > > 1. Basically all TLS implementations support OSCP, and a majority support > OSCP stapling (Certificate Status Request). Mbed is an exception rather than > the rule. > > https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations > > 2. All browsers (desktop and mobile) support OCSP stapling. > > https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP). > > 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the > Certificate Status Request extension (i.e. OCSP stapling). > > > - I do not think there is any wiggle room at all in the current version of > the draft: > > "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate > Status Requests [RFC6066] > for the server's certificate chain" > > Note that in the current draft it is unspecified how the server checks the > revocation status of the client's certificate: > > "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation > status of the certificates in the > client's certificate chain." > > > - The X.509 must-staple extension > (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant > for server certificates in the current EAP-TLS 1.3 draft as stapling is > already a must. OSCP stapling is not very useful for client certs. I do not > know if the X.509 must-staple extension is well supported or not. It could > become relevant for server certs if the requirements are softened. > > > - My view is that OSCP stapling is a very good fit for EAP in particular and > is well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 > from the start avoids having to rely on the X.509 must-staple extension. Any > implementation not supporting OCSP stapling should implement it together with > TLS 1.3. I do not think the requirent should be softened, but if it is, my > view is that is should be softened as little as possible. > > Cheers, > John > > _______________________________________________ > 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
