Mozilla: Entrust Issues
What is Entrust's and WebPKI's Future?
Taking a break from the Entrust Considered Harmful series with this breaking news.
Mozilla has collected and prepared a new page (archive) for recent Entrust incidents. I do not know if this is a precursor of Mozilla taking any mitigating actions against Entrust’s gross negligence and active disregard for the BRs. However, I think it’s still worth reading this report and looking at what potential options the root programs have, and especially how Mozilla can lead here.
On this page we see a sticking-to-the-facts style of reporting from Mozilla about what the classification of the incidents were, and the gist of the failures we’ve seen from Entrust.
Reading this post, and thinking about the Entrust Considered Harmful series, I would argue that Entrust hasn’t reached the historical level of non-compliance that would necessitate distrust. But as I discussed in “Beyond Distrust, what can a root program do?”, there are options that the root programs can take that aren’t the nuclear option.
My takeaway in Part 3 of the Entrust Considered Harmful Series was:
Entrust knows how to properly do incident response. They’re just choosing not to do so when the incident requires a large number of revocations.
Entrust isn’t an awful CA. They know how to do proper incident response, and generally have an alright operational stack. However, they never take fast and immediate action when they, like every other CA, inevitably mess up and have an incident. Demonstrating that Entrust will put their subscribers ahead of the requirements for being a CA. This creates an incentive for subscribers to choose Entrust for their CA needs. While also causing other CAs to consider behaving like Entrust.
This exact worry is something Ryan Sleevi specified way back in 2018:
However, let's further expand this thought experiment, and think about what
the consequences are of having the CA make such a determination
(Availability > Competent and Correct operation). A CA is naturally
incentivized to optimize for Availability - the CA who never revokes their
Subscriber certs is the CA to pick, the same as the CA that always picks
the maximum validity period rather than the minimum. This is something
we've seen time and time again - the worse a CA is, for the ecosystem, the
more popular it becomes relative to its competitors. But equally, a CA that
issues such invalid certificates, but encourages non-revocation, equally
encourages the rest of the ecosystem to do so, such that it becomes the
norm - a de facto standard of incompatibility.
Essentially, Entrust creates a situation where CAs need to decide:
Do I follow the BRs, and act like how an effective CA should operate? While potentially losing customers because I don’t put them ahead of these requirements?
Or, do I behave like Entrust is behaving so I can remain competitive and pay the bills?
What should happen?
With these all in mind, Entrust should be limited to 90-day lifetime certificates. We know 90-day lifetime certificates are significantly safer by:
Reducing the impact of a misissuance.
Incentivizing automation of certificate issuances and adoption of certificate lifetime management.
Reducing the ongoing cost of the manual work of certificate management, and the need to handle situations with emergency revocations.
Speeding up the adoption of new cryptographic primitives.
If Entrust continues to willfully ignore the BRs after such action from root programs, distrusting them would be the correct choice.
Beyond this, I believe a future ballot/rule to restrict all CAs to 90 day lifetime certificates should also be in the works.
The next few days will be interesting & exciting for WebPKI as we’re potentially turning the page on a new chapter.