Subject: RE: PKIX: Use of dnQualifier must be settled

From: "Manger, James" <[email-masked]>
Date: Wed, 17 Nov 1999 11:31:37 +1100

1. In the X.500 model, for any particular object there is precisely one
object entry [X.501, 7.3] in the Directory Information Base (DIB).
2. The intention of X.500 is to have a single DIB, composed of many systems
and serving many applications [X.500, 6].
3. The DIB is organized as a tree - the Directory Information Tree (DIT) -
that is partitioned into distinct naming contexts held by different DSAs
[X.501, 17.3].
4. Each entry within the DIB is administered by one, and only one, DSA
[X.501, 17.3].

The model stumbles when more than one group wants to manage information for
a single object.  For instance, two competing phone companies want to
publish (in X.500 directories) a business phone book, a legal firm wants to
run a DSA that lists the directors & secretary of companies and a
stockbroker wants to publish stock prices via X.500.  All 4 groups want to
manage their own DSAs, but  they all want entries for the same objects (e.g.
companies).

X.500 does not support "distributed entries", where different groups manage
different information about the one entry.  [X.500 allows an entry to be
replicated amongst many DSAs, but these are copies of one master entry.]
The DN Qualifier attribute was introduced as a partial solution to this
problem.  Different DSAs could have independent entries for the same object
without violating X.500 by adding a per-DSA DN Qualifier value to the
entries.  This gives the entries from different DSAs different DNs so they
are different entries in the DIB.

[I understand a more complete solution to this problem is currently being
developed by an X.500 working group.  It introduces "domain identifiers"
(DIT ids) that are used in conjunction with a DNs, but are not part of the
DNs.  This mechanism may obviate the need for DN Qualifier, but this would
in no way be justification for redefining DN Qualifier.]

Hopefully this gives a context for DN Qualifier.  Hopefully it also shows
that it was designed for a very different problem than holding
employee/customer/org/unique ids and, consequently, is not appropriate for
the latter.

=> Define new attributes to hold (printable) ids for
customers/employees/orgs that are unambiguous in a given context (e.g.
organization, jurisdiction).

In Russ Housley's example c=XX o=Acme grows so it adds a 2nd DSA for c=XX
o=Acme ou=Sales.  No DN needs to change, even if it has a DN Qualifier
value.  Both Acme DSAs can use the same DN Qualifier value because they
don't need to disambiguate each others entries (if they did it wasn't just
"reallocating the DIT among DSAs").  The DN Qualifier value disambiguates
any entries in the Acme DSAs from other **independant** DSAs.

> 	----------
> 	From: 	Russ Housley[SMTP:[email-masked]]
> 
> 	Interpretation 1 cannot be correct.  The DIT can be reallocated
> among DSAs, and this would result in name changes.  For example: assume
> that c=XX, O=Acme was handled by one DSA, but the organization grew so
> that a second DSA was added.  The new partition might be so that all of
> c=XX, o=Acme, ou=Sales was moved to the new DSA.  I would hope that this
> adjustment would nt cause any names to change.
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 17 Nov 1999 09:21:51 +0100

James,

I may not like it, but I can't close my eyes to the fact that what you are
saying here makes sense to me.

Is there any one out there who knows for sure that what James says in fact
is WRONG?

/Stefan

>any entries in the Acme DSAs from other **independant** DSAs.

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------