Hi Ryan, thanks for your enlightening feedback to my poor comments... let me try to add some more here.
El lunes, 30 de abril de 2018, 17:22:38 (UTC+2), Ryan Sleevi escribió: > 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. > Probably it's a language issue, but I would say that that was what I said, or at least what I intended to say... Another point is that the real-life implementations are tricky sometimes... For example: - By default MS CA adds empty entries to the permitted name list for the types of names not specified, so for example if you don't include the IP addresses constraints in the capolicy.inf file, then it will add automatically a constraint to disallow IP addresses, unfortunately in a non-very standard way that some certificate parsers don't like much (but effective when issuing certificates from a MS CA). - Same applies to the specification for name constraints in email addresses, MS specified this in the documentation in a way that is not fully in line of the RFC, and that caused trouble in the past - AFAIK Apple still doesn't like the name constraints extension to be critical, as it brings an untrusted certificate error So I see your concern on name constraints not being used properly... as actually aren't that easy to implement. > > > 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. > Well, that's another problem. At least we're used to play according to the rules, but also to be checked to do so. But you speak with a broader view on this, so I understand your point. > > > 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? > I'm just stating a customer demand that I've seen several times already: a company that wants an internal CA (typically a MS CA linked to the Active Directory) to issue certificates that are valid for several uses, being one secure email (i.e. outgoing signed messages easy to verify). These same customers typically also want to use trusted certs for web or other servers using the serverAuth EKU. > > > 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. Maybe I'm too pragmatic, but from a risk management perspective, I don't see a constrained CA issuing a poor certificate harming the whole CA/Browser community, so I would even accept that risk. Anyway, as a conclusion, I see your point about this maybe being difficult to manage in the real world, so I guess my request to consider the exception for name constrained CAs is not as straightforward as it's in my head. Cheers! _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
