On Wednesday, February 28, 2018 at 4:44:50 PM UTC-6, Jeremy Rowley wrote: > 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.
So, I suspect what I and others in the community, like Mr. Duff, are wondering is: Why did Trustico go to such lengths to forcibly cause revocation of all of these certificates? Because their initial request was for the revocation to occur and Digicert's initial position was that they are not the subscriber and so didn't have to revoke at their request they finally had someone put together the keys and re-request with the formal 24 hour deadline. That sounds like they went to significant effort to ensure the revocation would happen. If the keys were truly leaked or otherwise compromised, it makes sense. If they were not and Trustico just pulled them out to trigger the 24 hour revocation window, why did they do that? It seems like the only people they're (directly) hurting are their own customers. That's quite irrational behavior and generally businesses do not so overtly act against their own interest. That sort of thing will scare a customer away from a reseller in a hurry. So the question on my mind is, why would Trustico do that to their own customers? It can't just be about migration to a new CA, right? If so, wouldn't the certificates just be left valid and new certificates be issued by the new CA? Forcing the 24 hour revocation window just creates a support nightmare for Trustico and Trustico's customers with no apparent upside, unless there was a real compromise. Trustico's customers would seem to be entitled to know whether Trustico actually suffered a breach which compromises those customers. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
