Subject: Mark's coalescing proposal

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Jan 2014 10:23:10 -0800

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.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 31 Jan 2014 10:49:52 -0800

> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Jan 2014 11:02:07 -0800

> for each origin's hostname.    The considerations in RFC 6125 for

This implies exclusivity for 6125, which is a trap I wanted to avoid.
Otherwise, I'm good with that.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 1 Feb 2014 15:25:46 +1100

As I was writing this, I was wondering whether the MAY ought to be a SHOULD; i.e., when possible, clients are encouraged to reuse connections. 

Thoughts?

--
Mark Nottingham   http://www.mnot.net/