Zusammenfassung

  • RFC 9598 legt eine Mailbox mit Nicht-ASCII-Zeichen im Local-Part als SmtpUTF8Mailbox in einem X.509-otherName ab. Ein reiner ASCII-Local-Part gehört weiterhin in rfc822Name, auch bei internationalisierter Domain.
  • Die Domain wird nach IDNA2008 in ein kleingeschriebenes A-Label überführt. Der UTF-8-Local-Part darf weder in der Groß-/Kleinschreibung gefaltet noch Unicode-normalisiert werden; nach der Domainvorbereitung zählt der Vergleich Oktett für Oktett.
  • Ein Namensmatch ist nur der Beleg für einen begrenzten Vergleich. Pfadgültigkeit, Namensbeschränkungen, Einsatzzweck, Mailboxkontrolle, SMTPUTF8-Route, lokale Berechtigung und Wirkung benötigen getrennte Nachweise.

Das Migrationsprojekt beginnt mit einem vernünftigen Ziel. Alte Zertifikate enthalten internationale Domains in unterschiedlichen Darstellungen. Das neue PKI-Profil soll einen stabilen Vergleich ermöglichen, also führt die Organisation alle Zertifikatsdomains auf kleingeschriebene A-Labels zurück. Die Testkurve wird grün, die Zahl der Sonderfälle sinkt.

Dann schlägt das Team vor, dieselbe Bereinigung auf die linke Seite der Adresse auszudehnen. Zwei Local-Parts sähen gleich aus; eine Unicode-Normalisierung könne Unterschiede beseitigen. Genau hier würde eine Migration, die Darstellungen vereinheitlichen soll, anfangen, Identitäten zu verschmelzen. Die Mailboxverwaltung hat keine universelle Äquivalenzregel delegiert, und das Zertifikat hat andere Bytes signiert.

RFC 9598 macht diese Asymmetrie zum Kern des Vergleichs. Die Domain besitzt mit IDNA2008 einen Vorbereitungspfad. Der Local-Part besitzt keinen allgemein gültigen Normalisierungsvertrag. Eine Implementierung ist deshalb nicht vollständig, wenn sie möglichst viele Unicode-Transformationen beherrscht, sondern wenn sie nach der zulässigen Domainvorbereitung zuverlässig stoppt.

Zwei Zertifikatsformen teilen einen Namensraum

Der RFC-Editor-Eintrag und der IETF Datatracker führen RFC 9598 als Proposed Standard vom Mai 2024. Das Dokument aktualisiert RFC 5280 und ersetzt RFC 8398.

Das herkömmliche rfc822Name kann eine ASCII-Mailbox tragen, aber keinen nicht-ASCII-fähigen Local-Part. Daher verwendet RFC 9598 den erweiterbaren otherName-Zweig von X.509 GeneralName und definiert SmtpUTF8Mailbox. Der Objektbezeichner lautet 1.3.6.1.5.5.7.8.9; das IANA-Register SMI Numbers dokumentiert die Zuweisung.

Welche Form verwendet wird, entscheidet allein der Local-Part. Enthält er mindestens ein Nicht-ASCII-Zeichen, muss das Zertifikat SmtpUTF8Mailbox verwenden. Besteht er nur aus ASCII, muss es rfc822Name verwenden – auch wenn die Domain internationalisiert ist. Beide Formen gehören zu demselben E-Mail-Namensraum, sind aber keine frei wählbaren Kodierungsvarianten.

Für die Migration ist das eine Inventarregel. Ein Scanner, der nur rfc822Name indexiert, übersieht internationale Local-Parts. Ein Aussteller, der einen ASCII-Local-Part in SmtpUTF8Mailbox schreibt, produziert kein zukunftssicheres Universalformat, sondern verletzt den Vertrag. Ein Parser, der die ursprüngliche GeneralName-Form nach dem Einlesen verwirft, beseitigt Beweismaterial darüber, was tatsächlich signiert wurde.

