Операции протокола LDAP

В протоколе определено 9 операций:

Операции запроса информации. SearchCompare

Операции изменения информации. AddDeleteModifyRename

Операции аутентификации и управления. BindUnbindAbandon

Операция Abandon

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

AbandonRequest ::= [APPLICATION 16] MessageID

MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от id более ранней операции, для которой выполнен Abandon.

Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в AbandonRequest. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполняя последующую операцию Bind.

Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, update) определяется сервером.

В том случае, если сервер получил AbandonRequest для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.

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

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

Операция Add

Операция Add позволяет клиенту запросить добавление записи в Каталог. AddRequest определяется следующим образом:

AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attributes AttributeList } AttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue }

Параметрами AddRequest являются:

Entry: полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.Attributes: список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют собственный RDN записи), атрибут objectClass и значения всех обязательных атрибутов перечисленных классов объектов. Клиенты не должны указывать NO-USER-MODIFICATION атрибуты, такие как createTimestamp или creatorName атрибуты, так как сервер поддерживает их автоматически.

Запись, указанная в поле AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example, DC=NET, а запись DC=Example, DC=NET не существует и запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.

При получении AddRequest сервер пытается добавить запрошенную запись. Результат попытки добавления будет возвращен клиенту в AddResponse, определенном следующим образом:

AddResponse ::= [APPLICATION 9] LDAPResult

Успешный ответ указывает на то, что новая запись добавлена в Каталог.

Операция Compare

Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. CompareRequest определяется следующим образом:

CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion }

Перечислим параметры CompareRequest:

Entry: имя сравниваемой записи. Заметим, что сервер не должен рассматривать aliases записи при выполнении сравнения.Ava: утверждение, с которым сравнивается атрибут записи.

Результат сравнения, выполненного сервером при получении CompareRequest, возвращается в CompareResponse, определяемом следующим образом:

CompareResponse ::= [APPLICATION 15] LDAPResult

При получении CompareRequest сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Результат сравнения возвращается клиенту в CompareResponse. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.

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

Операция Delete

Операция Delete позволяет клиенту запросить удаление записи из директории. DeleteRequest определяется следующим образом:

DelRequest ::= [APPLICATION 10] LDAPDN

DeleteRequest состоит из Distinguished Name удаляемой записи. Заметим, что сервер по aliases не переходит и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.

Результат операции удаления, выполненной сервером при получении DeleteRequest, возвращается в DeleteResponse, определяемом следующим образом:

DelResponse ::= [APPLICATION 11] LDAPResult

При получении DeleteRequest сервер пытается выполнить удаление указанной записи. Результат возвращается клиенту в DeleteResponse.

Операция Modify

Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify определяется следующим образом:

ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification AttributeTypeAndValues } } AttributeTypeAndValues ::= SEQUENCE { type AttributeDescription, vals SET OF AttributeValue }

Перечислим параметры запроса Modify:

Object: модифицируемый объект. Значение данного поля содержит DN модифицируемой записи. Сервер не рассматривает никаких alias для определения модифицируемой записи.Modification: список модификаций, выполняемых для записи. Весь список модификаций записи должен быть выполнен в том порядке, в котором он перечислен, как одна атомарная операция. Хотя отдельные модификации могут нарушать схему Каталога, результирующая запись, после того как весь список модификаций выполнен, должна соответствовать требованиям схемы Каталога. Значения, которые могут находиться в поле "operation" для каждой модификации, имеют следующую семантику: Add: добавление перечисленных значений для данного атрибута; при необходимости атрибут создается.Delete: удаление перечисленных значений для данного атрибута; весь атрибут удаляется, если никаких значений не указано или все текущие значения атрибута перечислены для удаления.Replace: замена всех существующих значений данного атрибута новыми перечисленными значениями; если атрибута не существует, он создается. Замена без указания значения удаляет весь атрибут, если он есть, и игнорируется, если атрибута не существует.

Результат модификации, которую пытался выполнить сервер при получении ModifyRequest, возвращается в ModifyResponse, который определяется следующим образом:

ModifyResponse ::= [APPLICATION 7] LDAPResult

При получении ModifyRequest сервер выполняет необходимые модификации в DIT.

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

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

Операция ModifyDN

Операция ModifyDN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. ModifyDNRequest определяется следующим образом:

ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDN OPTIONAL }

Параметрами ModifyDNRequest являются:

Entry: DN изменяемой записи. Эта запись может как иметь подчиненные записи, так и не иметь их. Заметим, что сервер не переходит ни по каким aliases для изменяемой записи.Newdn: RDN, который формирует левый компонент нового имени записи.Deleteoldrdn: Boolean параметр, который указывает, должно ли старое значение атрибута RDN оставаться в качестве атрибута записи или оно должно удаляться из записи.newSuperior: если присутствует, то это DN существующего объекта, который становится непосредственным родителем существующей записи.

Результат попытки изменения имени сервером при получении ModifyDNRequest возвращается в ModifyDNResponse, определенном следующим образом:

ModifyDNResponse ::= [APPLICATION 13] LDAPResult

Например, если запись, указанная в параметре entry, была cn=Olga Laponina, c=RU, newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU. Если запись с таким именем уже существует, то операция не завершится с кодом ошибки entryAlreadyExists.

Объект, указанный в newSuperior, должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET, запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN, содержащим DC=NET.

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

Операция Search

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

SearchRequest определяется следующим образом:

SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeDescriptionList } Filter ::= CHOICE { and [0] SET SIZE (1..MAX) OF Filter, or [1] SET SIZE (1..MAX) OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion } SubstringFilter ::= SEQUENCE { type AttributeDescription, -- по крайней мере один должен -- присутствовать, initial и final могут -- быть только один раз substrings SEQUENCE OF CHOICE { initial [0] AssertionValue, any [1] AssertionValue, final [2] AssertionValue } } MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] MatchingRuleId OPTIONAL, type [2] AttributeDescription OPTIONAL, matchValue [3] AssertionValue, dnAttributes [4] BOOLEAN DEFAULT FALSE }

Перечислим параметры SearchRequest:

BaseObject: LDAPDN, являющееся записью базового объекта, относительно которого будет выполняться поиск.Scope: индикатор области выполняемого поиска.

Может существовать три типа области поиска:

baseObject: ограничивается только базовым объектом.singleLevel: ограничивается только непосредственно подчиненными объектами.wholeSubtree: поиск во всем поддереве данной записи.

DerefAliases: индикатор того, как alias объектов обрабатываются при поиске.

Семантика возможных значений данного поля следующая: NeverDerefAliases: не выполняются переходы по ссылкам для aliases при поиске или при размещении базового объекта поиска.DerefInSearching: выполняется переход по ссылкам aliases, подчиненных базовому объекту поиска.DerefFindingBaseObj: выполняется переход по ссылкам aliases, размещенных в базовом объекте поиска, но не в подчиненных базовому объекту.DerefAlways: выполняется переход по ссылкам aliases как при поиске, так и при размещении базового объекта поиска.

SizeLimit: ограничение размера максимального количества записей, возвращаемых в качестве результата поиска. Значение 0 в данном поле указывает, что при поиске нет ограничения размера пользовательского запроса. Серверы могут определять максимальное количество возвращаемых записей.TimeLimit: ограничение, определяющее максимальное время поиска (в секундах). Значение 0 в данном поле указывает, что ограничений по времени при запросах клиента не существует.TypesOnly: индикатор того, что результаты поиска содержат и типы, и значения атрибутов или только типы атрибутов. При установке данного значения в TRUE будут возвращаться только типы атрибутов. При установке данного значения в FALSE будут возвращаться и типы, и значения атрибутов.Filter: фильтр определяет условия, которые должны быть выполнены.

and, or и not используются для комбинирования фильтров. По крайней мере, один элемент фильтра должен присутствовать.



Сервер должен вычислить фильтры. Результатом вычисления фильтра должно быть либо TRUE, либо FALSE, либо Undefined. Если фильтр вычисляет TRUE для конкретной записи, то атрибуты данной записи возвращаются как часть результата поиска. Если фильтр вычисляет FALSE или Undefined, то данная запись при поиске игнорируется.

Правило соответствия для элемента фильтра equalityMatch определяется правилом соответствия EQUALITY для типа атрибута.


Рис. 15.1.  Область baseObject


Рис. 15.2.  Область singleLevel


Рис. 15.3.  Область wholeSubtree

Правило соответствия для AssertionValues фильтра определяется правилом соответствия SUBSTR для типа атрибута.



Правило соответствия для элементов фильтра greaterOrEqual и lessOrEqual определяется правилом соответствия ORDERING для типа атрибута.

Семантика соответствия для элементов фильтра approxMatch определяется реализацией.

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

Атрибуты должны быть поименованы самое большее один раз в списке и возвращаться самое большее один раз в записи. Если в списке существуют описания атрибутов, которые не распознаны, они игнорируются сервером.

Если клиент не хочет, чтобы возвращались какие-либо атрибуты, он может указать список, содержащий только атрибут с OID "1.1". Этот OID был выбран произвольно и не соответствует никакому используемому атрибуту.

Следует заметить, что если запрошены все атрибуты пользователя, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены, т.к. эти атрибуты могут иметь большое число значений.

Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в SearchResponses, которые являются сообщениями LDAP, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.

SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } PartialAttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } -- следует заметить, что PartialAttributeList -- может иметь ноль элементов (если ни один -- из атрибутов затребованной записи не может -- быть возвращен) и что множество vals может -- также иметь ноль элементов (если запрошены -- только типы или все значения были -- исключены из результата) SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL -- по крайней мере один элемент LDAPURL -- должен присутствовать SearchResultDone ::= [APPLICATION 5] LDAPResult



После получения SearchRequest сервер будет выполнять необходимый поиск в DIT.

Сервер может возвращать как найденные записи (SearchResultEntry), так и ссылки на другие серверы для продолжения поиска (SearchResultReference).

Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.

Например, предположим, что сервер (hosta), с которым соединяются, имеет запись DC=Example, DC=NET и запись CN=Manager, DC=Example, DC=NET. Он знает, что один из LDAP-серверов, hostb или hostc, имеет поддерево OU=People, DC=Example, DC=NET и что LDAP-сервер hostd имеет поддерево OU=Roles, DC=Example, DC=NET. Если сделан запрос поиска по поддереву DC=Example, DC=NET, он может возвратить следующее:

SearchResultEntry for DC=Example,DC=NET SearchResultEntry for CN=Manager,DC=Example, DC=NET SearchResultReference { ldap://hostb/OU=People,DC=Example,DC=NET ldap://hostc/OU=People,DC=Example,DC=NET } SearchResultReference { Lightweight Directory Access Protocol Version 3 ldap://hostd/OU=Roles,DC=Example,DC=NET } SearchResultDone (success)

В качестве продолжения примера, если клиент соединяется с сервером hostb и создает запрос для поддерева "OU=People, DC=Example, DC=NET", сервер может вернуть следующее:

SearchResultEntry for OU=People,DC=Example,DC=NET SearchResultReference { ldap://hoste/OU=Managers,OU=People, DC=Example,DC=NET } SearchResultReference { ldap://hostf/OU=Consultants,OU=People, DC=Example,DC=NET } SearchResultDone (success)

Если сервер, с которым установлено соединение, не имеет базового объекта для поиска, то он возвращает клиенту ссылку (referral). Например, если клиент запросил у hosta поиск поддерева DC=Example, DC=ORG, сервер может вернуть только SearchResultDone, содержащий referral.

SearchResultDone (referral) { ldap://hostg/DC=Example,DC=ORG??sub }

Операция Unbind

Функция операции Unbind состоит в завершении сессии протокола. Операция Unbind определяется следующим образом:

UnbindRequest ::= [APPLICATION 2] NULL

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

Протокол LDAP

Основные свойства протокола LDAP:

Используется клиент-серверная модель.Может быть сделано несколько запросов за один раз – каждый ответ содержит идентификатор сообщения запроса.В протоколе определено 9 основных операций протокола – запрос информации (2 операции), изменение информации (4 операции), аутентификация и управление (2 операции).LDAPv3 предоставляет расширенные операции и расширенные возможности управления.

Протокол LDAP описывается с использованием ASN.1, используя подмножество BER.

Для обеспечения расширяемости клиенты и серверы должны игнорировать часть последовательности элементов, чьи теги они не распознали.

Клиент указывает версию, которую он использует, как часть запроса Bind. Клиенты могут определить версии протокола, которые поддерживает сервер, по атрибуту supportedLDAPVersion из корневой записи сервера. Серверы, которые реализуют версию 3, должны предоставлять данный атрибут.

Все операции протокола инкапсулированы в общий конверт LDAPMessage, который определяется следующим образом:

LDAPMessage ::= SEQUENCE { messageID MessageID, protocolOp CHOICE { bindRequest BindRequest, bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, modifyRequest ModifyRequest, modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modDNRequest ModifyDNRequest, modDNResponse ModifyDNResponse, compareRequest CompareRequest, compareResponse CompareResponse, abandonRequest AbandonRequest, extendedReq ExtendedRequest, extendedResp ExtendedResponse, ... }, controls [0] Controls OPTIONAL } MessageID ::= INTEGER (0 .. maxInt) maxInt INTEGER ::= 2147483647 -- (231 – 1) --

LDAPMessage обеспечивает конверт, содержащий общие поля, необходимые всем обменам протокола. В настоящий момент общими полями являются только messageID и controls.

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

Обычно клиенты увеличивают значение messageID для каждого запроса.

Ответы сервера содержат значение messageID из соответствующего запроса.

Control представляет собой способ специфицировать информацию расширения для сообщения LDAP. Control только изменяет семантику сообщения, к которому он присоединен.

Controls ::= SEQUENCE OF Control Control ::= SEQUENCE { controlType LDAPOID, criticality BOOLEAN DEFAULT FALSE, controlValue OCTET STRING OPTIONAL }

Поле controlType должно быть представлено в UTF-8 в виде OBJECT IDENTIFIER, который однозначно идентифицирует control. Это предотвращает конфликты между именами control.

Поле criticality является либо TRUE, либо FALSE, и встречается в сообщениях запроса, которые имеют соответствующее сообщение ответа. Для всех других сообщений (например, abandonRequest, unbindRequest и всех сообщений ответа) поле criticality устанавливается в FALSE.

Если сервер распознает тип control, и он соответствует операции, сервер при выполнении операции будет использовать control.

Если сервер не распознает тип control, или он не соответствует операции, и поле criticality есть TRUE, сервер не должен выполнять операцию и вместо этого возвращает resultCode unavailableCriticalExtension.

Если control не распознан или соответствующий бит в поле criticality есть FALSE, сервер должен игнорировать control.

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

LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), -- 9 зарезервировано -- referral (10), adminLimitExceeded (11), unavailableCriticalExtension (12), confidentialityRequired (13), saslBindInProgress (14), noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), -- 22-31 не используются -- noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), -- 35 зарезервировано для неопределенного -- -- isLeaf -- aliasDereferencingProblem (36), -- 37-47 не используются -- inappropriateAuthentication (48), invalidCredentials (49), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), -- 55-63 не используются -- namingViolation (64), objectClassViolation (65), notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), objectClassModsProhibited (69), -- 70 reserved for CLDAP -- affectsMultipleDSAs (71), -- 72-79 не используются -- other (80), ... }, -- 81-90 зарезервировано для APIs -- matchedDN LDAPDN, diagnosticMessage LDAPString, referral [3] Referral OPTIONAL }

Коды результата являются расширяемыми.

Расширенные операции

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

Расширенная операция позволяет клиенту делать запросы и получать ответы с предопределенными синтаксисом и семантикой. Каждый запрос должен иметь уникальный OBJECT IDENTIFIER.

ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL }

requestName есть разделенное точками представление OBJECT IDENTIFIER, соответствующего запросу. requestValue есть информация в форме, определенной данным запросом, инкапсулированная в OCTET STRING.

Сервер отвечает LDAPMessage, содержащим ExtendedResponse.

ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL }

Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.

Типичные переговоры LDAP операции Bind

Рис. 15.0.  Типичные переговоры LDAP операции Bind

Операция Bind передает аутентификационную информацию от клиента к серверу.

Запрос Bind определен следующим образом:

BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication AuthenticationChoice } AuthenticationChoice ::= CHOICE { simple [0] OCTET STRING, -- 1 и 2 зарезервированы sasl [3] SaslCredentials, ... } SaslCredentials ::= SEQUENCE { mechanism LDAPString, credentials OCTET STRING OPTIONAL }

Параметрами запроса Bind являются:

Version: номер версии, указывает используемую версию протокола. В настоящий момент максимальная версия протокола равна 3. Заметим, что переговоров о номере версии не ведется, клиент просто посылает данный параметр. Если сервер не поддерживает указанную версию, он отвечает protocolError в поле resultCode в BindResponce.Name: имя объекта директории, к которой клиент хочет присоединиться. Данное поле может иметь нулевое значение (строку нулевой длины) для анонимного связывания или когда используется SASL аутентификация.Authentication: информация, используемая для аутентификации имени, указанного в запросе Bind. Серверы, которые не поддерживают выбор, предлагаемый клиентом, будут возвращать authMethodNotSupported в коде результата для запроса Bind. Аутентификацию с использованием механизмов SASL мы рассматривать не будем, так как эти способы аутентификации в инфраструктуре открытого ключа при доступе к репозиторию LDAP сейчас не используются.

Ответ Bind определяется следующим образом.

BindResponse ::= [APPLICATION 1] SEQUENCE { COMPONENTS OF LDAPResult, serverSaslCreds [7] OCTET STRING OPTIONAL }

BindResponce состоит из индикации от сервера статуса запроса клиента на аутентификацию.

Если связывание прошло успешно, то resultCode будет success, в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError.

Альтернативное имя субъекта

Расширение альтернативных имен субъекта допускает дополнительные идентификации, связанные с субъектом сертификата. Данная опция включает e-mail адрес, DNS-имя, IP-адрес и URI. Существуют и другие формы имени, в том числе полностью локальные определения. Может быть включено несколько форм имени и несколько экземпляров для каждой из них. Если подобные идентификации необходимо ввести в сертификат, должно использоваться расширение, описывающее альтернативное имя субъекта (или альтернативное имя выпускающего); однако DNS-имя может быть представлено в поле субъекта посредством атрибута domainComponent.

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

Более того, если идентификация субъекта, включенная в сертификат, является только формой альтернативного имени (например, адрес электронной почты), то расширение subjectAltName должно быть помечено как критичное.

