Mozilla

Ein jährlicher Prüfbericht kann zeigen, dass die Kontrollen einer Zertifizierungsstelle über einen abgegrenzten Zeitraum untersucht wurden. Er beantwortet allein nicht die kleinere und für eine vertrauende Partei wichtigere Frage: Warum wurde dieses Zertifikat für diesen Namen und diesen Schlüssel zu diesem Zeitpunkt ausgestellt, und was geschah später, als ein Client ihm begegnete?

Mozillas öffentlich dokumentierte Regeln trennen Vorgänge, die im Alltag leicht in einem Satz verschwinden. Ein Modulverantwortlicher oder Peer kann eine Änderung für ein bestimmtes Modul genehmigen; einer Person kann separat Repository-Zugang gewährt werden; eine Änderung kann in einem Branch landen; Firefox kann sie später in einen öffentlichen Kanal übernehmen – oder nicht. Die Vorgänge hängen zusammen, aber keiner beweist den anderen.

Eine CA kann im September 2026 korrekt auf die aktuellen TLS Baseline Requirements verweisen und trotzdem den alten Ableitungsweg für Authorization Domain Names verwenden. Version 2.2.9 führt zwar die sicherere Reihenfolge ein, erlaubt aber bis 15. November ausdrücklich Abschnitt 3.2.2.4 aus v2.2.7. Die Übergangsfrist ist Teil der Norm, kein Verstoß. Unzureichend ist ein Ausstellungsnachweis, der diese Wahl nicht erkennen lässt.

Mozilla initiierte die Public Suffix List, und Firefox verwandelt bis heute eine ihrer Versionen in Browserverhalten. Das DNS zeigt, dass `whatwg.github.io` unter `github.io` liegt, aber nicht, ob zwei Subdomains derselben Verwaltung oder einander misstrauenden Nutzern gehören. Dieser Artikel verfolgt Mozillas zwei begrenzte Rollen als Initiator und nachgelagerter Implementierer, um zu zeigen, wie ein Gemeinschaftsverzeichnis Sicherheitsmacht gewinnt, ohne Mozillas Eigentum zu werden.

Mozillas Add-on-Ausfall im Mai 2019 zeigte, wie eine legitime Sicherheitsanforderung zu einer Common-Mode-Verfügbarkeitsabhängigkeit werden kann, wenn Zertifikatslebenszyklus, Fernwiederherstellung, Datenschutz und Benutzerdatensicherungen zusammenwirken.