Кратко
- В опубликованной 23 сентября редакции -05 профиля CCF для квитанций COSE появились два запроса на регистрацию типов доказательств.
- В редакции -04 был лишь запрос на алгоритм. Теперь для
CCF_LEDGER_SHA256предлагается значение 2, а для этой структуры — метки -1 для включения и -2 для согласованности. - Публичные таблицы IANA пока содержат только структуру 1 и её доказательства. Обновлённый проект находится на повторной проверке, а не в состоянии утверждённой регистрации.
Представим реализацию, которая получила квитанцию с числовым обозначением структуры данных. Одного числа недостаточно: ей ещё нужно определить, какой именно тип доказательства перед ней и по каким правилам его разобрать. В предыдущем варианте проекта IETF SCITT для реестра CCF эта вторая часть отсутствовала в запросе к IANA. В замечании от 12 сентября эксперт указал, что алгоритм предлагается зарегистрировать без соответствующих типов доказательств. Редакция от 23 сентября исправляет именно эту документальную неполноту.
У IANA здесь два разных реестра. В первом авторы просят значение 2 для алгоритма проверяемой структуры CCF_LEDGER_SHA256. Во втором они просят записи для доказательства включения с меткой -1 и доказательства согласованности с меткой -2, привязанные к этой структуре. Отрицательные метки сами по себе не являются глобальным названием формата: сегодня те же -1 и -2 уже зарегистрированы для структуры 1, RFC9162_SHA256. Поэтому проверяющая программа должна учитывать пару «структура — тип доказательства», а не переносить существующее значение метки на CCF.
Проект также уточняет, где искать эти сведения в квитанции. Защищённый заголовок vds называет структуру, а отображение vdp в незащищённом заголовке группирует доказательства по типу. Это соответствует конструкции COSE-квитанций из RFC 9942. В -05 приведены процедуры проверки включения и согласованности. Но описание предлагаемого формата не говорит, что он уже внедрён конкретным оператором, и не делает черновик опубликованным RFC.
Хронология процедуры особенно важна. До обновления документ имел статус IANA - Not OK. После загрузки -05 он сменился на Version Changed - Review Needed; отображаемое состояние экспертной проверки всё ещё говорит Issues identified. В действующих таблицах COSE нет записей CCF. Сам текст использует для числа 2 формулировку «запрошенное назначение» и временное обозначение до распределения. Следовательно, регистрационная работа продвинулась на уровне предложения, но не завершилась в публичном реестре.
Даже после завершения регистрации останется отдельный вопрос о силе доказательства. Для проверки согласованности документ требует сравнить вычисленный старый корень с корнем, который проверяющая сторона подтвердила ранее; корень, присланный вместе с квитанцией, независимой опорой не служит. Доказательство согласованности не удостоверяет содержание журнала само по себе и не гарантирует соблюдения политики регистрации. Исправление двух строк реестра обеспечивает общий технический язык, а не универсальное одобрение поведения сервиса.
Источники
- https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/05/
- https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/04/
- https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/history/
- https://www.iana.org/assignments/cose
- https://www.rfc-editor.org/rfc/rfc9942.html
- https://www.rfc-editor.org/rfc/rfc9943.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

