RE: QC: Identification confusion continues

[Charles Moore <cmoore@xxxxxxxxxxxxx>]

>===== Original Message From Anders Rundgren
<SMTP:anders.rundgren@jaybis.com> 
=====
>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.

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


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

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

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

>
>Regards
>Anders
>
>----------
>From:  tgindin@us.ibm.com [SMTP:tgindin@us.ibm.com]
>Sent:  Tuesday, February 15, 2000 00:51
>To:  Anders Rundgren
>Cc:  stefan@accurata.se
>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