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. 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? 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. 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. These recommendations are based on the balance of the potential global risk and the potential limited use that the existing CA is intended for. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
