Кратко

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

Система обновления получает короткий COSE-конверт для многогигабайтной прошивки. Подпись верна, а защищённое поле местонахождения указывает на зеркало. Панель контроля способна показать успех ещё до DNS-запроса. Файл при этом может отсутствовать, зеркало — сменить владельца, а найденная прошивка — относиться к другой модели.

RFC 9995, опубликованный в июле 2026 года на Standards Track IETF, определяет COSE Hash Envelope именно как компактную защиту хеш-результата. Удалённому подписывающему сервису не нужно принимать большой прообраз. Проверяющему, у которого уже есть объект, не нужно получать дубликат. Экономия достигается тем, что объект остаётся снаружи.

Поэтому надпись «signature valid» должна означать ровно один завершённый этап. Она не может объявлять завершёнными доставку, byte match, анализ и разрешение.

Прообраз, дайджест и отсоединённый дайджест

Прообраз — точная последовательность байтов, поданная хеш-функции. Дайджест — короткий результат; в RFC 9995 он становится payload структуры COSE. Обычные правила COSE позволяют дополнительно отсоединить и этот короткий payload, предоставив его отдельно при проверке.

Отсутствие большого прообраза — назначение Hash Envelope. Отсутствие внутри сериализации ещё и маленького дайджеста — третий транспортный режим. Запись «detached payload supplied» не показывает аудитору, были ли предоставлены десятки байтов или весь целевой артефакт.

RFC 9052 задаёт структуры COSE. В COSE_Sign1 подпись связывает защищённые заголовки, выбранные приложением external authenticated data и полный payload в Sig_structure. Незащищённые заголовки в эту область не входят. В Hash Envelope payload — дайджест, а отсутствующий прообраз не становится подписанным из-за логической связи.

Проверить конверт офлайн — корректный результат. Установить соответствие объекта можно лишь после появления байтов и повторного вычисления. Эти состояния должны иметь разные имена и доказательства.

Метки 258–260 задают координаты

payload_hash_alg, метка 258, обязательна в защищённом заголовке и запрещена в незащищённом. Она указывает алгоритм, создавший payload-дайджест.

preimage_content_type, метка 259, необязательна и защищена при наличии. Она сообщает media type или CoAP Content-Format исходных байтов. Это не обычный COSE content_type с меткой 3: тот описывал бы текущий payload, то есть дайджест. RFC 9995 запрещает метку 3, чтобы два объекта не получили двусмысленное описание.

payload_location, метка 260, может содержать строку или URI для поиска прообраза. Защита обнаружит подмену подсказки внутри конверта. Она не обещает доступность, неизменного владельца, безопасность, приватность или полномочия проверяющего на обращение к адресу.

Реестр COSE IANA координирует значения и ссылки. RFC 8126 объясняет правила регистрации. Наличие записи не доказывает поддержку библиотекой, соответствие конкретного объекта или допустимость в локальной модели риска.

RFC 8610 предоставляет грамматику CDDL. Она проверяет форму, но не происхождение и права. RFC 7252 задаёт пространство CoAP Content-Format. Значение формата может выбрать parser, но не подтверждает корректность, правдивость или пригодность содержания.

Ключ ещё не является личностью

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

RFC 9052 возлагает на приложение связь verification key с правильной identity и проверку её authorization. Тестовый ключ, ключ архивных квитанций и ключ выпуска могут создавать математически верные подписи. Окончание договора, смена роли и отзыв изменяют власть, не меняя старое значение подписи.

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

RFC 9421 подписывает выбранные HTTP-компоненты и требует профиль приложения. Это соседняя, но другая область: Hash Envelope не подписывает HTTP-запрос и не разрешает переход по URI. Общий принцип — не расширять подпись за пределы названных компонентов и цели.

Отчёт должен разделять структуру, криптооперацию, связь ключа, актуальность identity, разрешённую роль и совпадение контекста.

Защищённый URI остаётся входом downloader

Проверяющий может уже иметь объект, работать без сети или получать его только через брокер. RFC 9995 позволяет использовать местонахождение, но не требует автоматического dereference. Без прообраза можно подтвердить конверт, но нельзя провести сравнение или извлечь пользу объекта.

Привилегированный сервис, открывающий любую подписанную URI, передаёт подписанту сетевую возможность. Redirect может уйти на другой origin, credentials — последовать за ним, старый домен — сменить хозяина, сжатый ответ — превысить бюджет после распаковки. Компрометация доверенного ключа превратит целую подсказку в целую враждебную команду, если архитектура не разделяет эти понятия.

RFC 9110 различает HTTP resource, representation, content coding, location и redirection. Политика получения ограничивает schemes, origins, redirects, DNS/TLS, credentials, время, байты, распаковку и сетевой доступ; сохраняет конечный источник и преобразования.

RFC 6920 разделяет хеш-имя и механизм поиска. Зеркала могут меняться, сохраняя те же байты. Тот же URL может начать возвращать другой объект. Местонахождение находит кандидата; дайджест после загрузки устанавливает равенство.

Точный объект определяется до вычисления

Получив кандидата, проверяющий применяет алгоритм метки 258 и сравнивает результат с COSE payload. Имя, версия и storage key не заменяют операцию.

RFC 9530 разделяет digest HTTP content и selected representation data. Content coding может дать одному абстрактному ресурсу разные байты. Digest-поля также не обеспечивают сами по себе authentication, authorization или privacy.

Профиль должен сказать, что является прообразом: сохранённый сжатый файл, декодированный content, каноническая сериализация или другой точный поток. Разбор и повторная сериализация JSON/CBOR способны изменить порядок, пробелы и числа. Нормализация строк или прозрачная распаковка меняют объект.

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

Равенство не заменяет смысл

Совпадающий SBOM может не разбираться. Разобранный может не соответствовать schema. Соответствующий schema может описывать другую сборку. Правильная сборка может иметь неполные dependencies. Полный список может содержать запрещённый компонент.

Content type выбирает средство чтения, а не решение. Старые данные продолжают точно совпадать со старым digest. RFC 9995 не задаёт универсальную freshness: версия, время, audience, revocation и цель принадлежат приложению.

Спецификация охватывает COSE_Sign, Sign1, Mac и Mac0. Encrypt и Encrypt0 вне области. Она не даёт конфиденциальность и не определяет порядок хеширования и шифрования для будущей композиции.

Алгоритмы требуют активной политики. RFC 9053 определяет COSE algorithms и проверки параметров. RFC 9995 требует согласованной стойкости hash и signature/MAC. RFC 7696 показывает, что agility — миграция: производители выпускают преемника, потребители поддерживают overlap, политика назначает прекращение старого варианта и обработку архива. Распознаваемый identifier не равен допустимому.

Доказательством служит исполненная цепь

Принцип running code Хэн Лу переносит доказательство на точные байты, digest, envelope, algorithms, key, identity и purpose, решение о fetch, маршрут передачи, пересчёт, compare, parser, оценку, authorization действия и результат. Маркер поддержки стандарта не закрывает эти этапы.

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

Различие слоёв реальности не позволяет слить parsing, криптографию, identity, получение, byte equality, смысл, authorization и effect в одно «verified». Успех предыдущего слоя не выдаёт права следующему.

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