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%2B1gtaY-hAOT6OaHDOhy6X2ffEG71H8az7tsLOu8zr7MZF4izQ%40mail.gmail.com.
