Closed
Bug 1232689
Opened 9 years ago
Closed 8 years ago
Add Root Certification Authority of the Republic of Kazakhstan (root.gov.kz)
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: seifullina_a, Assigned: kathleen.a.wilson)
References
Details
(Whiteboard: Information incomplete -- See Comments #6 and #11)
Attachments
(2 files)
CA Details ---------- CA Name: Republican state enterprise in the right of business «State technical service» of the Committee of Communication, Informatization and Information of the Ministry of Investment and Development of the Republic of Kazakhstan (hereafter - STS). Website: Public Key Infrastructure (PKI) – http://pki.gov.kz/index.php/en/ One Paragraph Summary of CA, including the following: - STS is a non-profit organization managed by Government of the Republic of Kazakhstan which works under Committee of communications, informatization and information of the Ministry of Investment and Development of the Republic of Kazakhstan. - PKI serves members of E-government, government and non-government information systems. All services provided by PKI are free of charge for the citizens of the Republic of Kazakhstan. Audit Type (WebTrust, ETSI etc.): WebTrust Auditor: plan to be audited in 2016 with WebTrust Auditor Website: will be provided after successful choice of auditor Audit Document URL(s): will be provided after successful choice of auditor Certificate Details ------------------- (To be completed once for each certificate; note that we only include root certificates in the store, not intermediates.) Certificate Name: НЕГІЗГІ КУӘЛАНДЫРУШЫ ОРТАЛЫҚ (RSA) Summary Paragraph, including the following: - Certificate is needed for creation of a common space of trust between information exchange participants in the Republic of Kazakhstan.(http://root.gov.kz/cps/certificate_policy.pdf) - Number and type of subordinate CAs: 3 root - Diagram and/or description of certificate hierarchy: http://root.gov.kz/assets/images/scheme.png Certificate download URL (on CA website): http://pki.gov.kz/cert/pki_rsa.cer Version: V3 SHA1 Fingerprint: e0 66 36 22 e5 9c 55 7a 3a 33 21 6b 77 44 76 78 98 5f 2a 72 Public key length (for RSA, modulus length) in bits: 4096 bits Valid From (YYYY-MM-DD): Monday, July 27, 2015 11:22:53 AM Valid To (YYYY-MM-DD): Sunday, July 27, 2025 11:22:53 AM CRL HTTP URL:http://crl.root.gov.kz/rsa.crl; http://crl1.root.gov.kz/rsa.crl OCSP URL: There is no necessity for certificates checking because all the client certificates that have to be checked are checked by NCA which is a subordinate certificate authority of RCA.
Attachment #8698461 -
Attachment description: Fully completed checklist → Fully completed and approved checklist
Assignee | ||
Comment 1•9 years ago
|
||
https://wiki.mozilla.org/CA:How_to_apply "The information listed in CA Information Checklist is expected to be publicly available so that it can be reviewed and referenced during the Public Discussion Phase and for future reference."
Group: mozilla-employee-confidential
Status: UNCONFIRMED → ASSIGNED
CC list accessible: false
Ever confirmed: true
Not accessible to reporter
Comment 2•9 years ago
|
||
Seems a dupe of bug 647959 to me. But in all seriousness, it seems clear that this root is intended for use in MITM attacks against TLS users; see http://bits.blogs.nytimes.com/2015/12/03/kazakhstan-moves-to-tighten-control-of-internet-traffic/
Assignee | ||
Comment 3•9 years ago
|
||
(In reply to Rodger Combs from comment #2) > Seems a dupe of bug 647959 to me. > > But in all seriousness, it seems clear that this root is intended for use in > MITM attacks against TLS users; see > http://bits.blogs.nytimes.com/2015/12/03/kazakhstan-moves-to-tighten-control- > of-internet-traffic/ This is being discussed in https://groups.google.com/forum/#!forum/mozilla.dev.security.policy topic: "Nation State MITM CAs?"
Comment 4•9 years ago
|
||
This bug summary *has* no verb :-) The user story also does not clearly state what the problem is, or what is being requested.
Assignee | ||
Comment 5•9 years ago
|
||
(In reply to Adrian Aichner [:anaran] from comment #4) > This bug summary *has* no verb :-) > > The user story also does not clearly state what the problem is, or what is > being requested. This is a CA root inclusion request. Reference: https://wiki.mozilla.org/CA
Summary: Root Certification Authority of the Republic of Kazakhstan (root.gov.kz) → Add Root Certification Authority of the Republic of Kazakhstan (root.gov.kz)
Assignee | ||
Comment 6•9 years ago
|
||
I have entered the information for this request into Salesforce. Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the attached document)
Assignee | ||
Updated•9 years ago
|
Whiteboard: Information incomplete
Comment 7•9 years ago
|
||
Is the proposal to put this KZ root certificate into regular Firefox releases so KZ can MITM the whole world? That sounds like a terrible idea. Maybe I misunderstand, though.
Comment 8•9 years ago
|
||
(In reply to Rodger Combs from comment #2) > MITM attacks against TLS users; see > http://bits.blogs.nytimes.com/2015/12/03/kazakhstan-moves-to-tighten-control- > of-internet-traffic/ definitely it is
Comment 9•9 years ago
|
||
Bugzilla is not a discussion forum, but a bug tracker. Regardless of whether you personally think this isn't even worthy of a discussion, any kind of lengthy discussion should *not* happen on Bugzilla but on the dev-security-policy mailing list. Details below: (In reply to Kathleen Wilson from comment #3) > (In reply to Rodger Combs from comment #2) > > > > But in all seriousness, it seems clear that this root is intended for use in > > MITM attacks against TLS users; see > > http://bits.blogs.nytimes.com/2015/12/03/kazakhstan-moves-to-tighten-control- > > of-internet-traffic/ > > This is being discussed in > https://groups.google.com/forum/#!forum/mozilla.dev.security.policy > topic: "Nation State MITM CAs?"
Comment 10•9 years ago
|
||
(In reply to Frederik Braun [:freddyb] from comment #9) sure, as far as there is a link to discussion. tried to find a way to delete the comment right after posting, no way.
Assignee | ||
Comment 11•9 years ago
|
||
(In reply to Kathleen Wilson from comment #6) > Created attachment 8705877 [details] > 1232689-CAInformation.pdf > > I have entered the information for this request into Salesforce. > > Please review the attached document to make sure it is accurate and > complete, and comment in this bug to provide corrections and the additional > requested information (search for NEED in the attached document) I would like to point out a few things... 1) The need for the Baseline Requirements (BR) audit is listed in the attached CA Information document. Completing a successful BR audit would mean that the auditor ensured the CA meets the requirements for validating that the certificate subscriber owns/controls the domain name(s) to be included in the certificate. (i.e. a BR audit should fail if the CA issues MITM certificates) Reference: https://cabforum.org/baseline-requirements-documents/ 2) All documentation, including the audit statements must be public-facing. 3) This CA might be a super CA. If it is, then we would need to take the approach described here: https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs "Some CAs sign the certificates of subordinate CAs to show that they have been accredited or licensed by the signing CA. Such signing CAs are called Super-CAs, and their subordinate CAs must apply for inclusion of their own certificates..."
Whiteboard: Information incomplete → Information incomplete -- See Comments #6 and #11
Reporter | ||
Comment 12•9 years ago
|
||
>> 1) The need for the Baseline Requirements (BR) audit is listed in the attached CA Information document. Completing a successful BR audit would mean that the auditor ensured the CA meets the requirements for validating that the certificate subscriber owns/controls the domain name(s) to be included in the certificate. (i.e. a BR audit should fail if the CA issues MITM certificates) Reference: https://cabforum.org/baseline-requirements-documents/ Preparation for certification audit of CA on compliance to the International WebTrust standard requirements was performed in 2014. The contract #34 from August 1, 2014. Audit for compliance to the WebTrust for CA and WebTrust for BR standards is planned for 2016 year. >> 3) This CA might be a super CA. If it is, then we would need to take the approach described here: >> https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs >> "Some CAs sign the certificates of subordinate CAs to show that they have been accredited or licensed by the signing CA. Such signing CAs are called Super-CAs, and their subordinate CAs must apply for inclusion of their own certificates..." As a Super-CA we are planning to perform WebTrust for CA and WebTrust for BR audits both for Super-CA and subordinates. Based on audit it will be proved that all subordinate CAs demonstrably adhere to the Super-CA’s documented policies and audit criteria. Our subordinate CA does not itself acts as a Super-CA and also does not sign a large number of public third-party subordinate CAs. Our Super-CA is at all times completely accountable for it’s subordinate CA, and ensures that subordinate CA demonstrably adhere to the Super-CA’s documented policies and audit criteria.
Comment 13•8 years ago
|
||
I can not believe it. They not only forcing Kazakhstan citizens to install this ROOT CA to all their devices, but also asking Mozilla to include it as trusted in new browser builds. That's really crazy. I hope even if regular user does not understand security risks of adding ROOT CA manually to enable MitM attacks network specialists should understand it and never add this kind of certificates as trusted.
Assignee | ||
Comment 14•8 years ago
|
||
(In reply to Kathleen Wilson from comment #11) > I would like to point out a few things... > > 1) The need for the Baseline Requirements (BR) audit is listed in the > attached CA Information document. > Completing a successful BR audit would mean that the auditor ensured the CA > meets the requirements for validating that the certificate subscriber > owns/controls the domain name(s) to be included in the certificate. (i.e. a > BR audit should fail if the CA issues MITM certificates) > Reference: https://cabforum.org/baseline-requirements-documents/ > > 2) All documentation, including the audit statements must be public-facing. > Closing this bug, because based on Bug #1229827 and other related information it appears that the owner of this CA has used their certificates to MITM people in Kazakhstan. If this CA does get a valid BR audit, they may re-open this bug. But note that I expect it would be very difficult for this CA to get through the public discussion phase. https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 15•8 years ago
|
||
(In reply to Kathleen Wilson from comment #14) > (In reply to Kathleen Wilson from comment #11) Dear Kathleen, Thank you so much for provided information. We are currently in process of preparing all required documentation including an audit report to be provided as soon as possible. Other than that, we accept the terms of processing the request and we will initiate the bug on public discussion phase soon.
Updated•7 years ago
|
Product: mozilla.org → NSS
Updated•2 years ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•