On Fri, Apr 21, 2017 at 04:09:57AM -0700, Nick Lamb via dev-security-policy wrote: > 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.
Didn't a CA get caught fairly recently issuing certs with sAN:example.com when the validation was for www.example.com, and got a stern talking to as a result? I vaguely recall something about that, but not with enough detail to trawl the archives looking for it. At any rate, I don't believe the BRs permit such an issuance. At most, if someone demonstrated control of www.example.com they would be able to get a cert for sAN:*.www.example.com (which is still not great, but not quite the complete disaster getting one for sAN:*.example.com would be). If your read of the BRs indicates otherwise, I'd be interested in your reasoning. That being said, I certainly agree that demonstrating control of a website is not *nearly* the same thing as demonstrating control over DNS, and I wouldn't be a sad panda if demonstrating control over a website didn't permit wildcard issuance. Perhaps Mozilla policy (or the BRs) could differentiate between "wildcard-permitted" vs "literal FQDN only" validation methods? That would, presumably, be applied independent of DV/OV validation grade. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
