Hello Cynthia, Our last post was intended to respond to the question immediately above it with regard to why the revoked certificate showed a revocation reason of 'cessation of operations' rather than 'compromise.' Additional information regarding what we are doing to ensure certificates are revoked within 24 hours of receipt of notice that a certificate is compromised can be found in the bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1640310 Daniela Hood GoDaddy
Daniela Hood GoDaddy | Compliance Manager [https://email-sig.gd-resources.net/img/godaddy-logo-outline.png] +16026881766 Gilbert, Arizona, United States dxh...@godaddy.com<mailto:dxh...@godaddy.com> From: Cynthia Revström <m...@cynthia.re> Sent: Wednesday, June 3, 2020 1:52 PM To: Daniela Hood <dxh...@godaddy.com> Cc: r...@sleevi.com; dev-security-policy@lists.mozilla.org Subject: Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours Notice: This email is from an external sender. Hi Daniela, Sorry if I am missing something, but what do you mean by "incorrect revocation reason"? The first sentence in the email sent to you by Sandy sounds pretty clear to me "Request you revoke the all certificate associated with this compromised key". Also I don't see how any of what you have said you have done would help to prevent it from taking over 24h again, could you please elaborate? - Cynthia On Wed, Jun 3, 2020 at 8:13 PM Daniela Hood via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Hello all, We appreciate the concerns and your questions to this thread. GoDaddy takes such issues very seriously and recognize the importance to the industry and health of the ecosystem. In the case where the user selected the incorrect revocation reason, we identified the error shortly before it was reported as part of a standard review. We reviewed the error with the user and corrected it the same day, per our procedure. Upon reviewing with the user, we identified an opportunity to enhance our process through additional visual cues to enable the agent to perform a final review prior to committing a revocation. Additionally, our process includes team calibrations where prior errors are used as training opportunities for the entire team. We also include any areas that have changed or where we notice an increased instance of errors in our annual training program. All of these efforts in combination help us to keep the instance of errors down and address situations as they arise. We hope this information helps address concerns regarding this error. Thank you, Daniela Hood GoDaddy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org<mailto:dev-security-policy-boun...@lists.mozilla.org>> On Behalf Of Daniela Hood via dev-security-policy Sent: Friday, May 29, 2020 9:16 PM To: 'r...@sleevi.com<mailto:r...@sleevi.com>' <r...@sleevi.com<mailto:r...@sleevi.com>> Cc: dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> Subject: RE: GoDaddy: Failure to revoke certificate with compromised key within 24 hours Notice: This email is from an external sender. GoDaddy acknowledges the inquiry and we will work to have a response to the community by Wednesday, June 3rd. Daniela Hood GoDaddy | Compliance Manager [https://email-sig.gd-resources.net/img/godaddy-logo-outline.png] +16026881766 Gilbert, Arizona, United States dxh...@godaddy.com<mailto:dxh...@godaddy.com><mailto:dxh...@godaddy.com<mailto:dxh...@godaddy.com>> From: Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> Sent: Friday, May 29, 2020 7:52 AM To: Daniela Hood <dxh...@godaddy.com<mailto:dxh...@godaddy.com>> Cc: dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> Subject: Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours Notice: This email is from an external sender. Thank you for your update. This does not appear to answer the questions raised. I would appreciate if GoDaddy shared a more meaningful response, in line with addressing the concerns Nick raised, as well as the outstanding matters on the bug. In particular, this response fails to analyze what went wrong, what has been done systemically by GoDaddy to prevent future incidents, and what are practices other CAs should consider to prevent similar incidents. In addition to the outstanding question from Nick, for this sort of response to be acceptable at all, more detail is needed: - What improvements were made, and why? - What training was done? What was changed? How is the training performed and evaluated? Why did the previous training fail to address this? Why is training seen as an acceptable answer, given previous training failed? What is done to support and monitor compliance to training? - What changes were made to the system? Why would they address this issue? How does that relate to why the issue? In 2020, publicly trusted CAs should not be expecting that such “incident reports”, if this can even be called that, are sufficient. As stewards of the trust placed in them by Mozilla and the broader community, and by other root stores, substantive and highly detailed, technical responses are expected. The goal of these reports is to both simultaneously address concerns caused by the failure to adhere to expectations and to help ensure that all CAs have an opportunity to learn from and implement similar mechanisms. If the response does not have sufficient information to allow for an independent implementation of whatever mitigations, and to the same level of assurance, it quite simply is not a response that meets expectations. We need to be able to work together, as an industry, to move things forward, and that requires complete transparency. On Thu, May 28, 2020 at 7:55 PM Daniela Hood via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org><mailto:dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>> wrote: Hello, We have made improvements on our problem reporting process, provided more training to our agents and made changes in our system to assure that such error would not happen again. We will keep on working with the community to find solutions that could benefit the industry, in hopes to avoid such errors from occurring. Daniela Hood GoDaddy -----Original Message----- From: Nick Lamb <n...@tlrmx.org<mailto:n...@tlrmx.org><mailto:n...@tlrmx.org<mailto:n...@tlrmx.org>>> Sent: Friday, May 22, 2020 4:50 PM To: dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org><mailto:dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> Cc: Daniela Hood <dxh...@godaddy.com<mailto:dxh...@godaddy.com><mailto:dxh...@godaddy.com<mailto:dxh...@godaddy.com>>> Subject: Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours Notice: This email is from an external sender. On Fri, 22 May 2020 22:48:42 +0000 Daniela Hood via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org><mailto:dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>> wrote: > Hello, > > Thank you for all the comments in this thread. We filed an incident > report related to the revocation timing that can be followed here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1640310. We also > identified the error in revocation reason as a user error, corrected > the error and provided feedback to the employee. In addition to Ryan's concerns about the supposed ambiguity of a pretty clear rule in the BRs I am as always interested in what can be learned from incidents that might help everybody else. What mechanism, if any, would have detected this "user error" in the absence of a report by a third party to m.d.s.policy ? Every CA has humans doing stuff, and humans make mistakes. Whether that's a Let's Encrypt team member fat-fingering a server configuration or a Symantec employee using google.com<http://google.com><http://google.com> rather than a Symantec name for a test. But even though it's expected for humans to make mistakes, we demand more of the Certificate Authority than we could ask of one human. Where humans are necessary they will make mistakes and so you need compensating controls. In this case that might mean reviewing critical work done by humans. Depending on volume that might mean a second person looks at every revocation, or it might mean a sample is examined once a week for example. I'd like to see incident reports like this not stop at "user error" for this reason. Why wasn't the "user error" caught? What (other than "feedback to the employee") prevents it happening again ? Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org><mailto:dev-security-policy@lists.mozilla.org<mailto: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<mailto: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<mailto: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
