Необходимость защиты информации

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

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

Для чего нужна криптография

Система криптографической защиты должна обеспечивать:

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

Что такое криптография с открытыми ключами

Криптографическое преобразование (шифрование)- взаимно-однозначное математическое преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации (представленной в некоторой цифровой кодировке) блок шифрованной информации, также представленной в цифровой кодировке. Термин шифрование объединяет в себе два процесса: зашифрование и расшифрование информации.

Криптография делится на два класса: с симметричными ключами и открытыми ключами.

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

Преимущества криптографии с симметричными ключами:

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

Недостатки криптографии с симметричными ключами:

• Распределение ключей - Так как для шифрования и расшифрования используется один и тот же ключ, при использовании криптографии с симметричными ключами требуются очень надежные механизмы для распределения ключей.
• Масштабируемость - Так как используется единый ключ между отправителем и каждым из получателей, количество необходимых ключей возрастает в геометрической прогрессии. Для 10 пользователей нужно 45 ключей, а для 100 уже 499500.
• Ограниченное использование - Так как криптография с симметричными ключами используется только для шифрования данных и ограничивает доступ к ним, при ее использовании невозможно обеспечить аутентификацию и неотрекаемость.

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

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

Криптография с открытыми ключами требует наличия Инфраструктуры Открытых Ключей (PKI - Public Key Infrastructure) - неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.

Верификация открытого ключа

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

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

Верификация цепочки сертификатов

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

Процедура верификации цепочки сертификатов описана в рекомендациях X.509 и RFC 2459 и проверяет связанность между именем Владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все "правильные" цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации. Под доверенным центром понимается главный ЦС, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не обеспечивают безопасности. Для обеспечения доверия к открытому ключу такого сертификата должны быть применены специальные способы его распространения и хранения, так как на данном открытом ключе проверяются все остальные сертификаты.

Алгоритм верификации цепочек использует следующие данные:

• Х.500 имя Издателя сертификата;
• Х.500 имя Владельца сертификата;
• открытый ключ Издателя;
• срок действия открытого (секретного) ключа Издателя и Владельца;
• ограничивающие дополнения, используемые при верификации цепочек (basicConstraints, nameConstraints, policyConstrains);
• СОС для каждого Издателя (даже если он не содержит отзываемых сертификатов).

Цепочка сертификатов представляет собой последовательность из n сертификатов, в которой:

• для всех x в {1, (n-1)}, Владелец сертификата x есть Издатель сертификата x+1;
• сертификат x=1 есть самоподписанный сертификат;
• сертификат x=n есть сертификат конечного пользователя;

Одновременно с цепочкой сертификатов используется цепочка СОС, представляющая собой последовательность из n СОС, в которой:

• для всех СОС x в {1, n}, Издатель сертификата x есть Издатель СОС x;
• СОС x=1 есть СОС, изданный Владельцем самоподписанного сертификата;
• СОС x=n есть СОС, изданный Издателем сертификата конечного пользователя;

После построения двух цепочек (сертификатов и СОС) выполняется:

• криптографическая проверка сертификатов и СОС в цепочках;
• проверка сроков действия сертификатов и СОС;
• проверка соответствия имен Издателя и Владельца с использованием дополнения nameConstraints ;
• проверка длины цепочки с использованием дополнения basicConstraints ;
• проверка на отзыв сертификатов, причем, если сертификат промежуточного центра был отозван СОС вышестоящего центра, все сертификаты, изданные промежуточным центром, считаются недействительными;
• проверка приемлемых регламентов использования сертификата и приемлемых областей использования ключа с использованием дополнений certificatesPolicies и extendedKeyUsage .

Компоненты ИОК и их функции

В состав компонент ИОК входят следующие компоненты:

• Центр Сертификации;
• Центр Регистрации;
• Конечные пользователи;
• Сетевой справочник.

Центр Сертификации

Центр Сертификации (или Удостоверяющий Центр) - основная управляющая компонента ИОК, предназначенная для формирования электронных сертификатов подчиненных Центров и конечных пользователей. Кроме сертификатов, ЦС формирует список отозванных сертификатов X.509 CRL (СОС) с регулярностью, определенной Регламентом системы.

