Zusammenfassung

  • SC100 erhielt 22 Ja-Stimmen von teilnehmenden Zertifikatausstellern und drei Ja-Stimmen von Zertifikatsnutzern. Es gab weder Nein-Stimmen noch Enthaltungen. Die Schutzrechtsprüfung soll am 5. September 2026 enden; am Stichtag 31. August gehörte der Text noch nicht zu den geltenden TLS Baseline Requirements.
  • Der Entwurf bündelt vorhandene DNSSEC-Regeln. Für einschlägige Domain-Control- und CAA-Abfragen verlangt er die Validierung an der primären Netzwerkperspektive, abgesehen von einer begrenzten Ausnahme für E-Mail-Methoden. An entfernten Netzwerkperspektiven bleibt DNSSEC optional.
  • Multi-Perspective Issuance Corroboration, kurz MPIC, beantwortet eine andere Frage. Entfernte Beobachtungen bestätigen das Ergebnis der primären Perspektive. Eine entfernte Perspektive kann an MPIC teilnehmen, ohne dass die Regeln ihr zwingend eine DNSSEC-Validierung auferlegen.
  • Der Entwurf nimmt den vollständigen DNS-Abfragesatz aus bestimmten Protokollierungs- und Selbstauditpflichten aus, verlangt aber genügend aufbewahrte Information zur Überprüfung. Dafür sollte ein zeitlich begrenzter Resolver-Kontrollbeleg mit einem ausstellungsspezifischen Beleg verbunden werden, der die primäre Rolle nennt und DNSSEC je entfernter Perspektive separat festhält.

Gleiche Versionsnummer, anderer Rechtsstand

Die offizielle SC100-Seite dokumentiert ein ungewöhnlich eindeutiges Ergebnis. 22 teilnehmende Zertifikataussteller stimmten mit Ja. Bei den Zertifikatsnutzern kamen Ja-Stimmen von Apple, Cisco Systems und Mozilla hinzu. Niemand stimmte dagegen oder enthielt sich; das ausgewiesene Quorum von 15 wurde erreicht.

Ein Abstimmungsergebnis schließt den Übernahmeweg jedoch nicht ab. Nach derselben Seite begann die Schutzrechtsprüfung am 6. August um 19:00 Uhr UTC und läuft planmäßig bis zum 5. September um 19:00 Uhr UTC. Am Recherche-Stichtag konnten Mitglieder also noch Ausschlusserklärungen einreichen. Auch das Sitzungsprotokoll vom 13. August beschrieb SC100 als gerade in die IPR-Prüfung eingetreten.

Die Dokumente machen eine Fehllektüre besonders leicht. Der angenommene Änderungsentwurf trägt die Versionsnummer 2.2.9 und das Datum 6. August. Gleichzeitig bezeichnet die Seite der geltenden Anforderungen auch die aktuellen TLS Baseline Requirements als Version 2.2.9 vom 6. August. Deren Revisionstabelle endet aber mit SC101; SC100 erscheint nicht als veröffentlichte Revision. Der Dokumentenindex und die Prüfungsmitteilung liefern die entscheidende Unterscheidung: Das eine Dokument ist die geltende Final Guideline, das andere eine vollständige Draft Maintenance Guideline für die Prüfung.

Das ist keine pedantische Formalie. Ein Compliance-Nachweis muss den Status des zitierten Dokuments festhalten, nicht nur dessen Kopfzeile. „Version 2.2.9“ sagt allein nicht, ob die geltende Fassung, der angenommene SC100-Entwurf oder eine spätere, womöglich um SC100 ergänzte Veröffentlichung gemeint ist.

Auch der Abstimmungstext setzt eine Grenze: SC100 habe kein Inkrafttretensdatum, weil es um Klarstellung und Konsolidierung gehe und keine bestehende Anforderung geändert werden solle. Dieser Artikel verkündet daher keine neue DNSSEC-Pflicht. Er untersucht, welche Belege die klarer zugeordnete Pflicht überprüfbar machen würden.

Verpflichtend ist die Handlung einer Rolle

Die zugrunde liegende Pflicht stammt aus SC085v2. Seit dem 15. März 2026 müssen einschlägige Domain-Control- und CAA-Abfragen der primären Netzwerkperspektive bei vorhandener DNSSEC-Kette validiert werden. Die geltende Fassung 2.2.9 enthält diese Vorgabe an mehreren Stellen.

