Кратко

  • RFC 9589 делает CMS signing-time обязательным в RPKI Signed Objects и запрещает binary-signing-time.
  • Оператор репозитория и relying party могут поставить это значение как mod-time для rsync-файла и материализованной RRDP-копии, экономя повторную передачу после сбоя RRDP.
  • Атрибут не доказывает реальное время подписи, публикацию, актуальный manifest, валидность сертификата или состояние BGP.

Один ориентир для двух доставок

RRDP доставляет snapshots и deltas, rsync — файловую иерархию. Это способы доставки, а не органы доверия. Ошибка XML, истекший TLS или timeout могут заставить relying party обратиться к rsync, хотя DER-объекты уже получены по RRDP.

Быстрая проверка rsync опирается на размер и время изменения. Если RRDP-копия получила локальное время загрузки, а сервер хранит другое, fallback вновь перенесёт существующий объект. RFC 9589 задаёт узкое правило: издатель включает signing-time, repository operator должен назначить его mod-time файла rsync, а relying party — своей RRDP-материализации. У двух представлений появляется общий вход сравнения.

Это сокращает сеть, I/O и CPU. Это не решение о принятии объекта.

Подпись не делает время надёжным

Подпись защищает переданное значение от незаметной подмены, но не подтверждает часы издателя, момент использования ключа или публикации байтов. RFC 9589 прямо не требует корректности signing-time и не считает его надёжной информацией о времени создания подписи.

Для оптимизации достаточно согласованного значения для одного объекта на обоих путях. Для хронологии инцидента нужны контролируемые журналы и наблюдения. Равные размер и mod-time — это условие пропуска передачи rsync, не криптографическое доказательство равных байтов. CMS, resource certificates и правила типа объекта остаются отдельными проверками.

Какие проверки не исчезают

Объект проходит общий профиль RFC 6488 и правила типа; EE certificate должен быть действительным и не отозванным. RFC 9286 даёт подписанный current manifest. По RFC 9829 релевантная CRL одновременно указана сертификатом и включена с совпадающим hash в текущий manifest CA.

Даже валидная ROA даёт лишь ограниченное разрешение AS origin-ировать заданные prefixes. Она не доказывает текущий анонс, выбор соседями, установку в router или доставку пакета. Успех RRDP и rsync не расширяют это утверждение.

Поэтому журнал охватывает URI, hash, решение о передаче, certificate, CRL, manifest, проверку объекта, fingerprint валидированного результата и лишь затем policy input. Успешная доставка доказывает только доставку.

Проверять нужно реальный fallback

Набор испытаний включает нормальный RRDP и rsync с теми же bytes, плохой XML, истекший TLS, timeout, отсутствующий файл, иной размер или mod-time, отозванный EE certificate и объект вне current manifest. Для каждой версии сохраняются путь, hash, signing-time, оба времени, размер, решение rsync, результаты certificate/CRL/manifest и fingerprint вывода. Различия validators — это доказательства, а не шум.

Источники