Кратко

  • RFC 6916 координирует смену алгоритмов между центрами сертификации, точками публикации и проверяющими сторонами RPKI; это не локальное обновление программного обеспечения.
  • При переходе сверху вниз в течение переходного периода параллельно публикуются подписанные данные со старым и новым наборами алгоритмов; затем наступают этапы готовности проверяющих и вывода старого набора.
  • Документ исходит из того, что работа займёт несколько лет, и не описывает срочный переход. Он предназначен для плановой смены, а не для реакции на внезапную криптографическую уязвимость.

Смена криптографии затрагивает всю цепочку

В инфраструктуре открытых ключей для ресурсов (RPKI) подписанные утверждения выстроены иерархически. Центр сертификации (CA) заверяет нижестоящий CA; тот может выдавать сертификаты и подписанные объекты для ресурсов ниже по дереву. Проверяющая сторона (RP) получает опубликованные данные и проверяет цепочку. Затем сетевые операторы могут учитывать результаты проверки в собственной политике маршрутизации.

Это разные этапы. Выданный сертификат не доказывает, что все репозитории опубликовали соответствующие объекты. Публикация не означает, что каждый RP умеет их проверять. И результат проверки сам по себе не определяет, какую запись примет маршрутизатор: дальнейшее решение зависит от оператора. Поэтому RFC 6916 рассматривает вопрос шире, чем замену криптографической функции: как сохранить работоспособный путь доверия между всеми звеньями во время смены набора алгоритмов.

RFC 6916 «Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)» опубликован в апреле 2013 года как Best Current Practice 182 (BCP 182). Среди авторов указаны Roque Gagliano, Stephen Kent и Sean Turner. Это документ консенсуса IETF, а не личное распоряжение одного из авторов. RFC 6916

Сначала график, потом новый алгоритм

RFC 6916 не выбирает следующий алгоритм. В 2013 году документ требовал сначала обновить профиль алгоритмов RPKI, который тогда задавала RFC 6485, а затем отдельно установить график перехода. Позднее RFC 7935 заменила RFC 6485 и определила профиль, проверенный в нынешних источниках. Поэтому будущий переход должен обновить применимый профиль, а не просто добавить новую метку в сертификат. RFC 7935

В графике должны быть указаны пять дат: когда CA обязаны быть готовы выдавать сертификаты с новым набором, когда они должны повторно выпустить все свои продукты, когда должны быть готовы RP, когда старый набор станет необязательным и когда завершится срок его использования. RFC назначает каждый этап на одну минуту позже полуночи UTC и требует показатели готовности для CA и RP. Время становится операционным условием системы доверия: репозитории, ПО проверки и сертификаты должны использовать нужную версию к установленному сроку.

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

Почему переход начинается с родительского CA

Миграция идёт сверху вниз. Дочерний CA не сможет запросить сертификат с новым набором, пока родительский CA не научится его выдавать. Документ также исключает сертификаты CA, в которых алгоритм подписи и открытый ключ субъекта принадлежат разным наборам. Без такого порядка пришлось бы поддерживать смешанные сертификаты и более сложную структуру репозиториев; RFC предупреждает, что непоследовательная миграция может привести к экспоненциальному росту опубликованных данных.

Здесь иерархия становится частью механизма управления. Готовность родительского CA — реальная зависимость его дочерних узлов, которую нельзя обойти. Стандарт делает последовательность явной: подготовка, выдача, поддержка со стороны RP, затем вывод старого набора. При этом он не утверждает, что существует центральный орган, способный одновременно обязать все системы к переходу.

Параллельная публикация даёт время на проверку

Этапы позволяют старому набору продолжать обслуживать рабочую среду, пока новый внедряется и тестируется. На этапе 0 используется только действующий набор. Этап 1 начинается в дату готовности CA: CA, не являющиеся конечными узлами, должны уметь обрабатывать запросы с новым набором, но RP в рабочей среде продолжают пользоваться старым. Новые продукты можно публиковать для испытаний, предпочтительно в отдельных точках публикации.

