X.500
The X.500 specification is the first Lightweight Directory Access Protocol (LDAP) described in RFC 1487 in 1993 ( http://www.ietf.org/rfc/rfc1487.txt ). The X.500 has even been described as being a mechanism derived from Domain Names in RFC 1279 in 1991 ( http://www.ietf.org/rfc/rfc1279.txt ). I have heard many times that X.500 and LDAP need not be used for security storage, but I wish to qualify that the X.500 protocol is always used for security structures, including X.509. Although the X.500 is built into protocols and specifications like X.509, an LDAP service may not be required to store the information. The point is that there is a protocol built into the digital certificates, but using servers to manage the X.500 protocol (called LDAP servers) is optional. For those organizations that do not use an LDAP server, the certificates should be stored in a file structure or Relational Database System using the X.500 protocol to define the storage. A distinguished nameThe reason that the X.500 protocol is used is because it defines a distinguished name (DN) that is unique to the issuer and subject. The DN is also used to define where to store the certificate because it is unique and can define a path down a tree-like store using the DN fields.
The X.500 directory is made up of entries distributed across a family of servers. Each entry has attributes. An example of an entry is the user Rich Helton and attributes are his address, telephone number, and credit card. The attribute value could be 333-333-3333 for the telephone number attribute. In short, an entry can be represented as an object, and the attributes are the fields in the object. An Access Control List (ACL) can be used to provide security for the attributes of an entry ( http://www.ietf.org/rfc/rfc1309.txt ). This would prevent others from accessing information such as credit card numbers . Directory Information BaseThe totality of an organization's information in the X.500 protocol is called the Directory Information Base (DIB). The entries are organized in a tree structure. Entries higher in the tree describe objects such as countries or organizations, while entries at the bottom of the tree ( leaves ) describe the people, equipment, or processes. An entry below any node is called a child . Every entry contains a set of attributes. The attributes depend on the class of the entry, such as country, organization, or organizational person. The object class determines the types of attribute values that you might expect to find in an entry. There usually will be a small number of mandatory attributes for an entry and a larger number of optional attributes that may be present. Figure 25-3 represents an example of a DIB. The example demonstrates a tree structure that represents the DNs of certificates, and the attributes at the bottom nodes represent the stored certificates. The distinguished name is made up of components such as country, organization, organizational unit, and personal name. Alias names may also be used to make lookups easier, but searches are normally a path down the tree structure to the end object of the lookup. Sometimes it is necessary to take actions on an entire node. An example of cascading a node is a node that starts with a "development" group . When a product moves to production after the development effort, the access to the servers and databases might have to change. In the X.500 protocol, only the connecting leaf node needs to change.  Figure 25-3: An X.500 DIB Figure 25-4 demonstrates a "Development" node that needs to be traversed to reach all of the developers, Developer1, Developer2, Developer3, and Developer4. Instead of changing the attributes of all the developers, the Development node's attribute could be changed to no longer have access to the production machines, thus blocking all developers without changing each developer.  Figure 25-4: OU removal This specific scenario is an example of a group. A group applies the same properties to a set of users. To be certain that this is clear, the DIB is the namespace to all of the objects that are listed in the tree. The organization of the tree itself is a Directory Information Tree (DIT). The DIB is distributed across a community of databases that are controlled by Directory Service Agents (DSAs). Users access directory information by means of a Directory User Agent (DUA). A DUA provides the user interface for interactive queries and updates and passes user requests to a DSA. The X.500 standard defines a formal protocol that governs the interactions between a DUA and a DSA. There also is a DSA-to-DSA protocol that enables DSAs to relay user queries or download copies of parts of the DIB. Even if a particular DSA does not have the information a user wants, it will know about other servers that might have the data. A DSA may either pass the address of another server to the DUA, or else may directly contact another server to get the information requested by the user. See Figure 25-5 for a relationship between the user, the DUA, and DSAs.  Figure 25-5: DUA As mentioned before when describing RFC 1279, there are a number of structural similarities between the X.500 directory system and the Domain Name System (DNS). Actually, it could be said that DNS evolved into X.500 on the Internet when a tree structure was needed to provide a path and relationships to multiple objects. Both the X.500 and DNS are distributed directory systems. Users of each interact with a local client to reach a designated server, and that server can initiate distributed queries on behalf of the user. X.500 databases are expected to include information that helps users to locate network resources. A user must be able to perform the following operations:
The X.500 protocol was widely accepted as a format for managing systems, but very few servers were developed explicitly for the X.500 protocol. The reason is that the protocol was defined well, but there was no specification defining the Software Development Kit (SDK) for the protocol and many of the details for the communications of the client and server. For these reasons, an RFC was developed in 1995 to extend the X.500 as a version 2, RFC 1777 ( http://www.ietf.org/rfc/rfc1777.txt ), called " Lightweight Directory Access Protocol ," commonly known as LDAP.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
