- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Tue, 16 Jun 2015 08:16:04 -0400
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNrEvqfr0hMkWAyfLtn1uyxz4+p-YNcABEOssEpnJ5eFUQ@mail.gmail.com>
On Tue, Jun 16, 2015 at 4:32 AM, Stefan Eissing < stefan.eissing@greenbytes.de> wrote: > > * Ch. 5.1 > "When it appears in a HTTP response from a strongly authenticated > alternative service..." > This means the certificate is valid for the alt-svc host that can be > different from the > host in the http:// url originally requested, right? > not in the way you mean. The point is that the alternate must authenticate for the origin to prove itself authoritative to serve the origin's resources. Now the actual certificate can be different (only one might be a wildcard, for example) - but the alternate's cert must cover the origin. > Example: > GET http://test.example.org/opportunistic > -> Alt-Svc: h2="h2.example.biz:81" > -> GET http://test.example.org/opportunistic via TLS+h2 connection to > h2.example.biz:81 > "strongly authenticated" meaning connection presents valid cert for > h2.example.biz, has acceptable cipher, etc. > it means that the cert presented by h2.example.biz:81 must be valid for test.example.org > * Given that the example above is correct, what protocol does > h2.example.biz:81 need to implement? > h2.. > Will it be something like RFC 7540, but ignoring the special security > requirements for TLS? Which parts would still apply to a server > implementing this? > > all parts of 7540 section 9.2 should still apply. > > hth
Received on Tuesday, 16 June 2015 12:16:35 UTC