On Tue, Feb 5, 2019 at 3:56 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Understanding these arguments, I think it must considered that there are > practical implications for the CAs to have Roots dedicated to each > use-case. Having multiple Roots is neither encouraged nor well seen by some > Root programs. Also, for a CA, adding a new Root is not only relatively > onerous, but is specially impacting in time to market (at least 9 months to > have it in the Mozilla Program, if everything goes smooth), while > separating issuing CAs for each CP is much more easy... Actually just > checking the EKUs in the subscriber certificate should be also enough to > apply rules in most cases. > Note that the topic of whether or not subscriber EKUs was significantly discussed in the past, and is why the policy is/tries to be very clear that it applies to anything technically capable of SSL/TLS issuance, and not merely leaf certificates. Considering the impact that a compromised CA can have - for example, being able to issue arbitrary certificates - it's hopefully clear why this is a necessary condition. Further, given that subordinate certificates need to comply with the parent CA's policies, it naturally results in what I described; where if you want divergent policies, you need to separate out the hierarchies meaningfully and technically. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
