Public Discussion of BJCA's CA Inclusion Request

[Ben Wilson]

All,

This is to announce the beginning of a six-week public discussion period for the inclusion request of Beijing Certificate Authority Co., Ltd. (BJCA) (Bug # 1647181, CCADB Case # 615) for the following two root CA certificates:

BJCA Global Root CA1  ((4096-bit RSA) websites trust bit with EV enablement and the email trust bit)

Download –  http://repo.bjca.cn/global/cert/BJCA_Global_Root_CA1.crt

crt.sh - https://crt.sh/?sha256=F3896F88FE7C0A882766A7FA6AD2749FB57A7F3E98FB769C1FA7B09C2C44D5AE

BJCA Global Root CA2 ((384-bit EC) websites trust bit with EV enablement and the email trust bit)

Download –  http://repo.bjca.cn/global/cert/BJCA_Global_Root_CA2.crt

crt.sh - https://crt.sh/?sha256=574DF6931E278039667B720AFDC1600FC27EB66DD3092979FB73856487212882

Mozilla is considering approving BJCA’s request to add these two roots as trust anchors with the websites and email trust bits enabled. BJCA is also seeking enablement for Extended Validation (EV) under the CA/Browser Forum’s EV Guidelines.

Repository: The BJCA document repository is located here:  https://www.bjca.cn/cps.

Relevant Policy and Practices Documentation:

Beijing Certificate Authority Co., Ltd. Global Certificate Policy, v. 1.0.6, dated July 25, 2022

Beijing Certificate Authority Co., Ltd. Global Certification Practice Statement, v. 1.0.6, dated July 25, 2022

Self-Assessments and Mozilla CPS Reviews are located within Bug # 1647181:

BJCA's-BR-Self-Assessment.pdf

Mozilla’s CP/CPS Reviews – Comment #7 and Comment #24

Value-vs-Risk Justification from BJCA – see Quantifying-Value--BJCA -2022.7.7.pdf

Audits:  Annual audits have been performed by Anthony Kam & Associates, Ltd. in accordance with the Webtrust Principles and Criteria for Certification Authorities. The most recent audit reports were published on May 18, 2022, for the period ending March 9, 2022.  See

https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=389f5843-e05f-4e80-aae0-23cee8922866 (Standard Webtrust)

https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=2c0c075a-0000-40f1-8a81-1ccb21268e62 (WebTrust Baseline Requirements and Network and Certificate System Security Requirements)

https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=78bb08b0-7523-4011-b27c-b8a1a978433e (Webtrust for Extended Validation)

Incidents

I am unaware of any incidents involving BJCA.

I have no further questions or concerns about BJCA’s inclusion request; however, I urge anyone with concerns or questions to raise them on this list by replying directly in this discussion thread. Likewise, a representative of BJCA must promptly respond directly in the discussion thread to all questions that are posted.

This email begins a 6-week period for public discussion and comment, which I’m scheduling to close on or about January 11, 2023, after which, if no concerns are raised, we will close the discussion and the request may proceed to Mozilla’s one-week “last-call” phase.

Sincerely yours,

Ben Wilson

Mozilla Root Program Manager

 

[Kurt Seifried]

The second google result I got was:

https://borncity.com/win/2021/08/02/spyware-hnliche-funktionen-in-china-app-bejing-one-pass-gefunden/

Which links to the original report:

https://www.recordedfuture.com/beijing-one-pass-benefits-software-spyware

Insikt Group independently verified that the installed application exhibits characteristics consistent with potentially unwanted applications (PUA) and spyware. The software is associated with the Beijing Certificate Authority (北京数字认证股份有限公司), which is a Chinese state-owned enterprise (BJCA, www.bjca[.]cn).

So a good start might be having someone from bjca.cn explain their relationship with PUAspyeware apps in China. 

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZH1bXQrWJ5zWPg0Rm8XqtX687qeMogFUGV%3Dsb0jDwF3g%40mail.gmail.com.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[Kurt Seifried]

Also a second question: are there any examples of people/orgs using this CA? It's trusted in the 360 browser and Adobe (https://crt.sh/?q=BJCA) but I can't find any examples of certificates.

[BJCA]

The software mentioned in the security incident report is a digital certificate application security suite developed by BJCA. The normal operation of this software depends on some technical implementation, which lead to misjudged as abnormal behavior, actually it is not a spyware.

After BJCA received the above security incident report on August 2, 2021, we had made a clarification reply in the Mozilla root inclusion case (see https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c15) . Since the reply involves amount technical details, I will not repeat them here. Please follow the link above to get details and feel free to discuss further if you have more questions. At the same time, please note that the mentioned software does not include the certificate chains of this root inclusion case (BJCA Global Root CA1 and BJCA Global Root CA2).

Regards,
BJCA team

[BJCA]

BJCA, founded in 2001, is a leading network trust and digital security service provider in China. It is one of the first CA institutions in China to obtain the Electronic Authentication Service License issued by the government. It provides electronic authentication services for nearly ten million enterprise users and hundreds of millions of individual users in China.

At the same time, BJCA has decades of practical experience in acting as a reseller for international SSL certificate products, and is familiar with the relevant standards and specifications promulgated by CA/Browser Forum. In 2019, it established the BJCA global certification system and implemented the WebTrust international security audit certification. BJCA hopes to provide global electronic certification services with international standardized operation management and service levels to our customers and contributes to publicly-trusted digital certificates ecosystem.

The root certificate of the BJCA global certification system has been trusted by 360 browsers and Adobe Reader. The document signing certificate has been widely used in Chinese universities to sign the transcripts which can be widely trusted and verified around the world.

Since the certificate chains has not been trusted by Mozilla, Microsoft, Apple, and Google, no SSL certificate has been issued to customers at present. If you want to retrieve an example SSL certificate, please visit the following website in 360 browser:

i.BJCA Global Root CA1, https://demossl-rsa-valid.bjca.org.cn

ii.BJCA Global Root CA2, https://demossl-ecc-valid.bjca.org.cn

Thanks again,
BJCA team

[Prof. Reardon]

Hello:

I looked into the report and the response that BJCA referred to (comment #15,
https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c15
which I understand to be the entire response). For convenience I'll repeat
comment #15 here and put my questions in line.

<<
We had received the security threat analysis report (CTA-CN-2021-0729)
mentioning the suspected spyware problem of Beijing One Pass certificate
application software. We had carried out security assessment and testing in
accordance with the regulations of the Cyberspace Administration of China, and
submitted the evaluation report. Here is a brief description of the evaluation
report.>>

Was this report submitted to Mozilla and is it available to read generally?

<<
Key result: The software mentioned in the security threat analysis
report was developed by us and is available for users to download on the pages
of government agencies. It has been checked that the official release version of
the software does not contain any known spyware, nor is it infected by virus
programs. The issues mentioned in the security threat analysis report should be
considered as the necessary technical conditions for the normal operation of the
software. There are no malicious behaviors or backdoor functions when the
program is running, and the software is not spyware.
>>

I suppose my question is thus how do you define spyware in this context and in
particular, "known spyware", and what was the process for evaluating if it was
present? In my opinion there is a difference is whether or not a piece of software
happens to include components that match a signature of spyware or a virus in a
some database of known spyware, versus whether it exhibits behaviours
consistent with spyware.

<<
The key points of technical analysis are as follows:
(1) The software is a application security suite for digital certificates, which
aims to provide device driver of USB token and cross-browser cryptographic
middleware for end user. The software mainly consists of four parts: certificate
application component, certificate assistant, device driver and online
upgrading. The software, by setting itself as self-startup program and
periodical checking, discovers the USB token device promptly and ensures
third-party application softwares’ trust to BJCA certificate chain by
registering the Trusted Root Certificate in Windows operating system. And it
also support accesing the USB token based on mass storage protocol in the
browser by acting as an agent with listening to a local network port. The above
behaviors are dedicated technologies for the normal operation of the software,
should not be considered as malicious behaviors and backdoor functions.
>>

I can see how software that installs novel root certificates to the trusted root
store would be flagged as PUA. I'm surprised that in the value/risk analysis
a desire to not have to install new root certificates on peoples computer's this
way is not a more prominent component, instead it is more or less "to become a
globally trusted CA ... to secure a wide range of websites visited by Firefox
users".

<<
(2) The software does not include the zfkeymonitor.exe program, and does not
include the following suspected behaviors: disable security and backup services
not related to this software, record screenshots, read clipboard data, capture
and retrieve user keystrokes.
>>

I'm a bit unclear here. The Insikt report said that there was substantial
functional overlap, not that a zfkeymonitor.exe program was included exactly.
From my understanding, a file with sha256
bed0d1139adcec9292841b7315289bb43960f2c7a4ff1bbab536528b1317b075 was included
and multiple security vendors label it as a kind of PUA named zfkeymonitoring,
e.g.,
https://www.virustotal.com/gui/file/bed0d1139adcec9292841b7315289bb43960f2c7a4ff1bbab536528b1317b075/detection

So to clear this up, is it that this file as referenced above was in fact
included, but Microsoft and others are incorrect to label it as they did? Or is
this code-signed file not actually included in the first place? The Insikt
report appears to be primarily static testing, meaning that code to record
screenshots, read clipboard, etc., was present in the library but their testing
did not seem to check whether such code actually ran during testing. Is it the
case that the code was present but never used, or that this code didn't exist at
all?

<<
Finally, it should also be noted that the software involved in the security
threat analysis report does not include the BJCA Global Root CA1 & BJCA Global
Root CA2 certificate chain. We follow the requirements of the relevant
guidelines of the CA/B forum for BJCA’s publicly trusted certificate chain. For
better user convenience, we have applied for the Root Program of Mozilla,
Microsoft, Apple, and Google.
>>

I'm not sure I understand this. The software did install new root certificates,
but it is not the same root certificates that you are attempting to add to Mozilla's
program?

Thanks
Joel Reardon

[Jeffrey Walton]

On Mon, Dec 5, 2022 at 12:40 PM Prof. Reardon <joel.r...@ucalgary.ca> wrote:
>
> ...

> <<
> The key points of technical analysis are as follows:
> (1) The software is a application security suite for digital certificates, which
> aims to provide device driver of USB token and cross-browser cryptographic
> middleware for end user. The software mainly consists of four parts: certificate
> application component, certificate assistant, device driver and online
> upgrading. The software, by setting itself as self-startup program and
> periodical checking, discovers the USB token device promptly and ensures
> third-party application softwares’ trust to BJCA certificate chain by
> registering the Trusted Root Certificate in Windows operating system. And it
> also support accesing the USB token based on mass storage protocol in the
> browser by acting as an agent with listening to a local network port. The above
> behaviors are dedicated technologies for the normal operation of the software,
> should not be considered as malicious behaviors and backdoor functions.
> >>
>
> I can see how software that installs novel root certificates to the trusted root
> store would be flagged as PUA. I'm surprised that in the value/risk analysis
> a desire to not have to install new root certificates on peoples computer's this
> way is not a more prominent component, instead it is more or less "to become a
> globally trusted CA ... to secure a wide range of websites visited by Firefox
> users".

One comment based on Dr. Reardon's observations.

When the Windows installer runs, is there an option to forgo or not
install the "Root Certificate Updates" functionality? As a person who
has written Windows installers, I would expect an installer option to
forgo Root Certificate installation and updates. If the user is not
informed, or the option is not present, or the installation happens
surreptitiously, then it would raise my suspicions.

And there's always the option to add the certificate and updates to
the current user's Personal store rather than the machine's Trusted
Roots or Trusted Third Party stores.

Jeff

[Prof. Reardon]

I was planning to wait for a response before following up but it seems to be taking some time so it may make more sense to ask questions in parallel instead.

In the link that Kurt provided it was stated "Foreign companies operating in China need the Beijing One Pass app, to access a digital platform for managing government employee benefits." I wanted clarity into the meaning of "need" in that context. That is, who would be examples of people who would be installing this software on their computer, and what other options would they have if they didn't want to install it. Is "need" referring to a necessarily piece of software in order to complete required tasks for economic participation of such firms? If it is being installed on computers of employees at foreign companies, what would be the typical ranks and occupations of those employees installing it? Is it the case that, e.g., only one computer would need to include it at the organization? Jeff makes an excellent point that should be considered in this context, which is whether those installing the software had the option to leave their system's trusted root stores unaltered during the process of installation. Can you share the screenshots from the user's perspective of the installation process?

Another question related to the link from Kurt: the "Foreign companies" part. Is the article just saying that foreign companies have to install this (but actually all companies have to install it, and foreign ones are a subset) or is this software that alters the system root store specifically for foreign companies. If it is the latter, can you explain in detail why this would be the case?

Thanks,

Joel Reardon

[BJCA]

Thank you all, reply one by one:

1. Was this report submitted to Mozilla and is it available to read generally?

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.

2. I suppose my question is thus how do you define spyware in this context and in particular, "known spyware", and what was the process for evaluating if it was present? In my opinion there is a difference is whether or not a piece of software happens to include components that match a signature of spyware or a virus in a some database of known spyware, versus whether it exhibits behaviours consistent with spyware.

We understand that "Spyware is software with malicious behaviour that aims to gather information about a person or organization and send it to another entity in a way that harms the user". Whether it is spyware is mainly to evaluate whether it behaves consistent with spyware. After analysis, we found that 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 devide 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) provided by BJCA. This measure will help our software out from being judged as spyware.

