- From: Ben Schwartz <bemasc@google.com>
- Date: Tue, 29 May 2018 11:52:19 -0400
- To: hurtta-ietf@elmme-mailer.org
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mike Bishop <mbishop@evequefou.be>
- Message-ID: <CAHbrMsBo_FkpGBt5i3_3zem8brvwj4RkLOmkvxv9f_PnrD4jKQ@mail.gmail.com>
On Tue, May 29, 2018 at 11:44 AM Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote: > > I may have missed something, but is this consistent ? > > 3.3. Omitting SNI > https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02#section-3.3 > > | Suppose a client has received the following Alt-Svc entry for > | sensitive.example.com in the past: > | > | h2="alternative.example.com:443";ma=2635200;persist=true;sni="" > > <...> > > | If the supplied certificate does not cover sensitive.example.com, or > | is not valid, the client will terminate the connection. > > However > > 2. The "sni" Alt-Svc Extension > https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02#section-2 > > says > > | If the certificate is not valid for the origin's hostname, the client > | MUST NOT make requests to any origin corresponding to this > | certificate. In this case, the client SHOULD send a > | "CERTIFICATE_REQUEST" frame including an SNI extension indicating the > | origin which published the alternative service immediately upon > | connecting. > > Should client send "CERTIFICATE_REQUEST" frame for sensitive.example.com > if supplied certificate was valid for alternative.example.com. > Yes, this is an error in the example text. Thanks for the close reading! This should be easy to fix. Situtation is different if there was no sni="" at all. > > Or what I have missed? > > > / Kari Hurtta > >
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 29 May 2018 15:52:57 UTC