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, <https://www.bjca.cn/u4d/%E8%AF%81%E4%B9%A6%E7%AD%96%E7%95%A5%EF%BC%88CP%EF%BC%89/files/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E8%AF%81%E4%B9%A6%E7%AD%96%E7%95%A5%20Beijing%20Certificate%20Authority%20Co.,%20Ltd.%20Global%20Certificate%20Policy.pdf> v. 1.0.6, dated July 25, 2022 ii. Beijing Certificate Authority Co., Ltd. Global Certification Practice Statement, <https://www.bjca.cn/u4d/%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99%EF%BC%88CPS%EF%BC%89/files/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99%20Beijing%20Certificate%20Authority%20Co.,%20Ltd.%20Global%20Certification%20Practice%20Statement.pdf> 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. 在2023年1月9日星期一 UTC+8 06:05:14<[email protected]> 写道：
> On Sun, Jan 8, 2023 at 2:11 AM BJCA <[email protected]> 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? > > >> >> 在2023年1月7日星期六 UTC+8 08:16:32<[email protected]> 写道： >> >>> 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!" >>> >>> >>> >>> >>> On Fri, Jan 6, 2023 at 2:30 PM Ben Wilson <[email protected]> wrote: >>> >>>> 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 >>>> >>>> On Sat, Dec 17, 2022 at 3:44 AM BJCA <[email protected]> wrote: >>>> >>>>> Thanks Kurt. We have sent you an email via our company domain email ( >>>>> [email protected]), At the same time, we added TXT records of >>>>> "[email protected]" to the >>>>> DNS servers of bjca.cn and bjca.org.cn for auxiliary inspection. >>>>> >>>>> Regards, >>>>> BJCA team >>>>> 在2022年12月16日星期五 UTC+8 22:09:43<[email protected]> 写道： >>>>> >>>>>> 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 <[email protected]> wrote: >>>>>> >>>>>> 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 ( >>>>>> [email protected]), 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 ([email protected]) on behalf of BJCA. >>>>>> >>>>>> Regards, >>>>>> BJCA team >>>>>> 在2022年12月16日星期五 UTC+8 12:34:42<[email protected]> 写道： >>>>>> >>>>>>> Simple question: how do we confirm [email protected] is actually >>>>>>> authorized to speak on behalf of bjca.cn >>>>>>> <https://www.google.com/url?q=http://bjca.cn&source=gmail-imap&ust=1671792992000000&usg=AOvVaw3ByniILH7_ZBCfnC40uNoa>? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On Thu, Dec 15, 2022 at 7:37 PM BJCA <[email protected]> wrote: >>>>>>> >>>>>>>> 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 ([email protected]) >>>>>>>> participating in the Google Forum discussion represents BJCA. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> BJCA team >>>>>>>> >>>>>>>> 在2022年12月16日星期五 UTC+8 02:18:39<[email protected]> 写道： >>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> On Mon, Dec 12, 2022 at 9:53 AM Kurt Seifried <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> In light of my inability to find any link/proof that >>>>>>>>>> [email protected] 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://www.google.com/url?q=https://bugzilla.mozilla.org/show_bug.cgi?id%3D1647181&source=gmail-imap&ust=1671792992000000&usg=AOvVaw0b1SxlVMRsjZsJZ6CfnJIs> >>>>>>>>>> >>>>>>>>>> https://bugzilla.mozilla.org/user_profile?user_id=663695 >>>>>>>>>> <https://www.google.com/url?q=https://bugzilla.mozilla.org/user_profile?user_id%3D663695&source=gmail-imap&ust=1671792992000000&usg=AOvVaw1y4uS658D2-pgc_nfmTPAP> >>>>>>>>>> >>>>>>>>>> Can we actually get confirmation that [email protected] is >>>>>>>>>> officially representing BJCA? >>>>>>>>>> >>>>>>>>>> On Sat, Dec 10, 2022 at 10:04 AM Kurt Seifried < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Uh, I just realized. How can we confirm that [email protected] >>>>>>>>>>> is indeed BJCA? Don't you have email setup on your domain? >>>>>>>>>>> >>>>>>>>>>> [image: Screenshot 2022-12-10 100338.png] >>>>>>>>>>> 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? >>>>>>>>>>> >>>>>>>>>>> On Sat, Dec 10, 2022 at 1:42 AM BJCA <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> <https://www.google.com/url?q=https://www.virustotal.com/gui/file/bed0d1139adcec9292841b7315289bb43960f2c7a4ff1bbab536528b1317b075/detection&source=gmail-imap&ust=1671792992000000&usg=AOvVaw3pPOOAc5mQLxYb1fygHMoV> >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> 在2022年12月6日星期二 UTC+8 02:51:24<[email protected]> 写道： >>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Dec 5, 2022 at 12:40 PM Prof. Reardon < >>>>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> <https://www.google.com/url?q=https://groups.google.com/a/ccadb.org/d/msgid/public/95c6ef70-2086-49bc-9713-bb25cd30724dn%2540ccadb.org?utm_medium%3Demail%26utm_source%3Dfooter&source=gmail-imap&ust=1671792992000000&usg=AOvVaw0lQZT56Clkanfby6FSy3Pn> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Kurt Seifried (He/Him) >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Kurt Seifried (He/Him) >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Kurt Seifried (He/Him) >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kurt Seifried (He/Him) >>>>>>> [email protected] >>>>>>> >>>>>> -- >>>>> 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 [email protected]. >>>>> 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 >>>>> >>>>> <https://groups.google.com/a/ccadb.org/d/msgid/public/34f78ee0-8377-49d8-998f-601e717e83b7n%40ccadb.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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 [email protected]. >>>> >>> 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 >>>> >>>> <https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaYLdOmasuSyumsWaM04T6JAUc8eP_T9W6XwEbsRNVzj_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> Kurt Seifried (He/Him) >>> [email protected] >>> >> > > -- > Kurt Seifried (He/Him) > [email protected] > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/95c68442-e13f-4e85-86a1-e499d5544c65n%40ccadb.org.