К основным функция ЦС относятся:

• Формирование собственного секретного ключа и сертификата ЦС;
• Формирование сертификатов подчиненных Центров;
• Формирование сертификатов открытых ключей конечных пользователей;
• Формирование списка отозванных сертификатов;
• Ведение базы всех изготовленных сертификатов и списков отозванных сертификатов;

Центр Регистрации

Опциональная компонента ИОК, предназначенная для регистрации конечных пользователей. Основная задача ЦР - регистрация пользователей и обеспечение их взаимодействия с ЦС. В задачи ЦР может также входить публикация сертификатов и СОС в сетевом справочнике LDAP.

Пользователи

Пользователь, приложение или система, являющиеся Владельцами сертификата и использующие ИОК.

Сетевой справочник

Опциональная компонента ИОК, содержащая сертификаты и списки отозванных сертификатов и служащая для целей распространения этих объектов среди пользователей с использованием протокола LDAP (HTTP, FTP).

Использование ИОК в приложениях

ИОК используется для управления ключами и электронными сертификатами в приложениях (таких как электронная почта, Web приложения, электронная коммерция), использующих криптографию для установления защищенных сетевых соединений (S/MIME, SSL, IPSEC), или для формирования ЭЦП электронных документов, приложений и т.д. Кроме того, ИОК может быть использована для корпоративных приложений.

Электронная почта и документооборот

Защищенные электронная почта и документооборот используют криптографию для шифрования сообщений или файлов и формирования ЭЦП. Из наиболее известных и распространенных стандартов стоит отметить протокол S/MIME (Secure Multipurpose Internet Mail Extensions), который является расширением стандарта Internet почты MIME (Multipurpose Internet Mail Extensions).

Web приложения

Web броузеры и сервера используют ИОК для аутентификации и конфиденциальности сессии, а также для онлайновых банковских приложений и электронных магазинов. Наиболее распространенным протоколом в этой сфере является протокол SSL (Secure Sockets Layer). Протокол SSL не ограничивается применением только для защиты HTTP (Hypertext Transfer Protocol), а также может быть использован для FTP (File Transfer Protocol) и Telnet.

ЭЦП файлов и приложений

Использование ЭЦП для подписи приложений и файлов позволяет безопасно распространять их по сети Internet. При этом пользователь уверен в корректности полученного приложения от фирмы-разработчика.

Стандарты в области ИОК

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

В особенности стандартизация важна в области:

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

Основным центром по выпуску согласованных стандартов в области ИОК является рабочая группа ИОК (PKI working group) организации IETF (Internet Engineering Task Force), известная как группа PKIX (от сокращения PKI for X.509 certificates).

Стандарты PKIX

Спецификации PKIX основаны на двух группах стандартов: X.509 ITU-T (Международный комитет по телекоммуникациям) и PKCS (Public Key Cryptography Standards) firmy RSA Data Security. X.509 изначально был предназначен для спецификации аутентификации при использовании в составе сервиса X.500 директории. Фактически же, синтаксис электронного сертификата, предложенный в X.509 признан стандартом де-факто и получил всеобщее распространение независимо от X.500. Однако X.509 ITU-T не был предназначен для полного определения ИОК. В целях применения стандартов X.509 в повседневной практике пользователи, поставщики и комитеты по стандартизации обращаются к стандартам PKCS. PKIX группа издала следующие стандарты Internet (RFC).

Введение

Данный документ дает краткое описание стандарта X.509 различных версий. В первую очередь, внимание уделяется стандартным полям сертификата X.509 и различным дополнениям (extensions), применение которых позволяет использовать сертификаты в самых различных областях.

Сертификат X.509 версии 1 и 2

Версия 1 стандарта X.509 была издана в 1988 году. Версия 2 стандарта X.509 была издана в 1993 году и содержала минимальные дополнения к версии 1. Приведенный ниже рисунок показывают формат сертификатов версии 1 и 2.

