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%2B1gtaZySBEJX63XneFp3UgjHAhke%2BjFP2qENMtEPC_sdbFGew%40mail.gmail.com.
