1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 02 октября 2022 в 13:53
Снять ограничение

ГОСТ Р ИСО 17090-2-2016

Информатизация здоровья. Инфраструктура с открытым ключом. Часть 2. Профиль сертификата
Действующий стандарт
Проверено:  24.09.2022

Информация

Название Информатизация здоровья. Инфраструктура с открытым ключом. Часть 2. Профиль сертификата
Название английское Health informatics. Public key infrastructure. Part 2. Certificate profile
Дата актуализации текста 05.05.2017
Дата актуализации описания 01.01.2021
Дата издания 03.12.2018
Дата введения в действие 01.01.2018
Область и условия применения Настоящий стандарт определяет основные профили сертификатов, требуемые для обмена медицинской информацией внутри одной организации, между организациями и при трансграничном обмене. Он описывает детали применения цифровых сертификатов в отрасли здравоохранения и фокусируется, в частности, на особенностях профилей сертификатов, специфичных для здравоохранения
Опубликован Официальное издание. М.: Стандартинформ, 2018 год
Утверждён в Росстандарт
Взамен ГОСТ Р ИСО 17090-2-2010ГОСТ недействующий


ГОСТ Р ИСO 17090-2-2016

     

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ



Информатизация здоровья


ИНФРАСТРУКТУРА С ОТКРЫТЫМ КЛЮЧОМ


Часть 2


Профиль сертификата


Health informatics. Public key infrastructure. Part 2. Certificate profile

     
ОКС 35.240.80
ОКСТУ 4002

Дата введения 2018-01-01

     

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации" (ЦНИИОИЗ Минздрава) и Обществом с ограниченной ответственностью "Корпоративные электронные системы" на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 "Информатизация здоровья" при ЦНИИОИЗ Минздрава - постоянным представителем ISO ТС 215

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 декабря 2016 г. N 2103-ст

4 Настоящий стандарт идентичен международному стандарту ИСО 17090-2:2015* "Информатизация здоровья. Инфраструктура с открытым ключом. Часть 2. Профиль сертификата" (ISO 17090-2:2015 "Health informatics - Public key infrastructure - Part 2: Certificate profile", IDT).

________________

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


При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВЗАМЕН ГОСТ Р ИСО 17090-2-2010

6 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение


Перед системой здравоохранения стоит проблема сокращения расходов с помощью перехода от бумажного документирования процессов к электронному. В новых моделях оказания медицинской помощи особо подчеркивается необходимость совместного использования сведений о пациенте расширяющимся кругом медицинских специалистов, выходящего за рамки традиционных организационных барьеров.

Персональная медицинская информация обычно передается с помощью электронной почты, удаленного доступа к базе данных, электронного обмена данными и других приложений. Среда Интернет предоставляет высокоэффективные и доступные средства обмена информацией, однако она не безопасна и при ее использовании необходимо принимать дополнительные меры обеспечения конфиденциальности и неприкосновенности личной жизни. Усиливаются такие угрозы безопасности, как случайный или преднамеренный несанкционированный доступ к медицинской информации, и системе здравоохранения необходимо иметь надежные средства защиты, минимизирующие риск несанкционированного доступа.

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

Для правильного применения цифровых сертификатов требуется сочетание технологических, методических и административных процессов, обеспечивающих защиту передачи конфиденциальных данных в незащищенной среде с помощью "шифрования с открытым ключом" и подтверждение идентичности лица или объекта с помощью "сертификатов". В сфере здравоохранения в это сочетание входят средства аутентификации, шифрования и электронной подписи, предназначенные для выполнения административных и клинических требований конфиденциальности доступа и передачи медицинских документов индивидуального учета. Многие из этих требований могут быть удовлетворены с помощью служб, использующих применение цифровых сертификатов (включая шифрование, целостность информации и электронные подписи). Особо эффективно использование цифровых сертификатов в рамках официального стандарта защиты информации. Многие организации во всем мире начали использовать цифровые сертификаты подобным образом.

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

Для обеспечения интероперабельности различных систем, использующих цифровые сертификаты, необходимо создать систему доверительных отношений, с помощью которой стороны, ответственные за обеспечение прав личности на защиту персональной информации, могут полагаться на политики и практические приемы и в дополнение на действительность электронных сертификатов, выданных другими уполномоченными организациями.

Во многих странах система цифровых сертификатов используется для обеспечения безопасного обмена информацией в пределах национальных границ. Если разработка стандартов также ограничена этими пределами, то это приводит к несовместимости политик и регламентов удостоверяющих центров (УЦ) и центров регистрации (ЦР) разных стран.

Технология цифровых сертификатов активно развивается в рамках определенных направлений, не специфичных для здравоохранения. Непрерывно проводится важнейшая работа по стандартизации и в некоторых случаях по правовому обеспечению. С другой стороны, поставщики медицинских услуг во многих странах уже используют или планируют использовать цифровые сертификаты. Настоящий стандарт призван удовлетворить потребность в управлении данным интенсивным международным процессом.

Настоящий стандарт содержит общие технические, эксплуатационные и методические требования, которые должны быть удовлетворены для обеспечения использования цифровых сертификатов в целях обмена медицинской информацией в пределах одного домена, между доменами и за пределами границ одной юрисдикции. Его целью является создание основ глобальной интероперабельности. Настоящий стандарт изначально предназначен для поддержки трансграничного обмена данными на основе цифровых сертификатов, однако он также может служить руководством по широкому использованию цифровых сертификатов в здравоохранении на национальном или региональном уровнях. Интернет все шире используется как средство передачи медицинских данных между организациями здравоохранения и является единственным реальным вариантом для трансграничного обмена данными в этой сфере.

Серия стандартов ИСO 17090 должна рассматриваться как единое целое, поскольку каждая из трех ее частей вносит свой вклад в определение того, как цифровые сертификаты могут использоваться для обеспечения сервисов безопасности в системе здравоохранения, включая аутентификацию, конфиденциальность, целостность данных и технические возможности поддержки качества электронной подписи.

ИСО 17090-1 определяет основные принципы применения цифровых сертификатов в сфере здравоохранения и определяет структуру требований к интероперабельности, необходимых для создания системы защищенного обмена медицинской информацией на основе применения цифровых сертификатов.

ИСО 17090-2 определяет специфичные для сферы здравоохранения профили электронных сертификатов, основанных на Международном стандарте Х.509 и его профиле, определенном в спецификации IETF/RFC 5280 для разных типов сертификатов.

ИСО 17090-3 имеет отношение к проблемам управления, связанным с внедрением и эксплуатацией цифровых сертификатов в сфере здравоохранения. В нем определены структура политик сертификатов и минимальные требования к ним, а также структура сопутствующих отчетов по практическому применению сертификации. ИСО/ТС 17090-3 основан на информационных рекомендациях IETF/RFC 3647 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" (основы политик сертификатов и отчетов по практическому применению сертификации в инфраструктуре открытых ключей, соответствующей стандарту Х.509 и использующей Интернет) и определяет принципы политик безопасности медицинской информации при ее трансграничной передаче. В ней также определен минимально необходимый уровень безопасности применительно к аспектам, специфичным для сферы здравоохранения.

     1 Область применения


Настоящий стандарт определяет основные профили сертификатов, требуемые для обмена медицинской информацией внутри одной организации, между организациями и при трансграничном обмене. Он описывает детали применения цифровых сертификатов в отрасли здравоохранения и фокусируется, в частности, на особенностях профилей сертификатов, специфичных для здравоохранения.

     2 Нормативные ссылки


В настоящем стандарте использованы нормативные ссылки на следующие стандарты*:

________________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - Примечание изготовителя базы данных.


ISO 17090-1, Health informatics - Public key infrastructure - Part 1: Overview of digital certificate services (Информатизация здоровья. Инфраструктура с открытым ключом. Часть 1. Структура и общие сведения)

ISO 17090-3, Health informatics - Public key infrastructure - Part 3: Policy management of certification authority (Информатизация здоровья. Инфраструктура с открытым ключом. Часть 3. Управление политиками удостоверяющего центра)

