On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy < [email protected]> wrote:
> > Regarding to our investigation they were only able to send the private > keys for those certificates where the CSR / private key pair were generated > within their online private key generating tool. This has to be the 23k > amount of keys which Jeremy received. > > I am not aware of guidelines of the CA/B forum but keeping 23.000 (!) > private keys at your online platform seems more than alarming and is > careless and the public should be made aware of this fact. > > I agree with this sentiment, but I also think it creates another policy question with respect to DigiCert's decision to revoke due to key compromise: were these 23,000 keys really compromised? The BR definition of Key Compromise is: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an unauthorized person may discover its value. A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the specific method used to generate the Private Key was flawed. In this case it might be reasonable to argue that Trustico was unauthorized (unless their customers agreed to key escrow when using the online key generation tool). However, in the case of a hosting provider reselling certificates for use on their platform, it's required that they hold the private key and we don't consider that a Key Compromise. - Wayne _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
