For example, my DN in the PARADISE X.500 pilot is
commonName=Colin Robbins, organizationName=NEXOR Ltd, countryName=GB
which is a bit of a long thing to type.
I keep reading things like this and I just don't understand, so apparently the
tools
that some people are using for these purposes are radically different from what
I am
using. Perhaps you were using a character oriented DUA that required all of that
stuff?
The DUA I am presently using evaluating, InfoBroker 1.0 from DEC, presents a
search
screen whenever I want to find out some information about someone. A search
screen
for "Person" is built in, with their notion of what things I would probably
like to
look for, but it doesn't fit my notion of what I want, so I built another one,
which
I call "GTEL Person".
The screen has a label, "GTEL Person", and then it has a number of blocks that
I can
fill in for search criteria. These blocks do NOT have to be the Distinguished
Name,
and they don't all have to be completed. I wouldn't normally search on telephone
number, for example, but I could, even though that is not part of a user's DN.
So normally I fill in just minimum information necessary, e.g., the surname
block
(jueneman), and a screen will be returned that has a gray top bar that contains
the
actual DN, CN=Robert Jueneman, OU=Wireless and Secure Systems, O=GTE
Laboratories
Incorporated, C=US. (Actually, the CN=Robert Jueneman is normally hidden unless
I
use the cursor controls. the rightmost portion is displayed.) More importantly,
the
rest of the screen displays the payload content, and is formatted as follows:
Robert Jueneman
Surname
Jueneman
Common Name
Robert Jueneman
Telephone Number
1-617-466-2820
Internet E-mail Address
Jueneman(_at_)gte(_dot_)com
I can click on any line, or drag the cursor to highlight certain portions,
using the
usual Windows conventions, then copy the information to the clipboard and paste
it
somewhere else. I haven't tried it yet, but I suspect that I could fairly easily
integrate this product with a macro and a button within Ami Pro, and probably
other
packages as well.
Once we have our directory fully populated a lot more information will be
available
to display if I choose to do so, but my point is that _I_ chose the descriptive
labels to be associated with the particular attribute types ("Internet E-mail
Address" is really rfc822, and "Common Name" is of course commonName).
In addition to assigning the labels to be displayed, I specified the order in
which
the attributes were to be presented.
Furthermore, I can simply and easily add new attributes to be displayed, as
soon as
they are defined within my DSA's schema. The new attribute object ID numeric
format
is simply typed in, along with the attribute name, default user label and syntax
type (at present restricted to string, JPEG, GIF, and binary). Normally, of
course,
these definitions would be provided by the local system administrator as a
default
x500c.ini file. But all of the attributes defined in X.520 (including User
certificate, CA certificate, and Certificate Revocation List) are already
included,
and a large number have also been added by DEC, including things like mobile
telephone number, pager number, building name, and the ever-popular favorite
drink,
etc.
I suspect that experience will show that it is possible to trade off search
time for
convenience rather directly, and that several search bases or search rules will
be
useful. For example, I would not want to search the entire world for
surname=Jueneman, so my primary search base will normally be limited to GTE
Labs, or
I should specify an organization. A secondary search base might be C=US, and
searching the entire world should probably take an explict command. When I
correspond with someone who is listed outside of C=US, I will either have to
change
the search base or specify the country explicitly.
But the basic point is that the user should rarely, if ever have to type in a
full
X.500 DN, for almost any purpose, in order to retrieve whatever information is
desired. This is certainly much more than what the DNS provides for IP lookup.
Even more to the point, perhaps, is the fact that the DN in the X.509
certificate
does NOT have to correspond to DN associated with the user's name. In fact, if
it
weren't for the fact that for identification and signing purposes we would like
the
name to be globally unambiguous, the name in the certificate wouldn't have to
be a
DN at all. Once I finally realized that, a lot of my concerns about having to
cram
information into a Distinguished Name field that didn't really seem to belong
there
just evaporated. In reality, the DN fields in a certificate are simply a
collection
of typed attributes. In the grand scheme of things, I think this was probably a
wise
decision, for trying to machine parse natural language text is usually more
difficult than it is worth. "Time flies like an arrow. Fruit flies like a
banana."
What is a time fly? How well do bananas fly? Some fruit flies like a rock??
It would be nice to come to some consensus as to what attributes would be nice
to
support within an X.509 certificate, but it may not be all that important.
Anyone
who feels the need can make up his own attributes and include them, and if
enough
people do that, maybe a consensus will eventually emerge as to which ones are
most
useful.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM