Zusammenfassung

  • Die aktuelle Mozilla-Policy trennt Root-Store-Pflege, zeitraumbezogene Assurance und die Prüfungen, die vor der Aufnahme von Abonnenteninformationen in ein Zertifikat nötig sind.
  • Weder Policy noch Zeitraumaudit rekonstruieren einen bestimmten Antrag, eine Validierungsbeobachtung, eine Ausstellung, einen späteren Sperrstatus oder ein bestimmtes Client-Ergebnis.

Die seit dem 1. Juli 2026 geltende Mozilla Root Store Policy 3.1 ist gerade deshalb aufschlussreich, weil sie richtige Aussagen nebeneinanderstellt, ohne sie gleichzusetzen. Mozilla verteilt CA-Zertifikate mit zweckbezogenen Trust Bits. Für erfasste Roots und technisch zur Ausstellung wirksamer Server- oder Mail-Zertifikate fähige Intermediates verlangt die Policy bestimmte Audits vor der Aufnahme und danach mindestens jährlich. Sie verlangt außerdem, dass vom Subscriber gelieferte Informationen vor der Aufnahme in ein Zertifikat über eine unabhängige Quelle oder einen alternativen Kommunikationskanal geprüft werden.

Bei TLS-Zertifikaten muss die CA Berechtigung für die Domainnamen und Kontrolle über IP-Adressen nach dokumentierten Verfahren sicherstellen.

Jede dieser Aussagen ist bedeutsam. Keine wird von selbst zum Beleg für die nächste.

Ein Audit hat eine Assurance-Grenze: abgedecktes System, Kriterien, Zeitraum, Methode, geprüfte Nachweise, Feststellungen und Beschränkungen. Die Policy verlangt, dass Zeitraumauditinformationen mindestens jährlich aktualisiert werden. Für jährliche Prüfzeiträume ab dem 1. Juli 2027 verlangt sie zusätzlich für bestimmte CAs mit Website-Trust-Bit einen Detailed Controls Report. Dieser Bericht soll Systemgrenzen, Kontrollen, Umsetzung, Prüfungen und Wirksamkeit beschreiben. Das ist wertvolle Governance-Evidenz, aber weder ein Journal aller Zertifikatanträge noch der zeitgenössische Nachweis einer einzelnen Ausstellung.

Der Unterschied zeigt sich am Zertifikat. Seriennummer, Aussteller, Gültigkeit und Subject Alternative Names beschreiben ein Objekt. Sie sagen nicht, welcher Antrag einging, welche Verfahrensversion galt, welche Person oder automatisierte Kontrolle zuständig war, was die unabhängige Quelle feststellte, ob die Beobachtung noch im zulässigen Zeitfenster lag oder weshalb ein Schlüssel mit diesen Namen verbunden wurde. Ein Prüfungsurteil erzeugt diese fehlenden Verknüpfungen nicht dadurch, dass es existiert.

Auch die umgekehrte Ersetzung ist falsch. Ein Ausstellungsdatensatz kann zeigen, dass ein Objekt entstanden ist. Er beweist nicht, dass die gesamte Kontrollumgebung über einen Prüfzeitraum funktionierte, alle Betriebsorte im Scope lagen, kein späterer Sachverhalt eingetreten ist oder jede abgeleitete Distribution denselben Root-Umgang beibehielt. Die Mozilla-Policy weist selbst darauf hin, dass Vertreiber auf Mozilla-Software beruhender Produkte Zertifikate und Trust Bits hinzufügen, löschen oder ändern dürfen. Die Policy regiert also Mozillas Standarddistribution, nicht jede denkbare Distribution.

Ausstellung ist auch nicht spätere Annahme. Die NSS-Dokumentation trennt Zertifikatsblöcke von Trust-Blöcken und beschreibt einen Root als Zertifikat plus Vertrauenseinstellungen. Ein Client muss weiterhin unter seinem Softwarestand und seinen lokalen Bedingungen einen Pfad bilden und bewerten. Hostname, Zeit, Erweiterungen, Pfadbildung, Sperrinformation, Anwendungszweck und der beim Verbindungsaufbau beobachtete Dienst sind eigene Fragen. Das behauptet kein Versagen eines bestimmten Clients; es begrenzt nur, was Audit- oder CA-Unterlagen ohne Client-Evidenz beweisen können.

Praktisch nötig ist ein begrenzter Ausstellungsnachweis. Geschützt zu bewahren sind Antragskennung; beantragte Namen und Schlüsselfingerabdruck; Regel- und Verfahrensversion; berechtigte entscheidende Person oder automatisierte Kontrolle; unabhängige Beobachtung oder alternativer Kanal samt Zeitfenster; danach Seriennummer, Aussteller, Gültigkeit, relevante Erweiterungen und Ausstellungszeit. Spätere Sperrinformation wird getrennt mit Abfragezeit und Antwortkontext bewahrt. Auch das Client-Ergebnis gehört getrennt dazu: Build- oder Policy-Grenze, Hostname, Pfad und Zeit, ohne unnötige Nutzerdaten zu sammeln.

Das fordert keine Veröffentlichung von Domainkontrollnachweisen, Kundendossiers oder Verteidigungsdetails. Gefordert ist nur, dass eine Behauptung nicht die Stelle einer anderen einnimmt. Sensible Nachweise können unter angemessener Befugnis geprüft werden. Dauerhaft bleiben muss die Karte der Verknüpfungen: Welche Entscheidung stützte welches Objekt nach welcher Regel, und welche spätere Beobachtung wird tatsächlich behauptet?

Evidenzgrenzen

Die geprüften Quellen nennen keine CA, keinen Subscriber, kein Zertifikat, kein Audit-Urteil, keinen DCR, keinen Vorfall und kein Relying-Party-Ereignis. Sie beweisen keine Pflichtverletzung. Der vorgeschlagene Nachweis ist redaktionelle Analyse, keine Vorgabe von Mozilla, CA/Browser Forum, NSS oder RFC.

Quellen

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS: Updating NSS’s Root Store
  3. RFC 5280