This is an index of RFC contained in this directory:
rfc1274.txt COSINE and Internet X.500 Schema (PS)
-rfc1275.txt X.500 Replication Requirements (I)
rfc1279.txt X.500 and Domains (E)
rfc1308.txt Executive Intro to Directory Services - X.500 (FYI)
rfc1309.txt Technical Overview of Directory Services - X.500 (FYI)
rfc1430.txt Plan for Deploying an Internet X.500 Directory Service (I)
rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I)
-rfc1777.txt Lightweight Directory Access Protocol (DS)
-rfc1778.txt LDAP String Representation of Attribute Types (DS/updated)
-rfc1779.txt LDAP String Representation of DNs (DS/obsolete)
-rfc1781.txt Using the OSI Directory to Achieve User Friendly Naming (PS)
rfc1798.txt Connection-less LDAP (PS)
rfc1823.txt LDAP C API (I)
-rfc1960.txt LDAP String Representation of Search Filters (PS/obsolete)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2119.txt Key words (BCP)
rfc2164.txt X.500/LDAP MIXER address mapping (PS)
rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
-rfc2559.txt Internet X.509 PKI Operational Protocols - LDAPv2 (PS,updates)
rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2596.txt Use of Language Codes in LDAP (PS)
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S.E. Hardcastle-Kille
-Requests for Comments 1275 University College London
- November 1991
-
-
-
-
-
-
-
-
-Replication Requirements to provide an Internet Directory using X.500
-
-
-
-
-
-
-
-
-
-
-Status of this Memo
- This memo provides information for the Internet community. It
- does not specify an Internet standard. Distribution of this memo
- is unlimited.
-Abstract
-
- This RFCconsiders certain deficiencies of the 1988 X.500
- standard, which need to be addressed before an effective open
- Internet Directory can be established using these protocols and
- services [CCI88]. The only areas considered are primary
- problems, to which solutions must be found before a pilot can be
- deployed. This RFCconcerns itself with deficiencies which can
- only be addressed by use of additional protocol or procedures for
- distributed operation.
-\f
-
-
-
-RFC 1275 Replication Requirements November 1991
-
-
-1 Distributed Operation Extensions
-
-The Internet Directory will operate DSAs over TCP/IP using RFC 1006
-[RC87], and DSAs over the an ISO Network Service. Distributed
-operation procedures should not require full connectivity.
-
-
-2 Knowledge Replication
-
-Knowledge information is critical to resolution of names, and
-performing searches. Knowledge information high up the tree needs to
-be widely available. Consider resolving a name below ``Country=US''.
-To do this, a DSA needs to have full knowledge at this point. Many
-DSAs need to be able to do this, in order to give reasonable response
-and availability. It would be an unacceptable bottleneck to force
-such resolution to a single or small number of DSAs. To replicate
-this knowledge widely, a systematic approach to replication is needed.
-
-
-3 Data Replication
-
-Searches are often made at the root and country level, and this is a
-vital service (e.g., an approximate match of an organisation name).
-Data needs to be collected in such a way that this sort of searching
-is reasonably efficient. The usual X.500 approach of subordinate
-references militates against this. At a node in the DIT, subordinate
-references to the entries below are held. These entries will be in
-many DSAs, each of which needs to be accessed in order to perform the
-single level search. It is suggested that replication of data is
-necessary to achieve this.
-
-The major requirement for this replication is high up the DIT, where
-information must be replicated between different implementations. At
-lower levels of the DIT, it is reasonable for DSAs to be of the same
-implementation and to use implementation specific techniques in order
-to achieve performance and availability.
-
-
-4 Alternate DSAs
-
-When a DSA Referral is returned, only the master DSA is indicated.
-This will lead to a single point of failure. It seems important to
-allow for additional references to slave copies, in order to get
-
-
-Hardcastle-Kille Page 1
-\f
-
-
-
-RFC 1275 Replication Requirements November 1991
-
-
-better availability. This needs to be solved in conjunction with the
-problem described in the previous section.
-
-
-5 Guidelines for use of Replication
-
-To be effective, the replication specification needs to provide
-guidelines for deployment in the pilot, in order to meet the desired
-service criteria.
-
-
-6 Some scaling targets
-
-Most techniques for replication have scaling limits. It is important
-that mechanisms used do not stress the limits of the mechanism. The
-order of magnitude envisioned in the pilot is 100 000 non-leaf entries
-and several million leaf entries.
-
-
-References
-
-[CCI88] The Directory --- overview of concepts, models and services,
- December 1988. CCITT X.500 Series Recommendations.
-
-[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services
- on top of the TCP. Request for Comments 1006, Northrop
- Corporation Technology Center, May 1987.
-
-
-7 Security Considerations
-
-Security considerations are not discussed in this memo.
-
-
-8 Author's Address
-
- Steve Hardcastle-Kille
- Department of Computer Science
- University College London
- Gower Street
- WC1E 6BT
- England
-
-
-
-Hardcastle-Kille Page 2
-\f
-
-
-
-RFC 1275 Replication Requirements November 1991
-
-
- Phone: +44-71-380-7294
-
- EMail: S.Kille@CS.UCL.AC.UK
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardcastle-Kille Page 3
-
+++ /dev/null
-
-
-
-
-
-
-Network Working Group W. Yeong
-Request for Comments: 1777 Performance Systems International
-Obsoletes: 1487 T. Howes
-Category: Standards Track University of Michigan
- S. Kille
- ISODE Consortium
- March 1995
-
-
- Lightweight Directory Access Protocol
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The protocol described in this document is designed to provide access
- to the X.500 Directory while not incurring the resource requirements
- of the Directory Access Protocol (DAP). This protocol is specifically
- targeted at simple management applications and browser applications
- that provide simple read/write interactive access to the X.500
- Directory, and is intended to be a complement to the DAP itself.
-
- Key aspects of LDAP are:
-
- - Protocol elements are carried directly over TCP or other transport,
- bypassing much of the session/presentation overhead.
-
- - Many protocol data elements are encoding as ordinary strings (e.g.,
- Distinguished Names).
-
- - A lightweight BER encoding is used to encode all protocol elements.
-
-1. History
-
- The tremendous interest in X.500 [1,2] technology in the Internet has
- lead to efforts to reduce the high "cost of entry" associated with
- use of the technology, such as the Directory Assistance Service [3]
- and DIXIE [4]. While efforts such as these have met with success,
- they have been solutions based on particular implementations and as
- such have limited applicability. This document continues the efforts
- to define Directory protocol alternatives but departs from previous
- efforts in that it consciously avoids dependence on particular
-
-
-
-Yeong, Howes & Kille [Page 1]
-\f
-RFC 1777 LDAP March 1995
-
-
- implementations.
-
-2. Protocol Model
-
- The general model adopted by this protocol is one of clients
- performing protocol operations against servers. In this model, this
- is accomplished by a client transmitting a protocol request
- describing the operation to be performed to a server, which is then
- responsible for performing the necessary operations on the Directory.
- Upon completion of the necessary operations, the server returns a
- response containing any results or errors to the requesting client.
- In keeping with the goal of easing the costs associated with use of
- the Directory, it is an objective of this protocol to minimize the
- complexity of clients so as to facilitate widespread deployment of
- applications capable of utilizing the Directory.
-
- Note that, although servers are required to return responses whenever
- such responses are defined in the protocol, there is no requirement
- for synchronous behavior on the part of either client or server
- implementations: requests and responses for multiple operations may
- be exchanged by client and servers in any order, as long as clients
- eventually receive a response for every request that requires one.
-
- Consistent with the model of servers performing protocol operations
- on behalf of clients, it is also to be noted that protocol servers
- are expected to handle referrals without resorting to the return of
- such referrals to the client. This protocol makes no provisions for
- the return of referrals to clients, as the model is one of servers
- ensuring the performance of all necessary operations in the
- Directory, with only final results or errors being returned by
- servers to clients.
-
- Note that this protocol can be mapped to a strict subset of the
- directory abstract service, so it can be cleanly provided by the DAP.
-
-3. Mapping Onto Transport Services
-
- This protocol is designed to run over connection-oriented, reliable
- transports, with all 8 bits in an octet being significant in the data
- stream. Specifications for two underlying services are defined here,
- though others are also possible.
-
-3.1. Transmission Control Protocol (TCP)
-
- The LDAPMessage PDUs are mapped directly onto the TCP bytestream.
- Server implementations running over the TCP should provide a protocol
- listener on port 389.
-
-
-
-
-Yeong, Howes & Kille [Page 2]
-\f
-RFC 1777 LDAP March 1995
-
-
-3.2. Connection Oriented Transport Service (COTS)
-
- The connection is established. No special use of T-Connect is made.
- Each LDAPMessage PDU is mapped directly onto T-Data.
-
-4. Elements of Protocol
-
- For the purposes of protocol exchanges, all protocol operations are
- encapsulated in a common envelope, the LDAPMessage, which is defined
- as follows:
-
- LDAPMessage ::=
- SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResponse SearchResponse,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modifyRDNRequest ModifyRDNRequest,
- modifyRDNResponse ModifyRDNResponse,
- compareDNRequest CompareRequest,
- compareDNResponse CompareResponse,
- abandonRequest AbandonRequest
- }
- }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- The function of the LDAPMessage is to provide an envelope containing
- common fields required in all protocol exchanges. At this time the
- only common field is a message ID, which is required to have a value
- different from the values of any other requests outstanding in the
- LDAP session of which this message is a part.
-
- The message ID value must be echoed in all LDAPMessage envelopes
- encapsulting responses corresponding to the request contained in the
- LDAPMessage in which the message ID value was originally used.
-
- In addition to the LDAPMessage defined above, the following
- definitions are also used in defining protocol operations:
-
-
-
-Yeong, Howes & Kille [Page 3]
-\f
-RFC 1777 LDAP March 1995
-
-
- LDAPString ::= OCTET STRING
-
- The LDAPString is a notational convenience to indicate that, although
- strings of LDAPString type encode as OCTET STRING types, the legal
- character set in such strings is limited to the IA5 character set.
-
- LDAPDN ::= LDAPString
-
- RelativeLDAPDN ::= LDAPString
-
- An LDAPDN and a RelativeLDAPDN are respectively defined to be the
- representation of a Distinguished Name and a Relative Distinguished
- Name after encoding according to the specification in [5], such that
-
- <distinguished-name> ::= <name>
-
- <relative-distinguished-name> ::= <name-component>
-
- where <name> and <name-component> are as defined in [5].
-
- AttributeValueAssertion ::=
- SEQUENCE {
- attributeType AttributeType,
- attributeValue AttributeValue
- }
-
- The AttributeValueAssertion type definition is similar to the one in
- the X.500 Directory standards.
-
- AttributeType ::= LDAPString
-
- AttributeValue ::= OCTET STRING
-
- An AttributeType value takes on as its value the textual string
- associated with that AttributeType in the X.500 Directory standards.
- For example, the AttributeType 'organizationName' with object
- identifier 2.5.4.10 is represented as an AttributeType in this
- protocol by the string "organizationName". In the event that a
- protocol implementation encounters an Attribute Type with which it
- cannot associate a textual string, an ASCII string encoding of the
- object identifier associated with the Attribute Type may be
- subsitituted. For example, the organizationName AttributeType may be
- represented by the ASCII string "2.5.4.10" if a protocol
- implementation is unable to associate the string "organizationName"
- with it.
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 4]
-\f
-RFC 1777 LDAP March 1995
-
-
- A field of type AttributeValue takes on as its value an octet string
- encoding of a Directory AttributeValue type. The definition of these
- string encodings for different Directory AttributeValue types may be
- found in companions to this document that define the encodings of
- various attribute syntaxes such as [6].
-
- LDAPResult ::=
- SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (8),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- isLeaf (35),
- aliasDereferencingProblem (36),
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- other (80)
- },
- matchedDN LDAPDN,
- errorMessage LDAPString
- }
-
-
-
-
-Yeong, Howes & Kille [Page 5]
-\f
-RFC 1777 LDAP March 1995
-
-
- The LDAPResult is the construct used in this protocol to return
- success or failure indications from servers to clients. In response
- to various requests, servers will return responses containing fields
- of type LDAPResult to indicate the final status of a protocol
- operation request. The errorMessage field of this construct may, at
- the servers option, be used to return an ASCII string containing a
- textual, human-readable error diagnostic. As this error diagnostic is
- not standardized, implementations should not rely on the values
- returned. If the server chooses not to return a textual diagnostic,
- the errorMessage field of the LDAPResult type should contain a zero
- length string.
-
- For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
- isLeaf, and aliasDereferencingProblem, the matchedDN field is set to
- the name of the lowest entry (object or alias) in the DIT that was
- matched and is a truncated form of the name provided or, if an alias
- has been dereferenced, of the resulting name. The matchedDN field
- should be set to NULL DN (a zero length string) in all other cases.
-
-4.1. Bind Operation
-
- The function of the Bind Operation is to initiate a protocol session
- between a client and a server, and to allow the authentication of the
- client to the server. The Bind Operation must be the first operation
- request received by a server from a client in a protocol session.
- The Bind Request is defined as follows:
-
- BindRequest ::=
- [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication CHOICE {
- simple [0] OCTET STRING,
- krbv42LDAP [1] OCTET STRING,
- krbv42DSA [2] OCTET STRING
- }
- }
-
- Parameters of the Bind Request are:
-
- - version: A version number indicating the version of the protocol to
- be used in this protocol session. This document describes version
- 2 of the LDAP protocol. Note that there is no version negotiation,
- and the client should just set this parameter to the version it
- desires.
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 6]
-\f
-RFC 1777 LDAP March 1995
-
-
- - name: The name of the Directory object that the client wishes to
- bind as. This field may take on a null value (a zero length
- string) for the purposes of anonymous binds.
-
- - authentication: information used to authenticate the name, if any,
- provided in the Bind Request. The "simple" authentication option
- provides minimal authentication facilities, with the contents of
- the authentication field consisting only of a cleartext password.
- This option should also be used when unauthenticated or anonymous
- binds are to be performed, with the field containing a zero length
- string in such cases. Kerberos version 4 [7] authentication to the
- LDAP server and the DSA is accomplished by using the "krbv42LDAP"
- and "krbv42DSA" authentication options, respectively. Note that
- though they are referred to as separate entities here, there is no
- requirement these two entities be distinct (i.e., a DSA could speak
- LDAP directly). Two separate authentication options are provided
- to support all implementations. Each octet string should contain
- the kerberos ticket (e.g., as returned by krb_mk_req()) for the
- appropriate service. The suggested service name for authentication
- to the LDAP server is "ldapserver". The suggested service name for
- authentication to the DSA is "x500dsa". In both cases, the
- suggested instance name for the service is the name of the host on
- which the service is running. Of course, the actual service names
- and instances will depend on what is entered in the local kerberos
- principle database.
-
- The Bind Operation requires a response, the Bind Response, which is
- defined as:
-
- BindResponse ::= [APPLICATION 1] LDAPResult
-
- A Bind Response consists simply of an indication from the server of
- the status of the client's request for the initiation of a protocol
- session.
-
- Upon receipt of a Bind Request, a protocol server will authenticate
- the requesting client if necessary, and attempt to set up a protocol
- session with that client. The server will then return a Bind Response
- to the client indicating the status of the session setup request.
-
-4.2. Unbind Operation
-
- The function of the Unbind Operation is to terminate a protocol
- session. The Unbind Operation is defined as follows:
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
-
-
-
-
-Yeong, Howes & Kille [Page 7]
-\f
-RFC 1777 LDAP March 1995
-
-
- The Unbind Operation has no response defined. Upon transmission of an
- UnbindRequest, a protocol client may assume that the protocol session
- is terminated. Upon receipt of an UnbindRequest, a protocol server
- may assume that the requesting client has terminated the session and
- that all outstanding requests may be discarded.
-
-4.3. Search Operation
-
- The Search Operation allows a client to request that a search be
- performed on its behalf by a server. The Search Request is defined as
- follows:
-
- 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),
- attrsOnly BOOLEAN,
- filter Filter,
- attributes SEQUENCE OF AttributeType
- }
-
- Filter ::=
- CHOICE {
- and [0] SET OF Filter,
- or [1] SET OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeType,
- approxMatch [8] AttributeValueAssertion
- }
-
- SubstringFilter
- SEQUENCE {
-
-
-
-Yeong, Howes & Kille [Page 8]
-\f
-RFC 1777 LDAP March 1995
-
-
- type AttributeType,
- SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString
- }
- }
-
- Parameters of the Search Request are:
-
- - baseObject: An LDAPDN that is the base object entry relative to
- which the search is to be performed.
-
- - scope: An indicator of the scope of the search to be performed. The
- semantics of the possible values of this field are identical to the
- semantics of the scope field in the Directory Search Operation.
-
- - derefAliases: An indicator as to how alias objects should be
- handled in searching. The semantics of the possible values of
- this field are, in order of increasing value:
-
- neverDerefAliases: do not dereference aliases in searching
- or in locating the base object of the search;
-
- derefInSearching: dereference aliases in subordinates of
- the base object in searching, but not in locating the
- base object of the search;
-
- derefFindingBaseObject: dereference aliases in locating
- the base object of the search, but not when searching
- subordinates of the base object;
-
- derefAlways: dereference aliases both in searching and in
- locating the base object of the search.
-
- - sizelimit: A sizelimit that restricts the maximum number of entries
- to be returned as a result of the search. A value of 0 in this
- field indicates that no sizelimit restrictions are in effect for
- the search.
-
- - timelimit: A timelimit that restricts the maximum time (in seconds)
- allowed for a search. A value of 0 in this field indicates that no
- timelimit restrictions are in effect for the search.
-
- - attrsOnly: An indicator as to whether search results should contain
- both attribute types and values, or just attribute types. Setting
- this field to TRUE causes only attribute types (no values) to be
- returned. Setting this field to FALSE causes both attribute types
-
-
-
-Yeong, Howes & Kille [Page 9]
-\f
-RFC 1777 LDAP March 1995
-
-
- and values to be returned.
-
- - filter: A filter that defines the conditions that must be fulfilled
- in order for the search to match a given entry.
-
- - attributes: A list of the attributes from each entry found as a
- result of the search to be returned. An empty list signifies that
- all attributes from each entry found in the search are to be
- returned.
-
- The results of the search attempted by the server upon receipt of a
- Search Request are returned in Search Responses, defined as follows:
-
- Search Response ::=
- CHOICE {
- entry [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes SEQUENCE OF SEQUENCE {
- AttributeType,
- SET OF AttributeValue
- }
- },
- resultCode [APPLICATION 5] LDAPResult
- }
-
- Upon receipt of a Search Request, a server will perform the necessary
- search of the DIT.
-
- The server will return to the client a sequence of responses
- comprised of:
-
- - Zero or more Search Responses each consisting of an entry found
- during the search; with the response sequence terminated by
-
- - A single Search Response containing an indication of success, or
- detailing any errors that have occurred.
-
- Each entry returned will contain all attributes, complete with
- associated values if necessary, as specified in the 'attributes'
- field of the Search Request.
-
- Note that an X.500 "list" operation can be emulated by a one-level
- LDAP search operation with a filter checking for the existence of the
- objectClass attribute, and that an X.500 "read" operation can be
- emulated by a base object LDAP search operation with the same filter.
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 10]
-\f
-RFC 1777 LDAP March 1995
-
-
-4.4. Modify Operation
-
- The Modify Operation allows a client to request that a modification
- of the DIB be performed on its behalf by a server. The Modify
- Request is defined as follows:
-
-ModifyRequest ::=
- [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2)
- },
- modification SEQUENCE {
- type AttributeType,
- values SET OF
- AttributeValue
- }
- }
- }
-
- Parameters of the Modify Request are:
-
- - object: The object to be modified. The value of this field should
- name the object to be modified after all aliases have been
- dereferenced. The server will not perform any alias dereferencing
- in determining the object to be modified.
-
- - A list of modifications to be performed on the entry to be modified.
- The entire list of entry modifications should be performed
- in the order they are listed, as a single atomic operation. While
- individual modifications may violate the Directory schema, the
- resulting entry after the entire list of modifications is performed
- must conform to the requirements of the Directory schema. The
- values that may be taken on by the 'operation' field in each
- modification construct have the following semantics respectively:
-
- add: add values listed to the given attribute, creating
- the attribute if necessary;
-
- delete: delete values listed from the given attribute,
-
- removing the entire attribute if no values are listed, or
- if all current values of the attribute are listed for
- deletion;
-
-
-
-
-Yeong, Howes & Kille [Page 11]
-\f
-RFC 1777 LDAP March 1995
-
-
- replace: replace existing values of the given attribute
- with the new values listed, creating the attribute if
- necessary.
-
- The result of the modify attempted by the server upon receipt of a
- Modify Request is returned in a Modify Response, defined as follows:
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- Upon receipt of a Modify Request, a server will perform the necessary
- modifications to the DIB.
-
- The server will return to the client a single Modify Response
- indicating either the successful completion of the DIB modification,
- or the reason that the modification failed. Note that due to the
- requirement for atomicity in applying the list of modifications in
- the Modify Request, the client may expect that no modifications of
- the DIB have been performed if the Modify Response received indicates
- any sort of error, and that all requested modifications have been
- performed if the Modify Response indicates successful completion of
- the Modify Operation.
-
-4.5. Add Operation
-
- The Add Operation allows a client to request the addition of an entry
- into the Directory. The Add Request is defined as follows:
-
- AddRequest ::=
- [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attrs SEQUENCE OF SEQUENCE {
- type AttributeType,
- values SET OF AttributeValue
- }
- }
-
- Parameters of the Add Request are:
-
- - entry: the Distinguished Name of the entry to be added. Note that
- all components of the name except for the last RDN component must
- exist for the add to succeed.
-
- - attrs: the list of attributes that make up the content of the entry
- being added.
-
- The result of the add attempted by the server upon receipt of a Add
- Request is returned in the Add Response, defined as follows:
-
-
-
-
-Yeong, Howes & Kille [Page 12]
-\f
-RFC 1777 LDAP March 1995
-
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- Upon receipt of an Add Request, a server will attempt to perform the
- add requested. The result of the add attempt will be returned to the
- client in the Add Response.
-
-4.6. Delete Operation
-
- The Delete Operation allows a client to request the removal of an
- entry from the Directory. The Delete Request is defined as follows:
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- The Delete Request consists only of the Distinguished Name of the
- entry to be deleted. The result of the delete attempted by the
- server upon receipt of a Delete Request is returned in the Delete
- Response, defined as follows:
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- Upon receipt of a Delete Request, a server will attempt to perform
- the entry removal requested. The result of the delete attempt will be
- returned to the client in the Delete Response. Note that only leaf
- objects may be deleted with this operation.
-
-4.7. Modify RDN Operation
-
- The Modify RDN Operation allows a client to change the last component
- of the name of an entry in the Directory. The Modify RDN Request is
- defined as follows:
-
- ModifyRDNRequest ::=
- [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN
- }
-
- Parameters of the Modify RDN Request are:
-
- - entry: the name of the entry to be changed.
-
- - newrdn: the RDN that will form the last component of the new name.
-
- - deleteoldrdn: a boolean parameter that controls whether the old RDN
- attribute values should be retained as attributes of the entry or
- deleted from the entry.
-
-
-
-
-Yeong, Howes & Kille [Page 13]
-\f
-RFC 1777 LDAP March 1995
-
-
- The result of the name change attempted by the server upon receipt of
- a Modify RDN Request is returned in the Modify RDN Response, defined
- as follows:
-
- ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
-
- Upon receipt of a Modify RDN Request, a server will attempt to
- perform the name change. The result of the name change attempt will
- be returned to the client in the Modify RDN Response. The attributes
- that make up the old RDN are deleted from the entry, or kept,
- depending on the setting of the deleteoldrdn parameter.
-
-4.8. Compare Operation
-
- The Compare Operation allows a client to compare an assertion
- provided with an entry in the Directory. The Compare Request is
- defined as follows:
-
- CompareRequest ::=
- [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion
- }
-
- Parameters of the Compare Request are:
-
- - entry: the name of the entry to be compared with.
-
- - ava: the assertion with which the entry is to be compared.
-
- The result of the compare attempted by the server upon receipt of a
- Compare Request is returned in the Compare Response, defined as
- follows:
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- Upon receipt of a Compare Request, a server will attempt to perform
- the requested comparison. The result of the comparison will be
- returned to the client in the Compare Response. Note that errors and
- the result of comparison are all returned in the same construct.
-
-6.9. Abandon Operation
-
- The function of the Abandon Operation is to allow a client to request
- that the server abandon an outstanding operation. The Abandon
- Request is defined as follows:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
-
-
-Yeong, Howes & Kille [Page 14]
-\f
-RFC 1777 LDAP March 1995
-
-
- There is no response defined in the Abandon Operation. Upon
- transmission of an Abandon Operation, a client may expect that the
- operation identityfied by the Message ID in the Abandon Request has
- been abandoned. In the event that a server receives an Abandon
- Request on a Search Operation in the midst of transmitting responses
- to that search, that server should cease transmitting responses to
- the abandoned search immediately.
-
-5. Protocol Element Encodings
-
- The protocol elements of LDAP are encoded for exchange using the
- Basic Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the
- high overhead involved in using certain elements of the BER, the
- following additional restrictions are placed on BER-encodings of LDAP
- protocol elements:
-
- (1) Only the definite form of length encoding will be used.
-
- (2) Bitstrings and octet strings and all character string types
- will be encoded in the primitive form only.
-
-6. Security Considerations
-
- This version of the protocol provides facilities only for simple
- authentication using a cleartext password, and for kerberos version 4
- authentication. Future versions of LDAP will likely include support
- for other authentication methods.
-
-7. Bibliography
-
- [1] The Directory: Overview of Concepts, Models and Service. CCITT
- Recommendation X.500, 1988.
-
- [2] Information Processing Systems -- Open Systems Interconnection --
- The Directory: Overview of Concepts, Models and Service. ISO/IEC
- JTC 1/SC21; International Standard 9594-1, 1988
-
- [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance
- Systems International, Inc., February 1991.
-
- [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol
- Specification, RFC 1249, University of Michigan, August 1991.
-
- [5] Kille, S., "A String Representation of Distinguished Names", RFC
- 1779, ISODE Consortium, March 1995.
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 15]
-\f
-RFC 1777 LDAP March 1995
-
-
- [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight
- Directory Access Protocol", RFC 1488, University of Michigan,
- ISODE Consortium, Performance Systems International, NeXor Ltd.,
- July 1993.
-
- [7] Kerberos Authentication and Authorization System. S.P. Miller,
- B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena
- Documentation Section E.2.1, December 1987.
-
- [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
- 1/SC21; International Standard 9594-2, 1988.
-
- [10] The Directory: Abstract Service Definition. CCITT Recommendation
- X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
-
- [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT
- Recommendation X.208, 1988.
-
- [12] Specification of Basic Encoding Rules for Abstract Syntax
- Notation One (ASN.1). CCITT Recommendation X.209, 1988.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 16]
-\f
-RFC 1777 LDAP March 1995
-
-
-10. Authors' Addresses
-
- Wengyik Yeong
- PSI Inc.
- 510 Huntmar Park Drive
- Herndon, VA 22070
- USA
-
- Phone: +1 703-450-8001
- EMail: yeongw@psilink.com
-
-
- Tim Howes
- University of Michigan
- ITD Research Systems
- 535 W William St.
- Ann Arbor, MI 48103-4943
- USA
-
- Phone: +1 313 747-4454
- EMail: tim@umich.edu
-
-
- Steve Kille
- ISODE Consortium
- PO Box 505
- London
- SW11 1DX
- UK
-
- Phone: +44-71-223-4062
- EMail: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 17]
-\f
-RFC 1777 LDAP March 1995
-
-
-Appendix A - Complete ASN.1 Definition
-
-Lightweight-Directory-Access-Protocol DEFINITIONS IMPLICIT TAGS ::=
-
-BEGIN
-
-LDAPMessage ::=
- SEQUENCE {
- messageID MessageID,
- -- unique id in request,
- -- to be echoed in response(s)
- protocolOp CHOICE {
- searchRequest SearchRequest,
- searchResponse SearchResponse,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modifyDNRequest ModifyDNRequest,
- modifyDNResponse ModifyDNResponse,
- compareDNRequest CompareRequest,
- compareDNResponse CompareResponse,
- bindRequest BindRequest,
- bindResponse BindResponse,
- abandonRequest AbandonRequest,
- unbindRequest UnbindRequest
- }
- }
-
-BindRequest ::=
- [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- -- current version is 2
- name LDAPDN,
- -- null name implies an anonymous bind
- authentication CHOICE {
- simple [0] OCTET STRING,
- -- a zero length octet string
- -- implies an unauthenticated
- -- bind.
- krbv42LDAP [1] OCTET STRING,
- krbv42DSA [2] OCTET STRING
- -- values as returned by
- -- krb_mk_req()
- -- Other values in later versions
- -- of this protocol.
-
-
-
-Yeong, Howes & Kille [Page 18]
-\f
-RFC 1777 LDAP March 1995
-
-
- }
- }
-
-BindResponse ::= [APPLICATION 1] LDAPResult
-
-UnbindRequest ::= [APPLICATION 2] NULL
-
-SearchRequest ::=
- [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2)
- },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- alwaysDerefAliases (3)
- },
- sizeLimit INTEGER (0 .. maxInt),
- -- value of 0 implies no sizelimit
- timeLimit INTEGER (0 .. maxInt),
- -- value of 0 implies no timelimit
- attrsOnly BOOLEAN,
- -- TRUE, if only attributes (without values)
- -- to be returned.
- filter Filter,
- attributes SEQUENCE OF AttributeType
- }
-
-SearchResponse ::=
- CHOICE {
- entry [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes SEQUENCE OF SEQUENCE {
- AttributeType,
- SET OF
- AttributeValue
- }
- },
- resultCode [APPLICATION 5] LDAPResult
- }
-
-ModifyRequest ::=
- [APPLICATION 6] SEQUENCE {
- object LDAPDN,
-
-
-
-Yeong, Howes & Kille [Page 19]
-\f
-RFC 1777 LDAP March 1995
-
-
- modifications SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2)
- },
- modification SEQUENCE {
- type AttributeType,
- values SET OF
- AttributeValue
- }
- }
- }
-
-
-ModifyResponse ::= [APPLICATION 7] LDAPResult
-
-AddRequest ::=
- [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attrs SEQUENCE OF SEQUENCE {
- type AttributeType,
- values SET OF AttributeValue
- }
- }
-
-AddResponse ::= [APPLICATION 9] LDAPResult
-
-DelRequest ::= [APPLICATION 10] LDAPDN
-
-DelResponse ::= [APPLICATION 11] LDAPResult
-
-ModifyRDNRequest ::=
- [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN -- old RDN always deleted
- }
-
-ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
-
-CompareRequest ::=
- [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion
- }
-
-CompareResponse ::= [APPLICATION 15] LDAPResult
-
-
-
-
-Yeong, Howes & Kille [Page 20]
-\f
-RFC 1777 LDAP March 1995
-
-
-AbandonRequest ::= [APPLICATION 16] MessageID
-
-MessageID ::= INTEGER (0 .. maxInt)
-
-LDAPDN ::= LDAPString
-
-RelativeLDAPDN ::= LDAPString
-
-Filter ::=
- CHOICE {
- and [0] SET OF Filter,
- or [1] SET OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeType,
- approxMatch [8] AttributeValueAssertion
- }
-
-LDAPResult ::=
- SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (8),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- isLeaf (35),
- aliasDereferencingProblem (36),
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
-
-
-
-Yeong, Howes & Kille [Page 21]
-\f
-RFC 1777 LDAP March 1995
-
-
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- other (80)
- },
- matchedDN LDAPDN,
- errorMessage LDAPString
- }
-
-AttributeType ::= LDAPString
- -- text name of the attribute, or dotted
- -- OID representation
-
-AttributeValue ::= OCTET STRING
-
-AttributeValueAssertion ::=
- SEQUENCE {
- attributeType AttributeType,
- attributeValue AttributeValue
- }
-
-SubstringFilter ::=
- SEQUENCE {
- type AttributeType,
- SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString
- }
- }
-
-LDAPString ::= OCTET STRING
-
-maxInt INTEGER ::= 65535
-END
-
-
-
-
-
-
-
-
-
-
-Yeong, Howes & Kille [Page 22]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group T. Howes
-Request for Comments: 1778 University of Michigan
-Obsoletes: 1488 S. Kille
-Category: Standards Track ISODE Consortium
- W. Yeong
- Performance Systems International
- C. Robbins
- NeXor Ltd.
- March 1995
-
-
- The String Representation of Standard Attribute Syntaxes
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) [9] requires that
- the contents of AttributeValue fields in protocol elements be octet
- strings. This document defines the requirements that must be
- satisfied by encoding rules used to render X.500 Directory attribute
- syntaxes into a form suitable for use in the LDAP, then goes on to
- define the encoding rules for the standard set of attribute syntaxes
- defined in [1,2] and [3].
-
-1. Attribute Syntax Encoding Requirements.
-
- This section defines general requirements for lightweight directory
- protocol attribute syntax encodings. All documents defining attribute
- syntax encodings for use by the lightweight directory protocols are
- expected to conform to these requirements.
-
- The encoding rules defined for a given attribute syntax must produce
- octet strings. To the greatest extent possible, encoded octet
- strings should be usable in their native encoded form for display
- purposes. In particular, encoding rules for attribute syntaxes
- defining non-binary values should produce strings that can be
- displayed with little or no translation by clients implementing the
- lightweight directory protocols.
-
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 1]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-2. Standard Attribute Syntax Encodings
-
- For the purposes of defining the encoding rules for the standard
- attribute syntaxes, the following auxiliary BNF definitions will be
- used:
-
- <a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
- 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
- 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
- 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
- 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
- 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
-
- <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
-
- <hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
- 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
-
- <k> ::= <a> | <d> | '-'
-
- <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
- '/' | ':' | '?' | ' '
-
- <CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
-
- <letterstring> ::= <a> | <a> <letterstring>
-
- <numericstring> ::= <d> | <d> <numericstring>
-
- <keystring> ::= <a> | <a> <anhstring>
-
- <anhstring> ::= <k> | <k> <anhstring>
-
- <printablestring> ::= <p> | <p> <printablestring>
-
- <space> ::= ' ' | ' ' <space>
-
-2.1. Undefined
-
- Values of type Undefined are encoded as if they were values of type
- Octet String, with the string value being the BER-encoded version of
- the value.
-
-2.2. Case Ignore String
-
- A string of type caseIgnoreStringSyntax is encoded as the string
- value itself.
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 2]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-2.3. Case Exact String
-
- The encoding of a string of type caseExactStringSyntax is the string
- value itself.
-
-2.4. Printable String
-
- The encoding of a string of type printableStringSyntax is the string
- value itself.
-
-2.5. Numeric String
-
- The encoding of a string of type numericStringSyntax is the string
- value itself.
-
-2.6. Octet String
-
- The encoding of a string of type octetStringSyntax is the string
- value itself.
-
-2.7. Case Ignore IA5 String
-
- The encoding of a string of type caseIgnoreIA5String is the string
- value itself.
-
-2.8. IA5 String
-
- The encoding of a string of type iA5StringSyntax is the string value
- itself.
-
-2.9. T61 String
-
- The encoding of a string of type t61StringSyntax is the string value
- itself.
-
-2.10. Case Ignore List
-
- Values of type caseIgnoreListSyntax are encoded according to the
- following BNF:
-
-<caseignorelist> ::= <caseignorestring> |
- <caseignorestring> '$' <caseignorelist>
-
-<caseignorestring> ::= a string encoded according to the rules for Case
- Ignore String as above.
-
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 3]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-2.11. Case Exact List
-
- Values of type caseExactListSyntax are encoded according to the
- following BNF:
-
-<caseexactlist> ::= <caseexactstring> |
- <caseexactstring> '$' <caseexactlist>
-
-<caseexactstring> ::= a string encoded according to the rules for Case
- Exact String as above.
-
-2.12. Distinguished Name
-
- Values of type distinguishedNameSyntax are encoded to have the
- representation defined in [5].
-
-2.13. Boolean
-
- Values of type booleanSyntax are encoded according to the following
- BNF:
-
- <boolean> ::= "TRUE" | "FALSE"
-
- Boolean values have an encoding of "TRUE" if they are logically true,
- and have an encoding of "FALSE" otherwise.
-
-2.14. Integer
-
- Values of type integerSyntax are encoded as the decimal
- representation of their values, with each decimal digit represented
- by the its character equivalent. So the digit 1 is represented by the
- character
-
-2.15. Object Identifier
-
- Values of type objectIdentifierSyntax are encoded according to the
- following BNF:
-
- <oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
-
- <descr> ::= <keystring>
-
- <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
-
- In the above BNF, <descr> is the syntactic representation of an
- object descriptor. When encoding values of type
- objectIdentifierSyntax, the first encoding option should be used in
- preference to the second, which should be used in preference to the
-
-
-
-Howes, Kille, Yeong & Robbins [Page 4]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
- third wherever possible. That is, in encoding object identifiers,
- object descriptors (where assigned and known by the implementation)
- should be used in preference to numeric oids to the greatest extent
- possible. For example, in encoding the object identifier representing
- an organizationName, the descriptor "organizationName" is preferable
- to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
-
-2.16. Telephone Number
-
- Values of type telephoneNumberSyntax are encoded as if they were
- Printable String types.
-
-2.17. Telex Number
-
- Values of type telexNumberSyntax are encoded according to the
- following BNF:
-
- <telex-number> ::= <actual-number> '$' <country> '$' <answerback>
-
- <actual-number> ::= <printablestring>
-
- <country> ::= <printablestring>
-
- <answerback> ::= <printablestring>
-
- In the above, <actual-number> is the syntactic representation of the
- number portion of the TELEX number being encoded, <country> is the
- TELEX country code, and <answerback> is the answerback code of a
- TELEX terminal.
-
-2.18. Teletex Terminal Identifier
-
- Values of type teletexTerminalIdentifier are encoded according to the
- following BNF:
-
- <teletex-id> ::= <printablestring> 0*('$' <ttx-parm>)
-
- <ttx-param> ::= <ttx-key> ':' <ttx-value>
-
- <ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
-
- <ttx-value> ::= <octetstring>
-
- In the above, the first <printablestring> is the encoding of the
- first portion of the teletex terminal identifier to be encoded, and
- the subsequent 0 or more <printablestrings> are subsequent portions
- of the teletex terminal identifier.
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 5]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-2.19. Facsimile Telephone Number
-
- Values of type FacsimileTelephoneNumber are encoded according to the
- following BNF:
-
-<fax-number> ::= <printablestring> [ '$' <faxparameters> ]
-
-<faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
-
-<faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
- 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
-
- In the above, the first <printablestring> is the actual fax number,
- and the <faxparm> tokens represent fax parameters.
-
-2.20. Presentation Address
-
- Values of type PresentationAddress are encoded to have the
- representation described in [6].
-
-2.21. UTC Time
-
- Values of type uTCTimeSyntax are encoded as if they were Printable
- Strings with the strings containing a UTCTime value.
-
-2.22. Guide (search guide)
-
- Values of type Guide, such as values of the searchGuide attribute,
- are encoded according to the following BNF:
-
-<guide-value> ::= [ <object-class> '#' ] <criteria>
-
-<object-class> ::= an encoded value of type objectIdentifierSyntax
-
-<criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
-
-<criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
- [ '(' ] <criteria> '|' <criteria-set> [ ')' ]
-
-<criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
-
-<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
-
-
-
-
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 6]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-2.23. Postal Address
-
- Values of type PostalAddress are encoded according to the following
- BNF:
-
- <postal-address> ::= <t61string> | <t61string> '$' <postal-address>
-
- In the above, each <t61string> component of a postal address value is
- encoded as a value of type t61StringSyntax.
-
-2.24. User Password
-
- Values of type userPasswordSyntax are encoded as if they were of type
- octetStringSyntax.
-
-2.25. User Certificate
-
- Values of type userCertificate are encoded according to the following
- BNF:
-
- <certificate> ::= <version> '#' <serial> '#' <signature-algorithm-id>
- '#' <issuer> '#' <validity> '#' <subject>
- '#' <public-key-info> '#' <encrypted-sign-value>
-
- <version> ::= <integervalue>
-
- <serial> ::= <integervalue>
-
- <signature-algorithm-id> ::= <algorithm-id>
-
- <issuer> ::= an encoded Distinguished Name
-
- <validity> ::= <not-before-time> '#' <not-after-time>
-
- <not-before-time> ::= <utc-time>
-
- <not-after-time> ::= <utc-time>
-
- <algorithm-parameters> ::= <null> | <integervalue> |
- '{ASN}' <hex-string>
-
- <subject> ::= an encoded Distinguished Name
-
- <public-key-info> ::= <algorithm-id> '#' <encrypted-sign-value>
-
- <encrypted-sign-value> ::= <hex-string> | <hex-string> '-' <d>
-
- <algorithm-id> ::= <oid> '#' <algorithm-parameters>
-
-
-
-Howes, Kille, Yeong & Robbins [Page 7]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
- <utc-time> ::= an encoded UTCTime value
-
- <hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
-
-2.26. CA Certificate
-
- Values of type cACertificate are encoded as if the values were of
- type userCertificate.
-
-2.27. Authority Revocation List
-
- Values of type authorityRevocationList are encoded according to the
- following BNF:
-
-<certificate-list> ::= <signature-algorithm-id> '#' <issuer> '#' <utc-time>
- [ '#' <revoked-certificates> ]
- '#' <signature-algorithm-id>
- '#' <encrypted-sign-value>
-
-<revoked-certificates> ::= 1*( '#' <revoked-certificate> )
- <signature-algorithm-id> '#' <encrypted-sign-value>
-
-<revoked-certificate> ::= <signature-algorithm-id> '#' <issuer> '#'
- <serial> '#' <utc-time>
-
- The syntactic components <signature-algorithm-id>, <issuer>,
- <encrypted-sign-value>, <utc-time>, <subject> and <serial> have the
- same definitions as in the BNF for the userCertificate attribute
- syntax.
-
-2.28. Certificate Revocation List
-
- Values of type certificateRevocationList are encoded as if the values
- were of type authorityRevocationList.
-
-2.29. Cross Certificate Pair
-
- Values of type crossCertificatePair are encoded according to the
- following BNF:
-
- <certificate-pair> ::= <forward> '#' <reverse>
- | <forward>
- | <reverse>
-
- <forward> ::= 'forward:' <certificate>
-
- <reverse> ::= 'reverse:' <certificate>
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 8]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
- The syntactic component <certificate> has the same definition as in
- the BNF for the userCertificate attribute syntax.
-
-2.30. Delivery Method
-
- Values of type deliveryMethod are encoded according to the following
- BNF:
-
- <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
-
- <pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
- 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
-
-2.31. Other Mailbox
-
- Values of the type otherMailboxSyntax are encoded according to the
- following BNF:
-
- <otherMailbox> ::= <mailbox-type> '$' <mailbox>
-
- <mailbox-type> ::= an encoded Printable String
-
- <mailbox> ::= an encoded IA5 String
-
- In the above, <mailbox-type> represents the type of mail system in
- which the mailbox resides, for example "Internet" or "MCIMail"; and
- <mailbox> is the actual mailbox in the mail system defined by
- <mailbox-type>.
-
-2.32. Mail Preference
-
- Values of type mailPreferenceOption are encoded according to the
- following BNF:
-
- <mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
-
-2.33. MHS OR Address
-
- Values of type MHS OR Address are encoded as strings, according to
- the format defined in [10].
-
-
-
-
-
-
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 9]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-2.34. Distribution List Submit Permission
-
- Values of type DLSubmitPermission are encoded as strings, according
- to the following BNF:
-
- <dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value>
- | <dl-label> ':' <dl-value>
-
- <dlgroup-label> ::= 'group_member'
-
- <dlgroup-value> ::= <name>
-
- <name> ::= an encoded Distinguished Name
-
- <dl-label> ::= 'individual' | 'dl_member' | 'pattern'
-
- <dl-value> ::= <orname>
-
- <orname> ::= <address> '#' <dn>
- | <address>
-
- <address> ::= <add-label> ':' <oraddress>
-
- <dn> ::= <dn-label> ':' <name>
-
- <add-label> = 'X400'
-
- <dn-label> = 'X500'
-
- where <oraddress> is as defined in RFC 1327.
-
-2.35. Photo
-
- Values of type Photo are encoded as if they were octet strings
- containing JPEG images in the JPEG File Interchange Format (JFIF), as
- described in [8].
-
-2.36. Fax
-
- Values of type Fax are encoded as if they were octet strings
- containing Group 3 Fax images as defined in [7].
-
-
-
-
-
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 10]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-3. Security Considerations
-
- Security issues are not discussed in this memo.
-
-4. Acknowledgements
-
- Many of the attribute syntax encodings defined in this document are
- adapted from those used in the QUIPU X.500 implementation. The
- contributions of the authors of the QUIPU implementation in the
- specification of the QUIPU syntaxes [4] are gratefully acknowledged.
-
-5. Bibliography
-
- [1] The Directory: Selected Attribute Syntaxes. CCITT,
- Recommendation X.520.
-
- [2] Information Processing Systems -- Open Systems Interconnection --
- The Directory: Selected Attribute Syntaxes.
-
- [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
- RFC 1274, University College London, November 1991.
-
- [4] The ISO Development Environment: User's Manual -- Volume 5:
- QUIPU. Colin Robbins, Stephen E. Kille.
-
- [5] Kille, S., "A String Representation of Distinguished Names", RFC
- 1779, ISODE Consortium, March 1995.
-
- [6] Kille, S., "A String Representation for Presentation Addresses",
- RFC 1278, University College London, November 1991.
-
- [7] Terminal Equipment and Protocols for Telematic Services -
- Standardization of Group 3 facsimile apparatus for document
- transmission. CCITT, Recommendation T.4.
-
- [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-
- Cube Microsystems, Milpitas, CA, September 1, 1992.
-
- [9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, Performance Systems International,
- University of Michigan, ISODE Consortium, March 1995.
-
- [10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
- "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
- SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach
- Consulting, Inc., Soft*Switch, Inc., August 1993.
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 11]
-\f
-RFC 1778 Syntax Encoding March 1995
-
-
-6. Authors' Addresses
-
- Tim Howes
- University of Michigan
- ITD Research Systems
- 535 W William St.
- Ann Arbor, MI 48103-4943
- USA
-
- Phone: +1 313 747-4454
- EMail: tim@umich.edu
-
-
- Steve Kille
- ISODE Consortium
- PO Box 505
- London
- SW11 1DX
- UK
-
- Phone: +44-71-223-4062
- EMail: S.Kille@isode.com
-
-
- Wengyik Yeong
- PSI Inc.
- 510 Huntmar Park Drive
- Herndon, VA 22070
- USA
-
- Phone: +1 703-450-8001
- EMail: yeongw@psilink.com
-
-
- Colin Robbins
- NeXor Ltd
- University Park
- Nottingham
- NG7 2RD
- UK
-
-
-
-
-
-
-
-
-
-
-
-Howes, Kille, Yeong & Robbins [Page 12]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Kille
-Request for Comments: 1779 ISODE Consortium
-Obsoletes: 1485 March 1995
-Category: Standards Track
-
-
- A String Representation of Distinguished Names
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The OSI Directory uses distinguished names as the primary keys to
- entries in the directory. Distinguished Names are encoded in ASN.1.
- When a distinguished name is communicated between to users not using
- a directory protocol (e.g., in a mail message), there is a need to
- have a user-oriented string representation of distinguished name.
- This specification defines a string format for representing names,
- which is designed to give a clean representation of commonly used
- names, whilst being able to represent any distinguished name.
-
-Table of Contents
-
- 1. Why a notation is needed ................................... 2
- 2. A notation for Distinguished Name .......................... 2
- 2.1 Goals ................................................ 2
- 2.2 Informal definition .................................. 2
- 2.3 Formal definition .................................... 4
- 3. Examples ................................................... 6
- 4. Acknowledgements ........................................... 7
- 5. References ................................................. 7
- 6. Security Considerations .................................... 8
- 7. Author's Address ........................................... 8
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 1]
-\f
-RFC 1779 DN Representation March 1995
-
-
-1. Why a notation is needed
-
- Many OSI Applications make use of Distinguished Names (DN) as defined
- in the OSI Directory, commonly known as X.500 [1]. This
- specification assumes familiarity with X.500, and the concept of
- Distinguished Name. It is important to have a common format to be
- able to unambiguously represent a distinguished name. This might be
- done to represent a directory name on a business card or in an email
- message. There is a need for a format to support human to human
- communication, which must be string based (not ASN.1) and user
- oriented. This notation is targeted towards a general user oriented
- system, and in particular to represent the names of humans. Other
- syntaxes may be more appropriate for other uses of the directory.
- For example, the OSF Syntax may be more appropriate for some system
- oriented uses. (The OSF Syntax uses "/" as a separator, and forms
- names in a manner intended to resemble UNIX filenames).
-
-2. A notation for Distinguished Name
-
-2.1 Goals
-
- The following goals are laid out:
-
- o To provide an unambiguous representation of a distinguished name
-
- o To be an intuitive format for the majority of names
-
- o To be fully general, and able to represent any distinguished name
-
- o To be amenable to a number of different layouts to achieve an
- attractive representation.
-
- o To give a clear representation of the contents of the
- distinguished name
-
-2.2 Informal definition
-
- This notation is designed to be convenient for common forms of name.
- Some examples are given. The author's directory distinguished name
- would be written:
-
- CN=Steve Kille,
- O=ISODE Consortium, C=GB
-
-
-
-
-
-
-
-
-Kille [Page 2]
-\f
-RFC 1779 DN Representation March 1995
-
-
- This may be folded, perhaps to display in multi-column format. For
- example:
-
- CN=Steve Kille,
- O=ISODE Consortium,
- C=GB
-
- Another name might be:
-
- CN=Christian Huitema, O=INRIA, C=FR
-
- Semicolon (";") may be used as an alternate separator. The
- separators may be mixed, but this usage is discouraged.
-
- CN=Christian Huitema; O=INRIA; C=FR
-
- In running text, this would be written as <CN=Christian Huitema;
- O=INRIA; C=FR>. Another example, shows how different attribute types
- are handled:
-
- CN=James Hacker,
- L=Basingstoke,
- O=Widget Inc,
- C=GB
-
- Here is an example of a multi-valued Relative Distinguished Name,
- where the namespace is flat within an organisation, and department is
- used to disambiguate certain names:
-
- OU=Sales + CN=J. Smith, O=Widget Inc., C=US
-
- The final examples show both methods quoting of a comma in an
- Organisation name:
-
- CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
-
- CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 3]
-\f
-RFC 1779 DN Representation March 1995
-
-
-2.3 Formal definition
-
- A formal definition can now be given. The structure is specified in
- a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC
- 822, with the terminals enclosed in <> [2]. This definition is in an
- abstract character set, and so may be written in any character set
- supporting the explicitly defined special characters. The quoting
- mechanism is used for the following cases:
-
- o Strings containing ",", "+", "=" or """ , <CR>, "<",
- ">", "#", or ";".
-
- o Strings with leading or trailing spaces
-
- o Strings containing consecutive spaces
-
- There is an escape mechanism from the normal user oriented form, so
- that this syntax may be used to print any valid distinguished name.
- This is ugly. It is expected to be used only in pathological cases.
- There are two parts to this mechanism:
-
- 1. Attributes types are represented in a (big-endian) dotted
- notation. (e.g., OID.2.6.53).
-
- 2. Attribute values are represented in hexadecimal (e.g. #0A56CF).
- Each pair of hex digits defines an octet, which is the ASN.1 Basic
- Encoding Rules value of the Attribute Value.
-
- The keyword specification is optional in the BNF, but mandatory for
- this specification. This is so that the same BNF may be used for the
- related specification on User Friendly Naming [5]. When this
- specification is followed, the attribute type keywords must always be
- present.
-
- A list of valid keywords for well known attribute types used in
- naming is given in Table 1. Keywords may contain spaces, but shall
- not have leading or trailing spaces. This is a list of keywords
- which must be supported. These are chosen because they appear in
- common forms of name, and can do so in a place which does not
- correspond to the default schema used. A register of valid keywords
- is maintained by the IANA.
-
-
-
-
-
-
-
-
-
-
-Kille [Page 4]
-\f
-RFC 1779 DN Representation March 1995
-
-
- <name> ::= <name-component> ( <spaced-separator> )
- | <name-component> <spaced-separator> <name>
-
- <spaced-separator> ::= <optional-space>
- <separator>
- <optional-space>
-
- <separator> ::= "," | ";"
-
- <optional-space> ::= ( <CR> ) *( " " )
-
- <name-component> ::= <attribute>
- | <attribute> <optional-space> "+"
- <optional-space> <name-component>
-
- <attribute> ::= <string>
- | <key> <optional-space> "=" <optional-space> <string>
-
- <key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
- <keychar> ::= letters, numbers, and space
-
- <oid> ::= <digitstring> | <digitstring> "." <oid>
- <digitstring> ::= 1*<digit>
- <digit> ::= digits 0-9
-
- <string> ::= *( <stringchar> | <pair> )
- | '"' *( <stringchar> | <special> | <pair> ) '"'
- | "#" <hex>
-
-
- <special> ::= "," | "=" | <CR> | "+" | "<" | ">"
- | "#" | ";"
-
- <pair> ::= "\" ( <special> | "\" | '"')
- <stringchar> ::= any character except <special> or "\" or '"'
-
-
- <hex> ::= 2*<hexchar>
- <hexchar> ::= 0-9, a-f, A-F
-
-
-
- Figure 1: BNF Grammar for Distinguished Name
-
-
-
-
-
-
-
-
-Kille [Page 5]
-\f
-RFC 1779 DN Representation March 1995
-
-
- Key Attribute (X.520 keys)
- ------------------------------
- CN CommonName
- L LocalityName
- ST StateOrProvinceName
- O OrganizationName
- OU OrganizationalUnitName
- C CountryName
- STREET StreetAddress
-
-
- Table 1: Standardised Keywords
-
-
- Only string type attributes are considered, but other attribute
- syntaxes could be supported locally (e.g., by use of the syntexes
- defined in [3].) It is assumed that the interface will translate
- from the supplied string into an appropriate Directory String
- encoding. The "+" notation is used to specify multi-component RDNs.
- In this case, the types for attributes in the RDN must be explicit.
-
- The name is presented/input in a little-endian order (most
- significant component last). When an address is written in a context
- where there is a need to delimit the entire address (e.g., in free
- text), it is recommended that the delimiters <> are used. The
- terminator > is a special in the notation to facilitate this
- delimitation.
-
-3. Examples
-
- This section gives a few examples of distinguished names written
- using this notation:
-
- CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
- ST=California, C=US
-
- CN=FTAM Service, CN=Bells, OU=Computer Science,
- O=University College London, C=GB
-
- CN=Markus Kuhn, O=University of Erlangen, C=DE
-
- CN=Steve Kille,
- O=ISODE Consortium,
- C=GB
-
-
-
-
-
-
-
-Kille [Page 6]
-\f
-RFC 1779 DN Representation March 1995
-
-
- CN=Steve Kille ,
-
- O = ISODE Consortium,
- C=GB
-
- CN=Steve Kille, O=ISODE Consortium, C=GB
-
-4. Acknowledgements
-
- This work was based on research work done at University College
- London [4], and evolved by the IETF OSI-DS WG.
-
- Input for this version of the document was received from: Allan
- Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone
- (Onsett); John Hawthorne (US Air Force); Roland Hedberg (University
- of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn
- (University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE
- Consortium).
-
-5. References
-
- [1] The Directory --- overview of concepts, models and services,
- 1993. CCITT X.500 Series Recommendations.
-
- [2] Crocker, D., "Standard of the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
- [3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, Performance Systems International,
- University of Michigan, ISODE Consortium, March 1995.
-
- [4] S.E. Kille. Using the OSI directory to achieve user friendly
- naming. Research Note RN/20/29, Department of Computer Science,
- University College London, February 1990.
-
- [5] Kille, S., "Using the OSI Directory to Achieve User Friendly
- Naming", RFC 1781, ISODE Consortium, March 1995.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 7]
-\f
-RFC 1779 DN Representation March 1995
-
-
-6. Security Considerations
-
- Security issues are not discussed in this memo.
-
-7. Author's Address
-
- Steve Kille
- ISODE Consortium
- The Dome
- The Square
- Richmond, Surrey
- TW9 1DT
- England
-
- Phone: +44-181-332-9091
- EMail: S.Kille@ISODE.COM
-
- DN: CN=Steve Kille,
- O=ISODE Consortium, C=GB
-
- UFN: S. Kille,
- ISODE Consortium, GB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 8]
-\f
-
-
-
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Kille
-Request for Comments: 1781 ISODE Consortium
-Obsoletes: 1484 March 1995
-Category: Standards Track
-
-
- Using the OSI Directory to Achieve User Friendly Naming
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The OSI Directory has user friendly naming as a goal. A simple
- minded usage of the directory does not achieve this. Two aspects not
- achieved are:
-
- o A user oriented notation
-
- o Guessability
-
- This proposal sets out some conventions for representing names in a
- friendly manner, and shows how this can be used to achieve really
- friendly naming. This then leads to a specification of a standard
- format for representing names, and to procedures to resolve them.
- This leads to a specification which allows directory names to be
- communicated between humans. The format in this specification is
- identical to that defined in [5], and it is intended that these
- specifications are compatible.
-
-Table of Contents
-
- 1. Why a notation is needed ................................... 2
- 2. The Notation ............................................... 3
- 3. Communicating Directory Names .............................. 7
- 4. Matching a purported name .................................. 9
- 4.1 Environment .......................................... 9
- 4.2 Matching ............................................. 10
- 4.3 Top Level ............................................ 12
- 4.4 Intermediate Level ................................... 13
- 4.5 Bottom Level ......................................... 14
- 5. Examples ................................................... 14
- 6. Support required from the standard ......................... 15
-
-
-
-Kille [Page 1]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- 7. Support of OSI Services .................................... 15
- 8. Experience ................................................. 16
- 9. Relationship to other work ................................. 17
- 10. Issues ..................................................... 19
- 11. References ................................................. 20
- 12. Security Considerations .................................... 21
- 13. Author's Address ........................................... 21
- A. Pseudo-code for the matching algorithm ..................... 22
- List of Figures
- 1. Example usage of User Friendly Naming ................ 18
- 2. Matching Algorithm ................................... 22
- List of Tables
- 1. Local environment for private DUA .................... 10
- 2. Local environment for US Public DUA .................. 11
-
-1. Why a notation is needed
-
- Many OSI Applications make use of Distinguished Names (DN) as defined
- in the OSI Directory [1]. The main reason for having a notation for
- name format is to interact with a user interface. This specification
- is coming dangerously close to the sin of standardising interfaces.
- However, there are aspects of presentation which it is desirable to
- standardise.
-
- It is important to have a common format to be able to conveniently
- refer to names. This might be done to represent a directory name on
- a business card or in an email message. There is a need for a format
- to support human to human communication, which must be string based
- (not ASN.1) and user oriented.
-
- In very many cases, a user will be required to input a name. This
- notation is designed to allow this to happen in a uniform manner
- across many user interfaces. The intention is that the name can just
- be typed in. There should not be any need to engage in form filling
- or complex dialogue. It should be possible to take the "human"
- description given at the meeting, and use it directly. The means in
- which this happens will become clear later.
-
- This approach uses the syntax defined in [5] for representing
- distinguished names. By relaxing some of the constraints on this
- specification, it is argued that a more user oriented specification
- is produced. However, this syntax cannot be mapped algorithmically
- onto a distinguished name without the use of a directory.
-
- This notation is targeted towards a general user oriented system, and
- in particular to represent the names of humans. Other syntaxes may
- be more appropriate for other uses of the directory. For example,
- the OSF Syntax may be more appropriate for some system oriented uses.
-
-
-
-Kille [Page 2]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- (The OSF Syntax uses "/" as a separator, and forms names in a manner
- intended to resemble UNIX filenames).
-
- This notation is targeted towards names which follow a particular DIT
- structure: organisationally oriented. This may make it
- inappropriate for some types of application. There may be a
- requirement to extend this notation to deal more cleanly with fully
- geographical names.
-
- This approach effectively defines a definition of descriptive names
- on top of the primitive names defined by the OSI Directory.
-
-2. The Notation
-
- The notation used in this specification is defined in [5]. This
- notation defines an unambiguous representation of distinguished name,
- and this specification is designed to be used in conjunction with
- this format. Both specifications arise from the same piece of
- research work [4]. Some examples of the specification are given
- here. The author's User Friendly Name (UFN) might be written:
-
- Steve Kille, Computer Science, University College London, GB
-
- or
-
- S. Kille, Computer Science, University College London, GB
-
- This may be folded, perhaps to display in multi-column format. For
- example:
-
- Steve Kille,
- Computer Science,
- University College London,
- GB
-
- Another UFN might be:
-
- Christian Huitema, INRIA, FR
-
- or
- James Hacker,
- Basingstoke,
- Widget Inc,
- GB
-
- The final example shows quoting of a comma in an Organisation name:
-
- L. Eagle, "Sue, Grabbit and Runn", GB
-
-
-
-Kille [Page 3]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- A purported name is what a user supplies to an interface for
- resolution into one or more distinguished names. A system should
- almost always store a name as a distinguished name. This will be
- more efficient, and avoid problems with purported names which become
- ambiguous when a new name appears. A user interface may display a
- distinguished name, using the distinguished name notation. However,
- it may display a purported name in cases where this will be more
- pleasing to the user. Examples of this might be:
-
- o Omission of the higher components of the distinguished name are
- not displayed (abbreviation).
-
- o Omission of attribute types, where the type is unlikely to be
- needed to resolve ambiguity.
-
- The ways in which a purported name may vary from a distinguished name
- are now described:
-
- Type Omission
-
- There are two cases of this.
-
- o Schema defaulting. In this case, although the type is not
- present, a schema defaulting is used to deduce the type. The
- first two types of schema defaulting may be used to deduce a
- distinguished name without the use of the directory. The use
- of schema defaulting may be useful to improve the performance
- of UFN resolution. The types of schema defaulting are:
-
- -- Default Schema
-
- -- Context Dependent Default Schema
-
- -- Data Dependent Default Schema
-
- o Omission of the type to be resolved by searching.
-
- Default Schema
-
- The attribute type of an attribute may always be present. This may
- be done to emphasise the type structure of a name. In some cases,
- the typing may be omitted. This is done in a way so that in many
- common cases, no attribute types are needed. The following type
- hierarchy (schema) is assumed:
-
-
-
-
-
-
-
-Kille [Page 4]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- Common Name, (((Organisational Unit)*, Organisation,) Country).
-
- Explicitly typed RDNs may be inserted into this hierarchy at any
- point. The least significant component is always of type Common
- Name. Other types follow the defined organisational hierarchy.
- The following are equivalent:
-
- Filestore Access, Bells, Computer Science,
- University College London, GB
-
- and
-
- CN=Filestore Access, OU=Bells, OU=Computer Science,
- O=University College London, C=GB
-
- To interpet a distinguished name presented in this format, with some
- or all of the attributes with the type not specified, the types are
- derived according to the type hierarchy by the following algorithm:
-
- 1. If the first attribute type is not specified, it is
- CommonName.
-
- 2. If the last attribute type is not specified, it is Country.
-
- 3. If there is no organisation explicitly specified, the last
- attribute with type not specified is of type Organisation.
-
- 4. Any remaining attribute with type unspecified must be before
- an Organisation or OrganisationalUnit attribute, and is of
- type OrganisationalUnit.
-
- To take a distinguished name, and generate a name of this format with
- attribute types omitted, the following steps are followed.
-
- 1. If the first attribute is of type CommonName, the type may be
- omitted.
-
- 2. If the last attribute is of type Country, the type may be
- omitted.
-
- 3. If the last attribute is of type Country, the last
- Organisation attribute may have the type omitted.
-
- 4. All attributes of type OrganisationalUnit may have the type
- omitted, unless they are after an Organisation attribute or
- the first attribute is of type OrganisationalUnit.
-
-
-
-
-
-Kille [Page 5]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- Context Dependent Default Schema
-
- The distinguished name notation defines a fixed schema for type
- defaulting. It may be useful to have different defaults in different
- contexts. For example, the defaulting convention may be applied in a
- modified fashion to objects which are known not to be common name
- objects. This will always be followed if the least significant
- component is explicitly typed. In this case, the following hierarchy
- is followed:
-
- ((Organisational Unit)*, Organisation,) Country
-
- Data Dependent Defaulting
-
- There are cases where it would be optimal
- to default according to the data. For example, in:
-
- Einar Stefferud, Network Management Associates, CA, US
-
- It would be useful to default "CA" to type State. This might be done
- by defaulting all two letter attributes under C=US to type State.
-
- General Defaulting
-
- A type may be omitted in cases where it does not follow a default
- schema hierarchy, and then type variants can be explored by
- searching. Thus a distinguished name could be represented by a
- uniquely matching purported name. For example,
-
- James Hacker,
- Basingstoke,
- Widget Inc,
- GB
-
- Would match the distinguished name:
-
- CN=James Hacker,
- L=Basingstoke,
- O=Widget Inc,
- C=GB
-
- Abbreviation
-
- Some of the more significant components of the DN will be omitted,
- and then defaulted in some way (e.g., relative to a local context).
- For example:
-
- Steve Kille
-
-
-
-Kille [Page 6]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- Could be interpreted in the context of an organisational default.
-
- Local Type Keywords
-
- Local values can be used to identify types, in addition to the
- keywords defined in [5]. For example, "Organisation" may be
- recognised as an alternative to "O".
-
- Component Omission
-
- An intermediate component of the name may be omitted. Typically this
- will be an organisational unit. For example:
-
- Steve Kille, University College London, GB
-
- In some cases, this can be combined with abbreviation. For example:
-
- Steve Kille, University College London
-
- Approximation
-
- Approximate renditions or alternate values of one or
- more of the components will be supplied. For example:
-
- Stephen Kille, CS, UCL, GB
-
- or
-
- Steve Keill, Comp Sci, Univarstiy College London, GB
-
- Friendly Country
-
- A "friendly country name" can be used instead of the ISO 3166 two
- letter code. For example: UK; USA; France; Deutchland.
-
-3. Communicating Directory Names
-
- A goal of this standard is to provide a means of communicating
- directory names. Two approaches are given, one defined in [5], and
- the other here. A future version of these specifications may contain
- only one of these approaches, or recommend use of one approach. The
- approach can usually be distinguished implicitly, as types are
- normally omitted in the UFN approach, and are always present in the
- Distinguished Name approach. No recommendation is made here, but the
- merits of each approach is given.
-
-
-
-
-
-
-Kille [Page 7]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- 1. Distinguished Name or DN. A representation of the distinguished
- name, according to the specification of [5].
-
- 2. User Friendly Name or UFN. A purported name, which is expected to
- unambiguously resolve onto the distinguished name.
-
- When a UFN is communicated, a form which should efficiently and
- unambiguously resolve onto a distinguished name should be chosen.
- Thus it is reasonable to omit types, or to use alternate values which
- will unambiguously identify the entry in question (e.g., by use of an
- alternate value of the RDN attribute type). It is not reasonable to
- use keys which are (or are likely to become) ambiguous. The approach
- used should be implicit from the context, rather than wired into the
- syntax. The terms "Directory Name" and "X.500 Name" should be used
- to refer to a name which might be either a DN or UFN. An example of
- appropriate usage of both forms is given in the Section which defines
- the Author's location in Section 12. Advantages of communicating the
- DN are:
-
- o The Distinguished Name is an unambiguous and stable reference to
- the user.
-
- o The DN will be used efficiently by the directory to obtain
- information.
-
- Advantages of communicating the UFN are:
-
- o Redundant type information can be omitted (e.g., "California",
- rather than "State=California", where there is known to be no
- ambiguity.
-
- o Alternate values can be used to identify a component. This might
- be used to select a value which is meaningful to the recipient, or
- to use a shorter form of the name. Often the uniqueness
- requirements of registration will lead to long names, which users
- will wish to avoid.
-
- o Levels of the hierarchy may be omitted. For example in a very
- small organisation, where a level of hierarchy has been used to
- represent company structure, and the person has a unique name
- within the organisation.
-
- Where UFN form is used, it is important to specify an unambiguous
- form. In some ways, this is analogous to writing a postal address.
- There are many legal ways to write it. Care needs to be taken to
- make the address unambiguous.
-
-
-
-
-
-Kille [Page 8]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-4. Matching a purported name
-
- The following approach specifies a default algorithm to be used with
- the User Friendly Naming approach. It is appropriate to modify this
- algorithm, and future specifications may propose alternative
- algorithms. Two simple algorithms are noted in passing, which may be
- useful in some contexts:
-
- 1. Use type omission only, but otherwise require the value of the RDN
- attribute to be present.
-
- 2. Require each RDN to be identified as in 1), or by an exact match
- on an alternate value of the RDN attribute.
-
- These algorithms do not offer the flexibility of the default
- algorithm proposed, but give many of the benefits of the approach in
- a very simple manner.
-
- The major utility of the purported name is to provide the important
- "user friendly" characteristic of guessability. A user will supply a
- purported name to a user interface, and this will be resolved onto a
- distinguished name. When a user supplies a purported name there is a
- need to derive the DN. In most cases, it should be possible to derive
- a single name from the purported name. In some cases, ambiguities
- will arise and the user will be prompted to select from a multiple
- matches. This should also be the case where a component of the name
- did not "match very well".
-
- There is an assumption that the user will simply enter the name
- correctly. The purported name variants are designed to make this
- happen! There is no need for fancy window based interfaces or form
- filling for many applications of the directory. Note that the fancy
- interfaces still have a role for browsing, and for more complex
- matching. This type of naming is to deal with cases where
- information on a known user is desired and keyed on the user's name.
-
-4.1 Environment
-
- All matches occur in the context of a local environment. The local
- environment defines a sequence of names of a non-leaf objects in the
- DIT. This environment effectively defines a list of acceptable name
- abbreviations where the DUA is employed. The environment should be
- controllable by the individual user. It also defines an order in
- which to operate.
-
- This list is defined in the context of the number of name components
- supplied. This allows varying heuristics, depending on the
- environment, to make the approach have the "right" behaviour. In
-
-
-
-Kille [Page 9]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- most cases, the environment will start at a local point in the DIT,
- and move upwards. Examples are given in Tables 1 and 2. Table 1
- shows an example for a typical local DUA, which has the following
- characteristics:
-
- One component
-
- Assumed first to be a user in the department, then a user or
- department within the university, then a national organisation, and
- finally a country.
-
- Two components
-
- Most significant component is first assumed to be a national
- organisation, then a department (this might be reversed in some
- organisations), and finally a country.
-
- Three or more components
-
- The most significant component is first assumed to be a country, then
- a national organisation, and finally a department.
-
-4.2 Matching
-
- A purported name will be supplied, usually with a small number of
- components. This will be matched in the context of an environment.
- Where there are multiple components to be matched, these should be
- matched sequentially. If an unambiguous DN is determined, the match
- continues as if the full DN had been supplied. For example, if
-
- +-----------+--------------------------------------+
- |Number of |Environment |
- |Components | |
- +-----------+--------------------------------------+
- |1 |Physics, University College London, GB|
- | |University College London, GB |
- | |GB |
- +-----------+--------------------------------------+
- |2 |GB |
- | |University College London, GB |
- | |-- |
- +-----------+--------------------------------------+
- |3+ |-- |
- | |GB |
- | |University College London, GB |
- +-----------+--------------------------------------+
-
- Table 1: Local environment for private DUA
-
-
-
-Kille [Page 10]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- +------------+-----------+
- | Number of |Environment|
- | Components | |
- +------------+-----------+
- | 1,2 | US |
- | | CA |
- | | -- |
- +------------+-----------+
- | 3+ | -- |
- | | US |
- | | CA |
- +------------+-----------+
-
- Table 2: Local environment for US Public DUA
-
- Stephen Kille, UCL
-
- is being matched in the context of environment GB, first UCL is
- resolved to the distinguished name:
-
- University College London, GB
-
- Then the next component of the purported name is taken to determine
- the final name. If there is an ambiguity (e.g., if UCL had made two
- matches, both paths are explored to see if the ambiguity can be
- resolved. Eventually a set of names will be passed back to the user.
-
- Each component of the environment is taken in turn. If the purported
- name has more components than the maximum depth, the environment
- element is skipped. The advantage of this will be seen in the
- example given later.
-
- A match of a name is considered to have three levels:
-
- Exact A DN is specified exactly
-
- Good Initially, a match should be considered good if it is
- unambiguous, and exactly matches an attribute value in the entry.
- For human names, a looser metric is probably desirable (e.g.,
- S Kille should be a good match of S. Kille, S.E. Kille or Steve
- Kille even if these are not explicit alternate values).
-
- Poor Any other substring or approximate match
-
- Following a match, the reference can be followed, or the user
- prompted. If there are multiple matches, more than one path may be
- followed. There is also a shift/reduce type of choice: should any
- partial matches be followed or should the next element of the
-
-
-
-Kille [Page 11]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- environment be tried. The following heuristics are suggested, which
- may be modified in the light of experience. The overall aim is to
- resolve cleanly specified names with a minimum of fuss, but give
- sufficient user control to prevent undue searching and delay.
-
- 1. Always follow an exact match.
-
- 2. Follow all good matches if there are no exact matches.
-
- 3. If there are only poor matches, prompt the user. If the user
- accepts one or more matches, they can be considered as good. If
- all are rejected, this can be treated as no matches.
-
- 4. Automatically move to the next element of the environment if no
- matches are found.
-
- When the final component is matched, a set of names will be
- identified. If none are identified, proceed to the next environment
- element. If the user rejects all of the names, processing of the
- next environment element should be confirmed.
-
- The exact approach to matching will depend on the level of the tree
- at which matching is being done. We can now consider how attributes
- are matched at various levels of the DIT.
-
- There is an issue of approximate matching. Sometimes it helps, and
- sometimes just returns many spurious matches. When a search is
- requested, all relevant attributes should be returned, so that
- distinguished and non-distinguished values can be looked at. This
- will allow a distinction to be made between good and poor matches.
- It is important that where, for example, an acronym exactly matches
- an organisation, that the user is not prompted about other
- organisations where it matches as a substring.
-
-4.3 Top Level
-
- In this case, a match is being done at the root of the DIT. Three
- approaches are suggested, dependent on the length of supplied name.
- All lead to a single level search of the top level of the DIT.
-
- Exactly 2
-
- This is assumed to be a 3166 two letter country code, or an exact
- match on a friendly country or organisation (e.g., UK or UN). Do
- exact match on country and friendly country.
-
-
-
-
-
-
-Kille [Page 12]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- Greater than 2
-
- Make an approximate and substring match on friendly country and
- organisation.
-
-4.4 Intermediate Level
-
- Once the root level has been dealt with, intermediate levels will be
- looking for organisational components (Organisation, Locality, Org
- Unit). In some cases, private schema control will allow the system
- to determine which is at the next level. In general this will not be
- possible. In each case, make a substring and approximate match
- search of one level. The choice depends on the base object used in
- the search.
-
- 1. If DN has no Organisation or Locality, filter on Organisation and
- Locality.
-
- 2. If DN has Org Unit, filter on Org Unit.
-
- 3. If DN has Organisation, filter on Locality and Org Unit.
-
- 4. If DN has Locality, filter on Organisation.
-
- These allow some optimisation, based on legal choices of schema.
- Keeping filters short is usually desirable to improve performance. A
- few examples of this, where a base object has been determined (either
- by being the environment or by partial resolution of a purported
- name), and the next element of a purported name is being considered.
- This will generate a single level search. What varies is the types
- being filtered against. If the DN is:
-
- University College London, GB
-
- The search should be for Org Unit or Locality. If the DN is:
-
- Organisation=UN
-
- the search should be for Org Unit or Locality.
-
- There may be some improvements with respect to very short keys. Not
- making approximate or substring matches in these cases seems sensible
- (It might be desirable to allow "*" as a part of the purported name
- notation.)
-
-
-
-
-
-
-
-Kille [Page 13]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-4.5 Bottom Level
-
- The "Bottom Level" is to deal with leaf entries in the DIT. This will
- often be a person, but may also be a role, an application entity or
- something else.
-
- The last component of a purported name may either reference a leaf or
- non-leaf. For this reason, both should be tested for. As a
- heuristic, if the base object for the search has two or more
- components it should be tested first as a bottom level name and then
- intermediate. Reverse this for shorter names. This optimises for
- the (normal) case of non-leaves high up the tree and leaves low down
- the tree.
-
- For bottom level names, make an approximate and substring match
- against Common Name, Surname, and User ID. Where common name is
- looked for, a full subtree search will be used when at the second
- level of the DIT or lower, otherwise a single level search.
-
- For example, if I have resolved a purported name to the distinguished
- name
-
- University College London, GB
-
- and have a single component Bloggs, this will generate a subtree
- search.
-
-5. Examples
-
- This is all somewhat confusing, and a few examples are given. These
- are all in the context of the environment shown in Table 1 on Page
- 13.
-
- If "Joe Bloggs" is supplied, a subtree search of
-
- Physics, University College London, GB
-
- will be made, and the user prompted for "Joseph Z. Bloggs" as the
- only possible match.
-
- If "Computer Science" is supplied, first
-
- Physics, University College London, GB
-
- will be searched, and the user will reject the approximate match of
- "Colin Skin". Then a subtree search of
-
- University College London, GB
-
-
-
-Kille [Page 14]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- will be made, looking for a person. Then a single level search will
- be made looking for Org Unit, and
-
- Computer Science, University College London, GB
-
- will be returned without prompting (exact match). Supplying "Steve
- Kille" will lead to a failed subtree search of
-
- Physics, University College London, GB
-
- and lead straight to a subtree search of
-
- University College London, GB
-
- This will lead to an exact value match, and so a single entry
- returned without prompting.
-
- If "Andrew Findlay, Brunel" is supplied, the first element of the
- environment will be skipped, single level search of "Brunel" under
- "GB" will find:
-
- Brunel University, GB
-
- and a subtree search for "Andrew Findlay" initiated. This will yield
-
- Andrew Findlay, Computing and Media Services, Brunel University, GB
-
- Dr A J Findlay, Manufacturing and Engineering Systems, Brunel
- University, GB
-
- and the user will be prompted with a choice.
-
- This approach shows how a simple format of this nature will "do the
- right thing" in many cases.
-
-6. Support required from the standard
-
- Fortunately, all that is needed is there! It would be useful to have
- "friendly country name" as a standard attribute.
-
-7. Support of OSI Services
-
- The major focus of this work has been to provide a mechanism for
- identifying Organisations and Users. A related function is to
- identify applications. Where the Application is identified by an AET
- (Application Entity Title) with an RDN of Common Name, this
- specification leads to a natural usage. For example, if a filestore
- is named "gannet", then this could easily be identified by the name:
-
-
-
-Kille [Page 15]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- Gannet, Computer Laboratory, Cambridge University, GB
-
- In normal usage, this might lead to access (using a purported name)
- of:
-
- FTAM gannet,cambridge
-
- A second type of access is where the user identifies an Organisation
- (Organisational Unit), and expects to obtain a default service. The
- service is implied by the application, and should not require any
- additional naming as far as the user is concerned. It is proposed
- that this is supported by User Friendly Naming in the following way.
-
- 1. Determine that the purported name identifies a non-leaf object,
- which is of object class Organisation or Organisational Unit or
- Locality.
-
- 2. Perform a single level search for Application Entities which
- support the required application contexts. This assumes that all
- services which are supporting default access for the organisation
- are registered at one level below (possibly by the use of
- aliases), and that other services (specific machines or parts of
- the organisation) are represented further down the tree. This
- seems to be a reasonable layout, and its utility can be evaluated
- by experiment.
-
-8. Experience
-
- An experimental implementation of this has been written by Colin
- Robbins. The example in Figure 1 shows that it can be very effective
- at locating known individuals with a minimum of effort. This code has
- been deployed within the "FRED" interface of the PSI Pilot [9], and
- within an prototype interface for managing distribution lists. The
- user reaction has been favourable:
-
- Some issues have arisen from this experience:
-
- o Where there is more than one level of Organisational Unit, and the
- user guesses one which is not immediately below the organisation,
- the algorithm works badly. There does not appear to be an easy
- fix for this. It is not clear if this is a serious deficiency.
-
- o Substring searching is currently done with leading and trailing
- wildcards. As many implementations will not implement leading
- wildcards efficiently, it may be preferable to only use trailing
- wildcards. The effect of this on the algorithm needs to be
- investigated.
-
-
-
-
-Kille [Page 16]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- Implementors of this specification are encouraged to investigate
- variants of the basic algorithm. A final specification should depend
- on experience with such variants.
-
-9. Relationship to other work
-
- Colin Robbin's work on the interface "Tom" and implementation of a
- distribution list interface strongly influenced this specification
- [6].
-
- Some of the ideas used here originally came from a UK Proposal to the
- ISO/CCITT Directory Group on "New Name Forms" [2]. This defined, and
- showed how to implement, four different types of names:
-
- Typed and Ordered The current Distinguished Name is a restricted
- example of this type of name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 17]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- -> t hales, csiro, australia
- Found good match(es) for 'australia'
- Found exact match(es) for 'csiro'
- Please select from the following:
- Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y
- The following were matched...
- Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU
-
- -> g michaelson, queensland, au
- Found exact match(es) for 'au'
- Please select from the following:
- University of Queensland, AU [y/n] ? y
- Axolotl, AU [y/n] ? n
- Please select from the following:
- George Michaelson, Prentice Computer Centre, University of
- Queensland, AU
- [y/n] ? y
- Manager, University of Queensland, AU [y/n] ? n
- The following were matched...
- George Michaelson, Prentice Computer Centre, University of
- Queensland, AU
-
- -> r needham, cambridge
- Found good match(es) for 'cambridge'
- Please select from the following:
- Roger Needham, Computer Lab, Cambridge University [y/n] ? y
- The following were matched...
- Roger Needham, Computer Lab, Cambridge University
-
- -> kirstein
- Found good match(es) for 'kirstein'
- The following were matched...
- Peter Kirstein
-
-
- Figure 1: Example usage of User Friendly Naming
-
- Untyped and Ordered
-
- This is the type of name proposed here (with some extensions to allow
- optional typing). It is seen as meeting the key user requirement of
- disliking typed names, and is efficient to implement.
-
- Typed and Unordered
-
- This sort of name is proposed by others as the key basis for user
- friendly naming. Neufeld shows how X.500 can be used to provide this
- [7], and Peterson proposes the Profile system to provide this [8].
-
-
-
-Kille [Page 18]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- The author contends that whilst typed naming is interesting for some
- types of searching (e.g., yellow page searching), it is less
- desirable for naming objects. This is borne out by operational
- experience with OSI Directories [3].
-
- Untyped and Unordered
-
- Surprisingly this form of name can be supported quite easily.
- However, a considerable gain in efficiency can be achieved by
- requiring ordering. In practice, users can supply this easily.
- Therefore, this type of name is not proposed.
-
-10. Issues
-
- The following issues are noted, which would need to be resolved
- before this document is progressed as an Internet Standard.
-
- Potential Ambiguity
-
- Whilst the intention of the notation is to allow for specification of
- alternate values, it inherently allows for ambiguous names to be
- specified. It needs to be demonstrated that problems of this
- characteristic are outweighed by other benefits of the notation.
-
- Utility
-
- Determine that the specification is being implemented and used.
-
- Performance
-
- Measurements on the performance implications of using this approach
- should be made.
-
- Alogrithm
-
- The utility of the algorithm, and possible variants, should be
- investigated.
-
- This format, and the procedures for resolving purported names, should
- be evolved to an Internet Standard. The syntax can be expected to be
- stable. In light of experience, the algorithm for resolving
- purported names may be changed.
-
-
-
-
-
-
-
-
-
-Kille [Page 19]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-11. References
-
- [1] The Directory --- overview of concepts, models and services,
- 1993. CCITT X.500 Series Recommendations.
-
- [2] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ WG4/N797
- UK National Body Contribution to the Oslo Directory Meeting.
-
- [3] S.E. Kille. The THORN large scale pilot exercise. Computer
- Networks and ISDN Systems, 16(1):143--145, January 1989.
-
- [4] S.E. Kille. Using the OSI directory to achieve user friendly
- naming. Research Note RN/20/29, Department of Computer Science,
- University College London, February 1990.
-
- [5] Kille, S., "A String Representation of Distinguished Names", RFC
- 1779, ISODE Consortium, March 1995.
-
- [6] S.E. Kille and C.J. Robbins. The ISO development environment:
- User's manual (version 7.0), July 1991. Volume 5: QUIPU.
-
- [7] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89
- Symposiun Communications Architectures and Protocols, pages 64--
- 71, September 1989.
-
- [8] L.L. Petersen. The profile naming service. ACM Transactions on
- Computing Systems, 6(4):341--364, November 1988.
-
- [9] M.T. Rose. Realizing the White Pages using the OSI Directory
- Service. Technical Report 90--05--10--1, Performance Systems
- International, Inc., May 1990.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 20]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-12. Security Considerations
-
- Security issues are not discussed in this memo.
-
-13. Author's Address
-
- Steve Kille
- ISODE Consortium
- The Dome
- The Square
- Richmond, Surrey
- TW9 1DT
- England
-
- Phone:+44-181-332-9091
- EMail: S.Kille@ISODE.COM
-
- DN: CN=Steve Kille,
- O=ISODE Consortium, C=GB
-
- UFN: S. Kille,
- ISODE Consortium, GB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 21]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-A. Pseudo-code for the matching algorithm
-
- The following pseudo-code is intended to clarify the matching
- algorithm. The language uses ASN.1 data types, with flow control
- "C"-like, but with keywords upper-cased.
-
-PurportedName ::= SEQUENCE OF String
- -- simplication, as attribute types can optionally be
- -- specified
-
- -- Each element of the Purported Name is a string
- -- which has been parsed from the BNF
-
-Attribute ::= SEQUENCE {
- type OBJECT IDENTIFIER,
- value ANY }
-
-RDN ::= Attribute -- simplification, as can be multi-value
-
-DN ::= SEQUENCE OF RDN
-
-Environment ::= SEQUENCE OF DN
-
-EnvironmentList ::= SEQUENCE OF SEQUENCE {
- lower-bound INTEGER,
- upper-bound INTEGER,
- environment Environment }
-
-
-friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN
-{
- -- Find correct environment
-
- IF length(el) == 0 THEN return(NULL);
-
- IF length(p) <= head(el).upper-bound
- && length(p) >= head(el).lower-bound THEN
- return envMatch (p, head(el).environment);
- ELSE
- return(friendlyMatch(p, tail(el));
-}
-
-envMatch(p: PurportedName; e: Environment): SET OF DN
-{
- -- Check elements of environment
- -- in the defined order
-
- matches: SET OF DN;
-
-
-
-Kille [Page 22]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
- IF length(e) == 0 THEN return(NULL);
-
- matches = purportedMatch(head(e).DN, p)
- IF matches != NULL THEN
- return(matches);
- ELSE
- return(envMatch(p, tail(e));
-}
-
-
-purportedMatch(base: DN; p: PurportedName): SET OF DN
-{
- s: String = head(p);
- matches: SET OF DN = NULL;
-
- IF length(p) == 1 THEN
- IF length(base) == 0 THEN
- IF (matches = rootSearch(s)) != NULL THEN
- return(matches);
- ELSE return(leafSearch(base, s, one-level);
- ELSE IF length(base) == 1 THEN
- IF (matches = intSearch(base, s)) != NULL THEN
- return(matches);
- ELSE return(leafSearch(base, s, one-level);
- ELSE
- IF (matches = leafSearch(base, s, subtree)) !=
- NULL THEN return(matches);
- ELSE return(intsearch(base, s);
-
-
- IF length(base) == 0 THEN
- FOR x IN rootSearch(s) DO
- matches += (purportedMatch(x, tail(p));
- ELSE
- FOR x IN intSearch(base, s) DO
- matches += (purportedMatch(x, tail(p));
- return(matches);
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 23]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
--- General. Might need to tighten the filter for short strings,
--- in order to stop being flooded. Alternatively, this could be
--- done if the loose search hits a size limit
-
-rootSearch(s: String): SET OF DN
-{
- IF length(s) == 2 THEN
- return(search(NULL, one-level, s, {CountryName,
- FriendlyCountryName, OrganizationName},
- {exact}, {Country, Organisation}));
- -- test exact match only
- -- probably a country code
- ELSE
- return(search(NULL, one-level, s, {OrganizationName,
- FriendlyCountryName}, {substring, approx},
- {Country, Organisation}));
-}
-
-
-intSearch( base: DN; s: String)
-{
- IF present(base, OrgUnitName) THEN
- return(search(base, one-level, s, {OrgUnitName},
- {substring, approx}, {OrgUnit}));
- ELSE IF present(base, OrganisationName) THEN
- return(search(base, one-level, s, {OrgUnitName,
- LocalityName}, {substring, approx},
- {Organization, OrgUnit, Locality}));
- ELSE IF present(base, LocalityName) THEN
- return(search(base, one-level, s, {OrganisationName},
- {substring, approx}, {Locality});
- ELSE
- return(search(base, one-level, s, {OrganisationName,
- LocalityName}, {substring, approx},
- {Organisation, Locality}));
-}
-
-
-present(d: DN; t: AttributeType): BOOLEAN
-{
- FOR x IN d DO
- IF x.type == t THEN return(TRUE);
- return(FALSE);
-}
-
-SearchScope := ENUMERATED (base-object, one-level, subtree)
-
-leafSearch(base: DN; s: String; search-scope: SearchScope)
-
-
-
-Kille [Page 24]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-{
- return(search(base, search-scope, s, {CommonName, Surname,
- UserId}, {substring, approx}));
-}
-
-search(base: DN; search-scope: SearchScope; s: string;
- alist SET OF AttributeType; matchtypes SET OF MatchType
- objectClasses SET OF ObjectClass OPTIONAL): SET OF DN
-{
- -- mapped onto Directory Search, with OR conjunction
- -- of filter items
-
- return dNSelect (s, search-results, alist);
-}
-
-read(base: DN; alist SET OF AttributeType): SET OF Attribute;
-{
- -- mapped onto Directory Read
- -- Types repeated to deal with multiple values
- -- This would be implemented by returning selected info
- -- with the search operation
-}
-
-dNSelect(s: String; dlist SET OF DN;
- alist: SET OF AttributeType):16SET0OF DN
-{
- exact, good: SET OF DN;
-
- FOR x IN dlist DO
- IF last(DN).Value == s THEN
- exact += x;
- ELSE IF FOR y IN read(x, alist) DO
- IF y.value == s THEN
- good += x;
-
- IF exact != NULL THEN return(exact);
- IF good != NULL THEN return(good);
- return(userQuery(dlist));
-}
-
-userQuery(dlist SET OF DN): SET OF DN
-{
- -- pass back up for manual checking
- -- user can strip all matches to force progres....
-}
-
-head() -- return first element of list
-tail() -- return list with first element removed
-
-
-
-Kille [Page 25]
-\f
-RFC 1781 User Friendly Naming March 1995
-
-
-length() -- return size of list
-last() -- return last element of list
-
- Figure 2: Matching Algorithm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kille [Page 26]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group T. Howes
-Request for Comments: 1960 University of Michigan
-Obsoletes: 1558 June 1996
-Category: Standards Track
-
- A String Representation of LDAP Search Filters
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-1. Abstract
-
- The Lightweight Directory Access Protocol (LDAP) [1] defines a
- network representation of a search filter transmitted to an LDAP
- server. Some applications may find it useful to have a common way of
- representing these search filters in a human-readable form. This
- document defines a human-readable string format for representing LDAP
- search filters.
-
-2. LDAP Search Filter Definition
-
- An LDAP search filter is defined in [1] as follows:
-
- Filter ::= CHOICE {
- and [0] SET OF Filter,
- or [1] SET OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeType,
- approxMatch [8] AttributeValueAssertion
- }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeType,
- SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString
- }
- }
-
-
-
-Howes Standards Track [Page 1]
-\f
-RFC 1960 LDAP Search Filters June 1996
-
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeType AttributeType,
- attributeValue AttributeValue
- }
-
- AttributeType ::= LDAPString
-
- AttributeValue ::= OCTET STRING
-
- LDAPString ::= OCTET STRING
-
- where the LDAPString above is limited to the IA5 character set. The
- AttributeType is a string representation of the attribute type name
- and is defined in [1]. The AttributeValue OCTET STRING has the form
- defined in [2]. The Filter is encoded for transmission over a
- network using the Basic Encoding Rules defined in [3], with
- simplifications described in [1].
-
-3. String Search Filter Definition
-
- The string representation of an LDAP search filter is defined by the
- following grammar. It uses a prefix format.
-
- <filter> ::= '(' <filtercomp> ')'
- <filtercomp> ::= <and> | <or> | <not> | <item>
- <and> ::= '&' <filterlist>
- <or> ::= '|' <filterlist>
- <not> ::= '!' <filter>
- <filterlist> ::= <filter> | <filter> <filterlist>
- <item> ::= <simple> | <present> | <substring>
- <simple> ::= <attr> <filtertype> <value>
- <filtertype> ::= <equal> | <approx> | <greater> | <less>
- <equal> ::= '='
- <approx> ::= '~='
- <greater> ::= '>='
- <less> ::= '<='
- <present> ::= <attr> '=*'
- <substring> ::= <attr> '=' <initial> <any> <final>
- <initial> ::= NULL | <value>
- <any> ::= '*' <starval>
- <starval> ::= NULL | <value> '*' <starval>
- <final> ::= NULL | <value>
-
- <attr> is a string representing an AttributeType, and has the format
- defined in [1]. <value> is a string representing an AttributeValue,
- or part of one, and has the form defined in [2]. If a <value> must
- contain one of the characters '*' or '(' or ')', these characters
- should be escaped by preceding them with the backslash '\' character.
-
-
-
-Howes Standards Track [Page 2]
-\f
-RFC 1960 LDAP Search Filters June 1996
-
-
- Note that although both the <substring> and <present> productions can
- produce the 'attr=*' construct, this construct is used only to denote
- a presence filter.
-
-4. Examples
-
- This section gives a few examples of search filters written using
- this notation.
-
- (cn=Babs Jensen)
- (!(cn=Tim Howes))
- (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
- (o=univ*of*mich*)
-
-5. Security Considerations
-
- Security considerations are not discussed in this memo.
-
-6. Bibliography
-
- [1] Yeong, W., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol", RFC 1777, March 1995.
-
- [2] Howes, R., Kille, S., Yeong, W., and C. Robbins, "The String
- Representation of Standard Attribute Syntaxes", RFC 1778,
- March 1995.
-
- [3] Specification of Basic Encoding Rules for Abstract Syntax
- Notation One (ASN.1). CCITT Recommendation X.209, 1988.
-
-7. Author's Address
-
- Tim Howes
- University of Michigan
- ITD Research Systems
- 535 W William St.
- Ann Arbor, MI 48103-4943
- USA
-
- Phone: +1 313 747-4454
- EMail: tim@umich.edu
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 3]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Boeyen
-Request for Comments: 2559 Entrust
-Updates: 1778 T. Howes
-Category: Standards Track Netscape
- P. Richard
- Xcert
- April 1999
-
-
- Internet X.509 Public Key Infrastructure
- Operational Protocols - LDAPv2
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Abstract
-
- The protocol described in this document is designed to satisfy some
- of the operational requirements within the Internet X.509 Public Key
- Infrastructure (IPKI). Specifically, this document addresses
- requirements to provide access to Public Key Infrastructure (PKI)
- repositories for the purposes of retrieving PKI information and
- managing that same information. The mechanism described in this
- document is based on the Lightweight Directory Access Protocol (LDAP)
- v2, defined in RFC 1777, defining a profile of that protocol for use
- within the IPKI and updates encodings for certificates and revocation
- lists from RFC 1778. Additional mechanisms addressing PKIX
- operational requirements are specified in separate documents.
-
- The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
- in this document are to be interpreted as described in RFC 2119.
-
-2. Introduction
-
- This specification is part of a multi-part standard for development
- of a Public Key Infrastructure (PKI) for the Internet. This
- specification addresses requirements to provide retrieval of X.509
- PKI information, including certificates and CRLs from a repository.
- This specification also addresses requirements to add, delete and
-
-
-
-Boeyen, et al. Standards Track [Page 1]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
- modify PKI information in a repository. A profile based on the LDAP
- version 2 protocol is provided to satisfy these requirements.
-
-3. Model
-
- The PKI components, as defined in PKIX Part 1, which are involved in
- PKIX operational protocol interactions include:
-
- - End Entities
- - Certification Authorities (CA)
- - Repository
-
- End entities and CAs using LDAPv2, retrieve PKI information from the
- repository using a subset of the LDAPv2 protocol.
-
- CAs populate the repository with PKI information using a subset of
- the LDAPv2 protocol.
-
-4. Lightweight Directory Access Protocol (LDAP)
-
- The following sections examine the retrieval of PKI information from
- a repository and management of PKI information in a repository. A
- profile of the LDAPv2 protocol is defined for providing these
- services.
-
- Section 5 satisfies the requirement to retrieve PKI information (a
- certificate, CRL, or other information of interest) from an entry in
- the repository, where the retrieving entity (either an end entity or
- a CA) has knowledge of the name of the entry. This is termed
- "repository read".
-
- Section 6 satisfies the same requirement as 5 for the situation where
- the name of the entry is not known, but some other related
- information which may optionally be used as a filter against
- candidate entries in the repository, is known. This is termed
- "repository search".
-
- Section 7 satisfies the requirement of CAs to add, delete and modify
- PKI information information (a certificate, CRL, or other information
- of interest)in the repository. This is termed "repository modify".
-
- The subset of LDAPv2 needed to support each of these functions is
- described below. Note that the repository search service is a
- superset of the repository read service in terms of the LDAPv2
- functionality needed.
-
- Note that all tags are implicit by default in the ASN.1 definitions
- that follow.
-
-
-
-Boeyen, et al. Standards Track [Page 2]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
-5. LDAP Repository Read
-
- To retrieve information from an entry corresponding to the subject or
- issuer name of a certificate, requires a subset of the following
- three LDAP operations:
-
- BindRequest (and BindResponse)
- SearchRequest (and SearchResponse)
- UnbindRequest
-
- The subset of each REQUIRED operation is given below.
-
-5.1. Bind
-
-5.1.1. Bind Request
-
- The full LDAP v2 Bind Request is defined in RFC 1777.
-
- An application providing a LDAP repository read service MUST
- implement the following subset of this operation:
-
- BindRequest ::=
- [APPLICATION 0] SEQUENCE {
- version INTEGER (2),
- name LDAPDN, -- MUST accept NULL LDAPDN
- simpleauth [0] OCTET STRING -- MUST accept NULL simple
- }
-
- An application providing a LDAP repository read service MAY implement
- other aspects of the BindRequest as well.
-
- Different services may have different security requirements. Some
- services may allow anonymous search, others may require
- authentication. Those services allowing anonymous search may choose
- only to allow search based on certain criteria and not others.
-
- A LDAP repository read service SHOULD implement some level of
- anonymous search access. A LDAP repository read service MAY implement
- authenticated search access.
-
-5.1.2. Bind Response
-
- The full LDAPv2 BindResponse is described in RFC 1777.
-
- An application providing a LDAP repository read service MUST
- implement this entire protocol element, though only the following
- error codes may be returned from a Bind operation:
-
-
-
-
-Boeyen, et al. Standards Track [Page 3]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
- success (0),
- operationsError (1),
- protocolError (2),
- authMethodNotSupported (7),
- noSuchObject (32),
- invalidDNSyntax (34),
- inappropriateAuthentication (48),
- invalidCredentials (49),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
-
-5.2. Search
-
-5.2.1. Search Request
-
- The full LDAPv2 SearchRequest is defined in RFC 1777.
-
- An application providing a LDAP repository read service MUST
- implement the following subset of the SearchRequest.
-
- SearchRequest ::=
- [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- },
- sizeLimit INTEGER (0),
- timeLimit INTEGER (0),
- attrsOnly BOOLEAN, -- FALSE only
- filter Filter,
- attributes SEQUENCE OF AttributeType
- }
-
- Filter ::=
- CHOICE {
- present [7] AttributeType, -- "objectclass" only
- }
-
- This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
- operation: a base object search with a filter testing for the
- existence of the objectClass attribute.
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 4]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
- An application providing a LDAP repository read service MAY implement
- other aspects of the SearchRequest as well.
-
-5.2.2.
-
- The full LDAPv2 SearchResponse is defined in RFC 1777.
-
- An application providing a LDAP repository read service over LDAPv2
- MUST implement the full SearchResponse.
-
- Note that in the case of multivalued attributes such as
- userCertificate a SearchResponse containing this attribute will
- include all values, assuming the requester has sufficient access
- permissions. The application/relying party may need to select an
- appropriate value to be used. Also note that retrieval of a
- certificate from a named entry does not guarantee that the
- certificate will include that same Distinguished Name (DN) and in
- some cases the subject DN in the certificate may be NULL.
-
-5.3. Unbind
-
- The full LDAPv2 UnbindRequest is defined in RFC 1777.
-
- An application providing a LDAP repository read service MUST
- implement the full UnbindRequest.
-
-6. LDAP Repository Search
-
- To search, using arbitrary criteria, for an entry in a repository
- containing a certificate, CRL, or other information of interest,
- requires a subset of the following three LDAP operations:
-
- BindRequest (and BindResponse)
- SearchRequest (and SearchResponse)
- UnbindRequest
-
- The subset of each operation REQUIRED is given below.
-
-6.1. Bind
-
- The BindRequest and BindResponse subsets needed are the same as those
- described in Section 5.1.
-
- The full LDAP v2 Bind Request is defined in RFC 1777.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 5]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
-6.2. Search
-
-6.2.1. Search Request
-
- The full LDAPv2 SearchRequest is defined in RFC 1777.
-
- An application providing a LDAP repository search service MUST
- implement the following subset of the SearchRequest protocol unit.
-
- SearchRequest ::=
- [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2)
- },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- attrsOnly BOOLEAN, -- FALSE only
- filter Filter,
- attributes SEQUENCE OF AttributeType
- }
-
- All aspects of the SearchRequest MUST be supported, except for the
- following:
-
- - Only the neverDerefAliases value of derefAliases needs to be
- supported
-
- - Only the FALSE value for attrsOnly needs to be supported
-
- This subset provides a more general search capability. It is a
- superset of the SearchRequest subset defined in Section 5.2.1. The
- elements added to this service are:
-
- - singleLevel and wholeSubtree scope needs to be supported
-
- - sizeLimit is included
-
- - timeLimit is included
-
- - Enhanced filter capability
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 6]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
- An application providing a LDAP repository search service MAY
- implement other aspects of the SearchRequest as well.
-
-6.2.2. Search Response
-
- The full LDAPv2 SearchResponse is defined in RFC 1777.
-
- An application providing a LDAP repository search service over LDAPv2
- MUST implement the full SearchResponse.
-
-6.3. Unbind
-
- An application providing a LDAP repository search service MUST
- implement the full UnbindRequest.
-
-7. LDAP Repository Modify
-
- To add, delete and modify PKI information in a repository requires a
- subset of the following LDAP operations:
-
- BindRequest (and BindResponse)
- ModifyRequest (and ModifyResponse)
- AddRequest (and AddResponse)
- DelRequest (and DelResponse
- UnbindRequest
-
- The subset of each operation REQUIRED is given below.
-
-7.1. Bind
-
- The full LDAP v2 Bind Request is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the following subset of this operation:
-
- BindRequest ::=
- [APPLICATION 0] SEQUENCE {
- version INTEGER (2),
- name LDAPDN,
- simpleauth [0] OCTET STRING
- }
-
- A LDAP repository modify service MUST implement authenticated access.
-
- The BindResponse subsets needed are the same as those described in
- Section 5.1.2.
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 7]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
-7.2. Modify
-
-7.2.1. Modify Request
-
- The full LDAPv2 ModifyRequest is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the following subset of the ModifyRequest protocol unit.
-
- ModifyRequest ::=
- [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1)
- },
- modification SEQUENCE {
- type AttributeType,
- values SET OF
- AttributeValue
- }
- }
- }
-
- All aspects of the ModifyRequest MUST be supported, except for the
- following:
-
- - Only the add and delete values of operation need to be supported
-
-7.2.2. Modify Response
-
- The full LDAPv2 ModifyResponse is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the full ModifyResponse.
-
-7.3. Add
-
-7.3.1. Add Request
-
- The full LDAPv2 AddRequest is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the full AddRequest.
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 8]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
-7.3.2. Add Response
-
- The full LDAPv2 AddResponse is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the full AddResponse.
-
-7.4. Delete
-
-7.4.1. Delete Request
-
- The full LDAPv2 DelRequest is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the full DelRequest.
-
-7.4.2. Delete Response
-
- The full LDAPv2 DelResponse is defined in RFC 1777.
-
- An application providing a LDAP repository modify service MUST
- implement the full DelResponse.
-
-7.5. Unbind
-
- An application providing a LDAP repository modify service MUST
- implement the full UnbindRequest.
-
-8. Non-standard attribute value encodings
-
- When conveyed in LDAP requests and results, attributes defined in
- X.500 are to be encoded using string representations defined in RFC
- 1778, The String Representation of Standard Attribute Syntaxes.
- These string encodings were based on the attribute definitions from
- X.500(1988). Thus, the string representations of the PKI information
- elements are for version 1 certificates and version 1 revocation
- lists. Since this specification uses version 3 certificates and
- version 2 revocation lists, as defined in X.509(1997), the RFC 1778
- string encoding of these attributes is inappropriate.
-
- For this reason, these attributes MUST be encoded using a syntax
- similar to the syntax "Undefined" from section 2.1 of RFC 1778:
- values of these attributes are encoded as if they were values of type
- "OCTET STRING", with the string value of the encoding being the DER-
- encoding of the value itself. For example, when writing a
- userCertificate to the repository, the CA generates a DER-encoding of
- the certificate and uses that encoding as the value of the
- userCertificate attribute in the LDAP Modify request.This encoding
-
-
-
-Boeyen, et al. Standards Track [Page 9]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
- style is consistent with the encoding scheme proposed for LDAPv3,
- which is now being defined within the IETF.
-
- Note that certificates and revocation lists will be transferred using
- this mechanism rather than the string encodings in RFC 1778 and
- client systems which do not understand this encoding may experience
- problems with these attributes.
-
-9. Transport
-
- An application providing a LDAP repository read service, LDAP
- repository search service, or LDAP repository modify service MUST
- support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
- 1777.
-
- An application providing a LDAP repository read service, LDAP
- repository search service, or LDAP repository modify service MAY
- support LDAPv2 transport over other reliable transports as well.
-
-10. Security Considerations
-
- Since the elements of information which are key to the PKI service
- (certificates and CRLs) are both digitally signed pieces of
- information, additional integrity service is NOT REQUIRED. As
- neither information element need be kept secret and anonymous access
- to such information, for retrieval purposes is generally acceptable,
- privacy service is NOT REQUIRED for information retrieval requests.
-
- CAs have additional requirements, including modification of PKI
- information. Simple authentication alone is not sufficient for these
- purposes. It is RECOMMENDED that some stronger means of
- authentication and/or (if simple authentication is used) some means
- of protecting the privacy of the password is used, (e.g. accept
- modifications only via physically secure networks, use IPsec, use SSH
- or TLS or SSL tunnel). Without such authentication, it is possible
- that a denial-of-service attack could occur where the attacker
- replaces valid certificates with bogus ones.
-
- For the LDAP repository modify service, profiled in section 7, there
- are some specific security considerations with respect to access
- control. These controls apply to a repository which is under the same
- management control as the CA. Organizations operating directories are
- NOT REQUIRED to provide external CAs access permission to their
- directories.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 10]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
- The CA MUST have access control permissions allowing it to:
-
- For CA entries:
- - add, modify and delete all PKI attributes for its own
- directory entry;
- - add, modify and delete all values of these attributes.
-
- For CRL distribution point entries (if used):
- - create, modify and delete entries of object class
- cRLDistributionPoint immediately subordinate to its own
- entry;
- - add, modify and delete all attributes, and all values of
- these attributes for these entries.
-
- For subscriber (end-entity) entries:
- - add, modify and delete the attribute userCertificate and all
- values of that attribute, issued by this CA to/from these
- entries.
-
- The CA is the ONLY entity with these permissions.
-
- An application providing LDAP repository read, LDAP repository
- search, or LDAP repository modify service as defined in this
- specification is NOT REQUIRED to implement any additional security
- features other than those described herein, however an implementation
- SHOULD do so.
-
-11. References
-
- [1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, March 1995.
-
- [2] Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
- Representation of Standard Attribute Syntaxes", RFC 1778, March
- 1995.
-
- [3] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 11]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
-12. Authors' Addresses
-
- Sharon Boeyen
- Entrust Technologies Limited
- 750 Heron Road
- Ottawa, Ontario
- Canada K1V 1A7
-
- EMail: sharon.boeyen@entrust.com
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- EMail: howes@netscape.com
-
-
- Patrick Richard
- Xcert Software Inc.
- Suite 1001, 701 W. Georgia Street
- P.O. Box 10145
- Pacific Centre
- Vancouver, B.C.
- Canada V7Y 1C6
-
- EMail: patr@xcert.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 12]
-\f
-RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 13]
-\f
projects / openldap / commitdiff