Termine
Beim ROW15 ging es um Zertifikate, die für EPP knapp werden
Am 29. September tagte online der 15. Registration Operations Workshop. Am dringendsten war ein Zertifikatsproblem: Viele öffentliche Zertifizierungsstellen stellen Webserver-Zertifikate nicht mehr mit der Client-EKU aus, die manche EPP-Implementierungen verlangen. Dazu kamen Transfercodes aus der Registry, S/MIME für Streitbeilegungsverfahren sowie ein neuer Delegationstyp im DNS.
Den Workshop, kurz ROW, gibt es seit 2014. Er behandelt die Technik hinter der Domainregistrierung. Dazu gehören EPP, über das Registrare Domains bei der Registry anlegen, die Abfrage per RDAP und DNSSEC. Sponsoren sind Verisign, ICANN und die kanadische Registry CIRA. In vier Stunden gab es zehn Vorträge. Die Teilnehmerzahl lag in der Spitze bei rund 110 Personen, Vortragende eingeschlossen.
EPP hängt an einer Regel für Browser
Zaid AlBanna von Verisign stellte das dringendste Problem vor. EPP-Verbindungen zwischen Registrar und Registry werden mittels Mutual TLS abgesichert. Dabei weist sich auch der Registrar mit einem Zertifikat aus. Viele nutzen dafür Zertifikate öffentlicher Zertifizierungsstellen mit einem Merkmal für die Client-Authentifizierung, der sogenannten Client-EKU.
2025 kündigte Google an, die Zertifikatshierarchien im Chrome Root Store schrittweise auf die Serverauthentifizierung zu beschränken. Webserver-Zertifikate aus diesen Hierarchien, die ab dem 15. März 2027 ausgestellt werden, dürfen nur noch die Server-EKU enthalten. Auch im CA/Browser Forum wird über eine stärkere Trennung der Verwendungszwecke diskutiert. Laut AlBanna bieten die meisten Zertifizierungsstellen solche Zertifikate nicht mehr an. Manche Software, etwa Java-Bibliotheken, prüft das Merkmal jedoch. Fehlt es, scheitert die Verbindung.
Ein Entwurf von AlBanna, James Gould und Scott Hollenbeck beschreibt vier Auswege. Die IETF-Arbeitsgruppe REGEXT prüft, ob sie ihn übernimmt. Kurzfristig ist es am wahrscheinlichsten, dass Registries das Merkmal nicht mehr prüfen. Registrare könnten Zertifikate bei den wenigen Anbietern kaufen, die es noch gibt. Registries könnten eine eigene Zertifizierungsstelle betreiben. Wer das schon tut, ist nicht betroffen. Oder Registries akzeptieren selbstsignierte Zertifikate, gegebenenfalls zusätzlich durch TLSA-Einträge im DNS abgesichert. AlBanna rechnet mit einer Kombination in mehreren Schritten.
.se vergibt die Transfercodes selbst
Bei .se und .nu legt der Registrar den Code für einen Transfer nicht mehr selbst fest. Eric Skoglund vom schwedischen Internetstiftelsen nannte die Gründe. Manche Codes waren schwach, manche wurden mehrfach verwendet, andere wurden von Kunden selbst gesetzt. Die Codes liefen nie ab. Und die Registry wusste nicht, wie Registrare sie speichern.
Heute schickt der Registrar nur noch „auto“, die Registry erzeugt den Code. Er enthält Endung, Ablaufdatum, Registrar und eine Zufallskennung und gilt 14 Tage lang. Das System läuft seit zwei Jahren. Die Registrare hätten positiv reagiert, sagte Skoglund. Der Support erkennt auf einen Blick, ob ein Code abgelaufen ist oder ob er zu .nu statt zu .se gehört. Ähnlich arbeiten laut Skoglund bereits .dk, .be und .eu.