On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy < [email protected]> wrote:
> 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. Unfortunately, this is not a correct understanding of nameConstraints. As described in RFC 5280, Section 4.2.1.10 ( https://tools.ietf.org/html/rfc5280#section-4.2.1.10 ), and as further expanded within the processing model, nameConstraints only apply to the name types specifically enumerated within the nameConstraints extension - that is, they don't apply to other name types that are specified. This is why, for example, the CA/Browser Forum requires that the CA explicitly enumerate the iPAddress, dNSName, and directoryName name constraints, to ensure that those types are all constrained. However, the introduction of any other name types is further problematic. > 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. > This is not consistent with what we see in practice, so I'm not sure this is a reasonable conclusion to pin all our hopes on. > 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. > Can you further expand on this? This was the piece of information that was previously missing, and remains missing. What is your envisioned use case for this, in which multiple EKUs benefit from public trust? > 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. > Of course, while limited in scope, there are still an ample number of ways such a CA could misissue - with the most obvious and alluring of these being related to key sizes. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
