On Tuesday, 4 October 2016 12:21:47 UTC+1, Rob Stradling wrote: > When we are required (by CABForum and/or root program requirements) to > do <thing>, we will of course undertake to do <thing>. > > There are lots of <thing>s that we are already required to do. We > haven't tended to issue a separate announcement for each <thing> just to > say that we do it!
I don't want to single out Comodo in particular, but you're the example we have. It feels to me, even during CA application processes here on m.d.s.policy as if the <thing>s are most often seen as bureaucratic red tape that gets in the way of your job, rather than, from my point of view as a relying party, as the bare minimum low bar a CA should expect to sail over in your day-to-day operations. The CA/B BRs didn't previously explicitly say "You can treat control of www.example.com as proof of control over example.com" and they don't (after Ballot 169) now say "You can't treat control of www.example.com as proof of control over example.com". It was obvious before that you shouldn't do this, it's still obvious now, and it will remain obvious in March 2017. Comodo's special "rule" that they've decided allows them to do this exists only in some unseen Comodo documentation. It's not in the Baseline Requirements, it's not in Comodo's Certificate Practice Statement, how should any Relying Party know about this rule? Suppose I, as a relying party see a certificate issued by Comodo for example.net - how am I supposed to guess that this really means Comodo saw only proof of control for www.example.net ? What, outside of Comodo's own judgement, makes the Comodo rule OK, while prohibiting a rule that says if you control two-words.example you must be entitled to two.words.example as well if that exists ? That's why I proposed Mozilla might like to write this to CA/B or in a group CA communication, because I would be astonished if WoSign and Comodo are the only CAs to have such special "rules" that defeat the purpose of the validation step, or if this is the only such "rule" in use today. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
