From: Kurt Zeilenga Date: Thu, 20 Dec 2001 18:20:34 +0000 (+0000) Subject: Zap RFCs being moved to Historical status X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~589 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=6905533757ef2b9753a4c86ef563ef029832e192;p=openldap Zap RFCs being moved to Historical status --- diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index 3c976896c8..445c10e626 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -1,19 +1,13 @@ 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) @@ -31,7 +25,6 @@ rfc2293.txt Tables and Subtrees in the X.500 Directory (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) diff --git a/doc/rfc/rfc1275.txt b/doc/rfc/rfc1275.txt deleted file mode 100644 index 488b3a0f24..0000000000 --- a/doc/rfc/rfc1275.txt +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - -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. - - - - -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 - - - - -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 - - - - -RFC 1275 Replication Requirements November 1991 - - - Phone: +44-71-380-7294 - - EMail: S.Kille@CS.UCL.AC.UK - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardcastle-Kille Page 3 - diff --git a/doc/rfc/rfc1777.txt b/doc/rfc/rfc1777.txt deleted file mode 100644 index f5593e72a2..0000000000 --- a/doc/rfc/rfc1777.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -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] - -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] - -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] - -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 - - ::= - - ::= - - where and 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/rfc/rfc1778.txt b/doc/rfc/rfc1778.txt deleted file mode 100644 index 7d99b029d8..0000000000 --- a/doc/rfc/rfc1778.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -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] - -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' | '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' - - ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' - - ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | - 'A' | 'B' | 'C' | 'D' | 'E' | 'F' - - ::= | | '-' - -

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | - '/' | ':' | '?' | ' ' - - ::= The ASCII newline character with hexadecimal value 0x0A - - ::= | - - ::= | - - ::= | - - ::= | - - ::=

|

- - ::= ' ' | ' ' - -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] - -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: - - ::= | - '$' - - ::= a string encoded according to the rules for Case - Ignore String as above. - - - - - - -Howes, Kille, Yeong & Robbins [Page 3] - -RFC 1778 Syntax Encoding March 1995 - - -2.11. Case Exact List - - Values of type caseExactListSyntax are encoded according to the - following BNF: - - ::= | - '$' - - ::= 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: - - ::= "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: - - ::= | '.' | - - ::= - - ::= | '.' - - In the above BNF, 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] - -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: - - ::= '$' '$' - - ::= - - ::= - - ::= - - In the above, is the syntactic representation of the - number portion of the TELEX number being encoded, is the - TELEX country code, and is the answerback code of a - TELEX terminal. - -2.18. Teletex Terminal Identifier - - Values of type teletexTerminalIdentifier are encoded according to the - following BNF: - - ::= 0*('$' ) - - ::= ':' - - ::= 'graphic' | 'control' | 'misc' | 'page' | 'private' - - ::= - - In the above, the first is the encoding of the - first portion of the teletex terminal identifier to be encoded, and - the subsequent 0 or more are subsequent portions - of the teletex terminal identifier. - - - - -Howes, Kille, Yeong & Robbins [Page 5] - -RFC 1778 Syntax Encoding March 1995 - - -2.19. Facsimile Telephone Number - - Values of type FacsimileTelephoneNumber are encoded according to the - following BNF: - - ::= [ '$' ] - - ::= | '$' - - ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | - 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' - - In the above, the first is the actual fax number, - and the 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: - - ::= [ '#' ] - - ::= an encoded value of type objectIdentifierSyntax - - ::= | | '!' - - ::= [ '(' ] '&' [ ')' ] | - [ '(' ] '|' [ ')' ] - - ::= [ '(' ] '$' [ ')' ] - - ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" - - - - - - - - - -Howes, Kille, Yeong & Robbins [Page 6] - -RFC 1778 Syntax Encoding March 1995 - - -2.23. Postal Address - - Values of type PostalAddress are encoded according to the following - BNF: - - ::= | '$' - - In the above, each 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: - - ::= '#' '#' - '#' '#' '#' - '#' '#' - - ::= - - ::= - - ::= - - ::= an encoded Distinguished Name - - ::= '#' - - ::= - - ::= - - ::= | | - '{ASN}' - - ::= an encoded Distinguished Name - - ::= '#' - - ::= | '-' - - ::= '#' - - - -Howes, Kille, Yeong & Robbins [Page 7] - -RFC 1778 Syntax Encoding March 1995 - - - ::= an encoded UTCTime value - - ::= | - -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: - - ::= '#' '#' - [ '#' ] - '#' - '#' - - ::= 1*( '#' ) - '#' - - ::= '#' '#' - '#' - - The syntactic components , , - , , and 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: - - ::= '#' - | - | - - ::= 'forward:' - - ::= 'reverse:' - - - - -Howes, Kille, Yeong & Robbins [Page 8] - -RFC 1778 Syntax Encoding March 1995 - - - The syntactic component 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: - - ::= | '$' - - ::= '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: - - ::= '$' - - ::= an encoded Printable String - - ::= an encoded IA5 String - - In the above, represents the type of mail system in - which the mailbox resides, for example "Internet" or "MCIMail"; and - is the actual mailbox in the mail system defined by - . - -2.32. Mail Preference - - Values of type mailPreferenceOption are encoded according to the - following BNF: - - ::= "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] - -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: - - ::= ':' - | ':' - - ::= 'group_member' - - ::= - - ::= an encoded Distinguished Name - - ::= 'individual' | 'dl_member' | 'pattern' - - ::= - - ::=

