I should have put my remarks in a double set of parentheses, to avoid jerking
everyone's chain. But just to rise to the bait, assuming that a document is
given a reasonable name, perhaps c=US, o=Certificates R Us,
cAPolicyUrl=http:// ... I see no reason for the document name, and hence the
DN, to ever have to change. The URL can then be changed as required to point
to the current location of the document. Am I missing something obvious?
The thing you're missing is the operational reality of X.500. The primary
problem with X.500 is that it requires careful planning to deploy properly. And
like it or not, people simply won't sit down and plan these things out properly
from the start. Small company or large, seasoned network professionals or
neophytes, access to experience consultants or not, they just won't do it. So
they end up having to change their setup around -- often not once but several
times. And the DNs change when this happens. Sometimes its possible to
implement a transition plan where old names remain valid, but often there
aren't adequate resources for such schemes. And even when a transition plan is
possible it goes away eventualy, leaving dangling pointers out there.
As for your example, it happens to be a perfect illustration of how these
things can go wrong. You gave a DN of the form C=US, o=whatever, ... Looks
reasonable, right? Trouble is, you're not allowed to register as an
organization under C=US without some sort of special national standing.
Organizational entries are properly made one level down, under the various
state registries. So, for most companies, it ends up as something like c=US,
st=CA, o=Certificates R Us, etc.
This happens to be a very common mistake people actually make. People implement
X.500 internally and don't put the proper state field in all their DNs. Then,
when they decide to register their setup as part of the Internet White pages
project, they have to change the whole thing around. This can be a nightmare to
fix.
As a matter of fact this particular problem is so bad that we're now seeing
cases of DUAs (usually written outside the US, but not always) that refuse to
traverse the state links used in the US! These DUAs end up being completely
incapable of seeing most US organizational entities. And this isn't a single
error made by a single company either. I know its hard to imagine such a
mistake actually making it out into released products, but it has.
X.500 is very complex. Deploying it correctly isn't easy, and unfortunately
most X.500 packages provide you with absolutely no assistance beyond a litany
of overly simplistic configuration scripts and incomplete or incorrect command
documentation. Elementary mistakes are very common, to say nothing of more
complex structuring errors. And so much energy is consumed getting things
working that there's none left over for planning.
Bob, this happens to be something I know a lot about. As I said before, my
company sells X.500 products -- we sell a DSA for VMS systems now (Digital UNIX
support is coming soon) and we include DUA support in our email software. We
went into this area with a reasonable awareness of what we were getting into,
and we labored mightily over our initial documentation and configuration
mechanisms in an attempt to make it easy for customers to set up and configure
the damn thing. We try as much as possible to lead people to build good, stable
setups. And to a certain extent we think we succeeded -- we appear to have kept
the number of egregious errors to a minimum. And in the process we've learned a
lot -- we basically rewrote much of our documentation for our second release,
and I expect we'll do it again for the third.
But even so, events are conspiring against us. I expect our next release to
include full X.500-1993 support, and that adds lots more complexity. The area I
worry about most is access control -- the QUIPU-derived access control
mechanisms we use now are going to change in lots of ways, and the new stuff is
much more complicated. I doubt that we can ever present this in a completely
coherent fashion. Its just too messy for that.
There are also a number of so-called "expert consultants" in this area who
actually don't know their ass from first base. Needless to say, the results
can be dreadful if you end up with one of them.
BTW, I agree that with prudent planning, it should be possible to create a
Domain Name that is used to indicate the always stable name for a file server
that would contain such information. My experience is that people tend to load
up such servers with lots of different files, all under the common, stable
name, and then suddenly the files won't fit anymore and some people have to
change the name of the file server, leaving previously valid URLs invalid.
You're absolutely right -- this does happen sometimes. However, what makes you
think DNs offer any sort of solution? People make exactly the same mistakes
with X.500 service deployment all the time. In fact my experience tells me that
the complexity of X.500 leads to these sorts of mistakes being made much more
often than with DNS-based services.
It's not that the problem can't be solved, e.g., with linked URLs. It's just
that most of the time it _isn't_ addressed until it is too late. Human nature,
I suppose.
Human nature is the key, and its something we don't spend enough time
considering. This was the major point behind my objections to S/MIME.
However, present-day URLs for the most part are pretty simple. And
simplicity is good thing since it tends to align well with human nature.
This gives them a huge leg up on DNs from the start.
Ned