So my response: CA's sell trust. Billions of people trust them. They should be above reproach. A CA in the root certificate store has supposedly passed through

So my response: CA's sell trust. Billions of people trust them. They should be above reproach. A CA in the root certificate store has supposedly passed through an arduous set of processes and should be rock solid. While you may not like the tone of my comments, was there anything that was factually incorrect? I saw BS answers and called them out. Specifically as to her question: >Thank you all for chiming in. I’m not sure how exactly you’re involved in the CA community, do you represent a CA? A browser perhaps? Or any of the governing I mean... yeah. I've been doing Open Source security since 1998. https://seifried.org/lasg/ https://seifried.org/lasg/, https://seclists.org/bugtraq/1998/Apr/ https://seclists.org/bugtraq/1998/Apr/. in the last decade I was one the CVE Board (resigned), still on the CWE/CAPEC board, I do the https://opensourcesecuritypodcast.com/ https://opensourcesecuritypodcast.com/ (350+ episodes). I was 1/3 of oss-security mailing traffic for a few years thanks to being "the CVE assigner" and such. If you look at the rest of the dev-security-policy@mozilla.org list posters it's the same 2-3 dozen people posting for almost a decade (myself included, going back to 2010 or so, I have a spreadsheet somewhere but it's easy enough to confirm). Again: a CA should be like a bank, well run, regulated, and trustworthy, they should not be toppled over so easily by a group of random Internet volunteers. I would also point out that Microsoft retroactively removed them: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/NxbhuW-4CgAJ https://groups.google.com/a/mozilla.org/g/dev-security-polic... so say what you will about my tone, but the facts are the facts. Also if anyone is interested we're looking at other root CA's, theres a few more that appear to be less then ideal. Heck within the last 3 months we've also had: SERPRO with MASSIVE problems (assigning certificates to URLs, "Bennar" and so on), they actually withdrew from the process because they need time to clean up their organization. https://groups.google.com/a/ccadb.org/g/public/c/Mux855BsRg4 https://groups.google.com/a/ccadb.org/g/public/c/Mux855BsRg4 bjcn.ca with again, spyware concerns and some other potential issues, https://groups.google.com/a/ccadb.org/g/public/c/o9lbCbr92Ug/m/lPkqrHF1DQAJ https://groups.google.com/a/ccadb.org/g/public/c/o9lbCbr92Ug... and there's a nice summary from 2 days ago: ========================================================================================= Summary of Discussion and Action Items Discussion Item #1: A concern was raised about BJCA’s Beijing One Pass software, which apparently facilitates client access to a digital portal or platform. It was noted that BJCA had attempted to address suspicions about the software in Comment #15, that the software was needed to support a USB token and to install another certificate chain, and not the two above-referenced roots. A follow-up question was whether a security report concerning the software would be made publicly available. BJCA Response to Discussion Item #1: “This report is a communication document between our company and the competent government department, and it is not suitable for disclosure or submission to Mozilla because it involves confidential information. And because the security incident does not involve the certificate chain of the root inclusion case submitted to Mozilla this time, we made a clarification in the Mozilla root inclusion case by disclosing the main points of the report.” ========================== Discussion Item #2: Two components were also mentioned: wmControl.exe and zfkeymonitor.exe. BJCA Response to Discussion Item #2: The “suspected spyware behavior indicated in the report was caused by one of the drivers, wmControl.exe. This program is a driver provided by the USB Token manufacturer, Its software behavior is different from spyware and does not have malicious behavior. It is intended to ensure the normal use of this type of [device] in the browser. In addition, the USB Token for digital certificate corresponding to the driver wmControl.exe is an old version device, and its driver has been deleted in the new version of the certificate environment software (version >= 3.6.8)”. Concerning zfkeymonitor.exe, BJCA responded that their software did not include the zfkeymonitor program. ========================== Discussion Item #3: Clarification was requested about root certificate installation by the One Pass software. BJCA Response to Discussion Item #3: BJCA reiterated that their software did not attempt to install the two roots, but stated, “in order to improve the user experience, the BJCA certificate environment software chooses to skip user confirmation during the installation process, which may cause doubts for users. At present, we have plans to adopt advanced options in the new version of the software, allowing users to choose whether to confirm the installation, and support users to choose to add certificates and updates to the current user's personal storage instead of the computer's trusted root or trusted third party storage. No doubt that there is an obvious contradiction between convenience and security, which could improve the software security but degrades the user experience and increase our operation costs.” According to BJCA, it maintains two separate systems: a global, public-trust system that meets international standards (WebTrust, CA/Browser Forum, etc.) and issues and manages SSL/TLS server certificates; and a national system that follows Chinese standards and issues and manages personal certificates, enterprise certificates and equipment certificates (e.g., Beijing One Pass software and certificate). BJCA acknowledges that both systems are under control of the same legal business entity, but for the latter, the software is not part of the global, public-trust system. BJCA says it “will also refer to the recommendations of experts, learn from the best practices of the public trust system, continue to innovate, practice corporate social responsibility, and strive to build a safe and reliable of cyberspace.” ========================== Conclusion We thank community members for their review and consideration during this period. Root Store Programs will make final inclusion decisions independently, on their own timelines, and based on each Root Store Member’s inclusion criteria. Further discussion may take place in the independently managed Root Store community forums (i.e., MDSP). ========================================================================================= If anyone is interested, we're looking into what can be done around the root certificate world, if you're interested feel free to reach out to me at kurt@seifried.org (I'm still in the exploratory phase, e.g. can anything actionable/useful be done, and so on).