On 07/01/2016 00:07, Paul Wouters wrote:
As was in the news before, Kazakhstan has issued a national MITM
Certificate Agency.
Is there a policy on what to do with these? While they are not trusted,
would it be useful to explicitely blacklist these, as to make it
impossible to trust even if the user "wanted to" ?
The CA's are available here:
http://root.gov.kz/root_cer/rsa.php
http://root.gov.kz/root_cer/gost.php
One site that uses these CA's is:
https://pki.gov.kz/index.php/en/forum/
Paul
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.
For example the trust list could state (depending on the known
properties of each CA).
- Additional path restrictions. Example 1: The Microsoft internal CA
should only be trusted for a list of Microsoft owned domains.
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).
- 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.
- Different validity period: Some CAs have made radical changes in
practices and may thus need to be trusted only before/after such
change.
- Issuance date validity period: While not expressible in standard
X.509 certificate formats, it is sometimes meaningful to assign
different trusts based on when a (non-lying, non-compromised) CA made
a policy change. Example: The TDC OCES CA at some date changed from a
regular CA operation to an operation where all keys are kept on a
central server where users log in to sign stuff.
- Ability to list multiple combinations of restrictions for the same
actual CA certificate. For example different path restrictions for
different EKUs.
- Ability to trust or distrust subordinate CAs directly. Example 1:
The DigiNotar incident. Example 2: Sometimes a well-run CA is
technically a subordinate of a non-acceptable CA or a CA that needs
deeper restrictions. Example 3: A root may have too lax a policy for
signing subordinates. Example 4: A CA company may run all its CAs as
subordinates under a single root, but only some of those subCAs meet
Mozilla criteria. Example 5: Some historic roots, such a Equifax,
have been subsequently used as the root CA signing the new CAs as
subCAs.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
