Subject: Re: Use of localityName attribute

From: [email-masked]
Date: Tue, 6 Jul 1999 19:06:39 -0400

"Anders Rundgren" <[email-masked]> on 07/06/99 07:28:44 PM

To:   Tom Gindin/Watson/IBM@IBMUS, [email-masked]
cc:   "Petra Gloeckner" <[email-masked]>, "PKIX-List"
      <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject:  Re: Use of localityName attribute

Tom
I think that I have a slightly different view on unique identity in
EE-certificates

<snip>
>Locality is often part of the uniquely identifying set of
>information for a legally registered organization, and thus needs to go into
>some such certificates.  How about some wording such as the following:
>StateOrProvinceName and/or localityName SHOULD be included in the subject and
>issuer name only when the organization or organizationalUnit is legally
>registered as possessing a unique right to the specified organizational name
>within the state or locality specified.

When you register a company you usually provide a lot of data such as
addresses, telephone-numbers, president and board-member, some
description of what the company does etc.

In return you get a DUN-number (in the US) or a registration number (in Sweden)
Why do you need anything more than information about the registering
organisation,
the subject organisation name and their registration code?

[Tom Gindin]   DUNS numbers are assigned by Dun & Bradstreet, the largest
business credit reporting service in the USA.  They have no particular legal
standing and you don't get one by registering a company or a non-profit.  Of
course, small businesses usually do get one pretty quickly but non-profits might
not always do so.  The legal identification numbers an organization does get are
usually local to a state, except for the federal taxpayer ID, which is not
normally published anywhere except on tax forms.  People use DUNS numbers
largely because the US government doesn't want the taxpayer ID's used for this,
while D&B is quite happy to have their numbers used.

Actually the same apply equally well to individuals.  You are probably
registered
with an employee-number at IBM for reasons like it is very convenient, uses very
little space and is compatible with current database technlogy.  QCs way of
determine
identity based on an unspecified (or variant) set of attributes is extremely
hard to combine with normal staff adminstering systems.  That you may want to
search a certified entity for various attributes does not require these to be
included
in the certificate.  And then any number of attributes can be specified
externally in
the way that apply to the situation/business etc. without interfering with the
certificate.

[Tom Gindin]   Actually, my proposed rule was intended to make the set of
attributes used more predictable rather than less.  Here's a short version of
the rules I was suggesting: CN, O, and C MUST be present, OU MAY be present, ST
and L MAY be present in cases where they are required to render a name legally
unambiguous and SHOULD NOT be present otherwise.  Furthermore, in any country
where ST is defined, L MUST NOT be present if ST is not present.  Also, since L
and ST are intended for legal clarification of organization names, they SHOULD
come between C and O, and MUST come between C and OU.

As an analogy: I have yet to see a computerized customer register using anything
but a single unique code to separate them from each other.  Or a credit-card
BTW.

And aren't certificates mainly intended for computers to read and interprete?

[Tom Gindin]   Of course they are, but who administers the unique codes?  In
Sweden, the answer is probably "the government".  In the USA and a number of
other countries, there is no equally simple answer.

<snip>

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 10 Jul 1999 00:14:48 +0100

From:           	[email-masked]

> attributes used more predictable rather than less.  Here's a short version
> of the rules I was suggesting: CN, O, and C MUST be present, OU MAY be
> present, ST and L MAY be present in cases where they are required to
> render a name legally unambiguous and SHOULD NOT be present otherwise. 
> Furthermore, in any country where ST is defined, L MUST NOT be present if
> ST is not present.  Also, since L and ST are intended for legal
> clarification of organization names, they SHOULD come between C and O, and
> MUST come between C and OU.
>

I appreciate what you are trying to do with your rules, but I think that 
a short set such as above will not be sufficient to cater for every 
case, and if you were to do that the text would get too long and 
unwieldly. It might be best to simply stick with Santosh's first wording 
that simply allowed L as an option and leave it up to the good sense 
of the people designing their DNs to do it sensibly and 
unambiguously whilst ensuring that they used legally registered 
names. And leave it at that.

David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************