Кратко

  • draft-templeman-scitt-framing-space-00 объявлен 5 сентября 2026 года как индивидуальный Informational Internet-Draft. Это не RFC, не консенсус IETF и не проект нормативных требований.
  • Из шести двоичных свобод CBOR получились 64 принятые последовательности и 64 разных data-hash. Все восстановили один Sig_structure и прошли одну и ту же проверку подписи.
  • 31 вход после чтения и повторного кодирования без предупреждения превратился в каноническую форму A. Сервис, который сохранил только новую выдачу, может потерять preimage собственного опубликованного ID.

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

Именно эту тихую границу измеряет проект Николаса Темплмана. Объявление I-D от 5 сентября фиксирует появление документа. Автор подчёркивает, что ничего не специфицирует и не предлагает формулировок. Это воспроизводимый вклад в текущую работу SCITT, а не решение IETF.

Подпись защищает не всё внешнее представление

По RFC 9052 подпись COSE вычисляется для Sig_structure. В случае COSE_Sign1 туда входят контекст, защищённые параметры, внешние аутентифицированные данные и payload. Не каждый выбор оформления внешнего CBOR-контейнера попадает в этот вход.

RFC 8949 допускает несколько сериализаций одной модели данных. Array и map могут иметь определённую или неопределённую длину, byte string может идти целиком или chunks, а подходящий profile может принять форму с tag или без него. Decoder получает то же значение, хотя по сети прошли другие октеты.

Исходный COSE_Sign1 A имеет длину 165 октетов. Опыт меняет наличие tag 18, форму длины внешнего array и карты незащищённого header, а также цельную или фрагментированную передачу protected header, payload и signature.

64 комбинации занимают от 164 до 170 октетов. cbor2 6.1.3 принял все. Каждая восстановила один 109-октетный Sig_structure, поэтому одна подпись оставалась действительной.

SHA-256 от переданных байтов дал 64 разных data-hash без коллизий. Криптографические примитивы не подвели: у hash разные входы, у signature вход один. Опасно лишь объединить эти два вывода в общий зелёный статус.

Тридцать один тихий переход

В 31 случае цикл decode и re-encode вернул точные канонические байты A. Ни отказа, ни предупреждения. Обычное приведение формата способно удалить свидетельство исходной передачи.

Если принимающий сервис сначала возвращает клиенту hash исходных bytes, а в очередь отправляет только parsed value, последующие уровни могут никогда не увидеть оригинал. База сохранит предпочтительную сериализацию своей библиотеки. При аудите сервис посчитает hash собственного представления вместо принятого.

Последствия выходят наружу, если data-hash служит ключом lookup, deduplication, registration, receipt или предметом следующей attestation. Одинаковое подписанное содержание может занять две практические позиции или казаться отсутствующим. Влияние на framing меняет координату без подделки подписи и изменения payload.

Набор framing-space публикует метод и результаты, а data-hash vector содержит исходные байты. Указаны версия decoder и платформа; одна ось отдельно пересчитана другим reader без COSE-библиотеки.

Это подтверждает механизм, но не распространённость. Ширина integer и порядок map keys не менялись, поэтому 64 — не верхняя граница. Документ не доказывает дефект конкретного развёрнутого сервиса.

Сохранять нужно до интерпретации

Запрет отдельных известных форм не закрывает комбинационное пространство. Запрет формы без tag оставляет варианты длины и chunks. Полной должна быть не чёрная таблица примеров, а граница preimage.

Если ID означает «как передано», принимающий сервис обязан неизменно сохранить полный body до parser, проверки формата и object mapping. Hash вычисляется по этой копии и связывается с названной byte production. Parsed и normalized формы хранятся как производные и никогда не заменяют доказательство.

Протокол может выбрать единственную deterministic serialization и отклонять прочие. Section 4.2 RFC 8949 даёт основу. Но предпочтение encoder ещё не означает, что decoder проверил вход на соответствие такой политике.

Предшествующий проект as-transmitted не применяет canonicalization и требует selector точной именованной последовательности формата. Это также индивидуальный проект. Новое измерение объясняет практическую ценность границы, но не придаёт предложению статус стандарта.

Идентичность, подпись, включение и полномочие — разные квитанции

RFC 9943 разделяет в SCITT Signed Statement, Transparency Service, Receipt и последующую оценку. Проекты SCITT Reference APIs и CCF receipt profile показывают, почему data-hash становится реальной координатой регистрации и получения.

Однако каждый результат говорит только за свой слой. Raw bytes показывают, что принял компонент. Valid signature подтверждает целостность Sig_structure под ключом; принадлежность ключа и полномочие проверяет приложение. Receipt подтверждает включение по правилам сервиса, а не истинность, свежесть или допустимость применения содержания.

Принцип Хэн Лу — описывать реальность, а не адвокацию — не требует назначать виновного. Толерантный decoder и нормализующий encoder могут работать правильно. Системная ошибка возникает, когда их результаты считают одним доказательством.

Приоритет работающего кода требует провести vectors через реальные gateway, queue, database и retrieval API. Различие между технической возможностью и полномочием не позволяет способности библиотеки перекодировать данные стать правом переименовать опубликованное свидетельство.

Canonicalization и wire hash решают разные задачи. Руководству нужно выбрать, какую реальность называет ID, а затем не уничтожить материал, способный её воспроизвести.

Sources