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

Сертификаты очень часто используются в криптографии. От поиска я немного запутался, что точно по существу является «открытым ключом» внутри сертификата? Всегда ли это ключ проверки подписи, или это также может быть ключ шифрования?

Насколько я понимаю, для корневых и промежуточных сертификатов CA открытый ключ всегда должен быть ключом проверки подписи. Но верно ли это и для листового сертификата (конечной сущности)?

Пожалуйста, добавьте ссылки на аутентичные ресурсы для поддержки ваших ответов и для дальнейшего чтения.

Всегда ли это ключ проверки подписи или он также может быть ключом шифрования?

Листовой открытый ключ (то есть ключ, принадлежащий конечному объекту) наверняка может быть ключом шифрования (или, если уж на то пошло, общедоступным значением обмена ключами, например общим ключом DH). Подобные обычаи не так уж экзотичны.

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

Расширение использования ключа может указывать любое или все из: digitalSignature, contentCommitment (аналогично digitalSignature, но с другими последствиями), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign (сертификат ЦС будет иметь этот и, возможно, некоторые другие) и cRLSign. Один с использованием keyAgreement также может иметь encipherOnly или decipherOnly, чтобы изменить это.

Например, у меня есть сертификат электронной почты (S/MIME), в котором в расширении использования ключа установлены биты digitalSignature, keyEncipherment и dataEncipherment. Это означает, что кто-то может использовать его для проверки подписи в сообщении электронной почты, которое я отправил им, а также для шифрования сообщения мне (обычно путем шифрования случайного симметричного ключа, который будет использоваться для шифрования фактического сообщения).

В качестве другого примера предположим, что у вас есть сертификат, в расширении использования ключа которого установлен только бит keyAgreement. Это означало бы, что его нельзя использовать ни для проверки подписи, или же шифрование, но Только для согласования ключей с помощью чего-то вроде алгоритма Диффи-Хеллмана.

Кстати, использование ключа можно ограничить и другими способами. Например, поле «алгоритм» ключа эллиптической кривой обычно задается как id-ecPublicKey (что не накладывает на него дополнительных ограничений), но может быть задано как id-ecDH (это означает, что его можно использовать только для соглашения о ключах EC Диффи-Хеллмана). ) или id-ecMQV (это означает, что его можно использовать только для соглашения о ключах EC Menezes-Qu-Vanstone).