I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain more than one name of a given type? Technically, we're not violating that, since we're not changing SNI. The client requests a single identity in the TLS handshake, which the server provides. Additional identities can be demonstrated later, regardless of where.
Or are you referring to the (lower-case) must not resume if SNI and the certificate used in the resumed session differ? For HTTP, we're leaving resumption out of the picture, requiring that any secondary certificates be proved anew for each connection. You're certainly correct that if the logic were moved to TLS, the semantics of resumption would have to be defined. That may be a solid argument on why it should remain at the application layer. -----Original Message----- From: Martin Rex [mailto:m...@sap.com] Sent: Thursday, July 21, 2016 5:57 PM To: Mike Bishop <michael.bis...@microsoft.com> Cc: tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Mike Bishop wrote: > > That means we now have a proposal for carrying both client and server > certificates above TLS, found at > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs. > > We have also discussed that it might be preferable to pull part of > this capability back into TLS, You are facing a MUST NOT in rfc6066 for this particularly bad idea. I'm currently wondering what kind of (weird) TLS session caching strategy would actually allow you to create such client or server behaviour. You're definitely in severe conflict with the "principle of least surprise" in respect to deterministic behaviour of your TLS clients and TLS servers. -Martin
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
