Кратко

  • RFC 2015 применила multipart/signed: читаемая MIME-сущность оставалась первой частью, отделённая подпись PGP — второй, а заголовки содержимого входили в подписываемые данные.
  • Семибитная форма, CRLF, транспортное кодирование, строки From и конечные пробелы стали частью границы доказательства, поскольку шлюзы могли их менять.
  • Успешная проверка связывает байты, подпись и ключ; личность, полномочия, намерение, доставка и результат требуют отдельных подтверждений.

Архитектура исправляла недостаток ранней формы application/pgp: ради извлечения подписанного текста программе могло потребоваться разбирать внутренние структуры PGP. RFC 1847 определила нейтральный контейнер безопасности ровно из двух частей. RFC 2015 поместила подписываемую MIME-сущность в первую, а application/pgp-signature — во вторую. MIME-клиент мог найти содержимое, даже не умея проверять PGP.

Читаемость первой части не давала права редактировать её по пути. Для текста отправитель выбирал представление, приводил окончания строк к CRLF, применял Content-Transfer-Encoding, добавлял заголовки содержимого и лишь затем подписывал заголовки вместе с кодированными данными. Заголовки защищались потому, что смена типа или кодировки меняет толкование тех же байтов.

Семибитное наследие SMTP сделало порядок операций критическим. Перед следующим узлом без поддержки восьми битов шлюз мог преобразовать письмо в Quoted-Printable или Base64. Доставка становилась возможной, но вход хеш-функции после подписи менялся. Поэтому безопасное для транспорта представление следовало создать и подписать заранее.

В примере RFC 2015 уязвимыми оказались обыденные детали. Программа почтового ящика могла поставить > перед строкой, начинающейся с From , а иной шлюз — удалить пробелы в конце. RFC 3156 позднее уточнила восстановление CRLF, защиту пробелов и границу последней строки. На экране текст не менялся, но криптографическая запись становилась другой.

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

RFC 2480 описала выбор шлюза при переходе в среду без MIME. Он должен уметь туннелировать защищённый multipart без изменений. Он также мог разобрать multipart/signed, чтобы показать содержимое, зная, что проверяемость будет потеряна; тогда подпись следовало сохранить и снабдить предупреждением. Проверка или новая подпись на шлюзе создавали нового хранителя ключей и новую точку доверия, поэтому не должны были включаться по умолчанию.

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

Главное наследие RFC 2015 предшествует криптографии: сначала инфраструктура должна зафиксировать представление, которое посредникам больше нельзя улучшать.

Источники