Summary

  • RFC 2440 определил множество тегов пакетов OpenPGP, но не ввёл обычную процедуру постоянного добавления новых: взаимодействие функций могло снизить безопасность протокола в целом.
  • Наличие свободных номеров в заголовке не давало разрешения. Значения 60–63 оставались частными или экспериментальными; запросы на новые значения следовало направлять директорам Security Area в IESG либо подходящей рабочей группе IETF.
  • Неизвестные подпакеты подписи обычно игнорировались. Бит critical позволял подписанту предпочесть ошибку незаметной потере смысла функции. Распознать — не значит реализовать; нехешированные метаданные не были окончательным доказательством.
  • Позднейшие редакции формализовали реестры и проверки. Выделенный номер, успешный разбор или действительная подпись всё равно не доказывают безопасную композицию или развёртывание.

Свободное место ничего не решало

Представим разработчицу, которая находит неиспользуемый тег в пакете OpenPGP. Два новых клиента записывают значение и читают его обратно; тест проходит. Байты помещаются. Но что сделает старый проверяющий? Может ли согласование понизить уровень функции? Не меняет ли другой пакет её смысл? Сохранится ли математическая действительность подписи, если новую семантику проигнорировать? Локальный тест «записал — прочитал» не отвечает ни на один из вопросов.

Именно это беспокойство отражено в примечании IESG к RFC 2440 от ноября 1998 года. Документ определял много тегов, но не описывал обычный способ добавлять новые. Заголовок нового формата мог кодировать значения до 63, однако спецификация предупреждала: тонкие взаимодействия новых и существующих функций способны существенно снизить общую безопасность. Запросы на новые значения — например, для алгоритмов шифрования — следовало направлять директорам Security Area в IESG или подходящей рабочей группе. Значения 60–63 оставались частными или экспериментальными.

Пространство номеров существовало; безопасная процедура расширения из этого не следовала.

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

Подписи сделали границу заметной

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

Бит 7 типа подпакета давал выбор. Если неизвестный подпакет отмечен как критический, проверяющий должен считать подпись ошибочной. Подписант мог предпочесть явный сбой принятию с потерянным смыслом. Это не абсолютная гарантия: проверяющий должен знать правило; даже распознав подпакет, он мог не реализовать его семантику. Спецификация прямо разделяла эти состояния.

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

От осторожности к реестру

RFC 4880, заменившая RFC 2440 в 2007 году, создала явные реестры IANA и потребовала консенсуса IETF для новых типов пакетов, считавшихся крупными функциями. Она также отметила риски downgrade и cross-grade у расширений механизма обнаружения изменений. Процедура стала прозрачнее, но совместимость, реализация и анализ безопасности не превратились в один флажок.

RFC 9580, опубликованная в 2024 году, заменила RFC 4880 и сохранила разные режимы выделения. В некоторых реестрах OpenPGP применяется Specification Required; для типов пакетов и отдельных пространств версий и идентификаторов действует более строгий RFC Required. Эксперты должны оценивать ожидаемые свойства безопасности и совместимость с существующими реализациями. Это институциональный ответ на прежний пробел, а не доказательство безопасности каждого принятого расширения во всех условиях.

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

Источники