Subject: RE: QC: Identification confusion continues

From: Anders Rundgren <[email-masked]>
Date: Tue, 15 Feb 2000 11:22:49 +0100

Tom,

Pardon me for bringing this to the list but it is really important

You may be right regarding the uselessness of dnQualifier.  My criticism of the
current solution is that QC assigns multiple semantics to serialNumber without
adding any disambiguiting element.  That is IMO an extremely basic requirement.

Actually, this debate was to a large extent initiated by my request for supporting
unique identifiers as I felt that the ambiguous dnQualifier was not
such a great idea.  And apparently that was in-line with other schemes
like the Swedish and Finnish ID-card programs.  Now we have got
an ambiguous serialNumber definition that at least for hands-on guys like
me looks like no progress at all.

Personally I think "esoteric" X-500 issues (taking in account that dnQualifier was
not challenged for several years) are of limited importance for the success of QC, compared to
elementary issues like how unmistakable identities are to be interpreted by a computerized
relying party, and how unmistakable identities are to be maintained by CAs over time.
None of this is covered by QC-03.

Therefore IMO dnqualifier could without hesitation be interpreted as it (apparently) was
by most people just 3 months ago.  And serialNumber be a replacement for the
defunct X-500 UniqueIdentity.   Then there is a slim chance to actually state some
almost human-readable rules regarding the interpretation of identity information
as well as certificate comparisons.  W.o. such rules we will continue to
"stumble in the dark" forever.  Yeah!  Some over-paid PKI-consultants will have less
to do but I can live with that...

BTW, if ITU's definition of dnQualifier really is useless, is there
no chance to make it right some day?

Regards
Anders

----------
From:  [email-masked] [SMTP:[email-masked]]
Sent:  Tuesday, February 15, 2000 00:51
To:  Anders Rundgren
Cc:  [email-masked]
Subject:  Re: QC: Identification confusion continues

     You may remember that this subject was discussed on the PKIX list at
considerable length during November.  James Manger pointed out that the
definition of DNQualifier was such that it was illegal to use it to break
ties between two users with all other attributes the same on the same DSA.
Your misconception is partly my fault, since I sent you the suggestion to
use DNQualifier a couple of days before James found the following clause
("and that its value be the same in a given DSA for all entries to which
this information has been added") in X.520's definition of DNQualifier.
IMO, this clause makes DNQualifier virtually useless.
     There was then a lengthy discussion of serialNumber, and the
possibility of changing its definition in such a way as to make it useful
for this purpose, which would at least be backward compatible.  IMHO, the
only remaining possibilities are 1) to amend serialNumber's definition in
X.520 and use it for QC's, and 2) to define a new attribute.  I have not,
however, seen any such amendment of serialNumber's definition in X.520.
     I don't think that political correctness in the usual sense of the
term has anything to do with these decisions.  Respect for the wording of
definitions when they have any ascertainable meaning, even when they
reflect poor decisions, is what is driving this.

          Tom Gindin

---

From: Charles Moore <[email-masked]>
Date: Wed, 16 Feb 2000 15:35:21 +1000

>===== Original Message From Anders Rundgren
<SMTP:[email-masked]> 
=====
>You may be right regarding the uselessness of dnQualifier.  My criticism of

the
>adding any disambiguiting element.  That is IMO an extremely basic 
requirement.

cm> Right on....Lets see what luck you have in this forum...

>Personally I think "esoteric" X-500 issues (taking in account that 
dnQualifier
>was
>not challenged for several years) are of limited importance for the success

of
>QC, compared to
>elementary issues like how unmistakable identities are to be interpreted by
a
>computerized
>relying party, and how unmistakable identities are to be maintained by CAs 
over
>time.
>by most people just 3 months ago.

as there are about 400Mil certs in exittance with DNq in the form you
require 
it is interesting to listen to the rastional of why they dont work...
The fact is this argument is one about a companies implementation and
exerting 
this into a standard... Might is right type argument that is more 
commercial/political rather than technical...

My one cents worth.....
An interesting side affect is that the same company is aruing in the ITU
that 
PKIX has already agreed  that serial numebvr is the ONLY solution...
Circles within circles....

And serialNumber be a replacement for the
>defunct X-500 UniqueIdentity.   Then there is a slim chance to actually
state
>some
>"stumble in the dark" forever.  Yeah!  Some over-paid PKI-consultants will 
have
>less

The ITU definitioon is ambiguios, there is no problem to solve ( see above),

the arguments are purley accademic and based on commercial interests...
Something that the ITU has traditionally been nuetral about, but this si not

the case today....

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 18 Feb 2000 14:39:03 +1100

Charlie,

I am beginning to understand your position as more of the history of dnq is
revealed.  I can even accept your solution - imperfect but usable.  Your
solution does go against X.520's explicitly stated intention for dnq, but
perhaps "intended" does not carry the same weight as "shall" or "must" in a
standard.

If QC does revert to using dnq to disambiguate multiple John Smiths it
should add a paragraph such as:
"X.520 intended dnQualifier to disambiguate entries in different
directories, with the same value used for all entries within a directory.
This intention, which is now deprecated, does not preclude the use of
dnQualifier as defined in this standard."
This paragraph would, at last, document this interpretation of dnq in a
standard.  Future users of the standard (who will not have been privy to
these PKIX discussions, as I was not privy to other committee meetings) will
understand the clash with X.520 (and perhaps question it no more).

P.S. The "reference source" & "basis" for the objection was the 2nd sentence
of the X.520 (1993 & 1997) definition of dnQualifier.  No experience, no
implementations, no legacy systems, no commercial imperatives, no history
(well a little), no compatibility, ...

My motivation was to keep the meaning in attribute types.  I see potential
value in knowing the type of an item and in the arrangement of types
(Att/RDN/DN).  However, this value vanishes if the syntax is used without
the semantics, or at least diminished if the semantics are loosened.  This
motivation impacts dnq in two ways: firstly the much discussed clash with
the "2nd sentence" in X.520 (clash = loosened semantics), secondly the
chance to use dnq to alleviate more important semantic perversions like
VeriSign's misuse of org & org unit.  I hoped dnq could be used to include
issuer information in a subject DN without implying a strong relationship
between the subject and the info (using org implies an "affiliation" between
the two).

The end game: for a computer looking at a DN (& little else) to be able to
understand what it means.

P.S. Where is dnQualifier deprecated (standard/draft/discussion/..)?  Is it
just the "intended use" sentence that is deprecated or the whole attribute?