- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Fri, 31 Jan 2014 10:49:52 -0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
- Message-ID: <CA+9kkMAVOPKSuUsS8d4X5H8otEGJRbo_GG1Q-dEtBBgTbR6HOA@mail.gmail.com>
On Fri, Jan 31, 2014 at 10:23 AM, Martin Thomson <martin.thomson@gmail.com>wrote: > I think that this is mostly right: > > >>> > Partial proposal: insert after 9.1 Connection Management second paragraph: > > Clients MAY use a single connection for more than one origin when each > origin's hostname resolves to the same IP address, and they share the > same port. When an origin's scheme is "https", the server's > certificate MUST be valid for the origin's hostname to be used in this > fashion; this might be accomplished using a "wildcard certificate", > subjectAltName [RFC3280], or some other mechanism. > <<< > > However, 3280 is out of date. I wonder if 6125 is not a better > reference to use here. As in: > > When an origin's scheme is "https", the server MUST be authenticated, > either by validating the server certificate against the hostname in > the origin [RFC6125], or by some other mechanism. > > Honestly, I like Mark's text a little bit better, so I'd suggest: Clients MAY use a single connection for more than one origin when each origin's hostname resolves to the same IP address, and they share the same port. For "https" scheme origins, the server's certificate MUST be valid for each origin's hostname. The considerations in RFC 6125 for verification of identity apply. I think the pointer to 6125 is useful, but since it defers to the PKIX standards as authoritative for validation, I don't think it should be the reference for subjectAltName or other core PKIX concepts. (That's just following 6125's applicability statement). Just my 2 cents, Ted
Received on Friday, 31 January 2014 18:50:18 UTC