Der Wert ist eine Envelope-Mailbox, keine Anzeigeadresse. Anzeigenamen, Kommentare und spitze Klammern gehören nicht zur Zertifikatsidentität. SmtpUTF8Mailbox ist ein nichtleerer ASN.1-UTF8String, dessen UTF-8-Kodierung keine Byte Order Mark enthalten darf. Die Kodierungsgrenze stammt aus RFC 3629; RFC 6532 beschreibt den Rahmen internationalisierter Nachrichtenköpfe.

IDNA2008 weist der Domain eine Transformation zu

Die Domainseite folgt IDNA2008. RFC 5890 definiert A-Label, U-Label und LDH, RFC 5891 die Protokollkonvertierungen. RFC 9598 verlangt, dass alle E-Mail-Domains in X.509-Zertifikaten IDNA2008 entsprechen, ohne zusätzliche Mapping-Verfahren aus dem Rahmenwerk als lokale Abkürzung zu behandeln.

In SmtpUTF8Mailbox wird ein nicht-ASCII-Domainlabel als A-Label, nicht als U-Label gespeichert. ASCII-Labels müssen die NR-LDH-Bedingungen erfüllen. Buchstaben in A-Labels und NR-LDH-Labels stehen klein geschrieben. Damit liefert das Zertifikat eine einzige Vergleichsform; der Pfadvalidator muss die Domain nicht erst in eine Unicode-Anzeige zurückverwandeln.

Kommt der Kandidat aus einem Formular, einer Nachricht oder einem Verzeichnis, ist eine begrenzte Vorbereitung zulässig. Anzeigename, Kommentar und Klammern werden entfernt. U-Labels der Domain werden in A-Labels konvertiert, geeignete Domainbuchstaben kleingeschrieben. Dann endet die Verarbeitung. Das ist eine kanonische Form für einen benannten Teil, kein Mandat, die gesamte Mailbox zu polieren.

Diese Festlegung behebt die wesentliche Mehrdeutigkeit von RFC 8398. Das ältere Dokument verwendete je nach Bedingung A-Labels oder U-Labels; RFC 9598 verlangt im Zertifikat durchgehend A-Labels. Das beweist noch keine vollständige Einführung in Ausstellern und Anwendungen. Es liefert aber einen testbaren Output und klare Fehlerorte für die Migration.

Ein UTF-8-Local-Part ist nicht automatisch normalisierbar

Der Local-Part kommt aus dem EAI-Rahmen in RFC 6530 und der SMTP-Erweiterung in RFC 6531. Er wird in UTF-8 kodiert. UTF-8 bestimmt jedoch die Bytekodierung, nicht die Äquivalenz von Konten bei allen Mailboxanbietern.

RFC 9598 untersagt daher jede Transformation des Local-Parts. Kein Case Folding, keine Unicode-Normalisierung, kein Kompatibilitätsmapping. Nach der Domainvorbereitung wird die gesamte Mailbox Oktett für Oktett verglichen. Zwei bereits kodierte SmtpUTF8Mailbox-Werte brauchen keine Vorbereitung: Nur identische Bytes sind äquivalent.

Ein SmtpUTF8Mailbox und ein rfc822Name stimmen nie überein. Ersteres setzt einen Nicht-ASCII-Local-Part voraus, letzteres kann keinen enthalten. Wer die Formen nach der Dekodierung ineinander überführt, verbessert nicht den Vergleich, sondern fügt eine Identitätsbeziehung hinzu, die im Zertifikat nicht vorhanden war.

Das erzeugt einen sichtbaren Preis. Menschen können zweimal denselben Namen sehen, während der Validator ablehnt. Die Alternative wäre jedoch, dass eine Bibliotheksversion nach der Zertifikatsausstellung neu bestimmt, welche Principals gleich sind. Wenn CA und Mailboxsystem verschiedene Bytesequenzen führen, ist der sichere Zustand ein nachvollziehbarer Mismatch. Suchnormalisierung darf den Support auf die Abweichung hinweisen, sie darf sie nicht im kryptografischen Entscheidungsweg löschen.

Namensbeschränkungen erhalten den Emissionsrand

