Zusammenfassung

  • Der Authorization Domain Name (ADN) ist der Name, dessen Kontrolle eine Zertifizierungsstelle tatsächlich prüft. Er kann vom beantragten FQDN abgeleitet werden.
  • SC101 beschreibt eine gefährliche Lesart der alten Definition: erst linke Labels entfernen und danach einem CNAME folgen. So konnte die Kontrolle des Aliasziels fälschlich als Kontrolle über Kundensubdomains erscheinen.
  • Die neue Regel wählt zuerst die Validierungsmethode. Sie entscheidet, ob CNAME, Kürzung, beides oder keines zulässig ist; werden beide Schritte genutzt, kommt CNAME vor der Kürzung.
  • Die aktuellen TLS Baseline Requirements v2.2.9 lassen bis 15. November 2026 wahlweise ihren eigenen Abschnitt oder Abschnitt 3.2.2.4 aus v2.2.7 zu. Der Ausstellungsbeleg muss deshalb Version und vollständigen Ableitungspfad nennen.

Ein aktuelles Dokument mit eingebauter Altoption

Die TLS Baseline Requirements v2.2.9 tragen das Datum 6. August 2026. In der Änderungstabelle steht SC101 für die Klarstellung der Authorization Domain Names; die Tabelle der Compliance-Termine nennt den 15. November für die neue Ableitung.

Abschnitt 3.2.2.4 definiert die Übergangslogik ausdrücklich. Vor dem Stichtag darf eine CA dem aktuellen Abschnitt oder demselben Abschnitt aus v2.2.7 folgen. Ab dem 15. November muss sie den aktuellen Abschnitt anwenden. Der alte Weg ist damit keine stillschweigende Duldung. Er ist eine befristete normative Option im neuen Text.

„Entspricht den aktuellen Baseline Requirements“ hat deshalb im Übergang zu wenig Auflösung. Die Aussage kann eine bereits migrierte Implementierung oder eine zulässige Nutzung der v2.2.7-Regel bezeichnen. Die Versionsnummer des zitierten Dokuments identifiziert nicht automatisch den ausgeführten Zweig.

Die Abstimmung SC0101v2 war unter den Teilnehmenden einstimmig: 27 Zertifikatsaussteller sowie Apple, Google, Microsoft und Mozilla auf Verbraucherseite stimmten zu; Gegenstimmen und Enthaltungen gab es nicht. Der Bericht nennt ein Quorum von 17 und erfüllte Schwellen. Nach Diskussion und Wahl endete die IPR-Prüfung am 6. August.

Damit ist die Annahme belegt. Nicht belegt ist, dass alle Validierungsdienste, Konfigurationen, CP/CPS-Dokumente, Tests und Produktionsknoten am selben Tag umgestellt wurden. Normative Einigung und Betrieb brauchen getrennte Beweise.

Ein Alias überträgt keinen Namensraum

Ein Antrag enthält vollständig qualifizierte Domainnamen. Die CA wählt eine zulässige Methode und prüft Kontrolle. Der ADN ist der Name, an dem dieser Nachweis ansetzt. Bestimmte Methoden erlauben, DNS-Aliasse zu verfolgen oder linke Labels zu entfernen.

Das verhindert unnötige Einzelprüfungen. Es verschiebt aber die Autorisierungsgrenze. Technische Zuständigkeit für ein Zielsystem ist nicht dasselbe wie Herrschaft über die Subdomains des Kunden.

Nach der Begründung von SC101 vermischte die alte Definition Beschreibung und normative Ableitung. Offen blieb, ob Schritte einzeln, nacheinander oder wiederholt verwendet werden durften. Eine problematische Interpretation ließ zuerst Labels entfernen und danach einen oder mehrere CNAMEs verfolgen.

Zeigt example.com per CNAME auf example.org, kontrolliert der Betreiber von example.org das Ziel. Daraus folgt keine Kontrolle über blog.example.com. Wird blog vor dem Alias-Schritt entfernt, kann der Zielbetreiber dennoch als berechtigt erscheinen. Das Ballot nennt einen CDN-Betreiber als Beispiel für einen Akteur, der die Zielseite kontrollieren könnte.

Die Quelle meldet keinen nachgewiesenen Missbrauch und nennt keine verantwortliche CA. Dieses Szenario ist eine dokumentierte Sicherheitswirkung einer Lesart, kein bestätigter Vorfall.

Die Methodenwahl begrenzt alle weiteren Schritte

SC101 setzt die Validierungsmethode an den Anfang. Erst daraus ergibt sich, ob CNAME-Folgen, Label-Kürzung, beide Operationen oder keine zulässig sind. Methoden, die an technischen Namen mit Unterstrich arbeiten, erhalten nicht durch Analogie dieselben Rechte wie Verfahren am eigentlichen Namen.

