Public Discussion re: Inclusion of the iTrusChina Root CAs
Ben Wilson
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
Ben Wilson
Ryan Sleevi
Ben Wilson
Andrew Ayer
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
Yutian Zheng
yutian zheng
yutian zheng
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
Ben Wilson
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
yutian zheng
Ben Wilson
Ryan Sleevi
- 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.
--
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
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.
Ben Wilson
yutian zheng
yutian zheng
Ben Wilson
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.
Ben Wilson
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
yutian zheng
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
Ben Wilson
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