Re: [websec] I-D Action: draft-nir-websec-extended-origin-00.txt

["Manger, James H" <[e-mail]>]

> 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