Кратко

  • RFC 9964 вводит общий тип Algorithm Key Pair и регистрирует ML-DSA-44, ML-DSA-65 и ML-DSA-87 для JOSE и COSE, чтобы ключи и параметры алгоритма представлялись единообразно.
  • Обязательные alg и pub, равно как и успешная проверка подписи, не устанавливают происхождение ключа, доверенный источник, правила для утверждений или разрешённое действие.

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

RFC 9964 решает именно задачу представления. Michael Prorock и Orie Steele описывают применение ключей и подписей ML-DSA с JOSE и COSE. Algorithm Key Pair, AKP, задан как общий формат ключевой пары для алгоритмов, не ограниченных регистрациями самого документа. Для каждого AKP обязательны alg и pub; priv хранит закрытую информацию и не должен присутствовать в открытом ключе. Так разные реализации получают общие правила для чтения и проверки криптографического материала.

Выбор закрытого ключа ML-DSA показывает границы этой стандартизации. FIPS 204 определяет представление в виде seed и представление развёрнутого закрытого ключа. RFC 9964 оставляет только seed: priv обязан быть seed длиной 32 байта. Это даёт JOSE и COSE одну компактную форму и уменьшает расхождения при управлении ключами. Но из этого не следует, кто создал seed, как он хранился, откуда пришёл открытый ключ и почему проверяющая сторона должна принять утверждение, связанное с этим ключом.

Регистрация ML-DSA-44, ML-DSA-65 и ML-DSA-87 также упорядочивает только общий язык параметров. Реестр не является списком доверенных эмитентов. Он не связывает ключ с субъектом, не проверяет канал распространения, не толкует claims и не решает, что положительный результат подписи означает разрешение. Эти переходы требуют отдельной политики: доверенного якоря, проверки эмитента и субъекта, правил принятия утверждений и владельца решения.

Документ отдельно отмечает крупный размер ключей и подписей ML-DSA. При ограничениях по полосе, памяти или вычислению они могут быть непригодны. Это не оценка какого-либо развёртывания, а различение правильного формата и эксплуатационной пригодности. Подробный анализ безопасности вынесен за рамки RFC 9964 и отсылает к FIPS 204 и RFC 9881.

В этом состоит устойчивая ценность соавторского вклада Prorock: он делает обмен ML-DSA-материалом более строгим, но не прячет политику доверия внутри переносимого поля. Решение всё ещё должно объяснять происхождение ключа, управление якорями, смысл утверждения и последствия, за которые кто-то отвечает.

Sources