Network Working Group Request for Comments: 4522 Категория: Standards Track S. Legg, eB2Bcom Июнь 2006 года
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
У каждого хранящегося в каталоге Lightweight Directory Access Protocol (LDAP) атрибута есть определённый синтаксис (то есть тип данных). В определении синтаксиса указывается как значения атрибутов, соответствующие этому синтаксису, обычно представлены при передаче в операциях LDAP. Такое представление называется специфичной для LDAP кодировкой, чтобы отличать его от других методов кодирования значений атрибутов. В этом документе определяется опция атрибута binary, которая может быть использована для указания того, что соответствующие значения атрибутов вместо специфичной для LDAP кодировки кодируются в соответствии с Основными правилами кодирования (Basic Encoding Rules, BER), используемыми в каталогах X.500.
У каждого хранящегося в каталоге 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 следует избегать.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14, RFC 2119 [BCP14].
Опция 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 оказывает влияние только на передачу значений атрибутов и утверждений в протоколе; серверы хранят любые значения конкретных атрибутов в выбранном ими формате.
Значения атрибутов некоторых синтаксисов атрибутов, в определениях которых нет специфичной для LDAP кодировки, должны передаваться в закодированной в BER форме. В этом документе мы будем называть такие синтаксисы синтаксисами, требующими двоичной передачи значений. Примеры синтаксисов, требующих двоичной передачи значений: сертификат, список сертификатов, пара сертификатов и поддерживаемый алгоритм [RFC4523]. У этих синтаксисов также имеется дополнительное требование, что точное BER-кодирование должно быть сохранено. Обратите внимание, что это свойство самих синтаксисов, а не свойство опции binary. В отсутствие данного требования LDAP-клиентам нужно было бы перекодировать значения с использованием Особых правил кодирования (Distinguished Encoding Rules, DER).
В поисковом запросе LDAP [RFC4511] содержится список атрибутов (список запрашиваемых атрибутов), которые должны быть возвращены из каждой записи, отобранной согласно поисковому фильтру. Указание описания атрибута в списке запрашиваемых атрибутов также неявно запрашивает все подтипы типа атрибута из этого описания атрибута, независимо от того, были ли эти подтипы образованы за счёт подтипирования атрибута или за счёт опций пометки [RFC4512].
Список запрашиваемых атрибутов может (MAY) содержать описания атрибутов с опцией binary, но не должен (MUST NOT) содержать двух описаний атрибутов с одним и тем же типом атрибута и с одними и теми же опциями пометки (даже если только у одного из них есть опция binary). Опция binary в описании атрибута в списке запрашиваемых атрибутов неявно применяется ко всем подтипам типа атрибута из этого описания атрибута (однако, смотрите раздел 7).
Если среди возвращаемых атрибутов есть атрибуты, синтаксисы которых требуют двоичной передачи значений, они должны (SHALL) быть возвращены в двоичной форме (то есть с опцией binary в описании атрибута и с соответствующим значением, закодированным в BER) независимо от того, присутствовала ли опция binary в запросе (для данного атрибута или одного из его супертипов).
Если среди возвращаемых атрибутов есть атрибуты, синтаксисы которых не требуют двоичной передачи значений, их следует (SHOULD) возвращать в той форме, в которой они были явно запрошены. То есть, если описание атрибута в списке запрашиваемых атрибутов содержит опцию binary, то соответствующему атрибуту в возвращаемом результате следует (SHOULD) быть в двоичной форме. Если описание атрибута в запросе не содержит опцию binary, то соответствующему атрибуту в возвращаемом результате не следует (SHOULD NOT) быть в двоичной форме. Сервер может (MAY) исключить атрибут из возвращаемого результата, если он не поддерживает запрошенную кодировку.
Независимо от выбранной кодировки, конкретное значение атрибута возвращается не более одного раза.
Если список атрибутов в поисковом запросе пуст или содержит специальную строку описания атрибута "*", то в этом случае запрашивается возвращение всех пользовательских атрибутов.
Если среди возвращаемых атрибутов есть атрибуты, синтаксисы которых требуют двоичной передачи значений, они должны (SHALL) быть возвращены в двоичной форме.
Атрибуты, синтаксисы которых не требуют двоичной передачи значений и имеют определение специфичной для LDAP кодировки, не следует (SHOULD NOT) возвращать в двоичной форме.
Атрибуты, синтаксисы которых не требуют двоичной передачи значений и не имеют определения специфичной для LDAP кодировки, могут быть возвращены в двоичной форме или исключены из возвращаемого результата.
Конкретный атрибут может быть явно запрошен путём указания описания атрибута и/или неявно запрошен путём указания описания атрибута одного или нескольких его супертипов, или же специальной строки описания атрибута "*". Если опция binary присутствует хотя бы в одном, но не во всех из этих описаний атрибутов, то эффект от такого запроса в отношении двоичной передачи определяется реализацией.
При интерпретации полей, влияющих на обеспечение безопасности, и, в частности, полей, используемых для предоставления или запрета доступа, реализации должны (MUST) гарантировать, что любые сравнения по правилам соответствия выполняются с использованием лежащих в основе абстрактных значений, независимо от конкретной применяемой кодировки.
Администрация адресного пространства Интернет (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
[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).
[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).