Hi Michael,
Thanks for the question. I am objecting to the mandatory use of OCSP for TLS
1.3 in EAP-TLS.
I am fine with having it optional.
Mbed TLS is used in implementations of EAP-TLS and we have received little
interest in OCSP support. The interest is so low that the proposed code was
never merged.
Companies seem to use an alternative approach instead, namely to change
certificates via a device management solution. After all, you will have to
offer a solution anyway. You cannot just reject access to your backend
authentication infrastructure and do nothing.
Do other EAP methods rely on OCSP?
Ciao
Hannes
-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: Wednesday, October 21, 2020 6:46 PM
To: Hannes Tschofenig <hannes.tschofe...@arm.com>; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
Hannes Tschofenig <hannes.tschofe...@arm.com> wrote:
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS)
> and I believe this is a problem for implementations. This extra burden
> is IMHO unjustified. For the type of deployments where EAP is used
> there is no need for a mandatory certificate revocation checking with
> OCSP.
Is it:
1) there is no need for mandatory certificate revocation checking
2) there is no need to make OCSP checking the mandatory method for
certificate revocation checking
Are you objecting to:
a) mandatory certificate revocation checking
b) mandatory OCSP
c) mandatory OCSP *stapling* when using OCSP
I think, if you the client (who has no Internet yet), is going to be able to do
certificate revocation checking, then doing it via OCSP stapling is the right
way to go. It can't do ONLINE CSP, because it has no Internet.
> Having it optional, like the use of many other TLS extensions, is fine
> for me. FWIW even TLS 1.3, which is used in a more generic environment,
> does not mandate the use of OCSP stapling.
> This requirement will make the problem described in
> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of
> this fact since they are also co-authors of draft-ietf-emu-eaptlscert.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
