Кратко

  • Рабочая группа COSE представила версию 21 проекта C509 24 сентября 2026 года. Версия 20 получила одобрение IESG в июле, но документ остаётся в очереди редактора RFC и ещё не опубликован как RFC.
  • В новой редакции чётче определена подписываемая последовательность CBOR. Серийный номер требуется передавать как строку байтов, а сокращать поле издателя можно лишь при побайтовом совпадении с полем субъекта.
  • Тип 3 сохраняет подпись исходного DER-сертификата после обратимого преобразования; тип 2 подписывает само представление CBOR. Ни один вариант не отменяет проверку пути сертификатов X.509.

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

Редакция C509 от 24 сентября делает первый из этих вопросов точнее. C509Certificate описан как массив CBOR, элементы которого образуют последовательность. Группа TBSCertificate без завершающего значения подписи названа подписываемой частью. Это уточнение границы для разработчиков, а не сообщение об эксплуатации уязвимости или о несовместимости конкретного продукта.

Особенно показателен серийный номер. Его нужно кодировать как строку байтов CBOR даже тогда, когда значение помещается в обычное небольшое беззнаковое число. При обратном восстановлении DER для типа 3 ведущий нулевой байт возвращают, если старший бит следующего байта иначе повлиял бы на трактовку целого числа. Аналогично краткое значение null вместо издателя допустимо тогда и только тогда, когда байты полей издателя и субъекта полностью совпадают. Внешне одинаковое написание имени не заменяет такого сравнения.

Различие между двумя типами нельзя спрятать за общей фразой «сжатие X.509». Тип 3 — обратимое перекодирование уже подписанного DER-сертификата. Подпись остаётся от исходного DER, а проверяющая сторона может восстановить эту форму; сама операция сжатия может проходить после выдачи в доверенной функции. Тип 2 подписывается непосредственно в CBOR. Он требует поддержки нового пути проверки и не становится совместимым с программой, понимающей только DER. Общая семантика X.509 не означает одинаковый набор поддерживаемых форматов у всех получателей.

Процедурные признаки также не стоит преувеличивать. IESG одобрила версию 20 20 июля; версия 21 находится в редакционной очереди. На момент проверки Datatracker сообщает, что редактор ожидает ответа авторов и действия IANA также ждут их. Это не новый утверждённый RFC и не показатель массового внедрения. Приведённые в проекте примеры уменьшения размера демонстрируют возможности метода, но не число сетей, уже его применивших.

Наконец, преобразователь не назначает корни доверия. Раздел безопасности сохраняет проверку пути по RFC 5280 и предупреждает, что заголовки сертификатов COSE нельзя считать доверенными без проверки существующим механизмом. Код в реестре IANA не является рекомендацией алгоритма. Для собственной оценки я бы фиксировал тип, версию преобразования, тестовый вектор подписанных байтов, результат восстановления DER и перечень проверяющих реализаций. Это предлагаемый редакцией журнал проверки, а не требование COSE.

Источники