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:m...@sap.com] Sent: Thursday, July 21, 2016 6:42 PM To: Mike Bishop <michael.bis...@microsoft.com> Cc: m...@sap.com; tls@ietf.org 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
