I would say that at the point that Trustico emailed them to DigiCert they necessarily became compromised -- while Trustico may (or may not) have been authorized to escrowing the keys by the subscriber, the subscriber did not authorize them to be emailed around, presumably.
Alex On Wed, Feb 28, 2018 at 2:29 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
