For the thread's reference, this is the relevant part of the application (from attached scanned images, more extended than the text they included inline on the Bugzilla thread) that describes the intended use:
https://s3.amazonaws.com/konklone-public/kazakh/kazakh1.png And this section has some additional information about potential uses and their intent to get a WebTrust audit: https://s3.amazonaws.com/konklone-public/kazakh/kazakh2.png -- Eric On Thu, Jan 7, 2016 at 7:40 PM, Jakob Bohm <[email protected]> wrote: > On 07/01/2016 22:21, Paul Wouters wrote: > >> 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. >> >> > Unfortunately, we have little power to do that. So if we don't accept > the CA, the users have to install a different browser or install that > CA manually in order to e.g. pay their taxes, but if we do accept it > without filtering, we expose them to the MITM. > > - 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. >> > > I seem to have seen "recent" X.509 extensions that can restrict the DNS > domains for which a CA can (directly or indirectly) issue certificates. > Compare the "Technically restricted" subCA clauses in current Mozilla > criteria. > > Idea would be to "tack on" additional semantically equivalent > restrictions even where not present in the actual CA cert. > > >> 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. >> > > It's the opposite. Restricting single-country CAs from being trusted for > wordwide URLs while still being trusted for URLs for which it is > appropriate. > > For the dual use nation-CA case this means allowing worldwide users to > connect securely to that nations government websites, while protecting > them from MITM attacks. > > For the ordinary nation-CS case, the means limiting the scope of trust > to nation addresses. For example "Staat der Neederlanden" would not be > trusted for .com domains such as google.com, thus preventing (if it had > been implemented back then) the DigiNotar breach from affecting Google > users in Iran visiting .com domains. > > >> - 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. >> >> > Note though that EKUs don't limit the domains or identities for which a > CA issues (real or MITM) certificates, only the protocols and protocol > roles. For example being a HTTPS server is one EKU, being an e-mail > signature is another EKU etc. Hence all my other suggestions. > > > > > > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
