*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 On Thu, Sep 23, 2021 at 10:28 AM Ben Wilson <[email protected]> wrote: > 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 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c53 > [2] https://www.itrus.com.cn/uploads/soft/210923/2-2109231I106.pdf > > On Sat, Sep 18, 2021 at 3:17 AM yutian zheng <[email protected]> > wrote: > >> 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 >> >> 在2021年9月16日星期四 UTC+8 上午1:36:48<[email protected]> 写道： >> >>> 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 >>> >>> On Fri, Sep 10, 2021 at 2:57 PM Ben Wilson <[email protected]> wrote: >>> >>>> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1554846> as >>>> soon as it's ready. >>>> >>>> Thanks, >>>> >>>> Ben >>>> >>>> >>>> On Tue, Sep 7, 2021 at 9:28 PM Ben Wilson <[email protected]> wrote: >>>> >>>>> 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 <[email protected]> >>>>> 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 <https://wiki.mozilla.org/CA/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 >>>>> >>>>> >>>>>> >>>>>> Regards， >>>>>> vTrus Team >>>>>> 在2021年8月24日星期二 UTC+8 上午6:51:57<Ryan Sleevi> 写道： >>>>>> >>>>>>> Hi Ben, >>>>>>> >>>>>>> I'm using the CP/CPS they updated in >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c33 and >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c34 >>>>>>> >>>>>>> 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 "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaWc26bbMMfkfFGcCBeSxOXLLnYvH6SuQi8ywU8EgSXDA%40mail.gmail.com.
