Re: Is it allowed the suspension of Issuing CAs?
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
Re: Is it allowed the suspension of Issuing CAs?
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. We, for example, created a new Root to have a purely ECC hierarchy... But having in mind the possibility to issue client-authentication certificates for IoT projects where is not desirable having to install a Root in the OS, and where it could be interesting to support suspension during the device life-cycle. You can guess that there's a big impact if disallowing suspension in the whole hierarchy because we could eventually also issue TLS certificates. In any case, clear regulation is always the best thing to have, even if the result is not convenient for all... I personally don't like working in grey zones that are prone to interpretation and later be "hammered" if someone has a different criteria. Well... I guess my question wasn't so silly after all :) El martes, 5 de febrero de 2019, 0:06:36 (UTC+1), Ryan Sleevi escribió: > I can't speak for the BRs, but I think root programs have considered this, > and have discouraged it in the absence of strong technically-enforcable > controls (e.g. being technically prevented from TLS certificates). Some > root programs have gone to a further extreme, and suggested that no > divergence is permitted in the CP/CPS (e.g. separate "root" per use case). > > While they may operate on similar setups and configurations, given the risk > to clients, I think CAs should take steps to segment their hierarchies on a > real and technical level (e.g. no cross-pollination of keys and > certificates). > > On Mon, Feb 4, 2019 at 5:38 PM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Thanks Wayne. > > > > Definitely, these things, the less left to interpretation, the better... I > > personally think BR should consider the fact that under a Root there can be > > different certificate policies, because as you say the strict reading of BR > > implies that suspension is forbidden also for certificates out of the scope > > of BR. > > > > Best, > > Pedro > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is it allowed the suspension of Issuing CAs?
I can't speak for the BRs, but I think root programs have considered this, and have discouraged it in the absence of strong technically-enforcable controls (e.g. being technically prevented from TLS certificates). Some root programs have gone to a further extreme, and suggested that no divergence is permitted in the CP/CPS (e.g. separate "root" per use case). While they may operate on similar setups and configurations, given the risk to clients, I think CAs should take steps to segment their hierarchies on a real and technical level (e.g. no cross-pollination of keys and certificates). On Mon, Feb 4, 2019 at 5:38 PM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thanks Wayne. > > Definitely, these things, the less left to interpretation, the better... I > personally think BR should consider the fact that under a Root there can be > different certificate policies, because as you say the strict reading of BR > implies that suspension is forbidden also for certificates out of the scope > of BR. > > Best, > Pedro > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is it allowed the suspension of Issuing CAs?
Thanks Wayne. Definitely, these things, the less left to interpretation, the better... I personally think BR should consider the fact that under a Root there can be different certificate policies, because as you say the strict reading of BR implies that suspension is forbidden also for certificates out of the scope of BR. Best, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is it allowed the suspension of Issuing CAs?
The BRs define Repository as: Repository: An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response. I see no evidence to support the idea that the scope of the term Repository in section 4.9.13 is limited to issuing CAs. Therefore, a strict reading of the BRs is that any BR-compliant root must not suspend any intermediate or end-entity certificate in the hierarchy. I can understand how this causes problems for CAs that rely on certificate suspension outside of TLS, and I have not been enforcing this strict interpretation, but I do think the BRs should be updated to solve this problem. - Wayne On Mon, Feb 4, 2019 at 10:07 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Well... my understanding is that “Repository” refers there to the one of > the Issuing CA, not the whole repository under a Root, because a Root could > have subordinates that don’t issue SSL, and for which suspension could be > allowed. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