Когда расширение subjectAltName содержит электронный адрес, он должен иметь вид, определенный в RFC 822, т.е. иметь форму local-part@domain.

Когда расширение subjectAltName содержит iPAddress, адрес должен храниться в строке октетов в "сетевом порядке байтов", как определено в RFC 791. Для IP версии 4 строка октетов должна содержать строго четыре октета. Для IP версии 6 строка октетов должна содержать строго 16 октетов.

Когда расширение subjectAltName содержит метку доменного имени системы, доменное имя должно храниться в dNSName (IA5String). Имя должно иметь вид, определенный в RFC 1034. Заметим, что хотя буквы верхнего и нижнего регистров в доменном имени допустимы, регистр не имеет значения. Кроме того, хотя строка " " является допустимым доменным именем, расширения subjectAltName с dNSName в виде " " использоваться не должны. Наконец, использование DNS-представления для адресов e-mail (xxx.cmc.msu.ru вместо xxx@cmc.msu.ru) не допускается.

Замечание: в настоящее время ведется работа по представлению доменных имен в международном наборе символов.

Такие имена не могут быть представлены в виде IA5String. После того как работа будет завершена, данный стандарт будет пересмотрен, и будут добавлены соответствующие функциональности.

Когда расширение subjectAltName содержит URI, имя должно храниться в uniformResourceIdentifier (как IA5String). Имя не должно быть относительным URL и должно следовать синтаксису URL и правилам представления, описанным в RFC 1738. Имя должно включать схему (например, HTTP или FTP) и конкретную часть этой схемы. Конкретная часть схемы должна включать полностью определенное доменное имя или IP-адрес хоста.

Как указано в RFC 1738, имя схемы нечувствительно к регистру (т.е. http эквивалентно HTTP). Часть хоста также нечувствительна к регистру, но остальные компоненты конкретной части схемы могут быть чувствительны к регистру.

Когда расширение subjectAltName содержит DN в directoryName, DN может не быть уникальным для субъекта, который сертифицируется СА, определяемым полем issuer name. СА может выпустить более одного сертификата с одним и тем же DN для некоторого субъекта.

subjectAltName может поддерживать дополнительные типы имен с помощью поля otherName. Формат и семантики имени определяются с помощью OBJECT IDENTIFIER. Само имя определяется как значение поля otherName. Например, имена формата Kerberos могут быть представлены в otherName с использованием OID-имени принципала Kerberos и последовательности Realm и PrincipalName.

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

Если расширение subjectAltName присутствует, последовательность должна содержать, по крайней мере, одну запись. В отличие от поля субъекта, САs не должны выпускать сертификаты с subjectAltNames, содержащими пустые поля GeneralName. Например, rfc822Name представляется как IA5String. Хотя IA5String допускает пустую строку, такое rfc822Name использоваться не должно.

id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } SubjectAltName ::= GeneralNames GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } EDIPartyName ::= SEQUENCE { nameAssigner [0] DirectoryString OPTIONAL partyName [1] DirectoryString }

Альтернативные имена выпускающего

Данное расширение используется для связывания идентификации в стиле Internet с выпускающим сертификаты. Альтернативные имена выпускающего должны иметь такое же представление, как альтернативные имена субъекта.

Когда данное расширение присутствует, оно не должно быть помечено как критичное.

id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } IssuerAltName ::= GeneralNames

Атрибуты директории субъекта

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

id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Базовые ограничения

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

Булевское значение сА указывает, принадлежит ли сертифицированный открытый ключ СА. Если булевское значение сА не установлено, то бит keyCertSign в расширении использования ключа не должен быть установлен.

Поле pathLenConstrant имеет смысл, только если булевское значение сА установлено, и в расширении использования ключа установлен бит keyCertSign. В этом случае данное поле определяет максимальное число несамовыпущенных промежуточных сертификатов, которые могут следовать за данным сертификатом в действительном сертификационном пути. Сертификат является самовыпущенным, если DNs, которые присутствуют в полях субъекта и выпускающего, являются одинаковыми и не пустыми. Когда pathLenConstraint не присутствует, никаких ограничений не предполагается.

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

САs не должны включать поле pathLenConstraint, если булевское значение сА не установлено и расширение использования ключа не имеет бит keyCertSign.

id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } BasicConstraints ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL }

Частные расширения Internet

На сегодня определено два расширения для использования в PKI Internet. Эти расширения могут применяться для предоставления приложениям on-line информации о выпускающем СА или о субъекте. Так как информация может быть доступна в нескольких формах, каждое расширение является последовательностью IA5String значений, представляющих собой URI. URI неявно определяют размещение и формат информации, а также метод ее получения.

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

Действительность сертификата

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

САs должны всегда указывать даты действительности сертификата до 2049 года как UTCTime; даты действительности сертификатов, начиная с 2050 года и далее, должны быть представлены как GeneralizedTime. Основная разница между представлениями времени в UTCTime и в GeneralizedTime заключается в том, что в UTCTime для значения года отводится две цифры, а в GeneralizedTime – четыре. В случае UTCTime, если год больше или равен 50, то он должен интерпретироваться как 19YY, а если год меньше 50, то он должен интерпретироваться как 20YY.

Период действительности сертификата является периодом времени от notBefore до notAfter включительно.

Доступ к информации уполномоченного органа

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

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription AccessDescription ::= SEQUENCE { accessMethod OBJECT IDENTIFIER, accessLocation GeneralName } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

Каждая запись в последовательности AuthorityInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставляемой СА, который выпустил сертификат с данным расширением. Тип и формат информации определяется полем accessMethod; в поле accessLocation указывается место размещения информации. Механизм получения может предполагаться accessMethod или указываться accessLocation.

В настоящий момент определено два accessMethod OIDs:

id-ad-caIssuers и id-ad-ocsp.

Когда accessMethod представляет собой id-ad-caIssuers, поле accessLocation определяет сервер и протокол доступа для получения указанного описания. Поле accessLocation определяется как GeneralName, которое может принимать несколько форм. Когда информация доступна через HTTP, FTP или LDAP, accessLocation должно быть uniformResourceIdentifier. Когда информация доступна через Протокол Доступа к Директории (DAP), accessLocation должно быть directoryName. Запись для этого directoryName содержит сертификаты СА в атрибуте crossCertificatePair. Когда информация доступна через e-mail, accessLocation должен быть rfc822Name.

