On Tue, Mar 5, 2019 at 9:01 AM Scott Rea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I have addressed most if not all of the various technical comments in this > list in respect to DarkMatter’s Roots submission and it might be helpful if > I summarize here the raised Compliance Concerns and Risk of Misuse Concerns: > > 1. Compliance > > Questions have been raised about DarkMatter’s compliance and I want to > again emphasize that we have a proven compliance and clean record in the > three years of operations and have been through two complete web trust > audits that have verified that we are operating within industry standards. > > • DM has resolved all technical and policy issues raised in the UAE > and DM Roots submission process on Mozilla list: see > https://bugzilla.mozilla.org/show_bug.cgi?id=1427262 > > • Since the inception of the DM CA we have had two technical > compliance issues during its three years of operation, both were addressed > immediately and resolved. > > • The first was that DM misissued 2 TLS certificates that were not > in compliance with the BRs as reported by Rob Stradling - specifically the > FQDN listed in the CN was not also included in the SAN. The 2 offensive > certs were already flagged by DM and were held and revoked and were only in > existence for approximately 18hrs and at NO TIME were they LIVE on the > internet protecting any services. They were promptly replaced by properly > attributed BR-compliant certificates. Comment 31 of the UAE and DM Root > inclusion Bug is where the two misissued certs were documented see > https://bugzilla.mozilla.org/show_bug.cgi?id=1427262 > > • The second was the serialNumber entropy raised by Corey Bonnell, > this amounted to an interpretation of the BRs standards that was known to > CAs following the time of Ballot 164, whereas DM interpreted the BRs as > they are written. DM was not privy to the discussions around Ballet 164 and > the subsequent community discussions. DM analyzed the BRs post Ballot 164 > and concluded based on the definition in Section 7.1, that our platform was > compliant with the BRs. This continued to be our position until Ryan Sleevi > posted historical data regarding the interpretations provided to other CAs > after the adoption of Ballet 164. At this point DM took the decision to > align with the general community interpretation of Section 7.1 (which up to > that point was not known to us). It was not a bug originally, our platform > was compliant at the time it was introduced. The update to the BRs appears > to have lost some specificity in its re-wording which existing CAs knew > about at the time, but any new CAs coming after the change may not make the > same conclusion without the benefit of the background information. All > public trust TLS certs issued by DM have now been replaced and the platform > updated as documented in > https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 > NOTE: The Roots and Issuing CAs have not yet been re-issued at this time, > awaiting availability of WT Audit staff. There is also an open question on > MDSP group about the necessity to re-issue the Roots. > > It’s evident from the above that DM has expeditiously addressed any issues > raised and Mozilla has already said that there is no direct evidence of > misissuance by DarkMatter. We have adhered to the rules and satisfied all > technical criteria to be included. And we operate entirely transparently, > providing all our public trust TLS certificates to CT logs so that anyone > can see all the certificates that were issued over time and in this way, > DarkMatter goes beyond required standards. > > 2. Risk of Misuse > > I also find it extremely troubling that speculation by members on this > list has far exceeded the bounds of reality. > > Claim: DM certifications could be issued to malicious actors who could > then impersonate legitimate websites. > > Response: > • DM does not issue certificates that can be used for MITM as stated > in our published policies which we are audited against. > > • There is no test that we’re aware of that allows us to ascertain > someone’s malicious intent in the future and if we find any misuse of a > certificate in this regards we revoke it immediately. We are willing to > engage in a dialogue with the industry on how to minimize the probability > of malicious actors and willingly subscribe to the industry consensus on > this. > > You're right, there is no test. That's why some of us believe we should look at proxies: such as honesty, considering root membership is ultimately about trust. DM has made claims that I am unable to understand in any way besides lying. > Referenced claim: outlandish claims of DM being able to decrypt all its > customers’ data if granted Root acceptance in Mozilla. > > Response: > • As everybody here knows, this is entirely ludicrous as commercial > CAs never hold customer’s private keys and therefore are incapable of doing > this. > > As you are well aware, there is a neighboring claim that _is_ accurate. Which is that a malicious root CA would be able to issue for any domain, and thus issue certificates to enable MITM. While it is misleading to say that DM would be able to decrypt all customer data, it's completely true that DM would be able to MITM _any_ TLS traffic -- customer or not! > I’m disappointed that when I started this journey for inclusion of our > Roots, that the process was clearly defined in terms of compliance and > controls, but the process now appears to have devolved into dealing with > the sort of wild speculation we are now experiencing. > > Do you believe there is _any_ outside activity a CA could engage in, while still maintaing clean audits, that should disqualify them for membership in the Mozilla Root Program? > > Regards, > > -- > > Scott Rea > > > > > > > Scott Rea | Senior Vice President - Trust Services > Tel: +971 2 417 1417 | Mob: +971 52 847 5093 > scott....@darkmatter.ae > > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance upon > this information by persons or entities other than the intended recipient > is prohibited. If you received this in error, please contact the sender and > destroy any copies of this information. > > > > > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > Alex _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
