The keys were emailed to me. I'm trying to get a project together where we self-sign a cert with each of the keys and publish them. That way there's evidence to the community of the compromise without simply listing 23k private keys. Someone on Reddit suggested that, which I really appreciated. I think the main hold up in this plan is, which websites do we want to call out?
-----Original Message----- From: dev-security-policy <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org> On Behalf Of Peter Bowen via dev-security-policy Sent: Wednesday, February 28, 2018 12:38 PM To: Wayne Thayer <wtha...@mozilla.com> Cc: timx84...@gmail.com; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: How do you handle mass revocation requests? On Wed, Feb 28, 2018 at 11:29 AM, 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. Jeremy's email suggests that the keys were emailed to him. If this is accurate, then it is reasonable that they have been "disclosed to an unauthorized person". The only other alternative, again assuming Jeremy did receive the keys, is to determine that he was authorized by the subscriber to access the keys. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
