On Thu, 7 Jan 2016, Jakob Bohm wrote:
It would appear from this information, that this CA (and probably others like
it) is deliberately serving a dual role:
1. It is the legitimate trust anchor for some domains that browser
users will need to access (in this case: Kazakh government sites
under gov.kz).
2. It is the trust anchor for fake MITM certificates used to harm
browser users, and which should thus be regarded as invalid.
Thus it would be prudent to extend the trust list format (and the NSS
code using it) to be able to specify additional restrictions beyond those
specified in the CA root itself.
Much easier would be to not allow a CA cert not to engage in such dual
roles.
- Additional path restrictions. Example 1: The Microsoft internal CA
should only be trusted for a list of Microsoft owned domains.
I'm not sure how to that would work in practise. I know it can be done
using TLSA DNS records to pin each domain. Having that logic elsewhere
seems more dangerous and less transparent.
Example 2: Many nation state CAs should only be trusted for sites
under that country cc-tld, and sometimes only for a subdomain
thereunder such as gov.kz).
I have a serious problem with this because the users are not explicitely
agreeing to this and so this is facilitating a MITM no different then
SSL middleware boxes. And those are only allowed to installed manually,
with the user's (or enterprise's) consent.
- Permitted EKU (Extended Key Usage) OIDs. Example, many nation
state eID CAs should be restricted to "e-mail signing" and "client
authentication", even if the CA itself suggests a more wide usage.
Enforcing proper EKU's would be good so nation state CA's meant for
official communication with citizens cannot be abused for MITMing those
same citizens.
Paul
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
