Кратко

  • Опубликованная 14 сентября редакция 02 превращает несколько фиксированных числовых требований к делегированным УЦ RPKI в ориентиры, которые оператор реестра может принять или изменить.
  • Доступность 99,5% и ответ за десять секунд переходят из обязательных требований в рекомендации; гибче становятся разрывы Manifest, срок хранения журналов и точность времени.
  • Единое окно отзыва в 90 дней заменено диапазоном 60–90 дней, отражающим разные решения APNIC и RIPE.
  • Документ остаётся индивидуальным Internet-Draft без RFC-потока, ответственного директора области и формального одобрения IETF или SIDROPS.

Изменился не секундомер, а право его настраивать

Редакция 02 прямо называет конкретную цель доступности и её применение политическим решением оператора реестра. Эта фраза определяет смысл обновления от 14 сентября.

Редакция 01 требовала с ключевым словом MUST, чтобы каждая точка публикации была доступна более 99,5% любого тридцатидневного периода. Теперь используется SHOULD, а 99,5% приведены как пример. Ответ HTTP не позднее десяти секунд тоже изменён с MUST на SHOULD. Запрет MUST NOT на отсутствие действующего Manifest дольше 24 часов стал SHOULD NOT, причём реестр может задать более строгий предел.

Официальное сравнение показывает такой же сдвиг для журналов и времени. Вести журналы операций с сертификатами всё ещё обязательно, но хранить их не меньше двух лет теперь рекомендуется; реестр или законодательство могут потребовать больший срок. Синхронизация часов обязательна, точность stratum 2 рекомендована.

В RFC 2119 и RFC 8174 MUST означает абсолютное требование, а SHOULD допускает осмысленное исключение. Поэтому новые слова не отменяют надёжность. Они передают выбор части цифр местному институту и вместе с выбором — обязанность объяснить последствия.

Общее техническое основание остаётся обязательным

Проект по-прежнему требует резервную инфраструктуру с автоматическим переключением, несколько географически разнесённых точек, полный мониторинг, проверку перед публикацией и атомарные обновления. Реестры должны наблюдать за всеми делегированными УЦ под своей властью, устанавливать ясные SLA, разумно пытаться связаться с оператором до отзыва и документировать процедуру и мотивы.

Работа о лучших практиках служб публикации уже требует высокой доступности и наблюдаемости без единого мирового процента. Её редакция 10 сосредоточена на согласованности разных серверов, синхронизации и проверяемом результате. Общий документ определяет, что должно быть безопасно и измеримо; реестр, выдавший делегирование, выбирает защищаемую цифру.

Источники доказательств распределены. УЦ измеряет свои точки, реестр контролирует всех дочерних операторов, валидаторы сообщают о длительных отказах. Проект о здоровье репозиториев предлагает доступность, свежесть, целостность и частоту изменений. Публичные наблюдения за неработающими УЦ и исследование CURE показывают, почему мёртвая или нестабильная публикация тратит ресурсы чужих валидаторов.

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

Региональные часы показывают 60 и 90 дней

Отзыв постоянно неработающих УЦ превращает различие политик в конкретные сроки. Прежняя версия предлагала более 90 дней после попыток связи. Новая указывает диапазон от 60 до 90 и ссылается на два региональных процесса.

APNIC prop-166 использует 60 дней, в течение которых текущие Manifest и CRL невозможно найти и проверить. Страница APNIC сообщает о консенсусе на APNIC 60. Принятое предложение RIPE 2025-02 задаёт три месяца, превращённые в 90 дней из-за неодинаковой длины месяцев. Оба подхода требуют разумных попыток обнаружения и уведомления и позволяют снова создать УЦ обычным способом.

Криптография не выводит единственно верное значение. Политика распределяет издержки между валидаторами, которые опрашивают бесполезную точку, оператором, которому нужно время на восстановление, и реестром, применяющим власть родительского УЦ. Новая редакция признаёт это различие, а не выдаёт региональное соглашение за универсальную константу.

Выбор легитимен, если доказательства сопоставимы. Реестр должен раскрыть проверяемые конечные точки, места и частоту наблюдения, момент запуска отсчёта, адресатов уведомления, утверждающего эскалацию, способ оспорить измерение и путь восстановления. Иначе «настраиваемый» легко означает «неподконтрольный».

Internet-Draft не создаёт мандат IETF

Datatracker помечает документ как индивидуальный проект и предупреждает: представить его может любой, IETF его не одобряет, формального статуса нет. Не назначены RFC-поток, ответственный Area Director или телеконференция. На обложке заявлено намерение Best Current Practice, но в Datatracker предполагаемый RFC-статус отсутствует. История подтверждает даты редакций, не консенсус.

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

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

Источники