One other thing I wanted to get ahead of is that we are revoking three Dark Matter issuing CAs tomorrow. This revocation was planned well before this discussion started. These three certificates were issued in 2016 with improper name constraints. The 2017 certificates currently used are replacements for those certificates without any name constraints. The three certificates are:
CN=DarkMatter Assured CA,O=DarkMatter LLC,C=AE 4812bd923ca8c43906e7306d2796e6a4cf222e7d 2024-04-29 22:53:00 6b6fa65b1bdc2a0f3a7e66b590f93297b8eb56b9 CN=DarkMatter High Assurance CA,O=DarkMatter LLC,C=AE 093c61f38b8bdc7d55df7538020500e125f5c836 2024-04-29 22:38:11 8835437d387bbb1b58ff5a0ff8d003d8fe04aed4 CN=DarkMatter Secure CA,O=DarkMatter LLC,C=AE 093c61f38b8bdc7d55df7538020500e125f5c836 2024-04-29 22:45:18 6a2c691767c2f1999b8c020cbab44756a99a0c41 Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Jeremy Rowley via dev-security-policy Sent: Monday, February 25, 2019 1:43 PM To: Buschart, Rufus <rufus.busch...@siemens.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: RE: DarkMatter Concerns Hi all, Sorry for the delayed response. Been traveling and haven't had a chance to properly format my thoughts until now. As you all know, DigiCert recently acquired the Quovadis CA. As the operator of the CA, DigiCert is responsible for the issuing CA controlled by DarkMatter. DarkMatter controls the keys of the intermediate, have their own CPS, and undergo their own annual audits. With one exception, DigiCert has a policy against signing externally operated intermediate CAs capable of issuing TLS certificates. The exception is for browser operators who want a cross-sign, which is not applicable in this case. We've found that limiting external CAs provides a better situation for users and the security community. As we've done in the past, we feel there is a logical and legal way to address inherited contracts and externally operating CAs so that we do not leave site operators and relying parties using those sites in a lurch. We are committed to working with DarkMatter on a plan that works for them and aligns to our policy. As for DarkMatter, we have not received direct evidence of any intentional mis-issuance or use of a certificate for a MiTM attack. As a policy, we do not revoke certificates based purely on allegations of wrongdoing. This is true regardless of source, such as trademark disputes, government requests for revocation, and similar matters. We do revoke certificates after receiving a formal request for revocation from a trust store operator. I think this policy is a logical approach as the policy avoids government influence and public pressure over unpopular sites while acknowledging the browser's control over their root store. If we are presented with direct evidence of serious BR violations or wrongdoing, we will certainly act in the best interests of user security and revoke the intermediate. Wrongdoing warranting revocation definitely includes using the issuing CA to intercept communication where the certificate holder does not control the domain. We already received a formal report on the serial number issue. This issue reminds me of past discussion (https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/entr opy%7Csort:date/mozilla.dev.security.policy/UnR98QjWQQs/Afk5pDHqAQAJ) which did not warrant removal from the root store. We plan on filling a bug report on the incident and working with DarkMatter to ensure their systems are compliant with the BRs. This includes their replacing non-compliant certificates in accordance with 4.9.1.1. Considering that the certificates resulted from a misreading of the BRs rather than a malicious act and the historical precedent in not removing CAs for entropy issues, I don't think there is justification to revoke the CA. IWe, of course, expect DarkMatter to update their systems and work with the Mozilla community in providing all information necessary to resolve concerns about their operation. Hopefully that answers questions you have. Feel free to ask me anything. Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Rob Stradling via dev-security-policy Sent: Monday, February 25, 2019 9:53 AM To: Nick Lamb <n...@tlrmx.org>; dev-security-policy@lists.mozilla.org Cc: Kurt Roeckx <k...@roeckx.be> Subject: Re: DarkMatter Concerns On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote: > On Sat, 23 Feb 2019 10:16:27 +0100 > Kurt Roeckx via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> I would also like to have a comment from the current root owner >> (digicert?) on what they plan to do with it. > > Two other things would be interesting from Digicert on this topic > > 1. To what extent does DarkMatter have practical ability to issue > independently of Digicert? > > https://crt.sh/?caid=22507 > > It would be nice to know where this is on the spectrum of intermediate > CAs, between the cPanel intermediate (all day-to-day operations > presumably by Sectigo and nobody from cPanel has the associated RSA > private keys) Hi Nick. I can confirm that all day-to-day operations for the cPanel intermediates are performed by Sectigo, and nobody from cPanel has the associated RSA private keys. > and Let's Encrypt X3 (all day-to-day operations by Let's Encrypt / > ISRG and presumably nobody from IdenTrust has the associated RSA > private keys) <snip> QuoVadis disclosed [1] that... "The DarkMatter CAs were previously hosted and operated by QuoVadis, and included in the QuoVadis WebTrust audits through 2017. In November 2017, the CAs were transitioned to DarkMatter's own control following disclosure to browser root programs." I take that to mean that DarkMatter are in possession of the RSA private key corresponding to https://crt.sh/?caid=22507. [1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Buschart, Rufus via dev-security-policy Sent: Monday, February 25, 2019 1:08 PM To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: AW: DarkMatter Concerns > Von: dev-security-policy > <dev-security-policy-boun...@lists.mozilla.org> Im Auftrag von Matthew Hardeman via dev-security-policy On Mon, Feb 25, 2019 at 12:15 PM Richard Salz <rich.s...@gmail.com> wrote: > > > You miss the point of my question. > > > > What types of certs would they issue that would NOT expect to be > > trusted by the public? > I get the question in principle. If it is a certificate not intended > for public trust, I suppose I wonder whether or not it's truly in > scope for policy / browser inclusion / etc discussions? If the certificate is part of a hierarchy that chains up to a root under Mozillas Root Program there should be no question about this - yes it is in scope. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
