Subject: Re: Multi-national company listing issues

From: Robert Moskowitz <[email-masked]>
Date: Thu, 26 Aug 1999 22:49:02 -0400

At 07:29 PM 8/26/1999 -0600, Bob Jueneman 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.?
>
The directory person at GM (an old friend of mine) told me that GM went and
actually registered under C=US.  So the have C=US,O=GeneralMotors,OU(I
think)=DE(german divisions),OU=etc

And he can't change it.  This was set up long before he came on board.  It
is baked into so many systems...

Who was it that said, "if you want a clean slate, have a revolution'" ?

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

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 27 Aug 1999 12:02:26 -0400 (EDT)

> From: Paul Koning <[email-masked]>
> 
>  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.

The problem with the Subject field of a certificate is that we have
chosen to overload it with multiple purposes:

  1) a globally-unique, heirarchically registered identifier
  2) purely descriptive attributes (OU, L, SP, physical mail address, etc)
      intended for human consumption
  3) attributes that in addition to their uniqueness or descriptive
      properties are also interpreted by machine (email address for
      mail delivery, C as an indicator of nationality for purposes of
      restricting access, or even worse, a parenthetical (U) as part of
      a Common Name to indicate a security clearance level!)

As Bob Moskowitz said:

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

or in other words, we reap what we have sown.  Since clear guidelines
for populating and using the Subject field are not established, people
do whatever works for them.  Using "whatever works locally" is not the
optimum approach for achieving global interoperability.  "C" can be
the identifier of a registrar (ANSI in the case of C=US), or it can
be citizenship of a person, or it can be country of incorporation for
a person's employer, but it can't simultaneously be more than one of
these.

Last year there was a long discussion on using subject names in the form
of email addresses.  That works great as long as everyone understands
that "[email-masked]" is the name of a subject, and not necessarily the
place where joe's email is sent from or ultimately delivered to.

Personally, I would prefer the Subject DN to be exclusively a sequence
of registrar identifiers followed by a unique subject identifier, with
all other information in Subject Altname and Subject Directory
Attributes.  But that isn't the way most certs are issued today.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 29 Aug 1999 07:46:16 +1200 (NZST)

>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:

It's kind of difficult to reply to that since I agree with everything in it.
All I can say is <aol>me too</aol>.

Peter.

---

From: "Sweigert, David" <[email-masked]>
Date: Mon, 30 Aug 1999 15:24:30 -0400

Thanks for the response.

Extremely helpful.

Dave

-----Original Message-----
From: Robert Moskowitz [mailto:[email-masked]]
Sent: Friday, August 27, 1999 11:02 AM
To: Paul Koning; [email-masked]
Cc: [email-masked]; Sweigert, David; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Multi-national company listing issues

At 10:48 AM 8/27/1999 -0400, Paul Koning wrote:
>*any* of the things you suggested above.  (I suppose another way to
>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: "Miklos, Sue A." <[email-masked]>
Date: Tue, 31 Aug 1999 10:33:46 -0400

excerpt from exchange w/ANSI...

"Upon approval of ISO/IEC 9834-7 | ITU-T Rec. 666, ANSI agreed to apply to
become the registration authority.  However, a complete set of procedures
has yet to be developed, and the application to ISO, IEC & ITU-T has not yet
been submitted."

note that this standard deals with registration of multi-national
organizations (use of the O= component) for those organizations/coalitions,
etc. who do not populate, or ignore, the C= component.

Sandi

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Monday, August 30, 1999 8:53 PM
To: Bob Jueneman; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: Multi-national company listing issues

All,

Just an observation:)  I get a strange sense of Deja Vu here.

As Paul Koning remarked, in the US at least, the designation
"C=US" means "The party in question paid ANSI the required fee,
so ANSI registered the entry under 'US'" (loosely paraphrased)."

So, if you want more specifics, consult ANSI's "RPS" (Registration
Practices Statement.)  OK, I'm making that part up, its a take-off
on "CPS", for those who don't get it otherwise :)

___tony___

At 05:27 PM 8/30/99 -0600, Bob Jueneman wrote:
>Ed,
>
>I used a conventional X.400 representational shorthand for 
>the attribute called "country"  I would always assume that 
>localization of any display code would translate that 
>appropriately, if that was felt to be necessary.
>
>Bob
>
>
>
>>>> Ed Gerck <[email-masked]> 08/27/99 11:01AM >>>
> 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
>
>
>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Aug 1999 10:47:09 -0400

At 10:33 AM 8/31/1999 -0400, Miklos, Sue A. wrote: 

> become the registration authority.  However, a complete set of procedures has
> yet to be developed, and the application to ISO, IEC & ITU-T has not yet been
> submitted."
>

One of these eons...  Sigh.  Like this is a new business invention.

Robert Moskowitz
ICSA