Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop <[e-mail]>]

Ah, I was seeing the lower-case version in Appendix A from a quick search.  Yes, that one is upper-case.

Still, that seems simple enough to handle in whatever discussion of how resumption affects this.  If they remain in effect across a resumption, any name in that set could reasonably be valid; if not, then only the name on the certificate is originally valid.

>From an HTTP layer, we see this as analogous to a certificate with multiple SANs present -- if the original connection asked for one name on the cert, but a resumption asked for a different SAN, is resumption permitted?  This seems to suggest that it's not, and to strictly obey that requires that the server remember which of several hostnames tied to that certificate was actually used to establish the connection.

-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 
Sent: Thursday, July 21, 2016 6:42 PM
To: Mike Bishop <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop wrote:
>
> I assume you're referring to Section 3, SNI's ServerNameList MUST NOT 
> contain more than one name of a given type?
>
> Or are you referring to the (lower-case) must not resume if SNI and 
> the certificate used in the resumed session differ?

My (online) copy of rfc6066 has a (fully reasonable) upper-case MUST NOT.


Last paragraph on page 7, rfc6066 (TLS extension server_name_indication)

https://tools.ietf.org/html/rfc6066#page-7

   A server that implements this extension MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session.


-Martin