Subject: [quicwg/base-drafts] Move authority discussion earlier (#4419)

From: Mike Bishop <[email-masked]>
Date: Wed, 02 Dec 2020 13:12:51 -0800

Fixes #4362.  The definition of how you determine a certificate matches an origin isn&#39;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&#39;d appreciate suggestions for greater clarity without losing the specifics.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4419

-- Commit Summary --

  * Move authority discussion earlier

-- File Changes --

    M draft-ietf-quic-http.md (38)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4419.patch
https://github.com/quicwg/base-drafts/pull/4419.diff

-- 
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/4419

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 02 Dec 2020 19:54:54 -0800

@janaiyengar approved this pull request.

This LGTM. It's clear.

-- 
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/4419#pullrequestreview-543423670

---

From: ianswett <[email-masked]>
Date: Sat, 05 Dec 2020 08:39:19 -0800

@ianswett approved this pull request.

-- 
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/4419#pullrequestreview-545599827

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Dec 2020 02:34:50 -0800

@martinthomson approved this pull request.

Seems fine.

>  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.
+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.  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.  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.

Breaking up this mega-paragraph might help some.

> @@ -316,10 +316,17 @@ authoritative server for an HTTP URL is discussed in Section 4.3 of
 
 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.
+component of the URL.  If a server presents a certificate and proof that it

Split here (and maybe "valid certificate").

> @@ -316,10 +316,17 @@ authoritative server for an HTTP URL is discussed in Section 4.3 of
 
 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.
+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.  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.  If the hostname or address is not

Maybe split here too.

-- 
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/4419#pullrequestreview-546018652

---

From: Mike Bishop <[email-masked]>
Date: Tue, 08 Dec 2020 07:37:10 -0800

@MikeBishop pushed 1 commit.

1c46b468d220ea0e6396ebee67d87521ad390b70  Break up paragraph as suggested

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4419/files/f6bde68f13e28e025cc82c44cc27ba3c0eb7e43c..1c46b468d220ea0e6396ebee67d87521ad390b70

---

From: Mike Bishop <[email-masked]>
Date: Tue, 08 Dec 2020 15:28:26 -0800

Merged #4419 into master.

-- 
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/4419#event-4087221202