SC100 würde das Material in einem neuen § 4.2.2.2 bündeln. Zunächst beschreibt der Entwurf den Resolver der primären Netzwerkperspektive. Er muss nach RFC 4035 § 5 validieren, NSEC3 und SHA-2 unterstützen und die Sicherheitsaspekte aus RFC 6840 § 4 berücksichtigen.

Danach wird das Verhalten verteilt. Die primäre Netzwerkperspektive muss alle DNS-Abfragen validieren, die mit Domain Authorization or Control und mit CAA zusammenhängen. Für die verbleibenden E-Mail-Verfahren gilt eine Teilgrenze: CNAME-, CAA- und TXT-Abfragen zur Bestimmung des Authorization Domain Name bleiben verpflichtend, während für andere Abfragen SHOULD gilt. Bei den übrigen Verfahren und bei CAA darf lokale Policy die vorgeschriebene Validierung nicht ausschalten. Ein DNSSEC-Fehler an der primären Perspektive, etwa SERVFAIL, darf innerhalb dieser Abgrenzung nicht als Ausstellungserlaubnis behandelt werden.

Die Regel für entfernte Perspektiven ist anders formuliert. Entfernte Netzwerkperspektiven im MPIC-Verfahren dürfen DNSSEC bis zum IANA-Root-Trust-Anchor validieren. MAY bedeutet weder MUST noch MUST NOT. Der Entwurf erklärt entfernte Validierung nicht für unsicher oder unzulässig. Er legt den verpflichtenden Mindestkontrollpunkt an der primären Rolle fest und erlaubt zusätzliche kryptografische Prüfung an entfernten Orten.

Genau darin liegt die Beweisgrenze. Ein Feld wie dnssec_status=secure belegt wenig, wenn es die erzeugende Netzwerkperspektive nicht nennt. Ein korrektes Ergebnis einer entfernten Perspektive ersetzt kein fehlendes Ergebnis der primären Rolle, nur weil beide denselben Mechanismus verwendeten. Umgekehrt darf das primäre Ergebnis nicht bequem in entfernte Datensätze kopiert und als eigenständige Entscheidung jedes Standorts ausgegeben werden.

MPIC vervielfacht Beobachtungen, nicht das DNSSEC-MUST

Mit SC067v3 wurde MPIC eingeführt, um zielgenaue BGP-Angriffe auf Domainvalidierungen zu erschweren. Der heutige § 3.2.2.9 beschreibt, wie entfernte Netzwerkperspektiven vor der Ausstellung die Domainvalidierungs- und CAA-Feststellungen der primären Perspektive bestätigen.

Die beiden Kontrollen schützen unterschiedliche Übergänge. DNSSEC fragt, ob ein Resolver die kryptografische Kette von DNS-Daten und einen authentisierten Nichtexistenznachweis unter dem Protokoll-Vertrauensmodell prüfen kann. RFC 4035 unterscheidet Secure, Insecure, Bogus und Indeterminate. Diese Zustände beschreiben ein Validierungsergebnis, aber weder die Ausstellungsmethode einer CA noch die Beobachtungsrolle oder den endgültigen Entscheid.

MPIC fragt dagegen, ob hinreichend unabhängige entfernte Beobachtungen die primäre Feststellung bestätigen. Der SC100-Entwurf wiederholt den Stufenplan: Seit dem 15. Juni 2026 brauchen betroffene Umsetzungen mindestens vier entfernte Perspektiven, müssen die Quorumstabelle erfüllen und Bestätigung aus wenigstens zwei RIR-Serviceregionen erhalten. Ab dem 15. Dezember steigt die Mindestzahl auf fünf. Das sind Zahlen entfernter Beobachter und keine Anzahl verpflichtender DNSSEC-Validatoren.

Eine entfernte Perspektive kann demnach eine bestätigende Challenge- oder CAA-Beobachtung liefern, ohne selbst zu DNSSEC verpflichtet zu sein. Eine CA kann sich trotzdem für DNSSEC an diesem Standort entscheiden und den zusätzlichen Zustand erfassen. Beide Varianten passen zum Entwurf; der Nachweis muss ausweisen, welche vorlag.

