Кратко

  • Необязательное поле rtt в RFC 9891 — подсказка клиента об ожидаемом времени между Challenge Bundle и ответом. Сервер ACME сам выбирает фактический интервал, применяет сетевые пределы и проверяет приход по Lifetime исходного вызова.
  • Корректный своевременный ответ подтверждает контроль Node ID в рамках одной проверки и одной политики. Он не доказывает вечное владение, будущую доступность пути, выпуск или установку сертификата, сеанс TCPCL, доставку Bundle либо результат приложения.

В заявке стояло число 300. Система сопровождения превратила его в запись: «проверка разрешена на пять минут». Но клиент сообщил предполагаемую длительность маршрута, а не установил обязательство для сервера.

RFC 9891 добавляет в ACME идентификатор bundleEID и метод bp-nodeid-00. Сервер формирует авторизацию и через свой BP Agent отправляет Challenge Bundle к заявленному DTN Node ID. Подготовленный агент клиента возвращает Response Bundle, связанный с авторизацией, ключом учётной записи и конкретным вызовом.

В Delay-Tolerant Network длинное ожидание может быть нормой. Это требует учёта задержки, но не отменяет границу между сведением о пути и властью проверяющей стороны.

Подсказка не переводит часы сервера

Response Object может содержать ожидаемый RTT в секундах. RFC прямо называет значение неавторитетной подсказкой. Обычно серверу следует взять удвоенный RTT и применить нижний и верхний пределы, подходящие сети. Для только наземной DTN верхний предел не должен превышать шестидесяти секунд.

В иной среде допустима другая величина. Не меняется субъект решения. Клиент знает расписание контактов и предполагаемую топологию; сервер знает запас ресурсов, стоимость хранения состояния, поверхность DoS и политику CA.

Клиент не должен отправлять Response Object, пока его BP Agent не готов отвечать. Поскольку фактический маршрут не гарантирован, оценка должна быть консервативной. Клиент отвечает за готовность и качество прогноза, но не владеет сроком принятия.

Решающими остаются Creation Timestamp и Lifetime исходного Challenge Bundle. У ответа есть свои время и остаточная жизнь, однако сервер сравнивает его с первоначальным окном. Поздний Response Bundle не может продлить вызов собственным полем Lifetime.

Длинное окно помогает прерывистым узлам, но дольше удерживает состояние и увеличивает стоимость защиты от повторов и перегрузки. Короткое бережёт ресурсы, но исключает допустимые пути. Один параметр заявителя не должен скрытно решать этот конфликт.

Доказательство собирается из двух каналов

Просто вернуть Bundle недостаточно. token-chal уникален для авторизации ACME и не появляется в канале BP. Несколько Challenge Bundles одной авторизации используют его вместе. Каждый Bundle получает отдельный token-bundle, видимый в DTN.

Агент соединяет оба токена с thumbprint ключа учётной записи, вычисляет Key Authorization и возвращает digest. Наблюдатель только BP-канала не знает закрытую для него часть; обладатель только ACME-объекта ещё не доказал получение конкретного Bundle.

Для каждой перспективы сервер проверяет срок, совпадение Source Node ID с целью, доверенный Block Integrity Block над primary block и payload, оба токена, допустимый алгоритм и ожидаемый digest. Нарушение любого условия означает неудачу. Отсутствие ответа до закрытия окна — тоже неудача.

Причины не равнозначны: маршрут, часы, конфигурация Agent, доверие к Security Source, алгоритм или корреляция. Оставив лишь invalid, оператор потеряет основу для следующего действия.

Успех также ограничен. Он связывает контекст аккаунта, конкретную авторизацию, Node ID и ответ в определённый момент. Он не устанавливает правовой титул и не обещает будущую связность.

RFC 9171 определяет Node ID как singleton Endpoint ID, способный обозначать BP Node. Глобальная уникальность не гарантирована; у узла может быть несколько Node IDs. Administrative EID уникален для узла только внутри конкретной URI scheme.

Реестр ACME IANA и реестр Bundle Protocol IANA координируют bundleEID, bp-nodeid-00, административный тип и схемы dtn и ipn. Общие коды обеспечивают совместимость, но не наблюдают узлы, маршруты и организационные права.

Несколько перспектив ещё не означают независимые пути

Сервер может отправить вызовы из нескольких источников или по разным маршрутам. У каждого Bundle свой токен, поэтому результаты не обязаны смешиваться. Это снижает некоторые риски атаки на одном пути, но не доказывает физическую независимость: логические маршруты могут сходиться на одном шлюзе.

RFC 9891 оставляет итоговую формулу политике сервера. Рекомендуемый вариант требует успеха основной перспективы и допускает не более одного отказа вторичной. Выбор основных и вторичных источников тоже относится к реализации.

Значит, valid — не сырое измерение. Это наблюдения после применения политики. Без отдельных строк и версии правила невозможно отличить полный успех от разрешённого частичного отказа или объяснить расхождение между двумя CA.

Integrity Gateway может локально проверить источник Bundle и добавить BIB. Получатель должен настроить, для каких диапазонов Node ID доверять этой Security Source. Криптография сохраняет утверждение шлюза, но не создаёт его полномочия.

Экспериментальный статус RFC относится именно к таким вопросам. Практическая польза разных перспектив, распределение naming authority и делегирование доверия между CA и другой сетью ещё проверяются. Зарегистрированный механизм позволяет провести опыт, а не объявляет его результат.

Это соответствует принципу Heng Lu из Минимальной начальной спецификации и локального будущего решения: общий слой фиксирует токены, сравнение, целостность и временную структуру. Допустимый риск и межорганизационное доверие остаются у тех, кто несёт последствия.

После успешной проверки остаются новые пороги

RFC 8555 разделяет challenge, authorization и order. Успех делает авторизацию действительной для аккаунта и идентификатора на определённый срок. Это ещё не сертификат.

Запрос по RFC 9891 может объединять NODE-ID, DNS-ID и IP-ID. Каждый идентификатор должен пройти проверку. CA затем применяет правила выпуска, Key Usage и ограничения алгоритмов. Верный DTN-ответ не обязывает её выпускать сертификат.

RFC 9174 описывает дальнейшее применение в TCP convergence layer. Сертификат может содержать NODE-ID и id-kp-bundleSecurity. Реальный peer по своей политике проверяет сетевую идентичность, Node ID или обе и прекращает сеанс при несоответствии.

RFC 9891 оставляет установку выпущенного сертификата в BP Agent реализации. Поэтому авторизация, выпуск, установка, выбор при TLS, сеанс TCPCL, передача Bundle и результат приложения требуют отдельных свидетельств.

RFC 9172 задаёт BPSec. Успех BIB подтверждает целостность покрытых данных в заданном контексте, но не решает, имеет ли Security Source право говорить за Node ID.

В Работающем коде как первичном доказательстве Heng Lu отделяет возможность спецификации от факта исполнения. Слои реальности и символическая власть показывают, как слово valid без времени, перспектив и объекта превращается в слишком широкую власть.

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

Источники