ГОСТ Р ИСО 17090-2—2010
5.4.5 Сертификат приложения
Индивидуальная идентификация и аутентификация могут потребоваться такому приложению, как
автоматизированная информационная система, например, система учета коечного фонда и движения
пациентов.
Хотя настоящий стандарт посвящен в основном применению сертификатов поставщиков меди
цинской помощи, необходимо отметить, что пациентам/потребителям медицинских услуг для контроля
своего здоровья все чаще необходимыданные, для защиты которых могут применяться цифровые сер
тификаты.
5.4.6 СА
СА представляет собой сертифицированную или заверенную цифровой подписью совокупность
атрибутов. Структура СА похожа на структуру СОК. Основное отличие состоит в том. что СА не содер
жит открытый ключ. СА может содержать атрибуты, специфицирующие членство в группе, категорию
допуска к информации идругие сведения о владельце сертификата, которые могут быть использованы
для контроля доступа. Структура СА должна соответствовать IETF/RFC 3281.
В системе здравоохранения СА может выполнять существенную роль носителя сведений об
авторизации.
Сведения об авторизации отличаются от информации о роли работника в системе здравоохране
ния или от лицензий, которые могут быть переданы в СОК. Наличие информации о роли или лицензии
влияет на авторизацию, но само по себе не обязательно идентично авторизации. Важно отметить, что
детальная спецификация СА еще неустоялась и будет уточняться помере более широкого
применения разработчиками информационных систем.
Синтаксис СА описан в IETF/RFC 3281.
Компоненты СА используются следующим образом.
Разные версии СА отличаются по номеру версии «version». Если в СА присутствует поле свертки
«objectDigostlnfo» или если поле «baseCertificatelD» идентифицирует издателя сертификата, то но
мер версии «version» должен быть «v2».
Поле «owner» задает идентичность владельца СА. Обязательно должны быть указаны наимено
вание издателя исерийный номер конкретного СОК. Могут бытьуказаны одно или несколькообщих наи
менований. а указание свертки объекта запрещено.
Использование общих наименований «GeneralName» в качестве идентификации владельца за
ключает в себе тот риск, что они не могут обеспечить достаточно точной привязки наименования к от
крытому ключу, что затруднит применение СА для аутентификации идентичности владельца. Кроме
того, некоторые формы общих наименований «GeneralName» (например. «IPAddress») не годятся для
наименования владельца СА. которого скорее можноотнести к роли, нежели к конкретному объекту. Не
обходимо ограничиться применением таких форм общего наименования, как отличительные имена, ад
реса. соответствующие спецификации ETF/RFC 822 [4] (электронная почта), и объектные
идентификаторы (для имен ролей).
Поле «issuer» содержит идентификацию ЦС. выпустившего сертификат. Наименование издателя
и серийный номер СОК должны быть указаны обязательно. Общие наименования указывать необяза
тельно.
Поле «signature» идентифицирует криптографический алгоритм, используемый для цифровой
подписи СА.
Поле «serialNumber» содержит серийный номер, уникально идентифицирующий СА среди всех
сертификатов, выпущенных его издателем.
Поле «attrCertValidityPeriod» задает срокдействия СА. представленный в формате генерализи
рованного времени «GeneralizedTime».
Поле «attributes» содержит атрибуты владельца сертификата, которые заверяются этим серти
фикатом (например, привилегии доступа).
Поле «issuerUniquelD» может быть использованодля идентификации издателя СА в инстанциях,
которым одного имени издателя недостаточно.
Поле «extensions» позволяет добавлять новые поля к СА.
Детали использования СА в здравоохранении приведены в ИСО 17090-1:2008. подраздел 8.4.
5.4.7 Сертификаты роли
СА пользователя может содержатьссылку надругой СА. содержащийсведения одополнительных
привилегиях. Это является эффективным механизмом реализации привилегированных ролей.
4