Re: dnQualifier is used incorrectly

Sean Turner <> Thu, 11 November 1999 21:15 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA09981 for <>; Thu, 11 Nov 1999 16:15:26 -0500 (EST)
Received: from localhost (daemon@localhost) by (8.9.3/8.9.3) with SMTP id NAA02815; Thu, 11 Nov 1999 13:13:40 -0800 (PST)
Received: by (bulk_mailer v1.12); Thu, 11 Nov 1999 13:13:04 -0800
Received: from ( []) by (8.9.3/8.9.3) with ESMTP id NAA02782 for <>; Thu, 11 Nov 1999 13:13:03 -0800 (PST)
Received: from ( []) by (8.9.1/8.9.1) with ESMTP id QAA26333; Thu, 11 Nov 1999 16:11:55 -0500 (EST)
Message-ID: <>
Date: Thu, 11 Nov 1999 16:06:27 -0500
From: Sean Turner <>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Manger, James" <>
CC:, "Kesterson, Hoyt" <>, Stefan Santesson <>
Subject: Re: dnQualifier is used incorrectly
References: <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-ID: <>
Content-Transfer-Encoding: 7bit


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


"Manger, James" wrote:

> 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]
>   ------------------------------------------------------------------------
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64