RE: Microsoft and multi-valued RDNs (was: draft minutes)

[Stephen Kent <kent@xxxxxxx>]

At 15:02 -0700 7/24/03, Trevor Freeman wrote:
> Hi Steve,
> First off, I am simply providing feedback as to what people do in 
> real deployments. So far the deployments I have seen are effective 
> at meeting the needs of the organisations without braking existing 
> applications. Personally I am mystified as to how adding an 
> arbitrary number to a name helps a user. Every time I have seen an 
> example of such a multi-valued RDN, they look pretty ugly to me. To 
> be widely adopted, a standard has to be a realistic solution to the 
> problem at hand.
>
> Trevor
We obviously have different experiences.  For example, the DoD PKI 
decided to avoid a terminal RDN SET and as a result the CN is of the 
form "John Smith 123457678901" which qualifies as ugly in my book. 
An organization typically identifies employees/students/members by 
name and ID number, which maps naturally to a terminal RDN set of CN 
+ Serial #.

I don't understand your comment: "Personally I am mystified as to how 
adding an arbitrary number to a name helps a user." The issue is that 
organizations make user names unique by assigning such numbers, and 
have for decades. Thus if we are to minimize the impact on an 
organization's existing naming practices, we need to be able to 
accommodate names that have these two components.  For users, the 
goal is to make the name presented to them as natural as possible. 
Separating the two components using the appropriate attributes 
provides an application with opportunities to do this, whereas gluing 
the two attributes together into the CN makes that very hard, since 
it may not be easy to determine where the real common name ends and 
the ID number or equivalent string, starts.

So, from my perspective, a terminal RDN SET is precisely a realistic 
solution to the problem at hand, except for the refusal of at least 
one major vendor to follow standards and support this solution.

Steve