Public Discussion re: Inclusion of the iTrusChina Root CAs

1713 views
Skip to first unread message

Ben Wilson

unread,
Apr 7, 2021, 2:49:42 PM4/7/21
to dev-secur...@mozilla.org

This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for iTrusChina’s vTrus Root CA and its vTrus ECC Root CA.  See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9).

These Root CAs  are operated by iTrusChina Co., Ltd.

This current CA inclusion application has been tracked in the CCADB and in Bugzilla–

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000431

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

These new root CA certificates are valid from 2018 to 2043, and they are proposed for inclusion with the websites bit and EV enabled.

Mozilla is considering approving iTrusChina’s request. This email begins the 3-week comment period, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10).

Root Certificate Information:

vTrus Root CA (RSA)

    crt.sh -
https://crt.sh/?q=8A71DE6559336F426C26E53880D00D88A18DA4C6A91F0DCB6194E206C5C96387

Download –

http://wtca-cafiles.itrus.com.cn/ca/vTrusRootCA.cer

vTrus ECC Root CA (ECC)

    crt.sh –

https://crt.sh/?q=30FBBA2C32238E2A98547AF97931E550428B9B3F1C8EEB6633DCFA86C5B27DD3

http://wtca-cafiles.itrus.com.cn/ca/vTrusECCRootCA.cer

CP/CPS:   

iTrusChina’s current CPS is v.1.4.4 / Dec. 19, 2020

https://www.itrus.com.cn/uploads/soft/201223/2-201223110436.pdf

Repository location:   

https://www.itrus.com.cn/repository

iTrusChina's 2021 BR Self-Assessment (PDF) is located here: 

https://bugzilla.mozilla.org/attachment.cgi?id=9209938

Audits: 

iTrusChina’s WebTrust auditor is PricewaterhouseCoopers Zhong Tian LLP, and the most recent audit reports are dated March 24, 2021. These audit reports may be downloaded by clicking on the WebTrust seals at the bottom of iTrusChina’s repository page.

Incidents:

I was not able to find any incidents involving iTrusChina, no misissuances were found under the iTrusChina root CAs, and the issuing CAs appeared to be properly formatted.

Thus, this email begins a three-week public discussion period, which I’m scheduling to close on or about 30-April-2021.

A representative of iTrusChina must promptly respond directly in the discussion thread to all questions that are posted.

Sincerely yours,

Ben Wilson

Mozilla Root Program

Ryan Sleevi

unread,
Apr 7, 2021, 3:01:25 PM4/7/21
to Ben Wilson, dev-secur...@mozilla.org
Ben,

I'm not used to parallel discussions for adding CAs. May I request that you put this discussion on hold until the conclusion of TunTrust? Or is this an intentional attempt to parallelize more, despite the limited resources? 

Ben Wilson

unread,
Apr 7, 2021, 3:39:09 PM4/7/21
to Ryan Sleevi, dev-secur...@mozilla.org
Ryan,
Yes, I think it is an intentional effort to process multiple applications simultaneously. As I was moving CA applicants through the queue these two just seemed to both be ready at about the same time. It was more efficient for me to handle these two at once.  Note that we also have Asseco/Certum with public discussion closing next week (4/14/2021). I'll repost that to this list right now so that there is continuity on this list.  Let's see how this goes. If it presents a problem, then we can adjust.
Ben

Ryan Sleevi

unread,
Apr 7, 2021, 3:52:39 PM4/7/21
to Ben Wilson, Ryan Sleevi, dev-secur...@mozilla.org
Thanks for clarifying.

In a personal capacity, while I can understand that Mozilla may have reached a level of confidence that they can handle processing these requests in parallel, I don't believe it's reasonable to expect the same of the community, since these public discussions may be the first time a number of members of the community are examining CAs in depth. This practically impacts both the quality and depth of review, as it effectively requires the community make larger and larger time commitments to handle all such reviews, or reduces the amount of time and effort focused on an individual CA.

Wearing a Google hat, Honestly, I don't think we'll be able to offer feedback here for both CAs in a parallel (time-gated) review. We'll examine the available data to help prioritize against our own stated policies, but I think realistically, we may request that the CA that does not align most with the priorities undergoes an additional public discussion when we're ready to proceed. We see significant risk to our users from trying to include CAs too quickly, and so want to make sure as much as possible that all CAs receive the same level of attention and thoroughness by dedicating specific time to focus on just a single CA.

It's an entirely reasonable goal, but the effect of running these in parallel does not mean both CAs undergo three weeks of review; it means both CAs undergo a week and a half, or less, since these processes do not linearly scale, nor should they.

Ben Wilson

unread,
Apr 20, 2021, 2:19:41 PM4/20/21
to Ryan Sleevi, dev-secur...@mozilla.org
Hi Ryan,
Kathleen and I discussed iTrusChina's and TunTrust's root inclusion applications this morning and agreed that we should extend the public discussion period and leave them open for discussion beyond April 30th. Meanwhile, I will work on follow-up questions for them regarding their added value to users vs. added risk.
Thanks,
Ben

