> The scheme that you propose > (a.sslvpn.example.com<http://a.sslvpn.example.com>, > b.sslvpn.example.com<http://b.sslvpn.example.com>, etc.) really does work. In > fact, the product that my company makes offers this as an option.
Good to hear. > Sadly, our customers don't like it, hence the other option. Using multiple > FQDNs requires them to either buy multiple certificates, or a wildcard > certificate, both options are more expensive. Additionally this requires them > to add multiple DNS records, which for some reason they find cumbersome. Not sure that that is a good enough reason to introduce extended origins. >> 2] I think it would be better to serialize an extended-origin as an >> additional sub-domain, not a fragment. The sub-domain could have a prefix so >> it cannot (or is highly unlikely to) clash with a real sub-domain. Example: >> → GET https://sslvpn.example.com/xyz >> ← Extended-Origin: asdhgasghd >> → Origin: https://xb--asdhgasghd.sslvpn.example.com > 2) I don't see that it makes much of a difference. I can do it either way. > Can you explain what is the advantage of this over the pseudo-fragment format? No big advantage. A pseudo-sub-domain hints at the better approach (using actual sub-domains). It matches the existing syntax (which probably simplifies some code). -- James Manger
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
