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
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
