Continuing the thread I started in the previous message:
Thread 2: Extended possiblities for naming structures that don't conform to the
current "what God intended" :-) civil or geopolitical naming authority
assumptions. Examples would include the use of DUNS numbers, international
telephone numbers, Internet e-mail addresses, etc.
Peter asked:
How about
"/CN=<DUNS+4>/O=DUNS/ADMD=Sterling/ at arc.nasa.gov" for the EDI traffic.
(We should leave Certificate DNs as they are for personal privacy, and
command
and control accountability, purposes, in my opinion.)
For my purposes I will assume that Sterling is a VAN, and that they are
offering an X.500 directory service. Whether or not they offer an X.400 mail
service is immaterial, as the directory entry will specify how to reach the
customer.
I understand what Peter was suggesting with O=DUNS, CN=<DUNS+4>, although I
would prefer something like nameRegistrationAuthority="DUNS", O=<DUNS+4> to
refer to a particular organization by its DUNS number. (Peter's suggestion
makes good syntactic sense, but it destroys the current, not well stated
semantics of what is meant by "organization" and "common name".)
But the real question (or at least the question I want to ask), is how anyone
finds that particular organization unless they already know that Sterling is
operating the X.500 directory (ADMD=Sterling) that contains that customer's
information? We clearly don't want to continue the current X.400 "verbosity,"
but there may not be many alternatives.
I don't want to get into the utility of any particular naming scheme at this
time, but instead would like to point out that unless a particular naming
authority has a world-wide MONOPLY authority on the creation and use of that
particular name, AND chooses to either operate or delegate the operation of
some form of a directory (X.500, domain name server, etc.), then we are likely
to be stuck with the use of both ADMDs and some extension of Organization to
indicate which directory service provider we want to use. DUNS operates a
monoply with respect to their assignment of DUNS numbers, but they do not
currently operate a directory, and I understand that they haven't shown any
particular interest in doing so.
The nice thing about the Internet's domain name authority (from this
particular standpoint) is that it _is_ a monoply, and there isn't any question
as to where to go to look up a name. It will be interesting to see if this mode
of operation survives as the Internet becomes increasingly commercialized, but
so long as it remains a free, not-for-profit service it will probably be OK.
But now consider the problems involved in using international telephone
numbers, or even residential person street addresses as a means of uniquely
qualifying the user's distinguished name. What organization is going to provide
the directory service for that user, and how do other users know how to find
him?
One possibility, which the developers of X.500 may have had in mind, is that
either the federal government or the individual state governments would step in
and exercise some right of eminent domain, and either provide the appropriate
directory functions themselves, or contract for them. This would effectively
provide a monoply, at least on a state by state basis, and everyone would know
where to find an individual's directory listing, at least if they knew the
individual's "home" state.
It is not out of the question that an organization such as the United States
Post Office might be chartered to provide such a function within the US as part
of the National Information Infrastructure initiative. Without some form of
legislative mandate, however, the forces of competition would probably cry
foul.
However, without some form of a master directory-of-directories function being
available, one that would at least maintain a knowledge link to where the
"real" information about as user is being held, it is very difficult to imagine
how all of the directory information could be shared if there are hundreds of
million of users in the public name space.
In the NADF pilot, the problem of sharing access to directory information is
solved by maintaining either naming links or knowledge links to other
directories of all entries that are in the public name space. However, in most
cases the name link points to an organization, and it is assumed (rightly or
wrongly) that all entries associated with that organization are (a) contained
in a common private directory (PRDMD), and (b) are qualified by the
organization name (and perhaps the state name), so that lower level entries do
not have to appear in the public name space.
This assumption is crucial, because the public name space is shared between all
directory service providers, and at present it is administered and updated by
an awkward and error-prone offline batch process, utilizing files resident on a
machine presently provided as a service by USPS (even for Canadian
organizations).
Because there are presumably many fewer organizations in the US than there are
people, this approach might be feasible for most commercial users.
But once you start to talk about residential persons, the system begins to
break down, because of the lack of a monopolistic way of subdividing the
civil/geopolitical name space.
At the last NADF meeting GTE Labs demonstrated an experiemental version of an
electronic white pages listing, using subscriber information from our Downey,
CA directory. Approximately 46,000 subscribers were listed. Yet it was
immediately recognized that if we were to add all of those subscribers to the
public name space, the CAN process used to maintain the public name space
would break down, and most of the directory implementations would immediately
run out of memory.
Worse yet, the NADF participants could not find a simple way of carving out a
"natural" way of subdividing the information that would continue to function if
another local exchange telephone carrier in California (e.g., PacTel) were to
provide a similar function, because local exchange telephone company
territories generally do not correspond to existing geopolitical boundaries.
(This is in addition to the problem that below the level of states, there
aren't any "locality" attributes that would uniformly tile the United States.
For example, Los Angeles is generally considered a city, but it is really a
county containing other cities. On the other hand, New York City is divided
into borroughs, which are really counties.)
Now suppose that the FCC requires that Competitive Access Providers must be
allowed to provide local exchange telephone service to residential users within
a given city on a nondiscriminatory basis. This might result in one house being
served by GTE and its neighbor being served by PacTel. Worse yet, people might
do what I do -- since I have two incoming lines, I assigned one to MCI and the
other to AT&T, hoping that a common catastrophy wouldn't knock out both of them
at the same time. Now who do you go to to find a person's telephone number? Do
you have to look in two or more directories, either paper or electronic?
Of course, this is already the case with cellular, cable TV (in some areas),
email, and other services that aren't monopolies within a given territory. But
they don't make their directory information available at present.
One of the big questions that hasn't been resolved is what the model will be of
how X.500 services will be provided for the consumer.
The model that most people have in mind is that a directory service provider
will either be mandated as a monopoly service, or that the customer will choose
a service provider, and will then list all of the information about himself (or
the entire organization) with that one directory provider. At least in this
case, if you know the directory service provider (ADMD=?), you can find the
user more or less directly.
With this model it seems reasonable to assume that the user would pay a modest
for this service, although it is conceivable that the service could be free to
the subscriber. The service provider would presumably charge other users for
their inquiries. It is even possible that the directory service provider would
PAY the subscriber for listing with them, making up for the expense by charging
more for lookups.
Another completely different model, however, is the possibility that lots of
different information service companies would have a portion of the sum total
of the information pertaining to a user, and Directory User Agents would have
to go to multiple directory sources to obtain the information that is desired.
If I want to know someone's telephone number, and I know that he maintains a
residence in California, I would go to both the PacTel and the GTE directories
(and perhaps some smaller local carriers as well). If in addition I want to
know his cellular or beeper numbers I would go to those carriers as well, and
the same for his e-mail address. Maybe someone would operate a X.509
certificate directory as well.
Finally, if I am trying to find a business or an individual who provides
certain services, or whose has expressed an interest in obtaining certain
services, I might go to a more specialized directory service provider, just as
I would look up someone in the Yellow Pages, a legal directory, a directory of
EDI-capable buyers and sellers, etc.
My intent in all of this is to point out that we so far don't yet have ANY
commercially viableX.500 directory service providers, and that some of the
fundamental issues involved in providing directory services for hundreds of
millions of users in a competitive environment haven't been resolved yet.
I still believe in X.500, and in the potential for universal encryption and
digital signatures provided by X.509 certificates. However, I believe that we
are just beginning to understand the complex infrastructure issues that will be
involved in providing these services. If other means, (preferably free! :-),
can be found for reliably distributing certificates, using either a push or a
pull model, it may be time to look seriously at them.
The original PEM model of including the certificates within the initial
correspondence begins to look better and better. That doesn't solve the problem
of how to find someone's e-mail address based on his name, etc., but it does
provide a usable way of distributing the certificates, and it is reasonably
economical of bandwidth by not sending certifica\tes to anyone that doesn't
need them.
We should probably look more carefully at ways of controlling local cacheing
mechanisms and associating certificates with users names and/or e-mail names.
Bob
--------------------------------
Robert R. Jueneman
Mgr., Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820 (rolls over to cellular and/or my house
if no answer -- have patience)