Change in control event at DigiCert

[Jeremy Rowley via dev-security-policy]

Just FYI, there is an upcoming change in control event that will happen at
DigiCert where TA and Clearlake will take equity ownership of the company.
TA is currently a minority shareholder in DigiCert. Details are posted here:
https://www.pehub.com/2019/07/clearlake-and-ta-to-invest-in-digicert/.
Operational personnel remain the same.  We're not sure when this will happen
exactly. Sometime later this year probably.

 

Let me know if you have any questions.

 

Jeremy



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

Re: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

I would like to point out that in the recent appeal PDF posted on bugzilla
showed darkmatter.ae in the footer on page 2 and onwards. This further
makes me believe that there is not much separation of the entities.

- Cynthia

On Wed, 17 Jul 2019, 01:29 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> I have to rebut the idea that revoking trust is an adequate -- let alone
> an "essentially absolute" -- recourse for a CA's abuse of its authority.
>
> The fact is that an abusive CA can cause unwanted (and potentially
> harmful) code and data to be injected into -- and personal data to be
> exfiltrated from -- nearly any user's device on the entire global internet.
>
> Once data is exfiltrated, its rightful owner has lost control of it
> forever. Revoking trust in the abusive CA that caused this loss does not
> amend it. Once a device is penetrated, it can be very difficult to
> disinfect, even assuming that the user knows that it has been
> penetrated. Such a device might function as a spy upon and/or an editor
> of its victim's data (and the data of persons with whom the victim
> communicates) indefinitely. An infected device is not in any way "fixed"
> by revoking trust in the abusive CA that caused it to become infected.
> Furthermore, an infected device can infect other devices, both locally
> and globally.
>
> The consequences to victims of breaches caused by an abusive CA can be
> extreme, potentially including prosecution, imprisonment, and worse. And
> revoking trust does nothing to amend these consequences.
>
> This is all but to say that enormous responsibility rests upon CAs, and
> even more so upon trust-store custodians, who effectively are supposed
> to protect every user on the global internet from bad actors. We must
> not lose sight of these facts while we argue about process, profit, and
> whatnot else.
>
> -R
>
> On 7/16/2019 2:23 PM, Matthew Hardeman via dev-security-policy wrote:
> > I also disagree with the contention that Mozilla has "effectively no
> > recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
> > on the borrowed trust through providing services to certificate
> subscribers
> > only in compliance with program and industry guidelines and with proper
> > validations.)  Mozilla's recourse is essentially absolute: you can revoke
> > the trust you've extended, preventing further damage.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Root CA in certdata.txt

[Vincent Lours via dev-security-policy]

Thanks guys for all those clarifications.
Always good to learn new stuffs ^^

So I don't have to be worried about some Trust anchors expiring :)

Have a good day.

This topic can be closed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy