Кратко

  • RFC 1505 предложил необязательное поле Encoding, которое описывало части тела письма, число строк и упорядоченные преобразования. Точное чтение описания не гарантировало сохранения смысла на другой машине.
  • Формат FS мог передавать владельца, группу, ACL, пароль, приложение и время. Чужие идентификаторы и недоступная точность требовали отдельного местного отображения, а не механического присвоения.
  • Для SHAR документ запрещал автоматическое исполнение восстановленных команд; для LZJU90 число байтов и CRC проверяли целостность. Ни одна такая проверка не удостоверяла отправителя и не давала разрешения на действие.

Значение, которое нельзя было записать без потери

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

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

С владельцем расхождение опаснее. Число или имя пользователя принадлежит административному пространству отправителя. На стороне получателя тот же номер может относиться к другому человеку, такое имя может отсутствовать или совпасть с привилегированной учётной записью. Буквально скопированная строка ещё не сохраняет владельца; она может назначить нового.

RFC 1505 поэтому интересен не обещанием универсального переноса, а местами, где признаёт невозможность автоматического тождества. Полученное описание можно сохранить точно. Применить его без перевода между системами нельзя.

FS переносил целую среду файла

Кодирование FS представляло каталоги, записи, файлы, сегменты и данные из разнородных сред — Unix, DOS, VMS, Primos, Macintosh. Оно могло нести отображаемое имя, комментарий, тип, время создания, изменения и доступа, владельца, группу, список контроля доступа, пароль, размер блока и записи, а также связанное приложение.

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

Синтаксис ACL включал права добавлять, удалять, перечислять, менять защиту, читать, использовать, писать, исполнять или получать полный доступ. Были зарезервированы роли $OWNER, $GROUP, $SYSTEM и $REST. Они создавали переносимый словарь ролей, но не создавали всемирных пользователей.

Если $SYSTEM отобразить на местного администратора, декодер выдаст полномочие. Если отбросить, он потеряет намерение отправителя. Если заменить пользователем, открывшим письмо, он смешает получение с владением. Все варианты требуют политики; ни один не становится нейтральным из-за надписи «восстановить атрибуты».

Добросовестная система должна была сохранить исходное имя и пространство, отметить отсутствие однозначного соответствия, записать выбранное местное значение и основание выбора. Тогда последующий наблюдатель видел бы не один «успешный» результат, а преобразование с потерями и автором решения.

Пароль в открытом виде не становился местным секретом

FS допускал атрибут password с паролем доступа к элементу в открытом виде. RFC 1505 рассуждал, что это не обязательно раскрывает дополнительную тайну, поскольку следом в том же кодировании идёт защищаемое содержимое.

Затем документ проводил важную границу. Если декодер действительно устанавливает полученный пароль для созданного элемента, безопасность или небезопасность этого шага относится к прикладной области, управляющей декодером. То же самое сказано об ACL и других защитных атрибутах.

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

Это меняло смысл «точного восстановления». Если механизм защиты в новой среде даёт иной объём доступа, буквальная копия становится не сохранением, а новым распределением власти.

Заголовок задавал путь к телу

RFC 822 разделял письмо на заголовок и тело пустой строкой. RFC 1505 добавлял необязательное поле Encoding, чтобы описывать несколько частей тела без вставки управляющих конструкций внутрь самого содержимого. Старые программы чтения могли бы показать такие конструкции как обычный текст.

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

Вложенные преобразования зависели от порядка. Декодер обрабатывал слова слева направо. Кодировщик записывал их в порядке, обратном выполненным операциям. Последовательность uuencode LZW tar была не перечнем трёх возможностей, а конкретным маршрутом назад к исходному материалу.

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

Парсер мог проверить числа и пройти маршрут. Это доказывало, что он понял заявленное представление. Оно не доказывало, что заявка правдива, преобразование безопасно, а дальнейшее действие разрешено.

SHAR можно было распознать, но нельзя было самовольно запустить

