Кратко

  • Сводка RFC 9787 учитывает лишь непрерывные слои подписи и шифрования вокруг Crypto Payload.
  • Корректная вложенная подпись, расшифрованный фрагмент или пересланное письмо имеют локальный результат, но не повышают статус внешнего сообщения.
  • Ответ, вложение и позднее чтение архива — новые действия, которым нужны собственные доказательства и полномочия.

Статус принадлежит структуре, а не экрану

RFC 9787 называет криптографическим конвертом непрерывную последовательность защитных слоёв вокруг Crypto Payload. Только она формирует единую сводку. Криптографический слой в другой ветви MIME-дерева является errant относительно этого конверта и не участвует в верхнем результате.

OpenPGP/MIME, S/MIME и основа MIME задают структуру, но не распространяют полномочия по визуальной близости. Внутренняя подпись может пройти проверку, не подписывая внешнее вступление, подвал списка или соседний файл.

Список рассылки может обернуть подписанное сообщение и добавить подвал. Подпись остаётся действительной для внутренней части, но становится errant для нового объекта, полученного подписчиком. Верхняя сводка должна быть «не защищено». MUA вправе отдельно объяснить внутренний результат, но не утверждать, что подписано всё полученное письмо.

Расшифровка не разрешает монтаж

Клиент может расшифровать errant-часть для просмотра. Открытый текст должен остаться отдельным MIME-поддеревом: его нельзя вставлять в окружающий HTML, который может контролировать атакующий, и нельзя называть всё письмо зашифрованным. Исследования EFAIL и multipart-oracle показывают, почему локальная расшифровка и безопасная композиция — разные полномочия.

Inline OpenPGP вне MIME-модели не даёт валидирующую подпись сводке, даже используя формат RFC 9580. Расшифрованный текст нельзя незаметно переносить в цитату ответа.

Пересылка и ответ создают новый объект

Пересланный message/rfc822 или message/global в рамках RFC 5322 и RFC 6532 может иметь собственный конверт. Его сводка и сводка внешнего письма должны быть визуально привязаны к разным объектам.

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

Файл и срок действия требуют отдельных свидетельств

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

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

RFC 9788 относится к соседней теме защиты заголовков и здесь не пересказывается. Карточка RFC, Datatracker и поиск errata подтверждают документальный статус, но не реализацию продукта.