Summary

  • IANA уже внесла три новых набора SFrame в публичный реестр и пометила их Y. У таблицы есть точные размеры, но документ-основание ещё проходит редактуру RFC; выбор варианта с короткой меткой остаётся за приложением.
  • Карточка IETF всё ещё относит проект к очереди редактора RFC. Публичная запись фиксирует номера и параметры. Готовый RFC, поддержка в программе и использование в реальном звонке требуют других документов.

Размеры переехали из текста в строку реестра

Первоначальный RFC 9605 создал реестр с номером, названием, отметкой рекомендации, ссылкой и контролёром изменений. Длины ключей и меток следовало искать в технической части спецификации. Новая работа выводит пять размеров прямо в таблицу. Nh означает длину результата хеширования, Nka — ключ базового шифра в составной схеме, Nk — длину ключа шифрования, Nn — длину nonce, а Nt — добавочные байты, обычно приходящиеся на метку аутентификации. Читатель может сравнить программный код с публичной записью, не угадывая, какие параметры скрыты за названием.

На действующей странице IANA эти колонки уже заполнены. В трёх новых строках Nh равен 64 байтам, Nka — 32, Nk — 96 и Nn — 12. Для Nt указан выбор из 10, 8 или 4 байтов. Проект объясняет величину Nk=96: внутри SFrame для новой составной схемы получают 96 байтов материала ключа и соли вместо 48 байтов в варианте AES-128-CTR/HMAC-SHA256. Значение Nh=64 показывает длину выхода хеш-функции; оно не равно Nt, где указаны итоговые дополнительные 10, 8 или 4 байта. В приложении помещены тестовые векторы для составного шифрования и полного кадра SFrame. Такая проверяемость ценнее красивого слова «сильный».

Буква Y имеет собственное правило выдачи. RFC 9605 оставляет по умолчанию N для обычной регистрации через Specification Required; чтобы поставить Y либо D или изменить уже выданную рекомендацию такого класса, требуется Standards Action. В истории проекта видна апрельская дискуссия о согласовании Standards Track статуса документа с рекомендованными записями. Процедура подтверждает право ставить букву в реестр. Она не запускает шифр в телефоне абонента.

Временная ссылка стоит на виду

Для номеров 0x00060x0008 таблица показывает RFC-barnes-sframe-iana-256-06. Это промежуточная ссылка на проект, а не опубликованный номер RFC. Редакция 06 датирована 4 мая; дата последнего обновления IANA — 5 мая. На 28 октября Datatracker показывает очередь RFC Editor и статус действия IANA RFC-Ed-Ack. Номера и размеры уже доступны всем; редакционная работа над формальным документом продолжается. Реестр аккуратно показывает этот промежуток, вместо того чтобы выдать временную ссылку за номер опубликованного RFC.

Без приложения даже готовый текст не выбирает шифр за звонок. RFC 9605 возлагает на приложение решение, когда применять SFrame и какой набор использовать. Он отдельно говорит о дополнительных мерах против подделки при коротких метках аутентификации; полный размер во многих случаях проще. Новые варианты дают метки по десять, восемь и четыре байта. У четырёхбайтовой строки есть точный номер в реестре. У её использования в продукте должны быть точные защитные решения и проверка.

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