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).
Yes, so we can neglect the ServerHelloDone for TLS 1.2? 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. I think, it could be better to make distinction between two TLS versions in handshake phase in terms of presentation. I don't have any objection to combine both in one document. I agree with you about the rest of comments. Cheers Mounira ----- Mail original ----- De: "Ilari Liusvaara" <ilariliusva...@welho.com> À: "Mounira Msahli" <mounira.msa...@telecom-paristech.fr> Cc: "tls" <tls@ietf.org> Envoyé: Lundi 27 Août 2018 18:34:05 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates On Mon, Aug 27, 2018 at 06:21:15PM +0200, Mounira Msahli wrote: > Hi Hubert, > > I can do the exercise but the result will be two sections totally > decorrelated: one for TLS 1.3 and one for TLS 1.2. Two drafts in > one document. The certificate message might be bit annoying as it has different format in TLS 1.2 and 1.3. But most textual discussion probably can be shared between the versions. > - The handshake phase in TLS 1.2 is different from handshake/TLS1.3 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 certificate type is different. One uses cert_type and the > other uses extension defined in [RFC7250]. cert_type is deprecated. One should use the RFC7250 extensions even in TLS 1.2. The TLS 1.3 certificate format negotiation works the same as in TLS 1.2, with exception of extensions being in different message. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
