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