Steve,
With respect to not hearing any reasons to avoid X.500, I would say
our experience has not been positive:
o Very complicated and opaque documentation.
o Not available online.
o Incomplete answers to simple questions, e.g. the role of RDNs, AVAs,
etc.
o No agreement on what OIDs exist, nor on how to introduce new ones.
o No mechanisms for specifying the legal set of values for an OID.
o Etc.
I'm smiling a bit, because most of those criticisms would hit pretty close to
home for most of us.
PEM, MIME, X9.30, X.500 -- everything is always very complicated
unitl you get some system up and running.
It isn't appropriate to turn this list into an X.500 list, but it is appropriate
to understand these problems if we are thinking about changing our
direction.
It isn't clear from your comments whether you are talking about the X.500
architecture, as specified in the ISO/ITU standards, or whether you are
talking about a particular implementation (public domain, e.g., QUIPU?)
(commercial offering, e.g., DEC?), or whether you are talking about
a particular service offering, e.g. ATTMAIL, MCIMAIL, PARADISE, etc.
Can you be more specific?
I've certainly asked questions on RDNs, AVAs, etc., as we began to come
up to speed, but to be fair most of the answers were in the book. If I had
read the primer by Marshall Rose (or others) before plowing through
the spec, it would have saved me a lot of time.
The questions regarding what OIDs exist, and more to the point, which
attributes have been defined, and by whom, and what is their current
standing, is a very fair one. The Directory itself out to be the solution
to this problem, but I anticipate that the proliferation of attributes will
be THE show-stopping issue if X.500 fails.
I'm not certain what the role of the NIST OIW is in the process, nor how
the Internet, the IETF, and/or the PSRG relates to them. But I would have
expected that as the reference implementation contractor for PEM
that you would have been involved. Were they helpful?
It is my understanding that any organization that is registered with ANSI
(or under the ITU as a registered organization) can create their own OID.
within the NADF pilot, I believe that anyone under the level of a
O=<organization> can create their own attributes, with OIDs.
How we get all of these attrbutes implemented in DUAs is the real
problem. As the Security AD, perhaps you should suggest to the OPS AD
that they address these problems? (this may be totoally off the wall,
as I really don't know anything about how the IETF functions, or the politics.)