Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

[Mounira Msahli <[e-mail]>]

Hi all, 

Please find attached a new version of the draft. We took account of pevious TLS group comments. 
William, editor of 1609.2, proposes to add the section certificate verify (section 4.3 in the draft). 
It concerns the addition of IEEE 1609.2 signature for the the Certificate verify. 

We are soliciting your feedbacks. 

Regards 
Mounira

----- Mail original -----
De: "Hubert Kario" <[e-mail]>
À: "tls" <[e-mail]>
Cc: "Mounira Msahli" <[e-mail]>, "Ilari Liusvaara" <[e-mail]>
Envoyé: Lundi 27 Août 2018 19:39:12
Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Monday, 27 August 2018 19:24:34 CEST Mounira Msahli wrote: 
> One could abbrevate the handshake traces to just show the relevant 
> parts (which could also cut some clutter)? I think the relevant 
> messages always occur in the same order (clienthello, serverhello/ 
> encryptedextensions, certificate, certificate). 

the draft doesn't change the order of messages, doesn't add new messages and 
doesn't change the place in which the relevant extensions are placed – so, 
what is the utility of duplicating the message flow from the TLS RFCs? 

e.g. RFC 8449 and RFC 7685 don't, and they did define new extensions 

> The table in section 4.2. Extensions of [RFC 8446] (TLS 1.3) indicates the 
> messages where a given extension may 
> appear: 
> | client_certificate_type [RFC7250] | CH, EE | 
> | 
> | server_certificate_type [RFC7250] | CH, EE | 
> 
> But in RFC 7250 (TLS 1.2), the same extensions could appear in CH and SH. 

correct, this RFC 8446 table applies only to connections that negotiated TLS 
1.3 

-- 
Regards, 
Hubert Kario 
Senior Quality Engineer, QE BaseOS Security team 
Web: www.cz.redhat.com 
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic