W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Mark's coalescing proposal

From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 31 Jan 2014 10:49:52 -0800
Message-ID: <CA+9kkMAVOPKSuUsS8d4X5H8otEGJRbo_GG1Q-dEtBBgTbR6HOA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC