I would echo Mr. Gaynor's point. While it's perhaps a pedantic distinction, the private keys are definitely compromised now and were the moment that Trustico provided the keys to Digicert, even if Trustico is defined to be the original authorized recipient.
The CA is explicitly not to be in possession of these private keys and if Digicert's assertions are correct, Digicert now holds the private keys. It would seem that revocation is unquestionably the appropriate remedy at this time, despite whether or not Trustico understands what they requested. On Wed, Feb 28, 2018 at 1:32 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
