ГОСТ Р ИСО 17090-2—2010
В ряде организаций для выполнения определенных работ требуется авторизация на основе при
вилегий. назначенных ролям (обычно в сочетании с индивидуально назначенными привилегиями).
Претендент на привилегии может представить контролеру нечто, демонстрирующее наличие у
него определенной роли (например, роли «продавца» или роли «покупателя»). Контролер может знать
априори или узнать с помощью каких-либо средств, какие привилегии связаны с этой ролью, и
принять положительное или отрицательное решение об авторизации.
Возможны следующие ситуации:
- любой ЦА может определять любое число ролей;
- сама роль иее обладатели могут определяться иуправляться раздельно с помощью отдельных ЦА;
- привилегии, назначенные данной роли, могут быть записаны в одном или нескольких СА:
- при необходимости обладателю роли может присваиваться только подмножество привилегий,
назначенных роли;
- право владения ролью может делегироваться;
- ролям и правам владения ими могут назначаться определенные сроки действия.
Объекту может быть присвоен СА, содержащий атрибут, уведомляющий, что этому объекту назна
чена определенная роль. Этот сертификат имеет расширение, содержащее указатель на другой СА,
определяющий эту роль (такой сертификат роли указывает роль в качестве владельца и содержит спи
сок привилегий, назначенных этой роли). Издатели сертификата объекта и сертификата роли могут
быть независимыми, и эти сертификаты могут управляться (прекращать действие, отзываться и т. д.)
отдельно друг от друга.
Не все формы общего наименования «GeneralName» пригодны для использования в качестве
имени роли. Полезнее всего использовать объектные идентификаторы и отличительные имена.
6 Общие требования к сертификатам
6.1 Соответствие сертификата
Ко всем сертификатам, определенным в настоящем стандарте, предъявляются следующие
требования:
- они должны являться сертификатами формата Х.509 версии 3 (5);
- они должны соответствовать IETF/RFC 3280. Отклонения от нее допускаются только в том слу
чае. если они соответствуют предложенным решениям выявленных проблем этой спецификации;
- сертификаты, подтверждающие индивидуальную идентичность, должны соответствовать
IETF/RFC 3739. Отклонения от нее допускаются только в том случае, если они соответствуют предло
женным решениям выявленных проблем этой спецификации;
- поле «signature» должно идентифицировать используемый алгоритм цифровой подписи;
- минимальная длина сертифицированного открытого ключа должна зависеть от используемого
алгоритма. Длины ключей должны соответствовать ИСО 17090-3, подпункт 7.6.1.5;
- назначение ключа для шифрования не должно сочетаться ни с неоспоримостью, ни с цифровой
подписью (см. 7.2.3).
Ниже описаны общие элементы всех цифровых сертификатов, предназначенныхдля здравоохра
нения и показанных на рисунке 1. Эти элементы одинаковы у различных типов сертификатов.
version[0]
scrialNumbcr
signature
issuer
validity
subject
subjectPublicKeylnfo
issuerllniqueldentifier[1]
Certificate::= SIGNED { SEQUENCE {
Version DEFAULT v1,
CertificateSerialNumber,
Algorithmldentifior,
Name,
Validity,
Name,
SubjectPublicKeylnfo,
IMPLICIT Uniqueldentifier OPTIONAL,
subjectUniqueldontifier [2]IMPLICIT Uniqueldentifier OPTIONAL,
extensions[3]Extensions MANDATORY.
version версия кодированного сертификата. Должна иметь значение v3.
5