‎I think some good work has been done here but the proposed solution is the wrong way to go since it establishes boundaries for CA's that are "locked in" at the browser, either in the form of a special table or in the trusted root store itself. While a method is provided for making changes to the boundaries, those changes won't be applied retroactively which means the older versions will be locked out as a CA expands it's service offering.

This backwards compatibility problem is a fatal flaw, but I have an alternative in mind: establish and enforce boundaries within the intermediates. The browser can enforce a policy that a technical constraint be specified somewhere between the root and the end cert. Where exactly in the chain that happens is not important so long as it's found and the boundaries established are not violated. The absence of the constraint would flag an error. Or, perhaps, a special table would be used to provide "default" boundaries.

The advantage here is that CA's would maintain the flexibility to expand or contract the DNS space in which they choose to operate. Presumably this would not be a high frequency occurrence. This flexibility not only helps the CA's but it can also help give cert purchasers more options when choosing a CA. That's the theory, anyway. 

It is certainly a good idea to encourage any CA to self-constrain but we do need a way to forcibly constrain all CA's. Allowing any CA to opt-out defeats the whole purpose.

Thoughts?


From: Richard Barnes
Sent: Friday, March 6, 2015 6:26 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Name Constraints

Hey all,

I've been doing some research on the potential benefits of adding name
constraints into the Mozilla root program. I've drafted an initial
proposal and put it on a wiki page:

https://wiki.mozilla.org/CA:NameConstraints

Questions and comments are very welcome. There's a lot of details to work
out here, but I think there's some significant benefit to be realized.

--Richard
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to