3. I can see how software that installs novel root certificates to the trusted root store would be flagged as PUA. I'm surprised that in the value/risk analysis a desire to not have to install new root certificates on peoples computer's this way is not a more prominent component, instead it is more or less "to become a globally trusted CA ... to secure a wide range of websites visited by Firefox users".

This is exactly the reason why we apply for root inclusion, so that the issued SSL certificate can be automatically trusted by Mozilla, Microsoft, Apple, and Google, so the user experience could be improved. It must be noted that our software needs to provide services for different types of users. In addition to SSL certificates, the certificates issued by our company have a wide range of uses, including document signing, identity authentication, etc. Registering the root certificate to the operating system can bring convenience for users to use certificates.

4. I'm a bit unclear here. The Insikt report said that there was substantial functional overlap, not that a zfkeymonitor.exe program was included exactly.

From my understanding, a file with sha256 bed0d1139adcec9292841b7315289bb43960f2c7a4ff1bbab536528b1317b075 was included and multiple security vendors label it as a kind of PUA named zfkeymonitoring, e.g.,

https://www.virustotal.com/gui/file/bed0d1139adcec9292841b7315289bb43960f2c7a4ff1bbab536528b1317b075/detection

So to clear this up, is it that this file as referenced above was in fact included, but Microsoft and others are incorrect to label it as they did? Or is this code-signed file not actually included in the first place? The Insikt report appears to be primarily static testing, meaning that code to record screenshots, read clipboard, etc., was present in the library but their testing did not seem to check whether such code actually ran during testing. Is it the case that the code was present but never used, or that this code didn't exist at all?