Version	Версия сертификата	1, 2, 3
Certificate Serial Number	Серийный номер сертификата
	Идентификатор алгоритма ЭЦП	ГОСТ Р 34.10-94
Issuer X.500 Name	Имя Издателя сертификата
Validity Period	Срок действия сертификата
Subject X.500 Name	Имя Владельца сертификата
Subject Public Key Info	Открытый ключ Владельца	длина ключа: 1024 значение: AF:ED:80:43.....
Issuer Unique ID version 2
Subject Unique ID version 2
CA Signature ЭЦП Центра Сертификации

Версия

Данное поле описывает версию сертификата. При использовании дополнений версия должна быть установлена как X.509 version 3 (значение равно 2). Если дополнения не используются, версия должна быть 1 (значение должно быть не установлено).

Идентификатор алгоритма ЭЦП

Поле содержит идентификатор криптографического алгоритма, используемого ЦС для выработки ЭЦП сертификата.

Серийный номер сертификата

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

Имя Издателя сертификата

Поле Издатель идентифицирует объект (субъект), который сформировал ЭЦП и издал сертификат. Значение в поле Издатель должно содержать ненулевое значение DN (distinguished name). Поле Издатель определено в рекомендациях X.501 как тип Name. Значение поля состоит из набора иерархических атрибутов (AttributeType), таких как код страны и соответствующего ему значения (AttributeValue, например, UA). Тип компонентов AttributeValue, входящих в имя, определяется типом атрибута AttributeType и в основном используется DirectoryString.

Срок действия сертификата

Данное поле определяет срок действия (в виде временного интервала) в течение которого ЦС управляет сертификатом (отслеживает состояние). Поле представляет последовательность двух дат: дата начала действия сертификата (notBefore) и дата окончания срока действия сертификата (notAfter). Оба этих значения могут быть закодированы либо как UTCTime, либо как GeneralizedTime.

Имя Владельца сертификата

Поле Владелец идентифицирует объект (субъект), являющийся обладателем секретного ключа, соответствующего открытому ключу в сертификате.

Открытый ключ Владельца

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

SEQUENCE { signKeyIdentifier IA5String, encryptKeyIdentifier IA5String OPTIONAL }

Уникальный идентификатор Издателя и Владельца

Данное поле может использоваться только в сертификатах версии 2 или 3. Поле было предусмотрено в версии 2 сертификатов X.509 для целей обеспечения использования одинакового имени Владельца или Издателя в разных сертификатах. С введением дополнений в версии 3 такая необходимость отпала.

Сертификат X.509 версии 3

Данный раздел описывает версию 3 сертификата X.509. Версия 3 описала механизм дополнений, дополнительной информации, которая может быть помещена в сертификат. X.509 и рекомендации RFC 2459 описывают набор стандартных дополнений, но вместе с тем не ограничивают возможности использования любых других дополнений путем регистрации идентификатора (ISO или IANA).

Каждое дополнение состоит из трех полей:

type

critical

value

Таким образом, дополнение представляет собой структуру, содержащую:

• идентификатор дополнения
• признак "критичное/не критичное дополнение
• собственно значение дополнения, представленное в бинарном виде (OCTET STRING)

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

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

Приведенный ниже рисунок дает представление о формате сертификата версии 3.

Version	Версия сертификата	3
Certificate Serial Number	Серийный номер сертификата	40:00:00:00:00:00:00:ab:38:1e:8b:e9:00:31:0c:60
Signature Algorithm Identifier	Идентификатор алгоритма ЭЦП	ГОСТ Р 34.10-94
Issuer X.500 Name	Имя Издателя сертификата	C=UA, ST=Kyiv,O=PKI, CN=Certification Authority
Validity Period	Срок действия сертификата	Действителен с: Ноя 2 06:59:00 1999 GMT Действителен по: Ноя 6 06:59:00 2004 GMT
Subject X.500 Name	Имя Владельца сертификата	C=UA, ST=Kyiv, O=PKI, CN=Petrenko
Subject Public Key Info	Открытый ключ Владельца	тип ключа: Открытый ключ ГОСТ длина ключа: 1024 значение: AF:ED:80:43.....
Issuer Unique ID version 2	Уникальный идентификатор Издателя
Subject Unique ID version 2	Уникальный идентификатор Владельца
type critical value
CA Signature ЭЦП Центра Сертификации

