Перевод выполнен участниками проекта Pro-LDAP.ru. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.
Network Working Group
Request for Comments: 4522
Категория: Standards Track
S. Legg, eB2Bcom
Июнь 2006 года

Lightweight Directory Access Protocol (LDAP): Опция двоичного кодирования

Статус документа

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

Уведомление об авторских правах

Copyright (C) Internet Society (2006).

Тезисы

У каждого хранящегося в каталоге Lightweight Directory Access Protocol (LDAP) атрибута есть определённый синтаксис (то есть тип данных). В определении синтаксиса указывается как значения атрибутов, соответствующие этому синтаксису, обычно представлены при передаче в операциях LDAP. Такое представление называется специфичной для LDAP кодировкой, чтобы отличать его от других методов кодирования значений атрибутов. В этом документе определяется опция атрибута binary, которая может быть использована для указания того, что соответствующие значения атрибутов вместо специфичной для LDAP кодировки кодируются в соответствии с Основными правилами кодирования (Basic Encoding Rules, BER), используемыми в каталогах X.500.

Содержание

1. Введение

У каждого хранящегося в каталоге Lightweight Directory Access Protocol (LDAP) [RFC4510] атрибута есть определённый синтаксис (то есть тип данных), ограничивающий структуру и формат его значений.

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

В этом документе определяется опция атрибута binary, которая может быть использована в описании атрибута [RFC4512] в операции LDAP для указания того, что соответствующие значения атрибутов или значения утверждений кодируются (или должны быть закодированы) в соответствии с Основными правилами кодирования (Basic Encoding Rules, BER) [BER], используемыми в каталогах X.500 [X.500], вместо специфичной для LDAP кодировки.

Первоначально опция binary была определена в RFC2251. Техническая спецификация LDAP [RFC4510] отменила ранее определённую техническую спецификацию LDAP [RFC3377], включавшую RFC2251. Опция binary не была включена в пересмотренную техническую спецификацию LDAP по ряду причин, включая несогласованность реализации. В данном документе не делается попыток устранить известные несоответствия в реализациях спецификаций.

В этом документе заново вводится опция binary в целях использования с определёнными синтаксисами атрибутов, для которых она необходима, такими как синтаксис сертификата [RFC4523], поскольку она требуется при передаче значений, имеющих этот синтаксис. Не предпринимается попыток распространить использование опции binary с атрибутами, для передачи значений которых использование этой опции не является обязательным. Если это не будет оговариваться в будущих спецификациях, подобного применения опции binary следует избегать.

2. Соглашения

Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14, RFC 2119 [BCP14].

3. Опция binary

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

При наличии опции binary в описании атрибута, связанные значения атрибутов или значения утверждений должны (MUST) быть закодированы в BER (в противном случае эти значения кодируются согласно определённой для данного синтаксиса атрибута специфичной для LDAP кодировке [RFC4517]). Обратите внимание, что синтаксис может быть определён так, что его специфичная для LDAP кодировка будет точно такой же, как и его кодировка BER.

В терминах протокола [RFC4511] опция binary указывает, что октеты содержимого связанной строки октетов (OCTET STRING) AttributeValue или AssertionValue представляют собой соответствующее значение, полностью закодированное в BER.

Опция binary не является опцией пометки [RFC4512], поэтому наличие опции binary не определяет подтип атрибута. Описание атрибута, содержащее опцию binary, указывает на тот же самый атрибут, что и описание атрибута без этой опции. Наличие или отсутствие опции binary никоим образом не влияет на взаимоотношения супертипа/подтипа атрибута, связанные с опциями пометки.

Описание атрибута должно (SHALL) быть интерпретировано как нераспознанное, если оно содержит опцию binary, а синтаксис этого атрибута не имеет связанного типа ASN.1 [RFC4517], либо BER-кодирование значений такого типа не поддерживается.

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

4. Синтаксисы, требующие двоичной передачи

