> Basically, we're revoking 50k people without > being able to explain why (well, other than the key was compromised).
Unless I misunderstood, you originally said you received 23k compromised keys and are revoking those. > Currently, we are only revoking the certificates if we received the private > keys. There are additional certificates the reseller requested to have > revoked, but DigiCert has decided to disregard that request until we receive > proof of compromise or more information about the cause of this incident. Has DigiCert received proof of compromise of all 50k in the meantime? On 28.2.18 22:42, Jeremy Rowley via dev-security-policy wrote: > We don't have a process to prevent third parties from storing private keys. > I'm not sure how that would even work considering the approved third-party > use cases vs. non-approved use cases. In fact, I'd postulate there's > nothing wrong with Trustico holding the private keys if they were hosting > the site or providing CDN services for all of these sites. The issue is > Trustico alleged compromise of the certificates and sent us the private keys > believed compromised in support. There were a lot of them. > > This is a mass revocation without any explanation of what went wrong or why. > The reseller mentioned and proved compromise, but there's no way to see if > what happened, whether the issue was mitigated, or how it's going to be > prevented from happening again. Basically, we're revoking 50k people without > being able to explain why (well, other than the key was compromised). > > -----Original Message----- > From: dev-security-policy > <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org> > On Behalf Of urijah--- via dev-security-policy > Sent: Wednesday, February 28, 2018 2:24 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: How do you handle mass revocation requests? > > Is Trustico's storage of private keys related to this security report from a > few months back (which did not appear to ever have been fully > investigated...)? > > https://clicktime.symantec.com/a/1/gUJtIwxyRazHoxd9FIcS40cx3EykeGjrwv4urOpHj > u0=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D > eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH > G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB > Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP > 1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui > OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg- > cER_Pj3TmyKGPFFw_SzUky&u=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla > .dev.security.policy%2FCEww8w9q2zE%2FF_bzX1guCQAJ > > Does Digicert have (or will it have) some sort of process in place to > prevent resellers from storing private keys so casually? > > On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote: >> Hi everyone, >> >> >> >> I wanted to share an incident report regarding the revocation of >> certain certificates ordered through a reseller. >> >> >> >> On February 2nd, 2018, we received a request from Trustico to mass >> revoke all certificates that had been ordered by end users through > Trustico. >> Unfortunately, the email was not sent to the appropriate certificate >> problem reporting channels and did not surface immediately so we're >> delayed in sharing the concerns and information. Once we were alerted, >> the team kicked off a debate that I wanted to bring to the CAB Forum. >> Basically, our position is that resellers do not constitute >> subscribers under the Baseline Requirement's definitions (Section >> 1.6.1). As such, we needed to confirm that either the key was >> compromised or that they revocation was authorized by the domain >> holder (the subscriber) prior to revoking the certificate. The > certificates were not alleged as compromised at that time. >> >> >> Later, the company shared with us that they held the private keys and >> the certificates were compromised, trying to trigger the BR's 24-hour >> revocation requirement. However, we insisted that the subscriber must >> confirm the revocation request or there must be evidence of the private > key compromise. >> >> >> Normally, we permit partners to revoke and manage the certificates >> freely on behalf of their customer, with DigiCert providing all >> validation and issuance services. However, the sheer number of >> revocation requests (50k) and allegation of compromise triggered >> concerns around the impact to the web and browser users. Therefore, >> this was categorized as high risk, especially considering the relationship > between Trustico and DigiCert is terminating. >> >> >> On 2/27/2018, at my request for proof of compromise, we received a >> file with 23k private keys matched to specific Trustico customers. >> This definitely triggered our 24-hour revocation processing requirement > under 4.9.1.1.3. >> Once we received the keys, we confirmed that these were indeed the >> matching private keys for the reported certificates. We will be >> revoking these certificates today (February 28th, 2018). >> >> >> >> At this time, Trustico has not provided any information about how >> these certificates were compromised or how they acquired the private >> keys. As is standard practice for a Certificate Authority, DigiCert >> never had possession of these private keys. >> >> >> >> Currently, we are only revoking the certificates if we received the >> private keys. There are additional certificates the reseller requested >> to have revoked, but DigiCert has decided to disregard that request >> until we receive proof of compromise or more information about the cause > of this incident. >> >> >> DigiCert sent out emails to the affected customers in order to notify >> them that their certificate(s) are being revoked. This revocation only >> affects those customers and there is no additional exposure that we >> are aware of at this time, nor any reason to believe there is. >> >> >> >> This raises a question about the MDSP policy and CAB Forum >> requirements. Who is the subscriber in the reseller relation? We >> believe this to be the key holder. However, the language is unclear. I >> think we followed the letter and spirit of the BRs here, but I'd like >> feedback, perhaps leading to a ballot that clarifies the subscriber in a > reseller relationship. >> >> >> This also brings up a ballot about the level of due diligence required >> for cert revocation. We generally believe that the private key or >> demonstration of domain control is sufficient to request revocation. >> Others are at the CAs discretion. Should we clarify what the due >> diligence looks like? Are there other things we should have done or been > doing? >> >> >> What kind of transparency would the Mozilla community like around this >> issue? There aren't many more facts than I shared above, but there is >> a lot of speculation. Let me know what I can share to help alleviate >> confusion and answer questions. >> >> >> >> Jeremy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/HzhUTcKY59cs-68Bx4Zcxt9mxYoEtI12E4LdF4LDI > mk=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D > eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH > G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB > Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP > 1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui > OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg- > cER_Pj3TmyKGPFFw_SzUky&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-se > curity-policy > > _______________________________________________ > 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