Дополнения X.509 версии 3

К стандартным дополнениям сертификатов версии 3, относятся дополнения определенные рекомендациями Х.509 версии 3 ITU-T и дополнения, определенные рекомендациями IETF RFC 2459 Базовый идентификатор дополнений, определенный рекомендациями Х.509: id-ce OBJECT IDENTIFIER::= {joint-iso-ccitt(2) ds(5) 29},
где id-ce обозначает: Object id entifier assignments for ISO c ertificate e xtensions.

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

К ограничивающим дополнениям относятся:

• базовые ограничения (basicConstraints);
• область применения ключа (keyUsage);
• расширенная область применения ключа (extendedKeyUsage);
• регламенты сертификата (модифицируемые ограничениями регламентов и соответствием регламентов) (certificatesPolicies);
• ограничения имен (nameConstraints).

К информационным дополнениям относятся:

• идентификаторы ключей (subjectKeyIdentifier, authorityKeyIdentifier);
• альтернативные имена (subjectAltName, issuerAltName);
• точка распространения СОС (cRLDistributionPoint, issuingDistributionPoint);
• способ доступа к информации ЦС (authorityAccessInfo).

Идентификатор ключа Издателя

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

Идентификатор ключа Владельца

Данное дополнение используется для идентификации различных сертификатов, содержащих открытый ключ. Для упрощения процедуры построения цепочки, данное дополнение должно устанавливаться во всех сертификатах ЦС, которые включают дополнение basicConstraints с установленным значением cA TRUE. Во всех издаваемых ЦС сертификатах значение keyIdentifier в дополнении authorityKeyIdentifier должно быть идентично значению subjectKeyIdentifier сертификата ЦС.
Для сертификатов, значение subjectKeyIdentifier должно вырабатываться из открытого ключа или с использованием метода генерации уникальных значений. Рекомендациями RFC 2459 предлагается два метода генерации идентификатора на основе значения открытого ключа:

(1) Значение keyIdentifier определяется как 160 бит хэш-функции, вычисляемой по алгоритму SHA-1 из значения BIT STRING subjectPublicKey (исключая тэг, длину и неиспользованные биты).

(2) Значение keyIdentifier определяется как 4-x битовое поле со значением 0100 и последующим за ним 60 битами наименьшей значимой части хэш-функции, вычисляемой по алгоритму SHA-1 из значения BIT STRING subjectPublicKey.

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

Область применения ключа

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

Таблица. Области применения ключа

Флаг	Применение ключа
digitalSignature	Ключ может быть использован для целей обеспечения целостности и авторства информации. Формирование и проверка ЭЦП электронных документов и информации, установление идентичности в процессе аутентификации и т.д.
nonRepudiation	не используется
keyEncipherment	не используется
dataEncipherment	Ключ может быть использован для целей обеспечения конфиденциальности и целостности информации. Шифрование и расшифрование данных и контроль целостности с использованием имитозащиты.
keyAgreement	не используется
KeyCertSign	Ключ может быть использован для целей формирования ЭЦП сертификатов. Может использоваться Центром Сертификации и Регистрации.
CRLSign	Ключ может быть использован для целей формирования ЭЦП СОС. Может использоваться Центром Сертификации.
EncipherOnly	не используется
DecipherOnly	не используется

Расширенная область применения ключа

Данное дополнение (Extended keyUsage) предназначено для задания дополнительных областей применения ключа по требованиям прикладного ПО. Значение Область применения ключа (KeyPurposeId) данного дополнения может быть определена любой организацией в зависимости от конкретных целей.
Идентификатор объекта, для идентификации области применения должен назначаться в соответствии с IANA или ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1.

Срок действия секретного ключа

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

Регламенты использования сертификата

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

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

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

Таблица. Информация о Регламенте сертификата

