On Mon, May 2, 2016 at 3:01 PM, Yngve N. Pettersen <yn...@spec-work.net>
wrote:
> On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla <e...@rtfm.com> wrote:
>
> Sorry, I'm responding to Yngve's "MUST" suggestion.
>>
>> I think what would be reasonable would be:
>>
>> - clients MAY send either {(v1,v2), (v2), or ()}
>> - servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the
>> client sent {(v1,v2), (v2)}
>>
>
> Which is what I suggested; note that I said "clients that support
> certificate status", with "support" meaning "enabled".
My mistake for misreading you. Sounds like we're on the same page. I'll
modify
as you suggest.
-Ekr
>
> That I could live with...
>> -Ekr
>>
>>
>> On Mon, May 2, 2016 at 2:45 PM, Watson Ladd <watsonbl...@gmail.com>
>> wrote:
>>
>> On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>> >
>>> >
>>> > 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?
>>>
>>> Wouldn't the client then not send the certificate status extension,
>>> which the proposed text seems to include as an option? Or am I missing
>>> something?
>>>
>>> >
>>> > -Ekr
>>> >
>>> >>
>>> >>
>>> >> --
>>> >> Sincerely,
>>> >> Yngve N. Pettersen
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > TLS mailing list
>>> > TLS@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/tls
>>> >
>>>
>>>
>>>
>>> --
>>> "Man is born free, but everywhere he is in chains".
>>> --Rousseau.
>>>
>>>
>
> --
> Sincerely,
> Yngve N. Pettersen
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