Значения атрибутов некоторых синтаксисов атрибутов, в определениях которых нет специфичной для LDAP кодировки, должны передаваться в закодированной в BER форме. В этом документе мы будем называть такие синтаксисы синтаксисами, требующими двоичной передачи значений. Примеры синтаксисов, требующих двоичной передачи значений: сертификат, список сертификатов, пара сертификатов и поддерживаемый алгоритм [RFC4523]. У этих синтаксисов также имеется дополнительное требование, что точное BER-кодирование должно быть сохранено. Обратите внимание, что это свойство самих синтаксисов, а не свойство опции binary. В отсутствие данного требования LDAP-клиентам нужно было бы перекодировать значения с использованием Особых правил кодирования (Distinguished Encoding Rules, DER).

5. Атрибуты, возвращаемые в операции поиска

В поисковом запросе LDAP [RFC4511] содержится список атрибутов (список запрашиваемых атрибутов), которые должны быть возвращены из каждой записи, отобранной согласно поисковому фильтру. Указание описания атрибута в списке запрашиваемых атрибутов также неявно запрашивает все подтипы типа атрибута из этого описания атрибута, независимо от того, были ли эти подтипы образованы за счёт подтипирования атрибута или за счёт опций пометки [RFC4512].

Список запрашиваемых атрибутов может (MAY) содержать описания атрибутов с опцией binary, но не должен (MUST NOT) содержать двух описаний атрибутов с одним и тем же типом атрибута и с одними и теми же опциями пометки (даже если только у одного из них есть опция binary). Опция binary в описании атрибута в списке запрашиваемых атрибутов неявно применяется ко всем подтипам типа атрибута из этого описания атрибута (однако, смотрите раздел 7).

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

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

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

6. Все пользовательские атрибуты

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

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

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

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

7. Противоречивые запросы

Конкретный атрибут может быть явно запрошен путём указания описания атрибута и/или неявно запрошен путём указания описания атрибута одного или нескольких его супертипов, или же специальной строки описания атрибута "*". Если опция binary присутствует хотя бы в одном, но не во всех из этих описаний атрибутов, то эффект от такого запроса в отношении двоичной передачи определяется реализацией.

8. О безопасности

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

9. Регистрация в IANA

Администрация адресного пространства Интернет (Internet Assigned Numbers Authority, IANA) обновила регистрацию опции описания атрибута LDAP [BCP64], как указано в следующей форме:

      Subject:
        Request for LDAP Attribute Description Option Registration
      Option Name: binary
      Family of Options: NO
      Person & email address to contact for further information:
        Steven Legg <steven.legg@eb2bcom.com>
      Specification: RFC 4522
      Author/Change Controller: IESG

10. Документы

10.1. Нормативные документы

[BCP14] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.

[BCP64] Zeilenga, K., "Соглашения Internet Assigned Numbers Authority (IANA) для протокола Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, июнь 2006 г.

[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Путеводитель по технической спецификации", RFC 4510, июнь 2006 г.

[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.

[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC 4512, июнь 2006 г.

[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Синтаксисы и правила соответствия", RFC 4517, июнь 2006 г.

[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, июнь 2006 г.

[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

10.2. Информативные документы

[RFC2251] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.

[RFC3377] Hodges, J. и R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, сентябрь 2002 г.

[X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.

Адрес автора

Dr. Steven Legg

eB2Bcom, Suite 3, Woodhouse Corporate Centre, 935 Station Street, Box Hill North, Victoria 3129, AUSTRALIA

Телефон: +61 3 9896 7830

Факс: +61 3 9896 7801

EMail: steven.legg@eb2bcom.com

Полное заявление авторских прав

Copyright (C) Internet Society (2006).

На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.

Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.

Интеллектуальная собственность

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

Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.

IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу ietf-ipr@ietf.org.

Признание заслуг

Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).

Перевод выполнен участниками проекта Pro-LDAP.ru. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.
Эта страница

Содержание

1. Введение2. Соглашения3. Опция binary4. Синтаксисы, требующие двоичной передачи5. Атрибуты, возвращаемые в операции поиска6. Все пользовательские атрибуты7. Противоречивые запросы8. О безопасности9. Регистрация в IANA10. ДокументыАдрес автораПолное заявление авторских правИнтеллектуальная собственностьПризнание заслуг
Lightweight Directory Access Protocol (LDAP): Опция двоичного кодирования
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!