IETF/RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) [Интернет. Профиль сертификата Х.509 инфраструктуры открытых ключей и списка отозванных сертификатов (CRL)]

     3 Термины и определения


В настоящем стандарте применены термины по ИСО 17090-1.

     4 Сокращения


В настоящем стандарте применены следующие сокращения:

ЦА - центр присвоения атрибутов (АА - attribute authority);

СА - сертификат атрибута (АС - attribute certificate);

УЦ - удостоверяющий центр (СА - certification authority);

ПС - политика сертификации (СР - certificate policy);

ОПС - отчет о практике сертификации (CPS - certification practice statement);

СОС - список отозванных сертификатов (CRL - certificate revocation list);

СОК - сертификат открытого ключа (РКС - public key certificate);

ИОК - инфраструктура открытых ключей (PKI - public key infrastructure);

ЦР - центр регистрации (RA - registration authority);

ДТС - доверенная третья сторона (ТТР - trusted third party).

     5 Политики сертификации в здравоохранении

     5.1 Типы сертификатов, необходимых для здравоохранения


Сертификаты идентичности должны выдаваться:

- физическим лицам (квалифицированным медицинским работникам, вспомогательным медицинским работникам, субсидируемым поставщикам медицинских услуг, работникам поддерживающих организаций, а также пациентам/потребителям медицинской помощи);

- организациям (организациям здравоохранения и поддерживающим организациям);

- устройствам;

- приложениям.

Роли физических лиц и организаций должны быть записаны либо в самом сертификате идентичности (в расширении сертификата) или в ассоциированном СА. Различные типы сертификата и их взаимоотношения показаны на рисунке 1.

     5.2 Сертификаты удостоверяющего центра

5.2.1 Сертификаты корневых удостоверяющих центров

Сертификаты корневых удостоверяющих центров используются, если удостоверяющий центр (УЦ) сам является субъектом сертификата. Они самоподписаны и применяются для выпуска сертификатов доверяющим им сторонам, включая подчиненные УЦ. Поле основных ограничений содержит признак, что субъектом сертификата является УЦ.

5.2.2 Сертификаты подчиненных УЦ

Сертификаты подчиненных УЦ выпускаются для УЦ, которые сертифицируются другим вышестоящим УЦ, наделенным правом выпускать сертификаты или для других подчиненных УЦ, или для объектов.

Рисунок 1 - Типы сертификатов, используемых в здравоохранении

     5.3 Кросс-сертификаты (сертификаты посреднических УЦ)


В среде Интернет не приходится рассчитывать на наличие УЦ верхнего уровня, которому будут доверять организации здравоохранения, если они подчинены разным ведомствам или должны участвовать в трансграничном обмене информацией. Вместо этого в системе здравоохранения должны создаваться отдельные "островки доверия", каждый со своим корневым УЦ, обслуживающим группу учреждений здравоохранения, образованную по признаку специализации, ведомственной подчиненности, или географического расположения. Каждый корневой УЦ каждого "островка доверия" должен выдать кросс-сертификат другому корневому УЦ. В такой ситуации группа УЦ может согласовать минимальный набор стандартов, включаемый в их политики и соответствующие отчеты о практике сертификации. Как только это сделано, доверяющая сторона может принять сертификат от УЦ, находящегося за пределами ее домена. Этот подход может быть особенно полезен региональным органам управления здравоохранением для организации межтерриториального обмена информацией.

Для взаимной сертификации различных доменов УЦ используется особый тип сертификатов - кросс-сертификаты (сертификаты посреднических УЦ). С их помощью обеспечивается масштабное развертывание приложений открытых ключей, например защищенная электронная почта и другие приложения, требуемые для системы здравоохранения.

     5.4 Сертификаты конечных объектов


Сертификаты конечных объектов выдаются таким объектам, как лица, организации, приложения или устройства. Они называются сертификатами конечных объектов, поскольку они не используются для выдачи сертификатов другим объектам.

5.4.1 Сертификаты идентичности лиц