id-ad-ocsp OID используется, когда информация отмены для сертификата, содержащего данное расширение, доступна с использованием Online Certificate Status Protocol (OCSP). В этом случае в поле accessLocation указывается размещение OCSP сервера.

Идентификатор ключа сертификационного центра

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

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

Значение поля keyIdentifier должно быть получено из открытого ключа, используемого для проверки подписи сертификата, или методом, который создает уникальные значения. Рассмотрим два метода создания идентификаторов ключей из открытого ключа и один метод создания уникальных значений для keyIdentifier. Если идентификатор ключа не был предварительно определен, рекомендуется использовать один из этих методов для создания keyIdentifiers. Если идентификатор ключа был предварительно определен, СА должен задействовать предварительно определенный идентификатор.

Рекомендуется поддерживать метод идентификации ключа всем пользователям сертификатов.

Данное расширение не должно помечаться как критичное.

id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } KeyIdentifier ::= OCTET STRING

Идентификатор ключа субъекта

Расширение идентификатора ключа субъекта предоставляет способ идентификации сертификата, содержащего конкретный открытый ключ.

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

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

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

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

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

Данное расширение не должно быть помечено как критичное.

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } SubjectKeyIdentifier ::= KeyIdentifier

Информация открытого ключа субъекта

Данное поле используется для указания использования открытого ключа, в частности для идентификации алгоритма данного ключа (например, RSA, DSA или Diffie-Hellman). Алгоритм идентифицируется использованием AlgorithmIdentifier структуры. Идентификаторы объекта для поддерживаемых алгоритмов и методы представления материала открытого ключа (т.е. открытый ключ и параметры) определяются IANA.

Информационный доступ субъекта

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

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription AccessDescription ::= SEQUENCE { accessMethod OBJECT IDENTIFIER, accessLocation GeneralName }

Каждая запись в последовательности SubjectInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставленной субъектом сертификата, в котором данное расширение появилось. Тип и формат информации определяется полем accessMethod; в поле accessLocation указывается место размещения информации.

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

id-ad-caRepository OID используется, когда субъект является СА и публикует свои сертификаты и CRLs (если выпускает) в репозотории. Поле accessLocation определено как GeneralName, которое может иметь несколько форм. Когда информация доступна через HTTP, FTP или LDAP, accessLocation должен быть uniformResourceIdentifier. Когда информация доступна через Протокол Доступа к Директории (DAP), accessLocation должен быть directoryName. Когда информация доступна по e-mail, accessLocation должен быть rfc822Name. Семантики остальных форм имени для accessLocation (когда accessLocation есть id-ad-caRepository) в настоящее время не определены.

id-ad-timeStamping OID используется, когда субъект предоставляет сервисы отметки времени, используя Протокол Отметки Времени. Когда сервисы отметки времени доступны по HTTP или FTP, accessLocation должен быть uniformResourceIdentifier. Когда сервисы отметки времени доступны по e-mail, accessLocation должен быть rfc822Name. Когда сервисы отметки времени доступны посредством TCP/IP, могут использоваться формы имен dNSName или ipAddress. Семантика других форм имени для accessLocation (когда accessLocation есть id-ad-timeStamping) в настоящий момент не определена.

Использование ключа

Расширение keyUsage определяет назначение (например, шифрование, подпись, подписывание сертификатов) ключа, содержащегося в сертификате. Ограничение использования должно применяться, когда ключ ограничивается использованием только в одной операции. Например, когда ключ RSA должен использоваться только для проверки подписей для объектов, отличных от сертификатов открытого ключа и CRLs, биты digitalSignature и/или nonRepudiation должны присутствовать. Также когда ключ RSA должен использоваться только для транспортировки ключа, бит keyEncipherment должен присутствовать.

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

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } keyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) }

Биты в keyUsage типе используются следующим образом:

Бит digitalSignature установлен, когда окрытый ключ субъекта используется с механизмом цифровой подписи для поддержки сервисов безопасности, отличных от подписывания сертификата (бит 5) или подписывания CRL (бит 6). Например, если механизмы цифровых подписей используются для аутентификации участника или аутентификации и целостности исходных данных.

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

Более тонкое различие между битами digitalSignature и nonRepudiation может определяться конкретными политиками сертификации.

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

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

Бит keyAgreement установлен, когда открытый ключ субъекта используется для согласования ключа. Например, когда ключ Диффи-Хеллмана используется для управления ключом, этот бит установлен.

Бит keyCertSign установлен, когда открытый ключ субъекта используется для проверки подписи в сертификатах открытого ключа. Если бит keyCertSign установлен, то бит сА в расширении базовых ограничений также должен быть установлен.

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

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

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

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

Issuer

Поле issuer идентифицирует того, кто подписал и выпустил сертификат. Поле issuer должно содержать непустое уникальное имя (DN). Имя определяется в соответствии со следующей ASN.1 структурой:

