Re: [TLS] PR#448: CertificateStatus to extension

[Eric Rescorla <[e-mail]>]

On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen <[e-mail]>
wrote:

> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla <[e-mail]> wrote:
>
> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen <[e-mail]>
>> wrote:
>>
>> Hi,
>>>
>>>
>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <[e-mail]> 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
>