Сертификаты идентичности лиц относятся к подтипу сертификатов конечных объектов и предназначены для выдачи отдельным лицам в целях аутентификации. Следующие пять типов действующих лиц в здравоохранении рассматриваются как отдельные лица:

а) квалифицированные медицинские работники:

- каждый владелец такого сертификата является медицинским работником, которому для выполнения профессиональных обязанностей необходим сертификат или лицензия от органа государственного управления (см. ИСО 17090-1, подраздел 5.1), эти сертификаты могут иметь тип аттестационного сертификата (см. ИСО 17090-1, подраздел 8.2 и подраздел 7.3 настоящего стандарта);

b) вспомогательные медицинские работники:

- каждый владелец такого сертификата является медицинским работником, которому для выполнения профессиональных обязанностей не требуется сертификат или лицензия от органа государственного управления (см. ИСО 17090-1:2008, подраздел 5.1), эти сертификаты могут иметь тип аттестационного сертификата;

с) субсидируемый поставщик медицинских услуг:

- каждый владелец такого сертификата является лицом, выполняющим определенные обязанности в системе здравоохранения по субсидии официальной организации здравоохранения или частнопрактикующего врача. Эти сертификаты могут иметь тип аттестационного сертификата;

d) работник поддерживающей организации:

- каждый владелец такого сертификата является работником организации здравоохранения или поддерживающей организации. Эти сертификаты могут иметь тип аттестационного сертификата;

е) пациент/потребитель медицинской помощи:

- каждый владелец такого сертификата является лицом, которое на определенном этапе либо получало, либо получает услуги квалифицированного или вспомогательного медицинского работника. Эти сертификаты могут иметь тип аттестационного сертификата.

5.4.2 Сертификат идентичности организации

Организация, связанная с системой здравоохранения, может владеть сертификатом в целях идентификации или для шифрования данных. В настоящем стандарте предусмотрено указание ее наименования в поле сертификата в соответствии с IETF/RFC 3647.

5.4.3 Сертификат идентичности устройства

Индивидуальная идентификация и аутентификация может требоваться таким устройствам, как сервер или медицинский прибор, например устройство лучевой диагностики, монитор жизненно важных показателей или протезирующее устройство.

5.4.4 Сертификат приложения

Индивидуальная идентификация и аутентификация могут быть необходимы такому приложению, как автоматизированная информационная система, например, система учета коечного фонда и движения пациентов.

Хотя настоящий стандарт посвящен в основном применению сертификатов поставщиков медицинской помощи, необходимо отметить, что пациентам/потребителям медицинских услуг для контроля своего здоровья все чаще необходимы данные, для защиты которых могут применяться цифровые сертификаты.

5.4.5 СА

СА представляет собой сертифицированную или заверенную цифровой подписью совокупность атрибутов. Структура СА похожа на структуру СОК; основное отличие в том, что СА не содержит открытый ключ. СА может содержать атрибуты, специфицирующие членство в группе, категорию допуска к информации и другие сведения о владельце сертификата, которые могут быть использованы для контроля доступа. Структура СА должна соответствовать спецификации IETF/RFC 3281 "An Internet Attribute Certificate Profile for Authorization" (профиль сертификата атрибута для авторизации в сети Интернет).

В системе здравоохранения СА могут выполнять существенную роль носителя сведений об авторизации. Сведения об авторизации отличаются от информации о роли работника в системе здравоохранения или от лицензий, которая может быть передана в сертификате открытого ключа. Наличие роли или лицензии влияет на авторизацию, но само по себе не обязательно идентично авторизации. Важно отметить, что детальная спецификация АС еще не устоялась и будет уточняться по мере более широкого применения разработчиками информационных систем.

Синтаксис СА описан в спецификации IETF/RFC 3281 "An Internet Attribute Certificate Profile for Authorization".

Компоненты СА используются следующим образом.

Разные версии СА отличаются по номеру версии version. Если в СА присутствует поле свертки objectDigestlnfo или если поле baseCertificatelD идентифицирует издателя сертификата, то номер версии version должен быть v2.