Name ::= CHOICE { RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY DEFINED BY AttributeType

Имя описывает иерархическое имя, состоящее из атрибутов, таких, например, как название страны, и соответствующих значений, таких как RU. Тип компонента AttributeValue определяется значением AttributeType.

Стандарт Х.509 не ограничивает набор типов атрибутов, которые могут появиться в имени. Тем не менее, стандартом рекомендуется поддерживать следующие типы атрибутов в именах выпускающего и субъекта:

СтранаОрганизацияОрганизационная единицаОбозначение уникального имениНазвание штата или регионаОбщепринятое имя (например, Иванов Иван)Серийный номер

Дополнительно могут присутствовать некоторые другие типы атрибутов в именах выпускающего и субъекта, например:

ЛокализацияЗаголовокОтчествоНазначенное имяИнициалыПсевдонимСпециальное название (например, "Jr.", "3-ий" или "IV").

Также может присутствовать атрибут domainComponent. DNS предоставляет собой иерархическую систему обозначения ресурсов. Данный атрибут предоставляет удобный механизм для организаций, которые хотят использовать уникальные DN имена параллельно со своими DNS-именами. Это не заменяет dNSName компонент альтернативного поля имени. Стандарт не требует конвертировать такие имена в DNS-имена.

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

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

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

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

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

Для URIs ограничение применяется только к части хоста из имени. Ограничение может указывать хост или домен. Примерами могут служить cmc.msu.ru или .msu.ru. Когда ограничение начинается с точки, оно соответствует одному или более поддоменам. Это означает, что ограничению .msu.ru удовлетворяют как cmc.msu.ru, так и oit.cmc.msu.ru. Когда ограничение не начинается с точки, оно определяет хост.

Ограничение имени для e-mail адресов может специфицировать конкретный почтовый ящик, все адреса на конкретном хосте или все почтовые ящики в домене. Для указания конкретного почтового ящика ограничение должно содержать полный почтовый адрес. Например, xxx@cmc.msu.ru определяет почтовый ящик "xxx" на хосте cmc.msu.ru. Для указания любого адреса в домене ограничение указывается с ведущей точкой (как в URIs). Например, .msu.ru специфицирует все e-mail адреса в домене msu.ru, а не только e-mail адреса на хосте msu.ru.

Ограничения DNS имени выражены как cmc.msu.ru. Любое DNS-имя, которое может быть сконструировано простым добавлением слева, соответствует ограничению имени. Например, oit.cmc.msu.ru будет удовлетворять ограничению, а mm.msu.ru – нет.

Существуют наследуемые реализации, в которых имя RFC 822 встроено в уникальное имя субъекта в виде атрибута типа EmailAddress. Когда имена rfc822 имеют ограничения, но сертификат не содержит альтернативного имени субъекта, ограничение имени rfc822 должно применяться к атрибуту типа EmailAddress в уникальном имени субъекта.

Ограничения формы directoryName должны применяться к полю субъекта в сертификате и к расширениям subjectAltName типа directoryName.

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

id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL } BaseDistance ::= INTEGER (0..MAX)

Ограничения политики

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

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

Если поле requireExplicitPolicy присутствует, значение requireExplicitPolicy указывает количество дополнительных сертификатов, которые могут появиться в пути до того, как потребуется явное указание политики. Когда требуется явная политика, необходимо, чтобы все сертификаты в пути содержали идентификатор принимаемой политики. Идентификатор принимаемой политики является идентификатором политики, принимаемой пользователем, или идентификатором политики, которая объявлена эквивалентной посредством отображения политик.

Конформные САs не должны выпускать сертификаты, в которых ограничения политики являются пустой последовательностью. Это означает, что, по крайней мере, одно из полей requireExplicitPolicy или inhibitPolicyMapping должно присутствовать.

Данное расширение может быть как критичным, так и некритичным.

id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } PolicyConstraints ::= SEQUENCE { requireExplicitPolicy [0] SkipCerts OPTIONAL, inhibitPolicyMapping [1] SkipCerts OPTIONAL } SkipCerts ::= INTEGER (0..MAX)

Основные поля сертификата

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

Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- если присутствует, версия должна -- быть v2 или v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- если присутствует, версия должна быть -- v2 или v3 extensions [3] EXPLICIT Extensions OPTIONAL -- если присутствует, версия должна быть v3 } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }

Отмена сертификата

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

Х.509 определяет один метод отмены сертификата. Данный метод предполагает, что каждый СА периодически выпускает подписанную структуру данных, называемую списком отмененных сертификатом (CRL). CRL является помеченным временем списком, который подписан СА или специальным выпускающим CRL и в котором перечислены отмененные сертификаты. Данный список становится свободно доступен в открытом репозитории. Каждый отмененный сертификат идентифицируется в CRL своим серийным номером. Когда использующая сертификат система получает сертификат (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и действительность, но также получает свежий CRL и проверяет, не находится ли в этом CRL серийный номер сертификата. Понятие "свежий" может зависеть от локальной политики, но обычно означает самый последний выпущенный CRL. Новый CRL выпускается регулярно (например, каждый час, день или неделю). При получении уведомления об отмене запись добавляется в CRL.

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

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

Как и формат сертификата Х.509 v3, для того, чтобы обеспечить интероперабельность реализаций различных производителей, необходимо иметь строгий формат Х.509 CRL v2. Существуют также специальные протоколы и соответствующие им форматы сообщений, поддерживающих on-line оповещения об отмене. On-line методы оповещения об отмене могут применяться в некоторых окружениях как альтернатива CRL. On-line проверка отмены может существенно уменьшить промежуток между отправкой сообщения об отмене и получением этой информации проверяющей стороной. После того как СА принимает и аутентифицирует сообщение от субъекта сетификата или от RA о необходимости отмены данного сертификата, любой запрос к on-line сервису будет корректно отображать действительность сертификата. Однако эти методы навязывают новые требования безопасности: проверяющая сторона должна доверять on-line сервису действительности, в то время как репозиторий не обязательно должен быть доверяемым.

Отображения политик

Данное расширение используется в сертификатах СА. Оно перечисляет одну или более пар OIDs; каждая пара включает issuerDomainPolicy и subjectDomainPolicy. Пара определяет, что выпустивший СА считает свою issuerDomainPolicy эквивалентной subjectDomainPolicy субъекта СА.

Отображение политик определяет список политик, связанных с субъектом СА, которые могут приниматься как эквивалентные issuerDomainPolicy.

Каждая issuerDomainPolicy, перечисленная в расширении отображения политик, должна также быть установлена в расширении политик сертификата в том же самом сертификате. Политики не должны отображаться в специльное значение anyPolicy.

Данное расширение может не поддерживаться САs и/или приложениями, и оно не должно быть критичным.

id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { issuerDomainPolicy CertPolicyId, subjectDomainPolicy CertPolicyId }

Период использования закрытого ключа

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

Увеличение периода использования закрытого ключа позволяет выпускающему сертификат указать период действительности закрытого ключа, отличный от периода действительности сертификата. Данное расширение предназначено для использования с ключами цифровых подписей. Расширение состоит из двух необязательных компонентов, notBefore и notAfter. Закрытый ключ, связанный с сертификатом, не должен использоваться для подписывания объектов до и после времени, указанного соответственно этими двумя компонентами. САs не должны создавать сертификаты с расширениями периода использования закрытого ключа, если, по крайней мере, один из компонентов не присутствует; расширение является некритичным.

Если расширение используется, notBefore и notAfter представлены как GeneralizedTime.

id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } PrivateKeyUsagePeriod ::= SEQUENCE { notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL }

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

