Кратко

  • RFC 3058 назначил разные идентификаторы и правила параметров для шифрования содержимого IDEA и обёртки ключей IDEA. Представление стало точным, но поддержка осталась необязательной, а контекст по-прежнему определял отсутствие параметров, NULL либо восьмиоктетный IV.
  • Подписанная возможность S/MIME была упорядоченным заявлением клиента, а не квитанцией исполнения. Реальное применение всё ещё зависело от обеих сторон, локальных предпочтений, частных соглашений, правовых ограничений, доступа к ключам, успешной развёртки и обработки содержимого.

Одного имени недостаточно для двух задач

Криптографические программы не могут взаимодействовать по фразе «использовать IDEA». CMS-сообщению нужны идентификатор, параметры и место каждого значения. Кроме того, надо отделить алгоритм защиты содержимого от алгоритма защиты ключа этого содержимого. Опубликованный в феврале 2001 года как Informational RFC 3058 дал такую точность.

Один OID называл IDEA-CBC для содержимого, второй — обёртку ключа IDEA. Первый работал со 128-битным секретным ключом и 64-битными блоками. Второй принимал 16-октетный ключ содержимого, присоединял восьмиоктетную проверку и выдавал 32 октета. Фраза «поддерживает IDEA» стирала две разные функции.

OID находились в частной корпоративной ветви, связанной с Ascom. Их ценность — координация независимых реализаций. Регистрация не означала наличия кода в каждом S/MIME-клиенте, разрешения каждому пользователю или доставки сообщения человеку. Она сделала выбор читаемым, но не доступным.

Отсутствие, NULL и IV — не одно и то же

Идентификатор содержимого допускал IDEA-CBCPar с необязательным IV ровно в восемь октетов. Если IV присутствовал в параметрах, его использовали там и не помещали в начало шифротекста. Если параметра не было, первые 64 бита шифротекста считались IV, хотя RFC не рекомендовал эту форму в CMS и S/MIME.

Для обёртки действовало другое правило: параметр обязан быть NULL. В двух объявлениях возможностей действовало третье: параметр обязан отсутствовать. В неточном описании всё выглядит как «ничего», но в ASN.1 это разные байты и инструкции.

Здесь находится тихий центр документа. Идентификатор становится полной инструкцией только вместе с контекстом и соглашением о параметрах. Парсер, подменяющий отсутствие на NULL, может отвергнуть правильную структуру или принять несогласованную семантику. Панель, сохраняющая одно слово IDEA, теряет доказательства для воспроизведения сообщения.

Errata 5913, удерживаемая для будущего обновления, подчёркивает границу: символ ASN.1 IDEA-CBC следует заменить на начинающийся строчной буквой id-IDEA-CBC, не меняя числовой OID. Человеческое имя, идентификатор в исходном ASN.1 и зарегистрированное число связаны, но не тождественны.

Внутри случайность, снаружи константа

Обёртка была расписана по шагам. К 16-октетному ключу добавлялась восьмиоктетная проверка. Случайный восьмиоктетный IV шифровал эти 24 октета через IDEA-CBC. Затем IV ставился впереди, все 32 октета переворачивались и снова шифровались с постоянным внешним IV 4adda22c79e82105. Обратная операция отвергала несовпавшую проверку.

Постоянный внешний IV легко неверно понять отдельно от схемы: свежий внутренний IV никуда не исчезал. И наоборот, случайность и совпавшая проверка не доказывали авторизацию, предпочтение получателя или полезность текста. Проверка отвечала лишь на узкий вопрос об извлечённом ключе.

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

Подписанная, упорядоченная и неполная возможность

Клиент мог публиковать SMIMECapabilities как подписанный атрибут. RFC 3058 дал точные DER-байты для IDEA-CBC и обёртки в разных категориях; порядок мог выражать предпочтение. Последующие спецификации продолжили считать список частичным, а не полным инвентарём.

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

RFC оставил выбор вне регистра. Он назвал полученные возможности, частные соглашения, пользовательские предпочтения и юридические ограничения. Если пользователь требовал IDEA, оба клиента должны были поддерживать её, а предпочтение — быть задано. OID устранял неоднозначность байтов, но не осуществлял эти полномочия.

Лицензия оставалась рядом с форматом

Историческое уведомление говорило, что Ascom владела патентами, предлагала неисключительные лицензии на разумных и недискриминационных условиях и разрешала бесплатное некоммерческое использование. Это свидетельство границы, показанной в 2001 году, а не современная юридическая консультация. Стандартизация не стирала заявленный тогда лицензионный слой.

Реализация могла распознавать OID и не содержать алгоритма. Разработчик мог иметь код, а организация — не принять условия. Получатель мог объявить возможность, а политика отправителя выбрать другое. Техническая регистрация не забирала эти решения.

RFC 3370 отделил соглашения об алгоритмах от ядра CMS; RFC 5652 определил более поздний CMS; RFC 8551 назначил уровни AES и ChaCha20-Poly1305, сохранив возможности и внешние решения. Эта история не доказывает внедрение IDEA, а отсутствие в новом обязательном списке не удаляет её OID.

Долговечный урок — не победа или поражение IDEA. Стандарт может сделать решение воспроизводимым, не делая его всеобщим. Число идентифицирует, параметры объясняют чтение, подписанная возможность связывает заявление с субъектом, политика и право ограничивают выбор. Только реальный обмен показывает завершение работы обеими сторонами.

Источники

Lu Heng не писал и не утверждал RFC 3058. Его эссе используются только как раскрытая аналитическая линза, отделяющая символическую регистрацию от исполняемого поведения.