Кратко

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

Представим проверку перед покупкой сетевых активов. Это иллюстрация, а не реальный случай. Продавец передаёт таблицу адресов, архив оборудования и .sig. Инструмент подтверждает два хеша, цепочку, CRL и включение ресурсов в EE-сертификат.

В checklist есть третья запись без переданного файла. По RFC 9323 это не обязано делать проверку двух объектов ошибочной; реализация должна предупредить о более длинном списке. Комитет всё равно записывает, что подписант — собственник, вправе продать и передал полный пакет.

Криптография сработала. Три вывода относились к другим системам полномочий.

Содержание RSC

RSC — защищённый CMS подписанный объект RPKI. Тип id-ct-signedChecklist имеет OID 1.2.840.113549.1.9.16.1.48. Реестр IANA содержит Signed Checklist и .sig; media type — application/rpki-checklist.

Блок ресурсов содержит AS, IP-блоки или оба вида. Каждый ресурс должен быть подмножеством соответствующего расширения RFC 3779 в EE-сертификате; inherit запрещён. Затем идут алгоритм и записи с обязательным хешем и необязательным переносимым именем. Имена уникальны среди именованных записей, хеши — среди безымянных.

Структура обозначает ресурсы и байты. В ней нет компании, должности, договора или права собственности.

Последовательность вердиктов

RFC 6488 требует DER CMS, разрешённые атрибуты, ровно один соответствующий EE-сертификат, проверяемую подпись и валидный путь к RPKI trust anchor. Эти проверки необходимы, но недостаточны без правил типа объекта.

RFC 9323 добавляет синтаксис, подмножество ресурсов, правила списка и отсутствие SIA в EE-сертификате. Сертификат должен быть действителен и не отозван. Истечение или отзыв прекращают валидность ранее действительного объекта.

Далее вычисляется хеш полученных байтов. Filename-aware требует единственного совпадения с тем же именем. Filename-unaware требует единственного совпадения без имени. Выбранный режим входит в доказательство.

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

Хеш не понимает смысл

Неизменный ложный документ идеально совпадает со своим хешем. Подпись сохраняет байты, но не проверяет собственность или факты. И наоборот, перевод строк или кодировка может изменить digest у текста с тем же смыслом. RFC 9323 рекомендует lossless compression для текста, уменьшая случайную канонизацию, а не подтверждая содержание.

Имя файла тоже не доказывает полноту: inventory остаётся лишь условием сопоставления.

Частичная проверка и полнота сделки

Операция может использовать не все записи. Это позволяет разным получателям проверять разные подмножества. Лишние записи вызывают предупреждение, а не обязательную ошибку.

Полнота определяется вне RSC. Для сделки могут требоваться реестровые права, клиентские назначения, обременения, споры, право на оборудование, инциденты, доступы и доверенности. RSC доказывает представленные файлы в своём списке; due diligence определяет обязательный состав.

Отчёт разделяет совпавшие записи, файлы без совпадения, записи без файла и требования, которых нет даже в RSC.

Контроль CA не равен личности

RFC 9323 называет данные самоутверждёнными. Relying party может заключить лишь, что подписант имел достаточный контроль над CA. Родительский CA не проверял содержание.

RFC 9255 поясняет: I в RPKI означает Infrastructure, не Identity. RPKI авторизует утверждения о ресурсах, но не аутентифицирует реального держателя или сделку.

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

Имена Subject и Issuer не решают задачу: RFC 6487 не считает их описательной идентичностью. Нужны внешний реестр, решение совета, доверенность, договор или другая власть, подтверждающая лицо, действие, цель и срок.

Вне репозитория и без надёжной даты

RSC не распространяются через публичный RPKI-репозиторий. Третья сторона без копии может не знать об объекте. Пробел serial или неизвестная запись CRL не доказывают его существование.

Канал передачи — отдельное доказательство. Аутентифицированный портал, известная почта и анонимная ссылка дают одинаковые байты с разным контекстом предъявителя. Канал и валидация не заменяют друг друга.

Одноразовый EE-сертификат позволяет отозвать отдельный объект. Повторное использование ключа для нескольких RSC лишает индивидуального отзыва. Экономия связывает независимые утверждения.

RFC 9589 требует signing-time, но не его корректность. Это не надёжное время подписи. Время проверки, срок сертификата, CRL и договорная хронология независимы.

Записать и отрицательную область

Досье хранит RSC и хеш, канал, OID, сертификат, путь, CRL, время, ресурсы, алгоритм, файлы, имена, режим, совпадения, неиспользованные записи, предупреждения, личность, мандат и решение. Оно прямо говорит, что собственность, истинность, полнота, представительство, надёжная дата и BGP origin authorization не доказаны.

Узость — сила RSC. Получатель сохраняет её, требуя отдельное доказательство для любой власти вне структуры.

Источники