I think that the best way to deal with the status_request_v2 extension is to make it a proper part of the TLS 1.3 messages, probably Certificate or CertificateVerify. This is a fairly heavily important extension.
On 12 December 2015 at 05:52, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > When looking at stuff some more, I noticed that extension > status_request_v2, which is used by OCSP stapling and is not deprecated > [1]. > > Now, that extension uses additional handshake message type > (certificate_status), which is specified to go between Certificate > and SKE. Now, TLS 1.3 does not have SKE, and closest equivalent is > server CertificateVerify. But OTOH, Cerficate/CertificateVerify/ > Finished are supposed to form a block? Where it is supposed to go? > > Then there are other supported extensions that add messages. > Specifically the following messages: > > - certificate_url: This can replace client certificate, whic is > straightforward (if causing security issues by its sheer nature). > - supplemental_data: There's ladder diagrams placing this just > before Certificate. Where should this go in TLS 1.3 (there are > undeprecated extensions that would use it)? > > > [1] Unlike status_request, which is listed as deprecated. Was > that intentional or mistake (if intentional, cert_type would also be a > good to deprecate as superceded). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
