I think you should consider an an exception Issuing CAs including Name Constraints. This would keep allowing root signing services for corporate CAs without forcing multiple CAs.
El viernes, 20 de abril de 2018, 23:03:17 (UTC+2), Wayne Thayer escribió: > On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy < > [email protected]> wrote: > > > On 17/04/2018 20:24, Wayne Thayer wrote: > > > >> This proposal is to require intermediate certificates to be dedicated to > >> specific purposes by EKU. Beginning at some future date, all newly created > >> intermediate certificates containing either the id-kp-serverAuth or > >> id-kp-emailProtection EKUs would be required to contain only a single EKU. > >> > >> Arguments for this requirement are that it reduces risk of an incident in > >> which one type of certificate affecting another type, and it could allow > >> some policies to be restricted to specific types of certificates. > >> > >> > > One case that needs to be considered is specifying a set of closely > > related EKUs, which are desirable to include in the same end entity > > certificate. A typical combination would be emailProtection and > > clientAuth, for the same identity in the EE cert. > > > > I believe the language I proposed takes care of this: > https://github.com/mozilla/pkipolicy/commit/1ccf31557932ede045f3c2d7bcdac533c5176f18 > > If there are no additional comments, I will consider this issue to be > resolved and will include this change in version 2.6 of the policy. > > - Wayne _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
