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

On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla <ekr@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".

> That I could live with...
> -Ekr
>
>
> On Mon, May 2, 2016 at 2:45 PM, Watson Ladd <watsonbladd@gmail.com>  
> wrote:
>
>> On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> >
>> > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen  
>> <yngve@spec-work.net>
>> > wrote:
>> >>
>> >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla <ekr@rtfm.com>  
>> wrote:
>> >>
>> >>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen <
>> yngve@spec-work.net>
>> >>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>>
>> >>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@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