Andrew Ayer

unread,
May 21, 2021, 9:22:59 AM5/21/21
to dev-secur...@mozilla.org
On Wed, 7 Apr 2021 12:49:29 -0600
Ben Wilson <bwi...@mozilla.com> wrote:

> https://crt.sh/?q=8A71DE6559336F426C26E53880D00D88A18DA4C6A91F0DCB6194E206C5C96387

> https://crt.sh/?q=30FBBA2C32238E2A98547AF97931E550428B9B3F1C8EEB6633DCFA86C5B27DD3

crt.sh reports verification errors for these roots' CRLs, which I was
able to reproduce using the openssl command. Could iTrusChina
investigate and file an incident report about this?

Regards,
Andrew

yutian zheng

unread,
May 24, 2021, 10:50:01 AM5/24/21
to dev-secur...@mozilla.org, Andrew Ayer
Hi Andrew,

We have submitted this issue to our security and R&D team and started the investigation,and we will release the incident report later today.

Regards,
Yutian Zheng
iTrusChina Co.,Ltd.

yutian zheng

unread,
May 24, 2021, 11:21:33 PM5/24/21
to dev-secur...@mozilla.org, yutian zheng, Andrew Ayer
Our R&D team has investigated this issue and found the problem. I published an incident report in bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1712664, we will add more details and progress on this page later.

yutian zheng

unread,
Jul 4, 2021, 9:11:40 PM7/4/21
to dev-secur...@mozilla.org, bwi...@mozilla.com, dev-secur...@mozilla.org, Ryan Sleevi

Hi All,

iTrusChina submitted a document to answer a series of questions in Quantifying Value:

attachment.cgi (bug1554846.bmoattachments.org)

Regards,
vTrus team

Ben Wilson

unread,
Aug 10, 2021, 11:20:55 AM8/10/21
to dev-secur...@mozilla.org, Ryan Sleevi, yutian zheng
All,
Are there any additional comments?
Thanks,
Ben

Ben Wilson

unread,
Aug 12, 2021, 2:17:48 PM8/12/21
to dev-secur...@mozilla.org

All,

Here is my summary of iTrusChina's value justification. Please provide any clarifications or additional comments you may have.

Ownership-Management Structure

