Кратко

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

У криптографической миграции есть опасный момент успеха: команда наконец получает список. В нём видны старые библиотеки, параметры, ключевые форматы, протоколы и исключения. Затем список начинают читать как ответ на другой вопрос — «защищена ли система от будущего?». RFC 9958 не поддерживает такой скачок. Он предлагает инженерную работу по инвентаризации: разработчики должны, где это возможно, искать алгоритмы, зашитые в приложения; администраторы, владельцы политик и специалисты по соответствию должны учитывать конфигурации, которые приложения делают доступными, и управлять ими через письменные или автоматизированные политики.

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

RFC 9958 подчёркивает, что переход к PQC часто не является заменой одного имени другим. Меняются размеры ключей, шифротекстов и подписей, затраты и интерфейсы; иногда требуется перепроектирование протокола или приложения. Имеет значение функция. KEM не тождественен подписи и содержит разные операции encapsulation и decapsulation. Строка ML-KEM в инвентаре не раскрывает, какая сторона выполняет операцию, в каком протоколе, с какой обработкой отказа и участвует ли она в наблюдаемом пути. FIPS 203 и FIPS 204 определяют ML-KEM и ML-DSA; они не удостоверяют поведение конкретной эксплуатации.

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

RFC 7696 определяет гибкость как способность менять криптографический выбор; способность не доказывает совершённого изменения. RFC 9958 имеет статус Informational и не является сертификатом поставщика, переписью развёртываний или прогнозом появления криптографически значимого квантового компьютера. В редакционной логике Heng Lu это три разных слоя: запись и конфигурация дают описание, работающий код даёт более узкое техническое свидетельство, а выбор изменить, отложить, откатить или принять риск остаётся локальным ответственным решением.

Sources