Ключевое слово SHAR обозначало shell-архив. Такой архив содержал команды, способные восстановить файлы, а вместе с ними — любые другие инструкции, понятные оболочке. RFC 1505 поддерживал формат, но не рекомендовал его и предупреждал: декодер не должен автоматически исполнять восстановленные операторы.

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

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

Если интерфейс объединял эти этапы в «архив обработан», он скрывал место принятия решения. Если после корректного декодирования запуск происходил автоматически, синтаксис удалённой стороны становился местной командой.

Источники не описывают конкретной атаки через SHAR по RFC 1505 и не подтверждают поведение названного продукта. Они подтверждают более узкий проектный факт: поддержка формата прямо не считалась разрешением исполнять его содержимое.

Число строк и CRC проверяли разные объекты

LZJU90 сочетал сжатие с печатным представлением, рассчитанным на прохождение через почтовые программы, шлюзы и преобразования ASCII/EBCDIC. В конце находились исходное число байтов и CRC, которые должны были совпасть после распаковки.

Эти значения помогали обнаружить обрезку, повреждение или неправильную операцию. Но CRC не аутентифицировал отправителя, не подтверждал владельца и не разрешал выполнение.

Кроме того, число из Encoding относилось к строкам кодированного текста, а хвост LZJU90 — к декодированным байтам и их CRC. Фраза «контрольное число совпало» без единицы и этапа могла выдать узкую проверку за общую гарантию.

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

Signature могла быть обычной подписью под письмом

В RFC 1505 слово Signature означало обычную область подписи в конце письма или сообщения Usenet: имя отправителя, любимую фразу или иной автоматически добавленный текст. Text Signature описывала элемент оформления, а не результат криптографической проверки.

PEM, PEM-Clear и PGP имели отдельные ключевые слова и собственные внутренние режимы шифрования, контроля целостности, ключевых блоков или отделённых подписей. Но и здесь внешняя метка не исчерпывала доказательство. Нужно было знать охваченные байты, результат алгоритма, происхождение ключа и местное доверие к заявленному имени.

RFC 1505 отмечал, что вложенный тип после PGP мог сообщить наблюдателю, является ли содержимое текстом или транзакцией EDI. Успешное шифрование не удаляло все сведения о контексте.

Один индикатор «подписано» смешал бы прощальную строку, криптографический формат, математическую проверку и принятую личность. Эти состояния нельзя было восстанавливать друг из друга.

Регистрация слова не подтверждала поддержку

Слова без префикса X- предполагалось регистрировать в IANA; X- оставался для специфических расширений. Регистрация давала общий термин и путь к его документации, уменьшая риск, что разные сообщества назовут одним словом несовместимые операции.

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

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

Эксперимент рядом с MIME

RFC 1505 был опубликован в августе 1993 года со статусом Experimental и отменил RFC 1154. Он не задавал стандарт Интернета. Примечание IESG сообщало, что в той же области уже существует технология на стандартизационной траектории, и указывало на RFC 1341 — MIME.

Проекты можно сравнивать как одновременные ответы на усложнение почты. RFC 1505 собирал упорядоченное описание частей в верхнем заголовке. MIME снабжал отдельные части явными заголовками и разделял границами. В модели MIME также были предупреждения об активном содержимом и потреблении ресурсов.

Позднее RFC 2045 пересмотрел линию MIME через RFC 1521, RFC 1522 и RFC 1590. Из этого не следует, что RFC 1505 был ранней версией MIME или что MIME формально отменил его. Подробность экспериментального документа также не доказывает широкое внедрение.

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

Что подтверждают источники

Первичные документы подтверждают синтаксис заголовка, подсчёт строк, порядок слов, атрибуты FS, предупреждение о SHAR, проверки LZJU90, правило регистрации, статус Experimental и замечание IESG о MIME. Они позволяют различать представление, целостность, аутентификацию, разрешение и эффект.

Они не называют реализацию, поддерживавшую все слова, не измеряют распространение, не описывают реальную атаку SHAR и не подтверждают безопасное отображение идентичностей между системами. Нельзя утверждать, что CRC удостоверял отправителя, Signature обязательно означала криптографическую подпись, а IANA разрешала исполнение.

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

Источники