Кратко

  • RFC 9668 объединяет EDHOC message_3 с первым OSCORE-запросом и при прямом распределении ролей и совместимом профиле сокращает обмен до минимум двух циклов.
  • Проверенный OSCORE-ответ подтверждает криптографическую цепь и связывается с запросом, но не заменяет доказательство авторизации, фиксации или физического исполнения.

Клиент получил ответ, защищённый новым OSCORE-ключом. Проверка прошла. Это означало, что Responder вычислил ожидаемый материал ключа и сформировал ответ, связанный с исходным запросом. Панель перевела это в «клапан закрыт».

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

RFC 9668 решает другую, более узкую задачу. В последовательной схеме стороны обмениваются EDHOC message_1 и message_2, завершают обмен message_3, а затем начинают первую OSCORE-транзакцию. После успешной обработки message_2 Initiator уже может вывести OSCORE Security Context. Поэтому message_3 и защищённый CoAP-запрос можно подготовить параллельно и поместить в одно сообщение. Вместо трёх round trips минимально нужны два.

Экономия эфира реальна. Она не отменяет расстояние между криптографическим принятием и внешним эффектом.

Два объекта сохраняют собственные границы

Комбинированная payload — это кодированный message_3, за которым следует OSCORE ciphertext. C_R передаётся в поле kid как Sender ID клиента. Пустая EDHOC option 21 сообщает серверу, что нужно сначала извлечь данные EDHOC, а затем обработать защищённую часть.

Option 21 является Critical, Safe-to-Forward, входит в Cache-Key, не повторяется и должна быть пустой. Это инструкция parser, а не разрешение. OSCORE ciphertext также не вычисляется поверх message_3: у последнего защита EDHOC, у запроса — OSCORE. Совместная оболочка не превращает два доказательства в одно.

Сервер проверяет формат, извлекает message_3, читает kid как C_R и находит EDHOC session. Если application profile требует message_4, оптимизированный путь должен завершиться ошибкой. Иначе сервер проверяет message_3 и только после успеха создаёт новый OSCORE Context.

Затем он извлекает ciphertext, восстанавливает запрос без EDHOC option, выполняет decrypt, integrity и replay checks и лишь после этого передаёт plaintext приложению. Отказ message_3 запрещает создавать context. Более поздний отказ OSCORE относится уже к другой стадии. Наличие context не доказывает delivery.

Ответ подтверждает ровно сформулированное состояние

После успешной обработки EDHOC и OSCORE сервер обязан вернуть OSCORE-protected response. Его проверка может дать Initiator key confirmation от Responder. OSCORE также связывает ответ с запросом, защищая от подмены и несоответствия.

Но response code и payload создаёт приложение. Если оно говорит «accepted», защищённым становится факт принятия, а не завершения. Если оно говорит «changed» после записи в volatile memory, это не доказательство durable commit. Если контроллер подтвердил отправку на actuator, это не показание датчика положения.

Полезная модель разделяет delivered, authorized, accepted, committed, observed и compensated. Для каждого состояния должен существовать собственный источник. Криптографическая квитанция может нести один из них, но не должна автоматически повышаться до самого дальнего.

Именно здесь важна граница символического слоя. Защищённое сообщение — достоверное описание ограниченного факта. Физическая система остаётся самостоятельной реальностью. Running code требует посмотреть, что реально приняло приложение и что измерил объект.

Потерянный ответ делает retry управленческим решением

Если ответ потерян, клиент не знает, на каком шаге остановилась цепь. EDHOC не обработает один и тот же message_3 несколько раз в session, а OSCORE применит replay protection. Однако новый запрос с новой business identity может снова вызвать допустимое действие.

Первый комбинированный запрос для необратимой или дорогой операции должен иметь стабильный idempotency key и доступный для запроса outcome. Timeout следует описывать через последнюю подтверждённую стадию: packet unknown, message_3 accepted, OSCORE accepted, application accepted, committed или response verified. Тогда повтор не превращается в догадку.

kid тоже должен связываться с generation. В комбинированном запросе он одновременно выбирает OSCORE Sender ID и EDHOC session по C_R. RFC вводит ограничения уникальности, но короткое значение со временем может использоваться в другой истории. Нужны transcript hash, profile version, session generation и context generation без сохранения секретов.

Размер может вернуть последовательный режим

message_3 способен включать certificate chain или External Authorization Data. При Block-wise только первый внутренний блок соединяется с EDHOC. Если COMB_PAYLOAD превышает MAX_UNFRAGMENTED_SIZE, клиент обязан оставить этот blockwise-вариант и может сначала отдельно завершить EDHOC, затем отправить OSCORE-запрос.

Это предусмотренный локальный выбор, а не нарушение. Но он меняет latency, energy и timeout. Храните длины компонентов, MTU, номер блока, порог, причину fallback и итоговый режим. Иначе показатель «два цикла» будет описывать только удобные сертификаты и лёгкие команды.

Discovery через ed-r и ed-comb-req сообщает поддерживаемую возможность. Оно не доказывает runtime profile, размер или успешный результат. Общая спецификация правильно остаётся узкой. Решение доверять оптимизации для конкретного действия принадлежит оператору.

Источники