Кратко

  • Действующий проект рабочей группы CBOR определяет общую, preferred-plus и детерминированную сериализацию. Последняя добавляет к preferred-plus побайтовую лексикографическую сортировку детерминированных кодировок ключей карты. Результат становится повторяемым, но карта не приобретает прикладного порядка.
  • Детерминизм нужен, когда независимые стороны отдельно собирают байты подписи, хеша, адреса содержимого, ключа кеша или сравнения. Если защищённые байты передаются без изменения, он обычно не нужен; совпадение байтов не доказывает полноту, актуальность, разрешение или фактический эффект.

Первоначальный диагноз звучал просто: «подпись недействительна». В журналах обоих сервисов декодированный объект выглядел одинаково. Шестнадцатеричное сравнение показало другое: одна библиотека использовала более длинную допустимую форму аргумента и порядок вставки карты, вторая — кратчайшие формы и сортировку ключей. Обе последовательности были корректным CBOR. Для криптографии они оставались разными.

Именно этот координационный разрыв рассматривает draft-ietf-cbor-serialization-08. Документ датирован 29 июля 2026 года и остаётся активным Internet-Draft рабочей группы CBOR на стадии Working Group Last Call; Datatracker указывает состояние IESG I-D Exists. Это не окончательный RFC и не свидетельство соответствия конкретного продукта. Его практическая роль — назвать три контракта, чтобы протокол мог определить объём свободы представления на каждой границе.

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

Три контракта, а не шкала качества

Общая сериализация является теоретическим вариантом по умолчанию, если протокол на основе CBOR ничего не уточняет. Для каждого поддерживаемого типа декодер должен принимать все разрешённые формы, включая определённые и неопределённые длины. Проект одновременно отмечает, что такая широта реализована далеко не везде. Фраза «поддерживает CBOR» поэтому не заменяет матрицу фактического приёма.

Preferred-plus сужает свободу кодировщика. Аргументы получают кратчайшую форму, числа с плавающей точкой — самое короткое точное представление, длины становятся определёнными, используется предписанная форма NaN, а целые и bignum нормализуются. Это практический выбор для большинства протоколов без сортировки карт.

Детерминированная сериализация берёт preferred-plus и добавляет главное правило: элементы карты сортируются по побайтовому лексикографическому порядку детерминированных кодировок ключей. Если модель и окружающие правила определены, независимые кодировщики могут получить одинаковые байты.

Эти множества не образуют лестницу добродетели. Общая сериализация сохраняет возможности, которые нужны некоторым системам: формирование с неопределённой длиной, смысловое различие между обычным целым и bignum, нетривиальная полезная нагрузка NaN. Детерминизм сознательно убирает эти варианты ради повторяемости. Выбор должен отвечать конкретной необходимости.

Выдача и приём тоже различны. Детерминированное декодирование не предъявляет требований сверх preferred-plus. Система может выдавать узкую форму и принимать более широкий набор. Отказ от любой недетерминированной формы — отдельная сквозная политика, которой нужны текст, тесты совместимости и основание.

Байты передаются или создаются заново?

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

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

Требование должно быть локальным. Детерминизм Sig_structure не делает автоматически детерминированными вложенную нагрузку, внешний конверт и будущие объекты. Превращение точечного правила в политику платформы способно сломать потоковые сценарии и старые данные без дополнительной пользы.

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

Сортировка ключей не создаёт деловой очерёдности

Карты CBOR неупорядочены в общей модели. Детерминированная сортировка выбирает повторяемое расположение байтов, но не устанавливает приоритет, порядок выполнения или отображения.

Инструменты отладки вводят в заблуждение, потому что показывают ключи списком. Один язык хранит порядок вставки, библиотека возвращает порядок получения, хеш-таблица обходит иначе. Все они могут представлять одну карту. Если приложению нужна последовательность, оно должно использовать массив, поле приоритета или явное правило.

Сортировка не решает повторяющиеся ключи, разрешённые теги, неизвестные поля, эволюцию схемы или эквивалентность. Без карт preferred-plus иногда даёт детерминированный результат, но это не отвечает, допустим ли тег и меняет ли отсутствие поля полномочие.

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

Слово «канонический» без уточнения скрывает различия. Отдельный профиль draft-mcnally-deterministic-cbor-17 дополнительно ограничивает CBOR. Его правила нельзя молча приписывать проекту рабочей группы. Аудиту нужны имя профиля и редакция.

Подпись подтверждает байтовую границу

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

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

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

CDDL описывает форму данных CBOR. Механизм управления сериализацией из проекта может добавить требование кодировки. Но схема не является работающим кодом, разрешением или свидетельством результата. Соответствие CDDL не показывает версию парсера, политику дубликатов, якорь доверия и подтверждённую транзакцию.

COSE и CWT демонстрируют распределение обязанностей. Универсальный каркас обслуживает разные конечные протоколы и не знает всех требований реконструкции и потока. Если каркас не назначает множество, проект рекомендует preferred-plus, а встраивающий протокол определяет реальную границу. Настройка библиотеки по умолчанию не заменяет контракт.

Проверять реально работающий декодер

Между теоретической широтой general и практикой есть измеримый пробел. Один компонент может отвергать строки неопределённой длины, второй — принимать непроверенные альтернативные ширины, третий — преобразовывать bignum, хотя все заявляют CBOR.

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

Отрицательные тесты очерчивают границу: законная общая форма для приёмника general; неминимальная форма для шлюза preferred-plus; разные порядки вставки; границы целого и bignum; определённые и неопределённые длины; ширины плавающих чисел и NaN. Помимо «разобрано» фиксируются полученное значение и путь политики.

Тест кодировщика не доказывает широту декодера. Тест приёма не доказывает детерминированность выдачи. Обратный цикл в одной библиотеке маскирует обе проблемы, повторяя её предположения. Совместимость начинается между независимо построенными путями.

Особые значения раскрывают скрытую модель

Preferred-plus выбирает кратчайшее точное представление числа с плавающей точкой и заданный тривиальный quiet NaN. Некоторые области сохраняют полезные биты NaN или придают им смысл. Если они входят в информационную модель, протоколу нужен иной контракт сериализации.

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

Минимальная начальная спецификация координирует наименьшую общую поверхность: детерминизм в местах реконструкции, preferred-plus в обычном обмене, если ограничения подходят, и general или именованный профиль там, где это действительно нужно. Ради одной структуры подписи не требуется замораживать всю экосистему.

Сузить один скрытый канал

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

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

На чувствительной границе можно хранить дайджест байтов и нормализованную модель при соблюдении приватности и сроков. Если якобы детерминированный производитель меняет дайджест той же пробы, исследуются вход, версия, параметры и среда. Расхождение — сигнал, но не автоматический приговор.

Квитанция, переживающая смену библиотеки

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

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

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

Принцип Lu Heng о первичности работающего кода спрашивает, какая версия и опция действительно выполнялись. Слои реальности не позволяют детерминированным байтам присвоить власть схемы, а подписи — власть решения. Детерминированный CBOR решает точную задачу: независимые кодировщики получают одну последовательность. Никаких иных полномочий этот результат не несёт.

Источники