Кратко

  • 25 сентября сопредседатель SCITT объявила официальный сбор мнений о принятии индивидуального проекта квитанций COSE для Merkle Mountain Range; ответы ожидаются до 9 октября.
  • Июльский опрос участников IETF 126 касался готовности рецензировать проект, а не его принятия рабочей группой.
  • RFC 9942 задаёт общую оболочку квитанции, но прямо предупреждает: разные проверяемые структуры данных не становятся взаимозаменяемыми.

Слова «поддержка квитанций COSE» слишком широки для практического выбора проверяющего ПО. Программа может разобрать контейнер и при этом не уметь восстановить корень дерева по доказательству MMR. Именно этот разрыв делает значимым процедурное сообщение SCITT от 25 сентября. Группа спрашивает, стоит ли принять draft-bryce-cose-receipts-mmr-profile-03 как основу дальнейшей совместной работы.

В письме предложено сообщить позицию и её основания, а также готовность рецензировать, дорабатывать или реализовать документ. Сопредседатель отдельно оговаривает: даже принятие не будет означать завершения текста либо готовности к публикации. Девятое октября — срок для откликов, не обещанная дата решения по стандарту. В Datatracker редакция -03 по-прежнему числится активным индивидуальным Internet-Draft без официального одобрения IETF.

Июльское заседание не следует превращать в скрытое голосование. В протоколе IETF 126 сказано, что из 34 присутствовавших четверо согласились участвовать в рецензировании, никто не ответил отказом и трое не высказали мнения. Вопрос был о рецензировании. Председатели тогда обещали продолжить процедуру в рассылке; нынешний открытый сбор мнений и есть новый этап, а не оформление уже принятой спецификации.

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

RFC 9942 стандартизовала общий механизм квитанций, но не унифицировала все возможные проверяемые структуры. Она прямо предостерегает от ожидания совместимости между ними. У SCITT уже есть отдельный рабочий проект профиля CCF. Если MMR-проект будет принят, группа получит ещё одну специализированную область работы, а пользователи — ещё один набор правил для явной проверки. Проект также не приписывает доказательству включения оценку законности записи или способность найти то, что в реестр так и не внесли.

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

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

Источники