Расширение политик сертификата certificatePolicies содержит последовательность из одного или более идентификаторов политики, каждый из которых может иметь квалификатор. Эти квалификаторы не должны изменять определение политики.

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

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

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

В настоящий момент определено два типа квалификаторов политики: CPS Pointer и User Notice.

Квалификатор CPS Pointer содержит указатель на Certification Practice Statement (CPS) – регламент сертификационной практики, опубликованный СА. Указатель должен быть представлен в виде URI.

Считается, что квалификатор User Notice будет показан соотвествующему участнику при использовании сертификата. Данный квалификатор имеет два необязательных поля: поле noticeRef и поле explicitText.

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

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

Поле explicitText включает текст непосредственно в сертификат. Оно является строкой максимального размера 200 символов.

Обе опции notifyRef и explicitText включаются в один квалификатор, и если ПО приложения может разместить текст уведомления, указанный опцией noticeRef, то этот текст должен быть показан; в противном случае должна быть показана строка explicitText.

id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } certificatePolicies ::= SEQUENCE SIZE ( 1..MAX) OF PolicyInformation PolicyInformation ::= SEQUENCE { policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL } CertPolicyId ::= OBJECT IDENTIFIER PolicyQualifierInfo ::= SEQUENCE { policyQualifierId PolicyQualifierId, qualifier ANY DEFINED BY policyQualifierId } -- policyQualifierIds для квалификаторов -- политики в Internet id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) Qualifier ::= CHOICE { cPSuri CPSuri, userNotice UserNotice } CPSuri ::= IA5String UserNotice ::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } NoticeReference ::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText ::= CHOICE { ia5String IA5String (SIZE (1..200)), visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) }

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

Сертификат есть последовательность трех обязательных полей: tbsCertificate, signatureAlgorithm и signatureValue.

Предотвращение anyPolicy

Расширение предотвращения anyPolicy может быть использовано в сертификатах, выпущенных САs. Предотвращение any-policy указывает, что конкретный anyPolicy OID со значениями { 2 5 29 32 0 } не считается явно соответствующим остальным политикам сертификата. Значение определяет количество дополнительных сертификатов, которые могут появиться в пути до того как anyPolicy будет запрещена. Например, значение, равное единице, указывает, что anyPolicy может быть обработана в сертификатах, выпущенных субъектом данного сертификата, но не в дополнительных сертификатах в пути.

Данное расширение должно быть критическим.

id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } InhibitAnyPolicy ::= SkipCerts SkipCerts ::= INTEGER (0..MAX)

Самый свежий CRL (точка распространения Delta CRL)

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

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

id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } FreshestCRL ::= CRLDistributionPoints

Расширения

Данное поле должно появляться только в том случае, если версия равна 3. Если оно присутствует, данное поле есть последовательность одного или более расширений сертификатов.

Расширения сертификата

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

Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются. Рассмотрим рекомендуемые в Internet расширения сертификатов. Могут использоваться дополнительные расширения; однако следует осторожно устанавливать любые критические расширения в сертификаты, так как это может препятствовать проверке действительности сертификатов.

Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле extnID, и соответствующая ASN.1 структура представления является значением строки октетов extnValue. Сертификат не должен включать более одного экземпляра конкретного расширения. Например, сертификат может содержать только одно расширение для идентификатора ключа уполномоченного органа. Расширение включает булево значение критичности со значением по умолчанию, равным FALSE. Для каждого расширения должны быть определены допустимые значения для поля критичности.

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

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

Могут также распознаваться расширения идентификаторов ключа сертификационного центра и субъекта и расширение отображения политики.

Расширенное использование ключа

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

id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER

Цели ключа могут быть при необходимости определены любой организацией.

Данное расширение может быть как критичным, так и некритичным.

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

Если СА включает расширенные использования ключа, чтобы соответствовать таким приложениям, но не хочет ограничивать использование ключа, он может включить специальный 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

Serial number

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

Сертификационные пути и доверие

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

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

Регистрационный уполномоченный орган политики Internet (IPRA): данный уполномоченный орган, функционирующий под руководством Internet-сообщества, действует в качестве корневого органа в сертификационной иерархии. Он выпускает сертификаты только для уполномоченных органов следующего уровня, PCAs. Все сертификационные пути начинаются с IPRA.Уполномоченные органы сертификатов политики (PCAs): PCAs являются вторым уровнем иерархии, каждый PCAs сертифицирован IPRA. РСА должны установить и опубликовать утверждение о своей политике в отношении сертифицируемых пользователей или подчиненных уполномоченных органов сертификации. Различные PCAs могут удовлетворять те или иные потребности пользователей. Например, один РСА может выпускать сертификаты для электронной почты, другой РСА может иметь политику, которая удовлетворяет более строгим законодательным требованиям в отношении цифровых подписей.Уполномоченные органы сертификации (САs): САs являются третьим уровнем иерархии, но могут иметь и более низкий уровень.

Те, что находятся на третьем уровне, сертифицируются PCAs. САs представляют, например, отдельные организации, отдельные единицы организации (департаменты, отделы, лаборатории) или отдельные географические единицы.

RFC 1422 определяет правило подчинения имен, которое требует, чтобы СА мог выпускать сертификаты только тем пользователям, чьи имена являются подчиненными (в дереве именования Х.500) по отношению к имени самого СА. Доверие, связанное с сертификационным путем, определяется именем РСА. Правило подчинения имен гарантирует, что САs, подчиняющиеся конкретному РСА, ограничены множеством участников, которых они могут сертифицировать (т.е. СА организации может сертифицировать только сотрудников данной организации). Системы сертификации пользователей должны иметь возможность автоматически проверять, выполняется ли правило подчинения имен.

RFC 1422 использует форматы сертификатов Х.509 v1. Ограничения Х.509 v1 требуют нескольких структурных ограничений на четкое связывание информации о политике или ограничения на использование сертификатов. Эти ограничения включают:

Строгую иерархию сверху вниз, все сертификационные пути начинаются от IPRA.Правило подчинения имен ограничивает имена субъектов CAs.Использование понятия РСА, которое требует знания индивидуальных PCAs, что встроено в логику проверки цепочки сертификатов. Знание индивидуальных PCAs требуется при определении возможности принятия цепочки сертификатов.

