Кратко

  • В квартальном плане RPKI, обновлённом 17 сентября 2026 года, RIPE NCC сначала указывает переход на OpenID Connect и новые API-ключи, затем работу по соблюдению требований и аудитам. Поддержка Resource Signed Checklists (RSC) через API запланирована только при наличии времени команды и зависит от хода первых двух работ. Интерфейс для пользователей возможен позже, если возникнет спрос.
  • Сообщение рабочей группе Routing в мае 2024 года предлагало реализовать подпись RSC через API и панель после ASPA либо раньше, если стандартизация ASPA затянется. Архивный план отмечал запрос RPKI-2024#01 как предмет изучения. Эти формулировки не создавали обязательной даты поставки.
  • RFC 9323 определяет подпись списка хешей файлов в пределах названных IP-ресурсов или ASN. Объект RSC нельзя распространять через глобальный репозиторий RPKI. Будущий API лишь выпустил бы объект; его передача вне глобального репозитория, проверка и деловое принятие остались бы отдельными шагами.
  • Проверенные открытые материалы не подтверждают действующий публичный API RIPE NCC для выпуска RSC, срок запуска, инцидент или потери держателя. Распознавание формата программной библиотекой не означает наличие услуги.

Стандарт не подписывает клиентский договор

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

Стандарт RFC 9323 опубликован в 2022 году. Готовность формата не равна готовности сервиса конкретного регионального регистратора. План RIPE NCC на четвёртый квартал честно показывает эту разницу. Сначала команда переводит RPKI Dashboard на OpenID Connect из RIPE NCC Access и начинает заменять существующие ключи API ключами, интегрированными с системой единого входа. Параллельно идут общеорганизационная работа над ISO 27001 и новый аудит SOC 2 Type II, начатый в мае. Поддержка RSC стоит третьей: API намерены добавить, если позволит загрузка команды и продвинутся первые две задачи. Возможность интерфейса зависит от последующего спроса.

Такой порядок понятен. Новому виду подписи нужен точный ответ, какой пользователь вправе обращаться к какому набору ресурсов; система выдачи должна выдерживать проверку. Но рациональная очередность не делает третью строку уже существующим endpoint. Компания, обещающая клиентам процедуру на базе ещё не описанного API, создаёт зависимость, о которой действующий план предупреждает прямо. В нём нет ни даты начала выпуска RSC, ни публичной схемы запроса.

Как изменилось публичное намерение

В мае 2024 года RIPE NCC объяснял группе Routing применение RSC на примере задания от провайдера держателю префикса. Тогда обсуждались подписи и через API, и через панель после ASPA. Если работа IETF над ASPA не дошла бы до последнего этапа вовремя, очередь могла измениться. Позднее архивный пункт RPKI-2024#01 сообщал лишь о намерении изучить варианты применения и ответить сообществу.

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

Документация действующего API управления RPKI посвящена управлению центром сертификации LIR и объектами ROA с помощью ключа доступа. Она не описывает публичную операцию создания RSC. Это не доказательство отсутствия внутренних опытов, а предел того, на что внешний разработчик может положиться. В истории rpki-commons есть запись 2024 года о начальном распознавании расширений, связанных с RSC. Библиотека, умеющая распознать тип объекта, не заменяет авторизованный производственный сервис его выдачи.

Подписанный файл должен выйти за пределы репозитория

Общее происхождение от RPKI легко вводит в заблуждение. В письме 2024 года сначала встречается широкое описание списка как объекта для публикации в RPKI, но далее авторы уточняют: RSC не публикуются в глобальном репозитории, а передаются между подписантом и проверяющей стороной. RFC 9323 закрепляет запрет; одноразовый сертификат для RSC не содержит расширения с адресом объекта в репозитории.

Следовательно, будущая API-операция не станет завершённой сделкой в момент ответа сервера. Запросивший должен получить файл .sig и передать его адресату вместе с точными файлами, которые покрывают контрольные суммы. Адресат проверяет сертификат, границы ресурсов, алгоритм хеширования и содержимое файлов. Лишь затем он решает, соответствует ли это его требованиям к клиенту и договору. Объект ROA, доступный маршрутизаторным валидаторам, выполняет иную работу. RSC не делает объявление BGP разрешённым и не попадает автоматически ко всем проверяющим маршрутное происхождение.

Если RIPE NCC предложит API раньше пользовательской панели, опытным операторам этого может хватить. Но для надёжной интеграции нужны описание полномочий вызывающей стороны, границ ресурсов, способа получить готовый файл, ошибок, срока действия и тестовых примеров для независимой проверки. Это критерии будущей приёмки, а не обнаруженные сегодня неполадки. Опубликованный план таких параметров для RSC пока не задаёт.

Проверка подписи не подтверждает собственность

RFC 9323 ограничивает и смысл результата. Данные списка — утверждение самого подписанта. Успешная проверка не позволяет установить сверх того, что у него было достаточно контроля над выпускающим центром сертификации для создания объекта. Она не доказывает юридическую собственность на ASN, личность корпоративного представителя, полноту пакета или достоверность текста документа. В архиве RIPE NCC примером названо «подтверждение владения ASN»; эту свободную формулировку нельзя превращать в юридический вывод из стандарта.

Общий вопрос о различии подписи и полномочия уже разбирался в других публикациях BTW. Здесь предмет иной — последовательность запуска конкретной услуги RIPE NCC и граница между выдачей и доставкой передаваемого вне глобального репозитория файла. По состоянию на 24 сентября доказаны только текущие статусы работ: доступ и аудит ведутся, API RSC остаётся условным, панель возможна при спросе. Нельзя сообщать о несуществующем инциденте или результате сделки, которую открытые источники не показывают.

Источники