As mentioned in my previous email, we were waiting for iTrusChina to complete its work on a monitoring system for CA signing operations under Bugzilla Bug #1712664 <https://bugzilla.mozilla.org/show_bug.cgi?id=1712664>. That work has completed, and the bug is now closed.
Pursuant to Steps 9 and 10 of the inclusion process, I am hereby concluding public discussion and declaring that it is Mozilla's intent to approve iTrusChina's inclusion request. This begins a one-week last call for objections through 3-November-2021, after which, if there are no further questions or concerns, the request will be approved. Thanks, Ben On Mon, Oct 4, 2021 at 3:00 PM Ben Wilson <[email protected]> wrote: > *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%2B1gtaY%2BF8zmhKSVs9becrP5cCajkDbELQ%2B94rGgbX294VnaBg%40mail.gmail.com.