Wer die Kontrollen zusammenzieht, gelangt zu zwei falschen Schlüssen. Zum einen soll ein bestandenes MPIC-Quorum beweisen, dass sämtliche Beobachtungen DNSSEC-validiert waren. Zum anderen soll optionales DNSSEC an den entfernten Perspektiven das Quorum wertlos machen. Beides steht nicht im Text. Netzwerk- und Ortsvielfalt wird nicht zu Kryptografie, und Kryptografie wird nicht zu Netzwerk- und Ortsvielfalt.

Die offene Protokollierung ist eine bewusste Entscheidung

Die Belegfrage entstand nicht zufällig. SC096 nahm DNSSEC-Prüfungen aus weitreichenden Protokollierungsanforderungen für DCV und CAA heraus. In der Begründung hieß es, Resolver seien nicht für umfassendes Logging ausgelegt; Change-Management-Unterlagen könnten zeigen, dass die einschlägigen Kontrollen wirksam waren.

Der vorgeschlagene § 4.2.2.2.7 in SC100 behält eine Ausnahme bei. Der vollständige Bestand an DNS-Lookup-Informationen zur DNSSEC-Validierung bliebe außerhalb der Selbstaudits nach § 8.7 und der Protokollierung nach § 5.4.1. Anschließend folgt aber die wichtige Anforderung: Ungeachtet dieser Ausnahmen muss die CA genügend Information aufbewahren, um die Einhaltung des übrigen DNSSEC-Abschnitts prüfen zu können.

Das Protokoll vom 16. Juli zeigt, dass die Offenheit beabsichtigt war. Die verbleibende Frage lautete, ob eine konkrete Logging-Lösung vorgegeben werden sollte. Die Teilnehmer bevorzugten ausreichende Belege bei freier Umsetzung. Nach der erneuten Diskussion des geänderten Wortlauts hielt das Protokoll vom 30. Juli vor der Abstimmung keine weiteren Kommentare fest.

Als Standardsetzung ist das vernünftig. Eine normative Anforderung sollte nicht jede CA auf denselben Resolver und dieselbe Speicherarchitektur festlegen. Die Freiheit verlagert die Arbeit jedoch auf das Evidenzdesign: Welcher kleinste Datensatz beweist eine rollenspezifische Handlung, ohne das vom Entwurf bewusst ausgenommene vollständige DNS-Protokoll nachzubauen?

Ein Beleg für die Kontrolle, ein Beleg für den Einzelfall

Die Antwort sollte nicht „alles protokollieren“ lauten. Sinnvoll ist eine begrenzte Verknüpfung aus zwei Belegen.

Der Kontrollbeleg beschreibt Resolver und Konfiguration der primären Perspektive für einen bestimmten Zeitraum. Mindestens gehören hinein:

Kontrollbeleg-ID + ID der primären Perspektive + Resolver-/Dienst-ID + Software und Build + Konfigurations- oder Policy-Hash + Trust-Anchor-Satz/Version + RFC-4035-Validierungsstatus + Nachweise zu NSEC3, SHA-2 und RFC 6840 + Zustand lokaler Ausnahmen + Testlauf-IDs + gültig von/bis + genehmigter Änderungsnachweis

Hashes und kontrollierte Referenzen können Geheimnisse und vollständige Konfigurationen ersetzen. Der Zweck ist, aus „DNSSEC war aktiviert“ einen zeitlich gebundenen, zuordenbaren Kontrollzustand zu machen. Change-Management-Nachweise zeigen hier, was Betreiber genehmigt und mit welchen Tests sie eine Resolver-Fassung verbunden haben.

Der Ausstellungsbeleg hält fest, was bei einem einzelnen Validierungsversuch geschah. Er sollte verbinden:

Versuchs- und Zertifikat-/Precertificate-ID + Anfrage- und Entscheidungszeit + angefragter Name und Geltungsbereich + Validierungsmethode + CAA-Umfang + geltende BR-/Entwurfsfassung + ID der primären Perspektive + Resolver-/Kontrollbeleg-ID + Abfragefamilien + DNSSEC-Zustand + Fehler und Fail-closed-Entscheid + IDs entfernter Perspektiven + DNSSEC-durchgeführt-Flag und Zustand je entfernter Perspektive + RIR-Regionen + MPIC-Beobachtungen und Quorum + Wiederholungsfolge + unveränderlicher Datensatz-Hash

