Steve,
Your bringing together two different threads force me to articulate my
position vs. X.500. The "CA/PCA" reports were derived from practical
experience within the Password project, where we do use X.500 + have
interconnected the partners' X.500 servers - I genuinely reported experimental
evidence. This is completely independant from my opinion on X.500. The general
objection I have against X.500 is the mixing of "natural naming" and
"hierarchical structure". To put it shortly, I believe that hierarchical data
bases have obvious advantages in terms of managing distribution, but are only
acceptable if you can "chose your key", i.e. insert your data at the point of
the hierarchy that you see fit. This allows competition between providers as
well as flexibility in the organization.
Using natural naming has different advantages - essentially your argument that
if the name is "natural" you "know" whom you are speaking to, while if the
string is random you have no clue and must use other channels to identify your
partner. Apart from being sort of heavyweight, the natural names have another
characteristic: they are pre-determined. If your company is registered in
Cambridge, MA, then it should be inserted in the X.500 hierarchy at precisely
that place, which induce a geopolitical monopoly - IMHO unacceptable. Which is
why I believe that natural names are unfit as "access keys" in a hierarchical
data base. In the particular case of X.500, this combines with problems for
non hierarchical searches, and the general heaviness of the protocol. On
the other hand, several people hold contrary opinions and think that X.500 is
great..
Indeed, if we were to publicly admit that we don't care much about X.500 per
se but merely keep it for compatibility with the previous versions of PEM, I
will have to admit that we can certainly pick whatever name type we see fit
for identifying users, CAs and PCAs.
Christian Huitema