Subject: Multi-national company listing issues

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 26 Aug 1999 19:29:05 -0600

I posted the following (modulo a few changes) to the 
ABA Information Security Committee list in response 
to David's request on this subject to that group:

David, having wrestled with these issues when I was 
still with GTE and involved with the NADF, and now 
even more that I am with Novell and tangentially involved 
with NDS, I wish you luck and a bottle of Excedrin.

This has been a train wreck about to happen for almost
ten years.  The semantics of the X.521 oxymoronic 
"useful definitions"  were completely inadequate even
when people were expecting the monopoly carriers to 
implement X.500, and they are even less helpful today,
when there is already a whole bunch of isolated island
directories that we would like to stitch together into
a certificate infrastructure.

For example, is "C=" the country where the parent
is located, where the subsidiary is located, where the
tiny field office is located, where they are incorporated 
(think of a ship with Liberian registry), etc., etc.?

In the case of an individual user, is the country where 
he was born (or adopted)? Where he is currently a citizen
(what about dual citizenship, stateless persons, and nomads)?
Where he maintains a residence (or maybe a domicile)?
Where he works (I assume some people work in one
country and sleep in another, every day)?

In other words, does country= qualify the organization 
or person, or the location, or what?

Nobody knows, and everyone does it differently.

If it matters, specify it in your CPS, since no one is going 
to read that anyway!

So here's my advice:

1.  Render unto Caesar that which is Caesar's. That is, let the system
administrator dictate what the DIT structure is going to look like,
since he will do what he wants to in any case.  Directory naming
is NOT based on legal principles, much less ISO recommendations,
but rather on physical connectivity and/ or organizational 
relationships that have relatively little to do with logic.  I wouldn't 
dare suggest that Novell change its internal directory structure, for
example, because even though I could certainly think of 
ways of improving it, it wouldn't be worth the effort.  And Novell
is only a 4000+ employee company -- think of GM, or the US Navy.
"Trying to change an already existing directory structure is like teaching
a pig to whistle. It's a waste of your time, and it annoys the pig."
In other words, "Fuggedaboudit"

2.  The DN in the certificate should be identical to the DN of the 
entity in the directory, even if this appears to be complete gibberish to 
someone on the outside of that organization's name space, e.g.,
"bjueneman.nsrd.prv.novell". This will at least simplify certificate 
mapping and retrieval within that directory.  Interconnections between
directories is probably going to have to be handled by some kind of a
meta-directory approach, or else by a URL-like directory qualification 
scheme.

3. Specify anything else you think might be useful to put in the certificate 
in subjectAlternateNames, including e-mail names, organizational 
names, etc., whether they are mapped to your directory or not.  Then specify
aliases or whatever other database construct works in your directory
to facilitate looking up entities by those names as required..

4. If it feels good, do it.  Don't let these issues get in the way 
of deploying a certificate infrastructure.

Trying to harmonize all of this stuff was too hard 10 years ago, 
and it's gotten harder yet since then. Computers are good at using 
databases to look up equivalences -- let's use them for that.

Bob

>>> Robert Moskowitz <[email-masked]> 08/26/99 12:06PM >>>
At 06:28 PM 8/24/1999 -0400, Sweigert, David wrote:

If I remember correctly, GM goes by country and then function.

Chrysler went by function and then country (don't know what DCX will do).

So do what ever you want.  Either will work for your client, neither will
work for a global lookup.

>
>As anyone grappling with the problem of defining a directory information
>tree for a multi-national company.  In other words, how do divisions in
>the UK and US relate in the DIT if both divisions are within one corporate
>organization; say MARKETING.
>
>Would this be appropriate:
>
>c=US
>o=GlobalCorp
>ou=Marketing
>
>and
>
>c=UK
>o=GlobalCorp
>ou=Marketing
>
>
>Any thoughts on this ?
>
>Dave Sweigert

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: Paul Koning <[email-masked]>
Date: Fri, 27 Aug 1999 10:48:57 -0400

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> For example, is "C=" the country where the parent is located,
 Bob> where the subsidiary is located, where the tiny field office is
 Bob> located, where they are incorporated (think of a ship with
 Bob> Liberian registry), etc., etc.?

 Bob> In the case of an individual user, is the country where he was
 Bob> born (or adopted)? Where he is currently a citizen (what about
 Bob> dual citizenship, stateless persons, and nomads)?  Where he
 Bob> maintains a residence (or maybe a domicile)?  Where he works (I
 Bob> assume some people work in one country and sleep in another,
 Bob> every day)?

 Bob> In other words, does country= qualify the organization or
 Bob> person, or the location, or what?

There's one data point that might help.

If you want to obtain an NSAP address block (for ATM for example) one
easy way is to get it under the DCC (Data Country Code) branch of the
NSAP space.  Those are administered by national bodies in various
countries; in the USA that is ANSI.

ANSI will assign a block under its DCC code to anyone who hands over
the $1000.  The fact that your entry appears under the code that
represents "USA" means simply that the assignment was made by the USA
registrar.  It has NO other meaning.  In particular, it doesn't mean
*any* of the things you suggested above.  (I suppose another way to
put it is "it's totally useless"...)

	paul

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 27 Aug 1999 11:01:45 -0400

>put it is "it's totally useless"...)
This is what GM supposedly did, according to my friend, but he quoted a
$1200 fee.  Maybe it came down.  GM basically ignores everything about
o=GeneralMotors.

Robert Moskowitz
ICSA

---

From: Ed Gerck <[email-masked]>
Date: Fri, 27 Aug 1999 10:01:47 -0700

Bob Jueneman <[email-masked]> wrote:

> For example, is "C=" the country where the parent is located,
> where the subsidiary is located, where the tiny field office is
> located, where they are incorporated (think of a ship with
> Liberian registry), etc., etc.?
>
> In the case of an individual user, is the country where he was
> born (or adopted)? Where he is currently a citizen (what about
> dual citizenship, stateless persons, and nomads)?  Where he
> maintains a residence (or maybe a domicile)?  Where he works (I
> assume some people work in one country and sleep in another,
> every day)?

Bob:

What is the meaning of "C=string"?

There are two ways to solve this. One, is to proceed with the hierarchical
type structure as a taxonomy and provide all the possible ramifications --
clearly, with very little chance of satisfying even just the majority of cases.
The other way is to renounce the concept (wrong, anyway) of "denotational
syntax", treat the hierarchical structure as an an ontology and consider all
qualifiers from the syntactic point of view, as "names".  With this approach,
the meaning of "C=string" is now clear:

"C" and "string" are specified, and "C" stands in equivalence with "string"

Here, "C" is a name -- a quite arbitrary designation that is simply formally
defined and may (or not) have a mnemonic purpose or be expressed in
a human language.  In other words, "C" is just a pointer, a handle in an
hierarchical ontology (not in a taxonomy).  OTOH, "string" may be either
a name or a record as usual, where records refer mainly to physical
quantities (e.g., geographical data, network addresses, port numbers,
service designations, company names, etc.) designated in a materially
pre-defined form.  The  map and query methods of a database can then
relate names to records in a variety of relationships according to local
need, such as one-to-one, many-to-one, one-to-many or many-to-many.
The database can also follow a variety of models such as hierarchical,
network, relational, distributed hierarchical, etc.

What is required to do this? Nothing, just renounce the taxonomy and
employ the same hierarchical structure already in place in X.500 or
LDAP or whatever is being used.  Even the same relational tables
if a relational database model is followed.

But, where is the meaning of "C" denoted?  Not, in "C" itself but in the
trusted context -- where it is anyway defined.  For example, "C" is
meaningless in German as an abbreviation for Country -- it is the trusted
context which says so (but, with all the ambiguities you point out and
which are basically irresolvable).

The integration of different trusted contexts becomes then a problem,
but one which I believe is being increasingly solved in database theory
-- for example, with meta-directory approaches.

Of course, denotational syntax also "works" one may say -- but only in a
parochial environment where the trusted context is implicitly known.  Since
we are past this stage in the Internet, the fact that syntax and semantics
are independent variables can no longer be ignored and must be either
properly handled or threatens to overwhelm.

Cheers,

Ed Gerck