On Friday, March 9, 2018 at 10:30:18 PM UTC+1, Ryan Sleevi wrote: > On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > This request has been in public discussion for more than 6 months, so I > > would like to make a decision soon. If you have comments or concerns with > > this request, please post them here by 6-March 2018. > > > Wayne, > > Thanks for encouraging this discussion and making sure it reaches a timely > conclusion. > > To assist in the review, I've tried to summarize the issues to date: > Incident 1: > - 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson > noted incomplete reply to the list of Mozilla Problematic Practices > regarding DNS names appearing within the subjectAltName. In response, on > 2016-01-20, TunRootCA 2 replies - > https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they > only use the subjectAlternativeName. > - 2017-02-28: TunRootCA2 violates this requirement - > https://crt.sh/?id=99182607 > - 2017-03-03: TunRootCA2 revokes this certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 2: > - 2016-01-04: TunRootCA2 states their validation practices > - 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121 > - 2016-03-21: TunRootCA2 revokes that certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 3: > - 2012-07-01: Baseline Requirements effective date, with restrictions on > reserved IPs and internal server names. > - 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address > with a validity period later than 2015-11-1. > - 2016-12-14: TunRootCA2 replaces the certificate > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 4: > - 2012-07-01: Baseline Requirements effective date, with restrictions on > reserved IPs and internal server names. > - 2017-01-09: TunRootCA2 issues a certificate for an internal server name > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > - 2017-07-28: TunRootCA2 revokes this certificate > > During the discussion of these incidents, TunRootCA2 disclosed that RAs > handled domain name validation, and they used another CA's tools to check > the validity of CSRs. RAs were then empowered to issue the domain > information directly to cause issuance. This suggests a strong lack of > technical controls and understanding by RAs. In response, TunRootCA2 > indicated they were deploying a new PKI platform. >
We do use another CA's tool to check the validity of CSR. As we do use the cr.sh tool developed also by another CA to check pre-certificate before issuance. So why is using a tool for checking CSR is problematic whereas using the crt.sh is approved ? The point here is to use an efficient tool to perform certificate checks regardless of the CA that owns it. Besides, given that the Tunisian government does not have a Mozilla trusted CA, we are forced to buy SSL certificates for Tunisian e-commerce websites from the CA who owns the CSR check tool that we use. In order to have a consistent RA process, we use the CSR check tool to by from that trusted CA and also to check our own certificates > On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain > validation, as per > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ > > > Incident 5: > - 2017-10-23: TunRootCA2 misissues again - > https://crt.sh/?id=242366304&opt=cablint > - 2018-02-22: Wayne Thayer raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ > - 2018-02-27: TunRootCA2 revokes the certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ > > Incident 6: > - 2018-02-22: Wayne Thayer completes initial review - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ > - 2018-02-23: TunRootCA2 misissues again - > https://crt.sh/?id=346579818&opt=cablint > - 2018-02-28: TunRootCA2 revokes the certificate > > > Like Jonathan, I am concerned about the technical controls instituted. From > this thread, it does not give the impression of a technically competent > organization. While the requirements for more detailed. While a number of > these incidents predate the normalized Mozilla Incident Report template ( > https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ > ), it was designed precisely to address these issues, and the more recent > replies do not provide particular reassurance that these incidents have > been fully understood. > > The failures Wayne raised, particularly around documentation, are > troubling. Equally troubling is that in the course of audits, these issues > were not disclosed - or, if they were, the revocation of the certificate in > response to these incidents was not disclosed to the broader community. > > Yet, at the same time, there are still-trusted CAs that have demonstrated > similar issues - although perhaps not to the same degree of becoming a > problematic pattern or an insufficient response - and they still remain > trusted. A recommendation to instill trust in such a new CA, one that has > demonstrated problematic patterns already, suggests that CAs may continue > to display such patterns without risk of distrust - which would overall be > harmful. Yet, if the recommendation is not to trust, what should the > remediation steps be to find a positive path forward? Since there are other still-trusted CAs that has the same problems, why is that the Tunisian CA treated with presumption of untrustworthiness . The decision-making process should be objective and fair for all CAs. > > I do not believe this CA should be trusted, given these patterns. I do not > feel the evidence supports a confident understanding of the critical role > that CAs play, nor an understanding of the technical risks and mitigations. > While it is good that TunRootCA2 has adopted practices such as linting, it > simply moves the problem to be more opaque - how many certificates fail > that check will not be known, nor will it be known how many failures are > now for policy reasons, rather than technical reasons. The community > largely relies on the information provided in audits - with the > expectations that CAs will self-report and self-disclose these issues - and > yet the audits not calling this information out is deeply worrying, both as > to quality and to completeness. During all the Mozilla review process, our team showed a willingness and a seriousness in the treatment of these incidents. We have implemented all the technical checks required to prevent the occurrence of other miss- issued certificates (pre-issuance linting). We have also reported all missiussed certificates of our root CA since its creation. There are in total 15 mississued certificates as listed Olfa's last message https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/fFcZ3SepAQAJ > > For this reason, I recommend this request be denied, and, as suggested > elsewhere, a new root be created. Further, I recommend that a new auditor > be selected, with the clear expectation and understanding that the > Government of Tunisia will promptly report any and all certificates that > are issued under this new root that have failed either the technical > controls or policy controls, in addition to revocation, to both their > auditor and to the Mozilla Community. Similarly, that there be a clear > expectation that any suspension of certification under the ETSI framework, > or any remedial actions to be taken as part of the annual audit prior to > the issuance of a certificate, be promptly and publicly disclosed. > The auditor who performed the conformity check of our CA is a Qualified Auditor as defined in the Baseline Requirements section 8.2. and required by Mozilla. I believe that your recommendation of selecting a new auditor is unacceptable. Calling into question the accreditation of the auditor is exceeding limits > These recommendations are based on the balance of the potential global risk > and the potential limited use that the existing CA is intended for. I do believe that your recommendations are alarmist and lack of objectivity considering the potential limited use of our national CA . _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