В Х.509 v3 большинство ограничений, определенных в RFC 1422, может быть указано в расширениях сертификата без необходимости иметь строгую иерархическую структуру САs. В частности, расширения сертификата, касающиеся политик, устраняют необходимость применения правила подчинения имен. Как результат, третья версия может поддерживать более гибкую архитектуру:

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

Пользователям открытого ключа требуются гарантии,

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

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

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

Signature

Данное поле содержит идентификатор алгоритма, используемого СА для подписывания сертификата.

Данное поле должно содержать тот же самый идентификатор алгоритма, что и поле signatureAlgorithm в Certificate. Содержание необязательного поля параметров зависит от конкретного алгоритма.

SignatureAlgorithm

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

Идентификатор алгоритма определяется следующей ASN.1-структурой:

AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }

Идентификатор алгоритма используется для определения криптографического алгоритма. Компонент OBJECT IDENTIFIER идентифицирует алгоритм (такой как DSA с SHA-1). Компоненты поля параметров изменяются в соответствии с указанным алгоритмом.

Поле должно содержать тот же самый идентификатор алгоритма, что и поле подписи в tbsCertificate.

SignatureValue

Поле signatureValue содержит цифровую подпись, вычисленную для поля tbsCertificate, записанном в DER-представлении ASN.1. Это означает, что поле tbsCertificate, представленное как ASN.1 DER, используется в качестве входа в функцию подписи. Полученное значение подписи представлено как BIT STRING и включено в поле подписи. Детали данного процесса могут отличаться для каждого конкретного алгоритма подписи.

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

Стандартные расширения

Рассмотрим стандартные расширения сертификата, определенные в стандарте X.509. Каждое расширение имеет определенный OID. Эти OIDs являются элементами id-ce множества, которое определено следующим образом:

id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

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.

Следует учитывать, что существуют наследуемые реализации сертификационных центров, в которых имя из RFC 822 встроено в уникальное имя субъекта как атрибут EmailAddress. Значение атрибута для EmailAddress является типом IA5String, благодаря чему допускается включение символа "@", который не входит в набор символов PrintableString. Значения атрибута EmailAddress нечувствительны к регистру (aaa@msu.ru – то же самое, что и AAA@MSU.RU ).

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

TbsCertificate

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

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

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

Расширение для точек распространения CRL определяет, как может быть получена информация CRL. Расширение должно быть некритичным, но рекомендуется, чтобы оно поддерживалось как САs, так и приложениями. Далее мы подробно рассмотрим управление CRL.

Расширение cRLDistributionPoints является последовательностью DistributionPoint. DistributionPoint состоит из трех полей, каждое из которых является необязательным: distributionPoint, reasons и cRLIssuer. Хотя каждое из этих полей является необязательным, DistributionPoint не должно состоять только из поля reasons; либо distributionPoint, либо cRLIssuer должно присутствовать. Если выпускающий сертификата не является выпускающим CRL, то поле cRLIssuer должно присутствовать и содержать имя выпускающего CRL. Если выпускающий сертификата является также и выпускающим CRL, то поле cRLIssuer должно быть опущено, и поле distributionPoint должно присутствовать. Если поле distributionPoint опущено, cRLIssuer должно присутствовать и включать имя, соответствующее записи Каталога Х.500 или LDAP, в которой размещен CRL.

Когда поле distributionPoint присутствует, оно содержит либо последовательность общих имен, либо единственное значение nameRelativeToCRLIssuer. Если расширение cRLDistributionPoints содержит общее имя типа URI, предполагается следующая семантика: URI является указателем на текущий CRL для соответствующих кодов причин и выпускается соответствующим cRLIssuer.

Если DistributionPointName содержит несколько значений, каждое имя описывает определенный механизм получения одного и того же CRL. Например, один и тот же CRL может быть доступен как по LDAP, так и по HTTP.

Если DistributionPointName содержит единственное значение nameRelativeToCRLIssuer, значение представляет собой фрагмент уникального имени. Фрагмент присоединяется к уникальному имени Х.500 выпускающего CRL для получения уникального указателя имени. Если поле cRLIssuer в DistributionPoint присутствует, то фрагмент имени присоединяется к уникальному имени выпускающего сертификат.

DistributionPointName не должно использовать альтернативное nameRelativeToCRLIssuer, когда cRLIssuer содержит более одного уникального имени.

Если в DistributionPoint поле reasons опущено, CRL должен включать информацию об отмене для всех кодов причин.

Поле сRLIssuer определяет участника, который подписал и выпустил CRL. Если оно присутствует, cRLIssuer должно содержать, по крайней мере, одно уникальное имя (DN) X.500 и может включать другие формы имени. Так как cRLIssuer сравнивается с именем выпускающего CRL,

id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint DistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL } DistributionPointName ::= CHOICE { fullName [0] GeneralNames, nameRelativeToCRLIssuer [1] RelativeDistinguishedName } ReasonFlags ::= BIT STRING { unused (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), privilegeWithdrawn (7), aACompromise (8) }

Уникальные идентификаторы

Данные поля должны присутствовать только в том случае, если версия сертификата есть 2 или 3. Эти поля не должны присутствовать, если версия равна 1. Уникальные идентификаторы субъекта и выпускающего представлены в сертификате для получения возможности повторного использования имен субъекта и/или выпускающего в более позднее время. САs не должны создавать сертификаты с одинаковыми идентификаторами.

Version

Данное поле описывает версию представления сертификата. Если используются расширения, то версия должна быть 3 (значение – 2). Если расширения не указаны, но UniqueIdentifier представлен, версия может быть 2 (значение – 1); но версия может быть и 3. Если представлены только базовые поля, версия может быть 1 (значение в сертификате опущено как значение по умолчанию); но версия может быть 2 или 3.

Реализации должны быть готовы принимать любую версию сертификата. Как минимум конформные реализации должны распознавать версию 3 сертификатов.

Рассмотрим стандартные расширения

Рассмотрим форматы сертификата Х.509 v3 и списка отмененных сертификатов (Certificate Revocation List – CRL) Х. 509 v2. Рассмотрим стандартные расширения сертификата и CRL и определим расширения, специфичные для Internet. Рассмотрим алгоритм проверки действительности сертификационного пути.

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

Пользователь сертификата должен просмотреть политику сертификата, созданную СА, прежде чем использовать сертификат.

---

---