Этап 2 начинается в дату старта CA. Для каждого набора подписанных продуктов должны существовать версии с обоими алгоритмами. RP могут проверять новую версию, сохраняя старую. RFC ожидает, что соответствующие результаты — например, данные об авторизации происхождения маршрута в ROA — будут совпадать с учётом задержек. Если многие CA не готовы, график необходимо выпустить заново. Полная поддержка нового набора RP пока не обязательна, но проблемы проверки могут отложить следующий этап.

На этапе 3, начиная с даты готовности RP, все RP должны уметь проверять новый набор; им рекомендуется отдавать предпочтение новым продуктам, пока доступны обе версии. Этап 4 наступает в дату Twilight: новый набор становится обязательным для RP и CA. Старые продукты ещё могут оставаться опубликованными, но их полнота уже не гарантируется. В конце срока старый набор выводится из эксплуатации, а его локаторы доверенных якорей удаляются из точек публикации. RFC 6916, разделы 4 и 10

Возможность вернуться к старому набору ограничена по времени. RP, который пока не умеет проверять новые продукты, может продолжать пользоваться старыми, пока их наличие требуется и они доступны. Но это не обещание вечного параллельного режима: это ограниченный период для испытаний, сопоставления результатов и выявления отставания до отключения прежнего пути. RFC 6481

Риск распределён между издателями и проверяющими

RFC 6916 описывает возможный сбой с обеих сторон. Если CA не завершил переход к окончанию срока старого набора, его подписанные продукты теряют действительность. RP, который не перешёл на новый набор, утрачивает возможность проверять соответствующие продукты. В результате представление RP о маршрутизируемых ресурсах RPKI может стать неполным.

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

Осторожный график одновременно показывает пределы документа. В аннотации RFC говорится, что переход займёт несколько лет, и отмечено отсутствие срочной процедуры. Для плановой замены, требующей широкого внедрения и совместимой публикации, такой срок объясним. Но остаётся отдельный вопрос: что делать, если алгоритм или ключ станет небезопасным до завершения цикла? RFC 6916 не содержит плана действий в кризисе.

Место Gagliano в публичных источниках

В открытом профиле Cisco Gagliano назван Principal Solutions Engineer; там же указаны его прежние инженерные и архитектурные должности в LACNIC, ANTEL и Sprint. Это связывает его карьеру с операторами, региональным реестром и поставщиком, но не объясняет, почему он поддержал конкретное положение RFC. Более надёжное утверждение даёт сам RFC: Gagliano стал соавтором процедуры консенсуса, которая рассматривает готовность как характеристику всей цепочки RPKI. Профиль автора Cisco

Профиль алгоритмов в изученной версии RFC 7935 задаёт RSA с ключом 2048 бит и SHA-256. В 2026 году информационный Internet-Draft изучает постквантовые варианты и архитектуры миграции, в том числе параллельную публикацию и смешанное дерево. Авторы прямо говорят, что черновик не обновляет RFC 7935 или RFC 6916, не выбирает производственный профиль и не разрешает использовать рассмотренные варианты в действующей RPKI. Наличие исследований не доказывает, что производственный переход утверждён или запланирован. RFC 7935; draft-yoshikawa-sidrops-pqc-rpki-02

Долгосрочная ценность RFC 6916 — в процедуре. Цель «перейти на более надёжный алгоритм» превращена в наблюдаемую цепочку зависимостей: CA выпускают продукты с новым набором, точки публикации содержат соответствующие версии, RP их проверяют, а старый путь остаётся до подтверждения готовности. Документ также показывает, что ещё предстоит решить: как измерять готовность, как помогать отстающим участникам и как отделить срочную реакцию от плановой миграции. Следующие решения остаются за операторами и участниками стандартизации.