Кратко

  • Если защищённый список crit называет расширение, которого проверяющая сторона не понимает и не поддерживает, JWS недействителен даже при совпавшей подписи.
  • Это граница смысловой совместимости: старая реализация не вправе отбросить обязательное новое правило и продолжить работу по прежним правилам.
  • Криптографический результат, обработка JOSE и прикладное разрешение должны фиксироваться как самостоятельные решения.

Правильный расчёт, после которого надо отказать

Сервис получает JWS, находит нужный ключ, восстанавливает вход подписи и успешно выполняет криптографическую проверку. В упрощённой панели это уже зелёный индикатор. Но в защищённом заголовке есть расширение, имя которого также помещено в crit, а сервис никогда его не реализовывал.

RFC 7515 требует признать такой JWS недействительным. Нельзя пропустить незнакомое поле, сохранить результат вычисления и применить привычное толкование. Успешная подпись подтверждает связь между байтами, алгоритмом и ключом. Она не подтверждает, что получатель знает новое правило, определяющее построение или смысл этих байтов.

Значение crit — массив имён параметров заголовка. Каждое имя должно относиться к расширению, которое действительно присутствует в JOSE Header и которое получатель понимает и поддерживает. Массив не может быть пустым, содержать повторы или ссылаться на отсутствующий параметр. Имена, уже определённые JWS или JWA, нельзя повторно объявлять расширениями.

Сам crit допустим только в защищённом заголовке. Если список обязательных смыслов можно было бы изменить без нарушения подписи, посредник удалил бы неудобное имя и заставил старый проверяющий компонент продолжить обработку. Незнакомые параметры, не объявленные критическими, в общем случае можно игнорировать. Это различие позволяет добавлять необязательные сведения, но запрещает молча пропускать изменение семантики.

Механизм обновления не одновременно обновляемого мира

Авторами RFC 7515 указаны Michael B. Jones, John Bradley и Nat Sakimura. Долгая работа Sakimura над стандартами цифровой идентичности и его роль в OpenID Foundation дают важный контекст, однако коллективную спецификацию нельзя приписывать ему одному. Она отвечает на общий институциональный вопрос: как менять формат, который годами живёт в библиотеках и продуктах разных поставщиков.

Нельзя ждать одновременного обновления всех получателей. Но нельзя и позволить старой программе принять сообщение с новым смыслом как обычное старое сообщение. crit распределяет обязанность доказательства. Отправитель защищённым образом сообщает, какие расширения необходимы именно здесь. Получатель может двигаться дальше лишь тогда, когда обработал каждое из них по известному правилу.

Слово «критический» не является оценкой секретности или тяжести инцидента. Вопрос в том, сохранятся ли значение и свойства безопасности при игнорировании параметра. Заметное бизнес-поле может быть необязательной подсказкой, тогда как небольшой переключатель кодирования меняет точные байты на входе подписи.

Последовательность проверки в RFC 7515 поддерживает это разделение: разобрать и проверить защищённый заголовок, удостовериться в понимании требуемых полей и значений, построить вход подписи, провести криптографическую операцию. API библиотеки, возвращающий единственный valid, может скрыть, какое условие выполнено и какое вообще не проверялось.

b64:false как проверка закрытого отказа

RFC 7797 даёт наглядный пример. Обычно JWS включает в подписываемую конструкцию payload в кодировке base64url. При защищённом b64 со значением false используется некодированная полезная нагрузка. Меняются точные подписываемые байты и некоторые условия сериализации.

Поэтому JWS с b64:false обязан перечислить b64 в crit. Проверяющая сторона, знакомая только с прежним поведением, встретит неизвестное критическое расширение и откажет. Она не станет применять стандартное кодирование к сообщению, построенному по другой схеме, и не выдаст вычисление над иной строкой за согласие о смысле.

Даже поддержка расширения ещё не означает право применять его везде. Профилю приложения рекомендуется последовательно выбирать один режим; компактная сериализация требует осторожности с некоторыми символами payload. А для JWT использование b64:false прямо запрещено. Универсальная библиотека JWS может идеально обработать расширение, но приложение JWT всё равно должно отвергнуть комбинацию.

Получаются три вопроса. Совпала ли подпись с построенным входом? Поняты и применены ли все обязательные расширения? Допускает ли данный тип сообщения такое применение? Положительный ответ на первый не принимает решения за два остальных.

Умение выполнить алгоритм не означает его допустимость

RFC 7518 определяет алгоритмы и идентификаторы JOSE. Наличие кода, способного выполнить алгоритм, не делает этот алгоритм приемлемым в любом контексте. RFC 7515 оставляет приложению выбор допустимых алгоритмов. Верная подпись может быть отклонена из-за политики алгоритмов, ключей или параметров.

RFC 8725 превращает это разделение в практические требования для JWT. Реализация должна ограничивать допустимые алгоритмы и не позволять вводу под контролем отправителя единолично выбирать метод проверки. Нужно валидировать издателя, субъект, аудиторию и правила профиля. Разным типам JWT могут потребоваться взаимоисключающие правила, чтобы токен одного назначения не был принят в другом.

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

При нескольких подписях важно знать, какая сработала

JSON-сериализация JWS может содержать несколько подписей. В общем порядке RFC 7515 хотя бы одна должна быть действительной, но приложение вправе установить более строгий порог. У каждой подписи собственный защищённый заголовок и, следовательно, собственный набор критических расширений.

При миграции новая подпись может вводить новый алгоритм или смысл, а старая — сохранять совместимость. Если правило «достаточно любой» действует бессрочно, старый путь становится постоянным каналом понижения защиты. Если немедленно потребовать все подписи, законные получатели без поддержки расширения перестанут работать.

Нужна явная политика: какие подписи засчитываются, какие ключи и расширения разрешены, для какой аудитории действует переход и когда закрывается прежний путь. Журнал должен показывать конкретную подпись, удовлетворившую условию. Общий успех не говорит, продвигается ли миграция или весь поток по-прежнему держится на исключении.

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

Криптографический слой фиксирует алгоритм, ссылку на ключ, построение входа и результат подписи. Слой JOSE — защищённый заголовок, встреченные критические имена, обработчик каждого расширения и отказы из-за непонимания. Прикладной слой — профиль, издателя, аудиторию, ограничения claims, решение авторизации и запрошенное действие.

Для этого не требуется хранить секреты или полный токен. Достаточно устойчивых идентификаторов связи и точных кодов причины. Формулировка «неверная подпись» ведёт инженеров к ключам, хотя подпись могла совпасть, а неизвестным было расширение. Формулировка «токен действителен» скрывает реальный отказ по аудитории или бизнес-политике.

Главная роль crit — не в ещё одном поле заголовка, а в честности относительно знания. Получатель не может заявить, что понял сообщение, лишь потому, что аутентифицировал его оболочку. Sakimura и его соавторы сделали признание «я не умею это обработать» корректным результатом протокола.

Источники