Кратко

  • RFC 9598 помещает адрес с не-ASCII-символом в локальной части в SmtpUTF8Mailbox внутри X.509 otherName. При локальной части только из ASCII по-прежнему применяется rfc822Name, даже если домен интернационализирован.
  • Домен преобразуется в строчное A-label-представление IDNA2008. Локальную часть UTF-8 нельзя сворачивать по регистру, нормализовать по Unicode или подвергать совместимостным отображениям; после подготовки домена весь адрес сравнивается октет за октетом.
  • Совпадение имени подтверждает лишь ограниченную операцию сравнения. Действительность пути, ограничения имён, назначение, контроль ящика, маршрут SMTPUTF8, локальное разрешение и наблюдаемый результат требуют самостоятельных доказательств.

В системе учётных записей уже есть полезный механизм: нечёткий Unicode-поиск. Он находит имена, которые человек, вероятно, считает одинаковыми, несмотря на регистр или форму представления символов. Служба поддержки использует его, чтобы обнаруживать дубли и ошибки ввода. Затем интеграция сертификатов берёт ближайший результат поиска и считает его совпавшей почтовой идентичностью.

В этот момент вспомогательный индекс выходит за пределы своих полномочий. Он больше не предлагает кандидата оператору, а решает, какой набор подписанных байтов означает какую учётную запись. Обновление Unicode-таблиц или алгоритма ранжирования способно изменить ответ без перевыпуска сертификата и без изменения почтового ящика.

RFC 9598 проводит границу иначе. Домен имеет формальную процедуру IDNA2008, поэтому его можно подготовить к сравнению. Для локальной части универсального правила эквивалентности нет, поэтому она остаётся нетронутой. Визуальное или поисковое сходство полезно как сигнал для расследования, но не как криптографическое равенство.

Форму сертификата выбирает локальная часть

Запись RFC Editor и IETF Datatracker определяют RFC 9598 как Proposed Standard, опубликованный в мае 2024 года. Документ обновляет профиль PKIX из RFC 5280 и заменяет RFC 8398.

Традиционный rfc822Name способен представить ASCII-адрес, но не локальную часть международной почты. Поэтому RFC 9598 использует расширяемую ветвь otherName типа X.509 GeneralName и определяет SmtpUTF8Mailbox. Её объектный идентификатор — 1.3.6.1.5.5.7.8.9; распределение зафиксировано в реестре IANA SMI Numbers.

Если локальная часть содержит хотя бы один символ вне ASCII, сертификат обязан применять SmtpUTF8Mailbox. Если она целиком ASCII, применяется rfc822Name, даже при международном домене. Таким образом, один почтовый namespace представлен двумя взаимоисключающими формами, а выбор не оставлен предпочтению библиотеки или издателя.

Для эксплуатации это правило инвентаризации. Сканер, который индексирует только rfc822Name, теряет международные локальные части. Издатель, помещающий ASCII-локальную часть в SmtpUTF8Mailbox, не создаёт более универсальный сертификат, а выходит за договор стандарта. Парсер, который после чтения стирает исходный вид GeneralName, уничтожает доказательство того, что именно было подписано.

Значение представляет envelope mailbox, а не отображаемый адрес. Фраза, комментарий и угловые скобки в него не входят. SmtpUTF8Mailbox — непустая ASN.1-строка UTF8String, и её UTF-8-кодировка не должна содержать метку порядка байтов. Границу кодировки задаёт RFC 3629, а контекст международных заголовков сообщений — RFC 6532.

Домену назначена процедура подготовки

Доменная сторона следует IDNA2008. RFC 5890 определяет термины A-label, U-label и LDH, а RFC 5891 — протокольные преобразования. RFC 9598 требует, чтобы все почтовые домены в сертификатах X.509 соответствовали IDNA2008 без превращения дополнительных отображений из рамочного документа в локальную политику.

Внутри SmtpUTF8Mailbox не-ASCII-метка домена хранится как A-label, а не U-label. ASCII-метки отвечают ограничениям NR-LDH. Все буквы в A-label и NR-LDH доменной части записываются в нижнем регистре. Сертификат тем самым даёт одну форму для сравнения, и валидатору пути не приходится восстанавливать Unicode-представление и снова толковать его.

Если кандидат поступает из формы, сообщения или каталога, допустима узкая подготовка. Убираются отображаемая фраза, комментарии и угловые скобки. U-label в домене преобразуется в A-label, соответствующие буквы домена переводятся в нижний регистр. На этом преобразование заканчивается. Это процедура для названной части адреса, а не разрешение отполировать всю строку.

Именно единое A-label-представление исправляет главную неоднозначность RFC 8398, где при разных условиях использовались A-label или U-label. Новое правило само по себе не доказывает, что все издатели и приложения обновлены. Зато оно создаёт проверяемый результат и позволяет точно указать этап, нарушивший контракт.

UTF-8 — кодировка, а не реестр одинаковых ящиков

Локальная часть происходит из международной почтовой модели RFC 6530 и SMTP-расширения RFC 6531. Она кодируется в UTF-8, но UTF-8 не определяет универсальную эквивалентность ящиков и не передаёт приложению внутреннюю политику почтового провайдера.

Поэтому RFC 9598 запрещает преобразовывать локальную часть. Никакого case folding. Никакой Unicode-нормализации. Никакого совместимостного отображения. После подготовки домена получившийся адрес сравнивается октет за октетом. Два уже закодированных значения SmtpUTF8Mailbox не требуют подготовки: равенство означает полное совпадение байтов.

SmtpUTF8Mailbox и rfc822Name никогда не совпадают. Первой форме необходима не-ASCII-локальная часть, а вторая не может её содержать. Если после разбора привести обе формы к общему объекту и объявить равными, приложение добавит отношение идентичности, которого не было в подписанном артефакте.

Строгость создаёт заметное неудобство: пользователь видит одинаковое имя, а валидатор отказывает. Но отказ сохраняет расхождение между двумя источниками полномочий. Если центр сертификации записал одну последовательность, а почтовая система выделила другую, исправлять следует выдачу или конфигурацию. Тихая нормализация делает версию поисковой библиотеки частью смысла ранее выпущенного сертификата.

Нечёткий поиск остаётся полезным в своей роли. Он может показать оператору вероятную причину и помочь найти запись для ручной проверки. Его результат нельзя подавать прямо в решение об идентичности. Представление на экране — проекция; подписанные и выделенные байты — исходные свидетельства.

Ограничение имён удерживает границу выдачи

rfc822Name и SmtpUTF8Mailbox относятся к одному пространству имён. Если подчинённый центр уже ограничен доменом через rfc822Name, новый otherName не должен стать каналом обхода этой границы.

RFC 9549 обновляет международные правила PKIX так, чтобы ограничения rfc822Name охватывали обе формы. Сертификат CA выражает почтовое ограничение в IDNA2008-совместимом A-label-виде rfc822Name. Домен субъекта подготавливается, локальная часть удаляется, затем выполняется точная проверка host или доменного суффикса. Ограничения на конкретный отдельный ящик использовать не следует.

Положительный результат говорит, что домен входил в разрешённое подчинённому CA пространство выдачи. Он не создаёт ящик, не доказывает его существование или текущий контроль субъектом, не подтверждает пригодность ключа для операции и не даёт приложению права открыть доступ.

Проверяемая квитанция разделяет как минимум четыре утверждения. Артефакт содержал ожидаемую форму GeneralName и точные байты. Сравнение ящика прошло по RFC 9598. Путь и применимые ограничения прошли выбранную политику доверия. Приложение приняло сертификат для указанной цели. Даже все четыре вместе не доказывают доставку по SMTPUTF8-маршруту.

Совпадение имени не является контролем или результатом

SMTPUTF8 — самостоятельная транспортная возможность. RFC 6531 позволяет узлам SMTP объявлять и применять международные envelope-адреса. Сертификат может совпасть с ящиком, но следующий relay не поддержит расширение. И наоборот, сообщение может пройти по SMTPUTF8-маршруту без сертификата RFC 9598.

Текущий контроль требует отдельной проверки. CA мог проверить адрес по своей практике, однако relying party всё равно нуждается в правильном trust anchor, фактическом пути, политике, key usage или extended key usage, состоянии отзыва, привязке приложения и действующем правиле разрешений. Подпись может быть корректной, а действие запрещённым. Сообщение может быть принято, но не прочитано. Вход может состояться, а последующее изменение — нет.

Тезис Lu Heng о первичности работающего кода даёт операционный критерий. Фраза «поддерживает RFC 9598» ничего не завершает. Нужен trace, сохраняющий байты сертификата, выход парсера, внешний домен до и после IDNA, нетронутую локальную часть, сравнение, путь, ограничения, решение политики, действие и эффект.

Подход минимальной начальной спецификации объясняет узкий объём стандарта. Общими становятся форма имени, представление домена и алгоритм сравнения; выделение ящиков, доказательства CA, прикладное разрешение и транспорт остаются локальными. Рассуждение об уровнях реальности требует не смешивать представленное имя, совпавшее имя, действительный сертификат, контролируемый ящик, разрешённое действие и наблюдаемый итог.

Руководителю здесь следует защищать не единый индекс, а границы между теми, кто вправе делать каждое из этих утверждений.

Источники