X.500 Standard status
(Implementors' Guide)

X.509 Related activities

How to be involved

More Information

Tutorial section 1
X.500 General

Tutorial section 2
X.509 specific

Other PKI organizations

edit SideBar

Search

Directory Attributes

Directory Entry Model
Figure 1 - Directory entry structure

The figure above shows the directory entry model. An entry holds a number of attributes each holding some particular piece of information. The type of information held by an attribute is indicated by the attribute type field within the attribute. The actual information is held by one or more attribute values.

As an example, attribute type may be "telephone number", and an attribute of this type will then hold one or more telephone numbers.

A DSA storing an attribute in some entry or a DUA retrieving that attribute needs to have a pretty good understanding of the attribute type. Based on the attribute type identification and its knowledge about the attribute type in question, a DUA or a DSA knows, as an example, what syntax the attribute value or values have. Without knowing the syntax, the values are just unstructured strings of bits. It is therefore necessary to clearly define all attribute types and make such specifications available to DUAs and DSAs.

The recognised way to specify an attribute type is to use a so-called information object class as defined by the newest version of ASN.1. The definition of the telephone number attribute type discussed above is shown here as an example:

telephoneNumber ATTRIBUTE ::= {
    WITH SYNTAX               PrintableString
        (SIZE (1..ub-telephone-number))
    EQUALITY MATCHING RULE    telephoneNumberMatch
    SUBSTRINGS MATCHING RULE  telephoneNumberSubstringsMatch
    SINGLE VALUE              FALSE
    ID                        id-at-telephoneNumber }

Attribute types form one particular ASN.1 information object class (don't confuse with Directory object classes - we have some clash of terminology). This information object concept is not that straightforward and has given somewhat complex specifications, although they are quite simple in nature. It is not necessary to understand the concept of information object classes. Just consider the specification as a shorthand notation and do not try to understand all the philosophy behind the specification method.

The label (the telephoneNumber in the example) is a so-called object reference, which is a unique identification of the type of information object to be defined, i.e. it is unique within some particular environment. Ideally, it is globally unique, but there is no procedure in place to ensure that.

The telephone number itself in the example above has, according to its specification, to be encoded using the PrintableString syntax, i.e. it is encoded using a rather simple character set.

Under certain conditions, like when doing a Search operation, it is necessary to compare the attribute value(s) with some other value. Rules for such comparisons are called matching rules. Matching rules are separately defined. Two such matching rules are here referred to as part of the attribute type definition. The first one (telephoneNumberMatch) specifies what makes two telephone numbers equal. This rule specifies that possible spaces and hyphens ("-") shall be removed before a comparison. As an example, the telephone number 31 23 04 90 is equal to 31-230490. The telephoneNumberSubstringMatch is a similar rule, where only a part of a telephone number is compared against the attribute value(s).

Most attributes, as illustrated in the figure above, may have several values. This is the case for the telephoneNumber attribute type. However, in some cases it does not make sense for an attribute type to allow several values. As an example, the attribute type countryName can only have a single value. Setting the SINGLE VALUE to TRUE in the attribute type definition indicates that only a single value is allowed. In the telephoneNumber example it is set to FALSE. As FALSE is default, the SINGLE VALUE specification is normally left out for multi-valued attribute types.

The last part of the specification above is a so-called ASN.1 object identifier that uniquely identifies the attribute type. This object identifier is occupying the "attribute type" field. id-at-telephoneNumber is a reference to the value itself, which, by the way, is equal to { 2 5 4 20 }.

The actual structure of an attribute as it is transmitted between systems is given by the following ASN.1 construct:

Attribute ::= SEQUENCE {
    type     AttributeType ({ SupportedAttributes }),
    values   SET SIZE (0..MAX) OF AttributeValue
        ({SupportedAttributes}{@type})}

Note - The above construct is simplified not including the contexts specifications. This specification says that an attribute is a sequence of an object identifier and a set of values, where the values may be in any order.

The Attribute specification consists of the type and the values components, which means that an attribute is a sequence of a type definition and a set of values. ''' AttributeType in the specification above is synonymously with an object identifier, but is not just any object identifier. It is an object identifier that has been allocated as part of the attribute type definition. The ({ SupportedAttributes }) specification is a so-called constraint that indicates that the attribute types must be a member of the attribute type set that is supported. This set is normally defined as an indefinite set. The values component seems somewhat complicated. The ASN.1 construct SET OF''' says that it is a set of values. It is an unordered set. There is no garantie that a DSA will store or transmit values in the same order as used when adding the values.

The SIZE (0..MAX) specifies that the number of values can be from zero up to some unspecified limit. An attribute has always at least one value. However, there are cases where an empty set is returned, as an example, if an accessing user is not granted access to any of the values of an attribute.

The {@type} specifies that the values shall be of the type determined by the type component. The { SupportedAttributes } specifies once more that this type must be among a set of supported attribute types.

A receiving system (DSA or DUA) identifies the attribute type by recognising the object identifier in the type component. A receiving system needs to have some pre-knowledge about what specifications are behind a particular attribute type. As an example, when a telephoneNumber attribute is sent to a DUA, the DUA must recognise the object identifier in order to display the telephone number(s) in a user-friendly way.

The Directory standard has defined a number of attribute types that are assumed to be general useable.

Page Actions

Recent Changes

Group & Page

Back Links