While this revised report and letter from leadership is a substantial improvement compared to what was submitted on June 7th, I share a number of the concerns raised by others here:
1) Swaroop's letter contains the line "As a global CA we must walk a tightrope in balancing the requirements of the root programs and subscriber needs, especially for critical infrastructure." There is no tightrope to walk here. As a custodian of public trust, a CA must transparently and strictly enforce the rules under which they operate. Subscribers will then take appropriate actions to reach an acceptable level of risk for their operations, which, for critical infrastructure subscribers, could mean anything from having hot spare certificates from an alternate CA ready to go, to migration to a privatePKI. That nearly the highest level of Entrust's leadership still does not recognize this has me worried that this is lipstick on a pig rather than actual meaningful change. 2) Though very pretty in language, these documents are shockingly light on quantitative, externally measurable, metrics on which to define improvement. I would have at a minimum expected Entrust to commit to almost never delay revocation again (e.g. "we commit to delaying revocation of no more than one certificate per thousand in future incidents"), to commit to not knowingly issue certificates to subscribers for whom revocation in 24 hr/5 days would cause significant harm, and to commit to other actions that help meaningfully move the webPKI ecosystem towards agility and resilience (such as issuing certificates with lifetimes of no more than 1/2 year starting "now", and 1/4 year starting January 2025). Even the commitments to automation and ARI are shallow, missing, e.g., a commitment to not charge customers more for using them, and missing quantitative targets for the fraction of subscribers to be on fully automated certificate pipelines by particular dates. Instead this report commits to almost nothing that is publicly measurable, and comments from Entrust representatives on various open bugs, even after June 21st, make clear that they are unwilling to commit to a quantitative limit on revocation delays, and all but state they will continue to issue certs to subscribers who cannot tolerate a 24 hr / 5 day revocation timeline. I think that the lack of concrete metrics is a serious deficiency. 3) It is impossible to tell given the shifting language, but it seems to me that, as of this report, Entrust still disagrees with https://bugzilla.mozilla.org/show_bug.cgi?id=1890898 and https://bugzilla.mozilla.org/show_bug.cgi?id=1890685 being misissuance events. This I think also speaks volumes about the proposed changes in operation not being changes that meaningfully alter the outcomes of how Entrust behaves as a CA. Based on these observations, and those of others on this thread, I highly encourage mozilla and other root store operators to distrust Entrust as soon as practicable, e.g. to immediately distrust all Entrust certificates with a not-before of July 1, 2024 or later, and rapidly phasing out the roots. And if Entrust believes they have made meaningful changes that make them again deserving of public trust, that they reapply for inclusion at a later date. Tyrel PS: For the Entrust business leadership: this is not the end of the world in providing certificates for your customers. Nothing prevents you from becoming a reseller (even a branded reseller) of certificates from another public CA. On Friday, June 21, 2024 at 2:59:25 PM UTC-4 Bruce Morton wrote: > Attached is a letter from Bhagwat Swaroop, President of Entrust Digital > Security Solutions, along with an updated response to address questions > from the community. > > Thanks, Bruce. > > On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote: > >> I am not going to say with certainty that Entrust is definitely putting >> Chrome over Mozilla. However, I hope they know that most Linux systems out >> there use the Mozilla root store directly. >> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote: >> >>> On Tue, Jun 18, 2024 at 12:49 PM Walt <[email protected]> wrote: >>> >>>> I'd just like to point out that we now have a situation where Entrust >>>> is in the position of seemingly valuing the opinion of other Root Programs >>>> over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42 >>>> >>>> In Comment #37, it was hinted at (and made slightly more explicit in >>>> #39) that the opinion of the Mozilla RP is that the attempt to >>>> re-characterize these certs was not going to be looked kindly upon, and >>>> only once a Google RP member explicitly said that it was the Google RP >>>> opinion that the certs remained mis-issued was any movement made on >>>> re-confirming the mis-issuance and taking action to revoke them. >>>> >>>> Also, if we're in a position where Entrust is finally able to commit to >>>> revoking certs within a 5 day period (setting aside that these certs >>>> technically need a delayed revocation bug as the mis-issuance was known as >>>> far back as 2024-04-10), why are other incidents not able to be resolved >>>> in >>>> this amount of time? Is it because Google showed up? >>>> >>> >>> We’ve seen this behaviour in other incidents as well, I believe >>> including the cpsURI one that has turned into a magnet for evidence of poor >>> operation and lack of transparency and responsiveness. I remarked on it in >>> my initial snarky reply to the Entrust Report, in fact. >>> >>> From a realpolitik perspective their behaviour could indeed be rational, >>> especially when the only tool root programs have is distrust. Firefox would >>> suffer substantial market disadvantage if it stopped trusting Entrust >>> certificates when other browsers didn’t. I think people generally >>> underestimate how much Mozilla would be willing to take near-term pain to >>> protect users, but it’s also possible that I am overestimating it. >>> >>> Related to that, I think Chrome’s root program representatives have >>> generally been more willing to take a concrete position quickly, so Mozilla >>> might be waiting for more explanation when Chrome decides that there’s no >>> explanation that could suffice, or similar. The root programs tend to be in >>> agreement more often than not (virtually always with Chrome and Mozilla, I >>> would say, excepting some slightly different root store populations), so it >>> may be somewhat irrelevant whose opinion spurs motion. >>> >>> Realpolitik analysis aside, I do agree that Entrust has created the >>> impression that they care much more about Chrome’s opinion than Mozilla’s, >>> which IMO might not be the best posture to take given that Mozilla and its >>> community are the locus for the processing and evaluation of the incidents >>> in question. >>> >>> Mike >>> >>> >>> >>> -- 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/19e16f5a-1011-4e4a-8c1f-55a859c70208n%40mozilla.org.