Our software contains drivers from multiple certificate device vendors, resulting in overlapping functionality. The SHA256 digest mentioned here points to the certificate application environment installation package developed by our company. In fact, our software does not include the zfkeymonitor.exe program.

5. I'm not sure I understand this. The software did install new root certificates, but it is not the same root certificates that you are attempting to add to Mozilla's program?

The root certificate installed by this software is not used for the application of the SSL server certificate, but for other purposes. Therefore, the software does not include the BJCA Global Root CA1 and BJCA Global Root CA2 certificate chains in the Mozilla root include case, nor does it attempt to add them to browser programs.

6. When the Windows installer runs, is there an option to forgo or not install the "Root Certificate Updates" functionality? As a person who has written Windows installers, I would expect an installer option to forgo Root Certificate installation and updates. If the user is not informed, or the option is not present, or the installation happens surreptitiously, then it would raise my suspicions.

And there's always the option to add the certificate and updates to the current user's Personal store rather than the machine's Trusted Roots or Trusted Third Party stores.

The BJCA certificate environment software will write the BJCA root certificate into the certificate store trusted by the system during installation. If you choose not to install the root certificate when installing the root certificate, some functions of the BJCA certificate will be abnormal, which has caused a large number of user complaints.

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.

Regards,
BJCA team

