Кратко
- 8 сентября 2026 года Datatracker перевёл draft-ietf-lake-edhoc-psk в состояние «WG Consensus: Waiting for Write-Up»; в тот же день появилась редакция 09. Документ остаётся Internet-Draft, не является RFC и ещё не одобрен IESG.
- Редакция 09 допускает, что один ID_CRED_PSK возвращает одну или несколько PSK-кандидатов и связанные удостоверения. Ответчик перебирает контексты до успешной проверки CIPHERTEXT_3B либо исчерпания набора.
- Запись одного компактного идентификатора больше не доказывает, какой локальный контекст удостоверения аутентифицировал другую сторону.
- Daniel Kade предлагает фиксировать версию набора, выбранную несекретную версию удостоверения и исход попыток. Это редакционное предложение, а не требование проекта.
Множественность возникает не в сообщении, а после его получения. Инициатор помещает ID_CRED_PSK в защищённую часть третьего сообщения EDHOC; ссылка может быть такой же короткой, как COSE kid. Ответчик использует её в локальном поиске. По сети идёт одно значение, тогда как за ним может находиться упорядоченный набор.
Редакция 09 описывает последовательность явно. Поиск возвращает PSK-кандидаты и данные, необходимые для обработки EDHOC. Ответчик выбирает первый контекст, выводит K_3 и IV_3, затем выполняет AEAD-проверку CIPHERTEXT_3B. При неудаче он переходит к следующему. Ошибкой обработки или признаком вмешательства считается лишь исчерпание всех кандидатов. Успех подтверждает владение PSK выбранного кандидата и активное участие партнёра в обмене.
В редакции 08 идентификатор служил для извлечения «правильного PSK». Уникальное либо стохастически уникальное обозначение рекомендовалось в том числе ради устранения неоднозначности и перебора нескольких ключей. Официальное сравнение показывает: рекомендация уникальности сохранена, но ранее нежелательный множественный случай получил нормативно описанный путь обработки. Соответствие один к одному остаётся предпочтительным быстрым путём, однако оно уже не единственная предусмотренная форма.
Выбирается не просто ключ
Фраза «попробовать другой ключ» скрывает важную часть состояния. Кандидат включает PSK, CRED_I, CRED_R и сведения, необходимые для согласованного криптографического набора. Удостоверения инициатора и ответчика должны различаться для защиты от отражения и ошибочной привязки; контекст хеширования также обязан соответствовать выбранному набору. На каждой попытке проверяется цельный контекст аутентификации, а не взаимозаменяемая секретная строка.
Базовый стандарт EDHOC, RFC 9528, уже отделяет короткие ссылки на удостоверения от самих удостоверений. В RFC 9052 COSE kid — подсказка получателю, а не глобально уникальное имя. RFC 8392 задаёт один из способов представления связанных утверждений. Расширение PSK делает различие критичным для аудита: одна полученная ссылка способна вести к нескольким локальным идентификационным и вычислительным состояниям.
Такой перебор нельзя приравнивать к подбору пароля. Для внешней PSK редакция 09 требует не менее 128 бит энтропии и длину не менее 128 бит. Пароль и другой источник с низкой энтропией не считаются безопасной основой общего секрета. Кандидаты — заранее подготовленные контексты, разделяющие поисковый дескриптор, а не догадки из слабого пространства.
Доступность в период смены ключей
Проект не предписывает, зачем хранить несколько кандидатов. Возможны окно ротации, временное расхождение баз подготовки, повторное использование короткого пространства идентификаторов в изолированных разделах или сохранение старого контекста до подтверждения замены. Это разумные операционные выводы, но не подтверждённые развёртывания: в зафиксированном наборе источников нет производственной системы с таким отображением.
Польза тем не менее понятна. Ограниченному устройству не приходится передавать более крупный объект идентичности, а весь парк не обязан переключаться одномоментно. Обратная сторона — политика переезжает в таблицу ответчика. Состав, порядок, сроки вывода и бюджет попыток не видны инициатору.
Два ответчика, которые должны следовать одной политике, способны получить одинаковый идентификатор и принять одного партнёра, но добиться успеха на разных позициях. Если оба сохраняют только ID_CRED_PSK, записи выглядят одинаково. Из них нельзя узнать, проверялось ли сначала просроченное удостоверение, вступила ли в силу новая версия или продолжает работать резервный путь.
Это и есть вопрос управления. Успешная аутентификация — реальный результат, полученный идентификатор — реальный вход. Но ни то, ни другое отдельно не описывает локальный выбор, соединивший их. Считать короткую ссылку уникальным именем принятого удостоверения означало бы приписать ей более сильное доказательное значение, чем допускает проект.
Консенсус группы — ещё не публикация стандарта
Объявление и отзыв по Working Group Last Call задали окно проверки редакции 08 с 1 по 15 июля. В архивном обсуждении выбора кандидатов рецензенты предложили переходить к новому кандидату после неудачной AEAD-проверки; эти шаги появились в редакции 09.
История Datatracker фиксирует 8 сентября переход из In WG Last Call в «WG Consensus: Waiting for Write-Up», назначение Marco Tiloca сопровождающим документа и выход новой редакции. Текущая карточка всё ещё описывает активный проект LAKE, предназначенный для Standards Track. Заключение сопровождающего, рассмотрение IESG, возможные новые редакции, утверждение и публикация RFC остаются отдельными этапами.
Сохранить факт выбора, не раскрывая секрет
Соразмерному журналу не нужны байты PSK или публичная идентичность устройства. Он должен ответить на узкий вопрос: какой несекретный локальный контекст принял этот ответчик при данном поиске?
Запись может связать отпечаток полученного ID_CRED_PSK, версию или дайджест набора кандидатов, количество кандидатов, выбранную несекретную версию удостоверения, набор и хеш-контекст EDHOC, число попыток, исход, версию политики и время. При исчерпании та же структура покажет, что ни один кандидат не прошёл, не раскрывая содержимое. Задержку и долю исчерпаний можно агрегировать по диапазонам размера набора.
Так ротация становится наблюдаемой и обратимой. Временный рост успехов на втором кандидате может означать нормальный переход; тот же показатель после срока вывода — закрепившееся старое состояние. Несовпадающие версии набора у ответчиков с общей политикой обнаружат расхождение до того, как расследованию останется лишь сообщение «ошибка PSK».
Эта схема — редакционное предложение Daniel Kade. Редакция 09 её не требует, и рабочая группа её не утверждала. Разделение разумно: стандарт задаёт криптографическую обработку, а профиль применения — хранение и границы приватности. Неразумно лишь продолжать вести журнал как для единственного результата после того, как поиск стал множественным.
Источники
- IETF Datatracker — EDHOC Authenticated with Pre-Shared Keys
- История документа в Datatracker
- Редакция 09
- Редакция 08
- Официальное сравнение редакций 08 и 09
- Проверка LAKE и обсуждение выбора кандидатов
- RFC 9528 — EDHOC
- RFC 9052 — COSE Structures and Process
- RFC 8392 — CBOR Web Token
- RFC 9668 — Using EDHOC with OSCORE
- Рабочая группа IETF LAKE
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

