5.8.1. Цифровая подпись и шифрование

5.8.1.1. В зависимости от транспорта, с помощью которого отправляются сообщения, целостность сообщения может не гарантироваться, а отправитель сообщения может не проходить проверку подлинности. Чтобы уменьшить эти риски, при обработке значений ID токена, ответа UserInfo, объекта запроса и аутентификации клиента может использоваться JWS для цифровой подписи содержимого этих структур данных. Для обеспечения конфиденциальности сообщений также может использоваться JWE для шифрования содержимого этих структур данных.

Сервер авторизации может объявлять о поддерживаемых им алгоритмах подписи и шифрования в своем документе Discovery (см. подпункт 5.4.4.1) или предоставлять эту информацию другими способами. Клиент может декларировать свои алгоритмы цифровой подписи и шифрования в своем запросе динамической регистрации (см. подпункт 5.4.4.5) или передавать эту информацию другими способами.

Сервер авторизации может объявлять свои открытые ключи цифровой подписи и шифрования через документ Discovery или предоставлять эту информацию другими способами. Клиент может объявлять свои открытые ключи через запрос динамической регистрации или передавать эту информацию другими способами.

5.8.1.2. Цифровая подпись

Подписывающая сторона должна выбрать алгоритм цифровой подписи на основе алгоритмов, поддерживаемых получателем.

Ключ асимметричной цифровой подписи

Ключ цифровой подписи, который используется для формирования подписи контента, должен быть связан с открытым ключом, используемым для проверки цифровой подписи и опубликованным отправителем в его документе JWK Set. Если в указанном документе JWK Set есть несколько ключей, в JOSE-заголовке должно присутствовать значение параметра <kid>. Параметр <use> соответствующего ключа должен указывать на то, что этот ключ поддерживает алгоритм цифровой подписи ("sig").

Ключ кода аутентификации сообщения

При использовании подписи JWS на основе кода аутентификации сообщения (MAC) значение параметра <alg> JOSE заголовка должно быть равно идентификатору алгоритма MAC. Используемый ключ MAC - это октеты UTF-8 представления значения <client_secret>. Требования к энтропии значений <client_secret> см. в пункте 5.8.2. Симметричная подпись не должна использоваться публичными клиентами из-за их неспособности сохранять ключ клиента.

5.8.1.3. Смена асимметричных ключей подписи

Смена асимметричных ключей цифровой подписи может быть выполнена с помощью следующего подхода. Подписывающий публикует свои ключи в документе JWK Set, местоположение которого указывает в качестве значения параметра <jwks_uri> документа Discovery (см. подпункт 5.4.4.1), и включает идентификатор ключа цифровой подписи в качестве значения параметра <kid> JOSE-заголовка каждого JWS сообщения, чтобы указать проверяющему, какой ключ должен использоваться для проверки цифровой подписи. Ключи можно обновлять, периодически добавляя новые ключи проверки цифровой подписи в JWK Set по адресу <jwks_uri>. Подписывающий может начать использовать новый ключ цифровой подписи по своему усмотрению, сигнализируя об этом проверяющему, использовав новое значение параметра <kid>. Проверяющий понимает, что, обнаружив незнакомое значение параметра <kid>, он должен обратиться по адресу <jwks_uri> для повторного получения ключей отправителя. Документ JWK Set по адресу <jwks_uri> должен сохранять недавно выведенные из действия ключи проверки цифровой подписи в течение периода времени, соответствующего требованиям к СКЗИ.

5.8.1.4. Шифрование

Отправитель, выполняющий шифрование передаваемой информации, должен выбрать алгоритм шифрования из тех алгоритмов, которые поддерживает получатель. Перечень этих алгоритмов указан в конфигурации сервера авторизации (см. подпункт 5.4.4.1) и клиента (см. подпункт 5.4.4.5).

Асимметричное шифрование на основе арифметики эллиптической кривой

Генерируется эфемерный открытый ключ с использованием арифметики эллиптической кривой в качестве элемента <epk> JOSE-заголовка JWE. Второй открытый ключ, используемый для ключевого соглашения (key agreement), должен быть открытым ключом, опубликованным получателем в его документе JWK Set. Если в указанном документе JWK Set есть несколько ключей, в JOSE-заголовке JWE должно быть указано значение параметра <kid>. Для согласования ключа шифрования контента, который будет использован для шифрования подписанного JWT, следует использовать алгоритм ключевого соглашения с использованием арифметики эллиптической кривой. Параметр <use> соответствующего ключа должен включать шифрование ("enc").

Симметричное шифрование

Симметричный ключ шифрования вычисляется из значения <client_secret> с использованием усеченного слева хэш-кода октетов UTF-8 представления параметра <client_secret>. Симметричное шифрование не должно использоваться публичными клиентами из-за их неспособности сохранять ключ клиента.

5.8.1.5. Смена асимметричных ключей шифрования

При смене ключей шифрования следует использовать процесс, отличный от процесса смены ключей цифровой подписи, поскольку процесс смены открытого ключа получателя запускает получатель, не являющийся отправителем (шифрующим), и, таким образом, отправитель не может полагаться на изменение параметра <kid> в качестве сигнала о необходимости смены ключей. Шифрующий продолжает использовать прежний параметр <kid> в заголовке JWE. При этом он должен выбрать наиболее подходящий ключ из представленных в JWK Set, расположенном по адресу <jwks_uri> получателя. При отсутствии в JWK Set открытого ключа получателя с разрешенным сроком использования шифрование не допускается. Об этом следует сообщить получателю, пользуясь другим надежным каналом связи.

Для смены ключей расшифровывающая сторона своевременно должна опубликовать новые ключи по своему адресу <jwks_uri> и удалить из JWK Set те ключи, которые выводятся из эксплуатации. Должны быть приняты меры по корректному кэшированию <jwks_uri> в соответствии с рекомендациями пункта 10.2.1 [11]. Получатель должен удалить отозванные ключи из JWK Set, но сохранять их у себя в течение некоторого периода времени, согласованного с продолжительностью кэша, чтобы обеспечить плавный переход между ключами, предоставляя отправителю некоторое время на загрузку новых ключей. Продолжительность кэша следует также координировать с выдачей новых ключей подписи, как описано в подпункте 5.8.1.3.