Кратко

  • kid в COSE — неструктурированная и неуникальная подсказка для отбора ключей-кандидатов, а не отпечаток ключа, идентичность устройства или разрешение на действие.
  • Для проверяемого вывода нужны область поиска, все кандидаты, полный отпечаток действительно сработавшего ключа, подписанные данные, связь с личностью, версия политики и наблюдаемый результат.

Проверяющий узел получает COSE_Sign1. В незащищённом заголовке записано kid = 0x19. Хранилище возвращает два ключа: прежний ещё действует для архивных сообщений во время ротации, а второй находится в ином клиентском контуре. Первый не подходит, второй подтверждает подпись.

Строка журнала «0x19: успешно» стирает смысл операции. Из неё нельзя узнать версию хранилища, область запроса, состав кандидатов, отпечаток победившего ключа и правило, разрешившее последующее действие. Поисковая метка превращается в имя подписанта.

Это не описание известного инцидента. Сценарий показывает, как допустимая спецификацией неоднозначность исчезает из неудачной схемы аудита.

Короткое значение сужает множество

RFC 9052 задаёт действующие структуры и процедуры COSE. Общему параметру kid назначены целочисленная метка 4 и тип «строка байтов». Значение может сопоставляться с одноимённым членом COSE_Key или эквивалентным полем иного способа распространения ключей.

Спецификация прямо запрещает предполагать уникальность. Одно значение может быть связано с несколькими ключами, поэтому иногда необходимо проверить их все. Внутренняя структура kid не определена. В объекте COSE_Key это может быть пользовательская строка или результат вычисления по открытой части ключа, но одинаковое значение всё равно допустимо у разных ключевых объектов.

Значит, запрос обязан иметь контекст: приложение, издателя или клиента, версию key store, момент времени и исходные байты. Его результат — множество кандидатов. Полный отпечаток ключа, на котором прошла проверка, появляется на следующем шаге и не является гарантированной расшифровкой короткой метки.

Реестр COSE в IANA сохраняет именно узкую семантику: kid с меткой 4 и типом bstr — идентификатор ключа. Отдельно зарегистрирован kid context. Не каждый профиль обязан использовать этот параметр, однако сам реестр не сливает значение с областью его толкования.

Незащищённое размещение ограничивает доверие

В объектах COSE есть защищённая и незащищённая группы параметров. Первая включается в аутентифицированную конструкцию. Вторая передаётся вместе с объектом, но не получает ту же защиту автоматически.

RFC 9052 называет kid подсказкой о выборе ключа и не считает его полем, критичным для безопасности. Поэтому параметр может находиться в незащищённой группе. Это не обещание нулевых последствий при подмене. Искажённое значение способно расширить поиск, обратиться не к тому tenant, потратить ресурсы или испортить журнал. Но решение о доверии не должно зависеть от истинности самой подсказки.

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

У подписи есть точный предмет

Для подписи RFC 9052 строит Sig_structure: контекст, защищённые параметры тела, защищённые параметры подписанта, если они предусмотрены структурой, внешние аутентифицированные данные приложения и полную полезную нагрузку. Кодирование даёт ToBeSigned, который вместе с алгоритмом, конкретным ключом и подписью поступает на проверку.

Квитанция должна хранить тип COSE, исходные байты защищённых заголовков, способ формирования external_aad, хэш обработанной нагрузки и полный отпечаток каждого кандидата. Отказ из-за некорректной map или неизвестного критического параметра тоже важен: он мог произойти до криптографической операции.

Зелёная отметка «подпись верна» относится к этой точной конструкции. Если интерфейс показывает рядом незащищённый kid, визуальная близость не добавляет его в область подписи.

Проверка не завершает работу приложения

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

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

Ротация делает различие очевидным. Старый и новый ключи могут временно делить один kid, оставаясь пригодными для разных операций. Историческая подпись продолжает подтверждаться после того, как её автор утратил право на новую команду. Отзыв меняет текущий допуск, но не переписывает прежний математический результат.

Решение политики также не равно эффекту. Разрешённая операция может не зафиксироваться в приложении, а внутренний commit не доказывает изменение внешнего устройства. Цепь заканчивает отдельное наблюдение результата.

Профиль ACE сохраняет неуникальность

Раздел профилирования RFC 9052 оставляет приложениям выбор сообщений, сервисов безопасности, заголовков, алгоритмов и переговоров. COSE предоставляет общую конструкцию, а конкретный протокол определяет юрисдикцию.

RFC 9200 применяет OAuth в ограниченных средах. В примере ответа Authorization Server с proof-of-possession COSE_Key она поясняет: kid нужен лишь для упрощения индексации и извлечения ключа, а его уникальность нельзя предполагать ни в домене клиента, ни в домене Resource Server.

Даже внутри протокола авторизации метка остаётся индексом. Записи дополнительно нужны профиль и версия, издатель или сервер авторизации, клиент, audience, Resource Server, допустимые операции ключа и итог политики.

Авторство Schaad не является властью над реализацией

Jim Schaad написал первоначальную спецификацию COSE RFC 8152, опубликованную в 2017 году. Позже RFC 9052, где автором также указан J. Schaad, заменила разделы о структурах и процессе, а алгоритмы были вынесены в RFC 9053. Профиль Jim Schaad в IETF Datatracker связывает эти документы с более широким списком RFC.

Это документы консенсуса IETF, а не личные распоряжения. Авторство не доказывает развёртывание или безопасность продукта. Памятная публикация Oregon Wine Press содержит подписанную фотографию, использованную только для сохранения узнаваемости в редакционном портрете. Винодельческий сюжет не служит техническим источником.

Неудачные кандидаты сохраняют историю

Первая запись фиксирует полученный объект: хэш, структуру COSE, защищённые и незащищённые заголовки, внешние данные и ссылку на нагрузку. Поиск оформляется отдельно с областью, версией хранилища, временем, исходным kid и полным перечнем результатов.

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

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

Источники