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

Reply via email to