Регламент и номер ссылки MDPREI CertPolicy n	Информация о Регламенте сертификата
Registration (n = 1)	Данный сертификат и соответствующий ему секретный ключ предназначен для целей, предусмотренных процессом регистрации пользователя в системе, и не могут быть использованы для обеспечения авторства, целостности и конфиденциальности любой другой передаваемой или хранимой информации.
Class1 (n = 2)	Центр Сертификации не гарантирует принадлежность открытого ключа и дополнений Владельцу сертификата. Использование данного сертификата в приложениях, требующих идентификации Владельца, может привести к фальсификации конфиденциальной информации.
Class2 (n = 3)
Class3 (n = 4)	Данный сертификат и соответствующий ему секретный ключ предназначен для обеспечения авторства, целостности и конфиденциальности любой передаваемой или хранимой информации, не составляющей государственную тайну.

Соответствие регламентов

Данное дополнение предназначено для использования в сертификатах ЦС. Оно содержит список парных Идентификаторов Объектов (OID). Каждая пара в свою очередь включает Регламент Зоны Издателя (issuerDomainPolicy) и Регламент Зоны Владельца (subjectDomainPolicy). Такая парность означает, что ЦС, выступающий в роли Издателя (issuing CA), принимает Регламент Зоны Издателя эквивалентным Регламенту Зоны Владельца для подчиненного ЦС (subject CA).
Пользователи, относящиеся к Издающему ЦС (issuing CA) могут принимать Регламент Зоны Издателя(issuerDomainPolicy) для соответствующих приложений. Дополнение Соответствие Регламентов ставит в известность пользователей Издающего ЦС о том наборе Регламентов, subject CA) которые сравнимы с регламентами, соответствующими их требованиями.

Альтернативное имя Владельца

Дополнение Альтернативное Имя Владельца может использоваться для двух целей. Во-первых, оно позволяет расширить границы идентификации Владельца сертификата. Для этого используются заранее определенные идентификаторы, которые включают адрес электронной почты Internet, имя в DNS, IP адрес и URI. Во-вторых, оно предоставляет набор дополнительной справочной информации о Владельце сертификата. Для этого используется представление имени в различных видах и множественное представление имен. При необходимости введения такой дополнительной идентификации в сертификат должно использоваться дополнение Альтернативное Имя Владельца или Альтернативное Имя Издателя

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

TYPE-IDENTIFIER::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } WITH SYNTAX {&Type IDENTIFIED BY &id} Таблица. Поля дополнения Альтернативное Имя

Наименование	Тип	Назначение	Идентификатор
rfc822Name	IA5String	Адрес электронной почты rfc 822	CHOICE
dNSName	IA5String	Имя DNS	CHOICE
directoryName	IA5String	X.500 DN (имя	CHOICE
uniformResourceIdentifier	IA5String	адрес URI	CHOICE
iPAddress	OCTET STRING	Адрес IP	CHOICE
registeredID	OBJECT IDENTIFIER	Идентификатор ASN.1 объекта	CHOICE
organizationName	DirectoryString	Наименование организации	id-at 10
registredAddress	DirectoryString	Зарегистрированный (юридический адрес) организации	id-at 26
surname	DirectoryString	Фамилия, имя, отчество	id-at 4
businessCategory	DirectoryString	Должность	Должность
physicalDelivery	DirectoryString	Почтовый адрес	id-at 19
telephoneNumber	PrintableString	Номер телефона	id-at 20
description	DirectoryString	Дополнительное описание	id-at 13
accountNumber	DirectoryString	Номер банковского расчетного счета	OBJ_mdprei_extensions,10
bankID	DirectoryString	Банковский идентификационный код	OBJ_mdprei_extensions,11

Поля с идентификаторами id-at, определены в рекомендациях Х.520.

Альтернативное имя Издателя

Так же как и дополнение Альтернативное Имя Владельца, дополнение Альтернативное имя Издателя (issuerAltName) служит целям дополнительной ассоциации Издателя сертификата. Правила использования данного дополнения аналогичны использованию дополнения Альтернативное Имя Владельца.

Атрибуты Справочника Владельца сертификата

Дополнение предусмотрено для хранения дополнительной информации, связанной с атрибутами директории X.500. Дополнение Атрибуты Справочника Владельца сертификата не рекомендуется использовать рекомендациями RFC 2459 , но он может быть использован в частных реализациях.

Основные ограничения

Дополнение Базовые ограничения идентифицирует, является ли Владелец сертификата Центром Сертификации, и какова длина цепочки сертификатов для этого ЦС.
Поле pathLenConstraint имеет смысл только при условии, если значение cA установлено в TRUE. В этом случае оно обозначает максимальное количество сертификатов ЦС, которые следуют за данным сертификатом в цепочке. Значение нуль означает, что только сертификаты конечного пользователя могут следовать в цепочке за данным сертификатом. При использовании, значение pathLenConstraint больше или равно нулю. Если значение не установлено, это означает, что лимит на длину цепочки не определен.

Ограничения имени

Дополнение Ограничение имени, должно использоваться только в сертификатах ЦС. Оно указывает пространство имен, внутри которого должны быть расположены все имена Владельцев издаваемых сертификатов. Ограничения могут быть применимы как имени Владельца (Subject DN), так и к альтернативному имени.
Ограничения определены в терминах допускаемого (permittedSubtrees) или исключаемого (excludedSubtrees) поддерева имен. Любое имя совпадающее с ограничением в исключающем поддереве является некорректным, в независимости от возможного его присутствия в допускаемом поддереве.
При реализации данного дополнения RFC 2459 рекомендуется:

• не использовать поля minimum и maximum ни в какой из форм имен, так что minimum всегда нуль, а maximum всегда отсутствует;
• использовать только поля permittedSubtrees для задания разрешенного диапазона имен и не использовать excludedSubtrees, что согласуется с организационной или территориальной схемой иерархии.

Данное дополнение проверяется функцией верификации цепочек сертификатов.

Ограничение регламента

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

Точка распространения СОС

Точка распространения СОС является дополнением, которое определяет механизм и расположение СОС определенного типа в сети, и определяет зону действия СОС как:

• только для конечных пользователей,
• только для ЦС,
• или ограничивает коды мотивации.

Коды мотивировки, ассоциированные с точкой распространения, должны специфицироваться в поле onlySomeReasons. Если поле onlySomeReasons отсутствует, точка распространения должна содержать отзываемые сертификаты для всех кодов. ЦС может использовать Точку распространения СОС как основу для управления потоками данных при компрометации. В этом случае, отзывы сертификатов с кодами keyCompromise (1) и cACompromise (2) располагаются в одной точке распространения, а все остальные в другой.

Способ доступа к информации ЦС

Данное дополнение указывает на способы доступа к информации и сервисам ЦС, издавшим сертификат, в котором это дополнение установлено. Информация и сервис могут включать процедуры on-line проверки и получения Регламента (Регламентов) ЦС. Способ получения СОС не специфицируется данным дополнением, для этого используется дополнение cRLDistributionPoints. 

Common Name or CN is generally used in SSL Certificates. CN is used to define the server name which will be used for secure SSL connection. Generally this SSL certificate used to secure connection between a HTTP/S server and client browser like Chrome, Explorer, Firefox.

Common Name is used to specify the host or server identity. When a client try to connect to a remote server like HTTP server it will first get the SSL certificate of this server. Then compare the Host name or domain name it want to connect with the Common Name provided in the SSL certificate. If they are same it will use the SSL certificate to encrypt connection.

Common name technically represented as commonName field in X.509 certificate specification. X.509 specification is used in SSL certificates which is the same.

We can formulate Command Name like below.

Common Name = Domain Name + Host Name

Common Name = Domain Name + Host Name

We can use following domain and host names as Common Name.

сайт www.сайт *.сайт

poftut . com www . poftut . com * . poftut . com

Fully Qualified Domain Name (FQDN)

Fully Qualified Domain Name or FQDN is used with Command Name interchangeable. Fully qualified name is used to define the host name in a strict manner. More details about the FQDN can be found in the following tutorial.

Organization Name

Organization name may be misinterpreted with the Common Name. Organization Name is the name of the organization where the IT infrastrure belongs. Organization name shouldn’t be used for common name which will create security problems.

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

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

Несимметричные системы устроены так, что в них существует два числа:

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

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

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

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

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

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

Цифровая подпись

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

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

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

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

Удостоверяющий центр (Certification Authority)

Проблема связывания открытого ключа и некоего объекта может решаться разными способами. Один из самых простых подходов — это составить список соответствия открытых ключей и »имен« объектов. В качестве имени может выступать любой идентификатор, например доменное имя машины, полные имя, фамилия и отчество человека и т.д.; проблема уникальности имен, которая обязательно должна появляется — это отдельная трудность, которая обычно решается административными способами типа иерархической системы пространства имен и некоторой системы разрешения конфликтов имен внутри одного подпространства имен. Здесь эта проблема более освещаться не будет.

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

Поэтому были введены понятия X.509-сертификата и удостоверяющего центра. X.509-сертификат (далее, просто сертификат) — это конгломерат из открытого ключа пользователя, пользовательской информации, имени сертификата, называемого Distungiushed Name (DN) и цифровой подписи удостоверяющего центра, которая скрепляет все эти данные друг с другом. То есть появляется возможность связать открытый ключ и DN пользователя, что может служить искомым ингридиентом процесса аутентификации, если в качестве идентификатора пользователя используется Distinguished Name его сертификата. Кстати говоря, у сертификата есть срок действия, который ограничивает срок соответствия, создаваемого удостоверяющим центром.

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

Зачем нужна аутентификация? Одного шифрования недостаточно?

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

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

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

1. доверие удостоверяющему центру вообще, то есть доверие его репутации,
2. уверенность в том, что тот открытый ключ, который к вам попал, действительно является открытым ключом данного удостоверяющего центра.

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

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

Proxy-сертификаты

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

Что же еще? В многокомпонентных системах очень удобно то, что называется Single Sign-On — возможность аутентифицироваться вручную только один раз, а все остальные операции аутентификации будут проводиться автоматически. Обычно это актуально в системах, которые первоначально вас аутентифицируют, а потом система начинает выполнять действия от вашего лица, например, получать данные, запускать задачи, публиковать их результаты и т.д. Это называется делегированием.

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

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

1. Проверяется подпись, созданная сервисом. При этом используется открытый ключ, который был передан вместе с подписью.
2. Аутентифицируется открытый ключ, которым была проверена подпись. Сначала проверяется подпись на proxy-сертификате, которая была создана с помощью закрытого ключа пользователя. Это делается с помощью открытого ключа пользователя.
3. Таким же образом аутентифицируется открытый ключ самого пользователя, но здесь уже используются данные об удостоверяющем центре.

В результате этого строится то, что называется цепочкой доверия (chain of trust), которая начинается на какой-то цифровой подписи и заканчивается на цифровой подписи удостоверяющего центра.

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

• X.509 Style Guide , написанный Питером Гутманном. Там много технических деталей, но некоторым почитать вполне стоит.

Формат сертификата Х.509

Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающем этот стандарт. На практике, однако, сложилась ситуация, что разные компании создают собственные расширения для Х.509, не все из которых между собой совместимы.

Всякий сертификат требует, чтобы кто-то заверил взаимосвязность открытого ключа и идентифицирующей владельца ключа информации. Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащихся в нём сведений (за исключением случаев, когда эта возможность намеренно ограничена политикой безопасности). Но в случае сертификатов Х.509 заверителем может быть только Центр сертификации или некто, специально уполномоченный им на эту роль. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)

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

