Кратко

  • В ревизии 05 сказано, что экспериментальные идентификаторы 100–107 заменены назначенными 37–44. Снимок реестра IANA от 1 октября 2026 года всё ещё показывал 37–99 как Unassigned. Это датированное расхождение, а не свидетельство причины или результата процедуры.
  • Все восемь вариантов имеют статус MAY и относятся только к ключам, сертификатам и подписям v6 или новее. Распознавание номера не доказывает поддержку, включение или полное выполнение.
  • Составная подпись требует успеха ECDSA и ML-DSA. Составной KEM требует ECDH и ML-KEM, полной проверки эллиптической точки, точного контекста комбинирования и успешной проверки целостности при развёртывании ключа.

Вектор доказывает ровно тот пример, который содержит

Текст ревизии 05 сообщает о переходе со 100–107 на 37–44, пересчёте отпечатков, промежуточных значений KEM и тестовых векторов. Для четырёх подписей добавлены отдельные векторы detached signature. Версии HTML и XML описывают те же конструкции.

Однако зафиксированный реестр параметров OpenPGP IANA перечислял алгоритмы до 36, а диапазон 37–99 оставлял свободным. Из этого нельзя вывести отказ, ошибку авторов или ожидаемую дату обновления. Можно утверждать только одно: в момент снимка публичные источники не давали согласованного ответа.

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

Страница Datatracker показывала активный Internet-Draft рабочей группы OpenPGP от 24 сентября 2026 года со сроком до 28 марта 2027 года. В API документа intended status отсутствовал, хотя заголовок говорил Informational. История указывала, что перед разрешением председателя нужна новая редакция. Это не RFC и не утверждённый стандарт.

Идентификаторы задают конструкции, а не покрытие

37 и 38 соединяют ML-KEM-768/1024 с ECDH на NIST P-384/P-521. 39 и 40 используют brainpoolP384r1/P512r1. 41–44 соединяют ML-DSA-65/87 с ECDSA на тех же семействах кривых.

Каждый вариант необязателен. Библиотека может реализовать одну кривую, продукт — включить только подписи, политика — запретить Brainpool, а хранилище — не принимать ключи v6. Число фиксирует набор компонентов и длины, но не является ведомостью внедрения.

RFC 9580 задаёт современную архитектуру пакетов, ключей и подписей OpenPGP. RFC 9980 вводит ML-KEM, ML-DSA и multiKeyCombine. Проект ограничивает новые варианты объектами v6 или новее; подписи требуют также дайджест не менее 256 бит. Эти параметры должны присутствовать в квитанции разбора.

Успешное развёртывание ключа — последний, а не единственный факт

При инкапсуляции отправитель выполняет ECDH и ML-KEM. Два секрета, ECDH ciphertext, открытый ECDH-ключ и идентификатор входят в multiKeyCombine. Полученный KEK заворачивает сеансовый ключ через AES-256 key wrap.

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

FIPS 203 определяет ML-KEM, а SP 800-56A Rev.3 даёт контекст классического обмена на эллиптических кривых. Финальный успех не сообщает автоматически, какой парсер и какие проверки привели к нему.

До секретного умножения точка должна доказать принадлежность

Ревизия 04 добавила полную проверку точек коротких кривых Вейерштрасса NIST и Brainpool. До умножения на секретный скаляр требуется убедиться, что точка не бесконечная, координаты находятся в поле и уравнение кривой выполняется.

При инкапсуляции проверяется открытая ECDH-точка получателя, при декапсуляции — входная эфемерная точка ciphertext. Ошибка требует остановки. Проект предупреждает: умножение выбранной атакующим точки вне кривой может создать invalid-curve attack и привести к восстановлению секрета ECDH.

Основание для этого дают FIPS 186-5, кривые SP 800-186, Brainpool в RFC 5639 и проверка открытых ключей в SEC 1 v2. Верная длина поля не доказывает принадлежность точки. Отдельная квитанция должна назвать кривую, валидатор, сборку и каждый результат без записи секрета.

В составной подписи нет запасного успешного пути

Подпись содержит ECDSA и ML-DSA над дайджестом данных OpenPGP. Оба результата должны быть положительными. Неподдерживаемый, пропущенный, повреждённый или невалидный компонент означает невалидность всей подписи.

Длины R и S ECDSA зависят от кривой. Подпись ML-DSA-65 занимает 3 309 октетов, ML-DSA-87 — 4 627; дайджест короче 256 бит отклоняется. FIPS 204 определяет ML-DSA, а RFC 9794 упорядочивает терминологию традиционных и постквантовых гибридов. Ни один документ не превращает AND в OR.

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

Границы доказанного

Источники не подтверждают конкретную реализацию, эксплуатацию, совместимость, пакет, атаку, инцидент, производительность или уровень внедрения. Они не повторяют отдельный вопрос RFC 9980 о сообщениях с несколькими путями получателей. Здесь рассматривается полное исполнение одного NIST/Brainpool-композита.

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