Поле owner задает идентичность владельца СА. Обязательно должны быть указаны наименование издателя и серийный номер конкретного СОК. Может быть указано одно или несколько общих наименований, а указание свертки объекта запрещено. Использование общих наименований GeneralName самих по себе в качестве идентификации владельца представляет тот риск, что они могут не обеспечить достаточно точной привязки наименования к открытому ключу, что затруднит применение СА для аутентификации идентичности владельца. Кроме того, некоторые формы общих наименований GeneralName (например, IPAddress) не годятся для именования владельца СА, которого скорее можно отнести к роли, нежели к конкретному объекту. Необходимо ограничиться применением таких форм общего наименования, как отличительные имена, адреса, соответствующие спецификации ETF/RFC 822 (электронная почта), и (для имен ролей) объектные идентификаторы.

Поле issuer содержит идентификацию УЦ, выпустившего сертификат. Наименование издателя и серийный номер СОК должны быть указаны обязательно. Общие наименования указывать не обязательно.

Поле signature идентифицирует криптографический алгоритм, используемый для цифровой подписи СА.

Поле serialNumber содержит серийный номер, уникально идентифицирующий СА среди всех сертификатов, выпущенных его издателем.

Поле attrCertValidityPeriod задает срок действия СА, представленный в формате генерализованного времени GeneralizedTime.

Поле attributes содержит атрибуты владельца сертификата, которые заверяются этим сертификатом (например, привилегии доступа).

Поле issuerUniquelD может быть использовано для идентификации издателя СА в инстанциях, которым одного имени издателя недостаточно.

Поле extensions позволяет добавлять новые поля к СА.

Детали использования СА в здравоохранении описаны в ИСО 17090-1, подраздел 8.3.

5.4.6 Сертификаты роли

СА пользователя может содержать ссылку на другой СА, содержащий сведения о дополнительных привилегиях. Это является эффективным механизмом реализации привилегированных ролей.

В ряде организаций для выполнения определенных работ требуется авторизация на основе привилегий, назначенных ролям (обычно в сочетании с индивидуально назначенными привилегиями). Претендент на привилегии может представить контролеру нечто, демонстрирующее наличие у него определенной роли (например, роли "продавца" или роли "покупателя"). Контролер может знать априори или узнать с помощью каких-либо средств, какие привилегии связаны с этой ролью, и принять положительное или отрицательное решение об авторизации.

Возможны все следующие ситуации:

- любой СА может определять любое число ролей;

- сама роль и ее обладатели могут определяться и управляться раздельно с помощью отдельных СА;

- привилегии, назначенные данной роли, могут быть записаны в одном или нескольких СА;

- при необходимости обладателю роли может быть присвоено только подмножество привилегий, назначенных роли;

- обладание ролью может делегироваться;

- ролям и обладанию ролью могут быть назначены определенные сроки действия.

Объекту может быть присвоен СА, содержащий атрибут, уведомляющий, что этому объекту назначена определенная роль. Этот сертификат имеет расширение, содержащее указатель на другой СА, определяющий эту роль (такой сертификат роли указывает роль в качестве владельца и содержит список привилегий, назначенных этой роли). Издатели сертификата объекта и сертификата роли могут быть независимыми, и эти сертификаты могут управляться (прекращать действие, отзываться и т.д.) отдельно друг от друга.

Не все формы общего наименования GeneralName пригодны для использования в качестве имени роли. Полезнее всего использовать объектные идентификаторы и отличительные имена.

     6 Общие требования к сертификатам

     6.1 Соответствие сертификата


Ко всем сертификатам, определенным в настоящем стандарте, предъявляются следующие требования:

a) они должны являться сертификатами формата Х.509 версии 3;

b) они должны соответствовать спецификации IETF/RFC 5280. Отклонения от нее допускаются только в том случае, если они соответствуют предложенным решениям выявленных проблем этой спецификации;

c) сертификаты, подтверждающие индивидуальную идентичность, должны соответствовать спецификации IETF/RFC 3739. Отклонения от нее допускаются только в том случае, если они соответствуют предложенным решениям выявленных проблем этой спецификации;

