W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

3.3. Omitting SNI | FW: New Version Notification for draft-bishop-httpbis-sni-altsvc-02.txt

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Tue, 29 May 2018 18:34:34 +0300 (EEST)
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: Mike Bishop <mbishop@evequefou.be>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Message-Id: <20180529153439.A00BAC4E35@welho-filter3.welho.com>

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.

Situtation is different if there was no sni="" at all.

Or what I have missed?


/ Kari Hurtta
Received on Tuesday, 29 May 2018 15:35:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC