Кратко

  • Тридцатидневный таймер RFC 9691 запускается отдельно у каждого Relying Party после первой успешной проверки той же пары ключей; общего момента старта нет.
  • Проверяемый переход связывает взаимные TAK, историю наблюдений, эквивалентность двух репозиториев, реально выбранный корень, старые TAL и уничтожение прежнего ключа.

TAL по RFC 8630 задаёт открытый ключ доверенного центра RPKI и адреса его сертификата. Пока ключ тот же, сертификат можно перевыпускать. Замена A на B меняет локальную исходную точку доверия.

RFC 9691 вводит подписанный объект TAK. Под A он называет B преемником, под B — A предшественником. Валидатор должен пройти проверку от B, проверить его TAK и убедиться, что B.current совпадает с A.successor, а B.predecessor — с A.current.

Такая взаимность фиксирует намеренный переход. Она не доказывает, что все валидаторы его увидели, непрерывно наблюдали или уже используют B.

Первый успешный просмотр принадлежит одному процессу

Если B успешно проверен и отсутствовал в предыдущем успешном запуске, этот валидатор ставит таймер на 30 дней. До истечения A остаётся рабочим корнем, а B только тестируется. При сохранении связи после местного срока процесс может принять B и начать проверку заново.

Ошибка B или его исчезновение отменяет таймер. Изменение ключа либо набора URI начинает новый эпизод. Постоянный сервис стартует рано, выключенный — позже, холодный экземпляр — через месяцы. Реализация без автоматического TAK лишь уведомляет человека либо продолжает жить по TAL.

Квитанция должна содержать идентификатор и версию валидатора, локальный TAL, отпечатки и URI A/B, предыдущий успешный запуск, первый просмотр, отмены, перезапуски, срок и реально выбранный корень. Фраза «опубликовано 30 дней» не называет принимающую сторону.

Стандарт не рекомендует убрать B и затем вернуть его без изменений. Процесс мог не увидеть промежуток и сохранить старый таймер. Изменение URI заставляет наблюдавших начать заново даже при прежнем SubjectPublicKeyInfo. Последний снимок не заменяет историю.

Два корня требуют двух равных результатов

Во время перекрытия A и B публикуются в разных каталогах. Кроме TAK, сертификаты CA, ресурсы IP/AS и делегирования должны давать одинаковый результат проверки.

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

Поэтому сравниваются валидированные проекции A и B: ресурсы, делегирования, сертификаты, manifest, CRL и поколения публикации. Требуется смысловая эквивалентность, а не одинаковые байты. Подпись TAK этого не обеспечивает.

Удаление A меняет цену молчания

Четыре фазы — это отдельные решения: TAK только для A; создание B и взаимной связи; новый TAL для B при сохранении A; удаление репозитория A и уничтожение закрытого ключа.

Разные URI в TAL и TAK помогают оценить канал перехода, но молчание неоднозначно. Оно может означать миграцию, остановку, кэш, обновлённый пакет или отсутствие поддержки. Статья APNIC 2025 года сообщала об исследовании внедрения RIR в программе NRO RPKI; это контекст планирования, не доказательство общего развертывания.

После удаления A старый валидатор не сможет проверить путь, чтобы узнать B, и потребует локального ремонта. Пропустив несколько поколений, он может ждать по 30 дней на каждом шаге. Бессрочное хранение A сохраняет доступность и одновременно сохраняет старую власть.

TAK не лечит компрометацию текущего корня. Владелец закрытого A уже контролирует подписанные данные. Внеполосное преобразование TAK в TAL переносит доверие к распространителю, если объект не связан с уже доверенной TA.

RFC 6487, RFC 6488, RFC 9286 и RFC 6481 задают сертификаты, объекты, манифесты и репозитории. RFC 9319 находится ниже: смена корня не доказывает загрузку данных маршрутизатором или путь пакета.

Минимальная начальная спецификация Lu Heng оставляет общий механизм узким, а дальнейшие решения — локальными и видимыми. Разделение слоёв не позволяет подписанному объявлению говорить за исполненное состояние и сетевой эффект. Приоритет running code ставит наблюдение конкретного валидатора выше календаря.

Источники