Warning: This is just a draft proposal for a new Firefox feature. Please see discussion on dev.security.policy

Enhancing name constraints on public CAs

In the web PKI today, the ability of any CA to issue a certificate for any domain name is a major source of risk. For example:

• The French CA ANSSI was used to facilitate MitM against arbitrary sites
• Both Diginotar and an Indian CA mis-issued certificates for Google

One way to constrain this risk is to limit CAs to issue only for certain names, using the "name constraints" extension for X.509 certificates. This was the response taken in the ANSII case above: The ANSSI root is limited to only issue for French ccTLDs. More generally, research by the University of Michigan shows that most CAs only issue for names within a small set of TLDs, which indicates that name constraints can be chosen that increase security with minimal impact to CAs. Mozilla has reproduced these results at the level of TLDs. Over the past year:

• 60% of roots have issued for fewer than 11 TLDs
• 28% of roots have never issued for com

Adding Name Constraints to the Root CA Program

To reduce the risk posed by unconstrained CAs, Mozilla proposes to develop a list of name constraints to be applied to each root CAs in its program. These constraints would be published alongside the CA definitions in the root CA list. Software using the root CA list would be responsible for enforcing the constraints. We anticipate that Firefox would enforce these constraints, and possibly that this enforcement would be implemented in NSS itself.

To be clear, the goal of creating name constraints is not to constrain the operations of CAs, but to guard against mis-issuance. The name constraints for a root should allow issuance for any name that the CA wishes to issue for -- but they should also disallow issuance for any name that the CA does not intend to issue for. The goal here is

(Footnote: In principle, it would be possible to re-issue the root certificates with name constraints underneath a "super-root". This would allow for the name constraints to be applied automatically by most PKIX implementations, at the cost of running the super-root. Mozilla does not intend to implement such a super-root, but obviously, other parties using the root list could do so for their own purposes.)

The constraints will be logically structured as a "permitted suffix list". There is one entry in this list for each root, containing a list of domain name suffixes for which that CA is trusted to act as a root; effectively the contents of a "permittedSubtrees" entry in an X.509 name constraints extension. The suffixes in the list will be TLDs.

The content of the permitted suffix list will be determined by community consensus, via the dev.security.policy mailing list. The general process for changes to the list is as follows:

• A change is proposed to the list
• This triggers a four-week discussion period. In this period, it is expected that data and arguments will be provided supporting the change.
• At the end of the comment period, the chairs will evaluate whether there is consensus to make the change

Next Steps

The first change to be made will obviously be the establishment of initial contents of the permitted suffix list.

Mozilla has performed an initial survey of which roots have issued for which TLDs, in the sense that a certificate has been observed on the public Internet that (1) contains a domain name under the TLD and (2) chains to the root.

Based on these findings, we will develop an initial proposal for the permitted suffix list. Comments on this list are welcome on the Mozilla dev.security.policy mailing list.

We are working on an update to Firefox to add these constraints in "test mode", in which a constraint violation will not result in the certificate being rejected, but only in telemetry measurement. This telemetry will allow us to recognize whether the proposed constraints are accurate (if few violations are observed in telemetry), or whether there is a need for further revision.

Once we have validated this initial set of name constraints, we will propose a plan for moving constraints from test mode to real enforcement.

Our hope is that this process can reduce the attack surface of the web PKI, while allowing CAs the flexibility they need.