新的gTLDs来了。浏览器将如何处理cookie、SOP和证书？

Question

考虑到安全“区域”根据TLD、新的TLS将如何处理？而变化

例如:浏览器可能允许共享cookie和SSL证书，以及通配符证书。

• company.com (两层深)
• company.co.uk (三层深)
• local (一层深度)

然而，cookies、跨站点请求等都被浏览器禁止，因为它们对to的应用范围太广。

• *.com (两层深)
• *.co.uk (三层深)

问题：

1. 对于新提议的TLD，通配符证书和SOP的新安全范围将是什么？这是在哪里发表的？
2. 是否期望SOP和通配符证书的范围相等？
3. 除了SSL证书和SOP之外，还有其他适用于cookie、跨站点请求、javascript、本地存储、Flash等的问题吗？

更新：

由于每个CA在颁发证书时都不可能支持相同的策略，而且SOP实际上依赖于所有获得共识的浏览器，那么浏览器将如何处理这个问题呢？

Answer 1

它和现在并没有什么本质上的不同。实际上，应该由CA来决定他们的策略，以确保他们不会比请求证书控制的实体颁发更广泛的证书。它将尝试将通配符与证书中的域名称匹配，以查看它是否匹配。他们必须根据每个区域以及如何在该区域分配域名来确定这一点。

Answer 2

我的理解是通配符证书只支持单一级别的子域匹配。。也就是说，您不能有像*.*.com或*.*.stackexchange.com这样的匹配。我相信您在技术上可以拥有*.com这样的通配符证书，尽管没有任何证书颁发这样的证书(而且它们只匹配google.com，而不匹配www.google.com)。

当然，RFC-6125似乎指出通配符在通配符证书中的允许位置在浏览器中是不明确和一致定义的。但是，它给出了关于如何做这件事的明确规则：

如果客户端将引用标识符与DNS域名部分包含通配符“*”的标识符匹配，则适用下列规则：

1. 客户端不应尝试匹配所呈现的标识符，其中通配符包含左边最标签以外的标签(例如，不匹配bar.*.example.net)。
2. 如果通配符是当前标识符中最左边标签的唯一字符，则客户端不应与引用标识符的最左边标签进行比较(例如，*.example.com将匹配foo.example.com，而不匹配bar.foo.example.com或example.com)。
3. 客户端可以匹配所呈现的标识符，其中通配符不是标签的唯一字符(例如，baz*.example.net和_baz.example.net以及b_z.example.net将分别用于匹配baz1.example.net和foobaz.example.net以及buzz.example.net )。但是，客户端不应尝试匹配一个已呈现的标识符，其中通配符嵌入到国际化域名的A标签或U标签IDNA-DEFS中。

Answer 3

使用公共后缀列表相对容易，因为这个列表不会经常更改。

这是一个列表的所有顶级和二级域名，人们可以购买域名。因此，浏览器只需匹配此列表中相应条目之外的一个级别即可确定其应用作来源的域名。

火狐为相当一段时间提供了支持，并且Mozilla向任何想要使用它的人开放了这个列表。