Кратко

  • RFC 8181 делает запрос с несколькими операциями атомарным, однако успех подтверждает транзакцию клиента и сервера, а не состояние всех доверяющих сторон.
  • Манифест RFC 9286 связывает имена и хеши текущего набора объектов; RRDP распространяет снимки и дельты с идентификатором сессии и серийным номером.
  • Реестр разделяет состояния запроса, фиксации, согласованности с манифестом, публичной выдачи и наблюдения.

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

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

Ответ об успехе доказывает, что названный сервер принял весь аутентифицированный запрос. Он не доказывает обновление публичного уведомления RRDP, доступность новых файлов по rsync или получение данных конкретной доверяющей стороной. RFC 8181 отделяет клиент-серверный протокол публикации от интерфейса распространения.

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

Область манифеста точна: актуальные сертификаты данной CA, её последняя CRL и прочие связанные подписанные объекты. Если точку делят несколько экземпляров CA, каждый манифест описывает только свои продукты. При завершении изменений RFC 9286 требует новый манифест, новые хеши заменённых объектов и публикацию до nextUpdate.

RFC 8182 задаёт последовательность распространения. Уведомление содержит идентификатор сессии и текущий serial; снимок даёт полное представление, а каждая дельта соответствует одному приращению и содержит добавленные, заменённые и удалённые объекты. Serial не является мировыми часами. Сторона может обратиться до обновления, увидеть кэш, отклонить дельту или вернуться к снимку.

Первая часть реестра хранит стороны, хеш подписанного сообщения, теги, URI, прежние и новые хеши, времена запроса и ответа. При атомарной ошибке нельзя заявлять частичный успех. Вторая часть связывает точку публикации, манифест, thisUpdate, nextUpdate, CRL и точный перечисленный набор.

Третья часть описывает распространение: URI уведомления RRDP, сессию, serial, хеши уведомления, дельты и снимка; наблюдение rsync фиксируется отдельно. Четвёртая часть хранит личность наблюдателя, версию ПО, время, транспорт, сессию и результаты проверки манифеста, набора и валидации.

Состояния REQUEST_AUTHENTICATED, SERVER_COMMITTED, MANIFEST_COHERENT, PUBLIC_VIEW_OBSERVED, RP_OBSERVED и EXCEPTION_OPEN удерживают выводы в пределах доказательств. Старое представление после успеха может отражать порядок наблюдений; новый serial при несогласованном манифесте всё ещё указывает на нездоровое операционное состояние.

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

Источники