Die wichtigsten Felder sind kurz: die ID der primären Perspektive und ein DNSSEC durchgeführt je entfernter Perspektive. Ohne das erste hat ein sicherer Zustand keine normative Rolle. Ohne das zweite bleibt Schweigen mehrdeutig: Vielleicht wurde die optionale Prüfung nicht vorgenommen, vielleicht ging das Ergebnis verloren, vielleicht bildete das Schema die Entscheidung nie ab.

Hat eine entfernte Perspektive DNSSEC nicht ausgeführt, sollte der Datensatz dies neutral sagen: nicht durchgeführt, zulässiger optionaler Zustand. Insecure wäre falsch, denn es ist ein definierter Protokollzustand. Wurde geprüft, gehört das Ergebnis zur konkreten Perspektive und ihrem Resolver. Das Ergebnis der primären Perspektive darf nicht aus Bequemlichkeit auf entfernte Zeilen übertragen werden.

Der Ausstellungsbeleg braucht weder vollständige Pakete noch jeden Resource Record noch einen kompletten Debug-Trace. Er muss die zu prüfende Aussage rekonstruierbar machen: Die vorgeschriebene primäre Rolle nutzte für die maßgeblichen Abfragen eine konforme Kontrolle; ein Validierungsfehler wurde nicht zur Ausstellungserlaubnis; und das davon unabhängige MPIC-Verfahren erreichte sein Quorum.

Dieses Zwei-Beleg-Modell ist ein Analysevorschlag von Daniel Kade. SC100 zählt die Felder nicht auf. Der Artikel schreibt die Idee weder DIGICERT noch den Antragstellern, Unterstützern, Abstimmenden, Prüfern oder dem RFC Editor zu. Das Forum wählte einen Suffizienzmaßstab. Das Modell ist ein Weg, Suffizienz prüfbar zu machen.

Ein grünes Feld verbindet noch keine Nachweiskette

Vier Aussagen können gleichzeitig stimmen:

  1. Die CP/CPS der CA erklärt DNSSEC für aktiviert.
  2. Eine Resolver-Konfiguration hat einen Konformitätstest bestanden.
  3. Ein Versuch lieferte Secure.
  4. Nach einem bestandenen MPIC-Quorum wurde ein Zertifikat ausgestellt.

Trotzdem ist nicht belegt, dass die vorgeschriebene primäre Perspektive bei diesem Versuch die getestete Konfiguration für die maßgeblichen Abfragen nutzte. Es fehlt die Verbindung.

Eine CP/CPS ist eine Praktikenerklärung, keine konkrete Ausführung. Ein Test belegt Verhalten unter Testbedingungen, nicht jeden späteren Aufruf. Secure beschreibt den DNSSEC-Zustand, nicht den Erzeuger in der Rollenordnung. Das Zertifikat belegt die Ausstellung, nicht den Weg dorthin. Das MPIC-Quorum belegt Bestätigung, aber keine verpflichtende DNSSEC-Prüfung jedes Teilnehmers.

Der Governance-Fehler liegt darin, die Aufzeichnung der Regel für die von ihr zugewiesene Handlung zu halten. SC100 macht die zugewiesene Rolle lesbarer. Die Belege sollten ihr von der kontrollierten Fähigkeit bis zum Ausstellungsentscheid folgen.

Was öffentlich nicht feststellbar ist

Die öffentlichen Quellen zeigen nicht, ob eine bestimmte CA den SC100-Entwurf bereits umgesetzt hat, wie interne Resolver organisiert sind oder welche Details die Ausstellungsprotokolle enthalten. Eine einstimmige Abstimmung beweist keine Ausbringung. Fehlende öffentliche Details beweisen keinen Verstoß. Dieser Artikel stellt keine Fehl-Ausstellung, DNS-Manipulation oder verschwiegene Protokollierung fest.

Ebenso lässt sich nicht vorhersagen, ob bis zum 5. September eine Ausschlusserklärung eingeht, ob sich der angenommene Text ändert oder welche Nummer eine spätere Veröffentlichung trägt. Der genaue Status am Stichtag bleibt: Abstimmung bestanden, Prüfung offen, geltende Fassung unverändert.

Quellen