2012/2/26 Yoav Nir <y...@checkpoint.com>: > > On Feb 24, 2012, at 1:35 AM, Manger, James H wrote: > >> The scheme that you propose (a.sslvpn.example.com, 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. > > > I checked the products of some of our competitors, and they seem to also > offer both options. IMHO the cost and complexity of deployment for the user > are valid considerations for engineering. > > In this case, the cost is incurred not because of technical necessity but > because of the way browsers work with commercial CAs - that wildcard > certificates are more expensive, and multiple certificates are also more > expensive. Regardless, the cost and complexity are real. > > I hope to have a -01 draft ready in time, which will address your other > point. > > Thanks again for the review
Frankly, your proposal is very unlikely to be implemented. The engineering effort required to implement is quite large, if it's even possible. Consider, for example, that beyond just changing the browser, you'd also need to change Flash, Java, and every other plug-in that implements the same-origin policy. In addition to that complexity, there are many assumptions in browsers and in the software that surrounds browsers that origins are determined by URL. Your proposal breaks that assumption. Adam _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