d) поле signature должно идентифицировать используемый алгоритм электронной подписи;

e) минимальная длина сертифицированного открытого ключа должна зависеть от используемого алгоритма. Длины ключей должны соответствовать ИСО 17090-3, подпункт 7.6.1.5;

f) назначение ключа для шифрования dataEncipherment не должно сочетаться ни с неоспоримостью, ни с электронной подписью (см. 7.2.3).

Ниже описаны общие элементы всех цифровых сертификатов, предназначенных для здравоохранения и показанных на рис.1. Эти элементы одинаковы у различных типов сертификатов.

Certificate

::= SIGNED { SEQUENCE {

version

[0]

Version DEFAULT v1,

serialNumber

CertificateSerialNumber,

signature

Algorithmldentifier,

issuer

Name,

validity

Validity,

subject

Name,

subjectPublicKeylnfo

SubjectPublicKeylnfo,

issuerUniqueldentifier

[1]

IMPLICIT Uniqueldentifier OPTIONAL,

subjectUniqueldentifier

[2]

IMPLICIT Uniqueldentifier OPTIONAL,

extensions

[3]

Extensions MANDATORY.


В поле version указана версия кодированного сертификата. Ее значение должно равняться v3.

     6.2 Общие поля всех типов сертификатов

1) Поле serialNumber имеет целое значение, присваиваемое УЦ каждому сертификату. Оно предназначено для уникальной идентификации сертификатов. Значение serialNumber должно быть уникальным для каждого сертификата, выпущенного данным УЦ (то есть наименование издателя сертификата в сочетании с серийным номером является глобально уникальным идентификатором).

2) Поле signature содержит идентификатор алгоритма, использованного УЦ для подписи сертификата.

3) Поле issuer идентифицирует наименование организации, подписавшей и выпустившей сертификат. Значение этого поля представляет собой структуру имени ИСО, состав которой соответствует определению класса объектов роли в организации (organizational Role), находящегося под классом объектов организации organization или подразделения organizationUnit.

4) Поле validity содержит интервал времени, в течение которого УЦ гарантирует действительность информации, содержащейся в сертификате. При выдаче сертификата квалифицированному медицинскому работнику УЦ должен принять меры, чтобы срок действия цифрового сертификата не превысил срок действия сертификата специалиста или профессиональной лицензии. Чтобы выполнить это условие, УЦ должен либо установить срок действия цифрового сертификата не превышающим срока действия сертификата специалиста (профессиональной лицензии), либо надежным образом получить подтверждение, что сертификат специалиста (лицензия) продлен до истечения его срока действия, а если срок истек, а подтверждение не получено - отозвать цифровой сертификат или приостановить его действие.

Примечание - Отличительные правила кодирования (Distinguished Encoding Rules (DER)) разрешают использовать несколько способов форматирования значений даты и времени типа UTCTime и GeneralizedTime. Чтобы минимизировать проблемы с верификацией цифровой подписи, в реализациях стандарта важно использовать один и тот же формат. Если год больше или равен 2050, то время должно кодироваться, используя формат GeneralizedTime. Чтобы кодирование значений типа UTCTime было совместимым, необходимо кодировать их, используя формат "Z", и не опускать поле секунд, даже если оно имеет значение 00 (то есть формат должен быть YYMMDDHHMMSSZ). При таком кодировании поле года YY должно интерпретироваться как 19YY, если YY больше или равно 50, и как 20YY, если YY меньше 50. Когда используется тип GeneralizedTime, то значение этого типа должно кодироваться, используя формат "Z", и поле секунд должно быть включено (то есть формат должен быть YYYYMMDDHHMMSSZ).

5) Поле subject идентифицирует наименование субъекта, ассоциированного с открытым ключом, содержащимся в поле subjectPublicKeylnfo.

6) В поле subjectPublicKeylnfo хранятся открытый ключ и идентификатор алгоритма применения этого ключа.

