[TLS] RFC 4366 server name indication

[Peter Williams <home_pw@xxxxxxx>]

Summary:- Sanity check sought when using a std server name indication type of host_name, for non classical internet 
environments. Do I use properly use host_name, or create a new indication type?
 
RC4366 specifes  that Server name indication allows one to indicate a virtual server name. host_name in the only std type.
 
So lets assume an "outer" TLS Connection exists between the parties C->S, where the client nic 
for TCP is in fact one or many vlans/pseudo-nics in client's bridge/stack. Lets say, the outer TLS Connection 
once negotiated also gets its own vlan#base1, with a psuedo-Mac address in the local stack. Perhaps that
MAC even participates in ARP & binds to a DNS record using DHCP.
 
For whatever reason, the server party decides to create an "inner" TLS Connection , as is its right. It thus 
issues an (Extended)  client hello etc transferring this over the application_data of the outer connection, using 
tunneling techniques using some encapsulation standard (ethernet.v2 say)
 
In terms of server name extension rules as I read them, the outer tunnel's protocol engine is now the 
"application", which gets to "interpret" the host_name sent in the client hello. 
 
Lets say the wireless stack is bridging/trunking at layer 2 various vlans, each if which are adjacent to
vlan#base1 with local ids {vlan#base1#1, vlan#base1#2, vlan#base1#3). 
 
Given the application ( i.e. the TLS-Connection-capable bridge behind vlan.base#1) interprets the name, am 
I being consistent with the proposal if I indicate values such as  "1.base1.vlan.wirelesslan.isp.com"?

---

Get free, personalized online radio with MSN Radio powered by Pandora. Try it!
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls