Открытые вопросы

Label 309 v1 заморожен. Формат записи под меткой метаданных 309, каноническое кодирование CBOR, реестры алгоритмов, конверт запечатанного подтверждения существования и конструкция подписи — всё это устоялось: совместимый с v1 верификатор читает любую запись v1, а совместимый с v1 производитель выдаёт записи, которые принимает любой верификатор v1. Эта страница не про изменение этого ядра. Она фиксирует, что в стандарте сегодня подтверждено, а что остаётся намеченным на будущее — какие криптографические конструкции-кандидаты зарезервированы для возможной будущей редакции и по какой строгой процедуре меняется криптографическая константа, когда одна из них доходит до реализации.

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

Зафиксированные конструкции

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

Постквантовый KEM поставляется в v1

Гибридный KEM X-Wing (ML-KEM-768 в композиции с X25519) зарегистрирован под идентификатором mlkem768x25519 в реестре enc.kem начиная с первого выпуска. Это не кандидат на будущее: он живёт в enc.scheme: 1 рядом с классическим KEM x25519, а поле enc.kem в записи выбирает для каждой записи свой KEM на уровне слота, форму слота и способ выведения ключа шифрования ключей (KEK).

X-Wing используется как чёрный ящик: конструкция опирается лишь на его публичный интерфейс — инкапсуляцию, декапсуляцию и 32-байтовый общий секрет — и не делает никаких предположений о внутреннем хешировании комбайнера. Ту привязку к получателю, которую классический путь получает из pub_R в своей соли HKDF, на гибридном пути обеспечивает внешняя соль, вычисленная над собственными проводными байтами слота: SHA-256("cardano-poe-xwing-kek-salt-v1" || kem_ct || pub_R). Хеширование этой конкатенации в фиксированные 32 байта и привязывает шифртекст и открытый ключ получателя к KEK слота, и снимает неоднозначность разбора, которую постквантовый шифртекст переменной длины создал бы при раскладке соли в виде голой конкатенации. Доступен только гибридный вариант — чистый ML-KEM намеренно не предоставляется, чтобы плечо X25519 сохраняло классическую стойкость, если ML-KEM-768 когда-нибудь будет взломан. См. Sealed PoE и Реестры алгоритмов.

Запечатанное обязательство по ключу привязывает заголовок и утверждение о хеше

Оба запечатанных пути привязывают ключ шифрования содержимого к закрытому транскрипту, сериализованному той же функцией канонического CBOR, что и остальной конверт, который фиксирует поля заголовка и утверждение о хеше открытого текста элемента (hashes_hash). На пути с адресацией по получателям (enc.slots) обязательство — в блокчейне: slots_mac — это HMAC с ключом от CEK над транскриптом, несущим идентификаторы схемы, пути, AEAD и KEM, nonce, перемешанный набор слотов и hashes_hash, — так что ретранслятор не сможет пришить шифртекст к другому набору слотов или другому утверждению о хеше, не провалив ончейн-проверку MAC ещё до выгрузки шифртекста. Путь с парольной фразой (enc.passphrase) несёт эквивалентное обязательство в 32-байтовом заголовке внутри блоба шифртекста, над транскриптом, добавляющим соль и параметры Argon2id, — так что подмена входов KDF проваливает проверку обязательства. Само содержимое затем запечатывается в сегментированном STREAM под ключом содержимого, выведенным из CEK; AAD на фрагмент пуст, поскольку каждое поле заголовка уже привязано к этому ключу транзитивно. Полная конструкция — на странице Sealed PoE.

Глубина подтверждения — это политика верификатора

Запись закреплена в момент, когда её транзакция попадает в блок, но верификатор, решающий, какую степень финализации требовать перед вынесением вердикта, применяет порог глубины подтверждения. В Label 309 это политика верификатора, а не нормативное ДОЛЖЕН. Стандарт определяет машиночитаемую поверхность — вердикт pending при неглубоком подтверждении и типизированный сбой при нарушении настроенного порога, — тогда как сам порог (РЕКОМЕНДУЕТСЯ ≥ 15 блоков) задаётся в конфигурации развёртывания, а не зашит константой в формат записи. Верификатор, требующий более глубокой финализации для дорогостоящих заявлений, полностью совместим. См. Проверка.

Проверка Ed25519 — строгая

Подписи на уровне записи ДОЛЖНЫ проверяться по строгим правилам RFC 8032 §5.1.7, а не по более снисходительному допуску пакетной проверки ZIP-215. Строгая проверка отвергает неканонические кодировки и точки малого порядка, которые снисходительный верификатор принял бы, поэтому два совместимых верификатора всегда приходят к одному вердикту по одной и той же подписи. Реализующим стандарт следует убедиться, что их бэкенд Ed25519 работает в строгом режиме; некоторые библиотеки по умолчанию используют снисходительный вариант. См. Подписи.

Каноническое CBOR — это контракт детерминизма

Каждая запись кодируется в каноническом CBOR согласно RFC 8949 §4.2.1: предпочтительные формы целых чисел, массивы и отображения определённой длины, ключи отображений, отсортированные побайтово, без дублирующихся ключей, без тегов. Именно детерминизм позволяет подписи, вычисленной над телом записи одной реализацией, пройти проверку в другой, и позволяет двум производителям одной и той же логической записи выдать побайтово одинаковые байты. Это не подлежит обсуждению ни в одной совместимой реализации и составляет основу контракта кросс-языкового паритета.

Кандидаты, намеченные на будущее

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

Зарезервированный альтернативный профиль AEAD содержимого

Слой содержимого запечатанного PoE в v1 — это chacha20-poly1305-stream64k: ChaCha20-Poly1305 по RFC 8439 в сегментированной компоновке STREAM, — который сам опирается на RFC, так что о формальном статусе текущего шифра содержимого открытого вопроса нет. Зарезервированным остаётся путь к другому AEAD содержимого, если того когда-либо потребует контекст развёртывания. Идентификатор aes-256-gcm (NIST SP 800-38D) зарезервирован в реестре AEAD ровно для этого и не входит в enc.scheme: 1: запись, называющая его, сегодня подпадает под правило неизвестного конверта.

Его введение стало бы будущей конструкцией enc.scheme: 2, сохраняющей существующие модели slots[] + slots_mac и обязательства по парольной фразе, но заменяющей слой содержимого, закрепляя новый размер фрагмента, выведение ключа содержимого, построение nonce на фрагмент, AAD на фрагмент и аутентификацию последнего фрагмента для этого шифра. Это запасной профиль, а не замена: существующие записи enc.scheme: 1 остаются действительными, и реализовывать этот профиль нельзя прежде, чем появятся нормативное определение enc.scheme: 2 и его тестовые векторы.

Зарезервированные постквантовые алгоритмы подписи

KEM-половина постквантовой траектории поставляется в v1 (см. выше). Сигнатурная половина зарезервирована, но пока не реализована. На включение в существующий реестр подписей претендуют два семейства — как только IETF COSE стабилизирует идентификаторы постквантовых алгоритмов:

Поскольку алгоритм подписи задан именованным идентификатором в защищённом заголовке COSE, регистрация преемника носит чисто дополнительный характер: существующие записи Ed25519 продолжают проходить проверку, а верификатор, который не распознаёт новый алгоритм подписи, выдаёт сигнал «алгоритм не поддерживается», а не отвергает заявление о содержимом. Нераспознанная подпись никогда не делает недействительным само подтверждение существования. См. Подписи.

Возможный путь публикации v: 2

Отдельные добавления — новый KEM, новый AEAD содержимого, новый алгоритм подписи — это записи в реестрах, не меняющие схему записи верхнего уровня. Добавление KEM, в частности, — это запись в реестре под enc.scheme: 1, а не смена scheme; смена enc.scheme зарезервирована для изменения конструкции, затрагивающего сразу несколько KEM (нового slots_mac или AEAD содержимого, которое применяется ко всем KEM сразу).

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

Необязательное разрешение замещения на один шаг

Необязательное поле записи supersedes указывает на одну более раннюю запись по хешу транзакции. Разрешать этот указатель для верификатора необязательно. Верификатор, который проверяет, что supersedes структурно является 32-байтовым хешем, но не загружает предыдущую транзакцию, остаётся совместимым, но упускает возможность показать цепочку замещения. Рекомендация: верификатор МОЖЕТ разрешить один шаг — повторно запросить у резолвера транзакций указанный хеш и сообщить о его существовании и времени блока, — не уходя в рекурсию дальше. Одного шага достаточно; более глубокий обход — ответственность вызывающей стороны, а замещение никогда не отзывает более раннюю запись, которую цепочка навсегда сохраняет проверяемой самостоятельно.

Миграция криптографической константы

Каждая зафиксированная конструкция выше опирается на именованные константы: идентификаторы алгоритмов, строки info для HKDF, соли KDF, длины nonce для AEAD, метки разделения областей. Изменение смысла любой из них — это слом формата, и стандарт предписывает для этого ровно один строгий путь. Главное правило: применяйте изменение наименьшего возможного масштаба, разрешающее проблему, и никогда не меняйте молча смысл существующей константы в том же пространстве имён.

Процедура дополнительная и обратно совместимая — старые записи продолжают проходить проверку под теми константами, с которыми были опубликованы, — и разворачивается по масштабу:

1. Версионируйте пространство имён, а не значение. Изменённое выведение увеличивает суффикс -vN у каждой строки разделения областей, которой оно касается: строки info для HKDF (…-v1 → …-v2), префиксы сообщений HMAC, соли и метки. Новая константа живёт под новым суффиксом; старая остаётся действительной под старым. Более старые верификаторы чисто отвергают более новые записи на дискриминаторе, а не истолковывают их неверно.

2. Поднимайте тот дискриминатор, что соответствует радиусу поражения. Изменение, ограниченное одним семейством слотов, выбирается через enc.kem; изменение слоя содержимого или обязательства по набору слотов, затрагивающее сразу несколько KEM, — это смена enc.scheme; изменение самой схемы записи — это смена v на верхнем уровне. Каждый дискриминатор локализует слом до наименьшего слоя, который действительно изменился.

3. Сохраняйте проверяемость предшественников. Более старые версии записей остаются читаемыми как замороженные схемы. Верификатор выбирает конструкцию по собственным дискриминаторам версии записи, так что одна реализация может проверять v1 и будущего преемника бок о бок. Ни одна запись никогда не перестаёт проходить проверку из-за того, что вышел преемник.

Связанные страницы

• Реестры алгоритмов — именованные идентификаторы, чьи пространства имён версионируются при миграции.
• Sealed PoE — гибридный KEM X-Wing, транскрипт-привязка обязательства по ключу и дискриминаторы enc.scheme / enc.kem.
• Подписи — строгая проверка Ed25519 и реестр подписей, к которому присоединились бы зарезервированные постквантовые алгоритмы.