iTrusChina (iTC) was established in 2000 as the Beijing Tianwei Chengxin Electronic Commerce Service Co., Ltd. (https://m.itrus.com.cn/about/history/). It was approved by the Chinese Ministry of Industry and Information Technology and State Cryptography Administration. The company is owned by four natural persons and one partnership. Here is what I have been able to glean about the governance structure from iTC's value justification - https://bugzilla.mozilla.org/attachment.cgi?id=9229617:

Board of Directors

|

Security Policy Administration Committee

| | | | | |

Compliance R&D Authentication Business O&M Product Dept.

The Security Policy Administration Committee (SPAC) is the lead department for security and compliance issues, and is responsible for the overall coordination of the iTC's internal resources. It determines priorities for the product and R&D departments and reviews and approves rectification results. The SPAC conducts two-person review of all operations performed by operating team.

User Base

iTC users account for more than half of Chinese market of personal and corporate certificates (480 million). Main customers are Alibaba, Tencent, JD.com, Industrial and Commercial Bank of China, Bank of China, and China Construction Bank.

Finances - Budgeting

iTC originally invested $3.09 million in 2001. It invested 2 million yuan in 2017 for WebTrust audits and compliance transformations of its facilities. Continuous investment in fixed assets and operating expenses is about US$310,000 per year.

iTC's compliance budget includes personnel costs, audit costs, infrastructure construction and renovation costs, and is determined annually based on factors such as risk assessment, audit status, and software improvement plans for R&D.

With the increase in the number of certificates issued each year, iTC will increase the investment in compliance each year, including the investment budget for the training of personnel familiar with CABF and IETF standards and legal-related training. When faced with compliance issues, if the overall budget set at the beginning of the year is exceeded, it will be approved by the board.

Personnel Expense (R&D/O&M/security/verification/customer service/compliance teams)

2018 2019 2020 2021 (5 months)

$0.83M $1.07M $1.17M $0.68M

R&D team consists of 66 people (incl. 18 for CA system development, 3 for testing, and 6 for WebTrust business and authentication system development).

CA System and System Development

iTC operates a fully self-developed CA software system with a replica test environment for development and testing to ensure compliance. iTC’s CA system is designed based on CA/Browser Forum requirements and the RFCs and conforms to the Specification of cryptograph and related security technology for certificate authentication systems of the National Cryptographic Standards Committee of China (GB/T 25056-2018 Information Security Technology) and "GM/T 0037-2014 Certificate authority system test specification".

iTC designs product and system changes in accordance with privacy, security, and compliance requirements. iTC uses an agile (scrum) development process. Each iteration cycle is generally 1-4 weeks.

Compliance Team and Personnel

iTC’s Compliance team follows domestic and foreign compliance standards and specifications, and regularly updates internal documentation. There are two bilingual persons who follow changes in the CA industry requirements on a daily basis. The compliance team summarizes Bugzilla CA incidents quarterly and circulates an industry dynamic tracking report to relevant personnel every month. iTC conducts self-inspections and trains personnel to avoid similar errors. Going forward, iTC will train more compliance personnel and conduct more regular training for team members of authentication, R&D, and business departments.

iTC has 20 years of risk compliance experience and personnel with comparable management experience and appears to have a sufficient number of key personnel familiar with CABF and IETF standards.

Authentication Team

This team conducts monthly training on authentication procedures and industry standards, and conducts compliance audits on internal documents, certificate issuance and revocation records on a monthly basis.

R&D Team

This team integrates lint tests in the CA system for certificate issuance compliance inspection. R&D team inspects CA system at design level and performs unit testing and examines results of other testing processes.

Operation Team

This team operates and monitors the availability of all CA-related services.

Monitoring and Alerting

iTC has continuous automatic monitoring to detect and alert on any changes to the CA/RA system, and it responds to and solves the problem within 24 hours after receiving the alert. iTC uses three kinds of lint tests: zlint, certlint, x509lint. iTC conducts automatic inspection of CAA, blacklist, and high-risk list before the issuance of the certificate. The fortress machine records operations, and operation records are reviewed on a monthly basis.

Logs and backups

iTC logs/backs up:

1. Any CA operation and maintenance process in a bastion machine log. The log server backs up and archives every day and saves 2 backups, 1 remote backup, and 1 different device backup.

2. All business logs of CA, RA, etc. are backed up to the log server in real time.

3. regular CRL generation

Compliance Incidents

When a compliance incident occurs, the compliance team coordinates with the relevant business personnel to quickly initiate the investigation process within 24 hours and submit a problem report to Mozilla. The certificate that needs to be revoked after the investigation will be revoked within 24 hours after the incident.

Vulnerability Assessments

iTC conducts a vulnerability scan of the CA system every 3 months and a penetration test every year. Based on audit results, iTC also conducts vulnerability assessments of the system, physical site, operation management, and takes measures to reduce operational risks.

Risk Assessment

iTC's annual risk assessment is carried out by the operation and maintenance, product, development, and compliance teams. All internal and external audits include risk assessments. iTC's risk control refers to BR Chapter 5, including physical control, program control, personnel control, audit log program and other dimensions, and meets the WT audit requirements. iTC also follows the Chinese Ministry of Industry and Information Technology and the State Cryptography Administration’s formulated risk assessment and inspection standards.

Risk Control Team rates the risks, evaluate the impact on the business, and after the approval of the Security Policy Administration Committee, decides whether to undertake the risk and formulates a corresponding commitment plan.

Audits

The internal control team conducts WebTrust internal audits on a quarterly basis. External audits include:

· WebTrust audit by pwc

· ISO9001

· ISO27001

After reviewing iTrusChina's value justification, I would like to examine the compliance aspects of its budget a little closer, and I am wondering whether iTrustChina can provide something similar (or better) to that provided by TunTrust? See https://bugzilla.mozilla.org/attachment.cgi?id=9228562

Sincerely yours,

Ben

yutian zheng

unread,
Aug 13, 2021, 1:32:59 AM8/13/21
to dev-secur...@mozilla.org, bwi...@mozilla.com
Hi Ben,

Thanks for your advice, and we will give a more detailed budget list in the next few days.

Regards,
vTrus Team

yutian zheng

unread,
Aug 18, 2021, 3:53:47 AM8/18/21
to dev-secur...@mozilla.org, bwi...@mozilla.com
Hi Ben,

We added a document on our budget 2018-2021.


attachment.cgi (bug1554846.bmoattachments.org)

Regards,

vTrus Team


在2021年8月13日星期五 UTC+8 上午2:17:48<bwi...@mozilla.com> 写道:

Ben Wilson

unread,
Aug 18, 2021, 4:03:46 PM8/18/21
to dev-secur...@mozilla.org
Thanks to iTrusChina for providing a budget document. I will take a closer look at it. Meanwhile, do we have any additional comments or questions from the Mozilla Community?
Ben

Ryan Sleevi

unread,
Aug 23, 2021, 6:51:57 PM8/23/21
to Ben Wilson, dev-secur...@mozilla.org
Hi Ben,


There are a few things I wanted to call out and flag for further discussion/consideration:
  • Although the CCADB Policy does not require CAs make their CP/CPS authoritative in English, it does require that the CA attest the information is not materially different. In their CPS, 1.2, they clearly state that the English version is not authoritative, and that in any conflicts, the Chinese version prevails, but there's no such assurance about equivalence.
  • Section 3.1.6 states both that "Certificates issued by iTrusChina does not contain any trademarks or other information which may infringe other parties' rights" and that "iTrusChina don't validate trademark right or legal disputes when processing applications", which... seems to be conflicting.
  • Section 3.2.2.6 has an interesting statement regarding which entities are allowed to obtain wildcards; seemingly preventing them from DV certificates. This seems unfortunate and unnecessary, and while not prohibited, is at least something that stands out as perhaps misaligned in goals / understanding of the purpose of TLS certificates.
  • Section 3.2.2.6 also includes an interesting clause "If necessary, iTrusChina needs to adopt other independent authentication methods to confirm the ownership of a domain name." It's unclear if that's meant in addition to 3.2.2.4, or in lieu of 3.2.2.4.
  • Section 3.2.2.8 has a real red flag: "If the tag 'iodef' exists in CAA records, iTrusChina will determine whether to issue the certificate after communicating with the applicant".
    • It's unclear if they're treating this as permission to issue if the tag exists, which would be a BR violation.
    • If's unclear if they're redefining the semantics of iodef (which is used for exception reports / violations, not for permission)
  • Section 6.1.1.1 has a similar red flag "Since China has strict administration requirements on cryptographic products, FIPS 140-2 Standard is not a standard approved and supported by the State Cryptography Administration, FIPS 140-2 Standard is only enforced as a reference, selectively applicable on the premise of passing the evaluation and certification of the State Cryptography Administration and being licensed by national cryptography administration policies."
    • This reasonably calls into question the safety and security of the CAs' private keys. Similar remarks are found within Section 6.2.1.
  • Section 6.1.1.2 "If a subscriber submits a PKCS#10 file of a weak algorithm during application, iTrusChina will reject the application and recommend the user to generate a new key pair" - this proof of possession provides no benefit in the context of TLS, and so this is a rather silly check. This has been discussed in the past here on m.d.s.p.
  • Section 6.3.2 makes it clear that intermediates are generated very long (25 years), while the clear trend of industry has been moving towards shorted lived intermediates, and regularly rotating them, to ensure necessary certificate agility and robustness.
  • Section 7.1.2 is not that useful (e.g. the EKU for intermediates just says (paraphrased) "We'll put something here after 2019-01-01"). Similarly the notBefore/notAfter remarks.
Since they also issue EV certificates, and since it's mentioned in the CP/CPS, I also checked out their disclosure of EV validation sources, in https://www.itrus.com.cn/uploads/soft/210401/2-2104011K954.pdf

It's difficult to see this complying with 11.1.3 - rather than disclosing each Incorporating Agency / Registration Agency and associated meta-data, they appear to have broken each field down into possible permutations, leaving it unclear if it's subjected to combinatorial explosion here. It also appears to demonstrate some confusion about how the jurisdiction fields of an EV certificate work, judging by the disclosure, although this could be my own confusion with respect to jurisdictional issues in China. Without prejudice or opinion, it notes that one of the sources is the Unified Social Credit Code Certificate. It also lists Dun and Bradstreet as a source, which is highly questionable with respect to EV certificates and the use of qualified information sources.

Andrew previously noted https://bugzilla.mozilla.org/show_bug.cgi?id=1712664 during the public discussion, and that led to an opportunity for the CA to demonstrate its incident detection and response capabilities. In the course of that issue, it was determined that iTrusChina is running in-house developed CA software and that the issue was caused by bugs within that software. Within the bug, we see the unfortunately common struggle for CAs to go beyond simply "respond to the symptom", and instead perform a deeper analysis for the systems and processes that failed, and how to improve or strengthen them.

Although some of the issues highlighted above may very well be communication issues, there certainly are unmistakable elements of red flags of concern worth carefully consdering.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaasiS84aMHBw-qbsTDxko%3DahU-DjrhV84-v_HGpt1pchw%40mail.gmail.com.

yutian zheng

unread,
Aug 25, 2021, 2:48:32 AM8/25/21
to dev-secur...@mozilla.org, Ryan Sleevi, dev-secur...@mozilla.org, bwi...@mozilla.com

Hi Ryan,

Thank you very much for these questions, and we have checked our CP/CPS and corresponding business for these items, the answers are as follows:

1.      Although the CCADB Policy does not require CAs make their CP/CPS authoritative in English, it does require that the CA attest the information is not materially different. In their CPS, 1.2, they clearly state that the English version is not authoritative, and that in any conflicts, the Chinese version prevails, but there's no such assurance about equivalence.

iTrusChina’s CP/CPS has a strict Chinese and English correspondence, which can ensure that there is no substantial difference in information. We will modify the description here in the new version of CP/CPS.

New description: The Chinese version of this CPS is issued. iTrusChina sincerely guarantees that there is no materially difference between the Chinese and English versions of the information.

 

2.      Section 3.1.6 states both that "Certificates issued by iTrusChina does not contain any trademarks or other information which may infringe other parties' rights" and that "iTrusChina don't validate trademark right or legal disputes when processing applications", which... seems to be conflicting.

We will modify the description in the next version of CP/CPS.

New description: iTrusChina does not verify an Applicant’s right to use a trademark and does not resolve trademark disputes.

 

3.      Section 3.2.2.6 has an interesting statement regarding which entities are allowed to obtain wildcards; seemingly preventing them from DV certificates. This seems unfortunate and unnecessary, and while not prohibited, is at least something that stands out as perhaps misaligned in goals / understanding of the purpose of TLS certificates.

The description of 3.2.2.6 is indeed ambiguous and we will modify it. In fact, we are issuing DV wildcard certificates.

New description: Regarding a wildcard domain name, iTrusChina verifies the domain name on the right side of the wildcard to ensure that the domain name is clearly owned by the applicant.

 

4.      Section 3.2.2.6 also includes an interesting clause "If necessary, iTrusChina needs to adopt other independent authentication methods to confirm the ownership of a domain name." It's unclear if that's meant in addition to 3.2.2.4, or in lieu of 3.2.2.4.

We only use the domain verification method mentioned in 3.2.2.4, so we think our description is indeed ambiguous, and we will delete it in the next version of CP/CPS.

 

5.      Section 3.2.2.8 has a real red flag: "If the tag 'iodef' exists in CAA records, iTrusChina will determine whether to issue the certificate after communicating with the applicant".

         It's unclear if they're treating this as permission to issue if the tag exists, which would be a BR violation.

         It's unclear if they're redefining the semantics of iodef (which is used for exception reports / violations, not for permission)

Our description of iodef is incorrect and will be revised in the next version of CP/CPS.

New description: When the certificate requests or issuances violate the security policy of the Issuer or the FQDN holder,if the tag "iodef" exists in CAA records, iTrusChina will dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s).

 

