One item that I think could bear a useful discussion from these incident reports is how the community can get more involved in discussing and helping with incident reports. For example, the 63 bit serial number issue is leading to a lot of certs potentially being revoked with little benefit to the community (IMO of course). There are definite downsides to revocation that may or may not be fully considered when people are responding to incidents. For example, adding a bunch of certs to a CRL for a minor issue seems like a pointless increase in CRL size. There's also the customer disruption and other issues to consider that are probably important for the community to know when looking at incident reports.
I'm wondering if we (the community or CABForum) should have some mechanism of evaluating these risks and proposed incident plans before/while the plan is executed. For example, the pros and cons of revocation of the certs could be discussed. Actual revocation would be up to the CA , course, and any non-compliances would be noted on the audit report, but this part of the policy could be a community effort: "That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays." (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation). We could have the CA propose a rough draft to the community where they engage in a QA about the incident and then have members make a recommendation to the CA about remediation. All voluntary on the advice. This is probably the way it is supposed to currently work, but right now the flow seems like: 1) Post to Mozilla 2) Create an incident report 3) Community discussion about compliance and why CAs need to do better 😊 4) Update incident report until Wayne closes it A new flow that includes the community more fully could be: 1) Post to Mozilla, the post must include an initial proposed plan of action 2) Create an incident report (to track bugs) 3) Discuss on the Mozilla forum the proposed plan and post updated plans based on member suggestions 4) Post a final draft to Bugzilla 5) Post updates per a timeline set in the incident report 6) Wayne closes the bug. This is probably a lot more work for the CA, but I know we'd find the community feedback on how to resolve issues useful. Maybe it could also change into a continuous flow of "How can X CA do better - here's some suggestions" instead of "Better put up the lightning rod and get through this". Thoughts? Again, probably how this is supposed to work already, but if we can turn it into more actionable feedback about what's next, then I'd find that super useful. Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Daymion Reynolds via dev-security-policy Sent: Monday, August 20, 2018 10:27 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: GoDaddy Revocation Disclosure On Saturday, August 18, 2018 at 2:27:05 PM UTC-7, Ben Laurie wrote: > On Fri, 17 Aug 2018 at 18:22, Daymion Reynolds via dev-security-policy > < dev-security-policy@lists.mozilla.org> wrote: > > > Revoke Disclosure > > > > GoDaddy has been proactively performing self-audits. As part of this > > process, we identified a vulnerability in our code that would allow > > our validation controls to be bypassed. This bug would allow for a > > Random Value that was generated for intended use with Method > > 3.2.2.4.6 and 3.2.2.4.7 and was validated using Method 3.2.2.4.2 by > > persons who were not confirmed as the domain contact. This bug was > > introduced November 2014 and was leveraged to issue a total of 865 > > certificates. The bug was closed hours after identification, and in > > parallel we started the scope and revocation activities. > > > > In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued > > certificates were revoked within 24 hours of identification. > > > > A timeline of the Events for Revocation are as follows: > > > > 8/13 9:30am – Exploit issue surfaced as possible revocation event. > > 8/13 9:30-4pm – Issue scope identification (at this point it was > > unknown), gathering certificate list > > 8/13 4pm – Certificate list finalized for revoke total 825 certs, > > Revoke notification sent to cert owners. > > > > I presume you mean domain owners? > > Do we know if any of these certs were used? If so, how? > > > > 8/14 1:30pm – All certificates revoked. > > > > Further research identified 40 certificates which contained re-use > > of suspect validation information. > > 8/15 – 2pm – Additional certificates identified due to re-use. > > 8/15 – 2:30pm – Customers notified of pending revoke. > > 8/16 – 12:30pm – All certificated revoked. > > > > We stand ready to answer any questions or concerns. > > Daymion > > Yes, domain owners. Yes, some of the certs were being used as typical server certs. We have not detected any nefarious activities. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/SBQDHoNcfxIDo-iEQJuT-dmr7_pW60OdL-qV1EsnpHA=?d=bqzo5p3oDP-sRSQId_bPtHZigaw6daIpv_RsZQkwY-iHzzEA9WJYCCgyej3-L1Kn1kdzI7y7RWimDSsQZGlm9Fzw9NuG4hz0W-b_SuJ7uL9yiouYvIx6Wu4BsWwhF0FfeXN8L8dCJ3oaQPf_L2RelGC9xWRYrBkZWSGYN_1-HcPQIVhUYElwCGv09MRZjSB9vCm27aJXNSf1EPNSQX588qKM3jvO66sFZV2eO86SP2Jtmj1tW8eq1S8dSuu4_27dgMB7fnu9BaDMAsD6324YyDIlTGrTKRblMwbO3piSWYwiVoPg3Oh-XWcs8D9oVhjs8TWpvBcNUUt6zuHrA_ieaEzCik7_j1K3AEwVGrtmeh8eB7RhvP8OuyoXM4XBbf0AI8RySn6OrgkCnq22P3R2fuNooB4-S5I5WmM%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-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
