On Monday, June 24, 2024 at 1:25:47 PM UTC-4 Walt wrote: Some final thoughts on this after re-reading the updated report:
*First*, a deliverable due date is a deliverable due date. If I was asked to answer 7 questions by my management team by a given deliverable date, and provided a report that barely answered two of them, I'd be thinking long and hard about what got me to that point (and the future of my continued employment), and why an updated report took an additional two weeks to create. I would argue that Entrust should be judged based on the initial report primarily, as the due date was very clear, as well as the guidelines for assembling the report. The second report *should* have been what we saw the first time, but this theme of "Entrust doing closer to the right thing late" seems to be a recurring trend with this series of events. This even goes as far back as 2020, when there was allegedly a promise that this wouldn't happen again (or at least not at the scale it did in 2020) and yet here we are. *Two*, as Amir noted, there's numerous inconsistencies with the report(s) compared to incidents. This issue has been prioritized at the highest levels within Entrust. We have hundreds of people across Entrust working on remediation—including our senior leadership as well as teams from Customer Support, Operations, Sales, Legal, Compliance, and Product Management, and we have been working hand in hand with executives at Global 2000 companies who are impacted. Our colleagues are working around the clock to support our customers, meet CA/B Forum expectations, and expedite revocation and re-issuance of affected followed by saying [paraphrased]: "The work we were doing previously wasn't good enough so we tossed it all out". Is the goal in this updated response simply to make it seem like enough changes have been made to kick the can down the road again for a few more years until Entrust makes some relatively simple mistake that could have been caught by linting and then we end up in this same boat again? The updated report included additional details based on comments and feedback that helped us understand the level of detail the community wants to have visibility to. *Third*, I'll reiterate the fact that Entrust seemingly doesn't take the opinion of Mozilla RP and the associated community seriously. The incident (#1883843) <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843> that started this *all*, was only taken seriously (12 days after posting) when the original reporter (who happened to be with Google RP) came in and said that the response did not meet Google RP's standards. Only *then* did mis-issuance stop. *Fourth*, I'll re-iterate as well that pre and post issuance linting feels like a pretty table stakes feature to prevent giving customers certificates that are mis-issued, avoiding the awkward conversations you seem to continually be having with your subscribers. Instead you knowingly issue certificates that might be mis-issued to subscribers, don't pause issuance, and wind up digging a bigger hole which could have been avoided if Entrust team members were empowered to pull the circuit breaker at any time. *Fifth*, there's very little in this report that's measurable in terms of improvement. It digs deeper into what happened sure, but most of these metrics require trust in Entrust to be sharing these metrics correctly to evaluate their compliance with the report. To put it bluntly, I trust Entrust about as much as I could throw Entrust, which is not very far. Given that, I see no reason to trust these metrics given by Entrust, and as such I see no objective way of measuring these commitments. In conclusion, I would second Amir's suggestion that Entrust be distrusted, and re-apply for inclusion once the organizational deficiencies have been resolved. Walter -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4d29a015-5a05-4b3a-81da-5ee99865fe44n%40mozilla.org.