6.      Section 6.1.1.1 has a similar red flag "Since China has strict administration requirements on cryptographic products, FIPS 140-2 Standard is not a standard approved and supported by the State Cryptography Administration, FIPS 140-2 Standard is only enforced as a reference, selectively applicable on the premise of passing the evaluation and certification of the State Cryptography Administration and being licensed by national cryptography administration policies."

   This reasonably calls into question the safety and security of the CAs' private keys. Similar remarks are found within Section 6.2.1.

China has corresponding technology and testing standards for HSM. For compliance reasons, we must use HSM products from manufacturers licensed by the State Cryptography Administration. This requirement is also applicable to other licensed CAs in China. Our supplier's HSM products obtained FIPS 140-2 level 3 certification in 2019 (see attachment). If necessary, we can replace HSM later.

 

7.      Section 6.1.1.2 "If a subscriber submits a PKCS#10 file of a weak algorithm during application, iTrusChina will reject the application and recommend the user to generate a new key pair" - this proof of possession provides no benefit in the context of TLS, and so this is a rather silly check. This has been discussed in the past here on m.d.s.p.

There are some problems with our statement here. What we meant to express is that we will reject the application if we find that the subscriber is using a Debian weak key (as described in BR6.1.1.3), we will modify it in the next version CP/CPS.

 

8.      Section 6.3.2 makes it clear that intermediates are generated very long (25 years), while the clear trend of industry has been moving towards shorted lived intermediates, and regularly rotating them, to ensure necessary certificate agility and robustness.

At present, we have not formulated a policy for regular replacement of intermediate roots. Considering the agility and robustness of the certificate, we will issue new intermediate root certificates with a shorter age in the future.

 

9.      Section 7.1.2 is not that useful (e.g. the EKU for intermediates just says (paraphrased) "We'll put something here after 2019-01-01"). Similarly the notBefore/notAfter remarks.

iTrusChina plans to generate some intermediate CA certificates after 2019-01-01, and the intermediate certificates generated before this do not contain the EKU extension. According to the requirements of Mozilla's Root policy, the intermediate certificate generated after 2019-01-01 needs to include the EKU extension, so we have added this description.

 

10.   Regarding the issue of EV Certificates Registration Agency Disclosure, the data sources we disclose are not only EV certificates, but also information sources for all other types of SSL certificates. The Unified Social Credit Code Certificate and Dun and Bradstreet are used for the Subject field of the SSL certificate, iTrusChina's SSL business is currently only carried out in China, and D&B is only used to query applicants' English names. The third chapter of our document is dedicated to EV Certificates Registration Agency Disclosure.

11.   In addition, regarding https://bugzilla.mozilla.org/show_bug.cgi?id=1712664, we will complete the coding of the monitoring system this week, and then start the system test next week. We are very grateful to Andrew for raising the question and Ryan's suggestions for improvement. These are very helpful to us.


Regards,
vTrus Team
Sansec FIPS140-2 level 3.pdf

Ben Wilson

