1) Not all of the certificates being revoked use the Symantec hierarchy. There are some certs that use the DigiCert replacement hierarchy. Not many though. 2) Sorry my wording was strange. It almost always is. What I meant, is Trustico specifically asked for the certs to be revoked within 24 hours as required by the BRs. They said in the email they were triggering the 24 hour requirement. 3) I really feel like a third point would be important, but I can't think of one.
-----Original Message----- From: dev-security-policy <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org> On Behalf Of Matthew Hardeman via dev-security-policy Sent: Wednesday, February 28, 2018 3:23 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: How do you handle mass revocation requests? On Wednesday, February 28, 2018 at 3:55:37 PM UTC-6, Ryan Duff wrote: > >From what I've read, it appears the situation here is that Trustico wanted to revoke all their customer certs from Digicert so they could do a mass migration to another CA (which is not a proper reason to revoke). When asked for proof by Digicert that the certificates were compromised and needed to be revoked, Trustico sent Digicert 23,000(!) private keys that *they had stored* due to the fact that they were generated by their web-based system in order to effectively *make them* compromised. > > Am I missing anything? That's kind of what I was thinking happened also. Though a couple points to correct: The original issuing CA hierarchy is a Symantec trust path. This suggests that what they really wanted to occur was to trigger a 24 hour reissue of all of these certificates under a DigiCert trusted path -- since presumably any issuance at this point would fall under a DigiCert path. Thus, within 24 hours, getting new certificates for all their customers under the new trust path. I'm going to guess someone at Trustico was getting annoyed at support calls regarding the migration and somehow assumed there'd be no consequences for pushing the issue by way of getting all those certificates revoked on "security" grounds. As grounds for this belief, I submit the strangely worded statement of Mr. Rowley at the start of the thread "Later, the company shared with us that they held the private keys and the certificates were compromised, trying to trigger the BR's 24-hour revocation requirement". That language seems to imply that there's a sense that the security / web PKI integrity aspect is less the matter at stake and more that the keys were located and sent over to create an impossible to ignore security issue forcing the 24 hour window. My guess is that the person at Trustico wanted immediate reissuance of all of the Symantec certificates under the DigiCert trust paths and assumed: 1. That revoking the certs for security reasons would result in ASAP reissue (probably true in one-offs). 2. That the reissuance would happen in the DigiCert trust path (almost certainly true). 3. That they'd have a spike of support issues related to the reissuances, but that Trustico would have more control over the period over which they had to help customers migrate certificates and then the "bleeding" would stop. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/1SicdYM5NOSV8S29ZlemtDgUftWWe-mEnCeFfDCfA lw=?d=paMnJZlER7IHb626K-31V2u-Kf4DBs2hoO7Bro78ZuywH3EZ9N1dve7JXTCFPZFHyQrvw7 cDEqjPm1CCO0iQqqCbe-J7q2_uVOXTQzSslJpmeaUe9RmpgB81xaobKJOyb_YpAY8IOdkE832w7N tu7J94BmAMUFyIN-LINYJhcdKrmRggiP3dwENTjoH8GFBgeJgbAAJ7AXEY8EsaOLt-dqVymUiml9 GCqK8Pz2bZYq21i2TjrlH5i5ctTnHGcaJLrBukwohzJ1XA0B0Ma6sfh6NdDO9yi3psZCXUIDcZyp 5FtLBoYtTo6DUQVC8VhfOJY6KGhSpursgUnQdy6yQRtirjLO9kmIOKJSuJvlbaKD3gYKkxIRzMLA 6jPbVCxU77Z6q6OAnzLtAIRiCe7-MVzty2jFdcG8R9uiVI7Vf241-3ANcBFbr288JrDaZYHwhYJu rWo3wUC3HNJXFV_nf74MJE&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-se curity-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
