With all my respects to the experts involved in this discussion, my statement is based in risk management, and I just think there's maybe no need to over-regulate name-constrained CAs, as this technique is already reducing the risks that those new rules intend to control.
Name Constraints, as used in practice, define a name span of "only allowed" DNS and Organization names, so it's not actually a blacklist, but an exclusive whitelist. We must also consider that even if not disclosed in the CCADB, when we "suffer" a Webtrust audit we are screened on the effective usage of name constraints in all issued CA Certificates, so an auditor won't accept a CA as "out of scope of the BR audit" if it's merely whitelisting certain names or merely blacklisting certain other names... but effectively limiting the activity of a CA to a closed set of names, which BTW are vetted prior to execute the CA ceremony. Therefore, my statement is made considering the corporate customers that want a root signing service for their own CA, sometimes linked to an Active Directory and aiming to fulfill the needs of the company for personal and server certificates in the domains they own or are authorized to use, with the benefits that bring using publicly trusted certificates. Enforcing EKU separation will imply having two or more different CAs in a single AD, which is not that easy to manage, and forces also the acquisition of multiple HSM or expensive network HSM. As an additional comment, and considering this certain trend to "over regulation", and clarifying that I perfectly understand the need to control commercial CAs, I must say that for me personally new rules like the enforcement of CT on a name constrained CA doesn't bring a clear value in terms of risk management, but just adding complexity for a CA which is only entitled to issue certificates in a very controlled scope. But these comments are just my humble opinion... we'll just adapt to whatever is the result of this discussion. BR/Pedro El miércoles, 25 de abril de 2018, 19:04:23 (UTC+2), Wayne Thayer escribió: > On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi <[email protected]> wrote: > > > I'm not sure I underestand the use case. I'm hoping that they can clarify > > more. > > > > Pedro - can you explain more about why this is important? > > 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. > > > > Ryan - can you explain this concern in more detail? If, for instance, the > srvName type was added for TLS certificates, new intermediates would be > required to constrain that name type due to the "fail open" nature of name > constraints. If a single intermediate contained both the serverAuth and > emailProtection EKUs, how does that make the situation worse? Is it just > that now all of the S/MIME certificates issued under the intermediate must > also expire or be replaced so that the old intermediate (without a > constraint on srvName) can be revoked? > > 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
