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)}
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.
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
