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> 
Sent: Friday, May 22, 2020 4:50 PM
To: dev-security-policy@lists.mozilla.org
Cc: Daniela Hood <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> 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 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
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to