Trustico doesn't seem to provide any hosting or CDN services that would make use of the private key, nor do they appear to explicitly inform users about the storage of this private key.
In their statement, they say they keep the private keys explicitly to perform revocation as necessary: https://www.trustico.com/news/2018/symantec-revocation/certificate-replacement.php (archived: https://archive.is/0AnyR ) > These Private Keys are stored in cold storage, for the purpose of revocation. Their CSR/key generation form is here: https://www.trustico.com/ssltools/create/csr-pem/create-a-new-csr-instantly.php (archived: https://archive.is/hJV42 ) The storage of private keys appears to be done without the user's knowledge or consent. And of course, only the keys they create through their form are stored, so it is clearly not a necessary business function for most of their certificate business. Finally -- the CSR/key generation form page incorporates JavaScript from at least 5 or 6 different companies (including ad servers), which would allow any of those third parties (intentionally or through compromise of their own) to capture generated keys. This is a reckless amount of exposure, to the point that even if the keys were generated completely inside the browser and never exposed to the server (which does not appear to be the case), I would consider them compromised at the time of generation. Given everything that's known, then regardless of who emailed whose customers when and why, I think it's clear that Trustico compromised those keys at _least_ at the time they were stored, if not at the time of generation, and has been routinely compromising customer keys for years. Emailing them to DigiCert only widened their exposure to more unauthorized parties. And given that there's no evidence that Trustico has acknowledged this fact, or indicated any intent to change their business practices, then I believe it's appropriate for all CAs to immediately suspend or terminate their relationship with Trustico -- as any CA who continued doing business with Trustico would now be knowingly allowing Trustico to compromise the keys of the certificates issued under their hierarchy. -- Eric On Wed, Feb 28, 2018 at 3:24 PM, Ryan Hurst via dev-security-policy < [email protected]> wrote: > On Wednesday, February 28, 2018 at 11:56:04 AM UTC-8, Ryan Sleevi wrote: > > Assuming Trustico sent the keys to DigiCert, it definitely sounds like > even > > if Trustico was authorized to hold the keys (which is a troubling > argument, > > given all things), they themselves compromised the keys of their > customers, > > and revocation is both correct and necessary. That is, whether or not > > Trustico believed they were compromised before, they compromised their > > customers keys by sending them, and it's both correct and accurate to > > notify the Subscribers that their keys have been compromised by their > > Reseller. > > That seems to be the case to me as well. > > It also seems that this situation should result in the UAs and/or CABFORUM > re0visit section 6.1.2 (https://github.com/cabforum/ > documents/blob/master/docs/BR.md) in the BRs. > > Specifically, this section states: > > ``` > Parties other than the Subscriber SHALL NOT archive the Subscriber Private > Key without authorization by the Subscriber. > > If the CA or any of its designated RAs generated the Private Key on behalf > of the Subscriber, then the CA SHALL encrypt the Private Key for transport > to the Subscriber. > ``` > > In this case, TrustIco is not the subscriber, and there is no indication > in their terms and conditions (https://www.trustico.com/ > terms/terms-and-conditions.php) that they are authorized to archive the > private key. Yet clearly if they were able to provide 20k+ private keys to > DigiCert they are archiving them. This text seems to cover this case > clearly but as worded I do not see how audits would catch this behavior. I > think it may make sense for the CAs to be responsible for demonstrating how > they and other non-subscribers in the lifecycle flow handle this case. > > Additionally, it seems if the private keys were provided to DigiCert in a > way they were verifiable by them they may have been stored in a > non-encrypted fashion, at a minimum they were likley not generated and > protected on an HSM. The BRs should probably be revised to specify some > minimum level of security to be provided in these cases of for these cases > to be simply disallowed altogether. > > Finally, the associated text speaks to RAs but not to the non-subscriber > (reseller) case, this gap should be addressed minimally. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