rfc822Name und SmtpUTF8Mailbox bilden einen gemeinsamen E-Mail-Namensraum. Eine untergeordnete CA, deren Ausgabe bereits über rfc822Name auf eine Domain beschränkt ist, darf mit dem neuen otherName keinen zweiten, unbeschränkten Kanal erhalten.

RFC 9549 aktualisiert deshalb die PKIX-Internationalisierungsregeln, sodass rfc822Name-Namensbeschränkungen beide Formen erfassen. CA-Zertifikate formulieren die Einschränkung als IDNA2008-konformes rfc822Name in A-Label-Form. Beim Test wird die Subjektdomain vorbereitet, der Local-Part entfernt und anschließend ein exakter Host- oder Domain-Suffix-Vergleich durchgeführt. Beschränkungen auf eine einzelne Mailbox sollen nicht verwendet werden.

Der Erfolg dieses Tests bedeutet, dass die Domain im erlaubten Ausstellungsraum der untergeordneten CA lag. Er sagt nicht, dass die Mailbox existiert, der Zertifikatsinhaber sie aktuell kontrolliert, der Schlüssel für die Handlung geeignet ist oder die Anwendung Zugriff gewähren soll.

Ein prüfbarer Beleg trennt deshalb mindestens vier Aussagen: Das Artefakt enthielt die erwartete GeneralName-Form und die exakten Bytes. Der Mailboxvergleich folgte RFC 9598. Pfad und relevante Namensbeschränkungen bestanden unter der gewählten Vertrauensrichtlinie. Die Anwendung akzeptierte das Zertifikat für den genannten Zweck. Selbst zusammen beweisen diese Aussagen keine funktionierende SMTPUTF8-Zustellung.

Zertifikatsmatch, Mailroute und Berechtigung sind getrennt

SMTPUTF8 ist eine eigene Transportfähigkeit. RFC 6531 ermöglicht SMTP-Teilnehmern, internationale Envelope-Adressen anzukündigen und zu verwenden. Ein Zertifikat kann zur Mailbox passen, obwohl das nächste Relay die Erweiterung nicht anbietet. Ebenso kann eine Nachricht über einen funktionierenden SMTPUTF8-Pfad laufen, ohne dass ein RFC-9598-Zertifikat beteiligt ist.

Auch aktuelle Kontrolle folgt nicht aus dem Namen. Die CA mag die Adresse nach ihrer Praxis geprüft haben; die verlassende Anwendung braucht weiterhin den vorgesehenen Trust Anchor, den tatsächlich konstruierten Pfad, Richtlinie, Key Usage oder Extended Key Usage, Sperrstatus, Anwendungsbindung und eine aktuelle Autorisierungsregel. Eine Signatur kann gültig sein, während die Aktion verboten bleibt. Eine Nachricht kann angenommen und nie gelesen werden. Eine Anmeldung kann gelingen und die nachfolgende Änderung scheitern.

Lu Hengs Text zum Vorrang von laufendem Code liefert den Betriebstest: „unterstützt RFC 9598“ ist kein Ergebnis. Ein Ergebnis ist ein Trace aus Zertifikatsbytes, Parserausgabe, externer Domain vor und nach IDNA, unverändertem Local-Part, Vergleich, Pfad, Beschränkungen, Richtlinienentscheidung, Handlung und Wirkung.

Die Perspektive der minimalen Anfangsspezifikation erklärt die bewusste Enge. Standardisiert werden Namensform, Domainrepräsentation und Vergleich; Mailboxvergabe, CA-Nachweise, Anwendungsberechtigung und Transportbetrieb bleiben dezentral. Die Realitätsebenen halten Darstellung, Match, gültiges Zertifikat, kontrollierte Mailbox, erlaubte Aktion und beobachtete Wirkung als verwandte, aber verschiedene Datensätze auseinander.

Für die Leitung heißt das: Eine erfolgreiche Migration vereinheitlicht zulässige Repräsentationen, nicht die Institutionen, die über Identität und Wirkung entscheiden.

Quellen