unread,
Aug 31, 2021, 11:56:30 PM8/31/21
to yutian zheng, dev-secur...@mozilla.org
Dear vTrus Team,
Do we have an estimate for when you might have an updated CPS ready for another review?
Thanks,
Ben

yutian zheng

unread,
Sep 1, 2021, 2:17:30 AM9/1/21
to dev-secur...@mozilla.org, bwi...@mozilla.com, yutian zheng
Dear Ben, 

We have completed the revision of the new version of CP/CPS and are going through the internal release process, which will be updated to our official website for review within a week.

Regards, 
vTrus Team

yutian zheng

unread,
Sep 6, 2021, 11:27:02 PM9/6/21
to dev-secur...@mozilla.org, bwi...@mozilla.com, yutian zheng
Hi Ben,

We have released the latest version of CP/CPS (CP v1.4.5, CPS v1.4.6) on our official website https://www.itrus.com.cn/repository/, please kindly review it, thanks. 

Regards,
vTrus Team

在2021年9月1日星期三 UTC+8 上午11:56:30<bwi...@mozilla.com> 写道:

Ben Wilson

unread,
Sep 7, 2021, 11:28:36 PM9/7/21
to yutian zheng, dev-secur...@mozilla.org, Ryan Sleevi
All,

My review of CPS v. 1.4.6 and other comments appear inline below.

On Wed, Aug 25, 2021 at 12:48 AM yutian zheng <zhengyu...@gmail.com> wrote:

Hi Ryan,

Thank you very much for these questions, and we have checked our CP/CPS and corresponding business for these items, the answers are as follows:

1.      Although the CCADB Policy does not require CAs make their CP/CPS authoritative in English, it does require that the CA attest the information is not materially different. In their CPS, 1.2, they clearly state that the English version is not authoritative, and that in any conflicts, the Chinese version prevails, but there's no such assurance about equivalence.

iTrusChina’s CP/CPS has a strict Chinese and English correspondence, which can ensure that there is no substantial difference in information. We will modify the description here in the new version of CP/CPS.

New description: The Chinese version of this CPS is issued. iTrusChina sincerely guarantees that there is no materially difference between the Chinese and English versions of the information.

I see that this change has been made in version 1.4.6 of the CPS. As a minor matter of English grammar, in future versions, please make a change of "materially" to "material".

2.      Section 3.1.6 states both that "Certificates issued by iTrusChina does not contain any trademarks or other information which may infringe other parties' rights" and that "iTrusChina don't validate trademark right or legal disputes when processing applications", which... seems to be conflicting.

We will modify the description in the next version of CP/CPS.

New description: iTrusChina does not verify an Applicant’s right to use a trademark and does not resolve trademark disputes.

  I see that this change has been made in version 1.4.6 of the CPS.

3.      Section 3.2.2.6 has an interesting statement regarding which entities are allowed to obtain wildcards; seemingly preventing them from DV certificates. This seems unfortunate and unnecessary, and while not prohibited, is at least something that stands out as perhaps misaligned in goals / understanding of the purpose of TLS certificates.

The description of 3.2.2.6 is indeed ambiguous and we will modify it. In fact, we are issuing DV wildcard certificates.

New description: Regarding a wildcard domain name, iTrusChina verifies the domain name on the right side of the wildcard to ensure that the domain name is clearly owned by the applicant.

I see that this change has been made in version 1.4.6 of the CPS.

4.      Section 3.2.2.6 also includes an interesting clause "If necessary, iTrusChina needs to adopt other independent authentication methods to confirm the ownership of a domain name." It's unclear if that's meant in addition to 3.2.2.4, or in lieu of 3.2.2.4.

We only use the domain verification method mentioned in 3.2.2.4, so we think our description is indeed ambiguous, and we will delete it in the next version of CP/CPS.

The sentence mentioned above has been deleted in version 1.4.6 of the CPS. 

5.      Section 3.2.2.8 has a real red flag: "If the tag 'iodef' exists in CAA records, iTrusChina will determine whether to issue the certificate after communicating with the applicant".

         It's unclear if they're treating this as permission to issue if the tag exists, which would be a BR violation.

         It's unclear if they're redefining the semantics of iodef (which is used for exception reports / violations, not for permission)

Our description of iodef is incorrect and will be revised in the next version of CP/CPS.

New description: When the certificate requests or issuances violate the security policy of the Issuer or the FQDN holder,if the tag "iodef" exists in CAA records, iTrusChina will dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s).

I see that this change has been made in version 1.4.6 of the CPS.

6.      Section 6.1.1.1 has a similar red flag "Since China has strict administration requirements on cryptographic products, FIPS 140-2 Standard is not a standard approved and supported by the State Cryptography Administration, FIPS 140-2 Standard is only enforced as a reference, selectively applicable on the premise of passing the evaluation and certification of the State Cryptography Administration and being licensed by national cryptography administration policies."

   This reasonably calls into question the safety and security of the CAs' private keys. Similar remarks are found within Section 6.2.1.

