Кратко

  • RFC 5105 прямо называет правильную подпись необходимым, но недостаточным условием действительности Validation Token. Registry отдельно проверяет подписанный элемент, алгоритмы, сертификат, аккредитацию VE, Registrar, номер, метод, даты и защиту от повторного применения.
  • Token сообщает о проверке. Он не является решением Registry, результатом EPP, опубликованным делегированием, наблюдением DNS или доказательством завершённой связи.

После инцидента команда находит в архиве подписанный XML Token и отмечает делегирование как подтверждённое. Но архив отвечает только на вопрос о документе. Он не показывает, принял ли Registry запрос, выполнилась ли EPP-команда и появилась ли запись на авторитетных серверах.

RFC 5105 стандартизировал переносимое заявление Validation Entity для ENUM. Имя ENUM связано с номером E.164, поэтому нужно проверить, что Registrant совпадает с Assignee номера либо действует по его полномочию.

RFC 4725 разделяет Assignee, ENUM Registrant, Validation Entity, Registrar, Registry, DNS-провайдера и прикладного провайдера. VE проверяет связь. Registrar подаёт запрос. Registry принимает решение, ведёт основную базу делегирований и авторитетную зону.

Token проходит через сторону, которая может не иметь собственных полномочий подтверждать право на номер. Подпись не позволяет посреднику незаметно заменить номер, метод, дату или Registrar. Но защита заявления не превращает его в команду Registry.

Обязательная часть содержит уникальный в пределах VE serial, номер E.164, необязательный конец диапазона, идентификаторы VE и Registrar, идентификатор метода, дату выполнения и необязательную дату окончания. Отдельный необязательный блок может содержать контактные данные.

Serial не глобален. Одинаковое значение возможно у разных VE. Для идентификации нужны VE и serial, а для решения — точный хэш Token, Registrar, диапазон номера, метод, даты, версия политики и история использования. Одна колонка serial создаёт ложную уникальность.

Диапазон задаётся начальным E.164 и lastE164Number; оба номера должны иметь одинаковую длину. Нормализатор не вправе расширять границы или терять структуру. Подпись защищает исходное представление, а не последующую интерпретацию.

RFC применяет enveloped XML-DSIG и exclusive XML canonicalization. Это стабилизирует подписываемое содержание, когда Token вложен во внешний XML, например EPP. Унаследованные пространства имён не должны менять digest. Канонизация не проверяет бизнес-смысл.

Reference URI="#TOKEN" должен указывать на элемент с Id="TOKEN". Если перенести ID в tokendata, библиотека может успешно проверить подпись только над контактным блоком. Номер, метод и даты останутся вне охвата. RFC считает такую подпись бесполезной для задачи.

Поэтому общего ответа XML-DSIG недостаточно. Registry проверяет разрешённые transforms и algorithms, ссылку на полный Token и принадлежность ключа аккредитованной VE. В примере сказано буквально: верная подпись необходима, но недостаточна; сертификат и XML Schema требуют дополнительных проверок.

Встроенный сертификат не выдаёт себе доверие. Registry может быть собственным CA, принимать публичный CA или использовать заранее зарегистрированные ключи. Это локальная политика. Сертификат даёт ключ и возможную цепочку, но не выбирает trust anchor и не доказывает актуальную аккредитацию VE.

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

Registrar ID связывает Token с заявителем. Второй Registrar может перехватить неизменённый документ; подпись останется правильной. Сопоставление с запросом покажет другую сторону. Целостность становится доказательством несоответствия, а не разрешения.

Даты тоже подчинены политике. executionDate указывает выполнение проверки. expirationDate завершает её срок, а отсутствие поля означает бесконечную действительность в формате. Registry всё равно обязан решить, допускается ли отсутствие срока, и установить окно использования после execution date.

Token может быть формально не просрочен, но подан после разрешённого окна. Бессрочность может быть запрещена. Даты могут совпасть, а Registrar — нет. Статус «не истёк» не является полной авторизацией.

methodID называет заявленный способ, но не доказывает исполнение. RFC 4725 допускает разные методы в зависимости от источников, сторон, выбора Assignee и регулирования. Registry решает, подходит ли метод для номера и периода. Строковый идентификатор не выполняет процедуру.

Жизненный цикл продолжается после первой проверки. Делегирование ENUM должно следовать состоянию E.164. Успешная revalidation позволяет продолжение; неудачная приводит к приостановке явно или по сроку, иногда после grace period. Старая положительная подпись не отменяет новое отрицательное событие.

Защита от replay требует журнала применения. VE, serial, hash, Registrar, scope, первое предъявление, решение и допустимое окно должны быть связаны. Иначе повторный запрос нельзя отличить от повторного неправомерного разрешения.

Контактный блок остаётся вспомогательным. Компания или e-mail могут помочь новой проверке, но не подтверждают текущее назначение номера. Token не зашифрован. Конфиденциальность требует другой защиты; подпись не скрывает данные.

У алгоритмов есть исторический контекст. RFC требовал RSA-SHA1 и RSA-SHA256, одновременно отмечая сомнения в SHA-1. Registry выбирает принимаемые алгоритмы и размеры ключей. Возможность библиотеки вычислить старую схему не означает нынешнего допуска.

После Token начинается исполнение. RFC 5076 задаёт EPP-расширение для добавления, изменения, удаления и чтения validation information. Успешный EPP response доказывает эту транзакцию, а не публикацию авторитетной зоны.

База Registry может принять изменение, а генератор зоны — отказать. Авторитетные серверы могут обновиться, а recursive cache сохранить старое. RFC 3761 приводит ENUM-запрос к URI, но не гарантирует корректность URI, доступность узла или завершённый разговор.

Нужна цепочка раздельных receipts. Криптографический receipt хранит исходные байты, hash, parser, Schema, разрешённый ID, reference node, transforms, canonicalized input, algorithms, certificate path, trust anchors и результат. Он не утверждает делегирование.

Policy receipt хранит аккредитацию VE, допустимость метода, совпадение Registrar и E.164, даты, окно, policy version и replay history. Registry отдельно выдаёт принятие или отказ. EPP, delegation database, авторитетная публикация, resolver и приложение добавляют собственные результаты.

Так расследование различает неверный XML scope, неаккредитованную VE, другого Registrar, устаревший метод, replay, ошибку EPP, задержку DNS и недоступное приложение. Единое «validated» стирает причину и приписывает одному компоненту чужую власть.

Это соответствует слоям реальности Heng Lu. Подпись сильна как факт представления и происхождения. Она становится опасной, когда ей поручают говорить за политику или работающую систему. Приоритет running code требует отдельного доказательства каждого реально выполненного перехода.

Источники