Сертификат Х.509 содержит следующие сведения:

Версия Х.509 - указывает, на основе какой версии стандарта Х.509 построен данный сертификат, что определяет, какая информация может в нём содержаться.

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

Серийный номер сертификата - организация-издатель сертификата обязана присвоить ему уникальный серийный (порядковый) номер для его опознавания среди прочих сертификатов, выданных данной организацией. Эта информация применяется в ряде случаев; например, при аннулировании сертификата, его серийный номер помещается в список аннулированных сертификатов (Certificate Revocation List, CRL).

Уникальный опознаватель владельца ключа (или DN, distinguished name - уникальное имя) - это имя должно быть уникальным и единственным во всём Интернете. DN состоит из нескольких подпунктов и может выглядеть примерно так:

CN=Bob Davis, [email protected], OU=PGP Engineering,

O=PGP Corporation, C=US

(Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Организацию и Страну соответственно.)

Период действия сертификата - дата начала действия сертификата и дата окончания его действия; указывает на то, когда сертификат станет недействителен.

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

ЭЦП издателя - электронная подпись, созданная закрытым ключом организации, выдавшей сертификат. Идентификатор алгоритма подписи - указывает алгоритм, использованный ЦС для подписания сертификата.

Существует ряд фундаментальных различий между форматами сертификатов Х.509 и PGP:

