All,
Thank you to those of you that have been providing thoughtful and
constructive input into this discussion. I have been carefully reading
and contemplating all of the messages posted in the
mozilla.dev.security.policy forum.
As the owner of Mozilla’s CA Certificates Module[1] and in an effort to
respond to Matthew’s concerns about transparency[2], I would like to
share my current thoughts about DarkMatter’s intermediate certificates
and root inclusion request. I will make a decision after this discussion
has run its full course.
I appreciate that representatives of DarkMatter are participating in
this discussion, and reiterate that I have not yet come to a decision. I
would also like to remind everyone that we have not yet started the
public discussion phase of DarkMatter’s root inclusion request. This
discussion is separate from Mozilla’s root inclusion process, but will
determine if the process will continue for DarkMatter’s root inclusion
request. If this discussion concludes that DarkMatter’s intermediate
certificates should be added to OneCRL, then the root inclusion request
will be closed. However, if this discussion concludes that DarkMatter’s
intermediate certificates should not be added to OneCRL, then
DarkMatter’s root inclusion request will continue to follow the normal
process.
== Regarding DarkMatter’s current intermediate certificates ==
The current DarkMatter intermediate certificates are not constrained or
technically controlled by the parent CA, as was confirmed by a
representative of DigiCert[3]. This means that currently DarkMatter has
all of the certificate issuance capability of a root certificate that is
directly included in Mozilla’s root store. This is why we are having
this discussion to determine if DarkMatter’s current intermediate
certificates should be added to OneCRL.
In my opinion, there are other options for DarkMatter. For example, a CA
who is currently included in Mozilla’s program such as Digicert, could
issue DarkMatter new intermediate certificates that are owned and
controlled by DigiCert and for which DigiCert performs additional domain
validation before issuance of end-entity certs in that CA hierarchy. I
think that an option like this would provide sufficient oversight of
DarkMatter’s certificate issuance, if we decide to add DarkMatter’s
current intermediate certificates to OneCRL.
== Regarding DarkMatter’s root inclusion request ==
Since I began working on Mozilla’s CA Program in 2008 I have rarely seen
this much interest and opinions from the media and general public on
root inclusion requests, even though all of our process is performed in
the open[4] and includes a public discussion phase[5]. In my opinion,
we should pay attention to the messages we're receiving, and subject
this CA to additional scrutiny.
As others have already pointed out[6] DarkMatter’s root inclusion
request is reminiscent of CNNIC’s root inclusion request in 2009 [7] and
their request to include an additional root in 2012 [8]. As Ryan
reminded us[9] in his excellent analysis, the decisions about the
inclusion of the CNNIC root certificates was based on “a rigid
application of policy”. In one of my posts[10] about CNNIC’s root
inclusion requests I stated:
“There was a lot of discussion about government, politics, legal
jurisdiction, what-if scenarios, and people’s opinions about the Chinese
government. While I sympathize with people’s feelings about this,
Mozilla’s root program is based on policy and evidence. While CNNIC has
provided all of the required information to demonstrate their compliance
with Mozilla’s CA Certificate Policy, no usable evidence has been
provided to show non-compliance with Mozilla’s CA Certificate Policy.”
As we all know, in 2015 Mozilla revoked trust in CNNIC certificates[11]
after discussion[12] in this forum regarding the discovery that an
intermediate CA under the CNNIC root was used to mis-issue TLS
certificates for some domains, and subsequently used for MiTM. In that
case, rigid application of the policy left our users at risk. This was
an important learning experience for us.
Root inclusion requests rarely receive this much attention. Another one
that we have been reminded of is TeliaSonera’s root inclusion
discussion[13], in which I stated: “Typically this would have been
considered a very standard request, but this discussion turned into a
political sounding board. Approval of this root-renewal request means
that the CA complies with Mozilla’s CA Certificate Policy and provides
annual audit statements attesting to their compliance. It in no way
reflects my opinion, or that of Mozilla, on the actions of the owner of
the CA in regards to their non-CA related businesses and practices.”
Unlike CNNIC, TeliaSonera still has root certificates in Mozilla’s root
store. Similar to many CAs in our program, TeliaSonera has had some
compliance problems[14], but (to my knowledge) no evidence has been
provided of TeliaSonera knowingly issuing certificates without the
knowledge of the entities whose information is referenced in the
certificates, or knowingly issuing certificates that appear to be
intended for fraudulent use. TeliaSonera’s reported compliance problems
have not yet been deemed to be egregious enough to warrant removal of
their root certificates. Therefore, it is not as simple as saying that
this DarkMatter root inclusion request seems similar to the CNNIC
situation, so we should not approve DarkMatter’s root inclusion request.
However, I believe that the CNNIC experience is a valuable lesson that
should be taken into account when making a decision on DarkMatter.
During CNNIC’s root inclusion process, the community expressed grave
concerns about the company based on credible reports that they had been
involved in interception and surveillance of web traffic, including
providing malware products to others such as their government. Even with
these credible news reports, the community was unable to obtain
technical evidence of intentional certificate mis-issuance, so I
approved their root inclusion request. In essence this meant ignoring
the evidence that had been provided because I deemed that it was not
directly applicable to the policy requirements for being a CA in our
program. However, it wasn’t until much later that there was sufficient
evidence to remove the CNNIC’s root certificate. Therefore, we should
not ignore credible news reports regarding DarkMatter.
Matthew correctly stated[15] that he “can not recall use of subjective
discretion to deny admission to the program.” As demonstrated in both
the CNNIC and TeliaSonera requests I have always tried to be as
objective as possible in regards to root inclusion requests. However, as
Ryan pointed out[16] “the program is, and has always been, inherently
subjective and precisely designed to support discretionary decisions.”
And Wayne said[17]: “A stronger argument along these lines is that we
have plenty of CAs, so there is no good reason to take a risk on one
that we lack confidence in.” I do not believe that we should take a
certain action just because it is what we have always done. And we
should use all of the information that is available to us in analyzing
the risk that comes with including new root certificates, even if that
means the decision is more subjective than previous decisions. The
ultimate purpose of our transparency and our standards is to bolster
trust in our CA program. Ignoring information that doesn’t fall within
strict criteria does not serve that purpose.
Mozilla’s root store policy[18] says: “We will determine which CA
certificates are included in Mozilla's root program based on the risks
of such inclusion to typical users of our products.” To me this means
that if the risks of including a root certificate appear to outweigh the
benefits, then we should deny the root inclusion. There are credible
reports from multiple sources[19] providing reason to not trust the
DarkMatter organization to issue TLS certificates without constraints. I
think that the decision about DarkMatter should consider if the risk of
including DarkMatter’s root certificates outweighs the potential benefit
to consumers of Mozilla’s root store.
As always, I continue to appreciate your thoughtful and constructive input.
Thanks,
Kathleen
[1] https://wiki.mozilla.org/Modules/All#CA_Certificates
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/hi3WDHlYAgAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/I8CYOScMBgAJ
[4] https://wiki.mozilla.org/CA/Dashboard
[5] https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion
[6]
https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=476766
[8]
https://groups.google.com/d/msg/mozilla.dev.security.policy/QEwyx6TQ5TM/qzX_WsKwvIgJ
[9]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ
[10]
https://groups.google.com/d/msg/mozilla.dev.security.policy/QEwyx6TQ5TM/c3GXKsASCX4J
[11]
https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/
[12]
https://groups.google.com/d/msg/mozilla.dev.security.policy/czwlDNbwHXM/Fj-LUvhVQYEJ
[13]
https://groups.google.com/d/msg/mozilla.dev.security.policy/mirZzYH5_pI/5LJ-X-XfIdwJ
[14] https://wiki.mozilla.org/CA/Incident_Dashboard
[15]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/ew5ZnJtVAgAJ
[16]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/IfewIb0hAgAJ
[17]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/joyWkf5TAgAJ
[18]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[19]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
