Government Certification Authorities
Distinguishing between a Government CA and other CAs
How do we define what a Government CA is?
- The CA organization is owned/operated by the government of that country or region.
- Not sure if this would include organizations like CNNIC and HARICA
- Public corporations, private organizations, non-profit organizations that provide certs to a government agency?
- I think that would end up being all the CAs in the program.
- CA has "Government" in the name
- CA takes the "government" exception in our audit standards (i.e. no WebTrust; uses govt-internal audit process)
- CA does more than x% of its business (count of certs issued) with its own government
- CA is authoritative for a given set of names. For instance, CNNIC is authoritative for ".cn" (all of it); HARICA is authoritative for some names within ".gr"; ANSSI within ".fr".
- In the DNS, the registry for a name is authoritative for names below that name, since they decide who is assigned those names. The registry for a domain can always get certs under that name from a third-party CA. They have the ability to fake whatever information the CA is going to look at for validation, so they can convince the CA that they own the domain. If "org" wants their friend Bob to get a certificate for "*.mozilla.org", they can just set the DNS and WHOIS records to reflect that Bob owns mozilla.org. There's no point to constraining a CA's actions over names they have authority over -- they can *already* decide who gets certs for those names.
Is it reasonable to treat a Government CA differently from other CAs?
- What if the Government CA provides the documentation and audits showing that it complies with Mozilla's CA Certificate Policy?
- Why would we trust government A to certify sites in country B?
- Some government CAs don't follow our standard audit processes; such as having an independent, third-party auditor.
- Some government CAs can be very slow at adopting our new policies and requirements.
Government CAs who are currently included: (CAs that are owned/operated by the government of a country or region. -- Note, not sure if Izenpe actually falls into this category, but they claim to be a government CA.)
- Government of France
- Government of Hong Kong (SAR), Hongkong Post
- Government of Japan, Ministry of Internal Affairs and Communications
- Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Government of Spain (CAV), Izenpe S.A.
- Government of The Netherlands, PKIoverheid
- Government of Taiwan, Government Root Certification Authority (GRCA)
- Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
Included CAs that I've heard referred to as Government CAs, but it probably depends on the definition of "Government CA".
- China Internet Network Information Center (CNNIC) -- non-profit organization, operated by Chinese Academy of Sciences, customers include public, enterprises, and government.
- HARICA (Hellenic Academic and Research Institutions) -- non-profit organization operated by the Greek Universities Network
- Japan Certification Services, Inc. (JCSI) -- public corporation
- Camerfirma -- commercial CA, digital CA for Chambers of Commerce in Spain
- CATCert -- Catalan Agency of Certification provides signatures within Catalan government
- Certicámara S.A. -- public corporation
- Chunghwa Telecom Corporation -- public corporation, integrated telecom operator in Taiwan
- TurkTrust -- public corporation
- e-tugra -- privately held organization
- e-Guven Elektronik Bilgi Guvenligi A.S. -- private corporation, customers include government
- PROCERT -- private entity within the Venezuelan Bolivarian Republic, which is accredited by the Venezuelan State as a Provider of Certification Services (PCS)
Government CAs who have applied to have a root included, but are on hold pending action items that resulted from their first discussion
- KISA, Government of Korea -- sub-CA review and audits, bug 335197#c91
- SSC, Lithuanian National Root -- OCSP, Root Roles, CPS, Audit, bug https://379152#c34
- Swiss BIT -- New root, update CPS, bug 435026#c38
- ICP-Brasil, Government of Brazil -- sub-CA review and audits bug 438825#c98
- Finnish Population Register -- audit, bug 463989#c21
- E-ME, Government of Latvia -- new root, update docs, bug 518098#c95
- US FPKI, bug 478418
Government CAs who have been told in their root inclusion bug to have their subCAs apply for inclusion separately. After all of their subCAs have completed the root inclusion process, then the CA may continue with their request to include the root certificate.
- Government of India, bug 557167#c16 -- Large existing hierarchy, so proceeding with inclusion of each subCA separately. If all of the subCAs are approved/included, then the CCA root may be considered for inclusion.
- Government of Venezuela (SUSCERTE), bug 489240#c28 -- This CA functions as kind of a super CA and their CA policies don't apply to the sub ordinate CAs (including auditing), those CAs must apply for inclusion themselves.
Other CAs who might be considered Government CAs that have requested inclusion.
- Autoridad Certificadora Raíz Nacional de Uruguay (ACRN)- the root of the chain of trust of the Uruguayan National PKI
- French Institute of Certified Public Accountants (CSOEC)
- Latvian State Radio and Television Centre (LVRTC)
Concerns about Government CAs
Concern has been repeatedly raised about Government CAs having root certificates included in Mozilla products
- Distrust of Government
- Government interference with internet activities of their citizens.
- Government participation in spying on people on the internet.
- Previous instances of the government having initiated (or taken the blame for) malware including virus, worms, MITM attacks.
- Hostile jurisdiction compelled certificate creation attack
- Some CAs have been asked to update their CP/CPS to address concerns about being compelled by third parties to inappropriately issue an intermediate or end-entity certificate. Current recommendation from the discussions appears to be to provide information about which regulatory and legal framework/jurisdiction the CA is primarily beholden to; and add a statement that the CA will duly verify that an order from a government or other such organization is lawful before executing the order.
- What would browsers do if a CA mis-issued a certifiate, but had a court-order to do so?
- We would blacklist the false chains. Would potentially blacklist all of the CA's root certs. This would impact the CA's business. Government CAs do not have a commercial interest, so there is less downside for a Government CA being removed than for a commercial CA being removed.
- Some Government CAs are very slow to respond when changes are made to policy, such as technically constraining subordinate CAs and becoming compliant with the Baseline Requirements. https://wiki.mozilla.org/CA:Communications#January_2013_Responses
Suggestions about what to do about Government CAs
Suggestions to consider...
- Improve the policy text regarding independent audits. Some of the government CAs are audited by other government agencies, so essentially by themselves. If they cannot have a 3rd-party review their CA operations, then they are not a public CA, and should not be included. Audit must be independent.
- Require CAs to use separate root certificates for the CA hierarchies that are for issuing certs to governments. This allows for:
- Tools and process could be specialized root certs that issue certs to governments.
- Different UI treatment for them.
- Additional constraints based on region/language.
- UI changes will not help. UI already complicated, most users won't notice additions/changes to the UI. A lot of work involved, but very little benefit would result.
- Any sort of marking by a CA to indicate if they issue government CAs would be based on information provided by the CAs themselves, so not clear how reliable such information would be.
- Restrict government roots to their TLDs
- The purpose of this would be to limit the use of government roots to only within the government's jurisdiction. In the USA, however, federal, state, and local governments use the TLD .gov. The federal government does not have jurisdiction over state and local Web sites and vice versa. How would this restriction apply to the Basque certificate authority Izenpe, whose jurisdiction lies entirely within Spain and the TLD .es?
- We have asked this of Government CAs repeatedly in mozilla.dev.security.policy, and usually the CA responds by saying that they need to be able to issue SSL certs for .com and .org.
- HARICA (I think) was the first CA to voluntarily add Name Constraints to their root and intermediate certs, but they still needed to be able to issue to .org.
- This has been requested in regards to specific roots, such as CNNIC: Have Firefox provide a warning when the CNNIC ROOT CA is used to authenticate web sites outside the jurisdiction of the Chinese government.
- bug 555701
- Optional Name Constraints on government CAs have not helped. Even the CAs who agree to use Name Constraints want .org and .edu, so only solves problem for .com. Most government CAs say that they need to issue to .com. For this to be effective we would have to make Name Constraints a requirement and not optional. But then the question is for which CAs, because it is difficult to draw the line to distinguish between which CAs are government CAs.
- Treat Government CAs like other CAs that provide the necessary documentation and audit statements to show compliance with Mozilla's CA Certificate Policy.
- Make a clear statement about what it means to have a root certificate in Mozilla's program.
- What statements can truly be made about CAs in Mozilla's program.
- Are we trying to protect users from being spied on by their governments?
- Is inclusion in Mozilla's CA Certificate program an indicator that the CA is not evil?
- What is out-of-scope; e.g. what are unreasonable assumptions for people to make about CAs in Mozilla's program.
- Cannot protect anyone from governments using their power on their citizens, whether it is a government-owned CA or not.
- Make a clear statement about what it means to have a root certificate in Mozilla's program.
- The least we can do is say something like, yes, [Chinese/Dutch] Government, we will accept your root, but it should only work by default for users browsing in the [Chinese/Dutch] language, others will have to click-through once to trust it. This isn't about building one-to-one mappings of websites to national jurisdictions. This is about putting a least-privilege scope on claims of trustworthiness rooted in sovereignty rather than an independently verified audit. It's about protecting the trans-national nature of Internet trust against the abuse and or incompetence of sovereigns.
- This is not "the least we can do", it's very difficult :-) Mapping languages to countries is a political minefield. Also, the en-US version of Firefox is used widely outside the US. People in some countries prefer to compute in English. If we are going to do something like this, restricting by site TLD rather than user language is much less controversial. -- Gerv
What Inclusion of a CA in Mozilla's Program Means
What statements can be made about CAs in Mozilla's program?
- Certificates are used in three primary functions within Mozilla software:
- When a user connects to an SSL-enabled web server or other SSL-enabled servers.
- When a user reads digitally signed email from another user.
- When a user downloads and executes digitally signed code.
- A Certification Authority (CA) is an entity that digitally signs other entities' certificates. By signing the data in certificates CAs are vouching for the information contained in the certificate.
- A certificate used for a secure web server contains the domain name used to connect to the web server, and by signing such a certificate a CA is vouching for the fact that the entity operating the web server (the entity that controls the server's private key corresponding to the public key in the certificate) actually controls the domain name associated with the server.
- A certificate used for secure email contains the email address of the person or organization that controls the corresponding email account, and by signing such a certificate a CA is vouching for the fact that the entity owns or controls the email address contained within the certificate.
- A certificate used for to sign code should contain the name of the developer or distributor of the code, and by signing such a certificate a CA is vouching for the fact that the entity referenced in the certificate is the entity that requested the certificate.
- Inclusion of a CA in Mozilla's Program means that Mozilla has:
- verified that the CA's practices and policies are documented on their public-facing website,
- verified that the CA's practices and policies have been audited by an independent, qualified auditor,
- verified that, based on the publicly available information, the CA is compliant with Mozilla' CA Certificate Policy.
- A CA is considered to be non-compliant with Mozilla's CA Certificate Policy if the CA
- knowingly issues certificates without the knowledge of the entities whose information is referenced in the certificates; or
- knowingly issues certificates that appear to be intended for fraudulent use.
- Mozilla will consider removing a root certificate from NSS if the CA is issuing certificates in a manner that is non-compliant with Mozilla's CA Certificate Policy. (As per the previous point, a CA that is issuing certificates that are being used in MitM attacks is non-compliant with Mozilla's CA Certificate Policy.)
- SSL makes tampering visible to its victims. The certificate has to actually make it to the users client application before the user can decide to trust it.