вы можете лично создать собственный сертификат PGP;

вы должны запросить и получить сертификат Х.509 от Центра сертификации; сертификаты Х.509 содержат только одно имя владельца сертификата;

сертификаты Х.509 содержат только одну ЭЦП, подтверждающую подлинность сертификата.

Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляете системе свой открытый ключ, чем доказываете, что обладаете соответствующим закрытым, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет - запрос сертификата - в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной информации и, если всё сходится, создаёт сертификат, подписывает и возвращает вам.

Вы можете представить сертификат Х.509, как обычный бумажный сертификат или аттестат с приклеенным к нему открытым ключом. На нём указано ваше имя, а также некоторые сведения о вас, плюс подпись издателя сертификата.

Вероятно, наибольшая польза от сертификатов Х.509, это их применение в Веб-браузерах.

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

Из книги Windows Script Host для Windows 2000/XP автора Попов Андрей Владимирович

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

Из книги Инфраструктуры открытых ключей автора Полянская Ольга Юрьевна

Создание собственного сертификата Наиболее быстрым способом создания собственного цифрового сертификата является использование программы SelfCert.exe, входящей в состав Microsoft Office 2000/ХР. Запустив эту утилиту, мы получим диалоговое окно, позволяющее задать имя создаваемого

Из книги Яндекс для всех автора Абрамзон М. Г.

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

Из книги Введение в криптографию автора Циммерманн Филипп

Онлайновый протокол статуса сертификата Онлайновый протокол статуса сертификата OCSP - относительно простой протокол (типа "запрос-ответ") для получения информации об аннулировании от доверенного субъекта, называемого OCSP-респондером. OCSP-запрос состоит из номера версии

Из книги Операционная система UNIX автора Робачевский Андрей М.

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

Из книги автора

Проверка срока действия сертификата Эта проверка завершается успешно, если текущие дата и время на момент валидации находятся в пределах срока действия

Из книги автора

Проверка статуса сертификата Эта проверка завершается успешно, если издатель не аннулировал данный сертификат. Основным средством проверки статуса сертификата являются списки САС, но могут использоваться и другие альтернативные средства

Из книги автора

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

Из книги автора

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

Из книги автора

Завершение обработки сертификата Когда завершается обработка сертификата конечного субъекта, на основании значений переменных состояния устанавливаются выходные значения.Корректировка переменных состояния верификации цифровой подписи. В поле информации об

Из книги автора

3.3.1. Формат RSS Читать новости сайтов можно по-разному. Самый простой способ - заходить время от времени на сайт и просматривать новые сообщения. Можно поставить программу, которая подключается к новостному каналу и сама получает заголовки или аннотации новостей, по

Из книги автора

Формат сертификата Х.509 Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом,

Из книги автора

Аннулирование сертификата Применение сертификата допустимо только пока он достоверен. Опасно полагаться на то, что сертификат будет защищён и надёжен вечно. В большинстве организаций и во всех PKI сертификат имеет ограниченный срок "жизни". Это сужает период, в который

Из книги автора

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

Из книги автора

Формат ELF Формат ELF имеет файлы нескольких типов, которые до сих пор мы называли по-разному, например, исполняемый файл или объектный файл. Тем не менее стандарт ELF различает следующие типы:1. Перемещаемый файл (relocatable file), хранящий инструкции и данные, которые могут быть