Sind beide Transformationen erlaubt und werden beide eingesetzt, folgt die CA zuerst der CNAME-Kette und entfernt danach linke Labels. Eine vorgelagerte Kürzung kann so die scheinbare Autorität des Aliasziels nicht vergrößern. Das Ergebnis ist der ADN, auf den die gewählte Kontrollprüfung angewandt wird.

Für die Implementierung gelten der vollständige normative Text und seine Methodentabelle. Der Artikel ist keine Ersatzspezifikation. Er zeigt die beobachtbaren Zustände: beantragter FQDN, Methode, erlaubte Operationen, CNAME-Beobachtung, geordnete Kürzungen, ADN und Nachweis.

Auch die Entstehung des Texts ist versionierbar. Das Ballot verweist auf einen unveränderlichen GitHub-Vergleich, die Dokumentseite bewahrt aktuelle und frühere Fassungen. Das Protokoll vom 18. Juni erklärt die zusätzliche Wirksamkeitsfrist in v2. Diese Quellen belegen die Regelherkunft, nicht den Lauf eines bestimmten Systems.

Der Übergangsbeleg muss den Weg speichern

Ein Erfolgsstatus reicht nicht. Ein belastbarer Datensatz verbindet:

Ausstellungszeit + beantragter FQDN + gewählte Methode + BR-Version/Abschnitt + CNAME-Beobachtungen und Kette + geordnete Kürzungen + ADN + Identität/Zeit des Nachweises + CP/CPS-Version + Implementierungs-/Konfigurationsstand + Test- oder Auditverweis + Ausnahmen

Die Zeit bestimmt die zulässigen Optionen. FQDN und ADN zeigen die Grenzverschiebung. Die Methode begrenzt Transformationen. Die Versionsangabe trennt v2.2.7 von v2.2.9. DNS-Beobachtungen frieren einen veränderlichen Zustand ein. CP/CPS beschreibt die erklärte Praxis; Release und Konfiguration beschreiben den ausführbaren Zustand.

Der Beleg gehört an eine dauerhafte Ausstellungs- oder Zertifikatskennung. Hashes können spätere Ersetzungen sichtbar machen. Challenge-Geheimnisse müssen nicht öffentlich werden; Zugriff und Aufbewahrung bleiben kontrolliert. Ein autorisierter Prüfer soll die damalige Entscheidung nachvollziehen können, ohne heutiges DNS für historisches DNS zu halten.

Dieses Tupel ist Daniel Kades analytischer Vorschlag, keine dem Forum untergeschobene Pflicht. Die Baseline Requirements enthalten bereits Dokumentations-, Logging- und Auditregeln. Die These lautet: Wo der Text zwei Algorithmen erlaubt, muss vorhandene Evidenz die Auswahl identifizieren.

CP/CPS erklärt Absicht, nicht jede Ausführung

Certificate Policy und Certification Practice Statement geben den Anforderungen öffentlich Wirkung; RFC 3647 liefert den verbreiteten Rahmen. Eine Änderung kann Umstellungsdatum, betroffene Methoden und Rollback festhalten.

Sie ist kein Laufzeitprotokoll. Dokumentation kann dem letzten Deployment vorausgehen oder folgen. Ein gestaffelter Rollout erzeugt Mischzustände. Failover kann eine andere Konfiguration laden. Ein vor dem Stichtag begonnener Auftrag kann danach erneut laufen. Deklaration, Deployment und Einzelspur müssen zusammengeführt werden.

Forum und Root-Programme führen getrennte Akten

Die Baseline Requirements nennen sich notwendig, aber nicht hinreichend, und knüpfen Verbindlichkeit an Übernahme und Durchsetzung durch Application Software Suppliers. Das Forum setzt den gemeinsamen Boden; Root-Programme entscheiden die Produktvertrauensstellung.

Die Mozilla Root Store Policy übernimmt gemeinsame Anforderungen und behält vorrangige oder strengere Mozilla-Regeln. Die Apple Root Program Policy zeigt eine zweite Programmebene. Beide dienen hier nur der Kompetenzabgrenzung.

Ballot, CP/CPS, Validierungslauf und Root-Programmentscheidung sind vier Belege. Der bestehende Entrust/Google-Entwurf behandelt den letzten. Diese Analyse bleibt beim Validierungslauf und fragt, welcher der zwei erlaubten Wege benutzt wurde.

Grenze des Wissens

Norm und Termin sind öffentlich, der Umstellungsstand jeder CA nicht. Eine fehlende Ankündigung beweist keinen Rückstand; eine allgemeine v2.2.9-Aussage beweist keine frühe Migration. Ohne Einzelnachweis lautet der saubere Status „Regelversion nicht belegt“.

Quellen