Zusammenfassung

  • Ein erkanntes accounturi beschränkt die jeweilige CAA-Eigenschaft auf das anfragende Konto; validationmethods beschränkt sie auf erkannte Prüfverfahren. Die CA-Identifikationsdomain muss weiterhin passen.
  • Die Parametererkennung ist optional und CA-spezifisch. Verwenden jedoch mehrere Ausgabesysteme dieselbe Identifikationsdomain, müssen sie den Support konsistent auslegen.
  • Getrennte Identifikationsdomains sind der vorgesehene Ausweg für unvereinbare Systeme; ein gemeinsamer Markenname ist kein technischer Ersatz für diese Entscheidung.

Bei einer Zusammenführung wirkt der Name wie der leichteste Teil. Das moderne ACME-System, eine verwaltete Zertifikatsplattform und ein älteres Unternehmensportal sollen künftig alle unter derselben CA-Identifikationsdomain autorisiert werden. Hinter dieser Vereinfachung liegen jedoch drei Entscheidungsmaschinen. Wenn eine das Kontoparameter bindet und eine andere es nicht erkennt, beschreibt der gemeinsame Name keine gemeinsame Politik.

RFC 8659 begrenzt zunächst die Aussage von CAA. Der RRset steuert die gegenwärtige Ausgabebefugnis einer CA für jeden beantragten Namen. Die Suche folgt Aliasen bei der CAA-Abfrage, steigt bis zum ersten nichtleeren RRset auf und prüft alle Namen der Anforderung. Sie ist keine Validierungsregel für bereits ausgestellte Zertifikate, und eine spätere DNS-Änderung ist kein Widerruf.

RFC 8657 erweitert die einzelne issue- oder issuewild-Eigenschaft. Erkennt die CA accounturi, darf sie nur für das durch die URI bezeichnete anfragende Konto autorisieren; die Identifikationsdomain bleibt eine separate Bedingung. Ohne Parameter ist jedes Konto für diese Eigenschaft möglich. Mehrfache, ungültige oder nicht erkannte URI machen die Eigenschaft unerfüllbar.

Die Konto-URI ist öffentlich und kein Geheimnis. In einem unterstützenden ACME-System bezeichnet sie das Kontoobjekt; ein Nicht-ACME-System kann eine andere URI vergeben. Wer die Zeichenfolge kennt, kontrolliert nicht automatisch den Kontoschlüssel. Ebenso trägt die URI keine portable Befugnis zu einer anderen CA.

validationmethods begrenzt die Eigenschaft auf ein Verfahren aus der kommagetrennten Liste. Eine leere Liste erlaubt keines. ACME-Verfahren besitzen registrierte Bezeichner, während Nicht-ACME-Verfahren CA-spezifische Namen benötigen können. Die syntaktische Existenz des Parameters beweist daher noch keinen Support.

Die Erkennung ist freiwillig und je CA verschieden. Domaininhaber sollen sich auf eine ausdrückliche Supporterklärung stützen. Let's Encrypt dokumentiert beispielsweise letsencrypt.org, das Format seiner Konto-URI und http-01, dns-01 sowie tls-alpn-01. Das ist eine begrenzte öffentliche Erklärung, keine unabhängige Prüfung aller internen Wege und keine Aussage über andere Anbieter.

Für eine gemeinsame Identifikationsdomain setzt RFC 8657 hingegen eine klare Grenze. Alle Ausgabesysteme, die sie verwenden, müssen dieselben Parameter konsistent erkennen. Der Text erfasst ACME- und Nicht-ACME-Systeme sowie nach einem Zusammenschluss vereinigte Umgebungen. Kann die CA die Auslegung nicht angleichen, darf sie getrennte Identifikationsdomains einsetzen. Support unter einem gemeinsamen Namen zu erklären und einen abweichenden Altweg zu behalten, ist nicht zulässig.

Auch Konto-URI müssen über alle von einer CA erkannten Identifikationsdomains eindeutig bleiben. Werden zwei Namensräume verbunden, können identische lokale Kontonummern kollidieren. Eine URI mit Autoritätskomponente bewahrt die Herkunft besser. Daraus folgt keine gemeinsame Kontodatenbank für voneinander unabhängige CAs.

Konsistente Parser schützen nicht vor einer breiteren DNS-Alternative. CAA-Autorisierungen sind additiv. Eine eingeschränkte Eigenschaft hebt eine andere anwendbare Eigenschaft ohne Konto- oder Methodenbindung nicht auf. Bei Wildcards ersetzt vorhandenes issuewild die Auswertung von issue; für gewöhnliche Namen bleibt issue maßgeblich.

Das Critical-Flag zwingt ebenfalls keine unbekannten Parameter auf. Es behandelt unbekannte oder nicht unterstützte Property-Tags. Ein kritisches issue bleibt ein bekanntes Tag, auch wenn ein darin stehender optionaler Parameter nicht erkannt wird. Tag- und Parametererkennung sind getrennte Nachweise.

Zwischen Autorisierung und Ausstellung kann Zeit liegen. Kürzere Autorisierungsfristen oder eine erneute CAA-Prüfung nahe der Ausstellung können das Fenster verkleinern. Die ungefähr eine Stunde im RFC ist ein Beispiel, keine allgemeine Pflicht. Ein während einer offenen Übergangsphase ausgestelltes Zertifikat kann nach deren Ende gültig bleiben.

Ein belastbarer Beleg verbindet daher beantragte Namen, effektiven RRset, Alias- und Delegationsweg, DNSSEC-Ergebnis, anwendbare Eigenschaft, CA-Domain, Konto-URI, Verfahren, Ausgabesystem, Entscheidungszeit und ausgestelltes Zertifikat. Der gemeinsame Name ist der Anfang dieser Kette, nicht ihr Ergebnis.

Quellen

  1. RFC 8657 — CAA-Erweiterungen für Konto-URI und ACME-Methodenbindung
  2. RFC 8659 — DNS Certification Authority Authorization Resource Record
  3. Let's Encrypt — CAA-Dokumentation
  4. Heng Lu — Das Agency-Problem im Kern der Internet-Governance
  5. Heng Lu — Warum BTW Media existiert und Realität das Produkt ist