7) Необязательное поле issuerUniqueldentifier представляет собой битовую строку, используемую для уникальной идентификации издателя (в соответствии со спецификацией IETF/RFC 5280 настоящий стандарт рекомендует не использовать это поле).

8) Необязательное поле subjectUniqueldentifier представляет собой битовую строку, используемую для уникальной идентификации субъекта (в соответствии со спецификацией IETF/RFC 5280 настоящий стандарт рекомендует не использовать это поле).

9) Поле extensions должно содержать последовательность из одного или нескольких расширений сертификата.

Подпись сертификата добавляется к типу данных сертификата с помощью стандартного типа данных SignedData, определенного в спецификации Х.509.

     6.3 Спецификации общих полей

6.3.1 Общие сведения

Ниже приведены специфичные требования к информации, содержащейся в базовых полях сертификата, которые еще не были включены в спецификацию IETF/RFC 5280 или IETF/RFC 3279.

6.3.2 Поле signature

Рекомендуется присваивать полю signature одно из следующих значений:

1. md5WithRSAEncryption (1.2.840.113549.1.1.4)

2. sha1WithRSAEncryption (1.2.840.113549.1.1.5)

3. dsa-with-sha1 (1.2.840.10040.4.3)

4. md2WithRSAEncryption (1.2.840.113549.1.1.2)

5. ecdsa-with-SHA1 (1.2.840.10045.4.1)

6. ecdsa-with-SHA224 (1.2.840.10045.4.3.1)

7. ecdsa-with-SHA256 (1.2.840.10045.4.3.2)

8. ecdsa-with-SHA384 (1.2.840.10045.4.3.3)

9. ecdsa-with-SHA512 (1.2.840.10045.4.3.4)

10. id-RSASSA-PSS (1.2.840.113549.1.1.10)

11. sha256WthRSAEncryption 1.2.840.113549.1.1.11

12. sha384WithRSAEncryption 1.2.840.113549.1.1.12

13. sha512WithRSAEncryption 1.2.840.113549.1.1.13

6.3.3 Поле validity

Значения дат срока действия, передаваемые в поле validity, должны соответствовать спецификации IETF/RFC 5280. В настоящем стандарте приняты ограничения сроков действия сертификатов, выдаваемых в системе здравоохранения, описанные в стандарте ИСО 17090-3, подраздел 7.6.3.2.

Момент времени notBefore, указанный в сертификате, отражает точный момент, начиная с которого УЦ будет управлять актуальной информацией о статусе сертификата и публиковать ее.

6.3.4 Поле subjectPublicKeylnfo

В этом поле должен быть задан идентификатор алгоритма, например:

1 Алгоритм RSA

pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)

rsadsi(113549)pkcs(1)1 }

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}

2 Алгоритм Diffie-Hellman

Объектный идентификатор алгоритма Diffie-Hellman, поддерживаемый в настоящем профиле, определен в стандарте ANSI X9.42:2003 [X9.42].

dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) ansi-x942(10046) number-type(2) 1 }

3 Алгоритм DSA

Объектный идентификатор алгоритма DSA, поддерживаемый в настоящем профиле, имеет значение

id-dsa ID ::= { iso(1) member-body(2) us(840)

x9-57(10040) x9cm(4) 1 }

4 Эллиптические кривые

Ecdsa {[1, 2, 840, 10045, 2, 1]}

Требования к размерам ключа см. в стандарте ИСО 17090-3, подраздел 7.6.1.5.

6.3.5 Поле наименования издателя issuer

Наименование издателя, хранящееся в поле issuer, должно иметь формат, совместимый с соответствующей структурой имени ИСО, состав которой соответствует определению класса объектов роли в организации organizationalRole, находящегося под классом объектов организации organization или подразделения organizationUnit, с приведенными ниже дополнениями и ограничениями.

Содержание поля наименования издателя issuer для каждого типа сертификата описано в подразделе 6.4.

1 Поле наименования страны countryName. Это поле должно содержать двухбуквенный код ИСО страны.

Пример - countryName="US".