China has corresponding technology and testing standards for HSM. For compliance reasons, we must use HSM products from manufacturers licensed by the State Cryptography Administration. This requirement is also applicable to other licensed CAs in China. Our supplier's HSM products obtained FIPS 140-2 level 3 certification in 2019 (see attachment). If necessary, we can replace HSM later.

The FIPS 140-2 record provided by iTrusChina for the Sansec cryptomodule was reviewed. I.e. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3350.  No related changes were made to the CPS. 

7.      Section 6.1.1.2 "If a subscriber submits a PKCS#10 file of a weak algorithm during application, iTrusChina will reject the application and recommend the user to generate a new key pair" - this proof of possession provides no benefit in the context of TLS, and so this is a rather silly check. This has been discussed in the past here on m.d.s.p.

There are some problems with our statement here. What we meant to express is that we will reject the application if we find that the subscriber is using a Debian weak key (as described in BR6.1.1.3), we will modify it in the next version CP/CPS.

The sentence in section 6.1.1.2, quoted above, has been replaced by "iTrusChina will reject the application if it finds that the subscriber is using a Debian weak key."

 8.      Section 6.3.2 makes it clear that intermediates are generated very long (25 years), while the clear trend of industry has been moving towards shorted lived intermediates, and regularly rotating them, to ensure necessary certificate agility and robustness.

At present, we have not formulated a policy for regular replacement of intermediate roots. Considering the agility and robustness of the certificate, we will issue new intermediate root certificates with a shorter age in the future.

It will be good for iTrusChina to implement a process to replace intermediate CA certificates more frequently, even though the CPS says that they can have a validity of up to 25 years.

9.      Section 7.1.2 is not that useful (e.g. the EKU for intermediates just says (paraphrased) "We'll put something here after 2019-01-01"). Similarly the notBefore/notAfter remarks.

iTrusChina plans to generate some intermediate CA certificates after 2019-01-01, and the intermediate certificates generated before this do not contain the EKU extension. According to the requirements of Mozilla's Root policy, the intermediate certificate generated after 2019-01-01 needs to include the EKU extension, so we have added this description.

In the section 7.1.2 table in iTrusChina's future CPS, it should state that subordinate CA certificates will have EKUs, which shall only be the serverAuth and clientAuth EKUs. 

10.   Regarding the issue of EV Certificates Registration Agency Disclosure, the data sources we disclose are not only EV certificates, but also information sources for all other types of SSL certificates. The Unified Social Credit Code Certificate and Dun and Bradstreet are used for the Subject field of the SSL certificate, iTrusChina's SSL business is currently only carried out in China, and D&B is only used to query applicants' English names. The third chapter of our document is dedicated to EV Certificates Registration Agency Disclosure.

I am satisfied with this explanation. For anyone else's further review, the relevant document is located here: https://www.itrus.com.cn/uploads/soft/210401/2-2104011K954.pdf.

11.   In addition, regarding https://bugzilla.mozilla.org/show_bug.cgi?id=1712664, we will complete the coding of the monitoring system this week, and then start the system test next week. We are very grateful to Andrew for raising the question and Ryan's suggestions for improvement. These are very helpful to us.

The progress of this work has been requested in the above-referenced bug.

In conclusion, aside from closing Bug 1712664, I believe there are not open items remaining for iTrusChina to address. Step 6 of the Application Process states, "A representative of Mozilla summarizes the discussion and resulting decisions or action items," which I'll do on or before this Friday, 10-Sept-2021. Step 7 of the Application Process contemplates that the CA "completes action items resulting from the public discussion." I don't think an additional second round of discussions  under Step 8 is necessary. Then, under Step 9, "A representative of Mozilla concludes the public discussion of the CA's request," which I'll plan to do next week sometime.

Thanks,
Ben

Ben Wilson

unread,
Sep 10, 2021, 4:57:23 PM9/10/21
to yutian zheng, dev-secur...@mozilla.org, Ryan Sleevi

All,

In preparing my summary of the public discussion of iTrusChina's application for inclusion of its RSA and ECC roots with the websites trust bit enabled, I noted that iTrusChina is seeking enablement of EV. Last September, I had conducted a review of iTrusChina's CPS, but at that time I had not been checking specifically for compliance with the CA/Browser Forum’s EV Guidelines. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21. Instead of providing a summary of discussion and resulting decision and action items, which I had intended to do today, I have decided to review the CPS for compliance with the EV Guidelines, as I have done more recently with other applicants' CPSes. I'll post my review to the Bugzilla Bug #1554846 as soon as it's ready.

Thanks,

Ben

Ben Wilson

unread,
Sep 15, 2021, 1:36:48 PM9/15/21
to dev-secur...@mozilla.org
All,
This past week, I posted my EV Guidelines review of iTrusChina's CPS to Bugzilla. (https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c50). I expect that iTrusChina will want to update its CPS and address the EV comments in order to pursue EV enablement of its roots. Then I will close and summarize the public discussion, or ask follow-up questions, if necessary.
Ben

