Re: [quicwg/base-drafts] Authoritative access in HTTP/3 (#3558)

[ekr <[e-mail]>]

@ekr commented on this pull request.



> @@ -360,30 +399,20 @@ example, when a user navigates away from a particular web page) or until the
 server closes the connection.
 
 Once a connection exists to a server endpoint, this connection MAY be reused for
-requests with multiple different URI authority components.  The client MAY send
-any requests for which the client considers the server authoritative.
-
-An authoritative HTTP/3 endpoint is typically discovered because the client has
-received an Alt-Svc record from the request's origin which nominates the
-endpoint as a valid HTTP Alternative Service for that origin.  As required by
-{{!RFC7838}}, clients MUST check that the nominated server can present a valid
-certificate for the origin before considering it authoritative. Clients MUST NOT
-assume that an HTTP/3 endpoint is authoritative for other origins without an
-explicit signal.
+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

I fear you need to cite 2818 -- though 6125 is in fact due for revision and that should incorporate 2818.

> -any requests for which the client considers the server authoritative.
-
-An authoritative HTTP/3 endpoint is typically discovered because the client has
-received an Alt-Svc record from the request's origin which nominates the
-endpoint as a valid HTTP Alternative Service for that origin.  As required by
-{{!RFC7838}}, clients MUST check that the nominated server can present a valid
-certificate for the origin before considering it authoritative. Clients MUST NOT
-assume that an HTTP/3 endpoint is authoritative for other origins without an
-explicit signal.
+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.

Not to be nitpicky but you probably should say that if it doesn't verify it, it must fail.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3558#pullrequestreview-395727380