[Kurt Seifried]

Uh, I just realized. How can we confirm that wash...@gmail.com is indeed BJCA? Don't you have email setup on your domain? 

I'm sorry but we're supposed to believe you are capable of running a root CA when you can't even do a basic email address setup with your own domain? 

--

You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/95c6ef70-2086-49bc-9713-bb25cd30724dn%40ccadb.org.

[passerby184]

in contest of the gmail, aren't it blocked in china GFW? not sure how they works as this google groups would be blocked too though.

2022년 12월 11일 일요일 오전 2시 5분 21초 UTC+9에 ku...@seifried.org님이 작성:

[Prof. Reardon]

Regarding these remarks:

<< 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. >>

and << obvious contradiction between convenience and security, which could

improve the software security but degrades the user experience and increase our
operation costs. >>

While security and convenience are indeed often at odds, the idea that a
prospective root certificate authority views it an unnecessary inconvenience to
obtain informed consent from users before installing a new trusted root
certificate into the operating system is deeply troubling to me. It does not
convey to me a sense of responsibility and gravity about the role of globally
trusted root certificate authority.

I would be interested to know, were users given the option to not install the
certificates and, consequently, << some functions of the BJCA certificate will
be abnormal >>, what those functions are and why no other option (e.g.,
involving a root CA already trusted) were not possible to implement. How did it
become the case that installing new operating system roots without user
confirmation was seen as the most trustworthy approach?