yutian zheng

unread,
Sep 18, 2021, 5:17:04 AM9/18/21
to dev-secur...@mozilla.org, bwi...@mozilla.com

Hi Ben,

We have revised a new version of CPS based on your comments and are going through the internal release process, which will be updated to our official website for review within a week.
Regarding the issue of the EV certificate insurance policy, iTrusChina decides its insurance policies based on its business development and the business development of Chinese insurance companies. For the EV certificate, iTrusChina has passed the financial audit of a third-party audit company and has reserved the relevant insurance amount for the planned EV customers. Currently iTrusChina does not purchase relevant commercial insurance.

Regards,
vTrus Team

Ben Wilson

unread,
Sep 23, 2021, 12:28:33 PM9/23/21
to dev-secur...@mozilla.org
All,
I have completed an EV-Guidelines review [1] of iTrusChina's updated CPS, v.1.4.7 [2].
I will be closing public discussion and writing up a summary of the public discussion.
Thanks,
Ben

Ben Wilson

unread,
Oct 4, 2021, 5:00:38 PM10/4/21
to dev-secur...@mozilla.org

Summary of Discussion and Resulting Decisions or Action Items

Public discussion on the iTrusChina inclusion application began on April 7, 2021.[1] iTrusChina is seeking inclusion of an RSA root and an ECC root to be used for websites, including issuance of EV TLS server certificates. Progress on this inclusion request has been tracked in Bugzilla #1554846.[2]

In relation to the public discussion of TunTrust’s application, also announced on April 7, we received comments from Ryan Sleevi and others that new CAs might present limited value and pose unnecessary risk to Mozilla users.[3] So, on April 20, I announced that I was working on follow-up questions regarding their added value to users vs. added risk.[4] In May, we announced a position statement on our wiki titled, “Quantifying Value”.[5] Accordingly, a new applicant “must present an explanation of the benefits to our users so that the community can identify, measure, value, and understand the benefits of including the root certificate and determine whether it is worth the risk of including it. These applicant-provided explanations cannot just be marketing fluff or mere self-promotion. Justifications must be detailed, objective, and supported by data to establish credible facts and create legitimacy and trust.”

On July 2, iTrusChina submitted a Value Justification.[6] On August 12, I circulated a brief summary and requested a more detailed operations budget[7], which was provided by iTrusChina.[8] The budget shows an approximate $1.83M in 2021 operating expenses and $309.5K for 2021 in capital expenditures.

More recently, I conducted a review[9] and follow-up review[10] of the iTrusChina CPS for compliance with the Extended Validation Guidelines, and I found the updates to its CPS satisfactory.

Other Action Items

During the discussion period, it was noted by Andrew Ayer that the signatures on iTrusChina’s ARL (CRLs for CAs signed by the root CA) were failing verification.[11]  “Our offline CA's ARL system has a design bug, it causes the new extension item to not be added to the original signature, resulting in the signature verification failed.”[12]

iTrusChina worked on this bug #1712664 by adding signature verification steps, and it reported at the beginning of August that they had completed this work for the system generating CRLs/ARLs.[13] While Bug #1712664 is still open to finish work on monitoring and detection of CA certificate signature issues, I believe there are no other action items open.

Under Steps 7 and 8 of the Application Process[14], I will await completion of full testing of these enhancements to iTrusChina’s CA system. I do not believe a second round of public discussion will be needed, and I will await closing public discussion and giving notice of intent to approve iTrusChina’s application until then.

Thanks,

Ben

 

[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/a8dDrSjSBQAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1554846

[3] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/FssiRIHWBQAJ

[4] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/0xjkC8JNAwAJ

[5] https://wiki.mozilla.org/CA/Quantifying_Value

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c47

[7] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/WZFkYNJqAgAJ

[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c48

[9] https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c50

[10] https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c53

[11] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/4v2pNhrNAAAJ

[12] https://bugzilla.mozilla.org/show_bug.cgi?id=1712664

[13] https://bugzilla.mozilla.org/show_bug.cgi?id=1712664#c18

[14] https://wiki.mozilla.org/CA/Application_Process#Process_Overview

 

Ben Wilson

unread,
Oct 27, 2021, 12:01:09 PM10/27/21
to dev-secur...@mozilla.org
As mentioned in my previous email, we were waiting for iTrusChina to complete its work on a monitoring system for CA signing operations under Bugzilla Bug #1712664. That work has completed, and the bug is now closed.

Pursuant to Steps 9 and 10 of the inclusion process, I am hereby concluding public discussion and declaring that it is Mozilla's intent to approve iTrusChina's inclusion request. This begins a one-week last call for objections through 3-November-2021, after which, if there are no further questions or concerns, the request will be approved.

Thanks,

Ben


Reply all
Reply to author
Forward
0 new messages