Кратко

  • RFC 1421 поместил Privacy Enhanced Mail на конечные узлы, поэтому действующие SMTP-ретрансляторы могли переносить защищённый объект, ничего не зная о криптографии. Под защитой находилось вложенное тело, а не вся внешняя история письма.
  • MIC-CLEAR сохранял аутентификацию и целостность MIC-ONLY, но отказывался от печатного кодирования, которое ограждало подписанный текст от некоторых преобразований транспорта. Получатель без PEM мог читать, но не мог проверить подпись.
  • MIC вычислялся над каноническим ASCII-представлением со строками CRLF. Обычная смена конца строки или экранирование при пересылке могла дать несовпадение, поэтому факт ошибки, её причина и статус события безопасности требовали отдельных выводов.

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

Текст появлялся в локальном формате пользовательского агента. Затем Message Transfer Agents принимали его, передавали дальше и доставляли. Шлюз мог увести письмо в другую среду, а пересылка — заключить исходное сообщение в новую оболочку. Узлы расходились в наборах символов и окончаниях строк. Если бы новый формат требовал понимания на каждом участке, локальное внедрение зависело бы от глобальной модернизации.

RFC 1421 провёл границу на уровне User Agent или выше. Отправитель преобразовывал тело до передачи обычной почте; получатель выполнял обратные операции и проверку после доставки. Промежуточный SMTP оставался прежним SMTP. Организация могла включить PEM на своих краях, не получая разрешения от всех операторов маршрута.

Такая свобода держалась на узкой области защиты. Поля, которые ретрансляторы добавляли или преобразовывали между компонентами PEM, под privacy enhancement не попадали. Внешнее письмо было переносчиком вложенного объекта, но не становилось частью его подписи. Конверт, маршрут и служебные следы сохраняли собственное происхождение.

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

Новая функция на старом общем пути

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

Участники получили разные стимулы. Операторы ретрансляторов сохраняли оборудование и процессы. Разработчики на краях могли начинать самостоятельно. Зато отправителю требовалось знать, способен ли адресат обратить выбранные преобразования. Управление ключами и совместимость процедур не следовали из существования адреса.

Положительный ответ на RCPT TO означал лишь, что транспортный узел принял очередную ответственность. Он ничего не сообщал о программе PEM, ключе или полномочиях конечного пользователя. Принятие к доставке и готовность к проверке — разные состояния.

Сам стандарт перечислял задачи, которых не решал: управление доступом, сокрытие потока трафика, точность списка адресов, контроль маршрута, гарантированное или неоспоримое получение, сопоставление подтверждений, обнаружение дублей и защиту от повторного воспроизведения. Валидный MIC не заполнял эти пробелы.

Подпись относилась к байтам, а не к впечатлению

Началом служила локальная форма конкретного компьютера. RFC 1421 приводил её к общей модели inter-SMTP: ASCII и окончания строк CRLF. Точечное экранирование, необходимое для прозрачности SMTP, в канонический объект не входило.

Message Integrity Check рассчитывался именно по этим байтам. При выборе конфиденциальности шифрование тоже начиналось с них. Общая последовательность была выражена как Encode(Encrypt(Canonicalize(Local_Form))), причём ненужные для типа сообщения операции опускались. На принимающей стороне соответствующие действия обращались, и лишь затем текст переводился в местную форму.

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

RFC 822 описывал сообщение как поля и необязательное ASCII-тело, состоящее из строк. RFC 821 задавал SMTP-команду DATA и прозрачность. PEM использовал уже распространённую строковую дисциплину как общую модель, не выдавая промежуточную каноническую форму за наблюдавшуюся SMTP-транзакцию.

Три формата покупали совместимость по разной цене

ENCRYPTED давал конфиденциальность вместе с аутентификацией и целостностью. Каноническое тело шифровалось, затем представлялось ограниченным печатным алфавитом, рассчитанным на неоднородные почтовые пути.

MIC-ONLY убирал секретность, но не превращался в обычную видимую прозу. Печатное кодирование оставалось и защищало подписанное представление от класса изменений в Message Transfer System. Получателю требовался PEM, чтобы восстановить тело и проверить MIC.

MIC-CLEAR выбирал те же услуги целостности и аутентификации, но пропускал стадию печатного кодирования. Это было его предложение совместимости. Программа без PEM показывала человеку понятный текст, однако не давала средства подтвердить подпись.

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

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

Несовпадение было фактом, но не готовым обвинением

Печатное кодирование MIC-ONLY ограждало подписанное содержимое от определённых переписываний в Message Transfer System. MIC-CLEAR предпочитал непосредственную читаемость. Его MIC можно было проверить, только если MTS не изменил тело или если изменения удавалось распознать и обратить.

Простейший пример — окончания строк. SMTP использовал CRLF, однако принимающая система могла заранее преобразовать их в местный вариант. Проверяющий должен был вновь канонизировать доставленный текст, реконструировать inter-SMTP-представление и рассчитать эталонный MIC.

Пересылка добавляла ещё одну операцию. RFC 1421 применял границы инкапсуляции из RFC 934. Если строка MIC-CLEAR начиналась с дефиса и могла быть принята за границу, внешняя оболочка добавляла . MIC был вычислен до этого. Следовательно, владеющий оболочкой слой обязан был снять своё экранирование до внутренней проверки.

Неудачная проверка подтверждала расхождение с подписанным объектом после выполненной реконструкции. Она не называла виновника. Возможна злонамеренная правка; возможна и штатная конверсия, которую получатель не смог распознать или обратить. Поэтому RFC 1421 прямо указывал: ошибка MIC-CLEAR не обязательно является событием безопасности.

Интерфейс не должен был превращать эту неопределённость в ложную однозначность. Вместе с ошибкой следовало показывать тип PEM-сообщения. Синтаксически корректное письмо с неверным MIC нельзя было молча представлять как надёжное: пользователь получал предупреждение об аутентичности и целостности и явно подтверждал продолжение. Результат сравнения сохранялся без преждевременного диагноза.

Соседство с подписью ничего не подписывало

Управляющие поля PEM находились во вложенном заголовке внутри внешнего тела. За границами могли располагаться незащищённые пояснения, а в одном письме — несколько защищённых объектов и вложенные пересылки. Визуальная близость абзаца к границе не включала его в область MIC.

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

RFC 1423 вынес алгоритмы, режимы и идентификаторы в отдельную спецификацию. Основная грамматика обработки получила заменяемую криптографическую поверхность. Сейчас RFC 1421 и RFC 1423 имеют статус Historic. Идея модульного разделения остаётся поучительной, но конкретный набор алгоритмов 1993 года не является современной рекомендацией по безопасности.

Историческое значение MIC-CLEAR — не в обещании бесплатно защитить старую почту. Он точно показал обмен. Ретрансляторы не менялись, а текст оставался доступен любому читателю. Взамен каждое преобразование между подписанным каноническим объектом и локальным экраном должно было быть обратимым, объяснимым или честно признанным неизвестным. Письмо сохранило читаемость; проверяющий унаследовал его путь.