Кратко

  • Номер манифеста RPKI задаёт локальную последовательность подписанных перечней одной CA. Это не мировые часы и не свидетельство фактической маршрутизации. Поле имеет максимум, поэтому ошибка выпуска способна сделать любой следующий номер меньше уже принятого.
  • RFC 9981 считает другое имя манифеста началом новой эпохи сравнения. Relying party обязан предупредить оператора, а эмитент не должен превращать смену имени в рутину.
  • Заново начинается только числовая база. Цепочка подписи, более поздний thisUpdate, список файлов и хэшей, точное соответствие подписанного URI месту RRDP или rsync остаются обязательными.

Новее по времени, но никогда не больше

Представим CA, которая должна выпустить манифест 7914. Ошибка программы записывает 2^159 - 1 — наибольшее допустимое значение. Объект подписан верным ключом, даты действительны, имена и хэши правильно отражают точку публикации. Несколько relying parties принимают его и сохраняют число.

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

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

RFC 9981 выбирает минимальный наблюдаемый разрыв — иное имя файла. Это не общее право стирать неудобную историю. Имя объявляет другую эпоху сравнения, а все прочие свидетельства переходят границу без изменений.

Что именно учитывает манифест

Манифест RPKI — подписанный перечень файлов, которые CA намерена разместить в одной точке публикации. Каждое имя связано с хэшем, поэтому валидатор способен обнаружить отсутствие, подмену или неполное представление репозитория.

Сам манифест является подписанным объектом RPKI и использует одноразовый сертификат EE. Внутри находятся manifestNumber, thisUpdate, nextUpdate, алгоритм хэширования и пары имя/хэш. Сертификат CA указывает на объект через SIA id-ad-rpkiManifest.

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

Точная постановка удерживает восстановление в разумных пределах. Сломалось не «всё доверие RPKI». Невозможно продолжить числовую историю одной CA под одним именем. Исправление может оставаться локальным.

Огромное поле тоже конечно

RFC 9286 требует увеличивать номер на единицу для каждого нового манифеста. Relying party ожидает значение больше последнего принятого. Скачок указывает на пропущенное состояние, уменьшение — на старый или повторно предъявленный объект.

Номера разных CA несопоставимы и даже внутри одной CA не заменяют время. thisUpdate, nextUpdate, срок сертификата, отзыв и общая проверка подписанного объекта действуют отдельно.

RFC 9981 фиксирует предел: положительный INTEGER длиной до 20 октетов, максимум 2^159 - 1. При одном манифесте в секунду естественное исчерпание заняло бы около 23 171 956 451 847 141 650 870 квинтиллионов лет. Это не вопрос ёмкости.

Риск создаёт программа: неверное прибавление, бесконечный цикл выпуска, повреждённое восстановление состояния или случайное присваивание максимума. Одна ошибка перескакивает астрономическое расстояние.

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

Имя как явная граница эпохи

Если имя манифеста отличается от ранее связанного с CA, RFC 9981 запрещает отвергать новый объект только потому, что его номер не выше. Пройдя остальные проверки, он записывается под новым именем и начинает новую эпоху.

Имя — не свободная подпись в панели. Это последний сегмент URI в SIA id-ad-rpkiManifest сертификата CA. CA должна назвать новый путь в сертификате, опубликовать объект там и согласовать его с URI signed-object в сертификате EE.

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

Relying party обязан предупредить оператора. Смена может означать законное восстановление, плановый переход CA, ошибку или компрометацию. Подпись показывает автора утверждения, но не объясняет причины разрыва истории.

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

Что не сбрасывается

Правило не означает «новое имя — принять». Имя лишь выбирает сохранённый manifestNumber, с которым идёт сравнение.

По-прежнему нужны действительная подпись, сертификат EE и цепочка до CA. Срок, отзыв, профиль RPKI, структура, алгоритм, перечень и правила для отсутствующих файлов или неверных хэшей сохраняются.

Сохраняется свежесть. thisUpdate нового объекта должен быть позже значения в последнем принятом манифесте. Копирование старого подписанного перечня под новый путь не делает его свежим. nextUpdate продолжает ограничивать заявленный интервал.

Сохраняется местоположение. URI signed-object в сертификате EE должен точно совпадать с publish URI RRDP либо с путём rsync, откуда объект получен. Копия под другим именем без изменения подписанных ссылок не создаёт эпоху RFC 9981.

Манифест не переписывает перечисленные объекты. Он может вернуть перечень в область валидации, но не меняет ресурсы сертификата, префиксы ROA, состояние CRL или вход маршрутизатора.

Ловушка нескольких SIA

Сертификат CA может содержать несколько SIA манифеста. Relying parties способны выбирать разные места. Если новый сертификат удаляет одно старое имя, но сохраняет другое, часть валидаторов видит новую эпоху, а часть продолжение старой.

Обе группы могут правильно следовать выбранному URI и получить противоположные результаты. Новое имя допускает малое число, сохранившееся старое сравнивает его с максимумом и отказывает. Расхождение легко принять за кэш, задержку RRDP или дефект продукта.

Поэтому при восстановлении через имя ни одно прежнее имя не должно оставаться в новом сертификате. Нужно учесть все SIA, пути и правила выбора. Изменить только «главное» место недостаточно.

RRDP и rsync — транспорт, а не разные истины. Snapshot, delta и rsync должны сходиться к объектам с совпадающими байтами и подписанными URI. Успешный HTTP подтверждает доставку, но не криптографическую правомерность места.

Почему с trust anchor сложнее

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

У trust anchor нет родителя. Ключ и места сертификата поступают relying party обычно через TAL. Смена ключа или TAL сталкивается с разными темпами обновления, старыми установками и риском потерять всё дерево для тех, кто сохранил прежний материал.

RFC 9691 улучшает плановые переходы объектами TAK. Текущий trust anchor объявляет ключ-преемник и его места, валидаторы проверяют взаимные ссылки и ждут период принятия.

Но TAK не является тайным проходом вокруг повреждённой публикации. Relying party начинает с уже доверенного ключа, получает сертификат, проверяет манифест и CRL, затем обрабатывает TAK. Непрерывность готовят заранее и отрабатывают отдельно от смены имени RFC 9981.

Восстановление доказывает сходимость

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

Испытание использует записанные или синтетические материалы, а не производственный счётчик возле максимума. Нужны нормальная последовательность, скачок, максимум, малое число под прежним именем, малое число под новым, старый thisUpdate, несовпадающий подписанный URI и сертификат с оставшейся старой SIA.

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

В производстве сохраняют прежние сертификат и манифест, все URI, числа, времена и отпечатки выхода. Записывают причину, утвердивших лиц, новые SIA и ожидаемый эффект. RRDP snapshot, delta, rsync, валидаторы и входы маршрутизаторов сравнивают до удаления старого материала.

Если новый объект не проходит подпись, время, URI или перечень, ещё одно имя не является откатом. Выпуск останавливают, доказательства сохраняют и, когда правила позволяют, возвращаются к последнему доказанному состоянию. Цепочка сбросов превращает контролируемое исключение в необъяснимую историю.

Источники