All, If we strip away the cover page, table of contents, appendices and executive summary, the 17 page report goes down to somewhere in the realm of 13 pages.
If we take a closer look at those 13 pages, there's very little new information shared in the report that wasn't already shared in the various Bugzilla incidents. I don't see internal policies or procedures used to make their decisions on delayed revocation, I see exactly one reference to the previous delrev issues in 2020, in which it is offhandedly mentioned and again pushed onto Subscribers' responsibility, rather than the CA. I see statements that say "we intend to revoke following the BRs, unless a subscriber says we don't want to". I see references to IETF drafts and adoption of automation, but again, those *are not action items for a delayed revocation. *The problem is "we failed to revoke certificates, here's what we're doing to fix *that* problem", and the analysis and action items should reflect that. I also think it is absolutely impossible to judge a report at this point for the following reasons: 1. There are still unresolved delrev / failure to revoke incidents in Bugzilla, and this report is now drifting from what exists in Bugzilla. 2. Entrust is being even more evasive in answering questions in Bugzilla as of this report. There are numerous questions I as well as other community members, as well as individuals at other CAs have asked of Entrust that have either been ignored completely, ignored past the 7 day response period and only answered when prompted by another community member, and when answers are provided, they are seemingly copied from a internal working document on the best applicable answer that appears to have been workshopped, rather than the actual answer. Off the top of my head, I have multiple questions in 1886532 that remain unsatisfactorily answered, questions that should be a relatively easy answer. See Comment 52 <https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c52> If the report actually had action items and a deep understanding of the root causes that led them to this situation of failure to revoking certificates after promising it would never happen again, I would look differently upon this. Instead I see: - a report that admits to a policy that was supposed to be implemented 4 years ago is barely implemented, if at all (as if it were implemented it should have been documented in the report) - a CA who is being combative and evasive (which is just wrong from a public trust point of view) - certificates re-characterized as properly issued after being characterized as mis-issued (which is something that should absolutely be looked closer at, if the perceived solution by a CA to avoiding delayed revocation events is to simply re-characterize the certs as issued appropriately and refuse to elaborate further feels like something that is *Very Bad* for the ecosystem) - action items that don't seem to understand the organizational dysfunction that lead us to this series of misissuance events, and even for the minimal action items that exist, most are simply "tell Subscribers to do x" in more words In my opinion, evaluating the Entrust Report would only be possible given the following factors: - All delrev / failure to revokes are resolved satisfactorily (either via revocation or by an agreement by RPs that the certificates were indeed issued correctly, see 1890685) - All questions asked in all open bugs are answered satisfactorily, with meaningful answers that take the question asker in good faith, rather than being combative and evasive - A rewritten version of the report that A. acknowledges the missteps made in the submission of the report and the handling of the incident(s) and meta-incident around this, and B. answers the bullet points given by Ben W that should have been used as a framework to write the report, *including but not limited to* a thorough analysis and retrospective of the events of 2020, and learnings that were documented then, and why they weren't applied now. With the report as it is though, while I'm just a bystander who has become very interested in WebPKI as of the past few months, I feel that there is a clear lack of understanding of the responsibilities and duties of a CA due to organizational dysfunction at best, and at worst malicious incompetence. On Wednesday, June 12, 2024 at 9:05:53 PM UTC-7 Macy wrote: > 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/ea1ab89a-994b-4a33-bb45-195799532304n%40mozilla.org.
