4.2.1.3. Предназначение (применимость) ключа «keyUsage»
Субполе «keyUsage» в поле «Расширения» устанавливает назначение ключа, представленного в сертификате (например, шифрование, подпись, подпись сертификата). Сферы использования ключа могут быть ограничены, в частности тогда, когда ключ мог бы использоваться в нескольких процедурах, но в конкретной процедуре его использование запрещено. Например, если RSA-ключ должен использоваться только при проверке подписей на электронных документах, не являющихся СЕРТ|ОК или СОС, то биты (флаги) «digitalSignature» и/или «nonRepudiation» будут установлены в «1». Более того, если RSA-ключ должен использоваться только в процедурах обеспечения ключами, то бит (флаг) «keyEncipherment» будет установлен в «1».
УЦ, придерживающиеся данного стандарта, обязаны включать это субполе в сертификаты, которые содержат открытые ключи, использующиеся при подтверждении подлинности (ПП) ЭЦП на электронных документах, не являющихся СЕРТ|ОК или СОС. УЦ, придерживающиеся данного стандарта, обязаны помечать данное субполе как «критичное» («critical»).
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- в последних редакциях стандарта X.509 бит
-- переименован в «contentCommitment»
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
Биты, входящие в состав субполя «keyUsage» поля «Расширения» используются следующим образом:
Бит «digitalSignature» («№0») устанавливается в значение «1», когда открытый ключ владельца сертификата используется для ПП ЭЦП на электронных документах, не являющихся СЕРТ|ОК (бит №5) или СОС (бит №6). Данный ключ используется службами аутентификации объекта и источника данных и/или обеспечения целостности.
Бит «nonRepudiation» («№1») устанавливается в значение «1», когда открытый ключ владельца сертификата используется для проверки ЭЦП на электронных документах, не являющихся СЕРТ|ОК (бит №5) или СОС (бит №6). Данный ключ используется службой неотказуемости, которая обеспечивает защиту от ложного отказа автора подписи от его участия в каком-либо процессе или какой-либо процедуре (действии). Если в дальнейшем возникает конфликтная ситуация, то доверенная третья сторона (ДТС) может определить подлинность и достоверность подписанных данных.
Примечание. В последних редакциях Рекомендации ITU-T X.509 этот бит переименован в «contentCommitment».
Бит «keyEncipherment» («№2») устанавливается в значение «1», когда открытый ключ владельца сертификата используется для зашифрования закрытых или секретных ключей, т.е. при доставке ключа. Например, этот бит будет установлен в «1», когда открытый RSA-ключ предназначен для зашифрования симметричного ключа, необходимого для расшифрования соответствующих данных, или ассиметричного закрытого ключа.
Бит «dataEncipherment» («№3») устанавливается в значение «1», когда открытый ключ владельца сертификата используется для непосредственного зашифрования незащищённых данных пользователя без применения промежуточного симметричного шифрования.
Примечание. Использование этого бита встречается чрезвычайно редко. Почти все прикладные системы при формировании симметричного ключа используют процедуры доставки или согласования ключа.
Бит «keyAgreement» («№4») устанавливается в значение «1», когда открытый ключ владельца сертификата используется в процедурах согласования ключей. Например, если данный ключ используется в процедуре обеспечения ключами на основе алгоритма Диффи-Хеллмэна (Diffie-Hellman), то этот бит будет установлен в «1».
Бит «keyCertSign» («№5») устанавливается в значение «1», когда открытый ключ владельца сертификата используется в процедурах проверки подписей в СЕРТ|ОК. Если бит «keyCertSign» установлен в значение «1», то и бит «cA» субполя «Basic constraints» в поле «Расширения» должен в обязательном порядке иметь значение «1».
Бит «cRLSign» («№6») устанавливается в значение «1», когда открытый ключ владельца сертификата используется в процедурах проверки подписей в СОС (например, СОС, усечённый СОС (delta CRL) или УЦ-СОС (ARL)).
Если отсутствует бит «keyAgreement», то значение бита «encipherOnly» («№7») не установлено. Если же биты «encipherOnly» и «keyAgreement» одновременно установлены в значение «1», то открытый ключ владельца сертификата может использоваться в процессе зашифрования данных, пока проводится процедура согласования ключа.
Если отсутствует бит «keyAgreement», то значение бита «decipherOnly» («№8») не установлено. Если же биты «decipherOnly» и «keyAgreement» одновременно установлены в значение «1», то открытый ключ владельца сертификата может использоваться в процессе расшифрования данных, пока проводится процедура согласования ключа.
Если в поле «Расширения» присутствует субполе «keyUsage», то открытый ключ владельца сертификата не должен, в обязательном порядке, использоваться для проверки подписей в сертификатах и СОС, причём до тех пор, пока соответствующий бит «keyCertSign» или «cRLSign» не будет установлен в значение «1». Если открытый ключ владельца сертификата предназначен для проверки подписей в сертификатах и/или СОС, то не целесообразно устанавливать биты «digitalSignature» и/или «nonRepudiation» в значение «1». Тем не менее, биты «digitalSignature» и/или «nonRepudiation» могут быть дополнительно установлены в «1», если открытый ключ владельца сертификата предназначен для проверки подписей в сертификатах и/или СОС, а также и в других электронных документах.
Совместное использование бита «nonRepudiation» с другими битами субполя «keyUsage» в поле «Расширения» может означать наличие прикладных аспектов обеспечения безопасности в зависимости от сферы применения сертификата. Последующие различия между битами «digitalSignature» и «nonRepudiation» могут установлены соответствующими политиками сертификации.
Данный стандарт не устанавливает каких-либо ограничений на комбинации бит, которые могут встречаться при использовании субполя «keyUsage» в поле «Расширения». Однако, стандарты RFC-3279, RFC-4055 и RFC-4491 в интересах соответствующих криптоалгоритмов устанавливают дополнительные обязательные правила кодирования субполя «keyUsage». Когда в поле «Расширения» сертификата присутствует субполе «keyUsage», тогда, по крайней мере, один бит должен, в обязательном порядке, иметь значение «1».