Subject: RE: What good is a DN if the REAL stuff is somewhere else?

From: Anders Rundgren <[email-masked]>
Date: Thu, 16 Mar 2000 14:04:55 +0100

Bob,
What you are saying is that DN is a lost case and cannot be used
for anything except for pointing out a storage position in a directory.

So unmistakable identity is to be found somewhere else?

This is getting weird IMO.

Regarding the RFC822 name it looks like the most well-known CA of all, VeriSign
actually puts it in the DN so apparently theory (PKIX?) and practice are pretty mixed.

BTW, is permanent identifier equivalent to unmistakable identity?  To me
permanent goes one step further.

Although I agree that DN is a lost case, I believe that the better solution is to add an OPTION
to aid its INTERPRETATION, GUI DISPLAY and applicable NAME SPACE.  Such an option
could also include support for subjectAltName in case the directory administrator believes that
this is the place to put the REAL STUFF.   Admittedly a bit hairy

Anders

----------
From:  Bob Jueneman [SMTP:[email-masked]]
Sent:  Wednesday, March 15, 2000 21:46
To:  [email-masked]; [email-masked]; [email-masked]
Cc:  [email-masked]
Subject:  What good is a DN if the REAL stuff is somewhere else?

<<File: ATT00001.htm>>>"What good is a DN if the REAL stuff is somewhere else?"

Anders, this is the train wreck that has been about to happen 
for ten years or more, as a result of overloading the DN and not 
using directories in the way they are typically used in practice.

Render unto Caesar that which is Caesar's, and unto the directory 
administrator as well, and don't try to get organizations to change 
their directory structures to fit your notion of what a certificate should 
look like.  It simply won't work.

As we used to say back in the NADF days, it is like trying to 
teach a pig to whistle.  It's a waste of time, and it annoys the pig!

The DN in the certificate should match whatever the DN in the directory 
is for that user, as determined by the directory administrator. Period. Finis.
Full Stop. The End. 

Otherwise, it may work, but it won't be WORKABLE.

Any other useful information, such as the user's current "real name", 
department organization ,street address, DNA encoding, or whatever, 
that needs to be in the certificate should be carried elsewhere in the 
certificate, in particular in a subjectAltName, just we do for the 
name, and for the same reasons.

Let the record show that for once I agree with Denis. :-)  And by the way, large 
organizations such as the US Navy have come to the same conclusions.

Bob

>>> "Anders Rundgren" <[email-masked]> 03/15/00 12:33PM >>>
Denis,

<snip>

>b) allowing the use of a permanent identifier for an entity, even if
>the name of the entity changes. An example of that case is "C = US ;
>OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
>identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
>an employee number assigned by the Delta company. In that case Mary
>White gets married with Mr Green and becomes "Mary Green". Her
>permanent identifier does not change. Another example is that she
>moves from "Corporate" to "Marketing". Her permanent identifier does
>not change. 

What good is a DN if the REAL stuff is somewhere else?

>
>Note that the last case also allows to solve the problem of re-use
>of DN names and directory names. A DN or a directory name that has
>been used in a certificate can be re-used after the certificate that
>contained it has expired, as long as a permanent identifier, instead
>of the DN or the directory name, can be used by a relying party,
>e.g. in an ACL.

I liked your original suggestion

   http://www.imc.org/ietf-pkix/mail-archive/msg04094.html

more as it keeps DN unmistakable,   Re-use of DNs in QCs does not sound
too attractive IMO.

You original suggestion could also easily be expanded to include support for
"Preferred Display DN components" and the Naming Domain issue which so far
has beem totally neglected.

Both your solutions require a new OID to flag "enhanced" sematic interpretation.

Anders

<snip>

---

From: Ed Gerck <[email-masked]>
Date: Thu, 16 Mar 2000 08:35:24 -0800

> So unmistakable identity is to be found somewhere else?

There is IMO a reference-frame confusion here.  The concept of
"unmistakable identity" is being defined under the QC draft in
terms of the "source" (the directory), not in terms of the
"receiver" (you).

These two views are incompatible and even unknowable I
advance, because the basic tenet in communication is that
there is a chasm between source and receiver -- which is made
worse in the Internet by having one source and 400,000,000
receivers.

So, Bob J. is correct (as well as David K.) IMO, because that
"unmistakable identity" must be defined in directory terms for
the QC based on that directory.  OTOH, in your directory, or
end-user application, you may decide to provide quite another
"unmistakable identity" to that QC -- for example, the timestamp
in milliseconds when that QC: (a) entered your system, (b) was
accepted by you in terms of its signature validation, (c) was
verified by you in terms of its absence in a CRL, (d) was
verified by you in terms of its key challenge-response, etc.
These are *all* an "unmistakable identity" for that QC * within
your system*.  There are many other possibilities, of course.

So, "What good is a DN if the REAL stuff is somewhere else?"
Answer: good at the source, cope with it at your end.

And, X.509/PKIX certificates in general are not different.  In legal
reliance terms, one (the receiver) may trust the confirmation procedures
of the CA during certificate reliance, but one cannot rely upon them
for other than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules (the
source) -- therefore, a X.509 certificate is neither necessarily meaningful
nor valid in a user's reference frame or for the user's purposes.

The source of the confusion is to think that data is absolute.
It isn't -- data is relative. More on this if you wish, off list.

Cheers,

Ed Gerck