Re: h2 requirements on authoritative responses

On 2 September 2014 18:40, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> IMO this KEEP part needs to mention port remaining the same as well.
> That will avoid interop problems with port-based load balancer gateways.

With respect to authority, HTTP/1.1 doesn't rely on that.  You should
probably direct comments of this nature to the alternative services
draft instead.

>> For <spanx style="verb">https</spanx> resources, connection reuse
>> additionally depends on having a certificate that is valid for the
>> host in the URI. OLD: -           That is the use of -
>> server certificate with multiple <spanx
>> style="verb">subjectAltName</spanx> attributes, -            or
>> names with wildcards.  For example, a certificate with a <spanx -
>> style="verb">subjectAltName</spanx> of <spanx
>> style="verb">*.example.com</spanx> might -            permit the
>> use of the same connection for <spanx
>> style="verb">a.example.com</spanx> and -            <spanx
>> style="verb">b.example.com</spanx>. NEW: +           That is the
>> use of +            on having a certificate that is valid for the
>> host in the URI.  A server might offer a +            certificate
>> with multiple <spanx style="verb">subjectAltName</spanx>
>> attributes, or +            names with wildcards, one of which is
>> valid for the authority in the URI.  For example, +            a
>> certificate with a <spanx style="verb">subjectAltName</spanx> of
>> <spanx +            style="verb">*.example.com</spanx> might permit
>> the use of the same connection for +            requests to URIs
>> starting with <spanx style="verb">https://a.example.com/</spanx>
>> and +            <spanx
>> style="verb">https://b.example.com/</spanx>.
>
> Could also mention that DANE provides and alternative method of
> receiving certificates and RFC6698 section 5 explicitly documents as
> being possible to have multiple TLSA records with different contents
> for rollover and combination cases.
>
> ie. we need to be careful that we do not make h2 incompatible with
> multi-certificate origins any more than with wildcard or
> multi-subjectAltName origins.

The use of subjectAltName is intentionally exemplary for that reason.
The normative statements should still apply to DANE and other related
functions like pinning.  But I think that it's important to cover the
most common cases in the example to help avoid confusion where it
matters most.  (That is, until DANE is more commonplace; I've not yet
heard of a single use of it on the web.)

Received on Wednesday, 3 September 2014 18:45:15 UTC