Кратко

  • RFC 3185 позволял использовать CEK первого CMS-объекта для получения KEK последующих объектов, уменьшая асимметрические операции и создавая долговременное состояние.
  • Если множество S1 получило первую CEK, все его участники могли расшифровать MSG2, даже когда новый объект называл лишь подмножество. Верная ссылка не доказывала отправителя или отсутствие повтора.

Reuse of CMS Content Encryption Keys вышел в октябре 2001 года в Standards Track и числится Proposed Standard. Механизм предназначался для отдельных зашифрованных полей одной транзакции и частого обмена между серверами, где повторное асимметрическое установление ключа было дорого.

Это не был полный протокол или общая система групповых ключей. Внешний контекст должен был определить потерю состояния и ошибки. API обязан был позволять преобразование материала, а алгоритмы CEK и KEK — иметь совместимые форматы и силу.

MSG1 помещал CEKReference в незащищённые атрибуты. MSG2 повторял значение как KEKIdentifier. Ссылка находила сохранённую CEK; она не была секретом. Из CEK выводилась KEK для развёртывания новой CEK.

При совместимых форматах байты обращались, чтобы предотвратить конкретное использование известного блока. Для разных форматов предусматривался PBKDF2. Это исторический алгоритмический контекст, а не доказательство современной реализации.

Ключевой пример: MSG1 отправлен S1, MSG2 — только части S1. Все S1 всё равно имеют старую CEK и могут вывести KEK. Новая запись выражает намерение, прошлая доставка — способность. Исключение из списка не отзывает выданный секрет.

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

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

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

История показывает: доказательство расшифрования уже, чем публичное утверждение «сообщение подлинное и предназначено только этим людям». Для второго нужны отдельные записи о доставке, аутентификации, повторе и хранении.