Below, I have put together a set of statements taken directly from
X.500-521. People should not just read what I have taken out of X.500-521 but
instead use the information I point out to guide you through your own
investigation of the Directory. To aid in this effort I have appended the
recommendation number before every paragraph number.
________________________________________________________________________________
Definitions DIT elements
/------------------\ rules for --------------
| DIT structure |------------------------------->| DIT |
\------------------/ --------------
| ^
uses | belongs to |
v |
/------------------\ rules for --------------
| Object class |------------------------------->| Entries |
\------------------/ --------------
| ^
uses | belongs to |
v |
/------------------\ rules for --------------
| Attribute type |------------------------------->| Attributes |
\------------------/ --------------
| ^
uses | belongs to |
v |
/------------------\ rules for --------------
| Attribute Syntax |------------------------------->| Values |
\------------------/ --------------
T0704350-88
FIGURE 5/X.501
Overview of Directory schema
X.501-9.3.2 The Directory permits an entry to stand in the relationship of
immediate suborinate to another (its immediate superior) only if there exists a
DIT Structure definition, contained in the schema (see 9.2.3) applicable to the
portion of the DIB that would contain the entry, for which:
- the entry is of the subordinate object class;
- the immediate superior of the entry is of the superior object
class;
- the attribute type(s) forming the entry's RDN is (are) among
those permitted;
and
- any conditions imposed by the additional information set
element are satisfied.
Note 1 - Techniques for documenting DIT Structure or for representing
structure rules in the DIB are not presently provided by this series of
Recommendations.
Note 2 - If a DIT Structure Rule permits subordinate or superiors
belonging to a particular class, it implicitly (unless explicitly overridden)
also allows subordinates or superiors belonging to any object class derived from
that class (see 9.4)
X.501-9.4.3 Every entry shall contain an attribute of type ObjectClass to
identify the object class and superclasses to which the entry belongs. The
definition of this attribute is given in 9.5.4. The attribute is multivalued.
There shall be one value of the attribute for the object class and each of its
superclasses for which an object identifier is defined, except that the value of
"Top" need not be present so long as some other value is present.
Note 1 - The requirement that the ObjectClass attribute be present in
every entry is reflected in the definition of "Top".
Note 2 - Because an object class is considered to belong to all its
superclasses, each member of the chain of superclasses up to Top is represented
by a value in the object class attribute (and any value in the chain may be
matched by a filter).
The ObjectClass attribute is managed by the Directory, i.e. it may not
be modified by the user.
X.501-9.4.4 The Directory enforces the defined object class for every entry in
the DIB. Any attemp to modify an entry that would violate the entry's object
class definition fails.
Note - In partuicular, the Directory will prevent:
a) attribute types absent from the object class definition being
added to an entry of that object class;
b) an entry being created with one or more absent mandator
attributes types for the object class of the entry;
c) a mandatory attribute type for the object class of the entry
being deleted.
X.501-8.3.1 Each entry has a unique relative distinguished name (RDN). An RDN
consists of a set of attribute value assertions, each of which is true,
concerning the distinguished values of the entry.
RelativeDistinguishedName ::=
SET OF AttributeValueAssertion
The set contains exactly one assertion about each distinguished value
in the entry.
X.520-1.2.1 Some attribute types (syntaxes) are used by a wide variety of
applications or are understood and/or used by the Directory itself.
Note - It is recommended that an attribute type (syntax) defined in
this document be used, in preference to the generation of a new one, whenever it
is appropriate for the application.
X.520-1.2.2 Some attribute types (syntaxes) are internationally-standardized,
but are application-specific. These are defined in the standards associated
with the application concerned.
X.520-1.2.3 Any administrative authority can define its own attribute types
(syntaxes) for any purpose. These are not internationally standardized, and are
available to others beyond the administrative authority which created them only
by bilateral agreement.
X.520-5.11.2 User Certificate
userCertificate UserCertificate
::= {attributeType 36}
X.520-5.11.3 CA Certificate
cACertificate CACertificate
::= {attributeType 37}
X.521-1.2 Any Administrative Authority can define its own object classes and
subclasses for any purpose.
Note 1 - These definitions may or may not use the notation specified in
Recommendation X.501.
Note 2 - It is recommended that an object class defined in this
document, or a subclass derived from one, be used in preference to the
generation of a new one, whenever the semantics is appropriate for the
application.
X.521-1.3 Administrative authorities shall support some or all the selected
objects classes, and may also add object classes.
All Administrative authorities shall support the object classes which
the directory uses for its own purpose (the top, alias and DSA object classes).
X.521-6.16 Strong Authentication User
The Strong Authentication User object class is used in defining entries
for objects which participate in strong authentication, as defined in
Recommendation X.509.
strongAuthenticationUser OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {userCertificate}
::={objectClass 15}
X.521-6.17 Certification Authority
The Certification Authority object class is used in defining entries
for objects which act as certification authorities, as defined in Recommendation
X.509.
certificationAuthority OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
cACertificate,
certificateRevocationList,
authorityRevocationList}
MAY CONTAIN {crossCertificatePair}
::= {objectClass 16}
________________________________________________________________________________
Again I encourage everyone to do their own investigation and come to
their own conclusions. After doing so I suggest continuing reading this letter
for my conclusion.
In putting this list together I have concluded that what I have stated in the
past is accurate except for my first letter were I redefined
certificationAuthority. But, I'm still open to concrete evidence stating
otherwise.
Item 1: X.501-9.3.2 this section itself is not that significant except for the
notes. It is my belief it is a result of this part of the recommendation not
being complete which is a significant factor in the current misunderstandings.
With out this section you have practically no global means of ensuring schema
integrity.
Item 2: X.501-9.4.3 and X.501-9.4.4 implies to me that every entry is defined by
a specific objectClass. You may have to look at other objectClass's because of
subordinate relationships but it is still the one objectClass that defines the
entry.
Item 3: X.501-8.3.1 implies to me that every entry has a RDN and that for any
RDN in a DN their must exist an Entry in the DIT.
Item 4: Item 2 and Item 3 together implies to me that for every RDN in a DN
there must be defined at least one ObjectClass containing the RDN attribute.
Item 5: X.520-1.2.1, X.520-1.2.2 and X.520-1.2.3 all of this just implies to me
that if PEM needs to define additional attributes it should do so. But, when
ever possible it should use existing attributes like X.520-5.11.2 and X.520-
5.11.3.
Item 6: X.521-1.2 and X.521-1.3 all of this just implies to me that if PEM needs
to define additional objectClass's it should do so. But, when ever possible it
should use existing objectClasses like X.521-6.16 and X.521-6.17.
Item 7: X.521-6.16 and X.521-6.17 along with Item 2 implies that these things
would be distinct entries in the DIT.
Item 8: Scan through the ASN.1 notation for X.521 and convince your self that
the only objectClasses that use X.520-5.11.2 and X.520-5.11.3 are X.521-6.16 and
X.521-6.17. This is only 4 pages long in my book and should only take you a few
seconds to verify.
The significance of all this is potentially much farther reaching than
PEM but to focus on issues lets look at what this means to PEM.
Assumption that I will make for the following is that PEM does not define any
attributes or objectClasses.
The most significant items for PEM are Item 7 and 8. Because of these items
currently the only way any entry in the directory can have a certificate
associated with it is by using X.521-6.16 and X.521-6.17. Nothing else has been
defined. I believe the PEM community should give this concept of certificates
being entries beneath other entries some serious thought. It is not clear that
doing business this way improves or worsens the name subordination issues. But,
X.500 clearly thinks this is the way to go and I think it would be worth the
effort to find out why. Everything I have stated does not mean PEM can not do
things the way things are currently suggested. If PEM uses ou="" as the entry
with a certificate PEM must define a new objectClass for this entry. Currently
the only object class defined that uses the ou attribute does not have a
certificate attribute.
With all of the above information I highly recommend people look at
my second letter again.