On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla <e...@rtfm.com> wrote:
On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen <yn...@spec-work.net>
wrote:
Hi,
On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <e...@rtfm.com> wrote:
PR: https://github.com/tlswg/tls13-spec/pull/448
Targe landing date: Wednesday
In Buenos Aires we discussed moving CertificateStatus to part of the
Certificate message. In offline conversations, it started to look like
that
wasn't optimal in part because it created an asymmetry wrt Signed
Certificate Timestamps. Instead, I propose just carrying the response
in
the response extensions.
I just created PR#443, which moves the CertificateStatus response to an
extension in EncryptedExtensions. Comments welcome.
-Ekr
Regarding Certificate Status, is it such a good idea to keep both the
original extension and the newer status_request_v2 extension in TLS 1.3?
The client may have to signal the original extension in order to be
interoperable with older TLS implementations, but wouldn't it be best if
TLS 1.3 mandated the v2 extension in the server response?
I don't think it's a good idea to have the server responding with
extensions
that the client didn't offer. If we're going to prefer v2, I would rather
forbid
the v1 version in TLS 1.3
I was thinking along the lines of saying that TLS 1.3 clients that support
certificate status MUST send v2, MAY send v1 (to be interoperable with
older servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS
1.3 session) MUST respond with v2 and MUST NOT respond with v1.
--
Sincerely,
Yngve N. Pettersen
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
