Subject: dnQualifier is used incorrectly

From: "Manger, James" <[email-masked]>
Date: Thu, 11 Nov 1999 11:24:10 +1100

It is inappropriate to hold an employee/member/customer number as a
dnQualifier attribute value.  When multiple directories each have an entry
for the same person (or entity) the DN Qualifier disambiguates the entries.
A DN Qualifier value indicates which directory a DN refers to, not which
person in a directory.  In fact, the definition of DN Qualifier says the
same value should be used for all entries in a given directory.  Mapping
from directories to CAs, it is clear that the DN Qualifier should
disambiguate certificates issued to the same person by different CAs.  The
same DN Qualifier value should be used in all certificates issued by a given
CA.  The DN Qualifier should identify the CA, not the subject.

Example:
A company, Frottleby Limited, is certified by two CAs.
The TrustMe CA certifies Frottleby Limited using a DN:
	{ c "AU" / o "Frottleby Limited" dnQualifier "TrustMe Customer" }
The SuperID CA certifies Frottleby Limited using a DN:
	{ c "AU" / o "Frottleby Limited" dnQualifier "SuperID" }

Stephen & Stefan's quotes below are completely at odds with the original, &
surely definitive, X.520 definition of the DN Qualifier attribute.

Stephen Kent says, in 'Re: QC UID support must depart from RFC2459',

	"..I believe that the DN Qualifier makes more sense as a component
of a terminal RDN, at least from the standpoint of directory schema. I would
also suggest that this is the most appropriate attribute as a means of
expressing employee ID, payroll number, etc.  After all, these numbers were
assigned in the pre-X.500 world to achieve the analogous effect, i.e., to
disambiguate among database entries that might otherwise be identical."

Stefan Santesson says,

	"- Attributes for expressing a private identity (... dnQualifier)
...  Here the use of dnQualifier will be constrained to hold a unique
identifier of the subject within the set of all certificates issued by a
CA."

From X.520 | ISO/IEC 9594-6: 1993:

5.2.8 DN Qualifier
The DN Qualifier attribute type specifies disambiguating information to add
to the relative distinguished name of an entry.  It is intended to be used
for entries held in multiple DSAs which would otherwise have the same name,
and that its value be the same in a given DSA for all entries to which this
information has been added.

[DSA = Directory System Agent, basically a directory server]

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Nov 1999 16:06:27 -0500

James,

I disagree (with the part about the same dNQualifier must be used in the DSA in
every entry).  Say there are two DSAs.  The first DSA has an entries for Alice
and Bob.  The second DSA has entries for Alice (a different Alice than the one
on the first DSA) and Pat.  What X.520 says is that the different entries for
the two Alices on the DSAs use different dNQualifier values to disambiguate the
entries (you can use anything in the printableString just as long as they
disambiguate the entries).  Secondly, if the entry for either of the Alices uses
a dNQualifier it must be the same value in that particular entry (i.e., if
Alice's entries on the frist DSA use dNQualifier they must all have the same
value).

spt

"Manger, James" wrote:

>   ------------------------------------------------------------------------
>
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Nov 1999 16:00:47 +0100

We must come to a common understanding on what the defined usage of
dnQualifier is according to X.520.

X.520 defines:
--------------
5.2.8 DN Qualifier 
-------------------

Lets apply this to two DSA which in this case is represented by a group of
entries each.

DSA 1 group:            DSA 2 group:          
1) CN="Alice"           1) CN="Alice"
2) CN="Bob"             2) CN="Bob"
3) CN="Bob"             3) CN="Fred"

INTERPRETATION 1:
-----------------
One interpretation (Manger) is that this means that dnQualifier is defined
to disambiguate names between independent domains (DSA). In this case group
1 above is invalid because names within in a group must be unique also
without dnQualifier. but if we delete 3) from group 1 we can then use
dnQualifier to disambiguate Alice and Bob btween group 1 and 2. dnQualifier
is used to give all entries a common disambiguating value for each group.

Ex.
DSA 1 group:                  DSA 2 group:          
1) CN="Alice", DNQ="Grp 1"    1) CN="Alice", DNQ="Grp 2"
2) CN="Bob", DNQ="Grp 1"      2) CN="Bob", DNQ="Grp 2"
                              3) CN="Fred"

Note that DNQ is not added to "Fred" since that is not needed.

INTERPRETATION 2
-----------------

Interpretation 2 is the current interpretation behind the current rfc2459
and also the interpretation in the QC profile. This interpretation says
that dnQualifier can be used to disambiguate any name from any other name,
regardless of whether these names are located within the same group or not.

In this case the example groups may look like this:
DSA 1 group:                  DSA 2 group:          
1) CN="Alice", DNQ="1"        1) CN="Alice", DNQ="2"
2) CN="Bob", DNQ="1"          2) CN="Bob", DNQ="3"
2) CN="Bob", DNQ="2"          3) CN="Fred", DNQ="1"

It could also be used to store unique values like this:
DSA 1 group:                  DSA 2 group:          
1) CN="Alice", DNQ="01"       1) CN="Alice", DNQ="11"
2) CN="Bob", DNQ="02"         2) CN="Bob", DNQ="12"
2) CN="Bob", DNQ="03"         3) CN="Fred", DNQ="13"

Now we need to settle once and for all.....

Is interpretation 1 or 2 the right one. 

Please be active on this one because it is VERY important that we agree on
a consensus here very soon.

/Stefan

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

---

From: David Boyce <[email-masked]>
Date: Tue, 16 Nov 1999 15:27:01 +0000

>a consensus here very soon.

Taking your invitation to be active on this:

I'm coming at this from an X.500 point of view.   I cannot see how
Interpretation 2 can possibly be correct, given the statement in X.520
"that its value be the same in a given DSA for all entries to which this
information has been added".  Interpretation 2 clearly violates this, as
there are different values of dnQualifier for entries in the same DSA.

Consequently, if you are serious about conforming to X.520, I would have
to say interpretation 1 is the way to go.

(When we've done this, we can go on to discuss the proper order of RDNs
in Name.)

David.
-- 
David Boyce

MessagingDirect (UK) Ltd.
Tel:	+44 20 8332 9091		 Richmond, Surrey, ENGLAND
Email:	[email-masked]	 WWW: http://www.MessagingDirect.com/

---

From: Ella Paton Bassett <[email-masked]>
Date: Tue, 16 Nov 1999 10:31:20 -0500

Folks:

I've suggested to Hoyt Kesterson and Sharon Boeyen that we consider
slipping a new attribute definition into the FPDAM for X.509 but haven't
heard from them.

 uniqueIdentity ATTRIBUTE        ::=     {
        WITH SYNTAX                     DirectoryString
        EQUALITY MATCHING RULE          caseIgnoreMatch
        ORDERING MATCHING RULE          caseIgnoreOrderingMatch
        SUBSTRINGS MATCHING RULE        caseIgnoreSubstringsMatch
        ID                              id-at-uniqueIdentity }

The uniqueIdentity attribute type provides an unambiguous identity that
may be used as an RDN or in combination with another attribute as an
RDN.

Ella

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Nov 1999 14:57:43 -0500

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.

Russ