Also to clarify: the roots installed by the software are not the same as the
ones being applied for in the program, and those those software root will still need to
be installed for << wide range of uses, including document signing, identity
authentication, etc. >>? These roots have no relation to this inclusion
request, which is only for the reason that BJCA wishes << to become a globally
trusted CA ... to secure a wide range of websites visited by Firefox users >>?

Thanks,

Joel Reardon

[Kurt Seifried]

Especially as there are ways around this, e.g. this thread from Gossithedog:

https://cyberplace.social/@GossiTheDog/109490609421745698

That admittedly can result in even worse security outcomes, but I would argue that band-aiding this by minting more CAs is not the solution. 

[Kurt Seifried]

In light of my inability to find any link/proof that wash...@gmail.com is actually a representative of BJCA:

Nothing in google (well one result now, linking to a Mastodon posting about this whole situation)

Nothing on BJCA's website

https://bugzilla.mozilla.org/show_bug.cgi?id=1647181 

https://bugzilla.mozilla.org/user_profile?user_id=663695

Can we actually get confirmation that wash...@gmail.com is officially representing BJCA? 

[Kurt Seifried]

It's been 3 days. I thought the CA's had committed to replying and participating in a timely manner or did I misunderstand this?

[BJCA]

I'm sorry that the response to the above questions was slow, because we needed internal research and analysis on some problems, which delayed some time. We will speed up the response efficiency in the future.

Thank you very much, and I agree with the relevant expert opinions of on PKI best practices. We have summarized the discussed issues, and made the following replies:

1. The Mozilla root includes the root certificate in the case and the Beijing One Pass certificate respectively belong to two independent electronic certification systems of BJCA. Based on the difference between the supervision of the electronic certification service system and the application scenario, BJCA has established two types of independent electronic certification systems:

i. The global certification system, which follows the WebTrust international standards and the relevant standards and specifications issued by the CA/Browser Forum, aims to issue and manage publicly trusted SSL certificates.

ii. The national trusted source certification system, which follows the relevant standards and specifications issued by the national competent authority, and aims to issue and manage personal certificates, enterprise certificates and equipment certificates. (Beijing One Pass certificate is issued by the national trusted source certification system)

2. We agree that registering the root certificate to the OS or Browser trust list does not comply with the security rules of the public trust system, but due to the following conditions, we cannot solve the certificate chain problem of Beijing One Pass by applying for root inclusion case, for example:

i. The certificate issued by the BJCA national trust source certification system contains the SM2 algorithm, which is currently not an algorithm approved by the root storage policy;

ii. The BJCA national trust source certification system is mainly subject to the supervision and management of the national competent authority, and obtaining the Electronic Authentication Service License issued by the government; (WebTrust audit certification is optional)

iii. The PKI framework of the BJCA national trusted source certification system is not suitable for issuing publicly trusted SSL certificates.

To sum up, the BJCA Global Root CA1 and BJCA Global Root CA2 in the Mozilla root inclusion case are the root certificates of the BJCA global certification system. They have passed the WebTrust audit certification for many years since they were generated, and have obtained WebTrust for CA, BR SSL, EV SSL audit report.

Although Beijing One Pass certificate and subsequent software do not belong to the WebTrust public trust system, we 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.

3. Beijing One Pass certificate is an Enterprise certificate issued by the BJCA national trust source certification system. A brief description:

i. The certificate is applicable to enterprise users registered in Beijing, China. Users can log in to the Beijing One Pass service system with the certificate to declare social security and other information. For social security declaration, it is usually required to be installed by the staff engaged in the work of the human resources department;

ii. Usually only need to be installed on one computer of the enterprise;

iii. The main purpose of installing the root certificate is to create a complete authentication chain from the certificate to the root certificate when logging in. If the user does not install the root certificate, the user will not be able to log in to the service system. We plan to adopt advanced options in the new version of the software, allowing users to choose whether to install, 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;

iv. In addition to the certificate, the user can also choose the user name and password to log in to the service system.

4. BJCA has filed the root inclusion case contact information in CCADB, and the registered contact person has registered a Bugzilla account with the company domain name email address to submit the root inclusion case to Mozilla. We have already sent an email to Mozilla filed contact email address, stating that the account (wash...@gmail.com) participating in the Google Forum discussion represents BJCA.

Regards,
BJCA team

[Kurt Seifried]

Simple question: how do we confirm wash...@gmail.com is actually authorized to speak on behalf of bjca.cn? Thanks. 

[BJCA]

Thanks Kurt. When the discussion group responds, the "reply author" button is not available, so we responded by selecting "reply all".
When registering for a Google account using the company domain email (c...@bjca.org.cn), we encountered problems such as not being able to receive the verification code. We have made a explanation with the Mozilla root program manager Ben through an email to confirm that participating in the Google Forum's account (Wash...@gmail.com) on behalf of BJCA.

Regards,
BJCA team

[Kurt Seifried]

So how do we confirm this gmail represents the CA? Can you add a web page or dns record indicating that this gmail address is legitimate? Heck, why can’t you issue yourself an ssl certificate for your domain and sign something and include it in the message?

On Dec 16, 2022, at 3:56 AM, BJCA <wash...@gmail.com> wrote:

Thanks Kurt. When the discussion group responds, the "reply author" button is not available, so we responded by selecting "reply all".

[BJCA]

Thanks Kurt. We have sent you an email via our company domain email (c...@bjca.org.cn), At the same time, we added TXT records of "mozilla-root-inclusion-auxiliary-contact=wash...@gmail.com" to the DNS servers of bjca.cn and bjca.org.cn for auxiliary inspection.

Regards,
BJCA team

[Ben Wilson]

All,

This is a reminder that the public discussion period on the inclusion application of Beijing CA will close next Wednesday, on January 11, 2023.

Thanks,

Ben

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/34f78ee0-8377-49d8-998f-601e717e83b7n%40ccadb.org.

[Kurt Seifried]

I'm wondering if in addition this email thread(s) we should have a spreadsheet or document to collate the questions and answers, I feel like many of the questions asked here haven't been clearly or adequately answered. I think this would help collect and summarize these discussions in general. 

E.g.:

1. Was this report submitted to Mozilla and is it available to read generally?

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.

When you're an entity asking billions of people to trust you, EVERYTHING matters. This whole "oh that, it's confidential so you can't talk about it" is problematic.

