On Wed, 12 Aug 2020 at 07:17, Mohit Sethi M
wrote:
> Thank you again for the feedback. I have updated the text in github:
> https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7
>
> Here is the diff for your convenience:
>
Hi Alan and Terry,
Thank you again for the feedback. I have updated the text in github:
https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7
Here is the diff for your convenience:
On Aug 11, 2020, at 8:40 AM, Terry Burton wrote:
>
> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M
> wrote:
>>
>> Section 5.7 "Resumption" says:
>>
>>> When resumption occurs, it is based on cached information at the TLS
>>> layer. To perform resumption in a secure way, the EAP-TLS peer
On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M wrote:
>
> Section 5.7 "Resumption" says:
>
> > When resumption occurs, it is based on cached information at the TLS
> >layer. To perform resumption in a secure way, the EAP-TLS peer and
> >EAP-TLS server need to be able to securely retrieve
Hi Terry,
Section 5.7 "Resumption" says:
> When resumption occurs, it is based on cached information at the TLS
> layer. To perform resumption in a secure way, the EAP-TLS peer and
> EAP-TLS server need to be able to securely retrieve authorization
> information such as certificate
On Aug 10, 2020, at 11:58 AM, Terry Burton wrote:
> Reading "Using EAP-TLS with TLS 1.3" I find the text potentially
> misleading when it comes to resumption within TLS 1.3, specifically
> for the case where the peer wishes to re-validate the certificate
> originally provided by the server during
Hi,
Reading "Using EAP-TLS with TLS 1.3" I find the text potentially
misleading when it comes to resumption within TLS 1.3, specifically
for the case where the peer wishes to re-validate the certificate
originally provided by the server during the initial handshake using
only its locally cached
