Draft: draft-ietf-quic-http

Commentary: The definition of how you determine a certificate matches an origin is n't specific to reuse , so it belongs in the description of establishing a connection . 3.4 now just says that the certificate needs to also be authoritative for any other origins you want to reuse the connection for . The issue also suggested making this easier to understand , so I 'd appreciate suggestions for greater clarity without losing the specifics . 
   wrote : The only problem that I have is that the authentication model for QUIC - HTTP is not explicitly spelled out . The only discussion is in section 3.4 Connection Reuse , and although that section may be technically correct , I find it hard to understand . 
 For server authentication , which I think is what you 're getting at here , 3.2 also mentions the concept of establishing authority , but does n't go into much detail . I suspect the specifics of comparing a certificate should move to 3.2 . I 'd appreciate suggestions for making it easier to understand . 
 Seems fine . This LGTM . It 's clear .
Paragraph (version A):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URL.  If a server
presents a certificate and proof that it controls the corresponding
private key, then a client will accept a secured TLS session with
that server as being authoritative for all origins with the "https"
scheme and a host identified in the certificate.
Paragraph (version B):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URL.
Paragraph (version B):
If a server presents a valid certificate and proof that it controls
the corresponding private key, then a client will accept a secured
TLS session with that server as being authoritative for all origins
with the "https" scheme and a host identified in the certificate.
The host must be listed either as the CN field of the certificate
subject or as a dNSName in the subjectAltName field of the
certificate; see RFC6125.  For a host that is an IP address, the
client MUST verify that the address appears as an iPAddress in the
subjectAltName field of the certificate.
Paragraph (version B):
If the hostname or address is not present in the certificate, the
client MUST NOT consider the server authoritative for origins
containing that hostname or address.  See Section 4.3 of SEMANTICS
for more detail on authoritative access.
Paragraph (version A):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
In general, a server is considered authoritative for all URIs with
the "https" scheme for which the hostname in the URI is present in
the authenticated certificate provided by the server, either as the
CN field of the certificate subject or as a dNSName in the
subjectAltName field of the certificate; see RFC6125.  For a host
that is an IP address, the client MUST verify that the address
appears as an iPAddress in the subjectAltName field of the
certificate.  If the hostname or address is not present in the
certificate, the client MUST NOT consider the server authoritative
for origins containing that hostname or address.  See Section 4.3 of
SEMANTICS for more detail on authoritative access.
Paragraph (version A):
Clients SHOULD NOT open more than one HTTP/3 connection to a given
host and port pair, where the host is derived from a URI, a selected
alternative service (ALTSVC), or a configured proxy.  A client MAY
open multiple HTTP/3 connections to the same IP address and UDP port
using different transport or TLS configurations but SHOULD avoid
creating multiple connections with the same configuration.
Paragraph (version B):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
Clients SHOULD NOT open more than one HTTP/3 connection to a given
host and port pair, where the host is derived from a URI, a selected
alternative service (ALTSVC), or a configured proxy.  A client MAY
open multiple HTTP/3 connections to the same IP address and UDP port
using different transport or TLS configurations but SHOULD avoid
creating multiple connections with the same configuration.