On Monday, 13 February 2017 12:22:34 UTC, Gervase Markham wrote: > This is why the CAB Forum has been working for > some time on carefully documenting best practice in domain validation, > and passed ballot 169 to incorporate them into the Baseline > Requirements. The problem experienced by GoDaddy is one explicitly > foreseen by the drafters of those best-practice validation methods.
I don't think Ballot 169 represents best practices per se. Instead as with the rest of the Baseline Requirements what we have here are _minimums_, we aren't asking that CAs should do no more than what is described, but that they must do at least what is described. For example, the weakness with bulk-hosted HTTPS I mentioned and which led to changes in policy at Let's Encrypt prior to it going live is not covered in Ballot 169. A good CA should ensure that if they offer 3.2.2.4.6 they handle that issue, even though it's not listed in Ballot 169. Anyway, I have a nitpick for your GoDaddy remediation plan. I think in item (1) it's not clear that it's fine for a CA to choose to implement many or even all ten methods, and even for them to have other methods - what's important is that for any particular name validated their process ensures at least one of the ten Ballot 169 methods was used. For example, suppose a CA has a system which lets them see whether a web-based certificate request comes from an IP address in the same LIR allocation as an IP address associated with the requested name. Although it would be far from perfect this system might be quite good for detecting some attempts at fraud. We don't want to discourage them from having it. Nevertheless it is not a Ballot 169 method and its use alone to validate a name is not acceptable. I do not fear that GoDaddy might misunderstand this, but since an audit is requested I would want it to be clear to auditors what we want them looking for. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
