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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
