Кратко

  • RFC 9596 регистрирует защищённый параметр COSE typ с меткой 16 для типа всего объекта; content type из RFC 9052 относится к payload или ciphertext.
  • COSE-библиотека передаёт typ приложению, не толкуя его. Защита возникает лишь тогда, когда приложение отвергает отсутствие и несовпадение и связывает каждый тип со своими правилами, ключами и авторизацией.

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

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

Такой предел важнее самой метки. Название выбирает дорогу, но не отменяет шлагбаумы на ней.

Внешний объект и внутренняя нагрузка имеют разные типы

RFC 9052 уже определяет content type данных в поле payload или ciphertext. RFC 9596 вводит typ для структуры COSE целиком. Синтаксис значений общий, область утверждения — разная.

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

Значением typ может быть беззнаковое число из реестра CoAP Content-Formats или строка media type с параметрами. Точное представление следует сохранять. Число и текстовый вариант могут считаться эквивалентными в документации, но попасть в разные ветви кода.

Если журнал хранит одну нормализованную колонку «тип», он теряет сведения о слое, защищённых байтах и сравнении, выполненном в момент приёма. Позднее невозможно доказать, проверялся конверт, нагрузка или оба.

Защищённое утверждение всё ещё может быть ошибочным

RFC 9596 запрещает размещать typ в незащищённых заголовках. В COSE-конструкции, аутентифицирующей защищённую корзину, посредник не может подменить тип, сохранив действительную подпись.

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

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

Контроль находится в отказе. Интерфейс, показывающий typ, но при ошибке переходящий к общему обработчику, внедрил подписанную подпись к картинке, а не изоляцию.

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

RFC 9596 опирается на RFC 8725. В JWT один вид токена может быть перепутан с другим; явная типизация снижает риск. Следующий пункт RFC 8725 требует взаимно исключающих правил валидации.

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

Тип должен выбирать полный контракт: разрешённую COSE-структуру, обязательные защищённые поля, тип нагрузки, claims, issuer, audience, назначение ключа, срок, replay-политику, endpoint и операцию. Неверный класс должен остановиться до общей бизнес-логики.

RFC 8725 предупреждает, что старые валидаторы часто не используют typ. Доля маркированных сообщений не доказывает завершение миграции. Нужны версия принимающего правила и наблюдаемые отрицательные тесты.

Реестр именует, но не доверяет

IANA зарегистрировала typ в COSE Header Parameters под номером 16. Значения ссылаются на Media Types или CoAP Content-Formats. Это даёт независимым реализациям общий словарь и предотвращает коллизии.

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

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

Именно здесь полезна минимальная начальная спецификация из docs/heng-lu-note.md: общий слой задаёт защищённое место и формат. Будущий выбор остаётся у участника. Добровольное принятие доказывает работающий валидатор, а не публикация строки.

Каждый переход требует собственного свидетельства

Нужно сохранять хеш исходных байтов, класс COSE, защищённые байты, точный typ и его форму, content type нагрузки, endpoint, операцию, ожидаемый набор, версию правила, криптографический результат, ключ и назначение, парсинг, обязательные claims, issuer, audience, свежесть, replay, решение авторизации, обработчик и наблюдаемый эффект.

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

Нельзя заставлять COSE-библиотеку свидетельствовать за бизнес-операцию, а media-type registry — за полномочие ключа. Пусть каждый компонент выдаёт квитанцию только о наблюдаемом им переходе.

Слои реальности ограничивают не пользу стандарта, а избыточные выводы. RFC 9596 даёт сильный защищённый сигнал. Его сила становится фактом лишь там, где работающий код исполняет соответствующие границы.

Источники