On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote: > There is some good news. The CA/Browser Forum has already addressed > this, even prior to the current discussions. Ballot 169 > (https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/) > revises 3.2.2.4 considerably.
I'm aware of Ballot 169 > Under the new rules, which should be in > effect as of 1 March 2017, validating www.<domain> will not be a valid > method of showing control of <domain>. The name is true for any valid > hostname under <domain>. The only note is that names in the form > _<something>.<domain> (that is starting with an underscore) can be > used to validate <domain>. I wish I shared your confidence. My expectation is that if we leave this as it is, in April 2017 subscribers will still be able to get a certificate issued using this lackadaisical validation, and the issuing CA will say they feel it's not "really" disobeying the rules, that it's just a "technicality" and anyway what's the harm, it's so much more convenient for their customers this way? Comodo's document never actually says that they're abolishing this "rule" as a result of Ballot 169. It lets you choose to draw that implication, by specifying that their current practices pre-date Ballot 169's changes, but it never says as much. Hence I think Mozilla's rep should take this to CA/B, or it should go in one of the bulk CA communications, to find out at least how widespread the crazy is and whether it's even consistent in how it works from one CA to the next. On https://community.letsencrypt.org/ more than once users who've previously had certificates from elsewhere have expressed confusion or dismay when they realise that Let's Encrypt doesn't automatically issue them a certificate for both www.example.com and example.com after they only asked for one of the two. So this practice has apparently been widespread enough for some subscribers to assume it's "just how it works" even though it was never actually permitted by the BRs... _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
