dnQualifier has a bright future?

["Anders Rundgren" <anders.rundgren@xxxxxxxxxx>]

Tom and James,

I guess that these recent findings should eliminate dnQualifier from the list
of subjectAttributes in son-of-RFC2459  as it apparently has nothing to
do with subject attributes.  Right?

I believe though that there is a need for a dnQualifier in the way it was interpreted
by the majority of the PKI community (it was in QC for 12 months!!!).

Tom's suggestion to create a DSAInstance replacement looks real good IMO.

Anders

-----Original Message-----
From: tgindin@us.ibm.com <tgindin@us.ibm.com>
To: Manger, James H <James.H.Manger@corpmail.telstra.com.au>
Cc: 'Anders Rundgren' <anders.rundgren@jaybis.com>
Date: Wednesday, February 16, 2000 01:08
Subject: RE: QC: Identification confusion continues


>     I agree that DNQualifier was defined for a completely different
>purpose, but that definition makes it much less useful as a naming
>attribute than a "tiebreaker" would be.  The name DNQualifier, along with
>the first sentence of its definition, has led many people to believe that
>it was intended to distinguish between two DN's which otherwise would have
>the same name - without further restriction on its use.  Given its actual
>definition, the name "DSAInstance" would probably be more illuminating.
>
>          Tom Gindin
>
>"Manger, James H" <James.H.Manger@corpmail.telstra.com.au> on 02/15/2000
>06:58:06 PM
>
>To:   "'Anders Rundgren'" <anders.rundgren@jaybis.com>
>cc:   Tom Gindin/Watson/IBM@IBMUS
>Subject:  RE: QC: Identification confusion continues
>
>
>
>X.520's definition of dnQualifier is "virtually useless" for your purposes,
>because it was defined for a completely different purpose.  The fact that
>its definition makes it "illegal to use to break ties between two users
>with
>all other attributes the same" strongly suggests it was not meant for this
>purpose.  Attempts to use it for this purpose give it new semantics.
>dnQualifier then has "multiple semantics without adding any disambiguating
>element", which is precisely your (valid) criticism of QC's use of
>serialNumber.
>