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
