Кратко

  • RFC 3657 назначил разные идентификаторы CMS для шифрования содержимого Camellia и обёртывания ключа. Для CBC-шифрования содержимого требуется присутствующий IV длиной 16 октетов; у идентификатора алгоритма обёртывания параметры должны отсутствовать.
  • В объявлении возможностей S/MIME используется третья форма — параметр NULL. OID обёртывания указывает длину ключа шифрования ключей (KEK), а не обязательно длину обёрнутого ключа содержимого (CEK).

Одно имя — ещё не одна операция

В CMS-конверте слова «Camellia» недостаточно, чтобы определить, что именно сделал отправитель. Получатель должен различить шифрование содержимого и обёртывание ключа шифрования содержимого (CEK), а затем истолковать идентификатор алгоритма с учётом этой роли. RFC 3657 опубликован в январе 2004 года как документ Standards Track и задаёт две группы идентификаторов Camellia для CMS: одну для CBC-шифрования содержимого, другую для обёртывания ключей. RFC 3657

Разница видна в параметрах. Для id-camellia128-cbc, id-camellia192-cbc и id-camellia256-cbc поле параметров AlgorithmIdentifier ДОЛЖНО присутствовать и содержать вектор инициализации длиной 16 октетов. IV входит в описание шифрования содержимого; его нельзя вывести из названия алгоритма. Для дополнения открытого текста RFC также отсылает к правилу CMS. RFC 3657 RFC 5652

При обёртывании ключа правило обратное. Три OID Camellia для обёртывания содержат ветви с размером ключа, но параметры их AlgorithmIdentifier ДОЛЖНЫ отсутствовать. Способ обёртывания сам определяет использование внутреннего начального значения, поэтому это поле не переносит IV. Размер, указанный в OID, относится к ключу шифрования ключей (KEK), а не гарантирует такой же размер у обёрнутого CEK. Реализации ДОЛЖНЫ поддерживать равные длины KEK и CEK; если поддерживаются разные длины, KEK ДОЛЖЕН быть не короче CEK. Значит, RFC задаёт границу кодирования и совместимости, но не требует одного размера всех ключей в конверте. RFC 3657 RFC 3394

Для объявления поддержки действует третья кодировка

RFC 3657 также описывает, как клиент S/MIME объявляет поддержку Camellia в SMIMECapabilities. К OID возможности добавляется параметр NULL. Это не противоречит отсутствию параметров у идентификатора обёртывания: речь о разных структурах ASN.1 с разным назначением. В передаваемой кодировке NULL также не равен отсутствующему параметру. RFC приводит DER-представления для всех трёх размеров ключа, чтобы объявленную форму можно было точно сверить. RFC 3657 RFC 2633

Список возможностей подписан и упорядочен по предпочтению, но показывает лишь часть поддерживаемых отправителем функций. Он служит входным сигналом для последующего выбора наряду с частными соглашениями, пожеланиями пользователя и правовыми ограничениями. Это не согласование в реальном времени, не тест текущей конфигурации получателя и не доказательство, что конкретное сообщение было зашифровано Camellia. Чтобы установить выбранную операцию, нужно читать поля шифрования содержимого и управления ключами в самом конверте, а не только прежнее объявление возможностей. RFC 3657

Совместимость зависит от разделения контекстов

Проверка взаимодействия должна сопоставлять три контекста отдельно. Для CBC-шифрования содержимого — идентификатор, размер ключа и наличие IV из 16 октетов. Для обёртывания — отсутствие параметров и соответствие фактических длин KEK и CEK заявленной поддержке реализации. Для возможностей — подписанное DER-значение, включая NULL, и порядок предпочтения. Если смешать контексты, системы могут по-разному разбирать или выбирать параметры, хотя каждая заявляет поддержку одного и того же шифра.

RFC 3657 предписывает для Camellia обёртывание по конструкции RFC 3394, заменив AES на Camellia; размер блока у обоих алгоритмов — 128 бит. Значение проверки целостности по умолчанию — константа A6A6A6A6A6A6A6A6. Если при развёртывании не восстановлено это значение, получатель возвращает ошибку и не выдаёт данные ключа. RFC допускает альтернативные начальные значения для приложений с иным требуемым охватом целостности. Эта проверка относится к обёрнутым данным ключа в описанной конструкции; она не подтверждает отправителя, происхождение содержимого CMS или право пользователя действовать на основании расшифрованных данных. RFC 3657 RFC 3394

Это историческая реконструкция контракта кодирования, а не современная рекомендация по безопасности и не оценка распространённости. Реестр алгоритмов CMS и более поздние профили дают контекст, но не показывают, какие продукты реализовали RFC 3657 и насколько часто. Более узкий вывод таков: идентификатор алгоритма — типизированное поле протокола. OID, наличие параметров и внешнюю структуру нужно читать вместе. RFC 3370 RFC 8419

Источники