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?
>>> The extension could be specified as RFC 7250 >>> For the extension, TLS Client and Server Handshake Behavior shall be >>> specified for two TLS versions. Kind Regards Mounira ----- Mail original ----- De: "Hubert Kario" redhat.com> À: "tls" <tls@ietf.org> Cc: "Mounira Msahli" , "Ilari Liusvaara" com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
