On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > Hi Yaron, > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > As far as I see it, there are three options: > > a) Change the document to UPDATE RFC 8446 > This feels like a heavyweight option and may complicate things since it > will mean that SNI is allowed but undefined for CertificateVerify in the > TLS handshake. > > b) Ask for a new extension point for SNI sent in a client-generated > authenticator request. > This has the downside of not scaling to future client hello extensions that > could be useful in exported authenticator requests -- it forces the > definition of a new code point for each new extension. > > c) Explicitly state that the CertificateRequest-like construction in > client-generated exported authenticator requests is a new type of message > (analogous to a ClientHello) and clarify the rules about which extensions > can be used when it is client-generated (specifically, say that any > extension supported in CH is allowed) > This is my preferred solution.
Just to check: this would be adding a new possible value for the "TLS 1.3" column at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 ? Thanks, Ben > I'm interested to hear what the working group thinks, and I'll happily > present the options at IETF 106 if there's time. > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
