Кратко

  • RFC 9690 прямо говорит: rsaEncryption не сообщает, что владелец ключа согласен принимать RSA-KEM; для этого нужна отдельная ограниченная запись.
  • Решение об отправке должно связать сертификат, источник и возраст объявления, две позиции KDF, длину KEK, wrap-алгоритм и тип CMS-контента.

Ошибка возникает до шифрования. Реестр видит RSA-ключ, успешную проверку цепочки и допустимую длину модуля. Следующий сервис превращает это в флаг «RSA-KEM доступен». Но первая запись относится к ключу, а вторая уже говорит от имени программного обеспечения и политики получателя.

RFC 9690 запрещает такой переход: OID rsaEncryption не показывает готовность принимать RSA-KEM. Сертификат может оставаться действительным, когда механизм выключен, тип CMS не поддерживается или разрешён другой набор компонентов.

У RSA-KEM есть внутренняя KDF: из свежего случайного z получается общий секрет. Затем KEMRecipientInfo применяет ещё одну KDF, чтобы получить KEK для разворачивания ключа контента. Эти KDF могут различаться. KDF3/SHA-256 и AES-Wrap-128 — обязательный минимум, а не полное описание возможностей.

Частичное объявление надо датировать

Получатель может сообщить о RSA-KEM через SMIMECapabilities в signed-data по RFC 8551 или через расширение сертификата из RFC 4262. Это лучше догадки по форме ключа, но список частичный. Старое подписанное сообщение фиксирует прежнее объявление, а не сегодняшнее состояние endpoint.

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

Для ключа только под RSA-KEM используется id-rsa-kem-spki. Без параметров внутренняя функция — KDF3/SHA-256. С параметрами GenericHybridParameters ограничивают KDF, длину KEK и wrap в KEMRecipientInfo. Если есть keyUsage, допустим лишь keyEncipherment. Назначение стало точнее, но владение закрытым ключом и успешная декапсуляция ещё не доказаны.

Совместимость не стирает выбор формата

RFC 5990 использовала KeyTransRecipientInfo и соединяла C с WK. RFC 9690 переходит к общей структуре RFC 9629, разделяя kemct и encryptedKey. Обратная совместимость полезна, но маршрут RFC 5990 и маршрут RFC 9690 должны оставаться различимыми.

Журнал называет выбранную спецификацию, сертификат, объявление и точный набор. У получателя отдельно фиксируются проверка длины и диапазона ciphertext, операция закрытого ключа, derivation общего секрета и KEK, unwrap, обработка контента и решение приложения. Успешная сборка у отправителя не доказывает удалённый результат.

Квитанция с конечным сроком

В неё входят отпечаток и решение по цепочке; AlgorithmIdentifier и исходные параметры; keyUsage; источник, подписант и возраст возможности; внутренняя и CMS KDF; длина KEK; wrap; тип контента; выбранная ветвь совместимости.

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

RFC 8017, RFC 3394, RFC 4086 и RFC 5280 задают RSA, wrap, случайность и сертификаты. Они не наблюдают живую обработку у адресата.

Минимальная начальная спецификация Lu Heng поддерживает узкий общий уровень и явные локальные дальнейшие решения. Модель слоёв реальности не позволяет сертификату, объявлению, структуре, закрытому вычислению и бизнес-решению заменять друг друга. Приоритет running code оставляет последнее слово фактическому процессу получателя.

Источники