- B.3. standard x.509 v3 certificate extension reference red hat certificate system 9 | red hat customer portal
- Subject
- Базовые ограничения
- Идентификатор ключа сертификационного центра
- Идентификатор ключа субъекта
- Использование ключа
- Проверка правильности установки ssl сертификата онлаин. справочные материалы по установке и использованию сертификатов безопасности ssl
- Расширения сертификата
- Расширенное использование ключа
- Точки распространения crl
B.3. standard x.509 v3 certificate extension reference red hat certificate system 9 | red hat customer portal
An X.509 v3 certificate contains an extension field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates. Older Netscape servers, such as Red Hat Directory Server and Red Hat Certificate System, that were developed before PKIX part 1 standards were defined require Netscape-specific extensions.
Example B.4. Sample Pretty-Print Certificate Extensions
Data:
Version: v3
Serial Number: 0x1
Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
Issuer: CN=Certificate Manager,OU=netscape,O=ExampleCorp,L=MV,ST=CA,C=US
Validity:
Not Before: Friday, February 21, 2005 12:00:00 AM PST America/Los_Angeles
Not After: Monday, February 21, 2007 12:00:00 AM PST America/Los_Angeles
Subject: CN=Certificate Manager,OU=netscape,O=ExampleCorp,L=MV,ST=CA,C=US
Subject Public Key Info:
Algorithm: RSA - 1.2.840.113549.1.1.1
Public Key:
Exponent: 65537
Public Key Modulus: (2048 bits) :
E4:71:2A:CE:E4:24:DC:C4:AB:DF:A3:2E:80:42:0B:D9:
CF:90:BE:88:4A:5C:C5:B3:73:BF:49:4D:77:31:8A:88:
15:A7:56:5F:E4:93:68:83:00:BB:4F:C0:47:03:67:F1:
30:79:43:08:1C:28:A8:97:70:40:CA:64:FA:9E:42:DF:
35:3D:0E:75:C6:B9:F2:47:0B:D5:CE:24:DD:0A:F7:84:
4E:FA:16:29:3B:91:D3:EE:24:E9:AF:F6:A1:49:E1:96:
70:DE:6F:B2:BE:3A:07:1A:0B:FD:FE:2F:75:FD:F9:FC:
63:69:36:B6:5B:09:C6:84:92:17:9C:3E:64:C3:C4:C9
Extensions:
Identifier: Netscape Certificate Type - 2.16.840.1.113730.1.1
Critical: no
Certificate Usage:
SSL CA
Secure Email CA
ObjectSigning CA
Identifier: Basic Constraints - 2.5.29.19
Critical: yes
Is CA: yes
Path Length Constraint: UNLIMITED
Identifier: Subject Key Identifier - 2.5.29.14
Critical: no
Key Identifier:
3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79:
9C:37:85:84
Identifier: Authority Key Identifier - 2.5.29.35
Critical: no
Key Identifier:
3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79:
9C:37:85:84
Identifier: Key Usage: - 2.5.29.15
Critical: yes
Key Usage:
Digital Signature
Key CertSign
Crl Sign
Signature:
Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
Signature:
AA:96:65:3D:10:FA:C7:0B:74:38:2D:93:54:32:C0:5B:
2F:18:93:E9:7C:32:E6:A4:4F:4E:38:93:61:83:3A:6A:
A2:11:91:C2:D2:A3:48:07:6C:07:54:A8:B8:42:0E:B4:
E4:AE:42:B4:B5:36:24:46:4F:83:61:64:13:69:03:DF:
41:88:0B:CB:39:57:8C:6B:9F:52:7E:26:F9:24:5E:E7:
BC:FB:FD:93:13:AF:24:3A:8F:DB:E3:DC:C9:F9:1F:67:
A8:BD:0B:95:84:9D:EB:FC:02:95:A0:49:2C:05:D4:B0:
35:EA:A6:80:30:20:FF:B1:85:C8:4B:74:D9:DC:BB:50An object identifier (OID) is a string of numbers identifying a unique object, such as a certificate extension or a company’s certificate practice statement. The Certificate System comes with a set of extension-specific profile plug-in modules which enable X.509 certificate extensions to be added to the certificates the server issues. Some of the extensions contain fields for specifying OIDs.
The PKIX standard recommends that all objects, such as extensions and statements, that are used in certificates be included in the form of an OID. This promotes interoperability between organizations on a shared network. If certificates will be issued that will be used on shared networks, register the OID prefixes with the appropriate registration authority.
OIDs are controlled by the International Standards Organization (ISO) registration authority. In some cases, this authority is delegated by ISO to regional registration authorities. In the United States, the American National Standards Institute (ANSI) manages this registration.
Using an OID registered to another organization or failing to register an OID may carry legal consequences, depending the situation. Registration may be subject to fees. For more information, contact the appropriate registration authority.
If an OID extension exists in a certificate and is marked critical, the application validating the certificate must be able to interpret the extension, including any optional qualifiers, or it must reject the certificate. Since it is unlikely that all applications will be able to interpret a company’s custom extensions embedded in the form of OIDs, the PKIX standard recommends that the extension be always marked noncritical.
Each extension in a certificate can be designated as critical or noncritical. A certificate-using system, such as a web browser, must reject the certificate if it encounters a critical extension it does not recognize; however, a noncritical extension can be ignored if it is not recognized.
The Key Usage extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, and Basic Constraints extensions act together to specify the purposes for which a certificate can be used.
If this extension is included at all, set the bits as follows:
If the keyUsage extension is present and marked critical, then it is used to enforce the usage of the certificate and key. The extension is used to limit the usage of a key; if the extension is not present or not critical, all types of usage are allowed.
If the keyUsage extension is present, critical or not, it is used to select from multiple certificates for a given operation. For example, it is used to distinguish separate signing and encryption certificates for users who have separate certificates and key pairs for operations.
Subject
Поле subject идентифицирует участника, который является собственником сертификата и соответствующего закрытого ключа. Имя участника может быть указано в поле subject и/или в расширении subjectAltName.
Если субъект является СА (т.е. основное обязательное расширение сА есть TRUE ), то поле subject должно содержать непустое уникальное имя, соответствующее содержимому поля issuer во всех сертификатах, выпущенных данным СА.
Если субъект является выпускающим CRL (т.е. присутствует расширение использования ключа keyUsage, и значение cRLSign есть TRUE ), то поле субъекта должно содержать непустое уникальное имя, соответствующее содержимому поля issue во всех CRLs, выпущенных данным субъектом.
Если информация именования субъекта представлена только расширением subjectAltName (т.е. ключ
связан только с e-mail адресом или URI ), то имя субъекта должно быть пустой последовательностью, и расширение subjectAltName должно быть обязательным.
Поле subject, если оно не пусто, должно содержать уникальное имя в форме DN. СА может выпустить более одного сертификата с одним и тем же DN для одного и того же участника, определенного в subject.
Поле subject определено как тип Name в терминологии стандарта Х.501.
Базовые ограничения
Расширение для базовых ограничений указывает, является ли субъект сертификата СА и максимальную глубину действительных сертификационных путей, которые включают данный сертификат.
Булевское значение сА указывает, принадлежит ли сертифицированный открытый ключ СА. Если булевское значение сА не установлено, то бит keyCertSign в расширении использования ключа не должен быть установлен.
Поле pathLenConstrant имеет смысл, только если булевское значение сА установлено, и в расширении использования ключа установлен бит keyCertSign. В этом случае данное поле определяет максимальное число несамовыпущенных промежуточных сертификатов, которые могут следовать за данным сертификатом в действительном сертификационном пути.
Данное расширение должно присутствовать как критичное во всех сертификатах СА, которые содержат открытые ключи, используемые для проверки цифровых подписей в сертификатах. Данное расширение может присутствовать как критичное или некритичное расширение в сертификатах СА, которые содержат открытые ключи, используемые для целей, отличных от проверки цифровых подписей в сертификатах.
Такие сертификаты СА являются сертификатами, которые содержат открытые ключи, используемые исключительно для проверки цифровых подписей в CRLs, и сертификатами, которые содержат открытые ключи для управления ключом, используемые в протоколах регистрации сертификатов. Данное расширение может появляться как критичное или некритичное расширение в сертификатах конечного участника.
САs не должны включать поле pathLenConstraint, если булевское значение сА не установлено и расширение использования ключа не имеет бит keyCertSign.
Идентификатор ключа сертификационного центра
Расширение для идентификатора ключа сертификационного центра предоставляет способ идентификации открытого ключа, соответствующего закрытому ключу, который использовался для подписывания сертификата. Данное расширение используется, когда выпускающий имеет несколько ключей для подписывания.
Поле keyIdentifier расширения authorityKeyIdentifier должно быть включено во все сертификаты, выпущенные СА для обеспечения возможности создания сертификационного пути.
Существует одно исключение: когда СА распространяет свой открытый ключ в форме самоподписанного сертификата, идентификатор ключа уполномоченного органа может быть опущен. Подпись для самоподписанного сертификата создается закрытым ключом, соответствующим открытому ключу субъекта.
Значение поля keyIdentifier должно быть получено из открытого ключа, используемого для проверки подписи сертификата, или методом, который создает уникальные значения. Рассмотрим два метода создания идентификаторов ключей из открытого ключа и один метод создания уникальных значений для keyIdentifier.
Если идентификатор ключа не был предварительно определен, рекомендуется использовать один из этих методов для создания keyIdentifiers. Если идентификатор ключа был предварительно определен, СА должен задействовать предварительно определенный идентификатор.
Рекомендуется поддерживать метод идентификации ключа всем пользователям сертификатов.
Данное расширение не должно помечаться как критичное.
Идентификатор ключа субъекта
Расширение идентификатора ключа субъекта предоставляет способ идентификации сертификата, содержащего конкретный открытый ключ.
Для упрощения создания сертификационного пути данное расширение должно появляться во всех сертификатах СА, т.е. во всех сертификатах, в которых значение сА есть TRUE.
Для сертификатов СА идентификаторы ключа субъекта должны быть получены из открытого ключа или методом, который создает уникальные значения. Существует два метода для создания идентификаторов ключей из открытого ключа:
- keyIdentifier получается из 160-битного хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
- keyIdentifier получается из четырех битов поля типа со значением 0100, следующим за младшими 60 битами хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
Метод создания уникальных значений состоит в использовании монотонно возрастающей последовательности целых чисел.
Для сертификатов конечных участников расширение идентификатора ключа субъекта предоставляет способы для идентификации сертификатов, содержащих конкретный открытый ключ, используемый в приложении. Если конечный участник получает несколько сертификатов, возможно от нескольких САs, идентификатор ключа субъекта обеспечивает способы быстрого поиска конкретного открытого ключа, содержащегося в некотором множестве сертификатов.
Данное расширение не должно быть помечено как критичное.
Использование ключа
Расширение keyUsage определяет назначение (например, шифрование, подпись, подписывание сертификатов) ключа, содержащегося в сертификате. Ограничение использования должно применяться, когда ключ ограничивается использованием только в одной операции.
Например, когда ключ RSA должен использоваться только для проверки подписей для объектов, отличных от сертификатов открытого ключа и CRLs, биты digitalSignature и/или nonRepudiation должны присутствовать.
Данное расширение должно присутствовать в сертификатах, которые содержат открытые ключи, используемые для проверки действительности цифровых подписей над другими сертификатами открытых ключей или CRLs. Когда данное расширение присутствует, оно должно помечаться как критичное.
Биты в keyUsage типе используются следующим образом:
Бит digitalSignature установлен, когда открытый ключ субъекта используется с механизмом цифровой подписи для поддержки сервисов безопасности, отличных от подписывания сертификата (бит 5) или подписывания CRL (бит 6). Например, если механизмы цифровых подписей используются для аутентификации участника или аутентификации и целостности исходных данных.
Бит nonRepudiation установлен, когда открытый ключ субъекта используется для проверки цифровых подписей в сервисе невозможности отказа, который защищает от того, что подписавший участник может отказаться от совершенного действия.
Более тонкое различие между битами digitalSignature и nonRepudiation может определяться конкретными политиками сертификации.
Бит keyEncipherment установлен, когда открытый ключ субъекта используется для пересылки ключа. Например, когда ключ RSA применяется для шифрования ключа сессии, этот бит должен быть установлен.
Бит dataEncipherment установлен, когда открытый ключ субъекта используется для шифрования пользовательских данных, отличных от криптографических ключей.
Бит keyAgreement установлен, когда открытый ключ субъекта используется для согласования ключа. Например, когда ключ Диффи-Хеллмана используется для управления ключом, этот бит установлен.
Бит keyCertSign установлен, когда открытый ключ субъекта используется для проверки подписи в сертификатах открытого ключа. Если бит keyCertSign установлен, то бит сА в расширении базовых ограничений также должен быть установлен.
Бит cRLSign установлен, когда открытый ключ субъекта используется для проверки подписи в списке отмененных сертификатов.
Значение бита encipherOnly при отсутствии бита keyAgreement не определено. Когда установлены биты encipherOnly и keyAgreement, открытый ключ субъекта может использоваться только для шифрования данных при выполнении согласования ключа.
Значение бита decipherOnly не определено при отсутствии бита keyAgreement. Когда бит decipherOnly установлен, и бит keyAgreement также установлен, открытый ключ субъекта может использоваться только для дешифрования данных при выполнении согласования ключа.
Стандарт Х.509 не ограничивает комбинации битов, которые могут быть установлены в конкретном расширении keyUsage. Тем не менее соответствующие значения расширений keyUsage для конкретных алгоритмов строго определены (исходя из возможностей самого алгоритма).
Проверка правильности установки ssl сертификата онлаин. справочные материалы по установке и использованию сертификатов безопасности ssl
Данный документ дает краткое описание
стандарта X.509 различных версий. В первую
очередь, внимание уделяется стандартным
полям сертификата X.509 и различным
дополнениям (extensions), применение которых
позволяет использовать сертификаты в
самых различных областях.
Сертификат X.509 версии 1 и 2
Версия 1 стандарта X.509 была издана в 1988
году. Версия 2 стандарта X.509 была издана в
1993 году и содержала минимальные
дополнения к версии 1. Приведенный ниже
рисунок показывают формат сертификатов
версии 1 и 2.
Версия
Данное поле описывает версию
сертификата. При использовании
дополнений версия должна быть
установлена как 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).
Каждое дополнение состоит из трех
полей:
Таким образом, дополнение
представляет собой структуру,
содержащую:
- идентификатор дополнения
- признак “критичное/не критичное дополнение
- собственно значение дополнения,
представленное в бинарном виде (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 | Уникальный идентификатор Владельца | |
| дополнения (только версия 3) | ||
| 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 identifier assignments
for ISO certificate extensions.
Стандартные дополнения можно
разделить на две категории: ограничивающие
дополнения и информационные
дополнения. Первые ограничивают область
применения ключа, определенного
сертификатом, или сам сертификат. Вторые
содержат дополнительную информацию,
которая может быть использована в
прикладном ПО пользователем
сертификата.
К ограничивающим дополнениям
относятся:
- базовые ограничения (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.
В соответствии с рекомендациями X.681
синтаксис поля определен в следующем
виде:
TYPE-IDENTIFIER ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id} Таблица. Поля дополнения
Альтернативное Имя
| Наименование | Тип | Назначение | Идентификатор |
| rfc822Name | IA5String | Адрес электронной почты rfc 822 | CHOICE [1] |
| dNSName | IA5String | Имя DNS | CHOICE [2] |
| directoryName | IA5String | X.500 DN (имя | CHOICE [4] |
| uniformResourceIdentifier | IA5String | адрес URI | CHOICE [6] |
| iPAddress | OCTET STRING | Адрес IP | CHOICE [7] |
| registeredID | OBJECT IDENTIFIER | Идентификатор ASN.1 объекта | CHOICE [8] |
| 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) располагаются в одной точке
распространения, а все остальные в
другой.
Способ доступа к информации ЦС
Данное дополнение определено в
рекомендациях IETF RFC 2459 (в отличие от
остальных стандартных дополнений,
которые определены как в рекомендациях
X.509, так и в RFC 2459).
Данное дополнение указывает на
способы доступа к информации и сервисам
ЦС, издавшим сертификат, в котором это
дополнение установлено. Информация и
сервис могут включать процедуры on-line
проверки и получения Регламента (Регламентов)
ЦС. Способ получения СОС не
специфицируется данным дополнением, для
этого используется дополнение cRLDistributionPoints.
Расширения сертификата
Расширения, определенные для сертификатов Х.509 v3, предоставляют методы для связывания дополнительных атрибутов с пользователями или открытыми ключами и для управления сертификатами. Формат сертификата Х.509 v3 также допускает определение частных расширений.
Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются.
Рассмотрим рекомендуемые в Internet расширения сертификатов. Могут использоваться дополнительные расширения; однако следует осторожно устанавливать любые критические расширения в сертификаты, так как это может препятствовать проверке действительности сертификатов.
Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле extnID, и соответствующая ASN.1 структура представления является значением строки октетов extnValue.
Сертификат не должен включать более одного экземпляра конкретного расширения. Например, сертификат может содержать только одно расширение для идентификатора ключа уполномоченного органа. Расширение включает булево значение критичности со значением по умолчанию, равным FALSE. Для каждого расширения должны быть определены допустимые значения для поля критичности.
САs должны поддерживать расширения для идентификатора ключа, основных ограничений использования ключа и политик сертификатов. Если СА выпустил сертификаты с пустой последовательностью для поля субъекта, СА должен указать расширение альтернативного имени субъекта.
Поддержка оставшихся расширений необязательна. САs могут поддерживать расширения, которые текущим стандартом не определены; при этом сертификационные центры должны учитывать, что расширения, помеченные как критичные, могут препятствовать интероперабельности.
Как минимум должны распознаваться следующие расширения: использование ключа, политики сертификата, альтернативное имя субъекта, базовые ограничения, ограничения имени, расширенное использование ключа и запрет произвольной политики.
Могут также распознаваться расширения идентификаторов ключа сертификационного центра и субъекта и расширение отображения политики.
Расширенное использование ключа
Данное расширение определяет одну или более целей, для которых может использоваться сертифицированный открытый ключ, в дополнение к основным целям, указанным в расширении keyUsage. Данное расширение появляется только в сертификатах конечного участника. Оно определяется следующим образом:
Цели ключа могут быть при необходимости определены любой организацией.
Данное расширение может быть как критичным, так и некритичным.
Если расширение присутствует, то сертификат должен использоваться только для одной из указанных целей. Если указано несколько целей, то приложение не обязательно должно распознавать их все, а также расширенную цель, если она присутствует. Приложение, использующее сертификат, может потребовать указать конкретную цель, чтобы сертификат принимался данным приложением.
Если СА включает расширенные использования ключа, чтобы соответствовать таким приложениям, но не хочет ограничивать использование ключа, он может включить специальный keyPurposeID anyExtendedKeyUsage. Если keyPurposeID anyExtendedKeyUsage присутствует, расширение не должно быть критичным.
Если сертификат содержит как расширение использования ключа, так и расширение расширенного использования ключа, оба расширения должны обрабатываться независимо, и сертификат должен использоваться только для целей, содержащихся в обоих расширениях. Если нет целей, содержащихся в обоих расширениях, то сертификат не должен использоваться ни для какой цели (т.е. считается недействительным).
Определены следующие цели использования ключа:
anyExtendedKeyUsage OBJECT IDENTIFIER ::=
{ id-ce-extKeyUsage 0 }
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::=
{ id-kp 1 }
-- аутентификация сервера TLS
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature,
-- keyEncipherment или keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::=
{ id-kp 2 }
-- аутентификация клиента TLS
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature
-- и/или keyAgreement
id-kp-codeSigning OBJECT IDENTIFIER ::=
{ id-kp 3 }
-- подписывание загруженного выполняемого кода
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::=
{ id-kp 4 }
-- защита е-mail
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature,
-- nonRepudiation, и/или (keyEncipherment
-- или keyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::=
{ id-kp 8 }
-- связывание хэша объекта со временем
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature
-- и/или nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::=
{ id-kp 9 }
-- подписывание ответов OCSP
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature
-- и/или nonRepudiationТочки распространения crl
Расширение для точек распространения CRL определяет, как может быть получена информация CRL. Расширение должно быть некритичным, но рекомендуется, чтобы оно поддерживалось как САs, так и приложениями. Далее мы подробно рассмотрим управление CRL.
Расширение cRLDistributionPoints является последовательностью DistributionPoint. DistributionPoint состоит из трех полей, каждое из которых является необязательным: distributionPoint, reasons и cRLIssuer.
Хотя каждое из этих полей является необязательным, DistributionPoint не должно состоять только из поля reasons ; либо distributionPoint, либо cRLIssuer должно присутствовать.
Если выпускающий сертификата не является выпускающим CRL, то поле cRLIssuer должно присутствовать и содержать имя выпускающего CRL. Если выпускающий сертификата является также и выпускающим CRL, то поле cRLIssuer должно быть опущено, и поле distributionPoint должно присутствовать.
Когда поле distributionPoint присутствует, оно содержит либо последовательность общих имен, либо единственное значение nameRelativeToCRLIssuer. Если расширение cRLDistributionPoints содержит общее имя типа URI, предполагается следующая семантика: