On Thursday, September 8, 2016 at 9:00:15 AM UTC-7, Stephen Schrauger wrote: > It proves you control the web server that runs under the domain. Which is > more or less all that you need to prove, since a TLS certificate is designed > for web security. > > If you don't control DNS, but you do control the web server, you essentially > control the domain as far as web browsing goes, and thus you should be able > to acquire a certificate for that domain. Which is probably why it is > included in the Baseline Requirements as an acceptable validation method.
Just a slight correction: TLS is not only used for HTTPS. We certainly know it's used for other protocols - such as IMAPS and POPS - and we know that a given service may be colocated with other services on the same host. At present, a TLS certificate doesn't distinguish the intended or authorized services (there's a SRVName ballot circulating in the Forum that could resolve this), but I think recent events have shown the issues where control of a single service might be elevated to presumptive control of the domain, which can and, in the case of mail providers, frequently is, inaccurate. That is, consider the example of StartCom and WoSign including 'base domains' within the certificate (both authorized and unauthorized), where a certificate for 'mail.example.com' would include a SAN of 'example.com'. Just because I can demonstrate operational control of 'mail.example.com' (for example, if mail.example.com was actually run by GMail) doesn't imply authorization of 'example.com'. This is, perhaps, a convoluted example, but it's meant to highlight why, for the methods of control that don't directly rely upon DNS, the intended authorization scope in the new validation methods is limited to the FQDN of that host (e.g. the cert could only contain mail.example.com), which was already a requirement in previous versions, but made more explicit in the latest versions. However, control of the web portion of mail.example.com doesn't imply control of the email portion, and that's where the SRVName ballot fits. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
