Looking into this, we revoked the cert on our end at 2:20 MST (within 24 hours after the certificate problem report was processed), but we distribute all of our OCSP responses through CDNs. Distribution through the CDN took approximately an hour plus. I couldn't find a definition of revoked in the BRs, so I assume it's when we start distributing revoked responses, not when the CDN updates? Sorry for the confusion there.
Jeremy On Wednesday, June 21, 2017 at 2:39:57 PM UTC-6, Andrew Ayer wrote: > On Tue, 20 Jun 2017 21:23:51 +0100 > Rob Stradling via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > [CC'ing rev...@digicert.com, as per > > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028] > > > > Annie, > > > > "but these have been known about and deemed acceptable for years" > > > > Known about by whom? Deemed acceptable by whom? Until the CA > > becomes aware of a key compromise, the CA will not know that the > > corresponding certificate(s) needs to be revoked. > > > > Thanks for providing the Spotify example. I've just found the > > corresponding certificate (issued by DigiCert) and submitted it to > > some CT logs. It's not yet revoked: > > https://crt.sh/?id=158082729 > > > > https://gist.github.com/venoms/d2d558b1da2794b9be6f57c5e81334f0 does > > appear to be the corresponding private key. > > 24 hours later, this certificate is still not revoked, so DigiCert is > now in violation of section 4.9.1.1 of the BRs. > > Regards, > Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
