Кратко

  • Редакция 03 проекта рабочей группы LAMPS, опубликованная 14 сентября, в случае принятия обновит RFC 5652 и запретит id-data в новых применениях CMS SignedData.
  • Новым считается применение, для которого спецификация впервые определяет создание или обработку SignedData с даты будущей публикации документа, а не с момента разработки или развёртывания программы.
  • Для существующих применений предусмотрены рекомендации по миграции и проверке, а не тот же абсолютный запрет: резкая смена правила может нарушить совместимость с работающими отправителями.
  • Это активный Internet-Draft с предполагаемым статусом Best Current Practice, а не RFC, не принятое правило, не свидетельство эксплуатации и не доказательство уязвимости какого-либо продукта.

Граница, дата которой ещё не наступила

Редакция 03 добавляет важное положение в заголовок и аннотацию. В случае одобрения она обновит RFC 5652, действующий стандарт Cryptographic Message Syntax: новые применения CMS SignedData не должны использовать тип содержимого id-data.

Область действия задаёт новое определение. Применение является новым, если спецификация, опубликованная в дату выхода будущего документа или позднее, впервые описывает, как SignedData создаётся или обрабатывается для конкретного приложения. Неважно, имеет ли последующая спецификация статус RFC и регистрирует ли она идентификатор типа содержимого в IANA. Всё, что предшествует дате публикации, относится к существующим применениям.

Формальная черта ясна, но пока она только перспективная. Запись Datatracker показывает активный документ рабочей группы с предполагаемым статусом BCP. RFC 2026 прямо называет Internet-Drafts рабочими документами. Редакция 03 уже может направлять обсуждение, но одна её загрузка не изменяет STD 70.

Время спецификации и время развёртывания — не одно и то же

Официальное сравнение редакций вводит две шкалы, которые нельзя незаметно слить.

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

Проект не публикует реестр, который связывает эти состояния, и не заявляет обратного. В приложениях перечислены RFC, использующие id-data, и рассмотрена применимость, но ссылка на RFC не измеряет установленную базу. Строка в реестре IANA устанавливает идентификатор и источник, но не показывает, какой путь кода принимает сообщение, проверяет ли получатель signedAttrs и используется ли один ключ подписи в разных протоколах.

Вопрос безопасности зависит именно от поведения. RFC 5652 допускает отсутствие signedAttrs, когда инкапсулированный тип — id-data. Проект объясняет, как в таком случае может пройти проверку подпись над структурой, которую подписывающая сторона явно не намеревалась заверять. Одновременно названы ограничения: отдельные протоколы требуют подписанных атрибутов; корректная проверка получателем может остановить атаку; структура сообщения способна сузить применимость; существуют и другие меры. Поэтому «существующее» не значит «уязвимое», а «новое» не подтверждает безопасность реализации.

Совместимость входит в само правило

Для нового применения редакция 03 устанавливает: id-data MUST NOT использоваться. Если задействован MIME, предложенный тип mimeData SHOULD применяться, если только нет обоснования для более специализированного типа. Проект запрашивает у IANA идентификаторы модулей и типов содержимого, но значения пока отмечены как TBD. Действующие реестры SMI Numbers и CMS Inner Content Types не превращают место для будущего номера в уже состоявшееся назначение.

Существующим применениям предложен иной путь. При обновлении такого протокола следует отказаться от id-data. Если новая редакция сохраняет тип, проект просит объяснить решение, чтобы участники могли оценить компромисс безопасности. Обратно совместимое расширение может оказаться неподходящим моментом для принудительного разрыва; крупная версия или иное заранее несовместимое изменение может дать разумное окно миграции.

Это не спрятанная лазейка, а явная оценка совместимости. Развёрнутые отправители могут не создавать signedAttrs так, как требует более строгая норма. Универсальное MUST рискует заставить новых получателей отвергать легитимный старый трафик до появления пути миграции. Проблема управления не в самом наличии усмотрения, а в отсутствии общего ответа: где оно применено, на каких данных и до какого следующего решения.

Ключи, библиотеки и приложения расширяют контур контроля

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

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

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

Реестр перехода вместо общего вердикта

Краткий публичный реестр сделал бы границу проверяемой. Для каждого известного применения CMS SignedData в нём можно фиксировать: первую спецификацию и дату; тип содержимого и правило signedAttrs; класс свидетельств о развёртывании без выдуманной численности; возможное повторное использование ключа между протоколами или версиями; ближайшее реалистичное окно несовместимого изменения; причину сохранить или заменить id-data; владельца спецификации, дату следующего обзора и историю исправлений.

Такой реестр предлагает Daniel Kade; проект его не требует. Он не объявлял бы все старые применения небезопасными. Он позволил бы отличить старую спецификацию с обязательной проверкой от старого развёртывания с неизвестным поведением и от новой спецификации, подпадающей под перспективное правило.

Дата публикации может остаться формальной чертой. Реестр даст операционную карту вокруг неё.

Источники