No. Just the 23k. Part of the reason I posted to the Mozilla list are open questions about whether Trusticos request is sufficient to trigger the br requirements. My gut is no, and sounds like the browsers agree. We’ll only revoke the remaining 27k if we receive evidence of compromise
On Feb 28, 2018, at 2:52 PM, jomo <mozilla-li...@jomo.tv<mailto:mozilla-li...@jomo.tv>> wrote: 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><mailto: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<mailto: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<http://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<mailto: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<http://2Flists.mozilla.org>%2Flistinfo%2Fdev-se curity-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy<https://clicktime.symantec.com/a/1/3wjI0lE22JgYGnrIgtAQv7FW6pnTRdrR8fiCDSlaje0=?d=qnG23jeRzsakHnmv0m3tUVVNhTHCDp_XhG50BufJUY1ASHMt_9WbK21Ax7NgWSAA2xIM-RvMri-USsX9RhFJjmsPle-xObmX_pXxmdHIaaoZKpCslmIbvdctjhlZvrQalkvVEfm1zX0iu1zYXyDIibSV07BzfyniUgevaRZAqRNjw1Jx8MmcLciydYLHSPiCNOMb1MBcDYKtNOFp5SUKVh3TAAGLgtMS3cF3U45pLXWRezAm2ZE8YI3wxz9CImhm2Hx7tyCZ0IxQ0WaYMm1DHzaHoC_BuLeBMZfYs4ANAavnNt3j55dnS1EKIAfSMY__JjDbvyzGhCQ6IuH69wElLd1adi_CwkGlPMI8C7rWq7xl6e_4i9FU0b5QJmHdqHuR9XLIkW-TRfI%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
