Subject: RE: Global unique identifier

From: Anders Rundgren <[email-masked]>
Date: Thu, 13 Apr 2000 14:21:21 +0200

Jim,
You are absolutely right that DNs should be globally unique within their domain. 
The only problem is that we do not have any means (or do we?) to specify (in a certificate) a domain 
which may be internal (NULL) to the CA or external (hopefully centrally registered like IPs, OIDs etc.).   
Anders
----------
From:  Heimberg, Jim [SMTP:[email-masked]]
Sent:  Thursday, April 13, 2000 14:13
To:  'Denis Pinkas'; Anders Rundgren
Cc:  [email-masked]
Subject:  RE: Global unique identifier

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [email-masked]
Subject: Global unique identifier

Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 13 Apr 2000 11:03:55 -0600

That's why most countries use a taxpayer ID.  Even though they aren't guaranteed to always be unique across time and space, they reduce the possibility that the combination of name and number is not unique to a level that is negligible.  Not zero, perhaps, but negligible.

DON'T assume, however, that CAs have restricted geographic coverage, for that certainly isn't so.  Europe isn't like the US, and vice versa. We fell into that trap within the NADF about 8 years ago, when we assumed that monopoly telephone carriers (remember those?)  had territories that corresponded to geopolitical boundaries.  Turns out that wasn't true even then, and  most certainly isn't now.

I'm sure that VeriSign would be willing to sell you a certificate regardless of where you live/reside/are domiciled/are a citizen of/vote/own a second residence/are currently travelling/etc.  For that matter, so would we.

Bob

>>> Anders Rundgren <[email-masked]> 04/13/00 08:29AM >>>
Denis,

<snip>

>A CA can nominate the Delta Company from country FR, but another CA
>can nominate another Delta Company from the same country. There
>cannot be an ambiguity on the country name, because the way country
>names are used is well described. For any other level, the
>interpretation is free. Thus there is no way to make sure that the
>two Delta companies are the same, since there is no naming authority
>telling how "Delta Company" should be interpreted or undertsood.

This is perfectly valid in regions where no registration system exists.  In country SE
this has been solved in the same way as for persons.  Permanent unique IDs.

Actually I don't understand how tax authorities can separate the two Delta Companies
if there are no naming conventions.

There are very few global standards for this, but CAs usually have restricted geographic coverage.

<snip>

Anders

---

From: Paul Halliden <[email-masked]>
Date: Thu, 13 Apr 2000 18:08:11 +0100

<snip>

>if there are no naming conventions.

Quite simple - In this country (UK) the tax man allocates his own account
number to each.  If both Deltas are actually the same company, it soon
complains when it gets two tax bills.  The tax man can use a mass of
information that exists in the real world to establish whether there really
is one or two and adjust its account numbering scheme accordingly.  The
point is that in real life there are plenty of name collisions which can be
resolved in a given domain provided that domain has control over its naming
convention.

Paul Halliden

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 14 Apr 2000 08:12:32 -0600

Let's remember that the original purpose of X.509 was to 
allow authentication of a user to the directory ITSELF. Since
the DN in the directory was the controlling index used to look up 
all the other stuff, it by definition had to be unique in that directory.
Otherwise the directory would have been a relational database.

Then the PKI community came along and said, "Oh, that's nice" and
appropriated the syntax of X.509 without ever bothering to define the
semantics of what a DN really meant in their new context.

There was sort of a vague hope that a DN would actually be meaningful, 
despite the experience of many deployed directories to the contrary --
directory administrators set up directories for their own convenience, and 
sometimes for the convenience of the larger organization, but hardly
ever for the convenience of external users who might be inclined
to actually RELY on the DN.

So the DN in a directory is primarily Distinguished, i.e., unique within that
directory; and only secondarily, if at all, useful as an actual Name. Case
in point, my own DN or NetWare "context": 
bjueneman.nsrd.prv.novell.

Now there 's a name a mother could really grow to love! But it is unique, at least
within Novell's directory.

Well, 'sez some, how about using a subjectAltName? Good idea, bad execution,
at least so far: subjectAltName=[email-masked]. From the standpoint 
of providing human recognizable information, that's even worse -- it doesn't even
provide a hint to anyone where I work, or in what organization. I guess it's
better than [email-masked], but not by much.

You say that you'd like to have a name that more or less corresponds to
the name I am known by in social circles (no, not that name, the polite one)?
Or you'd like to have something that corresponds to my business card, or maybe 
a residential address, in case you want to send the sheriff after me?

Then put yet another subjectAltName in the certificate, this time a REAL one,
e.g., c=US, o="Novell, Inc." ou="Network Security Department", 
title="Security Architect", cN="Robert R. Jueneman"

Or even more informatively:, if backwards by conventional envelope 
addressing conventions:
c=US, o="Novell, Inc." ou="Network Security Department", s=Utah, l=Provo,
steetAddress="1800 South Novell Place", 
title="Security Architect", cN="Robert R. Jueneman"

Of course, it might have been nice to label these subjectAltNames
more informatively, as a hint to applications that have to display them, e.g.,
rfc822Name=..., organizationalPersonName=..., residentialPersonName=...
but I guess it's too late for that now. "Syntax first, semantics later, if
at all" is our motto, right, boys?

Oh well, maybe we'll get it right eventually. Son of son of 2459, maybe?
Sounds like a Russian patronymic, or maybe an SPKI reference. :-)

Bob

>>> Ed Gerck <[email-masked]> 04/14/00 12:08AM >>>

"Ramsay, Ron" wrote:

> Ed,
>
> I think we all know about the shortcomings of DNs and, as far as X.509 is
> concerned, I don't think we're going to see The Global Directory(TM).

not with that technology, but X.500 is not the end-all be-all of database
development -- new paradigms may always appear.

> My point, and I don't think you answered it, is that a CA can get it names
> from anywhere, the moon perhaps, and there may be clashes in the 'global'
> name space. But, as long as they are unique in all the DNs which have been
> associated with the CA's DN by a certificate, they will be a unique
> identifier for that CA.

We may agree that you are postulating the answer to your question -- so, no
wonder you get it. What you are saying is equivalent to "if names are unique
in a CA, then they are unique in that CA".

Now, let's try a real-world case, where two "Jim Jones" want to get a certificate
from Verisign -- why would the second one need to accept a different DN? More
probably, rather than being forced to accept a different DN he would look for a
different CA, which is of course not acceptable commercially for the first cert vendor.

The bottom line? Semantically, the CA certificate refers to a name; however it does
not denote it. Therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
local matter (local to the CA and its CPS) even if X.500 global directories were used
(X.509v3, Section 11.2). Of course, if the US INS accepts (rather, "uses") UK birth
certificates in order to issue residence permits to the US, this does not mean that the
INS is declaring that such birth certificates are valid in the UK. So, the eventual use
by a CA of a DN supplied by a X.500 directory does not mean that the CA is
declaring that such DN is global -- or, globally unique.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified -- is outside the scope of PKIX and depends
on each CA's CPS.

Cheers,

Ed Gerck