Subject: RE: Global unique identifier

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 14 Apr 2000 14:21:13 +1000

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

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.

Jim Heimberg's message was:

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

I'm simply saying that the 'domain' is not something like: All DNs; or: All
DNs under o=Ace Industry,c=US. I'm saying that the domain is: All DNs in
certificates issued by the CA.

Ron.

-----Original Message-----
From: Ed Gerck [mailto:[email-masked]]
Sent: Friday, 14 April 2000 12:56
To: Ramsay, Ron
Cc: [email-masked]; Anders Rundgren; 'Denis Pinkas'; 'Heimberg, Jim'
Subject: Re: Global unique identifier

"Ramsay, Ron" wrote:

> But surely the domain of the CA is the totality of subject DNs in all
> certificates issued by the CA. For two DNs to be the same in the CAs
domain
> they must each be the subject DN of a certificate naming the CA as issuer.

 Section 11.2 of X.509v3, "Management of certificates", states that the
certificate
 allows an association between a name called "unique distinguished name" or
DN
 for the user and  the user's public-key: "A  certificate  associates  the
public key
 and unique distinguished name of the user it describes.", while Section 7
explains
 that such DNs are essential to the security design of X.509:
"Authentication relies
 on each user possessing a unique distinguished name." But, how are such DNs
 assigned? Where are they unique? The DN is  denoted by a NA (Naming
Authority)
 and accepted by a CA (Certification Authority) as unique within the CA's
domain,
 where the CA can double as a NA. It is interesting to  note that the same
user can
 have different DNs in different CAs, or can use the same DN in different
CAs even
 if it is not the first one to use it in a CA -- so different DNs for
different CAs do not
 necessarily mean different users and vice-versa. Further, a DN does not
have to
 contain the user's real-world name or location. Thus, semantically, the CA
 certificate refers to a name; however it does not denote it.

(in http://www.mcg.org.br/cert.htm)

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Thu, 13 Apr 2000 23:08:26 -0700

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

> associated with the CA's DN by a certificate, they will be a unique

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 14 Apr 2000 12:48:14 +0200

Ed,

Your message was sent to the "Global unique identifier" thread.
Since I am adressing a different topic, I changed the  name of that
thread.

<snip>

There is one point in your E-mail I would like to comment.

> how such association was verified --   is  outside the scope of PKIX and depends

I am not sure that this is really outside the scope of PKIX. If some
judge would like to make the difference between John Smith 22 and
John Smith 23, what can he do ? Nothing that has been standardized
today. :-(  In PKIX we currently do not offer any solution. Maybe we
should ? What kind of solution ? Being able to get back (when
appropriate) the registration information (sometimes called the
credentials) that has been registered at the time of registration by
the RA. I do not think that it may be practical to get that
information by paper and in a different format for every CA in the
world. A protocol (and a schema) might be useful.

Denis

---

From: Ed Gerck <[email-masked]>
Date: Fri, 14 Apr 2000 09:58:54 -0700

Denis Pinkas wrote:

> I am not sure that this is really outside the scope of PKIX.

By your comment below, I think we both agree that indeed it IS (present tense)
outside the scope of PKIX and depends on each CA's CPS -- you write "what
can he do ? Nothing that has been standardized today. :-(  In PKIX we currently
do not offer any solution".

That was my point exactly.  Now, should we (in the future) offer it ? -- as
you also ask:

> If some

I like your approach and asking this question (going back to the
credentials) was at the root of my approach to non-repudiation
last fall. Non-repudiation (as I see it) is a necessary functionality
insofar as it can be used to negate that which might be false (e.g.
a wrong credential) -- not only doing "timestamping"and then
calling that the end-all be-all of non-repudiation (which, BTW,
is not what Tom Ginding says in his RFC for time-stamped non-
repudiation but it is how it stands today because there is no such
protocol).

So, Yes. The missing protocol thus exists IMO and is called non-repudiation
with all its bells and whistles.  In short, the ability to query the validity
of records, not just take them at their face value.

Now, whether this WG charter supports this discussion, I am not sure.
There were some voices last fall (including the WG's co-chair) against
moving any further in this direction than saying "this will be defined
by each CA's CPS".

Comments?

Cheers,

Ed Gerck