Кратко

  • AKP из RFC 9964 делает alg и pub обязательными и отделяет закрытый материал, чтобы ML-DSA одинаково представлялся в JOSE и COSE.
  • В priv помещается только 32-байтовый seed. Утечка seed или развёрнутого закрытого ключа позволяет подделывать подписи, поэтому оба требуют одинаковой защиты.
  • Открытый отпечаток сопоставляет ключ и алгоритм; право подписывать, ротация и решение сервиса принять эффект остаются за его пределами.

Сопоставимый ключ не является мандатом

JOSE и COSE нужен общий способ говорить о ключах ML-DSA. RFC 9964 задаёт AKP и регистрирует ML-DSA-44, ML-DSA-65 и ML-DSA-87. Поля alg и pub обязательны, а priv не должен появляться в открытом ключе. Отпечаток строится по открытым элементам, включая kty, alg и pub, поэтому реализация может проверить, говорят ли две записи об одном открытом ключе и одном алгоритме.

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

FIPS 204 допускает закрытый материал в виде seed или развёрнутого закрытого ключа. RFC 9964 выбирает только seed, чтобы у двух экосистем было одно компактное представление. При этом стандарт прямо указывает: оба материала требуют равной защиты, поскольку несанкционированное получение любого из них позволяет создавать подписи. Устранена неоднозначность сериализации, а не риск резервных копий, каналов восстановления, делегирования, компрометации устройств или неясной ответственности.

Поэтому нельзя сводить цепочку к записи «подпись действительна». AKP и открытый отпечаток — это свидетельство ключа. Место seed или развёрнутого материала и способы его защиты — свидетельство хранения. Цель и масштаб запроса — свидетельство операции. Тот, кто разрешил действие, оставляет свидетельство авторизации. Дополнительная проверка и принятие либо отказ на стороне получателя — свидетельство сервиса. Эти записи связаны, но ни одна не заменяет следующую. Корректный ключ может не иметь права на конкретный запрос; действительная подпись может быть отклонена сервисной политикой.

Более крупная подпись не создаёт более крупный центр

ML-DSA делает ограничение размера заметным. Открытые ключи и подписи значительно больше многих традиционных альтернатив, а кодирование JSON добавляет объём. RFC 9964 предупреждает, что среды с ограничениями сети, памяти или вычислений могут быть непригодны. Это повод каждому участнику измерить собственный путь, выбрать подходящий набор параметров, отвергнуть неподходящий и сохранить обходной маршрут в период проверки, а не основание для центрального навязывания единого профиля.

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

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