Кратко

  • RFC 9891 — экспериментальная спецификация IETF, расширяющая ACME для проверки идентификатора узла сети с задержками, представленного как идентичность сертификата BundleEID и как ACME-идентификатор типа bundleEID.
  • Node ID DTN — это singleton Bundle Protocol Endpoint ID, то есть одиночный Endpoint ID. Расширение не превращает non-singleton EID, то есть несинглтонный Endpoint ID, в допустимый Node ID.
  • Материал авторизации разделён между каналами: token-chal относится к ACME challenge, а token-bundle связывает проверку с конкретным Challenge Bundle.

Механизм проверки

Клиент начинает обычную процедуру ACME, включая доказательство владения ключом учётной записи. Сервер формирует challenge с token-chal и отправляет один или несколько Challenge Bundles на заявленный Node ID. BP Agent клиента получает Bundle и возвращает Response Bundle. Недостаточно, чтобы ответ просто оказался доступен через некоторый маршрут: его digest должен связывать challenge учётной записи, token-chal и факт получения именно этого Challenge Bundle, включая его token-bundle. Поэтому материал авторизации разделён: секрет ACME не передаётся по каналу BP, а один только канал ACME не доказывает получение выбранного Bundle.

Сервер проверяет ACME challenge, совпадение token-chal, принадлежность token-bundle нужному Challenge Bundle и digest-связь в Response Bundle. Он также проверяет, что целевой идентификатор является singleton Bundle Protocol Endpoint ID, а не non-singleton EID. Это различие не означает «один узел против нескольких узлов» в бытовом смысле: речь идёт о семантике Endpoint ID, установленной Bundle Protocol.

Если в процедуре действительно используется необязательный integrity gateway, он может аттестовать источник Response Bundles. Но RFC не определяет для такого gateway универсальную политику, делегирование доверия или межорганизационную власть именования. Поэтому, когда gateway фактически включён в проверяемый путь и его доверие не установлено локальной политикой, это является условием остановки конкретной проверки. Если необязательный gateway не используется, отсутствие доверия к нему само по себе не является причиной остановки и не делает gateway обязательным компонентом RFC 9891.

Граница доказательства

Успешная проверка может показать, что сторона с материалом учётной записи ACME создала корректный ответ и что ответ связан с получением определённого Bundle. Однако она не решает, кто обладает полномочиями именования DTN между организациями, является ли используемый gateway доверенным по согласованной политике и совпадает ли топология DTN overlay с топологией базовой IP-сети. RFC 9891 рассматривает атаки на пути и возможную пользу многоперспективной проверки, но её эффективность прямо остаётся экспериментальной.

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

Что находится вне спецификации

Развёртывание сертификата, выдача и хранение закрытого ключа, маршрутизация Bundle, ограничение скорости и обмен между компонентами ACME и BP Agent не входят в область расширения. Установка сертификата и жизненный цикл закрытого ключа остаются вопросами реализации. Политика integrity gateway, передача доверия и межорганизационные полномочия именования также не определены RFC 9891. Эти вопросы могут быть предметом локального анализа и управления, но не должны подаваться как дополнительные требования стандарта.

Идентичность сертификата и проверочные фикстуры

В сертификате идентичность должна описываться точно: SAN identity типа otherName с формой Other Name BundleEID. В ACME она кодируется как identifier type bundleEID. Это не произвольная формулировка «BundleEID SAN», а конкретная структура идентичности, которую следует сопоставлять с проверяемым Node ID.

Оператор может зафиксировать учётную запись, ACME challenge с token-chal, целевой singleton Endpoint ID и его значение. Затем отправляется Challenge Bundle с идентификатором и собственным token-bundle. Для ответа проверяются связь с выбранным Bundle и digest, объединяющий token-chal, token-bundle и challenge. В отрицательных тестах используются старый Bundle, token-bundle от другого Bundle, non-singleton EID и, если gateway был задействован, источник через gateway, не входящий в локальную политику доверия. Ни один такой ответ не должен считаться полным доказательством.

Путь решения оператора

Если Node ID, учётная запись, challenge и ответ корректно связаны с одним и тем же Bundle, результат проверки по RFC 9891 успешен только в пределах этого доказательства. При разрыве любой связи нужно проверить путь, токены и формат идентичности, не делая автоматического вывода о потере контроля над именем. Если используется integrity gateway и его доверие не подтверждено, проверку следует остановить; без фактического использования необязательного gateway это условие не применяется. Gateway и многоперспективная проверка должны быть записаны как локальная экспериментальная политика, а не как гарантия RFC.

Перед выдачей или установкой сертификата отдельно оцениваются ключи, provisioning и маршрутизация.

Источники

  • RFC 9891 — проверка DTN Node ID через ACME.
  • RFC 8555 — базовая спецификация ACME.
  • RFC 9171 — базовая спецификация Bundle Protocol.
  • RFC 9172 — базовая спецификация безопасности Bundle Protocol.