Subject: dnQualifier has a bright future?

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 16 Feb 2000 07:35:01 -0000

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: [email-masked] <[email-masked]>
To: Manger, James H <[email-masked]>
Cc: 'Anders Rundgren' <[email-masked]>
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" <[email-masked]> on 02/15/2000
>06:58:06 PM
>
>To:   "'Anders Rundgren'" <[email-masked]>
>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.
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 17 Feb 2000 16:05:09 +0100

James,
to overload the semantics of dnQualifier is probably not requested by anybody.

But we have a "situation" where we essentially only have three more or the less
bad alternatives

1. Do as QC-03 and overload serialNumber semantics.  Has so far as I can see
   been rejected already.  Note: serialNumber is still a good UID replacement.

2  "Legalize" the current wide-spread misinterpretation of dnQualifier and deprecate 
   the "true" X520 definition based on the assumption that there is virtually no
   customer-base using it

3. Define a brand new attribute and OID for this purpose (dn disambigiuer)

Personally I think that #2 would be better as it is closer to existing misuse and probably also
have direct software support (known OID)

But, #3 is OK as well although it seems that new attributes cause a lot of worries about
broken software etc.  I am not THAT worried as QCs will require new SW that currently is not
standard anyway (like browser plugins to support signing)..

Anders