I'm not sure I underestand the use case. I'm hoping that they can clarify more.
That is, it would seem valuable as part of the technical constraint exercise to ensure the EKUs are restsricted. This is particularly true due to how nameConstraints work - they are blacklists (effectively), rather than whitelists, which means that combined with EKUs, they can be used for unconstrained purposes. Similar to the discussions regarding nameConstraints and name types, this has the effect of discouraging the introduction of new EKUs, as such intermediates would be unconstrained for these potential new and novel EKU use cases. On Mon, Apr 23, 2018 at 3:42 PM, Wayne Thayer via dev-security-policy < [email protected]> wrote: > On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy < > [email protected]> wrote: > > > 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. > > > > Thank you for the suggestion. It seems reasonable to me. If no one objects, > I will move the proposed language to section 5.3.2 so that it applies only > to unconstrained intermediates. > > - Wayne > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
