On Thursday, June 13, 2024 at 3:38:54 AM UTC+10 Ben Wilson wrote:
All, So far, we have received substantive comments and questions on Entrust’s June 7 Report from Amir, Wayne, and Watson. Are others planning to submit comments or to request clarification and additional information from Entrust? Thanks, Ben Hi Ben, I just wanted to register my confusion and disappointment at Entrust's report and general responsiveness to community concerns. You mentioned in your original statement that "This is particularly disappointing in light of previous incidents in 2020 (#1651481 <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$> and #1648472 <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>), which arose out of similar misunderstandings of the requirements, similar poor decision-making in the initial response, and lengthy remediation periods that fell well below expectations. Entrust gave commitments <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> in those bugs to address the root problems through process improvements, and it is concerning to see so little improvement 4 years later." A thing that is notably missing from Entrust's report, given your explicit prompting, is any retroactive discussion of the events in 2020 or the changes they implemented in response to those incidents, or how those changes were insufficient to prevent these incidents. I haven't read every bugzilla comment so I may have missed other mentions, but in Bug #1890685 comment 39 <https://bugzilla.mozilla.org/show_bug.cgi?id=1890685#c39>it appears that the changes Entrust internally identified 4 years ago related only to the adoption of automation, with nothing learned about the failures in their process or adherence to the BRs. I find the report worrisome, because this shows that Entrust has not been and is still fundamentally not taking delayed (or failed) revocation as seriously as a WebPKI CA should. To that end, some of the action items in 1901270 <https://bugzilla.mozilla.org/show_bug.cgi?id=1901270> would strongly benefit from some explanation to the community as to what happened from the 2020 commitment to today, specifically: - Implement formal incident response process including incident response communication plan to meet mandatory reporting times - Implement specific handling processes for internal as well as external (CPR) reports - Review verification process for all certificate types - Create formal revocation event handling process - Establish delayed revocation criteria - Create revocation event communication plan How did these seemingly get missed in 2020, and continue to be missed for 4 years of operation, after making a commitment to always revoke certificates in accordance to the BRs? What was the process breakdown that led us to be here, watching a CA that predates the formalisation of the BRs just now committing to having a formal process for revocation events? What is the current process, how has it changed from 2020, and why is it still insufficient? What changes will be made to the process to ensure its sufficiency in the future? This is the bulk of what I expected to be reading in the report (and were explicitly requested in the prompt), but instead I saw the level of detail that should have been in the initial bugs with no acknowledgement or awareness of the overarching strategic failures that got them to this point. In addition, I'm greatly troubled by the way that bug 1890685 <https://bugzilla.mozilla.org/show_bug.cgi?id=1890685> was filed as a failure to revoke and treated that way by both Entrust and RPs for two months, only to have Entrust change interpretations and decide that there is no issue there. This entire bug was seemingly unaddressed by their report, and the timeline of the changed interpretation is confusing. Do other CAs share their understanding expressed in that bug that their CPSes' details don't matter if they say "unless the BRs override this"? I have questions about the status of monitoring Bugzilla to learn from events from other CAs, but they're mooted if the CA isn't learning from its own incidents either. I want to reiterate that the problem as I see it is not insufficient contrition, but rather insufficient self-awareness. I find it alarming that they are not showing recognition of the core problem here; namely, their continued retention of subscribers that they are willing to violate the BRs for and how that affects the trustworthiness of WebPKI in the event of future misissuances. I've looked through previous incidents where CAs were asked to participate in this process, and I have seen genuine signs of turnaround from CAs that were previously flirting with a distrust decision, but in each of those cases, there was a willingness to identify the deeper causes of failures that seems to be organisationally lacking here. The entire incident response from March onward comes off to me far more like a PR exercise than an attempt to meet other technologists in improving the WebPKI ecosystem. --Macy -- 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/7899419b-13c1-43ab-bf8c-0740d632b720n%40mozilla.org.
