On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen <yn...@spec-work.net> wrote:
> 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. Well, what if the client doesn't want the OCSP response? -Ekr > > -- > Sincerely, > Yngve N. Pettersen >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
