ГОСТ ISO/TS 22600-3—2013
лицу). Если указано имя лица, то удокументадолжна быть подпись, которую можно проверитьс помощью одного из
сертификатов пользователя. Если идентифицирован конкретный сертификат (по имени и идентификатору ключа
либо по имени издателя и серийному номеру), то у документа должна быть подпись, которую можно проверить с
помощью указанного сертификата. Если указан список целей подписи, то удокумента должна быть подпись, в кото
рой указана какая-либоизэтих целей (в атрибуте slgnaturePurpose подписи). Еслиуказаны иидентификатор лица, и
цели подписи, то в подписи этого лица должна быть указана одна из этих целей.
Каждой подписи документа может бытьприсвоен необязательный весна тотслучай, есличислоподписываю
щих лиц может быть переменным. Кворум задает суммарный вес. вычисляемый по списку подписавших лиц. при
котором документ считается утвержденным. Вобщем случае, когда все веса равны единице, кворум
указываетчис ло лиц. которые должны подписать документ. Присваивая веса, можно, к примеру, задать схему,
согласно которой для утверждения документа нужна подпись президента, любых двух вице-президентов или
любых четырех дирек торов. Нулевое значение кворума означает, что все лица, перечисленные в списке,
должны подписать документ. Может потребоваться указывать подпись в определенном порядке (совместная
подписьдокумента или заверение других подписей (24J).
А.10 Интеграция с инфраструктурой открытых ключей
Для идентификации сертификатов инфраструктура управления привилегиями должна полагаться на
инфраструктуру открытых ключей или. по крайней мере, должна быть сконструирована в расчете на нее. С
помощью этой инфраструктуры контролер аутентифицирует владельца сертификата атрибута (используя
электронные подписи). Каждый сертификататрибута либо содержит имя владельца, либо(что чаще)ссылкунасер
тификат идентификации владельца. Такое сращивание двух инфраструктур обеспечивает несколько уже описан
ных преимуществ.
Сертификаты атрибута выпускаются ОА. Эти органы могут иметь иерархическую организацию, подобную
иерархии центров сертификации. Когда подписчик запрашивает сертификат идентичности, то это не обязательно
влечет за собой выпусксертификатоватрибута. Такбывает в том случае,когда подписчики не распоряжаются свои
ми привилегиями.
Отзыв сертификатов атрибута осуществляется аналогично отзыву сертификатов идентификации (т. е. с
использованием списков отзыва). В другом варианте используется онлайновый протокол статуса сертификата
OCSP (online certificate status protocot). Однако обычно пользователь не обязан физически обладать своим серти
фикатом атрибута. Такие сертификаты могутхраниться сервисом каталога и простообновляться, если содержание
сертификата атрибута устарело. Вэтой модели отзыв сертификата ненужен, поскольку спомощью доступа кхрани
лищу сертификатов атрибута можно получить все текущие сертификаты атрибута.
В инфраструктуре управления привилегиями могут быть использованы два типа делегирования:
- ОА может делегировать свои полномочия подчиненным ОА или конечным пользователям В этом случае
полномочия возрастают по мере продвижения к корню иерархии. Контроль делегирования осуществляется с
помощью сертификатов, выпущенныхдля ОА:
- пользователи обращаются с запросом делегирования своей авторизации, и ОА выпускает соответствую
щий сертификат после проверки, что сертификатделегирующего пользователя разрешает делегирование. Иерар
хия подобного делегирования может быть выстроена с помощью использования в сертификатах атрибута
расширения delegatorAttnbuteldentifier.
Дальнейшее обсуждение интеграции инфраструктуры управления полномочиями с инфраструктурой откры
тых ключей см. в ISO/IEC 9S94-8.
А.11 Примеры приложений управления привилегиями и контроля доступа
А.11.1 Общиесведения
Здесь представлены несколько примеров приложений, использующих механизмы, определенные в
А.2—А.10. Они описаны не с высокой степенью детализации. Конкретные приложения могут быть описаны в буду
щих стандартах или в спецификациях разработчиков. Приведенные примеры служат иллюстрацией применения
механизмов управления привилегиями для поддержки типов приложений, описанных в рекомендациях
ASTM Е1762 и ASTM Е1986. Они также служат иллюстрацией текущей работы в области политик сертификации
и расширений.
А.11.2 Применение удостоверений
В этом примере врач выписывает контролируемую субстанцию. Рецепт заверяется электронной подписью и
отправляется в аптеку с помощью защищенных многоцелевых расширений электронной почты S/MIME
(secure/multipurpose internetmail extensions). Посколькув рецепте указана контролируемая субстанция, фармацевт
должен проверить, присвоен ли врачу действующий идентификатор Управления по борьбе с наркотиками (DEA).
Эту проверку можно выполнить по удостоверению врача в форме сертификата идентификации (ID) или сертифика та
атрибута. Удостоверениедолжно иметь тип «номер DEA», а его издателем должно быть Управление поборьбе с
наркотиками.
Аналогичные средства могут использоваться, чтобы определить, является ли лицо врачом (тип удостовере
ния «лицензия на право медицинской деятельности*). Чтобы узнать штат, в котором действительна лицензия вра
ча. можно проверить издателя удостоверения. Учтите, что при использовании отличительных имен правила
45