I have had trouble deciding just how I would do a directory search
myself, but I have never heard that I need to know an entity's entire DN
in order to find him in a directory.
The entire DN is not necessary. That seems to be an unnatural limitation on a
directory.
This is not the case and I never said it was. It certainly would be an
unnatural limitation if it were true!
Is it not the case that a directory search
could be performed with a limited set of AVA's (some distinguished and
some not) and then return multiple entries?
Sure. But you haven't already you really should try some of these things
sometime -- if you do you will find that there are all sorts of interesting
inconsistencies that make the directory a lot harder to navigate than it should
be. And I'm talking about the (very limited) white pages project directory
here, where everyone is for the most part using the same set of schema in a
fairly consistent fashion, and everyone's hierarchies are fairly consistent as
well.
The bottom line is that these tools have a long way to go before they'll be
novice-friendly even in an environment where the schema and hierarchies are
fairly consistent. And all bets are off in the larger picture.
I think the NADF is addressing these issues. Whether or not the directories of
the world will abide by their rules is another story.
I thought the question being discussed in the current thread was the
construction of a DN. How could that have any effect on the "structural
differences in directory schema"? If I wish to make a assertion about
myself, there is no reason that I can imagine for a directory to prevent
that. I am much more worried about the assertions a directory makes
about me without my knowledge. (I noticed telephone number, what about
salary?)
The construction of DNs impacts the ability to search directories in a direct
and obvious fashion -- typically you search on pieces of the DN, and the
further off your DN structure is from the search scoping the more expensive the
search becomes. And when the hierarchy is really screwy (again, you should try
some of the existing servers -- I don't want to name names but there is some
pretty strange stuff out there) it makes things fairly intractable.
Consistency in schema usage is very important when it comes to "making
assertions about myself". At issue is what the various attributes actually
mean: which certificate should be used for mail (if there is more than one),
which ID # is the right one, which is the daytime work phone number (out of the
5 phone numbers listed) and on and on and on.
Things like salary don't worry me as much simply because they will be protected
from public access (unless someone is really crazy or foolish). Semantic
consistency of fields that are used privately is pretty much a non-issue,
although I agre that it is tough to decide where to draw the line between pubic
and private use.
Well now, if I can't trust the directory, I guess that means that CA's
and their entire trust structure are not a transient necessity, but a
permanent fixture in trusted communications! Prior to this I had
thought that the CA hierarchy would go away, once X.500 reached its full
glory.
You'd have to define "full glory" here. I suspect that most X.500 deployment
will be without the security infrastructure for a while. Security will be added
later, and will probably never be universal. This means you won't be able to
trust what you get without checking it out. And even if it checks out, all that
means is that the certificate is valid -- it doesn't mean that you have the
right certificate for your purposes.
Ned