On Monday, June 24, 2024 at 12:43:52 PM UTC-4 Amir Omidi (aaomidi) wrote:
Let's take a step back from this report. I don't think this report deserves to be taken seriously for one reason alone: You've historically proven to the community that we should not trust any statements made by Entrust. Let's look at how you've proven this: First - Four years ago, you made a couple of promises in comment 6 of 1651481 <https://bugzilla.mozilla.org/show_bug.cgi?id=1651481#c6>: - We will not the make the decision not to revoke. - We will plan to revoke within the 24 hours or 5 days as applicable for the incident. None of these promises have been realized in the past four years. Why is this time going to be different? How are we even supposed to measure your commitment to your current action items? Our updated report addresses this. What will be different is addressed in the overview section. Action items and metrics are in Appendices 2 & 3. Per Bhagwat Swaroop’s letter to the community, we will provide regular progress reports to the community. If we receive additional comments that should be incorporated into our action plan, we will do that. Second - In this report, you're claiming that a lot of these issues stem from organizational structure. Meanwhile, 3 months ago, Entrust was claiming that: <https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c1> 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 So putting these two together, what Entrust seems to be doing is pressing shuffle on the same playlist that's led to all of this. Third - As you were sending out this Entrust Report Final-ForRealThisTime.pdf, we had Entrust continue to make nonsensical arguments <https://bugzilla.mozilla.org/show_bug.cgi?id=1890685#c46>. Even after it was pointed out by both Chrome <https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c44>, and Mozilla <https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c39>, that what you're doing is not okay. To be very clear here, this comment by Entrust was made on 2024-06-19 while we received this new report from Entrust on 2024-06-21. Entrust has not even bothered covering this incident in this report. Fourth - As evidenced in your recent incident responses, you don't really care about 1) what the community says 2) what Mozilla says. Time and time again, I've only seen Entrust change their tune on matters when Ryan Dickson (Specifically, Chrome Root Program) chimes in. Fifth - Some of your action items make absolutely no sense for a well-established CA: - Expand use of linters post-issuance for all certificate types - Expand use of linters pre-issuance for all certificate types - Implement process during incident review to stop issuing certificates when a mis-issuance event has been confirmed Are you claiming you didn't have the linting in place already? Did we learn nothing from all these previous incidents: - https://bugzilla.mozilla.org/show_bug.cgi?id=1635096#c14 - https://bugzilla.mozilla.org/show_bug.cgi?id=1667448#c7 - https://bugzilla.mozilla.org/show_bug.cgi?id=1648472#c9 - https://bugzilla.mozilla.org/show_bug.cgi?id=1448986#c7 You've had issues with, arguably one of the easiest parts of being a CA, linting. Your issues with linting go back at least six years. Seriously, how do you have so much difficulty with properly implementing pre, and post issuance linting? Linting has been standard operating process at Entrust since March 2018 for post-linting and May 2019 for pre-linting. We use zlint, and it was in use for pre and post linting during this incident. We plan to expand our linting capability by adding pkilint. With the next platform release (July 30, 2024), we will have linting coverage from both tools pre and post issuance." Beyond that, "Implement process during incident review to stop issuing certificates when a mis-issuance event has been confirmed" At Let's Encrypt, and Google Trust Services we used the wording of "suspected". As a CA Engineer, I was empowered to stop issuance at any time if I suspected mis-issuance was happening. I've used that power both correctly, and incorrectly in the past in those CAs and it wasn't a big deal. Why are you waiting until a mis-issuance event has been confirmed? Which seems to take at least 24 hours at Entrust. Beyond the language used there being problematic, I'm extremely shocked that this isn't done yet? This was one of the main problems in Entrust's response to the cpsUri incident <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843>. How has it taken you nearly five months to address this? This happened in the past. As outlined in the report, we’ve taken measures to improve our processes and compliance moving forward. And yes, we are empowered to stop issuing while we investigate possible mis-issuance. Sixth - Is this report now happening under the new leadership of compliance? How about the report prior to this? The tone of these two reports are so significantly different that it seems like something changed between these two. What changed between these two incident reports that caused such a significant change in the tone of the report? The same team wrote both reports. The revised report has additional content to address community comments. Moving beyond the tone of these reports - does the new leadership of compliance see the substance of this current report as a satisfactory response to how much Entrust has dropped the ball recently? In conclusion - there were so many things you could've done that would've been significantly better than this bag of words in the format of a pdf. I'll list a couple: - Immediately revoke all the certificates that you're still in the process of revoking nearly three months later. - Reduce the lifetime of your certificates to 180 days until the end of 2024, and then to 90 days once 2025 starts. - Sunset the ability for non-automated certificate issuance to take place. These are all actions that are externally verifiable, and actually show a meaningful change by Entrust. To the community: Entrust, using their own words in this report, admits that they're unable to properly meet the requirements of being a CA due to their organizational limitations, and have created certain action items that are impossible to measure from the outside looking in. To me this sounds like a ship that's sinking, and instead of us being allowed to use lifeboats to get to safety, we're being told to wait while they move people around to balance the ship. I do not see any compelling reason to 1) Trust Entrust's claims here, given their past history of not being truthful and not sticking to their promises 2) Assume the risk on the entire WebPKI ecosystem while Entrust tries to figure out their organizational deficiencies. My suggestion here would be to distrust Entrust, and let them re-apply for inclusion in the future once they've asserted that they've fixed the deficiencies that have led Entrust and the community down this path. -- 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/e0aa1fc2-b6ae-4f7c-bc29-dca4ff982857n%40mozilla.org.
