Mozilla

An annual assurance report can show that a certificate authority’s controls were examined over a bounded period. It cannot, on its own, answer the smaller and more consequential question a relying party often needs to ask: why was this exact certificate for this exact name and key issued at that moment, and what later happened when a client encountered it?

Mozilla’s public governance material makes a useful distinction that reporting often erases. A module owner or peer can approve a change for a module; a person can separately be granted repository access; a change can be checked in or landed; and Firefox can later move code through a release train toward a user-facing channel. These actions are connected by work. They are not interchangeable proof.

A certificate authority can now point to one current set of TLS Baseline Requirements while legitimately running one of two different domain-control derivation rules. SC101 made the safer order explicit: choose the validation method, follow a permitted CNAME path, then prune labels if that method permits it. Yet until 15 November 2026, the adopted text also allows the previous v2.2.7 section. The transition is reasonable. An issuance record that fails to say which path it used is not.

Mozilla began the Public Suffix List, and Firefox still turns a version of it into browser behaviour. The DNS can tell software that `whatwg.github.io` exists beneath `github.io`, but not whether those names belong to one organisation or mutually untrusting tenants. This article follows Mozilla’s two bounded roles—originator and downstream implementer—to show how a community-maintained record becomes security authority without making Mozilla the list’s owner.

Mozilla's May 2019 add-on outage showed how a legitimate security requirement can become a common-mode availability dependency when certificate lifecycle, remote recovery, privacy, and user-data safeguards converge.