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%2B1gtaZfbxR7AP%2B84JShRr%2BO3WXogjTM_fGoUJoD03zgP3ubzA%40mail.gmail.com.