Why should we trust you when your company has already been involved in activities that violate the trust of people, and your response when asked is "it is not suitable for disclosure or submission to Mozilla because it involves confidential information" sounds a lot like "yes we got caught but you're not supposed to know about it!"

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaYLdOmasuSyumsWaM04T6JAUc8eP_T9W6XwEbsRNVzj_w%40mail.gmail.com.

[BJCA]

Thanks Kurt for your questions and suggestions. We are sorry that we have no right to disclose this report. In the previous threads we have provided dedicated responses including the main points of this report to the concerning issues of the Beijing One Pass app. We might discuss more technical details if necessary. We have maintained effective controls for the SSL/CodeSigning/DocSigning certification services in accordance with the BR and WebTrust Principles. At this time the Beijing One Pass app is not included in our Publicly-Trusted System, hence we are ultilizing a secruity strategy which is not meeting the security requirements of the Publicly-Trusted System. We agree that we should not prefer the convenience in the tradeoff between security and convenience. We will enlarge the coverage of our business to comply with Publicly-Trusted System and re-design the security rules of the Beijing One Pass app.

[Kurt Seifried]

On Sun, Jan 8, 2023 at 2:11 AM BJCA <wash...@gmail.com> wrote:

Thanks Kurt for your questions and suggestions. We are sorry that we have no right to disclose this report. In the previous threads we have provided dedicated responses including the main points of this report to the concerning issues of the Beijing One Pass app. We might discuss more technical details if necessary. We have maintained effective controls for the SSL/CodeSigning/DocSigning certification services in accordance with the BR and WebTrust Principles. At this time the

Can you please provide links to the specific principles you're referring to (e.g. which ones and which version are you referring to n this statement)?

 

Beijing One Pass app is not included in our Publicly-Trusted System, hence we are ultilizing a secruity strategy which is not meeting the security requirements of the Publicly-Trusted System. We agree that we should not prefer the convenience in the tradeoff between security and convenience. We will enlarge the coverage of our business to comply with Publicly-Trusted System and re-design the security rules of the Beijing One Pass app.

So to confirm: you are trying to implement technical controls to protect your CA, but from a business controls perspective they are under control from the same legal business entity, correct?

[BJCA]

Thanks Kurt, reply one by one:
1.Can you please provide links to the specific principles you're referring to (e.g. which ones and which version are you referring to n this statement)?
The certificate Policy and Practices for BJCA to effective controls for the SSL/CodeSigning/DocSigning certification services in accordance with the BR and WebTrust Principles are the BJCA Global CP and CPS.
BJCA Global CP and CPS are also applicable to the root certificate in the Mozilla root inclusion case. The relevant documents are as follows:
i. Beijing Certificate Authority Co., Ltd. Global Certificate Policy, v. 1.0.6, dated July 25, 2022
ii. Beijing Certificate Authority Co., Ltd. Global Certification Practice Statement, v. 1.0.6, dated July 25, 2022
BJCA Global Certification system has passed WebTrust audit certification, and the latest audit report is as follows:
i. WebTrust for CAs
https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=389f5843-e05f-4e80-aae0-23cee8922866
ii. WebTrust for CAs - SSL Baseline with Network Security
https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=2c0c075a-0000-40f1-8a81-1ccb21268e62
iii. WebTrust for CAs - EV SSL
https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=78bb08b0-7523-4011-b27c-b8a1a978433e
2.So to confirm: you are trying to implement technical controls to protect your CA, but from a business controls perspective they are under control from the same legal business entity, correct?
Yes. Based on the difference between the supervision of the electronic certification service system and the application scenario, BJCA has established two independent electronic certification systems: global certification system and national trusted source certification system. The above electronic certification systems are controlled by BJCA.

[Ben Wilson]

All,

On November 30, 2022, we began a six-week, public discussion on the request from Beijing Certificate Authority Co., Ltd. (BJCA) for inclusion of two root certificates:

• BJCA Global Root CA1 

• BJCA Global Root CA2 

That public discussion period has ended.

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: 

1. a global, public-trust system that meets international standards (WebTrust, CA/Browser Forum, etc.) and issues and manages SSL/TLS server certificates; and 

2. 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).

Thanks,

Ben Wilson