- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 10 Jul 2018 06:11:17 +1000
- To: Benjamin Schwartz <bemasc@google.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Either certificates are available after resumption or not. 0-RTT is just resumption. Of a particular kind, but it's still resumption. It might be possible to use 0-RTT to proactively probe for secondary certificates while retaining this restriction, but if you want this, I think that we need to discuss the reasons we opted not to allow those secondary certificates to transfer to a resumed connection. On Tue, Jul 10, 2018 at 1:32 AM Ben Schwartz <bemasc@google.com> wrote: > > Hi HTTP, > > Section 5.1 of the Secondary Certificate Authentication draft [1] says: > Clients MUST NOT consider > previous secondary certificates to be validated after TLS session > resumption. However, clients MAY proactively query for previously- > presented secondary certificates. > > I think we should amend this to clarify the status of 0-RTT. Here's a proposed change. > Clients MUST NOT consider > previous secondary certificates to be validated after TLS session > resumption. However, clients MAY treat previous secondary certificates as validated > when sending TLS-1.3 0-RTT data, and MAY proactively query for previously- > presented secondary certificates in the 0-RTT data or after session resumption. > > This is my attempt to clarify that 0-RTT data retains the security scope of the session that is being resumed, which is the union of the validated certificates for that session. > > --Ben > > [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-02#section-5.1
Received on Monday, 9 July 2018 20:11:49 UTC