pem-dev
[Top] [All Lists]

Naming examples

1993-12-22 16:48:00
Steve,

In my previous message I failed to mention a couple of other cases of interest
that you, Hoyt, Sead, and I discussed, notably that of multinational 
organizations.

I will differentiate between an international organization, notably the United 
Nations, which is accorded the status of a sovereigh government and has
their own unique arc of the directory tree, versus a multinational corporation 
that is headquartered in one country but does business in others. The rules for 
international organizations are too complex for me to understand, so I will
refer anyone in that position to the lawyers, the relevant treaties, and the 
standards 
organizations.

Multinational corporations are relatively simple, however, and basically follow 
the same 
rules as laid out above. 

1.  The countryName is the name of the country in which the organization is 
incorporated or chartered. From the standpoint of the DN that is included 
within the
X.509 certificate, each corporation or wholly owned subsidiary is an 
independent 
entity, so IBM Corporation, IBM France, IBM Deutschland, etc., are all separate
organizations. Each may be nationally registered within the country in which 
they
are incorporated, or they may be identified at the state or locality level. It 
should be 
recognized that the creation of a wholly-owned subsidiary in a foreign country
is a common practice, in particular to shield the parent corporation from the 
vagaries
of local laws and practices, for tax purposes, etc.

2. Companies doing business outside of their home country but not as a 
subsidiary
corporation that is independently chartered in the foreign country is exactly 
analogous
to the situtation where a company is doing business outside of the state in 
which 
it is incorporated. The DN should specify the location of (an implicit and 
unspecified)
civil authority that knows where the headquarters organization is located, who 
the 
principals are, etc.

3. For DIRECTORY SEARCH PURPOSES ONLY, various seeAlso attributes may
be created to refer back to a parent organization, and/or down to lower level
subsidiaries. Directory aliases may also be created to provide somewhat more 
user-friendly (yellow pages) lookup capabilities.

An example of such an organizational structure might be as follows (apologies to
Hoyt Kesterson if I got some of the details wrong):

C=FR (France), O="Groupe Bull" (Bull is the French holding company)

C=US, S=AZ, L=Phoenix, O="Bull HN" (Bull, Honeywell, and NCR formed a joint
venture in the US. When Bull bought the controlling interest, the name changed 
from
Honeywell Bull to Bull HN).

If a Bull HN employee were assigned to Saudi Arabia on contract, his 
certificate DN
might be C=US, S=AZ, L=Phoenix, O=Bull HN, OU=Field Engineering,
C=SA, L=Riyadh, CN="Omar Kyam"

However, if instead of operating out of his hotel room there was actually
an office set up in Riyadh, then the DN might read

C=US, S=AZ, L=Phoenix, O=Bull HN, OU=Field Engineering,
C=SA, L=Riyadh, OU="Riyadh Field Engineering Operations", CN="Omar Kyam"


-----------------------------------
Charles Gardiner writes:

I'm somewhat puzzled by your item 5.  Shouldn't the name start off with

C=US, S=DE, O=GTE Laboratories Incorporated, S=MA, L=Waltham, 
OU=GTE Government Systems, etc. ?

Or did you mean that GTE Government Systems was a separate organization
located in, and known to, Waltham, Mass.?

I had said

5. In the case of an organization wich operates a branch office away from
its headquarters, the name should be something like

C=US, S=MA, L=Waltham, O=GTE Government Systems, 
S=MD, L=Rockville, OU=Rockville Operations, CN=John Doe

You may be raising a good point. If a company is incorporated, should they
always include the state of incorporation in their DN, even if they also
include the state and locality in which they do business? I would be inclined to
think so, just because only the state of incorporation guarantees unique
name qualification.

For all I know, there is an Acme Corp. which is registered in Deleware, and 
another
Acme Corp. which is registered in California. If either of the companies is 
sufficiently
large they would probably go to court to compel the other to change its name, 
but
if one were a software company and the other a plumbing supply company, the 
possiblity of confusion may not have warranted such an action. Now what happens
when both companies decide to open a major office in the same town in 
Massachusetts? Is it clear which one is which? Even if one changes their name 
to 
Acme Corp. of Massachusetts, which one is the "real" Acme?

In this case I was assuming that GTE Government Systems was known to 
the folks at city hall in Waltham MA, and that they operated a branch office in
Rockville MD. 

GTE Government Systems is not a subsidiary of GTE Labs, so your
example wouldn't be correct, but it brings up a couple of additional points.
I haven't kept up with GTE Government Systems corporate structure, but I think I
understand GTE Telephone Operations, and can use it to illustrate another
point.

GTE is made up of lots of individual state telephone companies, which are 
required to be kept separate (as I understand) for regulatory purposes.
The parent company, GTE Corp., has a wholly-owned subsidiary called
GTE Service Corp (probably spelled out in full). 

An organization UNIT of GTE Service Corp is GTE Telephone Operations,
which is NOT a corporation but a group. As I understand it, most of the 
employees
of GTE Telephone Operations, whose world headquarters is in Irving, are
really employed by GTE Service Corp. The presidents of the individual
state telephone companies are also VPs of Service Corp.

The letterhead and business cards of these people all say GTE Telephone 
Operations, but since Telops is not a corporation it would not be appropriate
to use just the state as a qualifier.

As it happens, some Telops people are assigned to work at GTE Labs on a semi-
permanent basis, but they are not employees of the Labs. I suppose that in all
its full glory, the certificate should read something like the following:

C=US, S=DE, O="GTE Service Corporation", 
S=TX, L=Irving, OU="GTE Telephone Operations", 
S=MA, L=Waltham, OU="c/o GTE Laboratories",
CN="John Doe"

This is probably necessary if John Doe is expected to sign something as a Telops
employee. If he just wants to send and receive e-mail, an alternative might be

C=US, O=GTE Laboratories,    (assuming we register with ANSI)
OU="Resident Visitor",
CN=John Doe

I would certainly expect that aliases would be used to simplify the directory 
search
process, so in the X.500 directory an alias with the following DN 

C=US, O=GTE Telephone Operations, CN="John Doe"

might point to the more complex certificate above.

However, this brings up a problem. I am assuming that the "alias" and "seeAlso"
attributes would probably not be considered suitable for inclusion in a DN, 
although 
it would certainly be nice to have a place to put it in the X.509 certificate 
as a 
separate attribute. This in turn means that the use will look up one name (the 
alias) 
in the directory and it will resolve to another name, WITH NO BACKWARDS 
POINTER TO CONFIRM THE CORRECTNESS OF THE LOOKUP PROCESS.

It is increasingly clear that these naming issues are quite complex. I 
volunteered
to try to write down the "rules" for the document that the ABA workshop on 
Notarization and Nonrepudiation, but some of the legal nuances are probably
beyond me. Because I just sent one of my guys to our first NADF meeting, I 
don't 
know whether they have addressed any of these issues at this level of depth, but
I highly doubt it.

I am beginning to feel really sorry for people like George Parsons of RSA, who
will have to advise their customers as to what constitutes a legitimate DN, and
I caution people who are starting down this road to talk to your corporate 
lawyers
early in the game. It may save you a lot of agony later on.

I also apologize to those would just like to write code or sign messages. 
All this legal mumbo jumbo must be awfully arcane and tedious to read through.
But the more I talk to users who are actually setting up CAs and getting ready 
to 
go "live", the more I am convinced that the issues are very important, and not 
very
well  understood by anybody.

Bob

<Prev in Thread] Current Thread [Next in Thread>