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://groups.google.com/d/msg/mozilla.dev.security.policy/CEww8w9q2zE/F_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://lists.mozilla.org/listinfo/dev-security-policy
