Кратко

  • Независимый запуск rpki-client 21 августа обработал материалы AFRINIC без прежнего предупреждения о кодировке имён издателя и субъекта X.509; один запуск не заменяет проверку всеми валидаторами.
  • Коммит rpki-client от 18 августа лишь подготовил номер версии 9.9: возврат ошибки по-прежнему отключён конструкцией #if 0, а последним опубликованным portable-релизом на 21 августа оставался 9.8.
  • Оценка примерно в 6 000 BGP-анонсов, способных перейти из ROV valid в not-found, описывала условный риск в 2025 году, а не подтверждённый августовский инцидент.

Один срок и четыре временные шкалы

19 февраля 2026 года сопровождающий rpki-client Job Snijders предупредил Database Working Group AFRINIC: начиная со вторника, 18 августа, реализация будет отвергать сертификаты, в которых commonName в имени издателя или субъекта X.509 закодирован не ASN.1-типом PrintableString. AFRINIC до этого обозначил 31 июля как срок устранения оставшихся объектов. Если реестр не успеет, говорилось в письме, у затронутых участников возможны проблемы с RPKI-сервисом. Публичный архив фиксирует это предупреждение, но не доказывает, что обещанное изменение затем было включено.

18 августа в upstream действительно появился коммит Prepare for rpki-client 9.9 release. Он заменил номер 9.8 на 9.9. Однако решающая проверка осталась мягкой.

В функции valid_printable_string() значение commonName иного типа по-прежнему вызывает только предупреждение при повышенной подробности вывода. Оператор return 0, который сделал бы такую ситуацию ошибкой, остаётся внутри #if 0 и не попадает в исполняемую программу. Так выглядит исходный файл в самом коммите с номером 9.9. Комментарий говорит, что предупреждение следует сделать ошибкой; код пока этого не делает.

На 21 августа portable-релиз 9.9 также не был опубликован. На странице релизов проекта последней оставалась версия 9.8, выпущенная в апреле. Так разошлись четыре шкалы: объявление, upstream-исходники, portable-релиз и фактическое внедрение у операторов. Поэтому календарная дата сама по себе не означает, что отказ заработал повсеместно.

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

Шкалу реальной работы видно из независимого запуска

21 августа в 08:33 UTC независимая публичная консоль rpki-client показала запуск с параметрами rpki-client -c -j. Он обработал материалы AFRINIC, сообщил о разрывах последовательности manifest и о двух просроченных AFRINIC ROA, но не вывел прежнее предупреждение о том, что commonName закодирован не как PrintableString.

Другие ошибки в журнале важны: это не пустой экран успеха, инструмент действительно показывал обнаруженные проблемы. Но отсутствие одной строки в одном запуске нельзя считать криптографической переписью всех объектов. На вывод влияют уровень подробности, версия программы и путь получения данных; другие реализации relying party могут вести себя иначе.

Поэтому наблюдение — независимый сигнал, совместимый с успешным перевыпуском, а не окончательный акт приёмки. Нет и оснований связывать отмеченные разрывы manifest или просроченные ROA с прежней ошибкой UTF8String.

Основное условие опасного сценария всё же изменилось. Риск предполагал большую группу старых объектов в момент включения строгой проверки. Независимый запуск смог обработать материалы AFRINIC без предупреждения, которым эта группа прежде обнаруживалась.

Узкое несоответствие потребовало полноценной миграции

Раздел 4.5 RFC 6487 задаёт формат имён издателя и субъекта в ресурсных сертификатах RPKI. Атрибут commonName должен быть закодирован как PrintableString. После обновления RPKI-системы в 2022 году размещённая платформа AFRINIC стала выпускать эти значения как UTF8String.

В объяснении от марта 2024 года AFRINIC связал поведение с обновлённой конфигурацией OpenSSL. Документация позволяла неверно понять фактическое значение по умолчанию. Исправление документации OpenSSL уточнило, что действующим значением был utf8only, а nombstr ограничивает вывод типами, совместимыми с PrintableString.

Исправление процесса подписи помогло новым выпускам, но не переписало уже подписанные сертификаты и объекты. Затронутым размещённым центрам сертификации требовалась смена ключей и повторный выпуск зависимых объектов. AFRINIC планировал проводить работу партиями, чтобы не создавать несогласованность в точках публикации и осторожнее обслуживать участников с большим числом EE-сертификатов.

Так проявилась разница между коротким детерминированным правилом и живой миграцией. Проверка типа занимает несколько строк; переход охватывает ключи, сертификаты, manifest, ROA, кэши валидаторов и коммуникацию с участниками. AFRINIC контролировал выпуск, разработчики — исключение, а дистрибутивы и операторы — скорость внедрения. Ни одна сторона не могла синхронизировать остальных одним объявлением.

Шесть тысяч анонсов были сценарием нагрузки

17 ноября 2025 года Snijders сообщал о 988 объектах с несоответствующим именем издателя и 657 — с несоответствующим именем субъекта. Если бы исключение убрали тогда, число уникальных VRP под trust anchor AFRINIC временно сократилось бы, по его оценке, с 21 027 до 19 480. Около 6 000 BGP-анонсов могли перейти из ROV valid в not-found до повторного выпуска соответствующих ROA. В письме приведены и цифры, и условие.

Это не был подсчёт уже случившегося. Not-found также не равен invalid и не означает недоступность: у анонса исчезает прежнее подтверждение авторизации источника, но он не становится автоматически запрещённым.

В рассмотренных публичных источниках нет подтверждения, что в августе 2026 года такой переход затронул 6 000 анонсов. Нельзя превращать условную оценку в статистику происшествия. Её корректная роль — показать последствия слишком раннего удаления совместимости.

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

Четыре шкалы показывают остаток долга совместимости

Если валидатор становится строгим первым, VRP исчезают, а участники исправляют последствия под давлением. Код соответствует профилю, но переход оплачивают работающие сети.

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

Сигналы 21 августа соответствуют второй последовательности. Независимый запуск не показал прежнего предупреждения, а rpki-client пока сохраняет мягкую ветвь и portable-релиз 9.9 ещё не вышел. Это лучше обратной ситуации, когда строгий код встречает полный репозиторий наследуемых объектов.

Из этого не следует, что исключение для AFRINIC следует оставить постоянно. Специальная логика увеличивает поверхность аудита и затрудняет сравнение результатов между валидаторами. После независимого подтверждения нулевого остатка её можно удалить значительно безопаснее.

Срок, возможно, сработал как средство координации, хотя четыре шкалы не совпали. Такой вывод соответствует тезису Heng Lu о первичности работающего кода по отношению к одним лишь заявлениям: решающим доказательством остаются опубликованный исполняемый путь и независимо наблюдаемое поведение, а не дата сама по себе.

Чего не хватает для окончательного закрытия

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

Независимая консоль остаётся одной точкой наблюдения, а не межреализационным исследованием. Вывод усилили бы несколько валидаторов с зафиксированными версиями, параметрами и отпечатками обработанных материалов. Состояние программного обеспечения также нужно датировать: в коммите номера версии от 18 августа отказ был отключён, а 21 августа последним portable-релизом оставался 9.8. Следующий коммит или downstream-патч может изменить картину.

В этих границах новость всё же однозначна: один срок распался на четыре шкалы. Объявление вступило в силу, исходники сдвинулись, portable-пакет отстал, а независимый запуск уже не увидел старого предупреждения. Миграцию RPKI завершает совпадение правильных объектов, опубликованного кода и реально развёрнутых версий, а не дата в календаре.