Это поле обязательное, поскольку в сфере здравоохранения важно знать страну происхождения сертификата, предъявленного для запроса на доступ к персональной медицинской информации. В разных странах существуют свои законы по защите персональных данных и своя практика их применения, поэтому знание страны происхождения запроса на доступ поможет принять решение, удовлетворить его или нет.

2 Поле наименования местонахождения localityName. Это поле может использоваться для хранения, по меньшей мере, одного наименования местонахождения. Спецификация его формата задает два уровня наименования местонахождения. Верхний уровень указывает страну, после которой указано географическое наименование местонахождения. В поле наименования издателя сертификата поле localityName страны можно опустить и ограничиться только полем localityName географического местонахождения.

Пример - localityName="California".

3 Поле наименования организации organizationName. Это поле, которое используется для хранения наименования субсидирующей организации здравоохранения в сертификате конечного объекта и наименования удостоверяющего центра в сертификате УЦ, должно содержать полное официальное наименование организации.

Пример - organizationName="California Hospital Authority".

4 Поле наименования подразделения organizationalUnitName. Если это поле присутствует, то оно используется для хранения наименования подразделения данной организации. Можно задавать несколько уровней подчиненности подразделений, задавая более одного значения этого поля. Если это поле указано, то его значение должно выбираться таким образом, чтобы исключить его неоднозначность в домене данного УЦ.

Пример - organizationalUnitName="Midtown Hospital Radiology".

5 Поле общего наименования commonName. Назначение этого поля - описание общеупотребительного наименования издателя. Это поле в сочетании с общим наименованием субъекта commonName нередко используется стандартными компонентами программного обеспечения при выдаче пользователю информации о сертификате. Поэтому наименование должно быть информативным, чтобы дать хорошее представление о назначении сертификата и его издателе. Кроме того, рекомендуется включать в значение поля commonName наименование управляющей политики сертификации. Оно служит дополнением к идентификации политики с помощью объектного идентификатора.

Пример - commonName="Patient Health Information Policy".

6.3.6 Поле наименования субъекта subject

Наименование субъекта, хранящееся в поле subject, должно иметь формат, совместимый с соответствующей структурой имени ИСО, состав которой соответствует определению класса объектов роли в организации organizationalRole, находящегося под классом объектов организации organization или подразделения organizationUnit, с приведенными ниже дополнениями и ограничениями.

Квалификация и должности участников системы здравоохранения отражаются в поле hcRole расширения сертификата.

Содержание поля наименования субъекта subject для каждого типа сертификата описано в разделе 6.4. Дополнительные советы и указания можно найти в документе ISO/TS 21091 Health informatics - Directory services for healthcare providers, subjects of care and other entities (Информатизация здоровья. Службы каталога для поставщиков медицинской помощи, субъектов медицинской помощи и других объектов).

1 Поле наименования страны countryName. Это поле должно содержать двухбуквенный код ИСО страны.

Пример - countryName="US".

Практика заполнения этого поля зависит от конкретной страны.

Это поле обязательное для УЦ, квалифицированных и вспомогательных медицинских работников, субсидируемых поставщиков медицинских услуг, организаций и работников поддерживающих организаций, поскольку в сфере здравоохранения важно знать страну происхождения субъекта, предъявляющего сертификат для запроса на доступ к персональной медицинской информации. В разных странах существуют свои законы по защите персональных данных и своя практика их применения, поэтому знание страны происхождения запроса на доступ поможет принять решение, удовлетворить его или нет.

2 Поле наименования местонахождения localityName. Это поле может использоваться для хранения по меньшей мере одного наименования местонахождения. Спецификация его формата задает два уровня наименования местонахождения. Верхний уровень указывает страну, после которой указано географическое наименование местонахождения. В поле имени субъекта сертификата поле localityName страны можно опустить и ограничиться только полем localityName географического местонахождения.

Закупки не найдены
Свободные
Р
Заблокированные
Р
Роль в компании Пользователь

Для продолжения необходимо войти в систему

После входа Вам также будет доступно:
  • Автоматическая проверка недействующих стандартов в закупке
  • Создание шаблона поиска
  • Добавление закупок в Избранное