[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Multi-national company listing issues



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 <rgm-sec@htt-consult.com> 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: rgm-sec@htt-consult.com