Re: Multi-national company listing issues

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

>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)."

Well, that really isn't true, at least in any realistic sense.

I believe that it is very important to distinguish between ANSI's role
as a registration authority OIDs under the joint ISO-CCITT registration arc,
versus the semantics of "country" in either a DIT or a certificate.

Speaking of deja vu all over again, the original RSA Commercial Hierarchy
CA, circa the early '90s, required the following:

1.  If an organization was to be listed at the country level, e.g., c=US, o=Novell,
then that organization had to been registered with ANSI and obtained an
OID and name listing (approximately $2000).  There name registration procedure 
did not provide any kind of guarantee of exclusivity, and in particular ANSI does not assume any liability for the correctness or right to use of a name, but procedurally it was pretty good.

2.  If an organization was not listed at the country level, the stateOrProvince attribute had to be listed immediately under the country, and the organization had to provide suitable proof of the fact that it was listed/chartered/incorporated in that state.  

3.  If an organization was not incorporated or otherwise chartered in some state,
the qualification had to extend down to the municipality level, expressed as locality.

All of this seemed very reasonable, although it was in no way required by ISO, CCITT, or ANSI itself, but rather by the CA, as a condition of registration.

Where this began to fall apart was when it was observed that many, many organizations simply didn't organize their directories that way, and weren't going to change.  And back then, in the X.509 v1 days, there were no convenient alternatives.

Now, of course, we have subjectAltName, and my recommendation would be that we strongly suggest if not require this DIT structure and registration requirement as a subjectAltName of any certificate issued to an "organizational person" or other corporate entity.

But I give up on tying to harmonize the Subject DN -- it's too late.  If we are going to be able to store and retrieve certificates, and authenticate users to a directory based on their certificate, a one-to-one mapping between the DN in the certificate and the DN in the directory is about the only reasonable way to progress.

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman@novell.com
1-801-861-7387

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:1-801-861-7387, 1-800-453-1267
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:1-801-861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com
N:Jueneman;Robert
TITLE:Security Architect
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD