Кратко
- Редакция 06 предлагает назначить JWS
noneи JWERSA1_5статус Deprecated, а не Prohibited: приложения обязаны отключать их по умолчанию, но могут разрешать для строго определённых объектов или операций. - На 29 сентября 2026 года действующий реестр IANA JOSE ещё не отражал предложение; даже будущая смена статуса не докажет удаление возможности из библиотеки или отказ конкретному запросу.
- Надёжная квитанция о выводе должна связать объект и операцию,
algиenc, итоговый список разрешений, реально собранные возможности, владельца, область и срок исключения, результат решения и выданное им полномочие.
Самая опасная миграция — та, которую объявили завершённой по косвенному признаку. Команда видит новый статус в реестре, обновлённую зависимость и закрытую задачу. Но старый контрагент предъявляет токен по аварийному маршруту, исключение всё ещё действует, и приложение отвечает успехом. Все три отчёта могут быть формально верны, а граница доверия — оставаться открытой.
Редакция 06 документа «JOSE: Deprecate 'none' and 'RSA1_5'» опубликована 25 сентября 2026 года. Карточка Datatracker показывает Internet-Draft на последнем рассмотрении IETF до 9 октября; также требуется проверка IANA. История документа свидетельствует о движении текста, но не о поведении развёрнутого сервиса.
Речь идёт о двух разных механизмах. JWS none означает незащищённый JWS без подписи и без MAC. RFC 7515 задаёт формат JWS, а RFC 7518 уже требовал, чтобы реализации не принимали такой объект по умолчанию. Если входное поле alg само выбирает путь проверки, недоверенные данные получают возможность отключить аутентификацию.
JWE RSA1_5, напротив, — алгоритм управления ключом RSAES-PKCS1-v1_5 внутри модели зашифрованных объектов RFC 7516. Это не JWS-алгоритмы подписи RS256, RS384 или RS512. Запрет всех названий, содержащих RSA, способен сломать независимые операции и одновременно не доказать закрытие уязвимого пути. RFC 8017 описывает базовые схемы RSA, а актуальное руководство CFRG связывает устойчивость к оракулам и единообразие ошибок с конкретной реализацией.
В проекте важен каждый глагол. Разработчикам библиотек следует объявить поддержку устаревшей. Разработчики приложений обязаны отключить оба варианта по умолчанию. При конкретной необходимости один из них можно включить только для нужных объектов или операций, но не глобально. Новые спецификации на основе JOSE не должны разрешать ни один вариант.
Это управляемый переход, а не удаление. Проект просит IANA поставить Deprecated, не Prohibited, оставляя существующим спецификациям и приложениям время для миграции. На момент фиксации реестр IANA JOSE всё ещё показывал none как Optional, а RSA1_5 как Recommended-. Будущая правка изменит общую метаинформацию, но не перепишет шлюзы, SDK, криптомодули, настройки арендаторов и файлы исключений.
Операционное доказательство должно пройти весь путь решения. Нужны класс объекта JOSE и бизнес-операция; защищённое значение alg и, для JWE, enc; издатель, аудитория, арендатор и маршрут; список разрешений после разрешения этих селекторов; версия библиотеки и фактически включённые в сборку возможности; источник, утверждающий, область и срок каждого исключения; тип ключа; окончательное принятие или отказ; субъект и действие, которым результат дал полномочие.
Для JWE следует фиксировать и форму ошибки. Разные сообщения, размеры ответа или длительность могут превратить точку расшифрования в оракул, даже если панель называет RSA1_5 редким исключением. NIST SP 800-131A Revision 2 даёт контекст криптографического перехода, но не подтверждает единообразие ошибок локальной службы.
RFC 8725 требует проверять алгоритм в JWT и не полагаться на выбор, контролируемый атакующим. Заголовок токена — запрос на способ обработки, но не право назначить проверяющий механизм. Такое право принадлежит итоговой политике приложения.
Проект задаёт и критерии для будущих регистраций. Новые подписи и MAC в JWS должны обеспечивать EUF-CMA, весь процесс шифрования JWE — IND-CCA2, а шифрование содержимого — AEAD по RFC 5116. Это полезные ориентиры для экспертной оценки, но не результаты испытаний конкретной сборки и не защита от ошибок сочетания ключей, парсинга и политик.
Принцип Heng Lu о первичности работающего кода ставит фактическое принятие выше инвентарного ярлыка. Слои реальности отделяют символический статус от факта получения полномочия. Минимальная исходная спецификация объясняет, как общее правило задаёт безопасное значение по умолчанию, не снимая с локальной системы ответственности за узкое исключение.
Вывод завершён лишь тогда, когда все значимые пути по умолчанию отказывают, а каждое оставшееся «да» точно ограничено, имеет владельца, измеряется и истекает. До этого Deprecated — предупреждение у входа, а не квитанция из точки принятия решения.
Источники
- Текущая карточка проекта
- Редакция 06
- История проекта
- RFC 7515: JWS
- RFC 7516: JWE
- RFC 7518: JWA
- RFC 8725: лучшие текущие практики JWT
- RFC 8017: PKCS #1
- RFC 5116: AEAD
- Реестр IANA JOSE
- Руководство CFRG по RSA
- NIST SP 800-131A Revision 2
- Heng Lu: Running-Code Primacy
- Heng Lu: Reality Layers
- Heng Lu: Minimum Initial Specification
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

