Кратко

  • RFC 9691 позволяет объявить ключ-преемник в объекте TAK, но в течение 30-дневного срока принятия доверяющая сторона продолжает рабочую проверку с текущим ключом.
  • Нужно проверить взаимные ссылки между текущим и следующим TAK и неизменность ключей и адресов сертификатов.
  • Переход одного валидатора подтверждает только его состояние, а не принятие нового ключа всеми.

Trust Anchor Locator из RFC 8630 сообщает, где получить сертификат удостоверяющего центра якоря доверия, и содержит открытый ключ для проверки, что найденный самоподписанный сертификат действительно является нужным якорем. Этот исходный материал доверия распространяется вне самой иерархии, поэтому его смена не равна обычному обновлению репозитория.

RFC 9691 определяет подписанный объект Trust Anchor Key. TAK может содержать текущий ключ и адреса его сертификата, а также ключ-преемник и его адреса. Сам факт появления преемника не означает принятия. Доверяющая сторона выполняет проверку сверху вниз и устанавливает двустороннюю связь: текущий TAK называет преемника, а TAK преемника называет текущий ключ своим предшественником.

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

Таким образом, публикация оператором, проверка конкретной стороной, непрерывное наблюдение и фактическое переключение — разные факты. Ни один из них сам по себе не доказывает переход всей совокупности валидаторов.

Кроме того, программы без поддержки TAK продолжают использовать ключ из TAL или ручной настройки. RFC 9691 допускает необходимость некоторое время поддерживать прежние и новые пары ключей и размещать их материалы в разных каталогах. Старый клиент TAL и современный валидатор, ещё ожидающий окончания срока, находятся в разных состояниях.

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

Журнал принятия должен связывать отпечатки обоих ключей, набор адресов сертификатов, хеши обоих TAK, первую успешную проверку, запуск и непрерывность таймера, время переключения, идентификатор и версию валидатора. Для групп, зависящих от TAL, отдельно фиксируются срок поддержки и решение о её завершении.

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

Источники