On Friday, 21 April 2017 11:02:01 UTC+1, Gervase Markham wrote: > This is all a bit inchoate :-) Can you give me any idea at all of what > such a policy would look like? Requiring OV is not an option IMO.
Yes, it's inchoate, if I had a fully filled out policy in mind here I'd be proposing that policy, rather than expressing my concern that just removing this from the problematic list isn't solving a real problem. I have no interest in requiring OV for wildcards. The two things have nothing to do with each other, so that wouldn't make any sense. Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for verifying that the applicant controls the entire domain and thus *.example.com, whereas say 3.2.2.4.6 proves only that the applicant controls a web server, it seems quite likely they have neither the legal authority nor the practical ability to control servers with other names in that domain. I can see arguments either way for 3.2.2.4.4, depending on how well email happens to be administrated in a particular organisation. That adds up to an opportunity for someone to get a nasty surprise, one rogue employee at a cheap shared host can turn their ability to pass 3.2.2.4.6 for a brochureware site on www.example.com into a working *.example.com wildcard that can MitM SMTP, HTTPS-based APIs, VPNs, any sort of TLS traffic at all into any name in example.com. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