'#' - |
- -
::= ':' - - ::= ':' - - = 'X400' - - = 'X500' - - where 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] - -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] - -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] - diff --git a/doc/rfc/rfc1779.txt b/doc/rfc/rfc1779.txt deleted file mode 100644 index b4eba851bb..0000000000 --- a/doc/rfc/rfc1779.txt +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - -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] - -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] - -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 . 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] - -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 """ , , "<", - ">", "#", 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] - -RFC 1779 DN Representation March 1995 - - - ::= ( ) - | - - ::= - - - - ::= "," | ";" - - ::= ( ) *( " " ) - - ::= - | "+" - - - ::= - | "=" - - ::= 1*( ) | "OID." | "oid." - ::= letters, numbers, and space - - ::= | "." - ::= 1* - ::= digits 0-9 - - ::= *( | ) - | '"' *( | | ) '"' - | "#" - - - ::= "," | "=" | | "+" | "<" | ">" - | "#" | ";" - - ::= "\" ( | "\" | '"') - ::= any character except or "\" or '"' - - - ::= 2* - ::= 0-9, a-f, A-F - - - - Figure 1: BNF Grammar for Distinguished Name - - - - - - - - -Kille [Page 5] - -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] - -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] - -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] - - - - diff --git a/doc/rfc/rfc1781.txt b/doc/rfc/rfc1781.txt deleted file mode 100644 index 864698edd7..0000000000 --- a/doc/rfc/rfc1781.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/rfc/rfc1960.txt b/doc/rfc/rfc1960.txt deleted file mode 100644 index 8e09abdd12..0000000000 --- a/doc/rfc/rfc1960.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -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] - -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. - - ::= '(' ')' - ::= | | | - ::= '&' - ::= '|' - ::= '!' - ::= | - ::= | | - ::= - ::= | | | - ::= '=' - ::= '~=' - ::= '>=' - ::= '<=' - ::= '=*' - ::= '=' - ::= NULL | - ::= '*' - ::= NULL | '*' - ::= NULL | - - is a string representing an AttributeType, and has the format - defined in [1]. is a string representing an AttributeValue, - or part of one, and has the form defined in [2]. If a 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] - -RFC 1960 LDAP Search Filters June 1996 - - - Note that although both the and 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] - diff --git a/doc/rfc/rfc2559.txt b/doc/rfc/rfc2559.txt deleted file mode 100644 index 3768a2a822..0000000000 --- a/doc/rfc/rfc2559.txt +++ /dev/null @@ -1,731 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] -