Кратко

  • CRL Number остаётся обязательным в RPKI CRL, но RP проверяет лишь некритичность расширения и неотрицательное целое до 2^159-1; сортировать списки по значению нельзя.
  • Применима единственная CRL, которую одновременно указывает CRLDP сертификата и перечисляет с совпадающим хешем текущий манифест выпускающего CA.
  • Выбор объекта, отзыв сертификата, проверка подписанного объекта, состояние происхождения, доставка маршрутизатору, политика и результат трафика требуют отдельных квитанций.

Архив содержал два правдоподобных ответа

Представим восстановление из архива. Там две подписанные CRL одного CA. У файла с большим номером нет записи в текущем манифесте. Другой файл указан в fileList с точным хешем, и на него ведёт CRLDP проверяемого сертификата. Выбор по числу кажется способом восстановить новизну, но на деле обходит подписанное состояние публикации.

Это модель, не сообщение об инциденте. RFC 9829 запрещает такой обход. Карточка RFC Editor и Datatracker фиксируют Standards Track RFC июля 2025 года, обновляющий RFC 6487. История, ссылки, последующие документы и поиск errata дают происхождение текста. При заморозке подходящих errata не было; это ничего не говорит о конкретных реализациях.

В общей PKI интуиция имеет основание. RFC 5280 определяет CRL Number как монотонную последовательность, помогающую выбрать более новый список среди нескольких применимых. Но RFC 6481 задаёт структуру репозитория RPKI, а RFC 9286 — подписанный манифест с именем и хешем каждого текущего объекта. В fileList находится одна текущая CRL CA.

RPKI устранила множество кандидатов, для которого был нужен счётчик.

Правильный синтаксис не даёт права выбора

В каждой RPKI CRL должны быть ровно два расширения: AKI и CRL Number. RP обрабатывает AKI. Для CRL Number он проверяет некритическую отметку и допустимое неотрицательное целое, а затем игнорирует величину.

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

RFC 9829 рекомендует уравнять CRL Number с manifestNumber манифеста, в который войдёт CRL. Это полезная диагностическая связь, но не резервный селектор. Расхождение требует расследования выпуска, а не выбора максимума.

Сертификат и манифест должны указать один объект

RFC 6487 определяет ресурсный сертификат и CRL Distribution Points. Обновлённый шаг проверки использует одновременно текущий манифест издателя и CRLDP сертификата.

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

Порядок остался у манифеста. manifestNumber, thisUpdate, nextUpdate, подпись, EE-сертификат и сравнение с ранее проверенными манифестами образуют утверждение о текущем состоянии. Материал о RFC 9981 уже владеет темой потолка номера и новой эпохи после смены имени. Здесь рассматривается выбор CRL внутри действующей эпохи.

Хеш фиксирует намерение CA, а не итог маршрутизации

RFC 9286 помогает заметить удаление, изменение и замену объекта старой версией. RFC 9829 называет хеш fileList криптографической гарантией намерения CA относительно самой свежей CRL и способом убрать возможные replay-векторы от конкурирующих правил.

Граница этой гарантии важна. Совпадение хеша не проверяет свежесть манифеста, подпись CRL, связь ключей, AKI и серийный номер. CRL должна быть валидна; её подпись и сертификат проверяются одним публичным ключом; отзыв следует только из наличия целевого серийного номера в применимом списке.

RFC 3779 описывает IP- и AS-ресурсы в сертификатах. Даже верное решение на этом слое не является наблюдением BGP или пакета.

Доставка байтов не выбирает их статус

RFC 8182 определяет RRDP; возможен и rsync. Успешная загрузка создаёт локальную копию. RP могут иметь разные кэши и эпохи, поэтому сравнивать надо проверенный манифест, хеш и правило кэша, а не видимый номер CRL.

Предыдущая статья RFC 9589 отвечает за CMS signing-time, файловый mod-time и переключение RRDP–rsync. Она использовала RFC 9829 лишь как опору для границы времени файла. Настоящий материал разбирает самостоятельный механизм: CRL Number лишён ранга, а объект выбирается пересечением ссылок.

Затем RFC 6811 соединяет проверенные данные происхождения с BGP-маршрутом, а RFC 8210 доставляет сведения кэша маршрутизатору. Приём, локальная политика, RIB/FIB и фактическая пересылка остаются отдельными событиями.

Полная цепочка хранит публикацию CA, транспорт, выбор манифеста, совпадение CRLDP/имени/хеша, проверку CRL, поиск серийного номера, проверку объекта, состояние происхождения, квитанцию маршрутизатора, решение и наблюдение.

Система стала строже, убрав один голос

RFC 9829 не расширяет общую власть, а удаляет дублирующий оракул. Minimum Initial Specification Heng Lu защищает узкий общий инвариант. Reality Layers разделяет число, подписанное намерение, проверку и результат. Running-Code Primacy требует показать, какой селектор действительно исполнил RP.

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

Источники